「ITプロジェクトのリスクマネジメントは異質である？」

　「ITプロジェクトのリスクマネジメント」に関する投稿は2回目である。1回目は2006年の「オンラインジャーナルPMAJ関西5月号」の掲載であったが、あれから2年近くが経った。 　前回は、PMBOK^®第11章「プロジェクト・リスク・マネジメント」を切り口に、PMBOK^®で解説されているリスクマネジメントプロセスをITプロジェクト(ここでは、受託案件型のシステムインテグレーションのプロジェクトを想定)に適用しようとすると、結構悩ましい問題が起こること、一般論としてITプロジェクトのリスクマネジメントが何かと属人的要素で語られ、一筋縄でいかないことに触れた。これはITプロジェクトが知識集約型で眼に見えないシステム／ソフトウェアを扱っていること、また建築基準法の如き設計基準・規定がないことが背景にあると言えなくもない、と記した。加えてこのような厄介なITプロジェクトのリスクマネジメントについて､経験の浅いプロジェクトマネジャーに対して実践的なリスクマネジメントのガイドブックの作成・提供を目的としたSIGに参画し活動していること、そして2006/9/1のPMAJ主催の“PMシンポジウム2006”においてSIGの成果の一部を中間報告させていただくことなどを紹介した。
　このガイドブック(正式名称−“ITプロジェクト 実践リスクマネジメント・ガイドブック”)はその後2007/8になって漸く初版刊行の運びとなった｡ 2007/8/31の“PMシンポジウム2007”でその成果を披露させていただいた後､現在PMAJ会員向けのみならず非会員の方にも有償頒布されているところである　(購入のお申込みは  こちら) ｡ また同ガイドブックをテキストとした1日セミナーも2008/2/1に11名の受講者のもとに東京・新橋のPMAJ会議室で開催。受講の皆様からはそれなりのご評価を得たセミナ−とすることができた｡

　本稿では前回の続編として、上記ガイドブックのPRと記載したITプロジェクトのリスクマネジメントに対して頂戴した貴重な問題指摘を取り上げることにする。

　まずPRである。このガイドブックを特長づける目玉であるが、2つある。一つはプレストン・G・スミス＋ガイ・Ｍ・メリットが著した「標準リスクモデル」をITプロジェクトに適用したこと、もう一つは特にお客さまのシステム構築を受託するSIベンダの立場で受託案件のプロジェクトにおけるリスクのワナとリスク事象をできるだけ体系的に、かつ多くの具体例として整理・まとめたことである。
　前者の標準リスクモデルは従来のPMBOK^®などでも取り上げられている単純リスクモデル(リスク要因−リスク事象−リスク結果の3要素でリスクを捉える)に対して、リスク事象とそのドライバ、リスクによる影響とそのドライバを含む7つの要素でリスクを捉え、特に二つのドライバにメスをいれることで、より具体的な実効性のある対応計画策定を可能にすることを特長としたモデルである。 ガイドブックではITプロジェクトでもその有効性・有用性があることを例示、解説した。
　また、後者はITプロジェクト(厳密にはSIプロジェクトに対象を絞っているが)のリスク事例として､リスクの潜むワナを8つの大分類､49個の中分類に区分けして特性要因図風に図解、それぞれにおいて約170のドライバに対する400項目にわたるリスク事象例をマトリックス形式の表で例示した｡
　SIベンダにとってプロジェクトを受注する際、及び受注後のプロジェクト遂行上で、「こんなところにこんなリスクが潜んでいる可能性があるよ。あなたはそのようなリスクドライバ(要因)を見過ごしていませんか？　ほ〜っておくと大変なことになりますよ」とのアラームを列挙したものとも言える。
　永年多くの様々なSIプロジェクトを横断的に診断(監査)してきた筆者のノウハウをまとめたものである。

　次に二つ目のテ−マである。　ガイドブックで示した大分類の内4項目が顧客(発注者)側に起因する要因として整理したが、これに対して、実は当オンラインジャーナル編集長でもある渡辺貢成氏から貴重なご指摘をいただいた。
　渡辺氏のご指摘は、前回の拙稿に対しても頂戴していたが、このような発注者側に存在する様々な要因を受託者側であるITベンダがリスク要因として捉えることの是非を問い、

