最初に Topotal に興味をお持ち頂いた背景を聞かせてください。

Gunosy の SRE チームは、インフラチームを SRE チームに名前を変更し組成しました。インフラチームは、AWS やネットワークなどのインフラ領域のスペシャリストが集まり、開発チームを支援していました。SRE チームとして名前を変更したのは、Site Reliability Engineering を知りインフラチームで Software Engineering を駆使し開発チームに今までの支援とは異なる価値を提供しようと決めたからです。経験豊富なメンバーが多いので SRE チームとして変化が進んでいきました。

しかし、SRE チームのリソースは常に不足していました。この限られたリソースを有効活用するために、開発チームや他のチームとうまく協力する方法を模索していました。その時に Topotal さんを知り、開発チームに SRE の権限移譲していく経験と自律的な SRE の実践の経験をお聞きし、一緒に取り組みをはじめました。

最初に SLI/SLO の運用改善についてご相談頂きました。

SLI/SLO の定義を決めて指標を計測しており、SRE チームは開発チームとの定例会で指標の変動からわかる課題を共有していましたが、課題の改善が進まない状況でした。改善が進まない原因はSREチームと開発チームで課題の重要性や具体的な改善タスクの認識が揃っていないことだったので、SRE チームが主導して認識を揃えるコミュニケーションをすべきだと考えました。このコミュニケーションをどのように進めたら良いのか Topotal さんに相談しました。

最初に Topotal さんと一緒に改善を進めたのは SRE チームと開発チームの定例会でした。この定例会で達成したい事はなにか、達成したいことに必要な情報はなにか、何を開発チームと議論し、何を決めたいのか、議論を提示する根拠の基準は？など、本当に細部に渡り1つ1つを整備していきました。改善された定例会では、SRE チームが課題だと感じている事に対して開発チームとネクストアクションを議論し、タスクが実行されるようになりました。

印象的だったのは、Topotal さんが開発チームがどうやったら議論に集中できるか徹底的に考えていた点です。 例えば、議事録のフォーマットにあらかじめ議題に上げる条件を記載しておき、その基準を超えたら議題に上げることをアドバイスしてもらいました。このような細かな点を1つ1つ整備し認知負荷を下げることで、全員が会議に集中できる環境になりました。

定例会が進むようになってから、業務設計や会議の準備などを行うためのスキルにはどのようなものがあるか、スキルの全体像があれば共有してほしいとお願いしました。Topotal さんからソフトスキルと言われる分野の情報をアウトプットしてもらうことで、私達が他のチームと協力を得るために必要なスキルも体系的に理解できました。

次に SRE カルチャーの言語化の支援を実施しました。

きっかけは SRE のメンバーの入社です。SRE の業務はドキュメントが整備されており、業務で迷うことはありません。しかし、どのようにやるかを決める判断軸は SRE チームの中で暗黙的に共通理解があるものの言語化していませんでした。新しいメンバーが今いるメンバーと同じように働けるようになるためには判断軸、それは Gunosy の SRE カルチャーを理解できるようにすべきです。そのため、Gunosy の SRE カルチャーの言語化を行うことにしました。Gunosy の SRE カルチャーを言語化を進めるにあたり、内部の視点だけではなくTopotal さんの視点も入れてもらうために、Topotal さんと壁打ちしながら言語化を進めました。

SRE カルチャーの言語化ができたことで、新しく入ってきたメンバーに伝えることができるようになりました。他にも良かった点があります。開発チームや社内の他のチームに SRE チームの責任範囲や目標を伝えることができるようになりました。その結果、SRE チームと他のチームの役割分担が明確になり、よりスムーズに仕事を進められる状態になりました。

SRE チームが他のチームと協力する体制・業務設計が整備できた上で、SRE カルチャーの言語化によって行動方針や目標、期待、業務範囲が他のチームでも理解できる状態になったことで、各チームが分担した業務に集中できるようになったと感じています。

セキュリティについてもご相談を頂きました。

Gunosy の SRE チームはセキュリティの分野も対応範囲です。当時、脆弱性対応のオートメーションや秘匿情報の権限のあり方などを Topotal さんとディスカッションを行っていました。個々に深堀りして検討を進められたもののセキュリティの範囲は広く、他にも検討が必要な状況でした。SRE チームの人数が増えたと言っても、セキュリティツールの検証を手当たり次第行うリソースはありません。戦略的にセキュリティの範囲を広げていく必要を感じ、進め方を Topotal さんに相談しました。

Topotal さんから共有してもらったのは、セキュリティ対策を考える上で参考になる全体像です。

全体像やセキュリティ対策の定義・考え方が明確になったおかげで、1つのツールでより広い範囲とより少ない運用負荷を考えながら、効果的にツールの候補を絞り込むことができ、私達に必要なセキュリティ施策の検討が進むようになりました。さらにセキュリティツール調査も Topotal さんに進めてもらうことで、効率よくセキュリティ施策が進められました。

直近ではインシデント対応のディスカッションを行っていました。

インシデント対応に対しては、なんとなく課題感はあったものの言語化できていない状況でした。Topotal さんとのディスカッションを通じて、エンジニア以外の組織を巻き込んだ非常時の情報伝達がうまくいっていないのではないか、インシデント対応の機会が少なすぎることでインシデント対応に必要な経験を得られてないのではないか、という課題が出てきました。

まず先にエンジニア以外の組織を巻き込んだ情報伝達の整備を進めました。 Topotal さんからインシデント対応のベストプラクティスを共有してもらい、Gunosy の組織に適した役割の決定やインシデント対応に必要なテンプレートの作成を進めていきました。テンプレートは Topotal さんのレビューをお願いし、ブラッシュアップをしました。

その結果、取引先やユーザーに対してコミュニケーションする営業やカスタマーサポートといったビジネスサイドのメンバーまで巻き込んだプロセスが策定できました。

次にインシデント対応の機会を設けるために、インシデント対応のオンボーディングとシミュレーションに関して Topotal さんの経験や知見を共有してもらい、インシデント対応の訓練をできるようにする予定です。

最後に Topotal へひとことお願いします。

Topotal さんとの取り組みで感じた変化は、SRE の活動をカルチャーとして定着できたことです。定着させるための改善を1つ1つ積み上げる中で、Topotal さんがよい相談相手になってくれました。

直近では「Gunosy 内でうまく言語化できていない課題感を共有する」→「Topotal さんとディスカッションする」→「課題感を分解し、具体的な課題に落とし込む」→「タスク化して解決する」という一連のサイクルを回すことができており、組織が強化されている実感があります。このサイクルを回す上で Topotal さんが持っている経験や知見が欠かせません。

この取り組みはゴールのあるプロジェクトではないので、継続して一緒に取り組んでいきたいと思っています。

本日はありがとうございました。