プロジェクトにおけるリスクマネジメント
リスクマネジメントは計画の段階から「回避」「低減」「共有」「保有」という４つの手段から検討することが求められていますが、具体的な実現方法としては大別して
・問題が起きる前にするできることは何か？（予防）
・問題が起きた場合、どう動くべきか？（対処）
の２点をそれぞれのポイントからコントロールできなくてはなりません。
どちらも大切な技術ですが、本来は前者の段階でコントロールできていることが理想です。何か起きてから後手に回っていたのでは、そのために要する時間もコストもどこかから捻出しなければなりません。そんな余剰リソース、少なくとも計画段階で見込んではいないはずです。
黒字/赤字と言う数値的結果だけで見ようとすると、こうした見えにくい部分への取組みはなかなか目につかず、評価の対象とされることはないかもしれません。
しかし、自身を含めたチームメンバー全員、およびお客さまを含むステークホルダーのことを考えるなら、リスクは顕在化させない（事故にしない）ままリスクであり続けるようにコントロールすべきなのです。
リスクが顕在化するということは、自分を含め、多くの人の人生（寿命）を無駄に費やさせるということです。規模の大きさによっては、お客さまにまで迷惑をかけてしまうことになります。
過去、苦い思いをした失敗や叱責等は、何が原因で起きたのでしょう？
それは、現在のプロジェクトにおいて同じ「原因」となり得る要素があるかどうかが１つのポイントとなります。同じ失敗を繰り返さないよう、失敗の原因(発生条件)を特定し、同じ条件を満たさないように立ち回る…これがプロジェクト活動内におけるリスクマネジメントの極意です。
つまり、今までの経験のうち、
「どれだけの失敗を経験してきたか？」
「どれだけ経験を活かして今に至ったか？」
がその人のリスクマネジメントに対する厚みをつくる…と言っても過言ではありません。
『若い時の苦労は買ってでもせよ』
と、故事でも言われていますが、大成するためには必要なプロセスなのかもしれません。そうした経験が「同じ状況を繰り返さない」ためにとても影響を与えるものだからです。
もちろん、経験なんてしなくても注意深く、失敗を回避するために最大限の努力をする…という人もいるかも知れません。ですが、多くの人たちは、経験をしていないからこそ、軽く見てしまうし、ナメてかかってしまうのですから、経験はできることならしておいた方がいいのでしょう。
また、自身が直接失敗しなくとも、トラブルに巻き込まれた等によって経験した場合も多くの知見を得るでしょう。「組織の知識」として共有されていれば、他人の経験を以ってリスクマネジメント力を向上させることも可能になります。
このニュースは今でも記憶に新しい記事ですが、これを読んで鼻で笑える人は「マネージャとしての素養がある」または「既にまともなマネージャである」と言えるかもしれません。
何故か？
BCM(Business Continuity Management)やコンティンジェンシープランの観点から言えば、組織の事業継続能力を継続的に維持・改善するためのリスク対策／リスク対応計画は、責任者の当然の責務だからです。
せめて
1. 日本は地震大国であるという前提に立って施設の設計を考える
2. 災害を想定し、原子力発電所は原則海沿いに製造する
3. プレートや地理的条件、過去の記録から、今後発生する大地震の予想マグニチュードを算出する
4. 算出されたマグニチュード+αくらいの地震に耐えられる構造設計を行う
5. 当然、海沿いで発生する地震のため、想定される津波高を算出し、対策を２重３重に用意する
くらいは普通にリスク対策として取るべきです。ただのべき論だと思いますか？国の重要施設や医療施設、昨今ではクラウドのデータセンターなどは、こういうことを当たり前のように事前調査し、対策を講じていますよ。
数百年に１回しか起きないリスクでも、起きた時の被害を想定して投資する。その意識こそが"リスクマネジメント"の基本的なあり方です。「万が一」というのは１万回に１回は起きうるという想定のもとで、リスク対策を検討する必要があるということであって、
「１万回に１回程度だったら、別に被害にあってもいいんじゃね？」
という発想をしていいものではありません。
リスクマネジメントに求められる本質は
杞憂に終わればそれが一番
杞憂に終わるために策を講じる
ものなので、「何事も起きなかったので投資したことが無意味に終わった」と言う結果こそが何よりも高く評価されます。何も対策を講じておかずに、たまたま「何事も起きなかったー…よかったー…」ではお客さまの信頼は勝ち取れません。何もしていないのですから当然です。
そして、こう言ったリスク対策の考え方は、通常私たちのシステム開発における設計にも広く利用されています。その１つがスケーラビリティ（拡張性）です。
たとえば、あるＡ社のシステムを作るとします。
• 1000人の従業員がいます。
• 現在、常時100人以上がそのシステムを使います。
• 繁忙期には200人以上(250人未満)の人がそのシステムを利用します。
• ただし、同じ時間帯に同時アクセスする人はその1/3程度です。
• 毎年、3～5%程度の割合で従業員は増加しています。
（その増加人員全てがシステムを利用するかどうかはわかりません）
と言われると、10年使うシステムであれば
ＣＰＵ負荷 ： 250 × 1/3 × 1.05の10乗
システム全体 ： 250 × 1.05の10乗
と言う計算式で10年後でも耐えられる最大人数を考慮したハード調達などを行います（"全体"には、メモリやストレージ、ネットワークのトラフィック負荷なども考慮に入れます）。想定しうるMAX値+αでも耐えられなければ、リスク対策とは言えません。
しかし、このαが大きすぎても冗長コストとなってプロジェクトや経営を圧迫するため、緻密な計算や根拠が必要になってきます。
面倒な人は、はじめは最小限しか用意しない代わりに拡張性を最大限考慮して、いつでも拡張できるようにしておく…と言った方法を取りますが、その場合でも業務や事業に支障をきたさない範囲で即時対応できる準備が必須となるはずです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。