業務システム再構築と要件定義の実態

中央省庁の既存の業務システムを再構築する(いわるゆるレガシーマイグレーション)は、 一通りの落ち着きをみせているが、
自治体や独立行政法人では、今まさにまっさかりである。 レガシーマイグレーションは、業務・システム最適化ガイドライン(EA)に従って
実施されることがほとんどであるが、 このガイドラインを実運用するにあたっては、いくつかの留意点があげられる。
ここでは、特に1業務システムの再構築における現状分析から新システムの要件定義に 焦点をあてて、その留意点を探ってみる。

現行システム分析~新要件定義

業務システム再構築は、一般的には、以下の手順で実施する。

  • 現行システムの機能と帳票の分析
  • 現行業務フローの作成(ユースケース分析)
  • 現行業務・システムの課題の抽出
  • 課題の解決策の検討
  • 新業務フローの作成
  • 新システムの機能と帳票要件の定義

現行システムの機能要件等を分析するのは、再構築においても 現行システムの必要最低限の機能を継承する場合が多いからである。
現行システムは、往々にして、設計ドキュメントが整備されていないか
あるいは、実態と一致しておらず、現行システムの正確な機能要件を洗い出すのは 困難なことが多い。
他方、業務フローはヒアリング等により作成できるが 業務フローはあくまでユースケースであり、
業務フローから現行システムの機能を洗い出すのは難しい。

ここで、現行システムの要件定義の1手法として、データ構造と入出力の定義が重要となる。
新システムがパッケージをベースに開発されることが分かっていれば
これは、新システムの調達仕様書の添付資料として、参考程度に現行システムの画面項目定義を添付とする
ということでもよいが、新システムがスクラッチ開発となるとそうはいかない。

交錯する問題

実際にシステム再構築の要件定義を行う上では、 上記のようなきれいな作業フローでは進まない。
これは、業務改革と新システムの要件定義を一体として考えねばならないからである。
例えば、現在手作業でやっている業務を新システムでは、システム化したいという要件は
単純なように見えるが、ものによっては、例えば、電子化を全部行うのか、一部でよいのか
等、具体的な新システムのイメージを考えないと定義できないものがある。 これが、パッケージの活用を前提とするとなると、
どこまで電子化できるかは、パッケージ次第となる。 つまり、新業務フローはもとより、機能・帳票要件であっても
調達仕様書作成段階の要件定義には曖昧性が残るということである。

また、上のような細かな要件であっても、実施者の役割分担に影響を与えるものがあり
その場合は、新システムの利用イメージ(新システムを使った作業とその実施者と、その時間配分)
を詳細に描いておかないと、新システムの導入が破綻を来たすことになる。 この意味で、新業務フローの、特に業務負荷の大きいところの
利用者と利用時間の想定が必要となる。

円滑な方法の提案

我々は、多くの公共団体において、システム再構築の支援をさせて頂いている。
ここで、陥りがちな間違いとして、以下のようなものがあげられる。

  • 現行業務フローの精緻化に時間を掛けすぎ、課題の洗い出しと解決策を考える時間がなくなる
  • パッケージの実態を軽視し、理想的なシステムの定義に走り、結果としてコスト高のシステムとなってしまう
  • 要件定義に十分時間をかけずに発注したため、開発業者と認識の齟齬が生じてしまう
  • 新システムの精緻な利用イメージを想定できず、結果として効率の悪いシステムができあがってしまう

上記のような間違いは、極力排除しなければならない。
そのために何をするか?、時間の限り詳細に未来を描き、シミュレーションする、ということにつきる。
つまり、何がどう変わるのかを詳細に定義していくことであるが ここでも、時間配分と作業の深度を決めておく必要がある。
というのは、開発業者とパッケージが決まる前の開発業者の調達段階での要件定義と、
調達後の要件定義では、要件定義または基本設計の深さが異なるからである。
開発業者調達前は、時間上の制約から、また、調達の公平性から、パッケージが決まらないので、
どうしても曖昧性の残る調達仕様書にならざるをえない。
しかし、一方で、システムに大きく影響を与えるような要件は、この段階で定義しえておかなければならない。
このあたりのさじ加減が、初期の要件定義の要といえる。
そのためにも、仮にパッケージを想定した開発を行うのならば、開発業者への発注前の要件定義フェーズ中盤
において、パッケージのデモ等で、複数のパッケージの特性を把握しておく必要がある。