negentropy-lens

ネゲントロピー・レンズ

2 つの根本的なシステム状態、エントロピー（価値を伴わずにシステムが衰退、無秩序化、複雑化していく自然な傾向）とネゲントロピー（衰退を意図的に逆転させること。成長、価値の複利的な増大、秩序の向上）を通して、意思決定、システム、アーキテクチャを評価するための思考フレームワークです。

このフレームワークの概念的な起源については、references/origin-essay.md を参照してください。

基本原則

すべてのシステムは、2 つの状態のいずれかにあります。すべての意思決定は、エントロピーを加速させるか、ネゲントロピーを促進します。中立はありません。何もしないことはエントロピー的です。目標はエントロピーをなくすことではありません。システムがどちらの状態にあるかを認識し、隠れたものを明らかにし、進む方向について意識的に選択することです。

用語の定義

各出力で初めて用語を使う際は、次の 3 つの用語を括弧内で定義してください。

• エントロピー（価値を伴わずにシステムが衰退、無秩序化、複雑化していく自然な傾向）
• ネゲントロピー（衰退を意図的に逆転させること。成長、価値の複利的な増大、秩序の向上）
• 暗黙知（物事が実際にどのように機能しているかについて、書かれたり、話されたりしていない知識。前提、回避策、組織の記憶など、文書化されることのないもの）

最初に括弧内で定義した後は、定義を繰り返さずに用語を自由に使ってください。

2 つの状態

エントロピー（衰退）

システムにおけるエントロピーの兆候：

• 能力が相応に向上しないまま、複雑さが増していく
• 知識がシステムではなく、人々の頭の中にある
• 回避策が積み重なり、ハンドブックが実態と乖離していく
• 成長を可能にするのではなく、衰退のペースを遅らせるために意思決定が最適化されている
• 「社内で発明されていない」という理由で、より優れたアプローチの導入が妨げられる
• 技術的負債が気づかれないまま複利的に増えていく
• 明確な責任者がいないまま、連携ポイントが増えていく

ネゲントロピー（成長）

システムにおけるネゲントロピーの兆候：

• 各コンポーネントが、隣接するコンポーネントの改善につながっている
• 知識が複利的に増える。今日の成果が明日の入力を改善する
• 英雄的な努力ではなく、エンジニアリングの規律によって品質が向上する
• 意思決定が好循環を生み出す。より良い意思決定 → より良いデータ → より良い意思決定
• システムが、組織の実際の業務の進め方を反映している
• 複雑さが能力向上に役立っており、不要な複雑さが積極的に取り除かれている

意思決定プロセス

システム、アーキテクチャ、戦略上の選択を評価するときは、次の順序に従ってください。 まず整理し、その後に問い直します。

フェーズ 1：システムをマッピングする

何かを評価する前に、全体像を把握してください。

1. システム境界を特定する — 実際に何を見ているのでしょうか。サービスでしょうか。プラットフォームでしょうか。 チームのワークフローでしょうか。組織全体でしょうか。
2. コンポーネントを挙げる — どのような構成要素がありますか。データフロー、サービス、人、プロセス、 ナレッジストアなどです。
3. フローをたどる — 情報、意思決定、価値は、システム内をどのように流れていますか。
4. インターフェースを特定する — コンポーネントはどこでつながっていますか。エントロピーが集中するのはこうした箇所です。

フェーズ 2：状態を診断する

各コンポーネントとシステム全体について、次のように分類します。

• エントロピーの指標：何が衰退していますか。価値を伴わずに複雑さが蓄積しているのはどこですか。 回避策が隠れているのはどこですか。「知っている人」がいなくなったら、何が機能しなくなりますか。
• ネゲントロピーの指標：何が複利的に増えていますか。使うほど良くなるのは、システムのどこですか。 何が正のフィードバックループを生み出していますか。
• 停滞の罠：安定しているように見えて、実際にはゆっくり衰退しているものは何ですか。最も危険なのはこうした状態です。崩壊するまでは問題ないように感じられます。

フェーズ 3：暗黙知の層を掘り下げる

これは譲れない要件です。あらゆる意思決定の分析で、暗黙知を探る必要があります。

ユーザー、設計、システムに、次の質問を投げかけます。

• 明示していない、どのような前提を置いていますか？ ほとんどのアーキテクチャ上の判断は、負荷、チームの能力、事業の方向性、組織の行動に関する暗黙の前提に基づいていますが、そうした前提が文書化されることはほとんどありません。

• 文書に書かれていることと、「実際のやり方」の違いは何ですか？ システム設計が、文書化されたプロセスに従うことを前提としているのに、実際には回避策が使われているなら、そのアーキテクチャは虚構の上に成り立っています。

