大手IT企業にて、約30年間システム開発プロジェクトのプロジェクトマネジャーを担当していました。プロジェクトマネジャーにはなすべき業務が多くありますが、中でもリスク管理は頭を悩ませる業務の一つでした。
リスク管理に不備があった結果、システムに不具合が起きたりリリース日が遅延した場合には、クライアントの業務に大きな影響を与え自社の信頼性を失ってしまうこともありえます。
そこで今回は、重要な業務であるリスク管理のポイントについて紹介します。この記事をご覧になれば、効率的なリスク管理方法がわかりますので、実際のプロジェクト運営に活用できます。ぜひ最後まで読み進めてみてください。
目次
システム開発プロジェクトにおけるリスクとは？
リスクとは、まだ起こっていないが起こるかもしれない不確実な事象のことを指します。そのため、絶対に起こることがありえない事象は、リスクとは呼びません。
リスクは不確実な事象であるため、発生確率によって評価することが多いです。また、リスクにはある事柄についてプラスとマイナス双方の影響が生じます。
システム開発プロジェクトにおけるリスクには、大きくわけると下記の4点があります。
・金銭的リスク
・納期リスク
・品質リスク
・技術リスク
それぞれのリスクについて、詳しくみていきましょう。
金銭的リスク
システム開発契約を締結したときのシステム開発費用（当初見積もり）が、実際に開発を行っているうちに膨らんでしまうリスクを、金銭的リスクと呼びます。
開発プロジェクトを進めていくうちに、クライアントからの追加要望により開発対象機能が広がり、費用が増えた場合は、クライアントとの間で費用負担交渉の余地があります。
しかし、それ以外の理由によって開発費用が増大した場合には、クライアントとの信用問題につながってしまったり、自社で増加した費用を負担しなければならない事態となる可能性があります。そのため、重要なリスクであるといえます。
納期リスク
納期リスクとは、クライアントへの納品がスケジュールに間に合わないリスクのことです。最も顕著な例としては、システムのリリース日がスケジュールに間に合わないといったケースがあげられます。
システムのリリースが、万が一スケジュールに間に合わないと、クライアントに多大な悪影響を与えてしまい、クライアント自身の企業としての信頼性を揺るがすことにもなりえます。
そのため、場合によっては納期遅延によって、損害賠償などの法的手段に発展してしまう可能性もあります。
品質リスク
契約時にクライアントが要求していた要件を満たしていないリスクを品質リスクと呼びます。要件とはシステム機能はもちろんのこと、システムからのレスポンスの速さやシステムのサービス時間などの非機能要件も含まれます。
クライアントと取り決めた要件に合致しないシステムを納品することによって、自社の信用失墜はもちろんのこと、先ほど紹介した金銭的リスクや納期リスク発生の引き金となってしまう恐れがあります。そのため、決して軽視できるリスクではありません。
技術リスク
自社の技術的な問題・スキル不足などによって、クライアントから受注したシステムの開発が困難になってしまうリスクを、技術リスクと呼びます。
たとえば、クライアントと取り決めた要件を技術的な理由で実現できなくなるといったことや、バグが発生し解消する見込みがないといったことがあります。また、納品後にシステムの不具合が発生しクライアントの要求する要件を満たせないといったリスクも該当します。
重大な技術リスクが発生した場合には、システム開発プロジェクト自体が頓挫してしまうケースもあります。
リスク管理の手順・ポイント
。
次に、これらのリスクの発生を抑止・低減するために行うべき、リスク管理の手順およびポイントについて紹介します。手順としては、以下の6点があります。
・リスクの洗い出し
・リスク対応の優先順位検討（リスクの定性的分析）
・リスクの定量的分析
・リスク対応戦略の検討
・具体的な対応策の検討
・設定したリスクを監視し発生した場合リスク対応計画に従って対応
これらの手順を通して、リスク管理の成果物である「リスク対応計画」を立案していきます。では、それぞれの作業内容やポイントについて、詳しくみていきましょう。
リスクの洗い出し
最初に行うべきことは、当該システム開発プロジェクトにおいて起きうるリスクの洗い出しです。特に重要なリスクは見落としをしないことがポイントです。
具体的な作業手法としては、ブレインストーミング・SWOT分析・RBSの活用などが有効的です。
ブレインストーミングとは、できるだけ多くの問題の解決策や新しいアイデアを発見するために複数人でアイデアを出し合う手法です。
SWOT分析とは、ある課題の洗い出しのために、内部環境（自社内）および外部環境（自社外）のプラス面・マイナス面を洗い出す現状分析手法です。内部環境としては強み・弱み、外部環境としては機会・脅威があります。
RBSとは、プロジェクト管理の計画立案に使われるツールであり、プロジェクトで必要となるリソース（人的リソース・物的リソース）を整理・管理するための手法です。
リスク対応の優先順位検討（リスクの定性的分析）
洗い出したリスクに対して、発生確率の高低・発生した場合の影響度合を設定し、リスクごとにポイントを算出します。発生確率は確率が高いリスクほどポイントが高く、発生した場合の影響は大きいほどポイントを高くします。
発生確率と発生した場合の影響のポイントを基に、各リスクのポイントを算出します。原則として算出したポイントが高いリスクほど対応の優先順位を高優先に設定します。この作業を、洗い出し全リスクに対して実施します。
各リスクのポイント算出は、一般的には影響度および発生率を加味したリスク評価マトリクスを活用して決定することが多いです。
リスクの定量的分析
リスクの定量的分析については、リスク管理において必須の作業ではありません。後続の具体的なリスク対策検討に迷った際に、定量的な評価が必要であると判断したときのみ、定量的分析を行えばよいでしょう。
リスク対応戦略の検討
リスクの洗い出し・対応優先順位付け・定量分析が終わると、次に対応優先順位に従って各リスクの対応戦略の検討を行います。
リスクに対応する戦略としては、以下の4点があります。
・エスカレーション
・回避
・転嫁
・受容
それぞれの戦略の詳細について、みていきましょう。
エスカレーション
エスカレーションとは、リスクごとの対応担当者がシステム開発プロジェクト内または、自分の所属する組織内の上司に判断を委ねる方法です。
リスクの対応担当者がシステム開発プロジェクトメンバーであれば、プロジェクトマネジャーにエスカレーションします。対応担当者がプロジェクトマネジャーの場合は、所属する組織の上司やPMOにエスカレーションし、判断を仰ぐことになります。
PMOとは、一般的に日本語では「プロジェクトマネジメントオフィス」と呼ばれており、組織内における個々のシステム開発プロジェクトの支援を横断的に行う部門のことをいいます。
回避
回避とは、リスクそのものを回避する戦略です。別の言い方では、リスクを生じさせる要因そのものを取り除くということです。
システム開発プロジェクトにおけるリスク回避としては、初めて採用する技術を活用することに大きなリスクがある場合に、その技術自体の採用を取りやめるといった例があります。
なおリスク回避は必ずしも可能というわけではありませんし、リスクを回避することによって潜在的な機会（チャンス）を失う可能性もあるため、リスクとチャンスのバランスをみて、実際に戦略を打つとよいでしょう。
転嫁
転嫁とは、保険や保障・契約などの工夫により、責任を転嫁する戦略です。つまりリスクの影響を外部に移転する対策です。
システム開発プロジェクトにおけるリスク転嫁とは、あるリスクを含む作業自体を他社にアウトソーシングすることにより、リスクを外部に移転するといったものがあります。
また、システム開発の失敗におけるリスクを考慮して、損害賠償対応のために保険に加入するといったこともリスク転嫁の一例です。しかし、すべてのリスクが転嫁できるわけではなく、また他社にリスクを転嫁するためにコストが発生する点も考慮し、戦略を決めるとよいでしょう。
軽減
あるリスクに対して発生する確率を減らしたり、リスクが現実のものとなったときに影響を最小限にする対応策を取る戦略のことをリスク軽減と呼びます。
システム開発プロジェクトにおける具体的な例としては、新技術を採用するプロジェクトの場合、プロジェクト発足前に新技術の試行を行うといったものがあります。また、品質保障活動の強化や適切なプロジェクト管理手法の採用なども、リスク軽減に有効であるといわれています。
受容
積極的にリスクの抑止を行わずに、現状予見できているリスクを受け入れ、発生したときに備える戦略をリスク受容と呼びます。
リスクの受容は、リスク発生時の影響が小さい、またはリスクの軽減・回避をするためのコストが高すぎる場合に選択されることが多い戦略です。システム開発プロジェクトでの例としては、テスト工程の終了が遅れても本番稼働に影響を与えないように予備の期間を設けるなどがあります。
リスク受容の戦略を取る場合には、リスク発生時に備えた予備プラン（コンテンジェンシプラン）を用意することが多いです。
具体的な対応策の検討
リスク対応戦略の検討が終われば、次にリスクごとに具体的な対応策を検討します。検討ポイントとしては、予防処置・事後対応計画（コンテンジェンシプラン）・コンテンジェンシプラン発動の契機を、各リスクに対して検討・整理を行うことです。
対応策検討後のリスク対応計画の例としては、下記のようなものがあります。
| リスク | 発生確率 | 影響度 | 対応の優先順位 | 予防処置 | コンテンジェンシプラン発動の契機 | コンテンジェンシプラン |
|---|---|---|---|---|---|---|
| A社のプロジェクト管理能力が低く、スケジュールが遅れる | 高 | 中 | 高優先 | B社のプロジェクト管理のノウハウを提供する | A社の進捗が遅れる | 指導・監視のためにC社の要員を配置する |
設定したリスクを監視し発生した場合リスク対応計画に従って対応
リスク管理は、リスク対応計画を立案することがゴールではありません。リスク対応計画を作成した後は、コンテンジェンシプラン発動の契機に抵触したリスクの有無を、継続して監視していきます。万が一抵触したリスクが発生した場合には、リスク対応計画で整理した対策を実行に移します。
また、システム開発プロジェクトの運営の中で、新たなリスクを特定したときには、リスク管理の手順に従い、リスク対応計画に追記して管理を行っていきます。
まとめ
今回はシステム開発プロジェクトにおけるリスク管理のポイントと題して、リスクの種類および特徴、リスクごとのリスク管理の手順やポイントについて紹介しました。
リスクには、金銭的リスク・納期リスク・品質リスク・技術リスクがあること。リスク管理の手順としては、リスクの洗い出し・優先順位付け・対応戦略検討・具体的な対応策検討・リスクの監視が必要だとわかったのではないでしょうか。
システム開発プロジェクトのプロジェクトマネージャーを担当している方で、リスク管理に悩まれた方は、ぜひ今回の記事を参考にしてリスク管理を行ってみてください。
（文：さえぐさ）
