wan0ri Lab

freee 技術の日 2025 参加メモ【イベント感想】

· wan0ri· Category: Event

TL;DR

  • 2025 年 11 月 30 日（日）開催の「freee 技術の日 2025」を視聴（インフラ/ SRE 関連セッションのみ）。
  • SLO Service Level Objective。SLI に対する“目標値”。 / エラーバジェット SLO を満たしつつ“許される失敗の枠”。意思決定の通貨。 を“止める規則”ではなく 意思決定のものさし として運用する姿勢が腑に落ちた。
  • 認知負荷を下げる仕組み（押すだけダッシュボード、最小アラート、例外運用の雛形）が継続の鍵。
  • 設計は 「前提 → 概算 → 手筋 → 検証」 の反復。観測可能性と段階的リリースを最初から設計に入れる。

参加イベント

2025 年 11 月 30 日（日）に開催された「freee 技術の日 2025」を視聴しました。
以下のページで案内されています。

connpass
freee 技術の日 2025 (2025/11/30 12:00〜)

＞＞ 公式サイト ＜＜ ## 技術の日とは 「freee 技術の日」は 2023 年から開催している freee のテックカンファレンスです。 テックカンファレンスと聞くと一般的にエンジニア向けのイベントを想像する方も多いかもしれません。しかし「freee 技術の日」は決 …

freee.connpass.com/event/364367/

免責

本記事は 2025 年 11 月 30 日時点のイベント視聴に基づく私的メモであり、登壇資料の直接引用・転載は行っていません。

視聴メモ（SRE/Infra）

セッション要旨

  • 組織分割の狙い

    • ミッションは「信頼性」と「開発生産性」の両立。前者を SRE、後者を Platform として分割し、セルフサービス 開発者が自律的に基盤を利用・変更できる状態。 を軸に加速。
    • 参考にした枠組みは Team Topologies チーム構造と協働様式のデザイン指針（書籍/フレームワーク）。 。ストリームアラインド（事業価値の流れに沿う）チームが自律的に回せる前提を作る。

  • 2 つの協働モード

    • X-as-a-Service モード “サービスとして提供”の関係様式（利用側はセルフサービスに近い体験）。 : SRE/Platform が提供する共通基盤をプロダクト側が“サービスとして”利用。
    • Collaboration モード Embedded SRE 的な期間限定の伴走。現場で課題を共に解き、知見を横展開。 : 期間限定で伴走し、生の課題を一緒に解き、後で横展開（標準化/共通化）。

  • 統一インターフェース

    • 相談窓口は Slack の「Ask SRE」 SRE への問い合わせを集約するチャンネル。 を単一入口に集約。依頼はそこで受け、SRE/Platform のどちらがオーナーでも同じ窓口からハンドリング。
    • これにより、組織分割後も“どこに聞くか”の認知負荷を一定に保てた。

  • 進め方（当時の課題と解き方）

    • 中央集権で一律のイネーブリングがボトルネック。プロダクトの成熟度・アーキ差を踏まえず横並び適用していた。
    • まず“ドメイン棚卸し”で領域と責任境界を言語化。優先順位付け（ロードマップ）とオーナー明確化で意思決定を速く。

  • 成果と気づき

    • ミッション/ビジョンとオーナーの明確化で改造度が上がり、ロードマップの引き直し（価値の大きい順）を素早く実施可能に。
    • AI 活用を SRE 運用に実装。例: Datadog アラートの一次判定エージェント アラート内容や過去対応を根拠に一次判断を自動化する仕組み。 、Ask SRE 質問の一次応答エージェントで取次ぎ負荷を軽減。

  • デメリットへの手当

    • サイロ化・窓口混乱は、単一窓口（Ask SRE）＋横断 PoC（例: LLM 可観測性の検証）で緩和。

後に試してみたいこと （自分向け）

  • 単一窓口の徹底: 自チーム版「Ask SRE」を唯一の入口にし、振り分け/優先度/オーナー決定を“その場で”完了。
  • ドメイン棚卸し: SRE/Platform/各プロダクトで責任境界を 1 枚に明文化（相談先と完了定義をセット）。
  • SLO 運用の定着: 3 件までに絞り、ダッシュボード → 月次レビュー → 四半期見直し＋例外運用の雛形を用意。
  • AI トリアージ PoC: Datadog アラートの一次判定と Slack 質問の一次応答をエージェントで試行（監視: 誤判定率/回収率）。
  • セルフサービス加速: 新規プロジェクトのブートストラップ時間を測り、テンプレ/自動化で短縮（現状 → 目標 → 差分）。
SRE 運用ミニテンプレ（コピペ可）
## 対象/目的

- 対象: <例: 注文 API>
- 目的: <例: 障害対応の判断を“SLO 基準”に揃える>

## SLI/SLO（初期案）

- 成功率: <HTTP 2xx 率 / 28 日 / 除外: デプロイ 10 分>
- レイテンシ: <p95 < 300ms / 28 日>
- 鮮度: <例: 同期遅延 < 60 秒>

## 可視化/アラート

- ダッシュボード: <URL or 名称>
- Pager 条件: <SLO 直結のみ>
- それ以外: 週次レビューで確認

## 例外運用（サンプル）

- 例外承認者: <PdM or EM>
- 期間/範囲: <例: 新機能 A の限定ロールアウトのみ>
- 事後対応: PIR（Post-Incident Review）で恒久対策まで記録

## レビュー

- 月次: 運用指標チェック（アラート量/MTTA/MTTR）
- 四半期: SLO の妥当性をサポート/NPS と照合
Topへ戻る