要件定義

業務フローの基本的な書き方 業務フローは要件定義の重要なツール!

記事内に商品プロモーションを含む場合があります

業務フローの書き方がわからない?
業務フローを書く前にやるべきことは?
業務フローの基本的な書き方が知りたい。

要件定義を行う時、業務フローは重要なツールとなります。それだけに業務フローの基本はしっかり身に付けたいものです。

業務フローの基本を理解しないまま、過去の事例やネット上のサンプルをもとに自己流で作成していると、後々大きな失敗をしてしまうかもしれません。

ここでは、初めて業務フローを書く方が知っておくべき基本的な書き方をわかりやすく解説します。少しでも要件定義の参考になれば幸いです。

なお、業務をマニュアル化したい方、業務引き継ぎのため手順を整理したい方など、システム開発をしない方でも参考になると思います。よろしければお読みください。

業務フローとは

業務フローは、業務のプロセスを可視化したもので、関連する前後のプロセスを矢印でつなぐことで業務の流れを直感的に理解できる図のことです。

要件定義では、システム化対象の業務を理解することから始まります。

図式化した業務フローを作成することで、お客様との認識合わせが容易になり、理解の食い違いを防ぐことができます。

業務フローのメリットをまとめると以下になります。

業務フローのメリット
  • 現状の業務の流れが可視化され、客観的に評価できる。
  • 業務プロセスの流れに無駄な作業や処理がないかを確認できる。
  • 部門をまたがってプロセスを整理でき、事業や業務のあるべき姿を検証できる。
  • 業務の手順を理解しやすくなり、業務マニュアルや業務引き継ぎに利用できる。

業務フローを書く前の準備

業務フローを書く前に準備が必要です。これらを怠ると、出来上がった業務フローが使い物にならない事態を招くのでしっかり準備しましょう。

業務フローの記号を決めて凡例を書く

フローチャートの記号はいろいろな団体が標準を設けていますが、重要なのは記号を予め決めて統一することです。自分の会社内で標準化されている場合はそれを利用すればいいですし、プロジェクトの特性にあわせて記号を見直しても問題ありません。

何よりも配慮すべきことは、お客様(ユーザー)が業務フローを見て理解しやすい表現を心掛けることです。

パッと見て意味が分からない記号を使うよりも、画面はパソコンをイメージした画像にする、メールでやり取りする場面はメールのアイコンを付ける、など工夫すると直感的に理解しやすくなります。

また、決めた記号は業務フローの補足として凡例を記載し、お客様(ユーザー)に業務フローを説明する時は記号の説明から始めましょう。

記号の凡例

業務フローを記述する上で、定義しておくとよい記号を列挙しました。
あくまでも一つの事例として参考にしてください。上述の通り、皆さんのプロジェクトに合った記号を選択してご活用ください。

記号意味説明
開始業務プロセスの開始を表す
終了業務プロセスの終了(完了)を表す
分岐・合流作業の分岐や合流があるポイントを表す
分岐の条件も記載する
作業人による作業を表す
システム作業システムを利用する作業を表す
システム機能利用されるシステムの機能を表す
画面利用される画面を表す
具体的な画面名を記述する
帳票利用される帳票を表す
具体的な帳票名を記述する
データ利用されるデータを表す
具体的なデータ名を記述する
作業の流れ作業を矢印でつなげて作業間の順序を表す
データの流れデータを矢印でつなげて情報の順序を表す
結合子同一ページ内で矢印のつながりを表す
記号の中に文字(例で1を記述)を入れる
※同じ文字同士がつながる
他ページ結合子ページまたがりの矢印のつながりを表す
記号の中に文字(例でAを記述)を入れる
※同じ文字同士がつながる

業務フローの粒度を合わせる

粒度とは、業務フローを書く細かさを表現した言葉です。

作業を大括りにして書いたり、システムの操作手順のように細かく作業を分割して書いたり、人によって書き方が異なります。そのため、業務フローを作成する作業に入る前に、あらかじめ粒度を決めておく必要があります。

お客様(ユーザー)の作業を「どのようにするか」の観点で書くと操作手順のように細かくなるため、その業務プロセスでは「何をするのか」という観点で作業を洗い出すことが大事です。

粒度をあらかじめ定義するのが難しい場合、粒度を揃える方法として、どの業務であっても必ずA4用紙1枚に収まるように作成するルールを作るのも1つのアイデアです。そうすることで細かくなりすぎるのを防止できますし、無理に1枚に収めたことで作業の粒度が荒くなった場合は、その作業を詳細にした業務フローをもう1つ作成すればいいだけです。

粒度が揃うと、とても見やすい業務フローになりますので、作成者によって業務フローの粒度が異なることがないように事前に粒度を合わせましょう。

業務フローを書く時のポイント

業務フローを書く時のポイントを紹介します。

登場人物の部門名と役割を確認する

業務フローの登場人物を洗い出します。

登場人物は部門名だけではなく、その役割(ロール)も確認しましょう。 責任者であれば承認行為を行う役割があるでしょうし、データを照会だけする人やデータを更新する人など、様々な役割がありますので区別する必要があります。

スイムレーンを書く

業務フロー上に登場人物を配置する時は、登場人物の作業範囲を明確にするために縦軸もしくは横軸を区切ってスイムレーンを作ります。

