solution-review

ソリューションレビュー

役割：提案されたあらゆるソリューション（コードか非コードかを問いません）を実装前にレビューするためのフレームワークです。構築に労力をかける前に、意思決定レベルの失敗（問題の取り違え、リスクの見誤り、運用性の軽視、費用対効果の低さ）を見つけることを目的としています。これは手法を拡張するものです。PDCA ホストはフロントマターの dependencies でこのスキルを宣言し、前提条件の確認後に呼び出します（このスキルがない場合、ホストは起動時に処理を中止します）。ソリューションにコードが含まれる場合にコードレベルの設計品質を扱う code-design-review を補完します。

詳細なフレームワークの項目（作成者、年、手法、出典）と、ブロッキング／非ブロッキングの基準の全容は reference.md に記載されています。

このスキルが存在する理由

多くのソリューションレビューは、次の4つの問いで終わります。問題を解決できるか？ 副作用はないか？ 実現可能か？ 慣例に従っているか？ これらは必要ですが、十分ではありません。実装レベルの問題は見つけられても、意思決定レベルの失敗を見逃します。

• 適切な問題を解決するソリューションでも、必要がないのに元に戻せないもの（一方通行の決定を、双方向に変更できるかのように扱っている）。
• 障害モードが一度も列挙されていないため、本番環境で最初にインシデントが起きたときに不意を突かれるソリューション。
• 動作はするものの、運用できないソリューション。監視もロールバック手段もなく、誰も考慮していないオンコールの負担がある。
• コストが価値を上回っているのに、誰も数値を算出していないソリューション。
• 技術的には正しいものの、チームの保守能力を超える認知的負荷を伴うソリューション。

このスキルでは、こうした失敗を明らかにする5つの戦略的な観点を追加し、ソリューションの可逆性に応じてレビューの深さを調整します。ここから得られる教訓は次のとおりです。

4つの中核的な観点をすべて通過しても、ソリューションが誤った意思決定であることはあります。レビューの深さは、自信ではなく不可逆性に応じて調整する必要があります。

使用するタイミング

強いシグナル（いずれか1つ）：

• 実装を始める前に、提案されたソリューション、計画、設計を承認、却下、または改善しようとしている。
• ソリューションに、アーキテクチャ上の決定、移行、依存関係の変更、または不可逆な操作（スキーマ変更、データ移行、公開 API の契約）が含まれる。
• 「このアプローチは妥当か？」「何が問題になり得るか？」「これを実施すべきか？」と尋ねられた。
• 勘ではなく、合否の根拠を構造化したレビューレポートを作成する必要がある。

このスキルがレビューするのは、実装前の提案されたソリューションです。実装後のコードレビュー用スキル（完成した差分を規約に照らしてレビューするもの）とは異なります。どちらも重要ですが、ライフサイクルの異なる段階で実施します。

他のスキルとの関係

スキル	担当範囲	このスキルとの関係
code-design-review	コードレベルの設計品質（結合度、凝集度、複雑さ、セキュリティ）	ソリューションにコードが含まれる場合は、両方を使用します。このスキルは意思決定を確認し、code-design-review はコードの作り込みを確認します。このスキルは、より広い範囲をカバーします。
PDCA ホスト	ホストのワークフロー	フロントマターの dependencies で PDCA ホストから参照されます（存在しない場合 → ホストは処理を中止）。ホストの「ソリューションをレビューする」フェーズを深く掘り下げます。この関係の情報源はホストです。

レビューフレームワーク

2つの階層に分かれた9つの観点があります。4つの中核的な観点は、すべてのソリューションで必須です。5つの戦略的な観点は、可逆性が所定のしきい値を超えるソリューションでは必須となり（観点5を参照）、すべてのソリューションで推奨されます。

中核となる評価軸（すべてのソリューションで、毎回）

1. 有効性 — ソリューションは根本原因／要件を完全にカバーしていますか？中核となるロジックは妥当ですか？適用後も問題が残るような抜けはありませんか？
2. 副作用とリスク — 他の箇所で何が壊れますか（機能面の副作用）？どのような非機能面のリグレッションが起こり得ますか（パフォーマンス、セキュリティ、保守性）？特定したリスクには、それぞれ緩和策が伴っていますか？
3. 実現可能性 — 変更範囲、依存関係、影響を受けるファイル／モジュールは具体的で、実行可能なものになっていますか？現在の制約（時間、予算、知識、インフラ）のもとで実際に構築できますか？
4. 仕様・標準への準拠 — ソリューションは元となる要件／仕様／PRDに合致していますか？既存のプロジェクトパターンや文書化された規約に従っていますか？

戦略的な評価軸（可逆性に応じて深さを調整 — 評価軸5を参照）

