【IDO】第15回:なぜ、あなたのIDOは「起動」しないのか?── それは「設計ミス」ではない。リーダーの“電源”が入っていないからだ。【実装編】
IDOがうまくいかない理由を、組織や現場のせいにしていないだろうか。
「現場が動かない」「Intentを伝えても確認してくる」「任せたら勝手なことをする」
しかし、その原因は、もっともっと単純なところにあるのかもしれない。
"From Control to Intent"
── 組織OSを「企図」で再起動する。
出典:Caspar David Friedrich Woman at a Window, Public Domain)
【免責事項】
本稿は筆者個人の見解であり、所属組織の公式見解を示すものではありません。また、記載内容は公開情報および一般化・抽象化された概念に基づいています。
IDO(目的主導型業務遂行)という概念を理解し、いざ現場に導入しようとしても、多くの組織でシステムは「フリーズ」します。
「企図(Intent)は伝えたはずだ」
「現場に任せると言ったはずだ」
「権限も渡した」
それなのに、組織は一向に自律へと向かわない。
それは、組織のどこかで「意志の伝達」が目詰まりを起こしているか、あるいはシステムを動かすための「電源」が入っていないからです。
今回は、IDO不全の正体を解剖し、実装への壁を明らかにします。
1. IDO不全のチェックリスト:6つの「関門」
IDOが機能しない原因は、リーダーの脳から現場の行動に至るまでの、どの階層で「情報の不全」が起きているかによって、以下の6段階に分類されます。あなたの組織は、どこで止まっているでしょうか。

⚠️止まりポイント
①Purpose(目的)不在:
そもそも「なぜやるのか」が定義されていない。
👉 「そもそも、何のためにやっているのかが分からない」
②Intent(企図)不在:
目的が分かっいても、「何を優先し、何を捨てるか」が決まっていない。
👉 「結局、何を基準に判断すればいいのか分からない」
③Intent不明確:
Intentは存在するが、抽象的すぎて現場が判断に使えない。
👉 「言っていることは分かる。でも、今この場面でどう判断すればいい?」
④Intent不同期:
企図が上位者の頭の中や会議室に留まり、現場の判断空間まで届いていない。
👉 「現場は聞いていない」
⑤現場の解釈不足:
言葉は届いている。
しかし、自分の仕事、自分の役割、自分の目の前の状況にどう適用するのかが分からない。
👉 「自分の仕事にどう当てはめればいい?」
⑥「独断」が起動しない:
ここまで全て揃っている。
でも、最後の一歩「自分で決める」ことが出来ない。
👉 「間違っていたらどうしよう」「上司に怒られないだろうか」「一応、確認しておこう」
そして、確認文化が再び起動する…
重要なのは、このチェックリストで出来ていないことを「すべてを一度に直そうとしないこと」です。
まず、「今、この組織で意思決定を止めている最大のボトルネックはどこか」を見つける。
そして、 “一番止まっている1箇所”だけを直す。
あなたの組織のIDOはそこから起動します。
2. しかし、それでも動かない組織がある
ここまでの議論は、すべて「構造」の話でした。
Purposeを定義する。
Intentを設計する。
Intentを翻訳する。
同期する。
判断する。
フィードバックする…
これらを正しく設計しても、なおも組織が動かないことがあります。
ここで初めて、「電源」の問題が出てきます。
IDOコンセプトという組織OSをインストールしても、組織の電源が入っていなければ、システムは動きません。
では、この「電源」とは何でしょうか?
3. IDOを起動する「電源」とは何か

