エンジニアリングカルチャー: その本質とリーダーが意図的に構築する方法

エンジニアリングカルチャーとは、ソフトウェアエンジニアリング組織がいかに業務を遂行するかを形成する規範、慣行、価値観の集合体です。エンジニアが問題にどう向き合うか、どう協力するか、品質と技術的負債をどう扱うか、失敗にどう対応するか、会議で何を率直に発言するかを決定します。強いエンジニアリングカルチャーは、信頼性が高くメンテナンスしやすいソフトウェアと、継続的に改善できるチームを生み出します。弱いカルチャーは、誰も誇りに思えないソフトウェアと、優秀なエンジニアが去るため離職率の高いチームを生み出します。

エンジニアリングカルチャーの本質

エンジニアリング組織における文化は、誰も見ていないときにエンジニアが下す決断に表れます。本番環境にプッシュする前にどれほど徹底的にテストするか、設計上の判断に誤りがあると思ったときに懸念を示すかどうか、次のメンテナー向けにいかに丁寧にコードを残すか、そして知らないことを認めるか、持っていない自信を装うかという点です。

これらの行動は、主として性格的な特徴ではありません。環境に対する学習された反応です。徹底的なテストを評価する組織（インシデントの減少、肯定的な認知、週末障害の回避など）で働くエンジニアは徹底的にテストします。スピードを何よりも優先する組織で働くエンジニアは、素早く出荷して結果は次のチームに委ねることを学びます。文化は、エンジニアリングハンドブックに書かれた価値観ではなく、生み出すフィードバックループを通じて行動を形成します。

つまり、エンジニアリングカルチャーは採用の問題ではなく、主としてリーダーシップの責任です。ある組織では丁寧でテストされたコードを書くエンジニアも、別の組織では雑でテストなしのコードを書くことになります。環境が個人以上に多くを決定します。

Key Facts

DevOps慣行に関する研究、とりわけ年次State of DevOpsレポートシリーズは、高パフォーマンスのエンジニアリング組織が平均的な組織と異なるのは、主として文化的・プロセス的要因、すなわちチームが主導するデプロイメント、エラー報告に対する心理的安全性、迅速なフィードバックループによるものであり、技術的選択やチームサイズによるものではないと一貫して示しています。

エンジニアリングチームのパフォーマンスに関する組織研究では、心理的安全性、つまり判断や責任追及を恐れずに技術的な懸念を提起できる能力が、欠陥率やインシデントからの回復時間を含むエンジニアリング品質アウトカムのチームレベルにおける最強の予測因子であることが判明しています。

技術的負債の蓄積に関する研究では、主要な要因が個人のエンジニアリング判断の悪さではなく、適切な技術品質作業を妨げるスケジュールでの機能提供を求める圧力を生む組織的インセンティブ構造であることが示されています。

強いエンジニアリングカルチャーの要素

真の価値としての技術的卓越性。 技術的卓越性を大切にすると言いながら、一貫して品質より機能提供を優先する組織は、技術的卓越性は任意であるとエンジニアに教えることになります。強いエンジニアリングカルチャーは、品質とスピードのトレードオフを明示化し、真の議論と真のリスクがある実際の会話として扱い、系統的にスピードを優先して解決しません。これは遅くすることではありません。品質が意思決定に本当に含まれており、述べられた価値観だけにあるのではないことを意味します。

技術的な反論に対する心理的安全性。 経験豊富なエンジニアは技術的な判断が誤っていることを知っています。しかし多くの組織では、そう言うことはリスクを伴います。判断はより上位の人が下したもので、スケジュールは固定されており、事業計画はその前提の上に構築されています。こうした環境のエンジニアは、反論せずに従うことを学びます。これは後に高コストな技術的問題を招く最も確実な道の一つです。強いエンジニアリングカルチャーは、特に技術的な反論を明示的に保護し、コミットメントが行われる前に懸念を提起するプロセスを持ちます。

