成果は出ていた。しかし、仕組みだけでは動いていなかったケース

表面上は、順調に見えていた

売上は安定しており、主要なプロジェクトも継続していました。

大きな問題は起きていない。
制度もプロセスもある。
各部門も、それぞれの役割を果たしている。

外から見れば、組織は十分に機能しているように見えました。しかし、実際の動き方を見ていくと、成果は仕組みだけから生まれていたわけではありませんでした。

仕組みを動かしていたのは、人だった

重要な意思決定ほど、限られた人に集まっていました。

部門をまたぐ仕事では、正式なプロセスを通すだけでは前に進まず、事情を理解している人が個別に説明し、関係者の前提を揃え、判断を促していました。

制度で扱えない例外が起きると、特定の人が引き取りました。

誰に確認すればよいか分からないときも、最終的には「この人に聞けば何とかなる」という非公式な経路に集まっていました。

仕組みは存在していました。しかし、必要な行動が仕組みからそのまま生まれていたのではありません。

人が解釈し、つなぎ、確認し、例外を引き取ることで、仕組みが動いていたのです。

人が支えること自体が、問題なのではない

立ち上げ期や変化の途中では、人が仕組みの隙間を埋めることは避けられません。

  • まだ決まっていないことを判断する。
  • 部門間の前提を翻訳する。
  • 想定外の事態に対応する。
  • 顧客や現場に合わせて調整する。

こうした行動は、組織が前に進むために必要です。

問題は、人が判断や調整をしていることではありません。本来は一時的であるはずの働きかけが、いつの間にか恒常的な成立条件になっていたことです。

  • 誰が、どこで、何を埋め続けているのか。
  • その人がいなくても、同じ行動は生まれるのか。
  • 事業が拡大したとき、その働きかけも同じように増やせるのか。

それが見えないまま、成果だけが計上され続けていました。

成果の数字だけでは、違いは見えない

例えば、成果が「10」出ている二つの組織があったとします。

一方では、役割の中で必要な判断が行われ、部門間の受け渡しが完結し、例外も定められた経路で処理されています。

もう一方では、曖昧な部分を特定の人が解釈し、確認し、個別に調整することで、同じ成果を成立させています。

外から見える数字は、どちらも「10」です。
しかし、成り立ちは異なります。

  • 人が替わったとき。
  • 業務量が増えたとき。
  • 新しい制度やAIを導入したとき。
  • 判断の速度を上げたとき。

違いは、そのときに現れます。成果が出ていることは、仕組みから必要な行動が生まれていることを意味しません。

このケースで目指した挙動

このケースで必要だったのは、単に売上やプロジェクトを維持することではありませんでした。目指したのは、次のような行動が、特定の人による継続的な働きかけに依存せず生まれる状態です。

  • 必要な判断が、判断すべき役割の中で完結する
  • 部門が異なっても、仕事の前提と目的が共有される
  • 例外が発生したとき、誰がどこまで扱うかが分かる
  • 次の工程へ渡す情報と、完了の基準が明確になっている
  • 担当者が替わっても、同じ確認や調整を最初から作り直さなくてよい
  • 問題が起きるたびに、特定の人へ判断が集中しない

これは、人を不要にするという意味ではありません。人にしかできない判断を、人が行わなくてよい状態にすることでもありません。

必要な判断や調整が、仕組みの外に放置されず、役割と経路の中で成立する状態をつくるということです。

現在の動き方を生んでいた条件

実際の動き方を見ていくと、制度やプロセスが存在しないわけではありませんでした。しかし、いくつかの条件が揃っていませんでした。

責任と判断範囲が一致していない

結果への責任は与えられていても、その結果に必要な判断を行える範囲が明確ではありませんでした。そのため、担当者は責任を持ちながら、判断のたびに上位者や関係部門へ確認する必要がありました。

部門間で前提が揃っていない

同じ言葉や同じ目標を使っていても、部門ごとに解釈が異なっていました。正式なプロセスだけでは、その違いを扱えません。結果として、双方の事情を知る人が間に入り、前提を翻訳していました。

正式なプロセスだけでは仕事が完結しない

手順は定められていました。しかし、どの状態になれば次へ渡してよいのか、例外を誰が判断するのか、どこで仕事が完了するのかが曖昧でした。そのため、プロセスの外側に確認、補足説明、再調整が発生していました。

