プロダクトマネージャーに必要な財務視点とAI投資の考え方 製品価値を最大化するための経営的思考の必要性

プロダクトマネージャーに必要な財務視点とAI投資の考え方　製品価値を最大化するための経営的思考の必要性

【3行要約】

・プロダクトマネージャーは顧客体験やKPIに注力する一方、財務構造への理解が十分でないことがあります。

・DMM.com副本部長の石垣氏は「経営層はP/L、B/S、キャッシュフローなど企業価値を重視している」と指摘。

・PdMは財務的視点を持ち、AIエージェント活用による生産性向上と運用工数削減の視点を取り入れていきましょう。

施策の効果・ユーザー体験をより多角的に話せるようになるために

石垣雅人氏：よろしくお願いします。このセッションでは、プロダクトの話とかはあまりしなくて、プロダクトマネージャーにとってプラスαになる話というところで、ソフトウェアの資産と、あとはAIエージェント系の話ができればなと思います。

あらためて石垣と申します。今はDMM.comで、主にプラットフォーム系のところの副本部長をしたりとか。あとは全社的に「AIエージェントの投資対効果をどうを測っていくのか？」とか「ポリシーは、どうするんだっけ？」みたいなところをやっているような人間になります。

（DMMは）だいたいグループで従業員が5,000名ぐらいいるような会社です。社内の中でクリエイター組織と呼ばれている、PdMとかPMとか、エンジニア、デザイナーみたいな者が、だいたい1,300名ぐらいいるような母体になっております。

今日話すことと、ペインみたいなところに関しては、視野を広げる入口のきっかけになればいいかなと。PdMとか、PMもそうですけども、「施策の効果はどうだったんだっけ？」とか「ユーザー体験は、どうだったんだっけ？」みたいなところの落としどころを、もうちょっと多角的に話せるようになるためにはみたいなところで、話せればなと思います。主に財務的なところで「どうストーリーを持たせるか？」というところを話せればなと思います。あとは「AIの投資」ですね。

アジェンダとしては3つ用意しております。まず「財務視点とは何か？」というところと、あとは「ソフトウェアの資産の観点」と、あとは「AIエージェント」のところで、3つ立てでやっていければなと思います。

前提知識としてのソフトウェア資産というものは、どういうものであるべきか？

場合によっては「ソフトウェアを作っていない」というPdMの方も、もちろんいらっしゃると思ってはいるんですけども、大前提、ソフトウェアを作っているという前提に立った時に、「前提知識としてのソフトウェア資産というものは、どういうものであるべきか？」を考えなければいけないというところがあります。

もちろんPdMもそうですが、エンジニア、デザイナー、クリエイターが作ったものは、作って終わりではなくて。会社としてはP/LとかB/Sとか……。B/Sという観点で、資産として乗っかってくる。

会社によっては、PdMが「P/Lは見ているけれども、バランスシートはそこまで見てないよ」というところもあるかなと思っていますし、そこまで権限がないというところもあったりすると思うので、概念的な話にはなるかなと思っているんですけども。

ソフトウェア資産になるもの・費用になるもの

物を作ったりとか、それに基づく会議をしたりとかという時に、その判断軸が「将来に収益獲得または費用削減が確実と認められる」場合は、作ったものはソフトウェア資産として計上されます。

そうじゃない場合は費用化とか。わかりやすくいうと、経費としてドンッと落とされるという意味なんですけれども。

（スライドを示して）左下の図で開発中のところですね。例えばソフトウェア仮勘定ということで、例えば1,000万円のものを作っている開発中の時は、だいたい人件費なんですけど、（開発が終わると）そこがB/S上に1,000万円ボンッて乗っかってくる。もしくは、人件費としてP/L上で引かれてくるというところがあると思います。

そこから「これは資産価値があるよね」というもの、わかりやすく言うと「物作り系は全部資産化です」ということで、それに基づかないマーケとか、物じゃないものに関しては費用化するんですが、資産化するものに関しては、リリースしてから資産計上する。

例えば1,000万円のものを作った時には、5年かけて償却していく。つまりB/S上は200万円ずつ引かれていく。実は1,000万円（一気に）引かれるわけじゃないんですね。B/S上はそういうふうなかたちで表現される。キャッシュフロー的には1,000万円の人件費を払っているので、もちろん引かれちゃうんですけど。

バランスシートやP/L上は、そういったかたちになっているというものが、減価償却と呼ばれているものです。例えば、車って5年くらい持つから、5年かけてちゃんと価値を計算していかなければいけないというところから出てきた（考え方です）。昔はこういうことはなかったらしいんですけれども、ちょっと前から出てきたところです。

