メルマガ
バックナンバー

第16号:自分のプロジェクトを守るためのプロセス領域

2005年07月25日

  • 自分のプロジェクトを守るためのプロセス領域

    「一生のうちに一度はやってみたい」と思っていることはありませんか?私は先日、その内の一つであるスカイダイビングに挑戦することができました。もちろん一人でジャンプするのではなく、インストラクターとつながった状態で飛ぶタンデムジャンプというやつなので、自分でパラシュートの操作をする必要は全くありません。

    小さい飛行機の狭い機体で体育座りをして地上4000メートルまで昇っていき、飛行機のドアが開いたところまでは流石に緊張しましたが、空に飛び出してからパラシュートが開くまでの1分弱ほどの間はまさに「経験したことの無い」感覚で素晴らしかったです。ジェットコースターで感じる気持ち悪さや怖さは全く感じることもなく、着地したときには既にもう一度飛びたいと思っていました。

    この話をすると「自分は絶対無理だ」とか「死ぬかもしれないのによくそんな事ができるな」とかいう感じの反応をする人が多いです。もちろん私も全く平気だった訳ではなく、色々と調べてみました。

    まず過去の事故の例ですが、私がジャンプしたところでは、今までに一度も死亡を含めた大きな事故は起きていないことがわかりました。また、一番気になるのは「パラシュートが開かなかったらどうするのか」ということですが、これについても対策がとられていることが分かりました。

    最初の対策は「予備のパラシュートがある」ということです。もしメインが開かなかった場合、その予備のパラシュートを開くということでした。ではインストラクターが気絶するとか予期せぬ事態でパラシュートを開く動作が出来なかった場合どうなるのかというと、「ある一定高度でパラシュートがまだ開いていないと自動的に開くパラシュートがある」ということでした。

    CMMIには「リスク管理」というプロセス領域があります。これはプロジェクトのリスクを特定し、分析し、優先順位付けをし、軽減策を事前に考えて対処しようというものです。このリスク管理の実装に価値を感じない方がたまにいらっしゃいますが、それで良いのでしょうか?

    「リスク管理」は自分を守るためにやれば良いのです。「~ということが懸念されるので、~という対策を打ちましょう。ただしそこにはコストがかかりますがやる価値があります」ということを胸を張って言えば良いのです。プロジェクトの進行を妨げるものがあるとすれば、それは顧客、エンドユーザー、自分達の上司等の全員にとっての問題であるはずです。

    リスクの脅威の大きさやその起きる確率を理解した上で、適切な軽減策を立てたりそのために予算を割くことは決しておかしなことではないでしょう。「ここでケチって手をうたないでいると、後で失敗するかもしれませんよ、○○さん」と言えるのは、誰よりもプロジェクトの事を心配している皆さんなのです。

    私なら「予備のパラシュートも自動で開くパラシュートも付けなければ半額になりますよ」と言われても、その選択はしないでしょう。またインストラクターも自分の命がかかっています。逆に倍の給料をもらってもそんな選択は飲めないかもしれませんね。