
システム開発の業務フロー作成ってどうすればいいの?
書き方やコツしりたい!
と言った疑問に答えます。
この記事を読むことで、システム開発で業務フローがなぜ必要か?どうすれば上手く作れるのか?を理解することができます。
システム開発における業務フロー作成の目的とは?
業務システムを構築する場合、業務フローの有無はプロジェクトの成功・失敗にかかわりえる重要なドキュメントです。
業務が高度にシステム化されたとはいえ、人間の仕事が完全になくなったわけではありません。その為、人間がシステムを使い業務を流す設計を業務フローとして明文化する必要があります。
もし、あなたの進めているシステム開発で業務フローを作っていない、ないがしろにしている場合、大なり小なりの認識齟齬が待ち構えています。
要件定義における業務フローの位置づけ
システム開発において要求・要件の明確化の為に業務フローが必要になるのは、以下、黄色ぬりのエリアです。

既存の業務フローを作成し(AS-IS業務フローと呼ぶ場合があります)、それをもとに、新規の業務フローを作成します(To-Be業務フローとも呼びます)。
システム開発の流れに関しては【【社内SE向け】システム要件定義の進め方・必要成果物とは?】の記事で詳しく解説しています。
業務フローはどこまでが業務の仕事?それとも社内SEの仕事?

システム開発においてこの議論は非常に悩ましいです。
本来は業務フロー作成は業務の仕事です。業務ユーザーに現場の業務設計に責任があるのからです。
しかし、システム開発となると、よく見かけるのが業務が業務フロー書けない・書かないケースが発生します。
業務フローがなく要件漏れ・開発手戻りで苦しむのは社内SEです。開発ベンダーにとっては要件漏れで特に痛くありません。
基本的には業務ユーザーに書いていただきたいですが、ない場合・書けない場合はたたき台をシステム側で作成・もしくは支援してあげるのは仕方がないでしょう。なくて困るのはSEですから。
開発時、口を酸っぱくして指導していることは、
システム開発のコツというか真実
— グルー@社内SE講師 (@it_compass_guru) November 15, 2020
要件定義で業務ユーザーとの合意形成は、記憶ではなく、記録に残す。。。これが後々、命運を分ける。。。
いった言わない議論でSEに勝ち目なし#社内SE #システム開発
要件定義を上手く推進する為に必要な業務フロー

ここからはどのように、システム開発の要件定義に役に立つ業務フローを準備できるのか?を解説していきます。
わかりずらい・使えない業務フローとは、どんな業務フロー?
わかりずらい・使えない業務フローの特徴として以下を上げることができます。
業務フロー全体の書き方に統一感がない
情報粒度がばらばらでわかりずらい
情報が細かすぎて理解に時間がかかる
結局、どこをシステム開発したいのかわからない
業務フロー全体の書き方に統一感がない
業務フロー作成時、アイコンや矢印と言った業務の表現方法がバラバラだと情報理解にものすごく時間がかかります。
業務フロー作成時には、レイアウトに統一感を持たせる必要があります。
既に、社内で既存業務フローが存在する場合は、レイアウトを合わせることで余計に読み手の理解が用意になります。
情報粒度がばらばらでわかりずらい
上記では、書き方の話をしました。あわせておさえておきたいのが、情報の粒度です。
もし、ある業務領域では、ものすごく細かいのに、他領域では抽象化されていると読み手は理解しずらくなります。
例えば、自動販売機でジュースを購入する例
ばらばらの抽象度
・自動販売機を見つける
・飲みたい商品の有無を確認
・値段を確認
・お金を取り出す
・コインを1枚ずつ投入し、目当ての商品のボタンが点灯するのを確認し、他商品を押し間違わないように、その商品のボタンを押下し、おつりがある場合は、返却口を確認(よく忘れる為、商品より先に実施)、その後自動販売機下の受け取り口のカバーをもちあげ、商品をとる
↑こんなの大袈裟!と思うかもしれませんが、業務で使う業務フローでこういったばらばらのケース結構目にします。
適切な抽象度
・自動販売機を見つける
・飲みたい商品の有無を確認
・値段を確認
・お金を取り出す
・おつりをとる
・商品を受け取る
業務フローは、1シート内では抽象度のレベルはそろえ、深堀したい業務フローは別シートに詳細化するなど工夫が必要です。
情報が細かすぎて理解に時間がかかる
業務フローは、業務の手順書ではありません。
あくまで業務の流れを可視化するツールです。あまりにも不要な情報まで載った業務フローは、”業務フロー”の目的から外れ使えないドキュメントになってしまいます。
調べた情報を全部書いていくうちにこのケースにおちいる場合があるので注意が必要です。
結局、どこをシステム開発したいのかわからない
ここまでは、業務フローの書き方をお話しをしました。書き方も重要ですが、一番困るのは、業務フローは存在するのにTo-Be業務フローでシステム化する業務が明確でない場合です。
業務フローを作るのに熱心になりすぎ、いつのまにか業務フローを作るのが目的になっていてしまうケースを見かけます。
これでは、本末転倒です、業務フローを使い業務を明確化し、システム要件を作るのが目的です。
以下システム開発における成果物の関連図で見ると一目両全ですが、業務フローが様々なドキュメントのインプットになっています。重要な位置づけであることが理解できます。

