業務フローは、どこまで描けばいいのか

「これで、業務フローと言えるのか」

業務フローを描いていると、こんな迷いに直面することがあります。「注文を受ける」というひとつの箱で済ませていいのか、それとも「注文内容を確認する」「在庫を確認する」「承認を得る」というように、細かく分解すべきなのか。

「要件定義の落とし穴――SEが『機能』に焦ると、何を見失うのか」で、SEが機能に焦ることの弊害についてお伝えしましたが、業務フローの作成にも、これと似た性質の悩ましさがあります。細かく描きすぎても、粗く描きすぎても、問題が生じるのです。

今回は、業務フローを描く際に、避けて通れない「粒度」という問題を整理します。

粒度の悩ましさは、業務フローに特有のもの

業務フローとは、業務がどのような順序で、誰によって、どう進んでいくのかを図示したものです。「要求と要件を分ける意味」でお伝えした「要求と要件」の関係と同じように、業務フローにも、抽象度の異なる複数のレベルが存在します。

「受注処理」という大きな箱ひとつで表現することもできますし、「注文を受け付ける」「在庫を確認する」「与信をチェックする」「出荷指示を出す」というように、細かく分解して表現することもできます。どちらも、間違いというわけではありません。しかし、この「どこまで細かく描くか」という判断が、業務フロー作成における最大の悩みどころになります。

粒度が粗すぎると、業務フローを見ても、実際に何が行われているのかが分かりません。「受注処理」という箱だけでは、その中にどんな業務が隠れているのか、読み取ることができず、後工程での見落としにつながります。

一方で、粒度が細かすぎると、業務フロー全体が膨大になり、かえって全体の流れが見えにくくなります。すべての操作をひとつひとつ書き出そうとすると、業務フローという「地図」としての役割を失い、単なる作業手順書になってしまいます。

粒度は、目的によって分ける

この悩ましさに対する、ひとつの答えは、「粒度は、その業務フローを何のために使うのかという目的によって、使い分けるべき」ということです。

たとえば、経営層に業務全体の流れを説明するための業務フローであれば、粗い粒度で十分です。「受注」「製造」「出荷」「請求」という大きな流れが見えれば、その目的は達成されます。

一方、現場のオペレーターに対して、システムの操作手順を伝えるための業務フローであれば、粒度は細かくなければ意味がありません。「画面のどのボタンを押すか」「どの項目に何を入力するか」というレベルまで踏み込む必要があります。

同じ「受注業務」という対象であっても、誰に何を伝えるためのフローなのかによって、適切な粒度はまったく異なります。ひとつの業務フローで、すべての目的を兼ねようとすると、粗すぎるか細かすぎるか、どちらかに偏ってしまい、結果として誰にとっても使いにくいものになります。

要件定義の現場では、複数の粒度の業務フローを、目的別に使い分けることが、現実的な解決策になります。全体像を示す粗いフローと、詳細な業務手順を示す細かいフローを、別々に用意するという発想です。

表記法も、使い分ける

粒度と並んで、業務フローには「どう描くか」という、表記法の選択という論点もあります。

業務フロー図の表記法として、BPMN(Business Process Model and Notation)という国際標準があります。BPMNは、業務プロセスの分岐、並行処理、例外処理、複数の担当者(スイムレーン)をまたぐやり取りなどを、厳密なルールに基づいて表現できる、非常に体系的な記法です。複雑な分岐や例外処理も、BPMNであれば正確に表現できます。

しかし、ここで注意しておきたいことがあります。すべての業務フローを、最初からBPMNで厳密に描く必要はない、ということです。

BPMNには、明確なメリットがあります。表記のルールが標準化されているため、開発チーム内での認識のズレが起きにくく、複雑な分岐や例外処理も漏れなく表現できます。最終的にシステムを設計する段階では、この厳密さが大きな価値を持ちます。

一方で、デメリットもあります。BPMNの記法を正しく理解していない相手にとっては、記号やルールが多く、かえって読みにくいものになりがちです。また、厳密に描こうとすればするほど、作成にも時間がかかります。（顧客のみならず、実際には全ての開発プロジェクトで利用されていないので、エンジニアのBPMN学習コストが必要なケースもあります。）

たとえば、顧客とのヒアリングを始めたばかりの段階を考えてみてください。この段階で必要なのは、大まかな業務の流れを、顧客と一緒に確認することです。ここでBPMNの正式な記法を持ち出して、スイムレーンやゲートウェイの記号を厳密に使い分けようとすると、顧客にとっては読み解くこと自体が負担になり、本来の目的である「認識合わせ」が、かえって進まなくなってしまいます。

