業務の流れを図にする：システム化の前に整理すること

業務をシステムにしようと考えたとき、開発会社から最初に頼まれることの一つが「今の業務の流れを教えてください」です。口で説明すると、話す人によって順番が入れ替わったり、例外の扱いが抜けたりします。そこで役に立つのが、業務の流れを1枚の図にしておくことです。

ただ、「業務フロー 書き方」と調べると、記号の意味や作図ツールの使い方の説明がたくさん出てきます。記号を正しく使えても、システムを作る人にとって大事なことが抜けていれば、図は役に立ちません。

この記事は、これから業務システムを作る、または作り直す会社の担当者に向けて書いています。目的は、きれいな図を描くことではなく、開発会社が読んで、作るものと費用を考えられる図にすることです。次のことを順にまとめます。

• システム化の前に図にする理由
• 記号を5つに絞った書き方
• 書く前の準備と、7つの手順
• 開発会社に渡す前に書き足すこと
• そのまま使える型紙と、つまずきやすい所

結論：きれいさより、抜けがないこと

先に結論です。システム化の前に作る業務の流れの図は、次の3つがそろっていれば十分です。

1. 誰が何をするかが、担当ごとに分かれている。 営業、事務、倉庫、お客様、今使っている Excel など、作業をする人や場所ごとに列（レーン）を分けて書く。
2. 紙やデータの受け渡しと、図にしにくい作業まで書いてある。 転記、確認の電話、差し戻し、急ぎの割り込みなど。
3. 件数と時間が書き添えてある。 1か月に何件あり、1件に何分かかり、どこで待ちが出ているか。

記号の細かい決まりや、ツールの選び方は後回しで構いません。手書きでも、付箋でも、Excel の表でも、この3つがあれば開発会社は話を進められます。

なぜシステム化の前に図にするのか

書かれていない要件は、作られない

IPA（情報処理推進機構）が発注する側と受注する側の双方に向けてまとめた「超上流から攻める IT 化の原理原則17ヶ条」には、「表現されない要件はシステムとして実現されない」という原則があります。「行間を読め」「言わなくても常識」といった、言葉にされない要件がトラブルの原因になるという指摘です。この原則の行動規範には、発注する側が「文書・モックアップなどの手段を講じて、要件を表現しつくす努力をする」とあります。

業務の流れの図は、この「表現しつくす」ための、いちばん手軽な道具です。現場の人にとって当たり前の作業ほど、口頭の説明から抜け落ちます。図にすると、矢印がつながらない所や、誰が担当しているか分からない所が目に見えるので、抜けに気づけます。

「今と同じ」でも、使われ方を書く必要がある

同じ17ヶ条には、「『今と同じ』という要件定義はありえない」という原則もあります。今のシステムや業務を調べるときは、機能を洗い出すだけでは足りず、「現行システムをどう使っているか、という点から調査をしなければなりません」と書かれています。例として挙げられているのは、データの再利用、出力したものの二次加工、お客様への提供といった使われ方です。

業務で言えば、「システムから出した一覧を Excel に貼って、色を付けて上司に送っている」「受け取った注文書の内容を、別の表にも書き写している」といった作業です。こうした作業は、システムの画面だけを見ていても分かりません。業務の流れの図に書いておくと、新しいシステムで何を自動にすればよいかが見えてきます。

複雑な所を、複雑なまま移さないため

17ヶ条の「要件定義は『使える』業務システムを定義すること」という原則では、発注する側に向けて、むだな業務や非効率な手順を客観的に見直し、新しい業務をゼロから設計し直すことが大切だとしています。あわせて、「業務の複雑な部分を複雑なままシステムに置き換えようとする」ことへの注意も書かれています。

図にすると、同じ情報を何度も書き写している所や、確認のためだけの往復が並んで見えます。システムにする前に「この作業は、そもそも要るのか」を考えられるのが、図にするいちばんの利点です。

事例：手作業の連絡を、システムに任せた

クリーヴァがシステムを開発した株式会社ステラ様は、建築・建設の現場で荷揚げ業を営んでいます。インタビューでは、システムを作る前の状況を次のように話しています。用途ごとに別々の管理ツールを使っていたため、情報を一つずつ確かめるのが大変だったこと。作業員への案件の連絡や、情報が届いたかの確認を、一人ひとり手作業でしていたこと。

