ハクソク

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

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

233日前原文(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に報告するディレクターとして、私もこれを実践しようとしたよ。

└

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

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

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

└

スライドデッキだけじゃないよ。ロビイストたちはすでに法案を書いてるから。

お気に入りの引用の一つ：“実際の危機、または認識された危機だけが、真の変化を生み出す。その危機が起こるとき、取られる行動は周りにあるアイデアに依存する。それが、私たちの基本的な機能だと思う：既存の政策に代わるものを開発し、それを生かしておき、政治的に不可能なことが政治的に避けられないことになるまで待つこと。” - ミルトン・フリードマン。1ページのドキュメントや技術文書を作って回覧し、危機が起きたときに再参照できるようにするのが、アイデアをその時に浮かせておく方法だと感じてる。自分の目標に向かって合意を築きながら、徐々に進めることで、理想のアーキテクチャを推進することに成功したこともあるけど、政治が得意なVPやディレクターに振り回されたこともある。1ページのライブラリを持って、それを回しておくことで潜在的に空気中に漂わせておき、そのアイデアを実行するきっかけを待つのが、ずっと成功してると思う。

└

1ページの資料があなたの認知を得たりキャリアを進めるのに役立ったのか、それともアイデアを実現するのに役立ったのか、どっちの意味？

└

この引用は好きだし、これがうまくいくと思う。ただ、タイムスケールが狂わせることがあるのが問題だね。もう一つの問題は、時々危機が無視されること。つまり、危機があるのに認められないか、何かしらの形で普通のこととして扱われることがある。

いちばん大事な政治的資本は、自分の技術的理解とスキルを高めることだよ。でも、それは会社全体の戦略に合わせて活用しないと意味がない。適切なアドバイスをして、会社のために成果を出すことで、信頼されるようになって、影響力が持てるようになる。だから、コンティンジェンシープランを準備して提案し、実行するのが一番の方法だね。

└

コンティンジェンシープランを準備して提案し、実行するのが一番の方法だよ。これをどうやって実行してるのか、もっと聞きたいな。どこで、どうやってプランを待機させてるの？

個人的には、できることはこれだと思う： - しょっちゅうプロダクションに出す（理論的な作業はしない）。 - 一般的に受け入れられる指標で勝ちを出す。 - 自分の勝ちをうまく売り込める管理職やPMを持つこと。 でも、ここでも問題にぶつかることがある。新しいVPやリーダーが常に影響を与えようとしてるから。今のシステムを維持してると、チームはWrongThinkに陥って、新しいVPはピカピカのRightThink（AIとか）を持ってる。コードがプロダクションに出た瞬間、もう「レガシー」コードになっちゃう。新しいVPは将来の理論的な富を約束できるけど、君は退屈な現実を維持してるから競争できない。現実はセクシーでも面白くもない。君は今や古いガードの一員だ。結局、上司を成功させることが大事で、彼らと一緒に新しい会社に移るポジションを持つことが重要なんだ。

└

これには本当に同意するけど、パトロネージがもっと上の方まで行くって付け加えたい。みんな、チェックをクリアするために必要なことを言ってるだけだよ。実際に成功したビジネスモデルを発明したエグゼクティブに会ったことがない。

└
  • あなたの成功を売り込むのが得意な管理職やPMを見つけること。キャリアを振り返ると、成功を改善するためにできた最大の変化の一つは、悪いPMがいるチームからできるだけ早く抜け出すことだった。優れたPMはすべてを改善してくれるけど、見つけるのが難しい。悪いPMが私たちを間違った方向に導いて、他のマネジメントチームと効果的に連携できていないチームに長く留まってしまった時間が多すぎた。状況からそのPMが外れた瞬間、すべてが改善したよ。
└

あなたの言い回しが好きだな。「未来の約束…競争できないもの」。これってよくあることで、奇妙なことに、その約束が過去26回実現しなかったっていう反論は全然通用しないんだよね。素晴らしい未来は本当に魅力的だよ！

└

あなたの言う通りだと思うし、さらに一歩上のレベルにも関係してると思う。スタッフエンジニアとして、人々に自分がコードそのものではないことを理解してもらうのがとても重要だよ。コードは単なる負債で、あなたが言った通り、プロダクションに出た瞬間にレガシーになる。自分を「コード」の側ではなく、リーダーシップやプロダクト、権力を持つ人たちの「対等なパートナー」として位置づけるのがベストだと思う。これって、しばしばフレーミングの問題でもあるんだよね！BOFHのようにほぼ同じことができるけど、リーダーたちに製品を出荷するための仲間として見てもらえるように自分を位置づけることで、「ただ製品を作るだけ」の承認を得るためにいじめる必要がなくなる。これで全然違うよ。

└

理論的な仕事については聞いたことがないけど、毎日出荷することは聞いたことがある。君が考える「頻繁に」というのがどのくらいかはわからないけど、他の場所では毎日出荷している人たちがいるよ。個人的には頻繁に出荷するのは理想的じゃないと思う。どうやって一日で何か重要なものを出荷できるの？私は会社に追加の収益をもたらすプロジェクトに取り組んでいて、もしそれらのプロジェクトが一日で終わるなら、彼らは私を解雇するだろうね。実際には年に4日しかソフトウェアエンジニアが必要ないから。これは見栄のための指標だよ。

この手のフラストレーションをよく聞くけど、「大規模なリファクタリングをして、コードをきれいにしたのに、誰も感謝してくれない」って感じのことが多いね。数年前に知り合いがデータパイプラインを数ヶ月かけて完璧に整備した話を聞いて、誰もその努力を評価しないって言ってたのが印象に残ってる。エンジニアとして、その作業が価値あることは分かるけど、PMやEMの視点から見るとどう思われるか想像してみて。PMが「先月、すべてのエンジニアリングドキュメントを箇条書きで整形するのに時間を使った」って言ったら、うーん、まあ、そうだけど、それが会社全体にどう影響するの？ もっと重要なのは、PMが影響力のある仕事をしているエンジニアと「箇条書きの整形」をしているエンジニアをどうやって区別するかってこと。PMの視点から見ると、こういう作業は見分けるのが難しいんだよね。だから、事前に何をするつもりなのかを、非技術者にも分かるように伝えることが大事なんだ。例えば、私は何年もユニットテストやインテグレーションテストを推進してきたけど、優先事項にするための政治的な意志が見つからなかった。何度も挑戦したけど、マネージャーはそれを理解してくれなかった。最終的に、すごく悪いSEVが発生して、テストがあればこういうことが起こらないって言ったら、その価値が明らかになった。今ではテストがあって、もっと重要なのは、みんながその価値を理解していることだね。

└

君が言ってるのは、聴衆が理解し、評価できる形で価値を伝えることだと思う。これは本当にセールススキルで、ほとんどの開発者はあまり経験がないか、そう認識していない。良いマネージャーがここで助けてくれるし、強く連携したスタッフの開発者とエンジニアリングマネージャーが多くのことを成し遂げられるのに同意するよ。それが私の経験で、こういう風に働く開発者にはいつも感謝してる。

└

同意する！優先事項を推進している人間であれば、優先順位を決める人に納得してもらうのが自分の仕事だってことも忘れちゃいけないよ。最も簡単な方法は、他の人と同じ言語を話すことだね。あなたのプロダクトマネージャーはおそらくドル（ユーロ、人民元など）で話してる。テストカバレッジを増やすとか、技術的な目標が200人時かかるけど、年間で400人時節約できる、サポートチケットの率を15%減らす、将来のビジネスシナリオに対応できる、みたいな善意の見積もりを提供すれば、一般的にはうまくいくよ。私のお気に入りの「トリック」は、技術的負債の作業をビジネスの観点から意味があるようにフレーミングすること。そうすれば、「技術作業」として押し込む必要がなくなるし、PMが積極的にロードマップに載せてくれるようになる。時間が経つにつれて、これも楽になるよ。最初は懐疑的な反応があるかもしれないけど、数ヶ月や数年にわたって正確な見積もりと結果を出していれば、利害関係者との信頼関係が築けるから、以前は会議を何回も重ねなきゃいけなかったことが、今では10分の会話で済むようになる。

└

言っておくけど、そういうのは目に見えない結果をもたらすんだよ。メンテナンス性が向上したり、バグの原因（誤解に基づくことが多い）を減らしたり、速度が上がったりする。でも、これらは全く測定できないから（だから目に見えない）、売り込みが難しいんだよね。

└

同意する。リファクタリングは開発者の責任だと思ってる。やる必要があるなら、実際の機能の作業をしながらやって、締切もそれに合わせて更新すればいい。そうすれば、技術的な人たちとだけ話すから、正当化がずっと楽になる。長い目で見れば、コードベースがずっと良くなるし、メンテナンスも楽になるし、新機能の開発も早くなるよ。

└

これには同意するけど、逆の例も考えられるよ。もし建設プロジェクトにいて、安全システムの点検やメンテナンスに時間をかけて、誰かが重傷を負ったり死んだりする事故を防ぐことができたとしても、管理側が「何もしていない」と思って努力を評価しないことがよくあるんだ。ROIとして定量化できない限り、利益の概念がないというのは、管理の大きな失敗だと思う。実際に命に関わる状況では、道徳的な失敗とも考える。実際、これは想像を超えた話じゃないよ。今のボーイングの状況だね。

└

例えば、トップレストランのシェフを考えてみて。手を洗うのは当たり前のことだよね。お客さんに糞便菌を感染させるなんて、レストランの経営陣に石鹸に投資させるために必要ないし。衛生管理には時間がかかるし、その間にもっとお客さんを接客できるかもしれないし。プログラマーにとって、自分自身で技術の基準を設定できるようになるのはキャリアの大きなステップなんだ。成功するソフトウェアエンジニアって、こういう教育が必要ないチームに雇われる人のことを指すんだよね。そういうエンジニアリングの衛生管理が、呼吸するみたいに当たり前なチームで。

策を練るには練習と力が必要 もし職場がそういう風に機能しているなら、新しい職場を探した方がいいよ。お花畑かもしれないけど、全ての会社がそういうわけじゃないから。（うちの会社は違う。）

いいアドバイスだね。個人的に好きな重要な役員に、自分が役立つと思われるようにできる限りのことをするのもおすすめだよ。たとえそれが、非技術的なユーザー向けの目立つけど些細な仕事（ダッシュボードとか）をすることを意味してもね。彼らに好かれて信頼されるようになったら、タイミングを見計らって本当に良いアイデアを提案すればいいんだ。

俺のアドバイスは、重要なところにお金を使うことだね。データセンタープロジェクトを引き継いだんだけど、実際にはソフトウェア開発環境なんだ。nginxで十分なのに、istioを導入しちゃった。必要なのはイングレスコントローラーだけで、これに関しては特に複雑なことは要らないんだ。VMがあって、nginxがアトラシアンツールのリバースプロキシを担当してる。でも、NSX-Tがあるから、別にnginxのリバースプロキシは必要ないんだよね。要するに、前の人たちがキラキラしたものを追い求めて、私たちの環境に合ったシンプルな方法を使わずに、物事を複雑にしちゃったってこと。