アジャイル開発における「ニーズの変化」への対応方法

軽くおさらい

早いモノで、この連載も残すところ2回。「そういえば初回で、『今後の予定』って紹介したなぁ。どんなんだったっけかな」と振り返ってみたところ（表1）......

表1：本連載2回目以降の計画と実績

...あれ？　...あれれれ？まぁその昔、当ThinkITで連載企画！　と華々しく立ち上げたものの、1回で終わった「黒歴史」を持つ筆者としては「連載という形になった」ことで、もう満足なのですよ、すでに（ザ・ヒラキナオリ）。

ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery、以下DAD）の特徴であるゴール駆動について、前回は構築フェーズのゴールのうち「アーキテクチャを早期に実証する」を取り上げました。話を進める前に、ポイントを確認しておきましょう。

アーキテクチャへのアプローチ

DADにおけるアーキテクチャへのアプローチを、時間軸やチーム編成を絡めてご紹介しました。統一プロセスのように、アーキテクチャにフォーカスしたフェーズ（推敲フェーズ）を明示的には設けていませんが、だからといってアーキテクチャを軽視しているわけではありませんので、誤解のないように。構築フェーズのイテレーションの中で、アーキテクチャのリスクを解決するというのは早期に取り組むべき重要なアイテムとして扱われます。

リスクと価値のライフサイクル

DADでは、これまでの価値駆動（ビジネス上の高い価値を提供するモノから実装するアプローチ）から、技術的なリスクとビジネス上の価値とのバランスを取りながら各イテレーションでの開発内容を決めていくというアプローチを採ります。エンタープライズ・アジャイルの背景にある問題意識（例えば、いろんなシステムが関与しあう複合システムでの統合の複雑さ）を考えれば、このアプローチの重要性がご理解いただけるかと思います。

安定化とリズム

「3Cリズム」ってありましたね（「なにそれ？」って方は第4回へ戻りましょう）。「安定化ってCI（継続的インテグレーション）のこと？」って質問が...　いやいや、ちょっと違います。

「CIで日に何度も統合」というのは、アジャイル開発において決定的に重要な要素だと思いますし、Jenkinsあたりでブンブン廻していただきたいところです。しかし「統合できる」という話と、「実用に供せるレベルのプロダクトになった」という話は別物です。安定化とは、各時間軸（「プロジェクト期間」、「フェーズ」など）の中の、ある期間の役割であり位置づけです。安定化とは機能を作り込む時期ではなく、「磨き上げる時期」と言えばイメージが湧くでしょうか？

前回までの確認ができたところで、構築フェーズのもう一つのゴール「利害関係者のニーズの変化に応える」に話を進めていきましょう。そこは、魑魅魍魎...　もとい、多様な利害関係者が跋扈する世界なのです。