Tracing Knowledge Lineages

知識の系譜をたどる

概要

アイデアには歴史があります。現在のアプローチに至った理由や、以前に何が試されたかを理解すれば、失敗の繰り返しを防ぎ、放棄された解決策を再発見できます。

基本原則： 現在のアプローチを評価したり、「新しい」アプローチを提案したりする前に、その系譜をたどりましょう。

系譜をたどるタイミング

次の前に系譜をたどりましょう：

• 既存のアプローチの置き換えを提案する（まず、なぜそれが存在するのかを理解しましょう）
• 「古い」パターンを否定する（誤った理由で放棄されたのかもしれません）
• 「新しい」アイデアを実装する（再考する価値のある復活案かもしれません）
• 何かを「ベストプラクティス」と宣言する（どのように進化してきたかを理解しましょう）

系譜をたどるきっかけとなる危険信号：

• 「これは複雑すぎるようです」（以前はもっと単純だったのでしょうか？ なぜ複雑になったのでしょうか？）
• 「なぜ単に……しないのでしょうか」（おそらく誰かが試しています。どうなったのでしょうか？）
• 「これが現代的な方法です」（以前の方法から何を学んだのでしょうか？）
• 「X に切り替えるべきです」（もともと、なぜ X から離れたのでしょうか？）

系譜をたどる手法

手法 1：意思決定の考古学

現在のアプローチがいつ、なぜ選ばれたのかを調べます。

1. 意思決定記録を確認する（よくある場所：docs/decisions/、docs/adr/、.decisions/、アーキテクチャ意思決定記録）
2. 会話を検索する（skills/collaboration/remembering-conversations）
3. Git の履歴を調べる（git log --all --full-history -- path/to/file）
4. それを書いた人に尋ねる（可能であれば）

記録すること：

## Lineage: [Current Approach]

**When adopted:** [Date/commit]
**Why adopted:** [Original problem it solved]
**What it replaced:** [Previous approach]
**Why replaced:** [What was wrong with old approach]
**Context that drove change:** [External factors, new requirements]

手法 2：失敗した試みの分析

誰かが「X を試しましたが、うまくいきませんでした」と言ったとき：

決めつけないこと： X には根本的な欠陥がある 代わりに、次の点をたどります：

1. そのときの状況は？（現在は当てはまらない制約）
2. 具体的に何が失敗したのか？（アプローチ全体か、一部の側面か？）
3. そのとき失敗したのはなぜか？（技術的な限界、チームの制約、時間的なプレッシャー）
4. 状況は変わったか？（新しいツール、異なる要件、より多くの経験）

記録すること：

## Failed Attempt: [Approach]

