- 技術系企業でエンジニアが組織政治に効果的に関与するための実践的な戦略を示す記事で、多くのエンジニアが抱く政治的無力感をどう克服するかを扱う
- エンジニアは政治ゲームのプレイヤーではなく道具だが、注目度の高いプロジェクトの成功を積極的に支援したり、組織の優先順位の変化に合わせて技術的アイデアを提案したりすることで政治的影響力を行使できる
- 組織の関心は波のように変化するため、安定性、開発者体験、性能改善などさまざまな方向の技術プログラムをあらかじめ準備しておき、適切なタイミングで提案することが中核戦略
- 政治的必要性と良いアイデアの不在が衝突するとき、最悪の技術的意思決定が下されるため、シニアエンジニアには適切な時機に正しいアイデアを提示する責任がある
- これはシニカルに見れば権力闘争の道具になることだが、楽観的に見れば経営陣の優先順位設定を尊重しつつ自分の技術的目標を達成する方法とも捉えられる
エンジニアの政治的無力感についての一般的な考え
- 多くのソフトウェアエンジニアは社内政治に対して宿命論的な態度を持ち、関与しても無意味だと考えている
- 技術的な意思決定はしばしば完全に利己的な理由で行われるため、善意のエンジニアが影響を与えることはできない
- 強い利害関係者はあまりに無能で機能不全であり、彼らの要求を把握して解決策を提供することは事実上不可能である
- 政治ゲームはエンジニアが持たない非公開情報に依存しているため、参加しようとしても右往左往するだけになる
- マネージャーや経営陣は時間の大半を政治に使う一方、エンジニアはエンジニアリングに使うため、エンジニアは最初から深刻な政治的不利を負っている
- ソフトウェアエンジニアが本物の政治オペレーターと同じレベルでゲームをすることはできない、というのは事実である
- エンジニアが
Game of Thrones のように陰謀を巡らせ始めるのはひどい間違いであり、その種の策謀はすぐに見抜かれて不利に利用される
- 策謀を巡らせるには訓練と権力が必要だが、そのどちらもソフトウェアエンジニアにはない
政治参加の実践的な方法
- 大企業ではソフトウェアエンジニアは政治ゲームのプレイヤーではなく道具であるという単純な事実はあるが、策謀なしでも政治に関与する方法は数多くある
- 最も簡単な方法は、注目度の高いプロジェクトの成功に向けて積極的に働くこと
- これは通常業務の一部としてやるべきこととほとんど同じである
- 会社が新しいプロジェクト（最近なら AI プロジェクトである可能性が高い）に多額の投資をしているなら、エンジニアリング能力を使ってそれを成功させることは、そのプロジェクトを主導する VP や役員にとって政治的に有利な動きになる
- その見返りとして、ボーナス、昇進の後押し、将来の注目度の高いプロジェクトでのポジションなど、役員が技術系企業で与えられる報酬を受けることになる
技術的アイデアを政治的キャンペーンに活用する
- もう少し難しいが、より多くのコントロールを得られる方法は、自分の好むアイデアを既存の政治的キャンペーンに活用可能なものにすること
- 既存機能を別サービスへ切り出したいと仮定すると、方法は 2 つある
- 難しい方法: 自分の政治資本を消費して支持を集め、マネージャーに重要性を理解させ、懐疑的な人々を少しずつ説得してプロジェクト承認を得る
- 簡単な方法: 役員が自分の（はるかに大きな）政治資本をそのプロジェクトに投入するのを許す
- プロジェクトと整合する目標について全社的な指示が出るまで待つ（例: 大きな障害の後に安定性が重視される）
- そのうえで、そのプロジェクトがそれに適しているかもしれないとマネージャーに提案する
- 見立てが正しければ、組織はそのプロジェクトを支持し、政治資本を消費するどころかむしろ増やすことになる
組織の関心の波に乗る
- 組織の関心は波のようにやってくる
- 安定性の時期になると、VP たちは何かをしなければと切迫し、上司に見せられるもっともらしい安定性プロジェクトを探したがるが、自分で実行する能力はない
- 彼らは一般に、エンジニアリングチームが提案するものであればほぼ何でも喜んで資金を付ける
- 一方で、組織の注意が別の場所（例: 大規模な新製品リリース）に向いているときは、エンジニアが顧客には見えない内部的な安定性中心のリファクタリングに時間を使うことを望まない
- 技術系企業で技術的な仕事をやり遂げるには、適切な波を待たなければならない
- 複数の異なる方向の技術プログラムを前もって準備しておくのは良い考えである
- 優れたエンジニアは通常業務のなかで自然にこうしたものを見つけている
- 計画例:
- 課金コードを、キャッシュされた API 呼び出しの代わりに Webhook で更新される保存データへ移行する
- 古い手作りのビルドパイプラインを廃止して Vite に置き換える
- トラフィックの多い雑然とした Python サービスを Golang で書き直す
- 公開ドキュメントを支える遅い CMS フロントエンドを高速な静的サイトに置き換える
適時の提案の重要性
- 役員たちが課金を懸念しているとき、課金リファクタリングを安定性改善として提案できる
- 開発者体験が懸念されているときは、ビルドパイプラインの置き換えを提案できる
- 顧客が性能について不満を述べているときは、Golang への書き換えを有力な選択肢として示せる
- CEO が公開ドキュメントの状態を見て慌てたときは、静的サイトとして再構築すべきだと主張できる
- 重要なのは、その月の流行が何であれ即座に実行できる、詳細で効果的な作業プログラムを用意しておくこと
最悪の技術的意思決定が生まれる瞬間
- このやり方に従わなくても何らかのプログラムには資金が付くが、そうしなければどのプログラムになるかをコントロールできない
- 会社が最悪の技術的意思決定を下すのはまさにここである。何かをしなければならないという政治的必要性と、良いアイデアの欠如が衝突するときだ
- 良いアイデアがなければ悪いアイデアでも使われるが、この結果を望む人はいない
- 役員にとって悪い: がっかりする技術的結果を成功であるかのように売り込まなければならない
- エンジニアにとって悪い: 時間と労力を、間違ったアイデアを作ることに費やさなければならない
- あなたが非常にシニアなエンジニアなら、VP たちは内心それをあなたの責任だと非難するだろうし、彼らは正しい
- 適切なタイミングで正しいアイデアを準備しておくことは、あなたの責任である
2 つの見方
- シニカルな見方: 会社を動かすソシオパスたちが、終わりのない内部権力闘争で使える便利な道具になれという提案だと読める
- 楽観的な見方: 会社全体の優先順位を役員たちに設定させ（それが彼らの仕事なので）、自分の技術計画をそこに合わせよという提案だと読める
- どちらにせよ、適切なタイミングで正しい計画を推進すれば、より多くの技術的目標を達成できる
Hacker News の反応と関連する引用
- この記事は Hacker News で注目を集め、政治に関する他の記事よりもはるかに肯定的な反応を得た
- あるコメントは Milton Friedman の引用に触れ、この文章のアイデアを一般的な政治政策に当てはめている
- "危機（現実であれ認識上であれ）だけが真の変化を生み出す。その危機が発生したとき、取られる行動は周囲にあるアイデアに左右される。これこそが私たちの基本的機能だ。既存政策の代替案を開発し、政治的に不可能なものが政治的に不可避なものになるまで、それを生かし、利用可能な状態に保つこと"
- 一部のコメントはこのアプローチを過度にゲーム的で利己的だと批判したが、著者はそれは目的次第だと見ている
- あるコメントはこの記事の要点をうまく要約している: "指示を待ち、空白があるときに悪いアイデアを皮肉り、やりたいことをしない代わりに、著者は重要人物が何かを優先事項だと言い出したときのために、持ち出せる良くて重要なアイデアのバックログを維持している。タイミングでは妥協しつつ、やりたいことを成し遂げている"
1件のコメント
Hacker Newsの意見
この投稿の要点は次のとおり
1つ目のポイントは当たり前に聞こえるかもしれないが、キャリア初期の多くの人に何度もコーチングしてきたテーマでもある 苦戦していたりPIPに向かっていた多くの人が、以下のループをうまく回すだけで転機になった
2番は、自分自身のアジェンダの準備だと解釈している。たとえばコードベースをもっとミニマルにしたいなら、機会が来たときにすぐ提案できるよう、PoCと関連する詳細を用意しておく 準備しておけば、サイト速度、SEO関連の問題やバグが起きたとき、そのミニマルなアイデアを解決策として提案することもできる この考え方は興味深いが、実際にどう適用するかはかなり悩ましい。将来使うための準備文書を作っておくべきかとよく考える。ブログを運営するように自分の作業を継続的に文書化し、機会を待つ感じだ 多くの追加作業は無駄に終わるかもしれないが、実際にはそういうことはすでにたくさんやっている気もする
もう1つ付け加えたいのは、自分のマネージャーより政治的な力が強い人たちが反対することを軽々しくやらないことだ。ただし、その人たちよりさらに力のある人が公に指示した場合は例外だ 彼らの望むことを無理にやれというわけではなく、いたずらに不快にさせないよう気をつけるのが重要だ 敵を作る価値はほとんどなく、たいていのマネージャーは危機の際に自己保身のため自分をスケープゴートにすることすらある
私はマネージャーに「何をすべきか」を直接提案するほうを好む。重要なイシューをテーブルに載せ、その理由を訴える 自分の専門性によってマネージャーが利益を得られるよう、積極的に動くべきだ 自分もまだ経験は多くないが、何度か成功した例はある
こうした助言は上に行くほど重要になる。エンジニアリングマネージャーにも同じことが言えるし、自分がCTOに直接レポートしていたディレクターだった頃にもこの原則を適用しようとしていた
私の好きな引用の1つがある: "現実の危機、あるいは認識された危機だけが真の変化を生む。そのときの行動は、周囲に漂っていたアイデアによって決まる。私たちの基本的な機能は、代替政策を開発し、それを生かし続け、政治的に不可能に見えたものを政治的に不可避にすることだ" - Milton Friedman 1 Pagerや技術文書を書いて事前に共有しておき、危機が来たときに再び引用するやり方は、自分のアイデアを前面に出すのに効果的だった 自分の望むアーキテクチャの方向を段階的に押し進め、少しずつ目標に近づいたことがあり、合意を積み上げるのが重要だ もちろん、自分より政治スキルの高いVPやディレクターに押し負けたことも多かった だが、1 Pagerのライブラリを用意しておき、さりげなく共有して空気中に「ばらまいて」おき、実行する動機が生まれるまで待つやり方のほうがずっと効果的だった
「政治闘争に負けた」という部分に共感する。中間管理職以上になって驚いたのは、下位レベルの社員が政治的な立ち回りをしているのがとてもよく見えることだった 多くのICや1階層目のEMは、自分の政治感覚やソーシャルIQを過大評価している また、組織内コミュニケーションの深さや広さが違うので、誰かを説得しているつもりで動いても、そのステークホルダーが終わった後で管理職にそっと状況を伝えてしまう 私たちが管理チームで拙い政治的立ち回りを静かに抑えようとしていたとき、こうした場面を何度も目にした
「1 Pagerや技術文書を漂わせる」というのが、具体的にどういうやり方なのか気になる
その引用には共感するし、この方法は効果がありそうだ。ただ、現実には時間スケールが狂っているほど長く、疲弊することがある また、危機そのものが無視されることも多く、通常のものとして認識されなかったり、正常化されてしまうこともある
1 Pagerによって評価され、キャリア上の昇進にもつながったのか、それともアイデアの実現に役立っただけなのか気になる
自分が考える最良の方法だ
頻繁にプロダクションにデプロイすること（理論的な作業より現実的なデリバリー重視）
意味のある結果（wins）を達成すること（合意されたメトリクスで）
自分の成功をうまく売り込んでくれる「セールスマン」がマネジメントやPMの中にいること それでも問題は起きる。常に新しいVPやリーダーがイノベーションを見せたがる。既存システムを保守するチームは間違っていると見なされ、新しいVPはAIなど先進的なアイデアで自分の路線を強調する。自分のコードはデプロイされた瞬間から「レガシー」扱いされる するとVPは華やかな未来の約束を次々と打ち出すが、今の現実を維持する自分の役割では絶対に太刀打ちできない。現実はセクシーでも面白くもないからだ。そうして旧勢力になってしまう 結局の本質は後見関係、つまり自分の上にいるVPを成功させ、その人が転職するときに一緒に移れるポジションを作ることだ
本当にその通りだと思う。もう一歩踏み込むなら、staff engineerとして「自分はコードそのものではない」という認識をはっきり持たせることが重要だ。コードはデプロイされた瞬間から負債／レガシーになる 自分は「コードの擁護者」ではなく、リーダーシップ、プロダクト、意思決定者などとEQUAL PARTNERとして位置づけられるのがベストだ。これは単なる視点やフレーミングの問題だ。同じ行動でも、自分が「仕事のパートナー」と見なされれば、リーダーたちは自分を積極的な協力者と捉えるし、そうでなければ無理に説得しなければならない障害物と見なされてしまい、大きな差が生まれる
「PMの中に自分の成果をうまく売る人が必要だ」という点には強く共感する。振り返ると、キャリアで最も大きな変化を生めたのは、悪いPMから離れる速さだったかもしれない 良いPMはすべてを改善するが見つけにくい。逆にPMが方向を誤るとすべてが壊れ、そのPMがいなくなった瞬間に空気が一変したこともあった
「未来の約束とは競えない」という表現が本当に良かった。そういうことはあまりにも頻繁に起きる。たとえその約束が過去26回一度も守られていなくても、「輝かしい未来」はいつだってすごく見えるものだ
実務では頻繁にプロダクションへデプロイするという考え方（rep=実行重視、理論禁止）は良いが、VPの雲をつかむような未来の約束が、なぜ実現可能性よりも高く評価されるのか不思議だ
「理論的な作業」という言い方は聞いたことがないが、毎日デプロイしているところが実際にあるのは確かだ。ただ、頻繁なデプロイが理想的だとは思わない。1日で実質的なものをどうやってデプロイできるのか疑問だ。私のように会社に追加収益をもたらすプロジェクトは1日では終わらない。1日で終わる仕事なら、エンジニアは年4回だけ必要という話になる。だからこの「頻繁なデプロイ」はむしろVanity Metricだ
私はdysfunctionalな会社で働いたことがないので、この文章の前半にはまったく共感できない 自分の経験では、常にトップダウンのコミュニケーションが活発で、自分が同意しない方向に開発するとしても、事前に十分議論して、なぜ賢い同僚が自分と違う見方をするのか興味深い発見があった エンジニア創業の会社でしか働いたことがないからなのか、それとも単に運が良いだけなのかは分からない
大企業の上位VPたちは目標も広範で、手段の概念もより広い。必ずしも悪いことではない。特定の技術や方法論に固定される前に、さまざまな手段を試す機会がある。もちろん無駄もあるが、業界の地殻変動に即応して経営陣の任務を満たすには効率的でもある
どの規模の会社で働いたことがあるのか気になる
「少し難しい道ではあるが、より多くのコントロールを得る方法は、自分のアイデアを既存の政治的キャンペーンに乗せることだ」 私はVP主導のプロジェクトにうまく相乗りする技術を身につけた。苦々しいが効果は確かだ
この陣営でよく聞く不満は、「コード全体のリファクタリングを完璧にやったのに、誰も認めてくれない」というものだ 昔の知人が、数か月かけてデータパイプラインを完璧に掃除したのに誰にもその価値を分かってもらえなかったと自慢しているのを聞いて、いろいろ考えさせられた エンジニアである自分にはそれが価値あることだと分かるが、PM/EMの視点では、PMが1か月かけて社内の全エンジニアリング文書に句読点を打って並べ替えたとしても、「それで会社にどんな影響があるのか？」と言われるのと似ていると思う PMの立場では、影響力のあるエンジニアと「単なるフォーマット作業」しかしていないエンジニアをどう見分けるべきか曖昧になる 結局のところ、これからやろうとしていることを、非技術系の聴衆に合った形式で事前に明確に説明することが重要だ 以前、ユニットテストや統合テストを推進したが、政治的な後ろ盾が弱く、何度も優先順位に入れられなかった。実際に大きなSEV（重大インシデント）が発生してから、「これを防ぐにはテストが必要だ」と話したところ、ようやく全員がその価値に同意した。今では誰もがテストの必要性を理解している
本当に同意する。もし自分が何かの行動を優先事項として推進する立場なら、それを優先順位を決める人の論理と言葉で説明しなければ通らない たとえばPMは通常、金額ベースで考える。テストカバレッジ拡大のような自分の技術的目標が年間200 dev hourを必要とするが、年間400 dev hourを節約できる、サポートチケットを15%減らせる、将来のビジネスシナリオを可能にする、などと示せば、はるかに説得しやすくなる 私の好きな手法は、tech debtの作業を「技術作業」ではなく明確なビジネス効果として包装し、むしろPM自身にロードマップへ入れさせることだ こうしたやり方はキャリアが進むほど簡単になる。最初は懐疑的でも、時間が経つにつれて自分の見積もりと成果への信頼が積み上がり、以前は何度も会議が必要だったことが、今では10分の会話で済むようになる
この意見にも同意する。ただ、逆から考えることもできると感じる たとえば建設現場で、誰かが安全システムを丁寧に点検・維持して事故を防いでいたとしても、マネジメントがその価値をまったく認めず報酬も与えないことは多い 定量的にROIとして示されないと何の利益も認めないというのは、それ自体がマネジメントの大きな失敗であり、安全が生命に直結する場合には道徳的失敗でもある 実際、これは今のBoeingで起きている現実だ
聴衆が理解できる価値で説明するのがポイントだ。結局これは営業スキルであり、多くの開発者には経験もなく、気づきにくいと思う。良いマネージャーがうまく支えてくれるのが理想だし、自分と考え方の合うstaff devやengineering managerが一緒にいると本当に大きな成果が出る 私もこうした同僚と協業するといつもありがたく感じる
手洗いの必要性をわざわざ説明して投資判断を取らなければならないなら、そのチームには何か問題がある。トップクラスのレストランのシェフに「石けんを買うべきか」を説得する必要がないのと同じで、それが当たり前の組織に入ること自体がキャリアの一段階だと思う。成功したSWEとは、そのレベルが当然なチームで働く人のことだ
同意する。リファクタリングは開発者が自然に責任を持つ仕事だ。機能開発の際に自然に一緒に進め、締切の更新をすれば、技術者同士だけで話が通るので説得ははるかに楽になり、長期的にはコードベースの品質が大きく向上する。その結果、保守が容易になり、新機能開発も速くなる
自分が築ける最大の政治資産は、自分の技術的理解と能力だ。しかしこの力は、会社全体の戦略と文脈の中で助言し、実際にデリバリーするときにこそ役立つ 適切な助言をし、会社のために行動すれば、人は自分の話に耳を傾け、頼るようになる。最終的には、自分が方向性を定められる権限が生まれる 別個のプランBのようなリスク管理案を用意し、それを必要なときに提案・実行するのが最善の方法だ
かなり過激だが、良いポイントを含んだキャリア本がある その1つは、技術的能力がむしろ自分のキャリアと権力に害を与えうるということだ。自分の時間とエネルギーを実際に何かをすることに使うと、有能なマネージャーは、自分ができるだけ政治的影響力を持てないよう、その場に縛りつけておこうと積極的に動く 逆にマネージャーになれば、実際には何もしないで、イニシアチブ（プロジェクト、方針、変化）をできるだけ多く始め、自分の政治力を巧みに調整すればよい そのイニシアチブが実際に価値創出に成功するかどうかは重要ではなく、まったく気にしなくてよい。自分はすでにその場を去っており、なおここで成功や価値にこだわって働いている人たちが遅れを取るのだ 必要なら、マネージャーは事後的に「自分がやった」とクレジットだけ持っていけばよい
「Flavor of the month」に合わせて態勢転換する専任チームがいないと物事は回らない――これが私の政治理論だ。ワシントンDCも同じだ。巨大な計画があるわけではなく、チャンスが来たらすぐに売り込める軍団が常時待機している
政治闘争を練習して権力を蓄えなければならないなら、新しい会社を探すべきだ 自分がナイーブだと思われるかもしれないが、どこもそういう会社ばかりではない。うちの会社はそうではない