リスクってなんだろう
まだ起きていないことを意識するワケ
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2019、第10弾（2019年12月13日）の投稿です！
今日はリスク管理のお話をしたいと思います。
プロジェクトを成功させるためにはリスク管理は非常に重要であると考えます。ソフトウェア開発プロジェクトでは必ず何らかのリスクが存在します。
- 新規機能を開発するために新しい技術を導入する
- 新しい OS のバージョンがでた
- 開発の途中で要求の追加・変更が発生した
etc…
これらの場合には必ずリスクが伴います。こうしたリスクを早い段階で認識し、早めの対応を取ることがプロジェクト成功のカギであり、リスク管理です。
リスクって何だろう
リスクとは、まだ起きていないこと、不確実なことです。
リスクとよく混同されることに問題、課題があります。リスクが顕在化すると問題であり、問題の発生原因を分析し、解決すべきと判断された事が課題です。なお、問題や課題はプロジェクトの進捗を妨げるので意識しなくても対応されます。
一方、リスクはまだ発生していないため、一般的に管理意識が希薄で軽視されがちです。そのため、あえて意識して管理する必要があるのです。
リスク管理することで
- 問題を未然に防ぐことができる
- リスクが顕在化した場合のダメージ・影響を軽減することができる
- リスク顕在化した場合でもやるべき対策が決まっているため、（リスク管理していない場合と比較して）問題発生から解決までの時間を短縮することができる
といった効果が得られます。
問題を未然に防ぐ＝問題が発生しない＝品質のよい製品ともいえるでしょう。
リスクが顕在化した場合、開発期間中であればチームやステークホルダーに、出荷後であればお客様に影響がでます。リスクが顕在化した場合でもそれが想定されており、素早い対応で最小限の影響にとどめることができれば関係者からも一定の理解、信頼が得られると思います。
つまり、リスク管理を適切に行うことで製品品質とともに、関係者（チーム・ステークホルダー・お客様）との信頼関係が向上します。
リスク管理の事例
最近、リスク管理をしていた良かったなーと思うことがありました。
私がSPQI部の前身である旧品質管理部に参画したのは昨年の11月。当時、旧品質管理部はオフショアへテストを委託していました。なんと3社に発注しているというではありませんか。
私はそれを知ってびっくりしました。前職でもオフショアへの開発委託を経験していますが、すごく苦労しました。3社ってどうなっているんだろう？？いろいろとモヤモヤ……
我々は、
- オペレーションが複雑になってコストが高くなっている
- 為替の高騰や渡航費も含めると委託費メリットが低い
これらのことをリスク要因と捉え、オフショアからニアショアへの移行というリスク対応を進めました。そして（色々と大変なこともありましたが）今年6月、ニアショアへ完全移行しました。
すると！！！
- A社のオフショアメンバーはチームごと転職
- B社、C社はともに親会社である日本企業に売却されるというニュースが…
あのままオフショアへのテスト委託を続けていたらどうなっていたでしょうか？
今回は、オフショア企業のチームメンバーの大量離脱による業務の停止といった問題を未然に防ぐ事ができました。
また、中国発注費用も現在は高騰していますので、親会社である日本企業が売却することも驚く事ではありません。
傍から見たらタイミングがよかった、運が良かったと言われることもあります。しかしこれは我々の部門が積極的にリスク管理していた結果です。
運ではありません。
リスク管理の手順
では、リスク管理とはどうやればいいのでしょうか？
リスク管理の手順はリスクの洗い出し、リスクの分析、対応計画の立案、追跡となります。
§ リスクを洗い出す
リスクの事象とその原因を可視化します。この時、過去のプロジェクトで起きたこと、メンバーの経験が活かされます。プロジェクトに同じものはないけど、発生する問題には似たようなものや傾向がある場合が多いです。一人で考えずチームみんなの知見を出しあいましょう。
§ リスクを分析する
リスクの発生頻度、発生した場合のプロジェクトへの影響度を分析します。
滅多に起きないリスクや、起きてもプロジェクトへの影響が小さいリスクのことをあれこれ考えてもムダですよね。そのため、リスク分析して対応するべきリスク、受容するリスクを決めます。
§ リスク対応計画を立てる
分析結果からいつ、だれが、どのような策をとるか決め、具体的なアクションに落とし込みます。
- 回避策…リスクが顕在化しないようにするための事前対策
- 軽減策…リスクが顕在化した際に影響を最小限に留めるための事前対策
- 受容…費用対効果やその他の状況をみて、リスクを受入れる
- 転嫁…リスク対策できる第三者に責任を移す
- 事後処理…リスクが顕在化した場合にとるべき策
対応計画を立てておくことで、予兆を見逃さず、慌てずに対応できます。
§ リスクを追跡する
追跡者を決め、定期的にリスクの状態を関係者で確認します。
これが一番大事です。
計画立てても放置してしまえば、リスクの予兆を察知できず、突然顕在化することとなります。追跡しなければ、リスク管理していない場合と同じ事になってしまいます。
リスク管理に着手しているプロジェクトでもプロジェクト初期に対応計画を立てて止まっているプロジェクトを見かける事があります。ぜひ、定期的に追跡する仕組みを盛り込んでほしいなーと思います。
オトナの階段をのぼろう
プロジェクトマネジメントのキモはリスク管理だと考えいています。でも、非常に難易度の高い、オトナの領域だとも思っています。
プロジェクト開発に携わっていると
- イヤな予感がする…
- モヤモヤする…
- これ大丈夫かな？！
と感じる場面に遭遇することが多々あります。オトナになるための第一歩はこれらの感覚をもったときに知らんぷりしないこと。この感覚を持った対象はリスクです！リスクと認識してプロジェクト関係者と共有、見える化しましょう。
では。明日から一緒にオトナになりましょう〜！
