新規事業向けシステム開発の要件定義の極意 Part4【業務フローの作成】業務フロー図の作成

前回に引き続き架空のシステム開発を例に、「業務フローの作成」について解説します。今回は前回作った業務プロセスを業務フロー図へ落とし込んでみます。

• 業務フローの作成方法がわからない
• 新規事業のためにシステム開発を行う
• システム開発で絶対に失敗したくない
• 発注者が要件定義の前に何をすべきかを知りたい

そんな方は、ぜひ最後までご覧ください！

※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。

業務フロー図を作成する

前回の動画では、業務の洗い出しをし、業務プロセスの作成までを行いました。そこで作った業務プロセスを業務フロー図へ落とし込んでみます。

業務フロー図は、フローチャートを使って作成します。フローチャートは、システム開発において広く利用されている技術ですが、他の一般的な業務においても利用できるものです。いくつかの図形や矢印を用いて、処理の流れを図式化します。

フローチャートの基本的な書き方

フローチャートに用いられる記号は次のようなものがあります。

フローチャートの説明は、ネットを検索して頂ければたくさん出てきます。その場合、これら以外の記号も紹介されていますが、業務フロー図を作成するうえではこのくらいの記号があれば十分です。

フローチャート≠業務フロー図

ちなみに、「業務フロー図=フローチャート」ではありません。フローチャートの技法を使って、業務の流れを記載することが目的ですので、自社なりに応用して作成しても全く問題ありません。但し、その場合はルールを決めておくことです。

例えば、同じ処理をするにしても色を付けて担当者が分かるようにする、処理の部分で手作業は点線、システムでの処理は実線、などのようにです。

業務プロセスを業務フロー図へ落とし込む

では、前回作成した業務プロセスを業務フロー図へ落とし込んでみましょう。業務プロセスは次の通りでした。

これを業務フロー図にしてみます。登場人物は、お客様とオペレータなので、列をその2つに分割しています。それぞれの列に、その人が行う処理を記載します。

まずは、大きな流れを記入しています。
「②問い合わせ内容はどの分類に相当するか」では、分類によって処理が変わっていました。

また、「⑤解決したか？」も解決したか否かという条件です。
「⑥FAQに未登録なら登録する」も、未登録か否かによって処理が変わるものですので、条件の記号に書き換えます。

その結果、このような業務フロー図に変わりました。お問い合わせがあったら、お問い合わせの概要を聞きます。そこからどの分類に該当するのか？アプリ会員登録についてか？そうであれば、会員登録はメールか、SNS登録なのか？それぞれによって、対応マニュアルを参照します。

アプリ会員登録ではなく、会員登録後の操作についてなのか？そうであれば、会員登録を特定できる情報を聞き、システムに登録されている会員の状況を確認します。

その後、ログインができない場合なのか、メアド・パスワード忘れについてなのか、会員登録情報の参照についてなのか、会員登録情報の変更に関することか、退会に関することかによって、それぞれの対応手順を確認します。そのうえで、お問い合わせの回答を用意し、回答します。

その回答によって、解決したか？解決すればいいですが、解決しない場合はオペレータが処理を代行して解決を図ります。

解決後、今後同様の質問について会員自身が解決できるような手段の一つとしてFAQを充実させて行きたいと考え、未登録ならば新たに登録する流れにしています。ここまでを終えて、会員サポート業務の完了です。

さて、少し戻って見直しをしますと、「アプリの会員登録に関すること」「会員登録後の操作に関すること」は詳細な処理が業務フロー図に記載されていますが、「順番待ちに関すること」「クーポンに関すること」については詳細が記載されていません。その代わりに、定義済み処理の記号が書かれています。

比較のためにあえて書き方を分けたのですが、1つの図に詳細を全て書き込む場合と、そうでない場合だと、後者の方がすっきりして見やすいです。1つの図の中に全てを詰め込もうとすると、ごちゃごちゃして全体感が掴みにくくなるため、細分化される業務はひとまとめにして、別途記載するようにすると分かりやすくなります。

順番待ちに関する問い合わせは、このように別途記載しており、この処理の「開始」「終了」以外の記号は、同じように記載します。

今回は割愛していますが、クーポンに関する問い合わせも定義済み処理として記載していますので、こちらも別の図に書き起こします。

このように図式化してみると、業務プロセス作成の際には気が付かなかった点が見えやすくなります。今回、問い合わせ内容は4つに分類していますが、この分類に収まらないことが考えつくかもしれません。例えばアプリはどのOSで動作するのか、アプリが起動しない、アプリをダウンロードできない人はどうするのか、という問い合わせもあるかもしれません。

関係者レビューとブラッシュアップ

一通り出来上がったら、関係者でレビューしましょう。違う立場、違う視点から見ることによって、新しい課題も見つかることでしょう。

今回、登場人物としてお客様とオペレータとしましたが、そもそもそれでいいのだろうか？
お客様がサポートを必要とした場合、ショッピングセンター内のショップ店員に問い合わせがいかないだろうか？もし、そうなるとショップ店員さんの仕事を増やす事となり、テナントさんからクレームが入るかもしれない。

それを防ぐために、フードコートにサポート要員を配置し、サポートするのがいいのではないか？その場合は、何人が適当か、曜日や時間帯によっても必要な人数は変わるはず。人を配置するとなると人件費が増えるが、本プロジェクトではそれを見込んでいるのか、予算内なのか、などなど。少し考えただけでも、このように課題は湧き上がってきます。

結果的に、業務フロー図を作成するうえではオペレータが対応する前提だったが、別の方法にしようなどと結論を導き出した上で、最終的にフローが決定することとなります

最初から考え得る全てが出揃うのは理想ですが、それもなかなか難しいもの。しかしこのように図式化され、他の人が見てもわかりやすくしておくことで、プロジェクトの成功にまた一歩踏み出すことができるようになるわけです。

まとめ

前回から今回にかけて、業務プロセスの作成から、業務フロー図の作成について解説をしました。業務フロー図の作成はシステム開発をするしないに関わらず、業務において以下の効果があります。

そしてもちろん、システム開発においても役立つものですので、業務関係者で知恵を出し合って、精緻な業務フローを作成してください。

次回も、さらに詳しく要件定義の進め方について解説していきますのでぜひご覧ください。