プロダクト全体で取り組むSREing イシューから始める信頼性・生産性向上の実践/SRE NEXT 2024

2024年8月3日より開催された「SRE NEXT 2024 IN TOKYO」の登壇資料です。
https://sre-next.dev/2024/

▼関連資料
ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う
https://speakerdeck.com/visional_engineering_and_design/jjug-ccc-2022-fall

職能を越えた連携で「目先の数字に囚われないSQLチューニング」を実現する
https://engineering.visional.inc/blog/535/essential-sql-tuning/

-----
Visionalのエンジニアリングに関する最新情報はX、ブログで発信しています！📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING / X
https://twitter.com/VISIONAL_ENG

Transcript

1. 株式会社ビズリーチ（Visionalグループ）
 リクルーティングプロダクト本部プラットフォーム開発部 部長
 菊池 信太郎
 1 プロダクト全体で取り組むSREing
 イシューから始める信頼性/生産性向上の実践
 
 @SRE NEXT 2024, 2024/8/4 

2. 菊池 信太郎
 
 2012〜 株式会社ニトリ
 • 店舗 / 物流でトラブルシューティングしたり、現場の改善を回したり 
 2014〜 SIer
 • 受託開発やSESで複数プロジェクト経験 
 • テックリード・PM・EMとして開発経験を積む 
 2018〜 株式会社ビズリーチ 
 • ビズリーチサービスの toBプロダクトを中心に開発 
 • EMとしてリアーキテクティングの推進、組織横断プロジェクトなどのリード 
 • 現在はリクルーティングプロダクト本部プラットフォーム開発部部長 
 
 麻雀と読書が好き。
 最近は3歳児に毎日翻弄されています。 
 2 自己紹介

3. 3 即戦力人材と企業をつなぐ転職サイト「ビズリーチ」
 C (ビズリーチ会員様) と B (直接採用企業様/ヘッドハンター様) へ
 転職プラットフォームを提供
 ビジョナル株式会社 2024年7月期 第3四半期決算説明資料 より
4. 4 顧客基盤の拡大に支えられた堅調な成長
 ビジョナル株式会社 2024年7月期 第3四半期決算説明資料 より
5. 5 目指す姿：選択肢と可能性を最大化する「キャリアインフラ」

6. 今日話すこと
 
 イシュードリブンで
 SREingを実践する事例3選
 6
7. 7 本日お伝えしたいこと：「イシューからはじめよ」

8. 今、自分の置かれた局面で、
 答えを出さなければならないことはなにか？
 8 イシューとは

9. イシューからはじめる考え方
 
 • 「問題を解く」より「問題を見極める」
 • 「解の質を上げる」より「イシューの質を上げる」
 • 「１つひとつを速くやる」より「やることを削る」
 9
10. よくある失敗：HOWから入る
 • SREのプラクティス（SLO、エラーバジェットなど）を導入したが、運用が形骸化している
 • ダッシュボードを作ってみたのはいいものの開発チームに使われていない
 
 イシューの質を上げることが最も重要
 • プロダクトごとにそれまでの経緯や現在の状況がある（経路依存性）
 • As-Isを把握したうえで、To-Beを描き、現実解を出す必要がある
 • やるべきことを明確にした上で、プラクティスを適切に当てはめればいい
 10 イシューの質が低いと労力のわりに成果に結びつかない

11. イシュー度：
 自分のおかれた局面でこの問題に答えを出す必要性の高さ
 
 解の質：
 そのイシューに対してどこまで明確に答えを出せているかの度合い
 11 価値ある仕事はイシュー度、解の質が高い
 引用：『イシューからはじめよ』 p.25 図2 バリューのマトリクス 

12. 12 事例①：技術的負債を抱えるプロダクトへのアプローチ

13. 背景
 • 2018年頃まで短期戦略が重視されており、技術的負債が蓄積
 • 2019年にはスロークエリなどが頻発し、CTO判断で半年間新規開発をストップ
 • 専任のSREチームは存在していたが、プロダクト組織全員で集中して取り組む必要があった
 13 プロダクトの信頼性をどう改善していくのか？
 【JJUG_2022秋】ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う 

14. 14 SRE観点でのイシューの見極めでは『信頼性の階層』が有用
 引用：SRE サイトリライアビリティエンジニアリング
 p.88 サービスの信頼性の階層

15. 15 『信頼性の階層』の下から順番にアプローチ
 ①現状把握とプロセス整備から始め、緊急度 の高いリスクは応急処置
 ④段階的な内部品質改善
 ②ポストモーテムを通じた継続的 な改善サイクルの確立
 ③自動化、プロセス、テスト、QA の強化
 引用：SRE サイトリライアビリティエンジニアリング
 p.88 サービスの信頼性の階層

