前回の説明内容を踏まえ、再構築プロジェクトの企画・計画段階で検討すべきリスク対策について説明する。それぞれについて、なぜそれが必要なのか、何をするのか、特記事項やポイントを説明しよう。
連載の最初で、事例をもとに基幹系システムの再構築で発生しがちな問題を説明した。
（1）「現行踏襲＋仕様変更」というスコープの中、現行システムの仕様が把握し切れていないまま着手すること。
（2）開発段階で、ソースの自動変換だけでは済まない場合があること。
（3）事前調査不足によって、テストの完了条件が不明で終われないこと。
これらの問題を未然に防ぐために、まず、現行システムの状態および新システムへの要求からの再構築手法の選択とリスクの把握までを取り上げた。
さらに前回から、リスク対策として、プロジェクト計画立案にあたって検討すべき内容に入った。
そのうち、前回では
- 要求の確認
- 現行踏襲内容の明確化
- 現行業務知識不足への対応
まで進めたが、今回は
- 品質保証の検討
- 意思決定プロセスの策定
を解説する。
品質保証の検討
再構築における品質保証の特徴は、現行システムで行っていた業務や運用を、新システムでも継続して実施できるよう求められることだ。これを「業務継続性の担保」と表現する。
具体的には、処理の結果だけでなく、目に見える要件（画面の操作性、帳票のレイアウトや出力される時間、性能など）が現行と変わらないことを担保するよう要求される。
これが、思いの外難しい。どういう状態になれば、どういう確認をどこまですれば、業務継続性を担保できたと言えるのか。これに対し、今のところ定石がない。当該システムで実現している業務の重要度やステークホルダー、すなわちユーザー企業、ベンダー企業、当該システムと関連のある他社、さらにユーザー企業の中でもシステム部門や利用部門によって感覚は異なる。
プロジェクトに掛けられる予算や期間によっても左右される。そのため、業務継続性をどのように考え、再構築プロジェクト全体を通じてどのように業務継続性を担保できるような品質保証の取り組みをするのか、を検討しておく必要がある。
再構築の品質保証は、「現行があるのだから新規構築に比べて容易だ」「現新比較試験で何とかなる」というのは、大きな誤解だ。事前にこの方針が決められていないと、事例で紹介したような終わらないテストに突入する事態になる。
そこで、どういう状態になれば、どういう確認をどこまですれば業務継続性を担保できたと言えるのか、を業務の重要度やプロジェクトに掛けられる予算や期間などを考慮して具体化する。具体化した内容を、当該システムにかかわるステークホルダーの間で合意する（図1）。
次に、具体化した内容について、再構築プロジェクト全体を通じてどのような取り組みを実施するのか、方針を検討する。再構築プロジェクト全体というのは、要件定義、設計工程、製造工程、試験工程と、場合によってはリリース後も含む。
