業務フローチャートの粒度

プロジェクト担当者の多くが頭を抱える問題、それが業務フローチャートの粒度についてです。

業務フローチャートを複数のメンバーで書き始めた場合、この粒度をはじめとした業務フローチャート品質のばらつきが必ず発生します。

これは参画する担当者の属性（所属する部門、その立場など）によって、業務フローチャートの粒度に対する認識が大きくことなることが原因となっています。

それではどのような場合に粒度が細かくなったり、粗くなったりするのか、またその場合の対処法について考えていきましょう。

業務フローチャートの粒度が細かすぎる場合

現場に近い担当者レベルの方が書いた業務フローチャートですが、どのシステムのどのメニューのどこどこを実行する、といったような細かい粒度で書いてしまう傾向にあります。特に情報システム部門の担当者の場合、「受信日付を確認して、フラグを0から1に変更して・・・」といった、オペレーションレベルの作業を細かく書いてしまいがちです。

業務可視化の目的がシステム導入前の要件定義であったり、限られたメンバー・属性で業務フローチャートを利用する場合には問題ないのですが、マニュアルや業務改善として利用する場合には、結果として見づらい業務フローチャートとなってしまいます。

粒度が細かすぎる場合の補正方法

細かすぎる、粗すぎる、といった偏りのない担当者、例えば事務局などが補正をしていきます。

具体的には、業務フローチャートを作成した担当者にヒアリングを行いながら、洗い出された細かいオペレーションレベルの作業をある程度の粒度にまとめあげていきます。（ある程度の粒度は後述）

基本的には業務が細かくも洗い出されている状態なので、事務局担当者の判断で次々とまとめあげていくだけで補正を進めていけます。

業務フローチャートの粒度が粗すぎる場合

非常に細かい業務フローチャートを書く方がいる一方、非常に粗い業務フローチャートを書く人も出てきます。

傾向としては立場が上の管理者・責任者の場合が多く「大体こんな感じでやっています」というような書き方になるのが特徴です。

ひどい場合には作業図形１つに対して、文章のように作業名がかかれていることもあります。

粒度が粗すぎる場合の補正方法

粒度が細かった先ほどの例とは対照的に、必要な情報がすべて洗い出されていない可能性が高いので、業務に抜け・漏れがないか最新の注意を払う必要があります。

進め方としては、同じく事務局担当者がヒアリングを通じて１つ１つ細かく聞いていく他ありません。

ポイントとしては、その業務のトリガーに注目すると良いでしょう。発生トリガー、パターンを軸に、どこから発生し、どのような作業があるのかを１つ１つ聞いていきます。

よくありがちなヒアリングの落とし穴「状況・場合によって・・・」

業務をよく知っている方にヒアリングを行った場合にありがちな落とし穴があります。それは、業務をヒアリングしていくと「状況による」「場合による」といった回答です。いわゆる例外処理なのですが、よく業務を経験されているからこそ出てくる情報です。

ここに落とし穴があります。

それは、これらの事象を１つ１つの業務フローチャートとして起こさないことです。

ましてや、条件分岐などですべてのパターンを表現してはいけません。

よくありがちなのが、個社別対応の業務をフローチャートとして落としこんでしまったり、状況に応じた対応などを、判断図形を使用して条件分岐で全パターンを表現してしまうのですが、これはせっかく簡潔で視覚的に理解できる業務フローチャートの特性をすべて台なしにしてしまいます。

ついつい、業務をよく知っている方＝立場が上の方が話した内容はすべて業務フローチャートとして落とし込まなければならない心境になりがちですが、そこはぐっと抑えて、業務フローチャート本来の視認性を優先させ、細かい情報は業務フローチャートに展開せず、別途詳細情報として記載しましょう。

業務フローチャートの正しい粒度とは

業務フローチャートを作成する目的によって、正しい粒度というのは異なります。なので残念ながらコレといった正解はありません。

しかし、ある程度の基準をルールとして定めることで、業務フローチャートの粒度を近づけることができます。

担当者が変われば図形を分ける

作業する担当者が変ったときに、別の図形で表現するというルールを定めることで、わかりやすい業務フローチャートに仕上がります。

業務フローチャートを見る人の多くは、どれかの担当者の目線で評価する場合がほとんどで、その担当者の区切りが明確になることで、ほかの担当者の作業を区別して自分の知りたい業務を集中して評価することができます。

対象の帳票やデータが変われば図形を分ける

入力、確認、照合など、処理の対象物が変わるタイミングで図形を分けるのも効果的です。

特にマニュアルとしての業務フローチャート作成を目的とした場合ですが、作業・処理の対象物が複数混在していたり、入れ替わると混乱してしまいます。

対象を固定して表現してあげると、頭の中で思い描くイメージがすっきりし、理解しやすくなります。

一連の入力作業などは図形を”分けない”

上記とは対照的に、図形を分けないルールも必要です。

それは上記のルールのいずれにも該当せず、一連の処理となる場合です。

例えば、「お客様属性の確認」という作業「1.顧客情報確認」「11.条件抽出」「112.お客様属性」といった画面遷移などのオペレーションが該当します。

システムの要件定義を目的とした場合は図形を分けるべきかもしれませんが、業務の把握レベルであれば「お客様属性の確認」といった図形１つにまとめてしまうほうが利便性が高まります。

細かい情報はメモやコメントなど、別途記載しておくことで、必要なときに取りだせる情報として利便性を損なうことなく活用できます。