システムとの会話から生まれる先手のDevOps

by KAKEHASHI

Slide 1

Slide 1 text

©KAKEHASHI inc. システムとの会話から生まれる先手のDevOps 2025年４月15日松本明紘 DevOpsDays Tokyo 2025

Slide 2

Slide 2 text

©KAKEHASHI inc. 株式会社カケハシ(2023年2月〜) ● AI在庫管理、医薬品のSCM関連の新規事業 ● バックエンドに軸足を置くテックリードもっち(X: @mottyzzz) 松本明紘 2 自己紹介 https://speakerdeck.com/kakehashi

Slide 3

Slide 3 text

Mission 日本の医療体験を、しなやかに。カケハシは、調剤薬局DXを入り口に日本の医療システムの再構築を目指すヘルステックスタートアップ

Slide 4

Slide 4 text

Vision 明日の医療の基盤となるエコシステムの実現。「調剤薬局DX」からはじまり、「患者コミュニケーション」、「医薬品流通」と既存の医療の垣根を超えた”つながりの連鎖”を作ります 4

Slide 5

Slide 5 text

対人業務の支援から多様なサービスへ患者フォローから調剤薬局の効率化までをサポート 5

Slide 6

Slide 6 text

Musubi AI在庫管理 6 患者さん・医薬品ごとに、AIが需要予測めんどうな在庫管理の課題を解決

Slide 7

Slide 7 text

AI在庫管理の開発チーム ● フィーチャーチームでフロー効率重視の開発 ● 仮説検証サイクルを高回転で回したい ● 開発も運用もチーム内で同じメンバーで行っている PdM(3人) デザイナー(2人) FE(7人) BE(10人) 7

Slide 8

Slide 8 text

AI在庫管理の開発チーム小さくリリースして迅速なフィードバックループを大事にし、現在まで常に改善を続けている ● フロー効率重視でリードタイムは短く ● スループット(デプロイ頻度)は高く 8

Slide 9

Slide 9 text

迅速なフィードバックループのための日々の営み 9 PullRequest を小さく小さな課題に分割エンジニア全員で日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 10

Slide 10 text

システムとの会話 10 本番環境で起きていることをシステム自身からのシグナルから確認し、それに基づいた課題解決のフィードバックループを回すこと PullRequest を小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 11

Slide 11 text

プロダクトのフェーズが変わってきた

Slide 12

Slide 12 text

2024年初旬大手法人様への導入が決定開発プロジェクトを開始

Slide 13

Slide 13 text

導入に向けてさまざまなワーキンググループが発足 ● 導入推進 ○ 既存の在庫管理システムからAI在庫管理への移行にあたりデータ移行の仕組みづくり ○ 顧客の本部組織と連携して、各店舗の移行をスムーズに進めるためのプラン策定 ● サポート体制の見直し ● 障害対応フローの見直し ○ 顧客への障害時のエスカレーション方針の確認 ○ 障害レベル、障害フローの再定義 ● 大手法人向け新規機能開発 ○ 本部組織向けの機能 ○ これまでは運用でカバーしていたものを機能化 ● 既存ユーザー向けの機能エンハンス ○ 大手法人向けの開発に注力はするが、対応がゼロにはできない 13

Slide 14

Slide 14 text

総力戦！！！

Slide 15

Slide 15 text

やるぞ！！！

Slide 16

Slide 16 text

しかしこのとき AI在庫管理のチームは課題を抱えていた

Slide 17

Slide 17 text

インシデントの対応が増えてきていた 17 PullRequest を小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハットを含めたインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応ヒヤリハットを含めたインシデント対応ヒヤリハット含むインシデント対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 18

Slide 18 text

AI在庫管理のインシデント対応 18 AI在庫管理で定義するインシデントとは https://speakerdeck.com/kakehashi/more-incident-reports

Slide 19

Slide 19 text

インシデントから成長できるチームを目指している 19 https://speakerdeck.com/kakehashi/more-incident-reports

