エンジニアリング・リーダーシップ：Michael Grayと考える自律性、成長、文化のバランス
- Aisha Washington
- 1 時間前
- 読了時間: 11分
エンジニアリング組織はしばしば、一見すると相反する2つのことを望んでいる。独立して行動できるチームと、システムの分断を防ぐための十分な調整である。企業が成長するにつれ、この緊張関係を解消することはより難しくなる。人、サービス、依存関係が増えることで監督が必要となる正当な理由が生まれる一方、過度な中央集権化はデリバリーを遅らせ、エンジニアのオーナーシップ意識を弱めかねない。
このInfoQの対談で、Michael Grayは、ClearBankが分散型のアーキテクチャ意思決定、明示的な境界、そして継続的に学ぶ文化を通じて、この課題にどのように取り組んでいるかを説明する。彼のより広いメッセージは、自律性とはガバナンスをなくすことではないということだ。意思決定が適切なレベルで行われ、持続する文脈と建設的な異議によって支えられるよう、ガバナンスを設計することを意味する。
アーキテクチャ承認からアーキテクチャ助言へ
従来のアーキテクチャレビューのプロセスでは、権限が少数のグループに集中しがちである。チームは提案を作成し、レビュー委員会に提示し、承認を待つ。このモデルは一貫性を生み出せる一方で、アーキテクトを門番に、デリバリーチームを請願者にしてしまうこともある。意思決定は会議、予定表、そして運用上の詳細から離れている可能性がある人々の意見に結び付いてしまう。
Grayは、ClearBankがAndrew Harmer-Lawの仕事から影響を受けたアーキテクチャ助言プロセスへと、この中央集権的なレビューのパターンから移行したと説明する。重点は、重要な選択を行う前に中央組織へ許可を求めることから、関連する専門知識を得ることへと移る。
この違いは重要である。承認プロセスは、「権限を持つ者はこれを許可するか？」と問う。助言プロセスは、「誰の知識がこの意思決定に役立つべきか、そしてそれを考慮したことをどのように示すのか？」と問う。後者では、情報に基づいた精査に提案をさらしつつ、責任を実務に携わるエンジニアの近くに保てる。
アーキテクチャ意思決定記録、すなわちADRは、このモデルの中心にある。会議そのものを意思決定として扱うのではなく、チームは問題、関連する制約、検討した選択肢、採用したアプローチ、そしてその理由を文書化する。Grayは、こうした記録は従来の議事録よりも有用な文脈を提供すると主張する。議事録は通常、人々が何を言ったかを記録する。一方、優れたADRは、組織がなぜある道を別の道より選んだのかを説明する。
長期的な利点は、組織の記憶である。数か月後、エンジニアは過去の意思決定がまだ適切か、あるいはその当初の前提が変化したかを理解できる。これにより、過去のあらゆる選択が恒久的なものとして意図されていたと見なすことなく、アーキテクチャを見直しやすくなる。
意思決定の範囲に権限を合わせる
意思決定を効果的に分散するには、チームに自律的であるよう伝えるだけでは不十分である。人々は、どの選択を独立して行えるのか、いつ他チームを関与させる必要があるのか、そしてどの事項に組織全体での調整が必要なのかを知る必要がある。
Grayは、ClearBankがこれらの境界を定めるために「decision scopes」を使用していることを説明する。意思決定は大きく3つのレベルに分かれる。
チームレベルの意思決定は、その影響が局所的にとどまる場合、チーム内で行える。
ドメインレベルの意思決定は、関連領域にある複数のチームに影響するため、より広範な協議を必要とする。
エンタープライズレベルの意思決定は、会社全体に影響を及ぼすため、中央集約された助言フォーラムを通す必要がある。
この構造は、よくある2つの失敗を防ぐ。1つ目は不要なエスカレーションであり、チームが可逆的で局所的な意思決定について上位者の承認を求めるケースである。2つ目は見せかけの自律性であり、あるグループが他の多くのグループにコストや制約を課す選択を、それらを関与させずに行うケースである。
有用な原則は、比例性である。意思決定に対するガバナンスは、その影響範囲を反映すべきだ。局所的な実装の詳細が、全社規模のプラットフォーム、セキュリティ制御、またはアーキテクチャ標準の変更と同じ組織的負担を伴うべきではない。
明確なスコープは、説明責任の信頼性も高める。境界が理解されていればエンジニアは自信を持って行動できる一方、リーダーは影響が1つのチームをはるかに超える意思決定に対処する仕組みを維持できる。
調整の仕組みとしてのArchitecture Advisory Forum
エンタープライズレベルの意思決定に対して、ClearBankはArchitecture Advisory Forumを利用している。Grayはこれを、単にトップダウンの判断を下す場ではなく、意見を集め、ステークホルダーの支持を確立する場として提示している。
これは、トーンと機能における重要な違いである。提案の承認または却下だけを目的とするフォーラムは、チームに不確実性を隠し、洗練された弁明を用意して臨むよう促しかねない。対照的に助言フォーラムは、未解決のリスクを明らかにし、影響を受けるグループを特定し、組織がそれにコミットする前に提案を改善できる。
このフォーラムは、協議と合意形成を区別するのにも役立つ。幅広い意見は価値があるが、全員一致を求めれば重要な意思決定が不可能になりかねない。目標は、関連する観点が聞き入れられ、重大な懸念が対処され、説明責任を負う意思決定者が進めるために十分な情報を持つことを確実にすることだ。
この仕組みが機能すれば、中央での調整は現場のオーナーシップを消し去らない。実務的な知識がある場所に大半の選択を残しながら、会社横断的な影響を管理するための構造化された方法を提供する。
機能工場の罠に抗う
Grayはまた、テクノロジー業界における「より少ないリソースでより多くを成し遂げる」圧力にも触れている。特に予算が引き締められる場面では、効率性は妥当な懸念である。しかし、その定義は危険なほど狭くなりうる。リーダーが生産性を主にリリースした機能の数で測る場合、チームは機能工場的な思考へと流れていく可能性がある。
目先のアウトプットは印象的に見えるかもしれない。しかし時間が経つにつれ、放置された保守、弱い開発者向けツール、アーキテクチャ上の摩擦、未解決の品質問題によって、その後のあらゆる変更のコストが高くなる。チームは次のデリバリー目標に絶えず追われるため、実験する能力を失ってしまう。
Grayは、この対応をリーダーシップに直接結び付けている。リーダーは継続的改善を自ら体現し、そのための余地を守り、上級ステークホルダーにその価値を説明しなければならない。すべての計画やパフォーマンスのシグナルが、目に見える機能開発だけを評価しているなら、品質が重要だとエンジニアに伝えるだけでは不十分である。
技術的な改善をビジネス成果に結び付けることで、この働きかけはより容易になる。より優れたデプロイプロセスはリードタイムを短縮できる。より信頼性の高いシステムはインシデントコストを下げられる。簡素化されたアーキテクチャはオンボーディングを短縮し、プロダクト変更をより安全にできる。したがって、継続的改善は価値創出とは別のものではない。それは、組織が繰り返し価値を生み出す能力を維持するものである。
リーダーはまた、公の場でどのようなトレードオフを行うかを通じて文化を形作る。期限のプレッシャーのもとで基盤的な作業を一貫して犠牲にすれば、チームは改善が任意のものだと学ぶ。システムの健全性と学習をデリバリーの一部として扱えば、これらの優先事項は信頼できるものになる。
急成長の中で文化を守る
成長は文化を試す。非公式な連携が、もはや規模に対応できなくなるからだ。小さな組織では、人々は共有された歴史と頻繁な直接の会話に頼ることができる。人数が増えるにつれ、その背景を知らない新入社員が加わり、チームは専門化し、オーナーシップは見えにくくなる。
Grayは、ClearBankがオープンなコミュニケーションと知識共有を促しつつ、明確な境界とオーナーシップを設けることで文化を維持したと述べている。そのアーキテクチャ・アドバイス・プロセスは、両方の目的を強化している。チームには意味のある権限が与えられる一方で、意思決定は可視化され、意見を受け入れる形で保たれる。
これは、文化がスローガンや会社の初期段階への郷愁によって守られるものではないことを示している。文化は運用の仕組みに組み込まれる。誰に意思決定が許されているのか。アーキテクチャ上の選択の根拠はどこで確認できるのか。学びはどのように共有されるのか。エンジニアが懸念を提起した場合、何が起きるのか。
明確なオーナーシップは曖昧さを減らし、透明な意思決定記録は自律性が孤立に変わることを防ぐ。知識共有の取り組みは、人々が直属チームの外で行われている仕事を見つける助けとなり、長年在籍している少数の従業員への依存を減らす。
そのバランスは繊細だ。構造が少なすぎれば混乱を生み、多すぎれば判断が官僚主義に置き換わる。Grayのアプローチでは、境界は促進要因として扱われる。自分たちの権限がどこから始まり、どこで終わるのか、そして意思決定がその境界を越える場合にどう助言を得るかをチームが理解していれば、より速く動ける。
メンタリングでエンジニアリングのスキルギャップを埋める
Grayは、エンジニアリング業界全体に大きな経験のギャップがあると指摘している。比較的最近になってこの分野に入った実務者が多いため、組織には指導を必要とする人の数に対して、深い経験を持つエンジニアが相対的に少ない。
採用だけでは、この不均衡を解消できない。経験豊富なエンジニアは希少であり、彼らを採用しても、能力を企業間で移動させるだけだ。組織は、すでに在籍している人材を育成する力を高めなければならない。
Grayは、特に効果的な仕組みとしてメンタリングを挙げている。その影響は、単一のメンターとメンティーの関係を超えて広がる。より明確なメンタルモデルを得たり、より強固なエンジニアリング実践を学んだりした人は、その知識をチーム全体へ持ち帰ることができる。
効果的なメンタリングは、答えを与えるだけのものでもない。問題をどう整理するか、トレードオフをどう評価するか、関連する助言をどう求めるか、不確実性をどう伝えるかを、エンジニアが学ぶ助けとなる。これらの能力は、Grayが説明する分散型の意思決定モデルを支える。自律性が持続可能なのは、人々がそれを行使するのに必要な判断力を継続的に身につけている場合に限られる。
したがって、リーダーはメンタリングを、納品義務を果たした後に行われる課外的な親切ではなく、正当なエンジニアリング業務として扱うべきだ。知識移転が組織のレジリエンスに不可欠であるなら、それに時間、評価、そして意図的な支援を与える価値がある。
有用で、タイムリーで、安全なフィードバックにする
自律的な組織は、人々がアイデアに異議を唱えられることに依存している。しかし、技術的に正しい反論であっても、文脈を考慮せずに伝えられれば効果を失い得る。
Grayは、フィードバックを行う際のタイミング、場、アプローチの重要性を強調している。即時のリスクがより広い集団に影響する場合、公開の場で異議を唱えることが適切なこともある。しかし、私的に話し合う方が適している問題であれば、同じ伝え方でも屈辱的に感じられる可能性がある。フィードバックが遅すぎれば、もはや実行可能な対応につながらないかもしれない。急すぎるフィードバックは、その中身を検討する前に防御的な反応を招くことがある。
目的は、意見の対立を避けることではない。対立を生産的なものにすることだ。有用なフィードバックは提案とその結果に焦点を当て、懸念を明確に説明し、欠けている文脈があり得る余地を残す。断言よりも、質問の方がより良い対話を開けることが多い。この選択を支える前提は何か。どの代替案が検討されたのか。他に誰が影響を受けるのか。
この対人関係における規律は、エンジニアリングの有効性に付随するソフトな要素ではなく、その一部である。助言プロセス、ADR、メンタリング、チーム横断のフォーラムはいずれも、人々があらゆる異議を地位を争う競争に変えることなく批判を交わすことに依存している。
環境を設計することとしてのリーダーシップ
Grayの議論にある考え方は、一貫したリーダーシップモデルを形作っている。チームは、明示された意思決定の範囲内で権限を与えられる。より広範な影響が生じる場合には、より広い協議が行われる。ADRは判断の根拠を残し、助言フォーラムは全社的な懸念を調整し、メンタリングは健全な判断を下す組織の能力を広げる。
同時に、リーダーは自律性を持続可能にする条件を守る。改善のための時間、透明なオーナーシップ、知識共有、そして慎重に伝えられるフィードバックである。彼らの仕事は、あらゆる技術的判断を下すことではない。他者が良い意思決定を行い、それを検証し、記録し、改善できる環境を築くことだ。
これは、エンジニアリング組織をスケールさせるうえで最も実践的な教訓かもしれない。自律性、成長、文化は、注意を奪い合う別々の施策ではない。適切に設計すれば、それぞれが他を強化する。有能な人々が分散した意思決定を行い、透明な仕組みがその意思決定の整合性を保ち、学習する文化が、複雑性の増大に合わせて組織が改善する助けとなる。
