Topotal入社1週間で感じた、SRE as a Serviceという働き方と日常

2025年9月から同社に入社しています、VTRyoです。一週間と少し経過しました。

だんだん慣れてくると何が他社と異なるかわからなくなってきますので、まだ新鮮なうちにTopotalの日常を紹介していこうと思います。

ちなみにこのTシャツは入社とともに自宅に発送されます。

Topotalとは

Topotalは「事業成長に伴う技術課題をSREによって解決する組織」です。在籍する社員のほとんどがSREで構成されており、お客様のサービスに対してSRE as a Serviceを提供しています。

また、WaroomというインシデントマネジメントのSaaSも展開しています。

topotal.com

ギルド構造で働くTopotalの日常

分散型チームでよく課題となる「情報共有の難しさ」や「知識の属人化」といった問題に対して、Topotalでは積極的に取り組む工夫が実装されています。

バディ制による協力体制

SRE as a Serviceにおけるお客様のご支援については、必ず2名以上がアサインされるようになっています。

ひとりで担当するということはなく、互いに協力しながら社内のSlackやGather(バーチャルオフィス)を使って相談しながら進めています。

この体制により、知識の属人化を防ぎ、品質の向上と継続性を担保しています。

またどちらかが不在となっていても、お互いに助け合いながら進められる安心感もまた精神的に重要です。

ノウハウの自動収集と共有

組織にとって情報のサイロ化は常に課題になります。DevOpsを体現するSREは、この問題を解決すべく頭を悩ませます。

Topotalにおいては、まだ少数精鋭組織という前提もありますが次のようなことが実施されています。

  • 定期的なLT会の開催
  • ノウハウを自動的に収集してドキュメント化される基盤(Topotal SRE Document)

Waroomのドックフーディング&LT会
Waroomのドッグフーディング&LT会(ゆるふわ)

Topotal SRE Document
Topotal SRE Document

実際にメンバーが経験した技術的な内容にアクセスできる環境は今まで在籍した組織でも整っていないことが多く、この仕組みは特に印象的でした。

20%ルール: 毎週金曜は自社改善デー

毎週金曜日は、メンバー全員が自社の改善に時間を当てています。

Topotal社員のほとんどがSREで構成されていることから、社内のToilには敏感です。もちろんソフトウェアによって解決すべく、このような日が設けられています。

スタートアップとして継続的に改善・構築する必要があるフローは多くありますが、そうした活動をこの日に実施しています:

  • Software Engineering - 業務プロセスの自動化。社内業務用のCLI改善なども
  • Platform Engineering - Topotal社内の基盤改善(k8sやTerraformのメンテナンス、クラウド基盤のコスト管理など)
  • SRE Advocacy - ブログ(社内・社外問わず)、登壇、コミュニティ活動、勉強会の開催など

これらの活動は、Squad単位(共通の目的を持ったグループ)で行っています。

私はもともと外部発信が得意なので、まずはSRE Advocacyに参加しています。

珍しくなったフルリモートワークの実際

Topotalはフルリモートワークを採用しており、私は個人的な事情で出社が極力必要のない職場を探していたため、この点でマッチしました*1

福利厚生として提供されるリモートワーク手当(毎月1万円分のお菓子、炭酸水、備品など)も実用的でありがたく感じています。

「そんなこと言って〜、いつか出社しようっていう話が出るんじゃないの〜?」と懐疑的になる私。

times芸人は今日も元気ですね
times芸人は今日も元気ですね

弊社には出社すべきオフィスがありませんので、安心してください。

出社すべきオフィスがないので回帰する物理出社もない

コミュニケーションは基本的にSlackかGather

オフィスがないため、メンバーは基本的にSlackかGatherというバーチャルオフィスで話をしています。 バーチャルオフィスにあまり明るくはなかったのですが、操作は案外簡単です。

バーチャルオフィス Gather
バーチャルオフィス Gather

会議の時間になると、大きな部屋にテクテク歩いていくことでそのスペースにいるメンバーと会話できるようになります。それ以外のときは、自分の席(論理)でマイクもカメラもオフにしていることがほとんどです。

事業会社のSREだった私から見た、SRE as a Serviceが持つ可能性

さてここからは私が所属している事業の話になります。

