全エンジニアに営業コールを義務づけたら、2週間でプラットフォームが完全に書き直された

• あるスタートアップでは、エンジニアが自ら営業コールに参加するようにしたことで、製品開発の進め方が根本から変わった
• 営業コールの中で、彼らは競合製品が非技術系ユーザーには複雑すぎること、そして顧客はログや指標よりも、監視が動作していることを示す**確認マーク（緑のチェック）を求めており、さらには「誰かが代わりにやってくれないのか」**という要望まで持っていることを知った
• これにより、バックエンド中心のチームはユーザー視点を理解するようになり、PMの介入がなくても新しいアーキテクチャを自ら構想し始めた
• わずか2週間でプラットフォームの機能を60%削減し、進捗を示すプログレスバーの追加、Slack連携、代行ワークフロー機能を構築し、結果としてサポートチケットが70%減少した
• この経験から得た教訓は、ユーザーは問題解決だけを望んでおり、エレガントなコードには関心がないこと、そして機能はコード量ではなくユーザーの混乱というコストを生むという点だった

---

背景と実験

• DevOpsのシニアエンジニアは営業コールへの参加に反対していたが、最低5件だけ試すという条件で同意した
• 創業者は、エンジニアが顧客の言葉と課題を直接聞いてこそ、製品設計が変わると判断していた

営業コールで得たインサイト

• 競合製品は非技術系ユーザーには複雑すぎると語られていた
• 顧客は複雑な指標よりも、単純な緑のチェックマークのような直感的な確認を求めていた
• 多くの顧客が**「代行サービス」**を求め、単に使うことよりも問題解決そのものを外注したがっていた

製品書き直しの結果

• チームは既存機能の60%を削除し、必須機能に集中した
• シンプルなプログレスバーを追加し、利用体験を改善した
• Slack統合によって問い合わせの流れを簡素化した
• Done-for-youワークフローを提供し、顧客の要求を直接反映した
• 最終的にサポートチケットが70%減少し、製品の使いやすさと満足度が大きく向上した

核心的な教訓

• ユーザーはエレガントな技術的解決策ではなく、問題解決そのものを求めている
• 技術的な正確さよりもユーザー理解のほうが重要である
• あらゆる機能には、コードではなくユーザーの混乱というコストが伴う

チーム文化の変化

• その後、会社ではすべてのエンジニアが四半期ごとに5回の営業コールに参加することを義務化した
• エンジニアが顧客の疲弊を直接聞き、「とにかくちゃんと動いてくれればいい」という要望に触れながら、製品に対する直感を養うことが文化として定着した

---

Redditコメントの主な要約

• PMの役割をめぐる議論
  • 一部では、優れたProduct Managerの不在こそが問題であり、エンジニアが顧客との通話まで担うのは非効率だと指摘された
  • その一方で、「PMは結局翻訳者の役割にとどまり、エンジニアが顧客課題を直接オーナーシップするときに最良の結果が出る」という反論もあった
• 顧客接点の価値
  • 多くのコメントで、エンジニアが直接ユーザーの声を聞く経験が強力なインサイトを与えると強調された
  • 初期段階のスタートアップや小規模チームでは、エンジニアがそのままPMの役割の一部を担うことも珍しくないという意見もあった
• 批判的な見方
  • 「これは単にリーダーシップ／文化の失敗をエンジニアに押しつけただけだ」という批判
  • 「機能を削って単純化することが本当に改善なのか」という反論もあり、長期的にはパワーユーザーや高度な機能要件を軽視するリスクがあると警告された
• 前向きな事例共有
  • 銀行、医療機器など複数の業界で、同様に全社員が顧客サポート・営業を体験する制度があったという体験談が多く寄せられた
  • Dogfoodingや自ら顧客の前に立つ経験が、製品品質と文化に役立つという共感もあった
• 総合的な示唆
  • 顧客の問題を直接実感させることは強力な学習ツールだが、
  • 同時に長期的には、専門的なPM・UX・デザイン能力と組み合わせてこそ、バランスの取れた製品戦略を作れるという点が議論の核心として浮かび上がった

[meteorizer]

結局のところ、効率性の問題なのでしょう。
顧客と直接やり取りすることには本当に多くの利点がありますが、
会議や電話など頻繁なコミュニケーションによって業務の連続性がしばしば途切れ、開発に投資できる時間が減ってしまいます。
そうなると会社は、低下した生産性に対応する採用計画を立てなければならないはずです。
たいていは、そのつもりがないのが問題ですよね。
結局、時間不足のせいで、時間がたつほど品質低下を招く可能性が高まるでしょう。
一長一短をよく考慮すべきだと思います。

