こんにちは！いい生活エンジニア採用・広報担当の黒江です🎆
暑い日が続いておりますが、みなさまいかがお過ごしでしょうか？

今回も前回に引き続き、いい生活のプロダクトを支えるメンバーと、CTO 松崎さんとの対談をお届けします！

CTO 対談第 4 回の今回は、SRE 部の隆辻さんと CTO 兼 SRE 部の部長でもある松崎さんに、当社の開発を支える SRE 部について語ってもらいました💬

今回の対談は 3 つの記事に分けてご紹介させていただきます。
こちらの記事は前編です！

SRE 部とは

開発や運用を行いやすくするための支援

黒江：
SRE 部はどのようなことをしているチームか教えてください。

松崎さん（以下 松崎）：
SRE 部は 2022 年 4 月に発足しました。SRE部発足までの経緯を説明しますね。

別の記事でも少し説明しましたが、2021 年 4 月ぐらいのタイミングで当社のインフラはオンプレミスのデータセンターからパブリッククラウドへ移行完了しました。

※データセンターからクラウドに移行したお話は以下の note をぜひご覧ください！

これにあわせて組織の再編も行い、プロダクトチーム制、いわゆるクロスファンクショナルチームでプロダクトの開発も運用もやる体制に変えたんですね。
この結果、いい生活のインフラを一任していたサービス基盤システム部とAPI 全般を担当していたサービスプラットフォーム開発部という部署の2つを解体・再編成することになりました。

今まではオンプレミスですから、当然データセンターに自社所有のハードウェアを多数設置し、これを運用管理していました。
なので、これをメンテナンスするには、専門職的なスキルがいるしそういうチームもいるよねみたいな世界観だったわけですね。
だけど、クラウドに移行したことによって、従来行っていたハードの調達や保守運用に該当するような作業がなくなり、ソフトウェア的な作業として開発者自身ができるようになったので、従前ほどハードウェアに特化した知識やスキルがいらなくなりました。

また、実際にアプリケーションを開発運用してる人たちが、システムを設計して運用していく上で、インフラもどういう風に設計した方がいいか、自分たちで考えてできる方がいいと考えました。
プロダクトを育てていく中で、ソフトウェアの要件が変わる、規模が大きくなってアーキテクチャそのものを見直す必要がある、といったことはよくある話です。
そうなった時に、開発チーム自身が自分たちの責務でできた方がやりやすいでしょうし、そうすべきだなと。

そういう意図や背景もあってプロダクトチーム制に変えたわけです。

この体制に変えて 1 年ぐらいやっていく中で、当然といえば当然なんですが色々な課題が見えてきました。
一番わかりやすい例で言うと、開発組織全体で使うソースコード管理システムなどのさまざまなツール類を定期的にメンテナンスする責務が曖昧になってしまった、とかでしょうか。

従来はサービス基盤システム部がメンテナンスしていたんですけど、移行後は「今あるものをそのまま使えばいいでしょう」ぐらいの感じになってしまったんですね。
でもやっぱり、開発メンバー全体で共有して使わなきゃいけないものっていうのは、誰かが責任を持ってメンテナンスしないと駄目な訳です。
「それは当たり前だ」って言われればそうなんですけど、責任の所在があやふやになってしまった。
なので「この状況はやはりよくないので変えなきゃいけないね」という課題感がありました。

あと、各プロダクトチームが実際にそのプロダクトの開発・運用やアーキテクチャ、インフラも見ていく中で、「これは明らかに知見が足りてないぞ」ということが分かってきました。
理想は各プロダクトチームにそこが得意な人を 1 人以上配置できればいいんですけど、もともとバックエンドやインフラを見ていたチームメンバーを分散して再配置したんですが、それでも足りていない。
かといって、もともと得意ではない人のキャッチアップが十分かというと、なかなかそうもならない。

これは、これまでのサービス基盤システム部とは違う形で、こういった課題に取り組むチームを作る必要があるな、と考えました。
この結果、2022 年 4 月に、こういった課題に対する知見や興味、やる気がありそうな人を CTO の独断と偏見により 3 人ピックアップして発足したのがSRE部なんです。
ちなみに、部長は CTO である僕が兼務してます。

ただ、単に「便利ツールを提供してくれるチーム」にしちゃうと、いい側面もあるけど悪い側面もあるかなと思っていました。
いい側面の例は、「プロダクトチームが開発することに集中しやすい」ということ。
一方の悪い側面の例は、「ブラックボックス化が進みすぎると、そもそもどういう仕組みで動いてるのかだんだん分からなくなる」ということ。

