どうも、アドプラットフォーム事業のプロダクト組織の大曲です。
ADWAYS DEEEの子会社化に伴い、組織改編がありプロダクト開発組織（PdM、エンジニア、デザイナー、データサイエンティストが所属している）が子会社の中で一番人数が多い組織になりました。そこを統括する責任を持つ人間として予算額や影響を考えるたびに、「ああ〜なんかヒリヒリする〜」と思うようになりました。
今回は、社内でのアウトプットを出来るだけそのまま貼っているため細かい言葉などが読みづらい点があるかもしれないです。細かく理解するというよりも全体感を理解して貰えたら嬉しいです。
簡単に話すことをまとめると。
- エンジニアの事業貢献のために「仕事の定量化」を求められた
- 戦略を策定し、事業貢献を表す指標を決め、運用した
- 完璧でなくとも定量化することで方針判断に活用できるが、遅行指標であることを意識すべき
背景
アドウェイズの開発組織がエンジニアリングで勝負できるような会社になることを目指しています。
その一環として仕事の価値の定量化を各組織が行い、事業貢献への証明をする必要がありました。
私はアドプラットフォーム事業の開発責任者であるため、主にJANet,Smart-C,AppDriverのサービスの価値の定量化を行いました。
詳しくはこちら
取り組んだこと
まず開発組織がどんな事業貢献をするべきか考えました。その戦略に合わせて定量化に向けた動きを行いました。
戦略策定
事業貢献の事例整理
まず、過去のプロダクト開発の中で良いと思う実績を出した事例を整理しました。どういった仮説検証のサイクルを回したいのか、何回かの仮説の中でどんなことが発生し、どう決断したのかを伝わるような図を書きました。
サイクル感を出したかったので真ん中をスタートして、徐々に拡大している感じを出すような図にしました。
※このとき選んだ事例が今でも良いかというとそうではないです。
現状と理想決め
現状、理想を定め、達成基準の仮指標を決めました。仮指標はその後の定量化の動きにつながります。簡単にまとめると以下のような内容になりました。
先ほどの事例整理の延長戦としてこの戦略がマッチすることを確認したり、営業側が共感できる価値と近いのかをすり合わせをしたりしました。
方針： データ最適化を事業のコアとする 現状： アフィリエイトやリワードの事業において、データを活用した最適化の適応が少ない。 理想： アフィリエイトやリワード業界において、データ最適化を活用した機能を多く持つサービスとしての地位を確立させる。 達成基準 - 月の売上XXXX円以上の影響力をデータ最適化機能が与えている状態 - 半期単位で開発中案件の6割がデータ最適化に関わる案件であること
理想の詳細には、事業貢献での影響範囲やユースケース、また技術的な視点なども盛り込みました。これを必ずやれってことではなく、技術的な視点からのアプローチができる余地があるよねを伝えるために追加しました。
- データ最適化の機能の品質が事業の数値に影響する - アルゴリズムやロジックの品質で売上に大きく影響するほどの機能を作る - エンジニア自身も常に事業の数値を向き合い、事業成長を意識せざるを得ない状態にする - 例：ロジックの品質向上で事業全体のCTRが10%向上したことで売上が20％向上した - 人の限界でアプローチできなかった部分を発見したり、新しい価値を提供した中でのデータ最適化出来る余地を探す - 例：記事毎でのXXX機能を実装することで人が細かく管理していた部分をシステムが担う - 新しいビジネスモデルを提供し、より活用するためにデータ最適化できる部分を探す - データ最適化を実施することで新たな価値を提供できる - 人力では困難だった細かい組み合わせでの分析実施を行い、新たな訴求として提供可能 - 例：レコメンドでユーザーx案件の粒度で案件を訴求できる - データ最適化が事業のコアとなり得るようなシステムであるべき - システムのアーキテクチャや技術が複雑なデータ最適化の機会を損なってはいけない 例：BigQueryを用いたデータ分析、受け入れテスト基盤（トラッキングの開発を積極的な改修が可能となる）
グロースサイクルっぽいものを軸にロードマップ策定
軸となる事例と目指すべき状態（現状と理想）が明確になったので、そこに対して道筋を示すことにしました。そのためにグロースサイクルを作成しました。
ちょうどこの期間にプロダクト戦略の一環でグロースサイクルを作る機会があったのでそれを元に全体感の整理とフェーズごとでの優先度を決めました。
結果的にグロースサイクルもどきが出来たなと思っています。
フェーズ１は「回収と種まき」と題してそのタイミングで重視したい指標をサイクルを軸にメンバーに伝えるようにしました。ロードマップと言っても、ざっくり決めただけなのでこれにものすごく時間はかかっていないです。
フェーズ１内容： 回収と種まき - 回収＝現状のデータ最適化案件に該当するROIを達成率を向上させ回収する - 種まき＝データ最適化案件候補となる指標を模索する - 今後案件が増えてもスピーディーに開発出来るようにリードタイム削減を目指す
この時にそもそも組織全体だとどんなプロセスかな〜とかも整理しました。
必要な指標作成
さて、戦略やロードマップの目処が立ったので指標策定を行いました。
まずは達成基準として定めた指標に向けた定量化です。
達成基準 - 月の売上XXXX円以上の影響力をデータ最適化機能が与えている状態 - 半期単位で開発中案件の6割がデータ最適化に関わる案件であること
データ最適化売上貢献
方針である「データ最適化の機能」がどれだけ売上に貢献しているかを定量化し、サービスのコアに影響あるかを明確にするために策定しました。データ最適化影響度（0~100%）という概念でデータを活用していたら売上の比率が上がる仕組みを採用しました。
計算式： データ最適化の売上貢献 ＝ 機能経由での売上 * データ最適化影響度（0~100%） 活用のケース： - データ最適化の影響度の認識 プロダクトの機能が事業に与える影響度を明確にする - 規模や機能改善での優先度判断を行う 機能が与える規模やデータ最適化として機能改善の余地がどれほどあるか
| 影響度 | 内容 |
|---|---|
| 20% | 運用の補助ツール データ活用方法自体は営業が考え、その設定作業を手助けする |
| 40% | 運用の補助ツール 他社のツールなどを活用し、データ活用の一部を手助けする |
| 60% | 自社の運用に対してロジックを提供し、売上の品質向上や分析効率化の貢献が出来ている |
| 80% | なし |
| 100% | データに基づく制御がシステム内で完結して提供されている |
開発リソース（工数表）
アドウェイズでは工数をつけているため、それをもとに各サービスのリソース状況を可視化しました。
機能単位で細かくつけることもありましたが、それをやめてカテゴリ（新規価値、効率化、技術改善）でつけてもらうことにしました。
できるだけ工数付けの面倒さをなくし、大枠を把握できるようにしました。案件単位ですと案件開始のためにデータを追加する必要があったりと管理コストもかかったため、止めました。
カテゴリまでわかる指標では案件単位では分かりません。工数としての案件まで細かく追いたい要望はないのですが、効果があったのかの推測には使いたいため案件ROIという指標も作っています。 これに関して書くと、かなり記事が長くなりそうなので割愛しました。
最終的な P/L 作成
最後にP/Lを策定しました。
P/Lで難しかった部分としては、現状の価値を定量化した上で事業貢献を果たすことで伸び代がどれほどあるのかを考慮する必要がありました。
先に書いたデータ最適化売上貢献のみで事業貢献を判断できれば良いのですが、こちらは開発した機能の蓄積となるため売上としてはわかりやすいのですが、コストの概念を取り扱いづらいため別でP/Lとして考えることにしました。
まず、売上をどう扱うか考えました。リクエスト数に応じた料金計算（1クリック＝0.5円など）や月額利用料（メイン機能に対して機能ごとの売り上げ計算）など色々なサービスのプランなどを見比べて検討しました。
最終的には粗利に対して、システム利用料の概念でエンジニアの売り上げの取り分を決める方法に落ち着きました。売上にどれだけプロダクトの機能が影響しているかをベースにシステム利用率を決め、機能開発を進めることでプロダクトの売上への影響力を高めてシステム利用率を上げてエンジニアの事業貢献を示すことにしました。
P/Lの各項目とのマッチング
| 項目 | 内容 |
|---|---|
| 売上 | システム利用料（粗利 * システム利用率） |
| 売上原価 | - |
| 販管費 | システム費、組織運営費、投資費、人件費 |
システム利用率の内訳
| システム利用率 | 内容 | 該当サービス |
|---|---|---|
| 10% | システムのみの提供 他サービスでも代用できる状態 例：パッケージ化されたサービスに切り替えが容易 |
- |
| 20% | システムのみの提供 他サービスでも代用できない状態 例：自社にカスタマイズされて、最適化されている |
サービスA,サービスB |
| 30% | システムのみの提供＋データマーケティング機能の提供 プロダクトとして広告の価値を上げるためのデータマーケティング機能を営業に浸透させ売上に貢献している状態を作る |
サービスC |
| 40% | システムの機能品質次第で事業数値へのインパクトが高い 機能品質は機能の有無ではなく、機能が提供する精度に基づくもの 例： 配信ロジックの品質が事業全体のCVRに影響する 推論精度に基づくトラッキングで売上の半分を占める..etc |
サービスD |
| 50% | 業界をリードするもしくは新たなジャンルでも実績が出ている 例： ターゲティング性能やデザイン力を元にアプローチできなかった市場でも成果を出せた |
- |
※サービス毎で粗利率での影響が大きいため、粗利率を意識できる。粗利計上で扱う。
※事業責任者とは話して20~30%は既に貢献度としてはある認識なので、ベースを20~30%に設定する。（当初は5~10%にしていた）
データ最適化売上貢献とP/Lの関係性の図
現場向き合いとしてデータ最適化売上貢献を意識してもらい、経営陣に対してはP/Lで貢献を示すようにしました。
結果
定量化を行い、目標を策定して去年頑張りました。
ただ、数字としての結果としては進捗は芳しくありませんでした。
P/L、データ最適化売上貢献は目標に対しての35％進捗でした。
細かい話になるのでまとめると以下の内容になりました。
- P/Lは投資を回収できる事業貢献が出来ていなかった
- プロダクトの機能が顧客に選ばれる理由になったりする実績も出た
- 仮説検証の結果、規模を拡大できる機能が少なかったため売上影響が少ないものが多かった
- 基盤構築に想定よりも時間がかかり、価値貢献までのリードタイムに時間がかかった
各数値の経過
データ最適化売上貢献
最初は検証フェーズが終わった機能を拡大させて数字を伸ばせました。
その後、複数の検証が失敗したり、基盤構築に時間がかかり伸び悩みました。
このままでは目標を全然達成できないので、最後の追い込みで技術改善を止めてなんとか成果を出せるところまで向かいました。
開発リソース（工数表）
当初は新規価値の案件を生み出せなかったりしましたが、 徐々に検証の数を増やして成功したものを開発フェーズに乗せることができて基盤構築などを行えるようになりました。
最後の2022/10~12月は追い込み時期として技術改善を減らす方針に舵を切り、成果にこぎ着けました。
急拵えだったのでメンバーには苦労をかけました。メンバーの皆さんに感謝です。
まさしく、こちらの記事はその苦労の記事です。
P/L 売上
見づらいですが、最後（2022年11・12月）にあるサービスの売上の一部のシステム利用料があがってアップはしています）
P/L コスト
円安でのクラウド費用増加や投資（技術支援）の増加でコストは右肩上がり
経営層向き合い
- 投資判断としての活用
エンジニア側で投資したい場合に、その投資の結果が最終的にどのP/Lの部分が上がるのかをものすごく認識するようになりました。
これがあったから投資させてもらえたほどのインパクトは無いですが、エンジニア側での事業貢献のインパクトはどれだけ伸ばせるのかなと計算することが可能となりました。このP/Lでアドウェイズの経営陣と直接話したことはないですが、あくまで事業責任者と投資するかしないかを判断する際に利用しました。
営業側のMGRとは「XXXXの機能ができたら、XXX万円の影響があると思うけどエンジニア側の貢献としてXXX万円の取り分くらいあっても違和感はない？」と数値の感覚のすり合わせを行ったりしました。
今、注力して開発している機能はどのサービスのどのジャンルに大きく影響あるから、ここが成功すればシステム利用料がアップしてこれくらいの売り上げになって
仮にXXX万円くらい投資してもエンジニア側の利益はXXX万円となるから〜という感じで考えてました。
現場向き合い
- 方針転換の際にはどのポイントが良くないか分かりやすかった
成果が出ておらず、最後の追い込みとして方針転換を行いました。その際に各指標の定量化した数字を把握していたのでそれをベースに判断をしました。
メンバーにとっての急な組織変更でも大きな反発もなく協力してもらえました。結果的に最後の追い込みでは新規価値に90%近く振り切り、リリース完了となったステータスも増えました。
- 数値によっては遅行指標なのでOKRには組み込まない方が良い
半期OKRに「データ最適化売上XXX万円」というKRを掲げてました。メンバーが数字を意識してくれたので非常に良かったのですが、検証が思い通りにいかず全然何も上がらない時期があり目標としてはきつい時期がありました。（調子がいいと上がるんですけどね）最後の半期は、売上を上げるための行動XX件というOKRの組み立てにしました。遅行指標なのでやるべきかは悩んで実施したのですが案の定良くなかったとは思いますが、メンバーが数字を意識する良い効果もあったので組織の状態によっては良し悪しかもしれないです。
指標を策定してみてどうだったか
戦略を立てそこに合わせて色々な指標を模索しました。結果的には開発生産性の定量化に近いことを行ったのかなと思いました。
データ最適化の売上貢献などは開発生産性のレベル３に当たる部分なのかなと思っています。
※今回紹介していない指標は文字を薄くしています
生産性のレベル１などは明確な指標としてわかりやすいですし、自分たちの行動の結果であるためアプローチしやすいのかなと思っています。ただ、レベル３までいくと開発組織以外の影響もあったり遅行指標に当たるため定量化する指標として工夫が必要かなと思います。
プロダクトとして、もしくは開発組織としてどんな事業貢献をするかの戦略があった上での定量化が大事だなと改めて感じました。
シンプルに売上のみ追っていたら、遠すぎる指標として思考停止になっていただろうなと思いました。プロダクトの責任まで持つ開発組織ならば、North Star Metric がぴったりだろうな〜と思ったりしています。
今後
まだまだ、定量化の改善はしていこうかなと思っています。P/Lとしてのシステム利用料の概念を作りましたが、まだまだ改善の余地はあると思っているからです。
冒頭にも述べたように開発組織が、PdMチームを発足しプロダクト組織となりました。今まではエンジニアが貢献するという思考でしたが明確にプロダクトの全ての責任が組織に紐づけられました。
プロダクトの責任を負うものとして、P/Lやデータ最適化売上貢献みたいな指標はより事業向き合いの数値（プロダクトのNorth Star Metric）であるべきだろうと思っています。
また、生産性のレベル１となる工数、ベロシティ、Four Keysを個別で活用はしてますが、総合的に組み合わせチームの生産性の可視化はやれてはいません。そこにも着手したいと思っています。
いや〜まだまだ先は長いですな〜
