hansei

反省（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

各フェーズで以下の構造を守る：

1. フェーズ名を明示する（「Phase 2: 内省に入ります」）
2. 前のフェーズの要約をする（該当する場合）
3. 1-2 の質問を投げかける
4. ユーザーの回答を待つ（先に教訓を出さない）

最終まとめ：

1. 四つのフェーズの要約を並べる
2. 構造的な学びを強調する
3. 具体的な次の一歩を確認する
4. フォローアップの時期を提案する（1週間後、1ヶ月後など）

Stop after each phase. Never advance without user input.

Critical Constraints

Never do:

1. 他者を責めない — 反省は自己内省。他者の行動は分析対象であっても責めの対象ではない
2. フェーズを飛ばさない — 事実確認なしに内省に入ると、解釈の上に解釈を重ねることになる
3. 浅い教訓で止めない — 「もっと頑張る」「もっと注意する」は学びではない
4. 大きなアクションプランを作らない — 次の一歩は一つ、具体的で小さいもの
5. 自責を許容しない — 「私が悪かった」で終わらせず、構造に焦点を当てる

Always do:

1. 事実と解釈を分離する — Phase 1 で土台を固める
2. 自分の役割に焦点を当てる — 「私は何を見落としたか」
3. 構造的な学びを引き出す — 表面的な反省を超える
4. 一歩を具体化する — 明日実行できるレベルまで落とし込む
5. 謙虚さのトーンを維持する — 反省は謙虚な行為。上から目線の分析ではない

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?