LIMHAUS Inc.

プロジェクトに人員を追加しても開発期間は短くならない

This page is only available in Japanese.

プロジェクトに人員を追加しても開発期間は短くならない

Webサイト・Webサービスのリリースを早くしたいと思いませんか?
開発スケジュールが決まる要因のひとつに、開発に携わる人数があります。
しかし、人数を増やすことで開発期間が短くできるとは限りません。

その理由を解説します。

Webサイト・Webサービスの開発期間は人数に比例しない

Webサイト・Webサービスの開発には多くの人が関わります。
デザイナーやエンジニア、ディレクターなどがそれぞれの役割を担い、協力してプロジェクトを進めます。
基本的には大規模なプロジェクトほど多くの人数が必要になります。

開発がスタートしてからローンチまでの期間、開発工数は「人数×稼働時間」で算出されます。

開発工数=人数×稼働時間

開発にかかる時間、工数は人数と稼働時間をかけたものです。
いわゆる「人月」と呼ばれるものです。

例えば、エンジニアが1日8時間、週5日稼働し、2ヶ月(8週)で完成させるプロジェクトと想像してみてください。
この場合の開発工数は、エンジニア1人×(1日8時間×週5日×8週)=320時間です。
320時間の工数をかけるとプロジェクトが完成します。

先程の計算式を見ると「人数×稼働時間」で工数が算出されるため、人数を増やせば開発時間が短縮できると考えられます。
エンジニア1人では2ヶ月かかるプロジェクトなので、エンジニアを1人増員して2人にすれば1ヶ月で完成するというわけです。
エンジニア2人×(1日8時間×週5日×4週)=320時間となり、開発工数は同じですが1ヶ月で完成しそうですね。

では320時間かかるのであれば、エンジニアを320人にすれば1時間で完成しますね。
しかし常識的に考えて、それは不可能だとわかります。

『人月の神話』

アメリカの著名なソフトウェアの研究者、フレデリック・ブルックス氏は『人月の神話』という著書でこのように述べています。

Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.
私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。

数学では「2×3」と「3×2」は同じ値になりますが、開発においては「2人×3ヶ月」と「3人×2ヶ月」は異なる結果になります。
先程の「1人×320時間」と「320人×1時間」がその例です。

さすがに320人ものエンジニアが同時に作業することは不可能ということは直感的にわかると思います。
しかし、2人のエンジニアなら1人のエンジニアよりも2倍の速さでプロジェクトを完成させられると考えるかもしれません。

残念ながら実際には1ヶ月以上かかってしまいます。
その最大の理由は、コミュニケーションコストが増えるからです。

人数が増えるとコミュニケーションコストが増える

プロジェクトを進めていくにはコミュニケーションは欠かせません。
コミュニケーションによって、より良い成果物を作ることができますが、ここでは開発工数に絞って考えます。

プログラミングの作業において、それぞれのエンジニア同士のコミュニケーションが1時間必要としましょう。

先程のプロジェクトをエンジニア1人がが作るのであれば、エンジニア間のコミュニケーションはゼロです。(エンジニアは1人なので)
エンジニアが2人に増えた場合、コミュニケーションが1時間必要ですね。
エンジニアが3人に増えた場合、コミュニケーションは2時間ではなく3時間必要。
エンジニアが4人に増えた場合、コミュニケーションは3時間ではなく6時間必要。

エンジニアが320人に増えた場合、コミュニケーションは51,040時間必要。

このように関わる人数が増えるとコミュニケーションに必要な時間が爆発的に増えていきます。(nC2の組み合わせの数)
もちろんこれは極端な例で、すべてのエンジニアのペアで同じ時間のコミュニケーションを取るという仮定での計算です。

しかし、プロジェクトに関わる人数が増えるとコミュニケーションコストが増えるということはおわかりいただけたのではないでしょうか。

では最少人数で開発を進め、進捗が遅れたときに人員を追加しようと考えるかもしれません。
実は先程の『人月の神話』において「ブルックスの法則」として示され、人員追加は良くないとされています。

遅れているプロジェクトは人数を増やすとさらに遅くなる

