miamoto.net

§ 結局シリコンバレーなのか！？（１）

CNET Japan Blog：100万行のソフトの作り方(1)

…たまには仕事関連のこともエントリーしないといけないと思うので。
またしても梅田さんのところのお話。今回はゲストの石黒さんが執筆。

--

今回提示された問題意識は、私にとってみると、まさに「それだ！」という内容。現在私が会社で取り組んでいるのが「スピードとスケーラビリティ」問題そのものなのだ。梅田さんが以前にとりあげたときも気になったのだが、なんといても今回は多少なりとも具体的な方法論について触れられるような予感がする。

作っているモノが生モノ（？）なので、ほとんどの場合、割り当てられている開発時間が非常に短い（６週間以内）。そんなわけで誰でも同じことを感じていると思いますが、常識はずれに高い生産性と品質が欲しいのです。それも今すぐ。

とにかく、今回のトピックの前提となっている条件は驚くほど私の現状に近い。

まさに、シリコンバレーの特徴は、「スピードとスケーラビリティ」に尽きると言っていいでしょう。…（中略）…会社も製品も、まったく何もないところから作るわけですから、全てがスクラッチ・ビルディング（scratch-building）に特化したものになっています。

シリコンバレーの開発スタイルを簡単にまとめてみると、こうなります。

• 極めてシンプルな組織
• 完全にトップダウンの命令体系
• レビュー、ソースコード管理、デイリービルドを毎日行なう早い開発サイクル
• ダイナミックなリソース割り当て

何かどこかで見たことがあるような…って、これ、ウチのワーキング・ユニットと同じです。そのままです。

ウチの会社、多くの場合、まだ存在しないものをつくっているのでコードの約90％はスクラッチです。組織のスケールが小さいので、あがってきたコードはすぐにレビューしてコーディネイトした後に、即ビルド。これを延々と繰り返します。違いを強いて言うなら、リソースの割り当ては動的ですが、予算が少ないのでスケールが小さいことくらい。

経験的にこのようなカタチに落ち着いたのだが、もっと洗練された先例がある、ということなのだろう。やっぱりシリコンバレーに逝かないととダメなのかな…。無知は罪だ。

「明日は、このシリコンバレー流100万行のソフトの作り方を詳しく見てみることにしましょう。」

…肝心なところは明日か。
ってことで、このエントリーもつづく。

続き：結局シリコンバレーなのか！？（２）