理想は「SREチームをなくすこと」、一人目SREとしてたどり着いた真理｜イオン・エンジニアインタビュー

2024/3/1

インタビュー

#SRE

#イオンスマートテクノロジー

この記事に登場している人

齋藤光

Hikaru Saito

イオンスマートテクノロジー株式会社 Developer Enablementディビジョンディレクター
SIer2社を経た後、ネット系金融会社でインフラ/運用部門責任者やプロダクトマネージャーを経験。その後、小売業で全社共通プライベートクラウド基盤の設計・構築・運用に携わった後に2022年5月にイオンスマートテクノロジーへ入社。

齋藤光

Hikaru Saito

SREチームの1人目のメンバーとしてチームビルディングに携わってきたイオンスマートテクノロジー（以下、AST）齋藤光。

入社当時には多くの課題に直面し、"長期戦"で改革に向けた活動を進めていくことを決意しました。泥臭く地道に取り組むなかでも、確実によい方向へと変化している実感があるといいます。

入社当時はExcelでの管理やチャットでの仕事依頼などが普通、ドキュメントを残す文化もない……。それを変えることができたのは、経営層の理解を得られたことと、「まずはつくって見せる」姿勢だったと振り返ります。

「理想はSREチームをなくすことだ」と語る齋藤が、入社から地道に積み上げてきたことを聞きました。

【目次】

開発チーム自身がオーナーシップを持って取り組める文化とマインドを
経営の理解を得ながら「まずはつくって見せる」ことでスピーディーに進める
理想は「SREチームをなくすこと」

開発チーム自身がオーナーシップを持って取り組める文化とマインドを

――齋藤さんは、2022年に1人目SREエンジニアとして入社し、チームの立ち上げに携わってこられました。

齋藤：私が入社した当時のイオンは、技術と人の両面でさまざまな問題を抱えていました。

技術的には、セキュリティやインフラの設定が適切ではなかったり、開発したサービスの要件を把握できている人がいなかったりといった状況。クラウド、マイクロサービス、コンテナなど技術スタックとしてはそれなりのものを使っているように見えましたが、それらを手段として活かすためのルールや仕組みも不十分。

また、目的が曖昧になってしまっている会議があるなど、組織内の人と人とのコミュニケーションも十分にできているとはいえませんでした。人手不足のなかで経営陣からの要望に応えようと努力した結果だと思うのですが、さまざまなことが複雑化してしまい、どうしてよいのかわからない状態に陥っていたといえます。

――そうした状態をどのように解消されていこうとされたのですか。

齋藤：銀の弾丸はないので、1つずつ解決していくしかありません。「あれもできていない、これもできていない」という状況だったので、まずは重要なところ、あるいは条件的にやりやすく小さな成功体験を積めるところから着手しました。最初から100点を目指さずに、「まずは0を1にする、そこから少しずつ積み重ねていこう」というマインドで改革を進めていきました。

――具体的にはどのようなことに取り組まれましたか。

齋藤：当初は、口頭やチャットツールによるやり取りがメインで、チケットやドキュメントで記録に残しておくという習慣がなく、結果としてなぜその作業が行われたのかが半年後にはわからなくなっているような状態が生じていました。まずはこの問題から着手することにしました。

具体的には、前CTOが導入していたJiraとConfluenceを使い、チャットでの仕事依頼を原則禁止。チケット管理とドキュメンテーションの習慣化に向けて、前CTOとともに使い方の説明会を実施しトレーニングを行っていきました。

Confluenceは、まずは雛形となるようなものをつくろうという意識で、自分がオンボーディングで得た知見を次の人にいかせるように100ページにわたるドキュメント化を率先してコツコツと進めていきました。コミュニケーションのルール自体もドキュメントにまとめています。

これにより、ドキュメントを残すカルチャーがほとんどなかったところから、次第に真似をしてやってくれる人たちが出てくるようになりましたね。

――その他にはいかがですか。

齋藤：監視・モニタリング基盤の統一に取り組みました。

もともとアプリケーションのパフォーマンスや障害状態を把握するにあたって、
　- モニタリングの仕組みが組織全体で統一されていない
　- ツールがバラバラ
　- 監視項目が足りていない
といった課題がありました。どこで何が起きているかが正確に把握できていないと、障害調査が困難になりますし、そもそも障害に気付けないケースも生じえます。経験と勘をベースに障害の影響を特定しようとすると、声の大きな人の意見に右往左往してしまう状態になり対応が遅くなりがちで、結果としてお客さまにご迷惑をかけてしまうことになります。

そこで、システムごとにバラバラだった監視・モニタリング基盤をNew Relicに統一。障害調査の短縮化に向けて、モバイルからバックエンドまでの情報を1つのプラットフォームに集め、誰もがデータをもとに調査できる状況を整備しました。