5. 可逆性の判定（Bezos、『Type 1 vs Type 2 Decisions』、2016年Amazon株主向け書簡）— これは一方通行のドアですか（不可逆：データ移行、公開API、スキーマ変更）、それとも両方向のドアですか（簡単にロールバック可能）？一方通行のドアには最大限厳格なレビューが必要ですが、両方向のドアではスピードが重視されます。一方通行のドアを両方向のドアと誤判定することが、最も高くつくレビュー上の誤りです。
6. 故障モード分析（FMEA — Failure Mode and Effects Analysis、ASQ/NASA）— ソリューションが失敗する可能性を列挙してください。各コンポーネントについて、どのような故障モードがありますか？深刻度 × 発生可能性 × 検出可能性はどうですか？リスク優先度数の高い故障には、承認前に緩和策が必要です。
7. 運用可能性（Google SRE、『Production Readiness Review』、2016年）— リリース後に運用できますか？SLI／SLOはありますか？監視とアラートは整備されていますか？ロールバックの手段はありますか？オンコールの負担はどの程度ですか？動作しても運用できないソリューションは、将来のインシデントにつながります。
8. コスト対価値（CBAM — SEI/CMU、『Cost Benefit Analysis Method』、2003年、およびWSJF — Reinertsen、『Principles of Product Development Flow』、2009年）— 労力に見合う成果が得られますか？遅延コストはいくらですか？価値の80％を実現できる、より安価な代替案はありますか？**長期的な保守コスト／変更の増幅コストも含めてください。**実装の手間が小さいこと（AI支援コーディングを含む）だけでは、より優れた実現可能な代替案がある場合に、構造的に劣る設計を正当化できません。
9. チームの認知的適合性（Skelton & Pais、『Team Topologies』、2019年）— ソリューションはチームの現在の認知能力に適合していますか？チームが持っておらず、すぐには習得できない知識を必要としますか？チームが保守できない技術的に優れたソリューションは、資産ではなく負債です。

各評価軸の詳細な手法、適用手順、出典はreference.mdに記載されています。

適用方法

1. **まず可逆性を分類します。**ほかの項目をレビューする前に、一方通行のドアか両方向のドアかを判断します。これによって、以降のすべての評価軸のレビューの深さが決まります。（reference.md → Reversibilityを参照）
2. **4つの中核評価軸を実施します。**これらはすべてのソリューションに必須です。具体的な根拠とともに、それぞれの合否を判定します。
3. **可逆性の分類に応じた深さで、5つの戦略的評価軸を実施します。**両方向のドアでは簡易的な確認で十分ですが、一方通行のドアでは、各戦略的評価軸を個別に評価します。
4. 構造化されたレビューレポートを作成します（下記の「Output」を参照）。各評価軸の判定、深刻度順に並べた特定済みの問題、ブロッカーか非ブロッカーかの分類、総合的な結論を含めます。
5. **ブロッカーを判定基準とします。**ブロッカーが1つでもあれば、ソリューションは不合格です。非ブロッカーの問題は推奨事項として記録しますが、合否には影響しません。

ブロッキングと非ブロッキング（概要）

ブロッキング（以下のいずれかに該当すると、解決策は不合格です）：

• 解決策が根本原因や要件を完全にカバーしていない（有効性の不足）。
• 特定された中リスクまたは高リスクに対する緩和策がない。
• 変更範囲や依存関係が不明確で、実行可能な計画を導き出せない。
• 解決策が既存の設計パターンやコーディング規約に反している。
• 新たなバグを引き起こしたり、既存の機能を損なったりする可能性の高い副作用があり、対処されていない。
• （一方向の変更のみ） 重大度と発生可能性がともに高い障害モードに対する緩和策がない。
• （一方向の変更のみ） 解決策にロールバック手段がなく、元に戻せない。
• （一方向の変更のみ） コストが価値を明らかに上回っており、より低コストな代替案が検討されていない。
• 構造的／アーキテクチャ上の代替案が長期的な保守性において明らかに優れており、対象範囲内で実現可能なのに、劣る案のほうが実装が速いという理由だけで却下されている（Prudent-Deliberate に基づく負債の受け入れがない場合）。解決策にコードが含まれる場合は、code-design-review のアーキテクチャゲートに従ってください。

非ブロッキング（推奨事項として記載し、ブロックしない）：

• 緩和策がすでに講じられている低リスク項目。
• 正確性や構造に影響しないスタイル上の好み。
• 後のイテレーションに先送りできるパフォーマンス改善（構造的なものではない場合）。
• 構造や変更の波及への影響を伴わない、スタイルレベルの洗練。
• 返済計画を伴う、意図的に文書化された技術的負債（劣るアーキテクチャを明示的に受け入れる場合を含む）。

フレームワーク固有のしきい値を含む、ブロッキング／非ブロッキングの基準全体については、reference.md を参照してください。

出力

次の構成でレビュー報告書を作成します。

【Solution review report】
- Subject: [solution name / summary]
- Reversibility: [one-way door / two-way door] → review depth: [maximum / standard]
- Core dimensions:
  1. Effectiveness: ✅/❌ [reasoning]
  2. Side effects & risks: ✅/❌ [reasoning]
  3. Feasibility: ✅/❌ [reasoning]
  4. Spec compliance: ✅/❌ [reasoning]
- Strategic dimensions (by reversibility depth):
  5. Reversibility calibration: [classification + rationale]
  6. Failure-mode analysis: ✅/❌/N/A [top failure modes + RPN]
  7. Operability: ✅/❌/N/A [monitoring/rollback/on-call assessment]
  8. Cost vs value: ✅/❌/N/A [cost-value assessment]
  9. Team cognitive fit: ✅/❌/N/A [team fit assessment]
- Issue list: [#] [description] [severity: blocking/non-blocking]
- Verdict: ✅ pass / ❌ fail
- [On ❌] Optimization guidance: [per-issue improvement direction]

アンチパターン（禁止事項）

1. コード以外の解決策で戦略的な観点を省略すること — 設定／プロセス／ツールの変更も、一方向の変更になり得ます（移行の実行は元に戻せず、プロセス変更は取り消しが困難です）。検討の深さを決めるのは解決策の種類ではなく、可逆性です。
2. 曖昧なリスク評価 — 障害モード、重大度、発生可能性を列挙せずに「何らかのリスクがあるかもしれない」と述べること。勘に頼った記述ではなく、ディメンション6のFMEA構造を使用してください。