DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

世の中は自然災害やテロ行為が頻発、アメリカ大統領選でのトランプ現象など、ますます先行き不透明感が増してきているように感じます。そんな中で、ＢＣＰ（事業継続計画）に関する標準化も進んで、各企業ともＢＣＰに力を入れていることと思います。（※１）

さて、ウィキペディアの事業継続計画の説明に「コンティンジェンシープラン（緊急時対応計画）」というものが登場します。この「コンティンジェンシープラン」は、システム開発プロジェクトの現場でもカットオーバーが近づくと話題にのぼりますよね。。。

【　コンティンジェンシープランとは何か？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まずは一般的なコンティンジェンシープランの定義を確認します。IPAから公開されている『対サイバーテロ・コンティンジェンシープラン立案の研究』には、次のように記載されています。（※２）

コンティンジェンシープランとは、その策定対象が潜在的に抱える脅威が万一発生した場合に、その緊急事態を克服するための理想的な手続きが記述された文書である。

要は、何か緊急事態が発生したときにとるべき対応計画といったところでしょうか？たとえば自然災害が発生したときやサイバーテロなどに襲われたときに、どう対応するかあらかじめ決めておいて、実際に起きたときにもあわてないようにするといった感じでしょうか。

私がこのことばをはじめて聞いたのは、西暦2000年（Y2K）問題への対応のときです。1900年代に構築された古いシステムは、日付のデータ項目として西暦下２けたしか持たないこともあり、プログラムで上２桁を「19」固定としてみなして処理することで、1999年と2000年（⇒1900年と見なされる）が逆転してしまい、システムが誤動作するリスクがあるというのがY2K問題です。（※３）

もちろん、西暦2000年を迎える前にシステムで日付を扱っている箇所を全て洗い出して、上記のような問題が発生する箇所が無いかをしらみつぶしに確認・対応し、システム日付を2000年に設定したシミュレーションテストを行うなど万全を期すのですが、それでも対応漏れがあった場合に企業活動や社会への影響が懸念されました。そのため、何か不測の事態が発生しても、すぐに対応できるように、西暦1999年の年末、2000年の年始には、お客様の事務所に出勤して待機したのです。

年末年始はお客様の業務は基本的にお休みなので、何か緊急事態が発生する可能性はあまり考えられなかったのですが、システム提供ベンダーとしてできるだけのサポートをする姿勢を示すためにも交代で年末年始の待機を行ったのです。このような待機についても、Y2K問題対応のコンティンジェンシープランの一環だったわけです。

このときは、案の定何も起きなかったので時間を持て余していましたが、たまたまお客様の事務所が、正月恒例の箱根駅伝のコース近くだったので、１月２日の往路、１月３日の復路とも、選手が近くを通る時間に少し抜け出して、母校を応援したことを今でも鮮明に覚えています。苦しいことが多いシステム開発プロジェクトの現場にいる中でも、少しでもそういう楽しい思い出が残っていることが、今でもプロジェクトの現場に居続けるモチベーションになっているのかな、なんて思いです。。。（※４）

【　プロジェクトにおけるコンティンジェンシープランとは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
実は、当ブログの　【第３４回】カットオーバー・クライテリアとは何か？　にも、コンティンジェンシープランは登場しています。カットオーバー・クライテリア（本番稼働判定基準）のひとつとして、「新システムへの移行・本番稼働に際し、不測の事態が発生した場合の対応計画（コンティジェンシープラン）が明確であること」という判断基準が含まれています。

新システムを導入する組織にとって、新システムの本番移行が失敗すると、新システムを利用することを前提に考えていた事業が計画通りに実施できなくなり、それどころか今までやっていた事業が継続できなくなるリスクがあるため、たとえ新システムへの移行が失敗したとしても、事業への影響を最小限に食い止める施策を事前に考えておく必要があり、その対応計画のことをコンティンジェンシープランと呼んでいます。

そのため、システム開発プロジェクトにおけるコンティンジェンシープランは、システム移行計画とセットで検討されることが多いはずです。

なお、新システムへの移行が失敗するリスクの発生確率や、仮に移行に失敗した場合の事業への影響については、システム開発に本格的に着手する以前のシステム企画段階で検討しておく必要があり、その検討結果もそのプロジェクトに着手すべきかどうかという経営判断の材料とすることが求められます。（※５）

【　何が違う？コンティンジェンシープランとリスク発生時対策　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここで、プロジェクトマネジネト研修を受けてきたばかりの新人Ｐ子さんが何かにひっかかっているようです。

＜新人Ｐ子さん＞　：　「うーん、「移行が失敗するリスクに備えたコンティンジェンシープラン」って表現、なんかひっかかるわ！そもそも、プロジェクトのリスクのひとつとして移行が失敗するリスクもあって、それはリスク管理表で管理してて、その発生時対策も他のリスクと同じ感じで定義してあるはずでしょ？なんで、移行が失敗したときの発生時対策だけコンティンジェンシープランなんて呼び方をして、特別扱いする必要あるの？」

