SpeedData

エンジニアリングチーム

エンジニアチームの拡張 ― CatchpointエンジニアリングVPの視点から

レジリエンスを高め、成功するエンジニア・チームを構築するために

2022年7月12日
翻訳: 島田 麻里子

この記事は米Catchpoint Systems社のブログ記事 Scaling Engineering Teams: Perspective from our VP of Engineeringの翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

Catchpointでは、私の役割は大きく分けて2つあります。
1つはエンジニアチームの設計と管理、もう1つはエンジニアチームと協力して、当社のプラットフォームを動かす様々な分散システムを設計し、その管理をすることです。

先日、サファイヤ・ベンチャーズ社のHypergrowth Engineering Summitに参加しました。
（デビッド・カーター氏、サファイヤ社の皆さん、ご招待ありがとうございました！）

ここでは、高機能なエンジニアリングの構築と拡張に焦点を当てたセッションが行われました。
あるセッションはエンジニア・チームの拡張に焦点を当て、あるセッションはシステムに焦点を当てました。
特に興味深いのは、それぞれのトピックが非常に異なっているにも関わらず、まとまりのあるストーリーとして非常にうまく調和している点で、チームに対するアドバイスがシステムに対してもとても有効に機能しており、その逆もまた然りということです。

3つの重要な講演

どの講演も素晴らしかったのですが、その中でも特に気に入った3つの講演について、私の考えをお伝えしたいと思います。

1つ目の講演

Pendo社のエンジニアリング担当SVPであるデイブ・レンシン氏 は、人間の脳の働きと、それを理解することでエンジニアリングリーダーがいかに成果を上げることができるかについて話しました。

大前提として（かなり省略していますが）人間の脳の主な機能は、未来のモデルを作り、そのモデルを検証することである、ということです。
モデルと現実の間にミスマッチがあると、それが不安の原因になります。
人間は不安になると、決断ができなくなったり、判断を誤ったりします。

2つ目の講演

J. ポール・リードSr氏（最近までNetflixのシニア・アプライド・レジリエンス・エンジニアで、数年前のSRE from homeイベントで素晴らしい講演をしてくれました）は、エンジニアリング・レジリエンスについて講演しました。

基本的に、レジリエンスは消耗品であり、使い切ることもできるが、補充することもできる、と彼は力説しました。
チームが高い機能を発揮するためには、様々な状況下でレジリエンスを高める練習をする必要があると説明しました。

レジリエンスは、冗長性、信頼性と並び、重要な「R」の一つです。
冗長性と信頼性の高いシステムを持つことは、チームがレジリエンスを使い果たすことがないよう、有意義に活用するのに役立ちます。

3つ目の講演

パネリストのCircleCI社CTOロブ・ズーバー氏 と、LaunchDarkly社エンジニアリング・プロダクト担当SVPジョナサン・ノレン氏は、正しいシフトについて、また、問題を非常に迅速に解決できるという確信があれば、本番環境にリリースすることはそれほど怖くないかもしれない、その確信を得るためには、システム全体のオブザーバビリティが必要だ、と語りました。
このセッションの感想が一番多いので、別にブログ記事 を書きました。

成功するエンジニア・チームの構築

これらのセッションのテーマ（他のセッションも多数含む）を組み合わせ、成功するエンジニアチームに適用すると、理解は容易だが実行は難しいという話になります。
私たちエンジニアのリーダーの仕事は、メンバーの不安を軽減し、彼らが自分の役割に専念できるようにすることです。

不安を減らすには、レジリエンスの高いチームを作ります。
チームのレジリエンスを高める方法のひとつは、無駄なことにコストをかけないようにすることです。
だから、無駄な緊急事態が起こらないよう、正しい方法でシステムを設計するのです。

しかし、緊急事態が発生した場合は（結局のところ避けられないのですが）、できるだけ早く問題を特定するために適切なデータを用意するようにしてください。
システムの場合、これは適切なオブザーバビリティ戦略によって達成することができます。

アドバイスを翻すとどうなるか

興味深いことに、チームやシステムに関する上記のアドバイスは、実は全て反転させることができ、それは同じように有効で価値があるものなのです。
システムのモデルが現実とミスマッチしていると、間違った決定を下してしまいます。
例えば、if文の分岐を間違えるかもしれないし、極端な例では、自動運転車が事故を起こすかもしれません。

システムはモデルのミスマッチに強い必要がありますし、常に単一障害点を回避する必要もあります。
チームでも、システムと同じように、エンドツーエンドのオブザーバビリティが可能であることが重要です。
チームの状況についてできるだけ多くのデータを収集し、そのデータを使って問題を特定し、解決すると良いでしょう。

もちろん、これらの戦略を実行するのは、システムよりもチームにとって難しいのが普通です。

システムは一般的に予測可能であり、人が指示したとおりに動くものです ― 壊れても、何が悪かったのか、証拠の糸があります。
チームの失敗は、もっと予測不可能なもので、何が悪かったのかを正確に把握することは非常に困難です。
だからこそ、できるだけ多くのデータを収集し、チームとの信頼関係を築いた上で、彼らの成功のために全力を尽くす必要があるのです。

また、システムのオブザーバビリティと同様に、チームの状態や、チームの成長を助けるための洞察力（計測データや他のエンジニアリーダーからのインスピレーションなど）があればあるほど、成功する可能性は高まります。