• リスクマネジメントの基本はプロジェクトの不確実性をまず契約で明らかにする。契約で明らかにされなかった残りの不確実性をリスクとして洗い出し、その対策を求める手法である
• 契約とは考えられるすべてのことを盛り込むのが原則。ここでは発注者と受注者の役割、責任分担、リスクの分担が明確に記される
• わが国IT業界特有の契約上の問題として、発注者の行う範囲のすべてを受注者がリスクとして扱うのは不可解であり､他業界では凡そ考えられない構造的欠陥である
• それらは発注者と協議して実行すべきことで、そのような取り組みを顧客に進言することがプロフェッショナルとしての勤めである
• また(エンジ系プロジェクトに見習って)「フロントエンドエンジニアリンング」−これはリスクではなく必須の業務である-に注力することが重要

といった内容で、ガイドブックの目玉のキモに対するご指摘であった。

　これらのご指摘は確かにIT業界では特殊事情として、従来正面から取り上げられてこなかったテ−マである。わが国のSIプロジェクトの成功確率(所定のスコープを納期・予算・品質どおりに完遂させる割合)が30%前後にすぎず、受注者のみならず発注者もともに不採算、無駄な投資となって現れていることに相通ずるところでもある。

　このような状況の中で、昨春IPA-SEC(独立行政法人・情報処理推進機構−ソフトウェア・エンジニアリング・センター)から｢経営者が参画する要求品質の確保〜超上流から攻めるIT化の勘どころ〜｣という小冊子と、秋にはほぼ10年振りの改版となった「共通フレーム(SLCP-JCF)2007」が発刊された。改版の重要ポイントは「要件定義プロセス」と「契約の変更管理プロセス」の追加であったが、この両著で共通的に強調されているのは、要求定義の重要性であり、就中発注側の経営者や業務部門の参画が必須、不可欠であるとしている点である。発注者／受託者(SLCP-JCF2007の用語に合わせると取得者／供給者)が双方Happyになり、正当なビジネスの世界にもっていくための必須の取り組みとして、やっと発注側にも焦点が当てられ始めたと言える。

　渡辺氏のご指摘はまさにこのIPA-SECの取り組みと同じ方向を示されたものと理解しているが、残念ながらIT業界でこのような役割分担が地につくには､まだまだ時間がかかると思われる｡
　それまでは当ケースガイドブックに挙げた顧客要因に関わるリスクの潜むワナを顧客と共有し､両者で解決することをしつこくやることが当面の実のある取り組みではないかと考えている。
　ガイドブックの読者も渡辺氏からのこのようなコメントも念頭におき、IT業界の悪しき商習慣を変えていくスタンスでプロジェクトを推進していただければと念ずる次第である｡ 　一方で、渡辺氏からの今回のご指摘は私にとって、非常に新鮮かつ異業種から学んだ大きな収穫であったが、これもリスクマネジメントガイドブックの執筆がもたらした結果の一つである。
　IT(SI)プロジェクトマネジャーはITのプロジェクトマネジメントやリスクマネジメントは異質だという既成概念を捨て、真摯に他業界のプロジェクトに学ぶという姿勢こそ重要であること、PMAJはまさにそのための場であって、社内にはない様々な業界・業種・業務に関わっておられる数多くの先達のノウハウがそこで学べることを改めて声を大にして訴えて、本稿の終わりとしたい。

　なお、ここに記した内容はPMAJジャ−ナル31号「ITプロジェクトのリスクマネジメント」に関係が深い。
同ジャ-ナルには当WG主査の浅田氏執筆によるガイドブックの紹介記事の他、様々な視点でのITプロジェクトのリスクマネジメントに関する記事が満載と伺っている。発行を楽しみにしているが、本稿読者の皆さんも併せてお読みいただければ幸いである｡
　末筆ながら、渡辺氏にはリスクマネジメントに関する多くの示唆・ヒントを授けていただいた。
この場をお借りして心から感謝の意を表したい。どうも有難うございました。　　　　　　＜完＞

IT-SIG，内容にご意見ある方、参加申し込みされたい方は こちらまでメールください。歓迎します。

ITベンチマーキングSIGホームページは こちら