本連載では、本来身近なはずのリスクマネジメントをシステム開発の現場でも生かすための方法論を探ります。リスクマネジメントでは、その対策をいかにして講じるかが勘所になりますが、簡単なことではありません。第4回、第5回と2回にわたり、リスクマネジメントの対策の実際について見てきました。今回は、検討はしたけれど、実行には移さなかった対策がどのような意味を持つかということについてお話します。

これまで話しましたように、実際にリスクを抑止していく際は、技術系と人間系の対策を最適に組み合わせていくわけですが、中でも最も留意が必要な対策があります。それは「やらなかった対策」です。

逆説的な表現で違和感があるかもしれませんが、リスクマネジメントの世界においては、よくこのように言われています。

「対策を講じなかった」ということは、「そのリスクを受け入れる判断がなされた」ということになります。広義でのリスク対策には、この「リスク許容」選択肢として含まれます。例えば、「関東と関西で同時に震度7の地震が発生した場合、データセンターが機能不全になってもやむを得ないと判断し、新たに北海道にバックアップセンターを構築するようなことはしない」というのもリスク許容の一例です。

システム開発の現場においては、構築されたシステムが外部からのクラッキングやオペレーションミスなどによる情報漏えいのリスクにさらされる可能性があります。エンジニアにとっては、こうしたリスクが洗い出された以上、それに伴う対策を先述の2つの視点から列挙し、システム開発を求めている顧客と発注者に判断を仰がねばなりません。これを行っておかないと、後で顧客から「そんなリスクは当然抑えるのがシステム開発担当の役割だ」と言われ、工数面でもコスト面でも後手に回ることになってしまいます。

このようなお互いの不幸を避けるべく、リスクを許容すべきか否かについての判断材料の提供は、情報システム設計の早い段階で並行して実施し、発注者との合意形成を十分にすべきでしょう。

執筆者プロフィール

坂井司 (Tsukasa Sakai)
株式会社JSOL
ITコンサルティング・技術本部　情報技術戦略部　部長

『出典:システム開発ジャーナル Vol.2(2008年1月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。