16. • インシデント対応プロセスを整備する 
 • QAチームを組閣し、フェーズゲートとする 
 • ポストモーテムを通じて根本原因を改善する 
 セキュリティリスクを抱え ているものはないか？ 
 障害件数が多い
 16 「応急処置すべき緊急度の高いリスク」をイシュー分析した例
 潜在的なリスクはなに か？
 障害発生に正しく気づけ るか？
 イシュー
 • モニタリングを機能させる 
 ◦ エラーログを減らす
 ◦ アラートを設計する
 サブイシュー
 アクション
 • 構造的に脆弱性の多い Web Application Frameworkを入 れ替え
 • 継続的にEOL対応を実施する
 すでに顕在化しているリ スクはなにか？
 表示速度が3秒以上か かっている画面が存在す る
 • レスポンスタイムが3秒以上の画面を修正する 
 ◦ スロークエリ改善
 ◦ n+1対応
 ◦ テーブルリファクタリング 

17. 17 成果：段階的に改善し、現在は内部品質を高めるフェーズへ
 【JJUG_2022秋】ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う 

18. 18 事例②：リリースプロセス改善

19. 改善前の状況
 • 既存システム（toC/toB/Admin/Batch）は複数チームが関わる巨大なモノレポ
 • 定期リリースは2週間に1度
 • プロダクト組織総出でシナリオテストを手動で実施
 • QAチームが開発チームの外にあり、フェーズゲートとして機能
 19 開発リードタイム、改善サイクルを早くしたい

20. • 技術・組織の改善はすでに計画されていたため、ここではプロセスにフォーカス
 • 誰がプロセス改善を実行するか？
 ◦ チームを横断するプロセス改善は調整コストが高く優先順位が上がりづらい構造がある
 ◦ SRE、QAのSETから一部メンバーを異動して、「プロセスエンジニアリンググループ」を組成
 • クロスファンクショナルな小さなチームを構成し、意思決定を 素早くできるようにする 
 • DevOpsのケイパビリティを上げる 
 プロセス
 • リアーキテクティング、リライトによって変更容易性、テスト容 易性を獲得する
 20 イシューの見極め
 改善サイクルを早くする には？
 技術
 イシュー
 サブイシュー
 アクション
 組織
 • リリースプロセスのボトルネックをなくし、リリース頻度を上げ られるようにする

21. 引用：小田中育生さん『組織内でバリュー・ストリーム・マッピング (VSM) の宣教師をやってみてわかった、 VSMを組織に広める3つのポイント - Speaker Deck』
 https://speakerdeck.com/navitimejapan/zu-zhi-nei-debariyusutorimumatupingu-vsm-falsexuan-jiao-shi-woyatutemitewakatuta-vsmwozu-zhi-niguang-meru3tufalsepointo
 21 初手、バリュー・ストリーム・マッピング（VSM）で可視化
 企画〜設計〜開発〜リリースまで一連の流れを可視化し、イシューを考える材料を集める

22. 22 プロセスを可視化するとボトルネックが見えてくる
 手動シナリオテストが 2日間に 分けて数時間ある。エンジニア のコンテキストスイッチも結構 ありそう。
 QAチームによるQA期間が1週 間あるけど、チケット見てテスト 分析がここから始まってそう。 
 リリースを担当するリリースエ ンジニアの手作業が多い。 
 変更承認プロセスももう少し楽 にできそう。

23. • リリースエンジニアの手作業をなくす、自動化する 
 • 変更承認プロセスを最適化する 
 • バッチ処理を止めなくてもリリース可能にする 
 QA期間を短縮する
 • 手動シナリオテストを自動化した E2Eテストに置き換える
 • テストピラミッドを形成するため、 E2Eテストではなく、なるべく 単体テストやAPIテストに寄せる（リアーキで段階的に実現） 
 23 可視化されたボトルネックを踏まえ、イシュー分析
 リリースプロセスにおける ボトルネックはなにか？ 
 手動シナリオテストをなく す
 イシュー
 サブイシュー
 アクション
 リリースエンジニアの作 業を減らす
 • 開発チームにインプロセス QAを入れることで、開発チームの 外で実施しているQAテストをシフトレフトする 

24. E2Eテスト自動化を最優先
 • なぜなら複数の問題を同時に解決できるから
 • 開発者体験が改善され、アジリティを手に入れることができる
 • 安心してコード変更できるようになり、ライブラリアップデートやEOL対応にも役立つ
 
 インプロセスQAは着手自体は早かったが、体制構築に時間がかかった
 • 採用するとなると、リードタイムとして半年は見ておく必要がある
 • シフトレフトが定着するのもある程度時間がかかる
 
 リリースエンジニアの手作業を減らし、リリースプロセスを実際変えるのは最後
 • 手作業が減ること自体のインパクトはそこまで大きくなかった
 • 内部統制のことを考慮する必要もあり、一気に進める必要があった
 • デプロイを完全自動化するにはバッチアーキテクチャの載せ替えが必要だったため後回し
 24 優先順位のつけ方：重要なもの、効果が高いものにフォーカス

