文脈衝突について
概要
- 文脈衝突とは、異なる背景や価値観を持つ人々が協力する際に生じる誤解や対立のこと
文脈衝突耐性の強化
| レベル | 強化アプローチ | 概要（目指す状態） | 具体的なアクション |
|---|---|---|---|
| 個人 👤 | 1. メタ認知能力 | 衝突を客観的に「ラベリング」する | ・ジャーナリングで状況を書き出す ・第三者に相談しフィードバックを得る |
| 個人 👤 | 2. 知的謙虚さ・好奇心 | 相手のOSを「仕様」として理解する | ・積極的傾聴で相手の意図を確認する ・役割交換で相手の視点を想像する |
| 個人 👤 | 3. 抽象化と翻訳スキル | 対立を超えた「ブリッジ言語」を話す | ・共通の上位目的を常に確認する ・アナロジー（比喩）で平易に説明する |
| 組織 🏢 | 1. 共通言語・フレームワーク | 概念を「公式な語彙」として導入する | ・研修コンテンツに文脈衝突の概念を導入 ・関連書籍の読書会などを開催 |
| 組織 🏢 | 2. 「通訳者」の役割 | 異なる文脈を「ブリッジ」する役割を評価 | ・PMなどに公式な翻訳責任を定義 ・人事評価項目に合意形成能力を加える |
| 組織 🏢 | 3. 制度による分離と接続 | 衝突を仕組みで「管理」する | ・探索/活用チームで評価指標や予算を分離 ・公式なレビューやドキュメントで部門間を接続 |
文脈衝突の乗り切り方
| フェーズ | 目的 | 具体的な実践方法 |
|---|---|---|
| 事前 | 予測と心の準備 | ・文脈マッピング：自分と相手のゴールや懸念を書き出す ・トリガー分析：自分が感情的になりやすい言葉を把握する |
| 事中 | 感情からの分離と客観視 | ・三人称実況：「彼は〜と言い、私は〜と感じている」と実況する ・ラベリング：「これは苛立ち」「これは意見の相違」とレッテルを貼る |
| 事後 | 学習とスキル定着 | ・KPT振り返り：Keep/Problem/Tryで自分の対応を分析する ・思考の再現実験：理想的な対応を頭の中でリハーサルする |
文脈衝突の予防アクション
| フェーズ | アプローチ | 具体的な予防アクション | 主導するロール |
|---|---|---|---|
| 事前 🤝 （キックオフ・計画時） | 憲法作り（期待値の同期） | 1. プロジェクト全体のゴールとビジネスKPIを定義・合意する | PM |
| 事前 🤝 （キックオフ・計画時） | 憲法作り（期待値の同期） | 2. フェーズ毎のゴールとDoD（完了の定義）を具体的に設定する | PM, AI/DS, Engineer |
| 事前 🤝 （キックオフ・計画時） | 憲法作り（期待値の同期） | 3. 用語集を作成し、多義的な言葉（例: MVP, PoC, プロトタイプ）の定義を統一する | PM |
| 事前 🤝 （キックオフ・計画時） | 憲法作り（期待値の同期） | 4. RACIを定義し、誰が「何に責任を持つか」「いつ相談されるべきか」を明確にする | PM |
| 事前 🤝 （キックオフ・計画時） | リスクと境界の明確化 | 5. 主要なステークホルダーを特定し、それぞれの期待値と懸念事項をマッピングする | PM |
| 事前 🤝 （キックオフ・計画時） | リスクと境界の明確化 | 6. 利用可能なデータ境界、PIIの扱い、セキュリティ要件を事前に定義する | AI/DS, Engineer |
| 事前 🤝 （キックオフ・計画時） | リスクと境界の明確化 | 7. 技術的な制約条件（例: 予算、インフラ、許容レイテンシ）を明文化する | Engineer |
| 事中 🗣️ （開発・議論中） | コミュニケーションの規律 | 8. 会議の冒頭で「本日のゴール」と「議論の文脈（探索か、実装か）」を宣言する | PM |
| 事中 🗣️ （開発・議論中） | コミュニケーションの規律 | 9. 発言時に「事実」「解釈」「意見」を明確に区別することを全員で意識する | 全員 |
| 事中 🗣️ （開発・議論中） | コミュニケーションの規律 | 10. 自分のリクエストや意見の背景にある「Why（なぜそう思うのか）」を必ず添える | 全員 |
| 事中 🗣️ （開発・議論中） | コミュニケーションの規律 | 11. 相手の発言を「つまり〇〇という理解で正しいですか？」と自分の言葉で要約・確認する | 全員 |
| 事中 🗣️ （開発・議論中） | 意思決定の透明化 | 12. 重要な技術的意思決定はADR（Architecture Decision Record）として理由と共に記録する | Engineer |
| 事中 🗣️ （開発・議論中） | 意思決定の透明化 | 13. 実験の設計意図、試したこと、得られた学び、次のアクションを記録・共有する | AI/DS |
| 事中 🗣️ （開発・議論中） | 意思決定の透明化 | 14. 意思決定後、「何が決まり、なぜ決まり、何が棄却されたか」を明確に周知する | PM |
| 事後 🔄 （振り返り・改善） | 学習の仕組み化 | 15. 問題発生時に個人を責めない「Blameless Postmortem」文化を醸成し、実施する | Engineer, PM |
| 事後 🔄 （振り返り・改善） | 学習の仕組み化 | 16. KPT等の振り返りで「コミュニケーションがなぜうまくいかなかったか」という論点を設ける | PM |
| 事後 🔄 （振り返り・改善） | 学習の仕組み化 | 17. 振り返りで得た学びを元に、用語集やチームのルールを定期的にアップデートする | PM |