“作る”だけでは価値は生まれない。ソフトウェアエンジニアが学ぶべきプロダクトマネジメント

AIツールの進化は、ソフトウェアエンジニアの働き方に大きな変化をもたらしています。純粋な技術力がコモディティ化しつつある今、自身が開発するプロダクトが「誰の、どんな課題を解決するのか」を深く理解する「プロダクト志向」や、事業の成長に貢献する「ビジネス理解」の重要性が高まっています。言うなれば、エンジニアがプロダクトマネジメントのスキルを習得することが、有力なキャリアの選択肢になっているのです。

しかし、エンジニアがそのスキルを体系的に学ぶための道筋はまだ確立されていません。多くの人が手探りで知識を習得しているのが現状です。では、エンジニアはプロダクトマネジメントのスキルをいかにして学び、キャリアを切り拓いていけばよいのでしょうか。

今回お話を伺ったのは、identify株式会社の取締役CTOを約6年間務め、現在は複数企業の開発支援や技術顧問を行う岩崎裕馬さんです。岩崎さんは「すてぃお」名義でメディアプラットフォーム「note」やSNSでの発信を続けており、その高品質な情報は多くの方々の共感を得ています。

プロダクトマネジメントを担う上で必要なスキルセットの定義から、さらにはエンジニア時代の経験をどう活かし、何を“アンラーニング”すべきかまで、学習方法を語っていただきました。

• keyboard_arrow_down 求められるのは、課題の“Why”を考え、最小のコストで解決する力
• keyboard_arrow_down エンジニアがプロダクトマネジメントで陥る「ついHowを語りすぎる」罠
• keyboard_arrow_down 専門書、資格、そして雑談。ユーザー価値を深く知るためのアプローチ
• keyboard_arrow_down 自己流はNG。プロダクトマネジメントの「守破離」

――前提として、プロダクトマネジメントを担う方には、どのような役割が求められると考えていらっしゃいますか？

岩崎：創出できる「価値」と「投資コスト」を考慮し、プロダクトに関する意思決定をする役割が求められると考えています。

この価値には「ユーザー価値」と「事業価値」という2つの軸があります。ユーザー価値とは、ユーザーがサービスを「便利だ」「嬉しい」と感じるような要素です。一方、事業価値は、売上や利益の向上につながる要素を指します。

ユーザー価値が上がれば事業価値も上がるかというと、必ずしもそうではありません。たとえばWebメディアの場合、広告を掲載するとユーザー価値は下がる可能性が高いですが、事業価値は上がります。このように両者はトレードオフになる場合があるため、そのバランスを取ることが、まず重要な役割の一つです。

もう一方の軸である投資コストですが、プロダクトを開発・運用するには当然コストがかかります。投資コストが著しく高い意思決定は、プロダクト全体のROI（投資対効果）を悪化させてしまいます。そのため、創出できる価値が高く、投資コストは低いものから着手することが、プロダクトマネジメントの基本方針です。これに加えて、経営層からの制約や要望を汲み取りつつ、「ミドルマネージャー」として立ち回る役割も求められます。

――ROIの高い施策を見極める力が必要になるのですね。そのためには、具体的にどのようなスキルを磨くべきでしょうか？

岩崎：私が最も重要だと考えているのは、「なぜユーザーがこの課題を抱えているのか」という“Why”を考える力です。

いくつか例を挙げます。まず、有名なヒューストン空港の事例です。かつてこの空港では、手荷物受取所で「荷物が出てくるまでの待ち時間が長い」というクレームが非常に多かったそうです。そこで空港側は、人員を増やすなどしてオペレーションを改善し、待ち時間を数分短縮しました。しかし、クレームは全く減らなかったといいます。

乗客の行動を徹底的に分析した結果、クレームの本質は客観的な時間の長さではなく、「何もすることがなく、手持ち無沙汰で待たされる時間」が心理的な苦痛になっていることだとわかりました。そこで空港が取った対策は、到着ゲートから手荷物受取所までの通路を、あえて遠回りにして長くすることでした。その結果、乗客が手荷物受取所で何もせずに待つ時間はほとんどなくなり、クレームがほぼゼロになったそうです。

このように、表面的な課題に対して技術やオペレーションで「速くする」ことだけを考えるのではなく、「なぜユーザーは待つのが苦痛なのか？」という“Why”を深掘りしたからこそ、低コストで本質的な解決策を導き出せたわけです。

岩崎：同じような話で、ジェラルド・ワインバーグが書いた『ライト、ついてますか』という本があります。その中では、「エレベーターの待ち時間が長い」という課題に対し、エレベーターを速くしたり台数を増やしたりするのではなく、エレベーターの前に鏡を置くだけで解決した、という事例が紹介されています。この課題の本質も、「待っている時間が手持ち無沙汰で、無駄な時間だと感じてしまうこと」だったからです。

このように“Why”から考えれば、より楽な方法が見つかったり、そもそも何かをつくる必要がなかったりします。エンジニアは何かの依頼を受けた際、仮に他の解決策があるとしても、依頼内容やキーワードに思考が引っ張られてしまうことがあります。また、普段から技術を学んでいて解決策の解像度が高い分、高度な選択肢を想起しやすくもあります。

もしかしたらその課題は、プログラムに単純なif文を追加するだけで事足りるかもしれません。最小のコストで課題を解決するためにも、まずは「ユーザーはなぜその課題を抱えているのか」を、きちんと深掘りしていくことが大事です。

