Productは設計するのに、なぜ届け方は設計していなかったのか

Business OSの地図ができたとき、私はかなり満足していた。

市場を観測する。困りごとを根拠として残す。取り組む機会を選ぶ。製品を作る。伝える。使われた結果から学び、もう一度、市場へ戻る。

開発だけを切り出していたときより、事業全体のつながりが見えた。ところが、もう一度その地図を眺めると、一か所だけ、ほかと同じ細かさで描けていない場所があった。

作ったものを、誰に、どう届けるのか。

今回は、その穴に気づいてから、Distribution Machineという考えに至るまでを残しておきたい。JDCを使った成長の成功談ではなく、届け方を設計し直そうとしている私の思考の記録だ。

前回の話は、「AIでアプリは作れた。でも、事業の作り方はまだ分からなかった」前編と、「Business OSの地図を、JDCで使える形へ」後編にまとめている。

1. 事業の流れはつながった。でも、届け方だけ粗かった

前回、私がBusiness OSと呼んだのは、Business Operating System、事業を運営するための仕事のつながりだった。

きっかけには、個人開発についてのYouTube動画があった。いいものを作るだけでは使われない。開発の前や途中から、課題や背景を伝える必要がある。その話を、私は自分のJapan Dining Cardの状況に重ねた。

Japan Dining Card、ここからはJDCと呼ぶ。日本を訪れる外国人旅行者が、飲食店で食事条件や意思を伝えるためのアプリだ。作り、App Storeへ公開し、紹介動画や製品ページも用意した。それでも、必要な人へ届く道筋は弱かった。

そこから、Market Intelligence、市場を観測して学ぶ仕事を考え始めた。根拠、解釈、取り組む機会、戦略、製品、開発、伝える内容、Growth、利用や事業の成長を改善する仕事へつなぎ、結果をLearning、次の判断に使う学びへ戻す。

Closed Loop、結果が次の判断へ戻る循環として、事業を考えられるようになった。これで、何か思いつくたびに機能を足すところから、一段進めた感覚があった。

しかし、製品側と届ける側を比べると、非対称だった。

Productについてなら、誰の、どんな困りごとなのか、何の機能が必要か、画面や開発をどうするかまで細かく考える。一方、届ける側は「YouTubeで紹介する」「Xへ投稿する」「広告を出す」「SNSを活用する」程度で止まっていた。SNSはSocial Networking Service、人との交流や発信に使うサービスのことだ。

動画を作ることと、JDCを必要としている人に見てもらうことは別の課題だ。投稿しても、その人が私をフォローしているとは限らない。

製品の設計が「アプリを作る」の一行で終わっていたら、それでは足りないと思うはずだ。なのに、届け方が「SNSをやる」の一行でも、先へ進もうとしていた。

Productは設計するのに、なぜDistributionは設計しないのか。

Distributionは、ここでは製品を必要な人へ届け、利用につながる経路を作ることを指す。Business OSには、届ける仕事の名前はあった。でも、考えるための中身が足りていなかった。

2. 最初の10人は、どこから来るのか

JDCの対象を聞かれたら、「日本を訪れる外国人旅行者」と答えられる。でも、その答えは広すぎる。

日本語が得意な人も、別のカードを持っている人もいる。旅行前に準備する人と、飲食店に入ってから困る人では、出会える場所も違う。

そこで、もっと小さな問いにしてみた。

では、最初の10人は、具体的にどこから来るのか。

ここでいう10人は、すでに獲得した人数ではない。最初に考えるための単位だ。その人は、何を検索し、どんな動画を見て、誰の説明を信用しているのか。どんなコミュニティで、どんな言葉で困りごとを話すのか。

JDCを知ったとして、なぜストアへ進み、何ができると思い、ダウンロードしたあと何をするのか。「世界中の旅行者に使ってもらいたい」という願いでは、答えられない。

