業務フローの粒度はどう決める？細かすぎ・粗すぎを防ぐ基準

業務フローの粒度は、図を作る目的に合わせて決めます。改善点を探す図なら「1つの担当者が、確認できる1つの成果を出す単位」を1ボックスの目安にすると、細かすぎ・粗すぎを防げます。経営向けの全体像、部門間の改善、作業マニュアルでは必要な細かさが異なるため、最初に閲覧者と用途を決めることが重要です。

粒度	表す範囲	主な用途	ボックス数の目安
レベル1	事業・業務全体	経営層への説明、全体構造の共有	全体で5～15個程度
レベル2	部門をまたぐ主要プロセス	役割分担、滞留、手戻りの分析	1プロセス10～30個程度
レベル3	担当者の具体的な作業	マニュアル、システム要件、標準化	必要な画面・入力単位まで

ボックス数は絶対的な基準ではなく、読みやすさを確認するための目安です。1枚に収めるために必要な情報を削るのではなく、レベルを分けて親フローと詳細フローへ分割します。

業務フローの粒度を決める5つの基準

1. 担当者が変わる：引き継ぎや責任の境界が生まれるため、別の作業に分けます。
2. 判断が発生する：結果によって次の処理が変わる場合は、判断と分岐を示します。
3. 入力・成果物が変わる：帳票の作成、システム登録、承認結果など、確認できる成果ごとに分けます。
4. 待ち時間が発生する：承認待ち、顧客回答待ち、夜間処理待ちなどは改善対象になるため、隠さず記録します。
5. 改善策が異なる：自動化、廃止、統合など別々の改善判断が必要な作業は分けます。

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

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

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

 

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

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

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

Advertisement

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

細かすぎる・粗すぎる業務フローの見分け方

状態	よくある症状	修正方法
細かすぎる	クリック、キー入力、画面移動が大量に並ぶ	同じ担当者が連続して行い、1つの成果になる操作をまとめる
粗すぎる	「申請処理」「顧客対応」だけで担当や判断が分からない	担当変更、判断、成果物、待ち時間の位置で分ける
粒度が混在	部門全体の工程と個別操作が同じ階層に並ぶ	親フローと詳細フローを分け、相互参照を付ける

粒度を確定する前のチェックリスト

• この図で誰が何を判断するか説明できるか
• 同じ階層のボックスが同程度の大きさか
• 担当者が変わる箇所を省略していないか
• 例外、差し戻し、待ち時間が見えるか
• 1つのボックスに複数の成果物を詰め込んでいないか
• 詳細が必要な箇所を別フローへ展開できるか

業務フローと作業手順書は同じ粒度ですか？

同じではありません。業務フローは担当者間の流れや判断を把握する図、作業手順書は画面操作や入力ルールを再現する文書です。業務フローを過度に細かくせず、必要なボックスから手順書へリンクする形が管理しやすくなります。

Advertisement

Advertisement