Build in Publicとは？開発過程を公開して顧客を増やす起業手法を解説

事業づくりの過程を公開しながら、初期顧客やファンを集める発信手法

近年、「Build in Public（ビルド・イン・パブリック）」と言われる考え方を耳にした方も多いかもしれません。
しかし、中には「知らない」「仕組みをよく理解できていない」と考える人もいるでしょう。
Build in Publicは、ここ数年で海外の個人開発者やスタートアップといった界隈で当たり前になりつつある手法です。
プロダクトにおける過程や思考プロセスなどを外部に隠さずに公開していくスタイルを指します。

今回は、そんなBuild in Publicについて概要を解説すると共に、注目されている理由やメリット、向いている人や事業、公開する内容などを紹介していきます。
Build in Publicを始めたいと考えている人や内容を理解したい人は、ぜひ参考にしてみてください。

Build in Public（ビルド・イン・パブリック）とは

まずは、Build in Publicとはどういった考え方、手法なのか概要を解説していきます。

商品・サービスを作る過程を公開する

Build in Public（ビルド・イン・パブリック）とは、アプリやサービス、ビジネスなどのプロダクトを開発する課程や自分の思考プロセス、失敗談などを、ブログやSNSを通じて外部に隠さずに公開していくスタイルのことを言います。
開発状況や技術的な意思決定、売上の推移などを包み隠さず透明性を持って共有することで、潜在顧客との信頼関係を構築しながら、尚且つコミュニティにおいてフィードバックを得られる特徴があります。

完成してからPRする従来型との違い

これまでの企業活動では、製品やサービスは、ある程度完成してからPRすることが一般的でした。
しかし、Build in Publicでは開発の途中段階から情報を発信し、プロダクトが成長していく過程を公開しています。
主な違いは以下の通りです。

従来型では完璧な状態を消費者に対して見せることで信頼を得ています。
Build in Publicでは未完成の製品やサービスを開発段階から公開し、且つ試行錯誤している部分も見せることで共感や応援を獲得していくため、売り手側の人柄に対するファンが付きやすい点が大きな違いです。

海外のスタートアップ・個人開発者などで広がった背景

Build in Publicが海外のスタートアップや個人開発者の間で広がりを見せた背景には第一にSNSやインターネットの発展が考えられます。
かつては、企業が情報発信するためにはメディアや広告の利用が一般的でした。しかし、現代においては個人でもSNSを通じて世界中に情報を発信できる時代です。
この環境の変化によって、開発者自身がプロダクトの進捗や開発途中での学びを発信することが一般的となってきました。

また、完璧にデザインされている広告やプロモーションに違和感を抱いてしまうユーザーも中にはいます。
そんな中で、製品やサービスが誕生するまでのストーリーや失敗談、売上などを隠さずに公開する透明性があることで、ユーザー側からの信頼を獲得しやすくなった心理的背景も広がりをみせた要因の1つであると考えられます。

起業でBuild in Publicが注目されている理由・メリット

企業でBuild in Publicが注目されている理由やメリットは以下の通りです。それぞれ具体的に解説していきます。

サービス完成前から見込み客を集められる

起業でBuild in Publicが注目される最大の理由が「サービス完成前から見込み客を集められる」という点です。
これまでは「完成してから売る」という手法が一般的でした。しかし、時間をかけて良い製品やサービスを作ったとしても、誰も気づいてくれない可能性があります。
広告費を潤沢に使えない初期のスタートアップが、無名の状態で瞬時に大規模な認知を獲得するのは難しいです。

しかし、Build in Publicであれば、プロダクトが完成する前の段階から公開していくため、「一緒に育てている」という共感や愛着を醸成できます。
「応援したい」「この人が作る商品なら面白そうだし利用したい」という思いを持つ人も生まれるため、リリースする前の段階からファンを作ることが可能です。

ユーザーの反応を商品開発に反映できる

起業の失敗で多い要因として「市場が求めていないものを作ってしまう」という点があります。
ニーズのない製品やサービスを提供しても、誰も興味を持ってくれません。売上がなければ経営に大きな影響を与え、存続が難しくなってしまいます。
起業直後からの危機を防ぐためにも、需要のある製品やサービスを提供することが大切です。

Build in Publicの場合、制作段階でユーザーに質問ができます。
「この機能を追加したいけどどう思う？」「こういった機能は必要？」などと質問を投げかけることで、「すごく良い発想だと思う」「期待してる」といった共感の声もあれば、「こっちの機能の方が使いやすい」「わかりにくいからこうした方がいいのでは？」といった指摘をしてくれるケースもあります。
ユーザの生の声やアドバイスは、高価な市場調査よりも精度が高いと考えられます。
失敗やリスクを防げる点がBuild in Publicのメリットです。

起業家自身のファンやコミュニティを作れる

