第一部 問題とゴール

１章　計画の目的

• 初期の計画は不正確で、プロジェクトが進むにつれて正確になる（不確実性コーン）
• 計画作りはリスクと不確実性を低減させ、信頼のおける意思決定を導き、信頼関係を確率し、情報を伝達する
• 何かを学んだり過ちに気付いたりすれば変化が起きるので都度計画は変更する必要がある

用語

• リリース
  • ソフトウェアを実際に顧客に提供し、実用に使ったもらう
• 納品、デプロイ
  • リリースに必要な作業のこと
• リリース可能なソフトウェア(Shippable Software)
  • ドキュメント、本番運用環境の準備、品質保証部門による検査などの手続きが終了すればリリースできる状態にあるソフトウェア
• フィーチャ
  • 売り文句（機能、特性や特徴、性能目標、見た目、使い勝手）などを総称する言葉。
  • 要求仕様、機能要件といった言葉が指すものと似ているが、ユーザーにとってのソフトウェアの価値を表現するという点が決定的違いである。
  • 例）オンラインショッピング
    • フィーチャ：欲しい商品を注文できる
    • !フィーチャ（機能）：商品選択画面、注文確認画面

第２章 なぜ計画づくりに失敗するのか

顧客に重要なのはフィーチャだが従来手法は作業を基準に計画をするので、変更の阻害や、 スケジュールのための重要機能の削除などのフィーチャの軽視の行動に繋がる。 マルチタスク化は切り替えコストによりスケジュールの遅延を悪化させる。 ユーザーが求めるものの不確実性や、開発方法の不確実性を無視してはいけない。 見積もりはコミットメントではない。

用語集

• パーキンソンの法則「仕事の量は、完成のために与えられた時間を全て満たすまで膨張する」

第3章 アジャイル手法

アジャイルチームはビジネス観点でもっとも重要なフィーチャから順番に開発する。 プロジェクトは新たな機能と知識を生み出し続ける活動であり、計画を立てたそばから実態と乖離していくので、 アジャイルチームは計画を頻繁に見直す アジャイルチームの計画づくりは、リリースプランニング、イテレーレーションプランニング、デイリープランニングの３つ。 リリースプランニング、イテレーションプランニングでは、プロダクトオーナーの満足条件をどう満たすかをチーム全員で考える。 （満足条件を緩めることもある）

用語