あなたがプロダクトを完成させた。
LPも作った。
フォーム営業で最初のアポも取れた。——だが、毎月500件フォームを送り続けないとリードが枯れる。
この「自転車操業」から抜け出す方法はないのか。
ある。
「作る過程を見せる」だけでいい。
Build in Public(ビルド・イン・パブリック)とは、プロダクトの開発過程・売上の数字・意思決定の裏側・失敗の記録をリアルタイムでSNSに公開しながら事業を進めるスタイルだ。
海外のIndie Hacker(一人起業家)コミュニティでは、もはや常識となった手法で、広告費ゼロで「信頼」「認知」「初期ユーザー」を同時に獲得できる。
FeedbackPandaの創業者Arvid Kahlは、広告を一切使わず、XとブログだけでMRR $55,000を達成した。
Polsiaの創業者はBuild in Publicを始めた瞬間が「最大の転換点だった」と明言している。
Build in Publicを実践するSaaS創業者は、そうでない創業者と比べてオーディエンス成長速度が3倍というデータもある。
しかし日本のBtoBでは、これを体系的にやっている人がほとんどいない。
つまり今始めれば、先行者優位が取れる。
本記事は、特に「営業出身の一人起業家」に向けて、Build in Publicの始め方から運用法、リスク管理までを完全ガイドとして書く。
前回の記事でBuild in Publicの概要に触れた。 まだ読んでいない方はあわせてどうぞ。 → 営業部長がAIでプロダクトを作り、一人で売り始めるための実践ガイド
Build in Publicとは何か——30秒で分かる定義
「完成品をドン!と出す」のではなく、「作っている途中を見せ続ける」。
これがBuild in Publicの本質だ。
具体的には、SNS(X、LinkedIn等)やブログで以下のような情報を継続的に発信する。
- 今週追加した機能とその理由
- ユーザー数やMRRの推移
- マーケティング施策の結果(フォーム営業500件→反応8件、等)
- 失敗した施策と、そこから得た学び
- プロダクトの方向性を変えた意思決定の裏側
なぜこれが「営業」になるのか。
人はストーリーに感情移入する生き物だからだ。
あなたのプロダクト開発の「物語」を追いかけたフォロワーは、完成品を初めて見た赤の他人とはまったく違う心理状態にある。
彼らは応援者であり、潜在ユーザーであり、最も信頼してくれる見込み客だ。
起源と代表事例
| 年 | 企業/個人 | やったこと |
|---|---|---|
| 2013年 | Buffer | 社員の給与・売上・株式オプションまですべて公開する「Radical Transparency」を実践。ユーザーの忠誠度が大幅に向上 |
| 2014年 | Ghost | 非営利OSSとして売上とトラフィックを完全公開 |
| 2018年 | Pieter Levels | Nomad List / Remote OKの売上・トラフィックをオープンページで公開。Xフォロワー13万人超に成長。「Open Startupsの父」と呼ばれる |
| 2025年 | Polsia | ソロファウンダーがBuild in Publicでローンチ3ヶ月で月商$500Kに到達 |
なぜ「営業出身者」にBuild in Publicが最適なのか
ここが本記事の核心だ。
Build in Publicは一般に「エンジニアの文化」だと思われている。
だが実は、営業出身者のほうが圧倒的に有利だ。
営業スキルがそのまま武器になる3つの理由
理由1:「課題の言語化」ができる
エンジニア起業家のBuild in Public投稿は「〇〇のAPIを統合した」「レスポンス速度を200ms改善した」といった技術的な内容になりがちだ。
これは同業のエンジニアには響くが、ターゲットユーザー(=非エンジニアの営業マネージャーや経営者)には刺さらない。
あなたは15年間、顧客の課題をヒアリングし、提案書で言語化し、プレゼンで伝えてきた。
その力があれば「API統合しました」を「これで営業事務の月10時間の手作業がゼロになります」と翻訳できる。
この「翻訳力」が、Build in Publicの発信品質を決定的に変える。
理由2:「相手の反応を見て調整する」のが習慣になっている
営業は本質的に「相手の反応を見ながらトークを調整するリアルタイムゲーム」だ。
Build in Publicも同じで、投稿への反応(いいね数、リプライの内容、クリック率)を見ながら「この話題は刺さる」「この角度はスルーされる」と即座に軌道修正する。
PDCAを回す速度が、エンジニア出身者よりも桁違いに速い。
理由3:「人に聞く」ことへの抵抗がない
Build in Publicで最も効果的な投稿は「〇〇で悩んでいるのですが、皆さんはどうしていますか?」という質問形式だ。
営業出身者にとって、人に質問を投げかけることは呼吸するように自然なはず。エンジニアは「聞く前に自分で調べる」文化があるため、ここで心理的ブレーキがかかりやすい。
Build in Publicの5つのメリット
| メリット | 一人起業家にとっての意味 | |
|---|---|---|
| 1 | 信頼構築 | 無名プロダクト最大のボトルネック「信用の不在」をゼロコストで解消。失敗も含めて裏側を見せると「この人は本物だ」と伝わる |
| 2 | 早期フィードバック | フォロワーが「無料のプロダクトアドバイザー」になる。機能の要望、バグ報告、価格設計のヒントがリプライで飛んでくる |
| 3 | コミュニティ形成 | ストーリーを追いかけるフォロワーが「応援者→初期ユーザー→有料顧客→紹介者」へ段階的に昇格。広告では作れない「共犯者意識」 |
| 4 | コンテンツ資産の蓄積 | 毎日の投稿がそのまま「検索可能なアーカイブ」に。半年前の投稿が新フォロワーに発見されても有効——賞味期限がないマーケティング |
| 5 | 協業・採用・資金調達の呼び水 | 「この人と一緒にやりたい」「この会社に投資したい」が自然発生する |
何を共有して、何を共有しないか——線引きのフレームワーク
Build in Publicは「すべてを見せる」ことではない。透明性はスペクトラム(段階)であり、自分のフェーズと商材に合ったレベルを選ぶべきだ。
共有OK(推奨)
- プロダクトの変化: 新機能、UI改善、削除した機能とその理由
- 数字のトレンド: MRRの成長率、ユーザー数の推移、フォーム営業の送信数と反応率
- マイルストーン: 最初の1ユーザー、初の有料顧客、MRR 1万円突破
- 失敗と学び: この業種には刺さらなかった、この施策はROIが合わなかった
- 意思決定のプロセス: なぜこの機能を作った/捨てた、なぜこの価格にした
- 使っているツール・技術スタック: 開発環境、営業ツール、AI活用法
- 営業のリアル: フォーム営業の反応率、商談のビフォーアフター
慎重に / 非公開推奨
- 詳細なユニットエコノミクス: CAC・LTVの具体的な金額(競合の参入判断材料になる)
- 顧客名・顧客の個人情報: 事例掲載は必ず許諾を取ってから
- セキュリティの実装詳細
- 未リリース機能の詳細ロードマップ: 出してから語る。出す前に語ると競合にコピーされる
- 競争優位の「How」の核心: 独自のアルゴリズムやデータソースの詳細
覚えておくべきルール:
「WhyとWhatはオープンに。Howは選択的に。」
競合は、あなたの「なぜその判断をしたか」や「何が起きたか」は見ても、そこから得た顧客の信頼やインサイトはコピーできない。
週3投稿テンプレ——営業出身者が無理なく回せるスケジュール
毎日投稿する必要はない。
週3〜5投稿で十分。質>量。
投稿に1日30分以上かけるな——がIndie Hackerの鉄則だ。
| 曜日 | 投稿タイプ | 具体例 | なぜ効くのか |
|---|---|---|---|
| 月曜 | 先週の数字振り返り | 「先週:フォーム営業500件→反応12件→デモ3件→有料転換1件。反応率が先々週の2倍。変えたのは文面の冒頭2行だけ。」 | 具体的な数字がフォロワーの共感と学びを生む。「この人は本当にやっている」という信頼の証明 |
| 水曜 | 学び・失敗の共有(スレッド形式) | 「飲食業にフォーム営業200件送って反応ゼロだった話。原因を分析すると…(5投稿のスレッド)」 | スレッドはシングル投稿の3倍エンゲージメント。水曜はX上で最も反応が高い曜日。失敗談は成功談の2倍シェアされる |
| 金曜 | プロダクトのビフォーアフター | 「ユーザーの一言で追加した機能。Before→After。開発4時間。これで月10時間の手作業が消える。」 | スクショ付きの具体的な変化が「このプロダクト、進化してるな」という印象を作る |
追加オプション(余裕があれば)
- 火曜: 業界への意見・ポジション表明(「営業出身の自分がAIでプロダクトを作って気づいたこと」系)
- 木曜: 他のBuild in Public実践者との交流(引用リポスト+自分の学びを添える)
- 週末: 1週間のリプライにまとめて返信。他のファウンダーの投稿にいいね・コメント
各投稿に必ず入れるべき1つの要素
「質問」を1つ入れる。
「皆さんはどうしていますか?」
「同じ経験ある方いますか?」
「この判断、間違ってたら教えてください」——こうした質問がリプライを呼び、リプライがアルゴリズムに評価され、投稿がより多くの人に表示される。
営業出身者なら、商談の場で質問を投げかけるのは日常動作だ。
それをSNSに転用するだけでいい。
プラットフォーム戦略——LinkedInかXか
| プラットフォーム | 向いている場面 | 営業出身者への相性 |
|---|---|---|
| ターゲット顧客(営業マネージャー・経営者)への直接リーチ。 BtoBの長文投稿が伸びやすい | ◎ 最優先。日本のBtoB決裁者が日常的に見ているSNSはLinkedInとX。LinkedInは投稿の競合が少なくエンゲージメント率が高い | |
| X(旧Twitter) | スタートアップ・エンジニア・Indie Hacker界隈への認知拡大。#buildinpublic コミュニティとの接続 | ◎ IT/SaaS系の商材なら並行運用。短文×高頻度の文化に慣れれば強力 |
| note | 日本語圏での長文コンテンツ。 SEO効果も期待できる | ○ 週1の振り返り記事に最適。 XやLinkedInの投稿を週末にまとめてnote記事にする「再利用」が効率的 |
営業出身者へのおすすめ:LinkedIn+Xの2軸運用。
- LinkedIn = ターゲット顧客(営業マネージャー・経営者)への信頼構築+リード獲得
- X = 起業家コミュニティでの認知拡大+Build in Public仲間との交流
同じネタを両方に投稿してOK。
ただしLinkedInは長文・ストーリー調、Xは短文・データ重視とトーンを微調整する。
BtoBで効くBuild in Public——「個人ブランド趣味」ではなく「営業の仕組み」にする
ここが最も重要なセクションだ。
Build in Publicの失敗パターンで最も多いのは、「いいね集め」が目的化し、肝心の顧客獲得につながらないケースだ。
売上のスクショを貼って承認欲求を満たすだけの「Metrics Theater(数字の劇場)」に陥る。
BtoBでBuild in Publicを機能させるには、「投稿→信頼→問い合わせ→商談」の導線を設計する必要がある。
これは営業出身者がまさに得意とする「パイプライン設計」そのものだ。
導線設計の具体例
① 月曜の数字投稿「フォーム営業の反応率データ」
↓ (この投稿にターゲット業種の営業マネージャーが反応)
② リプライで会話が始まる
↓
③ DMで「もしよければプロダクトのβ版、試してみませんか?」
↓
④ 無料トライアル開始
↓
⑤ 1週間後にヒアリング電話(ここは営業スキル全開)
↓
⑥ 有料転換
ポイントは②→③の自然な流れ。
Build in Publicの投稿にリプライしてきた人は、すでに「あなたの活動に興味がある」シグナルを出している。
これは展示会で名刺交換した相手と同じか、それ以上に温かいリードだ。
営業出身者なら、この温度感を見逃すはずがない。
「Build in Publicが営業プロセスの前半を代替する」
海外のBtoB SaaS事例では、Build in Publicを続けた結果、見込み客が商談の初回から「基本的な信頼性の質問」をスキップし、いきなり「フィット確認」から入るようになったケースがある。
つまり、通常の営業では——
①認知 → ②信頼構築 → ③課題ヒアリング → ④提案 → ⑤クロージング
——というプロセスの①と②をBuild in Publicが自動で済ませてくれる。
商談の場では③から始められる。営業出身者にとって、これがどれほど効率的かは説明不要だろう。
リスクと「やめどき」——永久にやるものではない
Build in Publicは万能ではない。
リスクと、いつ「透明性のレベルを下げるべきか」を正直に整理する。
3つのリスク
| リスク | 具体的な症状 | 対策 |
|---|---|---|
| 競合に情報を与える | 競合がこちらの施策の成果を見て同じことをやり始める | 「WhyとWhat」はオープンに。「How」の核心は伏せる。未リリース機能は出してから語る |
| いいね中毒 | 売上スクショのバズを追いかけて、プロダクト改善や顧客対応が疎かになる | 月1回「Build in Public経由の問い合わせ件数」をKPIとして計測。いいね数はKPIにしない |
| 発信疲れ | 投稿が義務化し、開発時間を圧迫。楽しくなくなる | 週3投稿でOK。1投稿に30分以上かけない。疲れたら頻度を落とす。質>量 |
「やめどき」の3つのシグナル
実際にBuild in Publicを実践した企業の中には、途中で数字の公開をやめたケースもある。
BufferやTransistorがその代表だ。
シグナル1:競合がこちらのデータを使って意思決定している形跡がある
こちらの価格変更や施策の反応率を見て、競合が同様の施策を即座に打ってきた場合、情報を出しすぎている。
シグナル2:「数字公開のプレッシャー」で意思決定が歪み始めた
「MRRが下がったことを公開したくないから、この施策はやめよう」——こういう判断が出てきたら赤信号。
シグナル3:フォロワーは増えたが、顧客は増えていない
Build in Publicが「エンターテインメント」化し、ビジネスの実態とかい離し始めたサイン。
対策はシンプル。
Build in Publicは「永久にフルオープン」で続けるものではない。
フェーズに応じて透明性のレベルを調整すればいい。
初期は売上の生数字まで公開し、軌道に乗ったら「成長率」や「運用指標」に切り替える。
段階的に「何を見せるか」を進化させていくのが正しい運用だ。
日本市場はブルーオーシャン——今始める理由
最後に、日本でBuild in Publicを始める「今」の優位性を語っておきたい。
英語圏では #buildinpublic は飽和に近い。
X上のハッシュタグは毎日数千件の投稿で溢れ、単に数字を公開するだけでは埋もれるフェーズに入っている。
一方、日本語圏では——
- #buildinpublic をつけて日本語で投稿している人はごく少数
- 日本の個人開発者がnoteやZennで開発日記を書く文化はあるが、売上の数字を公開するレベルの透明性を実践している人は一部
- LinkedInの日本語BtoB投稿は、エンゲージメント率が英語圏より圧倒的に高い(競合投稿が少ないため)
つまり、日本語でBuild in Publicを「営業出身者の視点」でやる人は、現時点でほぼ存在しない。
「営業部長だった自分がAIでプロダクトを作って独立した話」——このストーリーを日本語のLinkedInとXで発信し続ければ、同じ境遇の人(AIでプロダクトを作り始めた営業経験者)は確実に反応する。
そしてその「同じ境遇の人」は、2026年にどんどん増えている。
あなたが発信する「苦闘のリアル」は、明日の彼らにとっての「教科書」になる。
教科書を書いた人は、その領域の第一人者になる。
まとめ:Build in Publicは「営業の仕組み化」である
ここまで読んで気づいただろう。
Build in Publicは「エンジニアの文化」でも「意識高い系の遊び」でもない。
Build in Publicは、営業プロセスの「認知→信頼構築」フェーズを、SNS投稿で自動化する仕組みだ。
前職では会社のブランドが「認知」を、導入実績が「信頼」を提供してくれた。
一人起業にはそれがない。
Build in Publicは、その空白をあなた個人のストーリーと透明性で埋める手法だ。
そして営業出身者には、この手法を最大限に活かすためのスキルセット——課題の言語化力、反応を見て調整する力、質問を投げかける力——がすでに揃っている。
Next Action
- 今日、X(またはLinkedIn)で「Build in Public 1投稿目」を出す。内容はこれだけでいい。
営業畑15年の自分が、AIでBtoBプロダクトを作って独立しました。
広告費ゼロ、月の持ち出し1万円以下で、
最初の10社を獲るまでの過程をリアルタイムで公開していきます。
#buildinpublic #一人起業
- 来週の月曜日に「先週の数字」を1投稿する。
- フォーム営業の送信数、反応数、デモ数。完璧な数字である必要はない。ゼロでもいい。「ゼロだった」と書くこと自体がコンテンツになる。
- 2週間続けたら、このテンプレに沿って「週3投稿」のリズムを作る。
- 月曜=数字、水曜=学び、金曜=プロダクト。これだけ。
営業のプロであるあなたなら分かるはずだ。
最初の一歩を踏み出した人だけが、次の景色を見られる。
完璧な戦略を練ってから動くのではなく、動きながら戦略を修正する——それがあなたが15年の営業人生で身につけた「最強のスキル」だったはずだ。


コメント