システムを入れた後は、案件の担当の作業員が決まると、作業員の LINE に案件の情報が自動で届くようになりました。インタビューでは、作業員の手配にかかっていた事務作業を、1日あたり約2時間減らせたと話しています。

この例で減ったのは、「情報をコピーして送り、届いたかを確かめる」という、業務の流れの中の受け渡しの作業です。こうした作業は、業務の説明では「連絡する」の一言で済まされがちです。図の中で一つの作業として書き出しておくと、システムに任せられる候補として見つけやすくなります。

記号は5つで足りる

業務の流れの図には、決まった書き方がいくつかあります。たとえば、日本の産業規格には、情報処理の流れ図の記号を定めた JIS X 0121「情報処理用流れ図・プログラム網図・システム資源図記号」があります。業務の流れを細かく表すための国際的な書き方としては、OMG（Object Management Group）が定めた BPMN（Business Process Model and Notation）があり、仕様では、業務の流れを表すフローチャートに近い書き方で、実際にソフトウェアの処理に落とし込めるほど正確に描けるものと説明されています。

こうした書き方は、システムの設計や業務改善を本格的に進めるときには役に立ちます。ただ、システム化の前に現場の人と一緒に書く図では、記号を覚えることが目的になると、肝心の中身が進みません。この記事では、次の5つだけを使うことをおすすめします。記号の形は、社内で決めておけば何でも構いません。

5つ目の「困りごとの印」は、一般的な流れ図の記号にはありません。システム化の前の図では、ここがいちばん大事です。開発会社が知りたいのは、今の業務の形そのものよりも、どこを変えると楽になるかだからです。

書く前の準備

1. 図にする範囲の、始まりと終わりを決める

最初に、図の始まりと終わりを1行ずつ書きます。たとえば「お客様から注文のメールが届く」から「商品が届き、請求書を送る」まで、のように決めます。

範囲を決めないと、話がどこまでも広がります。会社の業務全体を1枚に描こうとすると、どこも浅くなります。システムにしたい業務が複数あるときは、業務ごとに1枚ずつ分けましょう。

2. 登場する人と場所を書き出す

次に、その業務に関わる人と場所を、すべて書き出します。社内の部署や役割だけでなく、次のものも入れてください。

• お客様や取引先： 注文を出す、問い合わせる、承認する
• 今使っているシステムや道具： 販売管理のシステム、Excel の在庫表、共有のフォルダ、チャット
• 紙の置き場所： FAX、注文書の箱、ホワイトボード

人だけでなく「Excel の在庫表」も一つの登場人物として扱うと、情報がどこにたまっているかが分かりやすくなります。

3. 実物を集める

最後に、業務で使っている実物を1件分ずつ集めます。注文書、見積書、入力している Excel、送っているメールの文面、チェック表などです。個人情報や取引先の名前は、塗りつぶすか、架空の値に置き換えてから集めましょう。

実物があると、「この欄には何を書いているのか」「この欄は誰も見ていないのではないか」といった話ができます。開発会社にとっても、画面やデータの項目を考えるときの、いちばん確かな材料になります。

4. 描く場と、参加する人を決める

業務の流れの図は、1人で机に向かって描くより、関わる人が集まって一緒に描くほうが早く、正確になります。集まってもらいたいのは、次の3役です。

道具は、対面なら付箋とホワイトボード（または模造紙）、離れた場所の人と描くならオンラインのホワイトボードが使いやすいでしょう。付箋は貼り直せるので、順番の入れ替えや、作業の分け直しが簡単です。最初から作図ツールで清書しようとすると、直すのが面倒になり、話が止まりがちです。清書は、中身が固まってからで十分です。

一度で全部を描き切ろうとしないことも大事です。1回目はいつもの流れだけ、2回目に例外と困りごと、3回目に件数と時間、のように分けると、参加する人の負担が小さく、抜けも減ります。

業務の流れを図にする7つの手順

1. 横に、担当ごとのレーンを引く

紙やホワイトボードに、準備で書き出した人と場所を、上から順に並べて横の帯（レーン）を引きます。プールのコースのように担当ごとに分ける描き方で、スイムレーンと呼ばれます。お客様をいちばん上に、今使っているシステムや Excel をいちばん下に置くと、情報が人から道具へ流れていく様子が見やすくなります。

2. 作業を「何を、どうする」で付箋に書く

