業務プロセスをいじっても生産性が上がらない。あるいは業務を良くするテコについて

★「業務改革≒プロセスの見直し」と思っていた時期が僕にもあった
業務改革を仕事にしているし、ズバリ「業務改革の教科書」という本も書いているので、amazonで「業務改革」を検索することもある。その際に目につくのは「業務フローの書き方」みたいな本だ。少しずつ切り口を変えて、とてもたくさんある。
あたかも「業務の順番を組み替えたら効率化は成し遂げられる」とか「現状と将来の業務フローを書けば効率化ポイントが見いだせる」みたいな雰囲気だ。

みんながそう思っているのには理由がある。BPR≒業務改革の源流はマイケル・ハマーの「リエンジニアリング革命」という本なのだが、ここで業務プロセスの組み換えの効果が大々的に謳われていたからだ。粗く要約すると・・

業務の部分最適を推し進めるのではなく、業務プロセスの目的を意識しながら、始めから終わりまでを眺め直そう。
そうすると仕事の組み換えや役割変更の余地に気づく。
つまり仕事を分解、分析して再構成することで生産性が上がるのだ。

僕自身もこの本を読んで業務改革コンサルタントになったので、「業務の組み換えは改革の最も重要なテコである」という姿勢でプロジェクトに臨んでいた。コンサルタントになって10年ほどの間は。
その頃はコールセンターやシェアードサービスセンターの統合などが多く、業務手順や役割の変更（つまり業務フローの書き換え）が実際に効果を上げるプロジェクトが多かったのだ。

だがその後（ここ15年ほど）は、業務プロセスの組み換え、役割分担の変更などによって効率化が図れることはほとんどない。現場実感として。プロジェクトの主要な施策にもならない。

結果として、
・AsIs（現状）の業務フローを書く
・ToBe（将来）の業務フローを書いてAsIsと比較する
・ほら、ToBeの方がずっと効率が良いでしょ？
みたいなストーリーはプロジェクトで起きない。
だから業務フローを書くことにもあまり熱心ではない。

もう一度言おう。
「この15年、AsIsとToBeの業務フローを書くことで業務が良くなったことがない」



★なぜ業務プロセスをいじっても生産性が上がらないのか？
多くの会社で業務改革プロジェクトをやってきての「実感」なので、なぜマイケル・ハマーの主張の通りになっていないのか、正直なところはよく分からない。だが仮説はある。

自分のジョブディスクリプションに書かれた仕事に集中する傾向が強い欧米の従業員に比べて、日本人労働者は組織全体のことをちゃんと考えている。だからマイケル・ハマーが言う「業務の目的に照らして今一度プロセス全体を見渡して、業務を良くする施策を見つける」は、特別な変革プロジェクトを待つまでもなく、日常的に、とっくにやっているのだ。

プロジェクトをやる度に思うのだが、日本企業で仕事をしている人々は真面目だし、日々考えながら仕事をしている（日本人的には当たり前のことだ）。

よく「改革は改善とは違う。日本人は改善は得意だが抜本的な改革は苦手」と言われる。これは僕も半分そのとおりだと思うのだが、業務プロセスをいじるくらいなら、日本人が苦手な抜本的改革には含まれない。だから社外から来たコンサルタントが業務フローをいじって「ほら、効率良くなったでしょ」と言って見せるような、魔法のようなことはほとんど起こらない。


同じことをもう少し具体的に考えてみよう。例えば「リエンジニアリング革命」にはBPRの原則みたいな考え方が実例付きで紹介されている。

例えば「分割されていた仕事を一つにまとめる」。行き過ぎた分業をやめることで効率がアップするという考え方だ。
例えば「受付 → 審査 → 照会 → 承認 → 契約」を全て別の人、別の部署がやってバトンリレーをするよりも、多能工化した方が、情報共有の手間、引き継ぎの手間が削減される。
ただ日本企業の社員は（欧米企業よりも）元々多能工的であり、これが非効率の源泉、みたいな状況はほとんど見かけない（ゼロではないが）。

同様に「意思決定を実作業の中に組み込む」なんかも、良くも悪くも日本企業では現場の人が高度な意思決定をしていることが多い。何でもマネージャーに指示を仰いだりしない。

「同じプロセスを全案件に適用しない」という原則も同様。
これは例えば、
・少額・定型案件なら簡易処理で済ます
・大型・例外案件なら厳密な審査を行う
みたいな話なのだが、日本企業にとってはかなり当たり前。
逆にケースバイケースが行き過ぎていて、標準化しにくく、システム化の障壁になっていたりする。

このくらいでやめておくが、これらはいずれも「元々結構最適化されているので、プロジェクトでいざ業務プロセスを見直すぞ！となっても、あまり改良する余地がない」という例だ。


