SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

ProductZine Dayの第3回。オフラインとしては初開催です。

ProductZine Day 2024 Summer

ProductZine Day 2024 Summer

ソフトウェア開発者からプロダクトマネージャーへの転身に必要なマインドセット

「ステークホルダーに向き合う」ことの問題点―― 開発畑のプロダクトマネージャーの失敗から学べ

ソフトウェア開発者からプロダクトマネージャーへの転身に必要なマインドセット 第3回


 本連載は、ソフトウェア開発者からプロダクトマネージャーに転身した、ゆずたそ(@yuzutas0)さんが自身の経験を振り返り、切り替えるべきだったと考えるマインドセットを紹介していく連載です。第3回は、「ステークホルダーに向き合う」ことから発生する問題を取り上げます。コミュニケーションをとることではなく、プロダクトを通してユーザーに価値を届けることがゴールであることを今一度認識しましょう。(編集部)

はじめに

 こんにちは、ゆずたそ(@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」への変化です。「ステークホルダーと一緒に課題を洗い出す」「ステークホルダーと一緒に課題を解決する」というマインドセットが必要です。課題と向き合う仲間を作っていきましょう。

「to stakeholders」と「with stakeholders」との違い
「to stakeholders」と「with stakeholders」との違い

 例えば、ステークホルダー一人ひとりと向き合っていると、開発部門と営業部門の板挟みでスケジュールを決められなくなるでしょう。どちらも自部門にとって正しいことを言っているはずです。しかし、プロダクトにとってのベストを追求すると、開発部門に対しては「度重なるリリース遅延は許容できない」と言わなければいけないし、営業部門に対しては「間に合わないものは間に合わない」と言わなければいけません。

次のページ
採用ファネルで考える

この記事は参考になりましたか?

ソフトウェア開発者からプロダクトマネージャーへの転身に必要なマインドセット連載記事一覧

もっと読む

この記事の著者

ゆずたそ(ユズタソ)

自称企画屋・コンセプトデザイナーです。新規事業、急成長プロダクト、レガシーシステムとフェーズを問わず炎上現場に次々と巻き込まれ、システムアーキテクチャの再構築やエンジニアチームの立ち上げ、立て直しに従事してきました。現在は業務支援サービスの企画・開発を推進しています。著書・寄稿に『個人開発をはじめよ...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

ProductZine(プロダクトジン)
https://productzine.jp/article/detail/721 2021/11/09 15:28

おすすめ

アクセスランキング

アクセスランキング

イベント

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング