プロジェクト フェーズ
通常、方法論の実装により、プロジェクト全体が小さく分割され、進捗状況を簡単に追跡できるようになります。 一般的には、特定の方法論に関係なく、プロジェクトのこうした小さな部分に対するその他の一般的な名前は、スプリントまたは反復です。 呼び方にかかわらず、プロジェクトのこうした小さな部分の完了は、プロジェクトの進捗状況のマイルストーンを表します。
フェーズやプロジェクトによって、費やされる時間は大きく異なります。 プロジェクトの中には、考案から運用まで数か月しかかからないプロジェクトや、作業を開始できるまでに 1 年以上かかるプロジェクトもあります。
プロジェクトが進行するにつれて、プロジェクトのフェーズは満ち引きします。 プロジェクトでアジャイル方法論を使用する場合、プリセールスから運用までのパスに沿ってフェーズを繰り返すことができます。
プロジェクトは通常「プリセールス」「開始」「実装」「デプロイ」「運用」のパスに従います。
特定のチーム メンバーは各フェーズに特化しています。ただし、多くのプロジェクト チーム メンバーは、プロジェクトで必要とされる場所に移動します。 チーム メンバーは、考案からデプロイまでの任意の時点でプロジェクトに参加するのが一般的です。
プリセールス
プリセールスの主な活動は、プロジェクトの獲得に関して営業チームをサポートすることです。 プリセールスでは、プロジェクトを獲得するために必要な最小限の労力に焦点を当て、提供可能な商品を営業チームが過剰販売しないようにします。 契約のこのフェーズにおける活動は、主に次のように分類されます。
- 提案依頼 (RFP) の応答
- 顧客との顔合わせのミーティング
- 概念実証/デモ
- ソリューションの構想
開始
プロジェクトがソリューションの設計段階に進むと、ソリューション アーキテクトが主導します。 使用される方法論によっては、この作業の一部は事前に完了するか、より一般的には、よりアジャイルなプロジェクトの各スプリント/反復で実行される場合があります。
- 顧客ワークショップ - これらの要件は、業務を行うビジネス ユーザーのニーズを把握するための話し合いを取り込みます。
- 要件の検証と明確化 - ユーザー ストーリーとして指定された要件を含む、収集された詳細な要件を確認します。 目標は、それらが明確かつ簡潔な実装可能な要件であることを保証することです。 このプロセスで、チームは非機能要件を特定し、必要に応じて追加することを検討します。 このタスクでは、ソリューションを構築する前に要件を確実に理解するために、顧客またはチームとの追加のフォローアップが必要になる場合があります。
- 大まかなアーキテクチャ - ソリューション アーキテクトは、ソリューション トポロジ全体の設計を主導し、この情報を広範なプロジェクト チームに伝達します。 この評価には、Dynamics 365、Microsoft AppSource、または使用されたその他の外部サービス (内部および外部のシステムとサービスとのやり取りの大まかな概要など) が含まれます。
- 詳細ソリューション アーキテクチャ – このプロセスで、詳細が定義されます。 セキュリティおよびデータ モデルの設計やそれぞれの外部システムおよびサービスの全体的な統合戦略が含まれます。 さらに、このプロセスには、Dynamics 365 アプリおよび使用されるその他の既存のアプリに対するカスタマイズの指定が含まれます。 プロジェクト チームは通常、フィットギャップ分析を使用して、要件とすぐに使用できる機能の間のギャップを特定します。
- 技術デザインのレビュー - 広範なプロジェクト チームによってアーキテクチャが詳細な設計に進み始めると、ソリューション アーキテクトはレビュー担当者の役割を引き受け、設計が目的のアーキテクチャに適合するようにします。
- 変更管理 - 変更管理は、顧客が期日と予算を守ったソリューションを使用できるようにするための重要な要素です。 チームは、スコープの変化を回避すると同時に、プロジェクトの成功基準を満たすために必要な変更を許可するよう支援する必要があります。 プロジェクトのこの時点から、例外的な変更管理が必要です。
実装
実装フェーズでは、プロジェクト チームは合意したソリューションの設計と範囲に従ってソリューションを構築することに重点を置きます。 このフェーズでは、実装に関するレビューが導入されます。 実装のレビューは、ソリューションの設計 (データ モデル、セキュリティ、統合) と実装のプラクティス (アプリケーション ライフサイクル管理とテスト戦略) の特定の側面に関連する質問に入念に対処するために役立ちます。 実装フェーズでは、特定のコンポーネントの設計、テクノロジの選択、今後の変更、ロードマップ、廃止、アプリケーション ライフサイクル管理 (ALM)、およびビルドに関する疑問が生じることが考えられます。 開発するソリューションがベスト プラクティスに従っており、製品のロードマップに戦略的に沿ったものになるように、事前に顧客と対話するようにしてください。
デプロイ
デプロイ フェーズでは、ソリューションが構築およびテストされ、プロジェクト チームはユーザー受け入れテスト (UAT) とトレーニングの最終段階に向けて準備をしています。 また、必要なすべての顧客の承認、情報のセキュリティの確認、切り替え計画の定義 (実行/終了なしの基準を含む)、実行開始イベントのスケジュール、サポート モデルの準備が整いました。さらに、配置の実行ブックにはタスク、所有者、期間、および定義済みの依存関係が含まれています。
運用
アプリケーションの計画、開発、展開が完了していますが、これで終わりではありません。 運用フェーズの目標は、展開の成否を検証し、プロジェクトから学んだ教訓を見直して、次のフェーズへの移行、またはメンテナンス チームの移行に対するサポートを提供することです。 顧客の移行後に、ソリューション アーキテクトは Go-live 後のレビューを実施する必要があります。 移行計画について話し合い、メンテナンス チームともその計画を共有してください。