# Furikaeri Practice

> セッションや PR レビュー後のふりかえりを、KPT や YWT などの型で進める。Use when: 作業の学びを整理したいとき、改善アクションを決めたいとき、ふりかえり結果を蓄積したいとき。

- Skill: `ryomurakami1983/furikaeri-practice` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ryomurakami1983/furikaeri-practice`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ryomurakami1983/furikaeri-practice/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: RyoMurakami1983 (https://skillmd.com/u/ryomurakami1983)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ryomurakami1983/furikaeri-practice

---

# ふりかえりプラクティス

AI アシスタントとのセッションに、チームのふりかえり手法（KPT・YWT・5つのなぜ・SMART目標）を適用する構造化ワークフロー。暗黙知を形式知に変え、継続的カイゼンを実現する。

> **命名について**: 「ふりかえり」はひらがな表記が正式名称です。漢字の「振り返り」とは意図的に区別しています。「ふりかえり」は構造化された改善プラクティスを指し、単なる「過去を振り返る」行為とは異なります。

## こんなときに使う
以下のような場面で使います：
- コーディングセッションや複数ターンの会話を終えるとき
- PR レビューのフィードバック対応が完了したとき
- スプリントやマイルストーンの区切り
- セッションをまたいで同じ問題が繰り返し発生しているとき
- 暗黙知をドキュメント化された改善に変えたいとき
- 新しいプラクティスを導入して効果を追跡したいとき

## 関連スキル

- **`git-commit-practices`** — コミット履歴を学習資産に
- **`github-pr-workflow`** — PR作成とIssue close
- **`github-issue-intake`** — 改善項目をIssueとして起票

---

## 依存関係

- 必須なし（会話のみのワークフロー）
- オプション: GitHub CLI (`gh`) — 改善Issueの作成に使用

## コア原則

1. **立ち止まる** — 次のタスクに急ぐ前に、一度止まって観察する (温故知新)
2. **小さくカイゼン** — 少しずつ変える。小さな一歩が複利で効く (継続は力)
3. **知識を外に出す** — 暗黙の学びをチームの資産にする (成長の複利)
4. **事実ベース** — 事実から出発する。思い込みや責任追及ではなく (ニュートラル)
5. **型が洞察を生む** — KPT・YWT・5つのなぜ・SMARTという型が深い気づきを引き出す (基礎と型)

---

## ふりかえりの3つの目的

1. **立ち止まる** — 変化のきっかけをつくる。周りをみる。
2. **成長を加速させる** — 高頻度のコミュニケーションで悩み・問題を自然に共有し、即解決する。
3. **プロセスをカイゼンする** — 「価値をどう生み出しているか」に着目する。変更は小さく少しずつ。

---

## ワークフロー: ふりかえりを実施する

### Step 1: セッションストーリーを整理する

何が起きたかを時系列で整理する。事実に集中し、感情や判断は次のステップで扱う。

```markdown
## セッションストーリー

1. Issue #42（検索フィルタ追加）に着手
2. featureブランチを作成、テストファーストで実装（TDD）
3. 結合テストでAPIタイムアウトが発生
4. モック化に切り替え、テスト通過
5. PRレビューで2件の修正指摘
6. 修正してマージ完了
```

ユーザーへの問いかけ:
- 「今日は何に取り組みましたか？」
- 「このセッションの流れを教えてください。」

どのふりかえりでも最初に必ず行う。

> **Values**: 温故知新 / ニュートラル

### Step 2: KPT または YWT で分析する

フレームワークを1つ選び、セッションストーリーを分類する。

**KPT（Keep / Problem / Try）**

| カテゴリ | 説明 | 例 |
|---------|------|-----|
| **Keep** | うまくいったこと — 続けたい | TDDでタイムアウトを早期発見できた |
| **Problem** | うまくいかなかったこと — 修正が必要 | APIドキュメントが古かった |
| **Try** | 次に試したいこと | テスト設定にタイムアウト設定を追加 |

Try には2つの目的があります：
- **Keep強化** — すでにうまくいっていることをさらに伸ばす（← K と表記）
- **Problemカイゼン** — うまくいかなかったことを修正・防止する（← P と表記）

**YWT（やったこと / わかったこと / つぎにやること）**

| カテゴリ | 説明 | 例 |
|---------|------|-----|
| **Y**（やったこと） | 実際にやったこと | ユニットテスト5件、結合テスト1件を書いた |
| **W**（わかったこと） | 気づいたこと・学んだこと | 不安定なAPIにはモックファーストが速い |
| **T**（つぎにやること） | 次にやること | チーム用のモックライブラリを作る |

```markdown
## KPT

