はじめに
基幹システム刷新プロジェクトの最終関門が受け入れテストです。ここでの検証が甘いと、本番稼働後に不具合が多発し、現場の混乱や信頼低下につながります。受け入れテストをどう設計すれば、本番後の不具合を最小限に抑えられるのかを整理します。
受け入れテストは「ベンダー任せ」にしてはいけない
受け入れテストは、開発ベンダーが実施する単体・結合テストとは性質が異なります。開発ベンダーのテストは「仕様通りに作られているか」を確認するものですが、受け入れテストは発注側が「実際の業務で使えるかどうか」を自ら確認するためのものです。この主体の違いを理解せず、受け入れテストも開発ベンダーに任せきりにしてしまうと、実際の業務シナリオに即していない、形だけのテストになってしまいます。
受け入れテストを設計する際のポイント
① 実際の業務シナリオに基づいたテストケースを作る
仕様書の項目を機械的になぞるのではなく、「月末の締め処理」「繁忙期の大量データ処理」「イレギュラーな取引パターン」など、現場で実際に発生する業務シナリオをもとにテストケースを作成します。テスト計画の立て方｜品質を担保する3つの観点で触れた機能面・非機能面・データ移行面のそれぞれについて、業務シナリオに基づくケースを用意することが重要です。
② 現場の利用者を巻き込んでテストを実施する
情報システム部門だけでテストを完結させず、実際にシステムを使う現場の担当者にテストに参加してもらうことをおすすめします。現場の視点でしか気づけない違和感や、業務フロー上の問題は、情報システム部門だけのテストでは発見しにくいためです。これは基幹刷新で「現場の抵抗」が起きる本当の理由で触れた、現場の巻き込みという観点でも有効です。
③ 見つかった不具合を一元管理する
受け入れテストで見つかった不具合は、その場しのぎで個別に対応するのではなく、不具合管理表で一元管理し、重要度・優先度に応じて計画的に対応することが重要です。「不具合の疑い」の段階と「不具合と確定した」段階を同じ表で管理してしまうと、対応状況が見えにくくなるので注意が必要です。
実際に使っている不具合管理表（バグ管理表・問い合わせ管理表）は、noteで配布しています。受け入れテストで見つかった不具合の管理にそのまま活用できます。
④ 合格基準を事前に明確にしておく
「大きな問題がなければ本番稼働する」という曖昧な基準では、土壇場での判断がぶれやすくなります。「もう後戻りできない」空気に流されないために｜カットオーバー判定基準を事前に決めるで触れたように、受け入れテストの合格基準も、事前に具体的な数値・条件として明文化しておく必要があります。
受け入れテストの期間は十分に確保する
プロジェクト終盤はスケジュールが逼迫しやすく、受け入れテストの期間が真っ先に圧縮される対象になりがちです。しかし、受け入れテストは本番稼働前の最後の検証機会であり、ここを削ることは本番後のリスクを先送りしているに過ぎません。計画段階から受け入れテストに十分な期間を確保し、安易に圧縮しないことが重要です。
まとめ
受け入れテストは発注側が主体的に実施すべき工程であり、開発ベンダー任せにしてはいけません。実際の業務シナリオに基づくテストケースの作成、現場利用者の巻き込み、不具合の一元管理、合格基準の事前明確化が、本番稼働後の不具合を減らすための実務上のポイントです。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント