プログラムRAIDログのテンプレート

プログラムを進めていると、心配ごとがどんどん増えていきます。「この前提、本当に大丈夫だろうか」「あのPJの遅れがこちらに響きそうだ」「もう起きてしまった、誰が対応するのか」。

これらを別々のメモで管理していると、必ず取りこぼします。そこで使うのがRAIDログです。R（リスク）、A（前提）、I（課題）、D（依存）の頭文字をとった呼び方で、4種類を1つの台帳にまとめて管理します。

この記事では、プログラム全体のRAIDログのテンプレートと、使い方を紹介します。はじめての方にもわかるように、RAIDそれぞれの意味から説明します。

■ 背景・よくある課題

プログラムでは、心配ごとの管理が次のようにつまずきます。

よくある状態	なぜ起きるか	その結果
リスク表・課題表・依存表がバラバラ	担当者ごとに使いやすい形で作っている	前提がくずれてもリスクに移されず、消える
各PJの表をそのまま集めている	プログラムとして選んでいない	200行を超え、どれが重要かわからない
登録したきり更新されない	見直す日が決まっていない	半年前のままの行が並び、台帳が信用されなくなる
担当者が「PMO」になっている	実際に動く人を決めていない	誰も動かず、期日だけが過ぎる
閉じる基準がない	終わったかどうかの判断があいまい	行が増え続け、見るのが苦痛になる

とくに多いのが、前提（A）と依存（D）を管理していないケースです。リスクと課題だけを見ていると、「そもそもの前提がくずれていた」「他のPJの遅れが効いていた」という、プログラム特有の問題に気づくのが遅れます。

■ RAIDの4種類とは

4つの意味を、まず整理します。

記号	読み方	意味	例
R	リスク（Risk）	まだ起きていないが、起きたら困ること	移行データの品質が悪く、稼働が延びるおそれ
A	前提（Assumption）	「こうなるはず」と決めつけて進めていること	業務部門から2名が4月から参加してくれるはず
I	課題（Issue）	すでに起きていて、いま困っていること	レビュー返却が9営業日かかり、開発が止まっている
D	依存（Dependency）	他のPJの成果物がないと進めないつながり	C1はC4の認証基盤が3月にないと着手できない

この4つは、独立したものではありません。放っておくと、おたがいに姿を変えていきます。

図 RAIDの4種類の関係

前提がくずれればリスクになり、リスクが現実になれば課題になります。依存先が遅れそうなら、それもリスクです。1つの台帳にしておくと、種類の欄を書き換えるだけで移せる——これがRAIDログを1つにまとめる一番の理由です。

■ テンプレートの全体像

プログラムRAIDログは、次の14項目で作ります。表計算ソフト1シートで足ります。

#	項目	書くこと
1	ID	R-01、A-05のように種類＋連番。種類が変わってもIDは変えない
2	種類	R／A／I／D のいずれか
3	登録日	最初に台帳に載せた日
4	タイトル	25字以内。一覧で読んで意味がわかる長さにする
5	内容	何が心配か、何が起きているかを3行以内で
6	関係するPJ	C1、C2など。複数可。プログラム全体なら「全体」
7	影響するベネフィット	B-01などのID。効かないなら「—」
8	影響度	大／中／小。金額・期間・ベネフィットのどれかで測る
9	可能性	高／中／低。RとDのみ。IとAは空欄
10	対応方針	回避／低減／転嫁／受容／対応中／解消のいずれか
11	対応内容	具体的に何をするか。「注視する」は書かない
12	担当者	個人名。部署名・「PMO」は不可
13	期日	次に状況が変わる日。決まっていないなら次回レビュー日
14	状態／最終更新	未着手／対応中／完了／クローズと、最後に触った日

項目を増やしたくなりますが、増やすほど更新されなくなります。14項目でも多いと感じるなら、7と9を省いてもかまいません。

■ プログラムの台帳に載せる基準

一番よくある失敗は、各PJのRAIDを全部集めてしまうことです。プログラムの台帳には、次のどれか1つにあてはまるものだけを上げます。

複数のPJにまたがる：1つのPJでは解決できないもの
ベネフィットに効く：ねらった効果が出なくなるおそれがあるもの
PgMの権限が要る：予備費の使用、優先順位の変更、ベンダーとの再交渉など
影響額が基準を超える：たとえば500万円以上、または3か月以上の遅れ

これにあてはまらないものは、各PJの台帳に置いたままにします。上げる／上げないの判断は、隔週の推進会議でPgMが決めます。「迷ったら上げる」ではなく「迷ったらPMに理由を聞く」が正解です。

■ 記入例：クラウドリーフ「プロダクト基盤刷新プログラム」

SaaS企業クラウドリーフ（ARR68億円・契約3,200社）が進めるプロダクト基盤刷新プログラム（2025年1月〜2027年6月、承認枠7億4,000万円、構成PJ4本）の、2025年9月時点のRAIDログです。全62件のうち、代表的な6件を抜粋します。