ポイントをまとめ
・業務フローの目的を正しく理解する
・情報の粒度・書き方をそろえる
・業務フローを作ることを目的にしない
・システム要件を洗い出す
わかりやすい業務フローの書き方

上記で解説したポイントをふまえ分かりやすい業務フローの書き方のコツを解説します。
わかりやすい業務フローを書くコツ
業務フローのテンプレートを利用し書き方に統一性を持たせる
業務フローを適切に絞り・メリハリをつける
業務フローに記載する情報の抽象度をあわせる
はじめのうちは業務フローを書く時間に余裕を持つ
業務フローのテンプレートを利用し書き方に統一性を持たせる
分かりずらい業務フローの特徴は、業務フローの書き方がまちまち・業務フロー作成の目的を忘れてしまっている、と解説しました。
テンプレートや社内の以前作成されたフォーマットを活用し記述に統一性を持たせ時間の効率化は直ぐにでもおすすめしたい改善方法です。

業務フロー作成に直ぐにでも使える、エクセルのテンプレートは以下の記事からダウンロードきます。
業務フローを適切に絞り・メリハリをつける
システム開発の為の業務フローの作成は、システム化する周辺に絞り詳細化がおすすめです。全ての業務フローを作成しようとすうと終わりません。システム開発に必要な要件すら出てこないと言った状況に陥ります。
業務フロー作成を進めるうえで以下の観点で絞り・メリハリをつけ推進しましょう。
絞り・メリハリ (以下、サンプルの業務フローを使い説明)
①L1では一番大きな概念で記述。LV2で業務を詳細化し進める。LV3は更に詳細化必要な業務単位で書く

②LV1では詳細にとらわれず大きな流れを書く。詳細化するのは、システム化する領域が絞られている場合L2/L3に書き起こす業務フローも絞る
③初版、変更に対応しやすいように、初めのうちはスペースを広めにとり書く
④線でオブジェクトをつなぐ際も、意味に気を付け引いておく(これよくやってしまうケースで、後で意味合いを持たせようとすると工数がものすごくかかります)
⑤フローは交差しないように書く
⑥下書きは社内SEが書いてもいいが、最終的には業務を実施する人・責任者に書かせるor責任をもってレビューさせる
(これがないと、きれいにはかけても結局使われない業務フローになってしまいます)
業務フローに記載する情報の抽象度をあわせる
わかりずらい業務フローとは?で解説しましたが、情報の深さを合わせることで格段に読み手に物事を伝えやすくなります。
情報の粒度をうまく合わせる為に必要な技術が、抽象度の操作です。
業務フローだけでなくビジネスの様々なシーンで役に立つ技術です。
情報が分かりずらそうになるフローの領域は、上手く抽象度をコントロールし記述できるようになりましょう。
抽象度を磨くための方法に関しては以下の記事で詳しく解説しています。
はじめのうちは業務フローを書く時間に余裕を持つ
はじめは誰でも業務フロー作成には時間がかかります。 上記でご紹介したようなテンプレートの活用で時間の大幅な短縮が可能です。しかし、それでも初めて業務フローを作成する場合は、時間的に余裕をもって段取りを設計する必要があります。
時間の余裕は心の余裕にもつながり、ストレスレスで業務フローの準備ができます。
システム開発における業務フローとは?作成の目的は何?まとめ
システム開発における業務フローの目的は、業務の可視化のみならず業務要件を洗い出すために重要です。業務フローをベースに後続のドキュメントを作成していくのでプロジェクトの明暗を分けると言っても過言ではありません。
本来、業務フローは業務ユーザーが作成するべきですが、かなりのプロジェクトで業務ユーザーが作らない・作れないケースを見かけます。適切な業務フロー無しでは結局苦しむのは社内SE/システム開発側です。
エンジニアとしてもシステム開発を上手く推進できる業務フローは書けるようにしておきましょう。