精読「アジャイルサムライ」(第三部 アジャイルな計画づくり)
アジャイルサムライ――達人開発者への道
アジャイル開発を実践するための具体的な方法論と心構えを学べる一冊です。チームで成果を出す秘訣や、迅速かつ柔軟に価値を届けるためのツールや考え方をわかりやすく解説。初心者から経験者まで、アジャイルの本質を知りたいすべての人におすすめのガイドブックです！
関連記事
ユーザーストーリーを集める
文書化の難しさ
文書化はソフトウェア開発において大きな労力を要すが、顧客の真のニーズや意図を正確に伝える手段としては十分に機能しないことが多い。文書は会話を促進せず、むしろ誤解を招きやすい特性がある。
アジャイル開発では、文書に頼りすぎず、会話を重視し、顧客の意図を柔軟に捉えるアプローチが重要だと考える。
そこでユーザーストーリーですよ
ユーザーストーリーは、顧客が実現したい機能を簡潔に記述し、会話を促進するためのツール。詳細を詰めるのではなく、フィーチャの本質を捉えるキーワードだけを記録し、後で必要性が確認された時点で詳細を検討する。
これにより、時間と労力を節約し、変化に柔軟に対応できるようにすることが目的。ユーザーストーリーは「会話の約束」として活用される。
よく書けているユーザーストーリーとは
-
価値がある
- ユーザーストーリーには、顧客が対価を払いたくなるような価値が記載されている必要がある。
- 顧客にわかりやすい言葉で記述し、技術的な表現を避ける(「お客さんに分かってもらえる言葉遣いで表現すること」という意味合いから)
-
エンドツーエンド
- ストーリーは「ケーキを切る」ように、すべてのアーキテクチャ層を貫き、顧客にとって価値のある成果をもたらす形で記述されるべき。
- ストーリー同士はなるべく独立させることで、柔軟なスコープ調整が可能になる。
-
実現手段は柔軟に
- ストーリーはポルシェ級の仕上がりが必要な場合もあれば、フォード級で十分な場合もある。柔軟な交渉ができる余地を残す
-
テスト可能性
- ストーリーはテスト可能であるべきで、完了基準が明確でなければならない。
- ストーリーを小さくすることで、見積もりが容易になり、タイムボックスに収まりやすくなる。
-
良いユーザーストーリーの特徴（INVEST）
| 特徴 | 説明 | 例 |
|---|---|---|
| I (Independent) | 他のユーザーストーリーに依存せず、独立して実装・テストできる。 | 「ログイン機能の実装」→「パスワードリセット機能の実装」は独立している。 |
| N (Negotiable) | 要件が曖昧で、詳細を話し合いながら決められる。 | 「ユーザー登録機能」を作成するが、詳細なUIや仕様はチームで議論して決める。 |
| V (Valuable) | ユーザーやビジネスにとって価値がある機能や結果を提供する。 | 「管理者がユーザーを検索できる機能」→ これにより管理者が効率的にユーザー管理ができるようになる。 |
| E (Estimable) | ストーリーの実現にかかる努力を見積もれる程度に具体的である。 | 「注文履歴機能を表示する」→ どのデータを表示し、どのUIコンポーネントを使うかが明確になっている。 |
| S (Small) | 実装が小さく、短期間で完了できるように分割されている。 | 「商品詳細ページの表示」→ より具体的に「画像、価格、説明を表示する」など小さく分けられる。 |
| T (Testable) | 成果物が明確で、テスト可能な基準が存在する。 | 「ユーザーがログインできる」→ 成功と失敗のケースをテストする基準（正しいユーザー名/パスワード）を決める。 |
-
ユーザーストーリーテンプレート
- ユーザーストーリーを「誰が」「何を」「なぜ」の観点で記述するテンプレートを活用すると、ビジネスの視点が明確になる。
- 簡潔な表現と詳細な記述を状況に応じて使い分ける。
ストーリー収集ワークショップを開催しよう
ストーリー収集ワークショップは、顧客と開発チームが一緒に、ソフトウェアで実現したい機能（フィーチャ）を洗い出す作業。このワークショップの目的は、幅広いフィーチャを集めることで、システムの全体像をつかむこと。
具体的には、以下のステップを踏む。
-
大きくて見通しの良い部屋を用意する
立ったり歩き回ったりできる広い部屋を準備し、図やカードを使った作業に適した環境を整える。 -
図をたくさん描く
ペルソナやフローチャート、シナリオなどを使ってアイデアを視覚的に表現し、システム全体の理解を深める。詳細には立ち入らず、粗い粒度で幅広くフィーチャを捉える。 -
ユーザーストーリーをたくさん書く
図をもとに、具体的なユーザーストーリーを抽出。小さく、エンドツーエンドの機能に分割し、1～5日で実装できるサイズにする。大きなストーリーは「エピック」として扱い、後で分割する。 -
その他の要素もブレインストーミング
ソフトウェアに直接関係ないがプロジェクトに必要な作業（データ移行、負荷テストなど）も洗い出し、優先順位をつけてカードに記録。 -
リストを磨き上げる
作成したストーリーリストを確認し、重複や漏れがないか、グループ分けできるかを検討。顧客にとって分かりやすいToDoリストになるように整える。
見積もり：当てずっぽうの奥義
アジャイルな見積りプロセスでは、初期見積もりは精度が低く、実際にはあまり意味がないことを認識する必要がある。アジャイル手法では、精密な事前見積りに頼るのではなく、顧客と一緒に信頼できる計画を立てることが重要
概算見積りの問題
ソフトウェアプロジェクトの見積りは、正確な予測を目指すのではなく、プロジェクトが現実的に達成可能かどうかを判断するために行うもの。概算見積りは初期段階では不確実性が大きく、しばしば誤差が大きくなるため、正確に予測することは無理。
不確実性コーンより
見積りは当てずっぽうであり、プロジェクトを進める際にはそれを踏まえた上で、計画を立てることが重要。
ピンチをチャンスに
アジャイル開発では、初期段階の概算見積りを信用せず、予算や成果の見通しを立てるために相対的な見積もり手法を使用する。
具体的には、ストーリーの大きさを他のストーリーと比較して相対的に見積もり、進捗を「ポイント」を使って追跡する。相対見積もりでは、タスクの大きさを絶対的にではなく、他のタスクとの比較で測る。この方法は、見積もりの精度にこだわらず、チームの作業速度（ベロシティ） に基づいて計画を立てることができる。
「ポイント」で見積もることで、見積もり結果が大きさの相対的な違いを表現し、精密さに対する錯覚を避けることができる。この方法は、見積もりをシンプルかつ迅速に行い、現実の作業に即した進捗管理を可能にする。
見積り技法
-
三角測量
- 基準となるストーリーを選び、他のストーリーをその相対的なサイズで見積もる方法。
- 代表的なストーリー（小・中・大など）を選び、残りのストーリーをその基準と比較して見積もる。
- 実際に実装を始めてみると、見積もりの再調整が必要になることがあるが、相対的なサイズでの見積もりを維持する方が計画作成をスムーズにする。
-
スパイク
- 見積もりが困難なストーリーには「スパイク」を実施。短期間(長くても数日以内)で調査し、見積もりの参考情報を得る。
-
プランニングポーカー
- 開発チーム全員が自分で見積もり、数値をカードで示す。その後、見積もりに食い違いがあれば話し合い、再見積もりを繰り返してチームの合意を得る。
- チームメンバー全員（プログラマ以外も参加）が参加し、意見交換をすることでより正確な見積もりができる。
- プランニングポーカーは投票ではなく、意見交換を通じて適切な見積もりを行うことが目的。
見積もりは可能な限り正確であるべきだが、アジャイル開発では完璧な精度を求めることは現実的ではない。相対的な大きさでの見積もりを行い、その結果を基に計画を立て、チームの進捗を測ることが重要。
アジャイルな計画づくり：現実と向き合う
固定された計画の問題
固定された計画は、要件変更やメンバー離脱、期日の前倒しなどで破綻しがち。これに対処するには、次の基準を満たすアジャイルな計画が必要です
- 価値を提供
- 誠実さ
- 約束を守る
- 柔軟性
アジャイルな計画づくり
アジャイルな計画づくりは、チームの「ベロシティ」を計測し、それを基にプロジェクト完了時期を見通す手法。プロジェクト完了までのイテレーション数は、総作業量 ÷ ベロシティ で見積もる。
初期計画はあくまで仮定であり、進捗に応じて計画やスコープを柔軟に調整することが重要。
スコープを柔軟に
アジャイルプロジェクトでは、スコープを柔軟に保つことが重要
-
新しい要求の追加時
既存のストーリーを削るルールを徹底し、スコープを管理。顧客にも柔軟な計画の重要性を理解してもらう。 -
計画変更時の対応
期日を延ばすかスコープを調整するかを選択。アジャイルでは後者を優先する。 -
現実との向き合い
無理な計画は隠さず、事実を顧客と共有し解決を図る。
アジャイルでは固定計画にこだわらず、現実的かつ誠実な計画を維持することが成功の鍵。
初回の計画づくり
初回の計画づくりの5つのステップ
-
マスターストーリーリストの作成
- 顧客が実現したい内容をリストアップ。
- 顧客が優先順位をつけ、チームが見積もる。
- 1～6ヶ月程度で完了可能な範囲に収める。
- 優先的に「市場価値が高く」「最少の機能セット（MMF）」を含むリリースを定義する。
-
プロジェクト規模の見極め
- ストーリーサイズを見積もり、プロジェクトの全体期間（例: 3ヶ月～9ヶ月）を予測。
- リスク削減や価値の高いストーリーを早期に着手する。
-
優先順位付け
- 顧客がビジネス観点で優先順位を設定。
- アーキテクチャ上のリスクやエンドツーエンドで確認が必要なストーリーは、チームが提案して早めに実施。
-
チームのベロシティ見積もり
- 過去の成果やチームの状況を考慮し、ベロシティ（完了したストーリーポイントの平均）を推測。
- 最初は控えめな目標を設定し、イテレーションを重ねて精度を高める。
-
期日の仮決定
- 期日固定型：期日を優先し、スコープを調整。
- フィーチャセット固定型：重要な機能セットを優先し、期日を調整。
- どちらの方法でもスコープの柔軟性を確保。
補足
- バーンダウンチャートを使い、進捗を視覚化し期待を管理。
- 「完了の定義」を明確にし、すべての作業（分析、設計、テスト、コーディング）を含める。
これにより、計画は顧客価値を最大化しつつ、現実的な見通しを持つものとなる。
バーンダウンチャート
バーンダウンチャート
バーンダウンチャートは、プロジェクトの進捗を可視化するためのツールで、以下を明確に示す
- 完了した作業量
- 残作業量
- チームのベロシティ（作業速度）
- 完了見込み時期
縦軸に残作業量（ポイントや作業日数）、横軸に時間（イテレーション） を取り、進捗をプロットしていく。理想的には一定の速度で進むはずですが、現実にはスコープの変動やベロシティの変化が反映され、プロジェクト状況の可視化やステークホルダーとの調整の材料になる。
バーンアップチャート
バーンアップチャートは、完了した作業量を積み上げる形で表す点が異なり、スコープの変動をより明確に可視化する。バーンダウンチャートとバーンアップチャートを組み合わせて使うことで、完了作業と残作業の両方を追跡することも可能。
選択のポイント
どちらを使うかは好みや状況に応じて選ぶが、大切なのは簡潔かつ視覚的にプロジェクトの進行状況を管理し、期待値を調整すること。
プロジェクトを途中からアジャイルにしていく
プロジェクトを途中からアジャイルに移行する方法
途中からアジャイルを導入する状況は、以下のようなケースが考えられる
- 現在の開発がうまくいっていない
- 早急に成果を求められている
-
インセプションデッキの活用
チームの方向性に課題がある場合、以下の質問に答えられるようにしてチームの目的を揃える
- なぜこのプロジェクトに取り組んでいるのか？
- 何を成し遂げようとしているのか？
- 顧客は誰か？
- 解決すべき主要な課題は何か？
- 最終判断を下すのは誰か？
答えが曖昧な場合、インセプションデッキを使い直すと効果的。
-
計画の見直し
従来の計画を捨て、新たに信頼できるアジャイル計画を立て直す
- マスターストーリーリストを作成
- ストーリーの規模を見極めて優先順位を設定
- 最小限の機能（MVP）を完成させ、顧客に提供
-
価値ある成果を定期的に提供
当初の計画を変えられない場合でも、毎週1つか2つの価値ある成果を必ず完了させ、顧客に信頼を示す。これにより状況が好転し、計画を立て直す土壌を築ける -
進行中の計画の更新と信頼の確保
- リリース可能な実装を届け続ける
- 計画をプロジェクト進行に応じて更新
- 障害を素早く察知して取り除く
これらのアプローチにより、途中からでもアジャイルな開発を実現できる。
現場で実践する
アジャイル開発を実践するための具体的なシナリオを通じて、計画やスコープ、チーム、期限といった変化にどう対処するかを学ぶ
-
シナリオ1: お客さんが新しい要求を発見した場合
- 新しい要求についてお客さんと対話し、スコープ変更や期日の延長など、選択肢を提示。
- 「あるといいな（Nice-to-have）」リストを活用して、優先順位を明確化。
- 冷静で中立的な立場を保ちつつ、選択がプロジェクトに与える影響を伝える。
-
シナリオ2: 思ったほど速く進んでいない場合
- チームのベロシティが期待以下でも慌てず、進捗を基に計画を調整。
- スコープを柔軟に保つ重要性を強調。
- 悪いニュースは早めに共有し、事実に基づいてお客さんと選択肢を話し合う。
-
シナリオ3: 大切なチームメンバーがいなくなった場合
- メンバーの喪失がプロジェクトに与える影響を、可能であればベロシティの低下として計測。
- 具体的な影響を報告しつつ、チーム再編の現実的な対応策を検討。
- 新規メンバーの即戦力化に過度な期待を抱かず、懐疑的な態度で進める。
-
シナリオ4: 時間が足りなくなった場合
- 最小限のスコープに絞り込む（スパルタ式の実装）。
- お客さんと協力し、省ける要素を一緒に探す。
- 双方向で正直な対話を行い、最適な計画を再調整。
-
なにもかも固定されたプロジェクトの場合
- 「変化を見える化」することで、計画修正の必要性を認識させる。
- パーキングロットチャートを用い、スコープ外のストーリーを可視化。
- 固定条件を尊重しつつ、現実的な対処を模索する。
アジャイル開発の本質は、変化を管理し、柔軟に対応する能力にある。どのシナリオでもお客さんやチームと率直にコミュニケーションをとり、変化を受け入れる姿勢を大切にすることが重要
参考
Discussion