はじめに
こんにちは!
ourlyでバックエンドエンジニアをしております @naoto_911 です。
この記事は、ourly Advent Calendar 2024🎄 17日目の記事です。
昨日はHiroさんが、『小規模チームでテックブログ運営を軌道に乗せた方法』を書いてくれました！
少し前ですが、2Qに新規機能開発をプレイヤー兼PMとして進めた際にプロジェクトマネジメント文脈での学びをシェアさせていただきます。
この記事の主張
- プロダクトの機能とは、サービスの提供する"価値"の一つの手段である
- プロダクトだけではなく、人のオペレーションによっても同じ"価値"を提供できる
- その分の排反はあるが、このオプションを持てるかどうかでプロジェクトの進め方が大幅に変わる可能性がある
- 機能とオペレーションの最適解を探して、お客様へ最速で価値を届けましょう
新規機能の概要について
ourlyのサービス紹介&サーベイ開発の目的
新規機能開発としてサーベイ機能を作成することになりました。簡単に概要を説明します。
ourlyは社内のカルチャー醸成を目的として、社内向けに記事を作成して発信するCMS機能と社内のメンバーの相互理解を促進するためのプロフィール機能が存在します。
これらを用いて社員のエンゲージメントや帰属意識を高める運用を行っています。
これまではこれらの効果を記事の読了率やコメント率などの「ユーザー行動データ」を用いて計測することは可能でしたが、メンバーごとに定量/定性的にエンゲージメントや帰属意識を計測する機能は存在していませんでした。
そのため、同一サービス内でもこれらの情報を取得するために「サーベイ機能」を開発を行うこととなりました。
「ユーザー行動データ」という行動指標と「サーベイ機能」と結果指標の入出力を同一サービス内で計測し改善を回すということが可能になり、根拠を元にカスタマーサクセス(以後CSと表記)の提案の納得感を高めることができるようになります。
サーベイ機能の概要
サーベイは「①作成/編集」「②回答」「③分析」という3つの機能で構成されています。
ユーザーストーリーとしては、下記の3つになります
- 管理者が「①作成/編集」によりサーベイを作成。
- その後、サーベイが配信され該当者が「②回答」によりサーベイへ回答。
- 配信が終了すると「③分析」によりサーベイ結果やユーザー行動データとの相関分析を行う。
遭遇した問題について
我々は、機能の優先順位をつけ、まずは「サーベイ回答ができる状態」をスコープ1と定義しました。
つまり、「①作成/編集」「②回答」がスコープ1に該当します。
ボリュームを見積もり、期日に間に合うことを確認し、実装を進めていきました。
当初は、見えているタスクを洗い出した結果、期日にギリギリではあるが間に合うようなスケジュールを組みました。
期日までには、機能③は収まらないが、スコープ1(機能①②)は収まる
しかし、開発を進める中で当初不確実だった要素がクリアになり、当初の見積もり以上のボリュームの作業が必要であることが徐々に明るみになっていきます。
ここで、スコープ1のすべての機能を実装し終えるには、QCDS調整が必要になり、考慮の末にScope調整を行うことにしました。ところが、Scopeの調整を検討するも、機能①②のいずれかの機能がなくなると「サーベイ回答ができる状態」を実現することはできません。
期日までには、機能③は収まらないが、スコープ1(機能①②)は収まる
問題の対処について
発想の転換
これまでは、「どこから作るか?」 というScope調整を行なっていました。
我々は、ここで発想を転換しました。
「何で代替するか?」 と問いを変えました。
また、そのために、各種機能の 「何を提供したいのか?」 を整理しました。
ここで、「何を提供したいのか?」を整理する理由は、提供する価値を考えることで、「何で代替するか?」の代替案の幅が広がるためです。
代替を探す際には、代替にかかるコストも一緒に記載します。
「何を提供したいのか?」を整理した表
「何で代替するか?」を整理した表
実際の代替案の表はすべてのコンポーネント単位で様々な代替案を考えたためもっと情報量が多いですが、ここではその中で最もインパクトが高かった部分を紹介します。
実際の代替方法について
「①作成/編集」の部分について、すべてのUIをすぐには提供できないものの、CSメンバーへ運用でカバーいただくことで、同様の価値を提供できることがわかりました。
具体的には、以下のような変更を行いました。
Before
- ユーザーがUIを通して、サーベイ作成を完遂できる
After
- ユーザーがcsv形式で質問を作成する
- CSがcsvを受け取りエンジニアに渡す
- エンジニアがデータ流し込んでサーベイを作成する
この方法では、UIを丸ごと実装しないためFEのボリュームが大幅に削減されます。
この方法での実装ボリュームを再度見直すと期日までに完成できることが判明しました。
最終的に、これらのオプションを提示した上でプロダクトオーナー(以後POと表記)の意思決定によりこの方法が採用されました。
我々は、期日までに「サーベイ回答ができる状態」という価値を提供することができました。
トレードオフ
この代替案による方法は銀の弾丸ではありません。
本来の「①作成/編集」機能を後から実装完了するまでの間はCSの運用コストが発生してしまいます。
そして、何よりお客様が使いやすい状態とは言い難いです。
一方で、いち早く「サーベイ回答ができる状態」を提供することはできます。
このようにトレードオフの関係にある情報を整理した上で、POの意思決定に必要な判断材料をクリアに提示する必要があります。
これらの天秤の最適解を探した結果、代替案は否決になることもあると思います。
しかし、オプションを提示できるのとできないのとでは、戦い方が大きく変わってきます。
プロダクトエンジニアとして、「どうやって完成させるか?」 以外の手札を切るひとつのソリューションになり得ると思います。
提供価値 = プロダクト(機能) × オペレーション(運用)
ここまで話した内容をまとめます。
我々エンジニアは、機能を作ることで価値を提供することばかり考えてしまいがちです。
しかし、本来実現したいことはお客様へ価値を提供することです。
価値とは、機能だけではなくオペレーションによっても提供が可能です。
つまり、以下のような方程式への変換が必要です。
このように捉えることで、「プロダクト」ではなく「サービス」として、
「エンジニアだけ」ではなく、「組織全体」でOne Teamとなって提供価値を実現しましょう。
最後に
この記事で紹介した代替案は実際に日程のトラブルが発生するまでは考えてなかったです。
本来は最初から「機能実装だけのスケジュール」と「機能×運用の代替スケジュール」の両方を用意して、POの意思決定に幅をもたせるようなオプションの提示ができる方が望ましいと考えています。
次回のプロジェクトでは、初期段階からこれらのオプションを提示して、いかに早くお客様へ価値を提供できるか? を柔軟な発想で突き詰めていきます。
Discussion