[laeyoung]

なぜ Hacker News に old reddit のリンクのまま残していたのかはよくわかりませんが、現在の reddit UI へのリンクはこちらです。

[xguru]

Hacker Newsでは、RedditのURLを投稿するときはたいていold redditで投稿しているようです。軽いこともあって、そうしているのだと思います。

[cnaa97]

ボトムを引き上げることが目標の組織であれば、Webフロントエンド開発者だけで構成されたチームや、アプリ開発者チームのような職能別組織が適している、という点は認める。

しかし、ピークを目指すチームや組織では、職能別組織で構成することには必ず限界がある。
本文の内容のように、あえて企画担当、デザイナー、PM、エンジニアがそれぞれの仕事を受け持ち、工場のコンベヤーベルトのように働く必要があるのか、という疑問が生じる。そうではなく、いくつかの担当業務だけを受け持って働く典型的な「担当者」型の仕事ではなく、各分野に専門性を持つメンバーが集まり、共通の目標をともに設定し、全員で支え合う形が理想的だ。

多くの会社では、分社化やチーム編成などのタスクフォース形式で組織を作っていくが、これも結局は人（役割）を束ねただけなので、負の強化（自分が何かをしようとしても、会社が助けてくれないし、もう諦めるしかない、といったパターン）が起こり、キーメンバーのような重要人材だけを失うことにもなりかねない。したがって、目的別組織にも職能別組織による積極的なサポートが必ず必要だ。

[GN⁺]

Hacker Newsの意見

• 最後には、彼らは私の「PM業」抜きで、まったく新しいアーキテクチャを構想した。なぜなら、私たちの製品を実際に使っているのが誰なのかを、ついにきちんと理解したからだ。この経験全体を振り返ると、「エンジニアにセールスコールを担当させてみたら、結局のところ問題はPMが顧客とエンジニアリングの間のコミュニケーションをきちんとできていなかったことであり、DevOpsエンジニアのほうがむしろ顧客ニーズを実際に動くソリューションへ素早く変換する人だった」という結論になる
  • エンジニアが自信過剰で、ユーザーが製品を間違って使っているのだと思い込むことがある。つまり、「ユーザーがバカな振る舞いをしている」のであって、自分が作った複雑な設計に問題があるわけではない、という理屈だ。Desktop Linux界隈の人たちだけでも、ユーザーの不満を無視した経験だけで一冊書けるほどだ。頑固なエンジニアがPMやユーザーより自分のほうが上だと思っていると、何も前に進まない。だが、そんなエンジニアをユーザーに直接対応させると、普段は愛想のいいPMの代わりに、実際に苛立っているユーザーたちが「この素晴らしい創造物」を、まるで問題だらけのハムスターででもあるかのように酷評する。この過程は恐ろしくもあるが、エンジニアの自尊心を打ち砕くものでもある。私の見方では、これはPMが愚かだと示すためではなく、エンジニアを謙虚にするためのものだ。時間が経つとまたエンジニアのうぬぼれが戻ってくるので、この過程は繰り返し必要になる
  • 私は大企業の機械工学チームで、唯一コードを書ける人間だ。社内ITチームがさまざまなソフトウェアを自作しているが、その大半はチームメンバーの目にはいまひとつだ。だから、これを作り直したり、どうしても置き換えられない「いまいち」なプログラムを補うツールを自分で考えて、仕事を楽にしている。自分が社内ITチームより開発がうまいというより、実際のユーザーの視点があるので、自分自身、つまり私たちのチームに本当に必要なものが何かを、よりよく把握できるのだと思う。そして、このソフトウェアを実際に使うのは私自身なのだから、当然モチベーションも高い。だからこの記事のタイトルには共感した。ただし、本編で言っているようなことも現場では十分起こりうるとは思う。私は公式なソフトウェア開発／プロジェクト管理プロセスには詳しくない
  • 私は年商200万ドルの小さなテックスタートアップを経営している。サポート人員が足りないときは、自分で数日間カスタマーサポートを担当することもあった。そうするたびに不思議なことに、普段はエンジニアリングチームにまったく伝わっていない顧客の不満を大量に見つける。サポート担当者は問題をその場で「解決」することに集中しがちで、根本的な改善がエンジニアリングまで届かない傾向がある
  • そもそもソフトウェアがなぜあれほどひどかったのか、誰も気にしていないのが目につく。私の考えでは、PM一人に責任をすべて押しつけることはできない。実際には、Agile/Scrumのように責任が曖昧になり、開発者が雑に作られたチケットを短すぎるサイクルでさばかされることで、こうした雑なソフトウェアが生まれるシステム上の問題だ。「現代的な」ソフトウェア組織が肥大化すると、よくこういう結果になる
  • この記事を見て最初に思ったのは、「PMがあれこれ介入する前は、ソフトウェアってもともとこうやって作られていたよな」ということだ。エンジニアを実際の運用担当者の隣に座らせておけば、実はPMなど不要で、みんなずっと幸せになることがよくある。もちろんPMの中にも素晴らしい人はいるが、私の経験ではPMは縄張り争いに執着しがちで、驚くほどエンジニアリングにも顧客側にも詳しくないことが多い
