こんにちは！いい生活エンジニア採用・広報担当の黒江です🐰

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

今回の対談は 3 つの記事に分けてご紹介させていただきます。
こちらの記事は後編です！
前編・中編の記事は以下よりご覧ください💁‍♀️

新しい技術を積極的に知ることができる環境

技術やトレンドへのアンテナを張る

黒江：
では、SRE 部だからこそのプロダクトチームとはまた違う面白さや、やりがいはありますか？

松崎（以下 松崎）：
いろんなトレンドや技術がある中で、自分たちで選定して入れてみて、それがうまくハマれば面白いよね。

隆辻（以下 隆辻）：
そうですね。そういう新しいものを積極的に知ろうとできることは面白いと思っています。

どうしてもプロダクトの開発に注力すると、プロダクトに関わることしか見えなくなってしまう。
ロードマップに沿ってやる部分もありますけど、例えば「お客さんからこういう要望が来てます」や、「売上目標達成のためには、これが必要です」みたいな、そういった外部要因がプロダクトの開発ではあると思います。

それとは少し離れた場所に僕らは立っていられるんで、その分だけ新しいツールや「これから先、こういう動向が来そう」みたいな部分を早めに知ることができます。
そして、それをもとに、プロダクトチームに提案することもできますし。

松崎：
そうね。逆にいろいろ見なきゃいけないから、考えることも多いけど、そこが一番面白いんじゃないかな。

黒江：
そういう技術的な知識を学ぶ機会は、どのように得ているんですか？

松崎：
SRE 部はみんなアンテナを張っているね。そもそも、そういうメンバーを集めてるからだけど（笑）

隆辻：
社内だと特に僕らが使っているクラウドプラットフォームや、あるいは今使ってる SaaS のサービスのアップデート情報は基本的に Slack に通知が飛んでくるようになっています。
Slack を見れば新しい情報に関して通知が来ているので、それを見ると大体分かります。

あとは、特定のジャンルに絞ったカンファレンス、技術系の勉強会に参加しています。
サービスを提供している会社の広報の方のお話や、あるいはユーザー企業の社員さんが「当社ではこう使ってます」みたいな事例を紹介するイベントがこの業界では結構盛んなので、それを聴講していますね。

ここ最近でいうと、翔泳社が主催する Developers Summit（デブサミ）を聴講してみました。

黒江：
隆辻さんの Developers Summit を聴講されたという DocBase（社内のドキュメント共有する媒体）の記事を見ました！

松崎：
実際の支援もそうだけど、そういう風に情報やナレッジ知識の共有も、なるべく盛んにしようとしている。
SRE 部だといろんな締め切りに追われてなくて自由に動ける分、それに甘えずにたくさん貢献しなきゃいけないと思っています。
なので DocBase の記事は、ちょっとした内容であっても、いろいろとあげるようみんな心掛けていると思います。

キャッチしてきた情報についてエンジニア同士で語る

黒江：
いろいろと技術的な情報を得ている中で、情報の善し悪しみたいなものはどのように判断しているんですか？

隆辻：
勘としか言いようがないかなと思います。

とはいえ、当社は Web 系の技術、Web をベースにしたプロダクトの提供を中心に行っているので、例えば「Google がこう言ってます」みたいなものは参考にしています。
Google はブラウザや検索も持っているので、Web のアプリケーション開発をする上で、気にしなきゃいけないプレイヤーの一つですね。

なので、「こういう方針の修正を Web 業界でやろうとしてます」などは結構知っておいた方がいいなと思います。
他には、いい生活Home / Owner だったらスマホのアプリを作ってるんで、Google だけでなく Apple の発表などを気にするというのもあります。

それに、今の時代だと IT エンジニア系の人が、インターネット上でさまざまな内容を発信をしています。
そういう人の発信などを追いかけることで、何となくトレンドを見ることも一つあるんじゃないかなと思いますね。

松崎：
あとはキャッチしてきた情報をSRE部の中で喋ったりすることによって、良いか悪いかみたいな話をしてるケースもあるよね。

隆辻：
SRE 部に限らず、社内には結構そういう情報感度が高いエンジニアが複数人所属してるので、そういう人と Slack 上でコミュニケーションをとることもありますね。
それも個人の中である程度考えの軸があって、それに対して良いか悪いか選択できているのだと思います。
そういう軸をどう作るかはちょっと難しい話だと思いますけど、まずは興味を持つことが大事なんじゃないですかね。
あとはタイトルだけでもいいから、流れている情報をひたすら見てみると、何となくトレンドが見えてきますね。

