【ITニュース解説】Inspired by Marty Cagan : Lessons, takeaways, and real world product management insights

プロダクトマネジメントという言葉を聞いたことがあるだろうか。システムエンジニアを目指すあなたにとって、直接的に開発作業をするわけではないプロダクトマネージャーの仕事は遠いものに感じるかもしれない。しかし、ソフトウェアやシステム開発の現場で働く上で、プロダクトマネジメントの考え方、特に著名なMarty Cagan氏の提唱する原則を理解することは非常に重要だ。なぜなら、あなたがこれから開発に携わるシステムや機能は、単なるコードの集合体ではなく、誰かの問題を解決し、ある目的を達成するための「プロダクト」の一部だからだ。

Marty Cagan氏は、良いプロダクトには四つの側面が不可欠だと説いている。一つ目は「価値（Valuable）」があること。これは、ユーザーが本当にそのプロダクトを欲しがるか、使うことで彼らの生活や仕事が改善されるか、という点だ。二つ目は「使いやすい（Usable）」こと。どんなに優れた機能があっても、操作が難しかったり、直感的でなかったりすれば、ユーザーは使ってくれない。三つ目は「実現可能（Feasible）」であること。これは、技術的にそのプロダクトを開発し、運用し続けることができるかという側面で、システムエンジニアの役割が非常に大きく関わる部分だ。そして四つ目は「ビジネスとして存続可能（Viable）」であること。収益を上げたり、コストを削減したりといった形で、そのプロダクトがビジネスとして成立し、継続していけるかという視点だ。これらの四つの側面すべてを満たして初めて、真に価値のあるプロダクトと言える。

プロダクト開発には常にリスクが伴う。Cagan氏はこれを、先ほどの四つの側面に紐づけて「価値のリスク」「ユーザビリティのリスク」「実現可能性のリスク」「ビジネス的存続可能性のリスク」と呼ぶ。価値のリスクとは、ユーザーが製品を欲しがらないかもしれないというリスク、ユーザビリティのリスクとは、ユーザーが製品を使いこなせないかもしれないというリスクだ。実現可能性のリスクは、技術的に開発が不可能だったり、予定した期間やコストで完成できなかったりするリスクを指す。これはシステムエンジニアにとって特に意識すべき点だ。そしてビジネス的存続可能性のリスクは、その製品がビジネスとして成り立たないかもしれないというリスクである。プロダクトチームの主要な役割は、これらのリスクを開発の早い段階で特定し、最小限に抑えながら、顧客の抱える問題を解決するソリューションを生み出すことにある。

多くの企業では、単に「機能（フィーチャー）を作る」ことに焦点を当てたフィーチャーチームが存在するが、Cagan氏はこれに対し、より大きな目的意識を持つ「プロダクトチーム」の重要性を強調する。フィーチャーチームは与えられた仕様に基づいて機能を開発するが、プロダクトチームは顧客の問題を解決し、ビジネス目標を達成することに責任を持つ。つまり、単に「何をどう作るか」だけでなく、「なぜそれを作るのか」「それによって何を実現したいのか」という上位の目的を常に意識して行動する。システムエンジニアとして、自分が開発する機能がプロダクト全体のどの問題解決に貢献し、どのような価値を生み出すのかを理解することは、仕事の質を高め、より良い提案をする上でも不可欠だ。

プロダクトマネージャーは、しばしば「プロダクトのCEO」と表現されることがあるが、Cagan氏はこの表現には誤解があると感じている。プロダクトマネージャーは、プロダクトの成功に最終的な責任を負うものの、実際には、直接的な権限は限定的である。彼らは、エンジニア、デザイナー、マーケターなど、さまざまな専門家からなるプロダクトチームを、明確なビジョンと戦略で導き、チームメンバーの協力を促すことで、プロダクトを成功に導く必要がある。このため、影響力、リーダーシップ、そしてコミュニケーション能力が非常に重要となる。システムエンジニアは、プロダクトマネージャーが提示する「何を解決したいのか」という問いに対し、「どうすれば技術的にそれが可能か」「より良い解決策はないか」という視点から、積極的に協力し、意見を交換するパートナーとなるべきだ。

