世界を動かす技術を、日本語で。

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

2026年1月16日原文(lalitm.com)

概要

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

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

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

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

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

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

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

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

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

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

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

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

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

介入しない場合の戦略

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

まとめ

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

Hackerたちの意見

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

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

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

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

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

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

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

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

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

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

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

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

Hacker Newsで議論の続きを見る