（スライドを示して）逆に言うと、右下の費用化というところは「開発したけれども価値が……」（というものです）。会議とかもそうなんですよね。ものに捉われない工数の使い方のものだと、基本的に費用化になってきて。1,000万円を使ったら、その翌年とかに1,000万円引かれるというバランスシートの計算になります。

資産化するのと費用化するのでは、どちらが良いのか？

これはちょっと複雑ではありますが、「じゃあ資産化するのと、費用化するのって、どっちがいいのか？」という話になってきて。

これはごまかせるものではなくて、国税庁が出している指針に沿って「資産化するものづくりをどれだけできているか？」というところに捉われるので、嘘はつけない領域なんですけれども。

資産化すると、基本的には先ほど言った「1,000万円かかるものが、200万円ずつ5年かけて償却していく」ので、利益幅が増えますよね。売上とコストに対して、コストが1,000万円じゃなくて200万円なので。つまり、そこの利益に対して法人税がかかってくるので、法人税が増えてしまうことになります。

1,000万円の30パーセントじゃなくて、200万円の30パーセント、200万円の30パーセント、200万円の30パーセントって、どんどんラダー式になっていくので、増えます。

逆に費用化は、1,000万円がドンッと引かれちゃうので、利益幅が減る。1,000万円かけたら1,000万円減るので。そうすると税収が減るんですけれども、いきなりドーンッとくるというところがあります。

これは大企業とスタートアップではいろいろと観点が違うんですけれども、ソフトウェアのところでいったんそういう前提知識に立った時に、こういうところに興味がある人は、国税庁の（サイト）を見に行ったりとか、（スライドに記載した）右の研究のところをいろいろと見に行ったりすると、より理解が深まります。

PdMに欠けがちな財務諸表の視点

というところで、前提が長くなってしまったんですけれども、そうなってきた時に「PdMに欠けがちな財務諸表の視点って何か？」でいくと、やはり「顧客に向き合っている」とか「UXをやっているところ」とか「KPIに向き合っている」とか、外向けの価値は高いんですけれども、内部の財務構造って捉えにくいよねというところがあります。

「経営と話がズレるか」はその環境によると思うんですけど、やはり、その価値を持っていると非常にいい。PdMの1個上の、事業責任者とか経営層というところに、より近づいてくるのかなと思っております。つまり経営が見ているのは、単年のP/Lとか、その単一の施策というよりかは、P/Lとか、B/Sとか、キャッシュフローとかの企業価値の部分を見ているという話になります。

B/S的な視点をプラスαで持っておく

例えば、Aサービスでも何でもいいんですけれども、「1,000万円でA機能を作ろう」とします。工数10人月×単価100万円ぐらいだとして、1,000万円でA機能を作ろうと試算した時に、（スライドの）左下のPdM的な視点でいくと、「1,000万円に対して顧客価値がどれだけ生まれたのか？」とか「狙ったKPIに対して、どれだけ資産価値があるのか？」とか「（どれだけ）機能優位性が上がったのだろうか？」というところがあると思うんですけど、B/S的な視点をプラスαで持っておく。

資産化するのであれば、1,000万円を5年回収する前提で、先ほどもお話ししましたけれども、「200万円で償却が続くよね」と。逆にリリースして価値が生まれなかったら、5年間この負債を背負っていくことになるんですね。財務的にはそういうところがあったり、費用化だったら今年の利益が1,000万円圧迫しちゃうよねというところがあると思います。

この資産という観点でいくと、作る前と作っている時と、リリースしたあとだとお金の流れが変化するというところは、どうしても捉えなきゃいけなくて。（スライドを示して）下の図でいくと、企画に500万円かけました。それを「作るぞ！」って決めて、「計画から開発まで1,000万円でやりました」となったら、企画の段階はまだものを作ってない状態なので、基本的に費用化でいいんですね。資産化しないような費用になります。

逆に「何を作るぞ」って決まってから、会議とか設計とか、デザイン、エンジニアで1,000万円かかったものというのは、資産計上、つまり減価償却で5年かけて償却しなきゃいけないとかになってくると思います。

リリースした時に、例えば「単年の施策効果が1,000万円でした」となってきた時って、普通は「これを見るとリリースまでに1,500万円かかっているな」と見えるというか、実際にそうでもいいんですけど。B/S的な観点でいくと、費用的な企画のところの500万円は単年で償却、費用計上されてしまいます。

逆に資産というものは、1,000万円を5年かけるので、マイナス200万円と捉えることもできます。つまり、コストというのは1,500万円じゃなくて、700万円という見方もできる。ここの回収期間、Payback Periodみたいなところは、1,500万円でやったほうが正しいというケースもあります。

