evaluate-existing-solutions

既存ソリューションの評価

発明より再利用を優先することは意思決定の規律であり、あらゆる問題に依存関係が必要だというルールではありません。既存の機能と独自に構築する場合の基準案を、ライフサイクル全体の所有コストで比較します。適合し、全体的なリスクと仕組みの複雑さを軽減できる場合は、確立されたソリューションを優先します。証拠から、独自に構築するほうがより小規模で、安全で、制御しやすく、または差別化につながる選択だと判断できる場合は、独自の実装を優先します。

このスキルでは調査と意思決定を行います。パッケージのインストール、信頼できないコードの実行、アカウントの作成、調達の開始、ライセンスの受諾、サービスへのデータ送信、または別途権限を得ずに選択した案を実装することはありません。

外部調査の前に、references/evidence-and-currentness.md を読んでください。最終候補を比較する前に、references/evaluation-dimensions.md を読んでください。意思決定資料の骨子として、assets/solution-decision-template.md を使用してください。

適用範囲と調査の深さ

状況に応じて、次の3段階の調査を使い分けます。

1. 簡易事前確認 — 重要な汎用機能を独自に構築する案を提示する前に、リポジトリ内の既存機能と、標準・フレームワーク・プラットフォームのプリミティブを確認します。信頼できる代替案、または重要な所有判断がある場合に限り続行します。
2. デューデリジェンスのみ — ユーザーが指定した、まだ採用されていない重要な依存関係について、市場全体の比較を再開せず、正確なバージョンやプラン、互換性、保守状況、セキュリティ、ライセンス、来歴、ライフサイクルや実行時のリスク、既存環境との適合性を確認します。必須条件を満たさない場合はその点を明示し、それ以外の場合は指定された選択を尊重します。
3. 全面比較 — 影響が大きく、未解決の選択肢について、信頼できる既存の選択肢と、実質的な独自構築の基準案を比較し、意思決定案を作成します。

次のようなケースでは全面比較を行います。

• 長期的に使用する直接依存関係またはフレームワーク
• 認証、キュー、スケジューリング、検証、検索、可観測性、ストレージ、マイグレーション、フィーチャーフラグなどの汎用的な横断機能
• オープンソースアプリケーション、開発者向けツール、ビルドシステム、データベース、ランタイム、マネージドサービス、またはプラットフォーム機能
• 選択した独自の仕組みを、確立されたプリミティブに置き換える場合
• ライフサイクルコストに大きな影響がある、構築、購入、採用、適応、組み合わせ、延期、または何もしないという判断

ドメイン固有のポリシー、小規模で透明性の高いヘルパー、一度限りの接着コード、新たな仕組みを導入しない通常の修正やリファクタリング、またはプロジェクトがすでに保有するツールの通常利用には適用しないでください。find-skills はインストール可能なエージェントスキルを見つけるものであり、ソフトウェアライブラリ、ツール、アプリケーション、サービスを評価するものではありません。

運用上の取り決め

• 候補を探す前に、目的と必須制約を明確にします。動作がまだ曖昧な場合は、specification に戻ります。インストール済みの grill-me スキルが利用できる場合は、それを使って意思決定ツリーを検証してもかまいません。利用できない場合は、必須制約が明確になるまで、一度に1つずつ焦点を絞った質問をします。
• 外部検索の前に、リポジトリと既存の機能を調査します。
• 現在のバージョン、保守状況、セキュリティ、サポート、価格、ライセンスは変動するものとして扱います。候補の最新情報を確認し、モデルの記憶だけに頼らないでください。
• 主張の根拠には、一次技術情報を使用します。人気度やマーケティング情報は候補の特定には使えますが、選定の根拠にはできません。
• 比較には独自構築の基準案を含めます。採用が自動的に優れた選択となるわけではありません。
• 初期実装の労力だけでなく、連携用の接着コード、ラッパー、アップグレード、移行、セキュリティ対応、テスト、運用、サポート、離脱までを含む総所有コストを比較します。
• 影響度と可逆性に応じて調査の深さを調整します。必須条件の確認、または十分な証拠によって、それ以上調べても意思決定が変わる可能性が低くなった時点で終了します。
• 不確実性、確信度、証拠の日付、および推奨を変更する条件を記録します。

ワークフロー

1. 判断の枠組みを定める

以下を明確にします。

• 達成すべき業務、利用者と運用担当者、観測可能な成果。
• 必須の制約、希望事項、対象外とするもの。
• 想定する利用期間、規模、重要度、可逆性、判断責任者、納期、緊急度。
• 実行環境、言語、フレームワーク、デプロイ、データ、セキュリティ、プライバシー、アクセシビリティ、コンプライアンス、予算に関する制約。
• 影響範囲に見合った調査の深さ。

特定のソリューションに依存しないニーズと、魅力的な製品が使う用語を切り分けます。調査の開始後に候補の一つが要件を定義し直すことがないようにします。

2. まずローカルの選択肢と組み込みの選択肢を調べる

適用される指示、アーキテクチャ上の決定事項、進行中の計画、マニフェスト、ロックファイル、ワークスペース設定、関連コードを確認します。以下を特定します。

