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への入力は、承認済み仕様の写しと変更定義です。

lift-engine:製品・検証・配備開発の実行pdm-agent:要求を仕様へ調査依頼原文を記録要件を保存問い・回答未決が解消し、受理したらIssue仕様を確認・承認承認済みspecと変更定義をexport開発担当が手動dispatch起動・記帳・停止管理実装・別運用でpushとPRPRで検証レビュー・マージ・配備判断devは手動起動 /prodはmain反映で自動仕様の不足・矛盾を手動で差し戻し利用ログIssueとPRの状態改善要求週次まとめ・判断依頼

利用者・現場

Slack

青野さん・社内担当
優先順位・仕様・リリース判断

デジ坊 / Cloud Run
受付・回答・要求の記録

PDMハーネス / Actions
実物照合・要件化・影響分析

PDM台帳
要求・要件・仕様・判断根拠

週次PDM tracker
目標と利用状況の差を確認

dev-agent CLI
承認済み入力の検証・実行管理

Dev担当
Codex / 人の開発セッション

GitHub Issue・コード・PR

CI・開発ハーネス
テスト・変更範囲・回帰の検査

開発環境・本番環境

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、レビュー、配備の判断は開発担当とレビュアーの運用です。

開発環境・本番GitHub / CIDev担当PDM / 台帳Slack / デジ坊開発環境・本番GitHub / CIDev担当PDM / 台帳Slack / デジ坊loop[判断に必要な情報が残る場-合]break[説明で解決、または-保留・却下・未決]Issue作成は開発着手の承認ではないchange-id.spec.md とchange-id.yml再開も人の運用。自動再開(resume)は未実装opt[仕様の不足・矛盾が見つかる]別主体による検収・レビュー利用者・現場青野さん・社内担-要望・不具合・質問原文・出典を記録し、調査を-依頼developの製品コードを読む実物照合・要件化・-影響分析要求者/青野さんへの問い元のスレッドで確認回答必要な方針判断回答を渡し、要件を更新回答・理由・次に必要な判断-を返す要件が固まり受理したらIssue作成・更新仕様化を進め、優先順位・仕様を確認して承認承認済みspecと変更-定義をexport人手でセッション起動 / dev-agent dispatch承認済み仕様を引き渡すchangeブランチで実-装・ローカル検証該当作業を停止し、記録を手-動連携判断・仕様修正を依頼再判断・再承認再exportした仕様を渡す開発担当の運用でpush・PR作-CI・ハーネス・smo-ke検証developへマージ開発環境への配備を手動起動lift-devへ配備挙動・出力を確認リリースPRをmainへマージlift-prodへ自動配備利用者・現場青野さん・社内担-
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 trackerGitHubと利用状況を週次で照合し、gapを抽出改善要求、Slackのまとめ

境界と留意点

  • dev-agent CLIとDev担当は別です。前者は開発セッションを管理する仕組みで、実装やPR作成をするのは後者の運用です。
  • Slackからdev-agentを直接起動する連携、仕様exportの常駐監視、GitHubへの実投稿、自動再開(resume)、Claude headlessは現時点では実装されていません。
  • 差戻しは、記録して手動連携し、再承認・再exportして再開します。
  • 独立した検収の規約はありますが、現在のCIのacceptanceはnoticeであり、mergeを停止する強制にはなっていません。
  • 社内の承認担当との具体的な分担は、この文書で断定していません。ここでは確認できるプロダクト判断の主体として青野さんを記載しています。
  • 実際のSlack会話と起動中の開発セッションは照合していません。

根拠

以下はこの整理で参照した実装・運用文書です。リンク先は2026-09-15に確認しました。

図を拡大