IDOコンセプトにおける組織の電源とは、
「自分が定義したIntentによって現場に判断させ、その結果について自分が責任を引き受ける思想」
です。ここが従来の「権限委譲」とは決定的に違います。
権限委譲では、
「あなたに任せる」
と言うことが出来ます。
しかし、IDOコンセプトでは
「この判断空間をあなたに渡す。その判断の結果は、私が引き受ける」
というところまでリーダーが踏み込みます。
だからこそ、現場は判断出来る。リーダーは簡単に口を出してはいけない。
そして、必要な時には、リーダー自身がIntentを更新する。
「任せる」と「放置」は似て非なるものです。
4. リーダーが「手放せない」本当の理由
自律型組織への移行で、最も難しいには現場に権限を渡すことではありません。
リーダーが「コントロールを手放すこと」です。
「口では『任せる』と言いながら、現場の細部に口を出す」
「失敗の兆しが見えると、すぐにハンドルを奪い取る」
「自分と違う判断を見ると、修正したくなる」
これはリーダーの性格が悪いからではありません。
不確実性を自分の管理下に置こうとする、極めて自然な人間の反応です。
しかし、その反応を繰り返せば、現場はすぐに学習します。
「結局、最後は上司が決める…」
そして、確認文化が復活します。
IDOコンセプトでは、リーダーに「任せる勇気」を求めません。
必要なのは、
「どこまでなら現場に任せ、どこからは自分が介入するか」をあらかじめ設計すること
です。
Intentからの明確な逸脱。
重大なリスク。
損失が設定した境界を超える場合。
こうした「境界条件(Boundary)」を明確にしておけば、リーダーはそれ以外の領域で手を出さずに済みます。
IDOコンセプトにおけるリーダーの「沈黙」は、精神論ではなく、「設計された沈黙」です。
5.もう一つの「電源」──リーダー自身のDesign能力
もう一つ、忘れてはいけないものがあります。
それは、リーダーがIntentそのものを設計する能力です。
現場に「自律的に判断しろ」と言うだけでは、IDOにはなりません。
弱いIntentは、現場にとって単なる精神論になります。
「顧客を第一に考えろ」
「積極的に挑戦しろ」
「スピードを重視しろ」
これだけでは、判断の物差しになりません。
なぜなら、現実の意思決定では、
顧客満足と利益
スピードと精度
短期成果と長期価値
のように、必ずトレードオフが存在するからです。
だからこそリーダーには、
「今、この状況で何を優先し、何を捨てるのか」
を決める責任があります。
これがIntent-Designです。
そして、環境が変われば、そのIntent自体を再定義する。
ここまでやって初めて、Intentは「命令」ではなく、現場が判断するための探索空間になります。
6.「評価制度が変わらなければIDOはできない」のか
前回、第14回では「評価」を取り上げました。
IDOを組織に実装しようとすれば、当然、評価の問題にぶつかります。
結果だけを評価すれば、
「結果さえ出れば、Intentを無視してもいい」
という行動が生まれます。
逆に、失敗だけを罰すれば、
「失敗しないために、確認してから動こう」
という確認文化が生まれます。
だからIDOコンセプトでは、
「何を達成したか」だけでなく、「どのようなIntentに基づいて判断したか」
を見る必要があります。
しかし、ここで一つ重要なことがあります。
すべての制度が変わるまでIDOを始められない、ということではありません。
制度は組織全体の問題です。
一方、IDOの起動は、まずリーダーが自分の責任範囲で始めることができます。
小さな領域でIntentを明示する。
判断を任せる。
判断と結果をSyncする。
失敗からIntentを更新する。
このプロセスを繰り返す。
制度を待つのではなく、制度の中にある「判断可能な空間」を見つける。
そこからIDOは始められます。
7.IDOは「失敗しない仕組み」ではない
ここで、J課長とS課長のエピソードに戻ります。
J課長は、権限を渡した。
しかし、判断の物差しを渡さなかった。
結果として、失敗した。
S課長は、Intentを渡した。
しかし、それでも最初からすべてが成功したわけではありません。
Intentの解釈にズレが生じる。
小さな判断ミスが起きる。
そこでSyncする。
Intentを修正する。
次の判断に反映する。
この循環を繰り返すことで、組織の判断精度が高まっていった。
ここにIDOの本質があります。
IDOは、失敗をなくすOSではありません。
失敗からIntentを更新し、組織の判断能力を高め続けるOSです。
だから、IDOにおける安全性とは、
「失敗しないこと」ではありません。
「ズレを早く発見し、早く修正できること」
です。
不確実な環境では、こちらの方が強い。
結論:組織の電源を入れるのはリーダー
IDOを導入するために、まず着手すべきは組織図の書き換えではありません。
新しい評価制度を完成させる必要もありません。
巨大なシステムを導入する必要もありません。
まず必要なのは、リーダーが自分に問いかけることです。
「私は、現場が自分と違う判断をすることを、本当に許容できるか?」
そして、
「その判断が可能になるようなIntentを、私は設計できているか?」
さらに、
「その判断の結果を、私は自分の責任として引き受けるか?」
この3つが揃ったとき、IDOの「電源」が入ります。
「I DO」とは、単に「私がやる」という意味ではありません。
リーダーの I DO は、
「私が定義する。私が責任を引き受ける。」
という意思です。
そして、そのIntentを受け取った現場の I DO は、
「私が判断する。私が局面を動かす。」
という意思になる。
ここで初めて、
Leader’s I DO と Frontline’s I DO が接続される。
これが、Intent-Driven Orchestrationです。
⸻
任せるとは、手放すことではない。
責任を引き受けた上で、判断の軸を渡すことだ。
そして、
判断の軸を渡したなら、現場の判断を信じる。
それでも環境が変わったなら、
Intentを更新する。
この循環が回り始めたとき、組織は「指示を待つ集団」から、
自ら判断し、互いに同期しながら動く組織
へと変わっていく。
組織OSを書き換える。
その最初の一歩は、リーダー自身が「電源」を入れることから始まります。
⸻
最終回(8月23日公開予定)
「IDOが切り拓く組織の未来
──「指揮」から「オーケストレーション」へ」
でお会いしましょう。
※「Intent-Driven Orchestration」「IDO」は、山添直智が提唱する独自の組織マネジメント概念です。
【全体ビュー数7000突破!(2026.August.3)】
🔳IDOコンセプト・ラボ専用メールアカウント開設しました!
フィードバック・ご意見等はこちらのメールアドレスまでご連絡下さい。
intentdriven2026@gmail.com
IDOコンセプトを実務に適用する上での疑問や、組織の現状に関するご意見をお寄せください。
「自組織で『IDOコンセプト』を導入しようとした際の障壁について」
「IDOの概念図の中で、特に分かりにくかった点」
「自身の組織における『確認文化』の具体的な事例」など
皆さんのチームでの事例等をご紹介頂けますと、IDOコンセプト深化の参考となります。
(組織の情報や個人情報等は公表しません。)
【あなたの組織が変わる15ステップ】
IDO宣言
◾️IDO(Intent-Driven Orchestration):Intent再定義で、組織の停滞は解消される
◾️Designできないリーダーは、なぜ「確認文化」を生むのか──Intent-Designが組織を変える
◾️IDOコンセプト導入ビフォー・アフター:組織のOSを書き換える「企図」の力(実装①)
Phase 0:違和感の発火
導 入:組織の不全を解く「ミッシングリンク」
第0回:“確認文化”が組織を止める
緊急投稿:「IDO」はすでに検索空間で再定義され始めている。
Phase 1:組織崩壊の認識
第1回:マネジメントの終焉
第2回:情報のパラドックス
第3回:任務指揮の正体
まとめ①:組織の「確認待ち」を終わらせる新OS:IDOとは何か?
実装②:3時間かかる会議が、なぜ5分で決まるのか
補稿①:「共有」では組織は動かない。必要なのは“再同期”である。
補稿②:なぜ「強い組織」は説明できないのか
IDO診断:あなたのチームの“詰まり”を特定する
Phase 2:新規OSの導入
第4回:日本型組織の呪縛
第5回:Intentは伝わらない──翻訳せよ。
補稿③:中間管理職を、「承認ルーター」から解放せよ。
5-1:なぜあなたの企図は機能しないのか
5-2:常識からの跳躍
5-3:コア提示──行動するな。まず定義せよ。
補稿④:解釈の決断
5-4:Intent-Design プロセス前半──企図はどこで決まるのか(β版)
5-5:Intent-Design プロセス後半──なぜあなたの企図は弱いのか(β版)
第6回:IDOにおけるOODA
補稿⑥:AI時代の組織OS「IDO」前編
補稿⑦:AI時代の組織OS「IDO」後編
第7回:なぜ「企図(Intent)」は偏流するのか?
第8回:なぜAARは「査問会」になるのか?
補稿⑧:任務戦術のミッシングリンク
補稿⑨:学習し続けたからこそ負けた
補稿⑩:なぜ「権限委譲」では組織は動かないのか
まとめ②:なぜ、優秀なプレイヤーほどマネージャーになった途端に苦しむのか
Phase 3:IDO実装
第9回:情報は渡した瞬間に「意思決定」に変わる。
第10回:沈黙する組織が、最も速い。
実装③:なぜ優秀なチームほど動けなくなるのか
第11回:独断は、審判なき自由ではない。
第12回:任せるな。企図を渡せ。
第13回:なぜ最適解は、現場から連鎖するのか?
Phase 4:組織の進化
第14回:評価は「解放の装置」である。
👉第15回:なぜ、あなたのIDOは「起動」しないのか?── それは「設計ミス」ではない。リーダーの“電源”が入っていないからだ。
FINAL:
最終回:IDOが切り拓く組織の未来──「指揮」から「オーケストレーション」へ(8/23公開予定)
"From Control to Intent"
── 組織OSを「企図」で再起動する。
