MVPM: 有用なプロダクトマネージャーになるためにフォーカスしてはならないこと

この図をご覧になったことがある方もいらっしゃるでしょう。プロダクトマネジメントが多様なスキルセットの交差点であることをエレガントに示しています。

Originally from http://www.mindtheproduct.com/2011/10/what-exactly-is-a-product-manager/

そのシンプルさゆえに、この言葉はプロダクトマネジメントのミームとして最も成功を収め、プロダクトマネジメントという学問にとって良い影響を与えてきました。

昔、若いPMの卵であった私は、この言葉によって、学習の幅を広げるために構成する必要があることに気づきました。しかし、どこに焦点を当てるべきかということについては、教えてくれませんでした。私はすべてを学ぼうとし始めましたが、今にして思えばそれは間違いでした。

この3つの円についてすべてを学ぶには、この地球上に十分な時間はありませんので、この図が役に立つとしても、結局は非現実的なものになってしまいます。

それよりも、その交点を構成するものが何であるかを知る方がずっと役に立ちます。

この交差点は、私がMVPM（Minimum Viable Product Manager）と呼んでいるもので、効果的なジェネラリストプロダクトマネージャーになるために役立つ一連のスキルや知識を定義しており、ほとんどすべての問題に取り組むことができる人たちです。

MVPMは、決して、効果的になるためにそのスキルを習得する必要があることを意味するものではありません。それはこれから始める人にとって非現実的であり、逆効果です。その代わりに、この本は、存在しないプロダクトマネジメントのコースのシラバスのようなものと考えてください。

私は、若き日の自分、新米プロダクトマネージャー、そしてレベルアップを目指す経験豊富なPMのために、この本を書きました。図と対称になるように、スキルは分野ごとのセクションに分けられています。ここでは、注力すべき3つの重要なコンセプトとスキル、そして注力すべきではない1つのスキルを取り上げています。できるだけ平易な言葉で、どの分野にも冷静に取り組もうとする人向けに書いています。

▼本記事の内容

この記事は、MVPM: Minimum Viable Product Managerを、著者の了承を得た上で翻訳したものです。
著者: Brandon Chu
翻訳者: 渡辺圭祐

テクノロジー

1. スタック

エンジニアが「スタック」と呼ぶのは、プロダクトに機能を提供する（つまりプロダクトを動作させる）ために使用されるテクノロジーのレイヤーのことを指します。お客様がランディングページを開いた瞬間から、アカウントを削除するまでの間、スタック内のテクノロジーがすべてを処理します。

最速の学習方法 – エンジニアに頼んで、スタックを高レベルで説明してもらう。各技術の名前を書き留めておく。これらの用語を素早くググれば、選択した各技術の高レベルの利点とトレードオフ、およびそれらがどのように調和して動作するかを学ぶことができます。簡単にウサギの穴に落ちてしまうので、ハイレベルなものにとどめておきましょう（検索キーワードに「トレードオフ＋メリット＋対(trade offs + benefits + vs)」を追加してください）。

どうすればより良いPMになれるのか？– エンジニアが何かを構築する方法について議論しているとき、専門用語が部屋中に飛び交います。スタックを知っていれば、少なくともそれについていくことができますし、時間が経つにつれて、スタックのどの深さを指しているのか理解できるようになります。一般的に、スタックの中で触らなければならない層が多いほど、あるいは層が深いほど、変更はより複雑でリスクの高いものになります。これを知ることで、問題を解決するための別の方法を再度検討するようになるかもしれません。

2. システムアーキテクチャー

スタックがどのような技術を使用しているかを表すとすれば、システム・アーキテクチャは、それらの技術がどのように構成され、プロダクトを提供するために連携しているかを表します。スタックが主に生の技術的能力であるのに対し、プロダクトのアーキテクチャは顧客が意図する動作を設計に取り入れるものである。

最速の学習方法 – エンジニアにアーキテクチャを描くように頼む。このような答えが返ってくるでしょう。

まず、慌てないことです。システムの各コンポーネント（ボックス）が何をするのか、説明してもらってください。あるものはインターネットのリクエストを処理し、あるものは「ビジネスロジック」を収容し、さらにあるものは保存されるデータを保持します（シリンダー）。

次に、信じられないかもしれませんが、これはあなたにとって非常に有益なことです。

アーキテクチャを理解すると、プロダクトをシステムのように考えるようになり、それは一般的にエンジニアも同じように考えるでしょう。システム内の各コンポーネントが全体にどのように寄与しているかを理解することで、より良い意思決定やトレードオフを行うことができるようになります。

一般的に、システムの中で最も接続の多い部品は、データや機能を依存しているものが多いため、変更が最も複雑になります。ビルドを完了するために変更しなければならないコンポーネントが多ければ多いほど、依存関係も増え、プロジェクトの実行は困難になります。

