こんにちは。PMと事業開発を担当している中村です。このブログは、3月の estie PM Meetup に向けたブログシリーズとなっており、「PM Blog Week」第3弾5日目のブログです。
<<前回ブログはコンサルタントがシニアPMになるまでに感じた壁 - estie inside blog>>
今回はPM Blog Weekと謳っておきながら、エンジニアに向けた事業計画の読み方を解説してみようと思います。
一見PM向けではないように思うかもしれませんが、PMの最も大事な仕事の一つに事業とプロダクトの円滑なコミュニケーションを行うことがあります。そのためにロードマップがあったりしますが、ロードマップの元となる事業計画をエンジニア自身が理解できるようになることで、事業計画達成のためにやるべきアイデアが増えたり、開発スピードが上がり、プロダクト開発のスループットを今の10x以上に上げることが可能となります。
プロダクト開発のスループットを高めることでPMとしてのアウトカムも増えることに繋がります。エンジニアとの関わり方に困っているPMや、自分の実装している項目がどう事業貢献しているのかわからないエンジニアは、こちらのブログを読んでいただいて、エンジニアとPMで事業計画をベースとしたコミュニケーションを行う土台を作ってみてください！
BtoBの事業計画ってそもそもなにか？
今回はBtoBプロダクトという前提で事業計画の読み方を解説してみます。
本題ですが、そもそも事業計画を読んだことがありますか？
エンジニアとして優秀な方でも、事業計画を読む機会は意外と少ないように感じます。
“商談・定例に同行する”、“営業と話をする”といった目の前の顧客と向き合い、今必要な価値を提供する振る舞いを行うエンジニアを見かける機会が多く、この状況は非常に素晴らしいと思っております。
次のステップとして、事業計画を読み解くことができると、1年以上先のより長期の課題についても触れやすくなり、よりプロダクトで提供できる価値を大きくすることができます。
その理由として、事業計画には「どんな技術的課題」を「いつ」解決しなければならないのかが記載されているからです。
事業計画と聞くと、なにか大層なものをイメージし、実際に事業計画シートを見てみると複雑そうな数式が組まれており、少し小難しく思うかもしれません。
でも実は、事業計画はすごくシンプルな構造になってますので、アレルギー反応を起こす必要はありません。
例として、次のような事業計画を見てみます。
今回は説明のために下記の設定にて事業計画を作ってみました
- プロダクトは利用回数に応じた従量課金モデルのプロダクト
- 利用回数は社員数（≒ユーザー数）に比例する
セグメントは顧客のセグメント（業種）を指しており、下記の会社規模にてセグメントを分ける
- セグメントA：社員1,000人以上
- セグメントB：100~999人
- セグメントC：100人未満
- 上記の通り、セグメントAは想定利用回数が多いためARPAは相対的に高く、セグメントCはARPAは相対的に低い
事業計画（画像1枚目）がどのように作成されるかというと、MRRは単価×契約（社）数で計算されますので、下記のような想定で契約が増えていく計画となります。
実際にはプロダクトが複数あったり、事業によってはセグメントごとに単価が異なったりしますが、基本的には上記のような縦軸をサービス/セグメントごとの売上、横軸をスケジュール（契約タイミング）の2要素と、シンプルな構成まで分解することができます。
上記事業計画のうち、作成者が可変なものは2つあります。
それが“いつ”、“何社”導入するかという変数です。
今までの実績を加味したり、市況を見たりもしますが、正直キメの問題でもありますので、作成者の魂を持って「えいや！」と刻み込まれます。
ここには事業計画作成者（多くは社長や事業責任者だと思います）が絶対に達成できなければ死ぬ（意訳）覚悟が込められております。つまり事業計画は経営者の魂のメッセージなのです。
そういった覚悟を読み取り、応えることは営業だけではなく、PMやエンジニアもプロとしての当然の姿でしょう。
事業計画でエンジニアが見るべき箇所１「0→1に変わる瞬間」
事業計画でおそらく一番上の目立つ場所にあるMRR（ARR）はあまり見なくていいと思います。金額のインパクトを見たとして、1年後にMRR26百万のプロダクトにするにはどうすればいいか？と思考するのは難しすぎます。
ではどこを見ればいいかというと、まずひとつは社数が0→1に変わる瞬間です。
今まで0だったということは、営業的観点である可能性はありますが、基本的には対象セグメントに対して目指す単価の価値を提供できるプロダクトになっていないからです。
ここで”1”を実現するには、それまでに価値ある機能を実装、つまり対象セグメントに対するMVPを完成させる必要があります。
上記例でいうと、まず見るべきは5月のセグメントAの“1”です。多くの場合はセグメントによって重視するポイントが異なる事があるため、今すでに契約をできているセグメントCの顧客に向き合うのではなく、まだ見ぬ顧客のセグメントAと向き合う必要があります。また機能を実装してすぐ契約を取れるわけではなく、どんなサービスでも営業のリードタイムがあるため、最低限1ヶ月前までには実装完了をしたいところです。
今時点が1/1だとすると、3月末の”1”を作るには早急にセグメントAのユーザーのヒアリングをしたり、業務フローを深ぼったりと、セグメントAへのディスカバリーが最優先事項となります。
事業計画でエンジニアが見るべき箇所2「連続して加速度的に増加している箇所」
例示した事業計画を見たとき、一箇所違和感がある箇所があるかと思います。
黄色の部分、契約社数が急増しております。
セグメントAは四半期に1社、セグメントCは毎月5社ずつと一定の数字での積み上げとなっております。
おそらくですが、セグメントAは大きな会社なので契約に至るまでの合意形成にかなり時間がかかり、セグメントCに対しては一定の営業リソースで安定した契約を獲得する算段がついているのでしょう。
なのでセグメントAとセグメントCについては営業を信じて背中を預けることとします。
一方セグメントBを見てみると、6月に契約を獲得以降、倍々で契約社数が増えております。これはMVPを超えて、PMFまで達成させるんだという魂を感じます。
つまりは最初にセグメントAへのMVPをなんとか作りきったあと、セグメントBのMVPを作り上げ、そのまま速やかにセグメントBへのPMFにむけた検証を進める必要があるのです。
6月以降は契約してくれたユーザーに真摯に向き合い、他の要望も聞きつつにはなりますが、セグメントBのユーザーの声を優先して聞いていくことの重要性が高いことがわかります。
事業計画でエンジニアが見るべき箇所3「1年後の契約状況」
今まではその時々で優先すべきことを読み解いてきましたが、一歩下がって1年後のプロダクト状況を見てみましょう。
1月時点では契約社数は1、MRRは50万の事業ですが、1年後には契約社数124、MRRは26百万円と圧倒的成長をしております。
そうした場合、今の技術基盤、インフラ、コードはその利用数、障害発生による損出に耐えられる設計になっているでしょうか？
技術的負債や技術選定はその時々での判断になると、顧客要望が来た場合には優先度が下がっていくことはよくあることではないでしょうか？ですが中期的な視点で事業計画を読み解くと、いつまでにどういう開発基盤になっていなければならないかはエンジニアの皆さんのほうが寧ろ解像度高く見通せるかと思います。
細かにつついたり、実際の事業計画を読もうとすると他にも見るべき箇所はあるかもしれませんが、私としては上記3つさえ押さえていれば十分に事業計画を理解した、つまり事業計画を作成した経営チームからの魂のメッセージを受け取ったことになると考えております。
まとめ・最後に
今回はエンジニアにむけた事業計画の読み方をざっくりと解説してみました。
事業計画は事業計画作成者の魂のメッセージです。その魂を開発チーム全員がプロとして読み取り、応えていくことで強固なプロダクト、そして強固な会社になっていくと考えております。
またPMは事業計画を読みながら、ロードマップに落とし込んだ上でエンジニアとコミュニケーションを取っているかと思いますが、エンジニアが事業計画を直接読み解くと、PMの発想になかったロードマップを描いてくれたりと、より事業計画達成の確率が上がります。
ぜひ事業計画を自分に関係ないものと思わず、経営者の魂に直接触れることで、みんなでいいプロダクトマネジメントを実現していきましょう！
estieでは、上記のように開発チームそれぞれが事業計画を達成する意識を高く持ったチームとなっておりますので、ご興味ある方はぜひ弊社への応募をお待ちしております。
▼採用のご案内はこちら
estie PM Meetup #5、2025年4月8日（火）に開催決定！
プロダクトマネジメントを学びながら、estieのメンバーと交流しませんか？興味のある方はぜひご参加ください！