私が実際に行ったのは、製品を作り、公開し、紹介するところまでだった。Xなども使おうとしていた。当時の考え方を単純化すると、「作る→公開する→何か紹介する→誰か来てくれるはず」と見える。その間にある「誰に、どこで」が埋まっていない。

JDCは、食物アレルギーや食事制限、注文や意思表示を、カードで伝えるためのアプリだ。主要な機能はオフラインでも利用できる。Japan Dining Card公式ページ

こうした意思疎通の課題は、Vegan、動物由来の食品を避ける食事や、Vegetarian、菜食、宗教上の食事制限を持つ旅行者にも起こりうる。ただ、対象として考えることと、現在のカードで十分に対応できることは別なので、必要な表現を確認したい。

また、店を探すことと、食事条件を伝えることも違う。Veganの店を探している人へ、店の検索機能があるかのように紹介してはいけない。カードで伝えることは、店側の理解や食事の安全を保証するものでもない。

対象を細かくするのは、その人の困り方と、製品のできることと、出会う場所を、同じ場面にそろえるためだ。それができて初めて、「動画を作る」「ストアを直す」という作業にも理由が生まれる。

3. 市場調査とDistributionは、つながっていた

ここで、Business OSの最初に置いたMarket Intelligenceと、最後の方に置いたDistributionが、急につながった。

市場の困りごとを知るため、X、YouTube、Reddit、TikTok、Google Trends、検索データ、レビューなどを見ることを考えていた。

例えば、「日本の飲食店で、甲殻類のアレルギーをうまく説明できなかった」という声があるとする。これは説明用の架空例で、実在する投稿の引用ではない。

こうした困りごとの兆候をPain Signalと呼ぶ。最初は市場調査の材料として読んでいた。出所と文脈を残し、Evidence、確認できる根拠へ整理する。そこからInsight、意味の解釈へ進む。

でも、その困りごとを持つ人は、製品を必要とするかもしれない人でもある。

使っている言葉には、説明を考える手掛かりがある。声が集まる場所には、似た課題を持つ人との接点がある。回答を見ると、何が信用され、すでに何で解決しているのかも分かるかもしれない。

「何を作るか」を考える情報が、「どんな言葉で、どこへ届けるか」にもつながった。

その経路の一つが、Pain-Signal Outreachだった。Outreachは、こちらから関係を作るために働きかけること。関心のある人との試用や対話、少数の人に試してもらうProduct Seedingにもつながるかもしれない。

ただ、それを「困っている投稿を検索して、片っ端からDMを送る」に縮めると、別のものになる。DMはDirect Message、相手へ直接送るメッセージだ。公開された声でも、宣伝を受け取りたいとは限らない。

特にJDCでは健康や宗教に関わる条件がある。投稿からそれを推測して営業用の名簿を作る方向には進めたくない。まず匿名のテーマとして学び、適切な場での募集など、本人が参加を選べる入口を考える。現行のJDC設計でも、機微な条件を推測した個人DMは、最初の10人の獲得方法に置いていない。

市場調査で知った困りごとと、必要な人に適切な入口を用意する仕事をつなぐ。その接続が、今回の大きな転換点だった。

4. 「作る」と「届ける」を同時に設計する

届け方を考え始めると、仕事の順番にも疑問が出てきた。

製品を完成させてから相手のいる場所を探し、説明してみて、求められているものとの違いに気づく。それでは、分かったことを製品へ戻すのが遅い。

旅行前の準備で出会うなら、出発前に使い方を確認できることが大切かもしれない。旅行中の通信が不安な場面なら、オフラインでできることが説明の中心になる。そう考えて初めて、最初の画面で何を見せるかが変わることもある。

Distributionは、完成した製品の周囲へ広告を足すだけの仕事ではなかった。

そこで、BusinessThesisから二つのBriefを並べて作る構造にした。BusinessThesisは、誰の課題に、どんな価値を提供し、なぜ事業として成立すると考えるかをまとめた仮説。Briefは、仕事の目的と方針を短くまとめる文書だ。

