ウチの課長は、なぜ業務フロー図を書かないのか？

0. 「業務フロー図」とは何ぞや？

最近、「ソモソモ業務フローの必要性がワカラン」と言うコメントを複数人からもらった。

そりゃ普通のヒトにとって、業務フロー図なんて、見たこと無いだろう。もちろん、業務フロー図に従って仕事を処理したことも無い訳で、、、必要性も何も、ソリャ全く分かんねーだろー、、、と（心の中で）思ってしまった。。。

と言う事で、今日は初心に戻って『業務フロー図の必要性と具体的な業務フロー図の書き方』について、いま考えていることを、まとめてみようと思う。（結構タイヘンかも。。。）

1.そもそも何故「業務フロー図」が必要なのか？

まずもって「業務フロー図」とは何だろう？

「フローチャート」とか「業務プロセス図」とか「ワークフロー図」とか、、、表現はイロイロある。要するに『業務の進め方がわかる図』だ。日本の行政機関では「業務の流れ図」と呼んでいる。

最大の特徴は、業務マニュアルが『文字』で書かれるのに対して、業務フロー図は『チャート』（Chart）と呼ばれる図で記述される点だ。・・・と、カタカナ説明でゴマ化そうとすると「ほな Chart ってナンヤネン」と突っ込まれる訳だが、Chart とはそもそも「海図・航空図・天気図」を表す英単語だ。つまり業務フロー図は「進むべき道を知る為の図」が記述される。「フロー」＋「チャート」と言う表現は「全体の流れが解かる図」と言う意味になる。文字と違って、全体の流れを素早く理解できる。

そー言えば、むかし「チャート式」なる数学参考書にお世話になったものだ。あれは「この参考書が船における海図のような役割を果たすものでありたいという願いから名付けられた」（Wikipedia）らしい。（「赤チャート」はカナリ試練だったぞ・・・ん？どうでもいい！）

業務フロー図は、全ての社員が、

• 私は、全体の業務の流れの中で、どの作業工程を担当しているのか？
• 私は、何を受け取って(INPUT)、何を産みだし(manufacture)、誰に渡せば(OUTPUT)良いのか？

を解決できる図である事が理想と言える。

1-1. 社内に現状フローを共有したり、変更内容を共有したりするため

一番目のニーズとして挙げてみた。

たとえば、「業務の流れを工夫してチーム全体としての生産性を高める」や「不正が起きない様な情報伝達手順を考える」と言った発展的な議論をしようとすれば、現状の詳細な業務フロー図が必要となる。。。

もっとも、、、『社内に現状を共有したり、現状の変更を共有したりするため』は、実はかなりハイレベルな利用目的だ。いざ業務フロー図を実際に作成してもらうと、何気なくこなしている日常業務ですら、意外と「属人的」であったり、あるいは「流派」が分かれていたりする。つまり「現状フロー」なんて「十人十色」だったりする。平たく言えば、みんなバラバラ。例えば以下の様な属人例は、どんな会社にだってある。

1-1-1. クレーム対応フロー

クレーム回答メールを書く際、Aさんは全ての回答文を上司にレビューしてもらってから送信しているのに対して、Bさんはたまにしか上司レビューを受けない。

1-1-2. 新Webページ追加フロー

ホームページに新ページを追加する際、Aさんは、デザイナーさんに挿絵を書いてもらってから、本文原稿を書いて、その後またデザイナーさんにレイアウトを依頼するのに対して、Bさんは完全に本文原稿を書き終えてから、デザイナーさんに挿絵とレイアウトを依頼する。

ちなみに「業務フローが属人的」と言う表現は、しばしば大きな誤解を招く。
-A. 担当者スキルが属人的： 「人によって成果の品質（結果）が違う」
-B. 情報伝達経路が属人的： 「人によって成果伝達の手順や経路が違う」
当然ながら、ここでは、(B)「仕事を回す経路や順序にルールが無い」と言う意味で使っている。しかし、日常会話では、(A)のケースで使われる事の方が多い。議論の途中ですり替わっていることもあるので注意が必要だ。例えば、「Excelスキルは人によって違うから成果がバラバラだ」や「A部長とB部長では判断基準が違う」と言った場合にも、「業務（フロー）が属人的」と言う表現が使われがちだが、いや、むしろ業務フローは標準化されている。

