つまり、自分で書いた指示に従う方が上手くいくってこと？それとも、自分が関わったからこそ、より良いUXが得られるってこと？

こういう従業員が負の価値を加えるケースは多いよね。

そうかもしれないけど、私は機械工学のグループで、コードを書いたり自動化したりできる唯一のメンバーなんだ。大きな企業で、かなりのITサポートグループがいて、社内でかなりのソフトウェアを作ってるけど、私たちのチームはその多くをひどいと見なしてる。だから、アプリケーションを作り直したり、「ひどいけど代替できない」ソフトウェアを補完するツールを作ったりして、仕事を楽にしてるんだ。私は社内のITの人たちよりソフトウェア開発が得意だとは思ってないけど、実際のエンドユーザーとしての視点があるから、自分たちのニーズにどう応えるかが分かるんだ。自分が使うから、効果的にするモチベーションも高いしね。だから、このタイトルには最初共感したけど、このコメントは予想外だった。でも、正式なソフトウェア開発やプロジェクト管理に詳しくないから、あなたの意見が多くのケースで正しいのは分かるよ。

逆に、このPMはエンジニアに貴重な教訓を与えたね。彼らはおそらく、毎年繰り返す必要があるだろうけど。ユーザートレーニングみたいなもので、セキュリティトレーニングに似てる。

そうそう、元のソフトウェアがなぜこんなにひどい設計だったのかについては全く触れられていないよね。理由を知りたいとも思っていないみたい。あなたの結論の方がもっと正しいと思うけど、PMに責任を押し付けるつもりはないよ。アジャイルやスクラムの儀式では、責任が分散されて、開発者はひどく設計されたチケットを急いで処理させられるから、結果的にひどいソフトウェアが生まれるんだ。誰が予想できた？「現代」の肥大化したソフトウェア組織のシステム的な問題に感じるね。

俺は小さなテックスタートアップを運営していて、年間収益は約200万ドル。時々サポートが人手不足になって、俺もサポートに入ることがあるんだ。そうすると毎回、顧客が不満を持っている問題がたくさん見つかるけど、それがエンジニアリングチームに戻ることはないみたい。たぶんサポートの担当者のせいか、サポートの性質のせいかもしれないけど、彼らは問題をエンジニアに報告するよりも、自分たちで「解決」するのが好きみたい。

それに、エンジニアがちょっと自信過剰で、ユーザーが製品をどう体験すべきかを知っていると思っていることもある。もしユーザーが「製品の持ち方が間違っている」なら、それはユーザーの問題であって、ボタンの押し方を知っている人が作った愚かなデザインの問題じゃない。デスクトップLinux周辺の人たちは、ユーザーの不満を無視することについて本を一冊書けるだろう。頑固なエンジニアがPMやユーザーよりも自分の方が正しいと思っていると、本当に進展が難しい。ただ、そういうエンジニアをユーザーからの攻撃にさらすと、エンジニアにとっては優しいPMが「これは間違っている」と言っているのではなく、フラストレーションを抱えた人たちが彼を生きたまま皮を剥こうとしているように見える！それは恐怖を引き起こすけど、同時に彼の自尊心を粉々にする。誰かがエンジニアの天才作をまるで知恵遅れのハムスターのように非難しているから。俺の視点からすると、PMがバカだと示すことではなく、エンジニアを謙虚にさせることが重要だと思う。彼らの自尊心はまた育つから、このプロセスは繰り返す必要がある。

うん、最初に思ったのは「これがPMが全てに手を出す前のソフトウェアの書き方だな」ってこと。エンジニアを運用作業をしてる人と一緒に座らせると、PMがいなくても全然やっていけるし、みんなもずっと幸せそう。PMは素晴らしい存在になり得るけど、私の経験では、彼らは非常に領域意識が強くて、エンジニアリングや顧客側のことについて驚くほど知らないことが多い。

Hacker Newsのコメントの第一のルールは、エンジニアのせいじゃないってことだね。