極端に言えば、初期段階から表記の厳密さにこだわりすぎることは、SEの自己満足になりかねません。「正しい記法で描けている」という満足感と、「顧客と正しく認識が合っている」という実質的な成果は、必ずしも一致しないのです。

業務フローの表記法は、粒度と同じように、目的に応じて使い分けるべきものです。ヒアリングの初期段階では、シンプルな箱と矢印だけの、誰にでも読める図で十分です。要件定義が進み、システムの詳細設計に近づいていく段階になって初めて、BPMNのような厳密な記法に移行する。この段階的な使い分けが、実務上、もっとも現実的なアプローチです。

要求と要件で、粒度を変える

粒度の使い分けは、目的だけでなく、要件定義のプロセスにおける段階によっても、変える必要があります。

「要求と要件を分ける意味」でお伝えたとおり、要件定義には要望・要求・要件という段階があります。この段階に応じて、業務フローの粒度も変わるべきです。

要求のレベルでヒアリングをしている初期段階では、業務フローは粗くて構いません。「受注してから出荷するまでの、大まかな流れを教えてください」という問いに対して得られる業務フローは、大きな箱をいくつかつなげた程度のもので十分です。この段階で細部にこだわりすぎると、全体像を把握する前に、局所的な話に迷い込んでしまいます。これは、「要件定義の落とし穴――SEが『機能』に焦ると、何を見失うのか」でお伝えした「機能に焦る」ことの弊害と、根本的に同じ構造です。

一方、要件のレベルまで話が進み、実際にシステムとして何を作るのかを詰めていく段階になると、業務フローの粒度は、必然的に細かくなっていきます。「誰が」「何を」「どのタイミングで」という要件を定義するためには、粗い業務フローのままでは情報が足りません。

つまり、要件定義が進むにつれて、業務フローも粗いものから細かいものへと、段階的に精緻化されていくべきものです。最初から細かく描こうとしたり、逆に最後まで粗いままで済ませようとしたりすることが、粒度に関する典型的な失敗パターンです。

粒度がバラバラだと、何が起きるか

粒度に対する意識が不足していると、実務上、どのような問題が起きるでしょうか。

もっともよくあるのが、ひとつの業務フローの中で、粒度がバラバラになってしまうケースです。ある工程は「受注処理」という大きな箱で表現されているのに、別の工程は「在庫を確認し、在庫がなければ発注担当者にメールを送り、発注担当者が仕入先に連絡する」というように、極端に細かく描かれている。こうした業務フローは、読み手にとって非常に読みにくいものになります。

粒度がバラバラになる原因の多くは、ヒアリングの中で、たまたま詳しく聞けた部分と、あまり聞けなかった部分の差が、そのまま業務フローに反映されてしまうことです。詳しく聞けた部分は自然と細かく描かれ、聞けなかった部分は粗いまま残ってしまいます。

これを防ぐには、業務フローを描き終えた後、一度全体を見渡して、粒度の水準を意識的にそろえる作業が必要です。細かく描かれすぎている部分は、上位の箱としてまとめ直し、粗すぎる部分は、追加のヒアリングによって埋めていく。この調整作業を経て初めて、業務フローは「読める地図」としての機能を持つようになります。

まとめ

業務フローの粒度は、悩ましい問題です。細かく描きすぎても、粗く描きすぎても、それぞれ別の問題が生じます。

粒度は、その業務フローを何のために使うのかという目的によって、使い分けるべきです。経営層への説明用であれば粗く、現場のオペレーター向けであれば細かく、というように、目的に応じて描き分けることが現実的な解決策になります。

表記法についても、同じことが言えます。BPMNのような厳密な記法は、システム設計に近づく段階では大きな価値を持ちますが、ヒアリングの初期段階から使う必要はありません。むしろ、厳密さにこだわりすぎることは、SEの自己満足になりかねません。状況に応じて、シンプルな図と厳密な記法を使い分ける柔軟さが求められます。

また、要件定義のプロセスが進むにつれて、業務フローも粗いものから細かいものへと、段階的に精緻化されていくべきものです。最初から細かく描きすぎたり、最後まで粗いままにしたりすることが、典型的な失敗パターンです。

粒度がバラバラな業務フローは、読み手にとって使いにくいものになります。描き終えた後、全体を見渡して粒度をそろえる作業を、意識的に組み込むことが重要です。