1. 再利用または拡張できる、既存リポジトリの機能。
2. 言語の標準ライブラリまたはオープン標準。
3. 既存のランタイム、フレームワーク、クラウド、ブラウザー、データベース、オペレーティングシステムのプリミティブ。
4. チームがすでに所有し、サポートしている依存関係とツール。

バージョン互換性、現在の使用状況、推移的な依存関係、運用上の慣例、ライセンスとセキュリティのポリシー、再利用によって一貫性のない別経路が生まれないかを確認します。ローカルで再利用する場合も適合性を示す根拠が必要です。古いコードが、存在するというだけで優先されるわけではありません。

3. 候補の分類を定義する

今回の判断に適した分類だけを含めます。

• 何もしない、または既存のローカル機能を再利用する。
• 標準、フレームワーク、プラットフォームのプリミティブ。
• 保守されているライブラリ。
• オープンソースのツールまたはアプリケーション。
• マネージドサービスまたは商用サービス。
• 既存の選択肢を少数組み合わせる、ラップする、または適応させる。
• 独自に実装する。

候補を無理に増やさないでください。代表的な最終候補を2、3個と独自実装を比較基準にすれば、十分な場合がほとんどです。人気順の長い一覧は作成しないでください。

4. 最新の外部情報を収集する

現在利用可能な外部候補はすべてウェブで調査します。必要に応じて、次の情報を優先します。

• 公式ドキュメント、標準、ソースリポジトリ、正式なパッケージレジストリ。
• 正確なリリース情報、変更履歴、サポート期間、互換性、EOL、移行に関するページ。
• 対象リポジトリの正確な LICENSE、SECURITY、ガバナンス、所有権、コントリビューションに関するファイル。
• ベンダーのSLA、料金、DPA、データ所在地、ポータビリティ、バックアップ、削除に関する規約。
• OSV、GHSA、ベンダーのアドバイザリ、関連する国のガイダンスなど、公式またはエコシステムのセキュリティアドバイザリ。
• パフォーマンスが判断を左右する場合は、ベンダーの主張より再現可能なベンチマーク。

確認したバージョンまたはサービス階層、エビデンスの日付、URL、判明した内容を記録します。検索結果のスニペット、スター数、ダウンロード数やインストール数、ブログのランキング、自動生成された比較サイト、単一の総合セキュリティスコアは、候補の発見に使う情報にとどめます。

最新の調査ができない場合は、ローカルキャッシュ、ロックファイル、同梱ドキュメント、ソースのみを使用します。外部の最新状況を未検証と明記し、判断を暫定とします。実装の前に再検証が必要です。

5. まずハード制約で候補を絞り、その後トレードオフを比較する

references/evaluation-dimensions.md を使用します。

ハード制約を満たさない候補は除外するか、信頼できる緩和策を明示します。その後、残った候補を定性的に比較します。判断を、重み付けした数値スコアであるかのように見せかけないでください。

推移的依存関係、統合コード、ホスト型コントロールプレーン、運用者のワークフロー、移行ブリッジ、フォールバック動作、そしてなお必要となる独自の接着コードまで含め、採用するシステム全体を評価します。小規模なパッケージでも大きな保守負担が生じることがあり、焦点を絞った独自モジュールのほうが、幅広いフレームワークを統合するより低コストになる場合もあります。

ライフサイクル全体の保守負担だけでなく、価値を得るまでの時間と機会費用も比較します。定常運用時の保守負担が魅力的な独自実装でも、提供の遅れ、学習リスク、労力の転用によってメリットが上回らなければ、採用すべきでない場合があります。また、既存の選択肢でも、統合や移行にかかる遅延が、焦点を絞った開発にかかる遅延を上回る場合は、採用すべきでないことがあります。独自機能を戦略的差別化と見なすのは、その機能を所有するだけの価値が本当にある場合に限ります。

最終的な判断を、次のいずれかに分類します。

• 採用 — 既存のソリューションを、設計されたとおりにおおむね使用します。
• 適応 — 1 つのソリューションを構成、拡張、フォーク、またはラップし、独自の変更点を明確に管理します。
• 組み合わせ — 相互補完的な少数の機能を組み合わせ、統合の責任者を明確にします。
• 構築 — 総合的なトレードオフがより優れているため、独自のベースラインを実装します。
• 延期 — 根拠またはタイミングが不十分なため、選択の余地を残し、次の判断トリガーを明示します。
• 何もしない — 現状で目的を満たしており、変更による保守負担が価値を上回ります。

6. 不確実性を安全に解消する

重要な不明点については、判断を変え得る最小限の適合性検証を提案します。一時的なスパイク、コントラクトテスト、互換性ビルド、代表的なベンチマーク、運用演習、ライセンス／セキュリティレビュー、または移行リハーサルなどが該当します。

