すべての要求に応えないという勇気
はじめに
プロダクトオーナーとして様々なステークホルダーと会話すると、「この機能を追加して」「あの機能をもっと使いやすく」など、要望は尽きることがありません。
開発する側としてはステークホルダーのすべての要求に応えることは避けたいところです。ステークホルダーとの折衝については悩んでいる方も多く、僕も例に漏れずその一人ではあるのですが。
前回の記事でご紹介した「ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた」でこの辺の発見があったので、記事でご紹介したいと思います。
1. なぜすべての要求に応えるべきでないのか
1.1 プロダクトの核が喪失
無数の要求に応えようとすると、プロダクトの核心的な価値が薄れてしまう危険性があります。先ほど紹介した本に言わせると「なんでもできる『全部入りソフトウェア』」の完成です。
1.2 リソースの分散
限られたリソースを多くの機能に分散させることで、それぞれの品質が低下する可能性があります。
1.3 複雑性の増大
機能を増やすほどに、プロダクトの複雑性が増し、ユーザビリティが低下したり、バグの発生が増加したりする傾向があります。
また、以前紹介したことがありますが、仕様の衝突が起こる可能性があります。最悪の場合、機能を満たすために、いずれかの機能を制限して、仕様を実現するしかなくなります。
2. 「No」と言うための基準
2.1 プロダクトビジョンとの整合性
要求がプロダクトの長期的なビジョンと合致しているかを評価します。
2.2 ユーザー価値の評価
「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」という本でも、プロダクトの成功のためには、① ユーザー価値と事業収益がバランスを取りながら最大化している状態、② ビジョンが実現できている状態、この 2 つを満たす必要があると紹介されていました。その要求が本当に多くのユーザーに価値をもたらすかを検討します。
2.3 実装コストと期待される効果のバランス
実装に必要なリソースと、期待される効果を比較検討します。
常に意識すべきは「最小コストで最大成果をもたらせるか」です。
3. 「No」と言うための実践的テクニック
3.1 データに基づく判断
ユーザー行動データや市場調査結果を活用し、客観的な判断を下します。
僕は Google Analytics のユーザーイベントや DB のデータをクエリで集積して提示することをよくやっています。
3.2 代替案の提示
要求をそのまま受け入れる代わりに、より効果的な代替案を提案します。
3.3 段階的なアプローチ
すぐに全面的な実装ではなく、小規模な実験から始めることを提案します。
4. ステークホルダーとのコミュニケーション
4.1 透明性の確保
意思決定プロセスを透明化し、なぜその決定に至ったかを明確に説明します。
4.2 共感的なリスニング
要求の背後にある真のニーズや課題を理解するよう努めます。以下のテクニックが参考になります。
テクニック
アクティブリスニング： 相手の言葉を注意深く聞き、適切に要約し、確認質問をする。
感情マッピング： ステークホルダーの発言から感情を読み取り、マッピングする。これにより、表面上の要求の裏にある感情的なニーズを理解できる。
「5 つのなぜ」テクニック： 表面的な要求に対して「なぜ？」を5回繰り返す。根本的な課題や目的を掘り下げる。
4.3 フィードバックループの構築
決定後も継続的にフィードバックを収集し、必要に応じて再検討する姿勢を示します。
スクラムで開発している・いないにかかわらず、主要ステークホルダーと30分のフィードバックセッションを設けたり、匿名フィードバックアンケートを配布したりする案があります。ただ、実際にやってみたことがあるのですが、匿名フィードバックアンケートはしつこく催促しないとなかなか回答をもらえなかったり、自由記入式の質問が多いと回答率が下がったり、といった問題もあるので気をつけてください。
5. 「No」と言うことの難しさと向き合う
短期的な評価や人間関係への影響を恐れず、長期的な視点を持つ勇気が必要。意識すべきは「コミュニケーションは心地よさより明確さ」です
まとめ
プロダクトマネジメントにおいて、すべての要求に応えないという勇気を持つことは、真に価値あるプロダクトを作り上げるための重要な資質です。しかし、これは単に要求を拒否することではなく、プロダクトの本質的な価値を見極め、限られたリソースを最も効果的に活用するための戦略的な判断です。
最後に、「No」と言うことは終点ではなく、むしろより良いソリューションを見つけるための出発点であることを忘れたくないですね！