スタッフエンジニアが明かす！テック企業の社内政治で影響力を高める秘訣！
引用元：https://news.ycombinator.com/item?id=45473852
この記事は、マネージャーが何を望んでいるか理解し、それに従うか、将来望むことを先読みして準備しろってことだね。良いアドバイスだと思う。ただ、時にはマネージャーが要求したものと違うものでも、より高いレベルの目的が達成できれば喜ばれることもある。これはリスキーだけど、成功すれば尊敬と自主性を速く得られるよ。
マネージャーに媚びへつらうためだけに生きたくはないね。
もし大手テック企業でキャリアを築く別の戦略があるなら、ぜひ教えてほしいな。興味あるよ。
マネージャーの指示に従うのは当たり前だけど、新人には何度も教える必要があることだね。彼らはマネージャーに最優先事項を明確に聞き、それを書き留めて毎日確認し、終わるまで取り組む。これって単純だけど、多くの人が見過ごしがちで、脇道に逸れたり、マネージャー以外の人のタスクを受けたり、自分の興味を優先したりするんだ。
小さなテック企業で働くのは、何か違うの？
全く同感。このスキルはどんなに上に行ってもなくならないね。上に上がるほど、次に何が来るか見抜き、それをより速く解決する方法を知ることが重要になる。新人の頃、優秀なマネージャーがいて、チームの別の人が脇道に逸れて成功するのを見たよ。彼らは2週間〜2ヶ月後に起こる問題を知っていて、経験とプロジェクトの方向性に関する情報があったんだ。俺が彼らを真似してたら失敗してただろうね。
全然違うよ。人生が必ずしも良くなるわけじゃないけど、特に小さい会社では社内政治の役割ははるかに小さい。会社全体で10人くらいの規模なら、客観的に優秀なら政治的な理由で邪魔される可能性はかなり低いし、誰が価値を出しているか一目瞭然だからね。逆に凡庸なら隠れる場所もない。小さい会社にも政治はあるけど、それはシンプルで、みんなが創業者を喜ばせようとするんだ。創業者が素晴らしい人なら最高、そうでなければみんな大変な思いをするだろうね。
元エンジニアで最近マネジメントに転身したけど、まさにこれが有能なエンジニアが期待以下だと見なされる理由だね。正しい問題に集中して、脇道タスクは後回しにしろってこと。
マネジメントが「正しい問題」と「サイドクエスト」をどう認識してるか、どうやって見分けるの？これってかなり主観的で操作されがちだよね？エンジニアは設計が好きで、社内政治なんか興味ないって。
上司が変わるたびにプロジェクトがお蔵入りになったり、部署が干されたりするの、見たことない？そんな状況でどうするんだよ。
特定の個人じゃなく、「ビジネス」に忠誠を誓うのが良い戦略だよ。ビジネスの成功に一番コミットして、それを周りに示せば、自然と価値のあるポジションを築ける。
自分の重要性をアピールするんじゃなく、長期的な目標に集中するんだ。そうすれば仕事ももっと楽しくなって、創造性も高まるよ。
「適切な波を待つべき」ってのは違うな。待たずに、まず自分で行動を開始しろ！
30年間SWEをやってきた俺が言いたいのは、キャリアの初期段階の人には、小さな会社で働くために全力を尽くすべきだってことだよ。これはダントツの一番のアドバイスだね。
サイドクエストに手を出したければ、まず十分な信頼を積み上げておく必要があるんだ。
記事の2番目のポイントって、自分のアジェンダを事前に用意しとくってことだよね？例えば、コードをミニマルにしたいなら、POCとか詳細を準備しとくんだ。サイトの遅延とかSEO、バグの苦情が出た時に、それを解決策として提案できるかも。
このアイデアは良いけど、実用性や準備の文書化については疑問。ブログみたいに、なぜ、どうやって、って文書を作って機会を待つべきか考えるけど、日の目を見ない余分な作業になるかな？いや、どうせ普段から色々やってるか。
「次に起こることを見抜き、それを素早く解決する」って考え方は、俺にはすごく奇妙だよ。スタッフエンジニアの仕事って、明日の問題を無理に解決しなくていいって学ぶことじゃない？今の制約の中で解決して、必要なら拡張できるようにするもんだろ。
なんで組織は逆の考え方をするの？マネージャーなら、与えたタスクを達成するより、優秀な部下にあなたが望むことを推測させる方が良いとでも思うのか？本当に疑問だよ。
「マネジメントが正しい問題とサイドクエストをどう認識してるか？」ってのは、「聞けばいい」んだよ。俺がメンターで見てきた問題の多くは、エンジニアがコミュニケーションせずに考え込むことだった。不明確ならとにかく話せ！
スタンドアップをゲームみたいにせず、曖昧ならマネージャーにメールして、自分が最善だと思うことやってると伝え、間違いがあれば教えてくれって言うんだ。
「部署が干されたりすることないか？」って聞かれたけど、マネジメントが秘密の決定したり、部署が公の決定を無視するような機能不全の会社で働いたことはないね。そんなことする意味ある？
聞いてないとか、秘密の変更があったとか言い訳する奴はいたけどな。
「凡庸なら隠れる場所はない」って一文で、君は小さな会社で働いたことがないって確信したね。小さな会社ってのは、他に選択肢がない人が、自ら望んでか、そうじゃなくても、楽をするために行く場所なんだよ。
この戦略は良いね。俺も1年くらいスタートアップで実践して、めちゃ楽しかったんだ。でも新しいマネージャーが来て、技術チームの意見も聞かずに指示し始めた。俺は製品にとって良いことのために戦い続けたけど、そいつがアホで失礼だったから、ストレスが爆発して辞めたよ。でも後悔はないね。好奇心のない奴らのアホな指示なんか、俺には聞けない。
マネージャーが部下にその「アルゴリズム」をちゃんと説明しないのは、ひどい仕事だぞ。たった3行で済む話なのに、一度も説明しないなんてさ。そのせいで、優先順位とか、それをやるべきだってことを知らないジュニアやミッドレベルのSWEがたくさんいるんだ。ヤバいよ。
会社が機能不全になる理由の一つは、下位・中堅マネージャーが、優先順位を明確にしてフィードバックするって考え方を避けてるみたいだからだね。
51歳だけど、中小企業が本当に好きだよ。前の会社ではCTOの指示に忠実に従うだけで、AWSの経験がなくても2年間も技術アーキテクチャ全体を主導できたんだ。でもね、その後のAWSでの仕事では給料が50%も上がったし、22歳のインターンが2022年にもらった内定時の給料は、俺が46歳だった2020年と同じだったって話もある。だから「原則を貫く」ってのは、かなりの大金を捨ててるってことだよね。
俺はもう51歳だから、今さら大企業で働くくらいなら毎日サボテンで肛門検査された方がマシだと思ってる。他の大企業からの誘いやGCPの高給オファーも断ったんだ。今の700人くらいの会社も、スタッフエンジニアとして裁量があるから居心地がいいんだ。
でも、7万5000ドルから10万ドル以上も稼げるのに、社内政治を「やらない」ってのはどうかと思うよ。今は金より優先したいことがあるってだけ。あと51歳になって学んだのは、どの会社にも「キャリア」を賭けるな、ってことだね。環境が変わったり給料が市場に追いつかなくなったら、いつでも転職できるように準備しておくべきだよ。今で10社目さ。
それか、もっといい方法がある。ただ雇われた仕事をして家に帰るか、政治よりエンジニアリングが大事な稀な仕事を見つけるか、だな（もし可能ならだけど）。ただ上司のご機嫌取りのために、推測ゲームをするのは不愉快だ。人生はくだらないゲームに費やすには短すぎるよ。
まぁ、だいたいこんな感じだよね。自分のやり方でやって、それがうまくいけば評価される。でも自分のやり方で失敗したら、自分が悪く見えるだけ。指示されたことをやっていれば、はるかに安全だよね。だから独自路線を行くなら、成功するって自信が必要だよ。
＞会社が機能不全になる理由の一つは、下位〜中位のマネージャーが優先事項を明確に示したり、進捗についてフィードバックしたりするのを嫌がるように見えることだ。
これって、無能なんじゃなくて意図的だっていう可能性を考えたことある？もしこれらが明確に伝達されず、もっと重要なことに書面で残されなかったら、後で都合の良いように合意内容を再解釈して、問題が起きた時に責任を回避できるじゃん。これは完全に合理的な行動だよね。だって、そうする全ての権力を持ってるんだから。
この議論の何が間違ってるかっていうと、みんな暗黙のうちにマネジメントは正直で、オープンかつ誠実にコミュニケーションするって前提で話してることだと思うんだ。悲しいけど、そんなのはごく一部のケースでしかなくて、大抵は逆のインセンティブが働いてるんだ。ゲームを裁く側は、常に不正行為をした方が得なんだからね。
違うかもしれないけど、俺は毎週だいたい1日を「スカンクワークス」プロジェクトに費やしてるよ。これはまだ誰も頼んでないけど、いずれチームのためになるようなやつだ。そうすると、いざそれが求められた時に、ラフな解決策がすぐに提示できるんだ。
’マネージャーを良く見せる’ってことだよ。
＞でも政治の役割ははるかに小さい
「うまくいく」の定義って、マネージャーの視点によるんだよね。彼らが有能で、変な上司じゃないとしても、あなたとは違う目標や優先順位を持ってるかもしれない。もし彼らとずれてしまったら、たとえあなたがやったことが技術的に優れていてプロジェクトに合っていても、おそらく大変な思いをするだろうね。
＞でも政治の役割ははるかに小さい
これは俺が経験してきた小規模テック企業の経験とは全く違うな。たくさん働いてきたけどね。
でも政治の性質はすごく違うんだ。小規模企業では、ICとして複数のCレベルと直接仕事をする可能性が高いし、彼らの間で重要な文脈を伝えることも多い。シニアICは、物事が進むようにチームを横断してかなり積極的に働きかける必要があるし、すぐに「仕事をサクッとこなしてくれる良い人たち」っていう社内ネットワークを築くことになるだろうね。
政治がないように見えるのは、リーダーシップと仲良くしてるだけで人生がすごく楽になる場合があるからだよ。でももし逆の状況、つまりリーダーシップの誰かに嫌われてしまったら、この状況がいかに政治的か痛感するだろうね。一つの人間関係が悪くなるだけで、小規模企業では全てが台無しになりかねない。
大企業では（少なくともICとしてなら）頭を下げて、政治についてはマネージャーに任せておけばいいから、そんなに難しくない。マネージャーにとっては、階層が広くて深いから「リーダーシップと友達になる」っていうのが通用しないことが多いから、より政治的に見えるかもしれないね。
＞コードベースをもっとミニマルにしたいなら、機会が来た時のためにPOCと詳細を準備しておこう。
なんでそんなことしたいの？そういう仕事で評価されることはないよ。経験から言うと、こういうことでは絶対に認められないし、給料も増えない。そして間違いなく、もっと仕事を押し付けられるだけだろうね。主体的に動いて何かを改善しても、自分には何の得もないんだよ。
もしあなたが、会社の駐車場で役員が真新しいLamborghiniに乗ってるのを見て「俺があれを実現したんだ」って誇らしげに思うタイプの人間なら別だけどね。
もちろん、双方の2、3、5行のテキストよりずっと複雑なニュアンスがあるけどね。
それは、憶測と私が割り当てたものの達成、っていう話じゃないんだ。これは単純化しすぎた例だけど、エンジニアが依存関係のある2つのタスクを抱えているとして、タスクBを動かすためにタスクAをやり直す必要があるのは、質の悪いエンジニアリングだよね（APIの定義が曖昧な場合を想像してみて）。良いエンジニアは、もう少し先まで考えるものだよ。
スタッフ+レベルなら、それだけでなく「この仕事をやり直す可能性はどれくらいあるか」を考慮して、それに応じてスコープを設定したり、私に「ねぇ、Alphaサービスに機能を追加するたびにXYZをやらないといけなくなるんだけど、Betaではそうじゃないんです」って言いに来たりすることを期待するよ。彼らは私より10倍もコードを書く時間があるから、その辺は私よりよく知ってるはずだ。
私のチームは私の優先順位、私が何を重視しているか、そして私が注目している分野を知っているよ。もし一人の人間が役に立たない方向へ逸れ続けるようなら、それはその個人と直接対処すべき問題だね。
チームの規模、チームの成熟度、そしてプロダクト開発の状況によって、これは変わるだろうけど。
「大企業で働きたくない」って思ってたけど、3年後、大手企業に転職したらマジで衝撃だったよ。技術もマネジメントも給料も、何もかも中小企業より段違いに良かったんだ。もっと早く行っておけばよかったって、本気でイライラしたね。
キャリアは金だけじゃない。給料のためにヤバい環境に耐える人もいるけど、金を追いかけるだけの「転職」じゃなくて、心身の健康を優先する道もあるんだ。30代、40代でストレスフリーな生活を送る方が、50代で金銭的自由を得るよりずっといいって。
もっとコメントを表示（1）
「危機が変化を生む」って言葉が好きでね。俺は普段から1 pagerとか技術文書を書いてみんなに回しておいて、何か問題が起きた時にそれを引っ張り出すんだ。VPsやDirectorsには政治で負けることもあるけど、これで俺のアイデアを通したり、アーキテクチャを少しずつ進めて目標を達成できてるよ。
中堅以上のマネージャーになって驚いたんだけど、下っ端が政治をしようとするのってすごくバレバレなんだよ。みんな自分の政治センスを過信してるし、社内の情報も少ない。俺らマネージャーは、みんなの拙い政治工作を優しく見守りながら、そっと抑え込もうとしてるんだ。
俺は政治が苦手で、隠し事もない。良いエンジニアリングとシステムの長期健全性、同僚への公平性だけを考えて正直にやってきたけど、VPの考えと合わない限りいつも失敗するんだ。元海兵隊で政治がなかったから、今の世の中についていけない。もう政治は諦めて、1 pagersを書いてチャンスを待つことにしたよ。
素直な人と働くのはホント楽だね。彼らは自分を良く見せるための悪だくみをしないし、すごく貴重だよ。俺もそうありたいけど、結局現実は政治的だ。だから、必要な政治はやるけど、あとは素直で信頼できる仲間たちとつるむようにしてるんだ。
(コメント3の戦略に対して) その名言も戦略もいいと思うよ。でも、タイムスケールが長すぎて気が狂いそうになることもあるんだ。それに、危機自体が無視されたり、当たり前になっちゃうこともあるからね。
(コメント3の戦略に対して) 1 pagersとか技術文書を「浮遊させる」って、具体的にはどういうことなの？
(コメント8への回答) 同僚に送るんだよ。この戦略を成功させるには3つ大事なことがある。
1) みんなが読んでくれるような確かな評判があること。
2) 組織に関係のある、興味を引くテーマでアイデアを書くこと。
3) ちゃんとサポートしてくれる（つまり影響力のある）聞き手を見つけること。
(コメント9への質問) 1 pagerって、自分の認知度アップやキャリアアップに役立ったの？それとも、アイデアの実現に役立ったってこと？
危機が起きた時に解決策をすぐ出せるように、普段から1ページの資料（1Pager）を書いてアイデアを共有しておくといいよ。そうすれば、問題が起きた時に君の解決策が注目されて、具体的なものとして採用されやすくなるからね。
まったくだね！これはStaff Engineerなら当たり前のことだと思ってたから、記事でわざわざ言及されててちょっとびっくりしたよ。
マニュアルなんてなかったけど、俺が経験してうまくいったことを共有して、次の（新しい）StaffやPrincipalsの参考になればと思ってさ。
うわー、俺はそんなに機能不全な会社で働いたことがないのかも。この記事の冒頭部分には全然共感できないよ。いつも上から下までオープンなコミュニケーションだったし、意見が違っても議論して納得してた。エンジニアが創業した会社だったからかな？
大手のアメリカ企業（そしてそれに倣う国々）は特に機能不全に陥りやすいんだよ。それに関する良い文献もたくさんあるしね（Moral Mazes、Bullshit Jobs、Five Dysfunctions of a Teamとか）。君がそんなシステムに巻き込まれなくてラッキーだったんだよ！
いくつかの欧州やアジアの大企業を見てきたけど、アメリカ企業のどんな機能不全よりもっとひどい場合が多いよ。しかも、現地の習慣のせいでさらにヤバいこともあるしね。
確かにディストピアの種類は色々だよね。例えば、平均的な日本の大企業はアメリカのそれよりも労働時間をすごく重視するし。俺のドイツとスイスでの経験だと、企業のMoral Mazeはアメリカほどひどくなかったな。どれを選ぶかは自分次第って感じだね。
比較的小さな会社だよ。50～100人くらい。もっと大きい会社だと全然違うだろうけど、うわー、聞くだけでゾッとするね！
ああ、確かに悲惨だよ。でも、残念ながらそういう大企業って給料がすごく高いことが多いから、結局トレードオフなんだよね。なんか魂を売ってるようなもんだよ。
大企業のVPってさ、広い目標と手段を持つもんだよね。これって色々なやり方を試せるから、必ずしも悪いことじゃないんだ。確かに無駄はあるけど、業界の変化に対応するボードの要求を満たすには効率的だとも言えるよ。
俺もスタッフだけど、転職してなれたんだ。50人規模のスタートアップでのスタッフって、結局ジュニアレベルだよ。うちの会社、新卒でもスタッフの役職だったし。
わかんない、そうかも？でも、他の現実と比べるのは難しいよね。俺は会社の株式も持ってたし、年収20万ドル以上で年末に30％ボーナス、6人のチームリーダーでフルリモート、オンコールなしだったんだ。FAANGみたいな大企業で働くのに比べたら、マイクロサービスとか分散コンピューティングの経験は少ないけど、十分挑戦的だったし、報酬も十分だったよ。もしこれがジュニアだとしても、大企業のひどい組織に巻き込まれずに済むなら、毎日でもこのトレードオフを選ぶね。
新卒がスタッフの役職だったって？それ、君の会社が間違ってただけじゃん。
俺が思うに、最高のやり方は、
・頻繁に本番環境にリリースすること（理論だけの仕事はしないこと）
・成功をリリースすること（一般的な指標で評価されるもの）
・自分の成功をうまく売り込んでくれるマネージャーかPMを持つこと
って感じかな。
だけど、それでも問題は出てくるんだ。新しいVPとかリーダーは常に何かインパクトを出したがってるからね。今のシステムを保守してるチームは「間違った考え」って見られがちで、新しいVPはAIみたいな「正しい考え」をぶち上げてくる。コードなんて本番環境にデプロイされたらすぐに「レガシー」になっちゃうし、新しいVPは未来の理論的な金儲けを約束するけど、今の地味な現実を維持してるだけじゃ勝てないんだよ。現実はセクシーじゃないし面白くない。お前はもう「旧世代」なんだ。結局、多くは「庇護」に尽きる。上のVPを成功させて、彼らが新しい会社に行く時に一緒に移れるような立場にいることだね。
君の言う通りだと思うし、もう一歩上のレベルの話もできるよ。
スタッフエンジニアとして、自分は「コードそのものじゃない」って周りに認識させることがすごく大事。コードなんて、リリースされた瞬間から「レガシー」で負債でしかないんだからね。
俺が見つけたベストなやり方は、「コードの味方」じゃなくて、リーダーシップやプロダクト、権力者たちと「対等なパートナー」として自分を位置づけること。これって、ただの「見せ方の問題」だったりするんだよ！ BOFHみたいにほとんど同じことをやってても、リーダーが君をプロダクトとインパクトを出すための「味方」として見るか、「ただ製品を作るだけ」で承認をいじめながら取り付ける相手として見るかで、全然違うんだ。
リーダーと「対等なパートナー」として振る舞うべきだって？それってユートピアみたいで、実際にはバカげてるよ。
俺がテック業界で40年以上働いてきた中で、上の人間に「対等」だなんて思われたことも扱われたことも一度もないからね。俺はチームのメンバーをできるだけ平等に扱おうとしてるけど、上の連中は俺をクビにして、最近誰かが紹介した新しい流行りの誰かを優先することに何の躊躇もないだろうさ。彼らはどんな問題についても、めったに話を聞かないし、話す機会さえ稀だよ。働いてきた全てのスタートアップや会社で、ずっとこうだったね。
良いPMを見つけるのがマジ重要！キャリアを振り返ると、ひどいPMがいるチームからはさっさと逃げるべきだったと痛感したよ。彼らが原因でチームは間違った方向に進み、マネジメントとの連携も取れてなかった。PMが変わった途端、全部改善されたんだ。本当に良いPMは人生を変えるけど、見つけるのは大変だね。
マジで同感！優秀なPMやデザイナーがいると本当に人生変わるんだ。毎日残業漬けだったのに、定時で帰れるようになるくらい違う。彼らがしっかり計画を立てて機能を売り込んでくれるから、やり直しが減るし、製品を前に進めるタスクも適切に定義できる。無駄な変更の繰り返しから抜け出せるってわけ。
だからSWEを諦めかけたんだ。俺のスキルや成果なんて、キャリアにはほとんど関係なかった。結局、自分がやってないことでも上層部に褒めてもらうことだけが大事なんだよな。それに、新人マネージャーなんかが出てくると、自分の存在感を示すのに必死で、全然仕事が進まないし。
プロモーションがデタラメな情報で決まるような会社は、さっさと辞めて別の会社に行くしかないよ。俺が話してるのは、そこまでひどくないけど、PMがチームの方向性を決めちゃうような会社だね。悪いPMがいると、チーム全体を間違った方向に導いて時間を無駄にする。うちのPMは目標から逸れてサイドクエストばっかりやらせてたから、管理職が望んでないものばかり作って、大事なことは全部やり残してたんだ。
俺に言わせれば、伝統的なトップダウンの会社は全部最初から壊れてるってことだね。実際に、本当に事実に基づいたマネジメントなんて見たことも聞いたこともないよ。多階層のマネジメントでは、技術的な理解が乏しい人たちとの伝言ゲームになるから、現場の真実を正確に伝えるのは無理なんだ。だから、事実に基づいたマネジメントは理論上の理想に過ぎない。実際はめちゃくちゃ難しくて、みんな楽するから「事実」は完全に歪んでしまうんだよね。
オーストラリアにいるけど、まだ壊れてない会社に出会ったことがないんだよな。
もっとコメントを表示（2）
どこを見ても「臭い」と感じるなら、自分の靴の裏を見てみろってことさ。完璧な会社なんてないし、完璧なチームもない。誰もが魔法のように正しいことを知ってるわけじゃないし、完璧なビジョンを持ってるわけでもない。たとえ最高のチーム、最高のビジョン、最高の優先順位でうまくやっても、世界は変わるし、どれか一つは間違ったものになるんだ。
全員で30人未満の会社で働いてみたことある？俺の経験だと、そういうとこが一番良かったね。
どの会社も何かしら壊れてるよ。ただ、多くの会社は許容できる範囲だったり、むしろまともな壊れ方をしてるだけなんだ。
ねえ、もしみんなが俺の思う通りに会社を運営してくれたら、みんな幸せになるのになあ、って思うんだよね。
OPも私と同じで、アメリカ企業のリモートワーク案件を探してるみたいだな。
「未来の約束…競合できない」って表現、マジ好き。約束が毎回不発でも、輝かしい未来って言葉には勝てないんだよな。あるあるだわ。
「VPは頻繁にリリースしろって言うけど、そいつ自身は理論的な未来の富を約束してて、それに俺らは勝てない」って。なんでVPが理論的な仕事するのは良くて、俺らがするのはダメなんだ？矛盾してね？
VPは「大きな変化」のために政治的な後ろ盾を得て、リソースを投入して理論だけの話に終わらせないようにするんだよ。だから立場が違うんだ。
だって、それが彼らのジョブディスクリプションであって、お前の仕事じゃないからな。それだけの話だよ。
スタッフソフトウェアエンジニアで、ジョブディスクリプションに理論的な仕事は含まれてないのに、アウトプットが理論的なことばかりだったらどうする？それは政治的な問題じゃなくて、速攻クビになるレベルだろ。このアドバイスって、理論的な仕事はできるけど、やっちゃダメって前提に立ってるよな。
理論的な仕事は知らんけど、毎日リリースってのは聞くな。「頻繁に」がどれくらいか知らんけど、毎日リリースしてるところもあるらしい。でも、毎日リリースって微妙じゃね？一日で実用的なものなんて出せるか？会社の収益プロジェクトやってるけど、それが一日で終わるなら年4日しかエンジニアいらなくなるから、俺はクビだよ。あれはただの「見せかけ」の指標だろ。
全くその通りだけど、縁故主義はもっと上まで行ってる。奴らは小切手を通過させるために言いたいことを言ってるだけ。実際に成功したビジネスモデルを発明したエグゼクティブなんて、いまだに会ったことないわ。
ああ、奴らは成功したビジネスモデルを発明してるよ。ただし、それは役員たちにとっての成功だ。C-suiteの考え方って、エグゼクティブにとっては成功だけど、他の全員にとってはガンみたいなもんだからな。
エンジニアによくある「大規模なリファクタリングしたのに誰も評価してくれない」って不満。俺も数ヶ月かけてデータパイプラインを完璧にした友人の話を聞いて思ったんだ。エンジニアとしては価値ある仕事だけど、PMとかEMからしたらどう？PMが「エンジニアリングドキュメントを箇条書きにした」って言ってるようなもんだろ。「それが会社にどう影響するの？」ってなるよな。非技術者には、インパクトのある仕事とそうじゃない仕事の区別は難しいんだ。だから、非技術者にも伝わるように、事前に何をやるか明確にすることが大事。俺も昔、テスト導入をマネージャーに理解してもらえなかったけど、ひどいSEVが起きたときに「テストがあれば防げた」って言ったら、やっと価値を理解してくれたよ。今じゃみんなテストの価値を分かってる。
同意だね！大事なのは、何かを優先させたい時、優先順位を決める担当者にそれが意味あるって納得させるのが君の仕事だってこと。一番簡単な方法は、みんなが話してるのと同じ言語で話すこと。プロダクトマネージャーはたいていお金（ドルとかユーロとか）で話すから、テストカバレッジの向上とか技術的な目標が、開発時間200時間かかるけど年間400時間削減できるとか、サポートチケットの発生率を15%減らせるとか、将来のビジネスシナリオXをサポートできるようになるとか、そういう具体的な見積もり（大体の範囲で全然OK）を出せば、うまくいく可能性がグッと上がるよ。俺のお気に入りの”裏技”は、テックデットの作業を”技術的な作業”としてプッシュしなくても、PMがビジネス視点から見て納得して、むしろ積極的にロードマップに入れてくれるようにフレーム化すること。これも時間が経つとどんどん楽になるんだ。最初は少し懐疑的に見られるかもしれないけど、数ヶ月、数年にわたって正確な見積もりと結果を出し続けていれば、ステークホルダーとの信頼関係が築けて、前は何度も会議して説得してたことが、たった10分の会話で済むようになるよ。
確かにね。でも”コスト削減”って会社を勝たせるものじゃないし、キャリアを築くものでもないんだ。だから当然だよね。もし新しいライブラリをXドルかけて構築すれば、エンジニアリングがY%効率化されて、それが新しい製品を3つローンチして売上を倍増させることに繋がるって示せたらーそれこそが素晴らしい提案だよ（君の言う”X未来のビジネスシナリオ”ってやつだね）。現在の製品のコスト削減は、会社が次にどこへ向かうべきか全くわからない場合にだけ役立つものだよ。だって普通、今の製品は2年後にはなくなってるんだから。精製所みたいに、長期間安定した生産をしている会社で0.5%の節約がとてつもなく大きい、なんて場合は別だけどね。これは、ひどいコードベースとか、変な言語で大規模なアプリケーションを書くことについて、みんなが見落としがちな点なんだ。もしそのアプリケーションをリリースできて、5年後も利益が出てるなら、それはもうとてつもない成功だったんだよ。”正しい言語じゃなかった”って反論するかもしれないけど、それは間違いだ。だってすでに大成功してるんだからね。ドキュメントをきれいにすることについても同じだよ。
反論するつもりはないけど、俺のコメントに返信したつもりかな？俺はコスト削減の話はしてないよ。俺が言ってるのは、今週10時間使って投資すれば、毎月10時間分のキャパシティ（収益につながる新機能開発能力）が追加で手に入るってことで、これはよくあるお得な話なんだ。正社員のエンジニアの文脈では、”時間削減”って実際には、エンジニアの給料を減らすんじゃなくて、浮いた時間を製品の新機能開発に再投資するって意味だからね。同じように、エンジニアがサポートに割く時間が減れば、その分もっと機能開発に時間を使えるってことなんだ。
君のコメントには「200開発時間かかって、400開発時間節約できる」ってあったよね。俺はこれが正しい視点であることは稀だって主張したいんだ。それは「今」の200時間であって、会社にはそのための予算がないことが多い。そして400時間の節約は、もし星が揃えば2年後かもしれない。予算も時間枠も違うし、君の部署の責任でもない。理論的にはそうかもしれないけど、ほとんどのビジネスでは違うんだ。この今の200時間は投資だよ。この400時間っていうのは、もしかしたら貯蓄であって利益じゃないんだ。利益になる新しい製品に400時間分の投入を可能にするかもしれないけど、それなら単にその利益を生む新製品のための予算を要求すればいい。どこからそのお金が来るかなんて、君の給料レベルをはるかに超えてる問題だし、笑えないよ。もし400時間を投入するアイデアが価値があるものなら、会長が資金を調達するだろうね。そのアイデアを経営陣に持っていけばいい。それなら歓迎されるだろうね。
まとめると、節約と新製品は貸借対照表の同じ部分から来るものじゃない。彼らは会社の未来に同じように影響を与えるわけじゃないんだ。無駄になった400時間は、今後数年の見積もりですでに考慮されていて、実質的にすでに償却済みなんだ。もう関係ないってことだね。個人のエンジニアにとって、自分の3年間の仕事が財政的にはもうとっくに忘れ去られてるって考えるのは楽しくないかもしれないけど（笑）、基本的にはそうなんだよ。
これは何段階か上の経営レベルの人たちが、例えば40年先の主流のデータベースパッケージやコンパイラといったものを本当に考えているなら、正しい視点かもしれないけど、ほとんど誰もそんなことはしない（第一近似としてはね）。
また、ごくわずかな違いが大きな影響を与えるような状況（精製所とか）では良い視点でもあるね。
それでも、2年でなくなる予定がないほとんどの会社には、方法論部門やワーキンググループがあるんだ。プロセスを改善しようと努力している人たちがいる。彼らにはそのための予算があるんだ。そのアイデアを彼らに持って行けばいい。なんなら彼らの予算でパートタイムなりフルタイムなりで働き始めてもいい。でもこれはまた別のグループ、ミッション、予算だということを理解した上でね。それは「ここの200時間と引き換えにあそこの400時間」ではないんだ。そしてこれは非常に技術的なグループであって、CXOへの道筋ではないよ、一時的な勤務は別としてね。
これには同意するけど、類推で反例も思いつくよ。例えば建設プロジェクトで、安全システムを点検・維持するためにたくさん時間を使って、誰かを重傷させたり殺したりする事故を防いだとするよね。でも管理職は「何もしてない」と思って、その努力を報いないってのは、よくある問題なんだ。ROIとして数値化できないと利益とみなさないなんて、マネジメントの大きな失敗だよね。そして、それが本当に生死に関わる状況なら、俺は道徳的な失敗でもあると思ってるよ。実際、このシナリオは想像をはるかに超える話じゃない。今のボーイングがまさにそうだよね。
うん、俺はスタッフにはなれない運命なのかもしれないけど、何でもかんでも四半期ごとに動く会社全体の目標指標に紐付けないと見えないっていうのが、本当に嫌なんだ。価値があって、会社が絶対にやるべきことでも、四半期という時間軸では簡単に測定できないことってたくさんあるからね。
これは「マクナマラの誤謬」としてよく知られてるよ。
君が説明しているのは、価値を聴衆が理解し評価する言葉で伝えるってことだよね。これは本当にセールススキルで、ほとんどの開発者は経験が少ないか、そう認識してない。良いマネージャーならここで助けられるし、強く連携したスタッフデベロッパーとエンジニアリングマネージャーなら、多くのことを成し遂げられると俺も同意するよ。それが俺の経験だし、こういう風に働いてくれる開発者にはいつも感謝してるよ。
もし君のマネージャーがそう考えて、リファクタリングの価値を理解してないなら、すでに負けてるよ。彼らに説明しようと試みることはできるけど、もし彼らがそういう仕事をそのように認識しているなら、それは君がソフトウェアエンジニアリングを理解してない会社で働いている証拠だね。もちろん、新機能は作らないといけないし、バグも修正しないといけない。それらは常に優先事項だ。でもリファクタリングも、ソフトウェアを保守可能な状態に保つ上で同じくらい重要なんだ。なぜなら、まさにそれらが新機能をより速く、より効率的に、そしてより堅牢な方法で構築できるようにするからね。
例えば一流レストランのシェフを考えてみてよ。手を洗うのは当たり前で、お客様に糞便性細菌で感染させるまで、レストランの経営陣に石鹸に投資する（衛生には時間がかかる、追加のお客様をサーブできる！）よう説得する必要なんてないよね！プログラマーにとってキャリアの節目の一つは、自分の職人技の基準を自分で設定できることなんだ。成功するSWEっていうのは、そういう教育が必要ないチーム、つまりエンジニアリングの衛生が呼吸みたいに当たり前なチームに雇われた人だよ。
