MaemaemaeMaemaemae

OODA ループ — 基本・具体的活用例・使いこなすためのツールとフォーマット

OODA ループは軍事戦略から生まれた意思決定フレームワークで、変化が速く不確実な状況ほど威力を発揮する。この記事では基本概念・具体的な活用例・チームで回すためのツールとフォーマットをまとめて解説する。

OODA ループとは

ジョン・ボイド（John Boyd） が提唱した意思決定フレームワーク。元々は戦闘機パイロットの判断プロセスを分析したもので、現在はビジネス・経営戦略・アジャイル開発に広く使われている。

Observe（観察）→ Orient（状況判断）→ Decide（決定）→ Act（行動）
       ↑___________________________________|
                   フィードバックループ
フェーズ内容
Observe（観察）現実の状況・データ・情報を収集する
Orient（状況判断）収集した情報を解釈・分析し、自分の文脈で意味づけする
Decide（決定）取るべき行動を選択する
Act（行動）決定を実行に移す

行動後は再び観察フェーズに戻り、ループを繰り返す。

核心は「Orient（状況判断）」

4 つの中で最も重要なのが Orient フェーズ。以下の要素が判断に影響する。

  • 過去の経験・メンタルモデル
  • 文化的背景・価値観
  • 新たに得た情報の解釈
  • 分析・総合の思考プロセス

同じ情報を見ても、Orient の質によって判断が変わる。OODA の強さは「速さ」だが、速さを生むのは Orient の精度だ。

PDCA との違い

OODAPDCA
前提不確実・変化が速い状況計画が立てやすい安定した状況
起点観察（現実から始める）計画（目標から始める）
スピード素早いループが強み計画→振り返りのサイクルが長め
向いている場面競合・市場・危機対応品質改善・製造プロセス

具体的な活用例

1. 障害対応（インシデント）

状況: 本番環境でエラーが急増

フェーズ具体的な行動
ObserveDatadog でエラーレート急上昇・直前のデプロイ履歴を確認
Orient「新しいデプロイが原因」と判断。ロールバックで解消できると見立てる
Decide即時ロールバックを選択
Actロールバック実行 → 再度 Observe でエラーが収まったか確認

ループが速いほど MTTR（平均復旧時間） が短くなる。

2. スタートアップのピボット判断

状況: 新機能をリリースしたが反応が薄い

フェーズ具体的な行動
ObserveDAU が下がった・特定機能の離脱率が高い・ユーザーインタビューで不満の声
Orient「UI の問題ではなく、そもそもニーズがなかった」と解釈
Decide機能を削除して別のアプローチに切り替える
Act2週間でプロトタイプを作り直してリリース

3. 営業・商談

状況: 提案中に顧客の反応が鈍い

フェーズ具体的な行動
Observe顧客が資料を見ずに別の話題を振ってきた
Orient「価格ではなく導入コストへの懸念がある」と読む
Decide導入事例と ROI の話に切り替える
Act「他社での導入実績をお話しすると…」と切り出す

商談中に 何度もループを回す のが熟練営業の動き。

4. スクラムのスプリント運営

OODAスクラムでの対応
Observeスプリントレビュー・バーンダウンチャート・デイリースクラム
Orient「このペースではスプリントゴールに届かない」と判断
Decideタスクの優先順位を変更・スコープを削る
Actバックログを更新・翌日から動く

スクラムは OODA を スプリント単位 で制度化したフレームワークとも言える。

使いこなすためのツールとフォーマット

Observe を効率化するツール

目的ツール
メトリクス監視Datadog / Grafana / CloudWatch
ユーザー行動分析Mixpanel / Amplitude / GA4
顧客フィードバックIntercom / Slack の専用チャンネル
競合・市場情報Google Alerts / RSS リーダー
チーム内の状況GitHub Issues / Jira のバックログ

ポイント: 情報が自動で集まる仕組みを作る。毎回手動で集めていると Orient に移れない。

Orient のフォーマット（状況判断シート）

## 観察した事実
- （数値・具体的な出来事のみ。解釈を混ぜない）

## 解釈・仮説
- 事実が示す意味は何か？
- 過去の経験と照らして何が起きているか？

## 前提・バイアスの確認
- 自分が思い込んでいることはないか？
- 見落としている視点はないか？

「事実」と「解釈」を分けて書くのが重要。混在すると判断が歪む。

Decide のフォーマット（意思決定ログ）

## 決定内容
## 選択肢（検討した他の案）
## 決定の根拠
## 想定されるリスク
## 判断を見直すトリガー（いつ再評価するか）

「判断を見直すトリガー」を決めておくのがポイント。これがないと次の Observe に戻れない。

Act を小さく速くする — 優先度マトリクス

         影響大
           |
  後回し   |   すぐやる
-----------|----------→ 速度（実行しやすさ）
  やらない |   試してみる
           |
         影響小

「影響大 × 実行しやすい」から着手し、結果を観察してループを回す。

OODA ジャーナル（日次・週次の記録フォーマット）

個人・チームどちらでも使える。Notion・Obsidian・手帳で運用できる。

## 日付: YYYY-MM-DD

### Observe
- 今日気づいたこと・気になった数値・受け取った情報

### Orient
- それをどう解釈したか
- 修正した仮説・世界観

### Decide
- 次に取る行動の選択と理由

### Act
- 実際にやったこと

### 次のループへ
- 次の Observe で何を確認するか

チームで OODA を回すツール構成

フェーズおすすめツール使い方
ObserveSlack 専用チャンネル気になる情報を即投稿・流しっぱなしにしない
OrientMiro / FigJamホワイトボードで情報の意味を整理
DecideLinear / Jira決定をチケットに即落とす
ActGitHub / Notion実行・進捗を可視化

ハマりやすいポイント

1. Observe と Orient を混同する

「売上が下がった（事実）」と「施策が失敗した（解釈）」を同じ場所に書いてしまうと、Orient が雑になる。事実と解釈は必ず分けて記録する。

2. Decide を大きくしすぎる

「方針を全部変える」のような大きな決定は実行が遅くなり、観察のフィードバックも遅れる。「まず1つ試す」に分解すると OODA が速く回る。

3. Act の結果を観察しない

行動して終わりにすると PDCA と変わらない。Act の後に「何を Observe するか」を事前に決めておくことで、意図的なループになる。

4. Orient に時間をかけすぎる

Orient は重要だが、完璧な解釈を求めて動けなくなるのは逆効果。「仮説として動いて、次の観察で修正する」という姿勢がループを速くする。

まとめ

ループを速くするための原則方法
Observe は自動化ダッシュボード・アラートに任せる
Orient は記録する判断の根拠を残すと次回が速くなる
Decide は小さく「試して観察」を優先
Act は期限を決める「いつまでにやって、何を見るか」をセットで

OODA は「正しい答えを出すフレームワーク」ではなく、間違いを素早く修正し続けるフレームワークだ。ループを速く回すほど、不確実な状況での生存率が上がる。

タグ

生産性向上HCD