1.機能の目的を明らかにしていく手法の普及

「木を見て森を見ず」ということわざがあります。
このことわざ、海外にも似た意味で使われるものがありますが、それを訳すると「木はしばしば森を隠す」となります。少し違った印象を受けますね。

この「木はしばしば森を隠す」という状況、システム開発で起こる状況にぴったりの言葉だと思いませんか？

システム開発に関わるほぼ全ての人が、「仕様書をしっかり書いて発注したのに、出来上がってみたら業務では使えなかった」という経験をお持ちだと思います。

システム開発をするときは、システムを欲しい人が作る人に対して伝えなければならない情報がとても多くなります。

そのため、自分の頭の中を上手く整理できず、大量の情報に埋もれてしまいがちです。すると、情報を伝えようとする過程で、「そもそも何のためにシステムが欲しかったのか」ということが薄れてしまったまま、欲しいものを伝えることになります。

例えると、ドリルを買おうとして性能に注目しすぎて、そもそもドリルを買う目的が穴を開けるためだったことを忘れてしまうのです。

これはまさに、「木はしばしば森を隠す」という言葉がぴったりの状況です。

これを避けるために、近年のシステム開発では、最初の工程である要件定義工程のなかで、「何を作るか」ということを決めるときに「誰が何をしたいのか、なぜそれが必要なのか」というシステムを利用する目的とともに整理を行うという取り組みが行われています。

具体的には、業務フロー図をはじめとするドキュメントで、システムの機能を業務の利用場面とともに洗い出し、それをもとに機能一覧を作成するといった活動です。

札幌市においても、基幹系システムの再構築のなかで、業務フロー図をはじめとするドキュメントの作成を行いました。

作成した業務フロー図のページ数は、約１万ページにものぼります。

私たちは再構築での経験を通して、要件定義工程で単に業務フロー図をはじめとするドキュメントを作成しただけ、あるいは、その表記法を標準化したりしただけでは上手くいかず、そこには気を付けるべきポイントがあることがわかりました。

また、要件定義をしっかり行い、それを維持することで、システム稼働後にも大きなメリットがあることも分かりました。

これらのノウハウは、ドキュメントの表記法によらず共通して活用いただけるものだと思います。

今回は、まず要件定義において業務フロー図をはじめとするドキュメントを作成する際に起こる問題と、その発生を防ぐために気を付けておくべきポイントについてお伝えします。

そして、要件定義をしっかり行い、それを維持することで得られるシステム稼働後のメリットについても記載します。

1.機能の目的を明らかにしていく手法の普及

はじめにお伝えしたように、要件定義において業務フロー図を記述する手法にはさまざまなものがあります。

これまで、自治体においては、総務省から示された「自治体EA 業務・システム刷新化の手引き」をもとに、業務分析で使われるドキュメントとして示されたWFA(※1)が活用されてきました。

近年では、国際的な動向や総務省から示された「電子自治体の取り組みを加速するための10の指針」（平成26年3月）においてBPMN(※2)の利用が推奨されていることから、今後はBPMNの活用が増えていくと考えられます。

札幌市では、基幹系システムの再構築で、これまでの連載で紹介したAIST包括FWで定義されている業務フロー図をはじめとするドキュメント活用した要件定義を行いました。

私たちが利用しているAIST包括FW札幌市版（平成22年策定）には、WFAの改良版が使われています。

改良版となっているのは、元々のWFAは定義が曖昧な部分などの問題点があるため、それらを解決するために記法を拡張したものになっているからです。

BPMNが注目されるようになった理由には、こうした問題点を解決するところにもあるようで、札幌市版より以降に使われているAIST包括FWのバージョンでは、業務フロー図としてBPMNにも対応していると聞いています。

図１は、私たちが作成した業務フロー図を説明用に簡略化したものです。

フローは上から下に進みます。左上の黒丸が業務の開始を表し、右下の黒二重丸が終了を表します。

このフローでは、「①住民が申請書を提出」、「②区役所の○○担当が受付」、「③区役所の○○担当がシステムを使って、申請書の内容を元に申請の登録を行い、証明書を出力」、「④区役所の○○担当が住民に証明書を交付」、「⑤住民は証明書を受け取り、担当者は書類を保管する」、という一連の業務の流れを表しています。]

AIST包括FWでは、この業務フロー図の他に、業務を構造化し分類した一覧表である「対象業務一覧」や、業務フロー図で表現しきれない判断条件や状態遷移などを記述する「業務ルール」、業務で使われる概念（情報）をクラス図で表した「概念モデル図」といったドキュメントから構成されています(表1)。