| ProductBrief：製品の設計 | DistributionBrief：届け方の設計 |

| --- | --- |

| 誰の、どんな課題を支えるか | その人は、どんな場面で困っているか |

| どんな価値と体験を用意するか | どこにいて、何を検索し、誰を信用するか |

| どんな機能や利用条件が必要か | どの接点で、何を伝え、利用へ案内するか |

| 何ができれば目的を果たせるか | 何を測り、どんな結果なら続けるか |

製品の設計と届け方の設計を、同じ事業仮説から同時に始める。

そのうえで、製品ができないことを告知が約束していないか、届けたい相手に言語や利用条件が合うかを照らし合わせる。

最初から精密な予測を埋める必要はない。「Creatorなら届くはず」ではなく、「この場面を説明できる発信者との相性を確かめる」と書けば、次の仕事が変わる。費用、人の時間、結果の確認、止める条件も置きたい。

説明しにくい価値を投稿数で押し切る前に、対象や最小の製品体験を見直す。届け方の検討から、製品や事業仮説へ戻る道ができた。

5. 11のRouteは、全部やるためのリストではない

届け方を設計すると言っても、思いつきやすい経路から考えてしまう。自分が使っているSNSは思い出せる。一方、相手が製品を探す場所や、すでに信用している人は後回しになりやすい。

そこで、最低限一度は評価するDistribution Route、届ける経路を11種類に整理した。

| Route | 考えること |

| --- | --- |

| 1. Store Discovery | ストアの検索や閲覧で発見される |

| 2. Store Optimization | 名前、説明、画像を整え、理解とダウンロードにつなぐ |

| 3. Search Acquisition | Web、動画、ストアの検索で課題を持つ人と出会う。検索広告もここで考える |

| 4. Organic Social | 広告費を払わない通常の発信で利用場面や背景を伝える |

| 5. Creator | 対象と接点のある発信者の説明、実演、信頼を通じて届ける |

| 6. Pain-Signal Outreach | 困りごとを手掛かりに、参加意思と文脈に合う接点を作る |

| 7. Community | 共通の関心を持つ場で、ルールに沿って説明や対話をする |

| 8. Launch / PR | 公開の機会に紹介の場やメディアへ伝える。PRはPublic Relations、広報や関係を築く活動 |

| 9. Partnership | 相手のサービスや現場との協力を通じて届ける |

| 10. Referral / Affiliate | 自発的な紹介や、条件を明示した成果報酬の紹介で広げる |

| 11. Paid Social | SNSなどの有料広告で、対象と説明の仮説を確かめる |

11という数に特別な正解があるとは思っていない。検討の抜けを減らすための整理だ。また、YouTubeは発信にも検索にもCreatorの説明にもなる。同じ成果を別々の経路の成功として二重に数えたくはない。

毎回11個を実行するのではなく、毎回一度は評価する。

使う、条件が整ったら使う、後に回す、この仮説には合わない。理由を添えて決めればよい。

この地図で考えると、App Storeも製品の置き場所から、初めてJDCを知る人との接点へ変わる。名前、Subtitle、短い副題、Keyword、検索語、Screenshot、画面画像、Preview Video、機能を見せる動画、Localization、言語や地域への調整、レビューまでが入口になる。Apple「Creating your product page」

検索なら「food allergy japan」「vegan japan」「halal japan」「allergy card japan」「japanese allergy translation」などを考えられる。ただし、検索量を調べた結果ではなく仮説だ。店を探す意図と条件を伝える意図は分けたい。SEOはSearch Engine Optimization、検索で見つけられるように内容を整えること。検索広告、YouTube検索、ストア検索も、相手の問いに合う説明から考える。