そう、OPもスレの中でそれを認めてるよ。 > コメント者: プロダクトマネージャーがいないみたいだね [...] > OP: ハハ、いないよ :) シリーズAを調達するまでプロダクトの人を雇わないことを誇りに思ってるんだ。これのおかげで、すごくスリムに、素早く動けて、顧客が本当に欲しいものを作れた。私たちのプラットフォームは決して簡単ではないけど、初期の頃には製品を3回も作り直したし、3回目の書き直しで今の規模にまで成長したんだ。

こういう失敗の仕方はいろいろあって、見たことがあるのはこんな感じだね。 - ユーザーとのコミュニケーションをプロジェクトマネージャーやプロダクトオーナーを通さないといけなくなること。彼らがいい時もあれば、ひどい時もある。 - 顧客が開発者と話したがらなくて、ユーザーのマネージャーの要求を解釈するしかなくなること。 - 開発者がコードを書くことだけに集中したくて、顧客と会うのを拒否し、すべてのコミュニケーションをプロダクトマネージャーやバグトラッカーを通させること。 - 商業ソフトウェアプラットフォームを使った時に、技術が邪魔をして、適用できる修正やカスタマイズの種類が限られていて、ワークフローがひどくなることもあった。どこかで必ずズレが生じていて、会話がブロックされていることが多い。顧客、中間者、開発者の誰かが原因で、しばしばそのすべてが絡んで、機能不全のシステムになったり、開発者やユーザーが詳細に入る前に解決策が選ばれてしまったりして、間違った選択をすることがある。ユーザーにとってあまり良くないシステムを作る方法はいくらでもあるよね。

あなたの言ってることは間違ってないけど、エンジニアに営業の電話を強制するのも良くないと思う。成功するコールにはたくさんのソフトスキルが必要だけど、エンジニアはそれについてのトレーニングも受けてないし、面接でも見られないからね。（ここで言う「営業の電話」は、デモや概念実証の合意前の初回発見コールを指してる。複雑なプレセールスのデモにはエンジニアに「同乗」してもらうのはいいと思うけど、それでも製品がその役割を果たすべきだよね。）

エンジニアと製品がズレてる場所に無数にいたことがある。私もそうだけど、驚くことに、PMが多いところでそういうことがよく起こる。最悪の経験は、エンジニアに対して特定のPMと「プロダクトデザイナー」の比率を強制しようとした会社だった。デザイナー、プロダクト、プロジェクト、プログラムの人を全部足したら、エンジニアの数よりも多くなってた。それが全てを悪化させただけ。PMの官僚主義を乗り越えながら、自分の意見が脅威と見なされないようにするのは、それ自体が仕事だった。優れたPMは会社にとって貴重な存在だけど、現代のプロダクトマネジメントには官僚主義やプロセスを好む人がたくさん集まってきてる。PMインフルエンサーの増加がさらに悪化させてるよ。

そうだね、エンジニアが製品を理解するのは重要だと思う。基本的なエンジニアリングよりも、正しくやるのが難しいから。私が関わった製品のほとんどは、製品の理由で失敗してるから、論理的に考えても、チームの強みを確保することに集中するのが理にかなってるよ。

これは、非常に弱いガイダンスのもとで複数のピボットを経たB2B SaaS製品のように聞こえるね。あなたに反対するつもりはないけど、こういうことが間違うのは非常に一般的なパターンだよ。

リンクトインっぽい文体で、短い文が続いて「マイクドロップ」みたいな瞬間があるから、これが偽物だってわかるよね。

もちろん偽物だよ、ここはレディットだからね。こんなゴミがフロントページに載るなんて、どういうこと？

レディットはクリエイティブライティングの場になってるね。これは実際の出来事にインスパイアされたのか、純粋なフィクションなのかはわからないけど、どちらにしても典型的なレディットのクリエイティブライティング要素が満載で、リンクトイン風のビジネスストーリーテリングがちょっと加わってる。