PJ推進大全 — 5大分類×12工程

PJの起点となる課題・機会を発見し、技術的な実現可能性を調査した上で、要求をMECE分解し要件に落とし込む。最終的にPMOへPJ化を委託し、PJMを生成するまでがこのフェーズの責務。CEO承認ゲートを2箇所設け、スコープ・コストの合意を取得することで、後工程での手戻りを最小化する。

• 要求の曖昧さ排除: MECE分解の徹底。曖昧な表現はCONSULTでCEOに明確化を依頼する
• 既存PJとの重複検知: PMOの棚卸責務。工程5で重複チェックを必ず実施する
• 実現可能性の早期判断: 工程2での技術調査を省略しない。不可能な要件は早期に除外する
• CEO承認の粒度: 工程3は「何を作るか」の合意、工程4は「どこまで作るか＋コスト」の合意

要件定義書をもとに、アーキテクチャ設計・IF定義・ファイル構成・データモデルを策定する。セキュリティ・バイ・デザインの原則に従い、API設計（リソース所属検証）・データモデル（Int型金額）・UI設計（二重送信防止）を設計段階で組み込む。設計書はHTML形式で出力し、Cloudflare Pagesにデプロイして共有する。

• 設計書はHTML形式で出力: Markdown不可。Cloudflare Pagesにデプロイして公開URLを共有する
• セキュリティ・バイ・デザイン: API設計（リソース所属検証）・データモデル（Int型金額）・UI設計（二重送信防止）を設計段階で組み込む
• 設計方針対立時のエスカレーション: PJM → VDU（技術裁定） → CEO（事業判断が必要な場合）
• 非機能要件の設計反映: パフォーマンス（ページネーション・N+1防止）・スケーラビリティを設計書に明記する

設計書に基づいてコードを実装し、単体テストを作成する。ruffフォーマット・py_compile構文チェックをエラーゼロで通過させ、品質の担保されたコードをコミットする。実装品質ルール（整数演算・リソース所属検証・fetchエラーハンドリング・二重送信防止）を遵守し、過去のインシデント（danketsu-app教訓）を踏まえた安全な実装を行う。

金額・数値計算

• 金額の按分は整数演算のみ: Math.floor(amount / n) + 余り(amount % n)を先頭に加算
• 除数が0になりうる箇所は事前にガード（空配列、フィルタ後の0件等）

API実装

• リソース所属検証: ネストAPIでは子が親に属するか検証してからupdate/delete
• 入力バリデーション: APIハンドラの先頭で型・範囲・必須チェック
• エラーレスポンス: { error: "日本語メッセージ" }。内部情報を含めない

フロントエンド

• fetchエラーハンドリング: res.okチェック + .catch()
• 二重送信防止: disabled={submitting}
• フォームページ: 戻るリンク・キャンセルボタン・エラーフィードバック必須
• レスポンシブ: 390px幅で表示崩れなし

• コミットルール: 意味のある単位で英語メッセージ。機密ファイル（.env, credentials）混入禁止
• エラー時リカバリ: git stash退避 → クリーンツリー確認 → リトライ
• worktree活用: 複数coder並行時はgit worktreeでファイル競合を回避
• 自己修正ループ: py_compile → pytest → 失敗時は自力修正（最大3回） → 超過でエスカレーション

実装されたコードの品質を多層的に検証する。テスト必須カバレッジ6カテゴリ（正常系・異常系・境界値・認可・レスポンシブ・クリーンアップ）を全て網羅し、VDU受入レビュー（25項目チェックリスト）で事業価値・品質の観点から最終確認を行う。W層の報告を鵜呑みにせず、M層レビュー原則に基づいた独自検証を実施する。

• ハッピーパスのみにならないこと: danketsu-app教訓。異常系・境界値・認可テストを必ず含める
• 外部連携は実際に動かして検証: 「テスト全PASS」の推測報告は禁止。ツール実行結果を引用すること
• 三線防御: VDUレビュー（1線） → OA監査（3線） → CEO承認（最終）
• NG差し戻し時の修正指示: 具体的な修正箇所・期待する結果を明記する。「修正してください」のみは不可

