前回までで、“⁠現象⁠”→“⁠問題⁠”→“⁠原因⁠”→“⁠解決策…らしきもの⁠”で到達しています。もちろん、まだ「これだ！」という解決策の決定打には至っていません。

同時に、コンサルティング会社や専門家がこの業務分析に出しゃばり過ぎると、無関心を助長し、当事者意識が希薄となり、他人に依存することから抜けられなくなります。アナログ的な作業と場を通じて「自分たちでやる」ことが重要です。専門家は「やらせるのではなく一緒にやる」というスタンスが重要であることを書きました。

第10回では、解決策をタスクへ分解することを中心に、KPIの設定までお話します。

改善は部門単位で行うか？業務の一連の流れで行うか？

業務分析をどのような単位で行うかによって変わりますが、たとえば、部門単位で行う場合は、同じ業務を行う人のグループ単位、または個人で解決策を考えることになります。

一方、業務の一連の流れで見る場合は、自部門と前後工程に依存するので、複数部門に渡り全体業務で解決策を考えることになります（図1⁠）⁠。

前者の場合は、営業部なら営業部だけで解決策を一生懸命に考えることになります。これは、部門単位で比較的スモールスタートで、まずは自部門でできることから業務改善に着手しようという時に見られます。

後者の場合は、業務改善としては規模が大きなものです。業務の問題として「納期が長い」ことを例にして見てみましょう。図1の例では、商品の受注から始まり、商品がお客様の手元まで納品されるまでの業務フローです。

納期が長いことが問題であり、業務改善として「納期短縮」に取り組むことになったときに、営業部だけ受注のプロセスを早くしても、後工程の管理や物流のプロセスが遅ければ、納期短縮にはなりません。営業部門の部門内だけが速くなっただけです。お客様の手元に届くまでの納期は多少短くなるでしょうが、抜本的な納期短縮にはなりません。在庫確認がすぐにできるようにするためにはどうしたらよいのか、1分でも早く出荷して、お客様の手元に商品を届けるためには、各部門が最大限の納期短縮を図らなければ、全体としての納期短縮になりません。

業務は道路を走る車みたいなもの

このように、業務改善の対象範囲や改善テーマ（重点施策）によって、関連部門、すなわち、解決策を考えるメンバーが変わります。先の例のように、「⁠納期短縮」という命題が最初に出ていれば、営業部だけで行おうという話にはならないはずです。

仕事における1つ1つの業務は、道路を走る車みたいなものです。速い車もいれば、遅い車もいます。

片側何車線もあり制限速度なしのハイウェイもあれば、軽トラ1台がやっと通れる農道もあります。自部門の業務が改善されて高速道路になっても、前後部門の工程が農道ならば、そこで渋滞が起きることと同じです。かたや、高速道路でも整備不良のスポーツカーが故障して、その横を軽トラが抜かしていくという、「⁠ウサギと亀」のようなことも時として起こるものです。

業務改善を比較的、小規模から開始する場合は、「⁠まずは自部門からスタート」というケースは多く見られます。実際、当社がお手伝いする企業の7割程度は、最初は小さく部門単位で開始します。前後工程の業務プロセスを直さないと、自部門だけでは解決できないことが判明し、第二段階では関連部門を巻き込まざるを得なくなることは少なくありません。その際に、陥りがちなことが「一人だけで考える」パターンです。

解決策は一人で考えてはいけない

自部門のことだから、まずは自分たちで解決策を考えることは良いことです。

最近では業務が細分化＝役割分担されていることもありますが、皆、自分の仕事に手いっぱいで、自部門内でも他の人の仕事にかまっていられないという事情もあります。また、業務の属人度が高いときは、一人で解決策を考えざるを得なくなることもあります。

このような場合、問題の原因までは深堀りできても、解決策が1つしか出てこなかったり、自分の手に負える範囲の「実行に際して難易度の低い解決策」が出がちです。難易度の高い解決策、コストが発生する解決策、自部門内でも他のメンバーと協力しないと解決できない解決策は後回しにされるか、そもそも挙がってこないというもったいない事態にもなります。

そもそも、担当者が考えたことが解決の最善策という保証はありません。可能な限り、第三者の意見やアドバイスをもらいながら、意外な解決策も含めて見つけましょう。

人の仕事にかまっていられないという人に対しては、自分の業務が改善されないと、その人の業務にもマイナス影響を与えるということ説得を、業務フローを用いてできるはずです。

やってあげる「give」の精神は根本的解決にはならない

「give and take」という言葉がありますが、業務改善においては、相手のことを考え過ぎて「giveだけの精神」に陥ることがあります。特に、現場に負担をかけさせたくないというもっともらしい理由をかざして、「⁠我々はここまでやってあげているんだ」的な恩着せがましい解決策が見られることもあります。

これは絶対にNGで、根本的な解決になりません。

たとえば、ある期日までにデータを揃えておかなければならない業務があったとしましょう。元のデータは現場にあります。そのデータをあなたは現場から送ってもらい、データを加工して上司に報告をする業務をイメージしてみましょう。

