キーノートはドワンゴの川上さん。はじめて講演を聞いたのだが、キレキレで面白かった。言いたい放題。 クラウドの登場でウェブエンジニアが簡単にサービスを作れるようになった。それがエンジニアの質の低下を招いているのではないかという指摘をしていた。 スクリプトエンジニア、コンピュータの動作原理を知らないエンジニア、性能の理論的限界を計算できない、開発手法の宗教的依存度が高い、自分の頭で考えるより結果をググって覚えるだけ。二流のエンジニアの大量生産という現象を指摘していた。 自分の会社の会長が、エンジニアをdisるというのは自分がその会社にいたらちょっときついなあという印象を持つのだけど、ベースには技術者に対する愛があるので、ちゃんとコンテキストを理解すれば、そんなこともないのかなと思った。 一つ一つを文脈を無視して切り取ると誤解を招きかねないフレーズである。技術者に取ってのレッドオーシャンを避ける

ムーアの法則（18ヶ月で半導体の能力が２倍になる）というのは有名だが、それに比べてブルックスの法則は知られていない。 http://commons.wikimedia.org/wiki/File%3AFred_Brooks.jpg *1 ブルックスは1960年代、IBM System/360用オペレーティング・システムOS/360の開発責任者で、後にそのときの経験をもとに人月の神話という本を書いた。 大規模ソフトウェア製品開発の難しさを書いた画期的な書物である。IT産業に従事しているなら必読の書である。ソフトウェア開発あるいはプロジェクトマネジメントに関わる人はだまされたと思って読んだ方がいい。わたしの日記でも何度となく紹介している。 それはともかく第二章人月の神話だ。次のような例題がある。12人月かかると見積もられた仕事があるとして、３名で４ヶ月でその作業を完了すると考えた。そして一月毎

32年間続いた笑っていいともが3月末で終わってしまったが、タモリ倶楽部はまだ終わる気配もない。終わらないでほしい。 http://ja.wikipedia.org/wiki/%E3%82%BF%E3%83%A2%E3%83%AA%E5%80%B6%E6%A5%BD%E9%83%A8 金曜日の夜、酔っぱらいって帰って来て観るというのが一週間の締めみたいなものだ。酔っぱらっているから、途中で寝ちゃったり、そもそも番組が始まる前に寝落ちをすることも少なくない。土曜日の朝に、昨晩タモリ倶楽部を見過ごしたことなどを思い出し、微妙に悔しかったりする。 とはいうものの録画までして観ることはしない。金曜日の深夜にへべれけになりながら観るというのが正しいタモリ倶楽部の楽しみ方である。寝ちゃったらそれはそれでしょうがないのである。 ここだけの話なのだが、いつかタモリ倶楽部に出るのがわたしの夢である。本当は、笑

ともちゃんがGitHubを勉強したいにゃん、ということなので、勉強会に行ってきた。みんな猫耳つけて発表するというわけのわからない勉強会であった。 http://atnd.org/events/48075 Introduction to Git and GitHub #git_nyan from Hiro Yoshioka のれんがかかっていた。 これらはすべて手作り 沢田さんの説明 LTもあった GitHub実践入門とステッカー わたしのお話は、GitがLinusの自分の問題を解決することから始まったというような歴史の話からあれやこれや。Linuxのソースコードを管理するためには分散型、高速、高信頼性などが必要。 Linusは自分のPCのバックアップをとっていなくてもコミットしたものをインターネットにおいておけば誰かがコピーして、そのコピーは改竄することが非常に難しいので安全に複数のバック

グロースハッカーを読んだ。 従来のマーケターはマーケティングのイロハをアンラーニングする必要がある。 「製品開発とマーケティングを完全に別のプロセスとして行う方法はもう古い」（17ページ） 何ヶ月もかけて綿密な準備をしてマーケティングのために莫大な予算を使って製品を売り込む。マーケターは誰も利用したいと思わない製品だということを数ヶ月後に知る。そのような従来型の方法と一線を画するのがグロースハッカーだ。 本書で紹介していることのどれもがシンプルだ。 人が欲しがるものを作れ。ポール・グレアム。 誰のための製品なのか。なぜユーザーがこの製品を使うのか。なぜ私がこの製品を使うのか。 この「ソクラテス式問答法」が効果的だ。何度も何度もそれを問い直す。 著者の成功事例、新刊書をベストセラーにした方法も参考になる。またクックパッドの加藤恭輔氏による日本語版の解説が具体的で素晴らしい。 薄くて読みやすい

