PMが「どのタイミングで・何を・どうすべきか」に迷わないための実務指針。
一般的なシステム開発の進め方を、MNMLの行動規範「見立てる → 仕立てる → 動かす」に対応づけて整理した。本サンプル版は「構想〜要件定義」フェーズのみ詳細に記述し、以降は見出しのみ（後日拡張）。
プロジェクトで事故が起きるのは、多くの場合「技術力が足りない」からではなく、今どの段階にいて、その段階で本来やるべきことを飛ばしたから起きる。要件が固まる前に作り始める。作り終えてから「そもそも何を作るんだっけ」を議論する。こうした手戻りは、段階（フェーズ）ごとの「やるべきこと」と「まだやってはいけないこと」を明文化しておくだけで、かなりの割合が防げる。
本ガイドは、システム開発でよく使われるフェーズ分割の考え方を土台に、各段階について次の4点だけを短く定義する。①ゴール ②PMの標準タスク ③よくある失敗と対策 ④MNMLのIssue運用への落とし込み。読んで判断に使えることを最優先とし、網羅性より実用性を採る。
MNMLの行動規範は仕事を3段で捉える。この3段に、システム開発の標準フェーズを次のように割り当てる。
| 段 | その段の問い | 含まれるフェーズ | この段を終える判定 |
|---|---|---|---|
| 見立てる | 本当に解くべき問題は何か。誰が困っているか。 | 構想・要件定義 | 「何を・なぜ作るか」が測定可能な形で合意されている |
| 仕立てる | それをどう実現するか。どの順で組むか。 | 設計 | 作り方が決まり、着手可能な単位に割れている |
| 動かす | 本当に動くか。使われるか。回り続けるか。 | 開発・テスト・リリース・運用 | 本番で価値が出て、壊れても復旧できる |
以降の各フェーズは、必ず同じ4項目で書く。迷ったらこの順に確認すればよい。
| # | 項目 | 読み方 |
|---|---|---|
| ① | この段階のゴール | ここを抜けてよいと言える状態。曖昧なら次へ進まない。 |
| ② | PMの標準タスク | PM（＝M層）が自分の手で必ずやること。委譲してよい作業と分ける。 |
| ③ | よくある失敗と対策 | この段で典型的に事故る型。先回りで潰す。 |
| ④ | MNMLのIssue運用 | この段の成果をSlack/GitHub Issueにどう残すか。SoTの置き場所。 |
まだ「作る」と決めていない段階。作るに値するかを見極める。
構想の出口は、立派な企画書ではない。「解くべき問題」と「解けたと言える基準」が一致していることが唯一の合格条件だ。ここが曖昧なまま先に進むと、以降のすべての段階が空中戦になる。逆に、ここで「今回はやらない」と決められることも、構想フェーズの立派な成果である。
| 失敗の型 | 何が起きるか | 対策 |
|---|---|---|
| 要求のまま着手 | 「〜したい」を要件と誤認し、作った後にズレが発覚 | 要求→要件（定量化）の変換を必ず1ステップ挟む |
| 解決策ありき | 「AIで」「このツールで」から入り、問題を後付け | 先に困りごと、後に手段。手段から入ったら一度戻る |
| 成功基準なし | 完成しても「良くなったのか」を誰も判定できない | 数値・締切・Done条件を構想時点で1つは決める |
| 影響範囲の見落とし | 後工程で「あの業務にも関わる」が噴出し手戻り | ステークホルダーと既存資産（過去Issue・成果物）を先に確認 |
構想段階のSoTはSlackスレッド（議論）。まだGitHub Issueは起票しない。CEOとM層の対話で要求を要件へ寄せ、成功基準の合意までをスレッドに残す。着手GOが出て初めてIssue化する。
「作る」と決めた対象を、着手できる粒度まで確定する段階。
要件定義の出口は、「これが満たされたら完了」と誰が見ても判定できるチェックリストだ。仕様の細部を100%詰め切る必要はない（それは設計以降でよい）。だが「何ができれば終わりか」だけは、着手前に確定させる。ここが決まればW層・ベンダーへ安全に委譲できる。
| 失敗の型 | 何が起きるか | 対策 |
|---|---|---|
| スコープの無限膨張 | 「ついでにこれも」で終わりが見えなくなる | スコープ外リストを先に作り、追加は別Issueに切る |
| Done条件が曖昧 | 成果物を見て「これで合ってる?」の往復が続く | 受け入れ条件をテスト可能な文で、着手前に固定 |
| 入出力の未定義 | 実装者が想像で作り、様式が食い違う | 入力例・出力例を1組でも添える |
| 要件理解前の着手 | 作り直しコストが最大化 | 「要件が理解できていない状態では着手しない」を徹底 |
| 委譲先の選択ミス | 破壊的操作を社内ローカルでやり事故る | push/本番を伴う流れはベンダー(Web Claude)へ回す |
要件が確定したら、SoTはSlack → GitHub Issueへ移る。M層が下記テンプレでIssueを起票する。以降、作業のSoTはこのIssueになる。
## 経緯 (Slack thread の議論サマリ — なぜこの要件になったか) ## 要件 (確定した実装内容 / スコープ内・外) ## 受け入れ条件 - [ ] (Done の定義。テスト可能な粒度で) - [ ] ... ## メタデータ - 依頼者: (CEO / 自発) - M層: (chief / platform / ...) - Slack thread: (URL or thread_ts) @claude
auto-merge ラベルを付ける（CI通過後 squash merge → Issue close）以降のフェーズは本サンプルでは見出しのみ。4点セット（ゴール/標準タスク/失敗と対策/Issue運用）で順次書き足す。