よりよい開発者体験を届けるために

プロダクト開発の経験を生かしてSRE 部に

黒江：
なるほど、ありがとうございます。
ところで話は変わりますが、隆辻さんは「SRE 部に入りたい」といった希望を出されたんですか？
それとも「SRE やってみない？」と提案されたのですか？

隆辻：
希望を出してはいないですね。
新卒で入ったサービス基盤システム部が解体した後に、コミュニケーションプラットフォーム本部という別の部署に入ったときに「SRE 的なことをちょっとやってください」と言われてからですね。

僕はもともと「どうするとコンピュータをよりよく使えるか」「どうやったらコンピュータがしていることをうまく観測できるだろうか」「うまくリソースを使うにはどうするんだろう」「そもそもこれって仕組みとしていいのか」などに強い興味がありました。
なのでその「SRE 的なことをする」ということをやるように言われたその方向性は分かるな、と思いました。

松崎：
前半で話した「CTO の独断と偏見により」人選した部分の話ですね。

SRE 部を編成した 2022 年 4 月の前に 1 年間、クラウド移行のあと部署を解体しメンバーを分散したときに、メンバーがどういう雰囲気かを見ていました。

見ていく中で、どちらかというと開発そのものよりも、開発環境の整備や開発の仕方自体を良くしていくことにエネルギーを割いている人が見えてきたんですね。
その中から、僕がこのメンバーを集めて SRE 部を発足すると決めたのが 2022 年 4 月。
そういう意味では別にやりたいと言っていたわけではないけど、それっぽいことをしていたし、アウトプットを見てると適性もありそうだから、「やってもらおう！」と決めた感じですね。

黒江：
そうだったのですね。
SRE に興味があって働きたい！と考えている人もいるかと思うので、実際にはどういう人が向いてるのか聞いてみました。

松崎：
向き不向きで言うと、もう一つ大事なこととしては「開発を全くやったことがないと、実はあんまり活躍しづらい」というポイントもあります。

実際のプロダクトの開発・運用をやっていないと「SaaS サービス / プロダクトを自社で開発・運用をするには、どういうことを考える必要があるか？サービスやプロダクトを育てていく過程で何が起こるか？」の経験や知識がないことになります。
その状態で、SRE 部に入るのは難しいですね。

SRE 部のメンバーに求められるのは、「開発者がプロダクト開発・運用の中で遭遇する問題や面倒なこと」に対して、本人たちが気づいているか気づいてないのかに関わらず、コンサルタント的にそういったものを見出し、より良くしてあげる能力です。

でも、やったこともないことの問題点に気づき、それを良くすることは、かなり難しいと思っています。
例えが悪いかも知れないですけど、僕は料理は一人暮らし時代に必要に迫られてちょいちょいやった程度の経験しかないんですが、そのレベルの僕が「この辺をこうすると時短できてタイパいいし、片付けも楽になりますよ！」なんてアドバイスできるわけないですよね。

「やっててこういうところが面倒じゃないですか？」という課題を見つけ出し、「それを簡単にするために、実はこういう方法があって」という風に解決策を提示して、さらに「なるほど！」と納得してもらう。
ここまで含めて 1 セットなんです。

だから、「ある程度開発経験があり、プロセスや方法論の課題を見つける力もあった上で、課題解決経験もある」人が、SRE 部に向いてるかなと思いますね。

仕組みを整備してより品質と効率を高める

隆辻：
そうですね。あとは楽をするために努力を惜しまない人じゃないですか？

松崎：
「今それを頑張っておけば後で楽になる」というやつだよね。
世の中、ちょっと面倒でも頑張ってパワーで片付けちゃうタイプの人っているじゃないですか。
そういう人は SRE 部に向かないんですよ。
「繰り返しの作業が本当に嫌」や「待ち時間もったいない」「もうちょっとこうすれば楽になるはずなのにな」など、何かその自分が楽する方向にエネルギーを割ける人じゃないと多分難しいですよね。

逆に、単純作業を繰り返す方が楽という人も、もちろんいると思っていますし、それを否定するわけでもないです。
「考えるより先に手を動かしていれば終わりに近づくわけだから、多少その作業は多いかもしれないけど、別に考えなくていい分、楽」と感じる人もいると思うんですよね。

