システム開発のリスク管理表はどう使う？兆候・担当・次の判断を一件で追う方法

リスク・兆候・発生済みの課題を分ける

リスク管理表は、将来起こり得る困りごとを記録し、起きる前の確認や対応へつなげるための表です。本稿では、開発や業務へ悪い影響を与える可能性を扱います。今の事実と、そこから起こり得る出来事を分けると、何を確認すべきかが見えます。

リスク：これから起こり得る出来事

在庫側の仕様が決まらないまま連携を作り、後で項目を作り直す可能性です。この記録では、その手戻りはまだ起きていません。

兆候：注意して見る、今の事実

確定版の仕様書をまだ受領していないことです。将来の手戻りを考える手がかりですが、これだけで手戻りの発生や原因が確定したとは言えません。

課題：すでに起きており、対処が必要なこと

別の試験取込で品番欄が空になり、試験データで部品を特定できないことです。将来の発生確率を付けるより、記録を保ち、どこで空になったかを調べる必要があります。

同じプロジェクトにリスクと課題があっても、同じ出来事とは限りません。「仕様が来ないため、試験の品番が空になった」と因果関係を足さず、それぞれの資料と確認結果で扱います。本当に追っていたリスクが発生したと分かった場合には、元のリスクと発生記録を対応させますが、この架空例ではその対応は確認されていません。

IPAの「ITプロジェクトのリスク予防への実践的アプローチ」は、ユーザー側と開発側が、起こり得る出来事とその要因を分けて予防する考え方を扱っています。2013年のアーカイブで、発生確率や発生後の対処をすべて説明する資料ではありません。本稿の記録例や調査手順は独自の架空教材です。

仕様書が届かない一件を、判断できる記録にする

「連携が心配」「仕様書を催促する」だけでは、返答を受けた人も何を決めるか迷います。まず、対象を部品在庫サービスとの連携部分に絞ります。訪問日程システム全体を、理由なく一括で停止・承認する記録にはしません。

このつながりを残す理由は、在庫の項目を技術的につなげるだけでなく、訪問前に必要な部品を判断する仕事へ影響するからです。実際の遅れや損失額は分かっていません。影響の大きさを決めるには、業務責任者に、どの手配や確認ができなくなるかを説明してもらいます。

「誰かが確認中」から、役割が分かる書き方へ

この記録の担当案：発注側の業務担当が在庫側窓口へ確認、開発側担当が受領版を照合。次に聞くこと：品番・在庫数・更新時刻の意味と確定予定日を確認する。判断する時点：設計の当該連携部分を確定する前です。

発注側は、在庫側の窓口から資料と回答を受け取る役割を担います。開発側は、受領した項目の意味が、連携の設計案と合うかを説明します。例えば「在庫数」が訪問のための手配判断に使える数字か、「更新時刻」が何の更新を表すかは、言葉の見た目だけでは決められません。これらは確認する問いであり、この教材で特定の製品仕様を決めたものではありません。

実際の案件では、役割名だけで引き受ける人が分からなければ、各窓口と確認する人を特定します。管理表の記入者が、参加していない技術会議の結論まで推測して埋める必要はありません。会議で変わった点を、設計や業務を説明できる担当から受け取り、対応する資料へ結びます。

資料の受領と、設計を決める判断を分ける

発生前の対応案：確定まで当該連携部分を保留し、受領版と設計案を同じ項目で再照合。仕様書を受け取ったという連絡だけで保留を解除せず、何の版を受け取ったか、その版で品番・在庫数・更新時刻の意味が説明できるかを照合します。

この例では、二つの記録に対応する原資料の版は未確認です。影響額・日数も未確認、発生確率も未確認です。空欄をゼロや「問題なし」に置き換えません。自社に評価基準がある場合はその根拠と使い方を確認しますが、分からない数値を作って優先順位の根拠にはしません。

図で、仕様待ちと試験の空欄を見分ける

見る前の問い：今必要なのは、仕様書を受け取って設計を決めることですか。それとも、すでに空になった品番の記録から、どの段階を調べるかを決めることですか。図では、別々の記録として、使う資料と確かめる相手を見ます。

解説図を原寸で見る

図から読む判断：仕様待ちのリスクでは、確認する項目と判断時点を明らかにし、確定版と設計案の照合へ進めます。試験の課題では、試験入力・変換・取込結果を調べ、空欄が生じた箇所を探します。二つを一本の原因と結果の矢印でつなぐことはできません。

次の行動：発注側の業務担当は、在庫側の回答と、開発側の設計上の説明を、同じリスクの記録へ戻します。試験の課題は別の記録にして、開発側と部品照合の担当が再試験の前提をそろえます。どちらも「担当へ連絡した」だけで完了にはしません。

品番が空になった別の課題は、調査と再試験を追う

この課題に結び付く、将来起きるかもしれない別の出来事は未確認です。推測で埋めず、まず発生した空欄と調査対象を記録します。また、この課題についての発生前の対応は未確認であり、在庫仕様の受領待ちへの対応を流用しません。

この記録の担当案：開発側担当が試験入力と取込結果を確認、発注側業務担当が部品照合条件を確認。次に調べること：どの入力・変換・出力の段階で空になったか。確認する時点：該当試験の再実施前です。

1. 元の試験入力と取込結果を残す。同じ試験を指していることが分かるよう、使った入力、対象の版、操作や実行条件、空欄を確認した結果を開発側にそろえてもらいます。この教材にはその実値や版の記録はありません。
2. 入力・変換・出力を分けて確かめる。入力の時点で品番がないのか、変換の途中で扱いが変わったのか、取込結果への反映で空になったのかを調べます。どこに原因があるかを先に決めません。
3. 期待する結果と再試験条件をそろえる。発注側は試験データで何を使って部品を特定すべきかを説明し、開発側は対象の修正や確認方法を説明します。同じ条件で結果を見られるようにしてから再試験します。入力値を別の値へ変えて通っただけで、元の問題が解消したとは扱いません。

