今回は、基幹システムの再構築プロジェクトを失敗しないための手順として、
（1）要求の確認
（2）現行踏襲内容の明確化
（3）現行業務知識不足への対応
を取り上げる。それぞれについて、なぜそれが必要なのか、何をすればよいのかを説明する。
基幹システムの再構築で発生しがちな問題には以下の三つがある。
（1）「現行踏襲＋仕様変更」というスコープの中、現行システムの仕様が把握し切れていないまま着手すること。
（2）開発段階で、ソースの自動変換だけでは済まない場合があること。
（3）事前調査不足によって、テストの完了条件が不明で終われないこと。
これらの問題を未然に防ぐために、再構築プロジェクトの企画や計画の段階で、現行システムの状態とそれに伴う再構築時のリスクを把握し、その対策を検討しておくことが重要だ。今回は、現行システムの状態および新システムへの要求からの再構築手法の選択とリスクの把握までを取り上げよう。
（1）要求の確認
前回説明した手法の選択のプロセス（ステップ2）において、新システムに求める要求を整理した。その中で、採用された要求もあれば採用されなかった要求もある。また、ステップ4までいったん進んだものの、リスクや投資効果の検討からステップ2に戻って再度要求事項の整理や見直しを行う場合もある。
このような状況では、どの要求が採用されたのか、ステークホルダー内で認識の齟齬が発生する可能性がある。認識の齟齬が潜在している状態でプロジェクトを進めると、「なぜこの要求は実現されていないのか」「やっぱりこの要求も入れてほしい」と要求事項の変更や追加がバラバラと発生してしまう。
プロジェクトが進んでから要求事項の変更や追加が発生すると、手戻りが発生する。また、要求の程度によっては、選択した手法やそれを踏まえての計画にも影響がある。「こんなはずじゃなかった」となるのは、ユーザーが新システムを目にする試験工程の後半であることが多い。その場合はさらに手戻りが大きくなる。
そのため、プロジェクト計画の策定に着手するにあたり、これまでの要求事項の採否について整理し、ステークホルダー間で認識を合わせる必要がある。
それには、これまでに抽出してきた要求事項と、その採否の結果を整理してまとめる。整理した結果は、ドキュメント化することが望ましい。整理した結果を、ステークホルダー全員に共有し、認識を合わせる（図1）。
