「正しいはずの依頼」が届かなかった理由

by GeneGuchi

Embed

Start on current slide

Slide 1

Slide 1 text

「正しいはずの依頼」が届かなかった理由 ― 依頼設計を見直す ― SRE NEXT 2026 2026.07.10 GENEROSITY ／川口

Slide 2

Slide 2 text

丁寧に準備して、依頼をした。でも、思うように進まなかった。そんな経験、ありませんか。今日は、その理由と「依頼設計の3つの盲点」についてお話しします。 0 2 / 2 4

Slide 3

Slide 3 text

約1年半前にSREチームを立ち上げ、以来ほぼ1人で運用しています。 — クラウドはAWSのみ — 常時およそ200弱のアカウントを運用 0 3 / 2 4

Slide 4

Slide 4 text

SREとして、最初のセキュリティ課題 — 最初に対応したのは Security Hub Critical アラート — チーム発足前、上司がAWSアカウントの統合基盤を整備（Security Hubもこのとき導入） — Critical ＝最上位の深刻度。最優先で対応が必要 0 4 / 2 4

Slide 5

Slide 5 text

Critical の中身 ― 外から入れてしまう状態 01 セキュリティグループのポート全開放 02 S3バケットがパブリックアクセス可能 03 Lambda関数がパブリックアクセス可能 04 RDSインスタンスがパブリックアクセス可能 05 KMSキーが意図せず削除される可能性いずれも「外から簡単にアクセスされてしまう」重大な状態。7ルール・全54件を対応する必要があった。 0 5 / 2 4

Slide 6

Slide 6 text

どう依頼したか — Security Hubとは何か・Criticalの深刻度を説明する説明会を開催 — 対象アカウントとリソース・解消手順をまとめた「対応表」を作成 — 当初は担当者が不明確。仮の担当者に相談して割り振った — 期限は一律 1ヶ月後 ―― 丁寧に準備したつもりだった。 0 6 / 2 4

Slide 7

Slide 7 text

でも、対応は進まなかった。 0 7 / 2 4

Slide 8

Slide 8 text

依頼から2ヶ月後 ― なんとか、全54件のアラートを解消しきった。でも ―― “なぜ、こんなに大変だったのか” という、もやもやが残った。 0 8 / 2 4

Slide 9

Slide 9 text

「ここまで準備すれば、動いてくれる」 — 組織にとって重要だと、伝えた — 対応手順を、明確に示した ― そう、思い込んでいた。 0 9 / 2 4

Slide 10

Slide 10 text

01 誰にそもそも担当者が明確でなかった ―― 「誰がやるべき？」と、その場で議論になった依頼設計の3つの盲点 1 0 / 2 4

Slide 11

Slide 11 text

02 いつ案件の数や難易度、通常業務…人によって状況が違う ――「今月分と来月分で、2段階に分けたい」という打診もあった依頼設計の3つの盲点 1 1 / 2 4

Slide 12

Slide 12 text

03 どのように「いきなり」では、抱えている仕事に組み込めない ―― 前触れがなく、対応の段取りを立てられなかった依頼設計の3つの盲点 1 2 / 2 4

Slide 13

Slide 13 text

01 誰に担当者が明確でなかった 02 いつ人によって、状況が違った 03 どのように「いきなり」では、仕事に組み込めない依頼設計の3つの盲点 1 3 / 2 4

Slide 14

Slide 14 text

3つの盲点に共通すること誰に・いつ・どのように ― どれも「相手が“動ける条件”」の話だった依頼の “内容” は整えた。でも “動ける条件” を設計していなかった 1 4 / 2 4

Slide 15

Slide 15 text

「相手の問題」だと思っていた。でも、違った。私は「対応につながる依頼」を設計できていなかった。だから、届かなかった。 1 5 / 2 4

Slide 16

Slide 16 text

01 「誰に」― 依頼の前に、“依頼先” を整える — 担当者を設定 ― AWSアカウント作成時に、担当者登録を必須化 — リソースの作成者を特定 ― CloudTrailで調査 — それでもわからない場合は、ヒアリング 1 6 / 2 4

Slide 17

Slide 17 text

02 「いつ」― 期限は、相手の状況に合わせる — 担当者ごとに、案件状況をヒアリング — 一律でなく、段階的に期限を設定 1 7 / 2 4

Slide 18

Slide 18 text

03 「どのように」― 備え・理解を支える — 依頼の前に「今後こんな対応を」と頭出し（準備の余地をつくる） — 手順だけでなく、背景・原因・目的を簡潔に説明 — 質問しやすいよう窓口を広げる（SRE問い合わせチャネルを開設／いつでもどうぞ） 1 8 / 2 4

Slide 19

Slide 19 text

「内容」だけでなく「動ける条件」を設計する 01 誰に依頼の前に、依頼先を整える 02 いつ相手の状況に合わせて、期限を決める 03 どのように頭出し・背景説明で、動ける準備を支える ▼ 相手が “動ける” 状態になり、対応が回りだす設計し直した依頼 1 9 / 2 4

Slide 20

Slide 20 text

設計し直して数ヶ月後、同様の依頼をしたとき ―― 前回よりもスムーズに対応が進んだ。 1回目：54件・約2ヶ月　→　2回目：34件・約1週間で完了依頼の中身ではなく、“動ける条件” を整えたことが効いた。 2 0 / 2 4

Slide 21

Slide 21 text

私の考える「正しい依頼」とは ―― 相手に合わせて「設計された依頼」。 2 1 / 2 4

Slide 22

Slide 22 text

これから、目指していきたいこと — SRE起点でなくても、担当者が自ら気づいて動く — そうなるような仕組みづくりをする 2 2 / 2 4

Slide 23

Slide 23 text

組織体制や状況によって、依頼の仕方は変わります。 SREやセキュリティ対応に限らず、あなたの依頼設計を見直すきっかけになれたら嬉しい。 2 3 / 2 4

Slide 24

Slide 24 text

GENEROSITY は SRE を募集しています組織は拡大期。信頼性の仕組みは、これから。一緒に「設計」しませんか。 https://generosity.co.jp/ ぜひブースへ ―― MirrorSnap（自社プロダクト）体験 × ノベルティ配布中ご清聴ありがとうございました GENEROSITY 採用／ブース 2 4 / 2 4