フレームワーク活用ガイドひとことで言うと#
対話を**Objective（事実）→ Reflective（感情）→ Interpretive（解釈）→ Decisional（意思決定）**の4段階に分けて進めることで、表面的なやり取りを超え、全員が納得できる結論にたどり着くファシリテーション手法。ICA（Institute of Cultural Affairs）が開発した。
押さえておきたい用語#
- Objective（客観的段階）
- 参加者が見た事実・データを共有するステップ。意見や感想ではなく「何が起きたか」だけを扱う。
- Reflective（内省的段階）
- 事実に対してどう感じたかを共有するステップ。驚き、不安、期待など感情面を言語化する。
- Interpretive（解釈的段階）
- 事実と感情を踏まえ、何を意味するかを分析するステップ。パターンや因果関係を探る。
- Decisional（意思決定段階）
- 解釈をもとに次に何をするかを決めるステップ。アクションプランやコミットメントに落とし込む。
ORIDメソッドの全体像#
こんな悩みに効く#
- 会議で意見がまとまらず、毎回「なんとなく」で終わってしまう
- 振り返りが表面的で、本質的な改善につながらない
- 声の大きい人の意見に引っ張られ、全員の認識がそろわない
- 感情的な議論と論理的な議論が混ざり、話が堂々巡りする
基本の使い方#
テーマに関する客観的な事実を全員から集める。意見や判断は一切はさまない。
- 「何が起きましたか？」「何を見ましたか？」「数字はどうでしたか？」と問う
- ホワイトボードや付箋に書き出して全員で共有する
- 事実の認識がバラバラだと後工程がすべてズレるので、ここに十分な時間を割く
集めた事実に対してどう感じたかを一人ひとりが共有する。
- 「驚いたことは？」「嬉しかったことは？」「不安に感じたことは？」と問う
- 正解・不正解はなく、すべての感情を受け止めることが前提
- 感情を言語化することで、解釈段階での議論が深まる
事実と感情を踏まえて、それが何を意味するのかを分析する。
- 「なぜそうなったと思いますか？」「共通するパターンは？」と問う
- 複数の解釈を出し合い、チームとしての理解を深める
- ここで安易に結論を急がず、十分に意味を掘り下げることが重要
解釈をもとに、具体的なアクションを決定する。
- 「明日から何をしますか？」「誰が・いつまでに・何を？」と問う
- アクションは測定可能で期限付きにする
- 決めたことを全員で確認し、コミットメントを取る
具体例#
受託開発チーム8名が担当するシステム移行プロジェクトが、当初の納期を3週間オーバーした。マネージャーが「犯人捜し」にならないよう、ORIDで振り返りを実施した。
O（事実）: 要件定義フェーズが予定の2倍かかった。中間レビューが3回追加された。クライアントの担当者が途中で交代した。テスト工数は計画の130%。
R（感情）: 「要件が確定しないまま開発に入った焦り」「担当者交代で信頼関係がリセットされた無力感」「残業が続いた疲弊」が共有された。一方で「最終的に品質を妥協しなかった誇り」もあった。
I（解釈）: 要件の不確定さを吸収するバッファがゼロだった。クライアント側のステークホルダー管理を自社が支援する仕組みがなかった。中間レビューの追加自体は品質を守ったが、スケジュールへの影響をリアルタイムで可視化できていなかった。
D（意思決定）: 次のプロジェクトから要件定義フェーズに20%バッファを標準化する。クライアントの担当者変更時の引き継ぎチェックリストを作成する。週次で「残スケジュール vs 残タスク」のバーンダウンチャートを共有する。
3か月後の次プロジェクトでは、同規模の案件を予定通りに納品できた。
SaaSスタートアップが50社にベータ版を提供し、4週間のテストを終えた。NPS（推奨度）は**+12で、「悪くはないが期待ほどではない」という微妙な結果だった。経営陣4名とプロダクトチーム6名**でORIDセッションを開いた。
O（事実）: DAU（日次利用者数）は初週78%→4週目42%に低下。サポート問い合わせは週平均23件。最も使われた機能はダッシュボード（利用率91%）。CSV出力機能はわずか8%。解約理由の上位は「既存ツールとの連携がない」。
R（感情）: エンジニアは「ダッシュボードの評価が高くて嬉しい」。CSチームは「問い合わせ量が想定の2倍で疲弊した」。CEOは「DAUの低下が予想以上で焦っている」。
I（解釈）: 初期価値は伝わっているが、継続利用を支えるワークフロー統合が弱い。CSV出力は「あると便利」で作ったが、実際にはAPI連携のほうが求められている。サポート問い合わせの**60%**がオンボーディング関連で、初期設定のUXに問題がある。
D（意思決定）: API連携を次スプリントの最優先にする。オンボーディングウィザードを再設計し、セットアップ完了率を**70%→90%**に引き上げる。CSV出力機能の開発リソースをAPI連携に振り替える。
ORIDを使ったことで、「NPSが低い＝プロダクトがダメ」という短絡的な結論を避け、具体的に何を変えるかまで2時間で合意できた。
従業員200名の製造業で、営業部門とマーケティング部門を統合して3か月が経過した。社内アンケートで「統合に不満」が47%を占め、離職者が3名出た。人事部長がORIDで部門横断ワークショップを実施した。
O（事実）: 統合後、週次定例会議が2つ→5つに増えた。報告フォーマットが旧営業と旧マーケで2系統が併存。KPIが「売上額」と「リード獲得数」で別々に設定されており、相互に矛盾するケースが月4〜5件発生。
R（感情）: 旧営業メンバーは「マーケの指標に振り回されている」と感じ、旧マーケメンバーは「営業の短期視点で施策を潰されている」と感じていた。両方に「前のほうがよかった」というノスタルジーがあった。
I（解釈）: 統合の「箱」は作ったが、業務プロセスとKPIの統合が追いついていない。会議が増えたのは「何を誰に報告すればいいかわからない」ことの症状であり、根本は意思決定ルールが未整備だったこと。
D（意思決定）: 統一KPIを「パイプライン貢献額」に一本化する。週次会議を5つ→2つに統合し、残り3つはSlackの非同期報告に切り替える。意思決定権限マトリクスを2週間以内に策定・公開する。
1か月後のフォローアップ調査で「統合に不満」は47%→22%に低下。会議時間は週あたり6.5時間→3時間に半減した。
やりがちな失敗パターン#
- 事実の段階を飛ばしていきなり意見を求める — 参加者がそれぞれ違う事実を前提に話すので、議論が噛み合わない。最初に全員の認識をそろえることが大前提
- 感情の段階を省略する — 「仕事に感情は不要」と思って飛ばすと、不満や不安が解消されないままアクションを決めることになり、実行段階で抵抗が生まれる
- 解釈の段階で一人の分析に引っ張られる — 上司やベテランの解釈が唯一の正解になりがちだが、複数の視点を出し合ってこそ新しい洞察が得られる
- 意思決定で抽象的なまま終わる — 「もっとコミュニケーションを取ろう」のような曖昧な結論では行動に移せない。「誰が・いつまでに・何を」まで具体化する
まとめ#
ORIDメソッドは、対話を事実→感情→解釈→意思決定の4段階に構造化することで、表面的な議論を本質的な合意形成へと導く。最大のポイントは段階を飛ばさないこと。事実を共有してから感情を扱い、意味を読み解いてから行動を決める。この順番を守るだけで、会議の質は格段に上がる。