なぜシニアエンジニアは悪いプロジェクトを失敗させるのか

91日前原文(lalitm.com)

概要

シニアエンジニアになると、「正しいこと」と「効果的な行動」の違いを痛感
悪いプロジェクトを止めるべきか、影響力の使い方が重要
影響力は有限資産と捉え、戦略的に使うべき
発言のタイミングと方法を見極める判断基準
関与しない選択肢や、長期的視点での対応も必要

シニアエンジニアの影響力と「悪いプロジェクト」への向き合い方

若手時代、上司が他チームの「問題あるプロジェクト」について愚痴るも、直接介入しない姿勢に疑問を持った経験
自身が成長し、同じ状況に直面した際、「なぜ直接言わないのか」と問われ、考え方が変化したことを自覚
「正しいこと」と「効果的な行動」は異なるという認識
大企業では「悪いプロジェクト」への指摘は大事だが、やりすぎは逆効果
シニアになるほど**「聞く耳を持たない相手」に時間を割く無意味さ**を理解
「悪いプロジェクト」の例：UXの複雑化、技術的過剰設計、政治的動機など多岐
プロジェクトの良し悪しは主観的で、結果が明らかになるのは数年後が多い
シニアになると「ソフトウェアの“センス”」が磨かれ、直感的に「これはダメ」と感じる場面が増加

失敗例と学び：Googleでの実体験

Google内で発表された「画期的プロジェクト」が政治的障壁で失敗した事例
- プラットフォームチームがフラッグシップ製品のコア機能を掌握しようとしたが、PMやリードが権限移譲を拒否
- 数年にわたる遅延・最終的な「戦略的ピボット」で終了
- 技術的優秀さだけでなく、政治的調整や正しい問題設定の重要性を痛感

なぜ全ての「悪いプロジェクト」を止められないのか

指摘や反対を繰り返すと**「ネガティブな人」扱い**されやすい
ソフトウェア企業はスピード重視文化で、懸念は「邪魔」と受け取られることも
他人の昇進や幹部の「お気に入りプロジェクト」に反対することで人間関係悪化リスク
悪いプロジェクトの数は無限、個人のリソースは有限
介入しすぎるとシニカルになり、消耗する危険性

影響力を「銀行口座」として管理する発想

影響力は有限資産であり、日々の信頼構築や成果で「貯金」される
重要な場面で「引き出し」し、無駄遣いしないことが肝要
- $5チェック：コードレビューの細かい指摘
- $500チェック：アーキテクチャ決定への異議
- $50,000チェック：VPの重要案件への反対
小さなことに毎回「ノー」と言うと、本当に止めたい時に影響力が枯渇
影響力が「マイナス」になると、意見が無視され、仕事にも悪影響

影響力を使うべきタイミングの判断基準

自分の専門性が十分かを謙虚に見極める必要
発言は「事実の宣言」ではなく「一意見」と認識
3つの観点で判断
- プロジェクトの距離感：自チームに近いほどコスト低
- 自チームへの影響度：影響大なら発言価値高
- 会社全体への影響範囲：失敗時の「被害半径」が大きいほど慎重に検討

「悪いプロジェクト」への具体的な対処方法

直接介入（核オプション）：プロジェクト中止を強く主張
- 本当に危険な場合や自チーム存亡に関わる時のみ
強い懸念表明：直接チームと会議やドキュメントで議論
- チーム自身に再考を促す
小さな介入：設計レビューや助言で方向修正
- 1時間の助言で数ヶ月の損失回避
- 「邪魔者」ではなく「協力者」として認知されやすい

介入しない場合の戦略

政治的コストや影響度が小さい場合は静観も選択肢
チームへの影響が大きい場合は依存度を下げる・抽象化でリスクヘッジ
「悪いプロジェクト」も本質的な課題や気づきがある場合が多く、長期的に活かす視点も重要

まとめ

シニアエンジニアは影響力の使い方が問われる
全ての「悪いプロジェクト」には介入できない現実
影響力の戦略的運用と、発言・沈黙のバランス感覚がキャリアの成否を左右
専門性・影響範囲・タイミングを見極め、最適なアクションを選択することが大切

Hackerたちの意見

