してきました。楽しかったー。
登壇後記
実はプロポーザル募集が始まった8月頃、登壇へのモチベーションは枯渇していました。というのも（自分のスライド作成の技術が向上していないとも言えるのだが）準備の時間が割りに合わないと感じていたからです。これは今後再開するときは再度見直したいところ...。本業もあって、家庭の時間も必要で、健康維持の時間も必要で、可処分時間をどう投資するかをいい年なので色々考えると、登壇は”しばらくやめる”ということにしました。楽しさも知っているし、実際 SRE NEXT 終わったあとはすごくいい気持ちだったので、登壇は麻薬やな... などと思いました。
（業務として登壇するのだから）業務時間でやればいいじゃん、と言うのは簡単だしごもっともであるし、自分も所属メンバーにはそう言います。ただ、業務と登壇資料作成どちらが大事かなんて比べられないわけで、結局”業務を捨てる"ことができなかった自分は単に労働時間が膨らむ形になってしまっていました。
とのっけからネガティブな感じになってしまったんですが、そんな後ろ向きな状態でも SRE NEXT のプロポーザルは気がついたら書き始めていました。僕にとって思い出深く、大切な大切なカンファレンス。もしプロポーザル落ちたらそのときはそのとき、新しい世代へバトンタッチだな、通ったのなら、まだ自分に共有できることがあるな、と思い出しました。
プロポーザルの段階でかなり濃いめのアウトラインを書いていたので登壇自体は楽でした。今後出す人の参考に現物を記事の最後に晒しておきますね。
この登壇内容は、僕が2年間 SRE チームのマネージャとして過ごした期間の集大成のようなものでした。SLI/SLO として信頼性を開発チームで観測していく世界についてはある程度は僕がマネージャになる前から根付いていました。今でこそ Platform Engineering の認知が高まっていますが、我々も以前より信頼性と開発生産性、両方で開発チームをサポートするために Enabling / Platform Engineering 両面に取り組んでいました。
ここで語られなかったこともたくさんやりますが、僕が最も重要視し、注力したのが「開発チームからうまくフィードバックを得る」ことでした。Enabling だろうが Platform だろうが開発者の声を聞き、自分たちで何をやるかを決め、その結果を計測・観察し、次の計画につなげる。言葉にすれば当たり前に聞こえてしまうのですが、僕たちにとっては新しい挑戦でした。
そしてこれらの活動がうまくいったのは単なる方法論 / プラクティスがうまくいっただけではないことはわかっていました。簡単に真似ができない、だからこそみんな苦労している。だからその土台となる組織文化に着目し、考察した発表にまとめました。
結果として登壇内容で語られたことはほぼ全て所属メンバーの高い技術力とソフトスキルによってなされたものです。こういったものを僕の口で発表することは最初は抵抗あったのですが、所属組織の成果を代弁するのは何ら変なことではなかろう、マネジメントの成果の出し方の1つであろうと言い聞かせて話していました。
結果多くの方に来場いただき、感想を残していただき、ありがとうございました。当日の Twitter も、ブログで言及していただいているものも全て目を通しております。
本当にこの気持ちです。
引退だよ！！あとは任せた！！！！来年やるなら会には行くよ！、！！！！！たくさん話しかけていただいて嬉しかったです、自分の発表が誰かの勇気に、誰かの明日の一歩につながればこれ以上幸せなことはありません。その場を作ってくれてスタッフの皆さん本当にありがとうございました。#srenext
— Takeshi Kondo (@chaspy_) 2023年9月29日
懇親会も楽しかったです。アツい思いをぶつけてくれた VTRyo さん、お久しぶりの Nari さん、廊下で会って懇親会でもキャリアや業務について語れた t-jun さん、登壇後よりご一緒させてもらえた @yuta_k0911 さん、いつも仲良くしてくれている @donm_ri さん @a0i さん、全然暇ですよ！などと供述していた katsuhisa さん（安心感ある）グロービス _yukin01 さん、リアルでは久しぶり minamijoyo さん、その他懇親会で同じテーブルでお話しした皆さんありがとうございました！またどこかで会いましょう。
カンファレンススタッフとして room B を担当いただいた taxin_tt さん、shotaTsuge さん（ご近所！）ほか全てのスタッフの皆さん、本当にありがとうございました！
これから
登壇をやり切ったおかげでバチっと切り替えて 10/1 から新しい責務をやっております。
SRE のプレイヤーもマネージャも引退した後どうするのか、というのは以下の記事に書いたとおり、開発部長をやっております。部長なんて照れくさい、Senior EM だ！といってたけどなんやかんや社内呼称というのは強いもので、"部長"の自認も高まってきました。
社内 Public になってから1ヶ月、正式任用から1週間経った。忙しすぎて死ぬ、みたいなことは特段なく、順調に（？）職責変更と、責務を果たすために下準備を行なっています。
基本的には担当領域について、エンジニアリングを経営に接続することが責務だと思っている。（実際に数値責任を持つではなく、あくまで"接続"（橋渡し）が責務である）
この1ヶ月はとにかくいろんな人と話しまくっている。隣接の部署、あるいは新しくマネジメント対象になるメンバーと。新しい人と、自分にとって新しいことを知るのはとっても面白い体験で、そういう意味ではこのロール変更は自分に向いている面もあると思った。
ひとまずこれまで関与してこなかった会計用語の習得と、事業の現状を把握し、その現状に対して開発組織として貢献できることを探し、それを組織戦略、技術戦略に落とし込む、というのを直近やっている。あと FinOps は関係者と会話し進め始めている。開発生産性の経営への接続も、仕込みをちょっとずつやっている。
見るべき範囲が増え、変数が増え、これまで以上に緊張感は増すが、まずは半年、しっかり走りきろうと思います。
引き続きいろんな人とお話ししたいです！オンラインでもオフラインでも、声かけてください！
おまけ：出したプロポーザル
タイトル
開発者とともに作る Site Reliability Engineering
発表概要
SRE の実現には、SRE という Role を持つ人だけでは成し遂げられません。プロダクト開発を行う組織の場合、プロダクト開発者と緊密な連携が必須です。その場合、SRE Team がいかにプロダクト開発者の直面する課題をどれだけ深く理解し、その要求を適切に定義できるかが鍵となります。
開発チームの要求を理解するためには以下の3種類のアプローチが有効です。 直接のフィードバックを受け入れる 継続的にコラボレーションする 実際の現場を体験し、開発者の立場を理解する
そしてこれらを実現するためにはマネジメント上の工夫だけではなく、オープンで避難のないコミュニケーションや、定期的なふりかえり、そして適切なフィードバックを行うといった組織文化が必要不可欠です。
本セッションではこれらのアプローチの具体的な実践例と、それを支える組織文化に関する実例を詳しく紹介します。SRE チームと開発チームの両方のマネージャを経験を持つ私の独自の視点を通じて、プロダクト開発組織全体で SRE を効果的に実践するヒントを持ち帰っていただければと思います。
聞いた人が得られるもの
SRE チームが実現すべきことを開発者から得る方法 SRE チームとプロダクト開発者のコラボレーションを支える組織文化の作り方
発表の詳細
アウトラインです。
自己紹介
この発表のまとめ（伝えたいこと）
SREの価値
サービスの信頼性を期待値通りに実現するために開発者をサポートする - を最大限発揮するためには、SREが開発者の要求を正しく理解する必要がある。SREが開発者の要求を正しく理解するためのアプローチ
- フィードバックを得る
- コラボレーションする
- 実際に体験する
円滑/高速にサイクルを回すために必要な要素
マネジメントの工夫だけでなく、フィードバックをうまく行うスキルを組織文化として実装する必要がある。
導入 / これまでのあらすじ
- SRE NEXT 2020, 2022 の話
- スタディサプリ SRE の歴史
- 2018 chaspy 入社
- 2020 SLO コンセプトを組織に導入
- 2021
- SRE チームの Vision / Mission / Value 策定 リンク
- Terraform, Kubernetes など基盤の進化, 負荷試験基盤の構築など
- スタディサプリ小中高の組織規模やプロダクトについて
この2年間の SRE チームが目指していたこと
- 課題: SRE チームがやることは、SRE チームが決めていた
- 適切な課題設定ができない可能性
- 再現性がないと感じていた
- 開発者からフィードバックを得る / フィードバックサイクルを回す
- 複数のアプローチを試す
- 過去事例: マネジメントによるSREの実現
事例紹介
1. フィードバックを得る
- SRE サーベイの実施
- 「月間SRE」として、毎月の SRE からの Updates を開発チームが多く参加する勉強会で共有、フィードバックをもらう
- 2週間開発チームに SRE が入って密にコミュニケーション（Embedded SRE パターン）
2. コラボレーションする
- 新機能リリース前のデプロイパイプラインの構築
- 技術戦略グループで議論
3. 実際に体験する
- 短期留学（開発メンバーとSREメンバー）
- SRE マネージャが開発マネージャを兼任
これを可能にする組織
- マネジメントの工夫
- 組織文化
マネジメントの工夫
組織文化について
- フィードバックのスキル
- 360 feedback について
- あらゆるシステムやプロセスへのフィードバック
- 率直に・非難なくコミュニケーションすること（Blameless）
- あらゆるものを振り返る文化
まとめ
SREの価値
サービスの信頼性を期待値通りに実現するために開発者をサポートする - を最大限発揮するためには、SREが開発者の要求を正しく理解する必要がある。SREが開発者の要求を正しく理解するためのアプローチ
- フィードバックを得る
- コラボレーションする
- 実際に体験する
円滑/高速にサイクルを回すために必要な要素
マネジメントの工夫だけでなく、フィードバックをうまく行うスキルを組織文化として実装する必要がある。
SRE サーベイの質問内容
Slack ID (GitHub ID)
所属チーム
関わっているサービス
ロール
自分たちのチームは自己完結化できていると感じますか?
自分たちはいい感じにサービスを運用できていると感じますか?
何ができていればサービスを自分たちで運用できている、と言えますか?
よりプロダクトを良くしていくためには、何がボトルネックですか?
もし、最近直面した SRE に関連しそうな課題/問題があれば教えて下さい
自分たちはいい感じにサービスを運用できていると感じますか? (2)
普段の開発の中で最もストレスを感じている工程・手順は何ですか?
開発の工程の中で、これが速くなったら嬉しいという部分はありますか?
自分たちのサービスにおいて、負債だと感じている / 消し去りたい要素は何かありますか？
あなたは、以下のツール等をどの程度理解していますか（詳細のコンポーネント別に質問）
現在の(SREが開発/運用している)プラットフォームは良くできていると思いますか
現在の(SREが開発/運用している)プラットフォームで分からないことがあったら、何を見ますか?
今のプラットフォームにあって便利な機能や、よく使っている機能があれば教えてください
現状の SRE の対応や取り組みに満足していますか?
SRE の対応や取り組みについての要望/コメントがあればお願いします (問い合わせをしたことがあれば)
対応の速度や質に満足していますか?
SREの問い合わせ対応について要望/コメントがあればお願いします
サーベイについて何か要望/コメントがあればお願いします
SREチームから依頼があるとき、どのような形で連絡/依頼されると良いですか?
参考リンク 所属組織のブログ Web 開発者目線での、SRE が作る開発基盤について スタディサプリのWebアプリケーションはこうやって開発されている AWS Dev Day 2023 Tokyo で スタディサプリのDarklaunch について発表してきました 開発生産性を支えるデータベースリストアを SRE が作った事例 スムーズな開発体験を支えるデータベースリストアの仕組み - スタディサプリ Product Team Blog SRE メンバーが開発チームに入り、リニューアルプロジェクトのリリース前にプレモーテムをファシリテーションした話 「0回目のポストモーテム」としてのプレモーテムのすすめ - スタディサプリ Product Team Blog 著者自身のアウトプット Web Application 開発の EM を兼務することになった Web Application 開発の EM を兼務することになった - ツナワタリマイライフ SRE とプロダクト開発の EM を兼務して半年経った SRE とプロダクト開発の EM を兼務して半年経った - ツナワタリマイライフ 開発チームに実際に入ったからこそ見えた課題と SRE としての経験を活かした事例 『スタディサプリ 中学講座』における E2E Test の運用と計測による改善 / Improved E2E testing through measurement - Speaker Deck