1-2. 社内に現状を教えるため

『社内に現状フローを教える』は非常に分かりやすいニーズだ。

たとえば、チームに新人を受け入れる際、業務フロー図があれば便利だ。新卒採用や人事異動があった時に、「ホレ、ウチのチームは、こんなカンジでやってるんだよ」って渡してあげれば、新人は即座におおよその仕事の流れを理解できる。事業拡大期にある積極採用企業や、定期的な人事異動が多い会社であれば、業務フロー図は非常に有効な武器と言えるだろう。「社内規定と業務マニュアルをお渡しシマスね・・・」とは比べ物にならない。（ゼッタイ読まないって。。。爆）

「ウチには業務フロー図なんてネーぜ。OJTだ、おー・じぇー・てー！」などと、カタカナ用語でごまかそうとする上司には細心の注意が必要だ。確かに、実際の現場に身をもって飛び込んでいく On Job Training は即戦力化と言う視点で有効な手法かも知れない。が、一方で「獅子の子落とし」的な残酷な教育訓練になってしまうケースも少なくない。すなわち、先輩社員のフォローが少ない新人は、自力でガケから這い上る羽目になり、結果として社内ノウハウとしての「業務の流れ」を教わらずに成長してしまう。（自己流の「業務の流れ」を作ってしまう？）

1-3. 社外に現状フローを報告するため

上記２つのニーズと比べ、3つ目の『1-3. 社外に報告するため』は若干消極的なニーズかもしれない。

最も分かりやすい例はSOX法による内部統制報告制度だろう。上場企業等は金融庁に対して「業務の流れ図」を提出し、ガバナンスが効いてますよぉ～と報告する。延いては投資家保護に役立つ。（もっとも、報告したからと言って、現場が活気づく訳でもなく、売上げが上がる訳でもない。。。）

2. では、何故「業務フロー図」が無いのか？

第1章で利用目的（ニーズ）がはっきりした（？）。業務フロー図は必要だ（！）。

では「必要なモノ」にもかかわらず、何故「無い」（書かない）のだろうか？

2-1. 作れない

『作れない』は分かりやすい。

作れないものは存在しえない。トンビが居ればタカが生まれる可能性があるが、トンビが居なければタカも何も生まれるハズがない。（なんか違う）

しかしこの例は非常に多いのだ。ためしに身近な業務フローを描いてみて欲しい。百戦錬磨のベテラン社員であっても、パワポ（Power Point）やビジオ（Visio）で『新規作成』を選んだ途端、その真っ白なキャンバスを目の前に、何から書けばいいか分からなくなる。業務を知らないわけではない。むしろ誰よりも知っている。単に、業務フローの描写がムツカシイのだ。（目で見えるようで目で見えナイ 。写真や動画で撮れるものではナイ。そもそも他例を見かける機会もナイ。）

筆者自身は、これまでに500業務ほどをモデリングした経験がある。だから、今でこそ、ヒアリングすればその場で業務フロー図を描けるようになった（←ただの自慢）。　が、しかし、最初は1つ仕上げるのに5時間も10時間もかかった。しかも、寝て起きてそのフロー図を見返すと、まだまだ改良できる点が何か所も残っている。最初の10フローは、何度も何度も書きなおす羽目になる。（バカバカバカ。To:昨日のオレ、From:今日のオレ）

2-2. 作れるけど、意味が無いから作らない

『作れるけど、意味が無いから作らない』は、ある意味深刻な状況だ。

しかしこの例も少なくない。では何故「意味が無い」と感じるのか？　それは

• A) 「業務フロー図が、陳腐化してしまうから」と
• B) 「業務フロー図だけでは、業務の流れを統制できないから」

の2つの理由に集約される。

