プロダクト開発チームは「綺麗に正しく」よりも「早めに雑に」巻き込むのススメ｜プロダクトマネージャーのつぶやき
この記事はコネヒトアドベントカレンダー12日目の記事です！
前回の記事はおぐりんの記事です。
みんなも私も最初から経営者だったんだ！という言葉は最高でしたね。
なんだかパワーがもらえる記事でした💌
今日は、最近プロダクト開発を進める上でのお悩みや、やってよかったことを振り返りながらつらつら書いていこうと思います！
「開発着手可能な状態になるまで、もっとスピーディにしたい」
私は現在ママリアプリのプロダクトマネージャーを担当しており、
私の他に、PMM1名、iOSエンジニア1名、Androidエンジニア2名、サーバーサイドエンジニア3名、デザイナー1名という開発チーム構成になっています。
こうした比較的人数の多い開発チームで、ユーザー体験やデザイン、仕様などを詰めていく際に、こんなお気持ちがありました。
「なんか・・・時間かかってる気がする！」
その悩みをもっと細かく分解するとこんな感じです。
私1人や、私とデザイナーが固めた仕様でチームに落とし込むと、チーム全員の目で見た時に疑問や懸念が多く生まれ、再度検討し直すことがある
とはいえ、純粋にチーム全員で議論すると、発散してしまいなかなか収束が難しいことがある
さらに、開発チーム以外のステークホルダーも関わる機能開発の場合、そのステークホルダーの要求をチームに落とす際に自分が何往復かを移動するような動き方になってしまうことがある
これらは決して全てネガティブな意味ではなく、大事なプロセスなのですが、とはいえもっと早くユーザーに価値を届けられる進め方があるのでは？という思いもありました。
ということで、まだまだ試行錯誤中ですが、最近やってみてよかったな〜と思った進め方を残してみます✍️
1. ステークホルダーとのMTGに雑に参加してもらう
ママリアプリの機能開発には、さまざまなステークホルダーが関わってくるため、ステークホルダー側の要求を汲み取り、反映させていくことも重要になってきます。
以前は、ステークホルダーに要求をヒアリングするMTGを私がセットし、一人で参加し、あとから開発チームに落とし込むことが多かったのですが、
そうすると本来の意図が上手に伝わりきらなかったり、追加でヒアリングが必要なことが発生したり・・・。
つまり、わたしが中間に入ることでスピード感を持ちたかったのに、かえって時間がかかってしまったな〜ということがありました。
そんな時に開発者から「ヒアリング時点から呼んでくれていいよ」と言われ、ヒアリング時点から同席をしてもらうことにしました。
それによって、
生の会話に参加することで、要求の背景が正しく伝わる
開発目線で疑問点が出た時に、その場で解消できる
ステークホルダーとの関係値がもっと良くなり、その後も気軽に開発者からSlackでメンションなどしやすくなる
というメリットを実感しました💡
2. フィッシュボウル風のUIUX議論
以前は、デザイナーとユーザー体験やデザインを固める際、2人で議論して固まったものをチームに落とし込むことが多かったのですが（今もたまにそのように進める時もある）、
そうすると、なぜこのパターンになったのか？がこれまた上手に伝わらなかったり、別のパターンが良いのでは、となることも多々あります。
その議論自体はとても良いことなのですが、差し戻しによるデリバリー速度が落ちてしまうのを改善できないかな？と感じていました。
ただ、全員が発言できる議論だと、うまく収束できる自信も全くありません。
そんな時に開発者から（どういう文脈で紹介されたか忘れてしまったのですが）こちらの記事を共有してもらいました。
なるほど、発言者を絞りつつ、全員に参加して貰えばいいのか〜！
ということで、以下のようにユーザー体験・デザインの議論を進めてみる形式を取りました。
発言者は私とデザイナーのみ
パターンごとのメリットやデメリットを議論したり、その場でfigmaでUIに落とし込みながら良さそうなパターンを絞っていく
その間に開発者には質問や懸念点などがあればMiroで付箋を書き出してもらう
そのコメントを途中で、もしくは最後に拾っていく
（本来のフィッシュボウルとは多分違うのですが、方法はかなり参考にしました）
このような進め方にすることで、
（1つ目同様）生の会話に参加することで、要求の背景が正しく伝わる
懸念点を早めにキャッチして、アウトプットに反映できる
というメリットを実感しました💡
ちなみにこのフィッシュボウル風議論は、「デザイナーと私」以外にも「開発者2名と私」みたいな形式でも実施したことがありますが、チームの人数が多いとワークするなと感じました。
「綺麗に正しく」よりも「早めに雑に」巻き込むこと
施策が提案されてからユーザーに届くまでに綺麗なフローなんてものはあるようでなく、行ったり来たりするという前提で、
チームや開発者を「早めに雑に」巻き込んで行くことで、実はスピーディにコトが進んでいくのかも、という気づきがありました。
そして、100点満点のつもりの要求や仕様を持ち込むのではなく、100点に限りなく近いアウトプットをチームで出すための動きにフォーカスすることが大事だなとも思うようになりました。
私はプロダクトマネージャーとして、もちろん「意思決定者」ではあるのですが、それ以前に「チームで良いものを作るためのファシリテーター」なんだ、と最近は思っています。
少なくとも、伝書鳩ではなく、コラボレーションを促進してより良い成果を生み出すための動きをしていかないといけないですね。（自戒）
前提としてチームに感謝💌
今回の事例は、私が自分でゼロから考えて改善したというお話ではなく、開発者から提案をもらって実行してみてよかった！というお話でした。
こういった提案やアドバイスが積極的に集まる開発チームは本当に素敵だなと思うし、今後もそれを柔軟に取り入れていきたいと思っています。
また、今回は開発チームを含めた議論やコラボレーションに照準を当てましたが、もちろん、議論の方法だけが全てではありません。
例えば、同期のMTGだけが全てではなく、非同期のコミュニケーションでもっと改善できることはあるかもしれないし、
もっと早くユーザーに価値を届けるには？という大元のイシューに対してはやれることはさらにまだまだあります。
（ユーザーフィードバックをより早く得て施策に活かしていきたいよね、とか）
そういったことに対しても、今後もチームとして向き合っていきたいと思います！
この記事が気に入ったらサポートをしてみませんか？