※このストーリーは、noteで発信した記事を転載しています。

こんにちは！ カンリーでエンジニア採用を担当している宮本です。

GoogleがSRE（サイト信頼性エンジニアリング）を提唱してから、早20年余り。SREの概念は広く知られるようになり、どのサービス、組織でも当たり前にやることとして認知されるようになった気がします。

…と、いきなり堅苦しい話題から入ってしまいましたが、（ご想像のとおり）今回のテーマはSREです。

現SREチームのメンバーが、チームの立ち上げ〜これまでの歩み、仕事に対するスタンス、そして、これから挑みたい目標について語った座談会の模様をお届けします。

「どうすればチームは前に進むのか？」

そんな問いに向き合い続けるエンジニアのみなさんに、ぜひ読んでいただきたいです。

▼参加してくださったSREチームのみなさん
・本間さん：2021年3月入社、カンリー店舗集客をメインで担当
・吉村さん：2025年1月入社、カンリー福利厚生をメインで担当
・有村さん：2025年5月入社、カンリー店舗検索ページをメインで担当

▲左から、吉村さん、本間さん、有村さん

「火消し」から「門番」へ。SREチーム立ち上げの舞台裏

吉村さん（以下、吉村）：
最初は、「これまでどんなことに取り組んできたのか」というテーマについて話してください、とのことです。これはもう、本間さんしかいないですね。

有村さん（以下、有村）：
利他主義の塊のような人なので、きっとトップバッターを引き受けてくれると信じてます。

本間さん（以下、本間）：
盛り上げてくれてることはわかるのですが、ただただハードルが上がってる気が...（笑）。とはいえ、このメンバーで昔のことを知ってるのは私だけだと思うので、SREチームができる前の話からしたいと思います。

入社した当時（約4年前）は開発チームは1つしかなく、インフラ専任者は不在でした。インフラはCTOの長谷川さん（現在はVPoE）が片手間で見ている状態で、問題が起きたときに気づいた人が都度、対処するという、極めて属人的な感じでやっていました。ちょうどその頃、「インフラを学びたい」という個人的な希望もありまして、手を上げて積極的に関わっていました。EC2のディスクが足りなくなったから増やそうとか、スペックが足りないから上げようとか、本当に最低限のことだけでしたが。

その後、人が増えて、開発チームとインフラチームに分かれたものの、インフラは実質社員一人（私だけ）だったので、ひたすら火消し（問題が起きたら対処する）。現SREチームのEMである井上さんが入社して以降にやっと、火消しプラス交通整理、ルール整備に取り組み始めることができました。

この頃は、用途不明なクラウドリソースの整理や不足している監視の追加、是正など、問題にいち早く気づける仕組みづくりに注力していました。それと同時に、新しいリソースを増やしたり変更したりする際には、これ以上カオスを生まないようにする、いわゆる門番のような役割を担っていました。

同時に、Terraformを使ったIaC化も徐々に進めていました。運用を楽にするためにサーバレス系のAWSサービスにどんどん置き換えていったのもこの頃です。ちょうど、現CTOの小出さんが業務委託として参画されたタイミングで、たくさんアドバイスをいただけたのは本当に幸運でした。

吉村：
井上さんが書いていたnoteを見たのですが、チーム発足前は想像以上にカオスだったんですね...。

本間：
「なんでドキュメント残してくれなかったんだ」と、何度思ったかわかりません（笑）。
門番のフェーズを終えると、いよいよSREチームらしくSLOの設定やポストモーテム、インシデント管理に着手します。といっても、SLOも何もかもが初めての経験だったので、「SRE本（※1）」という有名な本を読みながら、最初はとにかくスモールにスタートしました。（後にこれはアンチパターンだと学ぶのですが）ここでは、計測しやすい指標を取って目標を追うようにしていました。

（※1）SRE本：SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム

その後、社内でも、次第にSREの考え方が認知され、インフラや信頼性タスクはSREチームだけがやるものでなく、開発チームと協力して進めるもの、という雰囲気が徐々に醸成されてきます。

さらに開発チームの人数が増えて、同時に、管理しなくてはいけないサービスも増えるタイミングで、より一層、拡張性をもたせる準備やセキュリティ・ガバナンスの強化を進めていくことになります。具体的には、AWS Control Towerの活用や、良く使う構成をTerraformのモジュールに切り出したり、Google Cloudの野良プロジェクトを削除してオーナー権限の整備を推進しました。

このようなベース強化により、やっとアプリケーションの信頼性に真正面から向き合う準備が整いました。

