第2回でプロダクトマネージャー（PDM）の概略と重要性を述べた。では、PDMを志すにはどうやってスキルアップすればよいのだろうか。今回はPDMになる方法と、出身キャリア別でみる必要な知識（一部スキルも含む）について考えたい。
【目次】
PDMになる方法
PDMとしてビジネス領域で最低限理解しておくべきラインとは
PDMとしてテクノロジー領域で最低限理解しておくべきラインとは
PDMとしてデザイン領域で最低限理解しておくべきラインとは
まとめ
PDMになる方法
PDMの役割は、ビジネス、テクノロジー、デザイン（以下、BTD）の中心部分を担うことである。そのため、この3領域を幅広く知っておく必要がある。ただ、最初からこの幅広い3領域を知っている人間などいない。誰もがこの領域のどこか1つから始め、PDMとなっている。
PDMになる方法は、以下の3パターンに分けられる。
（1）ビジネスサイド（マーケター、セールスなど）からPDMへ
（2）テクノロジーサイド（エンジニア）からPDMへ
（3）デザインサイド（デザイナー）からPDMへ
そこで、論点となるのは、どこまで自分の専門分野と異なる領域を広げられるか、その最低限のラインはどこか、という点である。そこで、現役PDMからアンケートをとり、その回答内容をまとめた。
アンケートへの回答者（PDM）は32人で、スタートアップ企業の方が約60%、中堅また大企業の方が40%だ。キャリアに関しては、「テクノロジーサイド（エンジニア）からPDMへ」（22人）が約７割で多く、かつエンジニアからプロジェクトマネージャー（PJM）になり、PDMになったヒトが多い。
PDMとしてビジネス領域で最低限理解しておくべきラインとは
まずはBTDのB（ビジネス）の領域において、PDMとして最低限理解しておくべきことは何か、見ていきたい。
（1）ビジネスモデル（30％）
ビジネスモデルの理解については、ビジネスモデルキャンパス（ビジネスモデルを9つの要素に分類）で自社のことが理解できるレベルまでは最低限必要、との回答が多い。
（2）財務構造の理解（18%）
財務構造の理解は、PLを理解していることの言及が多かった。売上は、どういう構成から成り立ち、何にコストがどれくらいかかり、利益がどれだけ残るのか。開発に関わるコスト感（エンジニア1人動けばいくらかかっているのか、サーバー料金など）を持っていることが最低限必要となる。
（3）ユーザー理解（13%）
すべてのプロダクト開発はユーザー理解からはじまる。第2回でも述べたが、PDMはプロダクトのwhyとWhatに責任をもつ。そのため、ユーザー理解のレベルは高く求められる。ターゲットとしているユーザー層はどこで、何に困っているのか。その課題を解決するために、自社のプロダクトにはどういう機能が必要で、それに対してユーザーはお金をどれくらい払ってくれるのか、までの考慮と理解が最低限必要となる。
（4）KPI（13％）
PDMは、KPIを分解し、数値状況から施策に落とし込める能力が最低限必要だ。プロダクトのステージによっては、KPIが変わるため、自ら適切なKPIを設定できる能力も必要となる。
（5）社内の業務理解（8%）
顧客へサービスを届けるまでのバリューチェーンを、社内でどこの部署がどのような業務として行っているのかを理解しなければならない。「サービスブループリント」といったマッピングツールを活用するなどして、最低限どのような役割・活動があるのか、表の顧客対応だけでなく、裏の仕組みも知っておく必要がある。
（6）業界理解（8％）
枠組みとしてPEST（政治、経済、社会、技術）分析や、5F（新規参入、売り手、業界内、買い手、代替品などの脅威）分析、3C（自社、顧客、競合）分析などのフレームワークを活用し、業界の現状を理解しておくことは最低限必要となる。
（7）仮説検証（6%）
自ら仮説検証できること。特にリソースがない場合は、自ら仮説検証を行う力が必要である。プロダクトの状況を定量定性的分析し、仮説を出し、実行して検証する。実行をメンバーに任せたとしても、自ら仮説を立てて、検証する力は最低限必要となる。
（8）説明力・翻訳力（4%）
チームメンバーや多部署、ステークホルダーとコミュニケーションをとる際、相手に納得してもらうことや、モチベートするために、説明する力が必要となる。多様なステークホルダーがいるため、それぞれにわかる言葉で説明する翻訳力も必須である。
■キャリアの違いで回答に差があるのか
ここでは、ビジネスサイド出身とテクノロジーサイド出身で、見解の違いがあるのかを見ていこう。
「ビジネスサイドからPDM」の方では、「社内全体の業務理解」を必要と認識している人が多い。ビジネスモデル、財務構造を理解したうえで、全体の業務理解の把握を重視していることが伺える。「テクノロジーサイドからPDM」の方は、メンバーへの「説明力・翻訳力」を示す必要があると考えている。「説明力・翻訳力」を日頃から使う機会が少ないため、そういった勉強をする必要があると、より感じていると考えられる。
PDMとしてテクノロジー領域で最低限理解しておくべきラインとは
続いて、まずはBTDのT（テクノロジー）の領域において、PDMとして最低限理解しておくべきことは何か、見ていきたい。
（1）採用技術の理解（31%）
まずは、自社で採用している大まかなシステムの構造とその動きを理解することが最低限必要となる。大なり小なり、その採用技術を使うことによって、ユーザーは何ができるようになり、何ができないのかがわかる必要がある。
また、他のアーキテクチャーと比較して、メリットとデメリットという観点で、自分でも大まかな内容が理解できている。あるいはエンジニアと会話して整理ができ、意思決定ができるレベルにすることも必要だろう。
（2）技術トレンドの理解（15%）
自社プロダクトの可能性を上げるために、技術トレンドの理解も必要となる。技術トレンドを継続的に注視しておくことで、技術が自社に与える影響を予測し、顧客への提供価値を高めることができるほか、他社のイノベーションによる自社への不意打ちを減らすことができる。
（3）開発プロセス理解、PJ管理（14%）
開発にあたりどのようなプロセスが必要か、そのプロセスにはどのようなリソース（人、モノ、金、情報・ノウハウ）が必要かわかることは必要だ。
加えて、問題が起きた際に、それが技術の問題か、非技術の問題かの切り分けができ、次のアクションを考えられなければならない。
（4）専門用語の理解（10％）
エンジニアと会話するにあたり、１文のなかに２つも３つも単語の意味がわからないものが存在すれば、会話が成り立たないだろう。まずは用語と意味を理解する必要がある。エンジニアも１つひとつは説明できない。「採用技術への理解」「技術トレンドへの理解」に現れる専門用語は理解する必要があろう。
（5）提供サービスの要件定義（10%）
要件定義とは、解決すべき課題を明らかにし、リソースとのバランスを考慮したうえで、目的を達成するために何をすべきかを明文化すること。
定義するためには、ユーザーの課題やステークホルダーを深く理解し、必要な機能をドキュメントへ落とし込むことが必要となる。
（6）職種特性の理解（10%）
技術面というよりはエンジニアの特性（個人に対しても、集団に対しても）の理解・職種特性の理解・業務特定の理解が最低限のライン。しっかりとしたニュアンスを汲み取るようにコミュニケーションをするためには、エンジニアという職種特性の理解が必要である。
（7）プログラミング知識（6%）
基本的なプログラミング・フレームワーク等の知識などビジネスサイドからPDMであったとしても、必須スキルだといわれている。
「プログラミング知識」とは、実際にプログラミングができれば最もよいが、そこまで求めているものではない。プログラミングとはどういう環境で、どういう作業を行い、どういった内容を記述するのか、といった基礎的な理解をもっておく必要がある。
（8）KPI確認・データ分析（4%）
PDMはKPIという数値で意思決定をすることが重要であるため、自分でKPIを計測することや、分析することは必要だろう。また、データベースから抽出した簡単なデータを分析する能力も必要。
■キャリアの違いで回答に差があるのか
「ビジネスサイドからPDM」の方は、「職種特性の理解」と「プログラミング知識」を必要とする回答が多かった。これまでエンジニアやプログラミングとの接点が少なかったビジネスサイドの人にとって、まずは、エンジニアという職種の理解やプログラミング知識を得ることが必要だと考えているのだろう。
「テクノロジーサイドからPDM」の方は、職種特性やプログラミング知識はあるため、むしろ開発プロセスの理解をあげている。
PDMとしてデザイン領域で最低限理解しておくべきラインとは
最後に、BTDのD（デザイン）の領域において、PDMとして最低限理解しておくべきことは何か、見ていきたい。
（1）ユーザビリティに対する理解（24%）
ユーザビリティとは、一般的には「ISO 9241-11」での定義が広く認識されている。それを引用すると、“特定の利用状況において、特定のユーザーによって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、ユーザーの満足度の度合い”だ。
ユーザーが利用する状況をイメージできていて、デザイナーから提出されたデザインや現状のデザインで、ユーザーは迷わず機能が使えるか、導線がおかしくないかといったチェック項目がわかるレベルは必要となる。
（2）UXデザイン（21%）
UXとは、「User Experience（ユーザーエクスペリエンス）」のことで、頭文字の「U」と、eXperienceの「X」から来ている。
User Experienceを日本語に訳すと「ユーザー体験」となり、製品（モノ）やシステム、サービス、スマホのアプリなどを使う人（ユーザー）の利用シーンや体験について指している。
（3）プロトタイプを作る（17%）
プロトタイプとは、試作品のこと。プロトタイプを作るにあたり、 紙レベルからツールレベルまで、何かしらデザイナーに伝えるために自分で表現できる技術は必要となる。
（4）デザインの基礎（17%）
デザインの基礎も必要だ。さまざまなものがあるが、大きくは4つの基本原則があるといわれている。一部抜粋すると以下のようなことである。
1) コントラスト
コントラストの背景にある考え方は、ページ上の要素同士が単に「類似」するのを避けるということ。
2) 反復
色、形、質感、位置関係、線の太さ、書体、サイズ、画像などの視覚的要素を、作品全体として繰り返すこと。
3) 整列
ページ上では、全てを意図的に配置しなければならない。あらゆる要素が、他の要素との視覚的な関連をもつ必要がある。
4) 近接
お互いに関連する項目は、近づけてグループ化しなければならない。
※引用：Robin Williams『ノンデザイナーズ・デザインブック』マイナビ出版、2016年
（5）デザインプロセスの理解（14%）
プロダクトを開発するにあたり、どういうフローでデザインが関わるかを理解する必要がある。
今日の開発では、見た目や動きのデザイン（UI）だけでも、デザイナーとフロントエンドエンジニア（見た目の動きをプログラミングする人）が分かれている場合がある。
その場合、複数人の間でデザインの受け渡しが必要になり、プロセスを理解していないと、大きな手戻りが発生する可能性がある。
（6）デザインレギュレーション（4%）
プロダクトのブランディングにおいて、デザインの一貫性をもたせる必要がある。「トーン＆マナー」（略してトンマナ）といったりするが、ブランドのイメージカラーとウェブサイトのデザインカラーや、フォントを合わせる必要があるなど、トンマナはブランディングにおいても重要となる。
■キャリアの違いで回答に差があるのか
「ビジネスサイドからPDM」の方は、「デザインの基礎」について、デザイナーに任せているため、あまり重要視していないのではないかと考えられる。しかし、デザインプロセスについては、理解することで、より良いプロジェクトのマネジメントを考えられるのではないかと認識していることが伺える。
「テクノロジーサイドのPDM」の方は、フロントエンドエンジニアなど、デザインに関わる部分も発生するため、実装においてデザイナーとのコミュニケーションも多く、意思疎通が必要なため、デザインの基礎を重視しているのではないかと考えられる。
まとめ
以上、アンケート結果をまとめてきたが、PDMになるために実際どこまで理解しておく必要があるのだろうか。この段階で、PDMになるための、私たちなりの処方箋を2つ書いておく。
1．ビジネスサイドからPDMになって成功している人に共通していることは、テクノロジーサイドに詳しい人と密に仕事をしていた。逆にテクノロジーサイドからPDMになった人は、ビジネスサイドに精通している人と密に仕事をしていた。これらを踏まえ、ビジネス、テクノロジー、デザインという領域を、文化や思考方法の違いを乗り越え、積極的に越境し、優れた人と交わるという方法である。
2．PDMとしてはBTD全ての領域の知識や知見が必要となるが、自分1人で網羅するのは非常に難しい。そのため、成功しているPDMは自分の苦手分野を埋めてくれるメンバーと密に仕事をしている。補完してくれる人に仕事を任せ、その領域の最低限必要な知識を、クイックに身に付けるという方法である。つまり、テクノロジーサイドの人は、ビジネスを学び、ビジネスサイドの人はテクノロジーを、一定レベルの意思疎通ができるまで学ぶということである。
アンケートに回答頂いた方々のキャリアの変遷を見ると、キャリアとして、BTDすべて業務経験をしている人はいなかった。そのため、PDMになる前後において自分で猛勉強している。その時、補完してくれるメンバーに助けてもらいながら、徐々に各領域の知識を着実に増やしていたのだ。
とはいえ、どの状況においても必要な力として、なにが必要なのか。BTDどのキャリアを歩んできても、汎用的に必要となる力を次回から紹介していきたい。
（調査協力）松浦 卓哉／石井 紀穂
.jpg?fm=webp&fit=clip&w=720)
