見出し画像

CTOの頭の中:技術投資を最適化する

ざっくり年収1,000万円のエンジニアが10名いる会社では、年間1億円の技術投資がなされているわけですが(地代家賃、ライセンスフィー、PC代など含めるともっと)、年間1億円を正しく詳細に把握して、投資をコントロールできている会社は少ないと思います。会社が創業期であれば、最低限作らなければならない機能などは分かりやすく見えていたりするのでまだしも、そのプロダクトでしっかりとした収益が成り立ち、上場企業となるようなレベル感のプロダクトに対する技術投資となると、一部の大きなプロジェクトは把握していても、細かな投資ポートフォリオを常に把握することは難しいのではないでしょうか?今回はこの部分に一石を投じてみたいと思います。

技術投資量を見える化する

画像

投資の最適化とは言いますが、最適化というのは「To Be」の話ですので、まずは「As Is」を知らなければ話になりません。その、まず「As Is」を知るために上記の図を用意しました。まず、これを説明させてください。

G/Pというのは先日のnoteで説明した通りですので一度目を通していただけると幸いです。P/Lはいわゆる財務三表の「損益計算書」、B/Sは「貸借対照表」になります。簡単に言えばB/Sは収益を生むための資産(プロダクトなど)であり、P/Lはその資産が(人的なコストも加味した上で)生み出す収益になります。ITでビジネスをする場合は「収益を生むための資産」、つまりソフトウェア的なプロダクト自体を作り続ける宿命にあるため、G/Pで定義された「生み出し続ける力」=「流量」もビジネス上重要な投資カテゴリとなります。うっかり流量が0になってしまったらプロダクトの進化は無くなり、ビジネス自体がジリ貧になることは必至です。

さて、こうやって区分けされたカテゴリがどういう意味を持つのか、という定義を次の絵にまとめてみました。

画像

一番メインとなるのは「対Assets投資」。創業期にプロダクトを作るのは何よりここへの投資となります。言い方は悪いですが金の成る木を作らねば、そもそもITでビジネスを立ち上げる意味がありません。まずは事業のベースとなる最小限の機能(MVP)を持ったプロダクトを作るために投資(エンジニアにお給料を支払うような)します。

この時、とっても大切なことがひとつあります。例えば「3,000万円」かけて(概ねエンジニアの人件費になるだろうけど)対Assets投資をした時、同等の「3,000万円」の技術負債またはプロダクト負債を抱える、と考えるべきだということです。正直なところ、凄まじく優秀で先見の明さえ持っているエンジニアが一人で美しいプロダクトを作った場合、負債量は上記の限りではないでしょうが、考えうる負債の最大量としては投資量そのものになるはずですので、同額が負債化していると考えておくことがリスク管理上ベターだと思っています。

この技術負債を「返済」する業務こそが「対Dept投資」になります。昨今では「SRE(Site Reliability Engineering)」チームがその投資の一部を担っていたりすることもあります。負債が貯まることで、開発コストがどんどん膨れ上がっていき、果てはセキュリティホールを潰そうにも、莫大なコストをかけなければ安全に修正モジュールをリリースできないなんていう状態も発生します。このため、一定の年数(5年前後)を経たプロダクトとなると、一定数のエンジニアが負債解消に付随する開発や作業を専属で行っていることが、健全な状態と言え流でしょう。

対Revenue投資、対Cost投資は上記のように「金のなる木」を作るとか、作り続けるために必要な投資ではなく、SEO対策やCPA改善の施策など、当該プロダクトのユーザー体験を大きく改善させるためのものではない、フロー的な投資を意味します。また対Cost投資に関しては、プロダクトそのものよりも社内の業務改善機能開発など、プロダクトの本丸以外の社内人件費の抑制などにアプローチするような投資も含みます。

対Power投資は「どんどん資本を積み上げていくためのエネルギーそのもの」に対する投資です。一番わかりやすいのがエンジニア採用で、エンジニアの量を増やすことで開発流量自体を大きくする。そのために採用専属の人員をはる、という施策などがこの部分への投資です。まあ、エンジニアを増やせば流量が増えるとは言い切れませんが、今回は投資量の話なのでこの話はカットします。

最後に、対Accelarator投資と対Reducer投資についてです。例えば開発プロセス改善や、自動デプロイ化、並行してQAを別働隊が行うようにすればそれらも対Accelarator投資になります。つまり「Power」の伝導性をより高めるための施策を実行するための投資です。この投資が増えれば増えるほど、基本的に生産性は上がるはずです。対Reducer投資、例えばエンジニアが出席すべき必須の会議体が多くなればなるほど、当然ながら開発時間が削がれるわけで、必要最低限の会議だけ出席すれば良いように社内の情報流通の仕組みや、会議体設計自体を変更するような対応への投資など、開発の阻害要因を取り払うような活動を意味します。大きな会社になればなるほど、情報流動性が悪くなったり、評価システムに欠陥があり、なかなかやるべきことがまとまらないということもままあると思います。それらを排除していくことも、れっきとした投資である訳です。

