10年に一度の大雪をモデルで考えるプロジェクトのリスクマネジメント

金曜日から「金曜の深夜から雪降るよ！」ってTLに情報が流れていましたが、まぁ、しかしこれほど積もるとは想定をしていませんでしたね。TLを追いかけていたわけでも、天気予報も見ていなかったとはいえ、雪が降るよ＝10cmも降らんだろーって思ってましたから。

実際、蓋を開けてみれば、40年ぶりくらいの大雪だった、わけで。

で、この大雪がプロジェクトに与えるリスクだとするならどうしたことがリスクとして想定されて、どうしたことが対策として取れたか、と言うことを整理するのも面白いかな、と。

プロジェクトに与えるインパクトはいつでも同じではないよ
大雪が降ることで、一体どのようなインパクトがプロジェクトに影響するのかを考えると、すぐに思いつくのは計画した作業の出来高が得られないことです。ただ、どの工程であっても何等かの作業はしているわけで、出来高が無いわけはないんです。そう考えると、対象となる作業の機会がファクターになりそうです。

では、その機会に重要度がある作業はどの工程でしょうね。

プロジェクトのインパクトはいつ起きるかで変わるんだよ
プロジェクトのどの工程でも構いませんがどの工程に大雪が降ったときにインパクトがあるかを考えます。要件定義、基本設計、詳細設計、開発構築、単体試験、結合試験、総合試験、移行のどの工程でソレが起きたらインパクトがあるか。要件定義から始まって移行の作業でプロジェクトは開発フェーズを終えるんです。そこで一旦区切りをつける。プロジェクトは終わりがあるものですから。

そう考えると、わかりやすいですね。総合試験まではたとえ進捗が終わらなくても次工程に申し送りという技が使えるんですね。「次工程で終わらすことを約束するから先に進めさせて！」と。そう考えると、移行はその次が無いのですから。例え予備日をスケジュールとして確保していても限界があるものだし、移行日に稼働することで他のシステムと接続するなどと言う場合、易々と移行日の日取りを変えることは取り巻く環境から選択しにくくなるのですね。

プロジェクトに与えるインパクトを検証する
これまでの整理で、移行のタイミングにリスクが起きた場合が一番プロジェクトにインパクトがあると導き出したわけです。では、どうしたらいいんでしょうか。今回起きては困るリスクは大雪の降雪です。

“大雪が降る→プロジェクトの移行にインパクトを与える”

これだけでは、雪が降ることでどのような影響を与えるかが不明確なので取れる対策がはっきりしません。つまり、影響を見切れて、どのようなインパクトがどう影響するか、具体的に想定できていないので本来なら取れる対策も間違えて対策してしまうこともあり得るわけです。

なのでもう少し、具体的にするんですね。

どんなふうにやるか。起きるリスクを書いてそれから起きる事象がプロジェクトにどう影響するかを具体的に“想像”していきます。

“大雪が降る→公共交通機関が乱れる→作業者が現地に集まれない→作業が始められない→移行作業がおわらない”

こうした“想像”をする作業は意外とエンジニアが苦手とすることなんですね。普段は、クラス図を描くとか、シーケンス図を描くとか、パラメータシートを書くといった具体的にゴールをイメージしやすい作業ばかりだから、なんです。それはなぜかわかりますか。

大雪のようなプロジェクトにインパクトを与えるような出来事をイメージすることは、普段の作業と違います。ゴールもその過程も違います。決まった作業ではないからです。

普段の作業は、“定量的”なんです。ゴールが決まっている。作業のボリュームが見切れるんですね。一方、大雪からプロジェクトに与えるインパクトを推し量ることは、想像を働かせて想像するプロセスが入り込むので、その結果も過程も一意に導けないのです。つまり、“定性的”なんですね。

エンジニアに必要なスキルはこういった定性的な事柄に対する対処を試行錯誤しながらその評価時には適切な解を導く力をつけることなんです。