大企業では、扱うコンポーネントの数は、対話が必要なチームやグループの数と同義であることが多く、プロジェクトを実行するために必要な調整も多くなります。

3. データモデルとそのAPI

データモデルは、プロダクトが使用する情報を整理し、その情報の断片が互いにどのように関連しているかを標準化するものです。「情報」とは、ユーザー、プロダクト、クレジットカードなどのことを指し、これらを総称して「エンティティ」と呼びます。これらのエンティティは、特定の構造化された方法で互いに関連付けることができます。例えば、ユーザーは多くのプロダクトを持つことができますが、クレジットカードは1つしか持つことができません。

データモデルは、特定のエンティティが特定のコンポーネントに「住んでいる」という点で、システムアーキテクチャと密接に関係しています。ユーザーモデルはコンポーネントAにあり、商品データもそうかもしれませんが、クレジットカードはその機密性から、コンポーネントBに置かれます。しかし、その中でどのユーザーがクレジットカードを保持しているかを知る必要がある場合、データを共有するためにコンポーネントAからコンポーネントBに接続する必要があります。それはより難しく、それを達成するためにAPI（アプリケーション・プログラミング・インターフェース）が必要になります。

APIはデータモデルの上に構築され、任意の2つのコンポーネントが互いに会話し、その基礎となるモデルに関する情報を交換する方法を表します。重要なのは、APIによって外部のコンポーネントと対話できるようになることです。GoogleマップからUberを呼び出すとき、GoogleマップアプリはUberのコンポーネントと会話しているのです。ほとんどのアプリケーションには、パブリックAPIとプライベートAPIがあり、それぞれインターネット上の誰でも使えるものと、指定した人だけが使えるものがあります。公開APIを知ることは、あなたのプロダクトが外部とどのように相互作用できるかを理解するために重要です。

最速の学習方法 – まず、パブリックAPIについて理解することに集中すべきです。これらは通常簡単に見つけることができ、多くの場合、あなたのウェブサイトの開発者向けドキュメントに掲載されています。それらを見たとき、コードを見ることになるので、あなたのバックグラウンドによっては、それが怖かったり、そうでなかったりするかもしれませんが、ドキュメントが中途半端であれば、それは関係なく、問題なく読むことができるはずです。APIを研究することの良さは、APIが基本的なデータモデルのほとんどを表していることが多いので、一石二鳥であることです。

どうすればより良いPMになれるのか？– データモデルを知ることは、より良いプロダクトを作るためにどのような情報を利用できるか、そしてその情報にアクセスすることがどれだけ難しいかを知る能力を拡大します。APIを知ることは、パートナーやサードパーティの開発者があなたのアプリケーションから取得できる情報の種類を理解し、どのような種類の統合が可能かを理解することを意味します。ソフトウェアの拡張性は、最も価値のある特性の1つであり、他のプロダクト（あなたの顧客が毎日使っている可能性のあるプロダクト）とうまく連携できることは、すぐにテーブルステークスとなりつつあるのです。

4. 注力すべきではない分野

プログラミング。誤解しないでください、私はプログラミングが好きですし、より良くするのに役立ちますが、高度に技術的なプロダクトでない限り、効果的なPMになるためにプログラミングは必要ありません。もしあなたがPMとしてコーディングをしていることに気づいたら、実際にレバレッジの高い仕事をしているのか、他に何をすべきなのか、自問自答する必要があるかもしれません。とはいえ、少なくとも1つのアプリを作り、本番環境に出荷した経験は、非常に価値があり、楽しいものだと思います。

ビジネス

1.プロジェクトマネジメント

退屈ですよね。私も嫌いですが、本当に大切なことです。プロジェクトをうまく運営できなければ、良いPMになることはできない。その通りです。

最速の学習方法 – これは難しい。効果的なプロジェクトマネージャーになるには、多くの経験と時間が必要です。本を読めばいくらでもわかるが、結局は人間の行動の問題なのです。一緒に仕事をすることになる様々な性格について学ぶには時間がかかりますし、どのようにアプローチするかについてのアドバイスも、その人の性格に左右されることが多いのです。

とはいえ、学習曲線を加速させるために投資できるソフトウェア特有のものがいくつかあります。

プロダクト開発の基本を理解し、チームと共感できるようにする。バージョン管理（Git）、共同プログラミング（GitHub）、品質保証プロセス、そして、いつどのようにコードがユーザーにデプロイされるのかについて、高いレベルで学ぶことができます。
ソフトウェアチームを悩ませる一般的な問題と、それを解決するために他の人々が開発したプロセスについて学ぶ。アジャイル、スクラム、カンバンといったものを目にすることがあるでしょう。自分の会社が使っているかどうかに関わらず、それらのアプローチの背後にある哲学を学ぶことには価値があります。
会社での意思決定を理解し、ステークホルダーをマッピングする。ステークホルダーとは、顧客、上司、チームメンバーの上司、他のPMのことです。プロジェクトがどのような状況、方向性で進んでいるのかを、ステークホルダーが気にするレベルで全員が把握できるような方法を見つける（これも自分で見つける必要があります）。

