自分のまわりにも比較的多いノンプログラマーなプロジェクトマネージャ(例えばSIerに所属されている方)に現時点でおすすめする本をまとめてみる記事の後編。前編はこちら。ノンプログラマーなPMは「技術が苦手」という旗を自ら頭の上に立てていることが多い(それに比べるとプログラマーは勉強熱心だ)。技術書は「技術の本」であるから、というロジックで技術書を手に取らないのであれば、それはもったいないと思っている。流行りのビジネス書や仕事術の本ばかり読まず、プロジェクトマネジメントの本をもっと読んでくれたら良いと思っている。
デスマーチ関連ｗ
闘うプログラマー[新装版]
PMの経験値を上げる本として紹介したい一冊。「精神と時の部屋」の疑似体験。本書をひとことで言えば、非常に苦難の道のりであった大規模プロジェクト「WindowsNT」の開発に関するドキュメンタリーである。単純にノンフィクションとして非常に面白い。本書は「プロジェクトを成し遂げること」について学べる本だと思っている。旧版が新古書店などで100円で手に入ることもあるのでチェックしてみるのも良いだろう。
![闘うプログラマー[新装版]](https://m.media-amazon.com/images/I/51kV6tOSplL._SL500_.jpg "闘うプログラマー[新装版]")
「第一に、品質は、全員の信念でなければならない。
トップの経営者から、一番下の助手まで、全員の信念でなければならない。
経営陣の風向きをいつも気にする気弱な管理者に、用はない。
品質を守るには、勇気が必要なこともある。
わたしのプロジェクトのメンバーはだれでも、そのライセンスをもっている。
不完全なまま出荷したいというばかがいれば、くたばりやがれと言ってやる」
闘うプログラマー[新装版]
このあたりの書評なども参考に。
なお興味深いのは、90年代前半においてすでにMicrosoftではデイリービルドや、リグレッションテストなどのプラクティスが本格的に行われていたということ。まったくの個人的偏見なのだけれども90年台のMicrosoftは圧倒的に賢い人たちが集中していた印象があって(IEのマネージャだったScott Berkunとか、ExcelのマネージャだったJoel Spolskyとか)とても参考になると思っている。
プロジェクトマネジメント(上級)
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
私のバイブル。本書は、MicrosoftでIEのマネージャであったScott Berkunによる包括的なプロジェクトマネジメントに関する書籍である。PMBOKなどに代表されるマネジメント技術体系には触れられていないような、ソフトウェア開発プロジェクトの勘所が詰まっている。タイトルにもあるようにプロジェクト・マネジメントは技術ではなく技芸と捉えており、全編参考になると言っても過言ではない。なおアジャイル開発とか、ウォーターフォールなどの開発プロセスには触れていない点も汎用的で良い。Jolt Awards2006年受賞。
このあたりも参考に。
- 「アート・オブ・プロジェクトマネジメント」読書感想文【まとめ】: わたしが知らないスゴ本は、きっとあなたが読んでいる
- 第2回 「scottberkun.com」Scott Berkun：インタビュー編―問題解決と良いコミュニケーションのヒント：Developer's Perspective―海外エンジニア/ブロガー 直撃インタビュー＋翻訳エッセイ｜gihyo.jp … 技術評論社
- 第2回 「scottberkun.com」Scott Berkun：翻訳エッセイ編―創造的思考Hacks：Developer's Perspective―海外エンジニア/ブロガー 直撃インタビュー＋翻訳エッセイ｜gihyo.jp … 技術評論社
巨大で危険な物体を操縦するときには、操縦桿をしっかりと握っているだけでは不十分です。あなたが操縦しようとしているものが巨大であり、多くの人が関与しているのであれば、より大きな慣性が働くのです。プロジェクトマネジメントにおいても同様ですが、巨大な機械（自動車、飛行機、航空母艦等）を操縦する場合、初心者は進路変更操作をしてから、実際に変更し始めるまでの時間を過小評価しがちです。
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
Manage It! 現場開発者のための達人式プロジェクトマネジメント
私のもう一つのバイブル。こちらはマネジメントコンサルタントのJohanna Rothmanによるまさに実践的なマネジメントに関する本である。主にリスク管理の観点が強いのだけれども、だからこそ「いますぐ役に立つ」本だと言える。なお本書も開発プロセスからは中立的である。Jolt Awards2008年受賞。
本書の目的は、ソフトウェアプロジェクトの状況や問題点を把握して考察する方法、および、プロジェクト内の問題に起因するリスクと開始時点で既にプロジェクトに内在しているリスクを管理する方法を示すことにある。各章では、計画書の作成からリリースまでのさまざまな段階でソフトウェアプロジェクト内部の状態を確認し、必要なデータを取得しながら、まるで手を触れたり味をみたり匂いを嗅いだりするように綿密に状況を把握していく方法を説明する。
Manage It! 現場開発者のための達人式プロジェクトマネジメント はじめに
このあたりも参考に。
コンストラクション全般
Code Complete第2版―完全なプログラミングを目指して
ノンプログラマーという理由で避けていたら惜しい名著。プログラミングがわからなくとも問題ない。確かに本書の中心話題は「コーディングとデバッグ」だけれども、そこを避けて読んでも十分に役に立つ。先頭から読み進めていって、必要に応じて「この章はパス」という判断をしても良いだろう(第6章～第19章あたりを飛ばすと良い。上巻の3/4くらいがこれに当たる。本書が高価であることを考えるとちょっとモッタイナイけれども、だったら社費購入とか古書、図書館を利用しても良いだろう)。Jolt Awards1994年受賞。
本書を執筆する上で私が最も配慮したのは、業界の第一人者や教授らの知識と、一般的な商用プラクティスとの差を縮めることである。多くの協力なプログラミングテクニックは、一般のプログラミングに浸透するまで何年もの間、専門誌や学術論文に埋もれている。
近年、最先端のソフトウェア開発プラクティスが目覚しい進歩を遂げている。しかし、一般的なプラクティスの方はそうではない。多くのプログラムは依然としてバグだらけだし、スケジュールは遅れ、予算をオーバーし、ユーザーのニーズには応えていない。(中略)いくつかの調査で、研究開発が商用プラクティスとして普及するには、一般に5～15年、あるいはそれ以上かかることがわかっている。本書は、そのプロセスを短縮し、重大な発見を平均的なプログラマに提供しようとするものである。
CODE COMPLETE 第2版 上 完全なプログラミングを目指して はじめに
残念ながら、まだ本書が書かれた1994年レベルにすら達していないプロジェクトはあるのだ。
さらに読みたい人向けの情報
ちょっと古いのだけれども、Joel on Softwareの著書のJoel Spolsky選定のマネージメントトレーニング用課題読書リストというものがある。2005年の記事と、ちょっと古いのだけれども、紹介されている書籍はいずれ劣らぬ名著ばかりだ。ワタシも以前、このリストを総ざらいで当たっていた(ただしパーフェクトには至っていない)。