それには同意できないな。このアドバイスは逆に有害になりかねないと思う。助けられる立場にいるなら、問題を無視しちゃダメだよ。でも、他人のプロジェクトの感情的な負担を背負う必要もない。もし何かが失敗に向かっているのを見たら、別のアプローチを考えた方がいいかもって伝えるよ。それだけ。厳しく言う必要はないし、しつこく言う必要もないけど、静かに見ているよりは声を上げた方がいい。

└

>「もし何かが失敗に向かっているのを見たら、別のアプローチを考えた方がいいかもって伝えるよ。それだけ。厳しく言う必要はないし、しつこく言う必要もないけど、静かに見ているよりは声を上げた方がいい。」そうだね、冷酷に思えるし、組織の成功を確保することにも反するように見える。仲間が失敗すると、エンジニアとしての評価が上がるかもしれないけど、あなたがより良い方法を知っていたのに仲間が失敗するのは、組織の目標や文化にとって有害だよ。少数の失敗で基準が下がって、あなた自身がそこに働きたくなくなることもある。時には他人のプロジェクトがあなたの問題でなく、フィードバックを求めていない時でも、組織にとって重要なことなら、彼らの欠点をあなたの問題にするべきだよ。そういうイニシアティブにエネルギーを注ぐべきタイミングを知ることが、シニアの証でもある。ブログでも少し触れられているね。

└

これは一番いい意見だと思う。もしあなたがもっと良いことを知っているなら、声を上げるべきだ（罰を受けない前提でね）。でも、痛みを感じた時は控えた方がいいよ。世界の重荷を背負う必要はないから。あなたは声を上げたし、もし彼らがあなたのアドバイスを無視したなら、それはあなたの問題じゃない。

└

著者が言いたいことは、タイトル「...悪いプロジェクトを失敗させることを許す」が少し誤解されている。著者が言っているのは、時にはそのプロジェクトをコントロールできないこともあるということ。だから「失敗させることを許す」というのは、著者が作り出した偽の選択肢のように思える。もっと良いタイトルは「他の人が何をしているのか、なぜそうしているのかは、あなたの仕事でない限りわからない」だね。

└

コンテキストによるね。小さな組織でプロジェクトの初期段階に関わっているなら、自分の懸念を説明するのが義務かもしれない。でも、大きな組織でプロジェクトがすでに進行中なら、プロジェクトを方向転換させるには多くの時間と労力が必要になる。それは他の場所でより生産的に使える時間と労力かもしれない。

└

それはどれくらい上手くいったの？逆効果になった？お二人ともそれぞれの方法で正しいと思うよ。

└

> もし失敗に向かっているものを見たら、別のアプローチを考えた方がいいかもしれないと伝えるようにしてる。私も同じことを、文章でやってるよ。それからは放っておく。プロとして何か言わなきゃいけないからね。それが私が給料をもらっている一部だから。でも、経験から言うと、ほとんど何も変わらないって分かってるから、義務を果たして次に進むだけさ。

└

賢く立ち回るために最善を尽くすことができるよ。もしかしたら、この直接的なアドバイスに従うのは賢明じゃないかもしれないけど、自分の理解に合った形に調整するのが良い選択だと思う。投稿には同意するよ。私が言い換えるとしたら、「政治に深入りしすぎず、一歩引いて関与することのトレードオフを評価しよう」って感じかな。

└

> …助ける立場にいる時この部分はすごく重要だね。いつ、どのように助けるかの良い判断が必要だよ。多くの人は、他の人が驚くほど簡単な方法で行動を変えれば、物事がもっと良くなることを想像できる。でも、実際に他の人を変えるために正しいボタンを押せるのは、ほんの一握りの人だけなんだ。小さな組織では、良いアイデアやフィードバックが traction を得るのはそれほど難しくないけど、大きな組織では広範な懸念に対しては非常に難しいことが多い。大きなプロジェクトが失敗する理由は、実際には経験豊富で広い文脈を持つ数人の上級技術者だけが知っていることが多い。関与する人数が一定以上になると、なぜそれが失敗するのかを説明するのが間に合わなくなることがある。無知な利害関係者たちが良さそうなストーリーを広めることにインセンティブを持っているからね。この場合、適切な反論を持った簡略化された説明が役立つこともあるけど、それにはかなりの評判や権威が必要なんだ。だから、この記事は大きな組織での戦いを選ぶことを勧めているんだ。実際に助けるチャンスは、自分の評判を壊すリスクよりも低いことが多いからね、たとえ君が正しくても。

