テーマ、知りたいこと
「技術のわかるPdM」の「わかる」という言葉が指すものについて、 よく耳にするようになった言葉ですが、具体的にどんな指標があるか、色々な方の意見を聞いてみたいと思い投稿します！
自分なりに「技術がわかる」の正体を考えてみたのですが、
- 自力でプルリクを出して、軽微な修正ができるか
- コードは書かないが、アーキテクチャ設計の妥当性を判断できるレベル
- AI の嘘や生成されたコードの不備を見抜けるレベル
など、人によって定義がかなり分かれる気がしています。
「これができないとエンジニアから信頼されない」な最低ラインや、逆に「ここまで知っていると現場がすごくスムーズに回る」な理想ラインについて、皆さんの現場感覚を教えてほしいです！
背景、状況
前の質問にも記載させていただいたのですが、エンジニア2年目で、最近は「技術をどうプロダクトの価値に変えるか」というPdM的な動きにワクワクを感じています。
webの記事を読んだり、知り合いから話を聞いた感じでは「必須ではないが強みの一つにはなる」というのが結論になるのかなとは思っています。
課題解決のためのプロダクト開発でいうと、マインド的には、PdMは「何を解決するか」寄りで、エンジニアは「どう解決するか」寄りという言葉もぼんやりとではありますがしっくりきました。
AIでは↓のようなものも出てきて、なるほどなぁ...と思いました。
| 項目 | 最低ライン（信頼） | 理想ライン（推進力） |
|---|---|---|
| コード | 読めなくてもいいが、構造は知る | 簡単な修正やSQLが書ける |
| 見積もり | 根拠を質問し、納得できる | リスク箇所を予測し、事前に相談できる |
| 設計 | 決まった設計を受け入れる | 拡張性を考慮した提案ができる |
| トラブル | エンジニアに丸投げする | 原因の切り分けをサポートできる |
回答6件
#1
総合スコア118297
投稿2026/01/16 10:35
経験と自信の対比にはダニングクルーガー効果がよく挙げられ、ざっくりまとめると「馬鹿の山と絶望の谷」で評価されます。
- まず経験のない初心者は「よくわからない」からはじまります
- 学習効果が高い初期段階で知識量が増えることで一気にできることが増え一度絶対的な自信（万能感）を手に入れます。それがバカの山、俗に言う「完璧に理解した（実際には大した知識もない）」です
- その後実務上知識の応用が必要になってくると一気に自分で解決できないことの多さに気づき次第に自信を徐々に喪失し低迷期にはいります。それが絶望の谷、俗に言う「ぜんぜんわからない（実際にはそこそこ知識はあるがゆえの無能感）」状態です。
- それを超えると徐々に課題に対処する方法がわかるようになり、仕事上提案やアドバイスなどができるようにます。その状態を指すのが「少しならわかる」です。
まとめると「わかる」という人に期待してはいけません。「ぜんぜんわからない」という人に聞くとそこそこいいアドバイスがもらえます。仕事を頼むなら「少しならわかる」という人がよいでしょう。
#2
総合スコア86533
投稿2026/01/17 15:59
PdMとして行動したことが無いですが、
「技術のわかるPdM」の「わかる」という言葉が指すものについて、
ということだと「どの程度分かればいいか」はPMとおそらく変わらないと思うのでその線で回答します。
「技術がどこまでわかればいいか」だけにフォーカスしています。
理想的には「メンバーの誰が欠けても、その代わりが技術的な面では務まる（代わりをする時間があるかどうかはさておき）」でしょう。ただ、これはまず無理で、それを目指す必要もないと思います。
「メンバーの誰とでも、技術的な会話ができて意思の疎通に問題がない。技術的問題を抱えているメンバーがいれば、アドバイスして解決できないとしても、問題の重大さや解決困難度合いが理解できて、解決に向けての手が打て、必要があれば上司(or顧客)に自分で自分の言葉で説明ができる。」くらいを考えるのがいいと思います。
「技術的問題を抱えているメンバーがいれば～解決に向けての手が打て」の部分は必ずしも技術的に解決する必要は無いです。PdMのミッションは「発生する技術課題を解決する・部下に解決させる」ことではなくて、「プロダクトをビジネスとして成功させること」なので、解決困難な問題は回避する手もあります。回避したうえでどうやって成功させるかを考える必要がありますが。
#3
#1ありがとうございます！
「ダニングクルーガー効果」勉強になります！すごく納得しました...
自分もよく「理解したつもり」で実際に実装しようと思っても手が動かない、みたいな経験を思い出して、「完璧に理解した（実際には大した知識もない）」→「ぜんぜんわからない（実際にはそこそこ知識はあるがゆえの無能感）」の状態だったんだなと思います。
若干主題とは逸れるかもですが、逆に、この「完璧に理解した」のステップをちゃんと踏むこと、そして「（実際には大した知識もない）」をメタ認知的に自覚して、3,4のステップに向けて動けるかが大事なのでしょうかね...
まとめると「わかる」という人に期待してはいけません。「ぜんぜんわからない」という人に聞くとそこそこいいアドバイスがもらえます。仕事を頼むなら「少しならわかる」という人がよいでしょう。
おっしゃる通りですね！自分も、「わかる」ではなく、その先の「少しならわかる」「ぜんぜんわからない」PdMを目指して経験積んでいきたいなと思いました！
#4
#2 ありがとうございます！
「技術的問題を抱えているメンバーがいれば～解決に向けての手が打て」の部分は必ずしも技術的に解決する必要は無いです。 PdMのミッションは「発生する技術課題を解決する・部下に解決させる」ことではなくて、「プロダクトをビジネスとして成功させること」なので、解決困難な問題は回避する手もあります。
発生した課題について、PdMが必ずしも直接技術的に解決する必要はなく、時には技術外のコミュニケーションも必要なだということですね、とても腑に落ちました！
問題の重大さや解決困難度合いが理解できて、解決に向けての手が打て
技術は深めていくとキリがないなと思って難しいと感じていましたが、「解決困難度合いが理解でき」ることがまずは大事だなと思いました。
その上でどんなコミュニケーションが取れるかというソフトスキルも大事にして、プロダクトの成功のためにさまざまな柔軟な動きができるPdMを目指したいなと思います！
#5
総合スコア86533
投稿2026/01/24 16:18
編集2026/01/24 16:22発生した課題について、PdMが必ずしも直接技術的に解決する必要はなく、時には技術外のコミュニケーションも必要なだということですね
違います。というか、「発生した課題について、PdMが必ずしも直接技術的に解決する必要はなく、時には技術外のコミュニケーションも必要なだ」は私の書いた文章の意味に含まれていますが、それは、「技術的問題を～～～必ずしも技術的に解決する必要は無いです。 ～～～解決困難な問題は回避する手もあります。」の文とは全く関係ありません。
「PdMが必ずしも直接技術的に解決する必要はなく」を言ってるのは、「理想的には～～～。ただ、これはまず無理で、それを目指す必要もないと思います。」の部分です。
コミュニケーションのことを言ってるのは、「メンバーの誰とでも、技術的な会話ができて意思の疎通に問題がない。～～自分で自分の言葉で説明ができる。」の部分です。
冒頭に「違います」と書いちゃいましたが、実際は「違ってないけど、無関係な引用文を書いている」です。
「技術的問題を～～～必ずしも技術的に解決する必要は無いです。 ～～～解決困難な問題は回避する手もあります。」の部分は、回避策・代替案を考えるということです。
例えば、「XXXを実現するために、YYYということをやっているが、YYYの実現がどうも上手くいかない」という場合に、「YYYじゃなくてYYZZという方法でやればできるではないか？」というのも一つの解決法です。手段を工夫することでXXXが実現できるならそれでよし。技術的解決です。
その文で言いたかったのは「XXXを実現することがプロダクトをビジネスとして成功させること」にどの程度必要なのかを再検討して、XXXが技術的に困難そうであれば、XXX以外の方法でプロダクトを成功させる方法を考えるということです。
特定範囲を割り当てられた部下の立場では「XXXを実現するために、YYYということをやっている」の場合、XXXが実現すべき目的なわけですが、PdMの立場では、XXXもプロダクト成功のための手段ですので、その手段を工夫することも責務でしょう。
以下、ちょっと本題から逸れます。
部下から「XXXじゃなくてWWWに方向転換しませんか？」という提案が出くればありがたいですが、これは組織風土次第ですかね。「余計なこと考えずXXXをちゃんとやれ。楽しようとするな」と返す上司がいたりすると、提案が出てこない。
少人数でレベルの高い人だけのチームであれば、全員が「プロダクトの成功が目的だ。そのために自分は何をすればいいか」という視点で動けると思うので、リーダーは楽です。
あなたの回答
tips
プレビュー