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

前回はディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery、以下DAD）における時間軸の捉え方としてのフェーズという概念と、その前段階で行う「プロジェクト・オリエンテーション（DADで定義されているわけではありませんが）」に言及しました。記事公開後に、プロジェクト・オリエンテーションとアジャイル技法の説明の違いについて質問を受けたので、少しだけ補足しておきます。

当然のことですが、一般的なアジャイルの説明はアジャイルそのものを理解してもらうことを主眼にします。「アジャイル・マニフェストをひも解きながら、アジャイルの魂を説明」したり、順を追って作業の流れを説明したりします。直感的にイメージしてもらうために、ウォーターフォール型プロセス（の一般的な形）と比較する形で説明することもあるでしょう。でもこんな質問が出ることはありませんか？　「うちは、4週間ごとにリリースしないんだけど」みたいな……

どんなビジネスモデルなのか、またどんな課題が存在するのかという事情は、プロジェクトごとに異なります。その一方でアジャイル開発そのものも、さまざまなテクニックを取り入れて発展し続けています。その結果、個別の事情に合わせてさまざまな期待値が持たれることになります。たとえば、目の前のプロジェクトが基幹系システムとの連携を前提としている、つまり統合リスクが高いようなケースでは、「小規模な統合を頻繁に行うことで、技術的なリスクに事前に対処できる」ことのほうが、「ユーザからの頻繁なフィードバックを得る」ことよりも重要とみなされるでしょう。

一般的なアジャイルの説明が「アジャイルで実現できること」をカタログ的に見せるものだとすると、オリエンテーションは「今回のケースではこんなことが期待できそうだ」という点に絞ることで、アジャイルに対して持っているかもしれない誤解を解き、期待値を整理するのが目的です。残念ながら今でも、アジャイル開発に対して「早くて安い丸投げ開発手法」というイメージを持たれている方にはよくお会いします。しかも、プロジェクトに対してそれ相応の権限を持った管理職の皆さんに多かったりするので、そういう方々が抱きがちな過剰な期待や誤解を早めに解いておこうということです。

では、プロジェクトの初期情報をHP Agile Manager（以下、AGM）に設定しながら、方向付けフェーズに話を進めていきましょう。

Agile Managerに初期状態を作ろう

AGMの評価版はインストールしていただいたでしょうか？ここでは、実際のAGM上にプロジェクトの情報をいくつか設定していきましょう。基本的な流れは次のようになります。

ツールとしてのAGMの概念や設定の手順については、弊社のブログで解説しています。上記の手順1〜3の詳細については、こちらをご覧ください。設定する内容としては、次のモノとしましょう。

• ワークスペース
  評価版には、デフォルトで［標準設定］というワークスペースが用意されていると思います。それを使ってもいいですし、追加してお好きな名前にしていただいても構いません。サイトユーザの一覧のところで、各ユーザに利用できるワークスペースを関連付ける必要がありますので、関連付けを忘れないようにしてください。
• アプリケーション
  お使いになるワークスペースに、アプリケーションを登録しましょう。とは言っても、［名前］と［説明文］だけでよいのですが。ちなみにこの連載では、インターネット上のショッピングモールをイメージしたアプリケーションをサンプルとして考えます。
• リリース：これは次のように設定してみましょう。
  開始日：本稿を読みつつ、皆さんが設定された日を開始日にしておきましょう。
  終了日：2015年3月末なんて、いかにも日本的な年度区切りで、よろしいのではないでしょうか？
  スプリント期間：ここは王道の4週間にしておきましょう。
  開始日、終了日、スプリント期間を決めて保存すると、自動的にスプリントを作成してくれます。開始日によっては中途半端な期間のスプリントができますが、後から調整が利くのでとりあえず先に進めましょう。
• チーム
  チーム名はなんでもいいですが、アジャイルの特性を活かすために、数人で1チームにしましょう。

ちなみに筆者の設定例は図1（アプリケーション）、図2（スプリント）の通りです。

図1：アプリケーションの設定例（クリックで拡大）

図2：スプリントの設定例（クリックで拡大）

設定例を通して考えてみる

一般的なアジャイルと「エンタープライズ・アジャイル」では、いくつか前提が異なります。例を挙げてみましょう。

• ゼロから作るよりも、既存システムへの改修のほうが多い
• 独立した単一のアプリケーションよりも、バックエンドのシステムや、関連する他社のシステムとの連携が前提となっていることが少なくない
• しかも関連する他のシステム側は、アジャイルの時間軸で作られているとは限らない
• 個々のプロジェクトの効率だけなく、組織的な効率化の観点で、共通化されたプラットフォームの利用や、開発標準への準拠が求められる

XP（エクストリーム・プログラミング）を起点とするアジャイラ−の中には、アーキテクチャの取り扱いについて明言しなかったり、「作っているうちに『見えてくる』」というような話をしたりする向きもあります。ゼロからの開発で、かつそれ相応のスキル（たとえばXPの提唱者であるKent Beck並の）がある開発者の集団であれば、それも可能かもしれません。ですが先ほど挙げた前提は、アーキテクチャを早い段階で検討しないと開発が進められないという現実を表しています。

となると、スケジュールを考える上でのポイントは、以下の点を考慮することです。

• 関連する他のシステムで、すでに安定稼働しているもの（→改修がほとんど不要なモノ）はなにか？
• 関連する他のシステムで、同時期に開発・改修されているものはなにか？　開発のサイクル（リリース間隔、スプリント期間）が合うか？
• 共通化されたプラットフォームに改修が必要か？

図1は、プロジェクトのサブシステム構造を考慮した例です。「ショップサービス」は個々の店舗の機能性を実現しているのに対して、「Webモールサービス」は個々のショップに依存しないモール全体としての機能性を実現します。
チームは、これに合わせて各サービスにマッピングする形で編成します。いわゆる「フィーチャーチーム」です。それに対してカード決済等の機能は、Webモール以外のシステムでも利用される「共通のサービス」と位置付けて、「共通サービス」として登録しています。こちらは、いわゆる「コンポーネントベースのチーム」編成です。エンタープライズアプリの場合は、このようなフィーチャーベースとコンポーネントベースの混成になることがめずらしくありません。

このアプリケーション構成を踏まえたスケジュールのイメージが図2です。

※AGMでリリースを定義すると、デフォルトでは「スプリント」が自動的に定義されますが、DADの仕様に準拠して、あえて「イテレーション」に変えました（個人的な趣味として……）。

前回、DADでは「フェーズ」という概念が導入されていることを説明しました。DADの初期では、方向付けの期間については4週間程度を基本とし、個々のプロジェクト事情を考慮して調整するとあります。この4週間で順に以下の作業を行います。

この時期に方向性を決めるビジョン（開発構想と呼ばれます）を合意し、数ページの文書としてアウトプットします。詳細は、本稿の後半で取り上げます。
すべてのチームが同じサイクル（リリースやスプリント）で開発している場合は、「頻繁に統合」することに無理はありません。しかし、現実にはウォーターフォール型で開発しているチームが混在していたり、共通プラットフォームも並行して開発改修が進んでいたりする場合があります。その場合には、以下の2点をスケジュール上意識する必要があります。

• 各々が並行して開発を進める時期
• それらを統合するタイミング

  上記の例では、そのために「安定化」のスプリントを入れています。

開発構想と初期計画

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

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

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

利害関係者のリスト

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

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

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

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

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

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

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