アート・オブ・プロジェクトマネジメント
>本書では「ものごとを成し遂げるためには何を行う（あるいは行わない）べきか」という実用的な視点からプロジェクトを捉えて、ものごとを成し遂げるための考え方やヒントを、スケジュール、ビジョン、要求定義、仕様書、意思決定、コミュニケーション、トラブル対策、リーダーシップ、政治力学といったさまざまな角度から考察しています。マイクロソフトで多くの巨大プロジェクトを成功へと導いてきた著者の豊富な経験とノウハウが凝縮された1冊として、マネージャやチームリーダーだけでなく、プログラマ、テスターなど、プロジェクトに関与するすべての人にお勧めです。
目次
>訳者まえがき
> 本書に寄せられた言葉
> はじめに
>
> 1章 プロジェクトマネジメントの簡単な歴史（なぜ気にかける必要があるのか）
> 1.1 歴史に学ぶ
> 1.1.1 失敗から学ぶ
> 1.2 ウェブ開発、厨房、緊急治療室
> 1.3 プロジェクトマネジメントの役割
> 1.4 マイクロソフトにおけるプログラムマネジメントとプロジェクトマネジメント
> 1.5 プロジェクトマネジメントにおけるバランス感覚
> 1.6 プレッシャとプロジェクトの敵
> 1.6.1 プロセスと目標を取り違える
> 1.7 正しい関与の仕方
> 1.7.1 あなたの観点からの強み
> 1.7.2 プロジェクトマネージャはユニークな価値を生み出す
> 1.8 サマリー
>
> I部 計画
>
> 2章 スケジュールの真実
> 2.1 スケジュールの3つの目的
> 2.2 銀の弾丸と方法論
> 2.3 スケジュールとは
> 2.3.1 1/3の法則を適用する
> 2.3.2 分割統治法（長いスケジュール＝多くの短いスケジュール）
> 2.4 なぜスケジュール通りに進まないのか
> 2.4.1 目隠しをした状態での遠距離射撃
> 2.4.2 スケジュールとは確率なり
> 2.4.3 見積もりは難しい
> 2.4.4 優れた見積もりは優れた設計から生み出される
> 2.4.5 よくある見過ごし
> 2.4.6 雪玉効果
> 2.5 スケジュールを機能させるためにすべきこと
> 2.6 サマリー
>
> 3章 やるべきことを洗い出す
> 3.1 ソフトウェア計画の謎を解く
> 3.1.1 プロジェクトのさまざまなタイプ
> 3.1.2 組織が計画に与える影響
> 3.1.3 一般的な計画の成果物
> 3.2 計画へのアプローチ：3つの視点
> 3.2.1 ビジネスという視点
> 3.2.2 技術という視点
> 3.2.3 顧客という視点
> 3.3 視点を超越した視点
> 3.3.1 パワーバランス
> 3.4 正しい疑問を持つ
> 3.4.1 正しい疑問に答える
> 3.4.2 時間がない場合は？
> 3.5 よく見かける悪い手段
> 3.6 計画プロセス
> 3.6.1 日々の作業
> 3.7 顧客調査とその誤用
> 3.8 すべてをまとめる：要求定義書
> 3.8.1 問題はシナリオになる
> 3.8.2 ビジネス要求および技術要求との統合
> 3.9 サマリー
>
> 4章 優れたビジョンを記述する
> 4.1 書き留めることの価値
> 4.2 どれだけのビジョンが必要となるのか？
> 4.2.1 チームの目標と個人の目標
> 4.3 優れたビジョンに備わる5つの品質
> 4.3.1 シンプル
> 4.3.2 意図重視（目標駆動）
> 4.3.3 統合
> 4.3.4 閃き
> 4.3.5 覚えやすい
> 4.4 網羅しておくべきキーポイント
> 4.5 うまく書き留める
> 4.5.1 シンプルであることの難しさ
> 4.5.2 うまく書き留めるには、主となる著者を1人起用すること
> 4.5.3 量は質にあらず
> 4.6 草稿、レビュー、改訂
> 4.7 （避けるべき）質の低いビジョンの一覧
> 4.8 ビジョンと目標の例
> 4.8.1 ビジョンの文章と目標を裏付ける
> 4.9 ビジョンはビジュアルになっているべきである
> 4.9.1 見えないものをビジュアルにする
> 4.10 ビジョンの健全さをチェックする：日々の確認
> 4.11 サマリー
>
> 5章 アイデアの源
> 5.1 要求と解決策の間に横たわる溝
> 5.1.1 要求の品質とミスの回避
> 5.1.2 設計の探求
> 5.1.3 探求に対する恐れと進歩を促すアイデア
> 5.2 悪いアイデアは存在する
> 5.2.1 優劣は何と比較するのか？
> 5.3 枠の内外で考えるのはOK
> 5.4 優れた質問は優れたアイデアを惹きつける
> 5.4.1 焦点合わせの質問
> 5.4.2 創造的な質問
> 5.4.3 修辞的な質問
> 5.5 悪いアイデアは良いアイデアの素となる
> 5.5.1 優れた設計は多くの優れたアイデアから生み出される
> 5.6 ものの見方とアドリブ
> 5.6.1 アドリブ講座におけるアイデアを生み出すためのルール
> 5.6.2 アイデアを生み出すその他のアプローチ
> 5.7 顧客のエクスペリエンスが設計を開始させる
> 5.8 設計とは一連の対話である
> 5.9 サマリー
>
> 6章 アイデアを得た後にすること
> 6.1 アイデアが手に負えなくなる時
> 6.2 アイデアのマネジメントには毅然とした態度が必要となる
> 6.2.1 変更によって連鎖反応が引き起こされる
> 6.2.2 創造的な作業には勢いがある
> 6.3 設計フェーズにおけるチェックポイント
> 6.4 アイデアのまとめ方
> 6.4.1 洗練と優先順位付け
> 6.5 プロトタイプはあなたの友達
> 6.5.1 プロトタイピングの始め方は？
> 6.5.2 ユーザーインタフェースを用いたプロジェクトのプロトタイピング
> 6.5.3 ユーザーインタフェースを用いないプロジェクトのプロトタイピング
> 6.5.4 プロトタイプはプログラマの味方
> 6.5.5 設計選択肢によって成功への扉が開かれる
> 6.6 イテレーションについての疑問
> 6.7 懸案事項の一覧
> 6.8 サマリー
>
> II部 スキル
>
> 7章 優れた仕様書の記述
> 7.1 仕様書の使用によってできることとできないこと
> 7.2 記述することを決定する
> 7.2.1 仕様書の責任者は誰？
> 7.3 仕様書の記述は設計ではない
> 7.3.1 設計の記述VS.構築方法の記述
> 7.3.2 優れた仕様はシンプルである
> 7.3.3 正しいものごとが起こるようにする
> 7.4 いつ誰がどうやって
> 7.4.1 1人のための記述VS.多くのための記述
> 7.5 仕様書はいつ完成するのか？
> 7.5.1 どれだけやれば十分か？
> 7.5.2 懸案事項のマネジメント
> 7.5.3 仕様書を完成させることの重要性
> 7.6 レビューとフィードバック
> 7.6.1 仕様書のレビュー方法
> 7.6.2 誰を参加させ、どのように運用するべきか？
> 7.6.3 質問の一覧
> 7.7 サマリー
>
> 8章 優れた意思決定の行い方
> 8.1 意思決定の重要度を評価する（リスクは何か？）
> 8.2 選択肢の発見と重み付け
> 8.2.1 感情と明確さ
> 8.2.2 比較を容易に行うためには
> 8.2.3 議論と評価
> 8.2.4 シャーロック・ホームズ、オッカムの剃刀、熟考
> 8.3 情報とは懐中電灯のようなもの
> 8.3.1 データは意思決定を行わない
> 8.3.2 データの解釈ミスは簡単に起こる
> 8.3.3 結果ありきの調査
> 8.3.4 精度と正確さの違い
> 8.4 決定する勇気
> 8.4.1 勝利をもたらす選択肢のない意思決定もある
> 8.4.2 優れた意思決定でも悪い結果をもたらすことがある
> 8.5 注意を払い、振り返る
> 8.6 サマリー
>
> 9.1 対話を通じたマネジメント
> 9.1.1 人間関係はコミュニケーションを促進させる
> 9.2 コミュニケーションの基本モデル
> 9.3 コミュニケーション上のよくある問題
> 9.4 人間関係に依存するプロジェクト
> 9.4.1 役割の定義
> 9.5 仕事における最善の態度
> 9.5.1 メンバーにベストを尽くしてもらう方法
> 9.5.2 メンバーがベストを尽くせるように支援する理由
> 9.6 サマリー
>
> 10章 メンバーの邪魔をしない方法：プロセス、電子メール、打ち合わせ
> 10.1 人々が不快になる理由
> 10.2 優れたプロセスの持つ効果
> 10.2.1 優れたプロセスを見つけ出す方程式
> 10.2.2 プロセスの作成、実践方法
> 10.2.3 下層から行うプロセスのマネジメント
> 10.3 人を不快にさせない電子メール
> 10.3.1 優れた電子メール
> 10.3.2 まずいメールの例
> 10.3.3 よい電子メールの例
> 10.4 打ち合わせを不快なものにしない方法
> 10.4.1 ファシリテーションの技芸
> 10.4.2 ファシリテーションにあたっての注意点
> 10.4.3 打ち合わせの3形態
> 10.4.4 邪悪な、惰性による打ち合わせ
> 10.4.5 打ち合わせにあたっての注意点
> 10.5 サマリー
>
> 11章 問題発生時に行うこと
> 11.1 大まかな指針の適用
> 11.2 よく見かける問題
> 11.2.1 問題の発生を知る方法
> 11.2.2 難題の一覧
> 11.2.3 実践と訓練を難しくするもの
> 11.3 責任を取る
> 11.4 ダメージコントロール
> 11.5 競合する解決策と交渉
> 11.6 役割と明確な権限
> 11.6.1 誰が意思決定者なのかを全員が知っておく必要がある
> 11.7 感情についての色々：プレッシャ、感情についての感情、ヒーローコンプレックス
> 11.7.1 プレッシャ
> 11.7.2 感情についての感情
> 11.7.3 ヒーローコンプレックス
> 11.8 サマリー
>
> III部 マネジメント
>
> 12章 リーダーシップが信頼に基づく理由
> 12.1 信頼の構築と破壊
> 12.1.1 信頼は表明によって培われる
> 12.1.2 矛盾した振る舞いによって信頼が失われる
> 12.2 信頼を明確にする（グリーンライトを点灯させる）
> 12.3 力の種類
> 12.3.1 付与された力に頼るべからず
> 12.3.2 力の獲得に向けた作業
> 12.3.3 説得は命令よりも強い
> 12.3.4 時には専制君主的に
> 12.4 他者を信頼する
> 12.4.1 権限の委譲
> 12.5 信頼は逆境に対する保険である
> 12.6 モデル、質問、競合
> 12.6.1 リーダーはフィードバックプロセスを定義する
> 12.7 信頼と過ち
> 12.7.1 問題が未解決なのに叱りつけてはいけない
> 12.8 あなた自身を信頼する（自恃）
> 12.9 サマリー
>
> 13章 ものごとを成し遂げる方法
> 13.1 優先順位付けによってものごとが成し遂げられる
> 13.1.1 一般的な順序付き一覧表
> 13.1.2 第1級優先順位VS. その他もろもろ
> 13.1.3 優先順位は力なり
> 13.1.4 優先順位付けマシンとなるべし
> 13.2 あなたが「ノー」と言う時に、ものごとが成し遂げられる
> 13.2.1 「ノー」の言い方
> 13.3 現実感を保ち続ける
> 13.4 クリティカルパスを知る
> 13.5 冷酷であれ
> 13.6 抜け目なくあれ
> 13.6.1 ゲリラ戦術
> 13.7 サマリー
>
> 14章 中盤の戦略
> 14.1 飛行機の前方を飛行する
> 14.1.1 あなたの健全さをチェックする
> 14.1.2 前方を飛行するための戦術的（日々の）質問
> 14.1.3 前方を飛行するための（週次/月次の）戦略的質問
> 14.2 安全な行動をとる
> 14.2.1 表明を破棄する
> 14.3 コーディングのパイプライン
> 14.3.1 挑戦的なパイプラインと保守的なパイプライン
> 14.3.2 コーディングのパイプラインはバグ修正のパイプラインとなる
> 14.3.3 進捗の追跡
> 14.4 動いている標的を狙う
> 14.4.1 鶴の一声の取り扱い
> 14.4.2 変更のマネジメント（変更管理）
> 14.5 サマリー
>
> 15章 終盤の戦略
> 15.1 大きな期限は、小さな期限の集合体でしかない
> 15.1.1 終了条件の定義
> 15.1.2 期日に間に合わせることと飛行機の着陸が似ている理由
> 15.1.3 ものごとが悪化する理由
> 15.1.4 アプローチの角度を修正するための大まかな指針
> 15.2 測定すべき要素
> 15.2.1 日々のビルド
> 15.2.2 バグ/欠陥のマネジメント
> 15.2.3 アクティビティチャート
> 15.2.4 傾向の評価
> 15.2.5 有益なバグ指標
> 15.3 コントロールすべき要素
> 15.3.1 レビューミーティング
> 15.3.2 トリアージ
> 15.3.3 ウォーチーム
> 15.4 終盤の大詰め
> 15.4.1 リリース候補（RC）
> 15.4.2 移行と運用
> 15.4.3 プロジェクトの検死
> 15.5 パーティタイム
> 15.6 サマリー
>
> 16章 社内の力関係と政治
> 16.1 私が政治を意識した日
> 16.2 力の源
> 16.3 力の誤用
> 16.3.1 力の誤用を発生させるプロセス
> 16.3.2 モチベーションに起因する力の誤用
> 16.3.3 力の誤用を防止する
> 16.4 政治的な問題を解決する方法
> 16.4.1 ニーズの明確化
> 16.4.2 あなたに必要なものを与える力は、誰が持っているのか？
> 16.4.3 評価
> 16.4.4 影響力を行使する際の戦術
> 16.5 場を知る
> 16.5.1 自分自身の政治の場を作る
> 16.6 サマリー
> 索引
>