修正が入った場合には、その修正確認に加えて周辺への影響も相談します。どの仕事を先に再確認するかは、修正後の回帰テストの優先順位と確認範囲で詳しく扱っています。ここでは、まだ修正や再試験を行った結果はありません。

定例では、更新の有無より変わった前提を聞く

定例のたびに「更新はありますか」と聞くと、「確認中です」という返答だけが増えがちです。リスクの記録を開き、前回の未回答と、次に判断する連携部分を見ながら話します。会議の回数や資料の枚数より、設計と業務の判断を変える情報を集めることが目的です。

• 原資料：在庫側から何の資料・版が届いたか。確定版か、検討中の下書きか。
• 変わった内容：品番・在庫数・更新時刻について、前回の質問のどれに答えが出たか。未回答は何か。
• 兆候と影響：資料が届かない状態や前提の変更が続いているか。どの設計や部品手配の判断へ影響するか。
• 次に動く担当：在庫側へ聞く人、設計案と照合する人、業務への影響を判断する人が、それぞれ何を確認するか。
• 判断する時点：当該連携部分の設計を確定する前に何をそろえるか。間に合わない場合、誰へどの未回答を説明するか。

技術的な会議へ毎回入れない担当でも、決まった項目と未回答、根拠資料、判断へ与える影響を受け取る形は相談できます。「会議で合意済み」とだけ記録せず、どの問いがどの回答で閉じたのかを説明してもらいます。会議へ出ていない関係者にも伝わる書き方を確かめる観点は、IPAの旧資料「ITプロジェクトの見える化」中流工程編の、リスク記録を確認する箇所も参考にしました。

管理表を埋める担当と、仕様を説明する担当、保留の見直しを決める責任者は同じとは限りません。記入者に判断を押し付けず、回答できる人へ問いを渡し、判断できる人へ未回答と影響を返します。

回答あり・一部だけ・未回答で次の行動を変える

次は、これから返答を受ける場合の進め方です。この架空案件で実際に返答や対策の成功を確認した記録ではありません。回答の種類に応じて、保留する範囲と次に調べることを変えます。

• 確定した仕様書と必要な回答が届いたら

  受領した資料の版と、どの質問への回答かを記録します。開発側は、品番・在庫数・更新時刻の意味と、連携の設計案の対応を示します。発注側は、その意味で訪問前の部品手配を判断できるかを確かめます。

  次の判断：必要な項目が説明され、設計案への反映と読み合わせができた範囲で、責任者が保留を見直します。「ファイルが届いた」という事実と、「設計を確定できる」という判断を分けて残します。

• 一部だけ回答が来たら

  回答のある項目と、更新時刻など未回答の項目を分けます。開発側に、未回答がどの設計へ影響するかを説明してもらい、確定できる箇所と保留を残す箇所を整理します。例示した項目が実際に回答済みだという意味ではありません。

  次の判断：必要な前提が残る範囲は保留を維持します。残る問い、答える窓口、次に判断する時点を更新し、回答済みの箇所まで毎回同じ催促に戻さないようにします。

• 回答がないまま判断する時点が近づいたら

  「確認中」のまま予定を過ぎさせず、未受領の資料、未回答の問い、確定できない設計、想定する業務への影響をまとめます。発注側の責任者と開発側へ、何を決める必要があるかを説明します。

  次の判断：連携部分の保留を続けるか、範囲や進め方の見直しを検討するかを相談します。この例で代替方式や追加費用が合意された事実はありません。回答が来なかったことを理由に、未確認のまま確定した扱いにしません。

誰が保留を見直し、何が残れば追跡を続けるか

リスク管理表の行を更新しただけで、リスクがなくなるわけではありません。仕様と設計の照合ができたか、関係者が残る前提を理解して判断したかを確かめます。この二つの記録の対応後の結果は未確認です。対応案を書いたことを、実施や解決に置き換えません。

1. 今回の判断の根拠を残す。何の資料・版と回答を用い、どの連携部分を確定または保留したか、判断した責任者と残る条件を記録します。
2. 未回答を次の行動へ戻す。資料が不足する場合は、答える相手、次に確認すること、設計を決める前の確認時点を明らかにします。終わった質問と未回答を混ぜません。
3. 発生済みの課題は結果で確かめる。試験の空欄は、原因の説明だけでなく、合意した条件で期待する部品照合ができるかを再試験で確認します。結果を得るまでは解決済みにしません。
4. 前提が変わったら記録を見直す。仕様の版や連携範囲が変わったときは、前の照合結果がそのまま使えるかを確認します。新しい版を受け取っただけで、すべての判断を引き継ぎません。

未発生リスクを閉じる際にも、単に「連絡済み」ではなく、どの懸念がどの確認で扱えるようになったかを示します。残る不確実さを引き受ける場合は、記入者の独断で「問題なし」にせず、権限を持つ責任者が影響と残る条件を理解して判断する必要があります。

まとめ：一件の記録を、確認する人と次の判断へつなぐ

リスク管理表は、列を埋めたり更新を催促したりすることが目的ではありません。設備保守会社の例なら、在庫側の仕様書が未受領という事実から、将来の連携の手戻り、訪問前の部品手配への影響、品番・在庫数・更新時刻の質問、担当、設計を決める前の照合までを一件でつなぎます。

すでに起きた試験の品番空欄は別の課題として、入力・変換・取込結果を調べ、再試験条件と結果を追います。二つの記録を混ぜず、分からない版、費用、日数、確率、対応結果は分からないまま、次に確かめる相手と行動を具体化します。