
その機能開発、ROIあってますか?| 税理士PdMが考えるSaaS開発のざっくり費用対効果
こんにちは!株式会社ナレッジラボでManageboardのプロダクトマネージャー兼プロダクトオーナーを務めている小野です。
今回は、すべての機能開発についてまわる話であるROIについて、会計専門家の観点で語りたいと思います。
私の自己紹介noteはこちらをご覧ください!
その機能開発、ROIあってますか?
「その機能開発、ROIあってますか?」
このnoteを読んでくださっているPdMの皆さま、経営者からこのような質問を投げかけられて返答に困った経験はないでしょうか?
機能単位でROI(Return on Investment:投資収益率)を計測するのは非常に難易度が高い作業です。私自身も、客観的でロジカルなROIを導き出すのは難しいと感じています。
しかし、ROIの説明はPdMにとって重要な責務です。開発前にざっくりでもROIを見積もっておけば、開発チームの振り返りや検証にも活かすことができます。
ここでポイントとなるのは「ざっくり」という考え方です。正確な数値を見積もることにフォーカスしすぎると、非現実的な前提を置かざるを得なくなり、ROIの計算自体が目的化してしまいます。 このnoteでは、機能開発単位のROIを現実的に計測する方法を解説します。
まずはROIを要素分解
ROIは大きくInvestment(投資)とReturn(収益)に分解できます。
- Investment:機能を開発するための金銭的コスト
- Return:機能から獲得できる収益

Investmentの算出方法
Investment=機能開発にかかる開発コストと定義します。
会社のP/Lにアクセスできる場合、その機能開発を行う単位(部門、チームなど)の月々の概算コストを基準にします。とは言うものの、会社のP/Lにアクセスできる権限を有するPdMは少数派だと思いますので、ざっくり以下の2要素の月々の概算コストを定義しましょう。
人件費(給与手当、賞与、法定福利費、業務委託費など)
通信費(サーバー費用、セキュリティ費用など)
人件費は、エンジニアやデザイナーのヘッドカウントと月額平均給与などから計算できると思います。業務委託費は一般的には人件費からは除外されますが、ここでは計算をシンプルにするために人件費に含めます。
通信費は、月々の概算コストをチーム数などで割った数字を使いましょう。
ここまでで求められた月々の開発コストに開発月数を乗じた金額をInvestmentとします。
Investment = 月間開発コスト × 開発月数
繰り返しとなりますが、ここでは正確な計算を目指さずに、ざっくりコスト感を把握することがポイントです。
機能開発にかかるその他の費用として、たとえば以下のようなものが挙げられますが、これらは固定費的なコスト(厳密には人件費や通信費も固定費として扱われますが、機能開発目線では他の機能開発にリソースを転換することもできるという意味で変動費的に扱います)と整理できるため、ROIの計算要素に入れるべきではありません。
地代家賃
減価償却費
Returnの算出方法
Return=機能から獲得できる収益と定義します。
機能単位で収益を予測、計測する難易度はとても高いと思います。
ROIを考える時に、ここのポイントで詰んでしまうPdMの方も多いのではないでしょうか?
ここでは、Investmentの算出以上にざっくり考える必要があります。
まずは、大胆に収益は売上に置き換えましょう。通常、ROIを計算する際は、売上からコストを差し引いた収益を計算のベースにします。しかし、収益をベースにするということは、その機能開発にかかるコスト(上記のInvestmentに該当しないもの)を見積もる必要があり、これは現実的ではないと考えます。
具体的には、様々な間接費用がこれに該当しますが、開発する機能との直接的な紐づけは難しく(無理やり前提を置けば可能ですが、、)、ここにこだわることの意義はないように思います。
次に、収益=売上を「機能開発起因の新規売上増加(契約増加)」と「機能開発起因の売上マイナス減少(解約減少)」に要素分解しましょう。
さらにそれぞれの要素を以下のように整理します。

