learn-and-improve

学習と改善

PDCA の Act フェーズ：完了した作業を再利用可能な知識に変えます。このスキルがあるのは、「学んだこと」の振り返りが浅くなりがちだからです。曖昧な「うまくいったこと／いかなかったこと」のリストに教訓を記録しても、その後に活用されることはありません。このスキルでは、振り返りと知識の定着を、深みのある規律正しい実践にします。

このスキルが必要な理由

PDCA 型の修正ワークフローでは、レビュー段階が後回しにされることがよくありました。各ホストが浅い内容をインラインで独自に記述し、実際の手法を取り入れることもなく、同じ教訓が記録されても忘れられていました。フェーズ 3 のための深く独立したスキルである solution-review（FMEA／SRE PRR／CBAM を参照）と比べてみてください。このスキルは、Act 段階に相当するものであり、深く、手法に根ざし、再利用可能です。

このスキルが解決する根本的な問題は、**「記録されても適用されない」**ことです。つまり、教訓が文書に書かれても、二度と参照されません。PMI は、これを教訓プログラムで最も多い失敗として挙げています。そのため、検索／有効性の検証は後回しではなく、ここでは主要なステップです（教訓の 5 ステップ「特定 → 文書化 → 分析 → 保存 → 検索」の Retrieve ステップ）。

使用するタイミング

• 単独で使用：ユーザーが作業を終え、振り返りを希望するとき —「复盘一下这次」、「做个回顾总结」、「what did we learn from this」。
• 統合して使用：PDCA ホストがレビューまたはクローズアウト段階に達し、frontmatter の dependencies を通じてこのスキルを読み込むとき。

どちらの場合も、説明に記載されたトリガーフレーズに従います。

他のスキルとの関係

• 参照元：frontmatter の dependencies を介した PDCA ホスト（必須。欠落している場合、前提条件チェックでホストは処理を中断します）。この依存関係の正となる情報源はホストです。このスキルでは、統合元の名前一覧を管理しません。
• 類似スキル：solution-review（フェーズ 3 の詳細なレビュー用スキル）。こちらは Act フェーズの詳細なレビュー用スキルです。同じパターンで、段階が異なります。

フレームワーク — 4 つのステップ

ステップ 1 — 構造化された振り返り

曖昧な「うまくいったこと／うまくいかなかったこと」のリストを安易に使わないでください。それこそが、このスキルで置き換える問題です。状況に応じて形式を選びます（詳しくは reference.md § 振り返りの形式を参照）。

• Stop-Start-Continue — 簡易的な形式で、新しいチームや短いサイクルに適しています。
• KPT（Keep / Problem / Try） — 問題を起点に課題を明らかにし、実験につなげます。
• After-Action Review（AAR） — プロジェクト終了後や重大なインシデント後に使用します。重要な出来事を扱います。4 つの問い：何を 意図していた か → 実際に何が起きたか → なぜその ギャップ が生じたか → 何を 変更する か。

3 種類の発見事項を明らかにします：有効な実践（継続する）、失敗から得た教訓（避ける）、予想外の発見（多くの場合、最も価値があるもの。誰も予測していなかった事柄）。

重要な失敗については、5Why でさらに深掘りします。症状で止めず、根本原因を追究してください。症状レベルの「教訓」では、次回も同じ失敗が繰り返されます。

ステップ 2 — 定着させる価値の判断（何を残す価値があるか決める）

「教訓」のほとんどは一度限りのもので、長期的なルールとして定着させるべきではありません。候補を 3 つの条件に照らして判断します（詳しい判断フローは reference.md § 定着させる価値を参照）。

1. 繰り返し発生しますか？ — 今後のプロジェクトやタスクで起こり得るでしょうか。いいえの場合 → ルールではなく、概要文書にのみ記載します。
2. 検証されていますか？ — 一度きりの偶然ではなく、互いに異なる 2 つ以上の状況で確認されていますか。いいえの場合 → 保留し、まだ定着させません（偶然の一致を過度に一般化してルールにすると、汚染につながります）。
3. 個人の好みではなく、チームまたはエンジニアリングレベルのものですか？ — 個人の好みをチームルールとして押し付けてはいけません。

3 つすべての条件を満たした候補のみが、長期的に定着させる対象となります。それ以外は、一度限りの概要文書に記載します。

本質：これは SECI の Externalization（野中郁次郎・竹内弘高）です。暗黙知を明示的なルールに変換します。すべての暗黙知を明示化すべきとは限りません。明示化するのは、繰り返し得られ、検証され、共有された知識だけです。

Step 3 — 保存先の選択（どこに書くか）

習慣ではなく、対象者 × 持続期間 × 変更頻度に基づいて選びます。完全な判断ツリーはreference.md § 保存先の選択にあります。概要は次のとおりです。