[A]の業務フロー図の陳腐化の例で言えば、例えば、[A1]「パソコンの購入は、総務部で一括して調達する事になった」や[A2]「組織が改編され部署やチーム構造が変わった」などの内部要因や、[A3]「ライバル企業の出現で標準納期を半分にする必要がでてきた」などの外部要因で、業務フローそのものが変化してしまうのだ。その瞬間に、せっかく作った業務フロー図も過去のものになってしまう。メンテナンスが難しいことは改めて説明するまでもない。また、[B]の統制が困難と言う話は、「業務フロー図を壁に貼る」「毎月研修をする」などなど、色々な施策が考えられるが、やはり紙に書いた業務フロー図だけでは限界がある。

2-3. 作れるけど、誰が作るべきか分からないから作らない

『作れるけど、誰が作るべきか分からないから作らない』は困った話だ。

デキルけどシナ～イと言う言わば職務放棄的な話だ。意外に思われるかもしれないが、業務フロー図に慣れた成熟組織において、しばしば発生する。

例えば製造部門と販売部門の業務をスムーズに流すと言った話になった際には、どうしても利害対立が発生するのだ。部署を横断する業務フローと言うヤツだ。「受注情報のチェックは販売部門でしておけよぉ」と言ったヤヤコシイ話にケリを付けなければならない。どちらの部門の業務についても精通している必要があるだけでなく、両部門を「全体最適」の名のもとに調停しなければならない。やっぱり人間、面倒なことはゴメンだ。（このケースは高度に組織論な話になる。結局のところ組織のトップが「プロセスオーナー」（後述）を任命するしかなさそうだ）

3. ちなみに、何故「業務フロー図」はムツカシイのか？

業務フロー図の描画はムツカシイ。（『2-1. 作れない』で触れた）。ここでは、業務フロー図が描きづらい理由を探ってみたい。

ちなみに、描写ツール側の問題には触れない。つまり、絵画に喩えるなら、紙や筆については触れない。ここでは、「走る馬」は何故に描きづらいのか、「裸体」は何故に描きづらいのか、と言った対象物に内包する難しさについて考察してみたい。

3-1. 実は社内ルールが無かった

『実は社内ルールが無かった』は痛恨である。

何せ描こうとする被写体が居ないのだ。まぁ、居ないと言ってしまうのは、やや乱暴だが、描こうとする業務フローが、「馬」の様だったり「車」の様だったり「寺院」の様だったり・・・。どれが本当の姿なのか全くわからない場合には、流石に描けない。

業務フロー（社内ルール）が無いのに、業務が動く（回る）のか？　まぁそれはそれで動くのだ。人間と言う生き物はスゴイとしか言いようが無い。

3-2. 処理をどの粒度で書くべきか悩ましい

『処理をどの粒度で書くべきか悩ましい』は、上級者の口から出るセリフだ。

第1章で「クレーム回答文を書く」と言う作業工程を例示したが、更に「タイトルを書く」「本文を書く」「見返す」などに分解する事ができる。描写粒度は幾らでも細かく出来る。色々な粒度設定が考えられるが、まぁ原則論として、業務フロー図に描くべき工程の粒度は「一人の社員が Input を受けて Output を出すまで」とするのが良い。

3-3. 例外処理をどこまで書くべきか悩ましい

『例外処理をどこまで書くべきか悩ましい』は、究極の悩みだ。永遠の悩みと言っても良い。

これも原則論としては、発生頻度の低いものは省略する事になる。発生頻度の低い例外処理を描き出せばキリがない。そして、描けば書くほどに全体が見にくくなる。とは、言いながらも一方、重要業務については、コンティンジェンシープラン（不測事態手順）と言う考え方もある。滅多に発生しないものの、発生すれば、その際には速やかに切り替えられる様にしたいのだ。

4. では、どうすれば「業務フロー図」が書けるのか？

必要な理由（第1章）、現存しない理由（第2章）、描写が困難な理由（第3章）を踏まえ、、、「業務フロー図の書き方」や「業務フロー図を誰が書くべきか」について考察したい。

