4. 要件定義はシステム稼働後も活用できると二度おいしい

要件定義のドキュメントは、システム稼働後も最新状態を維持することにより、システム稼働後にもそのメリットを享受することができます。

1つは業務所管部門が気づきにくい影響範囲をシステム部門が確認してアドバイスできるようになるということ、もう1つは、システム部門を悩ませる制度改正による仕様変更の際の業務部門の「決まっていない」を「決まっている」に変える力があることです。

この2つのメリットは、これまで仕様変更での立ち位置が曖昧だった情報システム部門の重要な役割になると考えています。

自治体の情報システム部門を悩ますこととして、近年、制度改正による仕様変更の際に、業務部門やその上位機関からの情報が提示されるのが遅くなり、契約や着手が遅れるといったシステム開発にしわ寄せが行くということで皆さんも苦労されていることと思います。

「システム部門が影響箇所を把握する」

表1で紹介したAIST包括FWで作成したドキュメントは、相互にトレーサビリティが確保されています。

ユースケース一覧などのドキュメントを使うことで、ユースケースがどの業務フローに登場するのか、取り扱う情報や関連する業務ルールはどれかといったことを双方向で確認できるようになっています。

これによって、制度改正などでシステムを改修する場合に、業務が分からないシステム部門の人でも、業務部門からの情報をきっかけに、他の影響のある業務や機能を影響範囲の候補として抽出し、アドバイスすることができるようになります。

図6はその手順を説明用に簡略化したものです。まず、制度変更の内容から思いつく影響箇所について、開発時に作成した要件定義のドキュメントを見ながらあげていきます。

事前に業務フロー図を渡して、影響のありそうな箇所に印をつけてもらうといった方法が有効です。

慣れてくると、沢山の箇所に印がついてきますが、最初の段階は、実際に利用している帳票や帳票に記載される項目が中心になりがちです。

どのような場合でも、ドキュメント間のトレーサビリティを活用することで、あがってきた箇所を起点に対象となるユースケースや業務ルールなどをみつけることができます。

それらについて、どのような変更が必要かを整理していきます。

制度改正の場合は、ユースケースが扱う情報項目の追加・削除や業務ルールに記載された計算方法などが変更となる場合が多くなります。

そして、ここまで洗い出した影響と変更内容を起点に、ユースケースが扱う情報項目などを使い、関連して影響の受けるユースケースをみつけ、あとは同様に、どのような変更が必要かを整理していきます。

ここで注意が必要なのは、影響範囲を整理する際に、必ず業務フロー図を使って利用場面をみながら検討を行い、最終的な確認を行うようにします。

影響範囲として抽出したユースケースは、複数の業務フロー図に登場することがあります。

言い換えると、複数の業務の利用シーンで使われているということになります。この場合、ユースケースだけに着目して変更を考えると、特定の利用場面だけを想定した仕様となり、他の利用場面では使えないということが起こり得ます。
ですから、登場するそれぞれの業務フロー図を参照し、全ての業務シーンで問題ないか、業務の利用場面に沿っているかを確認するようにします。

実際にやってみっところ、業務部門だけで影響範囲を検討してもらった場合は、金額の計算方法の変更といった主となる変更部分は影響範囲として出てきやすいのですがが、保険料の計算結果を元に行われる集計や統計等の機能は気づきにくく漏れやすいということがわかりました。

こういったノウハウを情報システム部門で持っておくことで、業務を知らないシステム部門の担当者においても、業務所管部門に対し抜け漏れを減らすための影響範囲のアドバイスという価値を発揮することができるようになります。