スタッフソフトウェアエンジニアとしてテック企業の政治にどのように影響を与えるか

2025年10月5日原文(seangoedecke.com)

概要

ソフトウェアエンジニアは 会社の政治 に対して悲観的な傾向 政治的駆け引き に参加する必要はなく、賢く関わる方法が存在 ハイプロファイルプロジェクト への貢献が最も簡単な政治的行動適切なタイミングで 技術アイデア を提案することの重要性会社の優先事項に合わせて 自分の目標 を達成する戦略

ソフトウェアエンジニアと会社の政治

多くのソフトウェアエンジニアは 会社の政治 に対して無力感を抱く傾向
技術的な意思決定が 利己的な理由 で行われるケースが多いという認識
強力なステークホルダー のニーズを把握し、解決策を提供するのは困難との考え
政治的なゲームには 非公開情報 が多く、エンジニアが関与しても失敗しやすい現実
マネージャーやエグゼクティブは政治に多くの時間を費やし、 エンジニアは不利な立場

エンジニアが政治に巻き込まれる理由と現実

ソフトウェアエンジニアは 政治のプレイヤー ではなくツールとして扱われる現状
Game of Thrones のような策略を練るのは危険で、すぐに不利に利用されるリスク
策略には 経験と権力 が必要だが、エンジニアには基本的に不足

ポジティブな関わり方と実践例

ハイプロファイルプロジェクト の成功に貢献するのが最も簡単な政治的行動
- 例：AIプロジェクトなど会社が重視する分野への積極参加
成功すれば ボーナスや昇進、将来の重要プロジェクトへの参加 などの見返り
Ratchet effects determine engineer reputation at large companies で詳細解説

技術アイデアと政治的タイミング

自分のアイデアを 政治的キャンペーン に乗せる戦略
- 例：信頼性向上の社内ムーブメントに合わせて関連プロジェクトを提案
自分の政治資本 を使うのではなく、エグゼクティブの資本を活用する方法
組織の関心が 波のように変化 するため、タイミングを見極めることが重要

複数の技術プランの準備と提案

様々な方向性の 技術プログラム を常に用意しておく重要性
- 例：請求コードのリファクタ、ビルドパイプライン刷新、PythonサービスのGolang化、CMSフロントエンドの静的サイト化
組織の関心ごとに合わせて 最適な提案 を行うことで、実現可能性が向上
悪いアイデア が採用されるのは、良いアイデアが準備されていないとき
シニアエンジニアには 適切なアイデアを適切なタイミングで出す責任

視点の違いと結論

シニカルな見方： 会社の政治ゲームの道具 として使われる
楽観的な見方： 会社の優先順位 に合わせて自分の技術目標を達成
どちらの見方でも、 適切なタイミングで正しい計画を推進 することが重要
参考記事： Terrible Software「Don’t avoid workplace politics」、Hacker Newsコメント
本記事の内容は 機能しているテック企業 向けのアドバイス

参考リンクと追加情報

How I ship projects at large tech companies ：プロジェクト成功のための政治的考慮点
Is it cynical to do what your manager wants? ：マネージャーの要望に応えることの意味
Ratchet effects determine engineer reputation at large companies ：評判形成の仕組み
完全に機能不全の企業には 本記事のアドバイスは適用外

Hackerたちの意見

うーん、俺、あまりに機能不全な会社で働いたことがないのかも。この記事の冒頭のコメントには全然共感できないな。上から下までオープンなコミュニケーションに慣れてるし、たとえ自分が反対する方向に進んでも、他の賢い人がどうしてそんなに違う見方をしているのかを知りたいと思えるくらい話し合ってるから。エンジニアが創業した会社でしか働いてないからかもしれないけど、よくわからないな。

└

どんな規模の会社で働いたことがあるの？

└

大企業の高レベルのVPは広い目標を持っていて、さらに広い手段を持っているからだと思う。それ自体は悪いことではない - 特定の技術に固執する前に、いろんなアプローチを試すことができるから。無駄？うん。業界のリアルタイムな変化に基づいたボードの指示を満たすのには効率的？それもそう。

