最終更新: 2026/06/22 18:56
commonid: rq-087type: researchstatus: active
pagepriority: P2

RQ-087: Decision Pipeline の意思決定確定・記録 UI/IA のベストプラクティス（DPJ-001 完遂・特に Decide/Corpus）

起案日: 2026-06-02 起案者: [email protected] ステータス: active (調査未着手) 優先度: P2 背景: 承認済み JTBD DPJ-001（アーキ/プロダクトの重要な意思決定を、盲点を潰して下し、監査可能な ADR として確定・記録する）のゴール軸は「ADR が Accepted 確定し記録された」。だが現行の Decision Pipeline chat UI（/chat）は 起案 → 審査 → 差し戻し対応までしか担っておらず、ゴール側の ①確定（Accept/sign-off）画面 ②記録の一覧・想起（ADR カタログ）画面が存在しない。JTBD の完了アウトカムを UI が支えていない。本 RQ は、この UI/IA をどう設計するかを 3 モデル並列調査で詰め、将来の「decision-pipeline UI/IA ADR」と MVP exit 基準の根拠を収集する。

0. 経緯

  • 親調査 RQ-086（意思決定支援ツール JTBD landscape） で「making + recording を 1 動作で繋ぐソロ作り手向け」が市場の空白と確認済み。本 RQ はその next layer（landscape → UI/IA 設計）。
  • 2026-06-02、Slide-IR ADR を実審査にかける過程で Cross-Validation 過剰審査ループ（多重却下 ADR が goalpost 移動で収束不能）を実データで確証。人間が「過剰審査と判断して迂回 Accept する」運用が属人的に発生しており、その判断・迂回 Accept・監査注記を載せる UI 面（Decide / Review）が未整備であることが顕在化した（[[reference_crossval_selfscore_premise_loop]]、systemic fix 設計は別 plan）。
  • 現 /chat（drp/public/chat.html）の機能: 起案フォーム（author/title/context/options）+ Server drafts（KV staging）CRUD + 審査開始 + gate 進捗ポーリング + score 表。Accept 操作・ADR 一覧・想起・整合チェックは無し。

1. 調査設問

主眼 = P1（Decide + Corpus）。P2 で 4 画面 IA の枠に位置づけ、P3 で HITL/過剰審査の可視化を付随的に扱う。すべて「ソロ作り手（n=1）・監査要件あり・認知負荷最小化（探す/迷うコストの排除）」を制約として評価する。

1.1 P1 設問（主眼: 確定 Decide + 記録 Corpus）

  1. 意思決定の「確定（Accept / sign-off / curation）」UI のベストプラクティスは何か。誰が・何を見て確定し、**監査証跡（誰が・いつ・何を根拠に Accept したか）**をどう残すか。ADR / decision-log ツール（Log4brains / adr-tools / adr-kit / Backstage ADR plugin / MADR 系 / sventorben decider）の確定・ステータス遷移（Proposed→Accepted）・curation フローの実装パターン。
  2. 「決定の一覧・カタログ・想起」UI のベストプラクティス。ADR catalog/index、issue tracker（Linear / Jira / Notion DB / GitHub Projects）の status / フィルタ / 停滞（Proposed のまま詰まった案件）検知の表現。本プロジェクト固有の Status × Mode × score × churn（再投入回数）× Implementation Status を n=1 運用で認知負荷最小に一覧化する方法。
  3. 単一作り手前提の MVP 必須要素 vs 省略可。確定・一覧 UI のうち、1 人運用で「無いと JTBD が完了しない」最小集合と、チーム化まで後回しにできる要素の線引き。

1.2 P2 設問（4 画面 IA・遷移）

  1. Compose → Review → Decide → Corpus の情報設計・画面遷移・状態モデル（draft / run / ADR の状態と画面のマッピング）。各画面が持つべき情報と、画面間で引き継ぐ context。
  2. 想起（Recall）/ 整合チェックの入口設計。新規起案時に「関連・矛盾する過去 ADR」を提示して二重起案・前提矛盾を防ぐ仕組み（decision graph / 全文検索 / タグ / 埋め込み類似）。Compose のサイドバーか Corpus 経由か。

1.3 P3 設問（HITL・過剰審査の可視化）

  1. 審査進捗・差し戻し理由の人間提示のベストプラクティス。AI レビュー結果を人間が短時間で把握できる UI（先行: Graphite / CodeRabbit / Devin / Cursor 等の AI レビュー提示）。差し戻し理由 → 該当節へのジャンプ等。
  2. 過剰審査（goalpost 移動）・収束不能を人間に促す UX。同一案件が連続却下され収束しない状態を可視化し、「人間判断（迂回 Accept + 監査注記）へ移れ」と促す設計（本プロジェクトの Cross-Val fix の Part2 escalate の UI 着地点）。迂回 Accept 操作と監査透明性の担保。

2. 想定情報源

  • ADR / decision-record ツール: Log4brains / adr-tools / adr-kit / Backstage ADR plugin / MADR / ThoughtWorks Tech Radar / Olaf Zimmermann Decision Capture / sventorben decider。
  • 一覧・カタログ・承認 UI: Linear / Jira / Notion DB / GitHub Projects / Atlassian DACI。
  • AI レビュー提示 UI: Graphite / CodeRabbit / Devin / Cursor。
  • UX 原則: Nielsen Norman Group（dashboard / approval / status 表現）/ Diátaxis（カタログ閲覧の情報設計）。
  • 自プロジェクト: RQ-086 synthesis（JTBD landscape）/ DPJ-001（customer_insight/_builder_jtbd_list.md）/ 現 /chat 実装。

3. 次工程（本 RQ doc は設問定義まで）

scripts/deep_research_meta_prompt.md を参照してメタプロンプト → 調査プロンプト（research_prompts/RQ-087_decision_ui_prompt.md）を生成 → 3 モデル並列（Claude / Gemini / GPT） で調査 → Synthesis（MCDA で bizlp 採用方針に集約）→ decision-pipeline UI/IA ADR 起案。 ※ その ADR は decision-pipeline 自体の話題＝Cross-Validation 過剰審査リスクに注意（迂回前提・[[reference_crossval_selfscore_premise_loop]]）。

4. 関連案件

  • 親: RQ-086（意思決定支援ツール JTBD landscape）。
  • JTBD: DPJ-001（make + record 統合）。
  • 出口: 将来の decision-pipeline UI/IA ADR / MVP exit 基準（mvp_exit_criteria.md / _builder_jtbd_list.md §未確定論点）。
  • 隣接: RQ-034（GAS Web App 上の Chat UI 設計）/ Cross-Val 過剰審査 systemic fix（別 plan）。