RAIDログ(リスク・前提・課題・依存関係)のスライドをPowerPointで作る手順。週によってリスク8件・依存関係1件のように偏っても崩れない組み方を解説する。
RAIDログのスライドはカテゴリが4つしかない。リスク、前提条件(アシャンプション)、課題、依存関係——だから4列のグリッドを一つ作って毎週の項目を流し込むだけの、デッキの中では一番簡単なステータススライドに見える。ところが実際には、ある決まったパターンで崩れる。RAIDログの4カテゴリは絶対に均等には埋まらない。実際の内訳がわかる前に組んだグリッドは、どのカテゴリにも合わないボックスサイズを固定してしまう。リスクが8件、前提が3件、課題が2件、依存関係が1件という週には、リスク列がスライドの大半を占め、依存関係列はその3分の1にも満たない高さで十分、というレイアウトが必要になる。4つの等高ボックスを並べてリスク列を8ポイントの文字で押し込み、依存関係列をほぼ空白のまま隣に並べる——というのが、何も考えずに組んだときに必ず起きることだ。直し方は、他の不揃いなステータスグリッドと同じ発想でいい。件数が確定してから、各列をその件数に合わせてサイズを決める。そして来週の入れ替わりがドラッグ操作で済むように、列同士を独立させておく。
ある中堅ERP移行プロジェクト、3週目のRAIDログ
これは中堅企業のERP移行プロジェクト、週次ステコミ(ステアリングコミッティ)がほぼ自動的に走る類のプログラムの3週目のログだ。リスクは8件——ベンダーのデータ移行ツールがまだ本番環境向けに未検証であること、統合担当のキーエンジニア2名が別の本番稼働プロジェクトにも入っていること、カットオーバー予定の週末が祝日と重なること、変更凍結期間がテストチームの想定より3日短いこと、などが並ぶ。前提条件は3件——レガシーシステムの取引量がカットオーバーまで現状の範囲内に収まる、という前提などだ。課題は2件——週の途中のインフラ変更以降、原因が特定できないままテスト環境が本番比でおよそ4割遅い状態になっている、というものを含む。依存関係は1件——次のテストサイクルを始める前に必要な、外部の給与計算ベンダーからのデータマッピング仕様のサインオフだ。
これを4列均等のグリッドで組むと、2方向同時に読みにくくなる。1行の説明文と担当者名が付いたリスク項目が8件、3〜4件分のサイズで作った列をはみ出していく。誰かがフォントを10ポイントに縮めて無理やり収め、火曜日のレビューで9件目のリスクが追加されるとさらに縮める。一方の依存関係列は、1件だけの項目が、隣で溢れているリスク列とまったく同じ高さの箱の中にぽつんと座っている——一見すると、依存関係もリスクと同じ厳密さで管理されているように見えるが、実際の中身は1行だけだ。
均等割りが最初から正解ではなかった理由
不均衡を生む要因は3つある。どれもログの付け方が悪いわけではなく、RAIDログという仕組みそのものの振る舞いだ。
プログラムのフェーズが進むにつれて、4カテゴリは同じ速度で埋まらない。プログラム序盤は、記録すべきことのほとんどがリスクか前提条件になる——まだ何も実際には起きていないので、課題として書けることがない。カットオーバー週に近づくとこれが逆転する。間に合わなかったリスクは課題に転化し、前提条件は成立するか棚卸しされて消え、1週目にはほとんど空だった課題列が、一番大事な週には一番厚い列になっていることが多い。キックオフ時点の1週目の内訳に合わせて一度だけ組んだグリッドは、12週目の内訳には合わないことが保証されているようなものだ。
RAID項目は単なるラベルではなく、担当者・影響度・たいていは1行の対応方針やネクストステップまで持っており、それらの長さも件数と同じくらいばらつく。先述のベンダーツールのリスクは、リスク内容・担当者・進行中の対応策を書くのに3行必要になる。一方、取引量の前提条件は1行で済む。行数だけを数えてサイズを決め、行ごとの高さが3倍違うことを無視した列は、紙の上では件数が妥当に見えても結局はみ出す。
項目はカテゴリ間を移動し、RAIDログはその移動自体が本質であるステータス資料だ。アイゼンハワーマトリクスのカードであれば、ある象限から別の象限へ再分類される程度で済む。しかしRAID項目はもっと特殊な動きをする——顕在化したリスクはリスクであることをやめ、課題になる。そのリスクを6週間追いかけてきたレビュー参加者は、履歴とのつながりを見たいのであって、脈絡のない新規課題を見たいわけではない。各列を独立した別々のリストとして扱うレイアウトは、項目が境界をまたいだ瞬間にその痕跡を失ってしまう。
ここがRAIDログが単なるリスク登録簿(リスクレジスター)と違う点でもある。リスクレジスターは発生確率・影響度スコア・対応責任者・レビュー日といった形で1カテゴリをより深く追跡するツールだ。RAIDログはその深さを手放す代わりに、同じ1枚の上でリスクを前提条件・課題・依存関係と実際に相互作用する形で並べる、という広さを取る。これから説明するレイアウトの問題は、この4カテゴリの「広さ」に固有のものであり、1カテゴリを10列の詳細で管理するリスクレジスターとは別物のスライドになる。
8-3-2-1の内訳でも崩れないグリッドの組み方
共有テーブルのセルとしてではなく、4カテゴリそれぞれを独立して伸び縮みするコンテナとして扱うのが基本の考え方だ。
手順1 ― 列数と列幅は固定し、高さは固定しない。カテゴリごとに1列、計4列を同じ幅で並べ、ヘッダーバーは色分けする——リスクは薄い赤、前提条件は淡い青、課題はアンバー、依存関係はグレー。列幅は件数について何も語らないので、4列とも同じ幅のままでいい。動かす変数は高さだけだ。
手順2 ― すべての項目に、一度割り振ったら使い回さない固有IDを付ける。今週のリスクにはR1からR8、前提条件にはA1からA3、課題にはI1とI2、依存関係にはD1。これはほとんどのRAIDログテンプレートが省略している手順であり、カテゴリ間の移動を「情報の欠落」ではなく「読める履歴」に変える唯一の手順でもある。翌週、リスクR4(ベンダーツールのリスク)が顕在化して課題になったとき、新しい課題カードは出所不明の新規行としてではなく、「I3(R4より)」と表示される。
手順3 ― 各項目のカードを内容に合わせてサイズ決めし、それを積み上げて列の高さを得る。1行の説明文と担当者名だけのカードは、11ポイントの文字でおよそ0.4インチあればよい。3行の対応方針メモが付くカードは0.9インチ近く必要になる。各列のカード高さを合計し、カード間の小さな余白(0.08インチ)とヘッダー分の固定スペースを足せば、それが列の実際の高さになる——勘でも、テンプレートの既定値でもない。3週目の例では、リスク列はおよそ5.5インチ、依存関係列はおよそ0.6インチになる。その差をそのまま見せればいい。
手順4 ― 4つのヘッダーバーは同じ上端に揃え、下端は中身が決めるところに任せる。これが、著しく不揃いなグリッドを「崩れて見える」のではなく「正直に見える」ようにする唯一の一手だ。上端がフラットで下端がギザギザ——リスクがスライドの3分の2近くまで伸び、依存関係は1枚のカードで止まる——という形は、「その週は実際にこうだった」と読める。1つの視点に6個のKPIが並び、別の視点には2個しかないバランススコアカードのスライドが不揃いな高さのまま成立するのと、同じ理屈だ。
手順5 ― 各列を「RAID_Risks」「RAID_Assumptions」「RAID_Issues」「RAID_Dependencies」として個別にグループ化する。ヘッダーバー・現在その列に入っている全カード・背景の塗りを選択して、Ctrl+Gでグループ化する。先週からカードが1件増えた列も、1件クローズして減った列も、そのグループの中で図形を1つ足し引きしてグループの高さが追従するだけで済む——変化していない他の3列を測り直す必要はない。
カテゴリの色とは別に、深刻度用のもう一色を用意する。ヘッダーバーはすでに「リスク/前提/課題/依存関係のどれか」を示す色を1つ持っている。この同じ色のチャンネルを「その項目がどれだけ深刻か」の表示にも流用してはいけない——影響度の高い前提条件を目立たせようとして、ヘッダーをリスク列と同じ赤に変えてしまうのがその典型的な失敗だ。代わりに、各カードの右上に0.1インチほどの小さなドットを置き、カテゴリとは別の赤・アンバー・緑のスケールで影響度を示す。給与ベンダーのサインオフが遅れるとカットオーバーが本当に止まるなら、依存関係のカードに赤いドットを付けてよい。リスクとしては実在するが影響が小さいなら、緑のドットでよい。カテゴリはヘッダーで、深刻度はカードで——役割の違う2つの色チャンネルを使い分けることで、「今週本当に危ないのはどれか」を、「どのリストに入っているか」と混同せずに一目で拾えるようになる。
4週目 ― リスク3件がクローズし、1件が課題に転化し、依存関係が1件解消する
翌週の火曜日、ベンダーからデータ移行ツールの検証完了の連絡が入る——ただし、きれいな形では終わらない。リスクR4はクローズするが、新たに小さな課題を浮かび上がらせる。移行ツールが、カットオーバー前に手作業での補正が必要なレガシーレコードを約2%検出したのだ。対応策が実を結び、他に2件のリスクがそのままクローズする。給与の依存関係D1は、ベンダーのサインオフが得られて解消する。結果として、リスクは8件から5件に減り、課題は2件から3件に増え、依存関係はその週に限って1件から0件になる。
すべての列が個別の名前付きグループで、すべての項目が固有IDを持っているため、このスライドの更新はドラッグ操作3回とグループのリサイズ1回で済み、作り直しにはならない。R4のカードはリスクグループから抜け出し、「I3(R4より)」とラベルを付け替えられ、課題グループに落ち着く。課題グループはカード1枚分高くなる。リスクグループからはさらに2枚のカードが削除され、グループは縮む。依存関係グループからはD1が削除され——その週に限ってはヘッダーバーだけが見える空の列になる。これ自体が有益な情報で、レビュー参加者は「外部要因で止まっているものは今のところ何もない」と一目で把握できる。依存関係をその週は追跡していなかったのかもしれない、と疑う必要がない。
現場メモ:外資系コンサル時代、あるPMOアナリストが9ヶ月間のプログラムを通じて毎週、このスライドをまっさらな4列の表から作り直すのを見ていたことがある。前週のファイルは、編集して使う作業ファイルではなく、数字を写すための参照資料として扱われていたからだ。4列を毎週目測で測り直す作業を9ヶ月続けた総工数は、グループ化とID管理を一度仕込んだうえで毎週90秒だけカードをグループ間で動かす場合とおおむね同じになる。スライドは「見た目がシンプル」だからといって作るのが楽になるわけではない。内部構造を持たない4列グリッドは、説明するのは簡単だが、維持するのは遅い。
ログ型ステータススライド全般に通用する3原則
- 列のサイズは件数が確定したあとに決める。確定する前には決めない。RAIDログ、意思決定ログ、依存関係トラッカー——カテゴリ分けされた箱に件数が変動して入ってくるステータス資料は、すべて同じパターンで固定グリッドの下で崩れる。
- 項目がカテゴリをまたいで移動しうるなら、出所を追跡する。固有IDの仕組みを導入するコストはわずかな手間だが、今週の課題が新規なのか、6週間前からの続きなのかをレビューのたびに議論し直す手間を省いてくれる。
- 空の列は体裁の問題ではなく、1つの発見だ。隣の列の高さに合わせて薄い列を水増ししてはいけない。今週、依存関係列に何も入っていないこと自体が、ステコミに伝えるべき実のある情報だ。
来週のステコミ前に、月曜のうちにやっておくこと
今週のRAIDログがまだ4列均等の表のままなら、もっと項目数が落ち着いた週を待つ必要はない。ログがまだ短く扱いやすいうちに、今のうちに4つの名前付きグループを仕込んでおく——今日の時点では追加のコストはほぼゼロで、来週の入れ替わりがどんな形であれ、作り直しではなく数秒のドラッグ操作で済むようになる。まだ何もカテゴリ間を移動していなくても、今週の項目にIDを振っておく。IDが生きるのは来月以降の移動が追跡可能になった時であり、ログに40件分の履歴が溜まってから後付けするより、今のうちに振っておくほうがはるかに楽だ。そして、薄い列を一度だけ均してしまいたいという衝動は抑える。8-3-2-1という正直な内訳を読んだステコミは、見た目だけ整った4つの均等ボックスを読むより、プログラムの実際の負荷がどこにあるかをずっと多く学び取れる。
Advisioは、Microsoft AppSourceで公開されているPowerPointアドインで、その週の実際の項目リストからRAIDグリッドをネイティブな編集可能図形として直接構築する。各列を件数とコンテンツの長さに合わせてサイズ決めし、ヘッダー行を上端に揃えたまま保持するため、8-3-2-1だったログが翌週5-3-3-0になっても、作り直しではなくリサイズで済む。多くのステコミ資料で隣に並ぶ100日プランのスライドと同じ週次サイクルにそのまま馴染む。