コンピュータサイエンス系の人たちの間では、サーチのテクノロジーで人気があるのはリリバンシー、次はバーティカルサーチ。
他の要素としては、クローリングとインデキシング、クラウド系というところらしい。
サーバをグリッド化（やや死語だな）して、、みたいなのは、コンピュータサイエンスというよりはエンジニアリング。
昔、シックスアパートの某Perlギークの人と話をしたとき、「自分はエンジニアリング系じゃないんで、、」と言っていた。そのときはエンジニアリングという言葉の定義がよくわからなかったけど、なんとなくわかってきたかも。
あ、全文検索とかマイニングとかも面白いといっていた。まあこれは要素技術だけど。Luceneを作った人が別で作ってる奴が結構良いって。なんだろ。SolrかHadoopか。
あと、エンタープライズサーチ。例えばメール。誰がどんな単語を多用しているかをサマリーしたり、検索させたり。
あと、CJKって言葉があって、China, Japan, Koreaの開発は中国がヘッドみたいね。
そうそう、Googleとかだとメインの部分（エンジンとかフレームワーク）はコアチームがやっていて、そこは普通の社員はいじれない状態になっているらしい。
じゃあその他の９８％の社員（それでもトップレベルなんだろうけど）は何をしているかというと、個々のファンクションを実装したり、DBをいじったりしているんだとさ。
***
MS内部のソフトウエア開発手法の話。
プロジェクト構成：
PM、プログラマ、テスター
とにかく、ソースレビューをまじめにやっている。
コードを書き、自分でテストしたら旧ソースとのdiffの結果を全員に配る。
すると、それに対して激しくコメントが入る。
ここはメールベース。
このアルゴリズムはいまいちだ、とかこの変数はいまいちだ、とかいろいろ入るらしい。
diffベースでのソースレビューが完了したら、再度自分でテストして、チェックイン。
するとテスターがテストする。
テスターの地位はプログラマ並みに高い。
ルールが結構ある。
バグが出たら、なぜそのバグが出たかを説明し、チーム全員が納得しないといけない。
全員が納得できない場合はどうなるんだろ。
結構、この「チーム全員に対する説明責任」っていうのがある。
先の、ソースコードレビューについても、全員がOKというまではチェックインしてはいけない。
細かく１行１行レビューしてコメントするらしい。だからメールが超長いと言っていた。
チーム内のトップクラスのプログラマからも激しくコメントが入る。
なので、チームの能力は徐々に平均化されていく。
（逆にこれがないと、いつまでたっても新人は新人のままだとも言っていて、なるほどと思った）
一通りの実装が終わり、全部のバグが潰れたら、リリースする。
（バグの消化曲線グラフ的なものもあるらしい。１５年前は私もそういうことやってたな。。）
リリース担当者は開発チームとは全然別の担当になっており、リリース後の不具合についても人目で誰が悪いのかが判るようになっている。アプリなのかDBか、ネットワークか、アプリだとしたらどこか。
アプリでバグが出た場合、なぜそのバグが残存してしまったのか、明確な説明をしなければならない。そしてそれはチーム全員が納得するまで説明しないといけない。
とにかくこのコードレビューをする、っていうのと、チーム全員が納得するまで、っていうのは良いやり方だと思う。
ちなみにMS内部でもCVSを使っているとのこと。VSSじゃないんだへぇ〜
***
プロジェクトの工数の管理方法の話も聞いた。
プログラマが一日のうち、コードを書く時間は４時間とする。
最低でも４時間確保しなければいけない。
それ以外の時間はその他のことをやる。コードレビューとか、他の人とのコミュニケーションとか。
実装機能の一覧を渡されて、一つ一つに対して自分で見積もりをする。時間単位で。
それを積み上げたものが、スケジュールとなる。
積み上げたものを消化していくから、右肩下がりのグラフになる。
真っ直ぐ直線でゼロになればいいけど、大抵は納期ぎりぎりで減少幅が小さくなり、最後は不要な機能を削って工数を減らして調整し、リリース、ということが多いらしい。
その分、納期遅延を起こした事は一度も無いとのこと。（過去二年で）
そしてここでもルール。
自分で行った見積もりに対して、多く時間が掛かったり、あるいはその逆になると、それがなぜそうなったかを説明しないといけない。
あと、その日の予定を消化しきれなかったら、翌日に回すという手続きを毎日やらないといけない。
結構プレッシャーあるなあ。
この工数管理は、単純にExcelベースでやっているとのこと。
MS Projectじゃないんだ。へぇ〜
MS内部の話を書いた本ってどんなのがあるんだろ。全然しらない。これくらいしか。
闘うプログラマー〈上〉―ビル・ゲイツの野望を担った男達
そんなわけで、某社と某社との合併直前最終宴会なのに某氏とそんな話を延々としていて他の人と殆ど話していない。わざわざ来ていただいたOBOGの方も居たのに。すみませんすみません
***
まあ上で書いたような分業でのソフトウエア開発ってのも悪く無いな。人を代替可能なパーツと見なし、、っていうところもあるけど、そのかわり個々のパーツの能力は時間と共に磨かれ、素晴らしいものになるだろう。
一人で最初から最後まで面倒見る（実装部分については他の人からの助けを借りたりするけど）、っていうやり方の方がなんとなく好みなのは確かなので、それぞれの良いとこ取りしたいところ。
他の要素としては、クローリングとインデキシング、クラウド系というところらしい。
サーバをグリッド化（やや死語だな）して、、みたいなのは、コンピュータサイエンスというよりはエンジニアリング。
昔、シックスアパートの某Perlギークの人と話をしたとき、「自分はエンジニアリング系じゃないんで、、」と言っていた。そのときはエンジニアリングという言葉の定義がよくわからなかったけど、なんとなくわかってきたかも。
あ、全文検索とかマイニングとかも面白いといっていた。まあこれは要素技術だけど。Luceneを作った人が別で作ってる奴が結構良いって。なんだろ。SolrかHadoopか。
あと、エンタープライズサーチ。例えばメール。誰がどんな単語を多用しているかをサマリーしたり、検索させたり。
あと、CJKって言葉があって、China, Japan, Koreaの開発は中国がヘッドみたいね。
そうそう、Googleとかだとメインの部分（エンジンとかフレームワーク）はコアチームがやっていて、そこは普通の社員はいじれない状態になっているらしい。
じゃあその他の９８％の社員（それでもトップレベルなんだろうけど）は何をしているかというと、個々のファンクションを実装したり、DBをいじったりしているんだとさ。
***
MS内部のソフトウエア開発手法の話。
プロジェクト構成：
PM、プログラマ、テスター
とにかく、ソースレビューをまじめにやっている。
コードを書き、自分でテストしたら旧ソースとのdiffの結果を全員に配る。
すると、それに対して激しくコメントが入る。
ここはメールベース。
このアルゴリズムはいまいちだ、とかこの変数はいまいちだ、とかいろいろ入るらしい。
diffベースでのソースレビューが完了したら、再度自分でテストして、チェックイン。
するとテスターがテストする。
テスターの地位はプログラマ並みに高い。
ルールが結構ある。
バグが出たら、なぜそのバグが出たかを説明し、チーム全員が納得しないといけない。
全員が納得できない場合はどうなるんだろ。
結構、この「チーム全員に対する説明責任」っていうのがある。
先の、ソースコードレビューについても、全員がOKというまではチェックインしてはいけない。
細かく１行１行レビューしてコメントするらしい。だからメールが超長いと言っていた。
チーム内のトップクラスのプログラマからも激しくコメントが入る。
なので、チームの能力は徐々に平均化されていく。
（逆にこれがないと、いつまでたっても新人は新人のままだとも言っていて、なるほどと思った）
一通りの実装が終わり、全部のバグが潰れたら、リリースする。
（バグの消化曲線グラフ的なものもあるらしい。１５年前は私もそういうことやってたな。。）
リリース担当者は開発チームとは全然別の担当になっており、リリース後の不具合についても人目で誰が悪いのかが判るようになっている。アプリなのかDBか、ネットワークか、アプリだとしたらどこか。
アプリでバグが出た場合、なぜそのバグが残存してしまったのか、明確な説明をしなければならない。そしてそれはチーム全員が納得するまで説明しないといけない。
とにかくこのコードレビューをする、っていうのと、チーム全員が納得するまで、っていうのは良いやり方だと思う。
ちなみにMS内部でもCVSを使っているとのこと。VSSじゃないんだへぇ〜
***
プロジェクトの工数の管理方法の話も聞いた。
プログラマが一日のうち、コードを書く時間は４時間とする。
最低でも４時間確保しなければいけない。
それ以外の時間はその他のことをやる。コードレビューとか、他の人とのコミュニケーションとか。
実装機能の一覧を渡されて、一つ一つに対して自分で見積もりをする。時間単位で。
それを積み上げたものが、スケジュールとなる。
積み上げたものを消化していくから、右肩下がりのグラフになる。
真っ直ぐ直線でゼロになればいいけど、大抵は納期ぎりぎりで減少幅が小さくなり、最後は不要な機能を削って工数を減らして調整し、リリース、ということが多いらしい。
その分、納期遅延を起こした事は一度も無いとのこと。（過去二年で）
そしてここでもルール。
自分で行った見積もりに対して、多く時間が掛かったり、あるいはその逆になると、それがなぜそうなったかを説明しないといけない。
あと、その日の予定を消化しきれなかったら、翌日に回すという手続きを毎日やらないといけない。
結構プレッシャーあるなあ。
この工数管理は、単純にExcelベースでやっているとのこと。
MS Projectじゃないんだ。へぇ〜
MS内部の話を書いた本ってどんなのがあるんだろ。全然しらない。これくらいしか。
闘うプログラマー〈上〉―ビル・ゲイツの野望を担った男達そんなわけで、某社と某社との合併直前最終宴会なのに某氏とそんな話を延々としていて他の人と殆ど話していない。わざわざ来ていただいたOBOGの方も居たのに。すみませんすみません
***
まあ上で書いたような分業でのソフトウエア開発ってのも悪く無いな。人を代替可能なパーツと見なし、、っていうところもあるけど、そのかわり個々のパーツの能力は時間と共に磨かれ、素晴らしいものになるだろう。
一人で最初から最後まで面倒見る（実装部分については他の人からの助けを借りたりするけど）、っていうやり方の方がなんとなく好みなのは確かなので、それぞれの良いとこ取りしたいところ。
コメント