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

もし「む、この機能が必要かもしれないけど、これを追加すると言われた期日に間に合わないな・・・オーナーにはリリースまで黙っておこう・・要求にはないし」こういったことを、プログラマがしていると、いつまでたってもアジャイルなチームにならない。アジャイルチームで必要のは、「顧客が満足する本当の価値を提供する」ことであって「言われた期日」ではない。もちろん、「期日」も価値の内だが、バランスが大切なのと、顧客とのコミュニケーションをしっかりと取ることが重要だ。何か新しいことを発見したら、チームやプロダクトオーナー、顧客に共有して価値の探索をしよう。顧客やプロダクトオーナーとまったくコミュニケーションをとらないようではいけない、一丸となって一緒の方向を向こう。本当の価値を追い求めて、コミュニケーションをとっていき、定期的に成果を出すことで、信頼もどんどん厚くなっていくだろう。

目次

アジャイル手法

  • アジャイルのムーブメントは公式には2001年2月のアジャイルマニュフェストに始まるとされている。実際にはその何年も前に始まっていたのだが。
  • アジャイルマニュフェストでは次のものに価値を置くと宣言している
    • プロセスやツールよりも、人と人との交流を
    • 包括的なドキュメントよりも、動作するソフトウエアを
    • 契約上の交渉よりも、顧客との協調を
    • 計画に従うよりも、変化に適応することを
  • すぐれたソフトウエアはすぐれた人々によって作られる。それなのに、この業界は随分と長い間、人々を交換可能な歯車として扱う開発プロセスを模索し続けている。そして、その結果はほとんど上がっていない
  • アジャイルプロセスは人間一人一人の持つ強み(と弱み)を認め、それを活用する。誰でも同じ仕事ができるようにしようとするプロセスとは対照的である
  • アジャイルチームは、包括的なドキュメントよりも動作するソフトウエアを重視する。なぜなら、イテレーション単位で少しずつ、インクリメンタルにフィーチャを追加しながら、安定して動作するプロダクトを提供できるようになるからだ。その結果、早い段階からプロダクトとプロセスの両方がフィードバックを受けられるようになる
  • ユーザーからのフィードバックを開発プロセスに反映させていくことで、チームは常に高いフィーチャを開発できるようになり、ユーザーの期待にも応えられるようになる
  • アジャイルチームは契約上の交渉よりもユーザとの協調に価値を置く。これはプロジェクトのすべての関係者の間でゴールを共有し、そこを目指して一丸となるためだ。契約上の交渉のせいで、開発チームとプロジェクトの顧客とが対立した状態でプロジェクトを始めてしまうことがある
  • アジャイルチームは、あらかじめ決められた計画に従うことよりも、起きた変化に対応することに価値を置く。なぜなら、チームが最終的に達成したいと望むのはプロジェクトの顧客とユーザーに最大限の価値を提供することだかだ
  • とても単純なプロジェクト以外では、ユーザーが必要とするあらゆるフィーチャを完全かつ詳細に把握することは不可能だ。ユーザーが新しいアイデアを思いつくこともあれば、今日は優先順位が高いと思っていたフィーチャが、明日にはそうでなくなっていることもある。こうした変化を避けることは出来ない
  • 未来には複数の未来が存在しうるのだ
  • チームは、プロジェクトが進むとともに蓄えた知識と経験を、計画にも反映する

プロジェクトへのアジャイルなアプローチ

  • アジャイルチームの基本的な仕事の進め方を見ていく。説明するのは次の5つだ

