要件定義の業務フロー図の書き方｜スイムレーン図の手順とチェック

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義で業務フロー図を描くのはなぜ？

要件定義の打ち合わせで、文章の資料だけを読み合わせると、話がかみ合わないことがありますよね。業務フロー図を広げると、「その前に、この確認があります」と現場の方が指で示してくれるんです。

要件定義全体の流れは要件定義とはで紹介しています。ここでは、要件定義のフローの中で業務フロー図をどう描き、どう使うかに絞ってお話しします。

業務フロー図とフローチャートの違い

似た言葉にフローチャートがあります。要件定義のフローチャートと業務フロー図は、同じものとして扱われることもありますが、目的が少し違います。

要件定義で描くのは、レーンを分けた業務フロー図が基本です。処理の細かい分かれ道は、必要になった時にフローチャートで補うと考えておきましょう。

要件定義のどの場面で使う？

業務フロー図は、要件定義の中で何度も出番があります。今の業務を描く時、目指す業務を描く時、そして要件を拾い出す時です。

今の業務と目指す業務の比べ方は、要件定義の業務分析（As-Is/To-Be）で詳しく紹介しています。

業務フロー図の基本ルールと記号

『記号の種類が多くて、どれを使えばいいのか迷う』という方もいますよね。実は、要件定義の業務フロー図で使う記号は、ほんの数種類で足ります。

形の決まりは会社によって違います。社内に描き方の決まりがあれば、それに合わせてください。

描く時の基本ルール

基本ルールを先に決めておくと、複数の人で描いても図の見た目がそろいます。

よくある描き間違いと直し方

初めて描いた業務フロー図には、よく似た描き間違いが出てきます。先に知っておくと、レビューで指摘される前に自分で直せますよ。

中でも多いのが、判断の出口の書き忘れです。ひし形を描いたら、出口の線に条件を書くところまでを1セットにしておきましょう！

1枚に収まらない時は分ける

業務が大きいと、1枚の図に全部を載せようとして文字が読めなくなることがあります。そんな時は、全体の流れを描いた1枚と、作業ごとの詳しい図に分けてみてください。

全体の図の四角に番号を振り、詳しい図の題名にも同じ番号をつけておくと、行き来しやすくなりますよ。

スイムレーン図を書く手順

ここがこの記事でいちばんお伝えしたいところです。スイムレーン図は、レーンを先に引いてから作業を並べると、迷わず描けるんです。

スイムレーンとは、プールのコースのように、部署や人ごとに横（または縦）の帯を分けた図のことです。帯の中に、その部署がする作業を置いていきます。

1. 始まりと終わりを決める

最初に決めたいのは、どこからどこまでを描くかです。範囲が決まっていないと、図がどんどん横に伸びてしまいます。

例えば、お客様から製品の修理を受け付ける業務なら、「修理の依頼を受けた時」から「修理した製品を返して記録を閉じた時」までと決めます。範囲の外になる作業は、図の端に「請求の業務へ」のように書いておけば十分です。

2. レーンを引く

次に、その業務に関わる部署や役割を並べて、レーンを引きます。お客様のように社外の人も、関わるならレーンを作っておきましょう。

システムを1本のレーンにする描き方もあります。今の業務を描く時は、表計算ソフトや紙の台帳もレーンや書類として描いておくと、後で置き換える対象が見えやすくなります。

3〜6. 作業を並べて、判断と受け渡しを描く

作業は、担当する部署のレーンに置いていきます。レーンをまたぐ線が出てきたら、そこが部署の間の受け渡しです。

受け渡しの線には、何を渡すのかを書き添えてください。「修理の依頼票」「見積もり」のように書いておくと、後で業務で扱うデータを洗い出す時に役立ちます。

7. 例外の流れを足す

いつもの流れが描けたら、例外の流れを足します。ここを省くと、要件定義の後半や設計の途中で「この場合はどうするの？」という質問が次々に出てきてしまいます。

開発側「修理の見積もりを、お客様が断った時はどうなりますか」
利用部門「製品をそのまま返します。その時は、点検の費用だけいただくこともありますね」

この会話から、「見積もりを断られた時の返却」と「点検の費用をもらうかどうかの判断」という2つの流れが図に加わります。

8. 現場の人に見てもらう

描いた図は、現場の担当者に見てもらって初めて使えるものになります。机の上で描いた図は、どこかで現場の流れとずれていることが多いんです。