例外処理が特定の人に集まる

制度で扱えない事態が起きたときの経路が定義されていませんでした。例外は、最も事情を知っている人、最も判断できる人、最も断りにくい人へ集まっていました。

こうした条件のもとでは、確認、調整、非公式な相談、判断の集中が合理的な行動になります。人が勝手に仕組みを外れていたのではありません。現在の条件が、その動き方を生んでいたのです。

仕組みを替えるだけでは、同じ調整が戻る

この状態で新しいシステムを導入しても、判断範囲が曖昧なままであれば、システムの外側で確認が続きます。組織図を変更しても、部門間の前提が揃っていなければ、新しい境界で同じ調整が発生します。プロセスを細かく定義しても、例外の扱いや完了条件が曖昧であれば、現場が再び隙間を埋めます。AIを導入して処理を速くしても、その出力を誰が判断し、どこへ渡し、どの時点で完了とするかが決まっていなければ、人による確認と手直しが別の場所へ移ります。

道具や制度を替えても、それまでの調整を合理的にしていた条件が残っていれば、同じ挙動は形を変えて戻ってきます。

実装が満たすべき条件を先に定義する

このケースで必要だったのは、最初から特定の解決策を選ぶことではありませんでした。
先に必要だったのは、どのような実装を選ぶ場合にも外せない条件を明らかにすることでした。例えば、次のような条件です。

  • 責任を持つ役割に、必要な判断範囲が与えられている
  • 判断に必要な前提と情報へ、その役割から到達できる
  • 部門をまたぐ仕事の目的、入力、出力、完了条件が共有されている
  • 通常経路では扱えない例外の判断先と戻り先が定義されている
  • 仕事が途中で宙に浮かず、次の行動まで接続している
  • 現在、人が非公式に担っている有効な判断や知識を、変更時に失わない
  • 人が仕組みを支える量が、拡大に伴って増え続けない
  • 実装後も、確認、調整、例外処理が別の場所へ移っていないかを観測できる

これらは、特定のツールの機能要件ではありません。AI、業務システム、組織変更、制度改定、プロセス再設計のいずれを選ぶ場合にも、その実装が満たす必要がある条件です。

観測によって変わったのは、問題の見え方だった

当初は、意思決定が特定の人に集中していることや、部門間の調整が多いことが問題に見えていました。しかし、観測によって見えてきたのは、それらが単独の問題ではないということでした。

  • 判断範囲が完結していない。
  • 部門間の前提が接続されていない。
  • 例外処理の経路がない。
  • 仕事の完了条件が曖昧になっている。

その条件のもとでは、誰かが確認し、つなぎ、引き取ることが必要になります。見えていた調整は、原因ではありませんでした。その構造の中で成果を成立させるために、合理的に生まれていた行動でした。

「動かす仕組み」から「動く仕組み」へ

このケースの成果は、本物でした。人がつくった成果であることも、否定する必要はありません。

ただし、その成果を続け、引き継ぎ、拡大していくためには、人が仕組みを動かし続ける状態から、必要な行動が構造条件から生まれる状態へ移る必要があります。

大切なのは、人の働きを減らすことではありません。人が本来担うべき判断と、仕組みの不足を埋めるために繰り返している仕事を分けることです。

仕組みはすでにある。成果も出ている。それでも、確認、説明、調整、例外判断を人が支え続けているなら、次の解決策を選ぶ前に見るべきものがあります。

今の動き方を、何が生んでいるのか。そして、望む行動が人の継続的な働きかけに依存せず生まれるために、次の実装は、どの条件を満たさなければならないのか。

構造ディスカバリー

構造ディスカバリーは、一つの成果や運用を起点に、現在の実際の動き方を生んでいる条件を、経営者とキーメンバーで観測する120分のセッションです。

解決策を決める場でも、構造診断を確定する場でもありません。

  • どの条件が、現在の挙動を生んでいるのか
  • どこで人の判断や調整が成立を支えているのか
  • なぜ同じ確認や例外処理が戻ってくるのか
  • 現在機能している何を壊してはいけないのか
  • 望む挙動に向けて、次に定義すべき条件は何か

これらを構造仮説として言葉にし、望む挙動の成立条件を本格的に定義する必要があるかを判断します。