エンタープライズ・アジャイルのキモとなるスケーリング
そして移行フェーズへ
プロジェクトの最後のフェーズは、移行フェーズと呼ばれます。
本連載の2回目で提示した移行フェーズのゴールを、以下に再掲しておきます。
- ソリューションの運用準備が整っていることを確認する
- 利害関係者のソリューション受け入れ準備が整っていることを確認する
- ソリューションを運用環境に載せる
この時期は、本番稼働後にうまく機能しないリスクに対処する時期です。上記の3つのゴールは、以下に示すリスクへの対処と見ることができます。
- データ移行や稼働環境の準備を整え、実際に運用環境に載せることで「環境面のリスク」をあらかじめ排除する
- これまでコラボレートしてきた利害関係者だけでなく、本番でシステムを実際に利用する者へのトレーニング等の受け入れ準備を万全にして、「利用できないリスク」を排除する
これを見ると「プロジェクト期間中に移行フェーズを設ける必要があるか否か」についても、検討する余地があることがわかります。以下のような具体例を挙げておきます。
既存システムへの小さな機能追加であり、画面操作も従来機能の延長上で利用できる
このような場合には、データの移行も伴わないし、簡単な操作ガイドをオンラインで提供するだけで、ユーザは利用できる(ことが期待される)ので、短期間(たぶん1日程度)で事足りるでしょう。
ユーザ数が少なく、開発の過程で密にコラボレーションしている
この場合は、各イテレーションの最後に評価環境にデプロイし実物を使ってもらうことで、学習機会を確保します。いわゆる「カナリアリリース」ってやつですね。結果として、プロジェクトの終盤の移行フェーズは、短時間で済むでしょう。
既存システム自体の移行
世のクラウド化の流れを受けて、ユーザシナリオレベルの改修はほとんどせずに、既存のシステムをクラウド環境に載せ替えるだけの案件も多くあります。この場合は、データの移行処置が必要になるか否かで、その検証も含め移行フェーズに要する日程を検討することが必要です。
新システムの開発あるいは既存システムの新技術を用いた再構築
この場合は、データの本番環境への移行と、利用者教育の負担が高まります。特に利用拠点が各地に分散している場合は、トレーニングにかかる期間が、移行フェーズの長短を左右します。
スケーリングという考え方:「一足飛びには行けないよね」に対する回答
エンタープライズ・アジャイルの代表的なフレームワークとして、スケールド・アジャイル・フレームワーク(Scaled Agile Framework、以下SAFe)とディシプリンド・アジャイル・デリバリー(Disciplined Agile Delivery、以下DAD)の2つがある中で、本連載ではDADを軸に話を進めてきました。その理由は、連載の第2回でも触れましたが、もう一度ここで確認しておきます。
DADが「プロジェクト」という単位でものを見ており、従来のプロジェクト視点を持った人達が手を出しやすい
多かれ少なかれ、新しいことを学ぶのは誰しも気後れするところがありますが、その際に従来の見方と比較して議論できるというのは大きなメリットではあります。特に経済的な側面に目を向けると、ある限られた期間と予算の中でゴールを達成するという「プロジェクト視点である」ことは、アジャイルの敷居を下げるという意味では無視できません。それに対してSAFeの世界観は、リーン開発の行き着いた形であるとは思いますが、これからアジャイルを本格的に始めようという向きには、少々追いつくのが大変な理想形であるようにも見えます。
その一方で、従来の見方に近いというメリットは、ともすると従来と同じように進めてアジャイルの良さを減じてしまうというデメリットも産み出しかねません。DADに対するよくある誤解の一つが、方向付けフェーズをウォーターフォール型の要件定義と同じモノと見なして、要件の詳細を一気に決めようとすることです。DADではこれを“Big Requirements Up Front(BRUF)”と呼び、明確に否定しています。期間の最初に、詳細で巨大な要求仕様を作成することは、そもそものアジャイルへの期待値を損なうモノでしかありません。
多様な利害関係者を前提に、意志決定の枠組みを定義している。
DADもSAFeも、多様な利害関係者とのコラボレーションを前提としています。その中でもDADはプロジェクト途中の節目で、何を意志決定するかという視点が色濃いフレームワークです。個々のプラクティスは、このゴールを達成するための実現手段の一つと位置付けられ、そのことによって、合意すべきゴールと開発者が採用するプラクティスとの間の独立性を担保します。つまり、手段の選択は開発者の自由となります。
本連載でも、フェーズのゴールを意識しながら、利害関係者とのコラボレーションのやり方を中心に話を進めてきました。
連載の最後にあたり、DADのもう一つの特徴にも触れておかねばなりません。それは「スケーリング」という考え方です。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- アジャイル開発における「ニーズの変化」への対応方法
- アジャイル開発の明暗を分ける時間軸の捉え方の違いとは
- アジャイル開発の「構築フェーズ」で留意すべきポイント
- エンタープライズ・アジャイルってなんだろう? 3つの視点と2つのフレームワーク
- ディシプリンド・アジャイル・デリバリーの基本モデル「方向付けフェーズ」を理解する
- アジャイル開発とは?プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説
- 少人数によるアジャイル開発の事例
- アジャイル・ブームの再来
- モバイルアプリの継続的テストフレームワーク、配信後のユーザー体験を測定―Think IT Mobile Developer Seminar 2015レポート
- Agile×Ruby×Cloudが示す価値