人月。それは、一人のITエンジニアが１カ月働いたときの労働量を「１」としたときの総量であり、ITビジネスにおいて、原価を推し測るために使われます。
■ 名著「人月の神話」とは
ソフトウェア開発の生産性をテーマにした著作で、ソフトウェア開発に関わる書籍では古典と言えるものです。
そこでは、「仕事の大きさを測る単位として、人月は疑うべき神話」と述べていて、それを「人月の神話」と呼んでいます。
人月は、一人が１カ月間で働く時間を表します。単位時間で達成できる作業量が人に依らず均一であれば、労働量としてみなすことができます。マニュアルで決まっているような作業、たとえば、工場のライン作業であったり、マクドナルドのハンバーガを作る作業など、いわゆる「マックジョブ」がそうです。
はたして、ソフトウェア開発はどうでしょうか。
プログラミングだけをとっても、すべての人が同じピッチでプログラムを書くことは不可能であり、ましてやつくるプログラムは多種多様です。さらに、仕様策定、設計、テストなど、プログラミング以外にも、次元の違う作業をこなさなければいけません。
そして、何といっても人の能力やスキルには、大きくばらつきがあり、それを定量的に評価することが不可能なことなど、誰でもわかるでしょう。
このように、ちょっと考えただけでも、ソフトウェア開発の仕事量（開発規模）を人月として正確に換算することは、ほとんど無理なことです。しかし、現実は、人月という指標が、疑念もなくまかり通っています。
それに対して、本書は、警告を発しています。
ソフトウェア開発の仕事量（開発規模）が「人月」によって決められるのであれば、それを使って単位時間あたりのアウトプットを「生産性」として算出することが可能になります。例えば、ひと月当たりにコーディングできるステップ数、ひと月当たりに書ける設計書のページ数、ひと月当たりに実施できるテスト数などです。
本書では、これら生産性を飛躍的（10倍以上）向上できる開発環境、開発手法、ツール、プログラミング言語などは執筆当時から10年以内には発明されてないことを指摘しています。それを「狼人間を打つ銀の弾丸はない」という有名な言葉で言い表しています。
この指摘は、VisualStudioなどの統合環境、オブジェクト指向、Java、C＃、Pythonなどの高級言語、アジャイル開発などが発明されてきましたが、現時点でも、この問題は解決されていません。
■ ITリソースは、お金で買える
人月によって、ITリソースが可視化され、商品として売買できます。
ITベンダーは、「人月商売」を業としており、雇用したITエンジニアの就業時間を商品として販売しています。
そして、それは一人一人の個人ではなく、束（複数人のチーム）として提供されます。
ITベンダーに属するITエンジニアは、同じ種類の案件が継続していくので、全員、保有する知識やスキルが同質化していきます。そのため、金太郎飴のように同じようなレベルの能力のITエンジニアが増えていきます。
その結果、同じ単価で同じレベルのITエンジニアを束にして販売することができます。
さらに、ITベンダーは、複数案件を一人のITエンジニアに担当させることで、案件単位の生産性を低位平準化します。したがって、優秀なITエンジニアは、一つの案件で100％集中させられることはなく、より多くの複数案件を担当させられることで成果が分散され、生産性が均されてしまいます。
優秀なITエンジニアであっても何倍もの人月単価を得られることは決してなく、優秀なITエンジニアほど仕事量が多くなって、労働量と賃金との妥当性がどんどん乖離していくというのが本当の姿です。
その結果、優秀な人ほど仕事に忙殺され、モチベーションが低下していき、スキルも狭い範囲だけにシュリンクしていき、並みのエンジニアへと劣後していきます。
■ 少数精鋭が怖い
ITリソースは、「質」か、「量」かと問われれば、量だと答えるユーザがほとんどでしょう。
よく言われるように、ITエンジニアの生産性は、人によって10倍以上もの差があると言われています。
同じ10人月でも、そこで働くITエンジニアによって、まったく違う成果が生み出されることになります。
そう考えると、ITリソースを量ではかることが正しいことなのだろうかと疑念が湧きます。
優秀なITエンジニアだけを集めた少数精鋭のプロジェクトが組めない理由は、失敗する恐怖があるからです。
人の姿を見ることはできますが、スキルや能力を見ることができないため、見える方を当てにしたくなるでしょう。
悪い言い方をすれば、優秀な人を信用できず、デクの坊や凡庸な人をたくさん集めたほうが安心できるという矛盾が「人月」には包含されているということです。
■ 目には目を、人月には人月を
ITプロジェクトの最大の問題は、遅延です。
ソフトウェアは人によってのみ作られるので、遅延が発生したときに人月、つまり、人を投入してリカバリするしか方法がありません。
しかし、人は機械のように一定のピッチで物をつくることができませんし、つまみ一つでピッチを上げたりすることもできません。
できるのは、ただただ人を増やす＝人月を増やすことです。しかし、これは予想通りには、遅延を解消することはできません。
テストであったり、動作環境のセットアップなど、いわゆるマックジョブと言われる単純作業であれば、人が増えれば、遅延を解消できるでしょう。しかし、ソフトウェア開発において、遅延の原因は、設計、プログラミング、デバック、課題解決など知識労働にあります。このような開発実務を誰でも対応できるかというと、不可能であると言わざるを得ません。
ブルックスは、「人月の神話」の中で、人を投入することのリスクは、「学習コスト」にあると言っています。誰でもそうでうが、それになりにピアノが弾ける人でも、難易度が高い曲を、初見で弾くことはできません。きちんと弾けるようになるには、練習時間というコストが必要になります。ソフトウェア開発も同様です。
ただし、例外があります。優秀なプロのピアニストであれば、初見でも弾けるように、ハイスキルのITエンジニアであれば、短時間で追いつくことができます。まさに、「銀の弾丸」として遅延という「狼男」を打つことができます。
はたして、このような超優秀なITエンジニアが身近にどれだけいるでしょうか。優秀であればあるほど、たくさんの仕事を抱えて、遅延が発生しているプロジェクトをヘルプできる余裕などありません。
手が空いているとしても、「学習コスト」がひどくかかるスキルの低いITエンジニアだけです。
このような人たちを人月として投入されると、遅延が増殖され、プロジェクトは「デスマーチ化」していきます。
■ まとめ
ITプロジェクトは、出たとこ勝負ではなく、なるようにはならない典型です。
ブルックスの提言は、ソフトウェア開発規模と複雑性が増大しつづけるソフトウェア開発に、よりリアルに迫ってきます。
解決策は、プロジェクトマネジメントの緻密にするようなマイクロマネジメント化ではなく、現場主義、技術面のハードスキルとコミュニケーション能力や問題解決力などのソフトスキルの拡充など、原点に戻るべきと考えます。
常に、現実を直視し、課題やリスクを「先読み」しながら、小さな芽の段階でつぶすような行動を、毎日毎日、実行し続けることが必要です。単なる管理ではなく、フレキシブルに対応できるマネジメントをしなければ成功には、至りません。