Creatorの人数だけを見るのも粗い。日本旅行の準備や食事条件のある旅行を扱う発信者なら、相性があるかもしれない。見るべきなのは、対象の重なり、信頼、説明力、製品との相性、費用や結果だ。大きなAudience、話を聞く人の集まりが、そのまま利用者数になるとは限らない。

Communityにも、困りごとの言葉、独自のルール、信用される説明、既存の解決策がある。「宣伝を貼れる場所」とだけ理解したくはない。Redditでは全体と各Communityのルールが関わる。Reddit「Spam」

提携まで考えれば、旅行情報サイト、ホテル、飲食店、観光に関わる組織、旅行会社やメディアも将来の候補になる。相手がなぜ案内するのか、負担や責任はどうなるかも問いたい。これらは候補類型であり、実際に協力を得た実績ではない。

6. JDCなら、10人、100人、1,000人で何を確かめるか

JDCのDistributionBriefへ短く落とすなら、次のようになる。これは説明用の仮説で、完成した戦略や実施済みの計画ではない。

| 項目 | 考える内容 |

| --- | --- |

| Product | Japan Dining Card |

| Target | 訪日旅行の食事で、条件や意思を日本語で伝える準備をしたい人 |

| Pain | 店員へ何を見せ、どう伝えればよいか分からない |

| Promise | カードを使って伝える準備を支える。食材確認、会話成立、食事の安全を保証するものではない |

| Where | 検索、旅行準備の動画、参加ルールのある旅行Communityなどの候補 |

| Routes | Store、Search、Creator、Community、Partnership。Pain-Signal Outreachは適切な参加意思と文脈が成立する場合に検討 |

最初の10人では、関心を示す知人経由の協力者や、許可された試用募集の参加者に、説明が伝わり、最初のカードを自分で準備できるかを確かめる。

人数を埋めることより、どこで期待がずれ、どこで迷うかを見る。カードの準備や表示は、価値へ近づく途中の手掛かりであり、実際の会話の成功や食事の安全を証明するものではない。

最初の100人では、Creator、Community、Search、Storeの候補から、私の個別説明なしでも同じ理解と体験へつながる経路を選ぶ。

最初の1,000人では、実測で見込みが得られた経路へ資源を寄せる。提携、検索向けの内容、Creatorとの協力を広げることを考える。有料広告は、収益、費用、計測、上限を確認してから小さく試す候補だ。

数字だけを先へ進めてはいけない。説明や利用のつまずきが大きいなら、広げる前に直す。別の解決策で十分なら、製品側の仮説を考え直す。

この考え方は、公開済みのJDCの見直しにも、次の製品の公開前にも使いたい。

Pre-launch、公開前から始めるとは、製品を作る間にも、関心を持つ人、Creator、Communityとの接点を探し、試作品の説明や試用を考えることだ。必要ならWaitlist、提供を待つ人の登録や、Pre-registration、事前登録も候補になる。ただし、JDCにその仕組みが実装済みという話ではなく、事前募集も必須ではない。

大切なのは、公開の日に、出会い方まで完全なゼロから考え始めないことだった。

7. 届いた先で、価値を感じてもらえたか

考えていくと、Business OSの「Go-to-Market & Growth」という箱も粗すぎた。

Go-to-Market、略してGTMは市場投入の戦略。誰へ、何を、どこで、どんな順番で届けるかを決めることと、実際に届けることと、利用後に改善することは、問う内容が違う。

そこで、三つの仕事へ分けた。

• GTM Architecture：対象、価値、経路、優先順位を設計する。

• Distribution & Activation：説明と入口を用意し、最初の価値体験へ案内する。

• Growth & Lifecycle：再利用、対価、紹介を見て、体験や方針を変える。

Activationは最初の価値体験へ進むこと。Lifecycleは、知る前後から利用を続けるまでの関係の流れだ。

動画が見られ、ダウンロードされても、まだ製品が役に立ったとは言えない。JDCなら、必要なカードへ迷わず進めるか、旅行前に聞いた説明と画面の期待が合うか、次の食事でも使いたいかを考えたい。