Slide 20

Slide 20 text

インシデント対応自体は歓迎だけど増えすぎると、、、、 20 PullRequest を小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハットを含めたインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応ヒヤリハット含むインシデント対応インシデントの復旧作業インシデントの復旧作業インシデントのふりかえり暫定対応恒久対応再発防止策の実施暫定対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 21

Slide 21 text

Deploy Monitor R elease Code Test Operate P lan Build 放置したままユーザーが増えると将来は、、、 21 PullRequest を小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハットを含めたインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応ヒヤリハットを含めたインシデント対応ヒヤリハットを含めたインシデント対応ヒヤリハットを含めたインシデント対応ヒヤリハットを含めたインシデント対応ヒヤリハット含むインシデント対応インシデントの復旧作業インシデントの復旧作業インシデントの復旧作業インシデントの復旧作業インシデントのふりかえりインシデントのふりかえり暫定対応恒久対応再発防止策の実施暫定対応暫定対応暫定対応暫定対応恒久対応

Slide 22

Slide 22 text

品質・信頼性向上のワーキンググループが発足 ● 導入推進 ○ 既存の在庫管理システムからAI在庫管理への移行にあたりデータ移行の仕組みづくり ○ 顧客の本部組織と連携して、各店舗の移行をスムーズに進めるためのプラン策定 ● サポート体制の見直し ● 障害対応フローの見直し ○ 顧客への障害時のエスカレーション方針の確認 ○ 障害レベル、障害フローの再定義 ● 大手法人向け新規機能開発 ○ 本部組織向けの機能 ○ これまでは運用でカバーしていたものを機能化 ● 既存ユーザー向けの機能エンハンス ○ 大手法人向けの開発に注力はするが、対応がゼロにはできない ● 品質向上・信頼性向上　←　New ○ 大手法人導入後に大きな問題につながるようなインシデントの防止 ○ よく発生しているインシデントの発生箇所・原因箇所の見直し 22

Slide 23

Slide 23 text

過去のインシデントを分析し打ち手を検討 23

Slide 24

Slide 24 text

どのような観点での分析をしたか # 観点説明使い方 1 障害レベルレベル0〜レベル5の障害レベル発生数に対しての打ち手か、大きな障害への打ち手か、どちらへの打ち手が効果があるかの確認 2 発生月いつに発生したインシデントか何かの体制変更などのイベント、大きな機能開発など発生につながった要素がありそうかの確認 3 対象コンポーネント backend/frontend/外部システム連携/データコンポーネント、サブコンポーネントごとに見直しが必要なコンポーネントの特定 4 作り込み顕在化までの月数作り込み日から発生日までの月数リリースしてすぐの検知が多ければテスト方法やリリースプロセスの見直し。過去に作り込んだ問題が多い場合は、開発時の既存仕様の確認方法の見直し 5 検知のきっかけシステム検知、エンジニア検知、 PdM/CS検知、ユーザー検知モニタリング、アラートの強化が必要か 6 現象が発生した機能発注、在庫管理、処方などの機能見直しが必要な機能の特定 7 原因となった機能発注、在庫管理、処方などの機能原因と現象発生の機能が異なる場合は、機能やシステムの依存関係が複雑になっている可能性がある 8 技術的要因の区分状態管理不正、計算ロジック不正、ライブラリアップデート偏りが見られる場合は、全体への類似見直しを検討する 24

Slide 25

Slide 25 text

リスクアセスメントを行い優先度を決定 25

Slide 26

Slide 26 text

対応を進めた結果 26 ● インシデントの発生頻度を1/3にすることができた ● 重大な顧客影響にしないために、問題の検知から薬局の業務開始までにリカバリーをしていたような夜間のインシデント対応を無くすことができた

Slide 27

Slide 27 text

リードタイム・デプロイ頻度への影響 ● 特にデプロイ頻度に関しては数値上は少しだけしゃがむ結果となった ● 結果的に、その後のデプロイ頻度は上昇傾向 27

Slide 28

Slide 28 text

健全なフィードバックループへ 28 PullRequest を小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 29

Slide 29 text

大手法人への導入を無事に終えることができた

Slide 30

Slide 30 text

先手を打てた部分もあるが、大手法人様への導入を進める中で初めて気づけたものもあった

Slide 31

Slide 31 text

インフラコストが急上昇！！？

Slide 32

Slide 32 text

ログによるインフラコストが指数関数的に増加し始めた ● 線形ではなかった ● これまでの店舗数増加では単純な比例関係に見えていたが、急に指数関数的に増加した 32

Slide 33

Slide 33 text

見直しを実施したログ ● AWSのインフラが出力するシステムログの削減 ○ Infoレベルの情報はトラブルシュートでもほぼ使っていなかったため、出力ログレベルをWarnレベルに変更し、ログの書き込み量を削減 ● アプリケーションで出力していた一部のInfoログの停止 ○ なんとなくの安心感のために出力し、使っていなかったアプリケーションのログを出力しないように変更 ● 内部処理のトラブルシュートためのトレース情報の保管期間の見直し ○ トレース情報は過去に渡って確認することがなかったため、保管の期間を見直し ○ CloudWatch LogsとDatadogの両方に保管していたトレース情報をDatadogのみに変更 33

Slide 34

Slide 34 text

実施方法自体も変えていかないといけなかった 34 ● 事業拡大でユニットエコノミクスも健全化が必要なタイミング。インフラコストの変化に気づくための確認頻度の見直しや、インフラコスト増加に対する感度を上げておかなければならなかった ● ユーザー数の増加に合わせて、書き込むログの内容やアラートの運用方法も見直しが必要だった PullRequest を小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブでの検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 35

Slide 35 text

DB負荷が2倍に

Slide 36

Slide 36 text

大手導入によって増加したDBのCPU使用率 36 ● 導入自体は一定の店舗数ごとに段階的に行っていたのになぜ？ ● 他の対応もあり、原因調査や負荷対策の工数が取れず、短期的な対応工数の少ないDBインスタンスのスケールアップ実施によって回避した ● それによって、この対応もインフラコストを増加させてしまった

Slide 37

Slide 37 text

大手法人はこれまでとはパフォーマンス傾向が異なっていた 37 これまでの店舗でDB負荷が大きい機能店舗と機能ごとのパフォーマンスの悪さ（DB負荷の大きさ）を表すヒートマップ機能A 大手法人の店舗でDB負荷が大きい機能店舗右側が後から導入した店舗(大手法人の店舗) 後日、原因の調査をしたところ、負荷やパフォーマンスに想定外の変化があった機能B 機能C 機能D 機能E 機能

Slide 38

Slide 38 text

確認の考え方や粒度も変えていかないといけなかった 38 ● 機能の使われ方もこれまでとは異なっていたため、もう少し細かな粒度でモニタリングと検知をできるようにしておく必要があった PullRequest も小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 39

Slide 39 text

それ以外にも色んな考え方を変化させていく必要があるこれまで拡大期(大手法人導入〜) 一度に導入される店舗数数店舗〜数十店舗数百店舗機能性と品質 AI在庫管理のコア機能であるおすすめ発注など、魅力的品質が求められてきた魅力的品質はもちろん、資産管理としての在庫管理としても使われるため、当たり前品質も求められるようになった導入時のデータ投入１店舗ずつなど進められた同時に複数店舗の大量のデータ投入が必要になり、データ投入時のシステム負荷が無視できないパフォーマンスとスケーラビリティ除々に遅くなるなど変化が緩く、システム全体の日々のモニタリングで十分に対処できていた導入店舗が急に増える、かつ、機能の使われ方も変わったため、急なパフォーマンス変化が見られた。これまでよりも細かいモニタリングの粒度が必要だったモニタリングとアラート日々のモニタリングで、対応が必要な場合も十分に対処できていたシステム規模が大きくなりこれまでのモニタリング粒度では変化を把握できないアラート数も増え、対処が間に合わなくなる運用エンジニアの手動での運用でも十分に対応できていた店舗数が増えたことで日々の運用にかかる時間も増えてきたインフラコスト PMFを優先し、ある程度無視できた 1店舗あたりのコストの健全性も事業継続のために重要になってきた 39

