アジャイル開発の「構築フェーズ」で留意すべきポイント

「安定化」のパターン

しかしチームが増え、アーキテクチャが別チームによって実装されることを想定すると、かならず統合のタイミングの問題が出てきます。アジャイルでは、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の仮想サービスでは、システムの負荷状態を勘案した応答性能特性を設定も可能で、負荷の多寡に呼応して異なる応答時間で答を返せます。業務サービスに負荷テストをかけ、チューニングをかけることもできるわけです。

サービス仮想化というと、ともすると「スタブ実装の手間が省けます」とコスト削減を期待される方が多くいらっしゃいますし、そういうアピールをするベンダーも中にはいます。しかしそれはメリットの極一部でしかありません。それよりも、上記の並行開発チームの中で、アーキテクチャ実装を待たずに早い段階からテストに労力をふり向けることができ、結果として質の高いインクリメントが仕上がるというのが、本質的な効果なのです。

次回は「利害関係者のニーズの変化に応える」

次回は、もう一つのゴール「利害関係者のニーズの変化に応える」にフォーカスを合わせて、変更が多発する場合のスコープ管理の話をしましょう。サブタイトルは、「目と目をみつめて」です。