 |
|
|
| 1 2 3 次のページ
|
|
| システム開発プロジェクトの組成段階に潜むリスク
|
「第1回：技術導入に潜むリスクを打破するプロデュース力」では、情報システム開発の着手段階におけるリスクについて、筆者の考えを紹介した。そして情報システム開発における技術選択のリスクの存在、それに向かい合うための技術者の姿勢について解説した。
今回は開発フェーズを進め、システム開発プロジェクトを組成する段階のリスクについて解説を行う。また最後に、情報システム開発のプロジェクトは「同じ目標に立ち向かう人の集団」であることから、情報システム開発に携わるシステムエンジニアに求められる能力についても、筆者の考えを述べる。
|
| RFPがもたらすもの
|
近年では情報システム開発の受注に際して、ユーザ企業がRFP（Request For Proposal）をまとめ、複数のIT開発ベンダーに提案を求める形態が多い。しかし、RFPによる提案要請は情報システム開発の構想段階で行われるため、曖昧な部分があるのも事実である。
RFPにはシステムで実現したい内容や目標などが記述されているが、それに向けての実現の可能性については提案する側が検討する責務を負っている。したがって、ITを使って実現できるものと実現が困難なものを選別するところから検討しなければならない。
ITのソフトウェア開発は「やればできる」ものがほとんどであるが、困難な課題を実現するには、その代償として期間やコストに跳ね返るケースが多い。よってこのような実現の可能性の見極めをまずは行うべきである。
そのような見極めの際にはシステムを作る側だからこそ、気がつく項目があるはずだ。よってRFPにそって提案を検討する過程においては、自身が解釈した前提事項を明確にしておくことが重要である。なぜならこの前提条件を曖昧にしておくと、曖昧さに拍車がかかってしまうからだ。まずは、「解釈のリスク」を排除しないといけない。
|
| 曖昧性からの脱却
|
RFPをベースとして情報システム開発の計画を練っていく際、ベンダー自身が前提とした条件をリストアップし、作業項目がブレークダウンできなければならない。前提条件は次の作業項目の洗い出しのインプットになるからである。
仮に、次の作業項目のインプットにならないような前提条件だとすれば、システム開発内容そのものの実現性はかなり低いものといわざるを得ない。このようにして、RFPで曖昧であった部分を可視化して作業を進めることになる。
加えて、最終的なシステムの目標や実現性の検証についても議論をしておくべきである。例えば、開発完了したシステムの受け入れ基準の設定や既存システムからの移行を伴う場合には、過渡期のシステム形態についての議論が必要である。
なぜなら、受け入れ基準が曖昧であると、どうしてもRFPの「曖昧な部分をよい方向に解釈してしまうリスク」が存在するし、移行を伴う場合は必ず「移行リスク」が存在するので、移行作業の実現性を見極めた上で理想のシステム形態を導く必要がある。
|
1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社日本総研ソリューションズ 森 陽一
79年 静岡大学工学部情報工学科卒業。
82年 株式会社日本総合研究所の前身、日本情報サービス株式会社に入社。
90年 技術士（情報工学部門）及びシステム監査技術者資格を取得。
82年〜04年カードシステムに関する企画・開発業務に従事。
04年 株式会社日本総合研究所技術本部本部長に着任。
06年 株式会社日本総合研究所執行役員就任を経て、株式会社日本総研ソリューションズ執行役員に就任。
|
|
|
|
|
|