元データは、ある部門は手書きでFAXしてくる。それも汚い字で、細かい部分はつぶれていて毎回、読み間違いが何ヵ所かある。別の部門は表計算ソフトで、メールに添付して送ってくる。その隣の部門は、メールに添付はせずに、メール本文にひたすら数字を打ち込んでくる。このようなバラバラな書式で送られてくることに業を煮やしたあなたは、書式を統一し、伝達手段も一本化しようと試みる。しかし、現場からは「めんどくさい」との声が出て、結局、元のバラバラ書式に戻ってしまう。

時間の概念も加えてみましょう。あなたはデータを加工する時間が必要なので、毎回、締切日に余裕をもって現場に依頼をしているものの、いつもギリギリになってからデータが揃い始めて、前日は深夜残業になってしまう。現場が忙しいことをわかっているものの、督促メールや電話を入れることになり、「⁠こっちはそれどころじゃないんだ！」と一蹴されてしまう。

このような場合、解決策に「書式を統一する」「⁠締切期日の1週間前と3日前と前日にリマインダーメールを出す」というものが出されがちです。現場はリマインダーメールが届いてから初めて動き出すので、結局何も変わらない結果となります。

「giveの精神」だけでは、業務改善は進まないことを頭の片隅に入れておきましょう！

“困るプロセス”を解決策検討時にどこまで考えられるか？

要は、「⁠現場の負担にならないように」という発想だと、全てあなたが背負込む解決策しか出てこなくなります。前述の言い回しを変えてみます。「⁠書式を揃えてあげる」「⁠ご丁寧に3回も期日を知らせてくれる⁠」⁠。何でもかんでも「やってあげる」の「giveの精神」では、現場もつけあがるだけなので、改善にならないばかりか、あなた自身の仕事がまったく減りません。増えるのは現場に対する不満とストレスだけです。

ここで考えなければならないことは、第2回でお話した“⁠困るプロセス⁠”をいかに仕掛けるかです。

考えるポイントは至ってシンプルです。期日どおりに、決まった書式で出さないと現場も痛い目を見るぞと。別に脅すわけではないですが、現場が不利益を被るとわかったり、いい加減に出していたデータの使い道が、実は上司から経営者にレポートされるものであったりすることをきちんと現場に伝えてあげると、「⁠やらざるを得なく」なります。

「giveの精神」はいったん横に置いておき、「やらざるを得なくするためにはどうすればよいか？」という視点で、今一度、解決策を考えるとまったく違った策が出てくるものです。

解決策からタスク分解

解決策が出てきたら、これを細かなタスクに分解をします。

簡単な解決策の例として、「⁠漏れ・ダブりのない受注書を作成する」を考えましょう。おそらく、ここの会社の問題は、受注書に不備があり、そのまま発送をしてしまい、お客様に違う商品が届いたり、届け先がわからない、などかもしれません。

では、「⁠漏れ・ダブりのない受注書を作成する」という解決策を、あなたはどのように作りますか？これが次に考える「タスク分解」になります。

完璧な受注書ができればいいはずですが、完璧な受注書とは何かを決めないといけないですね。でも、そんなものがわかっていたら、誰も苦労しないわけです。何から改善で着手をしようかとなった場合、最初から完璧な受注書など作れるわけがないので、解決策を実行する際に、具体的なタスクに分解することが必要となります。

タスクへバラす意味と意義

解決策をタスクにバラす意義は、「具体的に、何を行うか」と明確にすることです。

仮に、表1で解決策のレベルで止めてしまうと、「⁠漏れ・ダブりのない受注書とは何か？」「⁠どうやって作るのか？」がわからなくなります。

解決策の言い回しも重要です。『⁠漏れ・ダブりのない受注書を作成する』ではなく、『⁠漏れ・ダブりのない受注書を検討する』と書かれてしまうと、具体性が乏しくなり、検討した結果、何を行うことが改善になるのか不明確になります。特に「検討する」という単語は曲者なので、要注意です。

タスクをバラす意義は以下のとおりです。

• （1）具体的な改善作業項目が第三者が見てもわかる
• （2）個別の工数の見積が可能となり、リソース配分がやりやすい
• （3）他の人に改善作業そのものを依頼することができる

などです。

改善指標（KPI）の物差しはシンプルに！

タスクのバラしが済んだら、改善指標であるKPIを定めます。このKPIは改善の効果測定に欠かせない物差しです。

物差しとして、何を用いるかはケースバイケースです。確実に言えることは、物差しはシンプルにすることです。元々、無関心であった現場にも、このころになると徐々に当事者意識が芽生え始めていますが、まだまだ被害者意識もあり、余計なことに巻き込まれたと感じている人もいます。そこに、改善効果を測るために難解な指標を設定してしまうと、その測定やデータの二次加工に時間ばかりかかってしまいます。

「KPIの物差しはシンプルに！」が鉄則です。

次回は、KPI設定の続きと、優先順位の付け方、リソースの配分、メンバーアサイン、改善テーマとチーム編成についてお話します。