1つのチームとして働く

  • プロジェクトを成功させるために欠かせないのが、すべてのプロジェクト参加者が、共通のゴールを持った1つのチームに参加しているという意識を持つことだ。アジャイルプロジェクトに「壁越しに放り投げる」という発想はない
  • 成功するアジャイルチームには「全員が一丸となって取り組む」という考えが必須である
  • アジャイルが1つのチームとして団結したとしても、チーム内の役割分担は必要だ
  • 役割は「プロダクトオーナー」「顧客」「ユーザー」「開発者」「プロジェクトマネージャ」である
  • プロダクトオーナーの責務
    • なによりもまず、チームの全員がプロジェクトのビジョンを共有し、そこを目指せるようにすることだ
    • 優先順位づけもプロダクトオーナーの責務だ。もっとも価値の高いフィーチャを開発するようにするためである
    • 最終的な意思決定を下す責務もプロダクトオーナーにある。プロジェクトへの投資が良い結果を生むようにするのである
    • 商用のソフトウエア開発では、マーケティングプロダクトマネジメントの担当者がプロダクトオーナーになることが多い
    • 組織内部で利用するソフトウエアの場合には、ユーザーの代表や、ユーザー側のマネージャ、アナリスト、プロジェクトの予算を握っている人物などがプロダクトオーナーになる
  • 顧客
    • 顧客の役割を担うのは、プロジェクトの予算を確保した人物か、ソフトウエアを調達する意思決定をした人物である
    • 組織内で利用するソフトウエアの開発なら、顧客は他の組織や部署の代表になるだろう。そうしたプロジェクトではプロダクトオーナーと顧客の役割は1つになることも多い
    • 商用のソフトウエアなら、ソフトウエアを購入したり調達したりする人物が顧客である。どちらの場合でも、顧客がソフトウエアのユーザーであることも、そうでないこともある
  • ユーザー
    • ソフトウエアを使う人
  • 開発者
    • この言葉が指すのは、ソフトウエアを開発するすべての人のことだ。プログラマ、テスター、アナリスト、データベースエンジニア、ユーザビリティエキスパート、テクニカルライター、アーキテクト、デザイナーなどである
    • この定義に従えば、多くのプロジェクトではプロダクトオーナーも開発者になるだろう
  • プロジェクトマネージャ
    • アジャイルなプロジェクトマネージャはマネジメントよりも、リーダーシップを重視する
    • アジャイルプロジェクトのなかには、プロジェクトマネージャの役割を担う人物が、同時に他の役割を担っていることもある。よくあるのはプロジェクトマネージャかつ開発者というものだが、プロダクトオーナー兼プロジェクトマネージャという場合もある

短いイテレーションで作業する

  • アジャイルプロジェクトでは、プロジェクトを全体をフェーズに分割しない。要件定義フェーズの次の分析フェーズで、その後にアーキテクト設計フェーズ、といったフェーズ分けは、アジャイルプロジェクトにはない
  • 採用する(あるいは自分たちで定義する)アジャイルプロセスによっては、プロジェクトの開発時点にごく短期間の設計フェーズやモデリングフェーズを設けることがあるかもしれない。しかし、1回のイテレーションの中ですべての作業(分析、設計、コーディング、テストなど)が発生しそれを繰り返していくようになる
  • イテレーションはタイムボックスである
  • タイムボックスとは、期日が来たらイテレーションを必ず終了させるという意味だ。実装するはずだったフィーチャを削ってでも期日を守る。それがタイムボックスの考え方だ
  • タイムボックスは非常に短いのが普通だ
  • イテレーションの長さは2週間〜4週間だが、最長3ヶ月のイテレーションを採用しているところもある
  • イテレーションの長さは固定されていることが多いが、各イテレーションの開始時にイテレーションの長さを決めるチームもある

イテレーションごとに成果をあげる

  • イテレーションの長さよりも重要なことがある。それは、1回のイテレーションが終わるまでに、チームはイテレーション開発時点では明確には定義できない要求を、少なくとも1つはコーディングしてテストを行ない、リリース可能なソフトウエアとして統合することだ。もちろん、イテレーションごとに成果を毎回毎回、実際にユーザーへ提供するチームはほとんどない。重要なのは、いつでも提供できるという点だ
  • 確かにチームはイテレーションごとい小さなフィーチャを追加していくことで、着実に前進していることを示せる。だが、それだけでは十分ではない。追加したあらゆるフィーチャは、コーディングされているのはもちろんのことだが、テストされた状態で、リリース可能な品質に達していなければならないのだ
  • イテレーションの終了時点で、プロダクトがリリース可能な状態になっていることが、極めて重要なのだ
  • 「リリース可能」だからといって、リリースに必要なすべての作業を実際におこなうわけではない。イテレーションのたびにリリースするわけではないからだ
  • 1回のイテレーションで、ユーザーや顧客が満足できるようなひとまとまりのフィーチャを実装できることはまずない。そこで、より大きな単位としてリリース概念を導入する
  • リリースは、関連するひとまとまりのフィーチャを完成させるだけの長さが必要なので、複数のイテレーションで構成される
  • 一般的な1回のイテレーションの長さは2週間〜4週間だが、1回のリリースは2ヶ月から6ヶ月であることが多い

