軽くおさらい
早いモノで、この連載も残すところ2回。「そういえば初回で、『今後の予定』って紹介したなぁ。どんなんだったっけかな」と振り返ってみたところ（表1）......
表1：本連載2回目以降の計画と実績
| 回数 | 予定 | 実績 | 所感 |
|---|---|---|---|
| 第2回 | 遊具の準備と最初の一歩 | アジャイル開発の明暗を分ける時間軸の捉え方の違いとは | （あれ？いきなり？） |
| 第3回 | 計画する | ディシプリンド・アジャイル・デリバリーの基本モデル「方向付けフェーズ」を理解する | （お、戻ったかな...） |
| 第4回 | 作りながら、己を知る | アジャイル開発の「構築フェーズ」で留意すべきポイント | （あ、ずれた...） |
| 第5回（今回） | 何事も節目が大事 | アジャイル開発の「構築フェーズ」で留意すべきポイントその2 | （お、また戻すのか） |
| 第6回 | おさらい | ※これから考える... | （あれ？移行フェーズは...） |
...あれ？ ...あれれれ？まぁその昔、当ThinkITで連載企画！ と華々しく立ち上げたものの、1回で終わった「黒歴史」を持つ筆者としては「連載という形になった」ことで、もう満足なのですよ、すでに（ザ・ヒラキナオリ）。
ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery、以下DAD）の特徴であるゴール駆動について、前回は構築フェーズのゴールのうち「アーキテクチャを早期に実証する」を取り上げました。話を進める前に、ポイントを確認しておきましょう。
アーキテクチャへのアプローチ
DADにおけるアーキテクチャへのアプローチを、時間軸やチーム編成を絡めてご紹介しました。統一プロセスのように、アーキテクチャにフォーカスしたフェーズ（推敲フェーズ）を明示的には設けていませんが、だからといってアーキテクチャを軽視しているわけではありませんので、誤解のないように。構築フェーズのイテレーションの中で、アーキテクチャのリスクを解決するというのは早期に取り組むべき重要なアイテムとして扱われます。
リスクと価値のライフサイクル
DADでは、これまでの価値駆動（ビジネス上の高い価値を提供するモノから実装するアプローチ）から、技術的なリスクとビジネス上の価値とのバランスを取りながら各イテレーションでの開発内容を決めていくというアプローチを採ります。エンタープライズ・アジャイルの背景にある問題意識（例えば、いろんなシステムが関与しあう複合システムでの統合の複雑さ）を考えれば、このアプローチの重要性がご理解いただけるかと思います。
安定化とリズム
「3Cリズム」ってありましたね（「なにそれ？」って方は第4回へ戻りましょう）。「安定化ってCI（継続的インテグレーション）のこと？」って質問が... いやいや、ちょっと違います。
「CIで日に何度も統合」というのは、アジャイル開発において決定的に重要な要素だと思いますし、Jenkinsあたりでブンブン廻していただきたいところです。しかし「統合できる」という話と、「実用に供せるレベルのプロダクトになった」という話は別物です。安定化とは、各時間軸（「プロジェクト期間」、「フェーズ」など）の中の、ある期間の役割であり位置づけです。安定化とは機能を作り込む時期ではなく、「磨き上げる時期」と言えばイメージが湧くでしょうか？
前回までの確認ができたところで、構築フェーズのもう一つのゴール「利害関係者のニーズの変化に応える」に話を進めていきましょう。そこは、魑魅魍魎... もとい、多様な利害関係者が跋扈する世界なのです。
- この記事のキーワード
バックナンバー
この記事の筆者
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
