この記事はラクスルの2022年アドベントカレンダー8日目です。今日はエンジニアがROIを考えるようになった結果起こった変化や、私のチームでのROIの計算方法についてご紹介したいと思います。
自分と所属しているチームの紹介
改めまして、ノバセル株式会社でデータエンジニアをしているyamnakuと申します。最近は登山やキャンプなどアウトドア活動にはまっている新卒2年目です。twitterもぜひフォローしていただけると嬉しいです。Snowflakeに関する話題が多めです。
みなさまYoutube Liveご視聴いただきありがとうございます！
— yamnaku (@yamnaku_) August 30, 2022
先ほど検証内容の記事を公開いたしました！
Liveでご紹介できなかった部分の検証もあるので、是非ご一読いただければと思います〜😃#SnowVillage #SnowflakeDBhttps://t.co/ltJle79TXz
さて、ノバセルの開発組織は3チームに分かれているのですが、私はCoreDevelopmentチーム（以降、CoreDev）に所属しています。普段の開発業務では、
- Snowflakeを利用したデータ基盤の開発
- ノバセルのプロダクト群で共通して利用する基盤システムの開発
- エンジニアの生産性向上のためのDevOpsの導入・改善
などを行っています。
ROIを考えることになった背景
表題の通り、最近CoreDevではROIを考えるようにしています。最初に、ROIを考えるようになった背景を軽くご紹介します。
CoreDevは、「ノバセルの開発チーム全体の生産性を向上させる」ことをミッションとしたチームであり、前述したような業務に加え、他の開発チームから開発依頼も受け付けています。他チームで困っていることのサポートを担うことで、開発チーム全体の生産性を改善できると考えているためです。たとえば、他チームで行なっていた定常作業が開発時間を圧迫しているということであれば、その作業の自動化やアウトソーシングを進めることで開発時間を確保する、という取り組みも行っています。
CoreDevが今年8月に発足して以降、そうした依頼が多く、前述したようなCoreDevが本来やろうとしていたことになかなか着手できない状況が続いていました。 また、抱えているタスクが多くなり、どのタスクをまず着手するべきかも不明瞭になっていきました。
そうした状況を解決するために、タスクのROIを計算していくことで、より明確な優先順位をつけていくことを試みました。
ROIを考えることで解決しようとした課題
改めて、ROIを考えることで解決しようとした課題は以下の通りです。
- 他開発チームからの依頼を過剰に受け過ぎており、CoreDevで本来やるべき仕事が出来ていないという懸念
- 他開発チームからの依頼を含め、タスクに共通の基準がないため、優先順位が付けられない
取ったアクション
まず、ROIを計算するべく、チーム内のエンジニアにそれぞれ担当タスクを割り当て、そのタスクのROIを計算しました。また、ROIの計算方法については各エンジニアがバラバラな方法で計算しないよう、あらかじめフォーマットを作っておき、そのフォーマットに数字を当て込み計算するようにしました。
CoreDevで使っているROIの計算方法については後述するとして、主に開発コストと得られるリターンの見積もりが必要です。そのため、主に以下のようなポイントを調査しました。
- そのタスクを終わらせるのにどれくらいの開発工数がかかるか、それをお金に換算するといくらか
- そのタスクを終わらせると誰がどれくらい喜ぶのか、それをお金で換算するといくらか
必要に応じて、他チームのエンジニア・PdM・BizDevとディスカッションしながら明確化していきました。
得られた効果
具体的な計算方法は最後に解説するとして、先にどのような効果があったかをご紹介します。
タスクの優先順位が明確になり、納得感を持つことが出来た
当初の課題であった優先順位づけの課題についてはROIを算出することで一定解消させることができました。特に、他チームからの依頼についてもROIという共通の基準で比較することで、CoreDevでやりたい仕事を後回しにしてでも行うべきか否かを判断することができるようになりました。
また、他チームとの調整もやりやすくなりました。新しい依頼が来たときにもその依頼のROIを計算してもらい、今抱えている他のタスクと比べることで自動的に優先順位がわかり、CoreDevでいつ頃受け入れ可能かがすぐに判断できるためです。CoreDevで受け入れられない場合、依頼者は依頼内容を自分たちでこなすか、依頼内容を見直してROIをより高くするかの二択になるので交渉はシンプルなものになります。
また、このようにROIを元に優先順位を決めてタスクを行うことで、チームメンバーの仕事に対する納得感も高まりました。
ROIの算出を通じてタスクへの解像度が上がる
面白いことに、ROIを計算した結果決まった優先順位と、ROIを計算する前に感覚的に考えていた優先順位はほとんど一致していました。つまり、ROIを計算する前に頭の中で考えていたざっくりとした見積もりはおおよそ間違っていないということです。
しかし、感覚値に比べて、実際に出てきたROIがかなり低いタスクもいくつかありました。これらのタスクは、そのタスクによって得られる利益が曖昧である、という共通点がありました。つまり、役立ちそうなことはわかっているが、実際に言語化しようとすると何に役立つかはまだはっきりしていない、というものでした。
例を挙げると、「新しいBIツールの導入」がそのうちの一つでした。「新しいBIツールを導入すると何が変わるのか？」「現状のビジネスサイドの分析業務をどう改善できるのか?」というところへの我々の解像度が足りていないために、得られる利益について十分に計算出来ていないのではないか、と感じました。
解像度が低い状態でタスクを進めてもあまり成果は得られないことが多いため、これらのタスクについては、まず解像度を高め、ROIを正確に試算できるようにする、という結論に至りました。
普段の業務の中でビジネス感度が上がった
ROIを計算するようになってから、各メンバーの「ビジネス感度」も上がったように思われます。毎週行っている振り返りの中でも、今週やった仕事のROIはどうだったか、ビジネス上のインパクトはどれくらい生み出せたのかという視点で会話することが増え、よりビジネスへどう貢献するかという観点で仕事を進めるようになりました。チームメンバー間で、ROIという共通の物差しを持って会話することが出来るため、議論もスムーズに進むようになったと感じます。
CoreDevで利用しているROIの算出方法
では、CoreDevで利用しているROIの計算方法を紹介します。
参考にしたのが、Google Cloudが出していた変革の成果を数値化: DevOps 変革で収益を獲得する方法です。当初、DevOps関連のタスクのROIから算出しており、その際にこの資料を用いたのがきっかけです。この資料をベースに、以下のような項目を利用してROIを計算することにしました。
- 利益
- そのシステムにより減る不必要な仕事
- 上記で浮いた時間を再投資に回した場合の得られる利益
- そのシステムによって得られる利益
- 投資
- 開発するのにかかる人件費
- 運用するのにかかるインフラ費
- 技術的な訓練にかかる費用, 新しい技術の習得費用
各項目についてより詳しく説明していきます。
利益の算出
利益は、以下の3つの要素を合計したものになります。
そのシステムにより減る不必要な仕事
新たに開発するシステムが何かしらの効率化を目指している場合、それによって誰かの仕事が減るということになります。それはそのままそのシステムを開発した際の得られる利益になると考えられます。これが、「そのシステムにより減る不必要な仕事」を算出すべき理由です。この項目は、以下のような点がわかれば計算できます。
- 年間で削減できる仕事の時間（一人当たり）
- 仕事が減る人数
- 一人当たりの平均給与
なお、会社が実際に支払っている給与は社会保険料・年金などが上乗せされているので、我々は平均給与に1.3という係数をかけて算出しています。
上記で浮いた時間を再投資に回した場合の得られる利益
不必要な仕事が減った場合には、その時間を再投資できるわけなので、その場合の利益も考慮する必要があります。この利益を計算する上では色々な要素が絡んでくるため、注意して考える必要があります。CoreDevでは、前述のGoogleの資料を参考に以下の要素に分解して算出しています。
- 上記で浮いた時間が年間に占める割合
- 年間の開発リリース数
- 50（1週間に1,2のリリースができると仮定）
- 年間売上
- アイデアが成功する確率
- 1/3に固定（Googleの資料を元に仮定）
- アイデアが成功したときに何%売上を向上させるか
- 1%（Googleの資料を元に仮定）
基本的な考え方としては、年間のリリース数＝試すことができるアイデア数、と捉え、そのアイデア数をどれくらい増やすことが出来るか？ という観点で考えます。アイデアが成功すれば売上が上がるはずなので、アイデアの成功率と売り上げへの貢献度を加味します。
なお、上記の計算方法は、「エンジニアの開発時間を浮かせることができた場合」の計算方法です。エンジニア以外の人の仕事時間が削減される場合には、「開発リリース数」の部分を適宜変更する必要があります。たとえば、営業の業務時間を削減できるシステムであるならば、「年間に行ける営業数」に読み替えてみる必要があるでしょう。
そのシステムによって得られる利益
効率化ではなく付加価値を生み出すタスクの場合、このセクションの利益が重要となります。このセクションの計算方法はタスクに依存するため、適宜タスク内容を吟味して算出する必要があります。たとえば、DevOpsの改善タスクの場合、「システムのダウンタイム短縮」という利点があるので、それを利益として計上できます。つまり、ダウンタイム時に失った売上を失わずに済む、という観点で利益を計算します。また、プロダクトの機能開発の場合、その機能によって顧客数・顧客一人当たりのLTV・チャーン率などに影響を及ぼすはずなので、その増加分を利益として計上します。
投資
投資については、開発にかかるコストを計算すればよく、基本的には以下のような項目について検討しています。
- 開発するのにかかる人件費
- 運用するのにかかるインフラ費
- 技術的な訓練にかかる費用, 新しい技術の習得費用（ダウンタイム）
特に、新しい技術を導入する際には、その技術を利用することでのパフォーマンス低下やその技術を他の人にも覚えてもらうコストがかかってくるため、その点も考慮します。
このように、利益と投資が計算できたら、ROIを算出することが可能です。CoreDevでは、今後3年間に得られる利益と、必要な投資額を算出してROIを計算しています。
最後に
ここまで読んでいただきありがとうございました。
この記事では、ROIをエンジニアが計算した結果起こったこと、また計算方法についてご紹介しました。ROIに囚われすぎてしまうことの弊害ももちろんあり、全てをROIに基づいて決めるべきだとは考えていません。しかしながら、ROIを計算することは、タスクへの解像度が向上したり、業務への納得感を持つことが出来るという点でも有用であると思います。もし、我々と同じような課題感を持つチームがあれば、業務の中にもROIを取り入れてみてはいかがでしょうか？
