アジャイル開発の「構築フェーズ」で留意すべきポイント
いざ、構築フェーズに進まん
連載も半分まで進んできました。ここまで「理解度の異なる多様な利害関係者と一緒にアジャイル開発を進めていく」という文脈で、プロジェクトのビジョンを作る「方向付けフェーズ」と「ビジョン」の話をしてきました。その一方で、もっとガンガン宣伝しなければならないAgile Managerの話が少なく、筆者の社内的立場をなんとか維持しなくては…… 冗談はともかく、ここまででアジャイルの進め方が従来とは異なることが理解され、プロジェクトのゴールも関係者の間で合意されました（と願っています）。
いよいよ今回は、構築フェーズに入りましょう。まだまだ安心はできないのですよ。
構築フェーズのゴール
ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery、以下DAD）では「ゴール駆動」という考え方がその根底に流れています。各フェーズには、達成すべきゴールがあり、その実現のために最適なプラクティスを選択するという考え方であることは、連載の1回目に紹介しました。ここで、構築フェーズのゴールを振り返ってみましょう。
- 使用可能なソリューションを構築する（Produce a potentially consumable solution）
- 利害関係者のニーズの変化に応える（Address changing stakeholder needs）
- デプロイ可能なリリースへ近づける（Move closer to deployable release）
- 現在の品質レベルを維持・向上させる（Maintain or improve upon existing levels of quality）
- アーキテクチャを早期に実証する（Prove architecture early）
構築フェーズ中のチーム運営は、「スクラム＋XP＋アルファ」というよく見られる形で進みます。上記のゴールは、フェーズが終わった時点で到達（あるいは達成）しているべきゴールというよりも、フェーズ中のイテレーションで日々意識しているべきゴールととらえたほうがいいと思います。
実装技術系のプラクティスについてはここで取り上げていてはキリがないので、特徴的な2つのゴール、すなわち「アーキテクチャを早期に実証する」と「利害関係者のニーズの変化に応える」にフォーカスを合わせて話を進めていきましょう。
DADはアーキテクチャをどう扱うか？
アーキテクチャについてのアジャイル屋さんの立ち位置は、かなり個人差があるように思います。XPが広く知られるようになった頃に、有識者がアーキテクチャ軽視とも取られかねない表現を使っていたために、「作っているウチに見えてくる」みたいなことを語る信奉者にも会ったことがあります（なんだか「天の啓示」みたいです）。
ただ残念なことに、私を始め、ほとんどの開発者は「日本のKent Beck」ではありません。
プロダクトへの期待値が高くなり、機能はより複雑に、より高いパフォーマンスやスケーラビリティを求められるようになってくると、アーキテクチャの重要性が増してきます。
DADはその源流でもある「統一プロセス」の影響か、アーキテクチャを早期に実証することを推奨しています。言い換えれば、アーキテクチャとして対処すべき「技術リスクの大きなストーリー」を先に実装します。これは、XPを代表とする初期のアジャイル技法が、ユーザにとって価値のあるストーリーから順に実装していき価値の最大化を目指す「価値駆動」なのに対して、DADでは技術的リスクと価値とのバランスをとりながら優先順位を付けるということです。DADが採用するこのアプローチは「リスクと価値のライフサイクル」として知られています。
では時間軸を意識しながら見てみましょう。
（クリックで拡大）
図1は、アーキテクチャ実装の観点からフェーズをみたモノです。ゼロから開発をする場合には、アーキテクチャのデザインやその実装技術を、複数の候補から選択しなければなりません。この候補の選定は、一般的には方向付けフェーズで行います。同時に、プロダクトへのSLA等をインプットとして、技術的リスクの（初期の）リストを作ります。ここで影響度の大きなリスクをターゲットに、方向付けで選定された技術を使ってアーキテクチャの実装を行うのが構築フェーズの前半、図1で「調整」とされている時期です。
ここでのポイントは、「アーキテクチャを早期に実証（Prove）」としているところです。特定の技術的リスクを解消する（正確には解消できるか確認する）ために、ちょっとした（＝狭い領域の）プログラムを作ることを「スパイク（Spike、あるいはアーキテクチャ・スパイク）」と呼びますが、DADでの「実証」はフロントからバックエンドまで通しでシステムとしての動きを確認することが基本です。個々のスパイクが動いたからといって、組み合わせたプロダクトが動くとは限らないということです。
初期アーキテクチャが構築されたら、後続の「協働」では、ストーリーの開発と、アーキテクチャのブラッシュアップが並行して進みます。ここで視点を変えて、チーム編成とフェーズの関係を考えてみましょう（図2）。
（クリックで拡大）
新規開発量が多くアーキテクチャの検討が必要な場合、少人数のチーム（図2では、初期検討チームとしています）による検討＆実装を経て、アーキテクチャ候補を絞り込みます。構築フェーズの初期段階（調整）では、プロダクトのサービス（ここではより業務寄りの機能という意味）を開発するチームと、そこからのフィードバックを受けてアーキテクチャそのものを洗練させていくチーム（ほとんどの場合は、初期検討チームが発展していくでしょう）との並行開発になります。
習熟していない技術を使うときやパフォーマンス要求が桁外れに高いケースのように、技術的リスクが高い場合には、調整期間中に複数のイテレーションを実施して、技術リスクを解決するということも行われます。この時期は実質的には、統一プロセスでいうところの「推敲フェーズ」と同義になります。
統一プロセスをご存じの方は、DADのフェーズの概念を見た際に10人中10人が、「推敲（Elaboration）フェーズはないの？」と質問してきます。推敲フェーズはアーキテクチャを確立する時期と位置付けられていましたから、それがないとアーキテクチャを軽視しているように見えるのかもしれません。
「リスクと価値のライフサイクル」を採用し、アーキテクチャを重視しているのに、推敲フェーズが設けられなかった理由はよくわかりません。筆者の個人的な見解ですが、推敲フェーズを設けることによって、推敲フェーズでアーキテクチャが「確立」し、それ以降あまり手を入れられない状態、つまり「初期アーキテクチャに縛られることを避けたかったから」ではないかと想像しています。
「安定化」のパターン
しかしチームが増え、アーキテクチャが別チームによって実装されることを想定すると、かならず統合のタイミングの問題が出てきます。アジャイルでは、1日に何度も統合しましょう！という継続的統合により、統合リスクを排除しようとします。アーキテクチャが別チームによって開発が進んでいる場合は、各サービスはアーキテクチャチームがある時点で提供したベースライン実装の上で開発を進めることになります。
サービスの実装とアーキテクチャの実装が並行して追いかけっこみたいな状態になり、統合が難しくなります。これへの対策として取られるのが、「安定化のイテレーション」です。安定化のイテレーションでは、基本的にはサービス部分の新規追加は極力さけ、新しいアーキテクチャ実装との統合と安定化に力点を置きます。以前Agile Managerでイテレーションを定義した例を出しましたが、そこでも、複数のイテレーションの中に、安定化のイテレーションを入れていましたね。
この安定化にもいくつかのパターンがあります（図3）。
（クリックで拡大）
- パターン1：
アーキテクチャにはほとんど手が入らない場合には、定常的な継続的統合で対応できるので、特に安定化という時期を設ける必然性は薄いでしょう。既存システムやERPのようなパッケージをベースとしたプロダクトへの軽微な機能追加が、このパターンになるでしょう。 - パターン2：
アーキテクチャ自体にも手が入り、パフォーマンスに対して要求が高い場合には、適切なタイミングで安定化＆パフォーマンスチューニング作業に集中する時期が必要です。 - パターン3：
「サービス開発＋安定化」のペアで1イテレーションとするパターンもあります。アーキテクチャ自体を同時に作る場合や、再利用性を向上させるという目的のもとで、サービス部分と基盤との間で頻繁に機能が往来する（共通的なモジュールをどちらに置くのがベストか？で常に見直している場合など）場合には、安定化のタイミングを頻繁に入れます。
このように複数チームが並行開発している場合は、安定化のポイントをどれだけ多く設けるか、どのタイミングでどの範囲での安定化を目指すかという点がポイントになってきます。DADでは、ある所与の期間を3つに区切ってペースを作る「リズム」という考え方があります（図4）。
（クリックで拡大）
さきほど挙げた図1では、構築フェーズ自体を「調整（Coordinate）」−「協働（Collaborate）」−「完成（Conclude）」の「3つのC」で分けました。これを「3Cリズム」と呼んでいます。振り返ってみると、プロジェクト期間も「方向付け（調整に相当）」−「構築（協働に相当）」−「移行（完成に相当）」と3Cリズムの構造をとっていることがわかります。さらには、イテレーションの中も1日の活動も3Cリズムで構造化できます。「プロジェクト期間」→「フェーズ」→「イテレーション」→「1日の活動」の各レイヤーが、すべて3Cリズムで構造化されます。そのリズムの最後である「完成」が、各チーム単位、アプリケーション単位、そして全体での安定化のポイントになります。
仮想化がさらに安定化を加速する
それぞれの開発チームが相応の品質でアウトプットを出せるからこそ、統合のリスクを大きく減らすことができます。しかし前述したシナリオで見るように、アーキテクチャや再利用資産を同時並行で開発している場合には、常に最新の実装を統合してテストできない事態が起こりえます。通常は一つ前の安定化のアウトプットをアーキテクチャのベースとして、個々のサービスの開発を進めるわけですが、安定化の間隔が空いてしまうと、アーキテクチャ側のギャップが大きくなります。その結果、次の安定化での新アーキテクチャへの統合作業が大変になってしまいます。
それを避けるには、アーキテクチャ側で現在開発している機能の擬似的なインターフェース（いわゆるスタブ）を、サービス開発側が用意する必要がありますが、この場合にはインターフェースの機能部分が擬似的に提供されるだけで、性能特性までは提供できません。
ここに、やや流行りつつある「サービス仮想化」が有効な領域があります。例えばHPのService Virtualizationですと、インターフェースの定義ファイルや実際に稼働しているサービスからサービス間の情報のやり取りを収集して、それをもとに代理サービスを提供します。この代理サービスは、アーキテクチャ実装側が間に合っていないサービスが、あたかも存在するかのように応答を返します（それゆえ、仮想サービスと呼ばれるのです）。これにより、アーキテクチャ実装側が間に合っていなくても、それを利用する業務サービスのテストができるのです。しかもService Virtualizationの仮想サービスでは、システムの負荷状態を勘案した応答性能特性を設定も可能で、負荷の多寡に呼応して異なる応答時間で答を返せます。業務サービスに負荷テストをかけ、チューニングをかけることもできるわけです。
サービス仮想化というと、ともすると「スタブ実装の手間が省けます」とコスト削減を期待される方が多くいらっしゃいますし、そういうアピールをするベンダーも中にはいます。しかしそれはメリットの極一部でしかありません。それよりも、上記の並行開発チームの中で、アーキテクチャ実装を待たずに早い段階からテストに労力をふり向けることができ、結果として質の高いインクリメントが仕上がるというのが、本質的な効果なのです。
次回は「利害関係者のニーズの変化に応える」
次回は、もう一つのゴール「利害関係者のニーズの変化に応える」にフォーカスを合わせて、変更が多発する場合のスコープ管理の話をしましょう。サブタイトルは、「目と目をみつめて」です。