わたしは、1984年に日本デジタルイクイップメント研究開発センターという会社に大学院を修了して新卒として入社した。日本ディジタルイクイップメント研究開発センターというのは米国のコンピュータベンダーDigital Eiquipment Corporation（これよりDECと記す）のEngineering部門の子会社で、当時日本には別法人で日本ディジタルイクイップメント株式会社という販売サービス子会社というのもあった。後に二つの日本法人は合併する。 これはIT産業の歴史の話なので若い人にはなじみがないことだと思うので、ちょっと詳しく書くと、当時、IT業界というのはIBMがその覇権を握っていて、日本のハードウェアベンダーがそのIBMにキャッチアップするために熾烈な戦いを挑んでいた。世界的にみると、IBMの後を、DEC、日本のハードウェアベンダー、富士通、日立、NEC、東芝、三菱、沖電気などが競

この四月から新しい道に進まれた方、おめでとうございます。謹んでお祝い申し上げます。 4月1日の入社式が震災の影響で取りやめになった会社もあると聞く。未だに自宅待機で落ち着かない会社もあるかもしれない。 それでも多くの新入社員の皆さんにとっては、期待に満ちた一日だったのではないかと想像する。 この4月に社会人になったみなさんに何か一言お伝えしたい。 新入社員の皆さんへアドバイスとか、そんなものはないので、自分はこーやったということを思い出してみる。最初にやったことは、多分、同期や職場の先輩、上司の名前を覚えることだった。一人でも多くの人の名前を覚えた。そして、同時に自分の名前を一人でも多くの人に覚えてもらった。何度も何度も自己紹介をした。 新社会人の皆さんにとって新しい会社に馴染むことが当面の課題だと思う。大きな会社であれば、100名を越える同期がいることだと思う。研修期間中様々な課題が与え

先日、情熱プログラマー読書会が楽天であったので、参加した。LT(Lightning Talks)で発表もした。発表スライド 情熱プログラマー 自分にとっての情熱プログラマーってなんだろうと考えた。 この「情熱プログラマー」という書籍は、ソフトウェア開発者の幸せな生き方という副題がついているのだが、純粋な技術書というよりもプログラマーにとっての自己啓発書みたいな位置づけの書籍だ。 ソフトウェア開発におけるプログラマという役割を取り替え可能な部品のような立場から見れば、プログラマはコストであり、どのようにしてそのコストを削減するかということになる。コストを安くするという考えで行けば年功序列的な賃金体系の中ではベテランより若いひとを使った方が安く上がる。数字でソフトウェア開発を見ていけば人月工数がすべてであり、開発コストは工数＊人月単価になる。 そのような立場で言えば人件費の高い日本で開発するの

井の頭公園の入り口にある焼き鳥屋でプロジェクトのキックオフをやるのだと、唐突に@papandaが言った。その焼き鳥屋の名前がどーしても出てこない。なんだっけかな〜〜。あまりに気持ちが悪いので@papandaにTwitterで聞いてみたらどうかねという指令をだしたのが、http://twitter.com/papanda/status/10567492313 『急募。井の頭公園にある焼き鳥屋の名前。』 それがDevLOVEとの出会いである。*1 デブサミのお母さん岩切さんがDevLOVEの@papandaは熱いと熱く語るものだから一度勉強会でじっくりお話をしてみたいとかねてから思っていた。 楽天に転職して早いものでもう半年以上たった。楽天の芸風を変えるのだと、勉強会だなんだといろいろ試行錯誤をする日々であった。 勉強会に行く奴は放っといても行くし行かない奴はなにをしても行かない。熱い奴もいれ

会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその

