リスクが形式で終わる現場へ──リスクレジスタを生かす更新運用

リスク管理、やってます。
そう言える体裁はあるのに、炎上は普通に起きる。むしろ起きてから、リスク表が発掘される。

このパターン、PMとして一度は踏みます。僕も踏みました。
そして踏んだ後に気づくのは、リスクが足りなかったのではなく、運用が足りなかったということです。

リスクレジスタは、作るものではなく回すもの。
作った瞬間に古くなるのが、リスクの性質だからです。

今日は、形式で終わらせずに、リスクレジスタを現場の意思決定に接続する更新運用をまとめます。
ポイントは、項目を増やすことではありません。更新のタイミングと、赤信号の扱い方を固定することです。

リスクが形式で終わる3つの原因

まず、ありがちな原因を切り分けます。ここを外すと、どれだけ項目を増やしても形骸化します。

1）登録がゴールになっている

洗い出して、書いて、埋めて、完了。
でもリスクは、書いた時点ではまだリスクですらないことも多い。予兆は後から現れます。

2）更新のトリガーがない

月1の定例で眺めるだけ。
週次の進捗会議とは別物。だから現場の判断が変わらない。

3）意思決定と接続していない

リスクが増えた、で終わる。
で、何を変えるのかが決まっていない。結果として行動に変換されません。

結局、リスクレジスタは健康診断の結果みたいになります。
異常値は載っているのに、生活が変わらない。だから悪化する。

生きるリスクレジスタの最小フォーマット

最小でいいです。むしろ最小の方が回ります。
僕は次の列だけに絞るのが一番現場で回りました。

• リスク（何が起きるか）

• 予兆（起きる前に何が変化するか）

• 影響（何が壊れるか：期限・品質・合意のどれか）

• 対応方針（回避・低減・移転・受容のどれか）

• 次の一手（いつまでに誰が何をするか）

• 状態（緑・黄・赤）

• オーナー（責任者、1人）

ポイントは予兆と次の一手です。
この2つが無いと、リスクは読み物になります。あれば、運用品になります。

更新運用の骨格は3つの会議に埋め込む

更新運用を成功させるコツは、リスク会議を増やさないことです。
既存の会議にリスク更新を埋め込みます。

1）週次進捗会議で、黄と赤だけ扱う

全リスクを見ません。
見るのは黄と赤だけ。緑は更新しません。触らない勇気が必要です。

進捗会議のアジェンダに固定で入れます。

• 黄：予兆が出た。次の一手は実行されているか

• 赤：作戦を変える。スコープ・期限・品質・体制のどれを動かすか

リスクは一覧で眺めるより、黄と赤の行動を決める方が価値が出ます。

2）変更管理のタイミングで必ず更新する

要求追加、仕様変更、スコープ調整。
この瞬間が一番リスクが増えるのに、リスク表が更新されない現場が多い。

だから固定します。

• 変更が承認されたら、同時にリスク1行を追加または更新する

• 変更理由が期限赤を呼ぶなら、状態を黄または赤に上げる

• 変更が受容なら、受容条件を明記する

変更管理とセットにすると、リスクレジスタが現場の意思決定ログになります。

3）リリース判定で赤をゼロにしない

ここが一番重要です。
赤リスクをゼロにしてからリリース、は現実的ではありません。無理にゼロにすると、嘘になります。

やるべきは、赤の受容条件を明文化することです。

• 赤を受容するなら、どの障害レベルまで許容するか

• 監視と初動をどうするか

• 影響範囲はどこまでか

• 誰がどの判断で止めるか

赤をゼロにするのではなく、赤を扱える状態にする。
これが運用としての成熟です。

状態判定をブレさせない：黄と赤の定義を固定する

リスクが形骸化する現場は、状態の判定が空気になります。
だから判定基準を文章で固定します。複雑にしません。

• 緑：予兆なし。次の一手は不要

• 黄：予兆あり。次の一手が決まっていて実行中

• 赤：影響が現実化し始めた、または次の一手だけでは止まらない

この赤の定義が重要です。
赤は危険というラベルではなく、作戦変更のトリガーです。

以前の記事で書いた赤信号の考え方と揃えると、さらに回ります。

• 期限：遅延幅が赤に入った

• 品質：検出タイミングが遅い致命が出た

• 合意：未回答がクリティカルに残った

このどれかに接続できると、リスクは数字と判断に変わります。

よくある失敗：対策が抽象で終わる

リスクの対策欄に、注意する、注視する、連携する。
これが並ぶと、リスク表は祈りの書になります。

対策は次の一手に落とします。書き方はテンプレ化するとラクです。

• いつまでに：日付か期限

• 誰が：オーナー1人

• 何を：成果物で表現

• どこで確認：会議名かチャンネル

例）

• 3/8までにPMが、テストデータ提供の未回答を回収し、提供可否と期限をリスク表に追記。週次で確認。

これだけで実行率が上がります。実行率が上がると、リスクは生きます。

3種類のリスクを分けると運用が軽くなる

さらに軽くしたいなら、リスクを3種類に分けます。
全部を同じ棚で回そうとするから重い。

1）プロジェクトリスク

遅延、品質、体制、合意。PMが主に扱う。

2）技術リスク

性能、移行、セキュリティ、未知。開発リードが主に扱う。

3）運用リスク

監視、障害対応、問い合わせ、夜間体制。運用責任者が主に扱う。

リスクレジスタは1枚でも、オーナーが違えば扱いが変わります。
最小RACIの記事と同じで、Aやオーナーが曖昧だと決まりません。

明日から回すための手順

最後に、明日から始める最短手順を書きます。
全部やらなくていいです。順番だけ守ると回り出します。

1. 列を絞る（予兆、次の一手、状態、オーナーは必須）

2. 黄と赤だけ扱うと決める

3. 週次進捗会議に黄赤の確認を固定で入れる

4. 変更管理が起きたら必ず1行更新する

5. 赤はゼロにしない。受容条件を明文化する

これができると、リスクレジスタは現場の安心に変わります。
リスクが減るからではなく、扱えるからです。

最後に問い

あなたの現場のリスク表は、今どこで止まっていますか。
登録がゴールになっているのか、更新がないのか、それとも意思決定に繋がっていないのか。
一番詰まっているのはどれでしょうか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！

個別に整えたい人へ（キャリア相談）

僕は普段、30代エンジニアのキャリア停滞を抜け出す支援をしています。
現場の詰まりをほどいて、評価・役割・選択肢を整えるために、状況を一緒に棚卸しできます。

▼相談はこちら（ココナラ）：