melech-roi

ROI

核となる問い

すべてを一つのたとえで説明すると、こうなります。

蛇口から水が漏れています。修理案 A は家全体の配管を引き直し、その蛇口の水漏れを止めます。修理案 B は、その蛇口のパッキンを交換します。どちらも水漏れは直ります。しかし、いつか別の蛇口を修理するときに、今後のすべての配管工が家全体の新しい配管を理解しなければならなくなるのは、どちらか一方だけです。

これがすべてです。このスキルが毎回問いかけるのは、ただ一つです。

家全体の配管を引き直すのか、それともパッキンを交換するのか？

• パッキンの交換 — 漏れている箇所そのものに対する、局所的で範囲の限られた修正です。
• 家全体の配管の引き直し — 共通の境界、新たに永続化される状態、新しいライフサイクル、または広範な影響範囲を伴い、一か所の水漏れを直すためにその負担を引き受けることです。

melech-roi は、すでに存在するコードでも、まだコード化されていないアイデアでも、二つ目を一つ目に見せかけたものを見つけるためにあります。目の前にある解決策を評価するものであり、代替案を設計するものではありません。

配管のたとえが相手に伝わらない場合は、同じ問いを説明する日常的なたとえがほかに四つあります（荷造り、改修許可、工具箱、お直し）。references/analogies.md を参照してください。

評価する内容

便益 — 水漏れはどれほど現実的で深刻なのか：重大度、影響範囲（ユーザーや経路の数）、頻度、修正の持続性、戦略的価値。

負担 — この配管の引き直しは家のどの範囲に及ぶのか：影響を受ける共通の境界、新たに永続化される状態やライフサイクル、回帰のリスク、将来の保守担当者が学ばなければならない新しい概念、元に戻せるかどうか。

判定 — 負担は便益に見合っているのか、それとも一か所の水漏れのために家全体の配管を引き直しているのか。

評価の内訳 — 解決策が ROI を得た点と損なった点：問題の影響範囲と解決策の影響範囲、得られる価値、課されるコスト、最も大きな負担。

評価対象にできる情報源

• 既存の PR（差分、説明、議論）。
• ローカルの差分（ステージ済み／未ステージ、ブランチとベースの比較）。
• まだ会話で話し合われているだけのアイデアや方針 — まだ差分は存在しないため、確信度を低くし、前提は前提として明示します。

文脈から情報源を判断します。本当に曖昧な場合に限り、質問してください。

ワークフロー

1. 水漏れの内容を明確にします。 目指している実際の便益を一行で示します。便益自体が不明確または実証されていない場合は、確信度を低くし、不足している根拠を示します。便益を暗黙に作り出してはいけません。
2. 影響を受ける範囲をたどります。 コードの場合：共通モジュール、永続化される状態、公開契約、新しい依存関係、呼び出し箇所、概念。アイデアの場合：実装した際に何に手を加える必要があるか。
3. 同じ単位で影響範囲を比較します。 問題を経験する対象と、解決策の負担を負う対象を並べて示します。経路、呼び出し元、ユーザー、ジョブ、レコード、または根拠のある別の単位を使います。精度を装うよりも unknown を使ってください。
4. 評価の内訳を項目ごとに示します。 得られる具体的な価値と、課される恒久的なコストを列挙します。コストの重大度を LOW、MEDIUM、HIGH で示します。
5. 最も大きな負担を特定します。 不均衡の最も明確な原因を一つ示すか、広い影響範囲が正当化される理由を説明します。
6. 現在の解決策を評価します。 スコアが示すのは比例性であり、開発者が想像上の完璧な実装にどれだけ近づいたかではありません。
7. 既存の候補だけを順位付けします。 PR や議論に具体的な解決策が複数すでに含まれている場合は、それらを評価して順位付けします。順位付けを完成させるために、代替案を作り出してはいけません。
8. 評価の内訳を出力します。 表示形式の規約に従い、references/output-examples.md の例を適宜調整してください。

出力形式

デフォルトの出力は、次の項目を並べたレシートです。

1. ソリューション名；
2. ROI スコアと評価；
3. すでに 2 つ以上のソリューションが挙げられている場合に限り、順位；
4. 比較可能な単位で示した問題の到達範囲とソリューションの到達範囲のバー；
5. 得られる価値；
6. 重大度を添えたコスト；
7. 最大のコスト；
8. 現在のソリューションについての一文の評価。

レシートは診断を行うものであり、解決策を指示するものではありません。代替設計や改善計画、「代わりにこれをしてください」というセクションは追加しないでください。

評価は一貫して次のように解釈します。

• A（85–100）： 負担は明らかにメリットに見合っています。
• B（70–84）： 価値はありますが、実際のコストも伴います。
• C（55–69）： 機能していますが、到達範囲または複雑さに無視できない不釣り合いがあります。
• D（40–54）： 負担が、実証されたメリットを上回っています。
• F（0–39）： 著しく不釣り合い、または大部分が裏付けられていません。

評価の境界に近い場合に限り、位置を表すために + または − を使います。開発者が 100 に達する必要はありません。評価が示すのは、このソリューションが釣り合っているかどうかです。理由は項目別のコストで説明します。

結果を出力する前に、references/output-examples.md を読んでください。ここには、不釣り合いなケース、妥当なケース、運用コストの高いケース、順位付けしたケース、確信度の低いケースの例があります。

他のスキルとの境界

• melech-distill-need — メリットそのものが疑わしい場合に、問題が実在するかを確かめます。
• melech-8020 — melech-roi が不釣り合いを診断した後、より低コストな形を設計します。melech-roi 自体はその形を提案しません。
• melech-tidy — melech-roi が既存の diff を評価した後、適応的な diff の削減（不要な残骸の除去、接合部の影響範囲の縮小、プロンプトの肥大化の抑制）を実行します。melech-roi は評価し、melech-tidy は変更します。
• melech-challenge — 未解決の問いを通じて、方向性全体をストレステストします。melech-roi が問うのは、より限定的な問いです。つまり、変更対象の範囲がメリットに見合っているかどうかです。

一般的な順序：melech-distill-need → melech-roi → melech-8020 / melech-tidy。

すること／しないこと

すること： 「1 つの送信経路」と「47 のリクエスト経路」を並べて示し、共通ミドルウェア、永続化された状態、クリーンアップのライフサイクルをコストとして項目別に記載します。

しないこと： ROI がどこで失われたかを説明するレシートなしに、「ROI：58%」だけを示します。

すること： 「このバグはデータを送信するすべてのエントリーポイントで発生します。共通の修正が、ここでは本当に共通のメリットに見合っています。これは過剰な対応ではありません。進めてください。」

しないこと： 共通コードに触れるという理由だけで、本当にシステム全体に及ぶ修正を無理に低く評価します。

すること： まだコード化されていない文字起こし上のアイデアについて、「これはまだ方向性であり、diff ではありません。確信度は低めです。この提案によって共有サービスに恒常的に生じるコストは、メリットを受けるワークフローの数よりも、根拠が明確です。」

しないこと： 根拠にない正確な到達範囲の数、候補となるソリューション、代替設計を作り上げます。