VDU受入OKの成果物を本番環境にデプロイし、PJの知見・教訓を推進ナレッジ（T9）に記録する。全成果物の完全性を確認した上でPJMを消滅させ、CEOに完了報告を行う。リリース時のCEO承認ゲート（main直接push・破壊的変更）を遵守し、ロールバック手順を事前に策定することで安全なデプロイを実現する。

ナレッジ記録の完全性: T9テンプレートの全項目が記入されていること。

• リリース前のCEO承認フロー: force push・main直接pushは禁止。W層単独pushも禁止（M層が判断）
• ロールバック方針の事前策定: デプロイ前にロールバック手順を確認しておく
• 知見の構造化: 随時追記可能な形式（T9のテンプレート）で記録する
• PJM消滅のタイミング: PMOが全成果物・ナレッジ記録の完全性を確認してから消滅させる

生成〜消滅フロー

品質基準未達時の差し戻しパターン。無限ループ防止のため、同一工程への差し戻しは最大3回。3回超過時はVDUにエスカレーション。

PJM用：工程開始前チェック

• 前工程の成果物が揃っているか
• 前工程の品質ゲートを通過しているか
• 必要なW層のスキルが利用可能か（rate limit等で制約がないか）
• 差し戻しの場合：前回の修正指示が明確に記述されているか
• CEO承認ゲートの対象工程か（対象なら承認済みか確認）

PJM用：工程完了チェック

• 成果物が定義されたフォーマットに準拠しているか
• W層の成果物を自分（PJM）がレビュー済みか（W層報告を鵜呑みにしない）
• コミットメッセージが英語で、意味のある単位か
• 機密ファイル（.env, credentials等）が含まれていないか
• ruff / py_compile がエラーゼロか
• 次工程に渡すべき情報（申し送り）を整理したか

PMO用：PJM生成チェック

• 要件定義書（工程4成果物）が添付されているか
• 既存PJとの重複チェックを実施したか
• PJM CLAUDE.mdが工程計画を含んでいるか
• リソース（CLI同時起動数）に余裕があるか
• フェーズスキップの妥当性を確認したか（軽微/中程度/大規模の判断）

PMO用：PJ完了チェック

• 全工程の成果物が揃っているか
• VDU受入レビューがOKか
• OA監査（対象の場合）がOKか
• ナレッジ記録（工程11成果物）が推進ナレッジテンプレートに準拠しているか
• PJMの消滅処理が完了しているか

1. コミット・プッシュゲート

2. W層成果物ゲート（VDUレビュー）

VDUが reviewer の25項目チェックリストを使用して成果物をレビューする。W層の報告を無条件に信頼しない（M層レビュー原則）。

セキュリティ必須チェック（5項目）

• SQLインジェクション・XSS・コマンドインジェクションの脆弱性がないか
• ネストAPIでクロスリソースアクセスが不可能か（リソース所属検証）
• 認証・認可のバイパスが不可能か
• 機密情報（APIキー、トークン）がハードコードされていないか
• 入力バリデーションが全エンドポイントに適用されているか

金額計算チェック（3項目）

• 金額フィールドがInt型か（Float/Decimal不可）
• 除算で1円の消失が起きないか（整数演算のみ）
• 合計と明細の整合性が保たれるか

エラーハンドリングチェック（3項目）

• fetch失敗時に画面クラッシュしないか（res.okチェック）
• API呼び出しにタイムアウト設定があるか
• ユーザーに適切なエラーメッセージが表示されるか

UI/UXチェック（5項目）

• フォームページに戻るリンク・キャンセルボタンがあるか
• 送信ボタンに二重送信防止（submittingガード）があるか
• エラーフィードバックがユーザーに表示されるか
• モバイル（390px）で表示が崩れないか
• 3箇所以上で使うコンポーネントが共通化されているか

3. OA監査ゲート

VDUレビューとは独立した第三者監査。三線防御の原則に基づき、VDUが見落とした問題を検出する。

4. CEO承認ゲート

5. セキュリティゲート

設計〜実装〜テスト全工程を通じたセキュリティ確保。セキュリティ・バイ・デザインの原則。

ナレッジ記録テンプレート

工程11（記録）で作成するナレッジ記録は以下のテンプレートに準拠する。

ナレッジの分類体系

蓄積済みナレッジ（初期登録）

過去のPJ・インシデントから得られた知見を初期ナレッジとして登録。

ナレッジの運用ルール

追記エリア

— 以下、PJ完了ごとに追記 —