ただ、SRE 部の志向性は逆です。
「同じことの繰り返しなどを人間がやるのが勿体ないから、そこをソフトウェアや機械に自動でやってもらって、その時間はもっと生産的な活動に時間を割く」という方向に持ってきたがる人。
仕組みを整備して、人間がわざわざワンアクションしたり、何か繰り返し作業などをしなくても済むようにする志向の人たちなので、そういう感覚がないとなかなか向かないですね。

逆に、UI をいい感じにするのか不得意な人が多い気もしますね。
レポートなどをどう出すかは考えられるけど、使い心地の良い UI を考えるのは苦手、みたいな。

隆辻：
「結局人間ってコストが高いよね」や「人間って間違えることもあるよね」といったことをうまく機械で防ぎたいというのが大きいのかなと思いますね。

松崎：
「人間が能動的にアクションしなくていい方向に進める」部分に力を入れていて、「人間が作業をする」ためのわかりやすさにはエネルギーを割いていないよね。

人間がやる仕事と人間そのものに着目してるんだけど、解決策の方向性が「人間にやらせない」方向の人たちなんだろうね、SRE 部は。

隆辻：
繰り返し作業や間違えないことは人間より機械の方が上手なので、上手なことは上手なものに任せたいみたいな。

松崎：
そうだね。SRE 部としては、その思考で活動することで、開発運用の効率と品質にコミットしたいですね。

どんな人でも使いやすいツールを提供する

隆辻：
最終的な僕らのアプローチってどうなるんですかね。
SRE 部が、本当はいらないぐらいの組織の方がいいのかなと思いました。

DevOps の理想的なサイクルをプロダクトチーム自身がうまく運用できるんだったら、基盤プラットフォーム的な部分の整備ではない支援活動などは、実はそんなにいらないかもしれないという気持ちはありますね。

松崎：
でも、今後も 新しい概念やツールを布教することは、ずっとやっていく気がするけどな。
みんなが勝手気ままに走り出すとそれはそれでまた大変なので、ガードレールも必要だから一歩先に布石を置いておく感じかな。

あとは開発をするためのプラットフォームみたいなのは、結局誰かが用意しなきゃいけないんじゃないかな、と思うんですよね。
それをどういう形で提供するか、どこまで提供するか、どこまで伴走するか、みたいなところは、なるべくミニマムで済む状態に期待はしたいけど。

最近、読んだ本の一つで「チームトポロジー」というがあるんだけど、その中でチームの形・役割として、プロダクトの開発そのものをやってるチーム以外に、「複雑な技術をシンプルに提供する共通プラットフォームを整備することで開発者の認知負荷を下げるチーム」や「ファシリテーションを通じて、開発チームが新しい概念やツールを利用するのを支援するチーム」の存在が重要という話があって。

全てのエンジニアが、DevOps に精通し、開発から運用まで一通りのサイクルを全部見据えた上で、ソフトウェアアプリケーションコードを書けるわけではない。
全てのエンジニアが、常に新しい技術を理解してチームに導入できるわけでもない。
あとは、多様性を重視するクロスファンクショナルチームにおいては、個々人の関心の差もあるかもしれない。
フロントエンドに関心がある人もいるし、データに強い関心がある人もいるし、人によって関心のポイントはさまざま。

そう考えたときに、チームの中には DevOps や新しい技術に精通している人が多くいるチームもあれば、一部は理解している人とそうではない人で構成されたチーム、フロントエンドに関心の強い人が集まったチームなど、いろいろなチームができてしまうのは必然だな、と。

もちろんチーム編成する上で、作るものに対して適切な配分をしていくわけだけど、リソースは無限ではないし、そもそも人間は 1 人 1 人個性があって、その欲しい人が常に必要な分だけ組織にいるわけじゃない。

だからそうなったときに、どうしてもその理想と現実のギャップや、チームによる差は、濃淡ができる。
その濃淡に合わせた形で、よくわかってて深く使える人はそう使えばいいし、そうでもない人でも使えるツールを用意することは必要だよね、という話かなぁ。

また、そういうプラットフォームを用意したとしても、それを使ってもらうために、コンサルティングしたり伴走する人もやっぱり必要だよね。

