事業戦略があっても、何を作るかは決まらない

なぜこれを記録するか

新しいプロダクトをつくるとき、事業については多くのことが決まっています。

• どの市場へ参入するか
• どの顧客を獲得したいか
• どんな業務課題を解決するか
• どのように売上をつくるか

ところが、これらが決まっていても、開発が始まると「結局、何をどのようなプロダクトとしてつくるのか」が揃っていないことがあります。

個々の要件には理由があり、必要だと話した人もいる。それでも、全体を通して使うとユースケースがつながらず、なぜ今この機能をつくるのかも説明しにくい。事業戦略はあっても、それをプロダクト上の選択へ変換する過程がない。その結果、プロダクト戦略が形成されていない状態です。

答えている問いが違う

事業戦略が答えるのは、この事業をどこで、どのように成立させるかです。

• どの市場と顧客を選ぶか
• どんな価値を提供するか
• どう収益を得るか
• 何を競争優位にするか
• どの経営資源をどこへ配分するか

プロダクト戦略が答えるのは、その勝ち筋を、どのようなプロダクト上の選択で実現するかです。

• 誰の、どの場面の課題を中心に置くか
• 利用後の業務をどのような状態へ変えるか
• プロダクトが業務のどこまでを引き受けるか
• 何を共通化し、何を運用や個別対応に残すか
• どの能力を、どの順序で獲得するか
• 何をつくらないか

どちらも「何をするか」を決めるため、同じものに見えます。しかし、事業としての選択からプロダクトの具体的な形が一意に導かれるわけではありません。

「大企業を獲得する」と決めても、最初に強化すべきものが権限管理なのか、監査なのか、既存システムとの連携なのかは決まりません。同じ大企業でも、利用者と購買者、導入を阻む理由、成立させるべき業務が違えば、必要なプロダクトも変わります。

事業戦略はプロダクト戦略の制約と目的を与えます。しかし、プロダクトの形までは決めません。

間にあるのは翻訳ではなく、選択

事業側から届く要求を、表現だけ変えて開発要件にすることがあります。

大企業を獲得したい
だから管理機能をつくる

解約率を下げたい
だから利用を促す通知をつくる

AIを競争力にしたい
だから生成AIを組み込む

これらは仮説としては成立します。しかし、前半から後半が自動的に導かれるわけではありません。

その顧客の獲得を妨げているものは何か。解約につながっている未完了の業務は何か。AIに任せることで、誰の判断がどう変わるのか。その間を調べ、複数の可能性から一つを選び、捨てた選択肢を明らかにする必要があります。

したがって、ここでいう「変換」は単なる翻訳ではありません。

事業上の目的を制約として受け取り、顧客の業務とプロダクトの特性を通して、実現方法を選び直すことです。この選択のまとまりがプロダクト戦略になります。

変換がないと何が起きるか

プロダクト戦略を介さず、事業要求から直接開発へ進むと、個々には正しく見える機能が増えていきます。

要件は正しいのに、ユースケースがつながらない

それぞれの画面や機能には依頼者がいて、必要性も説明できます。しかし、利用者が一つの業務を最初から最後まで終えようとすると、途中が欠けています。

機能単位では要件を満たしていても、プロダクト全体では価値を届けられません。

優先順位が、声の強さに置き換わる

何を目指すかについて共通の選択がなければ、優先順位を判断する基準もありません。その結果、重要な顧客から言われた、商談に必要、期限が近い、といった個別の事情がそのまま順番を決めます。

これらの事情は無視できません。ただし、毎回それだけで決めるなら、判断は蓄積されず、新しい要求が来るたびに順番が変わります。

UXと品質の合格条件が決まらない

誰のどの業務を成立させるかが曖昧なままでは、「使える」とはどの状態かを定義できません。画面が存在し、操作でき、仕様通りに動くことは確認できても、業務を完遂できるかは確認されません。

品質の悪さは、プロダクト戦略だけで生じる問題ではありません。レビュー、検証、受入条件、開発プロセスにも原因があります。それでも戦略がなければ、何を品質として守るべきかという基準を置くことさえ難しくなります。

エンジニアリングが要求の受け手になる

プロダクト上の選択が共有されていなければ、エンジニアは届いた要件を前提に実現方法を考えるしかありません。これは職種の力が弱いからではなく、問いを返すための共通の基準がないために起きます。