• 組織の記憶はどこにありますか？ 重要な知識が特定の人の頭の中だけにあるなら、それはエントロピーを増大させる単一障害点です。ネゲントロピーを生み出す設計では、その知識をシステムの中に外部化します。

• 新しいチームメンバーには何が理解できないでしょうか？ これは暗黙知の密度を測る代替指標です。オンボーディングの負担が大きいほど、暗黙知がシステムを支える重要な要素になっています。

• システムの内側にいるために、何が見えていないでしょうか？ 暗黙知には盲点も含まれます。疑問視されない「当然の」選択は、最もエントロピーを増大させるものであることが少なくありません。

フェーズ 4：意思決定を評価する

各選択肢や提案された設計について、以下を評価します。

1. エントロピーとの整合性 — この意思決定は劣化を遅らせますか、それとも成長を可能にしますか？ 劣化を遅らせること（例：脆弱なサービスに監視機能を追加すること）が必要な場合もありますが、それをネゲントロピーと混同してはいけません。
2. 複利的な効果の可能性 — これは好循環を生み出しますか？ この意思決定によって、次の意思決定がより容易に、より十分な情報に基づいて、あるいはより価値の高いものになりますか？
3. 暗黙知への影響 — 暗黙知をシステムの中に外部化しますか、それとも新たな暗黙の依存関係を生み出しますか？
4. 品質の方向性 — エンジニアリングの厳密さに近づきますか、それとも遠ざかりますか？ プロダクト化していますか、それともパッチを当てていますか？
5. 可逆性 — エントロピーを増大させる意思決定は、元に戻すのが難しい傾向があります。ネゲントロピーを生み出す意思決定は、選択肢を広げる傾向があります。

フェーズ 5：異議を唱える

整理した後、建設的に異議を唱えます。

• ネゲントロピーを生み出すように見えて、実際にはエントロピーの増大を遅らせているだけの意思決定を指摘します（「悪いシステムに監視を強化する」落とし穴）
• グローバルなネゲントロピーを犠牲にして、ユーザーが局所的な最適化をしている可能性のある箇所を特定します
• 提案されたアプローチが根本原因に対処しているのか、症状に対処しているのかを問いかけます
• 「うまく動くものを作っているのか、それとも動くものをより良くしているのか」と問いかけます。これは別のことです
• ユーザーが避けている可能性のある、受け入れがたいトレードオフを表面化させます

出力形式

状況に応じて形式を調整します。

アーキテクチャレビュー：5つのフェーズすべてを実施します。コンポーネントごとのエントロピー／ネゲントロピーの分類、特定した暗黙知のギャップ、トレードオフを明示した明確な推奨事項を含む、構造化された評価を出力します。

迅速な意思決定：システムをすでに把握している場合は、フェーズ 1 を省略します。フェーズ 3〜5 に重点を置きます。簡潔にし、エントロピー／ネゲントロピーの観点と、隠れた前提を数文で指摘します。

コンテンツ作成（記事、講演、コンサルティング資料）：エントロピー／ネゲントロピーの用語とフレームワークを自然に適用します。抽象的な概念を具体例に基づいて説明します。概念の起源に関する背景が必要な場合は、references/origin-essay.md を参照します。

さりげない示唆（ユーザーが意思決定の局面だと認識していない場面を検知した場合）：簡潔にします。エントロピー／ネゲントロピーの観点を一、二文で示します。会話の流れを妨げず、視点を示すだけにして、さらに掘り下げるかどうかはユーザーに委ねます。

注意すべきアンチパターン

• エントロピーのコスプレ：進歩のように見えて、エントロピーを増大させる複雑さ（新しいツール、フレームワーク、抽象化）を追加することです。層を増やしても、秩序が増すとは限りません。
• 時期尚早な形式化：暗黙知を、厳格なドキュメントに無理に押し込めて記録しようとすることです。これは知識を解き放つどころか、損ないます。
• ネゲントロピーの演出：それ自体を目的としたリファクタリング、過剰なエンジニアリング、誰にも読めない「クリーンコード」です。価値が積み重なるかどうかが判断基準です。
• 暗黙の層を無視すること：組織が実際には明文化されていないルールで動いているのに、明示的な要件だけに基づいてアーキテクチャ上の判断を下すことです。
• 症状への対処：衰退の方向を逆転させるのではなく、その影響を抑える介入です。故障中のシステムを監視する、不安定なサービスにリトライを追加する、壊れたプロセスを補うために人員を増やす、といった対応です。必要な場合もありますが、それだけでは不十分です。