ボトルネックの解消とプロジェクトの品質向上で、開発力アップを支援する

本間：
吉村さん、有村さんが入社したのが、ちょうどこの頃ですね。

吉村：
たしか、組織が拡大して開発チームが分かれて、各チームにイネイブリングしていく中でSREが足りないと聞いた気がします。

本間：
そうそう。もっと深く信頼性を担保できるようにするには、開発チームに入り込まなくちゃいけないよね、となって。

吉村：
なるほど、だから「Embedded SRE（※2）」というポジション名で募集していたんですね。

（※2）Embedded SRE：特定のプロダクト開発チームの一員として開発・運用に深く携わるSREのことで、開発チームとSREチームの橋渡しを担う

本間：
吉村さんは、HR事業専任のSREとして入社したんですよね？

吉村：
ですね。ただ、最初は慣らし運転（？）みたいな感じで、主力プロダクトである「カンリー店舗集客」で、負荷を高めてるRedashのクエリの分離作業を任せてもらいました。HRのプロダクトを個別でキャッチアップしていたので、特別なことはしていないかなと思うのですが...。

本間：
DBアップグレードは？

吉村：
EOLを迎えそうなDBをアップグレードしたやつですよね。あんまり語れるようなものはないかも...。あ、でも、やり方はちょっと工夫したんですよね。

カンリー店舗集客のDBは、複数のサブシステムが同一のDBを参照しているので、影響範囲が大きく、リスクを見積もることが難しい状況でした。一方、HR側のプロダクトはサブシステムも少なく、影響範囲が限定的でした。そこで、HR側への適用の優先度を上げて実施し、実績を積んでからカンリー店舗集客のDBをアップグレードする方針にしました。（ちなみに、ここで密結合となっていた問題は、のちに有村さんが解消してくれました！）

本間：
個人的には、HR側に専任の吉村さんが入ってくれたこと自体もすごく良い影響があったと思ってるんですよね。「カンリー店舗集客はこういう構成になってるから、HRも同じようにしたらどうだろう」みたいな相談がしやすくなったので。

吉村：
なるほど。システムの特性は違うけど、信頼性という意味だと適用できる部分があって、それについて意見交換ができるのは、めちゃくちゃメリットが大きいですね。
有村さんが入社した時期は、どんな状況だったんでしたっけ？

有村：
SREチームの強化に向けて、井上さんがマネジメントに注力し始めた時期だと思います。なので、インフラがボトルネックにならないように運用を最適化するのが、最重要ミッションのひとつでした。

直近であった具体的な課題だと、リニューアル前の旧カンリー店舗集客とリニューアル後の新カンリー店舗集客、2つのプロダクトが共用データベースを参照していたことですかね。

密結合になってしまうのはあまりよくないので分離することになったのですが、事前に影響範囲を完全に特定できなかったのが原因で、実は1回、失敗してしまったんです。開発メンバーには影響範囲の特定や深堀り、CSにはお客さま向けにメンテナンス期間の調整をしてもらうなど、たくさんの人に協力してもらって、迷惑もかけてしまいました。

ただ、結果として、一つのインフラが新旧の両方に影響してしまうというリスクをなくせたのはよかったんじゃないかなと。理想のクラウド構成に一歩近づけた気もしています。とはいえ、まだまだリスクやボトルネックになり得る部分は存在しているので、ここをできる限り減らして、開発者がより開発しやすいような体制にできたらいいなと思ってます。

本間：
サービスの構造上、カンリー店舗集客で集まったデータを他のサブシステムでも使っているので、密結合になりがちなのは仕方がない。今後も「どこをどうやって分離するか」という課題はつきまとうので、上手く解決できる方法は考え続けたいですね。

吉村：
有村さんの話で思い出したのですが、SKD（※3）の話もしていいですか？

（※3）SKD：SRE Knowledge Database、SREの実践で得られた知識を整理し、組織全体で共有するためのデータベース

プロダクトが増え、チームも分かれると、どうしても情報が分散して、独自のルールで運用しがちになってしまうじゃないですか。これを解消するために「インフラに関してはこうして欲しい」「こういう風に管理をしていきます」といったADR（※4）を作れたのは、中長期的に見ていいことなんじゃないかと思っていて。

ADRができたのは、火消しや門番をやってきた知見がベースにあったからこそなので、井上さんと本間さんのおかげですね。

（※4）ADR：ソフトウェアやシステムのアーキテクチャにおける重要な意思決定とその背景、理由、結果などを文書化すること