なので、SRE 部の発足にあたっては、
「開発部門全体で共通的に利用できないといけないさまざまな仕組みはちゃんと提供していきます。
ですが、僕らはあくまでも支援組織です。
ソフトウェアやアーキテクチャも含め、各プロダクト固有の部分については相談には乗るけれど、基本的にはプロダクトチームの皆さんが維持運用改善してくださいね」
という立ち位置にすることにしました。

そして、SRE 部としてはこういった技術や知識の支援する方法論として、口頭伝承やドキュメントを作るのではなく、テンプレートやボイラープレートあるいは、開発者が実装を簡単に行えるようなツールの形で、あくまでもエンジニアリング的に取り組むこととしています。
そして、それらの使い方を説明していく過程で、知識や考え方といったものをチームにインストールする、という形で支援することとしました。

組織変更前は、こういったことはどちらかというとブラックボックス型だったんですけど、SRE 部は道具と知識の両方をオープン型で組織全体に浸透できるようにうまく持っていく、というコンセプトのもとやっています。

隆辻さん（以下 隆辻） ：
そうですね。
少し補足すると、そもそもエンジニア界隈で広く知られている SRE の概念は、Google によって初めて「DevOps っていう概念を実装するものだ」のように言及されてますが、それとは似てるけど少し違う感じですよね。

松崎：
あの文書は、従来 O㎰ チームと Dev チームが分離されている世界観の中で、DevOps をより高速によりよく回すためには、作業者としての Ops チームではダメで、Dev と Ops をもっと融合した上でそれをエンジニアリング的な手法で取り組む Ops チームが必要であり、それが SRE である、って感じだよね。

その点、当社の場合は Dev と Ops がそもそも別れてない世界観が先にあり、そこに足りない要素を補う形で SRE 部が発足しています。
例えば、アプリレベルでの監視やそのインシデント対応、CS からのエスカレーション対応などは、従前から開発チームが担ってましたからね。

なのでそういう意味では、世間一般で言われている SRE がやってることと当社の SRE 部を比べると、目指すところは一緒かもしれないけど、もしかしたら活動内容自体は若干違うのかもなと思っています。

隆辻：
確かに、最初からプロダクトチームがある程度運用に関する知見を持っていたのはあると思います。
そのうえで、例えば運用知識をプロダクトチームごとにサイロ化しないように、知見を一旦吸収しデファクトとして広めていく役割を担うのが、SRE 部の目的としてあるって感じですよね。

松崎：
そういうことだよね。
ちなみにこの説明をしても、社内でほとんど理解を得られてない気はしています（笑）。

エンジニアだと何となくわかってる人も多いけど、まだ開発経験や運用経験が浅いメンバーだとピンときてないこともある、みたいな。
非エンジニアだと、ほぼ理解されていないって感じかな。

なので、人によっては「監視のシステム（Splunk）を運用してる人たちでしょ？」や「何かアカウントとかを発行するとき依頼する人たちでしょ？」などのように見えていると思います。
Splunk も必ずしも監視のためだけではないんですけどね……。
もちろんそういう業務もあるんだけれども、もっともっと他のいろんな活動もしている、ということを知ってほしいので、まだまだ僕らの旅は始まったばかりと思ってます。
こう書くと、最終回っぽさありますけど（笑）。

新しい仕組みを導入し、よりスムーズな開発環境を提案

松崎：
さて、ここまで SRE 部が何を目的として何をするチームかを話しましたけど、じゃぁ具体的に何をやってるかって、多分イメージついてないですよね？

黒江：
そうですね……。まだあんまりイメージはついてないです。

松崎：
具体的に言うと、さっきも話した通り SRE 部には 3 人のメンバーがいます。
その 3 人で共通の目標もありますが、それぞれの得意スキルなどに合わせて、それぞれのメンバーがちょっとずつ違うことをやっています。

隆辻がメインでやってるのは、当社のソースコード管理ツールである GitLab  をうまく使いこなす中でも、特に CI / CD やビルドプロセスを中心に担当してもらってます。

直近の SRE 部の目標の一つに「この GitLab を単なるソースコード管理システム以上にいい感じに使い倒す」というのがあります。
ビルドプロセスの改善は、この中でも重要な側面です。

ソフトウェア開発をする上での基本的なサイクルは「コードを書き、ビルドをして、正しく動くかテストする」というものなので、ソースコード管理やビルドの仕組みはこの基本的なサイクルを支えるものになるわけですね。

で、この「ビルドをする」っていう部分なんですが、通常は単なる待ち時間なんですよね。
なので、この待ち時間をなるべく減らしたいし、なんならビルドプロセスの中でテストも極力実行しちゃいたい、となるわけです。