└

数年前、プロジェクトに参加したんだけど、なんか方向性が間違ってると思ったんだよね。意見を言ったけど無視されて、もう一度言ったら、新しいVPがイエスマンばかり集めてて、そういう意見はもう受け入れないって感じだった。それ以来、事故の連続を見てきたよ。聞く耳を持たない人たちのために戦う気にはならないね。面白いことに、私が「こうなるって言ったのに」って言った2年後に、顧客がまさにそのことについて文句を言い始めた。ちょっとスッキリしたし、彼らはその問題を解決するために全体を再設計しなきゃいけなかった。プロジェクトが始まって5年経つけど、まだその機能は完全には出てないんだ。

└

それは状況次第だね。もし権限があるなら（投稿にあるように、CEOみたいに）、提案したり、プロジェクトを指揮したり、ぶち壊したりしても、否定的な人とは見られない。でも、自分の懸念を口にする権限がないと、逆にやられることもある。自分の足を撃って影響力や信頼性を危険にさらすより、船が沈むのを見ていたいな。別のコメントでも言われてたけど、「時には人を失敗させることも必要だ」。

あるマネージャーが言ってたことを思い出すな。「時には人を失敗させることも必要だ」って。誰かを支えるのにはすごくエネルギーがいるからね。いつもは彼らが泳げるようになってくれればいいなと思ってるけど、時にはその努力を他に使った方がいいこともある。あるプロジェクトには私が関わってなかったから、私の知識がなければ成功しなかったと思う。彼らは本当にひどくて、実際の仕事に質問を混ぜ込んでくるくらいだった。管理職が私のチームに負担をかけて、彼らを褒めているのを知った時から、彼らを避けるようになった。彼らがうまくいくはずがないし、実行もひどかったから、ほんとに腹が立ったよ。

└

> あるマネージャーが「時には人に失敗させる必要がある」と言っていたのを思い出す。うん、私は失敗からたくさん学んだよ。他の人にその経験を否定するなんて、私にはできない。もちろん、その失敗が会社の崩壊や他の深刻な害につながらない限りだけどね。

└

> あるマネージャーが「時には人に失敗させる必要がある」と言っていたのを思い出す。私はよく「時にはマネージャーに失敗させる必要がある」と言うよ。マネージャーの中には、自分のアイデアがうまくいかないと言われるのを嫌がる人もいるからね。拒否したり議論したりすると、彼のアイデアが失敗した理由として見られちゃう。彼らには、仕事を進めつつ、頻繁に状況を知らせるのが一番効果的だと思う。そうすれば、物事がどう進展しているかを見られるし、予想していた失敗に気づくのが遅くなる前に察知できるから。そうすれば、ポジティブに見られるし、プロジェクトの失敗から切り離されるよ。

└

人に苦労させて学ばせるのはリスキーなことだよね。自分を理解してるかどうか、君のサポートに甘えてないかを信じなきゃいけないから。結果的に失敗して学ばないこともあるし、その時は見放さなきゃならない。でも、事前にサポートしようとしたり、できることをやったなら、少なくとも心の平穏は保てるよ。

└

人に失敗させることとプロジェクトを失敗させることは、少なくとも大きなプロジェクトに関しては、かなり違うと思う。キャリアの中で、部下に「失敗」させたことは何度もあるけど、個人が何かで失敗するのは、実際にはそれほど高くつかないことが多いし、教育的な面もある。時には、そのアプローチが実際にうまくいくこともあって、グループとして新しい知識を得られることもあるんだ。

└

経営陣が失敗すると、残念ながらお互いを責めないんだよね。ポストモーテムをやって、シニアエンジニアを解雇するためにコンサルタントを雇うんだ。

一人がこう考えているなら、他にも同じように考えている人がたくさんいるよ。これは大きな組織、特に政府機関ではよくあることだね。無駄に高いコストでチームを運営することの負担は、そのチームではなく、もっと大きな予算を持っている人が負うから。お金があるけど、気にしないか、全く間違ったインセンティブを持っている（「私が管理する人数が多いほど、私は重要だ」というタイプの組織）。これは内部から見た組織の壊死で、どうしてそうなるのかの一部でもある。もしあなたが組織をリードしているなら、これを測定して防ぐ方法を見つけて。