多くのプロダクト開発チームが陥りがちな罠として、「ロードマップ」の問題が挙げられる。従来のロードマップは、特定の日付までに特定の機能をリリースするという「アウトプット」に焦点を当てがちだ。しかし、Cagan氏は、プロダクト開発は不確実性に満ちているため、このような固定的なロードマップはしばしば失敗に終わると指摘する。本当に重要なのは、ロードマップに書かれた機能ではなく、「どのようなビジネス成果や顧客価値を生み出すか」という「アウトカム」に焦点を当てることだ。プロダクトチームは、柔軟なアプローチを取り、仮説検証を繰り返しながら、最も効果的な解決策を見つけていく必要がある。システムエンジニアも、与えられたタスクをただこなすだけでなく、そのタスクが本当に期待する成果につながるのか、もっと良い実現方法はないかといった視点を持つことで、プロダクト開発の柔軟性と効率性を高めることができる。

Cagan氏が提唱するプロダクト開発のプロセスは、大きく「探索（Discovery）」と「実行（Delivery）」の二つのフェーズに分かれる。探索フェーズでは、顧客のニーズを深く理解し、仮説を立て、プロトタイプやMVP（Minimum Viable Product、最小限の機能を持つ製品）を用いて検証を繰り返すことで、製品の価値、使いやすさ、実現可能性、ビジネス存続可能性に関するリスクを低減する。ここで「これは本当に正しい製品なのか？」という問いに答える。そして、探索で得られた確信に基づいて、実際に製品を開発しリリースするのが実行フェーズだ。この二つのフェーズは並行して、継続的に行われる。システムエンジニアは、実行フェーズでコードを書く役割を担うことが多いが、探索フェーズにも積極的に関与し、技術的な実現可能性の観点から意見を述べたり、プロトタイプ作成を手伝ったりすることで、より早い段階でリスクを発見し、手戻りを減らすことができる。

プロダクト開発の出発点は常に「顧客」だ。Cagan氏は、顧客の声に耳を傾け、彼らが抱える真の課題を理解することの重要性を繰り返し強調する。顧客は問題を抱えているが、必ずしも最適な解決策を知っているわけではない。プロダクトチームは、顧客の言葉の裏にある本質的なニーズを見抜き、それを解決する革新的な製品を生み出す必要がある。このプロセスにおいて、データも非常に強力なツールとなる。製品の利用状況やユーザー行動に関するデータを分析することで、客観的な根拠に基づいて意思決定を行い、製品の改善につなげることが可能になる。システムエンジニアも、自分が開発する機能が誰に、どのように使われるのかを想像し、データから得られるインサイトを理解することで、よりユーザーセントリックな開発が可能となるだろう。

そして、プロダクトは一度作ったら終わりではない。市場環境や顧客のニーズは常に変化するため、製品もまた、常に進化し続ける必要がある。プロダクトチームもまた、持続的に学び、改善を重ねていくべきだ。新しい技術の登場、競合の動向、そしてユーザーからのフィードバック。これらすべてが、次の製品改善のヒントとなる。システムエンジニアとして、常に新しい技術を学び、自分の担当するシステムの改善点を提案し続けることは、自身の成長だけでなく、プロダクト全体の競争力向上にも寄与する。

まとめると、Marty Cagan氏のプロダクトマネジメントに関する教えは、単にプロダクトマネージャーのためだけのものではない。システムエンジニアとして、あなたがこれから関わるプロダクトが、本当に世の中に価値を提供し、成功を収めるためには、「何を、なぜ、誰のために、どうやって作るのか」という全体像を理解することが不可欠だ。単にコードを書き、システムを構築するだけでなく、そのプロダクトが解決しようとしている問題、目指している成果、そしてそこに伴うリスクを把握し、プロダクトチームの一員として積極的に貢献すること。それが、これからのシステムエンジニアに求められる新たな視点であり、より価値の高いエンジニアへと成長するための道標となるだろう。