＜ベテランＰＭのM男氏＞　：　「ふん！なまじPMBOKだとか、なんだとか、横文字を使いたがるからそんなことになるんじゃ！リスクだとか、コンティンジェンシーだとかわけのわからんことに時間かけずに、目の前の作業や課題に集中して、プロジェクトを先に進めればいいんじゃ！とにかく、前に進まんことには何も始まらんのじゃ！」

―――　ひとまずＭ男氏の話はスルーするとして、Ｐ子さんは良いところに気が付きましたね。プロジェクトに内在する不確実性の一つとして、「新システムへの移行が計画通りに進まないリスク」も他の「仕様変更多発リスク」や「品質リスク」などと同じように管理すれば良いのではないか、という考え方も自然ですよね。

確かに、PMBOK第５版には、コンティンジェンシープランに関して、次のように記載されているのです。（※６）

11.5.2.3　コンティンジェンシー対応戦略
リスクの中には、そのリスク対応計画を実行するまでに十分な予兆があると考えられる場合、プロジェクト・チームは予め定義された特定の条件下でのみ実行する対応計画を作成しておくことが妥当である。（中略）この技法を用いて特定されたリスク対応策は、コンティンジェンシー計画あるいは代替計画とも呼ばれ、この中には計画を実施するために特定された誘因となる事象が含まれる。

そして、当ブログの　【第２７回】「既知の未知」と「未知の未知」に備える！　で登場した「コンティンジェンシー予備費」は、プロジェクトの「個別リスク」に対する予備費用のことでした。

つまり、プロジェクトにおけるコンティンジェンシープランは、プロジェクト・リスクの発生時対策と同義であると言っても間違いでは無いのです。むしろ、PMBOK第５版に忠実な用語を使うならば、移行以外のリスクの発生時対策のこともすべてコンティンジェンシープランと呼ぶのが正しいかもしれません。

では、なぜ、移行が失敗した場合の発生時対策を特別扱いするのでしょうか？

もうすでにお気づきの方も多いと思いますが、移行が失敗するかもしれないリスクは、システム開発のプロジェクト目標に影響を与えるかもしれないリスクであると同時に、システム開発を行う組織の事業継続に影響を与えるかもしれないリスクでもあるのです。「プロジェクト目標の達成」と「事業継続」の二つがリスクの対象となっていて、後者の事業継続に影響を与えるかもしれないリスクが顕在化したときの対応計画のことをコンティンジェンシープランと呼んでいることが多いのです。

当ブログの　【第１７回】それは誰のリスクか？　では、発注側と受注側のプロジェクト目標が異なる可能性があることから、抽出されるリスクやリスクへの対応計画が異なることを考察しました。これと同じように、個別のプロジェクト目標達成に向けたリスクなのか、もう少し大きな視点で事業継続に対するリスクなのかで、リスクへの対応計画が異なる可能性もあるのです！

もちろん、プロジェクト目標の達成と事業継続は密接な関係があるので、どちらをリスクの対象とみなしても、対応計画があまり変わらないということもあります。しかし、この辺の違いをしっかり理解できているかいないかで、コンティンジェンシープランを含めたリスク対応計画が的を得たものになるかどうかが分かれてくるとこいうことを理解しておく必要があるのです。

個別のプロジェクトにおいては、この辺の混乱が起きないように、事業継続に対する発生時対策を特別にコンティンジェンシープランと呼び、それ以外のプロジェクト目標達成に向けたリスク顕在化時の発生時対策とは区別するなど、しっかりとそれぞれの用語を定義したうえで、使いわけることが求められます。（※７）

「リスクの対象が、プロジェクト目標達成か、
事業継続かを意識して対応計画を考えよう！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　ＢＣＰ（事業継続計画）については、以下参照。
・「事業継続計画」『フリー百科事典　ウィキペディア日本語版』
2016年9月29日 (木) 00:40 UTC　https://ja.wikipedia.org/wiki/事業継続計画

※２　IPA情報処理振興事業協会(2000)『対サイバーテロ・コンティンジェンシープラン立案の研究』https://www.ipa.go.jp/files/000003132.pdf

※３　Y2K（西暦2000年）問題については、以下参照。
・「2000年問題」『フリー百科事典　ウィキペディア日本語版』
2016年11月7日 (月) 13:24 UTC　https://ja.wikipedia.org/wiki/2000年問題
なお、当ブログの以下の回では、2030年問題について触れています。
・【第８０回】２０３０年　プロジェクトマネジメントの旅

※４　箱根駅伝については、以下参照。写真は日付も場所も当時のものではありません。
・「東京箱根間往復大学駅伝競走」『フリー百科事典　ウィキペディア日本語版』
2016年11月19日 (土) 03:44 UTC　https://ja.wikipedia.org/wiki/東京箱根間往復大学駅伝競走

※５　一般的なシステム企画書の目次例については、竹内博樹氏『PM＋BAの実践講座』の以下の回を参照してください。
・【第２１回】システム企画書を完成させる！　ＩＴ化の構想・企画段階における“Ｈｏｗ”の明確化で仕上げ。

※６　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※７　プロジェクト・リスクについては「リスク」のタグ付されている回も参考にしてください。
・新感覚プロジェクトマネジメント > リスクの記事一覧