本間：
おぉ！ なんか最初の話につながった！（笑）
たしかに、今の設定値にした理由や、方針が作られた背景がわかれば、新しく入ってきた人もシステムを理解しやすいし、迷った時に辞書的にも使えるので、ありがたいかも。

吉村：
そうなんですよ。これまではミーティングとかで「じゃあこうしてこうね」という感じで、ふわっと決まって、その場にいる人しか「なぜそうしたのか」を知り得なかったじゃないですか。情報を1箇所に集めた上で、さらにAIを使って実装に直結できるようにもしたので、自分でいうのもアレですが、かなり便利になったんじゃないかと思ってます。

システムも、人との関係も、信頼（性）が大事

吉村：
ここらへんでテーマを変えますね、仕事で意識していることやスタンスみたいなところを聞いてみたいなと。

本間：
バリューの中でも、「利他主義でいこう（※5）」はかなり意識しています。SREの考え方を推進するには、開発チームとの協力が必要不可欠で、チームとして、そして人としても信頼されていることが重要だと思っていて。依頼文の書き方1つにも注意を払うようにしています。

（※5）利他主義でいこう：カンリーの5つのバリューのひとつで、困っている人がいたら手を差し伸べる、組織のことを第一に考えて動くことを示しています

当たり前のことかもしれないですが、依頼する時に自分の主張を押し付けるのではなく、開発チームにとって今やることがいかに重要なのか、いわば、メリットを伝えて納得感を持ってもらえるよう進めています。まぁ、とはいっても、カンリーのメンバーは全員がバリューを体現しているので、そもそも相談しやすい環境ではあるのですが。

吉村：
僕も同じです。ちょっと付け加えると、自分がバリューを発揮する以上に、相手にバリューを発揮してもらえるよう意識してます。たとえば、ネガティブなことでも相談しやすいように、まずは自分の懐を見せて、懐に入ってもらいやすくする感じです。信頼している人に対して、犬がおなかを見せるのと同じイメージですね（笑）。

本間：
懐に入ってもらいやすくするって、どんなふうにやってるんですか？

吉村：
言語化はむずかしいですね...。SREという役割の前に「どんな人なのか」を知ってもらうことが大事だと思っていて、そのためにあえて趣味や志向を積極的にみせるようにしています。そうすることで普段どんなことを考えていたり、している人なのかがわかると思うので。

その上で、エンジニア一人ひとりの性格、話し方、スピードを合わせる、いわゆるペーシングを心掛けています。話しかけやすさって、一人ひとり違うと思うので。
個人的には、有村さんのスタンスが気になります。

有村：
大事にしているのは、目的意識です。必要に駆られてやることも当然あるけれど、SREって基本的に、開発チームのように新しい機能を実装したりとかは少ないじゃないですか。なので、自発的に「こういうメリットがあるからこういうことをやる」「現状だとこういう課題あってこういうデメリットあるからこう変えていく」といった強い目的意識を持って取り組むってことが大事だと思っていて。

ここが欠けてると、「言われたからやる」だけになってしまったり、結果的に意味のないことをやってしまうことにもなりかねない気がするんです。バリューでいうと、圧倒的当事者意識（※6）ですかね。

（※6）圧倒的当事者意識：カンリーの5つのバリューのひとつで、一人ひとりがリーダーとして結果を出し、周囲の期待を超え続けることを示しています

本間：
めちゃくちゃ大事なことですね。ちなみに、目的意識を持つよう気をつけるようになったのはいつ頃からなんですか？

有村：
社会人になってからです。言われたことをひたすらやるのが、正直あまり好きではなくて。何のためにやるのか、誰の役に立つのかがわかっている状態こそが、あるべき姿だと思っているんですね。なにより、誰の役に立ってるかわからないことをやるのは辛いですし。

そこでいうと、SREはお客さまへの貢献が間接的になってしまいがちですが、エンドユーザーの人に課題解決に繋げたいという想いは強くあって。そのためにも、目的意識を忘れてはいけないなと。

吉村：
ひとつ聞きたいのですが、エンドユーザーの賞賛を受けない中で、どこでモチベーションのガソリンを補給してるんですか？ やる気に火をつけたり、落ちた時にどうやってたかめているのかなと思いまして。

有村：
賞賛されたり、感謝される機会は、開発チームよりは少ないですが、開発のメンバーがインフラで困っているときに手助けして感謝されるなど、完全にゼロではないので、そこでなんとか。あとは、インフラの技術を深掘りして学ぶことで、今後、誰かの役に立てる未来を思い描いてみたりとか。意外と機会はたくさんあるし、自分でつくることもできる気がしてます。

