BENTEN PRODUCT DEVELOPMENT
LIFT Engine 開発フロー
青野 × デジ坊 × PDM × Dev
確認日: 2026-09-15 · Markdownを保存
概要
このフローは、現場の声を仕様に変え、承認された変更を実装・検証・配備し、利用状況から次の改善へ戻す循環です。
青野さんがプロダクト上の判断を担い、デジ坊がSlackでの入口になります。PDMは要求を実物と照合して要件と影響分析へ整理し、Dev担当が承認済みの仕様に基づいて実装します。
重要: Issueの作成は開発着手の承認ではありません。PDMが扱う自動工程はrequirements・impactまでです。仕様化、承認、exportは運用工程として人が確認して進めます。
緑の箱:主な自動処理実線:処理・データの経路点線:人の操作・手動連携を含む確認した範囲: リポジトリと運用文書
構成
デジ坊はPDMのCloud Run受付です。PDM Actions/Claudeが実物を照合して台帳へ保存し、判断に必要な未決事項が解消して受理できたときだけGitHub Issue(triage/full)を作成します。Devへの入力は、承認済み仕様の写しと変更定義です。
Mermaidソースを表示
flowchart TB
U["利用者・現場"] --> S["Slack"]
A["青野さん・社内担当<br/>優先順位・仕様・リリース判断"] --> S
subgraph PD["pdm-agent:要求を仕様へ"]
B["デジ坊 / Cloud Run<br/>受付・回答・要求の記録"]
P["PDMハーネス / Actions<br/>実物照合・要件化・影響分析"]
L["PDM台帳<br/>要求・要件・仕様・判断根拠"]
T["週次PDM tracker<br/>目標と利用状況の差を確認"]
end
subgraph DV["開発の実行"]
C["dev-agent CLI<br/>承認済み入力の検証・実行管理"]
D["Dev担当<br/>Codex / 人の開発セッション"]
end
subgraph LE["lift-engine:製品・検証・配備"]
G["GitHub Issue・コード・PR"]
CI["CI・開発ハーネス<br/>テスト・変更範囲・回帰の検査"]
E["開発環境・本番環境"]
end
S --> B
B -->|調査依頼| P
B -->|原文を記録| L
P -->|要件を保存| L
P -->|問い・回答| S
P -->|未決が解消し、受理したらIssue| G
A -. 仕様を確認・承認 .-> L
L -. 承認済みspecと変更定義をexport .-> C
A -. 開発担当が手動dispatch .-> C
C -->|起動・記帳・停止管理| D
D -. 実装・別運用でpushとPR .-> G
G -->|PRで検証| CI
A -. レビュー・マージ・配備判断 .-> G
CI -->|devは手動起動 / prodはmain反映で自動| E
D -. 仕様の不足・矛盾を手動で差し戻し .-> P
E -->|利用ログ| T
G -->|IssueとPRの状態| T
T -->|改善要求| P
T -->|週次まとめ・判断依頼| S
classDef auto fill:#e7f4f2,stroke:#087b78,color:#102a43;
class B,P,T,CI auto;開発の流れ
Slackからの要求が要件化され、承認済み仕様が人手でDevへ渡されます。実装後のPR、レビュー、配備の判断は開発担当とレビュアーの運用です。
Mermaidソースを表示
sequenceDiagram
actor U as 利用者・現場
actor A as 青野さん・社内担当
participant B as Slack / デジ坊
participant P as PDM / 台帳
participant D as Dev担当
participant G as GitHub / CI
participant E as 開発環境・本番
U->>B: 要望・不具合・質問
B->>P: 原文・出典を記録し、調査を依頼
P->>G: developの製品コードを読む
P->>P: 実物照合・要件化・影響分析
loop 判断に必要な情報が残る場合
P-->>B: 要求者/青野さんへの問い
B-->>U: 元のスレッドで確認
U->>B: 回答
A->>B: 必要な方針判断
B->>P: 回答を渡し、要件を更新
end
break 説明で解決、または保留・却下・未決
P-->>B: 回答・理由・次に必要な判断を返す
end
P->>G: 要件が固まり受理したらIssue作成・更新
Note over A,P: Issue作成は開発着手の承認ではない
A->>P: 仕様化を進め、優先順位・仕様を確認して承認
P->>P: 承認済みspecと変更定義をexport
Note over P,D: change-id.spec.md と change-id.yml
A->>D: 人手でセッション起動 / dev-agent dispatch
P->>D: 承認済み仕様を引き渡す
D->>D: changeブランチで実装・ローカル検証
opt 仕様の不足・矛盾が見つかる
D-->>P: 該当作業を停止し、記録を手動連携
P-->>A: 判断・仕様修正を依頼
A->>P: 再判断・再承認
P-->>D: 再exportした仕様を渡す
Note over A,D: 再開も人の運用。自動再開(resume)は未実装
end
D->>G: 開発担当の運用でpush・PR作成
G->>G: CI・ハーネス・smoke検証
Note over A,G: 別主体による検収・レビュー
A->>G: developへマージ
A->>G: 開発環境への配備を手動起動
G->>E: lift-devへ配備
A->>E: 挙動・出力を確認
A->>G: リリースPRをmainへマージ
G->>E: lift-prodへ自動配備役割
| 主体 | 担うこと | 次へ渡すもの |
|---|---|---|
| 青野さん・社内担当 | プロダクト上の優先順位、仕様、リリースに関する判断 | 判断・承認 |
| デジ坊 | Slackでの受付、仕様回答、要求の記録・取りまとめ | 原文、出典、調査依頼 |
| PDM | 実物照合、要件化、影響分析、台帳への保存 | 承認対象の仕様、変更定義 |
| dev-agent CLI | 承認済み入力の確認、手動dispatch、開発セッションの管理 | 起動記録、停止・差戻し情報 |
| Dev担当 | 仕様に沿った実装とローカル検証、PR作成 | コード、PR、検証結果 |
| review担当 | 受入基準と変更内容の確認 | レビュー結果、merge判断 |
| PDM tracker | GitHubと利用状況を週次で照合し、gapを抽出 | 改善要求、Slackのまとめ |
境界と留意点
- dev-agent CLIとDev担当は別です。前者は開発セッションを管理する仕組みで、実装やPR作成をするのは後者の運用です。
- Slackからdev-agentを直接起動する連携、仕様exportの常駐監視、GitHubへの実投稿、自動再開(resume)、Claude headlessは現時点では実装されていません。
- 差戻しは、記録して手動連携し、再承認・再exportして再開します。
- 独立した検収の規約はありますが、現在のCIのacceptanceはnoticeであり、mergeを停止する強制にはなっていません。
- 社内の承認担当との具体的な分担は、この文書で断定していません。ここでは確認できるプロダクト判断の主体として青野さんを記載しています。
- 実際のSlack会話と起動中の開発セッションは照合していません。
根拠
以下はこの整理で参照した実装・運用文書です。リンク先は2026-09-15に確認しました。