つまり、開発効率の向上と品質の担保を、自動化の面から仕組みを整え改善するのが隆辻のミッションということになります。

隆辻：
前提として、当社が今使っているソースコード管理システムやビルドシステムのツールの多くは、基本的には以前のサービス基盤システム部が管理していたものです。
当時はいわゆるセルフホストで使っていたサービスなんですね。

セルフホストのメリットとしては、例えば自分たちの使いやすいように環境をカスタマイズできることや、セキュリティを担保するために必要な対策が比較的自由にできることなどがあります。
その一方で例えば、バージョンアップに対するコストが結構かかってくることや、必要なリソースを確保するための方法が、最適ではないことがあります。

そのような背景の中で、新しいやり方を導入したいと思っていても、それをうまく導入できるようなコストをかけられる状態になっていなかったという問題がありました。
まずはその点を解消していかなきゃいけないっていうのが、一つ大きくありましたね。

さっきも出てきましたが、当社ではソースコード管理ツールとしてGitLabを利用しています。
以前はセルフホストしたものをプロダクトチームに提供していましたが、今は SaaS 版をメインで利用しています。
このため、セルフホストしていた GitLab から SaaS 版へ、ソースコードだけでなく Issue/Merge Request などの開発に必要な情報をリポジトリごと移行する作業を支援したり、自分たちで行ったりということをしています。

また、ソースコードをビルド/コンパイルしてソフトウェアができるわけですが、ソフトウェアを配布可能な形式にすることをパッケージングといいます。
ソフトウェア自体もさまざまなモジュール、いわば部品みたいなものでできているので、これを複数のソフトウェアで利用できるように部品のレベルでもパッケージングしたりします。
このパッケージの管理・保管を行うのがパッケージリポジトリなんですが、これまではこれも社内でセルフホストしていました。

ですが、開発部門も大きくなり、アプリケーションも多くなってきた上、ソースコード管理システムも SaaS 化したことでセルフホストでは限界が見えつつあります。
ここが問題になると、開発のときにライブラリが取得できないなどの問題になり、開発に制約が生じる可能性があります。

そのため、ここも新しい仕組みを導入し、よりスムーズな開発環境を提供しようとしています。
このような改善は、実際にプロダクトチームに入って、これらの課題を解決するための提案や作業を行う形で進めています。

社内の開発環境を支える縁の下の力持ち

開発環境全般の SaaS 化

松崎：
そういう意味では、もう少し大きなゴールとして、開発環境全般の SaaS 化みたいなこともあったよね。

さっきも言ってたけど、セルフホストをしていて大変なことの一つがバージョンアップだよね。
そういや、隆辻が 1 年目のときに GitLab のバージョンアップ対応をしたことがあったよね？

隆辻：
そうですね。
通常、こういう開発ツールのバージョンアップの際は、使っているチームに対して「いつぐらいまでは作業できなくなりますよ」というダウンタイムを提示して、作業をします。
あの時は、結構大掛かりなものだったのでダウンタイムを3時間と少し長めに見積もってプロダクトチームに案内していました。
ところが、バッファ込みで 3 時間の停止で終わると想定していたメンテナンスが、実際は 9 時間もかかってしまったんですよね。

こういうことが一度起きると、次のアップデートのハードルが、実務的にも心理的にもさらに上がってしまいます。

そうなると、ただでさえ自分たちが作っていないソフトウェアをホストして管理することはコストが高いのに、追加のコストが見えない形で入ってしまいます。
そもそも、そのアップデートを提供するために行う検証作業そのものにも結構コストがかかるのもありますし。

その結果、自分たちが使っているツールを頻繁に新しいバージョンにアップデートして、より使いやすい機能を開発者に提供し続けるという責務が果たせなくなってしまいます。

このようなことがあったので、最終的にやっぱりセルフホストするのは効率悪いよねとなり、GitLab SaaS を使いましょうと流れに変わりました。

松崎：
どちらかというと、GitLab に限らずいろんなものを SaaS 化してるということだよね。

隆辻：
最初に松崎さんが言ってた、当社のプロダクトのホスティング環境をデータセンターからクラウドに移行したことが契機になって、ようやくできるようになったと思います。

松崎：
そうだね、クラウド化するにあたって、オンプレ時代のようにイントラネット前提ではない形でネットワークも再設計したので、ネットワーク的な制約はなくなったから SaaS の利用がしやすくなったよね。
むしろ、ちゃんとセキュリティ担保しつつインターネットに開いた環境でないとダメになった、というか。
なので、セルフホスティングの方が辛い部分が増えたかもね。

