review-the-work

作業をレビューする（セルフチェックのゲート）

それを書いた本人は、それが優れているかを判断するのに最も不向きです。これが創業者に届く前に、書き手であることをやめ、懐疑的な目で見てください。

これを使う場面： 重要な成果物を提示しようとしているとき、または創業者から「これは本当に良いのか？」と聞かれたときです。これはゲートであり、段階ではありません。直線的な手順の中には位置づけられません。どんな作業にも、そのたびに実行してください。

核となる考え方

何かを書き上げたばかりのエージェントは、それを提出したいというバイアスを持っています。そのバイアスによって、ありきたりで、もっともらしく、気づかれにくい誤りを含む仕事が、まだ見抜くための知識が十分でない創業者に届いてしまいます。そこで、2つの役割を分けます。書き手が草案を作り、別の視点で評価します。作ったからという理由で仕事を提示してはいけません。懐疑的な目に耐えたからこそ、提示するのです。

これを機能させる唯一のルールを取り入れてください。書き手は仕事を提出できますが、書き手が判定を下してはいけません。 意図的に役割を切り替えてください。懐疑的な開発者、忙しい購入者、こうしたものを100件見てきたレビュー担当者になり、市場に試される前に、問題を見つけようとしてください。

実行方法（エージェント向け）

• 提示する前に、表に出さずに実行してください。創業者に見せるのは判定と成果物であり、監査の全容ではありません。
• 判定は明確にしてください。PASS、または不合格となったチェック項目と、それぞれに対する具体的な修正を明記したREVISEです。「良さそうです」のような曖昧な判定は避けてください。
• 形式だけの承認はしないでください。 弱点が一つも見つからないなら、懐疑的な目で読めていません。PASSとする仕事でも、最も弱い点を示し、どこが脆弱なのかを創業者が把握できるようにしてください。
• 不合格になったら修正してゲートを再実行し、その後で提示してください。自分で直せたはずの問題一覧を創業者に渡してはいけません。

基準（すべてに適用）

• 大げさに言わず、具体的に。 「強力」「シームレス」「クラス最高」「プラットフォーム」といった表現は使いません。主張には必ず数値、名称、または証拠を添え、なければ削除します。
• 主役は開発者であり、製品ではありません。 創業者のツールが文の主役になっているなら、書き直してください。
• ブリーフにある実際のICPに語りかけます。「開発者」全般に向けてはいけません。誰にでも向けたメッセージは、誰にも届きません。
• 検証済みの事実に基づいています。 重要な前提のうち、まだ[assumption]であるものは、事実のように紛れ込ませず、明示してください。
• 外部の事実には実在するリンクを付けます。 コミュニティ、メンバー数、ローンチの結果、引用には、それぞれ実際に確認したリンクを付けてください。出典を示せない場合は削除するか、不明として示してください。創業者がその事実を信じて行動することになってしまう、捏造された事実は、このパックで最悪の失敗です。
• 懐疑的な開発者がすぐに誤りを証明できないこと。 開発者は主張を検証し、真実を見つけます。30秒で失敗するケースを見つけられるなら、合格ではありません。
• 人間らしい語り口。 人が書いたように読めること。エムダッシュや、AIらしい表現は使いません。

成果物別の具体的なチェック項目

一般的な基準を確認してから、該当するスキル独自のチェックリストを確認してください。

• ポジショニング／ストーリー（positioning-and-story）：解決策ではなく、問題から始まっています。敵役がいます。「どの競合も同じことを言えるのでは」というテストをクリアしています。
• バリュープロポジション（value-prop-that-converts）：禁止語がなく、実際に達成したい仕事を土台としており、開発者が自分の言葉で言い換えられます。
• ホームページ（the-homepage）：訪問しない購入者ではなく、訪問する開発者に向けて書かれています。最初の価値を得るまでの時間が明確です。
• ローンチ投稿（launch-it）：誠実で、売り込みがましくありません。製品ではなく、開発者の問題から始まっています。過大な主張で非難されることはありません。
• 価格設定（pricing）：推測した金額ではなく、価値を測る指標に基づいています。購入者が予算を管理する人に説明できます。
• 創業者主導の営業（founder-led-sales）：4つの要素からなる案件テストをクリアしています。好意的な無料ユーザーを購入者と取り違えていません。
• ブリーフ（start-here）：最も強い資産が先頭にあり、[validated]／[assumption] タグがそのまま残っていて、創業者自身の言葉で書かれています。
• 市場調査（research-the-market）：創業者が言わなかったことから始まっています。場は名前とリンクが示され、規模ではなく適合度で順位付けされ、セルフプロモーションのルールも記されています。記憶を頼りに補完したものはありません。
• ロードマップ（strategy-and-roadmap）：まず1行の診断から始まり、続いて調査で得られたこと、そして今／次／後が示されています。ブリーフを保存し直したものではなく、計画になっています。創業者に見せる際のテストは、読んで自分が伝えていなかった何かを学べるかどうかです。すべての施策が創業者自身の回答にたどり着くなら、不合格です。チャネルとローンチ施策では、カテゴリーではなく具体的な場を挙げています。

次の30分

• 最後に作成したもの（見出し、投稿、価格など）を取り上げ、作成者ではなく懐疑的な立場から上記の基準で確認します。
• その中で最も弱い主張を1つ特定します。証明できる内容に置き換えるか、削除します。
• それが最も依存している [assumption] を1つ見つけ、それを前提に公開しても安全か、それともまず talk-to-users で確認すべきか判断します。
• その後で初めて、実際の人に見せます。自分の確認を通らなかったものは、相手の確認も通りません。

---

実際の開発者向けツールのGTM経験をもとに、Adam Frankl（The Developer-Facing Startup）とJakub Czakon（markepear.dev）のフレームワークを取り入れています。 公開前に独立した人の目で確認してほしいですか？ それがまさに私の仕事です。LinkedIn からご連絡ください。