樹木は、健全な成長を促すためや安全を確保するといった目的で、剪定が行われます。

適切な時期に剪定を行うことで、綺麗な花を咲かせたり大きな実をつけたりします。

情報システム部門は、まさにこの剪定を行うのが重要な役割になります。

生い茂った木が森を隠してしまわないよう、枝葉の情報を剪定し、明るく見通しよく保つようにファシリテートしていくことが求められます。

3.1　違いを知り、事前に方向を整理しておく

これは、「2.1 業務マニュアルとして利用したくなる」ことの予防策です。

まずは、業務マニュアルとして耐えうるレベルの情報を記載したフローと、システム開発をする目的で作成するフローは作成する範囲も記述する情報量も大きく異なること、せっかくの機会だからという程度の認識ではできないものであるということを知ってください。

もし、業務マニュアルを含めた取り組みとするのであれば、それによって増加する作業量を見込んだ予算や人員、スケジュールなどを考慮した計画をたてるようにします。

プロジェクトが始まる前、できればシステム企画の段階で、システム構築の目的に絞った取り組みとするのか、業務の可視化・標準化を含めた取り組みとするのかを関係者で議論し、合意しておくようにします。

そして、プロジェクトがスタートした後は当初に決めた目的がぶれないようにプロジェクトをコントロールするようにします。

3.2　記載の粒度を揃え、会議をファシリテートする

これは、「業務フロー図をための話をしているのに、画面や帳票の話になる」ことへの予防策です。

既にお伝えしたように、業務フロー図はどの粒度でも記述することができます。ですから、作成する業務フローの粒度を揃えることとは別に、業務フロー図作成の目的と、そのために最適な粒度を考えることが重要になります。

ドキュメントを大量に作成するまえに、いくつか試行的に作成し最適な粒度を探っておくようにします。

「システム開発での業務フロー図の粒度」

業務のシステム化を決めるような場合に、適切な粒度の決め方としては、ハンドオフレベルという考え方が有用です。

ハンドオフというのは、ラグビーなどでボールを自分の手から離して他のプレイヤーにパスするような意味です。

通常の仕事の中でも、「今誰がボールを持っているんだ」という表現がありますが、仕事を自分の手から離してほかの人やシステムに手渡す単位で考えるということです。

業務の場合は、この仕事の手渡しするタイミングとしては、他の担当者に書類を送る、メールで指示する、書類を保存する、システムにデータを登録するといったものがあります。

その単位で作業を中断して席を離れたり、他の作業をしたりできるレベルの作業の大きさということもできます。

図5は、私たちの経験から、システムを開発するうえでの業務フロー図としての粒度を参考例として記載したものです。

AIST包括FWの業務フロー図は、次に続くシステムの要件定義工程のためのインプットとなるように位置付けされています。

このため、ハンドオフレベルの業務フロー図が、主として記述される業務フロー図のレベルになっており、システムが行う作業との境目、システム化する範囲が分かりやすくなっています。

業務フロー図の中でいうと、システムのレーンに業務を渡すところがシステム化の範囲となります。

「システム化する範囲を切り出すことに注力」

システムアクティビティをどこまで具体化するか、つまり、ハンドオフのレベルのフローより下のレイヤであるシステムの処理の具体化をどうするかについては、いろいろな考え方があります。

ひとつは、徹底的に細かいフローまで記述していって、自動化するところまで記述するという考え方です。

しかしながら、この場合は、開発レベルの知識がなければ記述できないため、自治体職員が見て判断できるレベルを超えてしまうことになります。

また、自動化には特定の製品を使用するため、強い業者依存が発生することにもなり、自治体で採用する場合には課題があります。

AIST包括FWでは、発注者主導のシステム開発を行うために、システム化されている範囲が業務のどの部分なのかについて、いつでも把握することが可能になっている状態、トレーサビリティを保つことを重要視しています。

そして、この状態を作り出すために、業務フロー図からシステム化部分を切り出しやすくすることを重要視しています。

システム化の単位が明確になると、その部分についての機能要件も明確になるので、それを調達仕様として競争入札により開発ベンダーに作ってもらうというアプローチがとれるようになります。

次工程となる基本設計工程では、業務フローで抽出したシステム化範囲であるシステムアクティビティに対して、１つまたは複数のユースケース（機能）として、ユースケース記述という形でシステムとユーザとのやり取りを文章化し、設計を進めていきます。

私たちのシステム開発では、この考え方を取り入れていることから、業務フロー図で抽出したシステム化範囲については、要件定義では、「ユースケース記述」の元になる概要レベルの情報、システムを使ってどんなことをするかを、5W1Hのレベルで洗い出すレベルで整理しています。

図5のシステムアクティビティを例にあげると「○○担当者が、○○申請の登録のために、申請書をもとに、申請者に○○の履歴ないことを確認後、申請を登録し、○○証明書を出力する。」といったレベルの情報になります。

「フロー図に始まりフロー図に終わる」

記載の粒度やレベルをイメージできたら、そのレベルを判断のものさしにして打ち合わせをファシリテートしていきます。

打ち合わせは、実際のフロー図をプロジェクタに移しながら、常に業務フロー図をベースに会話するようにします。具体的なイメージを持つために、画面や帳票のレイアウトを確認する場面が出てきますが、これらはあくまで、参考資料として映し出す程度にとどめ、これらを映しっぱなしにして打ち合わせが進まないように気を付けます。

些細な事のように見えるかもしれませんが、実際にやってみると打ち合わせの効率が大きく違うものです。