あるある会話
— 葉@外資でSalesforceエンジニア (@hskfwy) September 22, 2025
PM「顧客からこういう要望が来たのですが、技術的にできますか？」
エンジニア「できると思いますが、開発が必要ですね。」
PM「工数見積ってください。」
エンジニア「見積る前にその機能で顧客が本当に何をしたいか確認したいです」
PM「顧客折衝は私の仕事です」
エンジニア「は？」 https://t.co/t2sIx6yqAN
続き
— 葉@外資でSalesforceエンジニア (@hskfwy) September 22, 2025
PM「一応顧客に聞いてみます(まあ見積出す時に言お)。まず工数と費用出してください」
エンジニア「見積りました」
PM「この機能を既存WBSに入れることってできますか？人増やせばいけますか？それとも後で追加した方がいいですか？」
エンジニア「(なんでこっちでばっかり対応せなあかんねん)」
エンジニアはやりたくない開発の見積もりを相当お高い金額で算出します。そして、ユーザーの開発意欲を削ぐ暗黙の顧客折衝を行ないます。
— thewisewolfhoro (@thewisewolfhoro) September 22, 2025
PMはプロジェクトを支配しているつもりでいますが、適正な価格を自ら算出できない時点で、エンジニアに支配されていることに気づいている人は少数です。
実は既存機能をちょいと調整するだけで解決するような問題を、客先に言われるがままの機能を膨大な工数をかけて見積もらせるPM
— クロワッさん (@pogem447) September 22, 2025
という構図が頭をよぎった
工数も見積もれない、客の要件もシステムに落とし込んで理解できないんじゃ何のためにいるのか。って感じですね。
— 晴姫(はるひ)技術方 (@Haruhi40_tech) September 23, 2025
こういう高給取りが多すぎるんですよ。
「技術的にできますか？」って質問で素人感を漂わせる良い例文
— あざぜる (@pigeonist2) September 22, 2025
できる以外の回答は無いんよ
だから顧客とエンジニア間の折衝をしろと言うとるんだ
— Tachibana(misbranding) (@chidori10010) September 23, 2025
PMがそこを断ってどうする
いや、ちゃんと判断できるんならいいけど、できるかどうかの話してきて目的の摺合せ拒否してくるのは先行き不安すぎる
あるあるすぐるw
— keyakitomo (@keyakitomo) September 22, 2025
とにかく決定権だけ持ちたいっていうタイプがPMやるとそうなりがちね
顧客が何をしたいかを即答できない時点で、PMとしては弱いですね。
— Sat (@satonmybeat) September 23, 2025
実装しているエンジニアの方が、システムの作りに詳しくなるのは当然だが、PMなら顧客が相談してきた時点で目的を掴めよと思う。要望の背景を顧客に再確認せずともエンジニアと実現方法を語り合うくらいでありたいですね。
ちょっとコンサルっぽい視点が必要になるんですよね、話聞いてみたらわざわざ時間もお金もかけて開発しなくても簡単に別の案で解決できそうなな悩みだったり。ただ、自社の製品を売り込まなきゃいけない側面もあるから難しいというのはそうだとも思うからPMとリードエンジニアでセットが良いのかも。
— いわし@終わらせる者 (@i04_konk2) September 23, 2025
PMいらんやん
— MaltAndCigar (@MaltAndCigar) September 22, 2025
こういう話の段階では、営業と技術がセットで動いてました。
— jima (@jima0111) September 23, 2025
PMを立てるのは受注後。
タスクに対して遂行能力が無い担当者（自分）を割り当てているということですので、これだけを取っても、この人はプロジェクトマネージャーの仕事ができてないですね。名ばかりというやつですね。
— ぺこり (@peckori) September 23, 2025
顧客はコスパを確認したいんだよね
— めだまのオジキ🦳 (@2wQkVaudO311214) September 23, 2025
なので工数が出ないと話にならぬのよね、
伝言ゲームって上手く伝わらない。
— たな🏳 (@tanapapa1209) September 24, 2025
このPMなら確率は通常の倍以上やぞ
伝書鳩PMばっかりだよねー
— おっくん (@okkun_oosaka) September 23, 2025
「見積る前にその機能で顧客が本当に何をしたいか確認したいです」
— ひで＠京都 日の丸ファースト (@ITOHHideo19999) September 24, 2025
これで理解できないのか・・・
はっきりと
「この機能は明らかに過剰だから本当の目的を確認しろ」
こういわないとだめなのかな
え、この流れなら、積算に関する疑問点がないなら、まずはエンジニアは粛々と機能要件による見積もりをすれば良いのでは？
— kymmt (@kymmt867) September 24, 2025
機能が必要かどうかの判定はエンジニアの仕事ではない。
顧客への最前線の仕事を過小評価してはいけない。言う通りに進めないとそれこそ火を吹く。
この会話、プロダクト開発で何度も目にする。顧客の要望をそのまま機能に落とし込むのではなく、なぜそれを求めるのかという本質的な課題をPMが掘り下げ、エンジニアと共有することが肝心。要件定義の前に目的をすり合わせないとプロダクトは迷子になる。 https://t.co/5jRbGUyQ3v
— 石坂大輝｜医療マーケとプロダクト開発の専門家 (@isshi_crutech) September 23, 2025
横文字の多い役職なのに、どこも厳密に業務範囲が決まってない
— ビジネスインテリジェンス (@startdown_res) September 22, 2025
PM、PMO、PMM、Pdm、PL、PjM
みんな同じようなことをやってる
プロジェクトなのか？プロダクトなのか？知らんが、この手の役職ってベンチャーだとすぐに付く役職なので、能力もピンキリ https://t.co/so90fTtmY3
エンジニアじゃないけどこんなんばっかだった。そもそもプロジェクトとしての区別も役割の区別も責任の区別も何も明確じゃないことが多い。誰が何をやっているのか、区切りが明確だと困る人が意図してそうしている。 https://t.co/Cy7wCZlg2u
— しゅ (@shu_melancholy) September 23, 2025
