Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

第4回 リスク管理の効能

  2007/08/28 12:05

 システム開発はリスク管理の質で勝負が決まると言ってもよい仕事です。開発計画の段階からリスクを洗い出し、計画的にリスクを軽減させると同時に、開発中も次々と湧き出すようにおこってくる難題を的確に捉え、評価し対策をとらなければなりません。システム開発を破綻させないための管理も、出来上がってからの障害対応もプロジェクトレビューを活用するとうまく行きます。

現実のシステム開発は変化の連続

 「書いてあることはやらなければならない、書いていないことはやってはいけない。」

 要件定義の大原則ですね。要件定義は開発するシステムの設計図になるわけですから当然のことです。

 しかし、実際のシステム開発では、開始時点で未確定要素を多く残したままスタートすることが多く、加えて、書いてあるものさえも、発注側、受注側、同床異夢であることが一般的です。「仮決め」という要件定義さえ存在します。仮決めでシステム開発をスタートさせるのですから、さて、これは先の航海が思いやられる…といったところでしょうか。

 システム開発はこのように、常に準備万端、決めることを全て決めて始める、ということが出来ない仕事ですから、その程度に応じたリスク評価とリスク対策をしっかり行い、リスク解消を図っていかなくてはなりません。さらに、システム開発の状況は開発が進むに従って変化しますので、新しいリスクも発生します。

 例えば、テストで期待されたパフォーマンスが出ない場合、その原因によっては稼働環境の変更、使い物になるシステムにするために設計の変更、はたまた一部機能の実施断念等々、様々な検討が必要になります。関係者の衆知を集め、お金をかけるか、時間をかけるか、なにかをあきらめるか検討し、場合によってはステークホルダーとの政治的な調整が必要になることもあります。つまり、リスクとしてノミネートされたことがクロスファンクショナルに適切に評価されないと正しい結論が導き出せないのであります。

 従って、プロジェクトの最初からこういった開発プロセスの節目毎に、ステークホルダーも参加しリスクを評価、対策につなげるプロジェクトレビューを行う仕組みを組み込みませんと円滑な進捗は期待できません。

 リスクの程度は、開発の進捗に従って変化します。小さくなることも、大きくなることもあります。プロジェクトリーダーは可能な限りリスクを洗い出し、きちんと管理するだけでなく、一つ一つのリスクを数値化し、プロジェクト全体のリスクについて積算し、その絶対値と共に変化を管理しなくてはいけません。

リスク管理チェックシート

 リスクを評価し、リスクの程度を数値化して管理するための「リスク管理チェックシート」については、「実務で役立つプロジェクトレビュー」の第3章「プロジェクトレビュー制度の実際」に掲載されています。ぜひお読みください。

 プロジェクトの成功はそのシステムを利用しようとしている人にとってもっとも大切なものですから、プロジェクトリーダーは遠慮なくプロジェクトレビューで全てのステークホルダーにリスクを提示し、共同で評価を行い、対策を練り、リスクを軽減していく努力をしなくてはならないのです。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 菊島 靖弘(キクシマ ヤスヒロ)

    独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター(SEC) リサーチフェロー。 1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管...

バックナンバー

連載:実務で役立つプロジェクトレビューの心得
All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5