Egolessエンジニアリング
(egoless.engineering)エゴを排したエンジニアリング: 教訓と洞察
序論
- 技術業界では、エゴと地域主義（派閥主義）がチームワークを妨げる主な要因として作用する
- エンジニアリングチームをより効率的で協力的にする方法を考える中で得た洞察を共有する
責任分担のジレンマ
- 社員が2人しかいなくても、業務の分担は不可欠である
- しかし、その分け方は即時的にも長期的にも影響を及ぼしうる
- 多くの企業はこうした問題を深く考えていない
コンピュータサイエンスの現実
- 多くのコンピュータサイエンティストは、自分が数学的な抽象作業に関わる学問の世界に足を踏み入れたのだと後になって気づく
- この初期の衝撃のために、学んだことをコンピュータ以外の分野へ適用しようとしない姿勢をキャリアの大半にわたって示すことが多い
- 職場環境についても技術的アプローチと同じくらい深く考えれば、改善の可能性がある
組織における病理と経験
- 成功した会社であっても組織の病理を避けるのは難しく、そこから学ぶことができる
- キャリア初期を過ごしたあるスタートアップの事例:
- 会社がまだ小規模な初期段階だったにもかかわらず、すでに過度に官僚化した構造を採用していた
- Webリクエストを高速化するという誤った理論のもとで「Pythonミドルレイヤー」を追加した
- 結果的にネットワークホップが増え、性能は低下した
- ひとつの機能をリリースするには、複数の役割の間で複雑な協力が必要だった
- データベース担当者はDDLの作成とストアドプロシージャの開発を担当
- Python開発者は非効率なミドルレイヤー作業を担当
- PHP開発者はフロントエンドコードを作成
- この分業構造のため、2年間まったく新機能をリリースできなかった
- 結果
- 非効率な構造とワークフローの帰結として、全社員が解雇された
- 私は違った。不満を表明したおかげで生き残った
大規模企業における役割分化の問題
- 背景: 従業員1,000人超のB2B製品企業で勤務
- 当初は、役割が明確に分かれた機能別チーム（Feature Teams）と共通サービスチーム（運用、DBAなど）の構造を採用していた
- 当初は一般的な構造に見えた
- 時間が経つにつれて役割が過度に細分化され、非効率性が増大した
- 「Release Manager」という新しい役割を追加してリリースを管理した
- その役割を追加する理由は明確でなく、組織構造はますます複雑になっていった
- 問題事例:
- フロントエンドエンジニアはフロントエンド作業のみ、バックエンドエンジニアはバックエンド作業のみを行うよう制限された
- この分離は辛うじて成り立っていたが、セキュリティチームがあらゆるセキュリティ作業を一手に担うという方針は深刻な問題を招いた
- 結果: 役割を作業そのものと同一視することで、組織効率が損なわれた
- チーム間の協力不足と業務の重複が生じた
分散した製品ポートフォリオと監督構造の欠如
- 主にネイティブクライアントアプリケーションを開発する会社で働いた
- 当初は成功した主力クライアントアプリケーションがあったが、2020年代には分散し一貫性のないプロジェクトが並行して進められていた
- 製品ポートフォリオ管理の問題点
- 製品全体に対する監督構造が弱い
- 技術スタックや意思決定について、製品間の調整がまったく行われていない
- 各製品チームは独立してCEOに報告し、CEOは調整の努力を払わない
- 共通の運用機能を構築しようとした試み
- 運用グループがアーキテクチャ決定プロセスに関与していなかったため、困難が生じた
- 運用チームは、過去に開発チームが使っていた数百のサービスの管理に追われ、重要な意思決定に参加する時間がなかった
- これは組織的非効率の典型例といえる
[組織問題のパターンを一般化する]
パターン1: 役割と作業の混同
- 新しい業務のために新しい職務記述を作る傾向がある
- 例: AI関連の業務を既存のエンジニアが処理できるにもかかわらず、AIエンジニアという新しい役割を新設する
- これは組織内の対立を引き起こし、既存メンバーのモチベーションを弱める可能性がある
- こうした過度な役割分離は不要な官僚主義を招く
パターン2: DevOps革命の不完全な浸透
- 多くの会社が「DevOpsを導入した」と主張するが、実際には分業と対立が依然として存在する
- 運用チームと開発チーム、あるいはSREと開発チームの明確な境界は協力を妨げる
- DevOps本来の目的は、協力と共感を通じて境界を取り払うことだが、現実にはめったに実現されない
パターン3: 厳格な業務分業の限界
- 業務を細分化して専門化することは、リーダーには当然のように見えるかもしれない
- 例: AI業務はAI専門家、運用業務は運用担当者に専任させる
- しかし、この構造はボトルネックを生む
- 追加されたエンジニアが新しい作業を生み出して速度を上げようとしても、結果的に分析待ち時間は非線形に増加する
- データサイエンティストや分析リソースが限界に達すると、全体プロセスが遅くなる
パターン4: 誤った組織構造は追加作業を生む
- 組織の境界が不明確、または誤って設定されていると、不要な作業量が増える
- 例: セキュリティチームがすべてのセキュリティ問題を担当し、セキュリティチケットキューが発生する
- 開発チームはセキュリティを考慮せずに作業を進め、結果としてセキュリティ作業が増える
- これは短期的には見過ごされるかもしれないが、長期的には深刻な問題へと発展する
パターン5: 人間の根深いバイアス
- 自分の役割を過大評価し、他人の役割を過小評価する傾向がある
- サーバー作業は「技術的ではない」と誤って判断する人もいる
- 逆に、プロダクト作業のほうが技術的でないとみなすケースもよくある
- こうした態度はチーム間の信頼を弱め、協力を妨げる
- 「優秀だが独善的な人物」は、システム的観点からは実質的な価値を提供できない
- リーダーや組織は、こうした態度を「賢い」「価値がある」と誤って評価しがちである
[派閥主義とエゴ]
- 派閥主義（Parochialism）とエゴ（Ego）は、組織内の主要な非効率の原因である
- 派閥主義: 他人の領域に踏み込もうとしない態度、あるいは好奇心の欠如
- エゴ: 仕事への誇りとして肯定的に働くこともあるが、縄張り意識や他者の能力の過小評価といった否定的な形で現れることもある
- こうした本能的な行動は共感の欠如を招き、協力を妨げる
より良い事例: 成功したエンジニアリングチームの経験
- かつて在籍したあるスタートアップでは、水平的に分断された「領地（fiefdom）」構造を単純化し、より小さなチームへ再編した
- DevOpsを本気で導入したリーダーたちが障壁を取り払い、協力を促進した
- 約2年間の「創造的破壊」を通じて、すべてのメンバーが多様な業務に参加した
- その結果、インフラの安定性とソフトウェアリリース能力が回復した
- 組織再編後、エンジニアリングチームは時間と自律性を確保した
- それを土台に、チームの追加能力をどう活用するかを議論した
提案1: 大規模リファクタリング (Proposition 1: Boil the Ocean)
- チームはしばしば余剰リソースを使って、嫌っている部分を全面的にリファクタリングする
- しかしこれはすでに試された方法であり、人気がなかった
提案2: 「自己顕示」活動 (Proposition 2: Dress Like Big Dorks)
- チームの余剰時間を使って、チーム文化を強調するグッズ制作などを試みた
- しかし、これは主要戦略としては適していなかった
- 決定的な出来事: デザイナーのビルドエラー
- ある夜中にデザイナーがビルドを壊し、チームはそれを復旧しなければならなかった
- 当初は、デザイナーとコーダーの役割をより明確に分けるべきだという意見が出た
- しかし、チームのある人物がデザイナーにデプロイキーを直接渡すという大胆な決断をした
- 結果:
- デザイナーがコード作業に参加するようになり、協業レベルが向上した
- チームは監視やテストスイートなどを構築し、安全に作業できる環境を整えた
- 作業効率と生産性は大きく改善した
提案3: 他チームのエンパワーメント (Proposition 3: Empower Everybody Else)
- チームの余剰リソースを活用して、他チームを支援し、その能力を高める戦略を採用した
- 技術チームにも非技術チームにも適用した
- 組織全体の協力を促進し、効果的な実行へとつなげた
実践への意思
- デザイナーの事例以後、さまざまなグループと協力しながら同様の成功を経験した
- チームの自由時間と組織的権限を活用し、各チームが効果的に協力できるよう支援した
- 成功した実行は、全社的な協力と共感に支えられていた
[成功した実行の感覚]
- 専門家 vs. オーナー
- チームにはドメイン専門家を置くが、特定の作業やドメインの「オーナー」は置かない
- セキュリティの事例: セキュリティチームがすべての問題を処理するのではなく、チーム全体がセキュリティに責任を持ち、セキュリティチームはメンバーの能力向上を担う
- 他の分野でもこのモデルが適用されるべきだったが、ほとんどのチームでは実現できなかった
- 失敗事例
- フロントエンドエンジニアとバックエンドエンジニアを厳格に分離した
- 協力不足のために、GraphQLのような不要な複雑性を招いた
- 特定役割の専門家は必要だが、「フロントエンド」「バックエンド」と肩書きを分けるのは非効率である
- 中核原則:
- 「ドメイン専門家ではあっても、オーナーではない」
- 専門家が自分の仕事以外でも他のメンバーを助ける時間を確保できるよう促す
プロアクティブな協業の促進
- 余裕時間の提供
- 全体的なチームワークを維持するため、メンバーに余裕時間を与える
- 単に自然な協力を待つのではなく、意図的にシステムに活力を吹き込む
- 心理的安全性と内集団の拡張
- 人は自分が属する集団の中で心理的安全性を感じると、実験したり新しいことを学んだりしやすい
- メンバーの「内集団」を広げるために時間とリソースを投資する
- ブートキャンプ: 他チームで強制的に勤務させ、協業の機会を提供する
- ハッカソン: 同様の効果を生むイベントとして活用する
意図的なチーム価値観
- チームの哲学と原則の確立
- コードレビュー、ブートキャンプ、ハッカソンなど多様な活動のより高次の目標を明確に定義する
- エリート主義は毒だと宣言する
- すべてのメンバーが「必要な仕事を自分で処理する」文化を醸成する
- 相互信頼と改善への期待
- 他人の成果物を扱うときは、常により良い状態で残すという強い期待を設定する
- こうした文化は、メンバーが進んで協力することを促す
まとめの考え
- 技術業界の問題: エリート主義と独善的リーダーシップ
- 謙虚さを欠いた独善的なリーダーは、チームの協力を妨げ、不要な残酷さを助長する
- 技術業界はしばしば、こうした独善的リーダーを有用な存在だと勘違いするが、それは寄生的で有害な現象である
- 他者を尊重する行動が急進的であるべき理由はないが、現実にはそうなっていない
- 協力はより良い結果をもたらす
- 協力は結果を改善し、独善的リーダーのいない生活はより良いものになる
- 派閥主義とエゴをなくすための努力が必要である
- エンパワーメントの重要性
- メンバーが好奇心を持って協力できるよう励ますには、リーダーの許可と支援が必要である
- 例: デプロイ作業をSREではなく開発者が直接行うよう変更する
- 当初は開発者のミスへの懸念があったが、ほとんどの開発者は問題を自力で解決し、うまくいった
- プロダクトエンジニアたちは自ら問題を処理しようとする姿勢を示した
- システムに余裕（slack）を持たせる
- ブートキャンプやハッカソンのようなプログラムは継続的なコミットメントを必要とする
- こうしたプログラムは、システムに余裕がなければ消えやすい
- 私たちはコンピュータを100%で動かし続けたりはしないのに、自分たち自身にはそうしようとしがちである
- 価値と報酬の重要性
- リーダーは協力と好奇心に報い、それをチーム文化として定着させなければならない
- CEOはしばしば前向きなプログラム（ブートキャンプ、ハッカソン）をなくそうとするが、否定的なプログラム（義務的なコードレビュー）をなくそうとする努力は不足している
- 「苦痛」が結果をもたらすという誤った信念は捨てるべきである
- 苦痛は結果の代理指標として適切ではなく、協力と信頼のほうがより良い成果をもたらす
7件のコメント
> チームメンバーが好奇心を持って協力するよう促すには、リーダーの許可と支援が必要
必ずしも自分の担当領域ではないチームメンバーの領域にも好奇心を持つよう促すことが重要だと思います！
現実は…！
毎日のように進捗を細かく催促するウェジャイル系スタートアップでは不可能な構造ですね..
すべての実務担当者が入社初期の興味を継続して維持できるべきですが、そうした面への支援はたいてい無いか、不足していることが多いですね。
まったくその通りですね..
でも現実は..................涙涙
本当にいい文章だと思いますね！
良い文章です。
Hacker Newsの意見
ソフトウェア開発では、プログラマーの自我を排することが重要だという意見がある。チームワークを通じて、ソフトウェア製品をチームの成果として捉えるのが望ましい。
開発キャリアから得た教訓として、不要なプロセスを追加せず、あらゆる役割においてプロダクトのオーナーシップを求め、反応的な意思決定を避け、チーム間の協力を促進すべきだと助言している。
最高のチームは、スタック全体を所有するピザチームと、必要に応じて助言を提供する専門家たちで構成される。
スポーツのメタファーは技術分野では人気がないが、スポーツチームの力学は優れたビジネスチームと似ているという意見がある。
組織の成功は、各メンバーがグループの必要を満たすために利他的に行動することにかかっている。
意図的にチームの価値観を設定する重要性を強調している。
グロース部門で働いていた際、当初はマネージャーがすべてのコミットをレビューしてマージしていたが、後になって自分自身で本番環境にデプロイできる権限があったことに気づいた。
ドメインオーナーよりもドメインエキスパートのほうが好まれ、過度に明示的な専門分化は問題を引き起こす可能性がある。