• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

ITエンジニアのスキル向上ゼミナール

【上級】失敗プロジェクトの共通項 第1回

要求仕様の鵜呑みは危険

2006/08/01 日経SYSTEMS
出典:日経システム構築 2003年11月号148ページより
(記事は執筆時の情報に基づいており、現在では異なる場合があります)
目次一覧

 「外注したソフトの品質の悪さに閉口した」「検収時に利用者から使い物にならないと文句を言われた」「どうやり繰りしてもカットオーバーに間に合わない」…。プロジェクト・マネージャ(PM)の悩みは尽きない。

 システム構築プロジェクトを成功に導くために,具体的にどのようなマネジメントを行うべきか。過去の失敗プロジェクトの積み重ねを分析することで,その傾向と対策が見えてきた。

 ここではプロジェクト・マネジメントの中でも,失敗の原因を発見し潰すための“リスク・マネジメント”に焦点を当てる。前半は,リスク・マネジメントを行うための具体的な作業の内容を紹介する。後半では,ダミーのプロジェクトを想定し,そのプロジェクトが陥りやすいリスクとその予防策を紹介する。

11個の作業で構成する

 システム構築におけるリスク・マネジメントの標準的なフローは,11個の作業で構成する*1。作業の大半は,上流工程でのリスクの洗い出しに費やすと考えるべきである。開発着手時点で,さまざまな観点から漏れなくリスクを洗い出し明文化されていれば,プロジェクトの成功確率は飛躍的に高まる。もちろん,リスク管理に終わりはなく,工程ごとに対策の効果を把握し,必要に応じて軌道修正を行うことも必要である。

 以下,11個の作業を解説していく。リスク対策の検討は,PM主体で行うのが基本だが,プロジェクトの規模によっては,PM個人ではどうにもならないことがある。会社としてのプロジェクトへのコミットが必要だったり,プロジェクト外の技術者や協力会社のキーパーソンなどの協力を仰ぐのが効果的だったりすることもある。

 各項目の【 】内は,作業を行うべき主体を指す。例えば【会社】は全社的に取り組むべき作業,【PM】はマネージャ個人で行える作業を指す。

(1)リスクチェックシートの作成【会社】


図1●リスクチェックシートの例
チェック項目はここではキーワードを示した。具体的な項目は自社に適した形で決定する

[画像のクリックで拡大表示]

図2●想定プロジェクトの概要
ベンダー側のプロジェクト・マネージャとして参画し,ユーザーに満足してもらえるシステムを作ることを目的とする。ユーザー側は,情報システム部門が主にベンダーとのやり取りの窓口となる

[画像のクリックで拡大表示]

 過去の失敗事例の原因分析結果などを元に,自社または開発部門の特性に適した「リスクチェックシート」を作成する。チェックシートは,縦軸に想定されるリスクを列挙し,横軸にそのリスクに対する評価や対策,状況を並べると使いやすい。図1[拡大表示]に提示したサンプルをベースに,自社にあったチェックシートを作るとよい。

(2)対策プロジェクトの決定【会社】

 会社としてマネジメントすべき対象プロジェクトの基準を決める。「ソフト開発工数が50人月以上または危険プロジェクト」あたりを目安に考えるとよい。危険プロジェクトとは,過去に類似システムで失敗しているプロジェクトや,全社で経験のない業界や技術スキル,特殊事情をもつプロジェクトなどを指す。

(3)リスクの洗い出し【PM】

 リスクチェックシートに基づいて,各チェック項目の該当有無を付ける。これがリスクを洗い出す作業になる。チェックシートに項目がなくても,重要なリスクがあればシートに追加する。

(4)該当リスクの発生確率の評価【PM】

 該当リスクが発生する確率(危険度)を3段階(大:3,中:2,小:1)で評価する。評価基準の目安は以下の通り。

 大:ほぼ発生すると予測される。または既に発生している

 中:発生確率がおおむね50%以上と予測される

 小:発生確率の方が少ないと予測される

(5)リスク発生時の影響度の評価【PM】

 該当リスクが発生した時の影響度(品質,コスト,納期)を3段階(大:3,中:2,小:1)で評価する。

 大:品質,コスト,納期のいずれかに重大な影響を及ぼすと予測される。または既に重大な影響を及ぼしている

 中:品質,コスト,納期の何れかに致命的でないが,大きな影響を及ぼすと予測される

 小:品質,コスト,納期に直接及ぼす影響は少ないと予測される

(6)リスクの総合評価【PM】

 [該当リスクの発生確率]×[該当リスクの発生時の重さ]で算出する。算出結果は9段階(リスク大:9~リスク小:1)となる。ここで総合評価「6」以上のリスクを重点管理リスクの候補とするとよい。

(7)リスク対策会議の開催【会社】

 上記のリスク情報をもとに,リスク対策会議(仮称)を開き,検討する。リスク対策会議の目的は,リスク管理対象プロジェクトについてリスクの漏れを確認したり対策を検討,決定したりすること。メンバーは後述の「見積もり審査会」(p.157参照)とほぼ同じでよいため,同時開催が効率的である。ただし,リスク対策会議の方は,特に技術的なスキルの高いメンバーのアサインが不可欠である。

(8)重点管理リスクの決定【対策会議】

 リスクの総合評価で,数値が大きいものを参考にして,重点管理リスクと優先順位を決める。

(9)対策の検討,決定【対策会議】

 主に重点管理リスクについて,その対策を決める。マネージャに負担がかかりやすいが,関係部門の協力を得られるかどうかが成功を左右する。

(10)中間チェック【PM,品質部門】

 主に重点管理リスクについて,対策が有効に働いているかをチェックする。プロジェクトの規模に応じて,最大6つのマイルストーン*2(開発計画時,基本設計完了時,詳細設計完了時,プログラム製造完了時,結合テスト完了時,システム・テスト完了時)を設定して中間確認を行う。

 予想した効果が得られていない場合は,その原因を追究して対策を見直し,効果の期待できる対策を再検討する。

(11)納入後の評価【PM,品質部門】

 品質,納期,コストについて完了評価を行い,問題として最後まで残ったリスクについて,原因を明確にして「リスクチェックシート」の改善に反映する。

 以下,ダミーのシステム構築プロジェクトを想定し「どのようなリスクが発生しやすいか」「どのような対策を打つべきか」を解説する。

 リスク対策には,リスクが表面化する前に講じる「事前策」と,表面化した後に講じる「事後策」がある。事前策は,さらにリスクの表面化を抑制する「予防策」と,表面化時にその影響を減らす「準備策」に分かれる。今回は,最低限行うべき予防策を主に解説する*3

 想定するプロジェクトは,50人月の業務システム用ソフト開発。ベンダーとの窓口となるユーザーの情報システム部門はスキル・レベルが低く,実際の開発はベンダーへの丸投げに近い。利用部門はシステムに対して多くの要求を持っている。ベンダー側でも,開発を抱えきれず,半分を協力会社に発注する。これを,ベンダー側のプロジェクト・マネージャの視点で見ていくことにする(図2[拡大表示])*4

町田 仁司
松下電器産業 パナソニック システムソリューションズ社
品質・環境グループ 主任技師

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る