アプリを作り、公開するところまでは進められた。それでも、必要な人に届くとは限らなかった。そこからBusiness OSという事業運営の仕組みを考えるまでを、前編・後編で残しておきたい。
前編では、JDCで直面した問題から、市場の観測とAIを使う仕事の目的を考え直すまでを扱う。
1. 公開した。でも、ほとんど人に届かなかった
アプリを作って、App Storeに出した。紹介する動画も作って、YouTubeに投稿した。ランディングページ、つまり製品を紹介するWebページも用意した。SNSも使おうとしている。
そこまで進めても、思ったようには人に届かなかった。
私が作ったのは、Japan Dining Card。ここからはJDCと呼ぶ。日本を訪れる外国人旅行者が、飲食店で自分の食事条件や意思を伝えるための、軽量なアプリだ。
アレルギーや食事制限を伝えるカード、注文や意思表示のためのカードを、店員に画面で見せて使う。主要な機能はオフラインでも利用できる。日本語が得意でなくても、食事の場面で「伝える」「確認する」を支えたいと考えている。Japan Dining Card公式ページ
少なくとも、製品を形にして公開するところまではできた。
これは、私にとって小さなことではなかった。AIやCodexを使い、一人でもアイデアをコードにし、問題を直し、公開まで進められる。以前より、作れるものの範囲は広がったと感じている。
だからこそ、その先にあった壁がはっきり見えた。
作れるようになったことと、売れるようになったことは、違っていた。公開できる状態にするためには、やることが比較的見えやすい。必要な機能を決める。実装する。動作を確認する。ストアへ出す。もちろん簡単ではないけれど、何を進めればよいかは追える。
ところが、使ってくれる人へ届くまでの道筋は、同じようには見えていなかった。
App Storeに置いたことは、必要な人がそこで見つけたことを意味しない。動画を投稿したことは、その人が見てくれたことを意味しない。紹介ページを作ったことも、そこで価値が伝わったこととは別だ。
私は、公開するための仕事を進めていた。一方で、公開したものが、誰の、どんな場面に入り込むのか。そのつながりの設計は、まだ弱かった。
ここで売上や利用者数を成功談として語れるわけではない。むしろ、この原稿の出発点は、作って出したのに、ほとんど人に届かなかったという現実にある。
AIによって製品を作る速度が上がっても、事業を作る難しさまで、自動的に消えるわけではなかった。
2. YouTubeの話が、自分の問題として聞こえた
そんな自分の状況と結びついたのが、個人開発者向けのYouTube動画だった。
きっかけになったのは、入江慎吾さんのチャンネル「入江慎吾 / AIと個人開発」の動画、「【集客】個人開発でリリース時に200人に使ってもらう方法」だ。
ここでは、その話を自分のJDCの経験に重ねて、何を考え直したかを残している。詳しい内容や話の文脈は、元動画もあわせて見てもらいたい。
動画を見て私が受け取ったのは、作ることに集中するだけでは足りない、という話だ。開発に時間をかけて製品を公開しても、知ってもらう方法を考えていなければ、使われないことがある。公開の日に一度告知するだけではなく、開発前や開発中から、自分の課題や体験を伝えていく。その過程に関心を持つ人との関係が、公開時にもつながる。
Audienceという言葉も、そこで自分に引き寄せて考えた。ここでいうAudienceは、単なるフォロワーの合計ではない。発信している課題や活動に関心を持ち、話を聞いてくれる人たちのことだ。
大きな数字があっても、製品の課題と接点がなければ、利用にはつながらないかもしれない。人数が少なくても、その問題を自分のこととして感じている人がいれば、反応の意味は変わる。
機能の説明より、なぜ作ったのか、何に困ったのか、どこで試行錯誤したのかを伝える。そのStory、つまり背景のある話が、人にとっての入口になる。私は、そういう考え方として受け取った。
ただし、動画で語られた方法を、そのまま正解にするつもりはなかった。ある人にうまくいった発信が、別の製品や別の生活条件でも同じ結果になるとは限らない。
私にとって大きかったのは、成功するSNS運用の手順を知ったことより、JDCの状況を見直す言葉ができたことだった。
私は「何を作ったか」は説明できる。でも「なぜ、その人が今それを必要とするのか」は、同じだけ具体的に説明できていただろうか。
アレルギーのカードがある。オフラインでも使える。軽いアプリである。これらは製品の特徴だ。しかし、旅行者が店員を前にして言葉に詰まる場面と、その特徴の間を、私は十分につないでいただろうか。
開発と発信には、どちらにも価値を相手へ渡す仕事が含まれている。コードを書くところで価値が完成したと考えると、相手が受け取るところまでを見落とす。
動画の話は、一般論として聞けば知っているような内容だった。それでも、自分が作ったJDCに重ねると、聞こえ方が変わった。
「良いものを作れば、そのうち見つけてもらえる」という期待を、私はどこかに残していたのだと思う。
3. でも、毎日発信する生活にはできない
それなら、自分の経験を発信し続ければよい。
そう考えたところで、次の問題にぶつかった。
私には本業がある。家族がいる。開発も続けたい。YouTuberとして毎日撮影し、編集し、投稿するための時間を、簡単に増やせるわけではない。現時点では、自分自身を生映像で強く露出することにも積極的ではない。
発信の重要性に納得することと、その方法を自分の生活に組み込めることは、別だった。
もし「事業をやるなら、まず本人が毎日登場する発信者にならなければならない」と考えてしまえば、私の選択肢は急に狭くなる。
そこで、動画の方法を、自分に合う形へ読み替えられないかと考えた。
発信の材料として大事なのが、現実の課題や具体的な経験だとしたら、すべてを私自身の生活から生み出す必要はあるのだろうか。
JDCが向き合うのは、外国人旅行者の食事中のコミュニケーションだ。その現場を毎日経験しているのは、私よりも、旅行者本人かもしれない。
日本食を楽しみたい。でも日本語を話せない。食事制限を説明したい。メニューが分からない。注文のやり取りが不安だ。こうした課題について、公開された投稿やレビュー、動画へのコメントには、当事者が語る経験を探す余地がある。
ならば、私はまず、それを継続的に観測する仕組みを考えればよいのではないか。
自分が毎日カメラの前に立つ代わりに、市場で起きていることを、継続して学ぶ。もちろん、他人の体験を自分の体験として語ってよいという話ではない。当事者の投稿があっても、書かれた内容のすべてを外から確認できるわけではないし、一人の経験で市場全体を代表させることもできない。
自分の経験を発信することと、他者の経験から課題を学ぶことは、役割が違う。それでも、後者を続けることによって、自分が何を作り、何を確かめ、何を伝えるべきかを考える材料は増やせる。
私が発信できるのは、その観測からどんな仮説を立て、自分の製品で何を試したかという、自分自身の探索でもある。
このあたりから、考えている仕事が「SNSをもっと頑張る」だけではなくなってきた。
4. 投稿を集める前に、何を知りたいかを分けた
市場を観測する。この仕事を、Market Intelligenceと呼ぶことにした。市場の情報を集め、判断に使える形で理解する、という意味だ。
ただ、X、YouTube、Reddit、TikTok、レビュー、Webを見ればよい、と並べただけでは、仕事の形にならない。
情報は集まっても、何が分かったのかが曖昧なままになる。旅行者の困りごとと、よく検索される言葉と、突然伸びた動画が、一つの「市場情報」の箱へ入ってしまう。
そこで最初に、Signalを五つに分けた。Signalは、判断の手がかりになる兆しや情報のことだ。
| Signal | 知りたいこと | JDCで考える例 |
|---|---|---|
| Voice Signal | 人が何に困り、何を望んでいるか | 店員へ食事条件を伝える際の困りごと |
| Demand Signal | どんな情報が探されているか | 日本旅行と食事制限に関する検索の動き |
| Attention Signal | 今、何が注目されているか | 食事中の言葉の壁を扱う話題への反応 |
| Competitive Signal | 既存の解決策は何を満たし、何を残しているか | 翻訳やカードなどに対する評価と不満 |
| Outcome Signal | 自分の製品や施策で何が起きたか | JDCの利用、反応、売上など、取得できた結果 |
この区別をして、Xの一投稿とGoogle Trendsの検索推移は、同じEvidenceではないと整理できた。Evidenceは、判断を支える根拠のことだ。
ある人の投稿は、その人が何に困ったと述べているかを知る手がかりになる。でも、それだけで同じ課題を持つ人数までは分からない。
検索の動きは、関心の変化を考える材料になる。しかし、検索した人が困っているのか、ニュースを見て気になったのか、購入したいのかまでは、数字だけでは分からない。
Google Trendsについても、表示値は検索件数そのものではなく、地域や期間に応じて正規化された相対的な検索関心だ。100という表示を、100人の顧客や100件の検索と読み替えることはできない。Google公式「トレンドのデータに関するよくある質問」
注目を集めた投稿があることと、継続的な需要があることも、分けて考えたい。反応が多いのは面白いからかもしれないし、議論になっているからかもしれない。
競合への不満にも、前提がある。その人が求めた使い方と、製品が想定した使い方が違うだけかもしれない。一方で、既存の方法で十分だという声も、見落としたくない。
自分の結果を見るOutcome Signalも大切だ。市場に課題がありそうでも、JDCが役に立つ形になっているかは別に確かめる必要がある。ただし、まだ取得していない利用状況を、取得済みのようには扱えない。
五つに分けた目的は、情報の種類を増やすことではなかった。その材料で言えることと、まだ言えないことを、区別するためだった。
5. 現実を拾う仕組みも、思い込みで動いてしまう
市場を継続的に観測する、という考えには、魅力があった。
毎回ゼロから調べる代わりに、新しい声を見つけ、過去の声と比べ、課題の変化を追える。JDCのために得た情報が、機能を考える材料にも、説明を直す材料にもなる。
ただし、ここにも落とし穴がある。
私が「食事制限を伝えるのは難しいはずだ」と思って、その話だけを探せば、難しいという声ばかり集まるかもしれない。公開投稿で見つかりやすい人と、何も投稿しない人では、経験が違う可能性もある。
困っている人の投稿は具体的で、読み物としても強い。だからこそ、その話の強さと、課題の広がりを混同しやすい。
AIに要約させれば、その混同が見えなくなることもありそうだ。一人の体験が「旅行者はこう考える」という滑らかな文章になった瞬間、元の根拠より主張が大きくなる。
それを防ぐには、元の情報へ戻れるようにしたい。いつ、どこで、どんな文脈で書かれたのか。本人の経験の記述なのか、別の人の話なのか。複数の独立した声なのか、同じ話の転載なのか。
公開されていることと、自由に収集して再利用できることも同じではない。取得方法や利用条件を確認し、不要な個人情報を残さない。市場の課題を理解するために、個人の情報を大量に抱える必要はない。
まずは、取得できる範囲の少量の情報でもよい。その意味と限界を残し、仮説に合わない声も見る。
これなら、情報をたくさん集めること自体を成果にせずに済む。
必要なのは、私の考えを補強する材料だけを探す装置ではない。作ったものが市場とずれているかもしれない、と気づける仕組みだった。
この観測を、実際の開発や発信へどうつなげるか。そこを考え始めたとき、別の場所で検討していた話と合流した。
6. AIをどう動かすかより、先に決めることがあった
私は別途、AGI Cockpitの改修について考えていた。
複数のAIやCodex、Claude、さまざまな道具を、どう使い分ければよいのか。仕事をどう渡し、何を確認し、どこで判断を戻すのか。AIを動かす環境を、もっと整理できないかと検討していた。
その細かな設計は、ここでは扱わない。今回の話に必要なのは、考える順番が変わったことだ。
市場の情報を集める。課題を整理する。JDCを直す。説明するコンテンツを作る。反応を見る。
こうした仕事を並べると、AIの配役を決める前に、もっと上位の判断があると分かった。
そもそも、何のためにその仕事をするのか。新しい機能を作るべきなのか。それとも既存の機能の説明を直すべきなのか。今、調べるべきなのは競合なのか、利用する場面なのか。限られた時間を、どこに使うべきなのか。
AIへ上手に依頼できても、選んだ仕事が市場の問題とずれていれば、ずれた仕事が速く終わるだけかもしれない。
私が整えようとしていたのは、仕事を実行する側の仕組みだった。しかし、実行する仕事を選び、その結果から次の仕事を変える仕組みも必要だった。
そこで、Business OSという考え方が、AGI Cockpitの上位に見えてきた。
Business OSは、Business Operating System、事業運営システムという意味で使っている。パソコンのOSを作るという話ではない。事業を進めるルール、情報の受け渡し方、仕事の流れ、判断の基準を、一つのつながりとして捉えるための呼び名だ。
一方、AGI Cockpitには、その事業活動から生まれる仕事を、AIや道具を使って実行する役割を考えている。Control Plane、つまり、実行を整理し制御する層としての位置づけだ。
この図は、今の構想の関係を示している。すべてが実装され、実際の事業運営で効果を確かめたという意味ではない。
「よりうまくAIを使う」ことが、「より意味のある仕事をする」ことへつながるには、その間を設計する必要がある。
AGI Cockpitをいじろうとしていたからこそ、私は、その外側にある問いへ戻った。
7. 市場を見るところから、学ぶところまでを一周にする
Business OSと呼ぶ前から、それぞれの仕事は存在していた。
市場を調べる。戦略を考える。製品を作る。動画を作る。販促をする。数字を見る。これらを私が発明したわけではない。
変えたかったのは、それぞれの仕事のつながりだった。
以前の捉え方だと、開発は開発、発信は発信、市場調査は市場調査になりやすい。アプリを作り終えたら、次は動画を作る。動画ができたら、次はSNSへ投稿する。進んでいるようでも、前の仕事で分かったことが、次の判断に十分使われていないかもしれない。
JDCで見つけた困りごとが、何を作るかを変える。同じ困りごとが、何を説明するかも変える。実際の反応が、最初の困りごとの捉え方を変える。
そういう循環にしたかった。
これをClosed Loop、結果が次の判断へ戻ってくる循環として考えた。図は理解のために順番に並べているが、実際の仕事が必ず一列になるという意味ではない。説明を考えて製品へ戻ることも、作る前に仮説を確かめることもある。
例えば、食事条件を店員へ伝える場面について、具体的な困りごとが見つかったとする。
その課題に取り組む価値があるかを考える。誰のために、どの場面を支えるかを絞る。どう収益へつなげられるかを検討し、製品の内容と、利用場面の説明を考える。必要な変更を作り、反応を確かめる。
そこで「この機能は分かりにくい」という反応が出れば、説明だけを直せばよいとは限らない。製品の設計に問題があるのかもしれない。想定した利用場面が違うのかもしれない。
結果から戻れるようにしておけば、機能を増やし続ける以外の選択肢が生まれる。
私にとってBusiness OSは、事業を継続して発見し、作り、届け、学ぶための、ルールと情報と仕事の流れの集合だった。成功する方法を一つ見つけた、という感覚ではない。どこで思い込みが生まれ、どこからやり直せるかを、少し見えるようにしたかった。
ここまでが、Business OSという考え方へ至る前編だ。後編では、九つのOS、情報の受け渡し、意見が割れたときの判断を整理し、まずJDCで一周させる方法を考える。