勉強会エバンジェリストhyoshiokです。みなさんいかがお過ごしでしょう？ 開発は楽しいという@papandaの熱いメッセージが突き刺さるDevLove首謀者の基調講演で幕を開けたデブサミ（デベロッパーズサミット）も無事終了し、明日からは日常がまっている。 今週は、自分にとっての日常であるカーネル読書会も2世紀目に突入し、その記念すべき第一回を新世代にふさわしい若手ハッカーの@frsyukiにkumofsについてガツンと発表してもらう。楽しみ楽しみ。*1 昨年8月に今の会社に入社して以来、社内勉強会もいろいろやって、縦組織でも横軸プロジェクトでもない、第三の社内勢力としてのコミュニティ的価値観の醸成などをおこなってきた。最近ではいろいろなグループがいろいろな勉強会をいろいろやっていたりする。 で、先日Ruby朝練の首謀者A（以下（あ）と略す）にRuby朝練について聞いてみた。チームに新人

ソースコード理解と勉強会というタイトルでお話をした。ソースコードを読むことの意義などを話した後、わたしのしょぼいテクニックを恥ずかしながら披露した。 Sourcecode Reading Workshop2010View more presentations from Hiro Yoshioka. ワークショップは下記にあるようなプログラムになっている。 http://se.naist.jp/events/srw2010.html Javaアプレットのコードがあって、それぞれのパッチをあててよいかというのを判定するというのを実際のコードを読みながら行う。当初、コードを読むというハンズオンには参加するつもりもなかったのだが、2時間ほどぼーとしているのもヒマだし急遽参加することにした。ソースコードをPCにダウンロードしておけばよかったのであるが、ダウンロードしていなかったので紙でソースコードを

先日、ライブドアの社内勉強会に参加した。他社の社内勉強会をするという機会はそうそうない。その貴重な機会を与えていただいたライブドア情報環境技術研究室　執行役員　CTA　室長　伊勢幸一さんには厚く御礼を申し上げたい。担当の門馬さんにも大変お世話になった。また、当日参加していただいたライブドアの皆様にも御礼を申し上げたい。*1 書き出しがいきなり固くなちゃった感があるが、お話はいつものカーネル読書会のことというか、勉強会のことというか、それを社内でやってみたら、どーゆーことになったかとか、技術とはまったく関係ないよた話をさせていただいた。 今回、お話をさせていただくにあたり、わたしのセッションの部分を後日公開するということをお願いした。わたしのプレゼンは日頃いろいろなところでお話しているものであり、所属企業に属する非公開情報も特にないので、無理を言ってお願いした。 カーネル読書会の作り方＠ライ

