- シニアエンジニアは「正しさ」より「効果的な行動」を重視し、すべての誤ったプロジェクトを止めようとはしない
- 「悪いプロジェクト」 には技術的・政治的・UX的な問題が含まれ、しばしば主観的な判断によって左右される
- 影響力は銀行口座のように管理すべきで、頻繁に反対すると信頼を失い、「政治的破産」の状態に陥る可能性がある
- 介入するかどうかは プロジェクトとの距離、チームへの影響、会社全体への被害規模によって決まる
- すべての問題を解決しようとするのではなく、戦略的に介入のタイミングを選び、それ以外は観察と備えで対応すべき
悪いプロジェクトの定義と事例
- 「悪いプロジェクト」は 不要な問題解決、複雑な設計、政治的動機 など、さまざまな形で現れる
- UXの面では、存在しない問題を解決したり、既存のフローを壊したりするケース
- 技術的には 過度な複雑さ、誤ったライブラリ選定、非効率なアーキテクチャ
- 政治的には 昇進や流行への追随のためのプロジェクト
- プロジェクトの良し悪しは 時間が経って初めて見えてくる主観的な判断であり、初期段階では明確ではない
- Googleでの事例では、プラットフォームチームが中核となるユーザーフローを別チームに移そうとしたプロジェクトが政治的理由で失敗した
- 技術的には優れていたが、組織間の権限問題により2年後に廃棄された
- 「政治と問題定義の正確さは、技術的完成度と同じくらい重要だ」という教訓を示している
すべての悪いプロジェクトを止められない理由
- ソフトウェア企業には 「速く実行する」バイアス が強く、懸念の提起はスピードを遅らせる行為と見なされる
- そのため、大きな問題と認識されなければ無視される可能性が高い
- 繰り返し反対すると 「否定的な人物」だとレッテルを貼られ、未然に防いだ失敗は評価されない
- 反対は 他人の昇進や上級幹部のプロジェクト に影響しうるため、政治的なリスクがある
- 一人のエンジニアが負担できる注意力には限界があり、すべての問題に介入するとシニカルになってしまう
影響力を「銀行口座」のように管理する
- 影響力は 成果と協業によって蓄積される資産 であり、反対するたびに引き出される
- $5の小切手: コードレビュー水準の軽微な指摘
- $500の小切手: アーキテクチャの決定やスケジュールへの反論
- $50,000の小切手: エグゼクティブ級プロジェクトの中止を試みること
- 些細な問題に繰り返し介入すると、大きな案件に対応する余力を失う
- 影響力が尽きると、**会議への招待から外される、意見を無視されるといった「政治的破産」**状態に陥る
介入のタイミングを判断する基準
- 専門性の検証: 自分の判断に十分な根拠があるかを確認する
- 発言の限界を認識する: 意見の提示は「命令」ではなく「視点の共有」である
- 3つの判断要素
- 近接性（Proximity）: 自分のチームに近いほど介入コストは低い
- チームへの影響（Team Impact）: 失敗した際にチームへ直接的な被害が予想されるなら、介入の価値は高い
- 会社規模（Company Scale）: 失敗が組織全体に及ぼす影響が大きいなら介入が必要
悪いプロジェクトへの対応方法
- 直接介入: プロジェクトの中止を求めたり、強い懸念を示す文書を提出したりする
- 部分的介入: 設計の方向性を調整したり、よりよい解決策へ導いたりする
- 協力的な姿勢で接すれば 「助けてくれる人」と見なされる 可能性がある
- 非介入: 政治的な慣性や影響力の限界により、介入する価値が低い場合
- チームが関係しているなら、依存度の縮小や代替手段の構築など、備えを講じる
- 関係がないなら、静かに観察しつつ、内部でのみ意見を共有する
- チーム運営: メンバーには現実を率直に共有しつつ、不必要な政治的詳細は省く
結論
- 「正しさと効果性は異なる」 という認識が核心
- 大企業では 論理よりも政治と文脈が機能 し、すべての誤りを正せるわけではない
- 影響力と信頼を戦略的に使い、実際に変化を生み出せる瞬間に集中すべき
- それ以外の場合は 同僚と共有し、備え、観察を通じて学ぶ
- 完璧に解決できなくても、このアプローチが持続可能なやり方である
1件のコメント
Hacker Newsの反応
以前、あるマネージャーが「時には人を失敗させるままにしておくべきだ」と言っていたのを思い出した
ある人たちを支え続けるのに、あまりにも多くのエネルギーがかかっていた。いつかは自力で泳げるようになってほしいと思っていたが、その努力はもっと良い場所に使うべき場合もあった
私が関わらずに進められたプロジェクトがあったが、私の知識なしでは絶対に成功し得なかった。そのチームはあまりにひどく、質問を仕事のふりをして混ぜ込みながら進めていた
しかも経営陣が私のチームを貶し、彼らを褒めていると知ったときは本当に侮辱された気分だった。彼らの実装はひどいものだった
自分のアイデアが通らないと言われるのを嫌うマネージャーもいる。反論すると失敗の原因にされる
だから私は仕事は進めつつ、彼らに頻繁に状況を共有する。そうすれば予想された失敗を本人たちが目にできるし、私を失敗から切り離せる
個人の失敗はコストが低く、教育的でもある。むしろその人たちのやり方がうまくいくこともあり、組織が新しい知的資産を得ることさえある
失敗しても学べないかもしれない。それでも最善を尽くしたのなら、良心の平安は得られる
プロジェクトが「悪い」かどうかは、そのライフサイクルの大半において主観的だ
外部の人間がそのプロジェクトに反対して中止させようとしたことがあったが、最終的にリリースされて成功すると、彼らの信頼は崩れた
自分の評判をどこに使うかは慎重であるべきだ
世の中がいつも陽気で幸せに満ちているわけではないと分かってはいるが、あのときは本当にがっかりした
「俺の猿じゃない、俺のサーカスじゃない」という言い回しの通り、自分の責任でないことには関わらない
アーキテクトとして働いていたときも、自分の領域ではないUIやビジネスロジックには不要な助言をしなかった
上位マネージャーが決めたことにはただ従う。コンサルタントとして働くときも同じ原則を守る
自分の専門分野でのみ慎重に介入する。それもC-suiteの承認があるときだけだ
この助言は中小企業にはかなり適切だ。だが大企業では、プロジェクトに反対意見を述べること自体ほとんど意味がない
成功すれば自分がバカに見え、失敗しても誰も覚えていない
本当のROIは、失敗した後に解決策を提示するときに生まれる。人は「問題解決者」が好きだ
昔、自動化されたE2Eテストを提案して却下されたことがあったが、後で問題が起きたとき、そのフレームワークを持ち出したら英雄扱いされた
むしろ下位職位にいてストレスなく生きるほうが賢いと感じる
一方で大企業は政治のせいで何年も何百万ドルも浪費する
「問題を無視すべきではない」という立場だ
助けられる立場にいるなら、静かにでも別のアプローチを提案すべきだ。わざわざ感情的に反応する必要はない
小さな組織では良いアイデアが反映されやすいが、大きな組織では政治的リスクのほうがはるかに大きい
実際に助けられる確率より評判を失う確率のほうが高い。だからどの戦いを選ぶかが重要だ
だが大きな組織で、すでに進行中のプロジェクトを変えようとすると、莫大な時間とエネルギーがかかる
実際には、私たちはそのプロジェクトを制御できないことが多い。「別のチームがなぜそうしているのか分からない」のほうが正確な題名だ
プロフェッショナリズムとは、言うべきときに言うことだ。だが経験上、変わることはほとんどない
今まさに現実にこういう状況を見ている
事業オーナーがコストとスピードのためにローコードプラットフォームを選んだが、結局は巨大なハック同然のカスタマイズが必要になった
私のチームはTypeScriptで1日に何度もデプロイしているのに、そのチームは月に1回しかデプロイせず、curlで妙なことをしている
この助言はビッグテックの政治的現実では優れているが、結局のところ企業版の平和主義のようにも見える
別の環境では、金も動機も燃やしてしまう余裕などない
（それでもLalitは複雑な組織ダイナミクスを短い文章によく収めている）
いつも粗探しをする人は、結局否定的な人というレッテルを貼られる
要するに重要な瞬間のためにエネルギーを温存しておけというのが核心の助言だ。すべての問題が会社の存亡を左右するわけではない
エンジニアには、政治的に悪いプロジェクトを「失敗させるままにする」権限はない
それは経営陣の責任だ。エンジニアは技術的助言だけしていればよい
ただし、こうした力学を理解していないとキャリアに影響する
プロダクトチームとプラットフォームチームの縄張り争いは、明確なリーダーシップの欠如が原因だ
なぜこうしたことが頻繁に起きるのか知りたければ、Google関連の記事が参考になる
こうした考え方は大組織、とくに政府機関でよく見られる
コストは別の部署が負担し、管理する人数で権力を測る構造になっている
こうした組織的壊死を防ぐには、リーダーが明確な測定と予防の仕組みを築かなければならない
政治資本を無視しても消えるわけではない
良い比喩だ
リーダーシップと信頼を築けば、「あなたは間違っている」と言える余地が生まれる
だがリーダーが常にエンジニアを信じないのは、ときにはエンジニアのほうが間違っているからでもある
エンジニアは欠陥を見つけるのは得意だが、ビジネス文脈を理解するのは苦手だ
だから「バカげて見えるアイデア」であっても、文脈を理解してから判断すべきだ
本当に潰すべきアイデアと、単に欠陥があるだけのアイデアを見分けられるようになったとき、組織内の信頼を得られる