これをきっかけに、開発チームとの定点観測会を実施するようにもなりました。定期的に開発チームとNew Relicのダッシュボードを確認し、見つけた課題の対応方法などを検討しています。

どの会社でも起きうることですが、「誰かが監視してくれるだろう」という考えは、アジャイル開発という文脈でも、プロダクトの成長という意味でもよくありません。ダッシュボードを確認するのが当たり前の状態をつくっていくために開発チームと一緒に見ていくことで、意識付けと習慣化を行ってきました。こうした取り組みにより、ダッシュボードは障害発生時にのみ確認するものという意識は変わりつつあるように思います。

――カルチャーを含め、土台をしっかり固めるところから取り組まれているという印象です。

齋藤：そうですね。この他にも、そのまま使い続けることが難しい状態にあったIaCコードのリファクタリング、ポストモーテムの習慣化、CI/CDパイプラインの整備など、あらゆる方面から地道に改革を進めてきました。

いずれにしても、開発チームの意識を変えていこうという狙いがあります。これまではチームという壁の向こう側にボールを投げていたものを、開発チーム自身がオーナーシップを持って取り組める文化とマインドにしていくことが重要だと考えています。

[SRE NEXT 2023]エンタープライズ企業でのSRE立ち上げ挑戦の際に意識した事と気付き、現在地とこれからより

経営の理解を得ながら「まずはつくって見せる」ことでスピーディーに進める

――改革を上手く進めることができているポイントはどこにあるとお考えですか。

齋藤：これは偶然の要素が大きいですが、当時の副社長から「SREの重要性を理解しているつもりだが、細部のアプローチについて色々一緒に議論したい。組織内の交渉で協力できるところがあれば経営層からも後押しする」といわれたことがきっかけとなり、副社長と定期的にミーティングをするようになったことは、結果として効果的だったように思います。

例えば、Azureのコストモニタリングの仕組みづくりは、副社長からの「コストを何とかして欲しい」という意見がもとになっています。確かにコスト意識が薄くムダが多いところもあったので、コストモニタリングの大枠の仕組みを整え、開発チーム自身がオーナーシップを持てる環境をつくってきました。

こうして直接意思決定者と話ができる状況をいかして、揉めそうなことはトップダウンで進めるという方針を取ったことで、ある程度スピード感を持って動くことができてきたように思っています。

——トップの理解は重要ですね。ほかに取り組みを進めるうえで意識されてきたことはありますか。

齋藤：技術的な話が伝わりづらいときには、「説明に時間をかけすぎず、まずつくって見せる」ですね。つくったものを動かして理解してもらうことを強く意識してきました。便利だと思ってもらえれば、「それ、使ってみたい」という気持ちにつながり、ものごとが進めやすくなると考えています。

理想は「SREチームをなくすこと」

——齋藤さんが考えるSREチームの理想像はどのような姿ですか。

齋藤：そもそもチームの立ち上げ時からSREチームという"箱"をつくればよいという考えはありませんでした。SREという取り組み自体の必要性が高まっていたためにチームの立ち上げに至った形です。SREに取り組むこと自体は手段でしかありません。

最終的には、SREチームをなくすことが理想だと思っています。SREは普段から取り組むことであって、SREと名前の付いたチームに仕事を投げることではありません。「監視？運用チームが見てくれるでしょ？」「アラートは運用チームが受けてくれるはず」「アプリでエラーが起きたので、インフラチームが調べてください」といったマインドで、SREのような横断チーム頼みでサイトの信頼性を担保するのではなく、今回ご紹介したように開発チーム自身が監視・モニタリング基盤のダッシュボードの確認を習慣化するなどといった形で、本来は一人ひとりが実践している状態にしていかなければなりません。ただ、多くの会社はそこまで辿り着かないのが現状だと感じています。

——その理想にたどりつくために、今後はどのようにアプローチしていきますか。

齋藤：現時点では、SREチームという箱をとおしてSREのカルチャーを会社に根付かせようとしています。ただ、根付かせるということ自体も非常に大変なことです。

極論ですが、コードを書いてシステムが動けばそれでいいという考え方もありえます。採用と組織設計、組織としての目標、目指す姿が合致して、なおかつそれぞれのメンバーの力が十分発揮できる状態にしていかなければ難しいと思っています。

いきなり全員に行き渡らせることはできないので、まずは仲間を1人ずつ地道に増やして信頼関係を構築していくことを意識しています。会社としての課題を発見・特定してその解決をしていくことには時間がかかるだろうと当初から想定していましたし、いまだできていないことは多くありますが、1歩ずつステップを踏んで課題解決を進めていこうとしています。こうして長期戦で改善に向けた活動を進めていけば、気がついたら「なんかいつの間にかいい感じになってきたね」といえる状態になっていくのかもしれません。