昔、無駄なドキュメントは書くな(http://d.hatena.ne.jp/hyoshiok/20050510#p1)というよた話を書いたのだが、酒の席で、似たようなお話をしたので、いろいろ考えてみた。 酒の席でのお話というのは、次の日すっきり、さっぱり忘れるのが常であるので、詳細はもちろん把握していないのだが、概要程度は思い出せるので、それを再現してみたい。 登場人物は、工程改善チームのおじさんTさん、工程改善チームの若者（初対面）、SIerから転職してきた同じグループで9月入社のSさん、そしてわたくし。大井町の魔界のおでん屋の2階。民家の2階風で、テレビもある。だらだら終電までいればタモリ倶楽部も見られるねと言う感じの飲み屋である。 若者はドキュメントの標準化とかいろいろ悩んでいる。若者「詳細設計ドキュメントとかどうするんすかね？どー標準化するんすかね」、よしおか「そんなものは書かない

後で書く書いた。 第100回カーネル読書会にLinusをはじめとするLinux Kernel Hackersにいっぱいいっぱい来てもらった。 時系列に言うと、こんな感じだ。2008年の春頃（調べてみたら、夏ではなくて春頃に2009年のKernel Summitは日本でやるとアナウンスされていたようだ）から、2009年のKernel Summitが開催されるので、そこでカーネル読書会BoFを開催して、そこにLinusを呼ぼうというようなことを言っていた。id:publichtmlに指摘されて気がついたのだけど、1000speakersでそんなことを言っている。*1 カーネル読書会の作り方　1000 speakers conference, 2/23/'08View more documents from Hiro Yoshioka. それ以来、カーネル読書会の前説で、Kernel Summi

OSC2009 Tokyo/Fallで勉強会ラジオをやります。以下はその告知です〜〜 昨年のOSC2008 Tokyo/Fallで大好評だった「勉強会大集合」が、 「勉強会 x 勉強会（metacon）ラジオ」になって帰ってきました！ 勉強会 x 勉強会（metacon）ラジオでは、 オープンソースカンファレンス2009 Tokyo/Fallで紹介する あなたの「初めての勉強会の思いで」を募集しています。 どきどきしながら申し込んだ初めての勉強会、 隣の人に話しかけるのに勇気が必要だった懇親会、 細長い形の不思議な名刺や、そこに書いてある謎のid:○○の文字・・・ あなたが「初めての勉強会」と聞いて思い出すのは、 どんなことですか？ あなたの思い出を募集します！ いただいた思い出は、2009年10月31日(土)開催の 「はじめての勉強会ストーリー＠OSC2009 Tokyo/Fall」 h

ご報告*1したとおり、この8月より縁あって楽天株式会社へ転職した。 ここの日記のタイトルに「楽天へ転職」と記さなかったのでRSSリーダやアンテナなどでわたしの日記をウォッチしている皆様には陽に伝わらなかったみたいで、未だにミラクルにいると思っている人も少なくないようだ。先日も「LinkedInのupdateメールで @hyoshiok さんが楽天に移られたことを知る。吃驚！」*2とか「あれ、そうだったんですね RT @hyoshiok: 8月より縁あって、楽天にお世話になっています。LinkedInってほとんど放置だったんですがたまには役（？）にたちますね。 RT @masanork LinkedInのupdateメールで @hyoshiok さんが楽天に移られたこと」*3とつぶやかれたりしたり。 それはともかく、50歳からの転職という感じで、典型的な中高年の転職という感じではないが、一つ

企業に取って従業員が自主的に勉強会を開催する意義というのは、（１）社員の知識、スキル向上、（２）社員のモチベーションアップ、（３）社内の活性化、などなどいろいろある。まあどうとでも言えるというと語弊があるけど、定性的なメリットはいくらでも言える。定量的なメリットについて言うのはなかなか難しいが、定量化できないからといって、まったくやらない、あるいはその意義を無視する、あるいはその意義を過小評価するというのは、あまり賢い方法ではないと思う。 一方で勉強会を開催するデメリット、コスト、リスクなどについて考えると、コストは勤務時間外でやるので、ほとんどかからない、リスクというのもほとんんどないと思う。 やらないことのデメリット（機会利益の損失）は、やることのメリットのちょうど裏返しである。大きな企業であれば、事業部間をまたがった横串の関係が出来上がって、緩い情報共有などが出きるというメリットもあ

日本は全体主義の国ではないから、職業選択の自由はあるし、思想信条の自由ももちろんある。自分の親が仮に政治家だったとしても自分が政治家にならなければいけないということはない。どっかの国の主席の後継者がどうだこうだというのは、国レベルのリーダーを世襲で選ぶという前近代的なわかりやすいシステムに対する日本人の憧れの表現である。親の仕事を継ぐのが正しい親子関係であると心の底では思っているのである。世襲でしょうやっぱしと思っている。 日本にも政治家の世襲という世界に誇るべきシステムはある。日本の総理大臣になるには親が政治家でないといけない。日本の憲法にはそんなことは一切書いていないが、日本人は皆知っている。政治家という要職につく人間はどこの馬の骨かわからないようなものには勤まらない。由緒正しい血筋を持った人間でなければ任せられない。そのために親が政治家でないような人間には総理大臣は勤まらない。総理大

勉強会はバブルなのか？kanasansoft http://www.kanasansoft.com/weblab/2009/06/metacon2009.html が問題提起している。 バブル経済というは、株価や土地などの資産価格が、経済の基礎的条件から想定される適正水準を大幅に上回る状況を指すことを言う。勉強会によって起業したとか、どこかがそれを事業にしたとか、株式公開をしたとかいうことはないので、勉強会によってバブルが引き起こされているということはない。 経済的な定義で言えばそのとおりなのだけど、確かに半径5メートルの範囲では勉強会は活発に開催されている。実感としてバブルとはいえないけれどプチブームと言っていい状況にはあると思う。 それはいけないことなのだろうか。それは憂慮すべき状況なのだろうか。何か問題があるのだろうか。それを考えたい。 1998年、Linuxがビジネスマンによって発