DRP ビジネス要求定義書

役割: DRP（意思決定 審査パイプライン）の存在理由 = ビジネス要求（BR-）と設計原則の正典。旧 README §3〜5 から抽出（strangler-fig Phase 1 / ADR-0117）。 ID 規約: id_conventions.md。BR は最上層のため covers を持たない。下層（システム要件）が covers で本書を参照する。

1. 背景 — なぜこのパイプラインがあるのか

ねらいを一言でいえば、「特定の一人を待たなくても、誰もが質を保ったまま意思決定を前に進められる」状態をつくることである。

1.1 この仕組みが無かったとき（Before）

• 判断のたびに『詳しい人』に聞きにいく必要があった — その人が捕まらないと話が止まり、実装も止まる。
• 「なぜそう決めたか」がどこにも残っていない — 後から加わった人は背景が分からず、同じ説明を口頭で求めることになる。
• 一人で決めるとレビューが入らない — 見落とし・過去の決定との矛盾・代替案の検討不足に、誰も気づけない。
• それでいて会計領域なので、判断の根拠は監査でも説明できる形で残さないといけない。

つまり、知識と判断が**特定の一人に集中している（属人化している）**ことが、チーム全体のボトルネックになっていた。

1.2 会社のパーパスとのつながり

このねらいは思いつきではない。当社のパーパス 「信じあえるを手続きから解放する」（＝信じるための確認作業に費やす時間とエネルギーをゼロにする）を、まず自社の意思決定に当てはめたものである。「この判断は信じていい」を、特定の一人が逐一確認しなくても担保する——それがこの仕組みの根っこにある。

2. ビジネス要求（BR）

BR-001: 属人化の解消 — 特定の一人を待たずに意思決定を前に進められる

起案者が誰であっても——経験の浅いメンバーでも、外部の協力者でも、代表取締役でも——特定の一人の都合を待たずに、質を保ったまま判断を前に進められること。レビューしてくれる先輩がいなくても、盲点の指摘・過去決定との矛盾チェック・採点・多角レビューをその場で受けられる。

BR-002: 判断根拠の監査可能な記録

判断は ADR（Architecture Decision Record＝判断の記録）として文書で残り、後から読む人が自分で背景を辿れること。会計領域のため、判断の根拠は監査でも説明できる形で残す（記録に値する判断だけを選別して残すことを含む）。

BR-003: 一人判断へのレビュー担保 — 盲点・矛盾・代替案検討不足の機械チェック

提出された判断に対し、次の 3 点を機械的に確かめること。これは「AI が代わりに完璧な ADR を書いてくれる工場」ではなく、人間が下した判断の質を AI が機械的にチェックする仕組みである。

• ① 大事な論点を見落としていないか（網羅性）
• ② 過去の決定と矛盾していないか（整合性）
• ③ ほかの案ときちんと比べたか（代替案の検討）

BR-004: 最終決定権は人間 — AI は審査員であって決裁者ではない

AI は判定・採点・指摘を行うが、最終的な意思決定責任は常に人間（起案者および代表取締役）が負うこと。最終承認（Accepted）を出せるのは代表取締役だけ。

BR-005: 危険な変更は仕組みで止める — 安全側に倒れるデフォルト

過去の決定が勝手に上書きされない／機密が外に漏れない／最終承認は権限者が出す、をルールで固定すること。一人ひとりが気を張らなくても、安全側に倒れる。

3. 対象ユーザー・ステークホルダー

4. 設計原則

DRP のいちばんの原則は 「AI は決めない。人が決める」。すべての設計判断はここから外れない。下記は会社の大事な決めごとを AI で審査する仕組みを作るうえで、ゆずれない 5 つの構え。各原則は「X より Y を優先」の形で立場を言い切る（記載方針は RQ-096）。

ゆずれない原則（構え）

1. 人が決める ＞ AI に任せる — 大事な決定の最終判断は必ず人が下す。AI は下調べと点検をする助手。 なぜ: 「なぜそう決めたか」を説明する責任は会社に残る。AI に決めさせると責任の所在が消える。根拠 BR-004
2. 大事な決定を見落とさない ＞ 早く片付ける — 記録に残すべき起案を取りこぼさないことを最優先。多少の手間は許容する。 なぜ: 失った決定の記録は後から取り戻せない。拾いすぎは捨てられるが、見落としには気づけない。根拠 BR-002 / NFR-003
3. 迷ったら立ち止まる ＞ とりあえず進める — 危険・不明なときは初期設定で止める。 なぜ: 少人数の会社では、間違った決定の後始末のほうがスピードの利益より高くつく。根拠 BR-005
4. いつ出しても同じ審査 ＞ その時々で変わる審査 — 同じ提案には毎回同じ視点・同じ指摘を返す。 なぜ: 出すたびに指摘がぶれると提案者が振り回され、審査そのものが信用されなくなる。根拠 NFR-006
5. 本人が考え抜く ＞ AI に書かせる — 基準に届かない提案は AI に清書させず本人が練り直す。 なぜ: 考えること自体を外注すると、決定への納得と自分の言葉で説明する力が育たない。根拠 BR-003 / BR-004

原則を具体的に守る実装ルール（検証可能な要件の正典は システム要件定義書）

• 40 点未満は差戻し — 品質スコアが閾値に達しない起案は PR 化しない。AI と壁打ちして起案者自身が練り直す。根拠 BR-003
• AI に責任を委ねない — PR 概要欄に「最終的にこの決定で進めたい理由」を起案者自身の言葉で 1 行記述する。根拠 BR-004
• AI が足した補強は人間が承認 — AI が起案者の生テキストの外で織り込んだ補強策（Pipeline 補強一覧）は、PR レビューで承認者が項目ごとに確認するまでマージしない。AI 任せの自動確定を防ぐ。根拠 BR-004（手順は operator_guide §4.4）
• Status 遷移権限の分離 — 起案者は Proposed の PR を作成。Accepted / Superseded は代表取締役のみが判断する。根拠 BR-004 / BR-005
• 送信前マスキング — 秘密情報を消してから AI に送る。消せないときは送らず失敗させる。根拠 BR-005

変更履歴