SAP methodology
SAP ActivateのRealizeフェーズの進め方｜構築・テスト・移行準備を実務で管理する
SAP ActivateのRealizeフェーズで行う設計確定、構築、統合テスト、データ移行準備、課題管理、成果物の整理方法を実務向けに解説します。
SAP ActivateのRealizeフェーズは、Exploreフェーズで合意した業務プロセスをシステムとして構築し、テストを通じて本番稼働の準備度を高める段階です。要件を検討するだけではなく、設定、拡張、連携、権限、データ、テスト結果を具体的な証跡として残します。
このフェーズで重要なのは、作業量を増やすことではなく、合意済みの設計を変更管理の下で実装することです。未解決の判断事項を放置すると、テスト後半やDeployフェーズで手戻りが発生します。そこで、各作業に責任者、完了条件、確認者、期限を割り当てます。
Realizeフェーズの役割
Realizeフェーズの開始時点では、ExploreフェーズでFit-to-Standardの検討と業務要件の整理が進んでいます。実務では、承認済みのプロセス一覧、バックログ、設計判断、未解決課題を起点に、構築対象を確定します。
SAP Activate全体の位置付けを確認する場合は、SAP Activateの概要と各フェーズを参照してください。Realizeだけを独立した開発工程として扱うのではなく、前後のフェーズと成果物を接続して管理することが大切です。
Realizeフェーズの主な目的は次のとおりです。
- 標準機能の設定を完了する
- 承認済みの拡張や帳票を実装する
- 外部システムとの連携を構築する
- マスターデータとトランザクションデータの移行方式を確定する
- 単体テスト、統合テスト、業務受入テストへ進める
- 運用、権限、監視、サポート体制を検証する
- 本番移行に必要な手順と判断基準を整える
開始前にそろえる情報
Realizeフェーズを開始する前に、Exploreフェーズの成果物を実装可能な単位へ分解します。業務プロセス、組織、対象国、対象会社、インターフェース、データオーナーを一覧化し、構築対象と対象外を明確にします。
特に確認したいのは、次の情報です。
- プロセスごとの承認済みスコープ
- Fit-to-Standardで確定した標準利用方針
- 拡張、帳票、ワークフローの承認状況
- 連携先、通信方式、送受信データ、エラー処理方針
- 移行対象データ、データオーナー、クレンジング責任者
- 権限ロールの設計方針と職務分掌
- テストシナリオ、期待結果、テスト担当者
- 変更要求と未解決課題の優先順位
Exploreフェーズでの合意形成を確認するには、SAP ActivateのExploreフェーズとFit-to-Standardが役立ちます。Realize開始時に合意の根拠が不明な項目を残さず、判断記録と設計書を同じ管理体系に置きます。
構築作業の進め方
構築は、業務プロセスの優先順位とテスト準備を考慮して段階的に進めます。最初からすべての設定を完了させるのではなく、主要な業務シナリオを通して確認できる単位で構築し、早い段階で実行可能な流れを作ります。
設定と拡張を分けて管理する
標準設定、拡張開発、帳票、ワークフロー、連携を同じ作業一覧で管理すると、完了条件が曖昧になりやすくなります。作業種別ごとに担当、環境、依存関係、テスト方法を記録します。
標準設定では、設定値、設定理由、関連プロセス、確認者を残します。拡張では、対象業務、実装方式、エラー処理、性能条件、保守担当を定義します。設定と拡張の境界を明確にすると、追加要求が発生した際に影響範囲を判断しやすくなります。
変更をバックログで管理する
構築中に出た追加要望は、口頭の依頼だけで処理せず、バックログまたは変更管理票に登録します。優先度、業務価値、影響範囲、見積もり、承認状態を記録し、計画内の作業と区別します。
変更を受け入れる場合は、スコープ、納期、テスト範囲、移行手順への影響を同時に更新します。判断を保留する場合も、保留理由と再判断日を記録します。
環境間の移送を統制する
開発、品質保証、本番前環境など複数の環境を利用する場合は、移送単位と承認者を明確にします。設定変更、拡張、連携変更を同じリリース番号または変更単位にひも付けると、テスト結果と本番移行対象を追跡できます。
テストを段階化する
Realizeフェーズのテストは、単体テストから始めて、業務フロー全体と外部連携を確認する段階へ進めます。テストの種類ごとに目的と完了条件を設定し、単に実行件数を積み上げる管理にしないことが重要です。
単体テスト
単体テストでは、設定、拡張、帳票、ワークフロー、連携処理を対象に、機能単位の期待結果を確認します。テストケースには前提条件、入力値、実行手順、期待結果、実績結果、証跡、担当者を記録します。
失敗したケースは、設定不備、データ不備、プログラム不備、環境不備、仕様判断の未確定などに分類します。原因分類があると、修正担当と再テストの優先順位を決めやすくなります。
統合テスト
統合テストでは、部門をまたぐ業務フローとシステム間のデータ連携を確認します。たとえば、受注から出荷、請求、入金までの流れを一つのシナリオとして実行し、各処理の結果と後続処理への引き渡しを確認します。
連携テストでは、正常系だけでなく、必須項目欠落、重複データ、通信遅延、受信拒否、再送、訂正処理も扱います。エラーが発生した場合の検知者、一次対応者、再処理方法、業務への影響をテスト結果に残します。
業務受入テスト
業務受入テストでは、実際の業務担当者が日常業務を想定して操作します。担当者には、テストシナリオだけでなく、業務上の判断ポイントと期待する証跡を提示します。
完了判定では、合格率だけでなく、重大度の高い未解決障害、代替運用の有無、業務責任者の承認を確認します。重大な障害が残る場合は、テスト完了として扱わず、修正、再テスト、受入判断の順に進めます。
課題と障害を収束させる
課題管理では、障害票の件数だけでなく、業務影響と本番稼働への影響を見ます。各課題に一意の番号を付け、発生日、発見工程、対象プロセス、環境、原因、回避策、恒久対応、担当者、期限、ステータスを記録します。
優先度は、業務停止、財務影響、法令・統制、データ破損、連携停止、利用者影響などの観点で判断します。暫定回避策を採用した場合は、恒久対応の期限と、回避策を解除する条件を定義します。
週次会議では、未解決件数だけでなく、期限超過、再発、同一原因の横展開を確認します。重大障害はプロジェクト責任者と業務責任者へ即時にエスカレーションし、稼働判断に必要な情報を早くそろえます。
データ移行を構築と並行する
データ移行は、Realizeフェーズの終盤にまとめて行う作業ではありません。対象データの定義、抽出、変換、クレンジング、ロード、照合を早期に試行し、データ品質と作業時間を把握します。
移行対象ごとに、データオーナー、抽出元、変換ルール、必須項目、重複排除方針、照合方法、承認者を定義します。特に、コード体系、組織構造、取引先、品目、勘定科目などの参照データは、業務プロセスと強く結び付くため、早い段階で確認します。
移行リハーサルでは、実際の作業時間、エラー件数、修正時間、再実行方法を記録します。本番移行の判断では、ロードが完了したかだけでなく、件数照合、金額照合、残高確認、業務担当者の承認まで確認します。
権限と運用準備を進める
構築とテストが進んだ時点で、権限と運用設計を実環境に近い条件で確認します。職務ごとのロール、承認権限、機密データへのアクセス、緊急時の代替手順を整理し、業務責任者が確認できる形にします。
運用準備では、監視対象、ジョブ、連携、障害通知、バックアップ、問い合わせ窓口、一次切り分け、エスカレーション先を定義します。運用担当者が実際に手順を実行し、画面やログから状況を判断できるかを確認します。
また、利用者向けの操作手順と運用担当者向けの管理手順を分けて作成します。手順書には、前提条件、操作、確認結果、異常時の対応、連絡先、完了条件を記載します。
Realizeフェーズの成果物
成果物は、作成したかどうかではなく、次の工程で利用できる状態かどうかで評価します。文書ごとに所有者、承認者、版、最終更新日、関連プロセス、参照するテストケースを記録します。
代表的な成果物は次のとおりです。
- 構築済み設定と設定変更履歴
- 拡張、帳票、ワークフローの設計・実装記録
- 連携仕様、接続情報、エラー処理方針
- テスト計画、テストケース、実行結果、証跡
- 障害一覧、課題一覧、変更要求一覧
- 移行設計、変換ルール、移行リハーサル結果
- 権限設計、ロール割当、承認記録
- 運用手順、監視項目、障害対応フロー
- 本番移行計画とカットオーバー判定基準
- 未解決事項とDeployフェーズへの引継ぎ一覧
成果物の構成を全体計画と合わせて確認する場合は、SAP ActivateのDeployフェーズの進め方を参照してください。Deployへ渡す情報には、完了済み項目だけでなく、既知の制約、残課題、暫定運用も含めます。
完了判定のチェックポイント
Realizeフェーズの完了判定は、構築作業の終了日だけで決めません。次の条件を組み合わせ、業務責任者、IT責任者、テスト責任者、移行責任者が合意します。
- 承認済みスコープの構築対象が完了している
- 主要な業務シナリオのテスト結果が承認されている
- 重大度の高い未解決障害が稼働判断を妨げない
- データ移行リハーサルと照合が完了している
- 権限、監視、ジョブ、連携の運用確認が完了している
- 本番移行手順と切り戻し方針が承認されている
- Deployフェーズで必要な成果物が引き渡せる
RealizeからDeployへの移行では、未完了項目をゼロにすることだけを目標にせず、残課題を可視化したうえで、受容可能なリスクかを判断します。
アジャイルで反復する場合
短いイテレーションで構築する場合も、各サイクルに計画、実装、テスト、レビュー、振り返り、バックログ更新を含めます。イテレーションの完了条件を明確にし、未完成の作業を完了扱いにしないことが重要です。
SAP Activateとアジャイル開発の組み合わせを実務へ適用する場合は、スプリントの完了とフェーズ全体の完了を区別します。スプリントで機能が動作していても、統合テスト、移行、権限、運用手順が未完了なら、Realize全体の完了条件は満たしません。
レビューでは、動作する機能だけでなく、テスト証跡、設計判断、課題、次の依存作業を確認します。これにより、後続スプリントやDeployフェーズへ問題を先送りするリスクを抑えられます。
実務で起きやすい停滞と対処
要件の揺れが続く場合は、変更要求を登録し、業務価値、影響、納期、テスト範囲を比較して判断します。構築担当者がその場で受け入れる運用にすると、設計とテストの基準が崩れます。
テストデータ不足が起きた場合は、業務シナリオごとに必要なマスターデータ、残高、履歴、例外条件を洗い出します。データ準備をテスト担当者だけに任せず、業務オーナーと移行担当者が確認します。
障害の再発が多い場合は、個別修正だけで終わらせず、原因を設定、設計、データ、環境、手順、教育に分類します。同じ原因が別プロセスにも存在しないかを確認し、横展開します。
承認の遅れがある場合は、承認対象、判断期限、判断に必要な情報を明確にします。会議で結論が出ない項目は、選択肢、推奨案、影響、期限をまとめて決裁者へ提示します。
まとめ
Realizeフェーズでは、Exploreで合意した業務設計を、設定、拡張、連携、データ、権限、テスト、運用手順へ変換します。進捗を構築件数だけで測らず、業務シナリオが実行でき、結果が証跡として残り、本番移行の判断材料がそろっているかで評価します。
安定した進行には、承認済みスコープ、段階的なテスト、早期の移行リハーサル、課題の優先度管理、成果物の所有者設定が欠かせません。Realizeの終了時点でDeploy担当者が迷わず移行準備へ進める状態を作ることが、最も実務的な完了条件です。