業務改善の計画はできた。あとは実行のみ……だけど実行できないのでは絵に描いた餅で計画倒れになってしまいます。今回は、改善計画のちょっとした仕掛けから、まずはお伝えしていきます。

改善チーム間のタスクとリソース調整

前回の連載の最後で、改善のスケジュールを引くというテーマで、必要な工数の線引きをするところまでお話をしています。改善チーム（自部門だけではなく、関連する前後工程部門との混成チーム）の単位ごとにスケジュールができているはずです。ここで、気を付けなければいけないことがいくつかあります。

改善計画をつくっているときは皆、自分たちのチームのスケジュールづくりに没頭してしまい、ほかの改善チームのスケジュールまで見ている余裕はありません。したがって、改善チームスケジュールの構成要素であるタスクを、チーム間で調整するプロセスが必要となります。

とくに次の2項目は、実行段階になってから「できない理由」になりがちなので、計画段階で調整を行います。

（1）メンバーが重複している場合

改善に関わるメンバーが潤沢にいればよいのですが、実際には「改善チームA」の「改善タスクA-1」の主要メンバーであるAさんが、「⁠改善チームB」の「改善タスクB-3」の主要メンバーであることも少なくありません（図⁠）⁠。

「改善タスクA-1」と「改善タスクB-3」の時期がずれていれば、まったく問題がないこともあります。実際、Aさんは改善チームAと改善チームBの改善計画づくりに関与しているので、本来であれば、「⁠同時期に2つはできないよ」という話も出てくるでしょう。その場合は、自然にチーム間のタスク調整を行うこともありますが、多くの場合、どちらかの改善チームに重点を置いて計画づくりを行うケースがほとんどなので、最後の全体計画調整時に同一メンバーの重複タスクをやりくりすることになります。

この場合、どちらかのタスクの開始時期を完全に重ならないようにするため、メンバーアサインを再検討することとなります。しかし、最も業務に精通しているキーマンがAさんで、ほかの人は考えられないということもあるので、その場合は時期をずらすか、改善チームのテーマそのものを１つにする、すなわち、改善チームAと改善チームBを一緒にすることも検討します。

（2）チームのアウトプットが他のチームのインプットである場合

改善チームAのアウトプットが、改善チームBのインプットになっている場合があります。先ほどの図をご覧ください。どういうことかというと、改善チームAのアウトプットを用いて、改善チームBの業務改善が始まる場合です。

この場合は、改善チームAのアウトプットが完了するまで（タスクが終わるまで⁠）⁠、改善チームBの改善計画に書かれている最初のタスクは開始できなくなります。したがって、万が一、「⁠改善タスクA-1」に遅れが発生し「改善タスクB-2」が予定どおりに開始できなくなる場合を想定しないといけません。

なお、これらはプロジェクトマネジメント（PM）の世界では当たり前のことで、やり慣れている人もいますが、本社や管理部門などの改善では、PMなど聞いたこともないという人もいるので、わかる人が陣頭指揮をとることも重要です。

改善計画は表計算ソフトで十分！

スケジュール管理、リソース調整、進捗管理他、パレート図などが簡単につくれる便利なプロジェクト管理用ソフトウェアに、マイクロソフト社の「Project」があります。先のようにメンバーが重複していると、リソースのアラートが出たり、タスク間の調整が容易にできるので非常に便利です。

ただし、改善メンバー全員がこのようなソフトを使う必要はありませんし、費用面、習熟の差、インフラによっては全員が使える環境にない場合もあります。それに、「⁠お金をかけないで改善をする」ことも大事だと前回お話したので、使い慣れたExcelのような表計算ソフトの活用で十分です。

これは、次回以降でお話しますが、改善計画を改善チーム以外の部門や人に見てもらうことも大事でからです。その際、特別なソフトがないと見ることができないという状況にならない、日常的に業務で用いているソフトのほうが都合がよいことも理由です。我々がお手伝いをする企業も、表計算ソフトで済ませている企業が多くあります。

自分以外に影響を与える意図的なスケジュールをつくる

改善計画づくりまで、長いステップを踏んできましたが、改善計画ができた段階で、メンバーの中には息切れをしてしまう、改善計画をつくって安心してしまう……など、多少、気の緩みが出ることがあります。傍から見ていると、「⁠まだ、改善始まってないじゃん」の段階です。

