お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

100万行のソフトの作り方(2)

2004/04/27 09:15
  • このエントリーをはてなブックマークに追加

プロフィール

umeda

シリコンバレーで経営コンサルティングを行なう傍ら、ベンチャーキャピタリストとしても活躍する梅田望夫さんが、IT業界の先を読むのに役立つ英文コンテンツを毎日紹介していきます。これを読めば、英語と業界動向を読む力が同時に身に付くはず(このブログの更新は2004年12月30日で終了しました)。
ブログ管理

最近のエントリー

[ゲスト] 石黒邦宏 Kunihiro Ishiguro
4月26日(月)〜4月28日(水)までの間、梅田望夫さんの代わりに石黒邦宏さんがゲストブロガーとして登板します。梅田さんの更新は5月6日(木)からになります。

石黒さんのプロフィール:1993年銀行向け大規模開発プロジェクトのシステム管理者としてキャリアをスタート。1995年にISPへ転職、国内外のインターネットバックボーン構築に携わる。1996年ウェブシステム作成会社へ転職。同年フリーな経路制御ソフトウェアGNU Zebraの開発を開始。1997年、日本ネットワークオペレーターズグループJANOGの設立に関わり初代会長に就任。1999年シリコンバレーにIP Infusionを吉川欣也氏と共同設立、CTOとして技術面のマネージメントにあたっている。

今月の頭に、インドのソフトウェア開発アウトソース企業 Infosysm がシリコンバレーにオフィスを作るとアナウンスをしました。

今後3年間で500人規模にまで拡張する予定とのことです。もちろん地理的に顧客に近い場所に拠点を作って、サービスを充実したいというのが一番の目的でしょうが、最近インドのオフショアリング開発への風当たりが強いので、こういう形でシリコンバレーの雇用に貢献しますというメッセージもあるのだと思います。

昨日触れたように、もともとシリコンバレーのソフトウェア開発能力自体はそれほどレベルが高いわけではありませんから、コストの安いオフショアリングは常に魅力あるものでした。

インドへのオフショアリングがこれほど広まる前は、アメリカ国内での開発分散がよくおこなわれていました。私が働いている会社でもノースキャロライナ州にオフィスを作ってそこでソフトウェアの一部分の開発をしていました。人件費やオフィス代がシリコンバレーに比べてかなり安いこともあって、ノースキャロライナ州、オレゴン州、ユタ州あたりに開発チームをつくるのが一般的に行なわれてきました。

インドのオフショアリングの波で、軒並こうしたアメリカ国内の分散拠点に影響が出ています。昨年から、アメリカ国内のソフトウェア開発拠点の縮小や廃止のアナウンスが続いていますし、私の会社でも、ノースキャロライナの拠点を閉じ、インドのオフショアリングサービスを使うようになりました。

極めてシンプルな組織

短期間のうちに、100万行レベルのソフトウェア開発を可能にするスタイルには、こうしたオフショアリングの開発サービスがうまく利用できることも重要な要素です。

まず、組織から見てみましょう。エンジニアリング組織は極めてシンプルに構成されています。技術担当副社長(Vice President of Enginnering)と呼ばれる開発現場の最高責任者の下に、2、3人から多くても5人くらいのチームがフラットに並んでぶらさがっているというのが一般的な組織です。各チームには、チームリーダーと呼ばれるシニア・エンジニアが一人いて、チーム内のマネージメントを行ないます。

これでおしまいです。チーム編成は、プロジェクトの状況に応じて動的に変化します。ヤバそうなプロジェクトがあれば、平気でエンジニアを追加しますし(プロジェクト管理理論からすると、最もやってはいけないこと)、チームごと別のエンジニアに変えてしまったりすることもあります。

アウトソースする場合は、チームリーダーはシリコンバレーにいてプロジェクト管理を行ない、チームメンバーの部分をアウトソースします。こうすることで、技術担当副社長の管理の手間を減らし、仮に失敗したとしても、1つ1つのチームが小さいのでリスクを最小にするようにできます。もちろん経験を積んでチーム全体をアウトソースしても大丈夫だという見極めがつけば、積極的に進めていきます。