• 多くの場所で、エンジニアが製品とずれていた経験を何度もしてきた。同僚に知らせず何かを追加してしまってUIがわかりにくくなったり、Webサイトの内容が実際の製品と一致していなかったりすることもあった。また、[製品 -> PM -> バグトラッキングシステム -> エンジニア -> 修正 -> QA -> 製品] のような長いループのせいで、重要なことは直る一方で、小さな不便は本当に長い間直らない。[製品 <-> エンジニア] だけにすれば、驚くほど生産性を上げられる。多くのエンジニアは実際に製品全体の体験を直接したことがあまりなく、今年と去年の違いさえよくわかっていないことがある
  • 私も似たような経験があるが、不思議なことにPMが多い場所ほどこういう現象がよく起きていた。私が経験した最悪のケースは、ある会社でPMと「Product Designer」をエンジニア数に合わせた固定比率で割り当てようとしたことだ。デザイナー、プロダクト、プロジェクト、プログラム担当者を全部合わせると、エンジニアの数より多かった。結果として、状況はさらに悪化しただけだった。PMの官僚主義や、自分たちの役割を侵されたくないという姿勢を避けて回るのも一苦労だった。優れたPMは本当に貴重だが、最近のProduct Managementという肩書きには、官僚的でプロセスに執着する人があまりにも多く集まっている気がする。Product Managementインフルエンサーも問題を悪化させている
  • とはいえ、エンジニアを無理やりセールスコールに投入することが正解だとも思わない。電話一本をうまく進めるにはさまざまなソフトスキルが必要で、エンジニアはそうした分野の訓練を受けていないし、採用時にも考慮されていない。（ここでいう「セールスコール」とは、デモやPoC前の初期相談コールのこと。複雑なプリセールスデモにエンジニアが同席することはあっても、その役割は原則としてプロダクト担当が担うべきだと思う）
  • うまくいかなくなるパターンは本当にたくさんあり、私はそうした例を一通り見てきた。たとえば、すべての顧客コミュニケーションをPMやPOが独占してしまう場合や、顧客が開発者と話すこと自体を避け、ユーザーマネージャーの要求だけを解釈して伝える場合、開発者本人がコードだけ書いていたがる場合、すべてのやり取りをPMとバグトラッカー経由に限定させる場合など、本当にさまざまだ。また、市販ソフトウェアプラットフォームを使っていると、技術的制約のせいでワークフローが非常にひどくなることもある。いつもどこかにコミュニケーションを妨げる要因があり、顧客でも中間管理職でも開発者でも、それを塞いでしまうことがある。さらには、最初から間違ったソリューションを決め打ちして、開発者もユーザーも詳細をまったく知らないまま始めるケースも少なくない。ユーザーにとって本当に良いシステムを作れない道はいくらでもある
  • エンジニアが製品そのものを深く理解することは本当に重要だと思う。基本的なエンジニアリングより、製品面がうまく噛み合うことのほうが難しい地点なのだ。私が経験した製品のほとんどは、結局はプロダクト上の理由で失敗したので、チームの強みをこちらに合わせるほうが論理的だと思う
• 逆に、エンジニアが最終的にテクニカルサポートチームの役割に落ちてしまうこともある。各顧客企業を直接支援していると、ホットフィックスや個別カスタムソリューションばかりが積み上がり、それらをきちんとテストもできないので技術的負債だけが増える。そこへ、規模が大きく、しっかり資金調達した競合がもっと洗練された製品を作れば、あっという間に淘汰される。これは典型的なプロダクトマネジメントの失敗だと思う。PMが顧客ニーズをエンジニアにきちんと伝えられないか、その逆方向のプッシュもできないということだ。エンジニアをセールスコールに投入するのは、顧客層がある程度大きくなり成熟してくるとスケールしないやり方だ。もしプロダクトマネージャーが本当にエンジニアにセールスコールをやらせたいなら、そのエンジニアにも各アカウントのコミッションの一部を渡すべきだ。コミッションなしでセールスコールをやることは絶対にない
• スタートアップのように、チーム全員が顧客ニーズに深く共感する必要がある環境では、非常に優れた戦略だ。私が実際に製品要件の定義に参加し、現場を深く理解していたときのほうが、プロジェクトの成功率ははるかに高かった。要件だけを「受け取って」そのまま実装していたときより、ずっと良い成果物になった
  • それは、自分で実際にガイドラインを書いたから従いやすかったという意味なのか、それとも直接参加したことでより良いUXになったという意味なのか、気になる
• 「2週間でリライト完了、機能を60%削減、単純な進捗バーを追加、Slack連携を構築し、done-for-you ワークフローを提供 → サポートチケット70%減」これが本当なら、何かが深刻に間違っていたということだ
  • Redditは創作話の氾濫で有名だし、この話も実話に着想を得たものであれ完全な創作であれ、典型的なReddit風の文体要素にLinkedIn風のビジネスストーリーテリングがたっぷり混ざっている
  • これは、何度もピボットを繰り返したB2B SaaSで、プロダクト関連のガイドが乏しかったケースなのだと思う。もちろん、こういう形で物事がこじれるのは思っている以上によくある
  • LinkedInスタイルの短文のあとに劇的な結末が続く語り口を見ると、これは創作だとすぐわかる
  • Redditなのだから、当然創作だ。こんな投稿がどうしてこういう話題になるのか理解できない
• こんな結果なら、PM、PO、マーケティングチームを今すぐ全員解雇すべきだ。明らかなことが二つある。第一に、その人たちは顧客が実際に何を望んでいるのか把握できていなかったか、そのニーズを開発チームにきちんと伝えられなかったか、あるいはその両方だ。第二に、頭の中があまりにもシステム寄りに固まりすぎていて、むしろ顧客と開発チームの間にあるすべての中間段階をなくしてしまったほうがいいかもしれない
• 昔の職場でも、エンジニアが営業コールに継続的に参加していた。どんな顧客が何を求めているか、私たちの製品がどう売られているかを体験するのは興味深かったが、画期的ではなかった。顧客が求めた機能はすでにロードマップに入っていたし、わかりにくい機能も一つあったが、それは最大顧客の特殊な要件のためにそう設計されていた。開発チームはもっと単純にしたかったが、そうすると大口顧客の要件を満たせなかった。結局、使いやすい「ライト」版を別に作り、大口顧客以外は全員それを使えるようにした。だが、こうした変化も営業コールに同席したから起きたのではなく、難しいことは最初から皆わかっていたが、ロードマップに反映されるまでは変えられなかっただけだ
• 「実際のユーザーが誰なのかをついにちゃんと理解するようになった」という部分に深く共感する。「たいていのエンジニアの最大の問題はオーバーエンジニアリングだ」と言われるが、実際には顧客のユースケースをきちんと理解していないためにオーバーエンジニアリングが起きることのほうが多い。こちらのほうが本質的な問題だ。私もエンジニアとして最も頻繁に感じるもどかしさは、ほかのエンジニアが実際に売れている製品が何かを知ろうとしないことだ。その理由が業務上の適性であれ、プライドであれ、多くは組織文化やインセンティブ設計にある
• 昔、CRM向けのロボコールソリューションを作る会社にいたが、オフサイトのイベントで全員が実際にコールドコールをして、台本どおりにやってみようという話になった。これが営業以外の人員にどれほどの不安を与えるか、会社は理解も関心もなかった。その出来事のあと、転職を考え始めた
• 昔、似たような状況を実際に見たことがある。監視チームが「すべてのアラートをフロントラインのエンジニアが直接チケット登録すべきだ」と主張したのだ。だが、アラートは1時間あたり1万件以上あった。重要な問題がすべて「ノイズ」の中に埋もれてしまい、管理職も疲弊しきって、あるとき「監視チーム、お前たちが一度全部自分でチケットを切って解決してみろ」と半ば強制することになった。翌日には、重要度の低いアラームを除外したことでユニークアラートは1時間あたり十数件に減り、残りも順次すべてクローズされた。このとき初めて「ボードが全部グリーン」という状態が本物になった（それまではメディアやGartner Groupに見せるため、無理やり緑に塗っていただけだった）