このような場合は、自分以外に影響を与えるスケジュールを意図的につくるように仕向けます。つい先ほどまでは、チームのアウトプットがほかのチームのインプットになる場合は、関連タスクの遅れを考慮しなければいけないとお話しましたが、これを逆手に取ります。

タスクAとタスクBがまったく違うメンバーや部門である場合、

• 他部門に迷惑がかかる
• 他部門に迷惑がかかってから、自部門や自分自身にも被害を受ける

ようなスケジュールにします。

第2回で述べた「自分が困るプロセス」と同じ原理です。「他人に迷惑もかかるし、自分自身も困る」というロジックを仕掛けておきます。

タスクを上下に入れ替える複雑な作業になりますが、やたら手間のかかるこのような改善計画の出来不出来で、後に発揮する改善効果が大きく変わってきます。改善計画そのものはオープンにし、心理的にも「やらざるを得ない環境」にさりげなく追い込んでいるわけです。

当事者意識の醸成（Planをした人がDoする意味）

計画倒れに対する予防線であり、改善計画ができたことで息切れを起こすことも多いので、先ほど述べたようにタスクに少しばかり手間のかかる仕掛けを設けました。第9回において、「⁠自らPlan、自らDo！」として、「⁠自分たちでつくった計画は自分たちでやろうよ！」が鉄則と書いています。

無関心な現場に徐々に当事者意識を芽生えさせることは、相当、エネルギーのいることです。

極端な言い方をすれば、無関心な職場に身を任せている一人ひとりは、本人の問題意識の有無にかかわらず、ごく普通に毎日がそつなく過ごせればよいので、改善意欲はありません。他人、他部門に対しての関心は希薄です。ただし、自分に影響のあることは、やたら最優先してしまいます。

• "やらされ感"をなくす
• "気づきのプロセス"と"自分が困るプロセス"を仕掛ける
• "ソフト領域"にも目を向けケアする
• 業務調査、業務分析は自分たちで行い、業務フローも自分たちでつくる
• 原因分析、解決策も自分たちの頭で考える
• 現場でカウントできるKPIを定める

など、指示待ち・受け身から能動的に動くように、これまでに経営トップや周囲環境の整備も含めてお伝えしてきました。

あとは、いよいよテイクオフ！となりますが、その前にもう少し、Do以降のことを決めておく必要があります。

情報共有とレポーティングラインを決める

DoとCheckの仕掛けをつくります。基本は、第11回で述べたように、「業務改善に関わる報告・管理業務はミニマムに！」です。

業務改善の実行（Do）段階では、同時にいくつもの改善チームが動き出します。改善の事務局などとりまとめのPMも詳細な動きや進捗までは追い切れませんが、チーム間のタスクが相互に影響し合うつくりにしておくことで、PMがあれこれ細かく調整をする事態はうんと減り、チームの責任者同士で話をすればおおよそのことは解決できるはずです。

とはいえ、改善メンバーはほかのチームの進み具合はどうなっているのかなとか、自分たちのチームは遅れているのかもしれないという心理は常に働くので、改善計画の進捗と途中の成果物、課題などは全て共有します。

「業務改善のサイト」などと題してイントラネット上にホームページで情報共有してもよいでしょう。

一方、レポーティングラインは、進捗具合をはじめ、改善実行において当初、予期しなかった問題に出くわすこともあり、内容によっては自分たちのチームだけでは解決できないこともあります。

したがって、定期的に次示す項目などをPMに報告しながら、チーム間でも共有をはかります。

• 進捗の予実報告
• 発生した問題と考えられる対策
• 自分たちで解決できそうか、他部門、他チームの協力が必要か？
• 成果物（途中のものもOK）
• 改善効果（KPI設定を行った途中のプロファイルを生データで）

書式も定めて、紙1枚で十分でしょう。

この報告は毎日出す必要はなく、改善効果の発揮具合により定めるとよいので、1週間単位や2週間単位になります。1週間ではほとんど効果が出ないタスクを毎週、報告しても意味はないので、効果が出るまでに時間のかかるものは2週間以上の単位でもいいわけです。すべてのチームが同じ時間単位で報告を行う必要はありません。

Planをした人がDoをする。イメージはつかめましたか？

さて、次回は、「⁠責任と権限の与え方」「⁠責任者の役割」と、改善を社内への見せ方として「社内広報の重要性」を予定しています。