アジャイルな見積りと計画づくり:第1部:問題とゴール「1章 計画の目的」まとめ

最近は「アジャイルな見積りと計画づくり」を読んでいる。100ページくらい読んで、本に線は引いたけど、いまいち整理出来ていないので、以前読んだ場所を整理していこうと思った。
高校生くらいのころ、好きな本が1冊あって何回も読んでいた。その本には「読んだ本は、自分なりにまとめて読み返せるようにした方が良い」と書いてあった覚えがある。それをやってみよう。
今日は【第1部:問題とゴール「1章 計画の目的」】の理解することにした。ページ数はP25〜P35で10ページ。

目次

  • 計画の目的
  • なぜ見積りや計画づくりが必要なのか?
  • リスクを軽減する
  • 不確実性を減らす
  • 意思決定を支援する
  • 信頼を確立する
  • 情報を伝達する
  • 良い計画とはなにか?
  • アジャイルな「計画づくり」とは?
  • まとめ

計画の目的

  • 見積りと計画づくりをアジャイルにする手法を紹介していくにあたっては、計画づくりの目的を理解することが重要だ
  • 計画は投資判断となる
    • たとえば、あるプロジェクトの見積が6ヶ月で100万なら実施するが、2年で400万かかるのであれば却下するかもしれない
  • 計画は、プロジェクト期間中にどんな人材が必要となるのか把握するのに役立つ
  • 計画は、プロジェクトがユーザーの求めるフィーチャを提供できるか確認するのにも役立つ
  • 計画なしでは、プロジェクトは行く手に待ち受ける無数の問題に対して無防備になってしまう
  • 計画づくりは難しい
    • 見積りと計画づくりの難しさは、いまに始まった話ではなく、昔から知られている
    • 不確実性コーン
    • この不確実性コーンからは、初期のプロジェクト定義の段階では見積りに60%〜160%に及ぶ誤差が生じることがわかる。つまり、20週間かかると見積もられたプロジェクトは、実際には12週間〜32週間かかることになる
    • 要求が固まった後でも、まだ見積にはプラスマイナス15%の誤差が見込まれている。その結果、この段階での見積が20週間だということは、実際にはかかる期間は17週間〜23週間だということだ
  • プロジェクトマネジメント協会(PMI)も同様の見解を示している
  • プロジェクトが進むにつれて見積は正確になっていくのである


なぜ見積りや計画づくりが必要なのか?

  • 分かりやすい理由として、働いている組織から見積りの提出を求められることが挙げられる
    • マーケティングキャンペーンの計画を立てるためだったり
    • プロダクトリリース作業の予定をたてるためだったり
    • 組織内のユーザーをトレーニングするためだったり
    • いずれの場合にも計画や見積はかかせない
  • 見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない
  • 計画づくりとは価値の探求なのだ。とりわけ計画づくりを継続的に繰り返しながら行う場合はそうだ
  • 計画づくりとは、ソフトウエア開発の全体にわたる問に対する適切な答えを探る試みだ。その問ととはすなわち「なにをつくるべきか?」である。チームがフィーチャ、リソース、そしてスケジュールを検討するのは、この問に答えるためだ。とはいえ、その問に対していきなり最適な答えを出すことはできない。答えをゴールへと少しずつ近づけていくこと(インクリメンタルに)、そしてそれを繰り返すこと(ィテレーティブに)。計画づくりは両者をあわせて進めていかなければならない。
  • 良い計画づくりとは、以下のような特徴をもったプロセスのことだ。いずれも「ソフトウエア開発の問い」に対する答えを見つける手助けとなる。
    • リスクを軽減する
    • 不確実性を減らす
    • 意思決定を支援する
    • 信頼を確立する
    • 情報を伝達する

