成長を続ける組織でのSRE戦略： プレモーテムによる信頼性の認識共有 CTO 丹羽健 SRE Next 2022 

● ASCEND 株式会社 CTO ● 新卒でSIerに入社、 ベンチャー企業の経験をへて現職 ● 業務特化型の Vertical SaaS 開発歴５年 ○ 飲食店向けハンディアプリ ○ 行政向け電子申請サービス ○ 運送会社向け運行管理 ● 特技は料理のリバースエンジニアリング 丹羽 健 Niwa Takeru 

シード期のスタートアップとして 限られたリソースの中で費用対効果を考え SRE活動を進めてきたナレッジの共有です 

Goal 1. アセンド株式会社の紹介 2. ポストモーテム運営での課題 3. 信頼性についての再考 4. プレモーテムの設計 5. プレモーテムの効果 Agenda 適切な信頼性のターゲットを元に SRE戦略をとる重要性について知る 信頼性のターゲットを組織内で 認識共有するための プレモーテムについて知る スタートアップにおける信頼性 プレモーテム 

私たちが対象とする運送業界は エッセンシャルワーカーと言われながらも 労働時間は２割長く給料は２割低いという課題があります この社会課題を解決するため 私たちアセンドは運送管理 SaaS LogiX を開発しています アセンド株式会社 Mission 物流DXを推進し 物流業界の価値を最大化する。 

設立 2020年03月 従業員数 25名（副業・業務委託を含む） SERIES シード期 （累計調達額 2.5 億円 @ 2021年12月） エンジニア ９名 正社員４名、副業５名 アセンド株式会社 現在は Product Market Fit を目指して 理解と信頼関係のあるユーザ・運送会社に導入し ハイスピードでプロダクト開発を進行中 

エンジニア組織設計 Learning & Feedback Design Deploy Test Operate Develop Support Full Cycle Developers at Netflix — Operate What You Build https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 １エンジニアの担当領域が広いため、 SREに限らず自動化・効率化に積極的に投資 運送事業者の複雑なドメイン知識を学び、 価値あるプロダクトを迅速に開発するために Full Cycle Developer での開発スタイルを選択 ● Netflix における開発スタイル ● DevOpsよりも広く Software Lifecycle 全体に対して エンジニアがオーナーシップを持って取り組む 

Lean と DevOps の科学の 4 Keys を参考に デプロイ頻度を重点指標として技術を選定 ● Full Cycle Developer ● Full TypeScript Architecture ● ArgoCD x GitOps 高頻度なデプロイでのプロダクト開発 Deploys / Day 3.6 デプロイ頻度が高ければ障害も当然発生する 障害発生を前提としてポストモーテムを実施 

発生した障害を振り返ることで信頼性向上の糧とする ヒトを責めずコトに向き合う建設的な議論をする ● 障害は努力で防ぐのではなく仕組みで防ぐ ● 高い心理的安全性が保たれていることが前提 フラットに議論ができる環境を整える ポストモーテムによる障害の振り返り 成功のためのポイント 

ポストモーテムの運営で発生した課題 メンバー間での異なり 信頼性の共通認識を取れていない。信頼性について改めて考えてみた。 発生した障害に対する重要度の捉え方がメンバー間で異なり 過大な対策案・過小な対策案などバラツキが発生し議論の収拾しない問題が発生 ● 大企業出身の新規入社メンバー ○ 過大な対策案：高い信頼性は当然という前提から Unlearning できていない対策案 ● 副業エンジニア ○ 過大な対策案：ユーザの業務利用上で重要でない機能への対策案 ● プロダクト初期構築時からのメンバー ○ 過小な対策案：現在のユーザ数に見合わない障害への楽観視 ● CS（カスタマーサクセス）担当者 ○ 対策不要案：現状のユーザー数であればCSサポートで十分に解消可能、 エンジニアはどんどん機能開発を攻めてほしい 

信頼性のターゲットは高過ぎてもいけない 背景 適切に信頼性を捉え、効果的にSRE戦略を取るべき PMF以前でユーザ数が少ない頃のスタートアップにおいては、 ユーザが真に求めるのは信頼性の向上よりも機能拡充・プロダクト価値の向上 ● 業務系SaaSでは一定の信頼性は必要なものの １時間未満のシステム停止でさえ許容されるケースはある ● ユーザ数が少ないフェーズは有限であり この期間を活かしてアグレッシブに開発することが求められる 

信頼性のターゲットは変化する 変化の激しい状況において固定的なSLOの定義は困難 エンジニアが信頼性ターゲットを高い解像度で認識し逐次更新する必要がある 変化を起こす例 事業の成長に伴い必要となる信頼性は高まる 成長だけでなく事業内容・対象の変化によっても信頼性は変化する ● ユーザー数の増加 ● 資金調達などファイナンスイベント ● 対象とするユーザセグメントの変化 （中小企業→エンプラ） ● ユーザー検証の結果、 想定とは異なる機能が重要と判明することも 

定量的なSLO設定が難しい中で適切な信頼性を高い解像度で認識することが必要 ● 機能毎に必要な信頼性を把握することがプロダクト開発の精度向上につながる ● 自律的な行動がプロダクト価値の向上においては欠かせず、 メンバーの自律的なSRE活動を求める以上はコンテキスト共有の施策が必須 具体的な想定障害を元に議論をするワークショップ・プレモーテムを設計した ● プレモーテムはポストモーテムの対義として生まれた言葉 ● 一般的にプレモーテムはプロジェクト開始前にリスクを洗い出す活動を指す 信頼性の認識共有手段としてプレモーテムを設計 要求 解決策 