品質に対する共同オーナーシップ。 一部のエンジニアリング組織では、品質はQAチームの問題です。開発者がコードを書き、別の機能がそれを検証します。この構造は開発者が書くものの品質を系統的に低下させます。なぜなら彼らが結果を所有しないからです。強いエンジニアリングカルチャーは、製品を構築するエンジニアに品質の所有権を置きます。彼らはテスタビリティを考慮して設計し、テストを書き、互いのコードをレビューし、出荷するものに責任を持ちます。

責任追及なしに失敗から学ぶ。 すべてのエンジニアリング組織には失敗があります。障害、欠陥、セキュリティインシデント、見積もりの失敗、誤ったアーキテクチャ上の判断です。その後に何が起こるかで文化が定義されます。責任追及型のポストモーテムは、問題を起こした人物を探すことに会話が集中し、問題を隠し、露見するかもしれないエッジケースを避けるエンジニアを生み出します。責任追及なしのポストモーテムは、どのような状況が失敗を可能にしたか、同様の失敗をどう防ぐかに会話が集中し、問題を早期に提起して公開的に学ぶエンジニアを生み出します。この二つの文化の実際の運用上の差異は顕著で、責任追及型の文化はインシデントが多く、重大度が高く、回復時間が長くなります。

明確な制約の中での自律性。 エンジニアリング作業は高い自律性から恩恵を受けるナレッジワークです。問題を理解し、最善と思う方法で解決する権限を持つエンジニアのことです。しかし制約なしの自律性は、不整合、統合問題、技術的には興味深くもメンテナンスが困難なシステムを生み出します。強いエンジニアリングカルチャーは制約（アーキテクチャ標準、セキュリティ要件、運用上の期待）を明確に定義し、その中でエンジニアに真の裁量を与えます。制約は問題の解決方法ではなく、解決策が何と互換性を持つ必要があるかです。

率直な技術的コミュニケーション。 コードレビュー、アーキテクチャレビュー、技術的議論はすべて、率直で批判的な技術フィードバックを明確に与え受け取る能力を必要とします。一部の企業環境の間接的なフィードバック規範を採用したエンジニアリングカルチャーは、実際には問題を特定しないコードレビュー、実際の懸念を表面化しないアーキテクチャ議論、そして何も言わなかった複数のエンジニアに見えていたインシデントを生み出します。強いエンジニアリングカルチャーは、個人的でなく、無意味なほど和らげられてもいない、率直で具体的な技術的コミュニケーションの規範を育てます。

エンジニアリングリーダーがすること

技術系・エンジニアリングリーダーは、述べられた価値観だけでなく、具体的な行動を通じて文化を形成します。

望む行動を自らモデルとして示す。 本番コードを書き、コードレビューに参加し、失敗に対する真の知的好奇心を持ってポストモーテムを実施し、技術的な不確実性を認めるエンジニアリングリーダーは、チームが学ぶ行動テンプレートを設定します。技術的卓越性を大切にすると言いながら技術的作業に関与しないリーダーは、チームで最も影響力のある人物に文化形成を委ねることになります。

エンジニアリングの時間を守る。 エンジニアリング組織で最も一貫した不満の一つは、絶え間ない会議、頻繁なコンテキストスイッチ、不明確な優先事項が深い技術的作業を不可能にするというものです。エンジニアリング作業のための中断されない時間のブロックを守り、会議のオーバーヘッドを削減し、コンテキストスイッチのコスト管理を助けるリーダーは、深い技術的作業が守るべき真の仕事であることを伝えます。

技術的負債を可視化して管理可能にする。 技術的負債、つまり過去のショートカットと素早い修正の累積コストは、技術的問題であるのと同様にリーダーシップの問題でもあります。強いエンジニアリングリーダーは負債レベルの可視性を維持し、いつ負債を取るかいつ返済するかについて明示的な判断を下し、インシデントを起こすまで技術的負債を見えないものとして扱う組織パターンに抵抗します。典型的な失敗パターンは「後で修正する」を何度も繰り返し、後がついに来ないことです。