Slide 40

Slide 40 text

開発のためのフィードバックループだけじゃなく日々の運用もフィードバックループの中で改善できるようになりたい

Slide 41

Slide 41 text

やることはたくさん！

Slide 42

Slide 42 text

チーム全体で変化に余裕を持って対応できる習慣を作りたい

Slide 43

Slide 43 text

フィードバックループをさらに変化に強くする① 43 変化に合わせて日々の営みを変化させていくためにチームが柔軟に動けるための余白を作る PullRequest も小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼン、そして余白も一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 44

Slide 44 text

スプリントの後ろに計画的に余白を作る 44

Slide 45

Slide 45 text

スプリントの後ろに計画的に余白を作る下記のようなワーキングアグリーメントで実際に取り組んでいる ● 1週間スプリントの5日目はロードマップの開発は行わない ● プランニング時点で１週間の最初の3日で完了するくらいの余裕をもった計画にする ● 想定より早くそのスプリントの開発が完了しとしても、次の開発項目を始めない 45

Slide 46

Slide 46 text

フィードバックループをさらに変化に強くする② 46 変化に合わせて日々の営みを変化させていくためにチームが柔軟に動けるための余白を作る PullRequest も小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼン、そして余白も一緒にプランニングヒヤリハット含むインシデント対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認アラートの確認と対応さらにレビュー負荷を小さく Deploy Monitor R elease Code Test Operate P lan Build

Slide 47

Slide 47 text

Tidy First? チームに信頼があり、盤石な文化があれば、整頓にはレビューは不要だ整頓はレビューしなくてもよいというレベルの安全と信頼に到達するには、何ヶ月もかかる。練習しよう。実験しよう。みんなでエラーをレビューしよう。 https://www.oreilly.co.jp/books/9784814400911/ “ ” 47

Slide 48

Slide 48 text

実際にこんなルールで取り組みを開始しました 1. PullRequestタイトルのプレフィックスを [Tidy] とつける 2. 変更内容が単一である（複数の変更をひとつのPullRequestに含めない） 3. 修正箇所のテストが存在し、テストが通っている（コメントのみの修正等は除く） 4. アプリケーションの挙動は変わっていないこと 5. 可逆的である（不具合が発生した場合は、このPullRequestをRevertするだけでよい） 6. 不具合が発生するリスクが低い自信を持てている（PullRequest 作成者の自己申告でよい）レビュー負荷軽減のため、レビューなしマージの取り組みを開始した 48

Slide 49

Slide 49 text

気持ちにも余裕が出てきた

Slide 50

Slide 50 text

問題が起きそうなときに日々の営み自体をアップデートする習慣ができてきた

Slide 51

Slide 51 text

さらに先手を打てるようにするために取り組み始めたこと

Slide 52

Slide 52 text

SLOを導入することでチーム全体が何を達成すべきかを明確にする

Slide 53

Slide 53 text

日々の営みにSLOを追加導入 53 PullRequest を小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認 SLOによるサービスレベル低下の検知運用や保守、カイゼンも一緒にプランニングヒヤリハット含むインシデント対応アラートの確認と対応 Deploy Monitor R elease Code Test Operate P lan Build

Slide 54

Slide 54 text

AI在庫管理においてのSLO設定のねらい ● AI在庫管理のチームは、開発・運用・QAが分かれていないため、本来リリース時のガードレールが設定されるようなところに明確なガードレールがない ● そのため何らかのサービスレベル低下の検知後、エンジニアが対応の必要性を判断しており、その中でもその特定のサービスに詳しいメンバーが直感的な判断を行っている ● SLOを設定することで、エンジニア以外を含めたチーム全体がシステムの安定運用のために対応の優先順位を判断できるようにする 54