作業を1つずつ付箋に書いていきます。書き方は「注文書を確認する」「在庫表に数を入力する」のように、目的語と動詞で書きます。「受注処理」「在庫管理」のようなまとめた言葉は、中で何をしているかが分からないので避けましょう。

1枚の付箋に1つの作業です。迷ったら細かく分けておき、あとでまとめるほうが楽です。

3. 左から右へ、起きる順に並べてつなぐ

付箋を、担当のレーンの上に、起きる順に左から右へ並べます。並べたら矢印でつなぎ、矢印の横に、渡しているものを書きます。「注文書の PDF」「出荷指示のメール」「口頭で伝える」などです。

担当が変わる所、つまり矢印がレーンをまたぐ所は、特に丁寧に書いてください。仕事が人から人へ渡る所は、待ちや伝え漏れが起きやすい所です。

4. 分かれ道と、例外の流れを書く

ひし形で分かれ道を書きます。「在庫はあるか」「金額は社内の上限を超えるか」のように、はい・いいえで答えられる問いにします。

そのうえで、いつもと違う流れを書き足します。次のような場面です。

• 差し戻し： 書類に不備があって戻す
• 急ぎ： 当日の出荷を頼まれて、順番を飛ばす
• 欠品・取り消し： 在庫が足りない、注文が取り消された
• 担当が不在： 承認する人が休みのとき

例外は、図がごちゃごちゃするので省かれがちです。けれども、システムを作るときに費用と手間が大きく変わるのは、たいてい例外の扱いです。いつもの流れの下に、細い矢印で書き足しておきましょう。

5. 困りごとの印を付ける

できた図を見ながら、困りごとの印を付けていきます。印を付けたい所は、主に次の4種類です。

印を付けるときは、現場の人に「この作業で、いちばん面倒なのはどこですか」と聞くのが早道です。図を描いた本人が気づいていない困りごとが、たいてい出てきます。

6. 件数と時間を書き添える

困りごとの印を付けた作業と、件数の多い作業には、数字を書き添えます。

• 件数： 1日、または1か月に何件あるか。繁忙期は何件になるか
• 時間： 1件にかかる時間の目安
• 待ち： 待ちが出ている所では、何時間・何日待つことが多いか

正確な数字でなくて構いません。「1か月に約200件、1件5分くらい」で十分です。数字があると、どの作業から手を付けるか、システムでどれくらい楽になるかを、開発会社と同じ物差しで話せます。17ヶ条にも、要件は人によって基準が異なるので、数えられるものは極力数値にするという原則があります。

7. 実際の1件でなぞって、現場の人に確かめてもらう

最後に、準備で集めた実物の1件を手に持って、図の始まりから終わりまでをなぞります。図に書いていない作業が出てきたら、その場で書き足します。

そのうえで、その業務をふだんしている人に図を見てもらい、「この図のとおりですか」と聞きます。管理する立場の人が描いた図と、現場で実際にしていることは、少しずつずれていることがあります。このずれを、システムを作る前に見つけておくのが、この手順のいちばんの目的です。

開発会社に渡す前に、書き足すこと

ここまでで、今の業務の流れの図ができました。開発会社に渡す前に、図の外に次の5つを書き添えておくと、最初の打ち合わせの質が大きく変わります。

1. 一番困っていること： 図の中の困りごとのうち、いちばん解決したいもの。1つに絞って、理由とあわせて書く
2. 変えたくないこと： お客様とのやり取りの方法、社内の承認の決まりなど、システムにしても残したいもの
3. 使っている道具とファイル： 販売管理のシステムの名前、Excel のファイル、共有フォルダなど。今後も使い続けるかどうかも
4. データの量と期間： 今あるデータが何年分、何件くらいあるか。新しいシステムに移したいかどうか
5. 例外の頻度： 手順4で書いた例外が、1か月に何回くらい起きるか

5つ目は見落とされがちです。年に1回しか起きない例外まで、いつもの流れと同じようにシステムにすると、費用がかさみます。頻度が分かれば、「この例外は人が対応する」「この例外はシステムで扱う」と、開発会社と相談しながら決められます。

渡すときの形は、ホワイトボードの写真と、後で紹介する型紙1・型紙2の表、準備で集めた実物の3点で十分です。図を作図ツールで清書し直す必要はありません。写真の文字が読めるかどうかだけ、送る前に確かめてください。

