MIXI TECH DESIGN CONFERENCE 2024 に登壇しました

去年に引き続き、今年も社のカンファレンスに登壇させていただけました。

techcon.mixi.co.jp

去年と違い、今年はオフラインで会場にいらっしゃった方の前で初めて体験するパネル・ディスカッション形式ということで非常に緊張いたしました。

この記事では喋ったことの補遺というかライナーノーツみたいなことを書いていこうと思います。

他のチーム、職種の方との連携のコツ、取り組み

自分回答はこちら

「職種ごとに目線が違うのでそこを意識すること。非エンジニアの方とやり取りをする場合にはエンジニア間でしか通じない単語などを使わない。あとはベタにteam geekにも書いてあるHRTを大事にする。」

会場でも話しましたが、目線を揃えるということはサイトリライアビリティワークブックの18章にある「目標を揃える」と同義です。SREsが信頼性を尊ぶように、QAチームなら品質、ビジネスチームなら売上が目標となるはずです。
そこをお互いの目標が達成されるように目の前の課題などを乗り越えていく必要性があり、そこを対話によって目線を揃えていくことが大切だと考えているわけです。

sre.google

また、私は小さなベンチャーにいた経験があったので他職種の方と喋る機会が一般的な企業よりも多くありました。その中で培ったコツとして「エンジニア間でしか通じない単語などを使わない」がありました。意外な単語も思い返してみればエンジニア由来だな、というものがあるので一度頭の中で洗い出してみると小さな発見があるかもしれません。

HRTは有名すぎるエッセンスなので特に付け加えることもないですね。社会人として当たり前に身に着けておくべき教養です。

こういったことを意識して接することで、「SREingをやる人」という基本的な認識を持ってもらいつつも、「気軽に相談できる信頼できる仲間」として認知してもらえることを目指すのが良いのかなと思います。

SREの重要性をどう理解してもらうか

自分回答はこちら

「お題目だけの羊頭狗肉と思われないように開発チームにとっての重要なところからSREingを始めてみる。それでも伝わらないなら根気強く重要性を説明し、示していく」

モデレーターの清水さんから「開発チームにとっての重要なところって何？」という質疑がありましたが、開発チームはサービス価値を迅速にユーザーに届けることが重要で、そこに関して一番影響に寄与できるのがCI/CDですね。という応答をしました。

SRE in the Real worldのお話を挙げたのですが、ここでも「最初に始めるべきはdevinfra / relengだ」と述べられており、devinfraはDX（developer experience）の向上を狙った環境作り、relengはRelease Engineeringなので、CI/CDはまさにですね。

blog.relyabilit.ie

SREの人数規模による施策の違い、苦労や工夫など

自分回答はこちら

「一人でSREを実践していますが、リソースがとにかく足りないのでタスクの優先度決めはシビアにやる必要があります。あとはリソース不足の解消手段として開発チームを積極的に巻き込んでいくことです」

こちらも「優先度決めをシビアにやるためのコツはあるか？」という質疑を頂きまして、「コツというか指標はあって"ビジネスインパクトに影響するか？"が第一で、それ以外はチーム全体の影響度の高い低いで決める」と少しボヤッと答えました。
正直、チーム全体の影響度って何だよと思われた方いらっしゃるかもしれませんが、SREsのみに影響が偏るタスクよりもSREsと開発チームのお互いに影響が及ぼされるようなタスクを優先しましょうといった意味合いでした。例えば、「four keysの整備」はどちらかといえばSREs寄りのタスクで、それよりも「リリースサイクルの高速化」みたいなタスクの方を優先度高くしております。

何故そうしているのか？については、開発チームを巻き込むということをやるにあたって開発チームからの信頼貯金を貯めたいという側面が強いです。一人で全てのタスクをこなすといったことは無理に等しいので、貯めた信頼貯金を取り崩しながら開発チームにもSREingに積極的に関わってもらうようにする、といったことが非常に大事になってくるのです。