リスクを軽減する

  • 計画づくりによって、プロジェクトのリスクに関する情報が得られる。その知見を活かすことでプロジェクトの成功可能性を高められる
  • プロジェクトによっては、リスクが判明した時点で、そのリスクがあまりにも高すぎて取り止めになることがある。その一方で、リスクがあっても早い段階で対処すれば許容範囲内に収められるプロジェクトもある

不確実性を減らす

  • プロジェクトを通じてチームが生み出していくのは、プロダクトの新しい機能だけではない。プロダクトとプロジェクトに関する新しい知識も生み出していく
  • 知識は新しく得られていくものだということを受け入れて、その知識を計画づくりに活かすことはとても重要だ
  • 計画づくりのプロセスは繰り返し実施されるィテレーティブなものであり、その狙いは新しく得られた知識をそのつど取り込みながら、プロダクトのあるべき姿を洗練させていくことにある
  • 多くのプロジェクトが直面する最大のリスクは、間違ったプロダクトを開発してしまうことだ。ところがこのリスクはほとんどのプロジェクトでは無視されている。計画づくりをアジャイルにすることで、このリスクを大幅に軽減できる(理想を言えば完全に除去できる)
  • 私がプロジェクトの失敗を定義するならば、失敗条件には次のものを含めるようにする。「最初に定義した要求よりもいいアイデアを、最後まで誰も思いつかなかったプロジェクト」
  • 私たちはプロジェクトを、投資、スケジュール、フィーチャそれぞれの観点から定期的に評価したい
  • 最初に決めたフィーチャをすべて提供したプロジェクトが必ずしも成功プロジェクトであるとは限らない
  • プロダクトについての素晴らしいアイデアが、最初に立てた計画にはいっていないからというだけで却下されて、ただ最初の計画に入っていたからという理由でなんの面白みもないアイデアを採用していては、決してプロダクトのユーザーや顧客には満足してもらえないだろう

意思決定を支援する

  • 見積と計画があって、はじめて意思決定を下せる
  • プロジェクトを開始するかどうかの判断以外にも、見積が必要だ。プロジェクトによっては、どういった要因構成が必要かがスケジュールより重要になることがある
  • プロジェクトの計画づくりでの意思決定は、ほとんどがトレードオフの判断だ。どんなプロジェクトでも開発期間とコストのトレードオフを判断しているのかがそのいい例だ

信頼を確立する

  • 約束通りのフィーチャを、安定して頻繁に提供し続けることで、開発者と顧客の間に信頼を培うことができる
  • 信頼できる見積は、信頼できるフィーチャの提供を担保する

情報を伝達する

  • 計画とは期待と可能性を伝達するものである
  • 計画に描かれているのは、プロジェクトがたどることになるかもしれない1つの道筋だ。計画とは、リストにあるフィーチャを寸分違わず、厳格な期日に、正確なコストで提供することを確約するためのものではない。計画は、プロジェクトへの期待を共有する基盤として使うものだ。にもかかわらず、計画が、リリース期日だけに落とし込まれてしまうことがあまりにも多すぎる

良い計画とはなにか?

  • 良い計画とは、ステークホルダーが信頼できる計画だ。信頼できるとは、その計画を基にして意思決定出来るという意味である
  • 何をもって信頼できる計画とするかは状況によって異なる
  • 社内の他の部署は、あなたがつくった計画を元に様々な決定を下す。マーケティングの準備や広告キャンペーンのスケジュール、大口顧客向けアップグレードサポート要因の確保などである。あなたの計画は実に有用だ。少なくともプロジェクトの実際の経過を予想できる限りは役に立つ。これがもしも、6ヶ月の予定だった開発に、実際には12ヶ月かかってしまったらどうだろうか。あなたの計画は、まずい計画ということになる。では、6ヶ月の予定だったプロジェクトが7ヶ月で終わったとしたらどうだろうか。それでもあなたの計画は有用だったと言える。たしかに計画は不正確だったし、時期を若干誤った決定をさせてしまった。だが、6ヶ月後のリリース予定から1ヶ月遅れたという程度なら、大惨事というほどではない。予算見積りにおけるPMIの誤差範囲にも収まるはずだ。あなたの計画が不正確だったにもかかわらず、それでもなお役に立ったといえるのは、プロジェクトの進行中にも計画を定期的に更新していた場合だ。定期的に計画を更新していたなら、最後の最後になってはじめて、プロジェクトが1ヶ月遅れることを知ることになる不幸な人はいないはずだからだ。