――エンジニア経験のある方が、プロダクトマネジメントを担うときにやりがちな失敗はあるでしょうか？

岩崎：私自身の失敗談からお話ししますと、過去の職場でプロダクトマネジメントを担った際、他のエンジニアに具体的な“How（実現手段）”を提示してしまっていました。エンジニアリングができるので、設計や実装の方法を見通せてしまうからです。

しかし、具体的な方法を渡してしまうと、エンジニアからオーナーシップを奪い、「指示されたとおりにやればいい」という状況を生み出してしまいます。結果として、ドメイン知識を学ぶ意欲まで削いでしまいかねません。

短期的には作業がスムーズに進むかもしれませんが、チームが成長せず、プロダクトマネージャーへの依存が強まる、といったマイナスの影響があります。プロダクトマネジメントには、プロダクトだけでなく「プロダクトをつくるチーム」を成長させる責務も含まれています。

――どうすれば、プロダクトチームを育てることができるでしょうか？

岩崎：チームの地力を高めるには、メンバーが自ら考えて行動し、失敗から学ぶ経験が不可欠です。そのため、具体的な方法は極力伝えず、ユーザーが抱える課題やプロダクトとして達成したい目標を共有するようにします。もし意見を求められた場合でも「あくまで参考だけど」「こういう考え方もある」といった前置きをして話すよう心がけています。

もちろん、エンジニアが考えた方法が明らかに不適切であれば助け船を出す必要はありますが、「100点の機能ではないけれど、確かにユーザーの課題を解決できる」のであれば、任せるのがよいと考えています。数週間後とか数ヶ月後に本人が「もっとよい手段があった」と自覚し、改善してくれることが、個人やチームの成長につながるからです。

また、ありがちな失敗として、プロダクトマネジメントを担うポテンシャルのある人は情報処理能力が高いことが多いため、複雑な運用フローを設計してしまう、というケースがあります。自分自身が理解できるため、「他の人も同じように操作できるだろう」と考えてしまいがちなんです。しかし、ほとんどの人にとって複雑な手順は大きな負担になります。運用負荷や認知負荷を可能な限り低減させることが重要です。

――先ほどのお話にあった「ユーザー価値」と「事業価値」という視点は、どのように習得すればよいでしょうか？

岩崎：まず取り組むべきは、ユーザー価値の理解です。エンジニアはプロダクト開発の過程でユーザーに接する機会があるので、そちらの方が習得しやすいと思います。

仮にペルソナを設定するなら、その人の具体的な人物像や日々の生活・業務などを鮮明にイメージできるようにします。最終的には、何も資料を見なくても「この状況で、あのユーザーならどう考え、どう行動するだろうか」と、頭の中でシミュレーションできる状態になるのが理想です。

以前、私が携わっていたidentify株式会社の動画素材提供サービスでは、ユーザーヒアリングなどを通して、マーケターの業務フローに対する解像度を高めることを意識していました。そのほかにも、ユーザーが読んでいる専門書を自分も読んでみる、関連分野の資格を取るなどの方法も有効です。

また、ユーザーの本音を引き出すには、ユーザーと親しい関係を築くことも大切です。それほど親しくない相手から、いきなり「課題を教えてください」と質問されても、ユーザーはうまく言語化できないですよね。むしろ、仲良くなって雑談する中で、「これが実は不便なんです」と、ぽろっと口にした一言に、プロダクトのコアな課題が隠されているケースも少なくありません。

社内向けのシステムを開発する際も同様で、この場合はユーザーである社員の方々と、日常的に交流しておくことが大切です。たとえば、他の職種の人たちとランチに行って話してみるといったことも、情報を得やすくするために重要だと考えています。

――エンジニアとしての経験が、プロダクトマネジメントのスキル習得に活かされた部分はありますか？

岩崎：一言でいえば「自己流を避ける」という姿勢が役立ちました。これは武道などにおける「守破離」の考え方に近いです。まず、本に書かれているようなプラクティスを「守り」、素直に実践する。そこから徐々に自分なりの応用を加えて「破」や「離」の段階に進むというものです。この学習プロセスは、エンジニア時代の経験で培われたものだと感じています。

どのような分野でも、先人たちが試行錯誤の末に生み出した優れた知識が体系化されています。特にエンジニアリングの世界は、体系化された知識が他の業界と比べても多いです。その前提知識があったからこそ、プロダクトマネジメントもまずは基本を学ぼうと思えました。

――まずはゼロからプロダクトマネジメントを学ぶ意識が重要で、中途半端にエンジニア時代のスキルを応用しようとしない、ということですね。最後に、これからプロダクトマネジメントを学ぶ方々へのメッセージをいただけますか？

岩崎：今後、エンジニアがプロダクトマネジメントのスキルを身につけることは、ますます重要になると考えています。AIツールの普及なども影響し、「エンジニアリングスキルを持ちながら、事業成長に直接コミットすること」がより価値を持つ時代になっていくからです。

もし普段は実装を担当している方であれば、設計やアーキテクチャについて考える、ビジネスドメインで使われる言葉の意味を調べる、あるいはユーザーがプロダクトをどのように使っているのかヒアリングしてみるなど、身近なところから始めてみることをおすすめします。そうした経験の積み重ねが、将来的に大きな力になるはずです。

 

取材：中薗昴、池田恵実
執筆：中薗昴
編集：池田恵実
撮影：本多香
撮影協力：ワインと鍋