16
0

More than 1 year has passed since last update.

機能開発から考える「お金」と「チーム」の話

Last updated at Posted at 2022-12-03

前置き

メタップスアドベントカレンダー 4日目
今年はメタップスに入社して、10年の節目となりました。

これまでメタップスで関わってきたプロダクトも10を超え、色々な出来事もあった中で、今回はプロダクト開発時によくありがちな「顧客要望から機能開発に至るまで」のビジネスサイド、開発サイドの意識しておきたい部分などを「お金」と「チーム」の視点でまとめてみました。

顧客要望からの開発依頼

「お客さんがこんなもの欲しがってました!」
「この機能があれば導入が進みそうです!」
ビジネスサイドにとっては非常に嬉しい話です。
一刻も早くほしいと考えていることでしょう。

ビジネスサイドの意識

営業の場合、目標に近づくため開発サイドが作ってくれれば契約が取れるためこういった話があると、開発してほしいと懇願してくることがあります。

一歩引いて考えてみましょう。

営業サイドが欲しがっている機能で契約が取れて、売上が上がったとします。

この売上を形成するものはこの機能があることが前提ですので、機能開発コスト がまず差し引かれます。

サブスクリプションモデル(月額課金モデル)の場合、LTV(顧客生涯価値)を意識すると思いますので、

LTV = 単価 × 粗利率 × 継続月数 - 機能開発コスト

となるイメージですね。

チャーンレート(解約率)が低ければ機能開発コストが高くてもどこかで回収できそうなイメージを持つと思いますが、ここに更に 運用コスト が入ってきます。

そのため、粗利の部分に月次の運用コストが差し引かれるわけです。

LTV = (単価 × 粗利率 - 運用コスト) × 継続月数 - 機能開発コスト

つまり、イメージとしては原価率が上がる = 粗利率が下がる 状態になるわけです。

ビジネスとして、原価率が上がるということは限界利益が下がるということになるため、シビアに判断されるべき内容ですが、開発サイドに相談のないまま、機能開発が決まってしまうケースがあったりするのは非常に危険ですね。

例えば、ラーメンを一杯食べてもらうために、豪華な個室を用意してほしいというような発想の場合もあったりします。

この場合、確かにこのお客さんは求めていることなので、利用してくれるかもしれません。が、他のお客さんは全く求めていないものなので、一切利用しないものを日々運用しなければならないわけです。

要は、ターゲットとする多くの層が求めている機能なのか。
この機能をつけることにより、運用コストは上がるが、それ以上に満足度や利用率が上がり、
運用コスト < 増加するLTV
となるかどうかが重要になるのですが、ここが超初期フェーズだと顧客への個別対応で目先の売上を求める場合、慎重に判断したいところです。

開発側の意識

前述したケースを開発視点でどう配慮するか。
結論としては、前述した内容の中で、 開発コスト運用コスト を提示してあげましょう。

いままでやってきたことで、「どのくらいで作れますか?」という問いに答えてきたと思います。

いわゆる、「見積もり」です。

本来的には「いくらで作れますか」という話になるのですが、例えば「1ヶ月ください」と答えられた場合に、この機能開発コストをざっくりと金額で換算することになります。

ただ、気をつけてほしいのは、ここでどれだけ日々の運用コストが上がるのか、というのを考慮されていない場合があるということです。

3人の開発チームで、「機能開発」「運用」「改善」をギリギリで行っていた場合、この機能は1ヶ月で作れたとして、その後の運用が膨らむと、このチームのキャパを超えることになります。

このキャパを超えると、採用 が発生します。つまり固定費の増額です。
※正社員採用の場合

この運用コストを下げるために、日々のリファクタリングなどを行っているというわけです。

よほど突拍子もない話でない限り、ビジネスサイドで想像できる「できると思う」に対して、開発側で技術的に「できない」というものはほとんどないと思います。
ただし、事業としての「できる」「できない」の話は、今のビジネスの収益性や今後の運用面などのコストも踏まえなければ判断できない部分も多く、開発側からの情報としては機能開発コスト運用コストを提示し、ビジネスサイドとしっかり議論して判断したいところです。

まとめ

自社開発において、売れるものを作ることはとても重要です。
ビジネスサイドで声を集め、作るべきものを考える。
開発サイドで作るべきものに対してどう実現するかを考え、ものを作っていく。
この流れの中でちょっとした認識の差で関係性が崩れると、チームは簡単に崩壊します。
今回は考え方としてのほんの一部ですが、ビジネスサイドと開発サイド、お互いを理解し、信頼して、意識して状況報告や、相談が気軽にできる関係性を作れれば屈強なチームが作れるので、是非。

崩壊しているときには本当にプロダクトが進まなくなるのを目の当たりにしてきて、結構辛かったので、少しでも参考になれば幸いです。

16
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
0