はじめに
こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。
主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。
「Not for me」からの卒業
前回は「品質から逃げてしまう」という問題を取り上げました。焦りに負けると、品質を担保しないまま、顧客にデバッグさせることになります。対処法として、企画とテストに投資せよと話しました。
今回は「責任から逃げてしまう」という問題を取り上げます。プロダクト開発はソースコードを書くだけではありません。法律や集客などの幅広い論点があります。これらの論点を考慮せずに、ソースコードだけに注目しても、サービスとしての品質を担保できません。自身の責任範囲は想像以上に広くなるのだ、ということを認識しましょう。
つい「私は法律に詳しくないので任せます」「キャンペーンを打つタイミングはリリースに合わせてください」「このチームを動かす権限を持っていないのでスケジュールに間に合いません」などと発言しそうになります。仮にデベロッパーがこのような発言をしても、ソースコードを書いてさえいれば許されるかもしれません。しかし、プロダクトマネジメントを担当する人間が「Not for me」（この仕事は私向きではない）と考えてしまうと、プロダクト開発は破綻します。
スキルや知識がある専門家に助けてもらう。キャンペーンの意図や背景を踏まえて今後の方針を提案する。権限がある人にチーム間の連携方法について相談する。どのような状況でも、できることはあるはずです。ただ周りに流されるだけなら、プロダクトをマネジメントできているとは言えません。「Not for me」のマインドセットから卒業しましょう。
まずは、責任範囲を知りましょう。なるべく多くの関係者を巻き込み、多様な視点からコメントを受けることで「ここを押さえないといけないのか」と気づくことができます。そして、責任を果たせているかどうかをチェックしましょう。プロダクトの利用状況、問い合わせの件数、事業利益への貢献度など、結果指標をシビアに見ることで「アウトカムを出せたのか」が分かるはずです。
検討漏れはトラブル直行便
プロダクトマネージャーの視点は、デベロッパーのそれとは異なります。担当プロダクトの成功に直接的な責任を負うからです。自身の責任範囲を認識せず、何かを後回しにしたり、見て見ぬふりをしたりすれば、必ずトラブルにつながります。他の誰かが代わりに推進してくれるわけではないからです。プロダクトに関わるすべてに当事者意識を持つほうが、「Not for me」のスタンスでいるよりも、巡り巡ってラクになるでしょう。マインドセットの変革が必要です。
プロダクトマネジメントにおいて「Not for me」が通用しないのは、減点方式の側面があるからです。どれだけ革新的な企画だとしても、どれだけ素晴らしい開発チームだとしても、法令違反やセキュリティインシデントが続くようであれば、そのプロダクトが世間に受け入れられることは難しいでしょう。他の要素が素晴らしくても、1つのNGによってプロダクト全体がNGになるのです。プロダクトマネージャーは「Not for me」を言えない立場なのだと思います。
過去に筆者が体験したり、目撃したりした例を3つ挙げます。
1つ目は「カスタマーサポート」の話です。プロダクトの新機能をリリースしたのですが、新機能に関する問い合わせ対応マニュアルを用意できていませんでした。デベロッパーたちがリリースに満足している一方で、カスタマーサポート部門は大混乱です。結果としてユーザーに迷惑を掛けました。無意識のうちに「カスタマーサポートは自分たちとは関係ない」というマインドセットで行動した結果です。
2つ目は「法令遵守」の話です。プロダクトにメッセージ機能を追加するにあたって、リリース直前になって弁護士に指摘を受け、手戻りが発生しました。電気通信事業者の届け出を出す必要があったのです。また、警察からの照会に備えて、データを保存できるように、物理削除ではなく論理削除にすることを提案されました。各種手続きや修正対応によって、目標スケジュールを大幅に遅延しました。無意識のうちに「リーガルは自分たちとは関係ない」というマインドセットで行動した結果です。
3つ目は「営業・販促」の話です。「システム開発は不確実性が高いのでリリースのスケジュールは約束できない」「機能追加のスケジュールを外部に約束しないでほしい」というデベロッパーチームの強い主張を受けて、販促施策に関する他社調整を進めにくくなりました。そうこうしているうちに競合が類似機能をリリースし、競合の導入事例が増え、営業の難易度が上がり、売上毀損につながりました。開発チームに対して「無理にでも目標を決めましょう」「◯日までにリリースしてください」と発令したところ、一気に開発が進み、デベロッパーからは「目標があったほうがメリハリが出ますね」という言葉が挙がりました。営業や販促の事情を伝えて、目標スケジュールを提示する（またはチームに提示してもらう）べきでした。無意識のうちに「営業や販促は自分たちとは関係ない」というマインドセットで行動した結果です。
プロダクトマネージャーは、開発チームのマネージャーではなく、プロダクトのマネージャーです。筆者のようなデベロッパー出身の場合だと、ついつい「デベロッパーに対して理解のある存在」「システムの仕様詳細まで語れる存在」として振る舞ってしまいます。これでは役割をわざわざ分けている意味がありません。システム開発者にとって耳心地の良い話をするのではなく、ラストマンシップを発揮し、プロダクトをあるべき方向に導きましょう。
ソースコードだけがプロダクトなのではありません。サポートスタッフの運用に乗せないとユーザーは安心してプロダクトを使えないでしょう。UIを詰めないと意図した通りに使われないでしょう。法令を遵守しないと関係各所に迷惑を掛けることになります。リリース予定を見立てないと営業・販促の施策を仕込めません。これらの要素は、システムリリースのさらに後工程に影響します。ユーザーにプロダクトを届けられる状態になった後、プロダクトが価値を生み出すときに大事になります。「Not for me」を言う余地はないはずです。プロダクトを通してユーザーに（そして社会に）価値を提供するという、最後の最後に対するマインドセットが問われます。
