今月のはじめに、LIG社に寄稿した記事の評判が良かったので、こちらにも転載しておこうと思う。

システム開発のプロジェクトマネージャーは、間違いなく現代における最も難しい仕事の一つであると個人的に思う。下にも書いているように、ソフトウェア開発は「まずは現実の問題を解決しなければならない」上に、発注元である顧客もその解決方法が曖昧だったりする。

そして、システムが出来上がらなければ、「自分たちが考えていること」と、「システムが実現できること」の違いを理解できないからだ。したがって、プロジェクトマネージャーは常に「増え続ける要求」と、戦い続けなければならない。これは想像以上にしんどい仕事だ。

したがって、「不確定要素をコントロールする技術」をプロジェクトマネージャーは最初に学ばなければならない。これは学校や会社においてすら、なかなかうまく学ぶことの出来ない技術である。

そういった技術をうまく説明してくれる本は非常に少ないのだが、下に挙げる書籍は読む価値があると個人的に感じる。

————-以下転載————–

こんにちは。安達です。今年も引き続き、張り切って行きたいと思います。

さて、突然ですがみなさんは「プロジェクトマネージャー」を目指してますか？　もちろん、ひと口にプロジェクトマネージャーと言ってもさまざまな方がいます。

大規模な業務システム構築のプロジェクトもあれば、ECサイトやWebサービス構築プロジェクトもあります。LSIのチップ制御ソフトウェア開発もあれば、スマートフォンのゲームアプリ開発もあります。
ただ、共通して必要とされるスキルが、「プロジェクトマネジメント」だということは、みなさんも意見が一致するのではないでしょうか。

しかしそうはいっても、プロジェクトマネージャーになってから独学でプロジェクトマネジメントをゼロから学ぶのはとても非効率です。もちろん会社でOJTをするなり、体系的なプロジェクトマネジメントのマニュアルがあるならば、さしあたっての問題はないでしょう。

でも、ある程度「先人の知恵から」学ぶことができれば、知識の吸収も早いですし、なによりも「不測の事態」へ対応する力が上がります。

そこで今回は、「プロジェクトマネージャーになったら読むべき本」をご紹介したいと思います。残念ながら、プロジェクトマネジメントに関しては世の中には何やら難しい本が多いですが、以下に紹介する本は比較的読みやすく、かつ実践的であり、現場の知恵を補強するのに使えると思います。

では、行ってみましょう。

プロジェクトマネージャーになったら絶対に読むべき本6選

1. 人月の神話―狼人間を撃つ銀の弾はない（フレデリック・P,Jr.ブルックス ピアソン桐原）

古典。最も多くの人が読んだプロジェクトマネジメントの本の1つです。古くはなったものの今でも「原典」として実用に足る本です。例えば、あまりにも有名な「ブルックスの法則」は、この本で紹介されています。

ブルックスの法則

「遅れているプロジェクトに人を追加しても、ますます遅れるだけである」

この本が普遍性を失わない理由は、「ソフトウェア開発の本質的な難しさ」をきちんと分析していることにあります。

言ってしまえば、この本の主張は「ソフトウェア開発は本質的に難しい。それはコードを組み上げること以前に、現実の問題を解かなければいけないからだ」と言うものです。そして、著者は難しさの原因は4つあると述べます。

• 複雑性：ソフトウェアは、複雑である。仕様、設計、コード全てが大きいからだ。
• 同調性：ソフトウェアは、それ単独で存在するのではなく、さまざまな外部の要因（ネットワーク、ハードウェア、人など）に合わせなければいけない。それはとても難しい。
• 可変性：ソフトウェアは常に変化を求められる。
• 不可視性：ソフトウェアは目に見えない。見えないものは扱いにくい。

世の中には、さまざまなプロジェクトマネジメントの手法がありますが、「それらがなぜ生み出されたのか、何を目的としているか」ということについて知るための良い本だと思います。

2. クリティカル・チェーン（エリヤフ・ゴールドラット ダイヤモンド社）

エリヤフ・ゴールドラット氏という物理学者が考案した「制約条件の理論」に基づくプロジェクトマネジメント手法を紹介しています。小説形式で非常に読みやすいのが大きな特長です。

「プロジェクトはなぜ遅れるのか」という問いに対して彼が出した答えは、

• 納期を100%守るため、プロジェクトメンバー各自が大きくバッファのある期限を申告する。
• 早めに終わった人でもギリギリまで時間を使ってしまうため、どこかの工程で遅れが出ると、結局それがそのままプロジェクトの遅れになる。

という2つを主な原因としてあげています。

これを打破するため、エリヤフ・ゴールドラット氏が提案するのがクリティカルチェーン法です。これは、

