f:id:techtouch:20211203101610p:plain

こんにちは、この記事はテックタッチアドベントカレンダー20日目を担当するエンジニアリングマネージャーの小林こと Kobaan です。毎年クリスマスはフライドチキンをいろんなところから購入してます。去年は某コンビニのチキンを購入してましたが、今年はなんとコロナの影響からか品不足で、近隣の店舗では予約できなくなってました。残念。今年は某フライドチキン専門店のチキンでクリスマスを祝おうと思います。

まずはエンジニアリングマネージャーの業務

主に二つのチームマネジメントとデリバリーマネジメントの業務を持っています。この二つのチームの内訳としては下記となっています。

プロダクト機能開発チーム
SREチーム

今回はその一つである SRE （ Site Reliability Engineering ）チームについてお話しさせてください。

当初は保守対応部隊が存在しなかった

当初プロダクトサイドとしては、「機能開発部隊が３チーム」と「 CSE （ Customer Success Engineer ）が１チーム」という構成でした。その中で CSE は、お客様の立場に立って技術的側面からお客様課題に対する課題解決や説明責任を果たすのがミッションであり、実際の不具合修正や詳細な問い合わせ対応については機能開発部隊が行う構造になっています。

ただそうすると、機能開発部隊には差し込みや障害対応など Just In Time な対応が求められ、それを続けるとフロー効率が阻害され、機能開発が滞ることでプロダクト価値の積み上げスピードが落ち、開発者としてもストレスを抱える状況になっていました。

つまり、「機能開発部隊を阻害せずCSEからの差し込み対応をさらに詳細に捌ける緩衝材のような存在」が必要だったのです。

各ロールのミッションを再定義

じゃあそのまま「 SRE 作れば良いじゃん」というとそういうわけでもありません。なぜ SRE が必要なのか？を各ロールを再定義する過程で穴を見出し、そこを SRE で担う形に変更していきました。

f:id:techtouch:20211203100759p:plain — テックタッチのプロダクト開発におけるロールとミッション定義

※これがその時の資料抜粋。

赤字に部分が追加された部分になります。（横断リリースマネジメントについては別途記事を書こうかと思います。） SRE はまさにスクラムチームとCSEのミッシングリンクでしたので、それを埋めるためのチームを作るというお話ができたので開発者の皆さんも納得感が強かったのではと思っています。

また、これを作りながら意識したのはスタートアップならではの「お互いをカバーしあう」や「枠を超えて挑戦することの障害にならない」ことです。図上もあえて平行四辺形にしてはみ出す作りにしてありますし、プロダクトメンバー全員に向けて話すときも「これはあくまでオーナーシップであり、制約ではありません」とお伝えしました。

SRE の役割とミッション

では具体的に SRE は何をしていく人たちにするのでしょうか？

前提の課題に戻ると

差し込み・不具合対応が入り込むため機能開発部隊のベロシティが上がりにくいこと

が大きな問題でした。

この解決策としては下記のようなことが考えられます。

差し込みタスクの一次受けができるロールを作る
障害が発生しにくいアーキテクチャを構築する

これって実は「お客様が安心して利用できるプロダクトを作る」ことにつながるのです。プロダクトの価値は作っている時はゼロで、使えていることが重要なのですが

f:id:techtouch:20211203101331p:plain — プロダクト開発と価値

障害が発生した時はそのプロダクト価値を失っていることになるため、お客様側からすると「安心して利用できない」＝サービスとしての信頼性を毀損していることになります。

f:id:techtouch:20211203101204p:plain — プロダクト価値と障害

こうしたプロダクトとしての価値と信頼性を維持し続ける部隊が必要だよね、という背景から SRE チームとさせていただきました。

本題に戻りますが、 SRE チームのミッションは３つに絞り込んでいます。

とにかくお客様に提供しているプロダクト価値毀損を最小化するための障害対応.
将来発生しうる障害の事前抑止.
品質担保を継続的にするためのアーキテクチャ改善.

f:id:techtouch:20211203101349p:plain — テックタッチにおけるSREのミッション

その中でも現在注力しているのは<1>です。

ここはここで語ることが多いので、別記事にしたいと思っていますが

ログ監視をより強力にして、お客様環境で多発する前に検知できること
エラーログを整理して、障害を高速で解析できる状態にすること
そもそも障害をトリアージして優先度をつけられること

あたりを検討していたりします。

機能開発部隊だとなかなか浮いてしまう課題のため優先度が後回しになりがちですが SRE のミッション設計だからこそこういったことが着手できているのだと思っています。

最後に

まだまだやること山積みで、ざっと出した SRE でやるべきテーマだけでも３０以上ありましたし、プロダクト機能もガンガン追加されていますし、今後はさらなるプロダクト追加もありえると思うと、楽しみが尽きません。

ただ、やはりよりスピード感をもってプロダクトを安定化に導くためにはもっと仲間が欲しいと思っていますので、ぜひ採用情報をみて応募してください。どのエンジニア職でも構いませんので、採用人事の方に「SREがやりたくてきました」とお伝えいただければ、少なくとも私と CTO の jun が面談にお伺いします（笑 techtouch.jp

もしくは下記Meetyで興味のあるとピックスがあればいつでもお声がけください！ウォーターフォール経験者だからこそ出せるEMの価値について語りたい初めて専任スクラムマスターとしてスタートアップにジョインした話転職を重ねて時価総額トップ１０の後にスタートアップにジョインした理由

明日の Kirai の記事は CSE （ Customer Success Engineer ）についてのお話だそうです。 SRE とも協働することの多いのでとても楽しみですね！