「機能開発起因の新規売上増加(契約増加)」は、「新規契約顧客数 × 契約単価」に分解できます。
契約単価はサービスごとに決まっていることが多いため設定は難しくないと思いますが、新規契約数は見積もりが難しいですよね。
当社はtoBのサービスなので、その機能の顧客要望数やセールスへのヒアリングで「ざっくり◯件」という置き方をしています。
「機能開発起因の売上マイナス減少(解約減少)」は、「解約減少顧客数 × 契約単価」に分解できます。
契約単価は上記同様で設定は難しくなく、解約減少数も考え方は新規契約数と同じで、その機能の顧客要望数やカスタマーサクセスへのヒアリングで定義しています。
ここまでで計算した売上はあくまでも月単位の数字であり、永く契約が継続する前提のSaaSにおいては、LTV(Lifetime-Value)に変換する必要があります。
つまり厳密には、「その機能が追加されたことで増加する生涯売上」をROIの算定基準とします。
LTVを求めるためには、「平均契約継続期間(月単位)」の情報が必要です。
既存顧客のデータから求められる場合はその数字を、そのようなデータが手元にない場合は、PdMの感覚で「◯か月」と決め打ちしてしまいましょう。
日頃から数字に触れているPdMであれば、平均契約継続月数の肌感覚があると思いますし、それがなかったとして、ここはざっくり決めてしまうのがいいと思います。
「期待月額売上 × 平均契約継続月数」で得られた金額をReturnと定義します。
Return = 期待月額売上 × 平均契約継続月数
*****
このnote全体のポイントは、「機能起因の新規契約数 or 解約減少数」の捉え方です。ここを精緻に計算しようとすればするほど、多くの不確実な前提を置かざる得なくなります。
突き詰めると、「この機能を開発したらどれだけ契約数が増えて、どれだけ解約数が減るのか」が数字で示されていればよいので、もはや要素分解せずとも「ざっくり◯件!」でもいいと思います。
あくまでも目的は説明可能な(最低限合理的な)ROIを計算することなので、細部にはこだわりすぎないよう、ある程度「えいや」で数字を決め打ちしてしまうのが肝要です。
要素分解ができたら後は計算するだけ
ここまでできれば後はスプレッドシートなどで計算するだけです。あらためて、ROI算出の全体像をツリー構造で示すと下図のようになります。

この例では、以下の要素分解によって、ROIが120%と計算することができました。
ROI:120%
Investment:2,000万円
Return:2,400万円
ROI:120%が意味するところは、「機能開発によって得られるであろう生涯売上がコストを上回っている」状態であり、つまりこの機能開発は高い費用対効果が期待できるといえます。
逆にROIが100%を切ってしまうと、「機能開発によって得られるであろう生涯売上がコストを下回っている」状態であり、機能開発のgo or no-goを冷静に判断したほうがいいかもしれません。
なお、この計算には、機能開発による将来の保守増加、それに伴うエンジニアの人件費投下など、将来に見込まれるコスト増加が織り込まれていません。
したがって、ROIが100%を僅かに超える程度の水準であれば、それらのコストを織り込んだ時に費用対効果が合わなくなる可能性があるため、余裕をもってROIが100%を超えている状態が理想的であるといえます。
さいごに
今回のnoteでは、会計専門家 × PdMの立場で機能開発のROIの考え方を解説しました。
noteの中で繰り返しお伝えしている通り、「ざっくり」計算することが何よりのポイントとしてROIの計算にトライしていただけると幸いです。
ここまで読んでくださったPdMの方には、「数字ばっかりでつまらないな」と思われた方もいらっしゃるかもしれません。私自身もプロダクト開発には単純な費用対効果だけで説明できない要素や判断軸、魅力が詰まっていることは理解しているつもりです(費用対効果ばかりを考えていてもいいプロダクトは作れないですよね)。
しかし、プロダクトがビジネス上の課題を解決するものであること、また、プロダクト開発がビジネスの一部として機能していることを前提として置いたとき、ビジネスジャッジの軸としてROIは無視できない存在だと思いますし、PdMはその説明責任を負っていると考えます。
特に資源の少ないスタートアップにおいて、開発にかかるコストは相対的に大きく、その判断一つで会社の方向性に影響を与えると考えると、多少数字にまみれてでも説明責任を果たす努力は怠るべきではないと思います。
私たちはプロダクト開発を通じて日々経営管理や管理会計と向き合っています。少しでもManageboardの開発に興味をもっていただけた方は是非下記採用サイトからご連絡ください!
https://recruitment.knowledgelabo.com/
(この記事を書いた人)
小野敦志
日米の会計事務所勤務を経て、Big4税理士法人にて国際税務アドバイザリー業務に従事。2020年7月に株式会社ナレッジラボに入社し、現在はプロダクトマネージャーとしてManageboardの開発に携わる。
税理士 / 米国公認会計士 / 米国公認管理会計士。