プレモーテムの参加者 参加者 信頼性はユーザへの提供価値であり エンジニアだけで作るものではなく組織全体で作るものとして参加者を設定 ● プロダクトマネジャー【必須】 ○ メンバー間で意見が割れた場合など意思決定者としての役割 ● カスタマーサクセス責任者・担当者【任意】 ○ 障害発生時の顧客対応の中心であり、障害に対する認識を共有することが望ましい ● ドメインエキスパート【任意】 ○ ユーザー業務の理解を用いて機能毎の重要度を解像度高く伝える役割 ● エンジニア全員【必須】 ○ SRE関係者だけでなく、アプリケーション開発を含めた全員で検討する 

プレモーテムの構成 時間 内容 タイプ 前半 5分 プレモーテムの説明・目的の確認 導入 10分 想定される障害の書き出し 個人作業・事前可 45分 想定障害の顧客影響度の判定 チーム議論 後半 10分 想定障害への対策案の書き出し 個人作業・事前可 40分 対策案の優先度の判定 チーム議論 10分 プレモーテムの振り返り 振り返り 具体的な障害を想定し議論ができるようプレモーテムを設計 

想定される障害の書き出し 対象サービス 請求管理 障害内容 全ての請求書が 発行できない 発生期間 ３０分間・月中 記入のポイント 個人ワークで想定される障害を付箋に書き出す 具体性のある想定障害であるほど高い解像度での影響度の議論が可能となる ● 対象サービス ○ 影響度の判定後にサービス毎の重要度の比重が見える ● 障害内容 ○ 似て非なる障害を分けて書き出すことで 影響度判定の違いが見えてくる ● 発生期間 ○ 同じ障害内容であったとしても、 障害の発生時間・時期によって影響度が異なる場合あり 

想定障害の顧客影響度の判定 議論のポイント PM・カスタマーサクセス・ドメインエキスパートの協力を元に 想定障害に対して顧客影響度を判定する ● 影響度を相対的に判定することで許容可能な障害も明らかにする ● 同じ障害でも発生状況によって影響度は変わりうる ○ 時間帯によって顧客影響が変わりますか？ ○ 登録できずとも閲覧できれば救われませんか？ 

想定障害への対策案の書き出し　 記入のポイント 個人ワークで想定障害を参考に対策案を書き出す 障害発生から発生後の各ステップでの対策を立案 ● 想定障害や費用対効果は考慮し過ぎず 多様な対策案を洗い出す ● 障害発生前後のタイムラインを用意することで 多重な構えでの障害対策を洗い出す 

対策案の優先度の判定 議論のポイント 影響度の高い想定障害と照らし合わせ 優先度の高い対策案を選定する ● 導入コストだけでなく維持コストも含めて 費用対効果を見積もる ● 現在は選択が難しい対策案には いつ可能かを議論しリマインダを設定する 

プレモーテム参加者の声 総じて高い評価。具体的な題材で信頼性について 議論をすることで高い解像度での認識を共有することができた メンバー 感想 プロダクト マネジャー 具体的な場面・事象における顧客の動きを伝えることができた点は良かったです。フラッ トに顧客業務について話すよりも、こういうポイントポイントの深堀の方が結果として全体 的な理解に繋がるのではないかと感じました。 実はPMにとって一番学びの多い場だったような気がします。 副業エンジニア 障害という負の側面から業務ドメインを掘り下げることになるとは単純に驚きでした。顧客 がどうアプリケーションを使っているかの絵が見えない中で開発していたんだなということ を思い知らされた。 新規入社エンジニア 業務の中の重要度のグラデーションや、時間帯、月初月中月末のグラデーションなど、ど こが影響でかいのか、を把握できたのは収穫。 正社員エンジニア プレモーテムという形と内容の具体性を持って、スタートアップとしての現在地を定期的に 掴んでいくのは良いやり方だなと思いました。 

プレモーテムの効果 具体的な効果 障害というシビアな判断が求められるトピックを題材にすることで 信頼性について高い解像度での議論と理解をすることができる ● PMやCSを含むプロダクト関係者全員が信頼性・SREを理解する組織となった ● 影響の小さい障害を恐れなくなり、プロダクトのリリース頻度が向上した ● 障害影響度の共通認識ができ、障害発生時の対応精度が向上した ● 顧客業務ドメインへの理解が深まり 守るべき機能と壊れてもよい機能の取捨選択ができるようになった 

● シード期においては信頼性のターゲットの低さを 有効に活用してプロダクト価値向上に役立てる ● 信頼性は事業状況により変化するため、定期的な認識の更新が必要 ● プロダクトに関係する全員で信頼性への認識を醸成することができる ● 具体的な想定障害を元に高い解像度での信頼性の認識を作ることができる まとめ 信頼性のターゲット プレモーテム 

@niwa_takeru We’re hiring!!! アセンド株式会社は 共に社会課題を解決する仲間を探しています。 アセンドに少しでも興味が出ましたら 丹羽までご連絡ください!!!