アート・オブ・プロジェクトマネジメント

読みかけの本読破第二段ということで、「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」を読んだ。ページ数が多めってことを差し引いても結構長い間読んでたな…（半年くらい前から？）。マイクロソフトでExcelを作成していた筆者の経験を基としたプロジェクトマネジメントのノウハウが記載されている。ためになるポイントも多かったと思うけど、読むのに時間をかけすぎたためかあまり覚えてない…ってのが正直なところかも（意味無いじゃん）。Joel on Softwareでも書かれていたけど、簡潔に面白おかしく書かれている本が記憶に残るし約荷立つことが多い…ってことで、この本はそういう観点からするとまぁまぁって感じ？結構冗長な説明が多かった印象です。でもでも、書かれている内容はいいことであることには変わりないよ。
僕は本を読む際に気になるページがあるとページの角をとりあえず折っておく習慣がある。以下、ページが折ってある部分のポイント。

• プロジェクトマネジメントとソフトウェア開発は神聖な芸術ではない。
• 作業をシンプルな視点から見ることで、よりパワフルに、より集中できるようになる。
• シンプルは簡単ということではない。
• 他人の失敗からできる限り多くのことを学ぶ。
• 曖昧さの許容/完全さの追求。
• プロジェクトマネージャはプロセスや方法論に注力するのではなく、チームに注力するべき。
• スケジュールの第二の目的は、プロジェクトに貢献するすべてのメンバーに対してチーム全体における個人の成果物の位置づけを理解させ、各メンバーの協調を促進させること。
• スケジュールの第三の目的は、進捗を管理し、作業を管理可能な塊に分割するツールをチームに与えること。
• スケジュールとは確立なり
• 見積もりに対する自身を定量化する。
• プログラマを信頼する。
• 見積もりは、プロジェクト目標に対するプログラマの理解度に依存する。
• ビジネスという視点（P56）
• プロセスで最も重要なことは、メンバーに期待される役割である。
• 全員にマイルストーンを知らせておくこと。
• 質の低いビジョンのドキュメントに見られる特徴（P94）
• プロジェクトの目標として洗い出された問題を解決するためにう必要なことは何でも行う。
• 解決しようとしているのは、どのような問題なのか？
• 様々な道を考察し、前提の誤りを見つけ出し、新たな疑問を洗い出しながら行きつ戻りつを繰り返すことが、ものごを設計するということ。
• 洗練と優先順位付け
• イテレーションの疑問（P148)
• 懸案事項の一覧(P149）
• 仕様書の記述や作業の文書化を行うにあったっての万能の方法など存在しない
• 仕様書の使用によってできることとできないこと(P157）
• 誰かの作業を誉めたい時には、面と向かって伝える
• 仕様書のレビュー方法（P173)
• 長所と短所の一覧表を作る（P188)
• データは意思決定を行わない
• 精度と正確さの違い
• 「すべての人は道を知っている。しかし実際にその道を歩く者はほとんどいない」（達磨大師）
• 仕事における最善の態度（P219-225)
• 優れたプロセスの持つ効果（P229)
• 「誰かが暗闇で何かをひっくり返した時、あなたはその人を非難することもできれば、ロウソクを灯すことも出来る。しかし、問題のあることを知っていたにも関わらず何の対処もしなかったのであれば、非はあなたにのみあるのだ」ポール・ホーケン
• 責任を取る
• 信頼は表明によって培われる
• あなた自身を信頼する
• 優先順位付けによってものごとが成し遂げられる
• 「チャンスは備えあるところに訪れる。」ルイ・パスツール
• 「計画に従うことで勝利できるような戦いはないが、計画なくして勝利できるような戦いもない」ドワイト・E・アイゼンハワー
• 期限に間に合わせるために多大な努力を要求するということは、次のフェーズで費やされるはずだった工数を横取りすることに等しい
• バグ・欠陥のマネジメント（P376)
• 政治とは汚いことを表す言葉ではない

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)