本記事はLITALICOのアドベントカレンダー３の16日目の記事です。昨日も記事を書かせていただいたので、こちら『わからないことが分からない話（ChatGPTの使い方：プロンプトエンジニアリング）』もぜひご覧ください。
昨日に引き続き本日も8月から内定者インターンとして働いている@zacky_50がお届けいたします！
本記事は以下の記事を元に作成をしています。
はじめに
私は数理モデル好きで、大学では動作制御に関して数理モデルで考えていたりします。（医学系ではなかなか数理に興味を持つ人が少ないのか、同じ研究科でもかなり珍しい人種のようですが。）
そんな私が工期はなぜ遅れるのか、人員を投入しても工期が短縮できないブルックスの法則についてとどんなプロジェクトがこの法則からはずれ、開発がうまくいくのか（簡単な数理モデルで）考察してみようと思います。
ブルックスの法則
フレデリック・ブルックスによって提唱された、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則[Wikipediaより]
プロジェクトを簡単な数理モデルで理解する
プロジェクトには要件定義、実装、テストという各フェーズごとに参画するメンバーが変化していきます。ここで、メンバーが上記のように変化していくプロジェクトだと仮定します。要件定義・設計では参画するメンバーが少ないですが、実装やテストになってくると次第にメンバーが増え、テスト終盤になってくるとある程度参画するメンバーが減るという一般的に理解しやすいメンバーの投入フローなのではないでしょうか。このように開始時期と終了時期は動員数が0として時間($t$)軸方向に上に凸な人員投下モデルを仮に二次関数で近似します。
R(t)=a(Lt-t^2)
ここで$R(t)$を時刻$t$における人員数つまり工数、$a$をプロジェクトの動員に関する係数（大きくなればなるほど急に人員を導入する）、$L$をプロジェクトの終了時刻とします。
このように考えた時に、プロジェクト全体での工数$E$は時刻$t$を区間$[0,L]$で積分したものになり、
E=\int_0^LR(t)dt=\frac{L^3a}6
となります。（1/6公式を使うと簡単に計算できます。）
これを$L$について解くと
L=\sqrt[3]{\frac{6E}a}
となります。
JUASで報告されているプロジェクトにこのモデルを当てはめると$a=0.3$になり、
L=2.7 \sqrt[3]E
が標準的な工期と工数の関係式と言えそうです。
たしかにこの式は、当てはまりの良さを示す決定係数$R^2$は$R^2=0.89$と非常に高くなっており、かなり良いモデルであることがわかります。
しかし、全てのプロジェクトでこのモデルで説明できるわけではなく、何らかの他のパラメータも全体工期と関連していると考えられます。
原点を中心として分布している領域が限られているため、確率分布などを想定した方がいいのかもしれないませんが、今回はそこまでは踏み込まずに考えます。
ここまでで、工数が多いプロジェクトの方が工期が長くなることがわかりました。
しかし、一気にに人員を導入する場合（つまり$a$が0.3より大きい）では、工期・工数間の係数$\sqrt[3]\frac6a$が小さくなり、プロジェクト完了までの期間は短縮できないもののそれほど影響はなくなるのかもしれません。また、二次関数よりも急に導入するモデルを4次関数や6次関数のような偶数次数の多項式と見なすこともでき、この場合だと$L$について解いた時に5乗根、7乗根と変化していき、これは$E$が増加するにつれ$L$も増加する単調増加関数にはなりますが、その増加率はあまり増えていかないという特徴があります。
つまり他にも工期を短縮できない原因があるのです。
プロジェクトの短縮を妨げるコミュニケーションコスト
プロジェクトの遂行のためには綿密なコミュニケーションが必要になります。プロジェクトの工期を短縮するために人員を追加で投入した時に、このコミュニケーションはどのように変化していくのでしょうか。人と人との繋がりをグラフ理論（ネットワーク）の枠組みで考えてみます。綿密なコミュニケーションのために全ての人に会話をすることを想定すると、これは完全グラフ（下記図）と考えられます。グラフ理論ではノードとエッジで世界をモデル化するもので、人との繋がりでは、人がノード（頂点）、繋がりがエッジ（辺）となります。
ここで全ての人との繋がりを数えてみます。図では紫で表される点（ノード）のが人、緑で示される線（エッジ）が
$n$人でできるコミュニティ内ののつながりは$_nC_2=\frac{n(n-1)}2$となります。つまり、$O(n^2)$で増大し、コミュニケーションコストも同様になります。コミュニケーションにかかるコストによって一人当たりの開発には制限が生じます。これを表現してみると、
S(t)=R(t)-cR^2(t)
となります。ここで$S(t)$は時刻$t$の有効工数（純粋にプロジェクトを進めることができる工数）、$c$はコミュニケーションコストとします。
これを先と同様に積分することで実際にかけることのできる有効工数$S$を計算してみると、
S=\int_0^LS(t)dt=-\frac{L^3a(L^2ac-5)}{30}
となります。メンバー間のコミュニケーションコストがどの程度かは考慮する必要がありますが、この式は$L$について5次関数であることから、プロジェクトが長くなるにつれ有効工数が増えますが、ある点を境にコミュニケーションコストが増大し始め、生産性が悪化することがわかります。
ある点は、$\frac{dS}{dL}=0$の点であり、これは$L=\sqrt\frac3{ac}$です。
つまり、人数規模の拡大によって得られる工数の増加という利点よりもコミュニケーションコストによる損失の方が大きくなってしまい、プロジェクトの拡大には上限があるのです。
実際の想定と工期短縮のための考察
ここまで、数理モデル的に人員投入とプロジェクトの期間の関係を考えてきましたが、実際のプロジェクトでどれくらいこれが当てはまっているのでしょうか。先に示した図の通り、今回のこの簡単なモデルはある程度の当てはまりはありますが、完全に一致しているわけではありません。ここにはいくつか要因が考えられると思います。
- 大数の法則の妥当性
大数の法則は大量のデータを見ることで個々の値に差があったとしてもある規則性が一定担保されるという統計的な法則です。つまり、個々のエンジニアの能力に違いがあったとしてもプロジェクトに参加する人が多ければ平均的な開発効率が得られるよねということ。 - エンジニア一人一人の能力値
これは一人の工数がどのくらいかということ。これが多ければ同規模のプロジェクトであれば早く遂行できるよねということ。 - プロジェクトへの動員が本当に二次関数的になっているのか
これは単純な話、二次関数的でないのであればそもそも$L=2.7 \sqrt[3]E$が成り立たないかもしれない。 - コミュニケーションは本当に全員と取る必要があるのか
コミュニケーションコストは会話する人が増えればその分増えていきますが、一人ハブのような役割の人（マネージャーのようなイメージ？）がいてこの人を軸にすることでメンバー内のコミュニケーションコストは接する人が単純に減るので下がっていく。
そして、工期短縮の鍵は、コミュニケーションコストをいかにして下げるかとネットワークのスケールフリー性・スモールワールド性だと思います。
コミュニケーションコストを下げることは当然ですが、有効工数を上げるために重要なためこれはプロジェクト内の雰囲気作りで頑張っていきたいですね。
もう一点はスケールフリー性とスモールワールド性だと思っています。
-
スケールフリー性：一部の頂点が他のたくさんの頂点と辺で繋がっており、大きな次数を持っている一方で、その他の大部分はわずかな頂点としか繋がっておらず、次数は小さいという性質。
-
スモールワールド性：任意の2つの頂点が、中間にわずかな数の頂点を介するだけで接続されるという性質。
プロジェクト内のコミュニケーションコストによる生産性の低下を予防するために、プロジェクト内をいくつかのグループに分けることが有効になることはここまでの説明していました。しかし、それだけではプロジェクトを完成させることができないので、一定横断的にグループに参加する人が必要になるでしょう。この時に、できるだけそれが同じ人であればスケールフリー性でいうところのハブの役割をします。また、コミュニケーションをとる際に他のグループで何をしているのかは全員がある程度知っていた方がいいので、できる限り少ないコミュニケーションコストでかつ誰に聞いても比較的同じような情報が得られるようにということを考えると、任意の2点を選択した時に、その間でコミュニケーションをとる回数が極力少ない方がいいわけでこれはスモールワールドであるといいということです。
このようにプロジェクト内のコミュニケーションだけにフォーカスしてもかなり考えないといけないことはあるのではないかなと思います。そしてうまく人員を配置しコミュニケーションコストの削減ができると開発のアッパーに影響されないのではないかと思います。
余談：ちなみにそもそも見積もりは難しい
話が大きく変わりますが、我々はいつまでに何をするのようなタスクとそれがどれくらいの時間がかかりそうかと言った見積もりを出すことがあります。しかし、この見積もりが大きく外れてしまうこともあるでしょう。なぜ我々は見積もりができないのか、結論としては見積もりがめちゃくちゃ難しいということ、を前提に置いていただけると、今後見積もりをする際にどのくらいで完成するのかなどの味方が変わるのではないでしょうか。
プロジェクトも期間を見積もって始まります。あらかじめ建てられた見積もりがある程度妥当な範囲に収まっているのはかなりすごいことであるということを覚えておきましょう。（そもそもこの場合、大きく見積もりを外すと即死が待ち受けていると考えた方がいいので見積もりが正確にできることは必須なのですが）
ちなみにですが、「『人々が9割がた間違いない』と思っていることは実は『3割がた間違いない』である（つまり人がおおかたあっていると思っていることは3割くらいしかあっていない）」なのだそうです。どういうことかというとそれぐらい人間は見積もりができないということです。なぜか気になった方はぜひこちらの動画もご覧ください。
おわりに
インターネットなどの通信に関するネットワークとグラフ理論でのネットワークがあり、今回の記事でのネットワークはすべて後者でしたが、初めにイメージしたものと違ったかもしれません。わかりづらい表現なっていたら申し訳ありません。
最後まで記事を読んでいただきありがとうございました。プロジェクトの最大効率化と開発期間の短縮はどんな状況でも求められると思いますが、そんな中でもとりあえず人員投入ではなく、他に作業を効率化できないかであったりいくつかの小グループで開発し後から結合すると言った分解的な思考でボトルネックを取り除くために必要なのかもしれませんね。