はじめに
こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。
主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。
話を聞くことはゴールではない
前回は「責任から逃げてしまう」という問題を取り上げました。法律や集客などの幅広い論点について「Not for me」（この仕事は私向きではない）と考えてしまうと、プロダクト開発は破綻します。対処策として「多様な視点からコメントを受けること」「責任を果たせているかどうかをチェックすること」の2点が必要になると話しました。
今回は「ステークホルダーに向き合う」ことの問題点を取り上げます。プロダクトマネージャーが自身の責任を果たすために「全員に話を聞く」「結果を可視化する」の2点を心がけると、どのような課題が生じるでしょうか。2つの正反対のエピソードを紹介します。
1つ目は、筆者が周囲のプロダクトマネージャーから聞いた話です。プロダクトマネジメントのチームを率いており、部下に対して「営業担当にこの要件でOKか聞いてほしい」「リーガルレビューを実施してほしい」と指示を出したそうです。その後、案件が進まないので進捗を確認すると「話を聞いたけどNGでした」「その業務は代理店に任せているので分からないそうです」との報告が寄せられました。そこから次の一手を打つことなく、案件は止まっていました。ただ話を聞いただけで終わってしまっていたのです。
2つ目は、筆者自身の体験です。法務部に「これだと難しいかもしれませんね」「私はこのあたり詳しくないですけど」といった回答を受けると「じゃあ誰が詳しいんですか」「他社のこの事例はどうなっているのでしょうか」などとまくし立ててしまったことがあります。言われたほうは負担に感じるでしょう。レビューや承認が形骸化して、YESと言わせるだけのコミュニケーションになってしまいます。周囲と足並みがそろわずに空回っていたのです。
どちらのエピソードも、ステークホルダーと協業できているとは言えません。「聞く」という作業で終わってしまっています。「聞く」ことがゴールになってしまっています。ステークホルダーと足並みをそろえて「どのような課題があるのか」「どういう方向なら実現できるのか」を模索しなければいけません。
当初の意図としては、品質を担保したプロダクトをユーザーに届けることが目的で、これは連載1回目の記事で説明したとおりです。「関係者に話を聞いてきました」「NGでした」では、プロダクトをユーザーに届けていません。
品質を担保したプロダクトをユーザーに届けるには、早期にリスクを検知することが重要で、これは連載2回目の記事で説明したとおりです。だからこそ多様なステークホルダーにヒアリングやレビューを依頼する必要があります。YESと言わせるだけでは、リスクを検知できていません。
ステークホルダーに向き合うことの問題点
なぜこのような失敗をしてしまうのでしょうか。「ステークホルダーを仲間に引き込めていないからだ」と筆者は考えます。
（1）必ずしも周囲が動いてくれるわけではないので、焦りが生じます。他の人を100%コントロールできるわけではありません。
（2）ステークホルダーが増えると、コミュニケーションに時間がかかります。何度も同じような会話をしたり、合意形成がスタンプラリーのようになったりと、フットワークが重くなってしまいます。つい愚痴を言いたくなります。
（3）コミュニケーションの過程で、板挟みが生じます。ある人はA案がダメだと言い、別の人はB案がダメだと言います。「あれもダメ」「これもダメ」を積み重ねると、話がNGで終わってしまいます。案件を進めにくくなります。
ソフトウェア開発者としてソースコードと向き合っていた頃は「リリースが遅れます」「この要件はスコープから外しましょう」と安易に言っていました。ステークホルダーと向き合うようになると、物事の見え方は上記のように変わりました。ある意味では、これは一歩前進だと言えます。
上記の課題を乗り越えるには、さらに一歩進み、ステークホルダー一人ひとりに向き合うのではなく「ステークホルダー全員と一緒にプロダクトに向き合う」ことが求められます。「to stakeholders」から「with stakeholeders」への変化です。「ステークホルダーと一緒に課題を洗い出す」「ステークホルダーと一緒に課題を解決する」というマインドセットが必要です。課題と向き合う仲間を作っていきましょう。
例えば、ステークホルダー一人ひとりと向き合っていると、開発部門と営業部門の板挟みでスケジュールを決められなくなるでしょう。どちらも自部門にとって正しいことを言っているはずです。しかし、プロダクトにとってのベストを追求すると、開発部門に対しては「度重なるリリース遅延は許容できない」と言わなければいけないし、営業部門に対しては「間に合わないものは間に合わない」と言わなければいけません。
