o11yで育てる、強い内製開発組織

2025-10-15 [内製開発フォーラム](https://vpoe-summit.findy-tools.io/2025-inhouse-dev) での登壇資料です。

#内製開発フォーラム

Transcript

1. o11y で育てる、強い内製開発組織 ~ 2025-10-15 内製開発フォーラム ~ KINTO テクノロジーズ株式会社 粟田 啓介
2. ©KINTO Corporation. All rights reserved. 2 自己紹介 mysql > SELECT * FROM me \G ******************* 1. row ******************* name: 粟田 啓介 nickname: あわっち X(twitter): @_awache company: KINTO テクノロジーズ株式会社 role: DBRE/SRE MGR、KINTO Innovation Lab favorite: MySQL 1 rows in set (0.00 sec) NEW
3. ©KINTO Corporation. All rights reserved. 3 本日の発表に関して ◼ 話すこと ◼ なぜエンジニア組織に observability (o11y) が不可欠なのか ◼ New Relic を活用した実践事例と学び ◼ o11y を組織運営・人事評価に広げた経験 ◼ 話さないこと ◼ 個別ツールの導入手順や設定方法 ◼ メトリクスやログの細かいチューニングノウハウ ◼ 各ベンダーの機能比較やプロダクトレビュー
4. ©KINTO Corporation. All rights reserved. 4 KINTO テクノロジーズ株式会社 (KTC) について 2021年04月設立 2019年01月設立
5. ©KINTO Corporation. All rights reserved. 5 KTC の立ち位置 トヨタグループ初となる「BtoC・DtoC領域に特化した内製開発組織」
6. ©KINTO Corporation. All rights reserved. 6 持続的に Delivery を維持するための o11y 1
7. ©KINTO Corporation. All rights reserved. 7 内製開発で最も重要なことは？ 理想を言うなら QCD のバランスがいい状態 ◼とはいえ現実はそんなに簡単ではない Quality Cost Delivery
8. ©KINTO Corporation. All rights reserved. 8 プロジェクトをしていると Delivery 優先になりがち 一見うまくいっているように見える ◼短期的には成果が出ている ボディーブローのように効いてくる Quality の低下 ◼Delivery を優先し過ぎた結果、テストや運用が後回しになる 開発の停滞 ◼障害対応にリソースを取られ、メンバーも疲弊し、開発が鈍化する 走っているつもりがいつの間にか走れていない状態になってしまう その裏で起こりうる課題
9. ©KINTO Corporation. All rights reserved. 9 なぜ Delivery 優先になるのか 短期成果の要求 ◼ROI をすぐに示す必要があり、「まずは目に見える成果」を求められる 市場投入の急務 ◼競合に遅れないためにリリース速度が最優先され、品質が後回しになる コスト最適化の圧力 ◼先行投資よりも「すぐに使える機能」に予算が割かれやすい 品質投資は後回しになりやすい ビジネスの期待とスピードのプレッシャー
10. ©KINTO Corporation. All rights reserved. 10 なぜ Delivery 優先になるのか 少人数体制 ◼「作る」と「守る」を同じ人が兼務せざるを得ない Delivery 優先のアサイン ◼確実に成果を出せる人を前に置くため、属人化が進み開発偏重になりやすい 役割の未分化 ◼責任範囲が曖昧で、結果として開発タスクが優先されやすい 人に依存する体制が“守り”を後回しにさせる 限られたリソースと未整備な体制
11. ©KINTO Corporation. All rights reserved. 11 持続的に成長するために必要なこと 開発を持続的に進化させるカギとなる要素が o11y Delivery は当然優先されるべき ◼ ビジネスである以上、スピードと成果を出すことが第一 ◼ それを求めて組織も動いていく必要がある 忘れがちな視点 ◼ Quality も実は Delivery に直結する要素 ◼ 大事なことは両者のバランスを取り続けること 目指す姿 ◼ 開発を継続的に進められる基盤を持つ ◼ 改善サイクルを回し続け、組織として成長できる ここを変えられれば開発のスタイルそのものが変わる
12. ©KINTO Corporation. All rights reserved. 12 開発スタイルそのものを進化させる 障害対応などの時間を最小限にしつつ、持続的に Delivery を続けるための基盤としての o11y 見えない問題に気づき、改善サイクルを回せる ◼普通なら見逃す不具合や劣化も、数値やログからその兆候を可視化できる ◼問題が見えるから、改善にすぐ着手できる 検知が仕組み化される ◼人の気づきに依存せず、自動で異常を捉えられる ◼特定の人しか分からない状態を防ぎ、誰でも状況を理解できる 原因特定が速い ◼どこで何が起きているか可視化されることで障害復旧にかかる時間が大幅に短縮され、 開発に集中できる 結果として持続的に Delivery を維持できる開発スタイルになる
13. ©KINTO Corporation. All rights reserved. 13 KTC SRE の活動 2
14. ©KINTO Corporation. All rights reserved. 14 KTC における DBRE / SRE の立ち位置 エンジニア組織： 約 30グループ 社内のエンジニアの数： 約 350名 アプリケーション開発組織 • KINTO サービス開発 • グローバル 基盤開発 • バックオフィスシステム開発 • モバイルアプリ開発, etc. 横断組織 (プラットフォーム開発部) • QA • クラウドインフラ • DBRE / SRE • Platform Engineering • MSP (24*365 保守運用) プラットフォーム開発部 QA クラウドインフラ DBRE / SRE MSP アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 ・・・ Platform Engineering
15. ©KINTO Corporation. All rights reserved. 15 KTC SRE が KTC に良い影響を与えるための第一歩 見えないものは管理できない ◼ システムの状態を可視化し、正常が分かっているからこそ異常がわかる ◼ リアルタイムな影響把握で迅速な意思決定を行う ◼ 根拠ある改善と予防策の策定を可能にする ビジネスへの影響を最小限に抑える まずはモニタリングとインシデントレスポンスから！
16. ©KINTO Corporation. All rights reserved. 16 New Relic を強力に推進 可視化の先にあるアクションが重要 ◼課題発見と改善につなげるための仕組みが揃っている ◼従来は複数ツールを組み合わせた基盤で学習コストが高く自走しにくかった ◼可視化を目的にしない、その先にあるものを見る 自分たちで「見える」を育てられる ◼事業 KPI と開発の指標を一本で結び、経営と現場の共通言語にする ◼仮説→実装→観測→学習のループを短くし、意思決定の速度と質を上げる ◼顧客体験の変化をプロダクト内の要因まで遡れるようにし、優先順位付けを迷わない 可視化→解釈→アクションが自律的に回る“育てられる基盤”として New Relic を推進 なぜ New Relic を推進したのか
17. ©KINTO Corporation. All rights reserved. 17 New Relic 活用の推進 課題 ◼ New Relic を導入したはいいものの、障害発生時にしか使わない ◼ 日常的なメトリクス監視やプロアクティブな改善が根付いていない 取り組み ◼ KINTO のバックエンドチームと New Relic をどう活用するかについて定期的な MTG を実施 ◼ ダッシュボードを作って日次の定例で眺めてもらうことに 効果 ◼ プロアクティブなパフォーマンス改善が始まった ◼ 現場ならではの改善提案も出るようになった メトリクスを見る習慣づけ
18. ©KINTO Corporation. All rights reserved. 18 Delivery を止めない対応力を仕組みでカバー インシデントレスポンスの確実性を高める ◼実際に発生したアラートを New Relic のログやトレース情報から逆算しリクエスト解析 ◼エラー原因を素早く、かつその人の調査スキルに依存しない形で把握できる New Relic 活用の推進 - リクエスト解析ツールの提供
19. ©KINTO Corporation. All rights reserved. 19 プロアクティブな改善サイクルを推進 New Relic のログやトレースから、障害には至っていない“怪しい挙動”を検知 ◼検知した兆候をもとに改善提案を作成 ◼Devin など自動化された開発支援ツールを活用し、修正まで一連で対応 潜在的な問題を先回りして解決
20. ©KINTO Corporation. All rights reserved. 20 o11y を組織運営に広げる 3
21. ©KINTO Corporation. All rights reserved. 21 エンジニア組織における評価の課題 何をもって公平とするか ◼個人の貢献を客観的に捉えること ◼プロセス・アウトプット・インパクトを適切に見極めること なぜ公平性が必要か ◼不透明な評価はモチベーション低下や離職を招く ◼評価のブレは組織文化を損ない、信頼を失わせる ◼公平な評価はエンジニアの成長を支え、結果として組織の持続的な開発につながる 公平な評価は、信頼と成長を支える組織運営の土台になる アウトプットを公平に見極める難しさ
22. ©KINTO Corporation. All rights reserved. 22 公平な評価をするために必要なこと 期待値設定 ◼自分がメンバー一人ひとりに何を期待しているのかを最初に明確にする ◼同時に、自分がマネージャーとしてメンバーに何をもたらすのかを示す 期待値を明確にする
23. ©KINTO Corporation. All rights reserved. 23 公平な評価をするために必要なこと 会社テーマを翻訳する ◼会社のテーマは抽象度が高い ◼それぞれの言葉を自分が咀嚼できない状態でメンバーに共有すると、 不満は組織ではなく会社(のトップ)に向く 組織の言葉に変換することによって「矢印を自分 (MGR) に向ける」ことができる 会社からのメッセージを自分の組織に組み込む
24. ©KINTO Corporation. All rights reserved. 24 公平な評価をするために必要なこと 目標設定 メンバー自身のやりたいこと ◼ 上から落としたものだけがやるべきことではない ◼ メンバーにしか見えない課題があるかもしれない ◼ 各自が考えることでチームを「自分ごと」に落とし込める マネージャーの役割 ◼ メンバーがやりたいことをチームの方向性につなげる ◼ このプロセスを「矢印を組織に向ける」と表現している OKR形式での分解 ◼ 立てた目標をOKR形式で整理する ◼ 今の立ち位置とこれからやるべきことを可視化できる
25. ©KINTO Corporation. All rights reserved. 25 エンジニア評価の軸 定量的なアウトプット ◼この4つを押さえれば日常的な活動を客観的に把握できる ◼プロセス・成果・議論のログが揃う 評価の組み合わせ方 ◼期待役割・等級定義・目標の進捗を掛け合わせる ◼どこをどう見ているかを示すことで納得感のある評価FBができる 透明性のある評価プロセスが、信頼と成長を支える 基本的には GitHub, Confluence, Jira, Slack
26. ©KINTO Corporation. All rights reserved. 26 o11y を組織運営に広げる データの源泉 ◼ GitHub → コード・レビュー・コミット履歴 ◼ Confluence → ドキュメント化・ナレッジ共有 ◼ JIRA → タスク進捗・課題管理 ◼ Slack → コミュニケーション・意思決定ログ o11y の視点で接続 ◼ 個人の行動や成果を「見える」状態に統合 ◼ プロセス（取り組み方）とアウトプット（成果物）を両面で把握 ◼ 定性的な印象ではなく定量的な活動トレースで評価の基盤を作る 評価への展開 ◼ 期待役割・等級定義・目標進捗と掛け合わせる ◼ フィードバックの納得感を高め、公平性を担保 ◼ 評価プロセスそのものが組織の改善サイクルに直結 日常の活動を“観測可能”にすることで、公平な評価が可能になる アウトプットを可視化し、公平な評価につなげる
27. ©KINTO Corporation. All rights reserved. 27 実際の評価ツール 必要な情報を API で取得、サマリを生成させた上で評価を生成 自分が楽をするためだけの自分のためのツールを(勝手に)開発
28. ©KINTO Corporation. All rights reserved. 28 まとめ 4
29. ©KINTO Corporation. All rights reserved. 29 まとめ 持続的に Delivery を維持するための o11y ◼Delivery と Quality のバランスが保たれる ◼見えない問題を捉え検知→原因特定→対処のリードタイムを短縮 ◼結果として改善サイクルが回り続け開発を止めないスタイルが作られる KTC SRE の活動 ◼New Relic を推進し「見える→解釈→アクション」を自律化 ◼インシデントレスポンスの再現性向上とプロアクティブ改善を定着 o11y を組織運営に広げる ◼アウトプット可視化で評価の透明性と納得感を高める ◼期待値設定→目標→ OKR → FB を一本化し評価を運用と接続 ◼公平な評価が信頼と健全な成長の土台になる
30. o11y を文化として根付かせる準備はできていますか？
31. Thank you！