└

人間はこう考えるんだよね。これは文化的なことじゃなくて、人間の本質だ。私たちはポジティブな人が好きで、ネガティブな人は嫌い。政治的な資本が存在することを無視しても、それは消えないよ。

大手テックの「ハウス・オブ・カード」的な政治には素晴らしいアドバイスだけど、基本的には企業の平和主義だね。他のどんな環境でも、お金やモチベーションが燃えていくのを見ている余裕なんてないよ、「政治的に健全」でいるためにね。（ラリットは複雑な企業のダイナミクスを一つのブログ記事にまとめるのがとても上手だね。）

└

大手テック企業で働いたことはないけど、もっと小さな組織でも同じようなダイナミクスを見たことがある。常に細かいことを指摘したり懸念を表明していると、他の人のアイデアに対して常にネガティブな「その人」になっちゃう。しばらくすると、みんな聞かなくなるよ。君が「問題」を見つけることは分かってるからね。こういう人たち、みんな知ってるよね。誰も一緒に働きたがらない。だから、彼らはやろうとしていることにおいて「効果的」ではない。結局、君が評価されるのは、うまくいくものを出荷した時だけで、他の人のミスを防いだ時はめったにない。ブログの核心は、重要な時に備えて準備をしておけってことだよ。すべての問題が会社を破綻させるわけじゃないし、すべての懸念が正しいわけでもない。戦うべき戦いを戦略的に選ぼう。これは、組織の規模や性質に関わらず良いアドバイスだと思う。

└

覚えておいて、平和主義は無行動とは反対だよ。平和主義は、特に政治的に、最もアクティブで効果的な方法なんだ。

もっと簡潔に言うと：* 聴衆を理解しよう。彼らが聞けないことを言うのはエネルギーの無駄。* 戦うべき戦いを慎重に選ぼう。裏返しとしては：* 直感を信じて * 本音で話し、助けることを目的に（説得するのではなく） * 他人の行動や反応に過度に依存しないように（誰かに力を持たれていると難しいけど）これらのバランスを取ることを学んでいるところだよ…

└

「聞こえない」という表現は、すごく重要で大きな意味を持つね。その言葉をありがとう。

> プロジェクトのライフサイクルの多くにおいて、それが「悪い」かどうかは非常に主観的だということを指摘するのは重要だ。これを強調したい。私は、チーム外の誰かが私たちの仕事に反対して、私たちのプロジェクトを潰そうとしたことがある。私たちがそれを押し通して、出荷して、うまくいったとき、彼らは多くの信頼を失った。 reputational capitalを何に使うかには注意が必要だよ。

└

> チーム外の誰かが、私たちの仕事に反対してそれを止めようとしたプロジェクトに参加したことがある。私たちがそれを通して、出荷して、うまくいったら、その人はかなりの信頼を失った。最近、企業で初めてこの経験をしたんだけど、今までのキャリアの中で一番狂ったことだった。人生はいつも晴れやかじゃないけど、その時点まで、協力して顧客の問題を解決するために作られた組織で、あんなに露骨な自己中心的な利己心を見たことはなかった。 naïveかもしれないけど、本当にがっかりした。

ダイナミクスは完璧なんだけど、エンジニアは「政治的にまずい」プロジェクトを「失敗させる」ことはできないと思う。そういうのを直すのは、実際のところ彼らの給料の範囲を超えてるから。責任は経営陣にあるんだ。エンジニアの役割は主に技術的なアドバイザーとして、技術的な理由（UXやアーキテクチャなど）で悪いプロジェクトを指摘することだと思う。でも、どんなに経験豊富なエンジニアでも、企業内での地位や政治的な影響力がないから、政治的な問題（権力争いや組織間の争いなど）を指摘したり直したりすることはできない。彼らはリーダーシップに対してこういう対立を指摘するべきだけど、その結果に対して責任を負う必要はない。ただ、エンジニアとしてはこういうダイナミクスを絶対に理解しておくべきだよ。キャリアに影響するからね。プロジェクトがキャンセルされて何も成果が出ないこともあるし。製品チームとプラットフォームチームの間の潜在的な権力争いは、上層部から誰が何を持っているかを明確に指示することで避けられたかもしれない。これには、組織が自分の権益を譲る代わりに何を得るかの交渉が必要だっただろうね。（ちなみに、「なんでこんなに再編が多いの？」って思ったことがあるなら、これが理由だよ。）これが起こらなかったのは経営陣の失敗だと思う。余談だけど、これはどの大企業でも起こることだけど、Googleでは特に多い気がする？それとも、Googleの人たちがオープンに話してるだけかも。最近のGoogleからの教訓についての投稿でも似たようなことを見たよね。