見てもらう時は、「この図で違うところはありますか」より「この線の先で、本当にこの人が受け取っていますか」のように、具体的な場所を指して聞くと答えてもらいやすいですよ。

記入例：修理受付の業務フロー

架空の題材として、家電製品の修理を受け付ける業務の、目指す業務フローを描く場合の例を作ってみました。図そのものは載せられないので、スイムレーン図に置く中身を表にしています。

判断の分かれ道は、3番の「直せるか」と5番の「修理するか」の2か所です。それぞれの「いいえ」の行き先も描いておきましょう。

今の業務フローと並べてみる

目指す業務フローが描けたら、今の業務フローと並べてみましょう。変わる場所に印をつけると、関係者に「どこが変わるのか」を一言で説明できます。

この表は、As-Is/To-Beの分析でつくる差分の表とほとんど同じ形です。業務フロー図と差分の表を行き来しながら、変える場所を決めていくと進めやすいですよ！

細かさはどこまで？

『作業を1つずつ全部描いていたら、図が終わらない』と感じますよね。要件定義の業務フロー図は、「誰かに仕事が渡る場面」と「判断が入る場面」がわかる細かさで十分です。

1人で続けて行う細かい手順は、1つの作業にまとめて構いません。必要なら、その作業だけ別の図や手順書で補いましょう。

図から要件を拾い出すチェック

業務フロー図は、描いて終わりではありません。むしろ、ここからが要件定義の本番なんです。

図の中の作業、判断、受け渡しを一つずつ見ていくと、業務要件とシステムの出番が拾えます。拾った内容は、業務要件定義書に書き写していきます。

拾い出した要件をまとめる文書の書き方は、業務要件定義書の書き方で章立てと合わせて紹介しています。

システムの出番は「受け渡し」に多い

要件を拾っていくと、システムの出番はレーンをまたぐ受け渡しに集まりやすいことに気づきます。手で書き写したり、電話で伝えたりしている場面です。

例えば、受付窓口が依頼票を手書きして修理担当に渡しているなら、そこが登録と共有の機能を考える候補になります。逆に、1人で完結する作業は、システムにしなくてもよい場合もあります。

拾った要件を一覧にする

図から拾った要件は、図の番号と結びつけて一覧にしておきます。後で「この要件はどこから来たのか」をたどれるようにするためです。

ISO/IEC/IEEE 29148でも、良い要件の性質の一つに「追跡できる」が挙げられています。図の番号と要件を結んでおくのは、まさにこのためなんです。

業務フロー図をどの工程で作り、ほかにどんな資料をそろえるかは、要件定義の成果物一覧や要件定義の進め方も参考にしてみてください。

よくある相談に答えます

要件定義の業務フローについて、よく寄せられる相談を要約してお答えします。

ヒアリングから要件定義、設計へと進む流れがつかめない

「ヒアリング、論点の整理、要件定義、設計、開発と進むと聞いたが、実際の流れがよくわからない」という相談があります。結論から言うと、業務フロー図はヒアリングと要件定義をつなぐ役を担っています。

ヒアリングで聞いた話をその場で業務フロー図に描き、図を見ながら論点を出し、決まったことを要件として書く。この順番で進めると、聞いた話が要件の形に変わっていく様子がつかみやすくなりますよ。

画面の表示項目を、実際の運用に合ったものにしたい

「要件定義の段階で、画面に出す項目や表示の形を実際の運用に合ったものにするにはどうすればよいか」という相談もあります。業務フロー図のレーンをまたぐ受け渡しに注目してみてください。

受け渡しの時に、受け取った人が何を見て次の作業をしているかを聞くと、画面に必要な項目が見えてきます。図に「依頼票」と書いた所で、依頼票のどの欄を見て判断しているかまで聞いておくと安心です。

プログラミングが苦手でも、業務フロー図を描く仕事はできる？

「プログラミングが苦手だが、社内SEとしてやっていけるか」という相談も見かけます。業務フロー図を描く力は、プログラミングとは別の力です。

現場の話を聞いて、誰が何をしているかを図にする力は、要件定義でとても重宝されます。まずは身近な業務を1つ選んで、スイムレーン図を描く練習から始めてみてください。

よくある質問

まとめ

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

要件定義のAs-Is/To-Be分析とは？業務分析のやり方と記入表

業務要件定義書の書き方｜章立てとヒアリングで埋める順番