そして移行フェーズへ

プロジェクトの最後のフェーズは、移行フェーズと呼ばれます。

本連載の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のもう一つの特徴にも触れておかねばなりません。それは「スケーリング」という考え方です。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30