中央省庁の既存の業務システムを再構築する（いわるゆるレガシーマイグレーション）は、 一通りの落ち着きをみせているが、 自治体や独立行政法人では、今まさにまっさかりである。 レガシーマイグレーションは、業務・システム最適化ガイドライン（EA)に従って 実施されることがほとんどであるが、 このガイドラインを実運用するにあたっては、いくつかの留意点があげられる。 ここでは、特に１業務システムの再構築における現状分析から新システムの要件定義に 焦点をあてて、その留意点を探ってみる。
現行システム分析～新要件定義
業務システム再構築は、一般的には、以下の手順で実施する。
- 現行システムの機能と帳票の分析
- 現行業務フローの作成（ユースケース分析）
- 現行業務・システムの課題の抽出
- 課題の解決策の検討
- 新業務フローの作成
- 新システムの機能と帳票要件の定義
ここで、現行システムの要件定義の１手法として、データ構造と入出力の定義が重要となる。 新システムがパッケージをベースに開発されることが分かっていれば これは、新システムの調達仕様書の添付資料として、参考程度に現行システムの画面項目定義を添付とする ということでもよいが、新システムがスクラッチ開発となるとそうはいかない。
交錯する問題
実際にシステム再構築の要件定義を行う上では、 上記のようなきれいな作業フローでは進まない。 これは、業務改革と新システムの要件定義を一体として考えねばならないからである。 例えば、現在手作業でやっている業務を新システムでは、システム化したいという要件は 単純なように見えるが、ものによっては、例えば、電子化を全部行うのか、一部でよいのか 等、具体的な新システムのイメージを考えないと定義できないものがある。 これが、パッケージの活用を前提とするとなると、 どこまで電子化できるかは、パッケージ次第となる。 つまり、新業務フローはもとより、機能・帳票要件であっても 調達仕様書作成段階の要件定義には曖昧性が残るということである。
また、上のような細かな要件であっても、実施者の役割分担に影響を与えるものがあり その場合は、新システムの利用イメージ（新システムを使った作業とその実施者と、その時間配分） を詳細に描いておかないと、新システムの導入が破綻を来たすことになる。 この意味で、新業務フローの、特に業務負荷の大きいところの 利用者と利用時間の想定が必要となる。
円滑な方法の提案
我々は、多くの公共団体において、システム再構築の支援をさせて頂いている。 ここで、陥りがちな間違いとして、以下のようなものがあげられる。
- 現行業務フローの精緻化に時間を掛けすぎ、課題の洗い出しと解決策を考える時間がなくなる
- パッケージの実態を軽視し、理想的なシステムの定義に走り、結果としてコスト高のシステムとなってしまう
- 要件定義に十分時間をかけずに発注したため、開発業者と認識の齟齬が生じてしまう
- 新システムの精緻な利用イメージを想定できず、結果として効率の悪いシステムができあがってしまう