アジャイル開発の「構築フェーズ」で留意すべきポイント
いざ、構築フェーズに進まん
連載も半分まで進んできました。ここまで「理解度の異なる多様な利害関係者と一緒にアジャイル開発を進めていく」という文脈で、プロジェクトのビジョンを作る「方向付けフェーズ」と「ビジョン」の話をしてきました。その一方で、もっとガンガン宣伝しなければならない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）フェーズはないの？」と質問してきます。推敲フェーズはアーキテクチャを確立する時期と位置付けられていましたから、それがないとアーキテクチャを軽視しているように見えるのかもしれません。
「リスクと価値のライフサイクル」を採用し、アーキテクチャを重視しているのに、推敲フェーズが設けられなかった理由はよくわかりません。筆者の個人的な見解ですが、推敲フェーズを設けることによって、推敲フェーズでアーキテクチャが「確立」し、それ以降あまり手を入れられない状態、つまり「初期アーキテクチャに縛られることを避けたかったから」ではないかと想像しています。
