【No.126】設計・監視ボトルネック — SLO1枚＋障害チェックリスト
AI コーディングツールの普及で「行数を書く」ボトルネックは薄れ、システム設計・オブザーバビリティ・インシデント対応が scarce スキル、との二次論が 48K 求人分析 等で整理されています。
22〜25歳開発者雇用の減少言及もあり、コード量より信頼設計が値段を付ける方向です。
この記事は、論点を議論で終わらせず、担当サービスの SLO とアラートを1枚に書くためのテンプレと障害チェックリストとしてまとめた深掘りです。
この記事に含まれるもの
分析の読み方 — 48K JD とボトルネック移動の二次整理
信頼設計の3層フレーム — 設計・監視・インシデント
SLO1枚テンプレ — 指標・アラート・エスカレーション
障害再発防止チェックリスト — 3行から始める最小版
ポストモーテム3行テンプレ — 面接・レビュー用
面接で語る3行 — シニア判断力の伝え方
30日ロードマップ — 1サービスから横展開
この記事で持ち帰れること
AI に書かせた PR の後が勝負です。本番で壊れ方を先に潰す人が残る、というプロットの論点は、今日から SLO1枚 で証明できます。因果の単純化は避け、あなたの担当範囲で再現可能な形に落とします。
今週試す1手: 担当サービスの SLO とアラートを1枚に書く（下記テンプレをコピペ）。あわせて過去障害1件の再発防止チェックリストを3行で書く。
何が言われているか — ボトルネックの移動
48K posting analysis（Interview Stack 系の二次要約） を手がかりにすると、次の整理があります。
言語シェア
Python 言及も35%未満、との二次要約（他スキルと並立）。
インフラ・運用
K8s・CI/CD・オブザーバビリティが JD に並立、との論調。
新要件
LLM / RAG も新しい要件として現れる、との言及。
ジュニア雇用
22〜25歳開発者雇用の減少言及も二次情報に含まれる、との整理。
全社に当てはまる保証はありません。取り込むべきは、設計と監視が詰まりやすいという実務感覚です。
信頼設計の3層（フレームワーク）
1. 設計
境界・依存・失敗モードを書く（コード量ではなく制約）。
2. 監視
SLO とアラートで「壊れたら誰が気づくか」を固定。
3. インシデント
再発防止を3行でも残し、同じ事故を高く買わない。
よくある誤解と切り返し
誤解1: 「AI がコードを書くから設計は不要」
切り返し: 二次論は生成後の運用・監視がボトルネック、との方向。設計需要はむしろ残る。
誤解2: 「ジュニアが減る＝シニアだけが生き残る」
切り返し: 雇用減少の言及は相関の話。個人のキャリアを保証しない。
誤解3: 「SLO は SRE だけの仕事」
切り返し: 今週の1枚は担当サービス1つで十分。アプリエンジニアでも書ける最小形。
SLO1枚テンプレ（コピー用）
Notion・Issue・スプレッドシートの1ページに貼ってください。
サービス名: （ ）
ユーザーに約束する体験（1行）: （例: 検索結果が3秒以内に返る）
SLO 指標
指標1: （例: p95 レイテンシ < 3s）
指標2: （例: 可用性 99.5% / 30日）
指標3: （例: エラー率 < 0.1%）
測定元
ダッシュボード: （ ）
ログ/トレース: （ ）
アラート
条件: （ ）
通知先: （ ）
初動（15分）: （ ）
既知のリスク（1行）: （ ）
ロールバック（1行）: （ ）
完了定義: チーム内で1人が「この1枚で初動できる」と言える。
障害再発防止チェックリスト（3行スタート）
過去インシデント1件を選び、まず3行だけ書きます。後から増やしてよい。
インシデント: （日付・概要1行）
再発防止 行1: 検知 — （例: アラート閾値を〇に変更）
再発防止 行2: 緩和 — （例: タイムアウト・サーキットブレーカ）
再発防止 行3: プロセス — （例: デプロイ前チェック項目を1つ追加）
拡張用（任意・週次で足す）
テスト: （ ）
ドキュメント: （ ）
訓練: （ ）
完了定義: 上記3行が Issue またはポストモーテムに残っている。
ポストモーテム3行テンプレ（コピー用）
長文が書けない週用の最小形です。
何が起きた（1行）: （ ）
なぜ検知が遅れた/早かった（1行）: （ ）
次にやること（1行）: （ ）
完了定義: 関係者1名に共有した（チャット可）。
面接で語る3行（シニア判断力）
設計・監視の経験をコード量なしで伝えます。
行1: 担当の（ ）サービスで SLO を（ ）に設定し、アラート運用しました。
行2: インシデント（ ）では、再発防止として（ ）を入れました。
行3: AI 生成 PR 増でも、マージ前の信頼ゲートは（ ）です。
完了定義: 声に出して60秒以内。
CI / デプロイ観点の追記リスト（1項目足す）
設計・監視とセットで、次の PR で1つだけ選びます。
デプロイ後のスモークテストを CI に1本
feature flag で段階リリース
ダッシュボードリンクを PR テンプレに必須欄
ログに request_id を通す
on-call 連絡先を README に1行
完了定義: 選んだ1項目がマージまたは Issue に記録されている。
30日ロードマップ
第1週 — SLO1枚
担当サービス1つの SLO1枚を書き、チームに共有
完了定義: フィードバック1件（修正でも可）
第2週 — 障害3行
過去障害1件の再発防止3行＋ポストモーテム3行
完了定義: Issue リンクが取れる
第3週 — ゲート1つ
CI / デプロイ観点から1項目を PR で追加
完了定義: マージまたはレビュー中
第4週 — 横展開
第2サービスに SLO1枚をコピーし、差分だけ直す
面接3行を職務経歴に追記
完了定義: 履歴書に監視・インシデントの語彙が1行入った
ペルソナ別の使い方
アプリエンジニア — SLO1枚は「自分が一番触る API」1つで十分。インフラ全体を背負う必要はない。
テックリード — チームの PR テンプレに「ダッシュボードリンク」欄を足す。信頼設計をレビュー文化に落とす。
転職 — 面接3行とポストモーテム3行をセットで話す。コードより判断力の証拠になる。
ショート動画との関係
ショート 0126 は【変化】のフックで、設計と監視のボトルネックを一席で伝えています。動画は概要、本記事は SLO1枚・障害チェック・面接3行 の保存用です。今週は担当サービスの SLO1枚から着手してください。
参照
二次解説（業界論・48K 求人分析・YouTube 解説等 2026）。AI コーディング普及後のボトルネック移動。因果の単純化は避ける。
免責
本記事は二次分析の要約と、一般的な SRE 手順のテンプレです。SLO 数値・雇用動向は各出典・組織で異なります。本番変更は変更管理・オンコール体制に従って実施してください。
江戸テック瓦版 — AI 時代の生存戦略