Slide 55

Slide 55 text

SLO導入による期待するフィードバックサイクル 55 PullRequest も小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用や保守、カイゼンも一緒にプランニング →サービスレベル低下への対応を計画ヒヤリハット含むインシデント対応 →SLOを下回った場合にインシデントとしてチームで対応ペア・モブで検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認 SLOによるサービスレベル低下の検知アラートの確認と対応 →エラーバジェットでアラート疲れを防止 Deploy Monitor R elease Code Test Operate P lan Build

Slide 56

Slide 56 text

さらなる大手法人導入に向けて想定される課題 56 観点想定される課題感指標可用性特になし。マネージドサービス中心に使用していること、24/365のシステムではないーレイテンシーデータ量増加に伴って一部のAPIにパフォーマンスの劣化の可能性 ● APIごとのレイテンシー ● APIごとのタイムアウト数スケール性将来のスケールアウトが必要なタイミングの予測が困難。また、顧客数増加に対しての妥当な負荷増加なのか、不当な実装での負荷増加なのかの把握が難しい ● 店舗数増加との関係値 ● 店舗単位の負荷、リソース使用量データの納期データ量増加に伴って、バッチ処理が店舗の業務開始に間に合わなくなる ● 完了時間データ品質使用傾向の異なる顧客が増え、AIの出力結果の品質(精度)が下がる ● 出力結果の制約に異常検知率 ● 入力値や結果の分布変化値

Slide 57

Slide 57 text

さらなる大手法人導入に向けて想定される課題 57 観点想定される課題感指標可用性特になし。マネージドサービス中心に使用していること、24/365のシステムではないーレイテンシーデータ量増加に伴って一部のAPIにパフォーマンスの劣化の可能性 ● APIごとのレイテンシー ● APIごとのタイムアウト数スケール性将来のスケールアウトが必要なタイミングの予測が困難。また、顧客数増加に対しての妥当な負荷増加なのか、不当な実装での負荷増加なのかの把握が難しい ● 店舗数増加との関係値 ● 店舗単位の負荷、リソース使用量データの納期データ量増加に伴って、バッチ処理が店舗の業務開始に間に合わなくなる ● 完了時間データ品質使用傾向の異なる顧客が増え、AIの出力結果の品質(精度)が下がる ● 出力結果の制約に異常検知率 ● 入力値や結果の分布変化値 SLOとして設定オブザーバビリティ強化

Slide 58

Slide 58 text

SLO導入初期の考え方 ● レイテンシーはユーザー体験の悪化に大きく影響を与える分かりやすい指標 ● エンジニア以外を巻き込んだ運用になるため、まずはシンプルな少ない指標と目標でSLMの実践をスタートさせたい ○ 運用が軌道に乗ってから他の指標の追加を検討する ● 他の課題に関してはサービスレベルというよりはシステム内部の把握のための指標であるため、まずはオブザーバビリティの強化として扱う 58 APIごとに、30日間のローリングウィンドウで、 ● 99%tile(APIによっては95%tile) 値のレイテンシーが今のベースライン＋α以下 ● タイムアウト数が今のベースライン＋α以下

Slide 59

Slide 59 text

業務領域の分類おすすめ発注医薬品売却在庫管理それ以外の発注複雑さ顧客にとっての価値処方箋管理本部管理中核の業務領域補完の業務領域一般の業務領域一般または補完の業務領域システムの規模が大きくなり、APIだとしても一律の考え方では適切な設定が難しい。機能を業務領域で分類し、その分類ごとに設定する 59

Slide 60

Slide 60 text

業務領域の分類によるスコープの絞り込み顧客にとって魅力的な価値を提供できている機能や、業務が複雑な機能(システムも複雑になりがち)の優先度を上げてスコープを絞り込む 60 顧客にとっての価値

Slide 61

Slide 61 text