### Keep
- TDDワークフローで問題を早期発見できた
- アトミックコミットのおかげでレビューがスムーズだった

### Problem
- APIドキュメントが古くなっていた
- タイムアウトのデバッグに30分かかった

### Try
- (← K) テストセットアップにタイムアウト設定を追加する
- (← P) APIドキュメント更新を完了定義（Definition of Done）に含める
```

ユーザーへの問いかけ:
- 「KPTとYWT、どちらを使いますか？」（デフォルト: KPT）
- 「続けたいこと（Keep）は何ですか？」
- 「困ったこと（Problem）は何でしたか？」
- 「次に試したいこと（Try）は何ですか？」

必ず行う。ふりかえりの中核となる分析ステップ。

> **Note**: KPT/YWTのリストは必ずマークダウンテキストで会話に出力し、スクロールして見返せる形で残すこと。`ask_user` 等の選択UIは、Step 3の優先度選択など判断が必要な場面のみ使用する。選択UIは選択後に内容が消えるため、分析内容の記録には不向き。

> **Values**: 基礎と型 / 成長の複利

### Step 3: 重要項目をピックアップする

すべてが同じ重要度ではない。影響の大きい項目に絞り込む。

Step 2 の結果をまとめて提示し、ユーザーに1〜3項目を選んでもらう:

```markdown
## 優先項目（ドット投票方式）

KPTの結果から、最も重要な項目はどれですか？

1. 🔴 APIドキュメントが古かった（Problem）
2. 🟡 タイムアウト設定を追加（Try）
3. 🟢 TDDワークフローが有効だった（Keep）

→ ユーザー選択: #1（ドキュメント問題）と #2（タイムアウト設定）
```

ルール:
- 最大3項目に絞る
- 少なくとも1つはアクション可能な項目（Problem または Try）を含める
- Keep 項目は認識するが、アクションプランは不要

必ず行う。本当に大事なことにフォーカスさせる。

> **Values**: ニュートラル / 継続は力

> **次のステップ**: ここで選んだ優先項目は **Step 6a** で必ず GitHub Issue に変換する。Step 6 を完了せずにセッションを終了しないこと — 登録されなかったアクションは消える。

### Step 4: 深掘りする（必要な場合のみ）

根本原因が不明な項目には **5つのなぜ** を適用する。その後、アクション項目を **SMART目標** に落とし込む。

**5つのなぜ（例）**

```markdown
## 5つのなぜ: APIドキュメントが古かった

1. なぜドキュメントが古かった？
   → API変更時に誰も更新しなかった。
2. なぜ誰も更新しなかった？
   → PRチェックリストに含まれていなかった。
3. なぜチェックリストに含まれていなかった？
   → API変更の完了定義を決めていなかった。
4. なぜ完了定義がなかった？
   → API変更プロセスを形式化していなかった。
5. なぜ形式化していなかった？
   → 少人数チームで、全員わかっていると思い込んでいた。

根本原因: API変更プロセスが形式化されていなかった。
```

**SMART目標**

| 要素 | 内容 |
|------|------|
| **S**pecific（具体的） | PRチェックリストに「APIドキュメント更新」を追加 |
| **M**easurable（測定可能） | API関連PRの100%にドキュメント更新を含める |
| **A**chievable（達成可能） | チェックリスト1項目の追加 |
| **R**elevant（関連性） | ドキュメント陳腐化を直接防止 |
| **T**ime-bound（期限付き） | 次のスプリントまでに追加 |

Problem項目の根本原因が不明な場合、またはTry項目に具体的な計画が必要な場合。

> **Values**: 温故知新 / 基礎と型

### Step 5: ふりかえりのふりかえり

ふりかえりプロセス自体を改善する。1つだけ質問する:

> 「次のふりかえりで変えたいことは何ですか？」

例:
- 「ストーリーに時間をかけすぎた。分析を増やしたい」
- 「次回はKPTの代わりにYWTを試してみる」
- 「メトリクス（所要時間、コミット数）を含める」
- 「5つのなぜは不要だった。問題はシンプルだった」

次のセッション用に記録する。

```markdown
## メタふりかえり

次回の改善: YWT形式を試す — 今回のセッションタイプにはKPTが単調だった。
```

必ず行う。たった1文でも次のふりかえりを改善する。

> **Values**: 継続は力 / 成長の複利

#### スキル化候補チェック

メタ質問の後、もう一つ問う：

> 「今回のセッションで言語化されたノウハウをスキル化できるものはあるか？」

スキル化候補の例：
- その場で生み出したチェックリスト（例：「コアドメイン先行設計チェックリスト」）
- 繰り返す問題クラスへの対処パターン
- 他のコンテキストにも応用できる意思決定フレームワーク
- メタふりかえりで発見したワークフロー改善

アクション分岐：
- **新スキルが必要** → `skill` を起動
- **既存スキルの更新** → 該当スキルに対して `skill` を起動
- **候補なし** → Step 6 に進む

```markdown
## スキル化候補チェック

