リスクは将来起きる問題で懸案は既に起きている問題です、分けて管理しましょう
リスクと懸案の違いは何でしょう
仕事の上でリスクや懸案という言葉を使う事はよくあると思いますが、違いは何でしょうか？ リスクとは将来起きる可能性のある問題点で、懸案とは今の時点で既に起きてしまっている問題点です。このリスクと懸案は明確に分けて管理して、適切な優先順位の元で対策を進める事が、開発プロジェクトを成功させるためには大切です。また、リスクを懸案を分けて管理する事で、プロジェクトの正否を推測する事もできます。
問題点を指す言葉には他にも懸念や課題などもありますが、グータラ親父は懸念や課題という言葉は使わずに、時間軸を明確にしたリスクと懸案という言葉を使っていました。今起きている懸案か将来起きるリスクかを明確に分ける事で、対策の優先順位が判断し易くなるからです。
たいていのソフトウエア開発プロジェクトでは、開発を開始する時点でいくつかの問題点に気が付くので、それをリスクか懸案かに分けて一覧表に書き出して管理する事になります。そして、個々のリスクや課題の重要性が同程度ならば、対策の優先度は今起きている懸案＞将来起きるかもしれないリスク、と考える事ができます。
例えば、ソフトウエア開発プロジェクトの開始時点で、テスト担当者の割り当て人数が少な過ぎるという問題点があったしましょう。これはリスクです。開発開始時点ならまだ開発要件を整理する時期なので、テスト担当者が少なくても開発作業は進みます。今すぐに対策を取らなくても大丈夫で、テストが始まるまでに対策がとれれば問題は起きません。今はまだ起きていない問題点なのでリスクです。
一方で要件設計を担当する設計者の割り当て人数が少過ぎるという問題点の場合はどうでしょう。これは懸案と呼びます。ソフトウエア開発プロジェクトが始まって一番最初の作業が要件設計なので、この設計者が少なすぎると計画日までに要件設計が終わりません。ソフトウエア開発プロジェクトが始まったとたんに工程遅れが起きるので、これは今もう問題が起きているので懸念です。
今起きている問題点を懸案、将来起きる問題点をリスクとして、リスクと懸案を分けて管理する事で、対策の優先順位が付けやすくなります。そして、プロジェクトが進むに従って、それまでリスクだった問題点がある時期から懸案に代わっていき、対策の優先順位が上がります。
リスクと懸案を分けて管理する事でプロジェクトの正否を占えます
これで何が判るかというと、プロジェクトが成功しそうか失敗しそうかの判断がし易くなります。 リスクがたくさんリストアップされていても懸案が少なければ、そのプロジェクトは問題点をちゃんと管理できているという事です。将来起きるかも知れない問題点に予め気づいていて、その問題点が現実に起きる前に対策をする事で懸案になる事を防げています。
一方でリスクの件数は少ないけれど懸案が多いプロジェクトは、今来ている問題点懸案に対する対策が追い付いていなくて、今後起きる可能性のある問題点＝リスクの洗い出しが十分にでいない、とう状況に陥っている可能性があり結構ヤバイ状況です。
ソフトウエア開発プロジェクトが成功しそうか失敗しそうかという事は、プロジェクトの管理に関連する事で、ソフトウエアの品質保証や品質管理とは微妙に違うのですが、グータラ親父は結構気にしていました。
ソフトウエアの品質を良くするには、失敗しそうなプロジェクトをできるだけ早めに見つけて成功するように早めに指導するのが、一番効率が良いというかトータルで楽になります。 なので、リスクと懸案の状況を気にしていたというのが本当のところです。 品質の悪いソフトウエアをリリースしたり、リリース申請されたりすると、結構手間暇がかかりますが、品質の良いソフトウエアはリリース審査も楽ですし、リリースした後も問題が起きる事が少ないので、とっても楽ちんです。