アジャイルな「計画づくり」とは?

  • 本書で扱うのはアジャイルな「計画づくり(planning)」だ。アジャイルな「計画(plan)」ではない
  • 計画づくりは「活動」である。アジャイルな計画づくりで重視するのは、計画よりも、計画をつくる過程そのものなのだ
  • プロジェクトの途中で新しい知識を得たら、それをもとに計画を見直すのだ。「変更されてもかまわない」というだけでなく、むしろ「積極的に変更したい」と思うのがアジャイルな計画である
  • 変更そのものに価値があるわけではない。私たちが変更に積極的になるのはなぜかというと、変更が起きるということはすなわち、なにか学習したり過ちに気づいたりしたことを意味するからだ
  • 上で述べたような色々なことを発見したら、計画に反映すべきだ。そのためには、計画が簡単に変更できるようになっている必要がある。計画よりも計画づくりが重要なのはこのためだ
  • 縦は計画はじきに見直され、破棄されてしまう。しかし、計画づくりの過程で得た知識や洞察はずっと後まで残る
  • 私たちは、プロジェクトの初期段階で全体の計画を詳細にわたって定義するのは不可能だという立場をとっている。それならば、プロジェクトの着手段階ですべてを計画すべきではない。アジャイルな計画づくりとは、プロジェクトの全期間に均等に分散させて行うものだ。リリースプランニングが土台となり、これに基づいて複数のイテレーションプランニングがおこなわれる。このプロセスがプロジェクト全体を通じて何度も繰り返される
  • つまりアジャイルな計画づくりを定義すると次のようになる
    • 計画よりも計画づくりを重視する
    • 変化を促進する
    • 計画そのものは容易に変更できる
    • プロジェクト全体にわたって繰り返される

まとめ

  • 見積よりも計画づくりも極めて重要なのだが、難しく、そして誤りやすい。見積や計画づくりが難しいからといって避けて通ることは許されない。
  • プロジェクトの初期段階では不正確な見積しかできないが、プロジェクトが進むにつれて正確に見積もれるようになる
  • こうして見積が徐々に調整されて行く様子を示しているのが、不確実性コーンである
  • 計画作りの目的は、プロダクトの開発においてもっとも重要な質問、すなわち「なにをつくるべきか?」という問に答えることだ。この質問への回答には、フィーチャ、リソース、スケジュールが盛り込まれる。この回答に説得力を持たせるのが計画づくりである
  • 良い計画とは、プロダクトとプロジェクトについての意思決定を行う根拠として信頼できるものである
  • アジャイルな計画づくりで大事なのは出来上がった計画よりも、計画を立てるという活動そのものだ
  • アジャイルな計画づくりは変化を促進する
  • アジャイルな計画づくりでは、立てた計画を容易に変更できる
  • アジャイルな計画づくりはプロジェクトのはじめから終わりまで何度も繰り返される

個人的感想

アジャイルな見積りと計画づくりは素晴らしい書籍だと感じます。以前、こちらのエントリーを書いたときに、ブックマークで指摘され書籍がずばり書いてあったので読み始めました。kakutaniさんに感謝しています。具体的にどのように落としこむかまではまだ考えていませんが、それは書籍の後半になるにつれ、具体的な手法が書かれているので、それを読んでから考えようと思います。そういえば、Google グループというページを見つけました。このように読書会を開いて、みんなで話し合うプロセスいいなーと感じました。アジャイルな見積と計画づくりの読書会やるとすると、東京でやる人いますかね?