└

この記事の冒頭の発言には全く共感できないな。仕事で昇進したことがないんじゃない？

この投稿は以下のように要約できると思う。1. マネージャーが特にやってほしいことがあれば、それをやるべき。2. マネージャーが特にやってほしいことがなければ、将来的に何を求められるかを考えて、その準備をしておくべき。これは良いアドバイスだと思う。ただ、追加したいのは、マネージャーやリーダーシップは時々、求めていたものとは違うものをもらっても喜ぶことがあるってこと。もちろん、より高いレベルで求めていたものであればだけど。これはリスクがあるけど、成功すれば尊敬や自立への近道になるかもね。

└

マネージャーを喜ばせるためだけに生きるのは、あまり好きじゃないな。

└

自分のアジェンダを持つ準備ができているってことだと思う。例えば、コードベースをもっとミニマルにしたいなら、機会が来たときのためにPOCや詳細を用意しておくべきだよね。何か準備しておいて、サイトのスピードやSEO、バグのクレームが来たときに、そのミニマルなアイデアを解決策の一部として提案できるかもしれない。コンセプトは好きだけど、実際にどう機能するか、将来の準備をどう文書化するかはわからないな。自分のブログを運営するみたいに、仕事も少し運営してみるべきかな、理由や方法について文書を作っておいて、機会を待つ感じで。もしかしたら、光が当たらない余計な作業が増えるかもしれないけど、実際、そういうことは結構やってるよね？

└

それか、もっといい選択肢として、雇われた仕事をちゃんとやって帰るか、エンジニアリングが政治よりも大きな役割を果たす珍しい仕事を見つけるかだね。マネージャーを喜ばせるために推測ゲームをするのは楽しくないし、ただの上司だからってそんなことするのは無駄だよ。人生は短いんだから、くだらないゲームに付き合ってる暇はない。

└

これらはすべてフードチェーンを上がっていくもので、エンジニアリングマネージャーにとっても良いアドバイスだと思う。CTOに報告するディレクターとして、私もこれを実践しようとしたよ。

└

付け加えたいのは、あなたよりも政治的権力を持つ人がやりたくないことは、誰かもっと権力のある人が公に指示しない限りやらない方がいいってこと。彼らがやりたいことをやるわけじゃないけど、単に彼らを怒らせないように避けるってこと。敵を作る価値はほとんどないし、ほとんどのマネージャーはその状況で自分の身を守るためにあなたを犠牲にするよ。

└

マネージャーが特にやってほしいことがあるなら、それをやるべきだよ。これって当たり前のことに思えるけど、キャリアの初期にいる人たちに何度も教えなきゃいけなかったトピックの一つなんだ。困っている人やPIPに向かっている人たちの多くは、シンプルなループを実行することで改善できる。具体的には、1. マネージャーに優先事項を明確に聞く。何をやるべきか、状況が変わるかもしれない新しい情報に出くわしたときは、毎回その優先事項を再確認すること。2. 書き留める。見えるところに置いておく。毎朝チェックする。優先事項を思い出す。3. 完了するまでその優先事項をやり続ける。自分が完了したと思ったときに、マネージャーがそれを完了と認めているか確認する。これらのループを早い段階で内面化した人には簡単に聞こえるけど、そうでない人には明確に示さないと理解できないこともある。彼らは気が散ったり、サイドクエストに行ったり、マネージャー以外の人からタスクを取りすぎたり、興味のあるタスクを優先してマネージャーのリクエストを避けたりするんだ。

重要なのは、今月のトレンドに合わせた詳細で効果的な作業プログラムを用意しておくことだ。これが、ワシントンで物事が進む理論だと思ってる。大体の場合、壮大な計画はなくて、アイデアが出てきたときにプレゼン用のスライドを持ったオペレーターたちが待機してるだけなんだ。

Hacker Newsで議論の続きを見る

ハクソク