★では何が業務を良くするのか？
マイケル・ハマーの思惑とは異なり、業務プロセスをいじっても生産性は向上しない。
だとしたら何が改革のテコ（業務を良くする要素）になってきたのか。僕の経験では以下のようなことだ。

a)情報共有
例えば商談情報を共有して、個人商店からチームセリングへ転換する。

b)データの構造を改善
コード体系がぐちゃぐちゃだったり、データに不整合があったり。例えば在庫情報が当てにならないから毎回倉庫まで見に行っていたのをやめられる。

c)温存されているヤバい制度を捨てる
時代に合わず、今となっては競争力の源泉になっていない制度（人事制度や顧客への対応方針など）が残っていて、無駄に業務が複雑になっている。顧客数人しか使っていないサービスプランがいくつもあるとか。

d)戦略的ではない場当たり対応を改める
例えば価格決定のルールが明確ではなく、営業担当者が安売りをすることを防止できていない。

e)ITの力で、人力では到底やれなかった面倒なことができるようになる
例えば顧客候補が自社Webサイトのどのコンテンツにいつアクセスしているかをトラックし、最適な営業タイミングを把握するとか。


気づいただろうか。これらは全て、単に業務手順や役割分担を変更するのに比べて、難易度が高い。
例えば「個人商店からチームセリングへの転換」は営業担当者の行動変容が必要だが、改革の中でも最も難易度が高い。営業マンの行動はコントロールしにくいからだ。
制度を変えると不利益を被る人とその代弁者が強硬に反対するので、これも難しい。
データ構造のガンが悪さをしていると、気づくのは難しい。気づいたとしても、周辺システムへの影響が大きく、お金がかかりすぎて手を出しにくい。

a),b),e)などはITを活用した変革になるが、これも業務部門とIT部門の間に断絶があったり、投資金額が大きくなるために、普段は手を出せていない（だからいざ変革プロジェクトとなると、このあたりがカギになりやすい）。

変革プロジェクトの難易度が年々上がっている気がするのは、日本企業にとって難しいことしかもう残っていないからかもしれない。

つまり、これらの本質的な施策をやり損なうと、大騒ぎしてプロジェクトをやっても効果が出ない。つまりこれらの隣にはプロジェクトの罠がある。もちろん「プロジェクトを失敗させる55の罠」でもいろいろな角度から考察している。
a)とb)は「罠16 データのガンを放置」だし、c)は「罠15 制度や習慣をスクラップしない」だ。
そして業務プロセスをちょろちょろ変えただけで効果が出ない変革になってしまうのは「罠13 施策がショボい」である。

★それでも業務フローを書く意味
この様に、業務プロセスを多少いじっても業務は良くならない（業務改革のテコにはならない）し、AsIsとToBeの業務フローを書いたら何かが見えてくることはない。

とは言え実際の変革プロジェクトでは、やはり業務フローを書く機会は多い。いくつかの活用場面があるからだ。

業務フローの活用場面①：標準化後の姿を明確にする
工場ごと、事業部ごとにバラバラの仕事をしているケース。理由があってバラバラであり、無理に標準化しない方が良いこともあるのだが、単にいままでの名残（合併前は別の会社だったなど）でバラバラなのであれば、標準化することのメリットは大きい。
その場合、「標準化後は結局どうなるの？」を明確にしておくために、ToBe業務フローを書くことになる。
（明確にしないと、それぞれがAsIs業務を続けてしまう）


業務フローの活用場面②：新システム導入後の姿を明確にする
例えば「システムがSAPに置き換わったら、いまの仕事は変わるんだっけ？」という素朴な疑問には答えなければならない。全く変わらないなら業務フローを書かないが、大抵は大小様々な変更がある。


業務フローの活用場面③：後工程のインプットになる
テストシナリオ、マニュアルやトレーニング資料のベースになる。
業務の通し稽古的なテスト（僕らはそれをシステムテストと呼んでいる）は大きなプロジェクトでは必ず実施する。その際のテストシナリオはToBe業務フローがベースとなる。マニュアルなどのユーザー教育用の資料も同様だ。
これらを作る際にどうせ必要となるのであれば、早めにToBe業務フローを書いておいたほうが、プロジェクト内の認識を一致させやすい。


という感じで、いずれも「業務フローを書くことで、抜本的な業務改革ができる！」みたいな派手さはなく、「まあ、プロジェクト遂行上必要なので、コミュニケーションを良くするために作りますか」みたいな感じ。だからあまり時間を掛けないようにしている。淡々と若手に書いてもらったりする。

***********************新刊「プロジェクトを失敗させる55の罠」情報
発売後2週間で、早くも重版が決まりました。ほとんどの本は1回も重版されないことを考えると、中々良い滑り出しと言えると思います。
分厚くて読むのが大変だと思いますが、読んでくださった方は是非SNSで感想をつぶやいたり、同僚におすすめしてください。僕が喜ぶのもあるんですが、そっちのほうが全プロジェクトのためだと思います！