• プロジェクトメンバーは個別にバッファをかなりとった期限を申告するのではなく、「できるかどうかわからない、ギリギリの期限」を申告する。
• バッファは、プロジェクト全体の共有バッファと、クリティカルパスへの合流地点での共有バッファにのみ取っておく。（バッファは、個別の作業者でそれぞれ分けるのではなく、プロジェクト全体で共有する）

という2つが骨子です。
プロジェクトの遅れを科学的に分析した本としては、かなりわかりやすい分類に入るので一読をおすすめします。

3. 曖昧性とのたたかい（名内泰蔵 翔泳社）

元日立のエンジニアで、「みどりの窓口の予約システム」のプロマネの経験もある名内氏の著作。
個人的にはかなりの名作です。上の2つの本はどちらかと言えば「理論」が重視されていますが、この本はひたすら「現場で何が起きたか・何をしたか」に焦点が当てられています。

実践的な知恵が数々紹介されており、例えば、

「新人には、重要な部分を任せよ」

というノウハウなどが紹介されています。これは、周辺部のマイナーな部分は誰も見ていないためベテランが行い、新人は重要な部分を担当させ、みんなが見張るようにせよ、と言う趣旨です。まさに現場の知恵と言えます。

現場のTipsが欲しい人にはオススメです。

4. ソフトウェア見積り（スティーブ・マコネル 日経BPソフトプレス）

見積りはもっとも難しい仕事の1つですが、残念ながらやり方が確立していない仕事の1つでもあります。そんなときにオススメなのがこの本。著者のスティーブ・マコネル氏はソフトウェア工学の第一人者でもあります。

この著作で最も著者が訴えたかったことは、

「見積もりとは、幅である」

ということでしょう。

例えば、現在1つのプロジェクトが始まろうとしており、カットオーバーを12ヵ月後とします。プロジェクト責任者を呼び、製品完成までの納期を見積らせたところ、責任者は、「11ヵ月で製品開発終了しますので、1ヵ月程度の余裕があります」と言いました。

本当にこのプロジェクトは11ヵ月で終わるでしょうか？
IBMのプレゼンテーションによれば、12ヵ月後であっても予定通り顧客に納品できる確率は50％程度です。

これは、11月をターゲットとしてプロジェクトを進めた場合、不測の事態によってプロジェクトは遅延を起こし、実際には14ヵ月、15ヵ月かかるかもしれない、ということです。
見積りとは幅を提示することであり、「いつまでにやります」というコミットはリスク管理との兼ね合いで調節せよ、というのが著者の主張です。

この他にも統計に基づくスケジュールの基本公式

スケジュール（月）=3.0×人月^1/3

などが載っており、基本的な見積の計算式の基礎を学ぶのに良い本です。

5. ピープルウェア（トム・デマルコ 日経BP社）

マネジメントコンサルタントの第一人者である、トム・デマルコ氏の著作。彼のエッセイをまとめたもので、柔らかい文体と、鋭い分析で引き込まれます。
主題は「メンバーのやる気」。

体系的、というよりは現場での経験に基づく法則を集めたもので、最近の言葉で言えば、「ライフハック集」と言って良いと思います。
元祖ライフハックを読んでみたいという方には、オススメです。

6. ソフトウェアメトリクス調査（日本システムユーザー協会）

最後はすこし変わった本です。これはいわゆる「読み物」ではなく、いわゆる「統計データ集」です。

日本システムユーザー協会という団体が毎年発行しており、日本におけるユーザー企業の開発の実体をデータ化し、統計数値として紹介しています。どのようなデータが含まれるか、少し紹介すると、

• 主要な開発言語は何が多いか
• 非機能要求項目の提示項目毎の比率は
• 全体工数と全体工期の相関は
• システム規模別の納期遅延度は

といったさまざまなプロジェクトに関する統計値を入手できます。

これらのデータは非常に有用で、今まで勘に頼っていた「どの程度の期間で開発するべきか？」であったり、「どの程度バグを出せば正常値といえるのか？」などについての標準値を手にすることができます。

もちろん参考情報ではありますが、手元に置いておきたい一冊です。ただしちょっと高価（5,000円以上する）なので、個人で買うよりも会社で買って共有するのが良いかもしれません。

まとめ

以上で、プロジェクトマネージャーが読んでおくべき6冊の紹介は終わりです。

「プロジェクトマネジメント」に関する本は数多くありますので、上に挙げた本よりも良い本がたくさんあるとは思いますが、普遍的なことについて書かれた「名著」は抑えておいても良いのではないかと思います。

筆者Facebookアカウント https://www.facebook.com/yuya.adachi.58 （スパムアカウント以外であれば、どなたでも友達承認いたします）