あとは、ソフトウェアは月に1回以上アップデートがあるので、自分たちで管理するのはかなり辛いんですよね。
毎月毎週そのメンテナンス作業をしていたら「俺は何をしてんだろう、ソフトウェアのバージョンアップ屋さんなのか……？」みたいになってしまう。
そこに自分たちの時間を割くよりは、 SaaS 版を利用し、もっと違うところにメンバーの能力を使っていった方がいいよねとなりました。
どちらかというと、SaaS 版を安全にうまく利用するためのガイドをソフトウェア的に整備することを SRE 部でやっています。

さっきも話に出たけど、既存のレポジトリを移設するにしても、各プロダクトチームは毎日開発を継続してるので、ソースコードだけでなく、Issue や Merge Request などひっくるめて持ってくる必要がある。
コードの変更履歴は Git で管理してるから、それ自体を持ってくるのは全然難しくない。
けど、過去のレビュー記録などもちゃんと持ってこないといけないから、その辺りは結構大変ですね。

あと、SaaS 版の利用に変わったことで、さまざまな機能が日々アップデートされるわけだけど、これにうまくキャッチアップするのも中々難しい話だったりします。

プロダクトチームの開発者は、アプリケーションの機能の開発や使いやすさの改善など、そういうところにエネルギーを割いているので、それ以外のことは優先順位が後ろになってしまいがちです。
その結果、ビルドシステムが古いままだったり、新しい機能を使いこなせてなかったり、といったことがどうしても発生しちゃうんですよね。

そこを、プロダクト開発とは独立した SRE 部が横から支援してあげることで、この部分にリソースや時間が割けないプロダクトチームに代わって、改善のフォローができる、というわけです。

テストの自動化の支援

松崎：
あとは、今年に入ってからですが、品質保証部に対するフォローを深めていますね。
品質保証部はお客さんの観点でプロダクトを使って問題がないことや、最終的に会社としてプロダクトを世に出していくときのゲートキーパーの役割なんです。
なので、テクニカルスキルも一定重要なんだけど、どちらかというと不動産業務そのものや当社プロダクトに対する知見が重要な仕事なんですよね。

当社プロダクトがどんどん増えていって機能もどんどん増えていくと、「新しい機能を追加したけど、元々あった機能が正しく動いてるかどうか」を確認するリグレッションテストが課題になってきます。
当たり前なんですが、機能を増やしていけばいくほど、元々あった機能が新しく動いてるかを確認するためのテストが、雪だるま式に増えるんです。
どんどんテストのボリュームが増えいく中で、それを人手でカバーするのはどうしても限界があります。

なので、品質保証部に対する支援としては、こういった E2E のリグレッションテストを自動化してメンテナンスするための仕組みを用意しています。
そうすることで、最初はどうしても人手に頼らざるを得ない、新機能や機能改善内容のテストに品質保証部メンバーが注力しやすくなる、というわけです。

隆辻：
この部分は、品質保証部と共同で取り組んでいて、テストの作成そのものは品質保証部メンバーが作り込み、その仕組みを提供していく部分やうまい使い方を模索する部分は SRE 部が支援する形です。
ここは、僕がメインで取り組んでいることの2つ目ですね。

松崎：
そういう意味で言うと、僕らがやってることは、大きく2つあるのかな。
一つは、開発者がコードを書きビルドしテストするために必要な諸ツールを整理して、必要に応じて提供すること。
もう一つは、プロダクトチームがコードを書き終わってから、最終的にデプロイしリリースに至るまでのプロセスの効率化の支援をすること。

このように、開発をしやすくする仕組みを提供することで、開発の一連のサイクルをスムーズに回せるようにしています。
ただ、こういった活動は、完成したプロダクトの実際の機能みたいなわかりやすい形では見えてこないので、特に開発をしていない人からすると、SRE部が何をやってる人たちか理解されにくいんでしょうね。

SRE 部は品質にも関わってるけど、実際そのテストを書いてるのは品質保証部の人だし、開発にも関わっているけど、アプリケーションコードを書いてるわけでもないし。

なので、SRE 部は当社の開発プロセスを支える縁の下の力持ちなのかも知れないですね。

続きが気になるところですが、今回はここまでとさせていただきます！
読んでいただき、ありがとうございました😊

いい生活では新卒 / キャリア採用を行っております🧑‍💻
以下から気軽にご応募ください！

また、いい生活公式note の「いいnote」のフォローもお願いいたします！

それでは今回はこちらで失礼します！
次回はこちらの対談の続きです！

撮影：杉山 泰之