改善が得意な会社ほど、変革できない
「AIで業務を変革しよう」という会議で、削減時間の話ばかりしていることがあります。資料作成を30％短縮できる。問い合わせ対応を20％効率化できる。議事録作成をほぼゼロにできる。どれも悪くありません。むしろ、やったほうがいい。
ただ、そこで少し意地悪な質問をしてみたくなります。その資料、本当に必要なのでしょうか。問い合わせに速く答える前に、問い合わせ自体をなくせないのでしょうか。議事録を自動化する前に、その会議はまだ必要なのでしょうか。ここまで聞くと、話の種類が変わります。
改善が得意な会社ほど変革できないのです。変革を邪魔するのは、誰が見てもダメな仕組みではありません。長い時間をかけて、優秀な人たちが丁寧に改善してきた、かなりよくできた仕組みです。
変革が戦う相手は「悪い現状」ではない
たとえば、ある業務に100時間かかっていたとします。現場がExcelを直し、承認工程を減らし、判断基準を標準化する。100時間は90時間になり、70時間になり、ついには60時間になる。品質も上がってAになりました。
そこへAIを使った新しい仕組みが出てきます。40時間でできる。ただし品質はBです。すると、当然こう言われます。「今より品質が落ちますよね」。はい。落ちます。では却下でしょうか。
ここで考えたいのは、そもそも品質Aは必要なのかということです。事業に必要な品質がBなら、比較すべきなのは「現在のA」と「新しいB」ではありません。「必要十分な品質」とBです。ところが、何年も改善していると、いつの間にか「今できている品質」が「必要な品質」にすり替わります。
これは少し怖い話です。昨日まで「品質を上げろ」と言われて頑張った結果、品質を上げすぎたことで、今日の変革を拒否する理由ができてしまう。つまり改善は、コストを下げるだけではありません。現状を正当化する根拠まで強くしていくのです。
改善と変革は、そもそも問いが違う
改善と変革は、同じゲームの初級編と上級編ではありません。改善は、「この仕事をどうすればもっと良くできるか」と考えます。変革は、「なぜ、この仕事をしているのか」と考えます。
100時間を90時間にするのが改善で、10時間まで頑張れば変革になるわけではない。場合によっては、変革の答えは「0時間」です。
James Marchは、組織の活動を既存能力を磨くExploitationと、新しい可能性を試すExplorationに分けました。前者は成果が早く見えます。100を99にすれば、その瞬間に成果です。一方、探索は最初からうまくいくとは限りません。Mary BennerとMichael Tushmanの研究でも、プロセスマネジメントが強くなるほど、既存知識を使った漸進的なイノベーションが増え、探索的なイノベーションが押し出される傾向が示されています。
これは、「改善しすぎるな」という話ではありません。もっと厄介です。改善に適した経営の仕組みと、変革に適した経営の仕組みが違うという話です。
改善では、ばらつきを減らしたい、標準化したい、予算通り進めたい、再現性を高めたい。一方、変革では、むしろ違うやり方を試したい、失敗しながら前進したい、まだ正しいKPIさえ分からない。片方は「予定外をなくすゲーム」で、もう片方は「予定外から学ぶゲーム」です。同じ管理方法で両方うまくやろうとするのは無理があります。
新しい仕組みは、10年間改善された仕組みと初日から戦わされる
さらに変革には、かなり不利な条件があります。現在の60時間・品質Aの仕組みには、何年分もの改善が乗っています。現場の知識も、例外処理も、マニュアルもそろっています。一方、新しいAIの仕組みは導入初日です。
それを並べて、「ほら、今のやり方のほうが品質が高い」と言う。まあ、それはそうでしょう。10年間練習してきた選手と、今日入社した新人を試合させています。
そして新人が負けると採用しない。採用しないから新人は経験を積めない。翌年また試合をすると、やっぱり10年選手が勝つ。こうして、改善が得意な会社には「強すぎる現在」ができます。
変革が難しいのは、新しい技術が未熟だからだけではありません。現在の仕組みが、あまりにもよく訓練されているからです。
もっと困るのは、仕組みではなく人が成功していること
ここまでなら技術論で済みます。でも会社には人がいます。100時間を60時間にした人にとって、その60時間は単なる数字ではありません。何年もかけた仕事の成果であり、専門性であり、昇進や評価につながった実績です。
「60時間を50時間にしましょう」なら、その人はまだ主役です。では、「この業務そのものをなくしましょう」と言われたらどうでしょう。これは改善案ではありません。その人が過去に成功してきたゲームそのものを終了させる提案です。
そう考えると、変革に反対する人を「既得権益にしがみついている」と片付けるのは少し乱暴です。むしろ逆かもしれません。現在のKPIを守り、品質を高め、会社から求められた仕事を立派にやってきた人ほど、変革に合理的に反対します。つまり、変革に抵抗している人のほうが、現在の会社の評価制度には忠実だったりする。
ここはかなり重要です。問題は「変化を嫌う人」ではありません。昨日までの成功者を作った会社のルールが、今日の変革者を低く評価することです。
『最高を超える』の面白さは、改善と変革を混ぜていないこと
フランク・スルートマンの『最高を超える』を、この観点から読むと面白くなります。スルートマンは、仕事の速度を上げろ、基準を上げろ、もっと高い水準で実行しろ、と猛烈に要求します。一見すると、究極の改善本です。
ところが同時に、彼はIncrementalism、つまり小さな改善だけを積み重ねる発想と戦えと言います。戦略そのものを変える話もかなり出てきます。これは矛盾ではありません。
今のゲームを続けると決めたなら、異常な速度で改善する。でも、ゲームそのものが間違っているなら、改善をやめる。
実は難しいのは改善ではなく、この切り替えです。改善が得意な人に「次に何をしますか」と聞けば、今の仕組みをさらに良くする案が返ってきます。それは能力が低いからではありません。むしろ高いからです。
改善能力の高い人ほど、次の改善案を10個くらい簡単に出せます。だからこそ、「そもそも、このゲームを続けるべきなのか」という11個目の問いが出にくい。改善活動の中から、変革の問いが自然に生まれるとは限らないのです。
中間管理職の変革には、経営陣との「契約」がいる
ここで、経営者がする変革と中間管理職がする変革には大きな差があります。CEOなら、「今年は利益が落ちてもいい」「品質Aはもう要らない」「この部署はなくす」と決められます。中間管理職には、その権限がありません。
しかも変革の途中では、数字が一度悪くなる可能性があります。コストが増える。品質が落ちる。苦情が出る。年度評価だけを見れば、「変革した人」ではなく「KPIを悪化させた人」です。
だからスポンサーが必要になります。ただし、「いいね、やってみよう」と言ってくれる人では足りません。必要なのは、「この案件は既存KPIだけで評価しない」「品質はここまで落ちてもよい」「最初の失敗だけでは止めない」と決められる人です。
つまりスポンサーとは、変革を応援する人ではありません。変革者が既存ルールで負けないように、ルールを一時的に変える人です。
イノベーション研究でも、探索を促すには初期の失敗への一定の寛容さと、長期的な成果への評価が必要だとされています。「失敗を恐れるな」と言うだけでは簡単です。本当に必要なのは、失敗しても次を試せることを、失敗する前に約束しておくことです。
経営陣がそこまで守ってくれないなら、どうするのか
では、経営陣がそこまで守ってくれない会社で、中間管理職はどうするのでしょうか。変革するな、という話になるのでしょうか。
私は、そうは考えていません。
AIは改善にものすごく向いています。だから放っておけば、会社のAI活用は自然に「今の仕事を速くする」方向へ進みます。成果も説明しやすいし、誰もあまり怒りません。
でも管理職になったのであれば、一度くらいは「これをどう効率化するか」ではなく、「これ、まだ要る？」から考えてみたほうがいい。
もちろん、安全ではありません。変革を仕掛ければ、現在の会社では低く評価される可能性もあります。だから、ここは少し乱暴なくらいでいいと思っています。「ここで評価を落としても、この経験を持って次の会社へ行けばいい」くらいのキャリア上の余白を持つ。
私自身、仕事の進め方や組織、役割そのものを大きく変える仕事を何度も経験してきました。すべて成功したわけではありません。それでも「何を壊すべきかを見つけ、既存の仕組みと調整しながら新しい形へ移す」という経験は、会社が変わっても使えました。
社内評価だけを最適化すると、どうしても改善者になります。それはそれで立派です。でも変革したいなら、少しだけ社内評価から自由でいる必要があります。
変革とは、ダメな仕組みを直すことではありません。まだ十分うまく動いている仕組みに対して、「それでも、これは未来にも必要なのか」と問い続けることです。
改善案を出す人は、会社の中にたくさんいます。管理職にしかできないのは、「そもそも、この仕事を残すのか」を問い、その答えを引き受けることです。
あわせて読みたい
生産性を上げるために仕事を減らす
仕事を速く処理するだけでは、生産性には限界があります。やるべきなのは、価値の低い仕事を効率化することではなく、そもそも仕事を減らすこと。今回の「改善ではなく、業務そのものを問い直す」という話に最も近い記事です。
仕事が速くなっても、生産性は上がらない
一人ひとりの作業速度を上げても、組織全体の成果が増えるとは限りません。「作業を速くする」と「仕事の構造を変える」を分けて考える記事で、AIによる部分最適がなぜ変革にならないのかを補完します。
マネジメントは、人を管理する仕事ではない
人にAIを使わせて効率化するのではなく、仕事をなくし、仕組みやAIへ移し、その後に組織を作り替える。今回の記事を「では、管理職は何を変えるべきなのか」という側から掘り下げています。
「業務設計は人間、実行はAI」ではない。
AIは決められた作業を実行するだけでなく、設計や改善にも入り始めています。「現在の人間の仕事をどうAIで支援するか」ではなく、人とAIの境界そのものを引き直す必要がある、という記事です。
「視座を上げる」は「上司の立場で考える」ではない
中間管理職が変革を起こすには、経営者になったつもりで考えるのではなく、一段上の意思決定を具体的に提案し、判断理由を学び、実行まで引き受ける必要があります。今回の記事の「中間管理職による変革」を、個人の行動まで落とした記事です。