そう、、、簡単にメンテナンスできるレベルの業務フロー図でなければならない。働き手みんなにとっても便利な業務フロー図でなければならない。会社を良くするための業務フロー図でなければならない。

4-1. ITツールの高度化の動き

ヤッパリと言うか、当たり前の話と言うか、道具としてはITを使いたい。コンピュータはエライ！

2000年以降、21世紀に入り「業務上のデータやり取りをコンピュータに任せてしまおう」と言う思想に基づいたITが開発されている。もっとも20世紀にも「ワークフローシステム」と言う名称で存在していたのだが、それを大幅に拡張させたITだ。まだまだ認知度は低いが、それは「BPM システム」と呼ばれる。

概念は簡単。コンピュータに業務フロー図等で業務ルールを教えてあげると、人間同士のデータやり取りをコンピュータが仲介してくれるようになる、と言う仕組みだ。つまり「つぎの工程は何か」や「この案件は誰の処理に回すべきか」を判断して、良しなに仕事を回してくれる様になる。例えば、誰かが「見積書」を作ったとしてコンピュータに登録すれば、コンピュータが申請者の上司に対して「内容を確認して承認するか決めてチョ」と問う仕組みだ。また例えば、誰かが「日本語原稿」を作ったとしてコンピュータに登録すれば、コンピュータが翻訳者に対して「この日本語原稿を英語原稿にしてチョ」と言う。

100個だろうが1000個だろうが、会社内の全ての業務の進捗を把握し、どんどん仕事を回してくれるのだ。悪い言い方をすれば、人間は「歯車」になる。コンピュータが仕事を運んでくるので、言われるがままに作業を行う。

ちなみに、産業革命による「機械化」によって人間の尊厳が問われたが、この「IT化」の動きも人間の仕事を大きく減らす事につながるだろう。しかし、人間は次の役割を担えば良い。スマホが電話番号を覚えてくれるようになって、人間は退化したかも知れないが、それはそれで良いのだ。（チェスや将棋で負けてもいいぢゃないか。小説を書いたり、ブログを書いたり、、、人間にしか出来ない事はまだまだある）

4-2. 国際的な記法標準化の動き

ならば、簡単にメンテナンスできるレベルの業務フロー図でなければならない。

これは世界中の人が考えてきたことで、これまでにも沢山の業務フロー図フォーマット（アイコンの描き方やアイコン同士の接続の仕方）が提唱されてきた。

2000年以降、この「ITツールの高度化の動き」と連携して、業務フロー図の書き方（描き方）が BPMN と言うフォーマットに決まった。フォーマット自体が未だに進化の過程にあるが、およそ間違いない標準（デファクト・スタンダード）となっている。これは IBM・Oracle・Microsoft などの大手IT会社が主導したモノだが、流石に合理的で、コンピュータも人間も理解しやすいフォーマットと言う特徴がある。（Questetra だけが提唱している訳ではない）

最近では、米国政府や日本政府も相次いで採用の動きを見せており、政府内業務も BPMN で記述される日が近い。（キーワード: 「業務・システム最適化」）

4-3. プロセスオーナーと言う考え方

「ITツール（BPMシステム）を使いこなし、BPMN を学べばイイのか？」　答えは元気よくハイだ。

しかし、より重要な事がある。それは、誰が業務フロー図のメンテナンス責任者であるかを明確にする事だ。彼らは、プロセスオーナーと呼ばれる。言い換えれば、社内にあるそれぞれの業務フローにプロセスオーナーを決定するべきだ。当初は兼務であっても良い。

これは本稿の中で、もっとも大切な事で、もっとも重要な事で、もっともインポータントな事だ。（？！？！）

