ITシステム開発全般における指南書的な本。なんと初版1975年なのですが、いまにも通じることが多いのと、40年前とは思えない先見性のある本なのです。
↑気になったらここからポチっと↑
例：xxアプリのソースコード量の見積もりは10Ks（10,000行）
なお、生産性はプログラミング言語（JavaやPython・C・Cobolなど）によっても違いますし、同じ言語であっても対象となるアプリのミッションクリティカル度によっても異なります。例えば、重要性の高い企業の基幹系システムであれば入念にテストをする必要があるので低めの生産性指標を設定していたりします。
例：生産性指標が1人月=1Ksだった場合、10Ks開発するための工数は10人月
例：1人月＝100万円だった場合、10人月は1,000万円
この費用は開発にあたるSEの原価であり、これに管理者の費用やら開発に必要な物品費やらバッファ（なんかあった場合の予備費）を積み、開発にかかる原価を算出します。最後に利益分を積んだ金額がお客さんへの提案価格となります。けっこう泥臭い見積もり方ですよね。
例えば自動化ツールを使うと、設計書からソースコードが自動的に作られ、簡単なテストくらいまでは機械がやってくれます。従来の人月ベースの考えに当てはめると、1人月あたりの生産性が飛躍的に高まります。しかし、生産性が高まってしまうと見積もる際の工数が小さくなってしまいます。先ほどの例では、1人月=1Ksだったところが、仮に1人月=2Ksと生産性が倍になると10人月必要だった工数が5人月になってしまいます。そのぶん提案価格も下がるので、IT企業からすると効率化したぶん売上が減ることになります（価格が下がる分競争力は増しますが）。
ちょっと極端な例ですが、人月ベースの見積もりは人間が作業することを前提とした見積もりなので、自動化や機械化の流れと整合するのが難しかったりするのです。
また、1975年の時点で、今で言うJavaのようなオブジェクト指向型言語や、設計書などのドキュメントからのソースコード自動生成・テスト自動化の可能性を提唱するなど、先見性にあふれているのです。
↓気になったらここからポチっと↓
↑気になったらここからポチっと↑
人月ってなに？
”人月”という言葉は聞きなれないかもしれません。”にんげつ”と読み、英語でもそのままMan-monthと表現します。人月とはIT業界（特にシステム開発ビジネス）でアプリなどを開発する際の見積もりの単位で、一言で言うと”それを開発するのにどのくらいの人数・期間が必要か”です。例えば、10人月であれば、1人でやれば10ヶ月・5人でやれば2ヶ月かかるボリュームということになります。アプリケーション開発における見積もり
アプリケーション開発における見積もりはこんな感じで行われます。1. 開発するソースコード量の見積もり
過去の経験やら類似プログラムやらを基に、プログラムのソースコードで何行くらいになりそうかを見積もります。Ks（キロステップ＝ソースコード1,000行）という単位で表されることが多いです。
例：xxアプリのソースコード量の見積もりは10Ks（10,000行）
2. 生産性指標に基づいた工数（人月）の算出
IT各社で生産性の指標・ガイドラインを持っており、それに基づいてどのくらいの工数が必要かを算出します。生産性の指標は1人月＝1Ks（1人のSEは1カ月で1,000行のソースコードが書ける）のように表されることが多いです。（厳密に言うと、ソースコードを書くプログラミングだけでなく設計書などのドキュメンテーションやプログラムに対するテストなども含めた指標とする場合や、ドキュメンテーション・コーディング・テストなど工程ごとに指標を設けている場合があります）なお、生産性はプログラミング言語（JavaやPython・C・Cobolなど）によっても違いますし、同じ言語であっても対象となるアプリのミッションクリティカル度によっても異なります。例えば、重要性の高い企業の基幹系システムであれば入念にテストをする必要があるので低めの生産性指標を設定していたりします。
例：生産性指標が1人月=1Ksだった場合、10Ks開発するための工数は10人月
3. 開発費用の算出
生産性と同様に、1人月あたりの費用（SEの1カ月当たりの労務費）も各社で指標を持っており、人月に掛けることで開発費用を算出します。例：1人月＝100万円だった場合、10人月は1,000万円
この費用は開発にあたるSEの原価であり、これに管理者の費用やら開発に必要な物品費やらバッファ（なんかあった場合の予備費）を積み、開発にかかる原価を算出します。最後に利益分を積んだ金額がお客さんへの提案価格となります。けっこう泥臭い見積もり方ですよね。
人月ベースでの見積りの限界
IT業界では上記のような人月ベースでの見積もりが古くから行われており、その限界が指摘されるケースが増えてきています。例えば自動化ツールを使うと、設計書からソースコードが自動的に作られ、簡単なテストくらいまでは機械がやってくれます。従来の人月ベースの考えに当てはめると、1人月あたりの生産性が飛躍的に高まります。しかし、生産性が高まってしまうと見積もる際の工数が小さくなってしまいます。先ほどの例では、1人月=1Ksだったところが、仮に1人月=2Ksと生産性が倍になると10人月必要だった工数が5人月になってしまいます。そのぶん提案価格も下がるので、IT企業からすると効率化したぶん売上が減ることになります（価格が下がる分競争力は増しますが）。
ちょっと極端な例ですが、人月ベースの見積もりは人間が作業することを前提とした見積もりなので、自動化や機械化の流れと整合するのが難しかったりするのです。
本書の紹介
前置きが長くなりました。僕も人月ベースでの見積りの限界を感じており、何かヒントがないものかと本書を手に取った次第です。初版1975年の本だった
タイトル的に最近書かれた本なんだろうなと思いながらパラパラ読んでいたのですが、なんと1975年（僕が生まれる前！）に書かれた本だったのです。著者はIBMのSystem/360という初代のメインフレームマシンの開発マネジャーをされていた方で、当時の経験に基づいて人月の限界やシステム開発のお作法などが論じられています。古くて新しい
書かれたのは40年以上前ですが、”システム開発あるある”が色々出てきます。例えば、- 人月の誤った考え方は、”人と月が交換可能”であると考えること。例えば、10人月の仕事は理屈上、1人で10ヶ月・10人で1カ月となるが、そんな単純なものではない。
- 遅延したプロジェクトへの要員追加はさらなる遅延を招く。
- 一度構築したシステムに機能追加（追加開発）を繰り返すとモジュール数は線形に増えるが、影響範囲は指数関数的に増える。
また、1975年の時点で、今で言うJavaのようなオブジェクト指向型言語や、設計書などのドキュメントからのソースコード自動生成・テスト自動化の可能性を提唱するなど、先見性にあふれているのです。
20年目の再検証
初版は1975年ですが、それから20年たった1995年に著者が当時提唱した内容の再検証と今後の展望を追記しています。当時の論旨は一部誤っていたものの、概ね合っていました。また、1995年時点で以下のような将来展望が記載されています。- マウスによるポインティングデバイスの限界。マウスによる操作には限界があり、音声操作になるだろうと書かれています。実際に、スマホ・タブレットでは指による操作になりましたし、SiriやAlexaのような音声による操作が広まりつつあります。
- インクリメンタルな開発。期間をかけて最終製品を作るのではなく、動くものを少しずつ作っていくアジャイル開発のような方法論が提唱されています。
- システムの機能の再利用を促進するためのメタプログラミングインタフェースという概念が提唱されています。今で言うAPI（アプリケーション・プログラミング・インタフェース）のような概念です。
↓気になったらここからポチっと↓