エンジニアリング判断を採用し開発する。 技術スキルは強いエンジニアリングカルチャーに必要ですが十分ではありません。判断力、具体的にはトレードオフを評価し、技術的リスクを明確に伝え、不確実性の下で判断を下す能力は同様に重要で、開発がより困難です。技術力だけで採用し、判断力の開発に投資しないリーダーは、技術的には卓越しているが、アーキテクチャ上の判断が下手で組織の他の部分とのコミュニケーションが苦手なエンジニアのチームを生み出します。

非技術系リーダーシップへの橋を架ける。 エンジニアリングカルチャーの問題は、エンジニアリングとそれが奉仕するビジネス機能の間の分断によってしばしば悪化します。プロダクトマネージャー、経営者、エンジニアが技術的制約とトレードオフについての共通理解を持っていない場合、結果は技術的に非現実的なビジネス要件、誤った優先事項に奉仕するエンジニアリング作業、そして機能間の慢性的な緊張となります。これらの橋を架けるエンジニアリングリーダー、つまり技術的ショートカットのコストと技術投資の価値を非技術系リーダーが理解できるよう助けるリーダーは、チームが受け取るインプットを変えます。

異なる組織コンテキストにおけるエンジニアリングカルチャー

エンジニアリングカルチャーは、組織の規模、製品の成熟度、そしてビジネスにおけるエンジニアリングの役割によって異なる様相を呈します。

初期段階の組織。 スタートアップでは、エンジニアリングカルチャーは創業者のエンジニアリングカルチャーであることが多いです。規範は最初の数名のエンジニアによって設定され、コード品質、テスト、アーキテクチャについて彼らが下す決断は、次の採用者が受け継ぐデフォルトとなります。出荷プレッシャーの下でも良い基盤に投資する初期段階のエンジニアリングリーダーは、後の膨大な是正コストを節約します。最もコストのかかるエンジニアリングカルチャーの決断は、誰もそれを文化的決断として認識する前に下されます。

拡大する組織。 エンジニアリング組織が10人から100人から1,000人と成長するにつれ、初期の文化を維持していた非公式のメカニズムは不十分になります。近接性と共有コンテキストを通じた文化的伝達は、チームが増殖し在職期間が多様化するにつれ崩壊します。この段階のリーダーはエンジニアリングカルチャーを明示化する必要があります。標準を文書化し、プロセスを構築し、文化を希釈するのではなく担い、モデルとして示す管理層を育成することです。

大企業の組織。 大規模なエンジニアリング組織は、レガシーシステム、レガシーカルチャーという追加的な複雑性と、新しいツールや慣行が登場する中での関連性維持の課題に直面します。これらのコンテキストのエンジニアリングリーダーは、組織が持つ文化と必要とする文化の間の緊張の中で運営されることが多いです。実際的な道筋は通常、限定されたユニット（チーム、製品領域）で強い文化を構築しながら、より広い組織的条件を段階的に変えることです。

エンジニアリングカルチャーとビジネスアウトカム

エンジニアリングカルチャーとビジネスアウトカムの関係はよく文書化されています。強いエンジニアリングカルチャーを持つ組織は、より頻繁に出荷し、インシデントからの回復が早く、変更失敗率が低くなります。エンジニアは仕事満足度が高く、より長く留まります。システムはより信頼性が高く、メンテナンスコストが低くなります。

しかしこの関係は、特に文化投資が行われており回収がまだ先にある段階では、非技術系リーダーには常に明らかではありません。最も優れたエンジニアリングリーダーは文化投資のビジネスケースを説明できます。信頼性は顧客の信頼であり、デプロイメントの速さは競争力への応答性であり、技術的負債は利息を生む貸借対照表上の負債です。

よくある質問

最高のエンジニアリングカルチャーは偶然に生まれません。インセンティブ、行動、プレッシャー下の判断を通じて生み出すフィードバックループが、いかなる書かれた価値観よりも強力にエンジニアの行動を形成することを理解するリーダーによって構築されます。チームパフォーマンスにおいて発言の安全性が重要な理由についての基礎研究は心理的安全性をご覧ください。また、独創的な解決策が生まれる組織を構築するための関連原則はクリエイティブリーダーシップをご参照ください。