最も行動変容が必要とされる「リソースの捉え方・扱い方」 ―― 開発畑のプロダクトマネージャーの失敗から学べ

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

　本連載は、ソフトウェア開発者からプロダクトマネージャーに転身した、ゆずたそ（@yuzutas0）さんが自身の経験を振り返り、切り替えるべきだったと考えるマインドセットを紹介していく連載です。最終回となる第5回は、現在筆者も苦戦しているトピックの一つでもあるという「リソース管理」に関する問題を取り上げます。（編集部）

はじめに

　こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。

　主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。

リソースはプロダクトの生命線

　連載最終回となる今回はリソース（人材、資金、時間）について扱います。ステークホルダーの多様な視点をもとに（第3回）、あらゆるリスクを検知して（第2回）、トレードオフに対する意思決定を行うことで（第4回）、プロダクトとして品質を担保できるようになります（第1回）。これらを徹底するには、多くの人材、資金、時間が必要です。リソースはプロダクトの生命線と言えます。

　筆者がソフトウェア開発者としてソースコードを書いていたときには「リソース管理」という言葉に抵抗がありました。「ソフトウェア開発は不確実性が高いのだから見積もりやスケジュール管理をしても無駄ではないか」「ソフトウェア開発者はスキルや状況によって生産性が変わるのだから人員をリソースとして考えるのは筋違いではないか」「プロダクトさえあれば運営に必要な予算や資金はすぐに集まるのではないか」と思っていました。しかし、プロダクトマネージャーに転身したことで、見え方は変わりました。

　リソース不足でサービスを閉じる、というのはよくある話です。プロダクトを世に出せて、ユーザーから具体的な要望も挙げてもらって、それらを改善すれば状況がよくなると確信している。しかし、開発の予算や人員を投資し続けられない。泣く泣くクローズせざるを得ない。やがては似たようなサービスが出てくる。彼らは何年間も粘って、ついに市場を獲得する。自分には悔しい思いだけが残る。珍しい話ではないと思います。結局のところリソースの集め方や使い方で負けているのです。

　プロダクト単位ではなくとも、何らかの機能や施策を例に挙げてもよいでしょう。この機能を実装すべきだ。この施策を実施すべきだ。たとえプロダクトマネージャーの一人がそう考えていても、開発の予算や人員をそこに投資できない。社内で長々と優先順位の会話を続けているうちに、いつの間にか競合他社が似たような機能や施策を実施している。競合に先手を打たれてから突然慌てて、劣位解消のために付け焼き刃の対抗策を講じる。だったら最初から全力で投資すればよかったのに！

　リソース管理は筆者自身が特に苦戦しているトピックの一つです。周囲のプロダクトマネージャーの話を聞いても、ジュニアにはジュニアなりの、シニアにはシニアなりの悩みがあるように思います。ジュニアスタッフの場合だと、開発スケジュールが毎回のように遅延して、そのたびに関係者との調整で苦い思いをしている。シニアスタッフの場合だと、ロードマップや予算や人員の計画をなかなか達成できない。デベロッパーからプロダクトマネージャーに転身した方の中には、同じような境遇に陥っている方がいるのではないでしょうか。

　昨日までソースコードを書いていた。今日からプロダクトを任された。1年後までに開発したい案件のリストがある。何となくで開発をしているけど間に合うのだろうか。今の人数で足りているのだろうか。このままで本当によいのだろうか。プロダクトマネージャーが現状を正しく認識せず、節約すべき無駄を節約せず、調達すべきリソースを調達しなければ、担当プロダクト（あるいは機能や施策）の生命線は絶たれることになるでしょう。1人の開発者として目の前のソースコードを直す立場と、5人のプロダクトチームを任された立場だと、見るべきものは異なるはずです。

　そこで本稿では「リソースの効率活用」と「リソースの調達」について述べます。直接的に予算や人事に関わらない方であっても「エンジニアの人数が足りません」「スケジュールに間に合いません」といった会話を一度でもしているのであれば、本稿が役に立つはずです。問題解決のヒントを持ち帰っていただけると幸いです。