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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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