楽しいリスク分析――熊とワルツを踊るように 【その3】ソフトウェア開発版「災害発生時の対策」：山浦恒央の“くみこみ”な話（67）（1/3 ページ）

ソフトウェア開発プロジェクトで、リスク管理は大変重要ですが、きちんと実施している組織はほとんどありません。今回は「リスクの発見」を復習し、リスク管理の手順を解説します。

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），MONOist]

　ソフトウェア開発プロジェクトで、リスク管理は大変重要ですが、きちんと実施している組織はほとんどありません。リスク管理の最大の利点は、「実際に問題が起きた場合に、冷静に対処できる」ことです。事前にリスクを洗い出し、対応策を決めておくことが非常に重要です。今回は、前回（楽しいリスク分析――熊とワルツを踊るように【その2】「高校野球の頭脳プレー」と「ソフトウェア開発のリスク発見」）述べた「リスクの発見」の復習をし、残りのリスク管理の手順を解説します。

「リスクの発見」　リスク管理で圧倒的に重要なステップ

　リスク管理の最初にして最も重要なステップが「リスクの発見」です。これは、以下の手順で進めます。

• 1　ショー・ストッパーの列挙

　ショー・ストッパーは、リスク管理での頻出用語で、演奏や芝居のようなショーを即中止に追い込む致命的な問題をいいます。これには対策がなく、プロジェクトは直ちに解散へ追い込まれます。

　ソフトウェア開発は、特定のハードウェアを制御するために開発しますが、例えば、ソフトウェアの制御対象となるハードウェアを設計・開発している会社が倒産すると、ソフトウェア開発プロジェクトは存在意味がなくなり、即解散となります。また、自分たちが開発しているソフトウェアより、はるかに高機能、高性能、低価格のものを半年以上早く、別会社がリリースした場合も同様に、プロジェクトは中止になります。

　ショー・ストッパーが多く存在し、その発生確率が高いと、ソフトウェア開発は、エンジニアリングではなく、ギャンブルになります。

　この段階では、過去の事例から、ショー・ストッパーを列記しますが、リスク管理をキチンと実施している組織には、既に「ショー・ストッパー」一覧があるはずです。

• 2　常連リスクの列挙

　世界中のソフトウェア開発プロジェクトに起こり得る常連リスクを列挙します。

　ソフトウェア開発での「リスク四銃士」として、「エース級エンジニアの離職」「仕様が確定しない」「見積もりの精度が（安易な方向に）低い」「開発契約が締結されなかった（注1）があります。

　この「常連リスク」も、リスク管理の書籍や、Webサイトを見れば掲載されていますし、組織内でリスク管理に取り組んでいるなら、既に列記済みのはずです。

　注1意外に多いのが、契約締結前の「見切り発車」による開発です（私の想像では、ソフトウェア開発の2、3割がこの状態ではないでしょうか？）。毎回、正式な契約締結まで3〜4カ月もかかる組織では、締結するまで開発しないなどという悠長なことはしません。契約締結を前提に、両者の当事者同士が頻繁にミーティングし、要求仕様を決め、設計書を書き、コーディングまで突っ走ることも少なくありません。で、契約の条件が折り合わなかったり、相手側の財政状態が悪化したり、社会的な状況が変化すると、契約は物別れに終わり、タダ働きという悲惨な状態になります。

• 3　組織固有のリスクの列挙

　　会社固有のリスクも少なくありません。例えば、第1バージョンが完成すると、第2バージョン（保守）のために何人かを残して、プロジェクトは解散するのが普通ですが、第2バージョンがあるかどうか1年以上経過しないと判明しない場合、保守要員を確保しておく余裕がないと、プロジェクトは完全に解体される場合が多いようです。で、1年後に第2版を開発することになったとすると、保守がうまく行かないリスクが発生します。

　会社固有のリスクも、リスク管理に取り組んでいる組織なら、既に列挙済みでしょう。

• 4　プロジェクト固有のリスクの列挙

　開発しているプロジェクト、および、開発している製品に特有のリスクです。例えば、プロジェクト要員が2派に分かれて対立し、表向きは両派が協力して開発しているように見えますが、裏では足の引っ張り合いをしているなど、政治的な問題も少なくありません。

　この「プロジェクト固有のリスク」は、プロジェクトマネージャーが列記する必要があります（とはいっても、半日でできそうです）。ただし、バージョン2以降であれば、第1バージョンのリストに追加すればよいだけなので、大した作業にはなりません。