Retention、再利用についても、毎日開くことだけを正解にしたくはない。旅行の道具なら、次の必要な場面で選ばれるかを見る方が合うかもしれない。

Monetization、収益化では、価値と対価、費用の関係を見る。Referral、自発的な紹介と、Advocacy、経験に基づく公の推奨も分けたい。共有が始まったことと、紹介先で使われたことは違う。レビューを残さない人が、価値を感じていないとも限らない。

図は、全員が必ず順番に通るという意味ではない。見落としたくない問いを並べたものだ。

どの接点が効いたかを考えるAttribution、成果の帰属にも限界がある。検索、動画、ストアを行き来すれば、一つの経路へ割り当てられないことがある。Appleの利用分析にも、共有への同意やデータ量による制約がある。Apple「App Analytics」

JDCは主要機能をオフラインで使える。ストアの集計と個々のカード利用を当然に結び付けられるわけでもない。分からないところを埋めるために、本人の食事条件や会話まで収集したいわけではない。

使い方で迷うなら、集客を増やす前に体験を直す。分からない数字は、分からないと残す。届けた結果を、次の投稿だけでなく、製品や事業仮説へ戻す。ここまで含めて考えたかった。

8. Distribution Machineは、売れるボタンではない

最初はPromotion、紹介や販促、Marketing、市場と顧客へ価値をつなぐ活動、SNSといった言葉で考えていた。

でも、私が設計したかったのは告知が目に入るところだけではない。製品が必要な人の手元へ届き、使われ、価値が伝わり、反応が戻ってくるところまでだった。その範囲を意識するために、Distributionという言葉が合っていた。

さらに、毎回同じ空白を残さず考える仕事のまとまりを、Distribution Machineと呼ぶことにした。

もちろん、11経路をAIに動かしてもらえば売れる、という機械を作れた話ではない。ボタン一つで全員が売れるなら、全員が億万長者になっているはずだ。

Product Market Fit、製品が市場の課題や需要に合い、選ばれる状態がなければ、届け方だけを改善しても続きにくい。Pain Signalは市場規模や支払う意思を保証しない。Creatorの人数も利用を保証しない。

広告はEconomics、収益と費用の関係次第だ。無料のCommunityにも人の時間がかかり、やり方次第では迷惑な宣伝になる。プラットフォームのAPI、Application Programming Interface、情報や機能を扱う接続口や、規約に依存する部分もある。

仕組みを整える時間が増え、説明を一つも確かめられないなら重すぎる。最初は短いBriefと、一つの小さな検証でよいと思っている。

Machineという名前で残したいのは、勘で販促を繰り返す代わりに、考えるべき問いを構造化し、結果から見直せるようにすることだ。

Business OSを考えたからこそ、Distributionの設計不足が見えた。全体の地図は、穴を隠すためではなく、穴の場所を見つけるために役立った。

前回は、いいProductを作るだけでは足りない、という地点へ来た。今回は、その先を少し具体的に言える。

誰に、どの経路で、どの順序で届くのか。そこからどう使い始め、何を価値として受け取るのか。その道筋を、Productと同じ解像度で設計する。

作ることと届けることを同時に考えれば、届け方で分かったことが、作るものにも戻る。まだ設計と紙上の検討が中心だけれど、私のBusiness OSは、製品と市場の接続まで考える地図へ一段進んだ。

ここまで構造化できるなら、AIを使う実行基盤へ、この仕事のつながりを載せられるのではないか。そこで、先に検討していたAGI Cockpitという実行環境へ話が戻ってくる。AGIはArtificial General Intelligence、汎用人工知能の略で、ここでは実行環境の名前に含まれる語だ。

何を、なぜ行うかをBusiness OS側で決め、どう実行するかをCockpit側へ渡す。次は、このBusiness OSとDistribution Machineを、AGI Cockpitという実行基盤へどう接続するかを考えたい。