企業のソフトウェアエンジニアリングの仕事はパフォーマティブですか？

技術的成果と企業官僚主義の間の緊張

企業のソフトウェアエンジニアリングは、実際の技術的貢献と大規模組織を乗り切るために必要とされる「パフォーマティブ」な行動との間に認識されたギャップをしばしば生み出します。会議や1対1のミーティング、官僚的プロセスの増加を時間の無駄と見るエンジニアもいれば、これらの要素は規模に応じた安定性と調整を維持するために不可欠であると主張する人もいます。

多くのエンジニアは、大企業、特にFAANG規模の企業において、労働力のかなりの部分が製品の目標ではなく組織内部のニーズに応える仕事に従事していると主張しています。この現象は以下のように特徴付けられます：

• 努力のパレート分布: 複数の貢献者は、少数の「オールスター」が技術的負荷の大部分を担うことが多く、他の人は「社会的怠惰」に従事したり、単に可視性を得るための行動を取っていると指摘しています。
• インセンティブの不整合: 企業がコード行数（LOC）やプルリクエスト数、オフィスでの滞在時間といった不完全な指標に依存すると、従業員は高インパクトな仕事に集中するよりも、これらのKPIを満たすために「ゲームをする」ことがよくあります。
• 「目的工場」の台頭: 大規模組織は最終的に「目的工場」になり、実際の成果に関係なく従業員に重要感と役割の正当性を提供することが主たる製品になると主張する人もいます。
• 官僚的捕獲: 「ポーネルの官僚主義の鉄則」を引用し、組織自体に献身する者が最終的に組織の目標に献身する者を支配し、結果の提供よりも規則遵守の文化が生まれると示唆する貢献者もいます。

組織的「余裕」の擁護

逆に、見かけ上「パフォーマティブ」なものが実際には大規模企業にとって必要なインフラであるという強力な反論があります。

• 調整の必要性: 企業構造の支持者は、1対1のミーティングや管理のオーバーヘッドは無用ではなく、開発者の声を聞き、パフォーマンスが低い者を管理し、小規模チームでは無視できる複雑な依存関係を調整するために重要であると主張します。
• 組織的余裕: システムの「余裕」はバグではなく機能であると主張する人もいます。余剰のキャパシティがあれば、重要人物が退職したり休暇を取ったときに組織が停止するのを防げます。
• 規模のコスト: 製品が成熟すると、迅速な機能開発の必要性は低下し、作業は「ノブ回し」や最適化、リスク緩和へとシフトします。このシフトにより、グリーンフィールド開発に慣れたエンジニアは仕事のインパクトが小さく感じることがあります。
• 専門人材のROI: 一見「無駄」な役割（例：ソーシャルメディア企業のカーネル開発者）でも、数百万ユーザーに影響する重要なパフォーマンスボトルネックを一つ解消できれば、莫大なROIをもたらすことがあります。

視点の統合

この議論は、ソフトウェアエンジニアリングにおける価値の測り方に関する根本的な意見の相違を浮き彫りにしています。一方は価値を動作するコードの直接的な提供と見なし、もう一方は価値を組織の持続可能性と予測可能性と見なします。

"誰かに関する物語は事実よりもはるかに強力です。彼らの仕事は政治的に振る舞い、1対1のミーティングで他のマネージャーや個人貢献者に物語を押し付けることです。"

"組織を相互に組み合わさった部品の機械とみなすと、人々が価値を付加していないことに過度に驚くかもしれません。大企業を中産階級を満足させるための福祉システムのように理解しようとすれば、上司や同僚の行動が理解できるでしょう。"

最終的に、合意は大企業に非効率が蔓延しているものの、それはしばしば成長の副産物であることを示唆しています。仕事の「パフォーマティブ」な性質は、数千人の従業員をコントロールするために経営陣が作り出したインセンティブ構造への対応であることが多いです。