事業とは、複数の構造をつなぐ設計である。

I. プロダクトではなく、成立する事業を見る

01. 完成した画面より、成立する事業

新しいプロジェクトに参加するとき、私は最初に「何を作る予定か」だけを知ろうとはしない。誰に、どんな価値を届け、その価値がどうやって継続的な事業になるのかを確かめたい。良い画面や優れた機能は重要だ。しかし、使う人がいない、営業が始まらない、運用の体制がないといった状態では、どれほど美しく完成しても価値を届けきれない。事業とはプロダクトそのものではなく、人と技術、顧客と組織、販売と運用の関係がつながって働く仕組みなのだと考えている。

02. 部分最適に見えない依存関係

デザインの変更は見た目の問題に見える。けれど誰を獲得したいかが変われば、伝える価値が変わり、訴求が変わり、必要な機能が変わる。マーケティングと開発を別々に計画すると、広告開始時に伝えたい体験が未実装だったり、リリース後に必要な営業資料がなかったりする。私は部門の業務一覧ではなく、どの決定がどの決定に依存しているかを見たい。チームが専門性ごとに分かれていることと、事業の目的まで分かれていることは違う。

03. 存在する成果物から、存在しない必要条件へ

あるプロダクトチームの初期段階に参加したとき、デザインと開発の成果物はすでに揃い始めていた。一方で、品質保証、アプリ申請、顧客獲得、営業準備、統合マイルストーンなどは整理の途中だった。私は、すでにあるものを評価するだけでなく、本来必要なはずなのにまだ会話されていない要素を探した。画面の完成予定から逆算するのではなく、市場で利用が始まる状態から逆算すると、制作物以外の不足が見つかる。もちろん、見つけた欠損すべてにすぐ着手する必要はない。優先度を判断するために、まず全体を見えるようにする。

04. 言葉の定義からブランドまでがつながる

「良い企業」「良いスカウト」「ハイクラス」といった言葉は、事業の方針を示すが、そのままではチームで異なる意味を持ち得る。具体的な対象ユーザーが定まらなければ、デザインのトーンも、広告で何を訴求するかも決めにくい。たとえば高級感を求めているのか、新しい技術への感度を打ち出すのか。色だけを比較しても解決できない。私はデザインを事業戦略の出力の一つとして捉えている。感性は必要だが、感性を意思決定へつなぐための軸も必要だ。

II. 市場・組織・判断を接続する

05. 市場と接触する順番を変える

開発が終わってから利用企業や候補者を集め始めるのでは、学習の機会を失うかもしれない。サービスの価値仮説があるなら、完成前に顧客へ話を聞き、受け入れ条件を確かめ、先行利用の可能性を探れる。必要に応じて資料やプロトタイプを持って説明する。その反応は、機能の優先順位や訴求を更新する材料になる。私は、作ってから売るという一方向の工程より、市場で学びながら作る循環を重要だと考えている。

06. 誰が何を決めるかを、事業の一部として設計する

事業の停滞は、個人の能力不足によってだけ起きるわけではない。誰が意思決定するか曖昧だったり、議論する会議体がなかったり、仕様変更が文書へ反映されなかったりすると、優秀な人がいても進まない。だから私は、ロードマップだけでなく、判断基準、責任者、連携方法も整理したい。誰かを細かく管理するためではなく、それぞれが自分の専門性を発揮できる状態にするためだ。

07. 私の仕事は、つながっていないものをつなぐこと

自分が営業もデザインも実装もすべて担うべきだとは思っていない。私が力を発揮しやすいのは、構想や人材や技術がすでに存在するのに、全体として十分に接続されていない場面だ。経営者の言葉を要件へ変え、顧客の反応を戦略へ戻し、戦略を優先順位へ落とす。事業を一つの完成品としてではなく、更新され続ける仕組みとして扱いたい。新しいサービスを創ることは、誰かの選択肢を増やす構造を創ることでもあると考えている。

08. 市場投入をゴールにした逆算

プロダクトの完成日をゴールにすると、開発の予定は立てやすい。しかし事業の始まりは、誰かが使って初めて訪れる。仮に年明けの認知拡大を考えるなら、その前に何を試験提供し、いつ企業に営業を始め、どの時点で主要な体験が動いていなければならないのかを整理する必要がある。マーケティング、営業、QA、法務、アプリ申請などは互いに前後関係を持つ。私は、制作物ごとの締切を並べるだけでなく、ユーザーに価値が届く状態から依存関係を遡りたい。