**When attempted:** [Timeframe]
**Why attempted:** [Original motivation]
**What failed:** [Specific failure mode]
**Why it failed:** [Root cause, not symptoms]
**Context at time:** [Constraints that existed then]
**Context now:** [What's different today]
**Worth reconsidering?:** [Yes/No + reasoning]

手法 3：復活案の検出

「新しい」アプローチを評価するとき：

1. 過去の先例を検索する（名前を変えて以前に試されていないか？）
2. 本当に新しい部分を特定する（名前を変えただけのものと区別する）
3. 廃れた理由を理解する（復活案の場合）
4. 復活の条件が整っているか確認する（状況が十分に変わったか？）

よくある復活のパターン：

• マイクロサービス ← サービス指向アーキテクチャ ← 分散オブジェクト
• GraphQL ← SOAP ← RPC
• サーバーレス ← CGI スクリプト ← クラウド関数
• NoSQL ← フラットファイル ← ドキュメントストア

問いかけること：「以前の形から何を学んだのでしょうか？」

手法 4：パラダイムシフトのマッピング

大規模なアーキテクチャ変更があったとき：

移行をマッピングします：

## Paradigm Shift: From [Old] to [New]

**Pre-shift thinking:** [How we thought about problem]
**Catalyst:** [What triggered the shift]
**Post-shift thinking:** [How we think now]
**What was gained:** [New capabilities]
**What was lost:** [Old capabilities sacrificed]
**Lessons preserved:** [What we kept from old paradigm]
**Lessons forgotten:** [What we might need to relearn]

検索戦略

系譜を調べる場所：

1. 意思決定記録（よくある場所：docs/decisions/、docs/adr/、.adr/、または「ADR」、「decision record」で検索）
2. 会話の履歴（skills/collaboration/remembering-conversations を使って検索）
3. Git の履歴（git log --grep="keyword"、git blame）
4. Issue／PR の議論（GitHub／GitLab の Issue 履歴）
5. ドキュメントの変遷（git log -- docs/）
6. チームの知識（「これを以前に試した人はいますか？」と尋ねる）

検索パターン：

# Find when approach was introduced
git log --all --grep="introduce.*caching"

# Find what file replaced
git log --diff-filter=D --summary | grep pattern

# Find discussion of abandoned approach
git log --all --grep="remove.*websocket"

危険信号 — 歴史を無視しています

• 「これをそのまま書き直しましょう」（複雑な理由を理解しないまま）
• 「以前の方法が明らかに間違っていました」（背景を理解しないまま）
• 「もう X を使う人はいません」（廃れた理由を確認しないまま）
• 「古い」という理由でアプローチを退ける（古さ ≠ 品質）
• 「新しい」という理由でアプローチを採用する（新しさ ≠ 品質）

これらはすべて、いったん立ち止まり、まず系譜をたどるべきだという意味です。

履歴を覆すべきとき

次の場合は、来歴を無視してもかまいません。

1. 状況が根本的に変わった

   • 以前は存在しなかった技術が利用可能になった
   • 判断を強いた制約がもはや当てはまらない
   • チームが以前とは異なる能力を備えている

2. 重大な教訓を得た

   • 業界全体の理解が進んだ
   • 過去の試みから、避けるべきことを学んだ
   • より優れたパターンが生まれ、実証された

3. 当初の判断理由に誤りがあった

   • 後に誤りと判明した前提に基づいていた
   • 理解せずに形だけをまねていた
   • ニーズではなく流行に左右されていた

ただし、なぜ覆すのかを記録してください。 将来のあなたが、それが無知によるものではなく、意図的な判断だったと知る必要があります。

ドキュメントの形式

変更を提案する際は、来歴を含めてください。

## Proposal: Switch from [Old] to [New]

### Current Approach Lineage
- **Adopted:** [When/why]
- **Replaced:** [What it replaced]
- **Worked because:** [Its strengths]
- **Struggling because:** [Current problems]

### Previous Attempts at [New]
- **Attempted:** [When, if ever]
- **Failed because:** [Why it didn't work then]
- **Context change:** [What's different now]

### Decision
[Proceed/Defer/Abandon] because [reasoning with historical context]

例

適切な来歴の追跡

「以前はJSONではなくXMLを使っていました。XMLは冗長さが開発者体験を損なったため廃れました。しかし、XMLの名前空間は実際の問題を解決していました。JSONで名前空間の競合が発生したら、独自に作り直すのではなく、XMLがどう解決したかを調べるべきです。」

来歴を無視する悪い例

「RESTは古いので、GraphQLを使いましょう。」（無視していること：RESTがSOAPより選ばれたのはなぜか。どのような問題をうまく解決するのか。その問題はなくなったのか。）

文脈を踏まえた再検討

「2010年にクライアントサイドルーティングを試しましたが、ブラウザーのサポートが不十分だったため中止しました。現在はサポートが普及し、より優れたツールもあるので、得られた教訓を踏まえて再検討する価値があります。」

覚えておくこと

• 現在の手法には理由があります（その理由をたどりましょう）
• 過去に失敗した手法も、今ならうまくいく可能性があります（状況は変わります）
• 「新しい」手法が再登場したものかもしれません（先例を確認しましょう）
• 進化から学べます（変遷を調べましょう）
• 歴史を知らなければ、同じ過ちを繰り返すことになります