アジャイル開発の要件定義

アジャイル開発の要件定義が目指しているのは、要件を早く正しく「確定」させることよりも、要件を正しく「育てていける状態」を保つことです。市場や業務の前提が動くプロジェクトでは、着手時点で全要件を文書化しても、完成までに陳腐化する部分が出てきます。そこで、変わりにくい全体像と、変わりやすい詳細を切り分けて扱います。

具体的には、プロジェクトの初期にプロダクトの目的、対象ユーザー、達成したい成果の輪郭を関係者で合意します。ここで作るのは分厚い要件定義書ではなく、方向性を示す軽いドキュメントやユーザーストーリーの一覧です。そのうえで、実現したいことをプロダクトバックログに項目として並べ、優先度を付けます。

• 変わりにくいものは早く決める
  プロジェクトのゴール、守るべき制約、全体の予算と期限の枠は初期に合意し、途中でぶらさないようにします。
• 変わりやすいものは後で詰める
  個々の画面仕様や細かな業務ルールは、その機能を作るイテレーションの直前に具体化します。

PMが押さえておきたいのは、この「後で詰める」が無計画の言い換えではない点です。いつ、誰が、どの項目を詰めるのかという段取り自体は、あらかじめ設計しておく必要があります。

要件の具体化は、おおむね決まった登場人物とリズムで進みます。要件の優先度に責任を持つのはプロダクトオーナーで、開発チームが実装し、スクラムで進める場合はスクラムマスターが進行の障害を取り除きます。PMは、これらの役割の外側で、予算・納期・社内外の関係者との調整といったプロジェクト全体の制約を見ます。

一回のイテレーションに沿って見ると、要件は次の順で確定へ向かいます。

1. バックログの整理
   プロダクトオーナーが、項目の優先度を見直し、次に扱うものを上位に並べ替えます。
2. 受け入れ条件の明確化
   各項目について「何ができれば完成とみなすか」を、開発チームと一緒に具体的な条件に落とします。
3. 計画と実装
   チームがそのイテレーションで扱う範囲を選び、実装と確認を進めます。
4. ふりかえり
   うまくいった点と詰まった点を整理し、次の進め方へ反映します。

成果物の中心はプロダクトバックログと、各項目に紐づく受け入れ条件です。ウォーターフォールのように一冊の要件定義書を完成させてから次工程へ渡すのではなく、常に最新の優先順位が見える状態を保ちます。PMは、この成果物が関係者から見て追いやすい状態にあるかを気にかけると、合意が取りやすくなります。

アジャイルの要件定義は、柔軟さがそのまま弱点にもなります。実際のプロジェクトで起きやすいのは、次のような形です。

• 優先順位が決まらない
  関係者が多く、誰の要望を上位に置くかで合意が取れないと、バックログが膨らむだけで前に進みません。優先度の決定者を早い段階ではっきりさせておくと滞りにくくなります。
• 全体像の不在で手戻りが続く
  目先の機能ばかり詰めて、全体の方向性を初期に合意しないまま進むと、後から矛盾が見つかって作り直しが増えます。
• 受け入れ条件が曖昧
  「使いやすくする」のような言葉だけで実装に入ると、完成の判断がぶれます。確認できる条件まで落とすことが欠かせません。

もう一つ注意したいのは、スコープが際限なく広がる状態です。要件を後から足せる仕組みは便利な反面、優先度の見直しをしないまま要望を積み続けると、期限と予算の枠から外れていきます。PMは、新しい要望が入ったときに「何を後回しにするか」をセットで議論する場を保つと、全体のバランスを保ちやすくなります。手戻りをゼロにはできませんが、全体の合意と受け入れ条件の明確化で、その範囲を小さく抑えられます。

両者を比べるときは、いくつかの軸で見ると違いが整理しやすくなります。ここでは「確定のタイミング」「成果物」「変更への向き合い方」の三つで並べます。

• 確定のタイミング
  ウォーターフォールは上流工程で要件をまとめて確定し、承認を経て次工程へ進みます。アジャイルは全体の方向性を先に合意し、詳細は実装の直前に順次確定します。
• 成果物
  ウォーターフォールでは要件定義書が中心的な合意文書になります。アジャイルではプロダクトバックログと受け入れ条件が、常に更新される合意の形を担います。
• 変更への向き合い方
  ウォーターフォールは確定後の変更を変更管理の手続きで慎重に扱います。アジャイルは変更が起きる前提で、優先度の入れ替えとして日常的に受け止めます。

どちらが優れているという話ではなく、プロジェクトの性質で向き不向きが分かれます。要件が安定し、順序だった承認が求められる領域ではウォーターフォールが噛み合いやすく、前提が動きやすく早く試したい領域ではアジャイルが合う場面が多いと考えられます。PMは、両者の考え方を理解したうえで、案件ごとに要件の固め方を選べると、関係者への説明もしやすくなります。

アジャイル開発の要件定義を理解していると、PMとして対応できる案件の幅が広がります。要件が初期に固まる案件だけでなく、前提が動きながら進む案件でも、要件の育て方と合意の保ち方を語れるようになるためです。採用や面談の場では、要件定義書を書いた経験に加えて、優先順位をどう決め、スコープ変更をどう関係者に説明したかまで話せると、進め方を選べる人という印象につながりやすくなります。ウォーターフォールとアジャイルのどちらが上という立場ではなく、案件の性質に応じて固め方を使い分けられること自体が、PMの市場価値を支える要素の一つになると考えられます。まずは担当案件で、要件確定の段取りを言葉にして説明できる状態を目指すところから始めるとよいでしょう。

アジャイル開発では要件定義書は作らないのですか。

作らないわけではなく、形が変わります。一冊にまとめて確定させる代わりに、プロダクトバックログと各項目の受け入れ条件が合意の役割を担います。全体の目的や制約を示す軽い文書は初期に用意することが多く、必要に応じて補足の資料も残します。

要件を後で詰めると、スコープが無制限に広がりませんか。

広がる危険はあります。防ぐ鍵は、新しい要望が入るたびに優先度を見直し、何を後回しにするかをセットで決めることです。期限と予算の枠を初期に合意し、その枠の中で優先順位を入れ替える運用にすると、際限ない拡大を抑えやすくなります。

PMはアジャイルの要件定義でどんな役割を担いますか。

要件の優先度はプロダクトオーナーが持ちますが、PMは予算・納期・社内外の関係者調整といった全体の制約を見ます。要件確定の段取りが滞らないよう場を整え、スコープ変更の影響を関係者に説明する役割が中心になります。