ビジネス上の優先順位を重視する

  • アジャイルチームは2つのやり方で、ビジネス上の優先度を大切にしながら開発を進める
  • 1つ目
    • プロダクトオーナーが指定した順序通りにフィーチャを提供すること
  • 2つ目
    • アジャイルチームがユーザーにとって価値のあるフィーチャを実装し、提供することに注力すること
  • ユーザーにとって価値のあるフィーチャを単位とするための最善の方法の1つが、ユーザーストーリーだ
  • ユーザーストーリー
    • システムについてユーザーまたは顧客の視点からフィーチャの概要を記述したものだ
    • ユーザーストーリーには形式が定められておらず、標準的な記法もない。とはいえ、次のような形式でストーリーを考えてみると便利である「<ユーザーの種類>として、<機能や性能>がほしい。それは<ビジネス価値>のためだ」という形式に従うと、たとえば次のようなストーリーを書ける。「本の購入者として、ISBNで本を検索したい。それは探している本をすばやく見つけるためだ」
    • ユーザーストーリーがなぜ軽量かというと、要求の収集と記述を開発に先立って完了させておく必要がないからだ。アジャイルチームは、長大な要求仕様書を書く事よりも、必要になったその時、つまりジャストインタイムに要求を扱うアプローチを好む
    • それぞれのユーザーストーリーについて、開発者とプロダクトオーナーは必要なだけ会話を重ねる。

検査と適応

  • プロジェクトの開始時点に立てた計画は、実際のプロジェクトで何が起きるかを保証するものではない。いってしまえば、計画を立てた時点での推測に過ぎないのだ。いろいろな事柄が計画を無効にしてしまおうと待ち構えている
  • イテレーションを開始するときには、直前のイテレーションで得た知識を元にして、新たな状況へと適応する
  • 得られた知識が計画の正確さや価値に影響をあたえるなら、計画を調整する
  • 計画の正確さに影響を与える知識
    • たとえばチームが当初の想定ほど早く開発できないことがわかった場合だ。逆に、想定より早く開発できることがわかった場合も計画に影響がでるだろう
  • 計画の価値が変わるとき
    • プロダクトオーナーがユーザーの要望について新しい知識を得たときなど
  • 勘違いしないでほしいのは、アジャイルチームが「優先度は場当たり的に変えていい」と考えているわけではない点だ。優先度はイテレーションをまたいでもあまり変わるものではない。それでも、新しいイテレーションの開始時に優先度を変える機会を設けることには意義がある。プロジェクトへの投資から最大のリターンを得るうえでは極めて有用なのだ

アジャイルな計画づくり

  • マッコーマーによれば、プロジェクトというものを定められた一連の手順を実行するだけだと考えるべきではない。むしろ、プロジェクトとは、新たな機能と知識を迅速かつ安定して生み出し続ける活動と捉えるべきなのだ
  • アジャイルプロジェクトでは、生み出され続ける機能と知識の流れが、仕事を進めていく指針となる
  • プロダクトについて新しい知識(プロダクトナレッジ)が得られると、プロダクトがどうあるべきなのかをより深く考えられる
  • プロジェクトについて新しい知識(プロジェクトナレッジ)とは、チームや採用している技術、リスクに関する情報のことである
  • 私たちはこうした新しい知識を得ることを計画に組み入れ忘れてしまうことが多い。新しい知識の獲得を計画に組み入れないということは、計画を立てる時点で計画づくりに必要な知識をすべて持っているとみなしているということだ。しかし、ソフトウエア開発の世界では、最初に計画を立てた時点で必要な知識がすべて揃っていることはまず有り得ない
  • つまり、アジャイルプロジェクトではいつ完了するかはわかっているが、何を提供するかはわかっていないということだ。最終成果がどのようなものになるかを、事前に知ることができないと認めれば、計画づくりを、長期的な目標に達成するための適切なゴール設定と、その見直しのプロセスだと位置づけられる