候補：
- [パターン名/チェックリスト名]: → skill / skill（[スキル名]）
- 今回のセッションでは候補なし
```

> **なぜ重要か**：ふりかえりはノウハウを表面化させる。スキルはそれを保存する。このステップなしでは、暗黙知は一度言語化されるだけで失われる。ここでループを閉じることで、個人の学びが再利用可能なチーム資産になる。

> **Values**: 基礎と型 / 成長の複利 / 教える→広める→仕組み化

### Step 6: ふりかえり記録の保存

#### 6a: アクションを GitHub Issue に登録

優先したアクション項目を、追跡可能なIssueに変換する。

1. 各優先アクションについて「Issue化しますか？」を確認する。  
2. はいの場合は、SMART文脈（目的・完了条件・期限）を含めてIssueを作成（またはIssue下書きを提示）する。  
3. 発行したIssue番号をふりかえりノート側に記録し、Issue本文（またはコメント）にも当該ふりかえりノートへのリンク（URLやパス）を追記して相互参照にする。

```markdown
## Action → Issue 対応

| Action (SMART) | Issue |
|---|---|
| PRチェックリストに「APIドキュメント更新」を追加（次スプリントまで） | #128 |
| テストセットアップへタイムアウト設定を追加（今週中） | Draft: "Add timeout config to integration tests" |
```

> **アクション種別による分岐**
> - **コーディング・プロセスの改善** → GitHub Issue を作成（本ステップ）
> - **skill・型・ワークフローの改善** → `skill` を起動して該当スキルを更新

#### 6b: Notion へ保存（RyoMurakami1983 のみ）

> **適用条件**: `metadata.author == "RyoMurakami1983"` のセッション（このskills_repository）のみ。
> その他のコンテキストではこのステップをスキップする。

ふりかえり内容は **`notion-safe-operations`** を使って保存する。

> **なぜこの分岐？** Notionツールの可用性はセッション/エージェント/モデルで変動する。基盤スキルに集約することで、Preflight確認・DS ID安全管理・失敗時フォールバックを一貫運用できる。

> **DS ID 運用方針**: `NOTION_FURIKAERI_DS_ID` などのローカル環境変数、またはローカル設定を使う。実UUIDをリポジトリへコミットしない。

KPT/YWT のアウトプットをフィールドにマッピングする:

| Notion フィールド | 内容 |
|---|---|
| `タイトル` | セッションタイトル（何をしたか簡潔に） |
| `セッション日時` | セッション日付（`YYYY-MM-DD`） |
| `ステータス` | `完了` |
| `実施内容` | Step 1 のストーリーを番号付きリストで |
| `学び・気づき` | Keep 項目 + 新しい気づき（Step 2 から） |
| `課題・問題点` | Problem 項目（Step 2 から） |
| `次回アクション` | SMART 目標 + Issue 番号（Steps 3–4 + 6a から） |
| `関連タグ` | JSON 配列 — 選択肢: `["開発", "デバッグ", "設計", "テスト", "レビュー", "リファクタリング", "ドキュメント", "会議", "学習"]` |

`notion-safe-operations` を呼び出し、上記マッピング済みコンテンツを create-page payload に渡す。

> **なぜ？** — GitHub Issue は「次にやること」の追跡に強く、Notion は「時系列のふりかえりログ」として長期トレンドの把握に強い。両方を使うことで、実行管理と成長記録を分離できる。

> **完了ゲート（既定）**: Step 5 の分析だけでセッションを終えないこと。ふりかえりは、次の2つが完了して初めて「完了」とみなす。
> 1. **Step 6a** で優先アクションを GitHub Issue に変換する（または作成しない理由を明示する）
> 2. **Step 6b** が適用されるコンテキストでは Notion に記録を保存する
>
> Step 6b が適用されない場合でも、Step 6a を終えたうえで「ふりかえりノートをどこに残すか」を明示する。

> **Values**: 継続は力 / 成長の複利 / 基礎と型

### Step 7: Anonymization Gate (Before Output)

ふりかえり内容が公開スキルや共有ドキュメントに流れる可能性がある場合は、`knowledge-capture` の **Anonymization Checklist**（AC-1〜AC-4）を適用してから出力する。プロジェクト固有名、データ形式、業務ドメイン語、具体的な数値は一般化する。

> **Values**: ニュートラルな視点（固有データの漏洩を入口で防ぐ）

---

## ベストプラクティス

- ソロセッションのふりかえりは10分以内に収める
- 問題解決型のセッションにはKPT、学習型のセッションにはYWTを使う
- アクション項目はすぐに書き留める — 記憶に頼らない
- アクション項目をGitHub Issueに紐づけて追跡する
- **Issue化 + 記録保存** を既定の終了条件とし、後片付け扱いにしない
- 新しいふりかえりを始める前に、前回のふりかえりノートを読む

## よくある失敗

1. **ストーリーステップを飛ばす**
   対策: 必ず事実から始める。文脈なしの分析は誤った結論を招く。

2. **アクション項目が多すぎる**
   対策: 最大3項目に絞る。5つ放置するより1つ完了する方がよい。

3. **Tryが曖昧**
   対策: SMART目標に変換する。「もっと気をつける」はアクションではない。

4. **犯人探しのProblem**
   対策: プロセスとツールに注目する。「〇〇さんがミスした」ではなく「プロセスがXを許容した」。

5. **過去のふりかえりを見返さない**
   対策: 開始前に前回のノートを1分だけ読む。

6. **分析で終わってしまう**
   対策: Step 5 で止めず、Step 6 の Issue化と記録保存まで回してループを閉じる。

## アンチパターン

- ふりかえりをステータスレポートにする（改善のためのもので、報告のためではない）
- 問題が起きたときだけふりかえる（良いセッションにも学びがある）
- 「ふりかえりのふりかえり」を飛ばす（メタステップが長期改善を駆動する）
- アクション項目を書いてフォローアップしない

---

## クイックリファレンス

### KPT テンプレート

```markdown
## KPT — [日付/セッション名]