いい例えだね。Googleほど大きな会社で働いたことはないけど、私の経験では、投稿よりも少し楽観的なことが多いかな。リーダーシップとの信頼関係が築ければ、スタッフやアーキテクトレベルで、彼らが間違っていることをもっと伝えられるし、ちゃんと聞いてくれる。毎回「5万ドルのチェック」を出さなきゃいけないわけじゃないからね。それに関連して、すごく大事な質問があるんだ - なぜリーダーシップはいつもエンジニアを信頼しないのか？ブログには触れられていないけど、重要な答えがあるんだ - 時々、エンジニアが間違っていることもある。エンジニアは欠陥を見つけるのが得意だけど、ビジネスの視点を理解するのはあまり得意じゃない。状況によっては、欠陥のあるアイデアを進めることが理にかなう場合もある。だから、次に「バカみたいなアイデア」を聞いたら、そのアイデアの出どころをもっと理解するために一呼吸置いてみて。実際に問題があるアイデアと、消えるべきアイデアの違いを見極めるのが上手くなれば、組織内での信頼を得られると思うよ。

このアドバイスは中小企業には結構当てはまると思う。みんな会社の成功に投資してるけど、「ノー」と言い続ける人として知られたくはないよね。大企業では、プロジェクトについて意見を言う理由はあまり見つからない。チームや仕事にかなりの影響がない限り（つまり、心の平和）、疑念を持つ人になる意味がない。正しいことを言ってもあまりリターンがないし。プロジェクトが始まる前に潰せたとしても、どれだけひどい災害を防いだか誰も知らないし。プロジェクトが成功したら、反対したあなたがバカに見えるし、失敗したら、著者が言うように、それも記憶に残らない。シニアのICとして、こういう状況で見つけた唯一の実際のリターンは、もし失敗した時に解決策を用意しておくことだよ。人は「直す人」を好むからね。たとえ一度か二度しか成功しなくても、組織や会社での評価が大きく上がる。「わあ、あの人はいつも先を考えてる」ってね。前の会社で見た基本的な例は、本番環境での自動E2Eテストだった。チームメイトが回帰を検出する能力を向上させるために提案したけど、他の機能に対する投資としては価値がないと却下された。数ヶ月後、ユーザーが重大な問題に直面するのを何度も見た。チームメイトは、サイドで構築していたテストフレームワークをすぐに取り出して、称賛と組織のサポートを受けた（おそらく素晴らしい評価もね）。

└

> 大企業では、プロジェクトについて意見を言う理由はあまり見つからない。それは本当だね。現在、スタートアップがメガコープに比べて効率的な主な理由の一つだ。小さな会社では、数人のエンジニアが「これはクソだ」と声を上げるだけで災害を止められる。大企業では、同じ結果に達するのに2年、1000万ドル、そして燃え尽きたチームが必要なんだ。その主な理由は、すべての罪の元である「政治」だね。

└

企業の階段を登ることが全く意味がないことに気づいたよ。もっと努力して、バカな人の決定に責任を持たされて、それで得られる報酬は不釣り合いに少ない。最も賢い選択は、自分の望むライフスタイルを維持できるだけの給料をもらえる底辺のポジションを見つけることだね。でも、そのポジションでは経営陣の失敗の責任を問われることはない。

このブログが見落としていることの一つは、プロジェクトの方向性を修正する提案をして無視されても、最終的に提案が静かに採用されてプロジェクトが改善されることだよ。これがROIの純損失につながる。私たちが否定的な人として見られるリスクがあるのに、誰も私たちの善意や直感を認めてくれない。プロジェクトリーダーが改善を自分の勝利として発表するから。

ハクソク