4. 要件定義はシステム稼働後も活用できると二度おいしい
要件定義のドキュメントは、システム稼働後も最新状態を維持することにより、システム稼働後にもそのメリットを享受することができます。
1つは業務所管部門が気づきにくい影響範囲をシステム部門が確認してアドバイスできるようになるということ、もう1つは、システム部門を悩ませる制度改正による仕様変更の際の業務部門の「決まっていない」を「決まっている」に変える力があることです。
この2つのメリットは、これまで仕様変更での立ち位置が曖昧だった情報システム部門の重要な役割になると考えています。
自治体の情報システム部門を悩ますこととして、近年、制度改正による仕様変更の際に、業務部門やその上位機関からの情報が提示されるのが遅くなり、契約や着手が遅れるといったシステム開発にしわ寄せが行くということで皆さんも苦労されていることと思います。
「システム部門が影響箇所を把握する」
表1で紹介したAIST包括FWで作成したドキュメントは、相互にトレーサビリティが確保されています。
ユースケース一覧などのドキュメントを使うことで、ユースケースがどの業務フローに登場するのか、取り扱う情報や関連する業務ルールはどれかといったことを双方向で確認できるようになっています。
これによって、制度改正などでシステムを改修する場合に、業務が分からないシステム部門の人でも、業務部門からの情報をきっかけに、他の影響のある業務や機能を影響範囲の候補として抽出し、アドバイスすることができるようになります。
図6はその手順を説明用に簡略化したものです。まず、制度変更の内容から思いつく影響箇所について、開発時に作成した要件定義のドキュメントを見ながらあげていきます。
事前に業務フロー図を渡して、影響のありそうな箇所に印をつけてもらうといった方法が有効です。
慣れてくると、沢山の箇所に印がついてきますが、最初の段階は、実際に利用している帳票や帳票に記載される項目が中心になりがちです。
どのような場合でも、ドキュメント間のトレーサビリティを活用することで、あがってきた箇所を起点に対象となるユースケースや業務ルールなどをみつけることができます。
それらについて、どのような変更が必要かを整理していきます。
制度改正の場合は、ユースケースが扱う情報項目の追加・削除や業務ルールに記載された計算方法などが変更となる場合が多くなります。
そして、ここまで洗い出した影響と変更内容を起点に、ユースケースが扱う情報項目などを使い、関連して影響の受けるユースケースをみつけ、あとは同様に、どのような変更が必要かを整理していきます。
ここで注意が必要なのは、影響範囲を整理する際に、必ず業務フロー図を使って利用場面をみながら検討を行い、最終的な確認を行うようにします。
影響範囲として抽出したユースケースは、複数の業務フロー図に登場することがあります。
言い換えると、複数の業務の利用シーンで使われているということになります。この場合、ユースケースだけに着目して変更を考えると、特定の利用場面だけを想定した仕様となり、他の利用場面では使えないということが起こり得ます。
ですから、登場するそれぞれの業務フロー図を参照し、全ての業務シーンで問題ないか、業務の利用場面に沿っているかを確認するようにします。
実際にやってみっところ、業務部門だけで影響範囲を検討してもらった場合は、金額の計算方法の変更といった主となる変更部分は影響範囲として出てきやすいのですがが、保険料の計算結果を元に行われる集計や統計等の機能は気づきにくく漏れやすいということがわかりました。
こういったノウハウを情報システム部門で持っておくことで、業務を知らないシステム部門の担当者においても、業務所管部門に対し抜け漏れを減らすための影響範囲のアドバイスという価値を発揮することができるようになります。
「決まっていないは本当?」
図7は、「決まっていなくて、今はこれだけしか情報が出せない」と業務部門から提示のあった情報と、私たちが図6の手順によって影響のありそうな機能の候補を抽出し、それをもとに業務所管部門にヒアリングを行って得られた影響のある機能の一覧です。
一部のみの紹介となりますが、2行の文書だったものが影響のある機能一覧に変わりました。
このように、決まっていないという制度改正について、要件定義で作成したドキュメントを使用してヒアリングをしていくと、機能についての詳細が決まっていないだけで、影響のある機能の範囲というレベルでは特定でき、仕様変更の要件定義を行うことができる場合があることがわかりました。
業務部門が言う「決まっていない」は、「機能をどのように直さなければならないか」であって、「どの機能を直さなければならないか」という影響範囲のレベルでは決まっているということがあります。
影響範囲が見えていると、不確定要素の含まれる範囲を含めて発注するのか、その部分は切り出して別途追加発注するのかという判断が可能となり、制度が決まらないから開発に着手できずに工期が足らなくなるという、システム開発へのしわ寄せを減らすことができます。
まだ新システムが稼働してから間もなく、十分な事例を得られているとは言いがたい状況ですが、既にいくつか効果が得られています。
今後は、制度改正のパターンによって、効果の度合に差があるのかといったと点などについてもより的確な予想ができるようになると考えています。
「おわりに」
システム再構築のような短期間で大規模な開発を進めるためには、急激に増える人員にどのように即戦力となってもらうか、また、長期的に次世代の情報システム部門を担う人材の育成が重要となります。
次回は、この内容をテーマに、札幌市取り組みをお伝えする予定です。