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

前回はディシプリンド・アジャイル・デリバリー（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点をスケジュール上意識する必要があります。

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

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