本間：
ここまでのやりとりを聞いていて、自分が主役というよりはサポートすることが前提の回答になっていておもしろいです。SREってこういう気質の人が多いんでしょうかね...。

吉村：
全体的な傾向はわからないですが、言われてみると、サポートする側のほうが好きですね。サッカーでもゴールを決めるより、ゴールにつながるアシストをしたときのほうが、はるかに嬉しかったですし。

有村：
私は目立つことをやるより、裏でなんかすごいことやるほうがおもしろい、逆張り思考のほうが強い気もしますが...。それでも、サポートするほうが好きというのは同じです。

プロアクティブにまだ見えていない課題解決に挑む

本間：
最後に、これからやりたいことを聞いてみたいなと。

吉村：
僕からいいですか？ データ基盤周りをちゃんと整備したいです。

本間：
吉村さんは、前職でデータ基盤構築の経験がありましたもんね。なぜ整備をしたいのか、詳しく聞きたいです。

吉村：
単純に、カンリーが持っているデータがすごくおもしろいからです。一例を挙げると、カンリー福利厚生では、人の行動ログが取れたり、趣味嗜好がわかります。このデータをカンリー店舗集客のデータと合わせると、「こういうユーザーに対して、▲▲というマーケティング施策を打てるんじゃないか」といった、判断材料になるデータがいっぱい取れるようになるんです。

こうしたデータを分析することで、ゆくゆくはユーザが真に利用している箇所や機能の分析ができるじゃないですか。さらに、データ分析基盤が整うことで、ユーザへの価値提供とともに、開発者やPdMがプロダクトの成長に向かうためのファクトが整うんですね。

こんなふうにおもしろいデータがたくさんあって、それを分析できる環境って、めちゃくちゃワクワクしませんか？ あ、でも、決して自分がデータ分析したいわけではないんですよね...。

本間：
あくまでも環境づくりが目的になっているのは、SREっぽいですね。有村さんは、どんなことに取り組んでみたいですか？

有村：
取り組みたいというよりは、こうありたいみたいな話なのですが。AWSのソリューションアーキテクトのようなイメージで、社内ソリューションアーキテクトみたいな人になりたいです。

具体的には、今まで課題だと認識されていなかったもの、いわゆる潜在的な課題を見つけて、改善を提案して、みんなの役に立てたらいいなと思ってます。

実は今も、「ここをこうしたら、もうちょっとコストを削減できそう」みたいな提案を時々していて。これを継続することで、開発者もエンドユーザーも、みんなを幸せにできたら嬉しいです。

吉村：
自ら動かないと、なにも変えられないですもんね。かっこいいです！
じゃあ最後、本間さん締めてください！

本間：
またハードルをあげられた...（笑）。
すでにやってることではあるのですが、開発チームのSREイネーブリングに引き続き取り組みたいなと思ってます。

今、エンジニアチームでは「当たり前の水準を高め続ける」というビジョンを掲げていますよね。このビジョンの実現に向けて、開発速度と信頼性のバランスを意識して、開発チームが自律的にそのSREを回してる体制を作りたいんです。

そのために、「この機能を追加するにあたってこういうリスクがあるから、ここを抑えるためにじゃあこういう仕組み入れよう」とか、「もっと可視化をしないと何か起きた時にわかんないから、可視化をより強化した上で機能開発しよう」とか。SREチームだけでなく、開発チームも含めた全エンジニアが、信頼性を意識した開発ができるような環境を整えたいです。

もちろん、課題もあって。信頼性を意識すると開発スピードとのトレードオフはどうしても発生してしまうんですね。考慮する箇所や実装するものが増えてしまうので。ただ、これも、信頼性を担保することの重要性をボードメンバーやPdMに理解してもらい、信頼性の担保を全体とした計画が作れるようになれば、時間は担保できるようになると考えていて。問題が起こる頻度を減らせれば、プロダクト、ひいては、経営にもメリットがある。つまり、中長期で見たらみんな幸せになることがわかれば、きちんと浸透していくと確信しています。

＊　　＊　　＊　　＊　　＊　　＊　　＊　　＊　　＊

SREチームが発足してから、約2年。これからプロダクトも増え、開発組織も拡大していく中で、SREチーム、そして、プロダクトや開発チームがどのように変化していくのか、とても楽しみです。また続報をお届けしたいと思っていますので、期待してください！