情報システムや品質管理と同様、この人間の雇用は「間接投資」に該当するが、中期的に見てとても投資効果が高いはずだ。いや投資効果が高い人を雇用しなければならない。組織によっては、そのプロセスオーナー達を束ねるトップを役員待遇で雇用すべきかもしれない。 実際、情報戦略を担う CIO (Chief Information Officer) や技術戦略を担う CTO (chief Technical Officer) と同様に、業務フローの全社最適化を担う CPO (Chief Process Officer) と言う統括ポジションを用意する会社も少なくない。（COO や CFO が担うべきと言う議論もあるが、「業務プロセス」に関する専門的な知識で全社を統治すべきだ）

ちなみに、BPMN はコンピュータのためのモノでもある。業務フローを良くしたいなぁと思っている一般の方（末端のプロセスオーナーを含む）は、BPMN の深い部分について理解する必要が無い。しかし、数多くの業務フロー図に触れ、おおよそ読めるようになる必要はある。

では、プロセスオーナーは何をすればよいのだろうか。（2013年現在の所見だが）、それは、[A]「セオリー(コツ)を学ぶ事」と[B]「良い事例を真似る事」に集約されると思っている。

4-3-1. セオリー(コツ)を学ぶ

[A]セオリーについては、「BPM 100 Success Secrets」などの専門的なマニュアルもあるが、まだ決定的な教科書は存在しない。（ただ、今後は「OMG認定BPMエキスパート資格試験（OCEB＝オーセブ）」の分かりやすい解説書が出てくるとは思う）。今のところは、業務フローの書き方については、様々な良書や雑誌記事が出回っているので、それらをチェックするだけで良いだろう。ちなみに Questetra サイトにも「業務プロセスモデリングの鉄則」などの学習記事が多数ある。

4-3-2. 良い事例を真似る

[B]良い事例については、なかなか無い。これは実は当たり前の話で、業務効率を良くするワザは、なかなか公開されるものではない。場合によっては「競争力の源泉」だ。しかし、最近は、業務フロー図のテンプレートやサンプルであれば、数多く検索できる様になってきた。Questetra も御多分にもれず「ワークフローサンプル」と言う業務雛形提案サイトを運営している。500以上の業務フロー図が掲載されているので、「見積書」や「稟議書」などのキーワードで検索して欲しい。

5. まとめ

何とも長い文章になってしまった（そして後半は疲れの見える文章になってしまった）が、最後に Questetra の宣伝だ。（そう、このために書いている・・・）

実は、、、なんと、、、 Questetra は、、、、この夢の様なITツール「BPMシステム」の開発会社だ。（シラジラシイ）。しかも、世界最大の調査会社 Gartner から、「グローバル BPM の中の Cool Vendor」と注目されていたりする。（たぶんスゴイ事です）

なお使い方は簡単だ。しかもWebブラウザさえあればイイ（SaaS BPM）。詳しくは『ユーザ サポートサイト』のマニュアルページ等を見てもらいたいが、一部抜粋すれば以下の様な手順になる。

1. フローを決める（Drag ＆ Drop）
   アイコンを配置して業務の流れを設計します。各処理工程（タスク）は角丸長方形で表現されます。
2. 入力項目を決める（データ設定）
   文字型・日付型・選択肢型など、業務に必要な項目を設計します。
   例：「申請理由」「申請者名」など
3. アクセスレベルを設定する
   どの処理工程で、どの項目に入力できるのかを決定します。
   例：「決裁工程で『申請理由』の編集は不可」など
4. 担当者を設定する
   各工程の処理を誰が（どのグループが）担当するかを決定します。
   例：「決裁工程は申請者の上司」など
5. 分岐ルールを設定する
   ゲートウェイにおける条件分岐式を記述します。
   例：「500万円以上は社長へ」など

—
世界中のシゴトが、もっとスムーズに回るようにする！！
株式会社クエステトラ 代表執行役CEO 今村元一　（2013-01-18）

▼クエステトラはSaaS型のNo-Code開発プラットフォーム。無料トライアル、絶賛受付中です！▼

業務プロセス、オススメ設計手順（動画解説付）

電帳法の改正にあわせて、業務プロセスも改訂シタ

「業務プロセス」 って、なんですか？？

ワークフローとBPM、7つの違い