アジャイル開発の明暗を分ける時間軸の捉え方の違いとは

もう少しだけ時間軸の話

前回の記事で、「スケールド・アジャイル・フレームワーク（Scaled Agile Framework：SAFe）」と「ディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery、以下DAD）フレームワーク」という2つのフレームワークを簡単に紹介しました。この連載ではDADをベースに話を進めることにした一番の理由は、「DADがプロジェクトという単位でものを見ており、従来のプロジェクト視点を持った人達が手を出しやすい」という点です。こう書くと、前述のようなリーン的アプローチを否定しているかのように取られてしまいますが、そうではありません。
DADは自らを「意志決定のフレームワーク」と位置付けていますが、組織の置かれた状況（ビジネス状況や技術への成熟度）に応じて、その判断材料やメリット／デメリットが異なるのは、前回ご紹介した通りです。DADでは、開発組織の成熟度が高まれば、リーン型へ移行していくのは自然なことだと捉えています。つまり「従来型のやり方」→「プロジェクトベースで運営されるアジャイル」→「アジャイル／リーン」という段階があるという見方をしています。

さて、DADの特徴的な時間軸の見方は、「フェーズ」という概念です。
DADの基本モデルでは3つのフェーズを提唱しています。

DADの基本モデル

方向付け（Inception）フェーズ

プロジェクトとしての実現可能性を踏まえたうえで、「何に対して投資するのか」について利害関係者との合意を取り付け、開発に必要な準備を完了させる時期です。
アジャイル開発では「変化には積極的に対応する」というポリシーがありますが、さりとてなんでもかんでも受け入れていては､いつまでたっても収束しません。このフェーズで合意された目的が、後続の構築フェーズでの変更依頼を受けるか否かを判断するベースになります。

構築（Construction）フェーズ

対象のプロダクトを開発するフェーズです。このフェーズの運営はスクラム＋XPをベースとした、よく知られた「アジャイル開発そのもの」となります。

移行（Transition）フェーズ

開発されたプロダクトは、本番環境でいきなり稼働させても使えない場合があります。本番稼働後、プロダクトがきちんと稼働するためには、ユーザに対する利用者教育や既存のデータを新システムに移行するといった事前準備が必要な場合があります。それを行うのが、このフェーズです。

DADでは、これらのフェーズそれぞれに対して典型的なゴールを設定しています。最終ゴールにむけて中間ゴールを設定し、それをクリアしていくことで方向性がぶれないように確認しつつ進められるようにします。また同時に、それらのゴールを達成するやり方は、当該チームの状況に応じていろいろなバリエーションがありうるので、チームが適切なものを選択するという前提を設けます。DADには、その選択を助けるためのさまざまなガイドが記述されているのです。