シリコンの谷は、いま。 雑誌の記事とはずいぶんちがうみたいです。

第29回 なぜ、少人数の方がいいのか？ 僕のいるチームのリーダーは、度々、 「うちのチームはできるだけ小さいままに 　しておきたいんだよね」 と口にします。 僕のいる開発チームはリーダーを含めて4人しかおらず、 やらなければいけない仕事は山積みです。 しかし、僕もリーダーの意見にまったく賛成で、 人はなるべく増やしてほしくありません。 とにかく、システム開発は 人数が少なければ少ないほどいいのです。 今回は、なぜ、少人数の方がいいのかという話です。 インターネットの普及も進み、 その上で提供されているサービスも進化をし続け、 どんどん便利なサービスが開発されてきています。 Webが世の中に登場した頃は、 そこで提供されるサービスも 1人で作れるぐらい簡単なものから始まりましたが、 それも、年々規模が大きくなり、複雑化してきたので、 今、インターネットで有名になっているサービスと 同じものを一人で作ろうと思っても なかなか難しくなってしまいました。 インターネットを使ったサービスは、 通常、複数のコンピューターを 使って実現されています。 それぞれのコンピューターは、 そのコンピューターに与えられた仕事を こなしていきますが、 全体としてみれば、コンピューターが協力し合いながら、 1つの大きな仕事を実現しているような形になります。 そこで、これをひとまとまりにして、 「コンピューター・システム」とか 「システム」と呼んでいます。 コンピューターのシステム開発は、すなわち、 それを構成する様々な役割を果たす ソフトウェアを作ることです。役割が色々ありますから、 ソフトウェアもそれだけの種類作らなければなりません。 システムが行う仕事が複雑になってくると、 それを実現するためのソフトウェアの数が多くなったり、 それぞれのソフトウェアが複雑になったりします。 ソフトウェアの数が多くなったのなら、 大人数で同時に作ればいいじゃないかと 思うところなのですが、 ここに1つ大きな問題があります。 それは、それらのソフトウェアが 「協力し合いながら」動かなければならないからです。 1つのシステムの中にあるソフトウェアは、 お互いに密接に連絡を取り合いながら、 それぞれの作業を進めていきます。 そのため、すべてのソフトウェアの間で、 常に整合性が取れている必要があるのです。 1箇所直したら、その変更が影響する部分を 他のソフトウェアでも直さなければいけません。 もしその整合性が崩れ、 食い違いが起こると誤動作につながります。 1人で全部作ればこういった食い違いは ほとんど防ぐことができますよね。 2人で作るとしても、 相手に影響が出そうな時は必ず話し合うことで、 食い違いは防げそうです。 3人でも同じくなんとかなりそうです。 しかし、もし開発者が、10人になったらどうか と考えてみると、ちょっとうまくはいかなそうです。 1人が加えた変更が大勢の人に影響しますから、 多くの人と話し合いをしなければなりませんし、 その人たちとの意思疎通が全員うまくいくとも限りません。 10人で作るから1人で作る10倍早く作れるかというと そうもうまくはいきません。 もし、20人になったらと考えてみると、 食い違いを防ぐことは絶望的です。 つまり、ソフトウェア開発の場合、 人数を増やせばそれだけ早く作れるというわけでは ないようです。 僕の経験では、シリコンバレーのネット企業の場合、 チームは1人から多くても6人ぐらいが多いように思います。 (1人でチームというのもヘンですが、実際結構あります) 重要なのは、開発チームのメンバーの間で 常に意思統一が出来ていることです。 そのためには、毎日話をしたり、 すぐに全員集まることができる程度の人数でないと いけません。 なるべく優秀なエンジニアを揃えて、 人数を徹底して抑えるというのがこちらのやり方です。 個々の生産性と、小さいチームの効率性を 組み合わせることで、少人数でも、 大所帯のチーム以上の生産性を実現するというわけです。 会社側にとっては、人数が少ない分、 少々高い給料を払っても、 人件費の合計は安く上がるというメリットもあります。 実際に、少ない人数の割に、結構な仕事をしてるよなと 常々思います。 確かに、実際の生産性は、今回挙げた理由だけで 実現されているとは言い切れません。 この他にも生産性を高めるための工夫が いくつか思い浮かびます。 次回はこれ以外に実践されている 生産性アップの方法について、書いてみたいと思います。 上田ガク

2004-01-20-TUE

戻る