複数のレベルでの計画づくり

  • 計画づくりでゴールの設定と見直しを行うにあたっては、2つの明確な事実を忘れてはならない
    • 1つは、水平線の向こうを見ることが出来ないということ
    • もう1つは、見えない範囲の計画を立てようとしても、著しく正確さに欠けるということ
  • 目に見える範囲を大きく超えて計画を立てているにも関わらず、計画を見直す時間を組み込んでいないのであれば、そのプロジェクトは危険にさらされていることになる。計画には段階的な詳細化が不可欠である。アジャイルチームはこの問題に対する対策がある。それは、3つの「水平線」を基準に計画を立てることだ。3つの水平線とは、リリース、イテレーション、「今日」である。
  • 計画づくりは、これら3つ(とさらにいくつか)の水平線を含んだタマネギ状になる(プランニング・オニオン)


  • アジャイルチームは少なくとも、リリース、イテレーション、そして「今日」のレベルで計画を立てる
  • ほとんどアジャイルチームの計画づくりで対象とするのは、タマネギの内側の3つだけである
  • リリースプランニング
    • リリースプランニングのゴールは、プロジェクトのスコープ、スケジュール、リソースについて回答を出すことである
    • リリースプランニングでは、新しいプロダクトやシステムのリリースに向けた、ユーザーストーリーやテーマを検討する
    • リリースプランニングはプロジェクトの開始時におこなうが、そこで完結する単発の作業ではない
    • 良いリリース計画とは、プロジェクトの期間を通じて(通常はイテレーションの最初に)、更新されるものだ。こうしておけば、次のリリースになにを含めるかということについて、常に最新の状況を反映させられる
  • イテレーションプランニング
    • イテレーションプランニングは、イテレーションの開始時におこなう計画づくりのことだ
    • 直前のイテレーションで達成した内容に応じて、プロダクトオーナーは新しいイテレーションで達成すべき、優先度の高い作業を決定する
    • ここではリリースプランニングよりも近い水平線を見ている。よって、イテレーション計画の内容はリリースプランニングより細かくなり、タスクが対象となる
    • イテレーションプランニングでは、フィーチャに対する要求を動作するテスト済みソフトウエアとして実現させるためのタスクを検討する
  • 「今日」のプランニング
    • ほとんどのアジャイルチームは何らかの形で日々スタンドアップミーティングを実施しており、作業の調整と同期化をおこなっている
    • チームはこの場で確かに計画をつくり、評価し、見直しているのだ
    • 「今日」の計画づくりの水平線は、長くても翌日、すなわち次回のスタンドップミーティングまでの範囲だ
    • こうすることで、計画の焦点をタスクに絞り、どうやってタスクを完了させるかという視点から個々人の作業を調整も考えることになる
  • アジャイルチームは計画を3つの水平線 ― リリース、イテレーション、今日という複数のレベルに分けることで、レベルごとで対象にしちえるものに焦点を絞った計画づくりを行う
  • アジャイルチームが直接か携わる計画づくりから外れる(ということは、本書の対象範囲からも外れるわけだが)計画づくりには、プロダクト、ポートフォリオ、戦略といったレベルが存在する
  • プロダクトプランニングはプロダクトオーナーによる計画である
  • ポートフォリオプランニングは、組織のビジョンを実現するのに最適なプロダクトの取捨選択についての計画である。組織のビジョンを確立させるのが、戦略プランニングである

満足条件

  • プロジェクトには達成すべき目標があり、しかもそれは1つではない。世界最高のワープロを開発しようとしているかもしれな。しかしそれは目標の1つでしかない。これ以外にも、スケジュールや予算、品質といった面での達成目標があるはずだ。こうした達成目標は、顧客やプロダクトオーナーの満足条件と考えられる。すなわち、プロジェクトの成功を測定するための基準である
  • リリースプランニングは、チームとプロダクトオーナーとが協力しながらプロダクトオーナーの満足条件を探っていくことから始まる。スコープやスケジュール、予算に品質といったプロジェクトによくある項目はすべて満足条件の対象である。とはいえ、アジャイルチームは品質については譲歩できないと考えていることが多い。チームとプロダクトオーナーとで、すべての満足条件を満たす方法を見付け出していく
  • 一方、プロダクトオーナーの満足条件をすべて満たせない場合もある。実現可能な解決策を見つけられないなら、満足条件を変えなければならない。リリースプランニングと満足条件の探索とを何度も繰り返す理由はここにある
  • 1回のイテレーションにおけるプロダクトオーナーの満足条件は、フィーチャとそのテストとして表現される
  • リリースプランニングと同様に、イテレーションプランニングも何度も繰り返される。プロダクトオーナーとチームは、イテレーションのすべての満足条件を満たす方法をめぐって議論を重ねるのである
  • 満足条件がリリースとイテレーションの計画づくりを駆動する