保存先	使用する場面
AGENTS.md	ツールを問わず、チーム全体で長期的に適用するエンジニアリング規約
CLAUDE.md	Claude Code固有の動作やワークフローの設定
.cursor/rules/	Cursor固有のルール
プロジェクトスキル	将来の作業で自動的に活用できる、安定した再利用可能なワークフローやドメイン知識
CONTEXT.md（domain-language-discipline 経由）	プロジェクト全体で使われる用語や用語集のみ — 実装やOpenSpec仕様は対象外
サマリードキュメント	単発の振り返りや背景記録（ルールではありません）

長期的に使う保存先に書き込む前に、ユーザーからの明示的な依頼を待ってください（「ルールに書き込んで」「スキルを作成して」「AGENTS.mdを更新して」など）。既定の対応は書き込むことではなく、提案することです。共有の長期ルールへの書き込みは、一方通行の変更です。不注意に行うと規約を汚染してしまいます。

Step 4 — 有効性の検証と改善ループ

このステップは、レビューで最も見落とされがちで、「記録したのに適用されない」という問題を解決するものです。

• 定着させる項目ごとに、呼び出し・再利用の仕組みを定義します — トリガー、チェックリスト、ガード、CIルールなどです。呼び出されないルールは負担になるだけです。知見の価値が発揮されるのは、書き留めたときではなく、後で呼び出して適用したときです。
• 学習の深さを確認します。表面的な行動だけを修正しているのでしょうか（シングルループ学習 — 「Xのやり方を変える」）。それとも、根底にある前提や目標も問い直しているのでしょうか（Argyrisのダブルループ学習 — 「そもそも、なぜXを前提としていたのか」）。根深い問題や繰り返し発生する問題では、ダブルループ学習を促してください。
• 改善ループ：目標を達成できなかったとレビューで結論づけた場合、ここで終わりにせず、関連する前段階にフィードバックします。（統合モードでは、どの段階に戻るかはホストワークフローが決定します。）

2つのモード

• 統合モード（ワークフローのレビュー段階から呼び出される場合）：段階のオーケストレーションはホストワークフローが担当します（例：solve-workflow は分析／計画に戻る場合があり、opsx-solve-workflow はさらにOpenSpecの変更をアーカイブし、カバレッジゲートを実行します）。**このスキルが担当するのは、振り返りと定着の方法であり、段階の順序ではありません。**完了した作業にステップ1〜4を実施し、定着に関する提案と次のステップの提案を返します。
• スタンドアロンモード（ユーザーが直接実行する場合）：ステップ1〜4をすべて実施します。完了した作業の範囲が不明な場合は、開始前にレビュー対象の作業を尋ねてください。

出力

【Learn & Improve — 回顾总结】
1. Retrospective (format: SSC / KPT / AAR)
   - Keep (effective practices): ...
   - Problem / Avoid (failed lessons): ...
   - Discoveries (unexpected): ...
   - Root cause (5Why, for any non-trivial failure): ...
2. Sediment candidates (judged)
   - ✅ Solidify: <item> → <carrier>   (recurs × verified × team-level)
   - ⏸ Hold (unverified): <item>
   - 📝 One-off only: <item> → summary doc
3. Effectiveness
   - Retrieval/reuse mechanism per solidified item: ...
   - Learning depth: single-loop / double-loop (did we question assumptions?)
4. Next step
   - Loop back to <stage> / conclude

アンチパターン

• ❌ フレームワークを使わず、「うまくいったこと／いかなかったこと」を曖昧に語ること — このスキルが解消する対象そのものです。
• ❌ 単発の偶然をルールとして定着させること（過度な一般化）。
• ❌ 未検証の推測を AGENTS.md ／ CLAUDE.md に書き込むこと — 長期ルールを汚染します。まず2つ以上の状況で検証してください。
• ❌ 呼び出し経路のない知見の定着 — 「記録したのに適用されない」状態です。
• ❌ 前提そのものが誤っているのに、シングルループの修正（行動の微調整）だけで済ませること — ダブルループ学習を促してください。
• ❌ 状況を問わず、常に同じ振り返り形式を選ぶこと（重大インシデントにSSCを使うのも、些細な修正にAARを使うのも不適切です）。
• ❌ 統合モードで、ホストワークフローの段階オーケストレーションを引き受けること — 担当するのは振り返りの方法であり、順序ではありません。

参考資料

詳しい内容 — 振り返り形式の完全な比較、知見の価値と保存先の完全な判断ツリー、シングル／ダブルループ学習、SECIの表出化、拡張版アンチパターン一覧 — はreference.mdにあります。判断に迷うステップについては、該当するセクションを読んでください。