前編では、Japan Dining Card（JDC）を公開しても人に届かなかった経験から、市場を観測し、作り、届け、学ぶ仕事を一つの循環として考えた。このつながりを、私はBusiness OSと呼んでいる。
後編では、その地図を実際の仕事へ近づけるために整理した、役割、情報の受け渡し、判断の方法を残しておきたい。まだ構想の段階で、JDCでの効果を確認した話ではない。
1. 九つのOSは、九つの部署を作るためではない
一周の流れが見えてきたら、次は、その中で必要になる能力を整理した。
顧客にとっての価値を見つけ、作り、届け、学ぶ領域を、Value Creationと呼ぶことにした。その中には、次の九つを置いた。
| 領域 | 役割 | JDCなら、どんな問いになるか |
|---|---|---|
| Market Intelligence OS | 市場を観測する | 旅行者は、どの場面で何に困っているか |
| Strategy & Portfolio OS | 取り組む市場や機会、優先順位を選ぶ | 限られた時間を、どの課題へ使うか |
| Business Model & Economics OS | 価値、収益、費用の関係を考える | 支払う理由があるか。続けられる費用か |
| Product OS | 製品の目的と内容を決める | どの場面を、どこまで支える製品にするか |
| Development OS | 実装、テスト、公開を進める | 変更をどう作り、動作を確かめるか |
| Brand & Content OS | 伝える内容と、伝え方を考える | 機能の名前より先に、どんな利用場面を見せるか |
| Operations / LiveOps OS | 公開後も運営を続ける | 問い合わせ、不具合、情報の更新をどう扱うか |
| Go-to-Market & Growth | 市場へ届け、利用と成長につなぐ | 必要な人に届き、使い始めてもらえているか |
| Learning & Analytics OS | 結果を分析し、次の判断へ戻す | 何が効いたか。どの仮説を変えるか |
Portfolioは、複数の取り組み全体を見て、時間や資源の配分を考えること。Economicsは、売上だけでなく費用も含めて、事業が成り立つかを考えることだ。
LiveOpsはLive Operationsの略で、公開後の継続運営を指す。Go-to-Marketは、製品を市場へ持ち込み、利用者へ届けるための考え方で、GTMと略される。
こうして並べると、一人でやるには多すぎるようにも見える。私自身、名前を増やしただけで仕事が増えるのでは困ると思った。
しかし、JDCの仕事をしているとき、これらの問い自体は、すでにどこかで発生している。意識していなければ、開発しやすい課題ばかり選んだり、費用を後から考えたり、公開後の反応を見ることを忘れたりする。
九つのOSを置くのは、九つの部署や九体のAIを作るためではない。何を考え、何を考えていないかを分かるようにするためだ。一つの作業が、複数の役割を兼ねてもよい。
例えば、一つの困りごとを読み、既存のカードの説明を見直すだけでも、市場観測、製品の検討、コンテンツの検討がつながる。その程度の小さな仕事から、この地図を使えればよい。
最初に必要だったのは、巨大なシステムではなく、事業を回すための能力地図だった。2. 将来の場所は予約する。でも、全部は作らない
能力地図を考えると、JDCの外側も気になった。
将来、複数の製品やゲームを作るとしたらどうなるか。取り組みが増え、関わる人が増え、会社として運営する範囲が広がったら、顧客価値を作る流れだけでは足りない。
そこで、企業活動を支えるEnterprise Enablementという領域も、地図に置くことにした。
財務と資金、人と組織、法務と知的財産、データと知識、社内の技術基盤、パートナーとの関係、調達と資産、会社の成長や組み替え。知的財産はIntellectual Property、IPとも呼ばれる。
さらに、Governance & Controlという領域も置いた。運営の責任、リスク、ルールの順守、セキュリティ、プライバシー、品質、方針、監査などを扱う。
名前だけ見れば、ずいぶん大きな会社の話になっている。でも、これらを今すべて実装するつもりはない。一人でアプリを運営する段階から、大企業の管理制度を丸ごと作り始めたら、それだけで時間がなくなる。
そこで、能力ごとに三つの状態を持たせることにした。
| 状態 | どう扱うか |
|---|---|
| ACTIVE | 今、必要なので実際に動かす |
| LITE | 今の規模に合う、軽い形で扱う |
| RESERVED | 将来の役割と接続先を予約し、作り込みは後にする |
例えば、JDCに必要な市場観測や製品開発はACTIVE。運営、財務、法務、セキュリティ、プライバシー、知識の管理は、現状に合うLITEの形を考える。人や組織の拡大、会社間の関係、広範な監査などは、必要になる場所をRESERVEDとして残す。
LITEは、守るべき基準を軽くする意味ではない。今の規模で必要な確認や責任を果たせる、簡素な形にするという意味だ。
将来を考えることと、将来の仕事を今すべて引き受けることは、分けたい。地図に場所があるなら、必要になったとき、どこへ足すかを考えやすくなる。
この三段階によって、大きく育つ可能性を残しながら、目の前のJDCへ集中する道筋を考えられた。
3. 図の矢印に、何を流すのか
OSを並べて矢印でつなぐと、全体が整理されたように見える。
しかし、図の矢印を眺めても、次の作業へ何を渡すかは分からない。「市場を見て、よい製品を考えてください」では、結局、その場の文章と解釈に頼ってしまう。
そこで、OSの間をObjectでつなぐことを考えた。ここでのObjectは、決まった項目を持つ情報のまとまりだ。最初は表や短い文書でもよく、必ず専用のソフトウェアを作る必要はない。
まず、拾った情報をSignalRecordとして記録する。出所や時点、文脈を残し、根拠として扱うEvidenceObjectへつなぐ。その根拠をどう解釈したかをInsightObjectに、取り組む候補をOpportunityObjectに分ける。
その先は、判断を残すDecisionObject、事業の仮説をまとめるBusinessThesis、製品の目的や対象をまとめるProductBrief、具体的な要件であるProductRequirement、実装してできたBuildArtifactへつながる。
BusinessThesisには、誰のどんな課題に、どう価値を提供し、なぜ事業として成り立つと思うのかを残したい。作業を始める前の仮説を、後から結果と比べられるようにするためだ。
そして、取得できた結果をOutcomeRecordに、その結果から何を変えるかをLearningObjectに残す。
これも、今回の話のために製品側の流れを示した概念図だ。すべての判断が一度で決まるわけではないし、各段階に別のデータベースを作るという意味でもない。
残したいのは、判断から元の根拠へ戻れるつながりだった。「なぜ、この機能を作ったのか」と聞かれたとき、「AIがよさそうと言ったから」で終わらない。どの声をどう読んで、どんな仮説を立て、何を確かめるために選んだかを、たどれるようにしたい。
4. Evidence、Insight、Opportunityを混ぜない
この情報の受け渡しで、特に大事だと考えたのが、Evidence、Insight、Opportunityの違いだった。
JDCの文脈で、例を考えてみる。以下は説明のために作った例で、実在する投稿の引用ではない。
日本の飲食店で、甲殻類のアレルギーがあることを、うまく説明できなかった。
この発言を見つけたと仮定する。元の発言がSignalだ。
Evidenceとしてまず言えるのは、「日本の飲食店でアレルギーをうまく説明できなかった、と述べる旅行者の投稿がある」ということになる。本人の経験の報告であって、起きたことを私が独立して確認したわけではない。その限界を含めて記録したい。
そこから、「旅行者には、伝わったかどうか分からない不安もあるのではないか」と考える。これがInsightだ。根拠に意味を与えた解釈であり、追加の声や確認によって変わる可能性がある。
さらに、「通信に頼らず、相手へ見せてやり取りできる支援には価値があるかもしれない」と考える。これがOpportunityになる。どんな価値を提供できるかという、事業機会の候補だ。
一つの投稿から、JDCへの需要や支払う意思まで確定することはできない。すでに別の方法で十分に解決できている可能性もある。
また、カードで意思を伝えることと、店側が条件を満たせることは別だ。伝達を支える製品を考えるときにも、できることの範囲を越えて、食事の安全まで保証する表現にはしたくない。
以前の考え方では、この途中を一気に飛ばしやすかったのだと思う。困っている声がある。だから機能を作るべきだ。だから使われるはずだ。
しかし、その間には、確認していない仮説が何段もある。
分けて残せば、結果が出なかったときにも問い直せる。課題の捉え方が違ったのか。解決方法が合わなかったのか。伝え方が分からなかったのか。そもそも、その人へ届いていなかったのか。
根拠、解釈、機会を分けることは、自分の期待を事実へ変えてしまわないための工夫だった。5. 意見が割れることを、仕組みの中に置く
ここまで整理しても、取り組む課題が自動的に決まるわけではなかった。
市場の視点からは、困っている声があるので取り組みたい。製品の視点からは、比較的小さな変更で支えられそうだ。財務の視点からは、運営の費用に見合うか分からない。法務や品質の視点からは、伝え方によって過大な期待を生むかもしれない。
こうした意見は、同時に存在しうる。
それぞれを別のAIに担当させれば解決する、という話でもない。同じ私が考えても、見る側面が違えば、違う結論が出る。事業には、簡単に一つへまとめられない条件がある。
そこで、各OSが自分の立場を出し、その対立を整理する横断的な層を、Decision Planeと呼ぶことにした。意思決定を扱う場、という意味だ。
何を根拠に、何を勧めているかを比べる。その主張に反対するとしたら、どこが弱いかを考える。意見が食い違う点を見つけ、選択肢を整理し、実施するか、保留するか、まず調べるかを決める。
市場、製品、財務などのどれかに、あらゆる判断の最終決定権を固定するのではなく、判断の性質と条件を見る。ただし、守るべき法令や安全、本人の権限の境界まで、意見の多数で取り払うつもりはない。
JDCの先ほどの例なら、伝達を支える変更は試すが、安全を保証する表現は使わない、という条件つきの判断もありうる。あるいは、困りごとの解釈が弱いので、製品を変える前に追加で確かめる、という判断もある。
意見が一致している小さな仕事まで、毎回大きな会議にしたいわけではない。迷う点を、迷っていないふりで通過しないことが大事だと思った。
DecisionObjectには、結論だけでなく理由と条件を残したい。新しい根拠が出たら見直す。影響の大きな判断では、私が確認するHuman Gate、人の判断を挟む地点も必要になる。
構想が整理されるほど、AIに任せる範囲だけでなく、自分が引き受ける判断も見えてきた。6. v0.1は、きれいな図を完成させるためのものではない
この構想を、最初から完璧に作ろうとしたら、JDCへ戻れなくなる。
だから、まずJDCで一周させるBusiness OSを、v0.1、最初の版として考えている。
一つの課題を観測する。根拠と解釈を分ける。取り組むかを決める。製品や説明へ反映する。取得できる反応を見て、次の判断を変える。
その一周を通じて、仕組み自体も確かめたい。
情報の受け渡しに足りない項目はあるか。逆に、使わないObjectを作りすぎていないか。人の確認が必要な地点を見落としていないか。判断のルールが、都合のよい根拠だけを優先していないか。AIの解釈を、確かめずに採用していないか。
仮にJDCの反応が変わらなかったとしても、それだけで、この仕組み全体が無意味だとは言えない。一方、反応が少し良くなっただけで、Business OSの効果を証明したとも言えない。何を変え、何を見たかを残して、次の問いを具体的にしたい。
システムの手間も結果に含める必要がある。観測と記録に時間を使いすぎて、実際に作ることや確かめることが止まるなら、項目や手順を減らすべきだ。
そこからv0.2、v0.3へ直していく。JDCで使えた考え方を、複数の製品へ持ち出せるかを考える。ゲームなら運営やプレイヤーの反応に合わせて補い、複数の事業を扱うなら、時間や資金の配分まで広げていく。
これは、拡大が決まっているという宣言ではない。今の小さな実験を、将来への接続を失わずに進めるための道筋だ。
小さく始めることと、小さいものを最終形にすることを混同しない。
この言葉は、今回の構想で残しておきたい原則の一つになった。
小さく始めれば、実際の仕事へ戻れる。最終形だと思い込まなければ、実際の仕事で分かったことから、仕組みを変えられる。
7. そして、「届けること」の問いが残った
最初にあったのは、アプリを公開したのに、人に届かないという問題だった。
YouTubeの話をきっかけに、発信の重要性を自分の問題として捉え直した。ただ、自分が毎日登場する発信者になる方法は、今の生活には合わなかった。
そこで、公開された市場の情報から現実を学ぶことを考えた。情報の種類を分け、根拠と解釈を分け、製品の判断へつなぐ。その流れが、AGI Cockpitの改修について考えていたことと合流した。
AIをどう動かすかの上位に、何のために動かすかがある。市場を見るところから、戦略、収益の考え方、製品、開発、コンテンツ、届け方、学習までを、一つの循環として扱えないか。
私がBusiness OSという言葉で整理しようとしているのは、その仕事のつながりだ。
まだ、事業を作れるようになったとは言えない。構想を整理した段階であり、JDCを成功した製品として語れるわけでもない。
それでも、「もっと機能を作る」「もっと投稿する」という個別の作業だけで考えていたときより、どこに問いが残っているかは、見えるようになった。
そして、この全体を整理したことで、最初の問題が、もう一度違う形で現れた。
製品を作ることと、届けることの関係だ。
JDCには、誰に使ってほしいのか。最初の10人へ、どう届くのか。そこから100人、1,000人へつながるとしたら、何を確かめればよいのか。
これらは実績の数字ではない。これから設計するための問いだ。
アプリが完成してから、その問いを考え始める順番でよいのだろうか。
「作ること」と同じくらい、「誰にどう届けるか」も、最初から設計する必要があるのではないか。Business OSの地図を描いていた私は、次に、その問いを考えることになった。
前編「AIでアプリは作れた。でも、事業の作り方はまだ分からなかった」
この二回で整理したのは、Business OSに至る経緯と、その最初の地図だ。次の話では、ここに残った「誰に、どう届けるか」という問いを扱いたい。