発注・外注の進め方
システム化の前に業務フローを整理する方法｜簡単な書き方と例
「業務をシステム化したい」と考えたとき、いきなり必要な機能や画面を考え始めると、今の業務とずれた仕組みになりがちです。その前に役立つのが、今の業務の流れを書き出して見える化することです。難しい図法を覚える必要はありません。発注者が自分たちで書ける、業務フローの整理の仕方を紹介します。
なぜシステム化の前に業務フローを整理するのか
- 必要な機能が見えてくる：流れの中のどこで、何を記録し、誰に渡すのかが分かる
- 効果が出やすい箇所が分かる：転記、確認待ち、探す作業など、手間が集中している箇所が見える
- 開発会社との認識がそろう：口頭の説明より、書いた流れのほうが正確に伝わる
- 社内の認識もそろう：部署や担当者によって、思っている流れが違うことに気づける
書き方の基本：「誰が・何を・次に誰へ」
業務フローは、次の3つの要素を一行ずつ書いていけば十分です。
| 要素 | 書く内容 |
|---|---|
| 誰が | 担当者や役割（受付担当、営業、責任者、取引先など） |
| 何をするか | 作業の内容と、使っている道具（Excel、紙、メール、電話など） |
| 次に誰へ渡すか | 作業の結果を、誰に、どの方法で渡すか |
書き方の例：注文受付の業務
考え方をつかむための例です（特定の企業の業務ではありません）。
【今の業務の流れ：注文受付】 1. 取引先 → FAXで注文書を送る 2. 受付担当 → FAXを受け取り、注文管理のExcelに転記する 3. 受付担当 → 在庫表（別のExcel）を開いて在庫を確認する ※ 在庫が足りない場合は、仕入担当に電話で確認する（例外） 4. 受付担当 → 取引先に、受付完了と納期をFAXで返信する 5. 受付担当 → 出荷担当に、出荷指示を紙で渡す 6. 出荷担当 → 出荷し、出荷日を紙に書いて受付担当に戻す 7. 受付担当 → 注文管理のExcelに出荷日を転記する 8. 経理担当 → 月末に注文管理のExcelから請求書を作る
このように書き出すだけで、「同じ内容を何度もExcelに転記している」「紙の受け渡しで情報が止まる」「在庫の確認が別のファイル」といった、手間が集中している箇所が見えてきます。
書き出すときの3つのコツ
今の流れを、ありのままに書く
「本来はこうするはず」ではなく、実際に行っている流れを書きます。現場で行っている回避策や、担当者ごとの違いこそ、システム化の際に重要な情報です。理想の流れは、別に書き出します。
例外に印をつける
「在庫が足りない場合」「急ぎの注文の場合」など、例外的なケースは本流と分けて書き、印をつけておきます。例外をすべてシステム化するかどうかは、後で頻度を見て判断します。
手間と待ちに印をつける
転記、確認、探す作業、承認待ちなど、時間がかかっている箇所に印をつけます。ここがシステム化で効果が出やすい候補になります。
整理した流れから、システム化の範囲を考える
書き出した流れをもとに、どこをシステムにするかを考えます。
- 印のついた箇所を一覧にする：転記、確認待ち、探す作業など
- 効果の大きい順に並べる：頻度が高い、ミスが起きている、時間がかかっている順
- 最初の版の範囲を決める：上位の箇所から、まとめて解決できる範囲を選ぶ
- 理想の流れを書く：システム化した後の流れを、同じ形式で書き出す
先ほどの例であれば、「注文を一度入力すれば、在庫の確認、出荷指示、出荷日の記録、請求の元データまでがつながる」状態が、理想の流れの候補になります。ただし、最初から全部を作る必要はありません。範囲の決め方はWebアプリ開発を小さく始めるには？で解説しています。
業務フローは相談資料になる
整理した業務フローは、そのまま開発会社への相談資料として使えます。要件メモと合わせて共有すれば、開発会社は業務の全体像を把握しやすくなり、見積もりの精度も上がります。要件メモのまとめ方はWebアプリ開発を依頼する前に準備するもの、要件の決め方は小規模開発の要件定義はどこまで必要？をご覧ください。
よくある書き出しのつまずき
流れが長くなりすぎる
業務全体を一度に書こうとすると、どこまで書けばよいか分からなくなります。まずは「受付から完了まで」「月末の締め」など、一つの業務の始まりと終わりを決め、その範囲で書きます。
担当者によって書く内容が違う
同じ業務でも、担当者によってやり方が違うことは珍しくありません。違いがあること自体が重要な情報なので、無理に一つにまとめず、「Aさんはこう、Bさんはこう」と書き分けておきます。どちらに揃えるかは、後で判断します。
理想の流れを書いてしまう
「本来は承認を経てから発注する」と書いても、実際には事後に承認していることもあります。システム化の要件を考えるには、実際の流れを知ることが欠かせません。理想は別に書くと決めておくと、ありのままを書きやすくなります。
書いた流れを確認してもらう
業務フローを書いたら、実際にその業務を担当している人に読んでもらい、抜けや違いがないかを確認します。
- 実際の順番と合っているか
- 書かれていない作業や、例外的な対応はないか
- 使っている道具（Excel、紙、メールなど）は正しいか
- 時間がかかっている箇所、困っている箇所はどこか
管理者が書いた流れと、現場の担当者が認識している流れが違うことは、よくあります。この確認の段階で見つかった違いこそ、システム化の前に解消しておきたい点です。
理想の流れを書くときの注意
今の流れを書き出したら、システム化した後の理想の流れも同じ形式で書いてみます。このとき、すべての作業をシステムに置き換えようとせず、「人が判断する部分」と「仕組みに任せる部分」を分けて書くのがポイントです。たとえば、注文内容の確認や例外への対応は人が行い、転記や集計、連絡は仕組みに任せる、といった分け方です。人の判断が必要な部分を残しておくと、現実的で使いやすい仕組みになります。
書きかけのフローのままで構いません
業務フローが途中まででも、担当者ごとにやり方が違っていても、そのままお送りください。Tailboneでは、箇条書きの流れや今使っているExcel・帳票をもとに、システム化で効果が出やすい箇所と、最初の版の範囲を一緒に整理します。
よくあるご質問
業務フローは図で書いたほうがよいですか？
図にすると全体像が分かりやすくなりますが、最初から図にこだわる必要はありません。箇条書きで流れを書き出し、必要に応じてそれを図にすれば十分です。開発会社に相談する段階では、箇条書きでも内容は伝わります。
部署ごとにやり方が違う場合は、どう書けばよいですか？
まずは部署ごとに、今のやり方をそのまま書き出します。そのうえで、共通にできる部分と、違いを残す必要がある部分を整理します。違いを残す場合は、システムでどう扱うか（設定で切り替える、部署ごとに画面を分けるなど）を検討します。
業務フローの整理を開発会社に手伝ってもらえますか？
依頼先によりますが、ヒアリングを通じて業務の流れを一緒に整理することは、要件整理の一部として行われることが多くあります。最初から完璧なフローを用意する必要はありません。