• まず、検証する問い、成功／失敗の基準、代表的なワークロード、期間、破棄可能な成果物を定めます。
• 一時ディレクトリだけでなく、使い捨ての最小権限実行サンドボックスを使用します。ホームディレクトリやリポジトリのマウント、ネットワーク、認証情報、ホストサービスは、デフォルトで拒否します。使い捨ての入力のみをマウントし、例外は個別に明示して許可します。
• 権限付与と内容の検査を行わずに、信頼できないパッケージ、インストール後のスクリプト、コンテナー、バイナリ、リモートインストーラーをインストールまたは実行しないでください。
• エコシステムで可能な場合はライフサイクル／インストールスクリプトを無効にし、実行前に正確なアーティファクトと、利用可能なチェックサム／署名／来歴を確認します。許可したネットワーク、マウント、認証情報、権限の例外はすべて記録します。
• 明示的な許可と承認済みのデータ経路がない限り、候補サービスに秘密情報、個人データ、専有コード、本番環境のペイロードを送信しないでください。
• おもちゃのような API だけでなく、実際のバージョンとサポート対象の使い方をテストします。

適合性検証の根拠は不確実性を減らしますが、継続的な保守、セキュリティ、運用上の責任をなくすものではありません。

7. 所有権を決定してルーティングする

意思決定は assets/solution-decision-template.md を使用して記述します。エージェントが生成したすべての結果は proposed として開始されます。指名された意思決定オーナーのみがそれを承認でき、承認者と日付が記録されます。既存のストーリー、設計、またはアクティブな計画の慣例を使用してください。存在しない場合は、恒久的なドキュメントパスを勝手に作るのではなく、タイムスタンプ付きの一時ファイルを新規に作成します。明示的に承認された耐久性のある意思決定は、expectations を経てプロジェクトの既存の ADR 慣例へ移します。重大な提案には technical-writing を使用します。

採用または適応する場合:

• サポート対象の正確なバージョン/範囲またはサービスティア、および更新ポリシーを明記する。
• アップグレード、アドバイザリ、インシデント、更新、削除の責任者を明記する。
• 反射的にラップすることなく、最も狭く有用な依存関係の境界を定義する。
• ベンダーモデルをコードベースに漏らすのではなく、ドメインポリシーをローカルの言語で保つ。
• 終了パス、データエクスポートパス、および再評価のトリガーを記録する。

構築する場合:

• 既存の選択肢が明示的な制約または完全な所有権の観点でなぜ敗れたかを述べる。
• ドメイン上の利点と汎用的な配管作業を区別する。
• 今回所有することになるメカニズム、メンテナンスの約束、セキュリティ作業、および運用面の範囲を定める。
• オーダーメイド設計の内部でなお再利用される標準や小さなプリミティブがあれば特定する。

選択した実装をルーティングする:

• モジュールの責務と依存関係を隠蔽する契約: codebase-design;
• 公開プロトコルまたはチーム間の互換性: api-design;
• ソース/パッケージの配置と強制: structure-codebase;
• 選択したカスタム機構を純減で置き換える: reduce-system-complexity;
• デリバリーの順序付け: planning;
• 新規または変更された動作: 実装中の tdd、testing、refactoring、その後 PR 準備完了時に累積された変更に対して一度だけ mutation-testing;
• 最終的な重大な意思決定のレビュー: double-check.

再評価のトリガー

すべての耐久性のある意思決定は、いつ再検討すべきかを示すべきです。例えば:

• メジャーリリース、非推奨化、EOL、メンテナンスの鈍化、または互換性の破壊;
• セキュリティアドバイザリ、所有権/ガバナンスの変更、またはライセンスの変更;
• 価格、SLA、データレジデンシー、調達、またはプラットフォームポリシーの変更;
• 繰り返しの統合の苦痛、可観測性の欠如、信頼性インシデント、またはアップグレードの負担;
• 新たなスケール、レイテンシ、ポータビリティ、アクセシビリティ、またはコンプライアンスの要件;
• プラットフォームのプリミティブが、大幅に少ない所有権でその役割を満たすようになった。

完了チェック

• 候補の調査前に、役割とハード制約が判明していたか?
• リポジトリ、標準ライブラリ、フレームワーク、およびプラットフォームの機能が最初に確認されたか?
• すべての外部最終候補が、バージョン/ティアと日付を伴う最新の一次証拠によって裏付けられているか?
• オーダーメイドのベースラインが、 straw candidate ではなく真正なものか?
• 定性的なトレードオフの前にハードゲートが適用されたか?
• 比較に、推移的、運用上、セキュリティ、移行、および終了のコストが含まれているか?
• 人気度と集計スコアは、シグナルとしてのみ扱われているか?
• 推奨は調整済みで、可能な限り可逆的であり、何がそれを変えるかについて明示しているか?
• 実装は依然として別途承認され、適切なスペシャリストスキルを通じてルーティングされているか?
• 指名されたオーナーが明示的に承認しない限り、成果物は依然として proposed のままであり、却下されたすべての代替案に理由があるか?

手法の出典

このワークフローは、ローカルの「発明より再利用を優先する」原則と、依存関係管理、ライフサイクル、セキュリティ、および技術選定のガイダンスを統合したものです。出典マップと保持される限界については、references/evidence-and-currentness.md を参照してください。