プロダクト開発で価値あるものを生み出し続けたい、生み出し続けるプロダクトチームにしたい、塚本 (@nao_tsukamoto) です。
デジタルトランスフォーメーション（DX）事業本部でHousii（ハウシー）という事業で開発PMをしています。
はじめに
先日以下のような記事を書きました。
この記事では、短期〜中期で価値あるものを連続的に生み出していくために、OKRやNSMを活用しロードマップに落とし込んでいるという話をしました。
今回は、「実際の足元の開発で本当に価値あるものの開発ができているか？」「そのために何しているか？」ということをお伝えできたらと思います。
本記事では、
- 開発チームが生み出した価値の総量を計測する具体的な方法が分かって明日から実践できる
- 計測した指標の解釈の例が分かって次の日試してみたいと思う
ということをゴールにしています。
よって、以下に該当する方にはぜひ読み進めてもらえると嬉しいです。
開発チームのスクラム運営を担う若手の開発PMの方
- 自分たちのプロダクトチームが価値を生み出せているのかなんとなく気になっている
- 図らずも惰性でスクラム開発の振り返りをしてしまっている
- 価値の計測ってどうやってやるの？
私の関わっているサービスに関して
少しだけ私が携わっているHousiiというサービスの説明と紹介をさせてください。
完全会員制の家探しサービス「Housii」のプレスリリースを出しました。 こちらは、BtoBtoCのサービスです。
また、先行してベータ版を出しておりましたので、今回プロダクト提供開始記念インフォグラフィックも公開しました。
なぜ価値の計測を始めたのか
ロードマップを定義し価値あるものを開発していくようにしたとしても、実際の開発として価値あるものを計測できたかを保証するものではありません。 それは、調査やバグ対応、運用におけるイレギュラーな対応等、スクラム開発において日常茶飯事です。
ここで少しだけHousiiのプロダクトの状態について触れておきます。
プロダクトが拡大し複雑性を増してきて以下の問題が "見え始め" ていました。
- 1つの機能を開発・リリースするにおいてもその影響範囲が大きくなり、仕様が複雑かつ難しくなってきた（つまり、見積もりするとポイントが大きくなって開発期間が大きくなってきた）
- 上記に合わせて、不確実な技術検証のための調査、仮実装タスク (スクラムでいうスパイク開発が必要になってきた
- バグ対応、運用におけるイレギュラーな対応等が以前に比べて増えてきた感覚があった
その中でもやはり私たちは価値あるものにフォーカスし価値を生み出し続けたいと強く思っているので、それを継続していくための仕組みが必要だと感じるようになりました。
そのためにまずは、「自分たちが生み出した価値の総量を見える化」することになります。
具体的にやったこと
HousiiではZenHubを使ってチケット管理をしているため、以下の方法で価値の総量の計測にトライしてみました。
issueに価値のある開発でることを意味する専用のラベルをつける
具体的には以下です。
- 調査、仮実装タスク、依存ライブラリアップデート等のissueにはラベルを付けない
- バックエンドからフロントエンド・デザインの対応が必要な一連の機能や改善タスクについては、それを1つの価値としてラベルをつける（※フロントだけで改善できるものも、もちろん1つの価値とする）
そして、ZenHubのReport機能を使って、issueに関するデータを一覧でラベルを絞ってcsvダウンロードしスプレッドシートで集計していきます。
※ここでは、価値の量を「feature数」としています。
解釈できたこと / できなかったこと
そもそもの、集計した結果の見方は以下です。
- スプリント単位だと少し短いし誤解釈を生むケースが多くなる月単位で見る
- チーム全体の「feature数」の変遷をみて、「feature数」が前月・前々月と比較しての増減の変化量を見る
- チーム全体の「feature数」の変遷をみて、人数が増えた / 減ったときに「feature数」の増減の変化量を見る
この見方で解釈できたこととできなかったことがありました。
解釈できたこと
仕様が大きくなっていないか？
価値の数が減っていた場合、要件定義やリファインメントが十分ではなかったことがわかります。 また、チームとして仕様検討の難易度が上がっていることに気づくことができます。
小さい作業量ばかりのものを対応していないか？
価値の数が増えている場合、細かい改善に注力していることを示唆している可能性があります。 プロダクトフェーズやロードマップによりますが、結果的に改善系に注力しすぎていたと振り返ることができます。
解釈できなかったこと
個人が出した価値はどれくらいか？
ここで紹介した方法は個人が出した価値の計測には向いていません。 そもそも、個人が出した価値を出して計測すること自体が必要なのかは疑問なところです。 開発チーム全体として価値を生み出していこうというのが趣旨であるため私たちも集計自体しておりません。
余談
計測方法と解釈についてここまで書いておきながらお恥ずかしいのですが、本取り組みは長くは続きませんでした。
つまり、失敗でした。
どこが失敗だったかというと、
- issueに、価値のある開発でることを意味する専用のラベルをつけていく
- バグと調査タスク、dependabot等のissueには付けない
- バックエンドからフロントエンド・デザインの対応が必要な一連の機能や改善タスクについては、それを1つの価値としてラベルをつける
ここに運用の難しさがありました。
人力でラベルをつけていくことに限界がありました。 issueの粒度とリリース単位を明確に定義していないため、どの粒度で「価値のラベル」をつけるかの判断が曖昧になってしまいました。 それを手動で、かつチームで同じ判断基準をもって続けるには負荷が高かったです。
今はこの方法での計測はやめていて、絶賛、別の方法を模索中です。 もし別の方法で同じようなことをやられているチームがあればぜひお話をさせてもらい、アドバイスをいただきたいです。
最後に
今回、生み出した価値の数を計測し始めてみて学びもありました。それは、いつの間にかプロダクト開発の難易度が上がっていて仕様が複雑になっていることに気づけたことです。 少なからず機能を出し続けてきた私たちはいつの間にかより多くのことを検討する必要がでてきていました。 その結果、価値あるものを生み出すスピードが少し下がっていたということです。
仕様が複雑になっていることを開発チームが認識できただけでも大きな一歩だと感じています。 今では、仕様の認知負荷を下げるためにレーンを分けたり、レビュータイミングを少し細かくしたり、私のようなPMが要件定義に意識的に時間を割いたりといくつかのTryをしています。
私たちはこのことに向き合い、これからも価値あるものをより多く・よりはやく出していきたいと思います。
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください。
Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！ もちろんオープンポジション的に上記に限らず積極採用中です！！！
