はじめに
基幹システム刷新プロジェクトにおいて、テストは本番稼働前の最後の砦です。しかし、「とりあえずテストする」という曖昧な計画のまま進めてしまい、重要な観点が漏れたまま本番を迎えてしまうケースは少なくありません。テスト計画を立てる際に押さえておくべき3つの観点を整理します。
なぜテスト計画が曖昧になりやすいのか
テスト計画が曖昧になる背景には、プロジェクト終盤でスケジュールが逼迫し、テストフェーズにしわ寄せが行きやすいという構造的な問題があります。開発フェーズの遅延がそのままテスト期間の圧縮につながり、「時間がないから重要そうなところだけ確認する」という場当たり的な進め方になりがちです。
こうした事態を避けるには、テストを開発の後工程としてではなく、要件定義の段階から並行して計画しておく必要があります。
品質を担保する3つの観点
テスト計画を立てる際は、少なくとも次の3つの観点を網羅的にカバーする必要があります。
① 機能面：要件を満たしているか
要件定義で合意した機能が、仕様通りに動作するかを確認します。ここで重要なのは、テストケースを要件定義書・仕様書と1対1で紐づけておくことです。要件定義ワークショップを成功させる進め方で整理した要件が漏れなくテストされているかを、トレーサビリティ表の形で管理することをおすすめします。機能要件・非機能要件を整理したテンプレートがあると、このトレーサビリティ管理がしやすくなります。
② 非機能面：性能・セキュリティ・運用性を満たしているか
機能が正しく動くことだけでなく、想定される利用者数・データ量での性能、セキュリティ要件、障害時の挙動といった非機能要件も、テスト計画に明確に組み込む必要があります。基幹刷新プロジェクトにおけるセキュリティ要件の整理で触れているように、非機能要件は後回しにされがちですが、本番稼働後に問題が顕在化すると影響が大きい領域です。
③ データ移行面：移行後のデータが正しいか
基幹刷新特有の観点として、新旧システム間のデータ移行が正しく行われているかの検証があります。件数の一致だけでなく、金額・ステータスなどの重要項目が正しく変換されているか、マスタデータのコード体系の変換に漏れがないかを確認する必要があります。マスタデータ整備を後回しにするとどうなるかでも触れたとおり、ここでの見落としは本番稼働後に発覚しやすく、影響範囲も広くなりがちです。
テスト計画は「誰が」「いつ」「何を」まで決める
3つの観点を洗い出すだけでなく、それぞれについて「誰がテストを実施するのか（開発ベンダーか、発注側の業務部門か）」「いつ実施するのか」「何をもって合格とするのか」までを計画段階で明確にしておく必要があります。特に機能面のテストは開発ベンダー主体になりがちですが、非機能面・データ移行面は発注側が主体的に関わるべき領域です。受け入れテストの設計｜本番後の不具合を減らすためにもあわせて参考にしてください。
まとめ
テスト計画は、機能面・非機能面・データ移行面の3つの観点を網羅的にカバーする必要があります。スケジュール終盤でのしわ寄せを避けるため、要件定義の段階からテスト計画を並行して検討し、「誰が」「いつ」「何を」テストするのかを早期に明確にしておくことが、本番稼働後のトラブルを減らす鍵になります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント