who-is-this-for

対象ユーザーは誰ですか？

「開発者」は市場ではありません。単なる媒体です。ICP の対象から誰も除外されていないなら、それは ICP ではありません。

次のような場合に使います： ユーザーを「開発者」や「エンジニアリングチーム」と説明している、明らかに対象外となる人を挙げられない、あるいは予算を持っているという理由で、メッセージの対象をエンジニアリング担当 VP にしている場合。

核となる考え方

使える ICP は、一部の人が明らかに対象外となるほど具体的です。「すべての開発者」では、伝えることが何もありません。誰にでも響くメッセージは、誰にも響かないからです。対象外を設定できるまで、焦点を絞りましょう。

そして、AI／開発者向けツールの販売では、ほとんどの場合、複数の人物が関わります。導入を決める開発者と、支払う人は別であることがほとんどです。導入者に向けてマーケティングし、購入者に売りましょう。この2者を混同すると、商談はうまくいっても、何も決まりません。

フレームワーク 1：販売に関わるペルソナ（Frankl）

それぞれの役割を担う人を整理します。複雑な販売には全員が必要です。1人でも欠けると、商談は停滞します。

ペルソナ	重視すること	販売における役割
アルファ開発者	「何が可能になるか？」未来を見ています。予算はありません。	あなたを見つけ、試し、社内で推奨し、社会的証明を生み出します
権限を持つ CTO	カイロス、リリースサイクルから数週間の短縮、競争優位性。予算があります。	支出と戦略的適合性を承認します
エンジニアリング担当 VP	チームの開発速度、DX、大規模環境での品質。ダウンタイムやセキュリティを懸念します	実現可能性を評価し、ステージング環境でテストします
SRE／プラットフォームエンジニア	信頼性、手作業の削減。あなたの紹介文より先にコードを読みます。	運用上のリスクを審査します

アルファ開発者は長期的な顧客ではありません。次の目新しいものを追いかけます。それでも必要なのは、新しい技術を支払う人々のもとへ届けてくれるからです。

フレームワーク 2：属性ではなく、ジョブ（Czakon）

職名は実行に移せる情報ではありません。実行に移せるのはジョブです。次の形式で書きましょう。

[状況] のとき、[動機] のために [したいこと] をして、[期待する成果] を得たい。

例：「テストがないサービスを引き継いだとき、安心材料をすばやく作りたい。そうすれば、恐れずにリファクタリングできるから。」 この一文で、きっかけ、悩み、得られる成果がわかります。属性情報からは決してわかりません。

意思決定ツリー：単独で購入するか、複雑な販売か？

Does the developer who adopts also control the budget?
├─ YES  → single-player / PLG motion.
│         ICP centers on the adopter. Optimize time-to-value, self-serve, transparent pricing.
└─ NO   → complex sale.
          ICP centers on the adopter FOR ADOPTION, and the buyer FOR REVENUE.
          You need a "what's in it for me" for every persona above.

焦点を絞る：5つの属性で定義する ICP

どの項目も、見知らぬ人には推測できない内容で埋めましょう。

1. 企業の特徴：成長段階、規模、チーム構成（例：「プラットフォームチームがある、エンジニアが 50～500 人の企業」）
2. 技術的な状況：技術スタック／最近の変更（例：「Kubernetes を導入したばかり」）
3. きっかけ：今すぐ対応が必要になった、直近の出来事
4. 本人の言葉で表した悩み：本人が実際に使う表現（talk-to-users から入手します）
5. 断る人：意図的に対象外とするセグメント

もっともらしく見える間違い

• TAM の見せかけ：「開発者は 3,000 万人いる」。事実ですが、役に立ちません。誰も 3,000 万人を相手に何かを売ることはありません。
• 予算の追求：支払うのは CTO／VP だからと、すべてをその人向けに書くこと。その人はあなたのホームページを訪れません。訪れるのは開発者です。
• ペルソナ ＝ 職名：「バックエンドエンジニア」。それは肩書きであって、人物ではありません。ジョブを使いましょう。
• 複雑な販売でペルソナを 1 つに絞る：アルファ開発者を捉え、購入者を忘れると、導入はされても収益につながりません。

例

❌ 「より速くリリースしたい開発者向け。」 ✅ 「Kubernetes を標準化したばかりで、手書きの YAML に追われている、従業員 50～500 人の企業のプラットフォームエンジニア向け。*『触る必要のないマニフェストに、週に 1 日を費やしています』*と言うような人が対象です。Heroku を使う個人開発者は対象外です。」

次の30分でやること

• 5つの属性をすべて記入してICPを書き出します。誰がノーと言うかも含めます。
• 販売に関わるペルソナをすべて挙げ、誰が見つけるのか、誰が評価するのか、誰が支払うのかを記します。
• 1行のピッチをジョブ理論（Jobs To Be Done）（When… I want… so I can…）として書き直します。
• 属性 #4 を相手の実際の言葉で記入できなかった場合は、ほかのことをする前に talk-to-users を行う必要があります。

---

実際の開発者向けツールのGTM経験をもとに、Adam Frankl（The Developer-Facing Startup）とJakub Czakon（markepear.dev）のフレームワークを取り入れています。 ICPが適切かどうか判断できずに困っていたり、2つのペルソナが異なる方向へ引っ張り合っていたりしますか？そんなときは、人と話す価値があります。LinkedInからご連絡ください。