はじめに
プロジェクトを管理するような立場になってもうだいぶ経ちますが
プロジェクトの運営は常に不安との戦いです。
プロジェクトが思ったとおりに進む、なんてことはほぼ無く
大抵は思ってもいなかったような難題が発生します。
そんな難題が発生した際に、発生してから対策を考えるよりは
ある程度事前に予想して対策も考えておけていれば、
被害も最小限に抑えられるのでは？と思っています。
いわゆる「転ばぬ先の杖」ってやつですね。
これを持っているか持ってないかでプロジェクトが成功するかどうかは
だいぶ変わってくると思います。
今回はそんなプロジェクトにおける「転ばぬ先の杖」
「リスクマネジメント」の話をしようと思います。
リスクマネジメントとは
プロジェクトを始める際にはまずは絶対に
「スコープ」「納期」「予算」というものを
決めると思いますが
この3つが確定したらそれで満足してプロジェクトを始めてしまっていませんか？
ここで「スコープ」「納期」「予算」に影響を与えそうなリスクを
洗い出しておくことが大切です。
リスクマネジメントの流れとしては
- リスクの特定
- リスクの分析
- リスクの監視
となります。
ひとつずつ見ていきましょう。
リスクマネジメントのやりかた
1. リスクの特定
まずはこのプロジェクトを推進するにあたって、今後起こりそうなリスクを洗い出します。
やり方はいろいろあると思いますが、
プロジェクトメンバ全員でブレストするのがいいのではないかと思います。
この工程ではできる限り想像力を働かせて少しでも多くのリスクを挙げるようにしましょう。
考えられる代表的なリスクとしては以下のようなものがあります。
- 要件漏れ
プロジェクトの「スコープ」「納期」「予算」を決める時点ではある程度の要件は
決まっていると思いますが、これですべて、ということはほぼありません。
プロジェクト開始以降に追加要件が出てくることを想定しておく必要があります。
- 要員調達
自社のメンバだけで行うプロジェクトであればまだリスクは少ないですが
協力会社さんもメンバに加える場合には、
期限までに人数が集まらない、途中で離脱してしまう、といったリスクは大きくなります。
- 未経験の技術の採用
使い慣れた言語、フレームワークでシステムを構築するのであればリスクは少ないですが
未経験の技術を採用する場合にはリスクが高まります。
（ある程度事前にPoCなどを実施できればリスクは軽減できますが）
未経験の技術の場合、機能的には要件を満たせても、
非機能面（性能面）で苦しくなることがあります。
- 外部システムとの連携
自分たちの構築するシステムで完結するシステム、というのはほぼなく、
多くの場合既存の外部システムと連携する必要があります。
そういった外部システムがある場合、外部システム担当者が非協力的だったりすると
仕様の決定に時間がかかったり、
外部システム側にも修正が必要な場合に外部システム側の修正の遅れで
外部連結テストが始められなかったり、というリスクがあります。
2. リスクの分析
2-1. 挙げられたリスクに対して「発生確率」と「影響度」を決定します。
発生確率
文字通りそのリスクがどのくらいの頻度で起こりえるか
影響度
このリスクが発生した場合、「スコープ」「納期」「予算」のどの項目にどの程度影響があるか
2-2.「発生確率」と「影響度」をもとに対応する「優先度」を決定します。
いくら「影響度」が高くとも「発生確率」がほぼ０に近いようなリスク(*)は
「優先度」は下げて構いません。
(* 利用しているクラウドサービス(AWSなど)が長期間停止する、など)
「発生確率」と「影響度」のバランスを見て「優先度」を決定しましょう。
2-3. それぞれのリスクが発生した場合の対応策を検討します。
リスク管理表のようなものを作成して、
リスクごとの「発生確率」「影響度」「優先度」を記入し担当者を決めます。
優先度の高いものから対応策を検討しましょう。
リスク管理表の例
| No. | リスク | 発生 確率 |
影響度 | 優先度 | 担当 | 対策 |
|---|---|---|---|---|---|---|
| 1 | 開発工程開始後に要件追加が発生する | 高 | 高 | 高 | 岡林 | |
| 2 | 採用したライブラリが大量件数だと性能が劣化する | 中 | 高 | 中 | 福永 | |
| 3 | 開発開始までにBPが調達できない | 中 | 中 | 中 | 細川 | |
| 4 | 利用しているAWSが長期間停止する | 低 | 高 | 低 | 石川 | |
| 5 | ||||||
| 6 |
3. リスクの監視
プロジェクトが始まったら、定期的にリスク管理表を確認しましょう。
プロジェクトが進むにつれてリスクの発生確率が変化することもありますので
（未知の技術の不安要素がなくなった、とか、外部システムの担当者が協力的だった、とか）
「発生確率」「影響度」「優先度」は定期的に更新します。
また、プロジェクト開始前には考えることができなかったリスクも出てくるかもしれないので、
そういったリスクも追加していきましょう。
（プロジェクトの管理をするような立場の人は常に
「新しいリスクはないかな？」と考えておくことが重要だと思います。）
そして、もし想定していたリスクが不幸にも発生してしまった場合は、
検討しておいた対応策を速やかに実行しましょう。
体験談
最後にこれまでのプロジェクトで実際にあったリスクとその対策について述べます。
- 要件漏れ
プロジェクトが始まってからの追加要件は本当に普通にありますよね。
その場合には、まずは予算を増額してもらえないかを交渉してみます。（ダメ元で）
もし、増額してもらえたら、納期も変わらずに追加機能の入ったシステムがリリースできるので
お客さんも我々もハッピーです。
が、こんなことはほとんどないので、現実的にはスコープを変更することになります。
私がよくやる対策としては
事前にスコープアウトしてもよさそうな（次フェーズに回してもよさそうな）機能をリストアップしておいて、
追加要件が出てきたら、その機能との入れ替えを行う、というやり方です。
これであればあまりスケジュールに大きな影響を与えずに要件追加ができます。
- 要員調達
わりと規模の大きなプロジェクトでは期限までに人数が集まらなかった経験をしたことがあります。
年度初めなど区切りのいいタイミングだと人も集まりやすいのですが、中途半端な時期だと
募集してもそもそも応募が少なく、少ない応募の中ではスキルマッチせず…ということで
結果的に1,2名足りない状態で1ヶ月プロジェクトを進めました。
この時は事前に何のリスクマネジメントもしていなかったので、
足りない状態になってもそれを受け入れることしかできず、
リスクマネジメントの大切さを痛感しました。
とはいえ、
このリスクに関しては、人数が足りない！と決まってからできる対策は少ないように思います。
ある程度規模の大きなプロジェクトであれば（利益率とのバランスを見ながらにはなりますが）
予定人数+1,2名という体制でバッファを持っておき、予め対策しておく、
くらいしかないのかな、と思っています。
まとめ
こういったリスクマネジメントは本当に順調なプロジェクトの場合には必要ないのですが
なかなかそんなプロジェクトは存在しないので
リスクが発生した場合、慌てずに対策を打てるようにしておくことで
リスクの影響を最小限にできることが重要なのかと思います。
みなさんもプロジェクト推進するときには「転ばぬ先の杖」を持っておきましょう！
