理由：三つの構造的パターン
変革が定着しない組織には、共通した構造がある。
改善がプロジェクトとして切り出される
「今期の変革テーマ」としてプロジェクトが立ち上がる。専任チームが分析し、課題を特定し、解決策を実装する。成果が出れば報告し、プロジェクトは完結する。翌年、また別のプロジェクトが立ち上がる。改善は繰り返されるが、組織の動き方そのものは変わらない。改善が「イベント」として消費されている。
変革の主体が外部にある
外部コンサルタントや専門組織が改善を「代行」した瞬間、変革は他人事になる。分析はされている、資料も整っている。しかし事業を動かしている主体自身が、思考し、判断し、改善する経験を積んでいなければ、フレームワークを「使った」だけで何も変わっていない。
振り返りが学習になっていない
改善が成果で完結し、「なぜそのやり方を選んだのか」「どこで議論が噛み合わなかったのか」が言語化されない。経験が次に活かされない。改善が「点」で終わり、「線」にならない。
補足：「変革できる会社」との差
「変革できる会社」と「変われない会社」の差は、特別な施策を持っているかどうかではない。全社が同じ方向を向いて改善を積み重ねられる状態を維持しているかどうかだ。この状態をつくるために必要な問いは一つに集約される。「どのお客様に、どのような価値を、どのような方法で届けることが最も合理的か」。この問いに経営・企画・現場が同じ理解で答えられているか。ここにコンセンサスがなければ、個別の改善をいくら積み上げても全社としての変革にはつながらない。
具体例
製造業において日本企業が改善を定着させてきた理由はシンプルだ。外部任せにせず、方法論は学ぶが改善は自分たちで回してきた。現場が主体となって試し、失敗し、振り返り、次に活かす。この繰り返しが、改善を一過性の取り組みではなく日常の仕事の一部として根づかせた。
ビジネスプロセスの変革でも、同じことができる。違うのは対象がモノか情報・判断か、それだけだ。
変革を定着させるために必要なのは、より強力な施策ではない。改善の主体を現場に置き、思考のプロセスを組織に移転し、自律的に改善が回り続ける状態をつくることだ。ATBSのTRANSFERフェーズは、この移転を目的として設計されている。