優れたプロダクトチームと悪いプロダクトチームの重要な違い17

『INSPIRED』の著者マーティ・ケーガン（Marty Cagan）は『ユーザーストーリーマッピング』という本の推薦文で強いプロダクトチームと弱いプロダクトチームの違いを羅列しました。

優れたプロダクトチームと悪いプロダクトチームの重要な違い17

1. 優れたチームはプロダクトに対する強いビジョンを持ち、これを宣教師のように情熱的に追求する。悪いチームは傭兵集団のようだ。

2. 優れたチームはインスピレーションとアイディアを数値化されたKPIから得たり、顧客の悩みを観察、顧客が製品を使いながら作ったデータを分析し、問題を解決するために新しい技術を適用しながら得る。悪いチームはそうしない。

3. 優れたチームは主要ステークホルダーが誰なのかを理解し、ステークホルダーが提示する制約を理解する。また、ユーザーのための解決策だけでなくビジネスの制約事項を満足させられる解決策を作るために努力する。悪いチームはステークホルダーの要求事項を集める。

4. 優れたチームは開発する価値があるものを見極めるためにアイディアを素速く試すし、そのためのツールに慣れている。悪いチームは優先順位ロードマップを作るために会議をたくさん開く。

5. 優れたチームは社内の賢いリーダーとブレインストーミングすることを楽しむ。悪いチームは外から差し出がましく助言されることを嫌う。

6. 優れたチームはプロダクトオーナー、デザイナー、エンジニアが近くに座って機能とUX、技術に関して意見を交換する。悪いチームはメンバーが領域ごとに別れて配置され、何かをお願いするためには公式文書を作って会議を開かないといけない。

7. 優れたチームは革新のために新しいアイディアを継続的に試し、会社とプロダクトに役立つ方向に進む。悪いチームはテストに必要は許可を待ってる。

8. 優れたチームは強力なインタラクションデザインのように成功的なプロダクトのために必要な技術を使うべきだと主張する。悪いチームはインタラクションデザインが何か知らない。

9. 優れたチームはエンジニアがプロダクト探索のためにプロトタイプを試せる時間を毎日設ける。これによってエンジニアはプロダクトをより良くするために自分たちの意見を出せる。悪いチームはプロトタイプをスプリントMTGで見せてくれる。

10. 優れたチームは顧客をより深く理解しチームの新しいアイディアに顧客がどう反応するか見るためにユーザーと顧客に毎週会う。悪いチームは自分たちが顧客と同じ目線を持ってると思う。

11. 優れたチームは彼らのアイディアの中で多数が顧客の役に立たないことを知っている。顧客が欲しがっても成果を得るためには複数のスプリントが必要であることを知っている。悪いチームはロードマップに乗っているものを作り、予定どおり納品したら満足する。

12. 優れたチームは速いスピードとプロセス周期の短縮が革新の核心であることを理解している。速いスピードは正しい手法からでるもので、仲間を圧迫して出せるものではないことを知っている。悪いチームは同僚が真面目に仕事しないからスピードが遅いと愚痴を言う。

13. 優れたチームは要請を評価してビジネス的に実行可能な解決策を確保し統合的計画を樹立する。悪いチームは営業主導で働くことに不満をもつ。

14. 優れたチームは作ったプロダクトがどう使われるかすぐ知ることができるし、データをもとに調整できるように作業を組む。悪いチームは「あったら良いかもしれないもの」を分析して報告する。

15. 優れたチームは持続的にマージ・リリースし、小さなリリースの連続が顧客に安定的な解決策を提供することを知っている。悪いチームは辛いマージ作業のあと自動化されてないテストを遂行し、全てを一気にリリースする。

16. 優れたチームはリファレンスユーザーに集中する。悪いチームは競合に執着する。

17. 優れたチームはKPIで重要な成果を出した時に祝う。悪いチームは何かを最終的にリリースしたことを祝う。

優れたチームになりたい

以前はアジャイルに開発していると言いながらも悪いチームの働き方をそのまま体現していたところが多くあって、今思い返すと反省するべきところが多くあります。ユーザーより溜まっていたバックログを見ることが多かったですし、なるべくまとまった機能を出すようにしてました。「ドメイン知識が重要」と言いながらエンジニアの意見を聞くより完成された設計を渡す形の開発だったので今思うととてもアジャイルとは呼びづらいです。

今はどっちかと言うと優れたチームに近づいたと思っていますが、まだまだ強いプロダクトチームを名乗るには程遠いように感じます。良いプロダクトを作る中で強いチームになれるように精進しないとですね。