ここ数回，あえて「無関心な現場」というシチュエーションから離れていましたが，小さな仕掛けは少しずつ組み込んでいます。今回は業務改善に関わるメンバーのリソース配分と，改善スケジュールを立てる話をします。

業務改善の実行はほったらかし

無関心な現場で始まった業務改善ですが，徐々に問題解決案も出揃い，細かくタスクに分解し，KPIの設定までこぎつけました。しかし，まだ業務改善の計画には至っておらず，準備段階であることは変わっていません。つまり，まだ，スタートラインにもついていません。改善スケジュールがきちんとできてはじめて，PDCAのP（Plan）ができたこととなります。

P（Plan）の次は当然，D（Do）の改善計画の実行，すなわち，業務改善の実行ですが，この「業務改善の実行」を「ほったらかしにする」ことがポイントです。何を言っているのかわからないという人もいると思うので，簡単にお伝えします。改善計画を作るまでの長い道のりは，事務局やコアメンバー，あるいは私たちのようなコンサルティング会社が，多少なりとも現場をたきつけ牽引しますが，業務改善の実行そのものは，事務局や当社が行うものではなく，現場が行うものなので，そろそろ“⁠独り立ち⁠”をしてもらうということです。

改善は誰のために行うかを考えればわかります。会社や自分の職場のためということもありますが，一番の現場のモチベーションは「自分たちの仕事も楽になる」「⁠不愉快な思いをすることなく，気持ち良く仕事ができるようになる」ことです。

したがって，原則，「受益者負担」という考え方が必要となります。業務改善の実行段階（Do）で，あれこれ細かなことまで事務局や私たちが関わって口を挟むと，以前にお話をした“⁠やらされ感⁠”という余計なものをまた思い出してしまい，他人に依存するという悪循環に陥ります。

「ほったらかし」ができると，業務改善は計画通りに進む

理想は，実行段階になったら，「⁠放置」してしまうことです。放置するためには，上述した"独り立ち"ができていないと，放置されたままの無責任状態となるので，放置のやり方を考えなければなりません。

参考までに，私たちの経験則ですが，少なくともこれまで11回にわたってお伝えしてきた進め方を行うと，改善計画作成までは喧々諤々で一緒になって考え，時には悩みながら進めていきますが，実行段階になるとほとんどの場合自然に改善が進んでいきます。

これがどういう部分で具体的に現れるかと一言で言うと，「業務改善がほぼスケジュール通りに実行されて効果を出す」ということです。つまり，改善計画が計画倒れにならず，せっつかなくてもよくなるので，事務局はほとんど関与せずに済みます。現場も"やらされ感"の悪循環にはまらなくなり，一石二鳥です。

本連載の第1回で「二度とやるものか……業務改善」と書いたように，「⁠やっても無駄」「⁠関わりたくない」など，業務改善をやりたくない理由や原因はあれこれありました。

それに比べるとだいぶ，“⁠独り立ち⁠”してきます。しかし，最後の砦とばかりに現場の悪あがきが発生するときがあります。

改善計画づくりは現場の悪あがきを抑えるコミットメント

現場を悪あがきから脱却させ，“⁠独り立ち⁠”をさせるためには，現場自らが自分たちの手で改善計画を作るしかありません。

「いつまでに，何をやるか，どのくらいの効果を出すか」が，改善計画には書かれています。事務局や当社が作成するのではなく，自分たちでこれまで業務分析から解決策のタスク化，KPI設定まで行います。さらに，時間軸やリソースを配分してスケジュールができあがります。

業務改善の計画を作る行為は，基本的には自分たちへのコミットメントであり，こんな日程でこれだけ改善を行っていきますという宣言文でもあります。

改善計画を作る人は他ならぬ改善を行う現場のメンバー自身です。自分で作ったものを自分で約束を破るとカッコ悪いですよね？

単純な理屈ですが，これが連載第2回でお話した"やらざるを得ない環境を作る"ことで，「自分が困るプロセス」にもなっています。

改善メンバーのリソース配分

さて，業務上の課題の解決策はすでに実行タスクへと落とし込まれ，かつ，KPI設定と優先順位も前回まででできあがっています。

次に，具体的にどのくらいの資源（リソース）を投入して，業務改善を実行するかを決めます。

一番のリソースは，改善を行うメンバーが改善に割く時間です。「⁠業務改善をする時間がない」「⁠業務改善をしていると本業が疎かになる」という改善をやりたくないもっともらしい言い訳が出てくることは，これまでにも何度かお伝えしてきました。また，改善を業務と切り離してしまうこともNGで，仕事の中で改善を行うことが重要と連載第7回で書きました。

ここでのポイントは「仕事（本業）を行いながら，改善にどの程度の時間がかかるかの見積り」がいかに高精度にできるかです。仕事をしながらの改善なので，改善の工数見積もりには，ある程度のマージンが必要となりますが，そのマージンが大きすぎると「さばを読みすぎだ！本当にそんなにかかるのか？」と言われます。

私たちが掲げる業務改善の原点は，「⁠お金をかけないで改善をする」です。もちろん，全ての改善に当てはまるわけではありません。どうしても，システムがボトルネックで改修をしないといけないこともありますし，必要なものは購入することもあります。改善効果が早く出る場合もありますが，システムやツールに頼ってしまうと，時間が経つにつれて改善効果が頭打ちとなり，現場の無関心は変わらずになります。

改善がきちんと現場に定着し，継続することが大事なので，最初からシステムを導入する，ツールを購入するなど，“⁠モノ⁠”“⁠カネ⁠”“⁠システム⁠”のリソースに目を向けてしまうと，これらが「ありき」の前提となってしまうので，気を付けなければなりません。したがって，「⁠お金をかけずに改善をするためには？」を念頭に置きながら，リソース配分の順番を考えていきます。

ヒト以外のモノ，カネ，システムの投入は後回し

“⁠モノ⁠”“⁠カネ⁠”“⁠システム⁠”のリソースは無視し，“⁠ヒト⁠”だけに注目します。実際に，“⁠ヒト⁠”のリソース割当が，交渉や調整などが部門内だけではなく，他部門の協力も必要となるので，難易度も高くなります。

改善が1人で行えるのか，複数名必要なのか，自分だけで解決可能なのか，他部門のメンバーも巻き込まなければならないか，です。この際に，現状調査と分析の段階で業務を可視化（モデリング）した業務フローが役立ちます。どの部門を巻き込むか，もっと具体的には誰をキーパーソンとして巻き込まなければならないかです。後ほど，「⁠改善チームの作り方」でお話します。

「どの人が，どのくらいの時間をかけて」を見積もることが必要となります。改善に時間をかけているので，リソースとしては“⁠ヒト⁠”ですが，最終的には時間当たりの単価，賃率などを乗じることで“⁠カネ⁠”という投入リソースに換算することもできます。

まずは，要する時間の見積り

時間，つまり改善にかかる工数の見積りは意外と難しいものです。

業務改善の専属で業務改善が仕事の全てであればよいのですが，仕事をしながら改善を行うので，本業の負荷状態により改善にかけられる時間が変わってきます。1ヵ月の中でも忙しい時期もあれば，そうでない時期もあるでしょうし，突発的な仕事が割り込むことも予想されます。

これまでの連載でタスクを細かく落とし込んでいるので，時間の見積りは専属つまり連続的に改善にかかりっきりで行った場合をイメージして時間を算出します。たとえば，5時間などです。

5時間連続して時間が確保できる場合と，そうでない場合があるはずです。今月は5時間連続ではできないけど，来月なら5時間連続で時間が取れるという場合もあります。このように，いつなのかという「時期」のパラメータも必要となります。

したがって，今月だと正味，改善に要する時間は5時間でも，1日1時間しか取れなければ，1週間かかることになります。

スケジュールを作るときには，優先順位と時期を考えながら進めていきます。

改善チームの作り方―閉鎖的にしない

改善チームの作り方ですが，連載第10回の図1で示したように，改善は部門をまたがり，自部門だけではなく前後工程の部門を一緒に加えます。このほうが改善効果が高く，また，部分最適を抑制できる意味もあります。

小さくスタートする場合は自部門内のチームだけで進むこともありますが，自部門だけで改善を行うと，リソースである“⁠ヒト⁠”がメンバー1人だけになるケースも珍しくありません。

いつでも，改善を横展開し，前後工程部門を巻き込んで効果を発揮するためには，改善チームの作り方を部門内に留めず，業務フローの登場部門を関連部門として巻き込んでいきます。その際に，関連部門のかかる工数もしっかりと，リソースに含めておかなければなりません。

改善スケジュールを引く

リソースがおおよそ決まり確保できたら，残っていた着手する「時期」を加味し，必要な工数の線引きをしましょう。ただし，まだこの段階ではスケジュールらしきものができただけで，タスクやチーム間での調整が必要となります。

次回はこのタスク，チーム間の調整と，今回最初にお話をした「ほったらかしで改善実行（Do）を進む」ように，少しばかり改善スケジュールに仕掛けを入れることをお伝えします。