開発段階からブログやSNSを通じてユーザーとコミュニケーションを取れるため、起業家自身のファンを形成しやすい点もメリットです。
プロダクトの成否に関わらず、これまでに起業家が挑戦している姿を見ていたユーザーは「試行錯誤する姿に感動した」「次にどんなものを作るのか気になる」「応援したい」といった気持ちになりやすいです。
その結果、万が一最初のサービスが終了したとしてもファンがいるため、次につながる資産を形成できます。

また、ブログやSNSが盛り上がると、自然とユーザー同士のコミュニティが形成されます。
ユーザー同士で情報を交換したり、使い方を教え合ったりなど、自走する空間が生まれ、愛着がより深まりやすいです。

広告費をかけずに認知を広げられる可能性がある

Build in Publicは広告費をかけずに注目を集められる可能性があります。
初期のスタートアップや個人開発者にとって、マーケティング予算の確保は難しいケースもあります。

しかし、開発段階から様々なことを公開していくBuild in Publicは、共感や好奇心を呼びやすく、自然な拡散を生み出しやすい点が特徴です。
興味を持つユーザーが多くなればなるほど、拡散されていくため、広告費をかけずとも認知拡大につながる点は大きなメリットとなります。

Build in Publicが向いている人・事業

Build in Publicが向いているケースと導入を慎重に考えたいケースをそれぞれ紹介していきます。

Build in Publicが向いているケース

導入が向いている人や事業の特徴は以下の通りです。

・共感や応援を巻き込むのが好きな人
良いものを作るだけではなく、「この人の姿勢を応援したい」「一緒にこのサービスを育てたい」というファンやサポーターを作る過程を楽しめる人にBuild in Publicは向いています。

・失敗や試行錯誤をオープンにできる人
中には「完璧な自分を見せたい」「悩んでいる姿を見せたくない」という考えを持つ人もいるでしょう。
その場合、途中で発信をしていくのが苦痛になるため、「こんな失敗をしてしまった！」「この部分に悩んでいる」などと、自分の気持ちを他人に対して見せることができます。
泥臭いプロセスもネタや学びとして楽しめる人の方がBuild in Publicが向いていると言えます。

・需要があるかわからない事業
作っている段階や作り始める前からアイデアを公開できるため、需要をある程度わかってから製品やサービスをリリースできる点がBuild in Publicの強みです。
そのため、見込み客の反応を確かめながら軌道修正できる事業にBuild in Publicは向いていると考えられます。

導入を慎重に検討したいケース

導入を慎重に考えるべき人や事業の特徴は以下の通りです。

・開発や作業だけに集中したい人
日々の進捗を言語化してSNSやブログなどで小まめに発信し続けることだけでも苦労する人は多いです。
そのため、「作るだけで精いっぱい」「発信している余裕がない」といった人は、Build in Publicは向いていないと言えます。

・競合優位性が特許前の技術や模倣されやすさにある事業
独自のコア技術やまだ誰も思いついていないアイデアなど、模倣された瞬間に優位性が消えてしまうビジネスモデルの場合は、開発過程を細かく公開すると、競合に真似をされるリスクがあります。

・ステークホルダーが多く、情報管理が厳格な事業
企業の機密情報やコンプライアンス、株主やクライアントへの配慮が必要なプロジェクトでは、個人的な裁量で開発の裏側を発信することは、ルール違反や信用失墜に直結するので注意が必要です。

Build in Publicでは何を公開する？

Build in Publicで何を公開するのかは、プロダクトのフェーズや内容によって様々ですが、主に以下の5つの内容を公開するケースが多い傾向です。

開発における全ての段階をリアルタイムでさらけ出す必要はありません。
独自技術や詳細な戦略、セキュリティに関わるデータや個人のプライバシーを侵害する内容も、もちろん避けましょう。

Build in Publicの始め方

ここからは、Build in Publicを導入する際の手順を紹介していきます。

発信の目的と想定顧客を決める

Build in Publicを成功させるためにも重要な土台となるのが「発信の目的」と「想定顧客」の2つを決めることです。
この2つが曖昧なままだと、ただの日記になってしまいます。発信をする目的の具体例としては以下の通りです。

• 初期ユーザーやベータ版のテスターを集めたい
• 開発のモチベーションを保ちたい
• 投資家や協業パートナーに存在を知ってほしい

また、「誰に発信するのか」想定顧客を具体的に決めることも大切です。具体的なペルソナをイメージし、その人に伝えるよう発信内容を考えていってください。

想定顧客が利用しているSNS・媒体を決める

次に、情報を発信するプラットフォームを決めます。
前述したステップの「想定顧客」を軸にして、ターゲット層が多くいるプラットフォームを選んでください。
例えば以下のようなプラットフォームです

• X：日々の進捗や短い気付き、バグの愚痴などを投稿しやすいです。
• ブログ：1週間のまとめやサービスを作ったストーリーなどを語る場として向いています。
• YouTube：開発風景のライブ配信や裏話の共有を音声で伝えられます。

