人月の神話
ＳＩ業界で働いているプロジェクトマネジメントを志す方なら、おそらく一度は読んだことがあるでしょう。
「ソフトウェア工学のバイブル」と呼ばれるほど、とても著名な本です。
ＳＩとはSystem Integrationの略で、簡単に言えば
「システムを導入しようとしている顧客の面倒を
最初から最後までの全部または一部を請け負う」
というビジネスになります。
もちろんその中にはソフトウェアの開発も含まれていますが、ただ開発するだけでなく、開発までの調査や提案から開発後の導入、利用者教育、リリースのごサポートや保守・運用まで含めて、実際にシステムを生み出して、利用してもらい、お客さまのビジネスに根付くところまでを一括して引き受ける仕事のことを言います。
学生のうちはわかりづらいかもしれませんが、ＩＴ業界と一口に言ってもこのＳＩは単純に技術さえあれば成立するというものではありません。単純技術だけではＳＩは成立しないのです。
そんな中、お客さまの権限がやたら強くて「期限厳守」を私たちＩＴ企業側に押し付けてきた場合、ＩＴ企業はついつい投入する人員の数を増やして対応しようとします。
しかし、それは間違いです。
すぐさま「人を増やせばいい」という対応を決断してしまうプロジェクトマネージャーは多いと思いますが、そういった人海戦術は時間もコストも無駄に消費するだけの駄作と言わざるを得ません。
前職のころもそうした対応しか取れない課長や部長がいましたが、結局ものすごいコストを浪費していたはずです。
そうした過ちをより論理的に指摘したのが、この『人月の神話』になります。
この書籍で語られている概念はＩＴ企業で働いている人やＩＴ投資を考えている人はもちろん、複数人で仕事をしている「プロジェクト」に携わっている人なら誰でも知っておいて損はありません。
システム開発の現場でプロジェクトマネージャーを務めている人がこの書籍を読んでいなかったら一時期は「もぐり」だと言われていました。それ程、とても有名な書籍だったのです。
私も、複数のプロジェクトを管理していた関係上、15年以上前にこの書籍は熟読しました。しかし…さすがにソフトウェア工学の古典と言われるだけあって、
非常に読みにくい
です。
しかし、そういう読みにくさを吹き飛ばす衝撃があります。
それはこの書籍の古さにあります。
よく昨今ではパワーワードかのように「〇〇はもう古い！」みたいなキャッチフレーズを使う人がいますが、いやそもそもそのフレーズも相当古いんですけどね。さらにいうと、古くても長く続いているものには、どこかしら真理が含まれていることが多いものです。ただ惰性で残っているというものはほとんどありません。
時代や市場の変化にあわせて使いづらくなれば、どんなものでも廃れるものです。廃れずに古くから残っているものには、何かしら再現性や継続性が強い真理がどこかに含まれていると思って真摯に受け入れて吟味したほうがいいでしょう。
さて、少し脱線してしまいましたが、この『人月の神話』が最初に出版されたのはなんと今から45年以上前の1975年。私が生まれたのが1974年なので、ほぼ同時に育ってきたかと思うと少し感慨深いものがあります。
著者のブルックスの考察は、自身がIBMで「OS/360」というオペレーティングシステムの開発に携わったときの失敗に基づいています。ブルックスが経験した45年以上前の失敗事例が、現在でもさまざまなプロジェクトにおいてほぼそのままの形で再現されてしまっているのです。
つまり、PMBOKがどうとか言われていても、結局のところＩＴ企業の多くはプロジェクトマネジメントをきちんとできているわけではなく、45年以上前に起きていた失敗を未だに続けているほど、進化に疎いエンジニアや管理職、経営者が大多数を占めているということを指しています。
そのため、プロジェクトマネージャー、システムエンジニア、プログラマーの人が『人月の神話』を読み切ると、思わず唸ってしまうことでしょう。
事実、ＩＴあるあるの宝庫です。
この45年以上もの間にシステムを構築するための開発ツール、プログラミング言語、開発手法は劇的に変化してきました。しかし、システム開発におけるプロジェクトの失敗の本質は今も昔もまったく同じです。
この書籍の主張は至って単純明快です。タイトルの通り、
プロジェクトマネジメントの失敗の原因は
「人月」という考え方を使って見積りをしているから
であるとします。
「人月（にんげつ）」とは、１人が１ケ月で行うことのできる作業量（工数）を表す単位です。システム開発だけではなく、土木・建築の現場などの事業の作業工数見積もりにも使われている単位です。
たとえば、
「Aというシステムを作るのに、
１人のエンジニアが２ヵ月の作業を必要とするので、
２人月の工数をお客さまに請求する」
というような使われ方をします。
ただ、ブルックスは、この人月という概念には大きな問題点が潜んでいると考えています。
私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら人月は、人と月が置き換え可能であることを暗示しているからである。
どういうことかと言うと、
「人月」と言う言葉は、月と人とを変更可能だと思いがちだが、
実際にはそうはならない
と言うことです。たとえば３人で５ヶ月かかる仕事（15人月）を、目の前に５人いるからと言って単純に３ヶ月で終わることは絶対にないといっているんですね。
人数が増えればその分コミュニケーションコストがかかってしまいます。
また工場の流れ作業のようなものであれば、一律同じ作業を行うでしょうからそういった計算も成り立つかもしれません。しかし、実際には一人ひとりが異なる作業をするとなれば、５人ともその力量が備わっていなければ想定したパフォーマンスは出せません。
しかも、各業務のクリティカルパスをしっかりと把握してみると３人が分割できる上限ギリギリで５人いたとしても２人は何もすることがない…ということにもなりかねません。
要するに、単純に人月の算数でしか考えられないプロジェクトマネジメントというのは、人を増やせば増やした分だけ期間が短くできると勘違いしているわけです。３人で実施するのと同じようにはいかなくなってしまうことが全く考えられていないのです。
世の中には、なにかあるとすぐに会議を開きたがる人がいますが、そうやって高単価の人間をすぐに集めて生産性のない打合せに興じるだけで、恐ろしくコストを消耗することなんかを見れば言っていることがよくわかるかと思います。とにかく「人」を増やせば増やすほど効率は低下し、無駄なコストが跳ね上がっていくのです。
『人月の神話』で最も有名な主張は「ブルックスの法則」と呼ばれています。
上記のようなことがあるからこそ、
ブルックスの法則：
遅れているソフトウェア・プロジェクトに人員を投入しても、
そのプロジェクトをさらに遅らせるだけである。
という結論に結び付くことになるわけです。
おそらく、この現象はシステム開発に携わる人であれば、誰でも一度は経験しているはずです。さらに言えばシステム開発だけではなく、一般的なプロジェクトでも同じはずです。
ブルックスはこの法則が成り立つ理由を次のように分析しています。
ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。
この部分が、ブルックスが最も主張したかった点です。
少しイメージがわかないかもしれませんので、図解してみましょう。
たとえば、あるプロジェクトをAさん、Bさん、Cさんが3人で共同作業していたとします。
3人でコミュニケーション（情報の共有）を取り合うのに、必要なコミュニケーションにかかるコストは「3」です。
・Aさん ⇔ Bさん
・Aさん ⇔ Cさん
・Bさん ⇔ Cさん
このプロジェクトは予定よりも遅れていたため、ここにプロジェクトマネージャーが新しい人員Dさんを投入して遅れているスケジュールを回復させようとしたとします。
ここまではシステム開発にかかわらず、あらゆるプロジェクトで本当によくある話だと思います。
新しいDさんが加わったことによって、プロジェクト内のコミュニケーションコストは次のように変化します。
・Aさん ⇔ Bさん
・Aさん ⇔ Cさん
・Bさん ⇔ Cさん
・Dさん ⇔ Aさん
・Dさん ⇔ Bさん
・Dさん ⇔ Cさん
なんと、プロジェクト内のコミュニケーションコストは２倍の「6」に増えるのです。
さらにプロジェクトが遅れていた場合、また新たな人員Eさんを投入すると次のようになります。
・Aさん ⇔ Bさん
・Aさん ⇔ Cさん
・Bさん ⇔ Cさん
・Dさん ⇔ Aさん
・Dさん ⇔ Bさん
・Dさん ⇔ Cさん
・Eさん ⇔ Aさん
・Eさん ⇔ Bさん
・Eさん ⇔ Cさん
・Eさん ⇔ Dさん
コミュニケーションコストは「10」に増えます。今まで行っていたコミュニケーションコストが一気に３倍に膨れ上がるわけです。
そして、ブルックスが指摘している通り、新しい人員が増えるためにプロジェクトには次の3つのコストが増えていきます。
（新規コスト1）
再配置そのものに費やされる労力とそれによる作業の中断
（新規コスト2）
新しい人員の教育
（新規コスト3）
追加の相互連絡
上記のコミュニケーションコストは、主に新規コスト3の「追加の相互連絡」に焦点を当てて説明していますが、現実的には新規コスト1と2の影響も大きくなるはずです。
私は入社２年目の時から遅れている…と言うより超トラブルプロジェクトに投入された経験がありますが、当然ながら教育もロクにされずに放置され、パフォーマンスも出ず見よう見まねでテスト支援を実施してた経験があります。
当時のプロジェクトのメンバーやリーダーが忙しすぎて「周りの人間のことなんて、構ってられるか」といった空気が漂っていました。
しかしこちらも新人に毛の生えた程度の実力しかないとはいえ、給料が出ているのに一日中ボケっとしているわけにはいきません。周りの先輩たちに質問をしまくって、なんとか自分にもできる仕事を見つけようとします。
結果的に周りの人たちに作業を中断させて、新しい教育コストを発生させるという流れになっていたと思います。本来はプロジェクトマネージャーなり、リーダーなりがちゃんと音頭を取るべきなのにそれすらもできていませんでした。
ただ無策のままとにかく空いてる人員を追加することで、遅れているプロジェクトに対処することでまともに成功することは原則としてありません。よほど優秀な人材ばかりを集めない限りは確実にコストやスケジュールに悪影響が出ます。
たとえば私は過去、様々なトラブルプロジェクトに参画し、多くを解決してきましたが、それですらもコストやスケジュールに全く影響がなかったわけではありません。
ただ、私は他の人よりも少しだけトラブル解決経験が長く、少しだけソフトウェア工学に知見があったために、
「（顧客交渉を含む）冗長作業およびコストの削除」
「既存メンバーではパフォーマンスの低い作業の引継ぎ」
を行って稼いだ余剰分を、自分が加わることで増えてしまうコストに充て、悪影響が出ないように調整していただけの話です。
では一体、どうすればいいのでしょうか？
ブルックスは、スケジュールが遅れている時は次の２つのことを提案しています。
スケジュールを立て直す
仕事の規模を縮小する
この２つの対応策で鍵を握っているのは"顧客との関係性"です。
ただモノづくりをすればいいのではなく、普段からお客さまを中心に活動し、お客さまと密に連携が取れている場合は比較的調整がききやすく、そのプロジェクトは成功する確率が高くなります。
しかし、ＳＩ事業という本質を忘れ、ただの下請け的な姿勢で請け負って、ただお客さまの言ったとおりにしていればいいと思っていたり、そもそもお客さまとの関係性を培う努力をしてこなかったり、関係性が悪かったりする場合は、当初の計画を遂行するために「新しい人員を投入しまくる」という選択を取らざるを得ません。
それ以外に選択肢が無いわけです。
そもそも、取り組み姿勢そのものが「下請け」根性で振舞っていれば、ＩＴ企業は当然のようにお客さまから「下請け」だと見られることが多く、なかなかお客さまと良い関係を築けないのは当たり前のことなのです。
たとえばIBM社などのように長年にわたって強固な顧客基盤を築いている企業はかなりレアな存在で、大半のシステム開発会社はそうではありません。そして、そのIBM社ですら、たまに発注者であるお客さまから裁判で訴えられたりしています。
一般的にはシステム開発会社が『人月の神話』で語られている２つの対策を取ろうとすると、顧客はとても嫌がります。
そして、仕方がないからと遅れているプロジェクトに新しい人員を投入していき、さらにプロジェクトが遅れるという流れになります。
最終的にはプロジェクト自体が空中分解して、システム開発会社もお客さまも悲惨な目に遭います。挙句の果てには従業員も協力会社メンバーも疲弊して、会社を去っていきます。
結局、どんなに開発ツールが新しくなっても、開発手法や開発環境が変わっても、最後に鍵を握るのは「顧客との関係がどのぐらい深いのか？」という部分になります。
つまり、
システム開発はどこまで行っても「人対人」
なのです。何度も言ってきたように、ソフトウェア開発における基本的な業種は"サービス業"です。製造業ではありません。技術はしょせん手段であり道具です。
相手を見てナンボ
相手に信頼されてナンボ
相手が満足してナンボ
であり、少なくともフロー型ビジネスである限りはサービス業以外のなにものにもなりません。製造業寄りの立場でありたいのならば、ストック型ビジネスにシフトする必要があります。ＳＩ事業を担っている企業ですることではありません。
その大前提を無視して『モノを作ってナンボ』『モノづくりだけしていればいい』と考えている間は、４５年来の問題はいつまで経っても解消されることはないでしょう。
しかし、現在は働き方改革法案も公布され、既に「残業させればいい」「スケジュールを安易に遅らせればいい」という選択肢は潰れました。今までのような雑多なプロジェクトマネジメントではなく、計画的かつスマートに遂行することによって統制できなければ、今後確実に法令順守義務違反を犯す人が出てくることになるでしょう。
企業はそれでもプロジェクトマネジメントに注力しないままでよいのでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。