ITシステム開発・運用のリスク管理

# あたりまえすぎる話や知識として特に新しくないものは省略

• リスク管理の最初のステップは，管理すべきリスクを決定すること．
  管理するリスクが明確になっていないと，人も割りあたらないし，対策もはじまらない．
• リスクの構成要素
  • リスク イベント（実際におこる事象）
  • 発生確率
  • インパクト
  常にこの3つの要素で把握する必要がある．イベントだけ，あるいはインパクトだけを声高に主張するのは逆効果．オオカミ少年になってしまう．必ず，何がどんな確率でおこるか，おこったときの被害がどの程度かを冷静に記述しないと，だんだん信用されなくなってくる．
• リスク イベントを記述する際は，｛When（いつ），What（何が），How（どのような，どの程度）｝の情報を含める．
  • リスク イベントは，発生したかどうかが誰にも明確にわかる表現にする．
  • リスク イベントを検知するタイミングも工夫の余地がある．
    例：「納期直前に遅延が判明する」と書けば，何かしらもっと早いタイミングで検出する方法が必要なことがわかる．
  • before/afterを考えてみる．そのイベントが起こる前と起こったあとで，何がどうかわるか考えてみる．
  • 対策しないリスクを決める．
• リスク イベントからすぐに対策を考えず，(a)リスク イベントの特定→(b)ドライバー（誘因）の特定→(c)対策の立案とする．対策はイベントそのものではなく，そのイベントを生じさせている真因の方に働きかけるものになっていないと効果的な対策にならない．
• ドライバー（誘因）は「意識」＋「行動」の形式で書く．
  例：顧客は，自分たちの仕様決定が遅延した結果，後続の工程が遅延することについて自分たちの責任であるとの認識が低く，最終的には納期を守るよう迫ってくる傾向がある．（意識「自分たちの責任であるとの認識が低く」＋行動「納期を守るよう迫ってくる」）
• イベントではなくドライバーに対して対策をとる．
• イベントが発生するタイミングと対策をとるタイミングは異なる．

リスク対応の種類

• avoidance （回避）
• mitigate （緩和）
  • コントロールして発生確率を下げるbefore対策と，起こったときのimpactを下げるafter対策がある．
• acceptance （受容）
  • インパクトが小さければ，特に対策をせず受容（accept）することもありうる．
  • 対策するより受容した方が安い場合は受容でよい．
  • 営業政策上「今回は貸しをつくる」というパターンも受容にあたる．
• transfer （転嫁）
  • 契約などで責任範囲を変更し，リスク（リスク管理・対応）を他者にまかせることもある．例えばお金を銀行に預けるとか，施設管理を警備会社に依頼するなど．
  • 責任には，損害そのものの責任と管理責任がある．転嫁を採用した場合でも，管理責任が問われる場合があることに注意．

リスク対応の留意点

• afterの対策にはbeforeの準備が必要なため，実際にはafter対策であるにもかかわらず，before対策だと思い込んでいる場合がある．
  例：消火器を用意しておく．
  消火器は火災が起こった場合のafter対策だが，消火器を購入・設置するのは火災が起こる前であるため，before対策だと誤解されやすい．消火器があっても火事を防ぐこと＝回避（avoidance）はできず，火災の被害を緩和（mitigate）する程度の効果しかない．
• ドライバー（誘因）が原因でイベントが起こる．
  • avoidance，mitigate はドライバーに働きかける．
  • acceptance は impact を accept する．
• タイミングにはイベントの発生タイミングと判断のタイミングがある．通常は，イベント発生を契機にしたくはなく，それより前に判断タイミングを設定する．
  例：納期遅れの場合，納期期日をタイミングにせず，毎週の工程会議などを判断タイミングにする．
• 具体的に何をすればよいかがわからないものは対応策として機能しない．例えば…
  • ×コミュニケーションを密にする→○週1回のミーティングを週3回に増やす
  • ×フォローを強化する
  • ×レビューを強化する
  • ×教育する
  • ×ミーティングを開く→○ミーティングで△△を決定する
  • ×納期遵守を徹底する（だいたい「徹底する」はアカン傾向…）

その他

• メンバーの本音は業務時間外に聞こえてくる
  やりたくないけど，絶対にイヤというわけでもなく，仕方ないと割り切っている部分もある．このようなものは業務時間内の打ちあわせなどではすくいきれないことが多く，何かしら「諜報活動」的なものが必要．最近は あまり好まれないけど，飲み会とかタバコ部屋とかゴルフとか…そんな感じかも．
• Weak Link
  • 開発プロセスの中の各工程・作業項目の中で外注に出している作業と関連をもっているためにリスク管理が弱くなっている部分のことを Weak Link という．
  • 外注してもリスクがなくなるわけではない．リスクの管理主体がかわるだけ．逆にいえば，リスクが見えにくくなる，管理レベルが落ちるという問題点がある．
  • 外注に出す際に，外注先に直近3か月の退職率と退職理由を教えてもらうとか，どんな研修を施しているかなどの情報を聞くことで相手先の管理レベルを推定するよう努める．
• 参考 Fault Tree Analysis （FTA 分析）