作ろうとしているものと公開範囲を発信する

次に実際の発信のステップへと移ります。
その際、最初に「作ろうとしているもの」や「公開範囲」を発信しましょう。
「何を作っている人なのか」を一瞬でユーザーに伝えるためにも、サービス名を一言でいう他、どんな課題を解決したいのか、現在のフェーズなどを発信します。

また、Build in Publicでは全ての工程をさらけ出す必要はないため、あらかじめ「どの程度まで見せられるのか」を決めて発信しておくと、心理的な負担を減らすことに役立ちます。
例えば以下のような範囲での発信です。

【公開する範囲】

• 開発の進捗
• 日々の悩み
• 失敗したこと
• モチベーションの浮き沈み
• 売上やユーザー数

【未公開にする範囲】

• 企業の機密情報
• プライバシーに関わるデータ
• セキュリティ上公開できないAPIデータやソースコード
• プライベートな情報

進捗を公開・意見を集めて改善する

開発をただの実況中継で終わらせず、ユーザーを巻き込みながら共に良いものを作るためにも、進捗状況を公開することも重要です。
「今週はこの段階まで作った」「こんなミスをした」といった内容を週に数回公開することでユーザーの記憶にも残りやすくなります。

また、発信を続けていると自然とユーザーからの反応が返ってきます。
「AとBのどっちが良い？」「どれが見やすい？」といった質問を投げかけることで、プロダクトの質を高められます。
時には批判やダメ出しを受ける可能性もありますが、「リリース後に誰も使ってくれない」といった失敗を防ぐためにもアドバイスとしてしっかりと受け取ることが肝心です。

Build in Publicを行う際の注意点

最後にBuild in Publicを行う際の注意すべき点を紹介していきます。

公開する情報と非公開情報の線引きを決める

Build in Publicを安全かつ継続的に行うためにも、公開する情報と非公開にする情報をあらかじめ明確に決めておくことは重要です。
勢いのまま何でもさらけ出してしまうと、トラブルを招く危険性があります。

また、情報を出すか出さないかで迷った時のためにも、あらかじめ自分なりのルールを書き出しておくことも大切です。
例えば、以下のようなルールです。

• 画面のUIは出すけど、バックエンドの主要なアルゴリズムやAPIキーは絶対に映さない
• 売上は100円単位でオープンにするが、顧客のクレカ情報や詳細なユーザー属性は出さない
• 仕事に対する愚痴は言わず、試行錯誤のプロセスをユーモアを交えながらシェアする

顧客・取引先の機密情報や知的財産を公開しない

顧客や取引先の機密情報や知的財産の流出はBuild in Publicを行う上で最も重大なリスクの1つです。
オープンに発信することに夢中になるあまり、法律違反や契約違反、致命的なビジネスの損害を招かないためにも、機密情報や知的財産は公開しないようにしてください。

機密情報としては、テストユーザーの氏名やメールアドレスといった個人情報や受託開発の仕様書やチャットでのやり取りなどが当てはまります。
知的財産は、特許出願前の独自のアルゴリズムや競合に真似をされると優位性が消えるビジネスモデルの核心部分などです。

売上やユーザー数は目的と文脈を添えて公開する

売上やユーザー数などは、リアリティや説得力を与える内容ですが、時には思わぬ誤解を招いたり、期待外れになったりする可能性があります。
そのため、数字を公開する際には目的や文脈をセットで添えて公開することが重要です。

例えば、「今月の売上は○○万円でした」といった報告はただの自慢話に聞こえてしまいます。
しかし、「個人開発で月5万円を稼ぐという目標に向かっていた中、今月は○○万円を達成しました。先月から○％伸びており、その要因は△△です。」と細かく報告することで、「すごい」「頑張れ」といった感情を生み出せます。

発信すること自体が目的にならないようにする

発信すること自体が目的になってしまうと、プロダクトの開発が疎かになり、結果的にユーザー離れを引き起こす要因となります。
「今日は何を発信しよう」「どうやったら人の心を惹き付けられるだろう」などと考える時間に多くのエネルギーを奪われれば、ユーザーと向き合う時間だけではなく、作業の手も止まってしまいます。

製品やサービスが完成しなければ失敗に終わるため、プロダクトの開発を主役として「開発9：発信1」程度の割合を意識するよう心掛けてください。
その他、SNSを見る時間や作業の合間にポストをするなど、発信のルールを細かく決めることも大切です。

まとめ・小さく起業するならBuild in Publicも選択肢に

日本でもBuild in Publicという考え方が注目されつつあります。
完成品を作ってから顧客を探す必要はなく、作りながら顧客を見つけられる点が大きな特徴です。
個人での起業時にも向いている手法なので、Build in Publicを選択肢にいれながら起業を目指してみてください。

創業手帳（冊子版）では、起業に役立つ情報を発信しています。参考になる内容となっているので、ぜひチェックしてみてください。

（編集：創業手帳編集部）