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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

3 即戦力人材と企業をつなぐ転職サイト「ビズリーチ」  C (ビズリーチ会員様) と B (直接採用企業様/ヘッドハンター様) へ  転職プラットフォームを提供  ビジョナル株式会社 2024年7月期第3四半期決算説明資料より

Slide 4

Slide 4 text

4 顧客基盤の拡大に支えられた堅調な成長  ビジョナル株式会社 2024年7月期第3四半期決算説明資料より

Slide 5

Slide 5 text

5 目指す姿：選択肢と可能性を最大化する「キャリアインフラ」 

Slide 6

Slide 6 text

今日話すこと    イシュードリブンで  SREingを実践する事例3選  6

Slide 7

Slide 7 text

7 本日お伝えしたいこと：「イシューからはじめよ」 

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

イシューからはじめる考え方    ● 「問題を解く」より「問題を見極める」  ● 「解の質を上げる」より「イシューの質を上げる」  ● 「１つひとつを速くやる」より「やることを削る」  9

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

33 Appendix 

Slide 34

Slide 34 text

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 参考にしたもの 