SRE as a Serviceとは『サービスの価値を最大限に引き出すためのエンジニアリングを提供するサービス』です。

自社サービスのSREとは大きく異なり、私たちはお客様のサービスに対して活動します。これまでずっと自社サービスのSREとしてやってきたため、Topotalがどのような支援活動を行っているのかオンボーディングで詳しく学びました。

実際にSRE as a Serviceをご利用いただいた企業の方々の声も参考になります:

前職の私は、非常に多くのプロダクトチームを抱える事業会社であったため、別のチームの支援に参加すると全く違う文脈とルールで支援していました。まるで同じ会社とは思えないほどです。むしろそれが、SRE as a Serviceという事業に貢献できるかもと思ったきっかけです。

Topotalのように多くのお客様の支援ができる場所にいることで、業界全体の信頼性工学に貢献できると思っています。

SRE as a Serviceのビジョン

TopotalのSRE as a Serviceが目指す将来像は、私が常々考えていた世界観に似ていました。

Topotal の考える "SRE as a Service" の将来像は、2019 年の SRECon EMEA にあった発表の SRE in the Third Age や、2020 年の Grafana のブログの What does the future hold for Site Reliability Engineering? に登場する "SRE as a Service" のように、向き合う先を支援先の SRE チームからどんどん広げ、SRE の考え方をビジネス自体に紐づかせ、組織内のほとんどのエンジニアが SRE のプラクティスを活かしたツールやサービスを享受し、それぞれの開発チームが自律的に信頼性のコントロールができるような組織を作ることをより支援できるような形にしたい

昨今のSREは多様化しており、その中でもEnabling SRE*2という分類があります。SRE as a Serviceは、この形式に最も近いのではないかと考えています*3。自社内でEnabling活動をするか、TopotalがEnabling活動をするかの違いはあれど、信頼性工学という文化を組織にインストールする方向性は私の理想とするSREと一致していました。

VTRyoが事業会社でEnabling SREをしていたときの組織構図
VTRyoが事業会社でEnabling SREをしていたときの組織構図

このような世界観であるため、あるフェーズまで来たらSRE as a Serviceを必要としなくなるフェーズが訪れると思います。しかし、それこそがSRE as a Serviceのひとつの成功とも言えるでしょう。そして私は、その世界を実際に見てみたいと思っています。

SREは職種ではない。だからこそSRE活動を組織に浸透させていく

SREという言葉は割とバズワードです。SREがほしい……! という多くのお客様に弊社は支えられています。しかし支援なしにサービス運用が可能になることも、私たちにとってもひとつの成功であります。

世界で初めてのSREとしての役割を果たしたとされるマーガレット・ハミルトン氏が活躍した当時、ソフトウェアエンジニアリングという言葉もありませんでした。 それでも彼女の生き方は現代のSRE活動そのものだった*4のですから、私たちも自分がSREであるかどうかは関係ありません。

wired.jp

SREを自認していなくても、「このサービスはユーザの目的を果たせるか」について考え抜いている間は、その役割を果たしています。

SREは職種ではなく、生き様なのです。

おまけ: CEOもCTOもSREの会社あるある

インフラに関する問題があっても気づかないうちに修正されてました。

こういうのってたいていSREチームに連絡が来るのが常ですけど、よく考えたら私たち全員SREでした。ガハハ。

ドメイン転送設定が解決されている様子
ドメイン転送設定が解決されている様子

TopotalではSRE as a Serviceとして業界の信頼性に貢献したいソフトウェアエンジニアを募集しています

現役SREのCEOとのカジュアル面談は、なんといつでもこちらから応募できます!!!!

Topotal 採用情報 -> カジュアル面談はこちら! の部分まで下にスクロールする

カジュアル面談はこちら

*1:状況やイベントによってはその限りではありません

*2:信頼性に関連する知識を組織に浸透させ、活用できるようにするSREを指すことが多い。実際に手を動かしながら、現場と伴走していくケースが主流だと認識しています

*3:Platformに関わることをしていないか? 実際に手を動かさないのか? というと、そうではありません。Topotalがどのような内容で支援するかは、お客様と決定されます

*4:彼女が、オペレーターやシステムが失敗することを前提に設計し実装していなければ、アポロは月に人を運べなかったのです