導入実績

AsIs業務や改善要求などを盛り込んだ論点一覧を分母として

1. SAP標準機能で実現
2. カスタマイズ(アドオン)で実現
3. 他システムに機能移管

の整理が完了することで要件定義を完了する計画であったが、ゲートチェックレビューを経て

『そもそも論点一覧が要求定義を網羅できているのか？要件定義の分母足りえるのか？』

『各周辺システムとのIF連携の影響分析、E2EテストシナリオのENDポイントが不明確』

『業務ユーザー/周辺システムとの合意形成が不十分』

をプロジェクト側が解消できず、要件定義工程完了承認できず。

同時にプロジェクト側からスケジュール延伸の相談となったことから、PGMOの危険察知は合理的であったと言える。プロジェクトはリスケジュールでGoLiveを1年延伸した。

UAT工程で、先行テスト工程で顕在化すべきだった障害が発生。

先行テスト工程のテストカバレッジ分析やテスト結果レビュー品質等に疑義あり、ゲートチェックレビューにて先行テスト工程再実施を提案したが、祝日を挟んだ連休に本番移行する計画であり、この機を逃すと数カ月先までGoLiveできないバイアスがかかり、プロジェクト側は本番テスト工程を開始した。

結果、平行稼働検証にてさらなる障害に加え、要件漏れも顕在化し、本番移行直前のリスケジュールで半年以上の延伸となった。振り返ればPGMOのリスク察知は妥当であったと言える。

ドメスティック/グローバルのシステムが夫々並行して別プロジェクトとして進行中であった。

海外工場から外部輸出業者へのIF連携テストは合格し完了しているが、IF情報から出力された船積みドキュメントで輸出先の荷受けまで影響分析やE2Eテストが漏れていることをゲートチェックで指摘。

外部輸出業者からテスト印字された船積みドキュメントを荷受け先で確認したところ、並行して開発していたシステム毎に新旧商品コードが混在し、商品コードアンマッチで荷受けNGであることが判明した。荷受け側で新旧商品コードの変換機能を実装し、本番稼働後の重大な障害を回避できた。

ベンダーとの契約書上で契約不適合通知期限(瑕疵保障期間)が本番稼働後～1年でなく、納品後～1年となっているエラーを指摘。コロナ渦でプロジェクトがペンディングとなり、システム納品後から既に1年以上が経過しており、本番稼働後のベンダー瑕疵による保守が有償となった。

既に締結された契約を修正できなかったが、ベンダーと交渉し＠GoLive後の初年度保守契約をディスカウントさせることができた。

• 要件定義のトレーサビリティー＝要求定義との相関が不明瞭
• 業務側の合意証跡が不足、業務側サイン主体が担当チーム全員の合意を取りまとめできているのか？
• 要件定義の記載粒度/深度が不足、一意に読解できない

これらのレビュー指摘をプロジェクト側が解消できず、

1. 要件定義工程を延伸する
2. 要件定義内容を再精査する
3. N字/W字開発モデルのエッセンスを取り込み、２とあわせて、業務側がUATテストシナリオのドラフトを設計する
4. ３を２にフィードバックして記載粒度/深度を修正する

をガイドし、実施。

業務側ユーザーの仕様への理解度がUPし、より正確なToBe像へ設計品質を向上でき、後続工程の仕様ブレを抑止できた。

最終的に要件定義工程延伸分のコスト/工数はUAT設計工数短縮でカバーし、予算上振れも回避した。

本番切替1カ月前のゲートチェックで

• ECサイトパッケージアプリ/デザイナー/負荷テスト等の非機能/基幹システム連携の各チームスコープの残タスク/残課題の期日までの収束が困難
• UATテストシナリオカバレッジが不足、追加テスト要
• 先行工程で検知すべき障害が発生している
• パッケージアプリの潜在バグが発生、パッケージ品質を頼りに単体テスト工程を割愛しているが、ベンダーにて品質強化対策を実施いただくべき

等のレビュー指摘と共に、ST工程からやり直しを進言。

結果、PJリーダーの判断で1カ月の延伸で強硬リリースする計画を採択、新たなバグも噴出し、本番稼働に耐えられないとPJ内合意し、PJオーナー判断でプロジェクトはペンディングとなった。