配布資料 03全5部のカリキュラム設計

全体の地図として置いておきます。どこから読むか決めるときの見取り図として使ってください。

資料は自分のペースで読み進められるように作ってあります。 本文中の「再現手順」は手元で実行できる操作、「演習」は自分で判断する課題を指します。

各部は原則として「事故 → 原因 → ルール → 強制する仕組み → 再現手順/演習」の順に並べました。 失敗駆動です。理屈から入らず、実際に転んだところから始めます。

1部あたりの分量は、スライド 20〜30枚 + 再現手順・演習 3〜5本です。

第1部 — 思想と全体像

第1部は全員向けです。経営層・マネジメント層・システム部門の非エンジニアも読めます。元になっているのは「提供思想 — AIに仕事をさせるという仕事」です。

• 未来予想図: AI駆動開発の現在地と数年後（実PJの実績データで語る）
• 2つの誤解を正す — 経営層「人が介在しなくなる」/ 現場「仕事を奪われる」への実データ反証
• 「AIに仕事をさせるという仕事」= 人間の5つの役割（発注者・監督者・規律の設計者・記憶の管理者・最終責任者）
• 再現手順: タスクモード契約 / 本番デプロイの人間ゲート / 失敗事例2〜3件
• 導入3案の比較・最初に決める3つ・チーム契約のシート設計
• 構成の経緯: 第1部は全編を全員向け（思想と組織の話）に再構成しました。エンジニア向けの立ち上げ（AI の悪癖・Claude Code の全体像・Keihi 起動）は第2部の冒頭へ移し、Claude Code 設定の深掘りは重複を避けて第4部に一本化しています

第2部 — 要件定義と設計

• エンジニアの立ち上げ（第1部 から移設）: AI の代表的な悪癖 / Claude Code の全体像（統治の4階層・深掘りは 第4部）/ 題材システム Keihi の起動
• ドキュメント駆動開発（主教材: chronicle/01_ドキュメント駆動の歩み.md）— 2.4ヶ月の要件定義期間と9分間の一括インポート・「書き切ってから作る」順序の実証・文書の質が実装の質の上限になる理由・陳腐化防止の仕組み化（同一コミット強制）
• ドキュメント体系の設計（要件〜設計〜運用の文書構造。題材プロジェクトは19カテゴリ・274文書・8万行）
• イシュー管理ツール = AI の外部記憶（成否を分ける連携テーゼ）+ イシュー駆動開発（起票 → In Progress → In Review → Done の意味論）
• タスクモード契約: 「確認して」と「実行して」の分離が暴走を防ぐ
• タスク分割: 1PR=1レイヤー・200行超で分割再検討
• 大規模な要件追加・仕様変更の作法（主教材: chronicle/02_大規模仕様変更の実像.md）— 実例5件（事業転換・返金再設計・マルチテナント化・全数リファクタ・配色刷新）/ 人間の振る舞い8型（原則を与える・反例で否定・一次資料へ差し戻し・実地検分 等）/ AI の悪癖9型 / プロセスの型8段
• 再現手順: Keihi の要件をイシュー化し、AI に「確認モード」で調査させる + 大規模変更の exploration 文書演習

第3部 — 実装→検証イテレーション

• 実装期のイテレーション史（主教材: chronicle/04_実装期のイテレーション.md）— 20ステップは staging 誕生直後の5日間で固まった / ブラウザテスト規律を作った是正3段階（ふりの排除→深さの強制→過剰の較正・原文引用）/「自動テストの緑を信じない」に至った経緯 / 速度と規律の両立実測（コミット3倍とリードタイム9倍の同時進行）
• 20ステップワークフロー（起票からDoneまで、なぜこの順序か）
• 検証の階段: tsc → 単体 → Docker → e2e → dev 目視 → staging 目視
• 実証主義: 「完了」はスクショ・DOM引用・verify 出力で示す（grep で完了にしない）
• サブエージェント駆動開発（Plan / Explore / coder 並列 / test-generator / code-reviewer）
• 再現手順: Keihi に機能を1つ実装し、検証の階段を全段通す

第4部 — 規律の仕組み化（心臓部）

• 規律の共進化史（主教材: chronicle/03_規律の共進化.md）— CLAUDE.md 15行→477行→47行+rules分散→179行の成長曲線 / hooks 0→24本の3.5ヶ月 / 最初の hook は事故の復元 PR の中で生まれた / 事故→同日 enforcement 化のリードタイム / 統治コード0.9%が41万行の生産を支えた構造 / 「自動化の上限は規律の機械化の水準で決まる」
• hooks の解剖: SessionStart / UserPromptSubmit / PreToolUse / Stop の多層防御
• ルールの生まれ方: 事故 → feedback メモリ → rule 文書 → hook による強制、の進化サイクル
• メモリ三層アーキテクチャ: 自動メモリ / プロジェクト記憶DB / イシュートラッカーの役割分担
• 再現手順: わざと事故を起こし、自分でルール違反を検知する hook を書く

第5部 — デプロイ・運用・移植

• 運用成熟期の自動化史（主教材: chronicle/05_運用成熟期の自動化.md）— デプロイフローの4世代 / CI の死と再誕 / 監視の事故駆動積み上げ / 自己修復4装置 / DR 構築の1日 / バッチデプロイ三部作 / AI コスト統治 / 無人化チェックリスト5層
• デプロイ設計: バッチデプロイ・CI コスト管理（無料枠枯渇事故）・SSH 切断耐性
• 本番安全設計: デプロイ時間帯・金銭ロジック規律・バックアップ・DR
• 総合演習: 自分のプロジェクトへの移植計画書を作成（見直しの観点つき・同席者がいれば相互レビュー）
• クロージング: 継続のための最小セット（最初に入れる hook 3本はどれか）

読む順のおすすめ

頭から順に読めるように書いてありますが、立場によって近道があります。

経営・マネジメントの立場なら、第1部だけで完結します。 技術の話はほとんど出てきません。

エンジニアなら、第4部「規律の仕組み化」から読むのが近道だと思います。ここが心臓部で、 そこで出てくる用語や事故の背景が知りたくなったら、第2部・第3部へ戻ってきてください。

手を動かしたいなら、Keihi から。 起動して3つのロールで一巡してみるところから始まります。

全体の時系列を先に掴みたい方は、構築年表の総覧を1ページ読んでからのほうが早いかもしれません。