25. 主な成果
 • 手作業をなくしていったことで、リリース作業が効率化
 • リリース1回あたりのバッチサイズが小さくなった
 • QAのシフトレフトが起こり、テスト分析を開発プロセスの中で実施できている
 • E2Eテストが整備されたことでライブラリのバージョンアップなどが気軽にしやすくなった
 
 今後の展望
 • デプロイが完全自動化できていないので、次はそのボトルネックを取り除きたい
 • CI/CDの改善で、より短時間で開発サイクルを回せるようにしていきたい
 • リアーキテクティングで段階的に内部品質を上げることによって、開発のリードタイム短縮を狙いに行く
 25 成果：リリースプロセスが効率化され、リリース頻度が2倍に

26. 26 事例③：採用企業様向けプロダクトの表示速度改善

27. 背景
 • 2019年に大規模なスロークエリ改善を実施したものの、急速な拡大に伴い、2023年にはデータ量が増え続け、ま たもやシステム負荷は増大
 27 採用企業様向けプロダクトの「表示速度」問題再び
 エンジニアリングブログで事例公開中 
 https://engineering.visional.inc/blog/535/essential-sql-tuning/

28. 分析の結果、特に採用活動が活発なお客様ほど表示速度の問題が顕著になることが判明
 • 定性分析：
 ◦ カスタマーサクセスを通じ、お客様からのフィードバックを回収
 ◦ 自ら実際に利用し、期待の速度に対して遅い表示画面を特定
 • 定量分析：
 ◦ Datadog等を用いて、各エンドポイントごとのLatencyを計測し、モニタリング
 ◦ BigQueryに集約しているサービスデータとDatadogのデータを突合し、お客様の属性と利用状況に基づい て速度をモニタリング
 28 現状分析
 各エンドポイントごとのLatency等をまとめた信頼性ダッシュボード

29. 事業を理解し、ユーザーが機能をどう使っているのか解像度を上げると、イシューの質、解の質が上げられる
 優先すべき機能はある か？
 29 イシュー分析して、優先順位をつける
 顧客体験上、真に改善す べき点はなにか？
 イシュー
 サブイシュー
 企業群によって利用パ ターンや利用体制が異な るか？
 大手企業のお客様
 →p99, MAX改善
 中小企業のお客様
 →p50改善
 ビジネス寄与度
 実現可能性

30. • 4ヶ月で、スコープを定めた「重要な画面」の表示速度が大幅に改善
 ◦ 一部の画面では表示にかかる時間が50%以上削減
 ◦ レジュメの表示速度などの採用業務における非常に重要な画面も含まれる
 • 1ヶ月あたりでご利用いただく採用企業様全体で数千時間もの工数削減に貢献
 • PdM、SRE、DBRE、開発チーム、カスタマーサクセスなどのクロスファンクショナルチームで取り組んだ成果であ り、現在もお客様からのポジティブなフィードバックを受け取りながら、改善とモニタリングを継続（→SLI/SLOを設 定する布石に）
 30 成果：スコープを定めた重要画面の表示速度が大幅に改善
 レジュメ表示にかかる時間

31. イシューからはじめよう
 • イシューとは「今、自分のおかれた局面で、答えを出さなければならないことはなにか？」
 • やみくもに改善せず、解くべきイシューをよく見極める
 • イシューを見極め、優先順位を決めるために「計測」や「可視化」を使う
 • 全体構造を把握し、効率的かつ効果的に成果を出そう
 31 まとめ：本日お伝えしたいこと

32. SRE以外のポジションも募集中！
 • ソフトウェアエンジニア
 • エンジニアリングマネジャー
 • QAエンジニア
 • MLエンジニア
 • MLOpsエンジニア
 32 本質的な課題解決を志向するSREを絶賛募集中！
 https://hrmos.co/pages/hrmos/jobs/3100100100963/apply
 カジュアル面談はこちらから Engineering Blog https://engineering.visional.inc/blog/

33. 33 Appendix

34. SRE
 • O'Reilly Japan - SRE サイトリライアビリティエンジニアリング 
 • SRE - エンタープライズ ロードマップ
 イシュー
 • イシューからはじめよ ――知的生産の「シンプルな本質」 | 安宅和人 | ビジネス教育 | Kindleストア | Amazon
 • 【マッキンゼーの思考法を実際のビジネスでどう使うか①】仕事が 10倍早くなる「イシューの定め方」／イシューとはカギとなる問い／会議の生産 性が見違える／ヒカルさんとのコラボを例に解説【ロコンド田中 CEO】
 • イシューからはじめる FF10【前編】 | ドラクエ好きに悪い人はいない 
 VSM
 • 組織内でバリュー・ストリーム・マッピング (VSM) の宣教師をやってみてわかった、 VSMを組織に広める3つのポイント - Speaker Deck
 資料内で引用した過去の弊社事例 
 • ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う / JJUG CCC 2022 Fall - Speaker Deck
 • 職能を越えた連携で「目先の数字に囚われない SQLチューニング」を実現する - Visional Engineering Blog
 34 参考にしたもの