Issue #153 | CEOフィードバック9点反映 | 2026-03-30 | 第1〜4章: 本文詳細 / 第5〜12章: 構成+要点
プロジェクトの品質は、個々のルールの前に「何を大事にするか」で決まる。 この章の原則は、迷ったときの判断基準であり、ルールが想定しない状況でも正しい行動を導くためのものである。
作るべきものの要否を常に問う。「あったほうがいい」は作らない理由になる。
具体的には、要件定義で「この機能がなくても目的は達成できるか？」を必ず確認する。答えが「はい」なら、その機能は作らない。
要件分解・設計分割・テスト設計はMECEを徹底する。
何かを分類するとき、「この分類で全パターンを網羅しているか」「重複しているものはないか」を確認する。
同じ情報を複数箇所に書かない。一つの情報には一つの置き場所（正）を定め、他の場所からは参照する。
PJ推進大全自体もこの原則に従い、既存ドキュメントの内容はコピーせず参照先を示す。
プロジェクト固有のものと、組織全体で再利用できるものを常に区別する。
「このコード/ルール/ドキュメントは他のプロジェクトでも使えるか？」と問い、使えるなら共通資産として管理する（第9章参照）。
処理を2回実行しても、1回目と同じ結果になる設計にする。
データの登録、ファイルの生成、環境の構築など、あらゆる操作で「やり直しが安全」であること。
過度な抽象化・過剰設計を避ける。「今必要なもの」だけを作り、将来の仮定に基づいた設計をしない。
3行のコードで済むことに、汎用フレームワークを持ち込まない。
プロジェクトには以下の役割が関与する。詳細な組織構造は Issue #139 設計書を参照。
プロジェクトは以下の12工程で構成される。工程1〜4はPJ前（M/VDU主導）、工程5で委託しPJMが生まれ、工程6〜12がPJ中（PJM主導）となる。
| # | 工程 | 内容 | 主導者 | 関与者 | 成果物 | 区分 |
|---|---|---|---|---|---|---|
| 1 | 発見 | 課題・機会・要望の検知。CEOからの依頼、ニュース巡回、エラー検知など | M/VDU | CEO, IF層 | Issue起票（課題の概要） | PJ前 |
| 2 | 調査 | 既存コード・技術的制約・外部環境の調査 | M/VDU | W層 researcher | 調査報告書（技術的制約・選択肢の整理） | PJ前 |
| 3 | 要求整理 | やりたいこと・解くべき課題をCEOと明文化 | M/VDU | CEO | 要求一覧（やりたいこと・やらないこと） | PJ前（人関与必須） |
| 4 | 要件定義 | 実現すべき機能・非機能要件の確定 | M/VDU | CEO（承認必須） | 要件定義書（CEO承認済み） | PJ前（人関与必須） |
| 5 | 委託 | M/VDUがPMOにPJ推進を委託。PMOがPJMを生成する。M層はここで離脱し、受入（工程9）まで関与しない | M/VDU → PMO | — | PJM生成、WBS作成（第4章参照） | 移行点 |
| 6 | 設計 | アーキテクチャ・インターフェース定義・データモデル設計 | PJM | W層 architect | 設計書HTML（セキュリティ/パフォーマンス項目含む） | PJ中 |
| 7 | 実装 | 設計書に基づくコーディング | PJM | W層 coder, docs | ソースコード、ドキュメント | PJ中 |
| 8 | テスト | 品質検証（コードレビュー + テスト実行） | PJM | W層 tester, reviewer | テスト結果、レビュー指摘一覧 | PJ中（AI間チェック） |
| 9 | 受入 | M/VDUが復帰し最終受入を実施。CEOに完了報告 | PJM | M/VDU（復帰）, CEO | 受入完了報告（変更一覧・テスト結果・未解決事項） | PJ中（人関与必須） |
| 10 | リリース | コードデプロイ + ユーザー公開（定義は1.2節参照） | PJM | W層, CEO（承認必須） | デプロイ完了確認、リリース告知 | PJ中（人関与必須） |
| 11 | 記録 | PJの経緯・教訓を記録。推進ナレッジ（第12章）への蓄積 | PMO | PJM | PJ記録（教訓・振り返り） | PJ後 |
| 12 | 解散 | PMOがPJの完了を確認し、PJMを消滅させる | PMO | PJM（消滅） | PJ完結の確認 | 終了点 |
各工程で生まれる成果物と、そのレビュー体制を以下に整理する。 レビューの詳細手順は第8章および managers/dev/knowledge/review_process.md を参照。
| 工程 | 成果物 | レビュー者 | レビュー基準 |
|---|---|---|---|
| 2. 調査 | 調査報告書 | M/VDU | 調査範囲の網羅性、引用の正確性 |
| 4. 要件定義 | 要件定義書 | CEO | ビジネス要求との整合 |
| 5. 委託 | WBS | M/VDU（委託時確認） | 工程の抜け漏れ、担当の妥当性 |
| 6. 設計 | 設計書HTML | Layer 1: reviewer → Layer 2: M層Rv → CEO確認 | セキュリティ/パフォーマンス項目、実装可能な粒度 |
| 7. 実装 | ソースコード | Layer 1: reviewer → Layer 2: M層Rv | 品質ゲート（第6章）適合 |
| 8. テスト | テスト結果 | Layer 1: W層内 → Layer 2: M層Rv → CEO受入 | テスト網羅性（正常系/異常系/境界値/認可） |
| 9. 受入 | 受入完了報告 | CEO | 元の依頼内容との整合 |
工程10「リリース」には3つの異なる操作が含まれる。それぞれ承認者と手順が異なるため、混同しないこと。
| 操作 | 内容 | 承認者 | 実行者 | 手順 |
|---|---|---|---|---|
| コードデプロイ | ソースコード/DBの本番環境への反映 | CEO承認必須 | M層（Git操作） | 1. M層がpush判断 → 2. CEO承認 → 3. mainマージ → 4. 本番反映 |
| リリース | ユーザーへの公開・告知 | CEO承認必須 | CEO / M層 | 1. コードデプロイ完了 → 2. 動作確認 → 3. CEO承認 → 4. 告知 |
| ドキュメント公開 | 設計書等のCloudflare Pagesへの反映 | M層判断でOK | M層 / W層 | ACTIONタグ（cf_deploy）で自動デプロイ |
全てのIssueが12工程を全て通るわけではない。規模に応じて以下のようにスキップできる。
| 規模 | 判断基準 | 通る工程 | スキップ |
|---|---|---|---|
| 軽微 | 1ファイル程度の修正、typo修正、設定変更 | 実装（P2のみ） | 調査・設計・テスト工程を省略。PJM不要（PMO直接処理） |
| 中程度 | 複数ファイルの変更、新機能追加 | 調査/設計（P1）→ 実装（P2） | テスト工程を軽量化（reviewer省略可） |
| 大規模 | アーキテクチャ変更、複数モジュール横断 | 調査/設計（P1）→ 実装（P2）→ テスト/レビュー（P3） | スキップなし |
参照 フェーズ分割の詳細 managers/dev/knowledge/delegation_protocol.md
各工程から次の工程に進むための条件（ゲート）を以下に示す。ゲートを満たさずに先に進むことは禁止。
| ゲート | 通過条件 |
|---|---|
| 調査 → 要求整理 | 調査報告書がM/VDUレビュー済み |
| 要求整理 → 要件定義 | やりたいこと・やらないことがCEOと合意済み |
| 要件定義 → 委託 | 要件定義書がCEO承認済み |
| 設計 → 実装 | 設計書がLayer 1 + Layer 2レビュー通過 |
| 実装 → テスト | coderの実装完了報告 + M層による変更確認 |
| テスト → 受入 | MUST指摘ゼロ + テスト全件通過 |
| 受入 → リリース | M/VDU受入完了 + CEO承認 |
| リリース → 記録 | コードデプロイ + リリース完了確認 |
| 記録 → 解散 | 教訓の記録完了 |
MNMLではAgile用語（Epic/Story/Sprint）は使わない。作業管理の基本単位はGitHub Issueであり、以下の原則に従う。
1つのIssueが複数の独立した作業を含む場合、子Issueに分割する。
プロジェクト進行中に「ここも直したほうがいい」「この機能も欲しい」と範囲が広がることがある。以下のルールで管理する。
| 状況 | 対応 | 判断者 |
|---|---|---|
| 作業中に関連するバグを発見 | 新規Issueとして起票し、現在のIssueには含めない | PJM / M層 |
| CEOから追加要件 | 要件定義をやり直す（工程4に戻る）か、新規Issueとするかを判断 | CEO |
| 技術的に当初の設計では実現不可 | 設計工程に差し戻す。スコープを縮小するか代替手段を検討 | PJM + M層 |
| 共通資産への影響が判明 | 影響範囲を特定し、CEO承認を取る（第9章参照） | CEO |
要件定義（工程4）の時点で、「このIssueではやらないこと」を明文化する。 これにより、後から「これもやるべきでは？」という議論が出たときに、意図的に除外したのか見落としなのかを判断できる。
進捗を測るには、まず計画がなければならない。計画は以下のタイミングで作成する。
工程5（委託）でPJMが生成された直後に、WBS（作業分解構成）を作成する。
| 項目 | 内容 | 例 |
|---|---|---|
| 工程 | 工程6〜12のうち、このPJで通る工程 | 設計 → 実装 → テスト → 受入 → リリース |
| タスク | 各工程内の具体的な作業 | 設計書作成、CEOレビュー待ち、コーディング… |
| 担当 | 各タスクを実行するWorker/役割 | architect, coder, reviewer |
| 依存関係 | 他のタスクの完了を待つ必要があるか | 「実装」は「設計レビュー通過」の後 |
| 完了条件 | そのタスクが「終わった」と言える基準 | テスト全件通過、MUST指摘ゼロ |
「コード何行書いた」「ファイルを3つ編集した」は進捗ではない。 進捗は「人が理解できる単位」で測る。
| タイミング | 報告内容 | 報告先 |
|---|---|---|
| 工程完了時 | 完了した工程・成果物・次工程への移行判断 | M層 → CEO |
| ブロッカー発生時 | 何に阻まれているか・解決に必要なもの | PJM → M層（→ CEO if needed） |
| PJ完結時 | 全成果物の一覧・テスト結果・未解決事項・教訓 | M層 → CEO |
工程完了時の報告には、以下の項目を含める。これは既存の「Layer 3: CEO確認」の報告様式と同一。
参照 報告様式の詳細 managers/dev/knowledge/review_process.md（Layer 3: CEO確認）
M層は工程の状態をSTATUSタグで通知する。PJMも同様にSTATUSタグを使用する。
| STATUSタグ | 意味 | 使うタイミング |
|---|---|---|
| CONTINUE | 作業を続行中。次の工程に進む | 工程が正常に完了し、次の工程に自律的に進める場合 |
| DONE | PJ完結または依頼完了 | 全工程が完了し、成果物が受入済み |
| APPROVAL_NEEDED | CEOの承認が必要 | 要件定義、デプロイ、共通資産変更 |
| CONSULT | CEOに相談したい | 仕様の判断、スコープ変更、技術的な迷い |
| REROUTE | 別のDivisionに振り分ける | 担当外の依頼が来た場合 |
全ての報告には証拠（実行ログ、ファイルパス、スクリーンショット等）を添える。推測で「テスト通過」「保存成功」と書くことは禁止。
git diff の出力で変更内容を示すls -la の結果でファイルの存在とサイズを示す参照 捏造禁止・証跡確認ルールの詳細 managers/dev/knowledge/review_process.md（W層報告の検証）
| 分類 | 内容 | 管理先 | 例 |
|---|---|---|---|
| PJ内課題 | バグ・技術的負債・仕様不明点 | GitHub Issues（該当PJのラベル） | APIレスポンスが遅い、エラーハンドリング不足 |
| 組織課題 | ルール変更・共通基盤の問題 | GitHub Issues（org-wideラベル）+ M層エスカレーション | CLAUDE.mdの矛盾、共通認証基盤の不具合 |
| 共通資産課題 | CLAUDE.md改善・knowledge/更新 | H&A / PMO管轄 | 品質ゲート項目の追加 |
W層 → PJM → M層 → CEO（破壊的・組織横断の場合のみCEOまで上げる）
新規
参照 docs/done-definition.md（品質ゲート8カテゴリ + 完了定義）
参照 各W層CLAUDE.md（実装品質ルール・レビューチェックリスト・テスト必須カバレッジ）
統合 managers/dev/knowledge/git_workflow.md, managers/dev/knowledge/auto_commit.md, CLAUDE.md（プロジェクトルート） の Gitワークフロー
| 工程 | Layer 1（W層内） | Layer 2（M層） | Layer 3（CEO） |
|---|---|---|---|
| 6. 設計 | reviewer が設計書をチェック | M層が要件充足性・品質ゲート適合を確認 | CEO確認（設計方針の承認） |
| 7. 実装 | reviewer がコードレビュー（MUST/SHOULD/NIT分類） | M層が設計との整合・品質ゲートを確認 | （通常は不要） |
| 8. テスト | tester/reviewer が品質検証 | M層がテスト結果・MUST指摘ゼロを確認 | CEO受入（全体の最終確認） |
参照 レビュープロセスの詳細手順 managers/dev/knowledge/review_process.md
| 資産 | 内容 | 管理者 | 変更承認 |
|---|---|---|---|
| CLAUDE.md群 | グローバル / プロジェクト / 各層のCLAUDE.md | H&A | CEO承認 |
| knowledge/ | delegation_protocol, review_process, done-definition等 | PMO / M層 | M層承認（破壊的変更はCEO） |
| 設計書テンプレート | architect output のテンプレート | PMO | M層承認 |
| done-definition.md | タスク完了定義・品質ゲート | PMO | CEO承認 |
新規
新規
新規
docs/lessons-learned/ にMarkdownで管理し、本章から参照新規
| # | CEOフィードバック | 対応箇所 | 対応内容 |
|---|---|---|---|
| 1 | 工程定義: 設計からPMO/PJMが動き出す | 第2章 全体 | 12工程を定義。工程1-4はM/VDU主導、工程5でPMOに委託・PJM生成、工程6-12がPJM主導 |
| 2 | デプロイ/リリースの厳密な定義 | 第1章 1.2節 + 第2章 2.4節 | コードデプロイ/リリース/ドキュメント公開の3つを定義。承認者・手順を明記 |
| 3 | PJ完結・AI間チェックの平易な定義 | 第1章 1.2節 | 「PJ完結」「AI間チェック」を日常語で定義。具体的な運用イメージを記述 |
| 4 | プロジェクト体制図 | 第2章 2.1節 | CEO/IF/M/PMO/PJM/W層のスイムレーン図。Division構成（Three Lines）を併記 |
| 5 | スコープ管理: 分割単位の具体化 | 第3章 全体 | Issue単位の原則、「1文テスト」、子Issue分割、フェーズスキップ連動を定義 |
| 6 | 進捗管理: WBS/計画の作成 | 第4章 4.1節 | WBS作成タイミング（工程5）、含める内容、日付を入れない方針を定義 |
| 7 | 課題管理: フローの具体化 | 第5章（構成+要点） | 3分類（PJ内/組織/共通資産）、エスカレーションフロー、管理先を定義 |
| 8 | レビュープロセス: 工程ごとのRvフロー | 第8章（構成+要点）+ 第2章 2.3節 | 工程6/7/8ごとのLayer 1〜3レビューフロー、W層報告の検証ルールを定義 |
| 9 | 共通資産管理: 種類と管理ルール | 第9章（構成+要点） | 4種の共通資産（CLAUDE.md群/knowledge/テンプレート/done-definition）と管理者・承認フローを定義 |
PJ推進大全は既存ルールを「置き換える」のではなく、「統合的に参照できる入口」として機能する。
| 既存ファイル | PJ推進大全での扱い |
|---|---|
| docs/done-definition.md | 参照 第6章から参照。原本を正とする |
| managers/dev/knowledge/delegation_protocol.md | 参照 第2章から参照。フェーズ詳細はこちらを正 |
| managers/dev/knowledge/review_process.md | 参照 第4章・第8章から参照。レビュー手順の詳細はこちらを正 |
| managers/dev/knowledge/git_workflow.md | 統合 第7章に統合。原本は維持 |
| managers/dev/knowledge/auto_commit.md | 統合 第7章に統合 |
| 各W層CLAUDE.md | 参照 第6章から品質ルール部分を参照 |
| Issue #139 設計書 | 参照 第2章から組織構造・Division構成を参照 |