会社の事情的には「翌年、Aという機能を作った時の実際の資産的なところは700万円だよね」というところで、「単年施策効果としてはプラスじゃん」と捉えることもできるんですが、これは別に確実に正しいわけではなく、会社の状況にもよるところがあるので、会社の財務の人とかに聞くっていうのも、ぜんぜんありかなと思います。

プロダクト寿命と資産寿命は一致しない

ここからはもうソフトウェア資産の勘所みたいなところがあるんですけれども、2つ目の「プロダクト寿命と資産寿命は一致しない」というところがあって。先ほども言ったとおり、プロダクトとしては2年間で終了したいんだけれども、作ってしまったら、それは5年かけて償却されてしまう。資産がずっと200万円ずつ引かれてしまうというのが、負債としてどんどん溜まってくるというところがあります。

テクニックの話をすると長くなってしまうのでアレなんですけど。例えば20万円以下だと資産計上対象のものづくりなんだけれども、費用化してもいいとか。そういうテクニックはあるんですけど、これはTips的に書いてあります。

「意味があるものをどう作るか？」により観点がいきやすい

PdMとしては、意味のないものを作り続けちゃうと、UIとかでも「いろいろなものがバーッとあると見にくいよね」とか「ユーザー体験が悪いよね」とかがあるんですけど、（そこに）プラス、P/L・B/Sも圧迫してくるという観点も持っておくと、より「意味があるものをどう作るか？」に観点がいきやすい。

というか、「こういうふうにPdMから語られたら、コイツすごいよな」と思うようなことにはなってくると思います。なので、使われない機能とか、停止サービスとかもB/Sに乗っかってくるというところが（理解しておくと良いところとして）あります。

ソフトウェア資産の蓄積と売上の軸は非常に難しい

これもちらかというとエンジニアリング寄りすぎるところはあるんですけれども、やはりソフトウェア資産の蓄積と売上の軸というのは非常に難しいなと思っていて。（スライドを示して）これは微分・積分で書いてあるんですけど、真ん中にあるやつがB/Sで、一番右にあるのがP/Lですね。エンジニアが開発しているものって、どちらかというと売れるものを作っているんですけど、かたちとしてはP/Lに乗っかるわけではなくて、バランスシートに乗っかってくるんですね。資産として乗っかってくる。

それを営業とか、マーケットとかが物がある状態で売るので、P/Lに跳ね返ってくるという構造になってくる。そうすると、一番右のキャッシュインのほうが時間軸としては短かったり、売上に直接的だったりするので「いいよね」となりがちなんですけど。

資産として使ったものの効果が生まれるというところまでいくためには、時間軸が長かったり、売上に間接的なところがあるので。エンジニア的に「負債脱却したいです」とか、いろいろあると思うんですけども。

真ん中の、資産をちゃんときれいにするというためのところがあるんですけど、それは直接的に売上が上がるわけではなくて、資産をきれいにすることで、右のほうの営業とかマーケとかをがんばるために整理をしているという観点を忘れていなければ大丈夫かなと思います。

AIエージェントの投資対効果をどう捉えるか

ここからAIの話になります。「AIエージェントの投資対効果をどう捉えるか？」というところを最近はずっと考えています。はっきり言えるのが、PdMの方で組織マネジメントをしている方。「来月リリースなんですけど、人が足りないから人を入れたいなぁ」という、そういう権限を持っている方はよくわかるかなと思うんですけども、人でスケールする時代はそろそろ終わってくる。人で生産量を確保する時代って、そろそろ終わってきているというところがあります。

人を採用するのと、開発系のAIエージェントにかけるコストというのが、やはりP/L上、かかるコストのかかり方が違うというところがあります。人件費は固定費ではありますけれども、AIでは簡単に開発のリソースが確保できるというところがあるので、そこはいろいろ変わってくるかなと思います。

（スライドを示して）下の図でいくと、700万円の人を採用するというと、P/L上、人材関連費的なところで採用費もかかりますし、リードタイムもかかります。給与、法定福利費しかり、その他ライセンス費用などがボーダーにかかってくるんですけど。AIエージェントみたいなところを、今いる従業員にくっつけてあげるというのは、どちらかというとライセンス費用になってくると思うんですね。ここの費用計算は、それぞれ違うかなと思うんですけども、やはり時間軸がぜんぜん変わってくるというところがあるかなと思います。

人件費をどう捉えるかを真剣に考える人事戦略と取る必要がある