プロジェクトに関わる人数が増えるとコミュニケーションコストが増え、工数が増えてしまうことはわかっていただけたのではないでしょうか。
そのため少数のメンバーでプロジェクトを進め、進捗が遅れたときに人員を追加する方法はどうだろうと思いますよね。

ブルックスは『人月の神話』において、それを否定しています。
自分の名前を冠した「ブルックスの法則」として次のように述べています。

ブルックスの法則

『人月の神話』ではこのように書かれています。

Brooks’s Law: Adding manpower to a late software project makes it later.
ブルックスの法則:遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。

ブルックスはこのような理由で進捗をより送らせてしまうと述べています。

  1. 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる
  2. 人員の投下は、チーム内のコミュニケーションコストを増大させる
  3. タスクの分解可能性には限界がある

それぞれの理由についてご説明します。

新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる

エンジニアはプログラミングをするのが仕事ですが、プログラミング言語の知識だけではなく、開発しているWebサービスの業務知識が必要です。

例えば旅行代理店の予約サービスを開発しているとしたら、旅行の予約の仕組みや法律、クライアント企業の業務フローなどを頭に入れなければ良いものは作れません。
進捗が遅れている状況で新たなエンジニアを投入すると、その業務知識を身につけるまでに時間がかかってしまいます。

人員の投下は、チーム内のコミュニケーションコストを増大させる

先程ご説明したように、人数が増えるとコミュニケーションコストが増大します。
進捗が遅れている状況で、エンジニア間のコミュニケーション時間が増えてしまいます。

タスクの分解可能性には限界がある

新しく入ったエンジニアにタスクを割り振れれば、確かに作業が進みます。
しかし残念ながら、そう簡単にはいきません。

タスクを綺麗に分けられれば良いのですが、実際には分け方には限界があります。
極端な例ですが、100行ほどのプログラムを書かなければいけないときに、1行ずつ分けて割り振ることは非効率ですよね?

ある程度の単位でタスクを割り振ったほうが効率的に進められます。

ここまでで人員を増やしてもプロジェクトの開発時間が短くなるわけではないことをご理解いただけたのではないでしょうか。
続いては、開発期間を短縮するための方法をご紹介します。

最速でのリリースを目指すなら少数精鋭が効果的

プロジェクトの最大の敵はコミュニケーションコストです。
正確に言うと”不必要な”コミュニケーションが必要ありません。

プロジェクトの成果物のクオリティを上げるためにはコミュニケーションは絶対欠かせず、それは”必要な”コミュニケーションです。

一方で人数が増えることで発生する無駄な確認作業や調整作業は、プロジェクトの進捗を遅らせる原因になります。

つまり、最速でリリースを目指すのであれば少数精鋭のチームでの開発が効果的です。
特にデモやプロトタイプ、MVP(Minimum Viable Product)を作る際には、少数のメンバーで効率的に進めていくのがおすすめです。

むしろそういったプロジェクトでは、最少人数で最短期間でリリースするためにはどうすればいいかを考えることが大切になってきます。
そうすると自ずとサービスのコアになる機能やデザインに絞ることになり、ユーザーにサービスの本質を伝えることができるようになります。

まとめ

プロジェクトの開発期間を短縮するためには、人数を増やすことが最善とは限りません。
人数が増えることでコミュニケーションコストが増大し、進捗が遅れる原因になることがあるからです。
これは『人月の神話』という著書で有名なフレデリック・ブルックス氏が指摘しています。

特に進捗が遅れている状況での人員追加は「ブルックスの法則」として知られ、プロジェクトをさらに遅らせる原因になります。
予算やスケジュールが超過してしまっていることにお困りであれば、予定通りに進まない理由と解決策の解説記事をご覧ください。

Web制作で予算とスケジュールがオーバーしてしまう理由とその解決策

Web制作で予算とスケジュールがオーバーしてしまう理由とその解決策

そうならないようプロジェクトを最短期間でリリースするためには、少数精鋭のチームで効率的に進めることが重要です。
デモやプロトタイプ、MVPを作る際には、最少人数で最短期間でリリースするためには何をすべきかを考えることが大切です。

まずは2週間でWebサービスのプロトタイプを作ってみませんか?
弊社ではたった2週間でWebサービスを開発・提供しています。

ソクデモ

Webや事業の課題はございませんか?
お気軽にご相談ください。