※この記事は、2024 Speee Advent Calendar 22日目の記事です。
前日の記事はこちらになります。
はじめに
初めまして、2022年度新卒でSpeeeに入社し、現在Housii（ハウシー）という完全会員制の家探しマッチングプラットフォームの開発チームでエンジニアをしている大金と申します。
今回は、自分の実体験を元にした記事を書いてみました。 開発物を日々沢山リリースしているものの、イマイチ「事業の成果」に向き合えていないと感じるエンジニアの方々にとって、少しでも今後の動き方の参考となる記事になれば幸いです。
目次はこちら
なぜか「事業成果」から遠ざかってしまう問題
当初、開発チームは2つの問題を抱えていました。
1つ目は、プランニングの問題です。当時PMがサービス検証・数値分析などに大量の時間を割く必要があり、施策出し・要件定義などに十分な時間を割くことができませんでした。そのため、エンジニアチームに積まれる開発物が枯渇しかける現象が起きていました。
そこで、PMには要求だけ出してもらい、エンジニアが要件定義を中心にプランニングを進めていく、という方針になりました。 しかし、事業目標とKGIとKPIをここまで上げたいくらいの解像度しかないため、どんな機能を作ることができれば良いのか？というイメージが湧かなかったり、それがなぜ事業戦略上良いとされているのか？という問いにしっかりと答えることができなかったり、要件定義自体もなかなか自発的に意思決定しながら進めていくことができませんでした。結果的に、PMからの意思決定を「待つ」という振り出し状態に戻ってしまい、問題が解消されない日々が続いていました。
2つ目は、成果指標の問題です。私たちは「リリース施策数」「ベロシティ」といったアウトプット指標を重視し、事業目標のKGIやKPIはモニタリング指標として扱っていました。当初、スプリントの消化ベロシティは高水準を維持し、コードの品質改善、加えて障害発生数なども抑える取り組みを進めていましたが、それらの活動が事業目標の達成にどう貢献しているのかがクオーターを通して正しく評価できないことが問題としてありました。 例えば、「開発チームは今四半期の事業目標に対してどれだけ前進させることができたのか？」といった問いに、数値ベースで上がった下がったみたいな話はできますが、数字に表れていない定性的な部分も含めて、説明責任を果たすことができませんでした。
「価値ある顧客体験」を軸にした成果定義へのアップデート
この状況を打開するために、エンジニアチームがもっと事業の戦略を理解し、 開発のみならずプランニング、時には数値の分析も自発的にアクションを切れるような成果定義にする必要がありました。
ただし、単純にKPIやKGIといった指標とベロシティやリリース数といった開発のアウトプット指標のみだと、アクションまでが遠く、「結局この数値を上げるために何をすべきかわからない、PMに施策を出してもらうしかない」という状態になってしまいます。かといって、「この機能をXX月までにリリースしきる」だと、その機能をリリースする以外の選択肢が取れない制約条件的な枷になってしまうため動きづらい目標になってしまいます。
そのため、事業戦略と整合する、KGI, KPIからもう一段階ブレイクダウンしたサンドボックスのような目標が必要でした。
事業責任者とエンジニアリングマネージャーからの提案もあり、 開発チームの成果を「価値ある顧客体験の実現」として定義することを一旦試すことになりました。
具体的には以下のように、KPI, KGIを目標の達成水準に行くであろう価値のある体験を生み出すことに変更しました。
- 「会員登録からX日以内にY%のユーザーがZ件のメッセージを受け取ることができる」 - 「Xタップ以内で希望条件にXX%マッチする物件がZZ件ある情報を受け取ることができる」 - 「企業の担当者様が、Y件の物件データをZ秒で登録完了できる」 etc...
「価値ある顧客体験を軸にした成果定義の作成」という行動も含めて、これらを実現するという動きを取り始めると、 今までとは動き方の幅や思考の観点がガラッと変化し、明らかに行動が良い方向に変容したことがわかりました。
ここでは、主に変化したものを3つピックアップしようと思います。
1. 事業の解像度の向上
当たり前ですが、どんな体験を届けるのか？という最初のこの成果定義をする際に、闇雲によく見える体験を羅列して設定するわけではありません。 この体験群を届け切れたら、事業目標を達成できるというロジックを自分の言葉で他の開発メンバーや事業責任者の方々に説明できるようになる必要があります。 そのため、必然的に成果定義中に生まれてくる疑問点をひたすら事業責任者/PMメンバーと話して潰したり、時には自分で数値の分析を行う必要があり、「この事業はどうやって勝ちに行くのか？どうやったら勝てるのか？」という事業の戦略に対して今まで以上に深く理解をするようになりました。
2. 施策のプランニング周りの動きの改善
成果定義で決めた顧客体験を実現するために、「こういった機能が必要そうだな」とか「エンジニアリング観点でいうと、こういった機能よりもこちらの機能の方が工数も少なく、この体験を届けることができそうだな」といった思考が生まれます。
それに伴い、PMといったビジネスメンバーに対して、「〜日までにこの分析を終わらせて要求を出してほしいです」という動きが生まれたり、 時にはエンジニアメンバー起点で施策の要求・要件決めが生まれたりするようになりました。
このように、開発という枠組みに閉じた動きだけではなく、「価値ある顧客体験」を届けるためにはどうしたらいいのか？という観点から、段々とエンジニアが自発的に意思決定しながらアクションを取れるようになり始めました。
3. 「見るポイント」の変化
今までは施策をどれだけリリースできたか、どれだけPRをマージできたか、といったアウトプットの数字にフォーカスしてミーティングや日々の進捗の良し悪しを判断していましたが、今回の変化によって、成果定義で設定した顧客体験の数値周りといった数値を気にするようになりました。
例えば、「あの施策をリリースすることで、〇〇の時間が50%ほど改善する見立てとなっているが、実際に企業の担当者様の所感はどうか？狙っている体験は実現できているのか？」や「昨日のリリースによって、成果定義で決めた体験を届け切った想定だが、KPIやKGIに良い変化は生まれているのか？」といった発言がエンジニアメンバー起点でも生まれるようになっていきました。
「事業成果」に貢献するレバーが増える楽しさ
上記のような変化が起きると、単純にエンジニアとして事業に貢献できるレバーがグッと増えることがわかります。 プランニングも数値分析も、必要があればエンジニアメンバーで行い、成果定義も事業状況によって日々アップデートするサイクルに乗っからざるを得ない状況になります。 加えて、さらに時間軸を伸ばすことによって「将来的にこういった体験を作る必要がありそうだよね」といった会話が生まれ、それに伴って「こういったアーキテクチャにする必要がありそうだね」や「こういったデータがどんどん増えることになりそうだね」といったエンジニアリングとして考えるべき観点が大量に溢れてくるようになります。
もちろん、今まで通りベロシティなどは実行面での健康指標としてみる必要はあるので、単純に扱う情報量はグッと増え難易度は跳ね上がりますが、 それ以上にエンジニアリングを通して事業を動かす面白い瞬間が増えてくるようになりました。
最後に
今回は目指すべき「成果」を変えると、エンジニアとして、事業に対して引けるレバーが大量に増えることがわかったという話でした。
これに関しても「言うは易く行うは難し」で、チームへの浸透面や成果定義の難易度が非常に高いなど、様々な実行面の壁が沢山あり、私自身日々格闘中です。
ただ、それを差し置いてもこの成果定義の変更は、私の開発チームに大きな良い変化をもたらしました。
皆さんも目指すべき成果の観点から開発チームの行動を変化させてみてはいかがでしょうか？
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
新卒の方はこちらより本選考に申し込みが可能です！
キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