また、システム化業務フロー(システムを利用した場面を書き込んだフロー図)の場合は、システムのスイムレーンも記述します。

※1枚の用紙をプールに見立て、選手が泳ぐレーンを区切っているイメージからスイムレーンと呼ばれています。

スイムレーンを縦軸にするか横軸にするか決める

注文受付業務を非常に簡易にした業務フローの例です。

図の左側がスイムレーンを縦軸にしたもの、右側がスイムレーンを横軸にしたものです。なお、業務内容は左右とも同じです。

スイムレーンを縦にするか横にするかは自由ですが、業務フローがスイムレーンの方向に流れるように書くため、仕上がりをA4縦にする場合はスイムレーンを縦軸に、A4横にする場合はスイムレーンを横軸にするのが良いかと思います。
※画像をクリックすると拡大表示されます。

左上から右下に流れるように書く

人の視点は上から下、左から右に流して全体を見ますので、左上が一番最初に取り組む作業で、右下が最後に取り組む作業となるように配置するのが理想です。

スイムレーンの配置によってそうならない場合もありますが、少なくとも時間の流れを遡ることがないようにしましょう。

開始と終了を書く

業務プロセスの開始終了が分かるように、それぞれの記号を決めて業務フローに明記しましょう。

上述の凡例のように開始と終了の記号を決めておくと、業務フローを見た時に業務のスタート地点を探すことが無いですし、業務が終わるプロセスが明確になります。

また、その業務が開始される条件終了(完了)する条件もあわせて確認することで業務要件が明確になります。

矢印は出来るだけ交差しないように書く

複雑な業務フローは矢印が多くなります。気をつけないと矢印が交差して重なり、矢印がどちらの方向に進むのか見にくい業務フローになってしまいます。

矢印は必ず記号と記号の間をつなげて、他の矢印と重ならないように書きましょう。どうしても重なる場合は3本以上が重ならないように工夫しましょう。

インプットとアウトプットを意識して書く

作業の開始には何かしらのきっかけがあります。つまり、インプットがあるわけです。注文業務であれば、お客様からの電話やメールでの注文連絡、FAXの注文書などがあるはずです。

また、作業の終了も同様で、何かしらのアウトプットをして終了します。例えば出荷業務で伝票を発行して完了するのであれば、その伝票がアウトプットになります。

業務フローの作業を記述する時は、その作業のインプットは何か、アウトプットは何かを常に意識して明確にしましょう。

分岐する条件を見逃さない

作業の流れが複数ある場合は分岐記号をつけて流れを分けて記述します。

そして、分岐する時は必ず条件があります。

例えば「在庫商品を受注した時は出荷して終了するが、取寄せ商品だった場合は仕入先に発注する業務がある」ということであれば、受注する商品の在庫状態が条件となって作業が分岐することになります。

このように、作業の開始時点や終了時点で分岐したり、午前・午後などの時間帯季節による違い、または複数条件が絡むこともありますので見逃さずに確認しましょう。

業務フローは要件定義の重要なツール

最後に、繰り返しになりますが、業務フローのメリットを記載します。

業務フローのメリット
  • 現状の業務の流れが可視化され、客観的に評価できる。
  • 業務プロセスの流れに無駄な作業や処理がないかを確認できる。
  • 部門をまたがってプロセスを整理でき、事業や業務のあるべき姿を検証できる。
  • 業務の手順を理解しやすくなり、業務マニュアルや業務引き継ぎに利用できる。

少し視点を変えて見ると、これらは要件定義の目的そのものであり、業務フローは重要なツールであると言えます。それだけに、業務フローの書き方の基本を理解することが、要件定義をマスターするための第一歩となります。

それでは、業務フローの基本が理解できたあとは、何に気をつけるべきでしょうか?

それは、漏れなく業務フローを作成することです。

こちらで「3つの階層で業務を漏れなく書く方法」を解説していますので、あわせてお読みください。

もし要件定義に少しでも不安がある方は、要件定義の記事をまとめていますので、こちらもあわせてお読みください。要件定義が計画通りに完了することを願っています。

失敗しない要件定義の進め方!失敗事例と7つのポイントを解説システム開発において、スケジュールが遅れる主な原因のうち、50%以上が要件定義の不備に起因すると言われています。プロジェクトの成否は要件定義で決まると言っても過言ではありません。要件定義は、「企画構想」「要求定義」「要件定義」の3つのステップで進めていきます。いきなり要件定義に着手するわけではありません。要件定義を正しく進めるためには、そのインプットとなる要求定義を理解する必要があり、さらに要求定義のインプットである企画構想も正しく理解しなければなりません。ここでは、システム開発における要件定義について、要件定義の目的と進め方、失敗事例と失敗しないための7つのポイントをわかりやすく解説します。少しでも要件定義の参考になれば幸いです。...
ABOUT ME
hidechi
メーカーに入社し、その後IT部門が分社独立、情報システムエンジニアとして30年以上勤務しています。これまで多くのプロジェクトに携わり、それらの経験から得た知見を覚え書きとして記録することで、厳しい現場で奮闘しているSEの皆さんの一助となれば幸いです。
関連記事はこちら