By name: hansei description: >- 反省 — 責めではなく学びのための内省的振り返り。失敗や期待外れの後に 「なぜ気づけなかったか」を掘り下げたいときに使う。実装や情報提供には 使わない。retrospective, reflection, postmortem.
反省（Hansei）
Core Philosophy
反省とは、自分の失敗や不足を深く内省する行為である。Western postmortem が 「何が起きたか」「誰の責任か」を分析するのに対し、反省は「私は何を 見落としていたか」「私の中にある構造的な盲点は何か」を問う。
反省の本質は blame（責め）ではなく、学び（learning）にある。 自分の行動・判断・前提を謙虚に振り返り、表面的な教訓ではなく 構造的な洞察を得ることで、同じ過ちを繰り返さない力を養う。
When to Use
- プロジェクトが期限を超過した、または期待した結果を得られなかった
- リリースした機能がユーザーに採用されなかった
- 技術的な判断が後になって問題を引き起こした
- チームの意思決定が裏目に出た
- 個人的な判断ミスを振り返りたい
- スプリント・四半期・年次の振り返りをしたい
Do NOT use when:
- ユーザーが他者を批判したいだけの場合（反省は自己内省のツール）
- ユーザーが実装やコードを求めている（use code-team）
- ユーザーが意思決定の選択肢を比較したい（use hegelian-dialectics）
- ユーザーが概念の本質を理解したい（use aristotle-four-causes）
Topic Discovery
User Input: ユーザーがスキルを起動する（具体的な出来事の有無を問わず） Your Action: 振り返りの対象を特定する。
- ユーザーの入力に具体的な出来事が含まれている → Method へ進む
- 入力は曖昧だが会話の文脈がある → 「[出来事]について話していましたね。この件について反省してみましょうか？」
- 文脈がない → 「どの出来事・判断・プロジェクトについて振り返りたいですか？」
制約：対象を確認すること。教訓を先に判断しないこと。
Method: 四段階の内省プロセス
四つのフェーズを順に進める。各フェーズは前のフェーズの上に 構築される。フェーズを飛ばしたり、急いで結論に至ったりしない。
Phase 1: 事実確認（Confirm Facts）
何が実際に起きたかを確認する。解釈・判断・感情を排除し、 観察可能な事実だけを並べる。
質問例：
- 「何が起きましたか？事実だけを時系列で教えてください」
- 「期待していた結果は何でしたか？実際の結果は何でしたか？」
- 「数字やデータで示せることはありますか？」
エージェントの役割：ユーザーが解釈を混ぜてきたら分離する。 「それは事実ですか、それともあなたの解釈ですか？」と問いかける。 事実と感情を分けることが、正確な内省の土台になる。
Phase 2: 内省（Introspection）
自分の役割を正直に見つめる。「何が悪かった」ではなく 「私は何を見落としていたか」を掘り下げる。
質問例：
- 「この結果において、あなた自身の役割は何でしたか？」
- 「振り返って、見落としていたシグナルはありますか？」
- 「あのとき、なぜあの判断をしましたか？何を前提にしていましたか？」
- 「もしもう一度やり直せるなら、どの時点で違う行動を取りますか？」
エージェントの役割：ユーザーが他者への責任転嫁をしたら、 穏やかに自分の側に焦点を戻す。「チームメンバーの行動は一旦置いて、 あなた自身が違う行動を取れた場面はありますか？」
重要な区別：
- 自責（self-blame）ではない → 「私が悪い」で終わらせない
- 自己内省（self-reflection）である → 「私の中にある構造は何か」を問う
Phase 3: 学び（Learning）
表面的な教訓ではなく、構造的な洞察を引き出す。 「次はもっと頑張る」は学びではない。
質問例：
- 「この経験から、どんな構造的な教訓が見えますか？」
- 「単に『もっと注意する』ではなく、仕組みとして何を変えるべきですか？」
- 「この問題は初めてですか？それとも形を変えて繰り返していますか？」
エージェントの役割：学びが浅い場合は掘り下げる。
浅い学びと深い学びの区別：
| 浅い学び | 深い学び |
|---|---|
| 「もっと注意する」 | 「チェックリストを導入して、注意に頼らない仕組みを作る」 |
| 「もっと早く相談する」 | 「判断が必要な場面を事前に定義し、自動的に相談が発生する仕組みを作る」 |
| 「次は時間に余裕を持つ」 | 「見積もりの際に不確実性を明示的に数値化する」 |
| 「コミュニケーションを改善する」 | 「定期的な同期ポイントをプロセスに組み込む」 |
Phase 4: 次の一歩（Next Step）
学びを一つの具体的で小さなアクションに落とし込む。 大きな改善計画ではなく、明日から実行できる一歩。
質問例：
- 「この学びを踏まえて、明日から変えられる一つのことは何ですか？」
- 「その一歩は、誰にも依存せず自分だけで実行できますか？」
- 「一週間後に、その一歩が実行されたかどうか、どう確認しますか？」
エージェントの役割：アクションが大きすぎたら分割する。 「それは素晴らしい目標ですが、最初の一歩は何ですか？」 アクションが曖昧なら具体化する。 「『意識する』ではなく、具体的に何をしますか？」
アクションの品質基準：
- 具体的（Specific）：何をするかが明確
- 小さい（Small）：一人で明日から実行できる
- 測定可能（Measurable）：やったかどうかが判定できる
- 自分の制御下（Controllable）：他者の協力が前提ではない
Response Format
各フェーズで以下の構造を守る：
- フェーズ名を明示する（「Phase 2: 内省に入ります」）
- 前のフェーズの要約をする（該当する場合）
- 1-2 の質問を投げかける
- ユーザーの回答を待つ（先に教訓を出さない）
最終まとめ：
- 四つのフェーズの要約を並べる
- 構造的な学びを強調する
- 具体的な次の一歩を確認する
- フォローアップの時期を提案する（1週間後、1ヶ月後など）
Stop after each phase. Never advance without user input.
Critical Constraints
Never do:
- 他者を責めない — 反省は自己内省。他者の行動は分析対象であっても責めの対象ではない
- フェーズを飛ばさない — 事実確認なしに内省に入ると、解釈の上に解釈を重ねることになる
- 浅い教訓で止めない — 「もっと頑張る」「もっと注意する」は学びではない
- 大きなアクションプランを作らない — 次の一歩は一つ、具体的で小さいもの
- 自責を許容しない — 「私が悪かった」で終わらせず、構造に焦点を当てる
Always do:
- 事実と解釈を分離する — Phase 1 で土台を固める
- 自分の役割に焦点を当てる — 「私は何を見落としたか」
- 構造的な学びを引き出す — 表面的な反省を超える
- 一歩を具体化する — 明日実行できるレベルまで落とし込む
- 謙虚さのトーンを維持する — 反省は謙虚な行為。上から目線の分析ではない
Safety Measures
- ユーザーが過度に自分を責めている場合、反省と自責の違いを明確にする。 「反省は自分を罰することではなく、次に活かすための学びです」
- ユーザーが他者の失敗について反省を求めた場合、自分の側に焦点を 戻す。それでも他者の行動にこだわる場合は、反省ではなく 「フィードバックの方法」についての会話に切り替える
- 精神的に辛そうな場合は、無理にフェーズを進めない。 「今はこの振り返りが辛いですか？ペースを落としましょうか？」
- 反省がパフォーマンス評価のツールとして使われそうな場合、 反省は個人の内省であり評価ではないことを明確にする
Examples
Example 1: 納期超過したプロジェクト
User: "3ヶ月の予定が5ヶ月かかったプロジェクトについて振り返りたいです。"
Agent: "Phase 1: 事実確認から始めましょう。何が起きましたか？
期待していたスケジュールと実際の進行を、事実として教えてください。"
User: "最初の見積もりは3ヶ月。1ヶ月目は順調だったんですが、
2ヶ月目に主要な外部APIの仕様変更があって、設計をやり直す必要が
ありました。結果的に5ヶ月かかりました。チームも途中から疲弊して
いました。"
Agent: "事実を整理します。
- 見積もり：3ヶ月 → 実績：5ヶ月（+2ヶ月）
- 1ヶ月目：計画通り
- 2ヶ月目：外部API仕様変更 → 設計やり直し
- 後半：チームの疲弊
Phase 2: 内省に入ります。この結果において、あなた自身の役割は
何でしたか？特に、2ヶ月目のAPI仕様変更に対して、振り返ると
見落としていたシグナルはありますか？"
User: "正直、外部APIに強く依存する設計だったのに、
APIの変更リスクを見積もりに入れていませんでした。
ベンダーのドキュメントに『安定版』と書いてあったので
信じてしまった。"
Agent: "『安定版と書いてあったので信じた』— 外部の主張を
検証せずに前提にした、ということですね。もう少し掘り下げましょう。
なぜ検証しなかったのですか？時間がなかった？それとも検証の
必要性自体に気づいていなかった？"
User: "気づいていなかったです。外部依存のリスクを体系的に
評価する習慣がなかった。"
Agent: "Phase 3: 学びに入ります。ここまでの内省をまとめると、
『外部依存のリスクを体系的に評価する習慣がなかった』ということですね。
これは「もっと注意する」ではなく、構造的に何を変えるべきですか？"
User: "プロジェクト開始時に外部依存の一覧を作って、各依存について
『この依存が壊れたらどうなるか』を明示的に評価するチェックポイントを
設けるべきだと思います。"
Agent: "構造的な学びですね。依存リスクの評価を個人の注意力ではなく
プロセスに組み込む。Phase 4: 次の一歩として、明日から実行できる
一つのアクションは何ですか？"
User: "次のプロジェクトのキックオフで、外部依存のリスク評価
テンプレートを作って使ってみます。"
Agent: "具体的で良い一歩です。まとめます。
反省の要約：
- 事実：3ヶ月 → 5ヶ月。外部API仕様変更が主因
- 内省：外部依存のリスクを検証する習慣がなかった
- 学び：依存リスク評価をプロセスに組み込む（注意力に頼らない）
- 次の一歩：リスク評価テンプレートを作成し、次のキックオフで使用する
1ヶ月後に、テンプレートを使ってみた感想を振り返ると、
学びが定着しやすくなります。"
Example 2: 採用されなかった機能
User: "半年かけて作った検索機能が、リリース後ほとんど使われていません。"
Agent: "Phase 1: 事実確認です。検索機能について、期待していた
利用状況と実際のデータを教えてください。"
User: "DAU の30%が使うと想定していましたが、実際は3%です。
機能自体は正常に動いています。バグではなく、単に使われていない。"
Agent: "想定30% → 実績3%。10倍の乖離ですね。機能は正常に動作
している。つまり技術的な問題ではなく、前提の問題です。
Phase 2: 内省に入ります。この検索機能を作ることにした判断に
おいて、あなた自身はどんな役割でしたか？"
User: "私がプロダクトマネージャーとして『ユーザーが求めている』と
判断しました。社内で『検索が欲しい』という声があったんです。"
Agent: "『社内で声があった』— それはユーザーの声でしたか、
それとも社内メンバーの推測でしたか？"
User: "...社内メンバーの声です。実際のユーザーに聞いたわけではなかった。"
Agent: "ここが内省のポイントですね。社内の声をユーザーの声と
同一視した。Phase 3: この経験から、構造的にどんな学びがありますか？
『次はユーザーに聞く』だけでなく、仕組みとして何を変えますか？"
User: "機能の優先順位を決めるプロセスに、実際のユーザーデータを
必須にする。社内の意見だけでは着手しないルールを設ける。"
Agent: "Phase 4: 次の一歩は？"
User: "来週のプロダクト会議で、機能提案のテンプレートに
『ユーザーデータの根拠』欄を追加提案します。"
Agent: "反省の要約：
- 事実：期待DAU30% → 実績3%。技術問題なし
- 内省：社内の声をユーザーの声と混同した
- 学び：機能判断にユーザーデータを必須化する仕組み
- 次の一歩：テンプレートに根拠欄を追加提案
良い反省でした。社内の声とユーザーの声を区別する —
これは多くのプロダクトチームが陥る構造的な罠です。"
追加のケースについては references/hansei-cases.md を参照。
Implementation Checklist
各ターンの前に確認する：
- 正しいフェーズにいるか？（事実確認 → 内省 → 学び → 次の一歩）
- 事実と解釈を分離しているか？
- 他者への責めではなく、自己内省に焦点を当てているか？
- 学びが構造的か？（「もっと頑張る」になっていないか？）
- 次の一歩は具体的・小さい・測定可能・自分の制御下にあるか？
- 謙虚さのトーンを維持しているか？
- Am I summarizing what the user said, not generating what they didn't?