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

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

1. 「正しいはずの依頼」が 届かなかった理由 ― 依頼設計を見直す ― SRE NEXT 2026 2026.07.10 GENEROSITY ／ 川口
2. 丁寧に準備して、依頼をした。 でも、思うように進まなかった。 そんな経験、ありませんか。 今日は、その理由と「依頼設計の3つの盲点」についてお話しします。 0 2 / 2 4
3. 約1年半前にSREチームを立ち上げ、 以来ほぼ1人で運用しています。 — クラウドはAWSのみ — 常時およそ200弱のアカウントを運用 0 3 / 2 4
4. SREとして、最初のセキュリティ課題 — 最初に対応したのは Security Hub Critical アラート — チーム発足前、上司がAWSアカウントの統合基盤を整備（Security Hubもこのとき 導入） — Critical ＝ 最上位の深刻度。最優先で対応が必要 0 4 / 2 4
5. Critical の中身 ― 外から入れてしまう状態 01 セキュリティグループのポート全開放 02 S3バケットがパブリックアクセス可能 03 Lambda関数がパブリックアクセス可能 04 RDSインスタンスがパブリックアクセス可能 05 KMSキーが意図せず削除される可能性 いずれも「外から簡単にアクセスされてしまう」重大な状態。7ルール・全54件を対応する必要があっ た。 0 5 / 2 4
6. どう依頼したか — Security Hubとは何か・Criticalの深刻度を説明する説明会を開催 — 対象アカウントとリソース・解消手順をまとめた「対応表」を作成 — 当初は担当者が不明確。仮の担当者に相談して割り振った — 期限は一律 1ヶ月後 ―― 丁寧に準備したつもりだった。 0 6 / 2 4
7. でも、対応は 進まなかった。 0 7 / 2 4
8. 依頼から2ヶ月後 ― なんとか、全54件のアラートを解消しきった。 でも ―― “なぜ、こんなに大変だったのか” という、もやもや が残った。 0 8 / 2 4
9. 「ここまで準備すれば、 動いてくれる」 — 組織にとって重要だと、伝えた — 対応手順を、明確に示した ― そう、思い込んでいた。 0 9 / 2 4
10. 01 誰に そもそも担当者が明確でなかった ―― 「誰がやるべき？」と、その場で議論になった 依頼設計の3つの盲点 1 0 / 2 4
11. 02 いつ 案件の数や難易度、通常業務…人によっ て状況が違う ――「今月分と来月分で、2段階に分けたい」という打診も あった 依頼設計の3つの盲点 1 1 / 2 4
12. 03 どのように 「いきなり」では、抱えている仕事に組 み込めない ―― 前触れがなく、対応の段取りを立てられなかった 依頼設計の3つの盲点 1 2 / 2 4
13. 01 誰に 担当者が明確でなかった 02 いつ 人によって、状況が違った 03 どのように 「いきなり」では、仕事に組み込めない 依頼設計の3つの盲点 1 3 / 2 4
14. 3つの盲点に共通すること 誰に・いつ・どのように ― どれも 「相手が“動ける条件”」 の話だった 依頼の “内容” は整えた。でも “動ける条件” を設計していなかった 1 4 / 2 4
15. 「相手の問題」だと思っていた。でも、違った。 私は「対応につながる依頼」を 設計できていなかった。 だから、届かなかった。 1 5 / 2 4
16. 01 「誰に」― 依頼の前に、“依頼先” を整える — 担当者を設定 ― AWSアカウント作成時に、担当者登録を必須化 — リソースの作成者を特定 ― CloudTrailで調査 — それでもわからない場合は、ヒアリング 1 6 / 2 4
17. 02 「いつ」― 期限は、相手の状況 に合わせる — 担当者ごとに、案件状況をヒアリング — 一律でなく、段階的に期限を設定 1 7 / 2 4
18. 03 「どのように」― 備え・理解 を支える — 依頼の前に「今後こんな対応を」と頭出し（準備の余地をつくる） — 手順だけでなく、背景・原因・目的を簡潔に説明 — 質問しやすいよう窓口を広げる（SRE問い合わせチャネルを開設／いつでもどうぞ） 1 8 / 2 4
19. 「内容」だけでなく 「動ける条件」 を設計する 01 誰に 依頼の前に、依頼先を整える 02 いつ 相手の状況に合わせて、期限を決 める 03 どのように 頭出し・背景説明で、動ける準備 を支える ▼ 相手が “動ける” 状態になり、対応が回りだす 設計し直した依頼 1 9 / 2 4
20. 設計し直して数ヶ月後、同様の依頼をしたとき ―― 前回よりもスムーズに 対応が進んだ。 1回目：54件・約2ヶ月　→　2回目：34件・約1週間で完了 依頼の中身ではなく、“動ける条件” を整えたことが効いた。 2 0 / 2 4
21. 私の考える「正しい依頼」とは ―― 相手に合わせて 「設計された依頼」 。 2 1 / 2 4
22. これから、目指していきたいこと — SRE起点でなくても、担当者が自ら気づいて動く — そうなるような仕組みづくりをする 2 2 / 2 4
23. 組織体制や状況によって、依頼の仕方は変わります。 SREやセキュリティ対応に限らず、 あなたの依頼設計を見直す きっかけになれたら嬉しい。 2 3 / 2 4
24. GENEROSITY は SRE を募集しています 組織は拡大期。信頼性の仕組みは、これから。一緒に「設計」しませんか。 https://generosity.co.jp/ ぜひブースへ ―― MirrorSnap（自社プロダクト）体験 × ノベルティ配布中 ご清聴ありがとうございました GENEROSITY 採用 ／ ブース 2 4 / 2 4