III. 制約と依存関係を設計する

09. 予算の規模によって答えは変わる

経営者が「広告には十分に予算を使える」と話したとしても、それだけでは施策を選べない。数千万円と十数億円では可能な広告媒体、組織体制、検証の粒度がまったく異なる。反対に資金があっても、ターゲットがその媒体に接触していなければ効果は期待できない。私は、予算の大きさを驚きとして受け取るだけでなく、制約条件として捉える。誰に届くか、何を認知してほしいか、利用までの導線はどうなっているか。資金、チャネル、プロダクト体験を一つの設計問題として扱う。

10. 統合を引き受けることと、全部決めることは違う

複数の要素をつなぐ立場に立つと、自然に多くの未決事項が見えてくる。しかし、それをすべて自分で決めてしまえば、専門家の判断を奪ったり、意思決定の集中によって速度を落としたりする。私は、経営判断が必要なもの、技術の専門判断が必要なもの、ユーザー検証で答えを得るべきものを分けたい。自分が行うのは全体の依存関係を示し、決めるべき内容と情報を揃えること。良い統合とは、全員の仕事を抱えることではなく、それぞれが適切な判断を下せる状態を作ることだ。

11. 事業を機能させる「依存関係」の設計

事業計画を立てるとき、私はタスクを並べる前に依存関係を考えたい。企業向けサービスであれば、営業資料を完成させるためには価格や価値提案が必要で、価格を決めるためには顧客が何に対価を払うかを理解しておく必要がある。アプリストアへの申請には動作するアプリだけではなく、審査対応に必要な情報や運用上の準備が伴う。マーケティングに合わせて機能を訴求するなら、その機能が使用可能になる時期を開発と共有しなければならない。ここでの問題は、各部門の努力量ではない。順序を誤ると、前工程の判断待ちが後工程の手戻りを生むことだ。私は大きな予定日を置いたら、そこへ至る条件を逆算し、何が決まらないと何が始まらないかを見える形にしたい。その地図があるだけで、すべてを急ぐのではなく、遅れが全体へ影響する論点を優先できる。

12. 人材サービスで学んだ、両側の価値のつながり

審査制の人材スカウトサービスを考える場合、候補者にとっての価値と、採用企業にとっての価値は同じではない。候補者は自分に合う提案を受けたい。企業は採用につながる候補者へ効率よく接触したい。候補者を大量に集めれば企業の満足度が自動的に上がるわけではなく、企業を大量に集めれば候補者の体験が良くなるとも限らない。だから「質の高いスカウト」という言葉を分解する必要がある。条件の不一致が少ないことなのか、読む価値があることなのか、実際に双方の合意につながることなのか。どれを中心に置くかによって、審査の方法、送信上限、検索機能、通知の設計は変わる。プロダクトの中心概念を決めずに機能を増やすと、それぞれがもっともらしくても、サービス全体として一貫しない。事業設計では、機能を増やすより先に、両側の価値が成立する条件を明らかにしたい。

IV. 統合役を新しい属人化にしない

13. 予算が大きくても、判断は簡単にならない

資金が十分にあると言われても、私は規模と使途を確かめたくなる。広告に投じられるのが数千万円なのか、数億円なのかでは取れる施策が異なる。しかし、予算が増えれば、それだけで適切な広告手段が決まるわけではない。高い年収帯の技術人材に届けたいのであれば、どこで情報に触れ、どんな理由で転職サービスを選び、何を信頼の根拠とするかを調べる必要がある。大型の認知広告が有効な場合も、限られたコミュニティや紹介の方が機能する場合もある。重要なのは、支出額ではなく、仮説を持って配分し、効果を学習できる状態を作ることだ。私は予算という制約条件を定量化しつつ、その使い方を市場の理解から逆算する。お金が多いことと、使い方を知っていることは別だと考えている。

14. 統合役が生みやすい、新しい属人化

事業全体をつなぐ人が一人いると、立ち上げ期は物事が進みやすくなる。一方、すべての判断がその一人に集まると、やがてその人自身がボトルネックになる。私は統合の仕事を引き受けるなら、情報を自分の頭の中に蓄積するだけで終わらせたくない。誰が何を決めるか、どの条件が変われば方針を見直すか、何を根拠に優先順位を付けたかを、他の人が追える形に残す必要がある。そうすれば、各専門家は毎回私に許可を求めなくても判断できる。全体を見ることは、全員の仕事を代わりに考えることではない。互いの仕事が接続する条件を整え、必要な場面で意思決定できる状態を作ることだ。統合の成功は、最後に自分がどれだけ手放せるかでも評価されるべきだと考えている。