### Keep
- 

### Problem
- 

### Try
- (← K) Keep強化案
- (← P) Problemカイゼン案

### 優先項目（上位1-3）
1. 

### アクション（SMART）
- 

### メタ
- 次回のふりかえり改善点: 

### スキル化候補チェック
- 候補: 
```

### YWT テンプレート

```markdown
## YWT — [日付/セッション名]

### Y（やったこと）
- 

### W（わかったこと）
- 

### T（つぎにやること）
- 

### 優先項目（上位1-3）
1. 

### アクション（SMART）
- 

### メタ
- 次回のふりかえり改善点: 

### スキル化候補チェック
- 候補: 
```

### 判断テーブル

| 状況 | フレームワーク | 理由 |
|------|-------------|------|
| 問題が多いセッション | KPT | KeepとProblemを明確に分離できる |
| 学びが多いセッション | YWT | 発見したことに焦点を当てられる |
| 根本原因が不明 | KPT + 5つのなぜ | システム的な問題を掘り下げられる |
| 初めてのふりかえり | KPT | よりシンプルで直感的 |

---

## FAQ

**Q: ふりかえりにはどのくらい時間をかけるべき？**
A: AI とのソロセッションなら5〜10分。チームセッションなら15〜30分。

**Q: KPT と YWT、どちらが良い？**
A: 問題解決型のセッションにはKPT、学習型にはYWT。両方試して合うものを選ぶ。

**Q: 毎回7ステップ全部やる必要がある？**
A: 基本は Step 1〜3・Step 5・Step 6 を実施する。Step 4（5つのなぜ + SMART）は複雑/再発問題のときに使い、Step 7（Anonymization Gate）は公開・共有に流れる可能性がある場合のみ必須。実務上は Step 6 が終わるまで、ふりかえり完了とはみなさない。

**Q: 何も問題がなかったら？**
A: 良いセッションにもKeep項目やTry項目がある。「もっと良くするには？」は必ず何かを生む。

**Q: ふりかえりノートはどこに保存する？**
A: `RyoMurakami1983` のセッションでは Step 6b で自分専用のプライベート Notion ふりかえりログ DB に保存する。その他のコンテキストでは、フォローアップ用 GitHub Issue を作成したうえで、ふりかえりノート本体をプロジェクトノートや合意済みのチーム保存先に残す。アクション追跡と記録保存の両方が済むまでは、セッションを完了扱いにしない。

---

## 参考文献

- Esther Derby & Diana Larsen, *Agile Retrospectives*（アジャイルレトロスペクティブズ）
- https://www.funretrospectives.com
- トヨタ生産方式 — 5つのなぜ
- George T. Doran, "There's a S.M.A.R.T. Way to Write Management Goals and Objectives"