例えば、Kubernetesで、僕らがクラスタそのものと、それに加えて 調整済みの Helm チャートや 独自の Operator みたいなものを用意しておき、それを使いたい人はそれを使えばいいし、自分で全部 yaml で書きたい人はどうぞ、みたいな提供の仕方にするのもプラットフォームの一つの姿なのかなと思う。

そういう意味で SRE 部は「DevOps のためのツール類を as a Service の形でたくさん提供すること」が、究極的には理想なのかなと思いますね。
それやるのは、とっても難しいんだけど（笑）

開発者がより安心し、より素早くプロダクトをリリースできる環境作りを

黒江：
今の話と少し重複するかなと思うんですけど、今後社内のどういうことに取り組みたいですか？

隆辻：
究極的にはリリースサイクルをもっと早めたいですね。

松崎：
僕はリリースというよりは、デプロイサイクルを早めたいかな。
僕の中でやっぱりデプロイとリリースは分離したくて、まずはデプロイサイクルの方を早めたい気持ちです。

デプロイというのは、サーバー環境に配備していつでも公開可能だけど、まだ使えるようにはなっていない状態。
対して、リリースは、デプロイされたものを全てのユーザが使える状態。

デプロイからリリースするまでにいろんな手法があるよね。

もっとも単純なものだとインプレースデプロイで、今あるものを置き換えるから、デプロイ = リリースのパターン。
ロールバックするのに、古いバージョンを再度デプロイしなきゃいけないので、あまりお勧めできないけど。

他にも、Blue / Green、Canary リリース、プログレッシブリリースみたいに、新バージョンをデプロイした上で、テストして安全性を確かめてから、切り替える方式だってあります。
他にも、フィーチャフラグなど、ソフトウェアの設定として機能を Off にしたままデプロイしておいて、後で有効化する方法もある。

こういった「デプロイとリリース」に関して、概念をちゃんと整理した上で、「プロダクト特性、今のステージ、今のチーム規模に合わせて、最適な方法を選択できる」ように、ちゃんと説明していくことがまずは大事かな、と思います。もちろん、概念だけでなく、仕組みや手段の整備も足りていないとは思うけど。

なので、今の DevOps プロセス全体を見つつ、ツールの整備とメンバーの知見を高めて、開発サイクルを上げていきたいですね。

隆辻：
それは必要ですね。より品質の高いプロダクトを、より高頻度にデプロイできるようにする未来を作るのが一つの目標。

もう一つは多分、新しい開発者が新しくチームに入ったときに Day1 から開発がスムーズに進められる状況を作るための支援をうまくやるという感じですかね。

松崎：
やっぱりそのプロダクトの知識や使ってるユーザーの知識が必要になるから、そこだけに集中できる環境の提供をしたいよね。

隆辻：
CI / CD の観点で言ったら、当社の全てのプロダクトが CI / CD から、リリース、デプロイされるような環境を作りたいですね。

松崎：
そうだね、なんかリリースやデプロイにまつわる「面倒なこと」は色々ありそうだから、なるべくなくしていきたいよね。

隆辻：
そうですね。もっと開発者が安心して素早くプロダクトをリリースできる環境作りを目指していきたいですね。
安心はできるんだけど、リリースに時間がかかると結局、僕たちのプロダクトの価値も落ちていきますからね。

松崎：
かといって、たくさんリリースできてるけど品質が低いと信頼も落ちてしまうし、変更失敗率も見ないとデプロイ回数も多いけどロールバック回数も多いなんてことになりかねない。

大事なのは、そこのバランスもとれた仕組み作りかな、と。
だからある意味、品質保証部と僕らの仕事は両輪なんですよね。

隆辻：
結構難しいところではありますが、彼らの取り組みを僕らがサポートすることを引き続き行い、これからもそれらをより伝えていきたいです。

松崎：
あと SRE 部は、DevOps のサイクルにおいて、その流れをスムーズにする係でもあるんですよね。

速度そのものを上げるのはプロダクトチーム自身なんですけど、そこでアクセル踏みやすくする、フルスロットルにしても大丈夫にしてあげることが仕事かな、と思いますね。

こちらで松崎さんと隆辻さんの対談は以上です。

松崎さん、隆辻さん、ありがとうございました！
ここまで読んでいただいたみなさまも、ありがとうございました😊
いい生活の SRE 部の魅力が伝わっていたら何よりです🙆‍♀️

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

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

それでは今回はこちらで失礼します！
次回の記事もお楽しみに！

撮影：杉山 泰之