開発組織が陥りやすいビルドトラップについて考える

ビルドトラップとは

ビルドトラップとは成果・結果のためではなく、開発組織が機能を作ることだけに集中してしまうことです。

開発チームでよくありそうな状態だと思います。

これが頻繁に起こっていると作っているものへの主体性がなくなり、期限に追われ、開発チームは疲弊し、最終人が抜けていく流れにもなりかねません。

下の質問で「ぐぬぬ」となる場合は、組織がビルドトラップにかかっているかもしれません。

• ステークホルダーが開発するものと期限を決めていないか？

• 目標・指標が作るものによって、短い期間で変わってないか？

• プロダクトの機能のアイデアを思いついたのは誰か？

• ユーザーと最後に話したのはいつか？

• プロダクト組織の目標の体験と指標は何か？

• 権限のないプロダクトチーム、意思のないプロダクトチームになっていないか？

今回はなぜ、ビルドトラップが起こるのかを考えていきます。

ビルドトラップがなぜ起こるか

ビルドトラップの要因を4つに分解しています。

要因が大きくなるにつれて、解決するのに巻き込むべきメンバーが増えていきます。

• PdM

  • 「いつ」「何を」だけで「なぜ」がないまま開発進行していないか？

• 戦略

  • 事業戦略とは別にプロダクト戦略があるか？

  • 中長期的なプロダクトの提供価値があるか？

• プロセス

  • 戦略作成・調査/分析・打ち手だしをプロダクト組織でできるプロセスがあるか？

• 組織

  • 価値を提供することがよしとされるプロダクト型組織になっているか？

PdMにビルドトラップの課題がある場合

ユーザーの提供価値を考える必要があります。
開発組織全体が同じ認識を持つ必要があるので、メンバーごとで認識がずれている場合はすり合わせる必要がありそうです。
また、必要であれば、ステークホルダーも巻き込んだ上で、組織全体の認識を合わせることも必要になります。

戦略にビルドトラップの課題がある場合

中長期の事業戦略があるか？その上で、プロダクトの中長期戦略があるか？
ない場合は、ステークホルダー・開発チームを巻き込んで作成する必要があります。
プロダクト戦略は、機能を決めるのではなく、提供価値と指標を決めるのが大事になります。
機能案と目標だけ決まる戦略は危険です。中長期的にかなえる価値を考えたいです。

プロセスにビルドトラップの課題がある場合

戦略作成→調査/分析→打ち手だし→実行
の流れが開発チームでできていない場合は要注意だと思います。
なぜ作るのか？と何を作るのか？が開発チームが両方を理解していないと、受託開発組織になりかねないと思います。
現状のプロセスを可視化して問題点を出してプロセスを改善していきたいですね。

組織にビルドトラップの課題がある場合

組織体制・予算などから、開発組織が価値提供を検討した上で作るものが決められない・調整できない場合があります。
PMとして組織編成の責任を持つステークホルダーへ問題提起をして、現状の問題の認識を合わせることから始めると良いと思います。一緒に解決策を見つけていくのが良さそうです。

ビルドトラップについては『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』や小城さんのnoteにも書いてあるので、興味があった方はぜひ見てみてください。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける