新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 新春特集 リスクマネジメント特集３ コンサルタントから見た ＩＴプロジェクトのリスクマネジメント ―プロジェクトの構想・計画段階のリスク評価が肝心、 実施段階ではダイナミックなリスクマネジメントを！― 株式会社アイ・ティ・イノベーション 代表取締役社長 林 衛 はじめに ちょうど１０年になります。１９９８年という年 は、当時の通産省（経済産業省）が初めてＩ アイ・ティ・イノベーション社は１９９８年、 Ｔという言葉を使い、プロジェクトマネジメ ＩＴプロジェクトのマネジメントと開発方法 ント導入のブームが始まった年です。 論の革新を旗印に発足しました。今年で設立 私は、８０年代後半から９０年初めにかけて、 1 英国にあるＢＩＳ社と米国のジェームスマーチ スやテンプレート、テクニック、事例などを ン社からさまざまな開発方法論とプロジェク 肉付けして実務で使用できるようにしました。 トマネジメント手法を学び、多くのプロジェ この１０年間で１００余りのプロジェクトや クトに適用してきました。現在当社では、Ｍ ＩＴ組織変革の活動を支援してきましたが、 ｏｄｕｓ（登録商標）という名称で、ＰＭプロセ 私がコンサルタントとしてプロジェクトにか ス、ＩＴ企画プロセス、開発プロセス、テス かわる際に最も重要視してきた点は、次のと トと品質マネジメントプロセス、運用プロセ おりです。 ス、見積りプロセス、人材育成プロセスなど ①プロジェクトにビジョンがあり、目的やゴ に分類し、プロセス、アウトプット、テンプ ールが明確であるか？ レート、様式、テクニックの形式に体系化し ②プロジェクトの目的実現のためのアプロー てお客様と実施するプロジェクトへの適用、 チ、採用する方法論（プロセス）が適切で コンサルタントが活用する手法として、また、 あるか？ トレーニングシステムとして提供しています。 ③プロジェクトチームが適切に組織化されて Ｍｏｄｕｓの体系で最初にまとめ上げたノウ おり、活性化しているか？ ハウは、プロジェクトマネジメントです。Ｐ しかしいくらこの視点で点検したとして Ｍプロセスとさまざまなノウハウを、ＰＭＢＯ も、ここ数年にかかわったプロジェクトでは、 ＫやＣＭＭＩを基本に、当社のコンサルタント プロジェクトの目標自体が相当努力しなけれ が実際にプロジェクトで適用した詳細プロセ ば到達できない水準になっていて、全く不十 2 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 分な人的資源で実施することを常に強いられ す。 ました。つまり、そもそもかなり厳しい状況 で、成功することが困難な場合が多いという 私は、ここ２０年ほどの間に、火消し、難易 ことです。プロジェクトの知識も経験も無い 度の高い大規模プロジェクト、小規模である まま見切り発車して、力ずくで推進した結果 が短納期のプロジェクト、新しい技術を初め と言えるでしょう。 て採用するプロジェクト、要員のスキルが低 プロジェクト活動とは、別の言葉でいえば、 いプロジェクトなどさまざまなタイプのプロ 「定常活動では達成できない高い目標を掲げ、 ジェクトを経験してきました。 期限や予算を先に約束する行為」です。つま お客様のプロジェクトをコンサルタント り、この①から③の要素の整合性がいくら取 として支援する際に重要な点は、参画する段 れていても不確実性（リスク）を伴う活動で 階でできるだけ将来の見通しを立てることで あることを、リーダのみならずチームメンバ す。プロジェクトのビジョン、目標の設定、 全員が認識する必要があります。そもそも、 プロセス、体制、技術、プロジェクトの分割・ プロジェクトとはリスクを伴う活動であるこ 統合、情報共有とコミュニケーションの方法、 とがプロジェクトの本質なのです。 会議体、構成管理や品質管理、変更管理……、 プロジェクトをうまくマネジメントする 個別のマネジメント要素をそれぞれどのよう ということは、リスクを確実にマネジメント に改善するかを検討する前に、リスクマネジ することにほかならない、と私は考えていま メントの観点で横断的に点検します。さらに、 3 参画する時点で何をアクションとして取らな 保てないという状況も少なくありません。さ ければならないかを熟考し、不備があっても らに、プロジェクトの計画時に致命的な欠陥 計画書、進捗時のデータ、契約書、要件定義 があったり、ＩＴ要員のシステム分析力、設 や設計書などの具体的な材料に基づいて方針 計力が落ちていたりすることがトラブルの原 を立案します。また、参画者の意識、モチベ 因の７割にも及んでいます。これは、プロジ ーションなどに気を払いながら、実際のプロ ェクトの本質の理解不足、基礎力の不足とい ジェクトの状況と問題課題を明らかにします。 った基本的な土台の部分が欠けているためで 参画の段階でプロジェクトメンバと再スター あり、今の延長線上では、もはやたちゆかな トの方針を合意したうえで支援作業を開始す い状況です。 るわけです。 ここで認識しなければならないことは、実 行するプロジェクトの難易度が確実に上昇し ているにもかかわらず、マネジメント力や構 ＩＴの動向と現実に起きている問題 想企画力、開発力などが、相変わらず旧来の ガンバリズムに頼っていることです。 プロジェクトマネジメント力強化 情報技術とネットワーク技術が進化し、シ ステムの多様化、複雑化が進んでいます。要 開発方法論（プロセス）強化 員のマネジメント能力や絶対的な要員数の不 人材の実務能力向上とメンタルモデルの 足のために処理すべき仕事が山積し、品質も 改革 4 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ の３点を実現し、プロジェクト実施時に徹底 ある「コンピテンシ」について調査し、突出 したリスクマネジメントを行うことが、プロ した成果を出しているトップのＰＭと一般的 ジェクト成功の条件です。 なＰＭを比較したところ、非常に興味深い結 果が出ました。 それは、ＩＴのスキルや、真面目さを表す ＩＴの人財にかかわる課題 時間管理、協調行動、責任、約束に対する姿 勢は両者ともさほど変わらないのですが、ト 皆さんはご自分の会社のＩＴ組織の現状 ップのＰＭは、上流のマネジメントスキルと を正確に把握されているでしょうか。残念な もいうべき情報戦略、ビジネスモデル定義、 がら、ＩＴ業界で働く７割くらいの人は、自 計画策定、ＩＴプロセス管理といった戦略／ 力で仕事ができず、ベテランの指導が必要な 計画マネジメント力が強いのです。それが大 状況です。 きな差をもたらしています。 当社では、自らプロジェクトマネジャ（以 また、スキルの高いＰＭでは、向上心、改 下、ＰＭ）と称する数百名の人たちの能力構 革改善行動、コミュニケーション能力、企画 造を示す詳細な診断データのベンチマークを 力などが強いことも分かりました。これは、 保有しています。ＩＴ全般の「ＩＴスキル」 一般のＰＭと呼ばれている人でも、一度覚え （分析、プロジェクト評価、進捗コントロー たことは変えたくないという傾向があるから ル、戦略策定等々）と高業績者の行動特性で です。その中でも本当に高い成果を出してい 5 リスクマネジメントの位置づけ るＰＭは、全般的にコンピテンシが非常に高 かったのです。リーダシップやプレゼンテー ションという外向きの力だけでなく、特に、 プロジェクトマネジメントの標準知識体 問題解決、改革改善行動といった能力の点で 系（ＰＭＢＯＫ）によると、リスクは、 も大きな差があります。 「An uncertain event or condition that, if it occurs, has a positive or negative.（そ いくらマネジメント手法やリスクマネジ れが発生することによって、プロジェクトの メント手法を導入したとしても、実行できる 目標に良い影響、または、悪い影響を与える 人材がいなければ何も変わりません。すべて 不確定な事象や条件のことである）」と定義 のＩＴの課題は、それは誰ができるのか？と されています。ここでは、ソフトウエア開発 いう人材の問題に帰ってくるのです。ＩＴに を円滑に進めていくうえで悪影響を及ぼす事 従事する人は、時代に適合した実務力強化と 象や条件をリスクとして管理することを対象 メンタルモデルの改革が必要です。本稿では、 としています。リスク要素には、提案、契約 人材の課題は並行して解決するという前提で、 上の営業におけるリスクも含まれます。 リスクマネジメントの実務について述べたい と思います。 リスクマネジメントは、プロジェクトを実 行するすべてのチームにとって、重要な課題 であり、責任でもあります。 6 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ たとえば、発売間もないソフトウエア製品 （１）進捗管理との関連 を利用してシステム開発を行うような場合、 リスクマネジメントでは、定期的に開催 ソフトに多くの不具合やバグが存在する可能 される進捗会議や、随時更新される問題課 性が高いといったリスクが考えられます。仮 題を通じて、進捗管理の中のタイミングで にこのリスクを放置した場合、ソフトに期待 リスクに対する監視を行う。新たなリスク していた部分に重大なバグが発見されると、 要素を認識した場合には、アクションプラ システムとして必要な機能の実現が困難とな ンを立案してリスク一覧表を更新する。 り、プロジェクトの進行や目標の達成に影響 また、プロジェクトに関するデータは、 を与えてしまいます。 基本的に種々の管理から最終的に進捗管 このようなリスクが存在することをなる 理に収集される。したがってリスクマネジ べく早期に識別し、アクションプランを計画 メントは、進捗管理や種々の管理と並行し ／実施すること（このケースでは、事前にパ て遂行することとなる。 ッケージソフトの動作確認テストを行う、公 （２）変更管理との関連 開されているバグ情報をチェックする等）等 変更管理では、システム開発プロジェク の一連のリスク管理活動は、プロジェクトの トにおいて発生した仕様の変更要求を、優 成功にとって必要不可欠なものであると言え 先順位に基づいて変更可否を判断する。 ます。 リスクマネジメントでは、変更管理で受 け入れられた変更に伴って変化するリス 7 クの再評価を行う必要がある。 を繰り返し、リスクの影響を極小化していく 活動です。リスク管理の基本手順を以下に示 何と言ってもリスクマネジメントは、プロ します。 ジェクトの開始時点が最も重要であり、スポ ンサ、ユーザ、ベンダを含めたプロジェクト （１）リスクの監視、識別 を運営するメンバとリスクを共有し、対応策 プロジェクトの円滑な進行を阻む危険 について合意することが必要です。 要素をリスクとして洗い出して分類し、影 響を推定し、重要度をランク付けする。 （２）アクションプランの立案 ＩＴプロジェクトの プロジェクトマネジメントプロセス 識別されたリスクの影響を極小化する ための対策を立案し、それに基づいて行動 計画を立てる。 リスク識別の段階で発生確率と影響度を （３）アクションプランの実施 もとにリスクを分析・定量化し、定量化され 行動計画に基づいて、リスクの影響を極 たリスクの大小を判断して重点的に対応すべ 小化するための活動を実施する。 きリスクを明確にし、リスクの大小によって （４）アクションプラン実施結果の確認 アクションプランの立案方針を変えます。 既に識別されたリスクに対するアクシ リスク管理は、図表３－１のような基本手順 ョンプランの実施結果を確認する。また、 8 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ その結果をプロジェクトの責任者やチー 図表３－１ リスク管理の基本手順 ムメンバで共有し、チーム全体でリスクの 低減に取り組むことが重要である。 プロジェクトマネジメント対象項目のう ち、リスクマネジメントにおいて管理の対象 リスクの監視、識別 アクションプラン 実施結果の確認 とするのは以下の項目です。 プロジェクト開始時にリスク評価を実施 する。 プロジェクトの前提条件や開発システ ムの特性によるリスク項目を洗い出す。 プロジェクト実施時にもリスク評価を実 アクションプランの実施 アクションプランの立案 施する。 プロジェクト実施時にはリスク項 目の 管理を実施し、リスクの発生確率や影 響度の増加や新規リスクの発見を監視 する。 9 リスクマネジメントの詳細手順 ダだけが意識するものではありません。ステ ークホルダであるユーザ、トップマネジメン プロジェクトマネジメントにおけるリス ト、ベンダなど関係者全員で洗い出しを行い、 クマネジメントの手順を述べます。 共有する必要があります。悪い情報や困難な プロジェクトマネジメントサイクルにお 事態をいち早く共有できるオープンな文化、 いて、リスクマネジメントに関するタスクは メンタルモデルを同時に形成することができ 計画段階に開始し、監視・コントロール段階 れば、より円滑なプロジェクト運営ができる では、計画時に識別したリスクの監視を行う でしょう。 とともに、新たなリスク要素が出現しないか どうか、アクションをとるべきかどうかの判 断を定期的に行います。通常のプロジェクト では、６０～７０％のリスク要素は計画段階で 定義できることが多いようです。 図表３－２に示すような手順をあらかじめ ルール化しておいて、共通のリスク一覧表で 一元管理することが望まれます。リスクマネ ジメントは、プロジェクトのマネジャやリー 10 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 図表３－２ リスクマネジメントの詳細手順 リスクマネジメントタスク プロセス 開始 プロジェクトの計画 リスクマネジメント計画を立案する 計画 (1) プロジェクトのリスクを識別する (2) プロジェクトのリスクを分析する (3) 発生確率と影響度からリスクを定量化する (4) リスクに対するアクションプランを作成する (5) リスクの監視と報告の手順を決定する プロジェクトの進捗管理 リスクを管理する (1) リスクの状況を監視し、報告する 監視 コントロール リスクが発生 したか？ NO 新規リスクの 追加があるか？ 進捗管理 YES (2) アクションプランを実施する YES (3) リスクを再識別する NO (4) アクションプランを立案する プロジェクトの完了 プロジェクトを評価する 終結 (１) 実績を収集し、分析する (2) 管理手順を評価する 終了 変更管理 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 図表３－２ リスクマネジメントの詳細手順 11 ＩＴプロジェクトのリスク要素 リスク管理の対象として考えられるリス ク分類を図表３－３に示します。 12 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 図表３－３ リスク分類 大分類 ビジネスリスク 中分類 ビジネス上の変化 マネジメント ／顧客リスク コミュニケーション No. A11 A12 A13 A14 A15 A16 A17 B11 B12 B13 D34 D35 リスク項目 事業の合弁／撤退 ビジネスモデルの変更（BPR の結果として） 配置転換、早期退職、レイオフ 法律や制度の変更 訴訟 自然災害、戦争等 風評、噂 要件定義への顧客参画度合い ・要件定義が不正確、不十分 顧客側キーマンの継続的参画 ・キーマンの人事異動 顧客の過剰要求 (1) 機能向上（ex.極端な自動化要求） (2) 納期の短縮 (3) コストの圧縮 要件変更 ・規模増加（目的、範囲、機能） 重要な機能の大幅削減 ・システム化の効果が縮小 要件の確定度合い ・顧客側の社内コンセンサス ・業務要件、システム要件（性能、品質等） 、運 用に関する要件を含む 顧客と他ベンダとの役割分担、責任範囲、ルール 顧客の承認 顧客企業の組織、文化、風土 顧客側責任者の社内における政治力 顧客側責任者、組織のコミットメント（積極的な協力） 技術／製品選定の方向性間違い ・システム化対象ビジネスの要件に不一致 新技術の採用 ・選定した製品／ツールの機能不足、互換性、応 答性の欠如 ・選定した製品／ツールの有効性の欠如 製品／ツールの品質 製品／ツールベンダの方針 ・サービスの低下 転換、買収等 ・プロジェクト計画と合致しないバージョンアッ プ システムの規模 システムの品質 開発スケジュールの余裕度合い システム開発の先例性 システム開発の柔軟性 アーキテクチャ／リスクの解決度合い 開発チームの体制、人材の不足 ・管理者、ソフトウエア技術者の不足 顧客側チームメンバの管理 開発チームメンバのコミットメント（積極的参画） 開発チームメンバの健康不良、事故 開発環境 ・作業場所、開発用機器 規模、コスト見積り ・スケジュール、予算の見積り間違い （特に要件確定前の読みが過小） ・不適切な尺度、不適切な計測 ・残業が発生して人件費増大 プロジェクトマネジメント ・標準的なプロジェクトマネジメント技法、メ カニズムを実践しない ・不適切なリスク分析、価値分析 ・残業が発生して人件費増大 システム開発標準 ・標準的なシステム開発方法論を実践しない ・過大な文書化作業 システム開発手順の成熟度合い あいまいな改善目標 ・生産性向上や品質改善の目標が抽象的 D36 D37 D38 D39 システム開発技術のスキル、生産性 開発チームの凝集度、統制 協力会社の能力 不適切な構成管理 D41 D42 D51 D52 D53 D54 D55 高い保守コスト リカバリ レスポンス セキュリティ 他システム、既存システムとの I/F 障害バックアップ対策 データ容量見積り B14 B15 B16 人、組織 技術／製品リスク 技術／製品 B17 B18 B21 B22 B23 C11 C12 C13 C14 システム開発リスク システム自体 マネジメント 開発チームの能力 D11 D12 D13 D14 D15 D16 D21 D22 D23 D24 D25 D31 D32 D33 システム運用 技術要素 ・人材、トレーニング、再利用部品の利用 ・管理面、スキル面、モラール面 ・仕様書、ソースプログラム、その他資料の管 理 ・バグ、老朽化したシステム 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 図表３－３ リスク分類 13 ＩＴプロジェクトのリスク要素 るプロジェクトでは、プロジェクトを構成する 組織がますます複雑になる傾向があります。 リスクマネジメントの実務上で最も重要 たとえば、親会社、系列の関連会社、情報 な点は以下のとおりです。 子会社、メーカ、ソフトウェアベンダ、２次 プロジェクトの本質的な理解とリスクマ 下請け業者などがあり、役割や責任範囲を定 ネジメントの重要性を、経営トップを含 義するだけで大変です。さらに、大規模プロ めた関係者が理解すること。 ジェクトを構成する際には、必ず、人材のス プロジェクト組織メンバを常にオープン キル、要員の数の問題が表れます。実際の大 マインドに保つこと。 規模プロジェクトでは、技術者やマネジャだ プロジェクト計画段階で、プロジェクト けの問題ではなく、旧来のシステムを担当し の主力メンバ全員でリスクの洗い出しを ていて業務やシステムのノウハウを持った人 実施し、共通認識に立つこと。 が退職や異動でいなくなったり、ノウハウを プロジェクトマネジメントプロセスにリ 若手に引き継げないで空洞化したりして、本 スクマネジメントプロセスを組み込みル 来の機能やミッションを果たすことができな ール化すること。 い組織も少なくありません。ここ２０年間に採 用した若手とベテランの間の世代間のカルチ 前節では、プロジェクトのリスク要素の分類 ャギャップや価値観の違いからくる齟齬も克 と詳細の候補を示しましたが、私が現在見てい 服しなければなりません。 14 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 図表３－４ リスク一覧表の例 （影響度×発生確率） 経営方針の変更に伴い、開発工程/コスト 大規模なプロジェクト に大きな影響が 変更が実施される（分社 出る 化、事業部制等） 5 発生 確率 （％） 80 業務要件が確定しない 開 発 ス ケ ジ ュ ー ルが遅延し、開発 費用が膨らむ 5 70 3.5 業 務 要 件 が 確 定 し な い 理 由 ワ ー ク シ ョ ッ プ で 業 務 要 件 設 計 の 進 捗 が を明確にし、システム部門サ を確定する。また、場合によ ２ 週 間 遅 れ た イ ド で サ ポ ー ト で き る 部 分 り 責 任 者 同 士 の 打 ち 合 わ せ 時点 は極力協力して、業務要件を を設ける。 確定させる。 さらに、大幅にスケジュール 顧客に対して、事前に仕様凍 が遅延した場合には、スケジ 結時期を明確にし、仕様凍結 ュールを変更する できなかった場合にはスケ ジュール見直しと予算増加 の必要性を合意しておく 要件定義確定後、大幅な 設 計 作 業 の 手 戻 仕様変更が発生する りとなり、開発ス ケジュールが遅 延し、開発費用が 膨らむ 4 60 2.4 厳 格 に 仕 様 変 更 管 理 を 実 施 原則、仕様変更は開発後のフ する（仕様変更の手続きを定 ォロアップとして対応する。 める） しかし、絶対必要要件につい ては、経営層の判断を仰ぎ、 開発規模/スケジュールの変 更を含め対応する － 異動または 病気/不慮の 開 発 要 員 の 大 幅 事故などによる主力メ な見直しが必要 ンバの抜け、入れ替えが となる 発生 パッケージの製品バグ スケジュール遅 が発生する 延につながり、最 悪の場合はプロ ジェクト計画見 直しにつながる 可能性がある 3 30 0.9 メンバの健康状態 /転勤情報 要員/体制を見直す に注力する － 3 20 0.6 事 前 の パ ッ ケ ー ジ の 機 能 確 バ グ の 回 避 方 法 を 別 途 開 発 致 命 的 障 害 の 認 と ベ ン チ マ ー キ ン グ を 実 し対応する 発生した時点 施する。 パッケージ販売会社と密な 関係を形成し、リスク発生時 の即時対処に備える 想定リスク 影響 影響 度 評価 値 予防対策 トリガ ポイント 発生時対策 4.0 関係箇所に対して随時、プロ 絶対必要要件については、経 ジ ェ ク ト 変 更 の 情 報 を 確 認 営層の判断を仰ぎ、開発規模 し、早期に対策を検討する /スケジュールの変更を含め 対応する － 15 リスクマネジメントとは、単なる手法的な とにかく、プロセスを実施することにより 話だけではなく、リスクを克服するための創 プロジェクト活動の品質を変化させることを 造と努力を、持久力を持って対処する活動も 意識的に行うことが、私は重要であると考え 含まれます。 ています。なぜならば、成功したプロジェク つまり、認識できたとしても答えが簡単に トに共通して言えることは、進化を意識的に 見つかるわけではないのです。知恵を絞り、 実施したという事実があるからです。つまり、 想像力を働かせて、場合によっては何度でも リスクマネジメントや問題管理などのプロジ アクションを取る、繰り返しプロセスと考え ェクトマネジメント活動を通してプロジェク るべきでしょう。 ト期間中にプロジェクトのマネジメントレベ 幸いプロジェクトは、ビジョンや目標がは ルを進化させ、プロジェクトメンバのレベル っきりしているため、目標実現を旗印にすれ アップを図ったプロジェクトこそが、唯一、 ば、文化や考えが異なる人がいても明確なア 成功裏に終えているのです。 クションが取りやすいと言えます。リスクマ ネジメントのプロセスや予防策や発生時対策 のアクションを通してプロジェクト活動に継 続的な改善を実現する方法と考えても良いの です。 16 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ プロジェクトリスクの評価の方法自体 Ｃ／Ｓ・ＷＥＢ系のＩＴプロジェクトにおける リスクマネジメントと関連する要素 進捗報告・連絡・情報共有の方法 品質目標 進捗管理方法（品質、コスト、スケジュ Ｃ／Ｓ・ＷＥＢ系のプロジェクトでのリス ク評価をする際に注力すべき典型的な要素を、 ール、リスク、問題課題） プロジェクトレビュの方法 私の経験から工程別にご紹介します。どのプ ロジェクトでも重要な視点として必ず検討す （２）ＩＴ企画段階 べき事項です。それぞれの項目がリスクにな ビ ジ ネ ス の 方 向 性 と 新 ビ ジ ネ ス モ デ ル るかどうか、これらの項目が不十分なために のイメージのプロジェクトメンバによ プロジェクトが危機に陥ることはないかどう る共有 ビジネス目標、ゴール かをチェックすることが必要です。 プロジェクトの範囲の定義 （１）プロジェクトマネジメント （最初に決まっていないことがある） 開発シナリオの検討 成功イメージ 契約マネジメント（契約方法、契約の分 ア ー キ テ ク チ ャ と 活 用 す る ツ ー ル の 信 割など） 頼性確保・技術ノウハウ取得（未発達の プロジェクト体制と役割 技術環境・未確認技術） プロジェクト実施のイメージの共有 品質目標と品質モデルの定義 17 標準化（ＰＭ標準､開発標準など）と開 手順の検討､体制、必要なスキル、工数 発ツール／テストツール／構成管理ツ など） フレームワークや部品の利用 ールなどの利用 新 シ ス テ ム に よ る 業 務 の 運 用 と 組 織 方 デ ー タ モ デ リ ン グ か ら デ ー タ ベ ー ス 設 針 計 開発戦略（業務分析エリアと設計エリア 既 存 シ ス テ ム が 存 在 す る 場 合 の イ ン タ の分割およびリリース戦略、スパイラル フェース設計 移行計画（移行方法､データの信頼性確 アプローチ、プロトタイプ手法の採用） 工数見積りと発注先との契約方法 保） 外注管理の方法､体制、スキル、契約、 セキュリティと完全性設計 コンセンサスなど （インテグリティ・コントロール） ＨＷ／ＳＷ／要員の調達マネジメント シ ス テ ム 設 計 の 検 証 方 法 と ビ ジ ネ ス モ （３）要件定義・設計段階 デル（プロセスモデル、データモデル） 顧客との要件定義体制とワークショップ へのフィードバック ビジネスモデルの合法性、制約事項、商 （４）構築・テスト段階 開発環境・テスト環境の準備・検証（分 習慣、カルチャチェンジ プ ロ ト タ イ ピ ン グ を 使 っ た ワ ー ク フ ロ 散開発・マルチベンダマネジメント） プ ロ ジ ェ ク ト メ ン バ の モ チ ベ ー シ ョ ン ー／ユーザインタフェース設計（方法と 18 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 維持と健康管理 になるでしょう。昨今の新聞やニュースから 品質マネジメントの方法 お分かりだと思いますが、もはやＩＴの活動 第三者テスト 自体が国際化し、国内の企業間ばかりではな 検収条件 く、国境を越えたさまざまなプロジェクト活 （５）導入・移行段階 動を成功させなければなりません。 移行→試行→本番稼働 保守の方法と体制 今後のＩＴの活動の変化は、次のようにま とめられます。 ＩＴプロジェクトの対象は、グローバルに これだけ見ても、プロジェクトは企画段階 とマネジメントが重要であり、成功要件にな 横断する複数の企業になる。 ＩＴプロジェクトを構成するメンバは、異 っていることが分かります。 なる文化と異なる言語を使 う複数の国の 人で構成される。 日本国内の企業や人が使うシステムであ 今後のＩＴプロジェクトの運営 っても、大規模であればオフショア開発の 今や企業の活動は多様で、かつスピードア 要素が入ってくる。 ップしています。企業の事業環境は、グロー どのようなＩＴプロジェクトであっても、 バル化、合併・買収が頻繁に実施されるよう 国際的な標準や開発方法、マネジメント方 19 法に従わなければならない。 どうかです。実際のアクションを決断し、迅 どのようなＩＴプロジェクトであっても、 速にアクションできるかどうかがポイントに コンプライアンスやセキュリティの課題 なります。構想計画をうまく実行できたとし を重要視し、適合しなければならない。 ても、プロジェクト実行中に外部要因や企業 ＩＴプロジェクトの難易度は上昇し、多様 戦略の変更などから大きな変化が起こり、新 なニーズを満たすようアーキテクチャを たなリスク要素が頻繁に出現するようになり 見える化しなければならない。 ます。 開発場所、サービスを提供する場所、運用 このような状況下では、しっかりとしたマ する場所は、コストベネフィットの観点か ネジメントに加えて、スピード感のある判断 ら国境を越えてつながる。 力と正しいアクションを本当に実施できるか ＩＴサービスやベンダが提供する製品の どうかがプロジェクトの重要なコンピテンシ 競争と提携が激しく行われ、グローバルに です。誰も経験したことのない未知のプロジ アンテナを張って変化できない企業は、急 ェクトにも挑戦しなければならないでしょう。 速に市場から撤退することになる。 常にプロジェクトの外から冷静に判断するア ンテナが必要です。アンテナでキャッチした 今後のプロジェクトに重要なことは、動的 情報を分析し、組織に確実にフィードバック なリスクマネジメントでしょう。リスクが認 してアクションを本当に取る。リスクマネジ 識されていても、スピーディに手が打てるか メントは、企業の危険予知能力です。¶ 20 2008.1 MIND-REPORT No.80 新春特集---3.ｺﾝｻﾙﾀﾝﾄから見た IT ﾌﾟﾛｼﾞｪｸﾄのﾘｽｸﾏﾈｼﾞﾒﾝﾄ 林 衛 （はやし トッパン・ムーア・システムズ株式会社において、ソフトウエ まもる） ア開発方法論と CASE の開発適用に従事し、モデルベー ス開発方法論（DOA、OO 手法）を多くの企業に導入する。 株式会社 アイ・ティ・イノベーション 代表取締役社長 その後、ジェームスマーチン・アンド・カンパニー・ジャパン 株式会社においてユーザ系企業、SI 企業への IT 戦略コン サルティング、革新的な IT 方法論の普及、適用を行った。 1998 年 7 月、日本において IT 革新を専門に行うコンサル ティング会社の必要性を強く感じ、株式会社アイ・ティ・イノ 名古屋大学工学部応用物理学科卒 ベーションを設立する。2005 年からインド政府機関の IT 教 ITSS 協会理事、ＰＭＩ会員、ＵＭＴＰ主査、 育プログラム（CDAC/ACTS）を活用した日本の IT 技術者 Microsoft MVP 向けの文化・英語とソフトウェア・エンジニアリング教育に 取り組んでいる。また、２００７年からＩＴ部門や情報子会社 向けのリーダの育成を行う教育プログラムとして“ＩＳリーダ 塾”を本格的に主催する。ＩＴに関する著書多数。 目次に戻る 21
© Copyright 2024 Paperzz
