スポンサーリンク
【国際資格を目指すならアビタス】私もここで教鞭をとっています。
はじめに
今日のビジネス環境下において、IT投資を全く行わずにビジネスを行うことは困難となっています。ITの技術的進歩も目覚ましく、反面、すでに開発したソフトウェアの陳腐化のスピードも速まってきています。
下りのエスカレータを駆け上がっているような状況に近いのかもしれません。
以外に多いと思われる方もおられるかもしれませんが、システム開発については、70～80％が失敗していると言われています。
システム開発は、階層的にいくつものステップを経て契約、開発、テストを経て稼働します。
受託側（ベンダ）は、一次請、二次請、三次請と多重構造をとっていて、建設業に近いリスク管理が必要になります。
家を建てる時をイメージしてもらうと分かると思いますが、発注側（ユーザ）と受託側（ベンダ）の強い協力関係が必要で、コミュニケーションをしっかりとることが重要となります。
システム開発失敗の原因
発注側からシステム開発の失敗原因は、数多く存在しますが、主に発注側（ユーザ）と受託側（ベンダ）とのミスコミュニケーションにあります。
実際に契約にいたる前にも、ユーザ側でニーズ（要望）の吸い上げを行い取りまとめたうえで、複数のベンダに対しての「RFP（提案依頼書）の交付」、「提案書の受領」、「ベンダの選定」というステップを経て契約書の締結にいたります。
ユーザ側のニーズ（要望）が揺れている状況では、ベンダとのミスコミュニケーションを生みやすくなります。
ベンダの開発プロジェクトに対する理解は、提案書にあらわれます。
ユーザ側の要望がはっきりしない場合には、提出される提案書もアバウトなものとなります。
アバウトなまま実際にベンダが選定され場合には、システムの設計書というべき「要件定義」もアバウトになり、結果的に開発予算の大幅な超過を生みます。
ミスコミュケーションを助長する発注側（ユーザ）の要因としては下記のとおりです。
- ニーズ・要望（要件）・リスク管理方針がユーザ側で固まっていない
- IT開発に対する過剰期待（期待ギャップ）
- IT開発に関する知識・経験の不足
- 業務フローの理解不足
- 開発の進捗管理があいまい（透明性の確保）
- システムを実際に利用する部門が「要件定義」「運用テスト」に参加していない
- ベンダに丸投げ（何とかしてくれるだろう）
- 中止・撤退することを想定していない（資金を投下すれば投下するほど、撤退しにくくなる）
- 開発費のみを注視していて、その後の保守費の検討がなおざり
システム開発のリスクを減らすために
システム開発に、不確実性は常につきまといます。システム開発にかかわる訴訟は、前からよく起きていますが、事例を検討すると「要件定義」の段階で開発を続行するべきかよく検討すれば訴訟まで至らなかったケースがみられます。
システム開発のリスクを減らす意味においても、ベンダにしっかりと要望を伝え、「要件定義」をしっかりと作成することがのぞまれます。
