仕事の流れ2：業務モデリング
業務コンサルタントの仕事の流れを解説するシリーズの続きです。
第1回では、プロジェクトの最初に実施する「構想企画」を解説しました。
まだ読まれていない方は、以下からどうぞ。
t14764.hatenablog.com
第2回の今回は、「構想企画」が終わった後に実施する、「業務モデリング」フェーズについてです。
さて、このフェーズの目的は、読んで字の如く、業務をモデリング＝設計することです。
どのような業務を設計するのかと言うと、「構想企画」で明らかにした課題を解決するための業務です。
このフェーズで設計した新たな業務で仕事をすると、これまでの課題（例：売上が上がらない、品質が上がらない、など）
が解決しますよ、そんな新業務を一緒に考えて行きましょう、というフェーズです。
それでは、詳細について解説していきます。
目次
ポイントまとめ
最初にポイントをまとめておきます。
1. 現状業務の調査
- お客様に話を伺い、現状業務フローを作成する
- 仮説を持ちながら、検証に必要十分な業務のみフロー化する
- 現状業務を客観的に正確に可視化することで、正確な課題特定に繋げる
2. 現状課題の特定
- 業務フローのどの部分に課題があるかを特定する
- 課題とは、理想の状態とのギャップ
- 理想の状態を知っているのが、コンサルタントの大きな価値
3. 解決策とあるべき業務の検討
- 課題の真因を特定し、それを解決するあるべき業務を検討する
- 根本的な解決を行うには、表層的な原因ではなく、真因を特定することが重要
- たくさんの他社事例を参照しながら解決策を立案する（お客様単独では不可能）
4. 改革による効果試算
- 前提条件を明確にして改革による効果を試算する
- プロジェクト開始時点で、効果はある程度予測している
- 試算は、フェルミ推定のように行う
5. 実行計画の策定
- 今後どうやって解決策を実現するのかを示す
- 計画には明確な理由が必要
- 業務規定変更やシステム導入などを行っていくことが多い
それでは、それぞれについて説明していきます。
1. 現状業務の調査
まず最初にやることは、お客様にお話を伺いながら、
現状どのように業務を行なっているのかを調査することです。
いきなり新業務を考えることは、もちろんしません。
いきなり考えた新業務には、何の実現性も無く、また、なぜ今の業務をその新業務に変えれば、課題が解決するのか分からないからです。
日本にいる人に、1時間後にアメリカに来て、と言っているようなものです。
相手が今どこにいるかが分かって初めて、アメリカとの距離はどのくらいあるから、飛行機で明日の夜アメリカに来てください、のように言えますよね。
前回も書きましたが、やはりここでも、現状を正確に客観的に把握することが重要になります。コンサルタントの基本スタンスですね。そのため、お客様にとっては、何も目新しさが無くとも、きちんと現状業務を調査するのです。
ですので、客観的かつ正確にお客様に現状の業務をお伺いします。もちろん、何から何まで確認する訳ではなく、「構想企画」フェーズで改革対象とした業務、部門の方を中心に確認します。
その結果は、「業務フロー図」として表現します。
皆さんの会社にも、〇〇業務標準、〇〇業務マニュアル、みたいな形で文書があると思いますが、あれです。
「構想企画」フェーズでも、粗々の業務フロー図を書くことがありますが、本フェーズではより詳細な業務フローを書きます。
設計業務など、何かデータを作り込んでいく場合は、合わせてデータモデルフローを書く場合もあります。
詳細というのは、誰が、いつ、どんな業務をするかを
時系列に表現するレベルです。
各業務では、何がインプット情報になっていて、何がアウトプットされるのかも表現します。
サンプルはネットにたくさん転がっているので、
興味のある方は「業務フロー サンプル」で検索してみて下さい。
この時よくやってしまいがちなのは、お客様から話を聞いた通りに、全てを正しく正確に書くことです。
そうすると何が起こるかというと、今回の業務改革とは関係の無い業務がたくさん記載されてしまい、誰も読まない冗長なフローになってしまいます。
そもそも、ここで書いているのは現状業務であり、
お客様にとっては周知の事実であり、従ってほとんど価値の無い情報なんですよね。
また、当たり前ですが、コンサルタントというのは、正しい業務フローを書く人ではないのです。
じゃあ、業務フローに表現すべき部分はどこなのか？
それは、課題を解決するために変える必要のある業務と、その周辺業務です。
お客様単独で業務フローを書くこともあるかも知れませんが、この視点で、業務フローを書けるのが、業務コンサルタントの存在価値の1つです。
では、そのような業務フローを書くためには、どうすれば良いのかというと、皆さんもよく聞いたことあるであろう、「仮説思考」がその答えになります。
仮説を頭に思い浮かべながら、その検証に必要な部分の業務を確認するのです。
恐らくこのような業務を行っているため、これまでに聞いた課題が発生しているはずだ、という仮説を持った上で、そこに関連した業務に特化して現状調査していくということです。
また、これは何も業務フローを書く時に特化したものではなく、プロジェクトの成功を効率的に達成するためにも重要な考え方です。
2. 現状課題の特定
必要な現状業務を調査した後、どの業務でどんな課題が発生しているかを特定します。
「1. 現状業務調査」で作成した業務フローに追記していくと、誰が、いつのどんな業務に課題があるか、を
表現できるので良いでしょう。
お客様に、御社の業務ではここが課題です、と提示するのはこのタイミングですが、前述したように、コンサルタントの頭の中では、既に「1. 現状業務調査」の段階で、粗々の課題は特定されています。
さて、ここで質問ですが課題とは一体どのようなものなのでしょうか？
日常的に使われている「課題」という言葉ですが、正しい定義を意識しながら使っていますか？
恐らく、以下のようなイメージを持たれている方も多いのではないでしょうか。
・ダメなところ
・イケてないところ
・面倒なこと
・非効率なこと
私も前職で設計者をやっていた時は、上記のような漠然としたイメージで課題という言葉を使っていました。
ですが、これらは全て間違いです。
正解は、
課題＝理想の状態と現状とのギャップのうち、解くべき（解ける）問題
です。
なぜ課題という言葉の定義を気にするのかというと、
「現状課題を特定」するためには、「理想の状態」を知っておく必要があるためです。
この「理想の状態」を知っておくこと、というのが、前述した「仮説思考」の「仮説」に相当します。
つまり、コンサルタントの頭の中には、プロジェクトスタート時から、既にお客様の「理想の状態」がある程度描かれているのです。
そうでないと、「課題を特定」することが出来ないですからね。
では、その業務の「理想の状態」を知るにはどうすれば良いか？
答えは、その業務について経験を積み、他社について調べて詳しくなることです。
ただ、それには時間もかかりますし、お客様の本業は業務の理想の状態を調べることではないので、他社については分からない会社が大半です。
そこで、我々のようなコンサルタントの存在価値があるのです。
多くのお客様とのプロジェクトを通し、豊富な他社の成功事例を知っており、また常日頃から理想の業務について知見を蓄積しているからです。
成功確率を上げ、理想の状態を知るための時間を節約するために、我々コンサルタントに高いお金が払われてるということです。
このような理由から、お客様だけでは、適切に「現状課題を特定」することはなかなか難しいのです。
世の中の変化が激しくなり、他社との競争も激しくなっており、ただでさえ業務は複雑になっていますからね。
ここが難しいので、課題を特定できたら、半分は解決したも同然です。
3. 解決策とあるべき業務の検討
次は、課題に対する解決策と、それを実現する具体的な新業務フローを検討します。
「2. 現状課題の特定」で抽出した課題は、
いわゆる表層的な課題であることが多いです。
なぜなら、抽出したのは、お客様にお伺いした課題であるため、自部門に閉じた課題であることが多いためです。
ここでよくやってしまいがちなのが、その課題を解決する対策を安易に立ててしまうことです。
分かりやすい例を出すと、
課題 ：お金が貯まらない
解決策：お金を借りる
みたいなことです。
一時しのぎにはなるかも知れませんが、お金が貯まらない状態は変わりませんし、何なら借金をしてしまっているので、更に貯まらない状況になってしまいます。
何でもそうですが、表層的な課題に対して解決策を打っても、表層的な課題しか解決せず、大きな効果は見込めません。根本的な課題が解決していないので、別の形でまた似たような課題が発生することが多いです。
それを防ぐためには、特定した課題の原因分析をしっかりと行った上で、
根本的な原因、本質的な原因をあぶり出した上で、その原因を解決する対策を立てることがとても重要です。
この時活躍するスキルが、「論理的思考」です。
いわゆる、「ロジカルシンキング」というやつですね。
課題に対して、少なくとも3回は「なぜ？」を考え、
どんどん原因を深掘りしていきます。
原因は1つではなく、複数が絡み合っていることが多いです。コンサルタントに支援を依頼するような状況ですから、単純な問題であることはほとんど無いです。
ああでも無い、こうでも無い、原因分析を試行錯誤し、
論理的思考を駆使して、たくさん出した原因の因果関係を考え課題を構造化し、最終的に真因を特定します。
先ほどのお金の例で言えば、
課題 ：お金が貯まらない
↓なぜ？
原因１：収入が低い→なぜ？→平均年収が低い業界にいるから→なぜ？→平均年収を調べずに就職したから
原因２：支出が多い→なぜ？→職場で飲みに行く機会が多い→なぜ？→自分は営業、周りも営業であり、飲みに行くのが好きな人が多い
↓どうすれば良い？
解決策：平均年収を調べた上で、平均年収が高い業界の営業以外の職種に就く
みたいなイメージです。
このように、確実に効果を出すために、真因を解決する対策を立てることが重要です。
この時、コンサルタントには各業界にそれぞれ専門家がいますが、解決策を考える上で、その専門性が大いに発揮されます。
経営戦略に関する解決策をたくさん知っているのが戦略コンサルタント、各業界の業務に関するものなら業務コンサルタント、ITに関するものならITコンサルタント、のように。
ここにも、我々コンサルタントがお客様からお金を頂いている意味があります。
4. 改革による効果試算
解決策を立案した後は、その対策によって現状からどのくらい良くなるのかを示すために、改善効果を試算します。
何によって効果を測るかは、プロジェクトの目的によって異なります。
よく試算するのは、以下のようなものです。
- 業務工数がXX%削減
- 業務や調達などのリードタイムがYY日短縮
- 原価がZZ円低減
今回の改革には費用対効果があるのか、を示します。
試算した結果、思ったより効果が少なそうだ、ということは稀です。
なぜなら、経験豊富なコンサルタントは、プロジェクト開始時点で、ある程度効果を予測をしているからです。
これも「仮説」の1つですね。
高いお金を頂いている訳ですから、効果が小さいのは論外ですしね。
とは言え、効果が出るのはもちろん未来の話で、このタイミングでの改善値は、あくまで試算結果です。
そんな値がどこまで正しいのか、というご意見もあるかと思いますが、少なくとも何も試算しないよりはマシですよね。
そして、重要なのは、試算結果そのものではなく、その試算の前提条件の方です。
前提条件をお客様と合意することがここでの目的です。
この前提条件の下、計算すると、こんな効果が出ますよ、というのをお客様が認識していることが重要になります。
なぜなら、もし前提条件が変わった場合は、こうなりそうだ、というのが分かるからです。
経営陣としては、細かな効果額にはあまり興味が無く、
ざっくりどのくらい良くなるのか、またその値がある程度妥当かどうかが分かれば良いのです。
試算の時は、「論理的思考」はもちろん、巷で言う「フェルミ推定」の考え方が必要になります。
5. 実行計画の策定
最後に行うのは、
「効果がありそうなことは分かった。
で、今後どうやってその解決策を実現していくのか？」
に答えることです。
絵に描いた餅で終わらないよう、こういう手順で進めればこの時期に効果が出ますよ、というのを示します。
前述の通り、すぐに効果が出ることは稀で、業務規定を変更したり、システムを導入したりして、運用開始して初めて効果が出ることが多いです。
例えば、半年以内に業務規定を更新して運用開始しましょう、だったり、2年後に新業務に対応できるシステムを導入して運用開始しましょう、だったりという計画を立てます。
計画なので、当たり前ですが未来の話です。だからと言って、未来のことなど分からないから適当な計画を立てました、ではもちろんダメです。
きちんと、お客様が納得する理由とセットで、計画を策定することが重要です。
製造業を例にすると、まずは効果の大きな主力製品からお試しで新業務運用を行い、検証と効果を早期に刈り取りながら、その他製品へ適用を拡大していく、のようなイメージです。
計画立案は、理由とセットで考えるため、「論理的思考」と、未来を描くために「創造性」が必要になります。
最後に
以上、長くなりましたが、こんな流れで「業務モデリング」フェーズを進めることになります。
僕が経験した中で感じたのは、
「構想企画」「業務モデリング」を行わずに、いきなり「要件定義」を行い、結果、誰にも使われないシステムを構築している企業が多いなということです。
目的や解決方法が曖昧なまま、ITツールの持つ機能をベースに導入してしまうためですね。
あと、前回、今回と読んでいただいてお気付きかも知れませんが、コンサルタントの仕事の基本は、仮説・計画を考えつつ、現状を把握し、それに基づいて仮説・計画を修正し精度を上げ、お客様を成功に導くことです。
つまり、未来について考えている時間が全体の仕事の8割くらい、と言っても過言ではないですね。
僕はこの仕事のそういうところが好きです。
以上、今回はここまでです。
最後までお付き合いいただき、ありがとうございました。
次回は、「3. システム要件定義」フェーズの概要について解説します。
それでは。