ここまではこれまでより悪化してないかというシステムを守るための目標値

Slide 62

Slide 62 text

それだけで良い？

Slide 63

Slide 63 text

チーム全員が主体的にシステムを良くしていけるように

Slide 64

Slide 64 text

二段階のSLO設定目的スコープ目標値の考え方守りのSLO ● ユーザー数の増加や機能追加による変化によるシステムの安定稼働を守る ● 不要なアラートへの対応を抑制、アラート疲れを防ぐ ● 現状課題が見られる指標 ● 大手導入の拡大期において課題が想定される指標 ● 設計が妥当かどうかを示す値 ● 現状よりも急激に悪化していないかどうかを確認できる値攻めのSLO ※実態としては組織 OKRに近いがSLO の仕組みで運用する ● エンジニアが主体的にシステムを良くしていくために、背中を押してくれる ● 将来目指したいシステムの状態を測る指標 ● エンジニア主体でできるユーザー体験を向上させる指標 ● 現在地からするとムーンショットな目標値

Slide 65

Slide 65 text

守りのSLOと攻めのSLO 65 PullRequest も小さく小さな課題に分割エンジニア全員での日々のログ・ダッシュボード確認運用やカイゼンも一緒にプランニング →サービスレベル低下への対応を計画ヒヤリハット含むインシデント対応 →SLOを下回った場合にインシデントとしてチームで対応ペア・モブ中心の検討・開発シフト制の運用作業自動テスト CI/CD データ分析による効果検証定期的なインフラコストの確認【守りのSLO】によるサービスレベル低下の検知【攻めのSLO】による目指す姿の明確化できた余白と目標によって主体的なカイゼンエンジニアが主体となってBiz側とサービスレベル向上の提案アラートの確認と対応 →エラーバジェットでアラート疲れを防止 Deploy Monitor R elease Code Test Operate P lan Build

Slide 66

Slide 66 text

業務領域の分類によるスコープの絞り込み攻めのSLOのスコープは目指す姿を明確にするために、さらに絞り込む 66

Slide 67

Slide 67 text

攻めのSLO設定の具体例(数値は仮決め状態) 67 ● 中核の業務領域のAPIの９９％tile値のレイテンシーを500ms以下 ● 中核の業務領域のAPIのタイムアウト数をゼロ ● AI在庫管理の魅力的な機能をさらに魅力的にするための指標設定 ● 中核の業務領域の機能の一つである、AIによるおすすめ発注は、すべてのロールのメンバーが関わる機能であるため、誰一人無関係ではいられない機能

Slide 68

Slide 68 text

まだ始めたばかりですが、 SLOの導入によってさらにより良いフィードバックループを回せるように取り組んでいきます

Slide 69

Slide 69 text

おわりに

Slide 70

Slide 70 text

迅速なフィードバックループによる学習サイクル 70 ● 機能開発では、小さくリリースし、効果検証を繰り返す ● 運用の側面では、システムとの対話により、本番環境からのシグナルを測定し、システムの安定稼働のための改善を繰り返す

Slide 71

Slide 71 text

フィードバックループの安定化 ● プロダクトの大きな変化に対しフィードバックループが維持できない危機もありえる。フィードバックループの維持のために時にはしゃがむことも必要だった ● 開発に余白を取り入れ、さらに安定したフィードバックループの継続を目指す 71

Slide 72

Slide 72 text

二段階のSLO設定でさらに良いループを回す 72 ● これからの大手法人導入において、システムの安定稼働に対して先手を打てるようにシステムを守るためのSLOを導入 ● チーム全員が主体的にシステムを良くしていけるように、明確な目標値となり得る攻めたSLOを導入

Slide 73

Slide 73 text

仕事に追われている状況だからこそ先手を取れるように一歩踏み出してみませんか

Slide 74

Slide 74 text

ありがとうございました！！！！！！ 74 カケハシの技術に関連する情報を発信しています！ 𝕏 @kakehashi_dev 是非フォローもお願いします！