開発プロセスでの貢献
プロダクトマネージャーは既存仕様の整理や受け入れ条件の整理など、常にバックログアイテムの詳細化に追われています。ですが、その裏では検討したいが手が回らず形にできていないバックログアイテムが多く存在しています。
そんなプロダクトマネージャーの脳内にあるバックログアイテムを引き出し、形にすることができるのがプロダクトデザイナーです。
プロダクトデザイナーはデザインモックとして可視化することで、バックログアイテムとして作成されていないアプリケーションの課題をプロダクトマネージャーに見せることが可能です。
また、プロダクトデザイナーの存在は開発プロセスに対しても貢献することができます。
スクラム開発と言えど、アプリケーションの開発プロセスにおいては、要件定義からデザインモックの作成、実装といった単線的なプロセスに陥りがちです。さきに挙げたように、バックログアイテムの作成はプロダクトマネージャー、精緻化はプロダクトデザイナーも含むスクラムチームメンバー全体、実装は開発者といった流れで、上流工程におけるプロダクトマネージャーの作業が出発点のようにも見えてしまいます。
ですが、プロダクトマネージャーがプロダクトデザイナーに真に期待するのは、上記のプロセスの逆算を可能にする「アブダクション」的なプロセスをもたらすことではないでしょうか。
潜在的なバックログアイテム(アプリケーションの課題)は確実に存在します。あなたはその潜在的なバックログアイテムをプロダクトマネージャーから聞き出し、優先度を協議してもっとも重要なものをデザインモックに起こしましょう。
その先のプロセスはどのような方法も取り得ることができます。デザインモックの精度が甘ければ、モックをもとに要件の整理をプロダクトマネージャーに要求しましょう。
整理が難しければもととなる要件の解像度が低いことが原因なので、デザインモックをもとに顧客にソリューションヒアリングを行うのも良いかもしれません。デザインモックが余すことなく要件を満たしているのであれば、そこからバックログアイテムの作成につなげることができます。
追加で検討すべきことが出てきたなら、それはデザインモックがもたらした成果です。それはプロダクトデザイナーがプロダクトマネージャーに思考のハシゴを提供したことになります。
アプリケーション開発において日々ユーザーヒアリングを行いユーザーの課題を解決しようとしているように、プロダクトマネージャーに対しても同じことを行いましょう。プロダクトデザイナーにとってプロダクトマネージャーは、もうひとりの「顧客」でもあるのです。
プロダクトマネージャーは常にアプリケーション開発の効率化と透明性を意識しています。そのために自身の考えに対して建設的な批評を行い、共創を行えるようなコラボレーターを求めています。
プロダクトデザイナーはぜひプロダクトマネージャーの期待値をおさえ、アプリケーション開発を強力に推進する役割の獲得を目指してください。
次回が本連載の最終回となります。ぜひ、お見逃しなく。