ID	種類	タイトル	関係PJ	影響/可能性	対応内容	担当	期日
A-03	A 前提	旧基盤の停止を2027年3月に実施できる	C1・C4	大／—	10月の役員会で停止時期を正式決定してもらう	藤原	2025/10/24
D-05	D 依存	C2の課金統合はC1の認証基盤に依存	C1→C2	大／中	C1のAPI仕様を2025年11月に凍結し、C2へ先行提供	佐野	2025/11/28
R-11	R リスク	テナント移行時に一部顧客で設定が欠落するおそれ	C1	大／中	上位200社分の設定を事前比較し、差分を手動補正する	大沢	2025/12/12
R-18	R リスク	解約率の改善が想定より遅れる	全体	大／中	四半期ごとに解約理由を分析し、C3の分析項目に反映する	藤原	2025/12/26
I-07	I 課題	C1とC2で顧客IDの桁数の考え方が違う	C1・C2	中／—	10月10日のアーキテクチャ会議で統一案を決定する	佐野	2025/10/10
I-09	I 課題	SRE要員2名が運用対応にとられ、C1の作業が遅延	C1	大／—	外部SRE1名を11月から3か月追加（予備費420万円を申請）	藤原	2025/10/31

件数の内訳は次のとおりです。

種類	件数	うち影響度「大」	今月の増減
R リスク	24件	7件	+3件／−1件
A 前提	18件	4件	±0件
I 課題	11件	3件	+2件／−2件
D 依存	9件	5件	±0件
合計	62件	19件	+5件／−3件

依存（D）の9件のうち5件が「大」になっているのは、プログラムとしてはふつうのことです。依存はもともと、1つのPJでは解決できないから台帳に上がってきます。依存だけ影響度が高く出るのは、健全なサインと考えてよいでしょう。

■ 運用ルール

台帳は、作ったあとの運用がすべてです。クラウドリーフでは次のように決めています。

タイミング	やること	誰が
随時	気づいたらその場で1行追加する（入力5分以内の項目だけ埋めればよい）	誰でも
隔週の推進会議	今週動いた行だけをレビューし、PJの台帳から上げるものを決める	PgM・PM
月1回	影響度「大」の全19件を確認。期日切れの行を洗い出す	PgM・PMO
月1回（運営委員会）	「大」のうち、判断が必要なものだけを報告する	PgM
四半期	前提（A）を全件見直す。くずれていればリスクに変える	PgM・PM全員

とくに大事なのが、四半期の前提の棚おろしです。前提は「変わったら教えてくれる」ものではありません。誰も気づかないまま、静かにくずれます。3か月に1回、全件を声に出して読み合わせるだけで、かなり拾えます。

もう1つ、閉じる基準も決めておきます。「対応が完了し、2週間たっても再発していない」ならクローズ。クローズした行は削除せず、別シートに移します。あとで似た問題が起きたとき、過去の対応が参考になります。

■ 活用シーン

月次報告書の材料として：「今月増えた／消えた／悪化した」の3つは、RAIDログから機械的に抽出できます。
ステージゲート審査で：影響度「大」の未クローズ件数は、ゲートを通す／通さないの判断材料になります。
予備費の申請根拠に：I-09のように、台帳の1行がそのまま申請書の理由になります。
PJ間の調整の場で：依存（D）の行を一緒に見ながら話すと、感情論になりにくくなります。

■ よくある失敗と直し方

失敗	何が起きるか	直し方
各PJのRAIDを全部集める	200行を超えて誰も見なくなる	上げる基準（4条件）を明文化し、PgMが仕分けする
前提（A）を登録していない	くずれたことに誰も気づかない	四半期に1回、全件の読み合わせをする
対応内容が「注視する」	何もしないのと同じ	「誰が・いつ・何をする」が書けないなら、受容と書いて割り切る
担当者が部署名になっている	誰も自分ごとにしない	個人名しか入力できないようにする
期日が空欄・過去のまま	台帳が信用されなくなる	期日切れの行を月次で色づけし、会議の冒頭で必ず読む
クローズした行を消してしまう	同じ問題が別のPJで再発する	削除せず別シートへ。新規登録時に過去分を検索する運用にする

■ 導入効果

クラウドリーフでは、PJごとのバラバラな管理からプログラムRAIDログに切り替えて、次のように変わりました。

項目	切り替え前	切り替え後
管理している表の数	PJごとに3〜4表（計14表）	1表
プログラム台帳の行数	218行（全PJ分の合計）	62行
期日切れの行の割合	34%	6%
前提がくずれてから気づくまで	平均11週間	平均4週間
推進会議でのRAID確認時間	45分	15分

行数が3分の1以下になったのに、見逃しは減っています。管理する量を減らすことが、管理の質を上げるという、プログラムマネジメントらしい結果です。

■ まとめ

RAIDログは、リスク（R）・前提（A）・課題（I）・依存（D）を1つの台帳で管理するしくみです。
4種類はおたがいに姿を変えます。1つの表にしておけば、種類の欄を書き換えるだけで移せます。
プログラムの台帳に上げるのは、複数PJにまたがる／ベネフィットに効く／PgMの権限が要る／影響額が基準超え、のどれかにあてはまるものだけです。
前提（A）は誰も教えてくれないので、四半期に1回、全件を読み合わせます。
担当は個人名、対応内容に「注視する」は書かない。この2つを守るだけで、台帳は動き出します。

次回は、複数のプロジェクトのリスクをまとめて見える化する「プログラム・リスク統合管理表」のテンプレートを紹介します。