ただ「ダメです」と言うエンジニアはZIRP現象だった
(seangoedecke.com)- ただ「ダメです」と言うエンジニアは、コード変更を基本的に止め、複雑な機能を遅らせ、できるだけコードが少なく書かれるようにするシニアの類型である
- ZIRPの時期には、低金利と採用拡大のおかげで生産性の損失はそれほど重要ではなく、過激な技術提案を止める役割が企業にとって有用だった
- 金利上昇後、技術企業はエンジニアの**5〜20%**を解雇し、株価より売上を重視するようになって、「ダメです」の代わりを担う防波堤は減った
- LLMはAI生成PRや十分実用になるコードによって圧力を強めたが、中核的な変化はAIではなくZIRP終了による経済的インセンティブの変化である
- この役割は消えないが、純粋なエンジニアリング領域のほうにより適しており、2010年代より限定された範囲と低い可視性を受け入れる必要がある
「ただ『ダメです』と言うエンジニア」の役割
- ただ「ダメです」と言うエンジニアは、シニア・スタッフエンジニアの間に存在する類型で、機能開発を遅らせ、複雑さを増す変更を止め、できるだけコードが少なく書かれるようにする役割に近い
- 対極にいるただ「できます」と言うエンジニアは、素早く動くことを重視し、コード変更を基本的に承認し、MTTRをMTBFより重視し、多くのコードをデプロイする傾向がある
- ほとんどのエンジニアはこの両極端の間にいるが、ここで焦点を当てるのは、「ダメだ」という役割と強く自己同一化しているエンジニアたちである
- AI時代には、ジュニアエンジニアのPRだけでなくAI生成コードも大量に却下しなければならず、ときにはマネージャーやVPが作ったコードで、政治的に断りにくい状況も生じる
- キャリアで初めて基準を下げて「はい」と言えという圧力を強く受けているが、核心的な原因はAIそのものよりZIRPの終了にある
ZIRPが生んだ環境
- ZIRPは「ゼロ金利政策」の略で、2008年から2022年の間、銀行が企業にほぼゼロに近い金利で金を貸していたソフトウェア開発の時代を指す
- 投資家は借りた金をほぼ何にでも投じ、技術企業は低リスク・高リターンが期待できるプロジェクトのためにエンジニアを継続的に雇うインセンティブが大きかった
- 成功した企業はエンジニア数を数十人から数千人まで増やし、周辺的なオープンソースプロジェクト、終わりのない技術移行、別言語への書き換えのような仕事を任せた
- ソフトウェアエンジニアにとっては交渉力が大きく、ほぼどんな仕事をしても高い報酬を得られる時期だった
- 経営陣はチームがあまりに速く拡大して細部に気を配りにくく、エンジニア数が増えること自体が株価にプラスだったため、多くの活動を大きな問題にしなかった
- エンジニアが多すぎて自由に動き回るとシステムが管理不能になりかねず、このとき「ただ『ダメです』と言うエンジニア」が企業にとって有用になった
なぜZIRP期には「ダメです」に価値があったのか
- 生産性損失が大きな問題ではなかったため、会社のエンジニアの半分が変更を提案しては却下されるループに陥っていても耐えられた
- このやり方には、エンジニアがビジネスの中核システムに影響を与えないようにする効果もあった
- 技術的自由に酔って、自作データベースへ移行しようといった過激な提案をする5%のエンジニアを抑えるのにも役立った
- 技術基準が非常に高い会社だという評判は採用にプラスで、ZIRP期にはあらゆる技術企業が常に採用中だった
- 「ジュニアはコードをたくさん書き、シニアは少し書き、スタッフはコードを削除する」という言い回しは、専門家がほとんど動かなくてよいという魅力を与えるが、必要なときにはスタッフエンジニアも大量の動くコードを非常に速く生み出せなければならないという点で正しくない
ZIRP終了後の変化
- 銀行が金利を上げると、ほぼすべての技術企業は即座にエンジニアの**5〜20%**を解雇した
- 株価を押し上げるために肥大化したエンジニア組織を維持することは、もはや収益性がなく、企業は実際に金を稼がなければならなくなった
- ここで「金を稼がなければならない」とは、必ずしも利益を出すという意味ではなく、少なくとも売上を持ってこなければならないという意味である
- 何百人ものエンジニアに収益性のない仕事をさせていたと認めるのは、解雇の公的説明としては都合が悪かった
- ZIRPの終了はChatGPTの台頭とおおむね重なったため、企業は解雇をAIの力によるものだと説明できた
- 「この変革的な新技術のおかげで、半分のエンジニアで10倍の価値を届けられる」というメッセージは強く響くが、本当にそうなら、なぜエンジニアを維持して20倍の価値を届けないのかという疑問が生じる
集中度を高めた企業と減った防波堤
- 技術企業はこの20年で最も集中度を高めており、いまやランダムなことを大量にやるより、金を稼げる新しい能力や機能を必死に追っている
- この新しい環境は、ただ「ダメです」と言うエンジニアにとって積極的に不利である
- 以前はこうしたエンジニアが経営陣の暗黙の支援を受けており、誰かが不満を言っても、「あのエンジニアが何をしているかは分かっているし、ダメだと言ったなら信じる」といった形で済ませられた
- いまやその支援は消え、同じ行動が経営陣から批判されたり、積極的に覆されたりしている
- もっとチームプレイヤーになれとか、「はい」と言える方法を探せとか、主要な意思決定でもはや助言を求められない、といったことが起きる
- 2022年以前には報われていた行動が低評価につながっており、経済的インセンティブの変化のあとに文化の変化が数年遅れて追いつくこともある
- この変化はAIに依存しておらず、たとえLLMがこの10年に台頭していなかったとしても、企業はエンジニアを解雇し、「ダメです」を担当していたエンジニアは、なぜ同じ行動が罰せられるのか戸惑っていただろう
AIが加えた衝撃
- もしZIRPが終わっていなければ、LLMは「ただ『ダメです』と言うエンジニア」に強い大義名分を与えていたかもしれない
- AI支援コーディングを公にも社内的にも疑いにくい企業は、AIコードの津波が会社を覆わないようにするため、こうしたエンジニアに大きく依存していたはずだ
- 実際にはLLMは、既存の傷にさらに侮辱を加える役割を果たしている
- 以前なら止められていたAI生成PRがマージされるのを見なければならず、自分でもそうしたツールを使えと求められる
- さらに悪いことに、AIツールはおおむね動く
- まだ何らかの種類の災厄を引き起こしているわけでもなく、コードは多少きれいさに欠け、理解しにくさも少しあるが、十分使い物になる
- とくに企業が新しい試みをたくさん行い、失敗したものを捨てる環境では、「十分に良い」コードが通用する
- 最近インシデントが増えたと見ていても、実際には見当違いかもしれないし、速度向上や解雇のような、ZIRP終了に伴う他の要因のほうが主要因かもしれない
- ただ「ダメです」と言うエンジニアは、生計だけでなくアイデンティティの脅威にも直面している
- 自分の技術的役割が、技術産業の非常に特殊な経済環境に依存していたことを受け入れるか、あるいは終末がすぐそこだと言い続けるかという状況になっている
純粋なエンジニアリングと不純なエンジニアリング
- ただ「ダメです」と言うエンジニアが消えるわけではないが、もはやすべての技術企業にうまく適合するわけではない
- Pure and impure software engineeringで区別される純粋なエンジニアリングとは、コンパイラや言語ランタイムのように、範囲が明確で主に技術的な目標を持つ仕事である
- 不純なエンジニアリングは、成功するか確信できない新機能の試行のように、範囲が曖昧で顧客主導の目標を持つ仕事である
- ZIRP期には、技術企業はReact)のような純粋な仕事をはるかに多く行っており、不純な仕事まで純粋な仕事のように扱う傾向があった
- ただ「ダメです」と言うエンジニアは純粋な仕事に非常によく合う
- 純粋なコードベースには、はるかに高い品質基準が必要で、遅い開発サイクルにも耐えられるからだ
- ほとんどの技術企業は、いまでも中核インフラのような領域で何らかの形の純粋な仕事をしている
- この仕事は不可欠だが、巨大なエンジニアリングチームを必要とせず、スポットライトを浴びることもまれである
- ただ「ダメです」と言うエンジニアであり続けたいなら、こうした役割へ移るべきだが、2010年代よりも限定された範囲を受け入れなければならない
議論と補足された視点
- lobste.rsやRedditでは、AIコードの影響は時間がたって初めて見えるのだから、「おおむね動く」と断言するのは早すぎるという批判があった
- 「まだ判断が早い」という反論は間違いになりにくいが、AIコードが直ちに致命的ではないという点は明らかに見える
- ただ「ダメです」と言うエンジニアという類型が、ZIRP以前の数十年にも存在していたという反論もあり、Linus Torvaldsが例に挙げられている
- この類型そのものをZIRPが作ったわけではないが、ZIRPがこの役割のニッチを人為的に広げ、いま再び縮小したという見方である
- 動的言語の利用や未成熟な観測性・機能フラグのツールが、この役割のニッチを生んだという反論もあった
- Hacker Newsでは、この理論にはより堅固な証拠が必要だという見解も複数出ていた
- この見方は個人的経験という小さな窓に基づいており、ZIRP前後で産業がどうだったかという一般化は人によって異なりうる
- これを検証するには、2010年と2026年にシニア以上のエンジニア数百人を調査し、週に何回「ダメです」と言ったか、その拒否がどれくらいの頻度で覆されたかを尋ねればよい
- ZIRP前後のどちらでも「ダメです」と言うことは不可欠だが、ZIRP以後は経営陣がその能力を急速に身につけたことで、代わりにそれを言ってくれるエンジニア集団の必要性が減ったという違いがある
1件のコメント
Hacker Newsの意見
コードは負債である。エンジニアが「ノー」と言うのは、主観的にコード品質へ執着しているからではなく、複雑さを減らそうとしているからである
最近の経営陣は「品質」という言葉を誤解していることが多い。品質とは、エンジニアチームがコードを容易に追加・修正できることまで考慮しつつ、製品を可能な限り速く低コストで作るための適切な努力量を意味する
よりよい説明はこちら: https://www.nair.sh/guides-and-opinions/communicating-your-e...
その人が何をなぜ行ったのかを硬直的なルールとして成文化しようとする試みは、結局失敗せざるを得ない
この手の 机上の経済学 の問題は、どちらの側にも理屈を作れてしまうことだ
「ゼロ金利時代の終わりと、なんでもノーと言うエンジニアの台頭」とも言える。資本コストが高くなったのだから、企業はその金をより賢く使う必要があり、不要なことに浪費しないために ノーと言うエンジニアの判断 がいっそう必要になる
読み進めるほど、「もっともらしい用語は揃っていて、ZIRP時代だのなんでもノーと言うエンジニアだのと洞察があるように見えるが、掘り下げると当時のソフトウェアエンジニアリング現場での自分の経験とまったく一致せず、今AIで起きている大きな変化もきちんと診断できていない」と感じた。つまり 流行語まみれのたわごと に聞こえたので、記事自体に低評価ボタンがない代わりにコミュニティが指摘してくれるのはありがたい
AIプロジェクトが失敗しても、十分早く失敗して別のことに移れれば問題ない。最初から正しくやることが重要になるのは、初期投資の大きい長期プロジェクトだけだ
「会社のエンジニアの半分が、延々と変更を提案しては却下されるループに絡め取られていても完全に問題なかった。どうせ生産的である必要はなく、そのやり方ならビジネスの中核システムに影響しなかったからだ」というのも、一つの見方ではある。かなり シニカル だ
振り返ればシニカルに聞こえるが、当時は同じ事実のまとまりを、もっと人の感情を害しない形で別の言い方にしていた
FacebookでMetaverseをやっている人が、新しいビジネスモデルを試作する中核人材なのか、ただ忙しいふりをする仕事をしているだけなのかは、後になって初めてはっきりする
かなり過激な解釈だ。ZIRPが終わって集中度が高まったのなら、自然な結論は、より少なくではなく より多く断るべき ということではないか？
ZIRPがあらゆる偽の仕事を生み、その偽の仕事を統制するための階層まで作ったと主張するには、かなり無理なこじつけが必要だ
「なんでもイエスと言うエンジニア」と「なんでもノーと言うエンジニア」という区分、そして MTBFよりMTTRを優先 する観点は気に入った
自分は明らかに「なんでもイエス」寄りだが、悪いアーキテクチャの選択は後から直すのが非常に苦痛になりうるし、機能はリリース前よりユーザーがついた後のほうがはるかに直しにくくなる、という留保もある。だから少しは「なんでもノー」、少なくとも「まず少し考えよう」寄りでもある
「なんでもイエス」と「なんでもノー」のバランスは、プロジェクトに大きく依存する。金融や医療ならデフォルトが「ノー」のほうがよいかもしれないが、突飛なスタートアップのアイデアならYOLOだ
整理する時間を求めることは、実際には ノーと言うこと と同じだ。開発責任者はその権限を持つべきであり、実際に使うべきでもある。決して使わないのなら、実質的にはその権限がないのと同じだ
代案もなく「ノー」とだけ言うエンジニアになってはいけない。それは良いエンジニアではなく、怠けていながら有能そうに見せたいだけだ
エンジニアは、レガシーのせいで理想的ではなくても必要な解決策を出すことが多い。そして、いや、システム全体を書き直して「正しいやり方」にすることはできない。「ノー」と言ったり、その解決策が理想的でないと指摘したりするだけで 超知能の天才 になれるわけではない
ビジネス側の人たちとの会議では、コードが分かるという理由で威圧的に振る舞っていたし、最悪だったのは、提案に同意しないときに 代案をまったく出さなかった ことだ。一緒に働きにくかった
この記事の言うZIRP人間とは、その人のことなのかと思ってしまう
LLMやエージェントに足りない点があると、改善を待つよりも基準を下げようという流れがある。要するに「MTTRに集中しろ」という話だ
コードがひどいのか？ なら読まなくていい、レビューしなくていい、ボトルネックになっている人をループから外せ、という物語があちこちに広がっている
この技術はかなり有用なので、症状だけに対処するのではなく、ツールとうまく協働する方法や、それに合わせたプロセス改善に集中してほしい
できることに終わりはないが、実際のプロジェクトに使う時間と、そうした改善に使う時間をどう配分するかが問題だ
「エンジニアが多いほど株価に有利だった……銀行が金利を上げると……株価をつり上げるために肥大化したエンジニア組織を維持することは、もはや採算が取れなくなった」とあるが、ソフトウェアエンジニアの人数と株価を結びつけるメカニズムとして知られているものはあるのか？ それとも単なる経験的な観察なのか？
「以前ならジュニアエンジニアが手で書いたPRにノーと言えば済んだが、今ではAI生成コードがあふれていて、その一部は政治的に拒否しづらいマネージャーやVPが作ったものだ」というのだから驚く
大手テック企業で働いていたが、InstructGPTなどが出る前に業界を離れたので、社内でのLLMによるコード生成を経験したことがない。本当にそんなことが起きているのか？ 上級管理職やVPがLLMで作ったコード変更を提案してくるのか？ 自分には耐えられそうにない
政治的な負担も本物だ。単に「ダメです」とは言えないのに、何をしているのかもよく分からず、質問にも答えられない人が出してきた2万5千行のPRを、意味のある形でレビューするのはかなり難しい
公平のために言えば、彼は会社の初期にliquidやShopifyの多くの部分を自ら作っていたので、経験のない人ではないが、それでもやはりそういう話ではある
検証が難しい仮説に見える。何かを成し遂げようとしている会社なら、どんな意思決定に長期的なコストが生じるのかを知らせ、優先順位付けを助ける人がいるのは、当然理にかなっているのではないか？