どうすればより良いPMになれるのか？– チームとより多くのことを成し遂げられるようになり、人々はあなたと一緒に働くことを楽しむようになる。なぜなら、誰もが管理の悪いプロジェクトを嫌うからです。

2. インパクトのモデル化

測定されないものがうまくいくことはほとんどありません。すべてのプロダクトは、ユーザーの成長、機能の採用、収益など、最終的な成功に結びつく定量的な目標を持っている必要があります。

あなたのチームが次に作ることができる最も高いレバレッジのものを議論しているとき、そのプロダクトがこれらの測定基準でどのようにダイヤルを動かすかのモデルを開発できることが重要です。

最速の学習方法-スプレッドシートを使うときが来たのです。良いモデルは、2つのことを明確に示しています。

プロダクトのユニットエコノミクスと、それを生み出す仮定

新規顧客の獲得にいくらかかるか？
プロダクトの提供にはどれくらいの費用がかかるか？
コンバージョンは目標の針路をどれだけ変えるのか？

予測される影響とそれを生み出す前提条件

このプロダクトは今後1年間でどれだけの効果をもたらすか？次の3年間は？
このプロダクトを強化し、サポートするために何人の従業員が必要か？
コスト削減、インフレ、競争などの市場原理を長期的にどのように考慮するのか？

どうすればより良いPMになれるのか？– プロダクトのモデルを構築することは、直感的な仮定をテストし、プロダクトが十分な可能性を持ち、それを実行する価値があることを確認するための素晴らしい方法です。また、ステークホルダーが納得する形でプロジェクトを正当化したり、他のプロジェクトとの機会損失を簡単に比較できるようになるため、仕事もやりやすくなります。

3. データ収集と分析

迅速な意思決定を行うためには、独自にデータを収集することが不可欠です。なぜなら、分析に携わったことのある人なら誰でも、インサイトはデータの反復的な探索によって得られるものであり、自分で考えた完璧なレポートではないことを知っているからです。

また、重要な時にデータに基づいた意思決定を行う能力も低下させます。ほぼ毎日、あるシナリオでプロダクトがどのように振る舞うべきかという決定が飛び込んできますが、決定をサポートするデータがあれば、あなたとあなたのチームは正しい方向に向かっていると自信を持つことが簡単にできます。

最速の学習方法 – 目標はデータの独立性。SQLクエリーを書く必要があるか、ドラッグ＆ドロップのインターフェースを使うかは、会社のデータインフラに依存します。それが何であれ、利用可能なツールを学ぶために投資する必要があります。ググってみてください。

どうすればより良いPMになれるのか？– データに簡単にアクセスでき、それを快適に利用できれば、より多くのデータを利用でき、より反復的な作業ができるようになります。次に何を作るかを検討しているときでも、発売したプロダクトがどうなっているかを見ているときでも、データを重要なインプットとして意思決定に利用する反射神経が身につき、その結果、より良いプロダクトが生まれるのです。

4. 注力すべきでない分野

経営学部の出身者から言わせてもらうと、戦略的なビジネスケースや3年計画など、MBAの成果物を作って時間を浪費しないでほしいのです。私はそれをデタラメとまでは言いませんが、ソフトウェアで成功するための方法ではありません。ビジョンを理解し、それを達成するために解決すべき問題を見つけ、それを解決するための仮説を立て、実際の顧客とできるだけ早くそれを検証する。同じことを繰り返す。

ユーザーエクスペリエンス

1. プロダクトのデザインパターンを知る

ほとんどのプロダクトは、計画的かどうかにかかわらず、時間の経過とともにデザインパターンを発達させます。パターンとは、プロダクトの中で同じビジュアルやインタラクティブなコンポーネントを一貫して使用することです。ボタンのテキストはすべてフォントサイズ25px、フォームのフィールドは3つ以内、エラーが発生するたびに爆発音を鳴らし、ユーザーに詳細をメールで通知する、これらはすべてパターンです。

プロダクトのパターンを知ることは、ユーザーがプロダクトをどのように頭の中でマッピングしているかを理解し、時間をかけて効果的に新機能を与えるには非常に重要です。いつもは「新しい機能を追加する」という緑色のボタンをユーザーに与えているのに、今回は「あなたの心を揺さぶる」というオレンジ色のボタンに切り替えたら、ユーザーは混乱するでしょう。

プロダクトが成長するにつれ、パターンの一貫した使用はさらに重要になります。なぜなら、パターンを使用することで、チームは互いに独立して作業しながらも、まとまりを感じるプロダクトを構築できるからです。