技術的な選択肢を出せても、どの顧客価値を優先するかが決まっていなければ、要件そのものを変える提案にはつながりにくくなります。

初期のプロダクト戦略で決めること

プロジェクト初期に、将来の仕様をすべて決めることはできません。不確実な状態で必要なのは、完成形を詳細に描くことではなく、現在の判断を揃えるための仮説を置くことです。

最低限、次の問いには答えられる状態にします。

1. 中心となる利用者と業務は何か
   顧客企業という単位ではなく、誰がどの状況で行う何の業務を成立させるか。

2. その業務をどのような状態へ変えるか
   機能を提供した状態ではなく、利用者の判断や作業、結果がどう変わるか。

3. プロダクトはどこまで責任を持つか
   プロダクトで担う範囲、人の運用に残す範囲、初期には扱わない範囲を分ける。

4. どの順序で能力を獲得するか
   機能の納期だけでなく、どのユースケースを先に成立させ、その後どこを深くするか。

5. 何をしないか
   単なる後回しではなく、現在の戦略では対象にしない顧客、業務、解決方法を明らかにする。

6. 何をもって仮説が正しかったとするか
   売上だけでなく、対象業務が成立したことを観測できる条件を決める。

これは固定された正解ではありません。具体の業務を知り、利用を観測し、反例が出れば更新します。ただし、更新される可能性があることと、最初から何も選ばないことは別です。

ロードマップや仕様との境界

プロダクト戦略にすべてを書き込むと、今度は更新できない巨大な計画になります。戦略が決めるのは、個々の画面や操作ではなく、複数の判断を同じ方向へ揃えるための選択です。

• プロダクト戦略は、誰のどの業務を、どんな価値と責任範囲で変えるかを決める
• ロードマップは、そのための能力をどの順序で獲得するかを置く
• プロダクト要求は、各段階で成立させるユースケースと条件を具体化する
• 設計と実装は、それをどのような体験と仕組みで実現するかを決める

境界は完全には分かれません。実装可能性を知って戦略が変わることも、利用者を観察してロードマップを戻すこともあります。重要なのは、上から下へ一度だけ渡すことではなく、異なる問いを混同しないことです。

プロダクト戦略かを確かめる

事業目標や機能一覧を、プロダクト戦略と呼んでいないかを見るための三つの問いがあります。

1. プロダクト変化テスト — その戦略を読んで、利用者の業務やプロダクトがどう変わるかを説明できるか。
2. 棄却テスト — 新しい要求に対して、「今回はつくらない」と同じ理由で判断できるか。
3. 順序テスト — なぜ機能Aが機能Bより先なのかを、期限や依頼者以外の理由で説明できるか。

「売上を伸ばす」「大企業を獲得する」だけでは、一つめに答えられません。機能の一覧だけでは、二つめに答えられません。納期の一覧だけでは、三つめに答えられません。

三つに答えられるなら、少なくとも事業上の目的からプロダクト上の選択への変換は始まっています。

誰が決めるのか

事業戦略とプロダクト戦略を分けることは、組織を分断することではありません。

事業を担う人は、市場、顧客、商流、収益、契約上の制約を持っています。デザイナーは、利用者の行動と体験を具体化します。エンジニアは、技術によって可能になる選択と、その継続的なコストを明らかにします。PdMはそれらを受け取り、プロダクトとして一貫した選択にまとめます。

誰かが一人で正解を考えるのではなく、持っている事実と反例を持ち寄る。ただし、全員の要求をそのまま足したものを戦略とは呼ばない。協働することと、選択の責任を曖昧にすることも別です。

事業戦略はプロダクト戦略の入力であり、プロダクトから得た学習は事業戦略を更新する入力になります。二つの間には上下ではなく、往復があります。

まとめ

• 事業戦略とプロダクト戦略は、同じ目的に向かいながら異なる問いに答える
• 事業戦略は、プロダクトをつくる目的と制約を与えるが、プロダクトの形までは決めない
• 両者の間に必要なのは言葉の翻訳ではなく、顧客の業務を通した選択である
• その選択がなければ、事業要求が直接開発へ流れ、個々には正しいが全体ではつながらない機能が増える
• 初期のプロダクト戦略では、対象業務、目指す変化、責任範囲、獲得する順序、しないこと、検証条件を決める
• 事業とプロダクトの間には上下ではなく往復がある。ただし、プロダクトとして選択する責任は必要になる