「組織の壊し方」を逆用して、動かない組織をぶっ壊すには？

『組織の壊し方』を逆から読むと、AIの使い道が見えてくる

昔のスパイ文書に、いまの会社員が読むと胃が痛くなるものがある。1944年にCIA（の前身）が出した『組織の壊し方（Simple Sabotage Field Manual）』だ。

戦時下の破壊工作マニュアルなのだが、いまはCIAのサイトでも読むことができる。面白いのは、爆破や破壊だけではなく、「組織をどう骨抜きするか」にフォーカスしていることだ。

そこに並んでいるのは、派手な破壊工作ではない。

何でも正規ルートに通す。すぐ委員会に回す。会議では長く話す。関係の薄い論点を持ち込む。言い回しの細部で止まる。前回決めた話を蒸し返す。慎重さを理由に判断を延ばす。権限や上位方針との整合ばかり気にする。書面を求め、やり取りを増やし、重要な仕事よりどうでもいい仕事を先に割り振る。

文書は、そうした振る舞いを、組織と生産を内側から鈍らせる手口として列挙している。つまり、仕事回しをグダグダにするほうが、爆弾や拳銃より効率よく組織を破壊できるということだ。

ひょっとして、あらゆる日本の大企業の中にはCIAのスパイが入り込んでるのでは？という陰謀論にとらわれかねないほど、日本の大企業はこのような状態に陥っている。

慎重さも、整合性の確認も、手続きも、本来は必要だ。けれど、それが重なりすぎると、組織は壊れるというより、じわじわ動かなくなる。だいたいの組織不全は、大きな事故より前に、こういう小さな摩擦の蓄積として始まる。

だから逆転させてみよう

実はこのマニュアルの真に面白いところは、逆から読めることだ。

「組織の壊し方」は同時に、「組織を壊さないために何を減らすべきか」のチェックリストでもあるからだ。

何でも会議にしない。誰が決めるかを曖昧にしない。低リスクな話まで上に持っていかない。文言の調整で決定そのものを止めない。ひっくり返すなら、新しい事実を持ってくる。要するに、前に進む力を削る摩擦を、早めに見つけて減らせばいい。

ここでAIの使い道が見えてくる。生成AIは「書く」ほうで語られがちだが、むしろ「詰まりを見つける」ほうが筋がいい。

だから「組織の壊し方」をAIに読み込ませて、その逆をすればよいのである。

Slackのやり取り、会議の議事録、チケットのコメントを見て、「この話は三回差し戻されている」「小さな案件なのに承認者が増えている」「論点だけ増えてオーナーが決まっていない」「前に決めた話を、追加情報なしで再オープンしている」といった兆候を拾う。人の心を読むためではない。組織がどこで自分にブレーキをかけているかを見えるようにするためだ。

もちろん、ブレーキを全部外せばいいわけではない。そこを雑にやると、今度は無防備の暴走になる。法務、セキュリティ、財務、対外信用のように、止めるべき案件はちゃんと止める必要がある。必要なのは、全部を速くすることではなく、「現場で進めていいもの」と「上に上げるべきもの」を、迷いにくくすることだ。

その意味で、AIにやらせるべき仕事は二つある。ひとつは、摩擦の検知。もうひとつは、権限とリスクの仕分けだ。たとえば、あとから戻せる変更で、金額も小さく、法務やセキュリティへの影響もなく、顧客影響も限定的なら、現場で進めさせる。逆に、戻しにくく、対外影響があり、規制やセキュリティに触れるものは、上に上げる。AIがこの一次判定を手伝えれば、現場は必要以上に止まらず、本当に危ないものだけがちゃんとエスカレーションされる。

大事なのは、これを「人の監視」にしないことだ。誰が空気を悪くしたか、誰が慎重すぎたか、という個人評価に寄せた瞬間に、AIは新しい官僚制になる。人は良い議論をするようになるのではなく、怒られない言い方を覚える。見るべきなのは個人の性格ではなく、会議、承認、再審議、エスカレーションのパターンだ。AIは査定官ではなく、組織のダッシュボードであるべきだと思う。

行き過ぎたGOはAIが止めてくれる。慎重すぎる仕事まわしはAIが指摘してくれる⋯そういった心理的安全性ハーネスを、職場に埋め込むことはできないだろうか？

組織を止めるのは、たいてい大失敗ではない。小さな善意の積み重ねが、いつのまにか前に進む力を食ってしまう。だから「組織の壊し方」は、いま読むと逆向きの経営教科書になる。AIの価値は、何かを派手に自動化することより先に、組織が自分で踏んでいるブレーキを見つけ、必要なものだけ残して、不要なものだけを外していくところにある。

実際に組むなら、どういう構成になるか

最小構成なら、四つの層に分けるのがわかりやすい。

まず入力層。Slack、会議の文字起こし、チケット、稟議ログを集める。ただし、いきなり個人のDMまで広げず、公開チャンネルや公式な業務ログから始めるのがいい。

次に判定層。ここはルールベースとLLMの併用が現実的だ。承認者の数、差し戻し回数、再オープン回数、オーナー未設定のままの経過日数のようなものはルールで取れる。一方で、「論点が増えすぎている」「言い回しの話に寄りすぎている」「同じ慎重論が繰り返されている」といった曖昧な詰まり方は、LLMのほうが拾いやすい。

その上に、権限・リスク判定の層を置く。あとから戻せるか、金額はいくらか、顧客影響はあるか、法務やセキュリティに触れるか、対外説明が必要か。そうした観点で、現場決裁でよいもの、要レビューのもの、必ず上申すべきものに分ける。

最後が通知層だ。ここで強い警告を出すと嫌われるので、「この論点は前回も議論されています」「この案件はチーム権限で進められます」「この変更はセキュリティレビュー対象です」といった、軽いナッジから始めるのがよい。日次の監視より、週次のサマリーのほうが受け入れられやすい。

運用でいちばん大事なのは、個人評価と切り離すこと、判定根拠を見えるようにすること、そして人間がいつでも上書きできることだ。そこを外さなければ、AIは「監視装置」ではなく、「組織の摩擦を減らすための補助輪」になれる。