デザインパターンはまた、スタイルガイドやコンポーネントなどのテクニカルパターンと調和して開発されるのが一般的です。

最速の学習方法 – デザイナーは、これらのパターンを熟知しているはずですし、スタイルガイドへのリンクも教えてくれるはずです。また、フロントエンドエンジニアに相談すれば、パターンライブラリへのリンクを教えてくれるでしょう。

どうすればより良いPMになれるのか？– 簡単に言うと、パターンに基づいてプロダクトを設計することは、はるかに簡単で迅速です。パターンによって、あなたのチームが過去に行った設計上の決定、つまり、顧客にとって使いやすいプロダクトを実現するための決定の上に立つことができるのです。もし、既存のパターンを壊す必要があるのなら（もちろんそうする正当な理由もありますが）、プロダクトの長期的な健全性のためにそれが必要であるという正当な理由を用意しておいてください。

2. ユーザー・エクスペリエンス・リサーチの実行方法を知る

PMは顧客の声であることが前提です。ユーザーを理解しなければ、優れたプロダクトを作ることはできません。一人の人間に直接インタビューすることから、何百万ものユーザーの行動を定量的に分析することまで、優れたリサーチの基本を理解することは、あなたの仕事にとって不可欠なことなのです。

最速の学習方法 – 効果的なリサーチは非常に大きな分野なので、ウサギの穴に行かせるのではなく、次のことを理解することに集中することをお勧めします。

サンプルサイズと統計的有意差の計算方法を理解する。
サンプルを正規化する方法と、それがなぜ重要なのかを理解する。
調査やインタビューにおいて、偏りのない、誘導的でない質問をする方法を理解する。
結果を統合し、誤った結論を出さないようにする方法を理解する。

どうすればより良いPMになれるのか？– 一貫して頻繁にプロダクトを顧客にテストすることで、プロダクト開発における当て推量（およびリスク）の多くを取り除くことができます。プロジェクトが始まる前から、解決しようと考えている問題が本当にあるのかどうかを検証するために、テストを行うべきです。デザインと開発の段階では、プロダクトのデザインが使いやすく、顧客の問題を解決する可能性が高いかどうかをテストする必要があります。リリース後は、解決したかった顧客の問題が解決されたかどうかを検証する必要があります。

3. アイデアをプロトタイプ化する方法を知っておく

プロトタイピングとは、アイデアを効果的に表現するためのビジュアルモックアップを作成できることを意味します。プロトタイプは、以下のことを実現するのに十分なものでなければなりません。

プロダクトコンセプトを明確に伝える

プロダクトの体験を口頭や文章で伝えることは非常に困難です。プロトタイプは、人々が見ることができ、できれば対話できるもの（コードなしで可能）であれば、10倍以上の効果があります。

これには2つの理由があります。第一に、顧客が実際に操作するものという観点からプロダクトを明確にしなければならないこと、第二に、人間は本来視覚的に考えるものなので、プロトタイプは、チームの全員が同じ言葉で話し、それぞれの視点を効果的に伝えることができるように、競争の場を平準化するためです。

デザインの遅れや欠落がある場合、チームのブロックを解除する

多くのプロジェクトでは、プロダクトのデザインが開発に先行していることが重要です。デザイナーが「開発の先を行く」ことを心がけるのは、開発者が特定の方向性でプロダクトを作り始めると、その切り替えコストが格段に高くなるためです。

プロダクトデザインの多くは反復的で、開発と並行して行われるため、挫折（例えば、ユーザー調査によってデザインが効果的でないと判断された場合など）があると、デザインはすぐに遅れをとることになります。そんなときこそ、PMは腕まくりをしてリードデザイナーの「デザインインターン」となり、エンジニアが開発を続けられるよう、ピクセルのプッシュやモックアップの出荷をサポートしなければならないのです。

最速の学習方法 – これを正当化するために時間を費やすことはしませんが、Sketchを使い始めるといいでしょう。

どうすればより良いPMになれるのか？– プロトタイプを作成し、自分の考えていることを人に見せることで、相手が理解していると思い込むのではなく、自分のアイデアに対してチームからより良いフィードバックが得られるようになり、誤ったコミュニケーションによって無駄な労力を費やすリスクを減らすことができるのです。また、たまには実際に目に見えるものを作ってみるのもいいものです。

4. 注力すべきでない分野

優れたビジュアルデザイナーであることにこだわらないことです。洗練されたインターフェイスを作る能力は、プロダクトデザインという深い技術を学ぶためにキャリアを積んできた人にとっては、冗長で無力なものです。あなたがデザインに精通しているのであれば別ですが（もちろん、そういう人もいます）、おそらくあなたは自分が優れていると思っているだけで、実際は最低なのです。