完全にトップダウンの命令体系

通常、技術担当副社長は人事権を持っています。「金持ち喧嘩せず」と言いますが、シリコンバレーでは、「貧乏人こそ喧嘩してはいけない」と言えるでしょう。よく、米国のドラマで、パーティーで上司に会う場面で、やけにびくびくしている部下という図がありますが、あれは下手なことをするといつ解雇になるかわからないという背景を冗談をまじえて強調しているのだと思います。それが原因かどうかは分かりませんが、命令体系は、完全トップダウンです。上の命令は絶対です。プロジェクトを定義して、チームリーダーをまじえて、それがどのくらいの期間で実装可能かどうかを議論したあとは、「Go」となります。

シリコンバレーで働き始めてから気がついた事の1つですが、部下に何か技術的なことで相談すると、それとなく返答を避けられます。完全に技術的な議論であればいいのですが、何らかの判断が含まれるものについては、「It's your call」となります。つまり、部下は上司の「命令」を期待しているので、「相談」は期待していないということです。上司は「判断」の権限があると同時に「責任」も負うので、その「責任」を部下に押しつけないでくれというわけです。シリコンバレーで上司として振舞うときには、「俺はボスだ」と心の中でそっとつぶやいておいたほうがいいでしょう。

レビュー、ソースコード管理、デイリービルドを毎日行なう早い開発サイクル

エンジニアはひたすら開発を行ないます。そして、開発したコードはエンジニア相互のレビューに廻されます。相互チェックシステムというわけです。ソースコード管理は今ならフリーソフトのCVSを使うか、お金に余裕がある場合は商用のソースコード管理ソフトであるクリアケースを使うのが一般的でしょう。

毎日タグと呼ばれる印をつけて(これはいつでも過去の状態に戻せるようにするため)、デイリービルドを作成し、テストに廻します。このサイクルはほぼ毎日行なわれます。

ソフトウェア開発に詳しい方の中には、設計はどうした?という疑問を持つ方もいらっしゃるでしょう。このへんはかなり適当です。シリコンバレーのスタートアップの製品に問題があって、設計書を出せと言っても出てこないことがあるかと思いますが、その場合には設計書自体が存在しない可能性が大です。このあたり、設計書がないことなどありえない、受注開発の大規模ソフトウェアプロジェクトとはまるで正反対と言っていい開発スタイルだと思います。

ダイナミックなリソース割り当て

テスト人員は開発の段階と共に、また製品の規模に応じて、様々に変遷します。ソフトウェア開発初期のテストエンジニアの配分は、開発エンジニア3に対し、テストエンジニアの1とされていいます。つまり開発をするエンジニアが30人いれば、テストエンジニアを10人割り当てなさいということです。

製品が100万行を越すような規模になってくると、開発エンジニア2に対し、テストエンジニアの1というようにテスト人員の割合が少し大きくなります。噂によると、シスコやマイクロソフトでの割合は、開発エンジニア1に対し、テストエンジニア1だそうです。製品の規模が大きくなるにしたがって、テストをするのも、テストケースを作るのも難しくなってきます。場合によっては、開発エンジニアと同等かそれ以上のスキルがテストエンジニアに要求されることも珍しくありません。

スピードとスケーラビリティ再び

こうしてみてくると、ソフトウェアの開発スタイルと、シリコンバレーのスタートアップ自体のあり方が重なっているように思えます。それぞれのスタートアップ企業は、リスクの大きい実験体という側面を持っています。実験に長い年月をかけてはいられないので、早いスピードで製品を作り市場にその成否を仰ぐのです。失敗と結果がでれば、早急に解散し、成功であれば、即時に人的リソースを集中させ、スケーラビリティをもとに、ゴールへともっていくのです。

市場に受け入れられなかった実験の人的リソースは、即座に別の実験プロジェクトへ編入されます。こうした人的可塑性は、限られた時間に数多くの実験を可能にし、他のどの場所よりも成功への確率を高めているのです。

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー