デリバリーのリードタイムを短くするためにPMが工夫したポイント
こんにちは。Rettyの神山です。
Rettyでは、お店会員という飲食店向けの集客支援プロダクトで飲食店向けに広告出稿やネット予約機能を提供しており、そこのプロダクトマネージャー兼プロダクトオーナーをやっております。
今回は一連の開発プロセスにおけるPM↔︎エンジニア間で行う施策の内容を相談する会(以下リファインメント)で起きていたトラブルを解消し、デリバリーのリードタイムを短くできたお話です。
そもそもリファインメントとは？
Rettyでは2年ほど前からスクラム開発が本格的に導入されるようになり(詳しくはこちら)、バックログリファインメントと呼ばれるPMからエンジニアさんに対して開発物の内容を壁打ちするイベントが開催されるようになりました。
リファインメントではPMと複数人のエンジニアが開発物を洗練(リファイン)し、工数見積もりを行います。
見積もりが完了していないと開発ライン(スプリント)に施策を乗せることができないルールとなっており、PMはステークホルダーを巻き込みながら、開発ができる状態にするために動いていきます。
スクラム開発を本格導入するまでは、PMと一緒に動くエンジニアさんが固定化されていたため阿吽の呼吸で相談していくスタイルで、担当しているPMとエンジニアしか開発物の詳細がわからない透明性が低い状態でした。
リファインメントというイベントを通じて施策のWhy-What-Howが開発組織内で共有され透明性が担保されていく（属人性が低くなる）力学が働きます。
リファインメントで険悪なムードに
一見素敵な取り組みではありますが、リファインメントを導入し運用していく中でPMとエンジニアで揉めることが多くなっていました。
これで実装してほしい(PM側)vsこのやり方じゃない方が良さそう(エンジニア側)の対決になっており議論は難航。開発できる状態になるまでにかなりのリードタイムを要していました。
PMの中には、「もうリファインメントやるのが怖いです、、」という声も出てきており、私自身もそう言った感情になっていた時もありました。
このような状況になってしまった要因は主に2つありました。
要因①：PMがHowまで決めてしまう
要因②：PMの中で工数見積りが目的化
要因①：PMがHowまで決めてしまう
特にtoB側のPMは施策内容をビジネスサイドとすり合わせて具体的な開発要件に落とし込むことが多く、当時はエンジニアさんがほとんど介在しない中で具体的なHowまでほとんど決まった状態でリファインメントに挑む状態でした。
なぜPMがHowまで考えてしまうのかというと、当時のtoB領域はPMが受け身のディレクター的な立ち位置で仕事をしており営業要望を実現すること自体に主眼を置いていたからです。
問題をどう解決するかを考える立ち位置に営業や営業企画がおり、細かい要件定義を行なってエンジニアさんに開発依頼する役割としてPMが存在するというイメージです。
このような背景の中でリファインメントが開催されるようになると「これそもそも解決しなきゃいけない問題なんですか？」や「この方法じゃないとダメなんですか？適切な方法だと思いません」のような意見がエンジニアさんから出てきます。
PM側はビジネスサイドとHowのレベルまで合意しているので引くに引けない状態のためなんとか粘りますが、最後は「一旦持ち帰ります、、」となり、両者にとってあまり気持ちの良いコミュニケーションではありませんでした。
要因②：PMの中で工数見積りが目的化
前述でもありますが、ストーリーポイントと呼ばれる工数見積もりができている開発物しか開発ライン(スプリント)に乗せることができないというルールがあります。
PMは自分の担当している施策の見積もりを行わないと開発ラインに載せることができないため、なんとか見積もってもらうために入念に準備してロジックの抜け漏れがないように入念に準備していました。
今思うとおかしな話ですが、当時私はリファインメントを行うのに想定問答集まで用意していたくらいですw
本来は課題を解決をするために手段としての開発物を洗練することが大事なはずですが、PM側としては「早く見積もって次のスプリントになんとか乗せたい」の気持ちが勝り工数見積もり自体が目的化していました。
当時PMの評価基準もどちらかというとQCD(プロジェクトマネジメント)に主眼が置かれていたのもあり、顧客に価値を届けることにフォーカスできておらずビルドトラップにはまっている状態だったかもしれません。
どうやって解決してきたのか？
上記の通り組織として良くない状態だったので、下記の2つの取り組みを行いました。
①エンジニアとPMの役割を整備
②リファインメントの分割
エンジニアとPMの役割を整備
当時Howの領域までPMが主体で明確にする動きをとっていましたが、役割をある程度定義しました。
PMはWhyに対しては責任を持って明確にするものの、何で解決するか（What）、どうやって解決するか（How）はエンジニアさんと協働していくことにしました。
この役割を整備すること自体は簡単ですが、組織に受け入れられるための土台が大事だったように思います。
同時期に今や有名なビルドトラップ本の輪読会を行っており、PMは仕様の詳細化することよりも誰のどんな課題を解決したいのか？を明確にすることに注力することが大事であることが社内で共通認識となっていました。
上記の輪読会は一例ですが、教科書を元にPMがどんな働き方をするべきかについて共通認識があったため、役割の整備がすぐに受け入れられ定着することができたと思います。
リファインメントの分割
リファインメントでPM↔︎エンジニア間で認識が揃わない状態には以下の通りいくつかの種類があります。
①【Why】解決するべき問題なのかわからない
②【What】最適な解決方針かわからない
③【How】最適な詳細要件なのかわからない
PMは工数見積もりをしてもらうために①〜③までリファインメントで扱いましたが、そもそも①でつまずくケースもあれば、①はOKだけど②でつまずくケースもあったりします。
特に②がポイントで、②を合意形成ができれば③はエンジニアさん中心に考えれば良い感じに仕立ててくれるものです。
よって、①と②のリファインメントで解決方針を合意するリファインメントと③と工数見積もりを行うリファインメントを分けて実施できる取り組みを行いました。
この取り組みのポイントは、リファインメントの最初にPMがゴールを提示することです。
例えば、PMが
「今日のゴールは解決したい問題に対する解決策を広く洗い出してメリデメの整理ができている状態になることです。見積もりは次回させてください」
とゴールを提示すれば、幅広く解決策を洗い出し、開発すること以外の手段も検討することに注力できます。手段を卓上に並べて比較検討し最適なWhatを選択するプロセスをエンジニアさん含めて考える時間になります。
この取り組みを通じて、選択した解決策に対する納得感が醸成されその後の見積もりでトラブルが起きにくくなりました。リファインメントを行う回数は増えましたが、開発着手までのリードタイムは短くなりました。
昔はリファインメントに苦手意識があったPMメンバーからも以下のような言った声が上がっており、心境の変化があるようです。
今のリファイメントは相談ベースで気軽に行けるため参加しやすいです。今は一緒により良いものを作るチーム感を感じます
また、ちょうどこの頃アウトカムを重視するためのPM評価制度の導入していたため、PMが開発物をリリースすることではなくアウトカムを出すことに意識ができていたこともこの取り組みを根付かせる上で重要なポイントだったと思います。
最後に
いかがでしたでしょうか。このようなトラブルを解決してきたことで組織として自信もついてきました。
まだまだ課題は山積みですが、チームで解決しながら成長していきたいです。
この取り組みを見てRettyのプロダクト開発に興味のある方、絶賛採用しておりますのでまずはカジュアルにお話しましょう！！
この記事が気に入ったらサポートをしてみませんか？