新しい流れは、開発会社と一緒に描けばよい

今の流れの図ができると、「システムを入れた後の流れも描かなければ」と考えるかもしれません。けれども、新しい流れを最初から完成させる必要はありません。

新しい流れは、どんな技術で、どこまで自動にするかによって変わります。そこは、開発会社の知識を借りて一緒に描くほうが早く進みます。発注する側が用意しておきたいのは、今の流れの図と、「どこを、なぜ変えたいか」です。

クリーヴァのサービスでも、最初のステップで、改善の前と後の業務を Before／After や簡易なプロトタイプで見えるようにしています。今の流れの図があれば、この Before の部分をすぐに作れ、After の話に時間を使えます。要件定義の全体の進め方は「要件定義とは：開発会社に頼む前に、社内でまとめておくこと」にまとめています。

そのまま使える型紙

付箋やホワイトボードで描いた図は、最後に表に書き写しておくと、開発会社とのやり取りや、社内での説明に使いやすくなります。次の型紙を、Excel やスプレッドシートにそのまま貼って使ってください。

型紙1：業務の流れの一覧

表の（例）の行は、書き方を示すための架空の例です。自社の業務に置き換えて書いてください。

型紙2：例外の一覧

型紙3：書き終えたら確かめる10項目

• 図の始まりと終わりが、1行ずつ書いてある
• お客様や取引先、今使っているシステムや Excel も、レーンとして書いてある
• 作業が「何を、どうする」の形で書いてある
• 矢印の横に、渡しているもの（書類、メール、口頭など）が書いてある
• 分かれ道が、はい・いいえで答えられる問いになっている
• 差し戻し、急ぎ、取り消しなどの例外が書いてある
• 転記、待ち、確認、属人の困りごとに印が付いている
• 件数の多い作業と、困りごとのある作業に、件数と時間が書いてある
• 実際の1件でなぞって、抜けがないか確かめた
• ふだんその業務をしている人に、図を見てもらった

つまずきやすい所

管理する人だけで描いてしまう

部署の責任者だけで描くと、「本来こうするはず」の流れになりがちです。実際には、担当者が独自の Excel で管理していたり、急ぎの依頼をチャットで受けていたりします。描くときは、ふだんその作業をしている人に必ず入ってもらいましょう。

「あるべき姿」から描き始めてしまう

最初から、システムを入れた後の理想の流れを描こうとすると、今の業務の困りごとが見えなくなります。まず今の流れをそのまま描き、困りごとに印を付けてから、変えたい所を考える順番にしましょう。

細かさがそろっていない

ある所は「受注処理」の一言、ある所は「ボタンを押す」まで細かい、という図は読みにくくなります。目安は、1つの作業が、1人が1回に続けてする仕事になる細かさです。担当が変わる所や、道具が変わる所で、作業を区切ってください。

図を描いて満足してしまう

図はゴールではなく、開発会社や社内の人と話すための材料です。完成度を上げるより、早めに見せて、質問を受けて直すほうが、良い図になります。開発会社に見せるのは、型紙3の10項目のうち半分ほどが埋まった段階でも構いません。足りない所は、打ち合わせの中で一緒に埋めていけばよいのです。

システムができた後に、図を更新しない

システムを入れると、業務の流れは変わります。そのときに図を直しておかないと、次に改修を頼むときや、担当者が替わったときに、また一から描き直すことになります。新しいシステムを使い始めたら、今の流れの図の隣に、新しい流れの図を残しておきましょう。業務のマニュアルや、新しく入った人への説明にもそのまま使えます。

おわりに

業務の流れを図にする目的は、システムに置き換える前に、今の業務を全員で同じように理解することです。記号は5つで足ります。担当ごとにレーンを分け、作業を「何を、どうする」で書き、渡しているものを矢印に添える。そのうえで、転記、待ち、確認、属人の困りごとに印を付け、件数と時間を書き添える。ここまでできていれば、開発会社は作るものと費用を具体的に考えられます。

図ができたら、次は何を作るか、最初にどこまで作るかを決める段階です。小さく作って確かめる進め方は「MVP とは：小さく作って確かめる開発の進め方と、よくある3つの誤解」で、今のシステムを別の会社に引き継ぐ場合は「開発会社を途中で変えるとき」で詳しく書いています。