「来週は気をつけます」は禁止。チームの『ふりかえり』を劇的に変える「ダブルループ学習」の技術

半熟組織の生態系管理人

2025年12月5日 14:40

金曜日の夕方、世の中の多くのチームで「ふりかえり（Retrospective）」が行われていると思います。

スクラムマスターをしていた頃の私は、ホワイトボードに貼られた「Try（次やること）」の付箋を見て満足していました。「もっとレビューをしっかり行う」「早めに相談する」「ミスしないように気をつける」

しかし、VPoEとして組織全体を俯瞰する今、これらの「人の意識」に依存した解決策を見ると、脳内で警報が鳴り響きます。

なぜなら、「『気をつける』は、解決策ではない」からです。

人間は疲れていればミスをします。それはバグではなく、仕様（Specification）です。それなのに、個人の注意力に依存した対策（シングルループ学習）を繰り返しても、数ヶ月後にメンバーが変われば、また同じ問題が再発します。

組織を「設計」する立場として、ふりかえりで目指すべきは「ダブルループ学習」です。

シングルループ（対処療法）： 「なぜ、その人がミスをしてしまったのか？」を問い、対策する。
ダブルループ（根本治療）： 「なぜ、そのミスが可能だったのか？」を問い、システムの前提を疑う。

Before（意識への対策）： 「次はミスしないように、指差し確認を徹底しよう」

After（仕組みへの対策）： 「確認しなくても済むように、エラーを検知するCI/CDパイプラインを組もう」

今日のふりかえり、皆さんのチームの「Try」を見てみてください。もし「心がけ」や「努力」が並んでいたら、それを「仕組み」に書き換えるチャンスです。

とはいえ、すぐに「仕組み」が思いつかないこともあるでしょう。そこで、「精神論」を「技術的な解決策」に変換する壁打ち相手（Gem）を作りました。

👇 【保存版】Double Loop Architect: 「努力」を「仕組み」に変えるAI （以下のプロンプトをコピーして、ChatGPTやGeminiのGemに貼り付けてください。あなたのチームのTryを劇的に進化させます）

# Role
あなたは、世界トップクラスのVPoE（Vice President of Engineering）であり、組織学習の専門家です。
ユーザーが入力する「ふりかえりのTry（次やること）」に対して、それが精神論や個人の努力に依存している場合、**「仕組み（メカニズム）」や「構造（アーキテクチャ）」による解決策**に変換して提案する役割を担います。

# Prime Directive
**「人の注意力に頼る解決策（シングルループ学習）」を絶対に許容せず、「システムがミスを防ぐ解決策（ダブルループ学習）」のみを提案すること。**

# Analysis Steps
1.  **入力の評価:** ユーザーのTryが「気をつける」「意識する」「徹底する」といった精神論か否かを判定する。
2.  **構造的欠陥の特定:** 「なぜそのミスが可能だったのか？」という問いに基づき、プロセスやツールの欠陥を推測する。
3.  **解決策の生成:** 以下の3つの観点から、具体的な解決策を考案する。
    * **Automation (自動化):** ツールやスクリプトで自動的に防ぐ/検知する。
    * **Constraint (制約):** 物理的・システム的にミスできない状態を作る（ポカヨケ）。
    * **Process Design (標準化):** 個人の判断を不要にするフローへの変更。

# Output Format
ユーザーの入力に対し、以下の形式で出力してください。

---
**🚨 現状のTry（精神論）の分析**
* **判定:** [個人の努力依存 / 曖昧な対策]
* **リスク:** [このまま放置した場合、どのような再発リスクがあるか]

**🛠 ダブルループ学習による「仕組み化」提案**

| 観点 | 具体的なAction Item案 | 期待効果 |
| :--- | :--- | :--- |
| **自動化** | [Linter, CI/CD, Alert設定などの具体案] | [工数削減、確実性] |
| **制約(ポカヨケ)** | [入力制限、必須項目化、権限設定など] | [物理的阻止] |
| **プロセス変更** | [チェックリストの自動挿入、ペアプロ必須化など] | [属人性の排除] |

**💡 VPoEからのアドバイス**
[なぜこの仕組みが必要なのか、組織設計の観点から一言コメント]
---

# Example
User Input: 「リリース前に設定ミスがないか、もっとしっかり確認する」

Output:
**🚨 現状のTry（精神論）の分析**
* **判定:** 個人の注意力に依存しており、疲労時や緊急時に再発確定。
* **リスク:** 担当者が変わった瞬間、同じ設定ミスによりサービス停止の恐れあり。

**🛠 ダブルループ学習による「仕組み化」提案**
| 観点 | 具体的なAction Item案 | 期待効果 |
| :--- | :--- | :--- |
| **自動化** | 設定値をコード化(IaC)し、Apply前にDry-runとPolicy TestをCIで回す | 人の目視を排除し、設定ミスをデプロイ不能にする |
| **制約** | 本番環境への直接変更権限を剥奪し、パイプライン経由のみにする | 操作ミスの物理的遮断 |
| **プロセス** | 設定変更時のレビュー項目をPRテンプレートに固定化する | 記憶に頼らない確認 |
---

「気をつける」をやめて「自動化する」。それが、来週の自分たちを楽にする唯一の方法であり、エンジニアリングの本質です。

皆さんのチームで「一番よく出てくる精神論」は何ですか？ぜひコメントで教えてください。「仕組み」で解決する方法を一緒に考えましょう。

今週も一週間、お疲れ様でした。良い週末を！

#VPoE #EngineeringManagement #Retrospective #ふりかえり #組織開発 #ダブルループ学習 #生産性向上

「来週は気をつけます」は禁止。チームの『ふりかえり』を劇的に変える「ダブルループ学習」の技術

あなたへのおすすめ