ディシプリンド・アジャイル・デリバリーの基本モデル「方向付けフェーズ」を理解する

開発構想と初期計画

利害関係者が多岐に渡るときは、プロジェクトの方向性について合意を取り付けることがとても重要です。方向付けフェーズは、ビジネス状況や技術的観点を踏まえて合意を形成することであり、それを明文化するのが開発構想（ビジョン）です。開発構想は、DADの源流とも言える統一プロセス（Unified Process）における要求管理の主要な成果物の一つであり、同じく統一プロセスを源流とするSAFeにも存在しています。開発構想にどんなことを記載するか、DADでのガイドをピックアップしてみます。

• 解決すべきビジネス上の課題
• 重要なフィーチャー
• 利害関係者のリスト
• 制約：予算枠、スケジュール上の制約、技術的選択肢、準拠すべき標準規定の有無等

これらを「しがらみを制御する」という観点で、（やや順不同ですが）個々の項目を考えていきましょう。

利害関係者のリスト

方向付けフェーズで合意された事柄は、構築フェーズ以降に発生するであろうさまざまな変更依頼を扱う際の判断基準となります。そう考えると、合意事項そのものが適切な利害関係者で議論されたものであるか否かが重要であることがわかります。
利害関係者のリストは、投資の意思決定の過程で、適切な部門の適切な関係者が関与していることを確認・宣言するものであり、それをもって合意事項の妥当性・正当性を担保することになります。

注意が必要なのは、利害関係者は単なる「新システムのユーザ候補一覧」ではないという点です。
我々はすでに多くのしがらみ（他部門との協業・競業、相反する利害、政治力の差等々）にさらされています。たとえば以下のようなことが考えられます。

• コンシューマー向けサービスを強化すると、売り上げに大きく貢献してくれている代理店ビジネスに負の影響が及ぶ可能性がある。オンライン販売部門は新システムによるメリットを直接享受する一方で、これまでの稼ぎ頭である代理店ビジネス部門が売り上げを落とすかもしれない
• 内製化率を高めると外注費は削減できるが、相対的に低い技術力のために品質を落とす可能性が高いので、ビジネス的なリスクを生む元凶になる可能性がある。開発部門よりも品質保証部門に負荷がかかる。開発部門の論理が、ビジネス部門に負の影響を与えかねない事態は看過できない。

利害関係者のリストアップとは、問題解決や投資がビジネス面も含めどういう領域にどのような影響を及ぼしうるかを見極める作業という側面があり、方向性を決める上でとても重要なステップなのです。

「解決すべきビジネス上の課題」と「重要なフィーチャー」

「方向付けフェーズ」の話を初めて聞いた人は、ほとんど例外なく「ウォーターフォール型プロセスの要件定義工程と同様のもの」と誤解します。ここで、両者の違いを強調しておきましょう。
ウォーターフォールでの要件定義工程は、システム要件を網羅的かつ詳細に定義します（正確には「定義を試みて挫折します」でしょうか）。一方、アジャイルでの方向付けでは要件（この場合はストーリー）を網羅的かつ詳細に定義することはしません。これはBRUF（Big Requirement Up Front）と呼ばれ、むしろ積極的に避けるべきアンチパターンと考えられています。
またウォーターフォールでは、要件定義工程で要件を確定することが基本です。設計工程からみると、それは実現すべきシステムのあるべき姿の定義であり、ユーザ（発注側の立場）から見ると、それはリリース時点で手に入ることが約束された機能性の契約です。
これに対して方向付けにおける主たる議論は、投資対効果に向けられます。対象となるビジネスの課題やニーズを考え、それらを解決するためにシステムはなにができればいいのか、ハイレベルの機能性（これがフィーチャーです）を関係付けられればいいのです。ですから開発構想も、ターゲットと定めた主要なビジネス上の課題と、それに応える2〜3個程度の主要なフィーチャー（feature）が記述されていれば十分とします。

次回は、アジャイルとしての要件管理としてフィーチャーやストーリーの話に入っていきましょう。