エンジニアをプロットしてみよう

画像

それでは最初の表に、現在頑張って働いてくれているエンジニアが、どの「対○○投資」に当たっているかプロットしてみましょう。もちろん優秀なエンジニアほど色々なことをやっているのは間違いありませんが、一番優先度高く仕事している部分はどこか、でプロットしてみてください。

上記の絵のように、匿名でやっても良いですし、実名を表記したり、役職を付加しても良いです。一体自分たちはどこにどれくらいのリソースを張っているのかがわかれば、何よりも知りたかった「As Is」になっているはずです。

ここで種明かしが一つ入りますが、このカテゴリ区分にはトリックがあります。実はこのカテゴリ分けは「本質的にカテゴリ毎に目標とするKPIが異なる」はずなのです。例えば対Assets投資カテゴリであれば、プロダクトロードマップに対する実行状況がメトリクスの指標になるでしょうが、対Debt投資の指標は例えばSLAやクエリー応答速度(平均、95%、最長など)の改善量、改善率などが該当することもあるでしょう。対Revenue投資だとSEO系ならインデックス数や流入数など、CPA改善系ならそもそもCPAそのものだったり、対Cost投資なら本体のプロダクトとは全く異なるプロダクトロードマップがあったり、コストカットしたかったそのもののコストの改善量であることもあるでしょう。対Power投資であれば採用人数そのものから、手前は面談量など、対Accelarator投資、対Reducer投資もそれぞれの目標が明確化するはずです。

もし、エンジニア評価自体が一本化されていたりする場合、最も重要である「対Assets投資」に対する評価になっている(心理上も含めて)可能性が高く、他のカテゴリへのリソースを張っていたとしても、実際は機能開発をしている可能性も否めません。負債が一向に解消されない、エンジニアが採用できない、などの問題を抱えている場合は、それぞれのカテゴリへ本質的にリソースを当てているのか?また、それぞれ機能するような評価メトリクスを、それぞれのメンバーと握っているのかを確認することをお勧めします。

タスク/チケット/イシューをプロットしてみよう

画像

同じ表に、今度はやるべきタスクやチケット、イシューなどを当ててみてください。ホワイトボードにこの表を書いて、ポストイットでペタペタ貼ってみる感じで十分です。直近のクオーターや半年など、比較的短期で対策する必要のある、重要度と優先度が高めのものだけにしてみると良いでしょう。

今回の絵はあくまでサンプルですが、多くの場合はこのように、リソースの当て方と課題量が一致していないはずです。まさにこの矛盾の部分が「To Be」になれない原因そのもので、今回の記事でいう「最適化」とは、この矛盾した状況を認識した上で、取捨選択してリソースとの整合性を取ることに他なりません。ここからはぜひ、皆様自身で現況を確認した上で、最適化を行なってみてください。

投資カテゴリと投資回収期間

画像

最初の表に括弧書きで(短期)(中期)(長期)と併記してあります。例えば対Revenue投資にあるようなトラフィック改善は短期的に事業P/Lへの影響があるため、経営側は比較的ここに目を奪われるケースが散見されます。対Assets投資は創業時には最も大切な投資カテゴリなので、どんどん機能開発をしていたにもかかわらず、ある程度事業の収益構造が確立した時においては、トラフィックを増やせば収益も伸びるため、新しくユーザー体験を向上するような施策への投資量が減るケースもあります。新しい体験の開発をしたとしても、収益への即効性で言えばトラフィック改善よりも遅いことも多く、中期的投資観点がなければ本カテゴリへの投資量は減少する可能性が高くあります。さらに、エンジニアの採用やそもそもの開発生産性の改善は、機能を作るよりも手前のフェーズで、機能をスピーディに安全に作りやすくするための投資であるが故、長期的な投資となります。このため、ここの投資は極端に抑えられ、現場サイドの献身によってギリギリ成り立っているという状況も多いでしょう。

しかしながら、短期的投資ばかりでは素晴らしいユーザー体験を伴い、かつコスト構造も優秀なベンチャー企業に体験的、経済的メリットで足元を掬われる可能性もあります。中期、長期の投資も一定行い続けることで隙の無いプロダクト、サービス、事業に成長することと思います。

今、しっかりとバランスの良い技術投資のポートフォリオになっているかどうかを定期的に可視化し、調整しながら、価値ある技術投資を続けていけるよう、ぜひこの方法をご活用ください。

----------

本編ははじめてiPadとApple Pencilを利用しました。DXです。

いいなと思ったら応援しよう!

ピックアップされています

#エンジニア 系記事まとめ

  • 1,279本

コメント

1

知らなかった。プログラミングでは、好きな言語で会心のプログラミングができればよいと考えていました。技術投資量なんて考えもしなかった。

ログイン または 会員登録 するとコメントできます。
ニート
CTOの頭の中:技術投資を最適化する|Shin Takeuchi
word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word

mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1