15. 経営者と組むとき、最初に確認したい約束

他社の代表と協働するなら、構想の魅力だけでなく、意思決定の仕方を確認したい。事業の最終判断者は誰か。予算を承認するのは誰か。私に期待されているのは助言なのか、実務の推進なのか、チームの統括なのか。成功をいつ、何で判定するのか。これらが曖昧なまま役割だけを広げると、短期的には便利でも、責任の所在が不透明になる。私が提供できる価値は、経営者に代わってすべてを判断することではない。相手の持つ事業資産、業界経験、人材、顧客との関係を理解し、まだ接続できていない可能性を具体的な計画へ変えることだ。そのためには、互いの得意領域と権限を最初に明確にする必要がある。関係を構造として理解することは、信頼を減らすのではなく、長く協働できる土台を作ることだと考えている。

V. MVPから拡大までを一つの地図にする

16. MVPは機能数ではなく、価値の成立条件から決める

初期のプロダクトで機能を削ることは、しばしば単なる開発費の節約として語られる。しかし、私は何を削っても価値が残るかを先に考えたい。スカウトサービスなら、華やかなレコメンド画面を後回しにできても、候補者が信頼できる提案を受け、企業とやり取りできることは必要かもしれない。機能が少なくても、利用の最初から最後まで一つの価値体験が成立していることが重要だ。ここでマーケティングが約束する価値と、プロダクトが提供できる価値にずれがあれば、登録者を増やしても不満が残る。MVPの設計は、開発チームだけで閉じない。顧客を集める人、提供する人、支える人が、同じ価値の最小単位を理解する必要がある。

17. 事業の「勝ち筋」を、複数段階に分ける

市場で大きく勝つという構想があっても、最初の一歩から大規模投資をする必要はない。私は構想を、成立確認、再現性確認、拡大準備、拡大実行という異なる段階に分けたい。初期は特定の企業と候補者の間で価値が成立するかを見る。次に、担当者が変わっても同じ価値を届けられるかを確認する。そこから集客費用や運用負荷を検証し、規模を広げる判断につなげる。大きな目標は重要だが、段階ごとに必要な証拠は変わる。最初の検証で確かめたいことを、将来の完成形で上書きしてしまわないこと。大胆な構想と、足元の条件確認は両立できるはずだ。

18. 統合設計の成果をどう計測するか

事業統合の仕事は、直接の売上として切り出しにくい。私は少なくとも三つの視点で評価したい。第一に、未決事項と責任者が明確になり、判断待ちによる停滞が減ったか。第二に、事業、制作、営業、マーケティングの計画がつながり、後戻りを減らせたか。第三に、市場から得られた情報を次の仕様や戦略へ反映できたか。これらは最終的な採用数や売上の代わりにはならないが、そこへ至る実行能力の改善を捉えられる。私は「全体を見ています」という抽象的な自己説明より、どの接続を直し、どんな判断が前に進んだかという事実を残していきたい。

19. 顧客獲得と開発は、同じ時計で動かない

開発はスプリント単位で成果が見えるが、企業との契約や広告の準備は別の時間軸を持っている。私はロードマップを作るとき、すべてを開発の完了日へ従属させないようにしたい。顧客への接触はプロダクト完成前から可能な場合がある一方、法務や審査、運用体制は事前に一定の準備が必要となる。市場に出す日を決めたら、それぞれの仕事を同じ一枚に並べ、進め方の違いを理解する。チームを統合するとは、全員を同じ作業速度に揃えることではない。それぞれ異なる時間軸の仕事が、必要な時点で合流できるようにすることだ。

20. 事業の設計図は、相手の仕事を軽くするためにある

全体の構造を整理すると、細かな管理項目が増えてしまうことがある。しかし私が目指したいのは、管理のための管理ではない。営業は何を約束できるか、デザイナーは何を基準に選べばいいか、開発はどの仕様を優先すべきか。各専門家が迷わず判断できる状態をつくることだ。設計図が複雑すぎて誰も見なくなるなら、それ自体が改善対象になる。必要な情報を必要な人へ届けるという視点も、全体統合には欠かせない。