Slide 1
Slide 1 text
株式会社タイミー 岡野兼也
SLOを活用した技術的改善
@Juju_62q
Slide 2
Slide 2 text
まずは伝えたいこと
Slide 3
Slide 3 text
継続的な技術的改善、
どうやったらいいの？
Slide 4
Slide 4 text
すぐに気づいてすぐに実行
Slide 5
Slide 5 text
いや...そんなこといわれても...
Slide 6
Slide 6 text
今日は技術的改善を
「すぐに気づいてすぐに実行」
する方法を紹介します
Slide 7
Slide 7 text
目次
● 技術的改善の流れ
● 技術的改善の問題点
● 指標を使おう
● 事例紹介
● 一歩先の未来とまとめ
Slide 8
Slide 8 text
岡野兼也 / @Juju_62q
株式会社タイミー
プロダクト本部 ワーカーチーム
Backend Engineer
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
目次
● 技術的改善の流れ
● 技術的改善の問題点
● 指標を使おう
● 事例紹介
● 一歩先の未来とまとめ
Slide 12
Slide 12 text
よくある？技術的改善
Slide 13
Slide 13 text
技術的改善のながれ
パフォーマンスちょっとやばい...?
よく気づくエンジニア
Slide 14
Slide 14 text
技術的改善のながれ
なんかパフォーマンス遅そうで、直し
たほうが良さそうです
おっ、ちょっと考えたいから
起きる問題と時期、予想工数ほしいです
よく気づくエンジニア
PM
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
技術的改善のながれ
これならhoge機能開発よりも
先にやったほうが良さそうですね。
資料作りました！よろしくおねがいします！
Slide 17
Slide 17 text
技術的改善のながれ
Slide 18
Slide 18 text
技術的改善のながれ
1. 誰かが唐突に気づく
2. PMが判断可能な材料を作る
3. 優先度判断
4. 技術的改善の実行
5. 効果測定
Slide 19
Slide 19 text
目次
● 技術的改善の流れ
● 技術的改善の問題点
● 指標を使おう
● 事例紹介
● 一歩先の未来とまとめ
Slide 20
Slide 20 text
歯車が狂うと...?
パフォーマンスちょっとやばい...?
Slide 21
Slide 21 text
歯車が狂うと...?
でも伝えるとなんかやりたくない仕事めっ
ちゃ増えちゃうしな〜
Slide 22
Slide 22 text
歯車が狂うと...?
今週はhoge機能とfuga機能を作ろう
来週はfoo機能とbar機能を作ろう
Slide 23
Slide 23 text
歯車が狂うと...?
なんかアプリ全然開かないんだけど...?
Slide 24
Slide 24 text
歯車が狂うと...?
やばいやばい！早くなんとかしないと！！
開発全部止めてなんとかするぞ！！
Slide 25
Slide 25 text
歯車が狂うと...?
問題が絡まってて解決できない
Slide 26
Slide 26 text
どうしてこうなった？
Slide 27
Slide 27 text
よくある技術的改善のつらいところ
- 問題に気づくと作業が増える
- やりたいことに対してやらなきゃいけないことが多い
- 技術的改善が気づく人に属人化している
- 問題が起きてから解消が遅い
- 時間がたつと往々にして問題は大きくなる
- 大きな問題は解決が難しい
Slide 28
Slide 28 text
炎上と鎮火を繰り返す
Slide 29
Slide 29 text
遅く気づいて遅く実行
Slide 30
Slide 30 text
技術的改善のながれ（再掲）
1. 誰かが唐突に気づく
2. PMが判断可能な材料を作る
3. 優先度判断
4. 技術的改善の実行
5. 効果測定
Slide 31
Slide 31 text
エンジニアの立場で見てみる
Slide 32
Slide 32 text
エンジニアのやりたいこと
1. 誰かが唐突に気づく
2. PMが判断可能な材料を作る
3. 優先度判断
4. 技術的改善の実行
5. 効果測定
Slide 33
Slide 33 text
エンジニアの立場
- システムに近いので気づきやすい
- 実行権限はない
- 技術的改善をしたい
- プログラミング（エンジニアリング）をしたい
- 技術的改善をやるために頑張りたく
ない
- 局所最適に陥りやすい
Slide 34
Slide 34 text
PMの立場で見てみる
Slide 35
Slide 35 text
PMのやりたいこと
1. 誰かが唐突に気づく
2. PMが判断可能な材料を作る
3. 優先度判断
4. 技術的改善の実行
5. 効果測定
Slide 36
Slide 36 text
PMの立場
- はじめの気付きは遅い
- 意見通したい人に説明責任を担って
ほしい
- 実行権限がある
- 全体最適を考えるのが仕事
Slide 37
Slide 37 text
二人に問題はあった？
Slide 38
Slide 38 text
問題...?
- エンジニアの仕事は資料作りではない
ので面倒臭がるのも自然
- PMがエンジニアリング起因の問題に
気づかないのも不自然でない
- 問題を評価してから実行するのは当然
Slide 39
Slide 39 text
あれ？
Slide 40
Slide 40 text
人は最善の行動をしてる...？
Slide 41
Slide 41 text
改めて問題を探す
Slide 42
Slide 42 text
誰もやりたくない
1. 誰かが唐突に気づく
2. PMが判断可能な材料を作る
3. 優先度判断
4. 技術的改善の実行
5. 効果測定
Slide 43
Slide 43 text
仕組みの問題
- 気づく人に負荷が偏ってしまう
- やりたくないけどやらないといけない仕事がある
- やりたくない仕事は頑張れない
- やれる人・気づく人がやって疲弊する
- 判断ポイントが介在している
- 作業者から見た不確実性
- 実行が遅れる可能性
Slide 44
Slide 44 text
解決策1: よく気づく社員しか採用しない
- メリット
- 気づいて実行する人が分散される
- デメリット
- 採用が大変そう
- 気づく人ってなんやねん
Slide 45
Slide 45 text
解決策1: よく気づく社員しか採用しない
- メリット
- 気づいて実行する人が分散される
- デメリット
- 採用が大変そう
- そもそもよくわからない
Slide 46
Slide 46 text
解決策2: 現場の意見はすべて即実行する
- メリット
- よく気づく社員が疲弊しない
- 問題が深化する前に解決できる
- デメリット
- 適切な優先度判断がなされない
- 全エンジニアがPM的な視点を持たなければならない
- 妥当な説明が社内に残りにくい
Slide 47
Slide 47 text
解決策2: 現場の意見はすべて即実行する
- メリット
- よく気づく社員が疲弊しない
- 問題が深化する前に解決できる
- デメリット
- 適切な優先度判断がなされない
- 全エンジニアがPdM/PjM的な視点を持たなければなら
ない
- 妥当な説明が社内に残りにくい
Slide 48
Slide 48 text
じゃあどうするか...?
Slide 49
Slide 49 text
目次
● 技術的改善の流れ
● 技術的改善の問題点
● 指標を使おう
● 事例紹介
● 一歩先の未来とまとめ
Slide 50
Slide 50 text
技術的改善のながれ（改良版）
1. SLOをチームで見る
2. エラーバジェットの減少を認知
3. 技術的改善の実行
4. SLOの改善をチェック
Slide 51
Slide 51 text
SLO/Error Budget
SLO (Service Level Objective)
サービスを運用する上で守るべき基準値
ex. /hoge APIは99.95%で正常なレスポンスを返却する
Error Budget
事実とSLOの間にある余裕
ex. SLOが99.95%に対して事実99.97%であれば40%（0.02%分）の
エラーバジェットがある
Slide 52
Slide 52 text
どうしてSLOを使うか?
Slide 53
Slide 53 text
技術的改善のながれ（再掲）
1. 誰かが唐突に気づく
2. PMが判断可能な材料を作る
3. 優先度判断
4. 技術的改善の実行
5. 効果測定
Slide 54
Slide 54 text
技術的改善のながれ（再掲）
1. 誰かが唐突に気づく
2. PMが判断可能な材料を作る
3. 優先度判断
4. 技術的改善の実行
5. 効果測定
属人的
面倒くさい
Slide 55
Slide 55 text
Why SLO…?
属人性排除
SLOはシステム/チームに所属するので個人の所作に非依存
面倒臭さの解消
SLOを作成した段階で観測可能で合意形成が完了している
エンジニアは原因究明や改善に注力することができる
Slide 56
Slide 56 text
技術的改善のながれ（改良版・再掲）
1. SLOをチームで見る
2. エラーバジェットの減少を認知
3. 技術的改善の実行
4. SLOの改善をチェック
Slide 57
Slide 57 text
すぐに気づいてすぐに実行
Slide 58
Slide 58 text
従来との違い（属人性）
よく気づくエンジニアが、たまたま観測できた
結果として技術的改善につながっていた
問題の発生にチームで速やかに気づくことができる
もっと言えば、問題の予兆に対応ができるようになる
Slide 59
Slide 59 text
従来との違い（面倒くささ）
PMが問題を適切に評価するために資料を作る必要があった
また、これはあまりやりたい仕事ではなかった
SLOを眺めて閾値を超えているかをチェックすれば良くなった
運用フェーズで疲弊せず、最速で実行に移すことができる
Slide 60
Slide 60 text
なぜそうなっているのか
SLOを策定する場合以下について事前に考える
- 対象に問題が起きたときのビジネスインパクト
- 問題が顕在化するしきい値
コストを事前に支払うことで、運用の再現性を高め、
技術的改善の実行を容易にできる
Slide 61
Slide 61 text
目次
● 技術的改善の流れ
● 技術的改善の問題点
● 指標を使おう
● 事例紹介
● 一歩先の未来とまとめ
Slide 62
Slide 62 text
ここからタイミーの話
Slide 63
Slide 63 text
岡野兼也 / @Juju_62q
株式会社タイミー
プロダクト本部 ワーカーチーム
Backend Engineer
今日の話はtoC側の話です
Slide 64
Slide 64 text
SLO導入前の技術的改善
- 良くも悪くも熱意ベース
- やりたい人がやるべきという材料を揃えられるかが実行に対す
る強い変数となる
- ファーストビューの高速化とかは実施されなかった
- やったほうが良さそう
- やると確実に良いと説明しにくい
- 限界がどこにあるのか誰も知らない
- 何なら問題に気づかない
Slide 65
Slide 65 text
SLOを作ってどう変わったか
Slide 66
Slide 66 text
タイミーで運用中のSLO
CS, PdMなどにヒアリングを重ね、重要な機能がなにかを
調査し以下のSLOを作成した（一部抜粋）
1. API全体のx%が正常なレスポンスを返却する
2. ファーストビューがy%以上の期間でz秒以内に開く
Slide 67
Slide 67 text
技術的改善のながれ（改良版・再掲）
1. SLOをチームで見る
2. エラーバジェットの減少を認知
3. 技術的改善の実行
4. SLOの改善をチェック
Slide 68
Slide 68 text
SLOをチームで見る
- 毎日SlackでSLOを画像として投稿
- 開発スプリントごとにSLOの傾向をチェック
Slide 69
Slide 69 text
エラーバジェットの減少を認知
開発スプリント末に傾向をチェックする
- 問題が発生しそうな時期の推定
- いつ作業を入れるかを話す
Slide 70
Slide 70 text
エラーバジェットの減少を認知
違反した場合Slack内やデイリーMTGで話す
Slide 71
Slide 71 text
技術的改善の実行（SLO違反）
デイリーMTGで以下を周知する
- 違反している事実
- チームの対応
- 基本的に他の作業に作業に割り込む※
ただし、現状はエラーバジェットの減少を検知できているのであまり
発生していない
※事実として発生し、計測期間内の改善困難となった場合再発防止策をたてる
Slide 72
Slide 72 text
技術的改善の実行（例）
過去にTV露出でアクセスがスパイクし、コンテナが
落ちてしまい、DBも処理できない状態となった
結果としてALB -> ECSのアクセスが通らなくなり5xxエラーが大
量に発生し、エラーレートのSLO違反となった
これを受けてRDSのRead Replicaを増やし、重要なAPIに関してECS
Serviceを分けることでインフラの独立性を高めた
Slide 73
Slide 73 text
技術的改善の実行（例）
サービス成長や繁忙期により、x月あたりに現状のロジックでは
ファーストビューのSLOを満たせないことがわかった
ファーストビューにページングを入れることで処理対象を
制限することにした
Slide 74
Slide 74 text
SLOの改善をチェック
実行した改善がSLOにきちんと響いているかを翌日等にチェック
Slide 75
Slide 75 text
すぐに気づいてすぐに実行
Slide 76
Slide 76 text
できるようになった
Slide 77
Slide 77 text
5 一歩先の未来とまとめ
Slide 78
Slide 78 text
できるようになったこととできてないこと
- できるようになったこと
- システムの振る舞いが伴う技術的な改善
- 長期的なシステム品質低下の抑止
- できていないこと
- システムの振る舞いが伴わない技術的な改善
- リファクタリング
- インフラの刷新
Slide 79
Slide 79 text
今後やっていきたいこと
エンジニアの生産性の測定
エンジニアの生産性を測定することで、コードの可読性などシステ
ムの振る舞い以外の負債の大きさを明らかにする
挑戦に対する環境圧の形成
エンジニアが挑戦しやすい、したほうがうまくいきやすい
環境を作り負債になる前の改善をサポートする
Slide 80
Slide 80 text
まだわからないこと
- 測定や効果測定は大切であることに対して測定/観測可能に
する行為ROIをどう示すのが良いか
- 現状は定性的に判断している
- 本当にコスパが良かったのかは不明
- 根拠のない満足感が高い
- SLO違反時の行動
- 原因が常に異なるため都度都度判断している
- 現状エラーバジェット消費の逆の行動をしている
Slide 81
Slide 81 text
まとめ
- 技術的改善の問題はエンジニアリングじゃないところにありが
ち
- 合意形成
- 放置するとよく気づく人が疲弊する
- 技術的改善にはSLOを使うと便利
- 意思決定コストを前払いしているので、エンジニアにとって
は気が楽
- 責任をチームに持たせるので属人性も撤廃
Slide 82
Slide 82 text
もしこの発表を見てタイミーに興味を持った方がいればこちらご覧ください！
Slide 83
Slide 83 text
Thank you