最近思っているのは、AIエージェントって、けっこう人の代わりというか、（人の代わりとして）開発はしているので、あらためて「人の人件費をどう捉えるか？」というところが非常に大事かなと思っていて。つまり、（固定費として）1,000万円の人が、「1,000万円の価値があるんだっけ？」というのを真剣に考えなきゃいけないような人員戦略を取らなきゃいけないよなと思っています。なので、そこもあらためて考え始めているということになります。

ここは投資対効果を測る前提知識的な生産性ツリーの話なので、バババッと言ってしまうんですけど、「DMMの場合はこういうふうに考えています」というところがあって。

Budget、人件費があった時に、そこに対する投資の投資工数というところでいくと、新しい価値に張れる工数。新規で開発するとか、エンハンスする、既存の価値をグルグルする、回収するみたいなところと、Opsのところがあります。会議とか、障害対応とか、アカウントの発行とかがある。そこをまずLookerで全部可視化しているところがあったりとか。そこから新規開発のところをブレイクダウンしていくと、基本的にはそれぞれの施策工数とか工期。

「Aのプロジェクトは10人月を5ヶ月で終わらせました」とか「1人月を0.5か月で終わらせました」という、プロジェクトの工数・工期って呼ばれるストリームがあって、そこからまたブレイクダウンをすると、そのプロセスとしては開発があって、設計があって、デザインがあって、QAがあってみたいなところを全部Lookerで出しているというところになります。

これを勤怠情報とともに「1日何をしたか？」を全部Bigqueryに流して、それをLookerで可視化しているという前提に立った時に……。（スライドを示して）これは細かい図なのでそんなに見なくても大丈夫なんですけれども、AIの投資対効果を考えた時によくあるのが、「前は10人月で終わったものを、AIエージェントを使って5人月で終わらせましょう」みたいなものが、まず1つあります。

先ほど言った、新しい価値を張れるようになる工数というのは、まさにこの開発のバリューストリーミングみたいなところなので、非常に時間がかかります。

（そうではなくて）どちらかというと、今はOpsのところ。例えば運用したりとか、管理したりとか。DMMで9月とか2月とかに管理コストがバッと増えていて「これは何かな？」と思っ（て見てみ）たら、みんな目標を書いているんですね。何十人月みたいなところに1,300人もいるとなっていて。

「そこの工数をAIに置き換えたら、新規サービスが何個作れるんだ？」という話になってくるというところがあるので、基本的には一番下の2のところなんですけど、「生産性を1.5倍にしたいな」という時には、Opsの工数をAIエージェントに置き換えて、余剰工数みたいなものを新規にどんどん投資していくほうが、もしかしたら筋がいいかもしれないなぁと最近思っているところです。

AIに置き換えられるかをマッピングして検討する

（スライドを示して）イチ組織のところなんですけど、DMMは管理工数みたいなところが、だいたい40パーセントぐらいあります。体感は「すごく多いな」と思います。PdMからしたら、エンジニアがそこにいるんだったら全部（新規）開発に割けているんだろうと（思うと）思うんですけど、実は60パーセントぐらいしか開発に割けていなくて。

40パーセントは、既存のシステムの運用とか、障害対応とかに割いているというところが例としてあります。「ここはどうしたほうがいいかな？」というところがあるので、先ほど言ったLookerのデータを出しつつも、スプレッドシートで「実際に何をしているの？」というところを（出しています）。

例えば組織管理においては、勤怠の承認をしていたり、採用面接をしていたり、評価対応とか、会議の議事録を取っているとか。いろいろとバーッとあるので、それを一つひとつ「AIに置き換えられるか？」をマッピングしていって置き換えていくというところを、最近はやろうとしております。

ソフトウェア資産に基づくB/Sの観点を持っておく

時間もアレなので、まとめです。今回はプロダクトマネジメントというよりかは、プロダクトマネージャーの視野を広げるきっかけというところで、ソフトウェア資産のところに基づくB/Sの観点は持っておくとすごいなというか、「経営的な観点がわかっているな」とか「財務的な観点がわかっているな」と（思われると）いうところの運びにもなりますし、お金の構造を理解するきっかけにもなるとは思いますので。興味があればぜひいろいろと調べていただくと、よりよい体系になるかなと思います。

あと、AIの投資においては「開発を早くする」というアプローチもそうなんですけど、「Opsのところをどう捉えていくか？」というところをできればと思っています。ご清聴ありがとうございました。

関連記事

管理職が今すぐ捨てるべき3つの「思い込み」　脱・完璧主義がもたらす効率的なマネジメント術

リスクが低い目標を優先、期中で戦略を変えられない…　目標の達成度で評価を決める制度の落とし穴

チームが嫌う「不安定さ」の正体　「嫌われたくない」が手放せない上司のNG習慣