このユニットの結論
大きなプロジェクトでは、「決める人」と「実行する人」と「相談を受ける人」と「知らされる人」を分けて、事前に決めておく必要があります。
これが決まっていないと、作業はできても、判断が止まります。
1. 何の話か
このユニットは、プロジェクトの役割分担の話です。
約120人が関わるプロジェクトでは、同じ課題について、
- 実際に手を動かす人
- 最終的に「これでいく」と決める人
- 決める前に意見を聞くべき人
- 決まったことを知らされるべき人
が別々にいます。
2. なぜ必要か
役割があいまいだと、次のようなことが起きます。
- 全員が「誰かが決めるだろう」と待ち、何も決まらない
- 決めた人と実行する人の認識が違い、やり直しになる
- 影響を受ける部門が知らされず、あとから反対が出る
経理で言えば、「伝票を起票する人」と「承認する人」が決まっていない状態です。作業はできても、正式な処理にはなりません。
3. このユニットで分かること
- 役割を4つに分けて考える方法（RACI）
- アステリア案件の人物と役割
- 役割分担で、AIに任せてはいけないこと
4. 役割を4つに分ける — RACI
実務でよく使われる整理の仕方に、RACI（レイシー）があります。
| 記号 | 英語 | 意味 |
|---|---|---|
| R | Responsible | 実行する人 |
| A | Accountable | 最終的に責任を持ち、決める人（原則1つの役割） |
| C | Consulted | 決める前に意見を聞く人 |
| I | Informed | 決まったことを知らされる人 |
ポイントは、A（決める人）を1つの役割に絞ることです。Aが複数いると、結局誰も決められなくなります。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の主な人物と役割
- P-001 佐伯 隆志 — CFO／プロジェクトスポンサー
- P-002 高瀬 真理 — CIO／IT統括責任者
- P-003 西村 俊介 — プログラムマネージャー
- P-004 田辺 彩 — PMOリーダー
- P-005 藤本 遥 — 経理業務リーダー
- P-006 川村 美咲 — プロジェクト管理業務リーダー
- P-007 松本 健太 — 営業・契約業務リーダー
- P-008 黒田 健 — システムアーキテクト
- P-009 橋本 奈緒 — データ移行リーダー
- P-010 宮田 直人 — テスト・品質管理リーダー
- P-011 山下 恵 — 本番移行・運用リーダー
- P-012 石井 稔 — セキュリティ責任者
- P-013 木村 亮 — AIガバナンス責任者
- Vendor PM：P-A01 井上 健一（Vendor A）、P-B01 吉田 圭介（Vendor B）、P-C01 大森 裕（Vendor C）
正本には、どの人物がどの判断の「A（決める人）」かという対応表はありません。未確定 このユニットでは、役職名から決定権を推測しません。
5. 役職名だけでは決まらない
「プログラムマネージャーだから全部決める」「業務リーダーだから業務のことは全部決める」とは限りません。
実務では、判断の種類ごとにAを決めます。たとえば、
- 要件の追加・変更
- 設計方針の選択
- テストの終了
- 本番稼働の可否
は、それぞれAが違うことがあります。
6. THINK — 会議で決まらない
ある要件について、業務部門とシステム部門の意見が分かれ、3回の会議で決着がつきませんでした。
問題
4回目の会議を開けば決まるでしょうか。
判断例を開く
判断
会議の回数では解決しないことが多いです。
確認すること:
- この判断のAは誰か（決まっているか）
- Cとして意見を聞くべき人は誰か
- 判断の期限はいつか
- 決まらない場合、誰に上げるか（エスカレーション先）
Aが決まっていないなら、まずAを決めることが先です。
7. よくある失敗
- 「関係者全員の合意」を決め方にしてしまう
- Aが複数いる、またはAがいない
- 役割表を作ったが、判断の種類ごとに分けていない
- 決まったことを記録せず、あとで蒸し返される
8. 成果物との接続
- PRG-004 役割・責任分担表：判断の種類ごとに、R・A・C・Iを整理する
- PRG-007 意思決定記録：誰が、いつ、何を、なぜ決めたかを残す
- PRG-003 プロジェクト体制図：組織と報告の流れを示す
危機演習 CR01 要件定義が終わらない、CR03 Vendor AとVendor Cが責任を押し付け合う では、プロジェクトの途中で起きた状況を体験します（学習上の接続です。正式な対応関係ではありません）。
9. AI WORKFLOW — 役割表の抜けを探させる
指示例:
「次の役割・責任分担表を確認し、①Aがいない判断、②Aが複数いる判断、③Rがいない判断、④同じ人にAとRが集中しすぎている箇所、を挙げてください。誰をAにすべきかは提案せず、確認すべき点だけを示してください。」
10. REVIEW — AIの指摘を確認する
- 判断の種類の分け方が、実際のプロジェクトに合っているか
- AIが役職名から決定権を推測していないか
- 指摘された抜けが、本当に抜けなのか（別の表で決まっていないか）
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 判断を分解する粒度と、決定の記録の型
A が決まらないのは、判断が大きすぎるから
「要件の変更」を 1 つの判断として A を決めようとすると、業務の側もシステムの側も譲れず、A が決まりません。判断を分解します。「業務上の必要性を決める」「システムへの影響を見積もる」「費用と期間の増加を受け入れる」「反映の時期を決める」に分ければ、それぞれに A を 1 つ置けます。A が決まらないときは、まず判断の粒度を疑います。
決定の記録の型
決めたことは、結論だけでなく、同じ型で残します。世界で共有されている型は、おおむね次の 4 つの欄です。
- 文脈：何が問題で、なぜ今決める必要があったか
- 選択肢：比べた案と、それぞれの長所・短所
- 決定：どの案にしたか。誰が、いつ決めたか
- 結果：この決定で受け入れた制約と、見直す条件
結論だけの記録は、あとで「なぜそうしたのか」を説明できず、同じ議論が蒸し返されます。
反対しても従う
C（意見を聞く人）が反対しても、A が決めたら、その決定に沿って動く、という約束を前もって交わします。世界で共有されている考え方では「反対しても従う」と呼ばれます。これがないと、決定のあとも議論が続き、決めた意味がなくなります。反対した意見は、決定の記録の選択肢の欄に残し、見直す条件に反映します。
測り方の例
- A が決まっていない判断の数
- 決定の記録のうち、4 つの欄がそろっている割合
- 決定のあとに蒸し返された判断の数
現場で確かめる問い
- A が決まらない判断は、分解できないほど大きくないか。分解するとどうなるか
- 決定の記録は、結論だけになっていないか。選択肢と見直す条件が残っているか
- 反対した人が、決定のあとにその決定に沿って動く約束があるか
- 蒸し返された判断の数を数えたことがあるか。蒸し返される理由は何か
アステリア案件で判断をどの粒度で分解し、決定の記録がどの型だったかは、正本に記録がありません。記録なし
11. 人間が判断すること
- 判断の種類ごとに、誰をA（決める人）にするか
- 決まらないときのエスカレーション先
- 役割表を、いつ、誰の承認で変えるか
AIは意思決定責任者ではありません（正本の方針）。決定権の割り当てはAIに任せません。
12. 判断演習
次の判断について、RACIのうち何を決めておく必要があるかを考えてください。
- 「本番稼働してよいか」の判断
- 「この要件を次期に回すか」の判断
それぞれ、Aを1つの役割に絞れるかを確かめてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
役割分担の目的は、判断が止まらないようにすることです。
判断の種類ごとに「決める人」を1つに絞り、決めたことを記録します。