プロジェクトを危機から救う「本気のコンティンジェンシー・プラン」のススメ

コンティンジェンシー・プランは実際に発動できてこそ意味がある

こうして万全の準備を整えてシステム基盤移行と社外システム連携に臨んだのですが、嫌な予感は的中するものです。移行当日、社内システムの基盤移行は順調に進んだものの、移行作業の終盤になって社外システムとの連携に関する問題が発覚。必死の復旧を試みるも当日中の復旧は現実的に困難と判断し、用意していたコンティンジェンシー・プランを発動、切り戻し（＝社外システムとのシステム連携自体の取りやめ）をすることにしました。

いざ本番となって問題が起こると、得てして現場は混乱するものです。事実、このように社外システム連携でトラブルが発生した際は、現場にかなりの緊張が走りました。しかし、こうした問題の発生を想定して対策を練り、リハーサルを重ね、いざという時の対応人員もその場に待機させておいたことで、極めてスムーズにコンティンジェンシー・プランを発動することができました。結果としてある程度の痛みは伴ったものの、システム基盤の移行という大目的の1つについては、無事完遂することが出来ました。

こうした「いざという時の備え」は、「どうせ大丈夫だろう」「こんなレアケースは起きないだろう」という思い込みから手を抜きがちです。中には「上から言われたから、仕方なく体裁だけ整えた」というレベルの対策も珍しくないでしょう。そんな時に限って、本番では問題が起きて右往左往してしまうものです。そうならないためには、リスクに応じたコンティンジェンシー・プランを事前にきちんと検討した上で、机上の空論に終わらないようテストやリハーサルもしっかり行っておく必要があります。今回のプロジェクトで、こうした対策の重要性をあらためて強く認識しました。

リスク管理とコミュニケーション設計の質がプロジェクトの成否を分ける

ちなみに、当初は切り戻しを行った社外システムとの連携は、その後問題の原因を修正した上で移行作業を実施し、今度は移行に伴うサービス停止もなく、無事連携を開始することができました。しかし、もし社内システムと社外システムのリスク分析・対策をいっしょくたにしていたら、社外システム連携の切り戻しに引きずられて、社内システムの基盤移行までやり直しを余儀なくされるところでした。当時は冷や汗ものでしたが、プロジェクト側で品質を管理できる範囲をしっかり見定め、それぞれのレベルに応じたリスクの評価・管理・対策を行っていたことで最悪の事態を回避することができました。

また社内システムの基盤移行についても、「リクルートの全Webサービスを一斉に新基盤に移行する」という極めてリスクの高い取り組みだったにもかかわらず、大きな問題もなく無事に完了させることができました。その勝因は、技術面での検討や作り込みもさることながら、各ステークホルダーに対するコミュニケーション体制をきちんと組織だって設計したことにあると考えています。そのことによって、当初は調整が難しいと思われていた全社参加のテストやリハーサルが可能になり、各社からコンティンジェンシー・プランへの理解を得ることができたのです。

そして最後の最後でプロジェクトを危機から救ったのは、実際に発動することを前提として練りに練った「本気のコンティンジェンシー・プラン」の存在でした。失敗することを前提とした対策の検討には、誰もがあまり時間や手間をかけたがらないものですが、万が一に備えたリスク管理の質が、ときにはプロジェクトの成否を分けることになります。今回私たちがとった戦略はその一例に過ぎませんが、皆さんがプロジェクトを運営する上で何らかの参考になれば幸いです。