SEチャンネル

ITについてできる限り書くメモ

「人月の神話」について思うこと

f:id:tkmtys:20200512142250j:plain

ITエンジニアにとって超有名本「人月の神話」。単一テーマの本じゃない(=雑多でまとまりもない)し、内容ももう古臭いところが多くてそれほどいい本じゃない。それでもタイトルにもなっている人月についてのパートは、今見ても本質を書いていると思う。

人月の神話について

そもそも人月とは

本のタイトルにもなっている「人月」はIT業界特有の用語で、「1人のエンジニア」が「1ヶ月」働いたときの生産量(工数という)を表す語だ。例えば

  • 1人が10ヶ月働いた場合は10人月
  • 2人が5ヶ月働いた場合も10人月
  • 10人が1ヶ月働いた場合も10人月

という風に計算する。なぜこれが便利なのかというと、システムエンジニアの生産性が同一だと仮定すると、1人が10ヶ月働いてできる成果物と、10人が1ヶ月働いてできる成果物は同じになるからだ。100人月の量の仕事があって、納期が10ヶ月なら、少なくとも10人のSEが必要だと計算できる。

人月にはもう一つ利点があって、コスト(金額)を表す単位としても使える。システムエンジニアの1ヶ月の支払い額(コスト)は均一化されていて、だいたい100万円/月だ。1人月=100万円の換算によって一つの単位で仕事量とコストを両方表す事ができる。

予算金額も表すことができ、かつ成果物の進捗も計算できる。この2面性でIT業界では「人月」の単位が広く使われている。

ちなみに人月は日本の古いIT業界だけで使われていて、世界標準では使われていない、という誤解が広まっているがそんなことはない。そもそも人月の英語訳はman-monthで英語圏から来たものを日本語訳したのだし、コストの単位としては正確だ。有期プロジェクトであればどこでも使っている。

「人月の神話」で言っていること

著者のBrooksが言っているのは

  • 人月はコストの計算にはしやすいが、仕事の量としては使えない。仕事量で見たときは「人月 ≠ 人×月」。
  • 炎上プロジェクトに人を追加してもプロジェクトはより炎上する

ということだ。Brooksがあまり厳密に定式化せず、文学的(定性的)な表現になっているので納得しづらいけど、結局言っているのはITの仕事は農耕作業と違って、個人作業に分割するのにコミュニケーションコストがかかるということだけだ。より厳密に言うとすれば、プロジェクトの仕事量全体W _ {tot}は、純粋にコーディング・設計に係る仕事量 W _ {devel} と(チーム内の)コミュニケーションに必要な仕事 W _ {comm} の和となっている。


 W_{tot} = W_{devel} + W_{comm}


プロジェクトチームの人数をN人とすると、よく知られているようにN人内でのコミュニケーション量はN2に比例する*1から、結局プロジェクトの全体の仕事量は


 W_{tot} = Const. + O(N^ 2)


となる(Oはラージオーダ:対象変数の最大べき数を表す)。チーム全体の単位時間あたりの処理量Pは、個人個人の処理能力が均一だとすると、結局は人数に比例するから*2


 P = O(N)


プロジェクト全体の仕事量 W _ {tot}をチーム全体の単位時間あたりの処理量Pで割ると、全体を処理するのに必要な時間Tは以下のようになる。


 T = W_{tot}/P = O(1/N) + O(N)


プロジェクト完了までに必要な時間TはNに反比例する部分とNに比例する部分の和だ。グラフにすると次のようなイメージになる。

sponsor

f:id:tkmtys:20200512151114p:plain:w400
y軸=T, x軸=N, 係数を調整していないためスケールは参考程度

この式からわかることはいろいろあるけれど、一番わかり易いのは


 (c1) Nが大きくなると、TはNに比例して増加する


これがBrooksが本で言っていることの本質だと思う。本では「炎上プロジェクト」と言って対象を限定しているけれど、実際はどんなプロジェクトであれ同じだ。チームサイズが小さいときはメンバを追加すればプロジェクト完了までに必要な時間(T)は減っていくけれど、プロジェクト人数が多くなりすぎると逆にTは増えていく。大規模プロジェクトになればなるほど、チームサイズが大きくなってこの罠にハマりやすい。


より重要なこと

一方、本で明示的に述べていない(定式化しなかったので気づかなかったのだと思う)けれど、もっとより重要なことは


 (c2) Tは極小点をもつ


ということだ。普通のプロジェクトは(予算を別にすれば)、 W _ {devel}とT(プロジェクト納期)を所与として、プロジェクトサイズ(=人数N)を決める(Wを一人あたりの生産性と時間Tで割るわけだ)。しかし今の考え方をもとにすると、実際はプロジェクトで創るもの W _ {devel}が決まれば、プロジェクトの最短納期Tと、それを実現するチーム人数Nが自動で決まる。W、T、Nは独立変数で、1つの関係式で結ばれている(=TとNの選択に自由性がある)と思い込んでいるけれど、本当のところ望ましいTとNはWから完全に決まる従属変数だ。


チームの生産性を上げるためには

 W _ {devel}から最適なTとNが自動で決まってしまうならば、もはやプロジェクトにおいて調整可能なところは残ってないように見える。しかし実際はコミュニケーションコスト W _ {comm}はチームのサイズNとチーム内でのコミュニケーション濃度で決まる量なのだから、チームビルディングで大きくしたり小さくしたりすることが可能だ。このコミュニケーション量を可能な限り小さくすればするほど、本来の開発作業 W _ {comm}に集中できプロジェクトの成功確率が上がる。これはtypoではなくて、チーム内コミュニケーションは重要ではない、極力なくすべき対象*3

例えば高難度プロジェクトや大規模開発プロジェクトだと、PMは次のようなことをよく言う

  • チームの人数は多くしたほうが良い
  • チーム内のコミュニケーションは重要
  • チームメンバの多様性が成功には重要だ

だが実際はこの逆が正しい

  • チームのサイズNを小さくする
  • チーム内のコミュニケーションを可能な限り少なくする
  • チームはできる限り均一化した、同じバックグラウンドを持つメンバで構成する

ダイバーシティの重要性が言われている今の社会で、均一性(同じ文化・宗教・性別・年齢等多くの共通バックグラウンドを持つこと)を主張すると殺されてしまいそうだけれど、実際には均一的なチームのほうが生産性が高い。同じコミュニケーションを達成するためのコミュニケーション量が圧倒的に少なくなる(ときにはゼロになる)から。

みんな気づいているけれどはっきりと言わないだけなのか、共通知の前の状態なのかはわからないけれど、補足的な情報はいくつか見つけられる。Jeff Bezosがピザ2枚ルールを持ち出したり、Peter Thielが密で結束したチームの関係性を重視したりするのもそうだし、直接的に、チームの生産性は実際に成されたコミュニケーション量には関係なく、チームが暗黙の協調状態にあるかどうかに依存しているという論文もある。

これがプロジェクトに関する真実だ。議論を再度追いかければわかるけれど、問題の本質は人間の生産性はN1にしか比例しないのに、コミュニケーション量がN2に比例することだから、IT業界だけではなくコミュニケーションが必要な大多数の仕事について成り立つ。

sponsor

*1:N個の中から2つ選ぶ組み合わせはN2に比例する

*2:この仮定も間違っていると思うのだが...

*3:もちろんコミュニケーション不足による、認識齟齬などの問題を起こさないようにしないといけない