2014年9月29日月曜日

開発失敗案件が増えています

【このテーマの目的・ねらい】
目的:
 最近また増えてきた開発失敗案件の原因
  を知っていただきます。
 その対策研修があることを知っていただきます。

ねらい:
 案件を成功させる対策を考えていただきます。

ーーーーーーーーーーーーーーーーーーーーーーーー
 

ご承知のように、バブル崩壊後1990年中盤、
開発請負中心の情報サービス業では、
軒並み巨額赤字案件で苦しみました。

会社の存続が危ぶまれた企業も多く、
その後のM&Aブーム(?)にも繋がりました。

しかし、その後各社が対策を講じました。
経済産業省の上流工程請負見合わせ指導もあり、
かなり目をむく赤字案件は減りました。

(日経コンピュータ2007年 4月16日号「Interview」の
富士通黒川博昭社長(当時)の言をご紹介します。

「すさまじい失敗プロジェクトは極端に減りました。
最大の理由は、システム開発の前に
プロジェクトの目的を定義できない場合、
そこで作業を打ち切ることができるようになったからです」)

実は、経済産業省や業界団体は、
1980年代は請負推奨一辺倒だったのです。

「1億円で受注して8000万円で仕上げれば
2000万円の利益が出る。
そのような技術を身につけろ」

本質を弁えない空論だったのです。
要件が決まっていないものを請負するなんて
気違い沙汰です。

(当時、N旧メインフレームメーカの米国法人社長が、
現地の社長たちとの交流会で
「日本では開発上流の請負をしているのか!
信じられない暴挙だ!!」と言われたのです)

最近また大型赤字案件発生の「噂」を
かなり聞くようになりました。

その大きな発生原因は、システム再構築案件の壁です。

システム再構築は、
新しいニーズを取り込むと同時に、
新システムの8割以上の部分は、
既存機能の継承をしなければなりません。

ところが、その継承方法の技術が確立していないのと、
その経験者が皆無に近いのです。
再構築が、
不況のため10年以上も凍結されていたからです。

「現状どおりにしてくれ」と言われても、
現状を記述したドキュメントが存在しない、
という問題もあります。

私が多くの失敗案件を見ての分析ですが、、
失敗要因は以下のように類型化されます。
失敗案件はこのいくつかを抱えているのです。
ーーーーーーーーーーーーーーーーーーーーーーーーーー
【開発案件失敗要因】

1)要件定義が完結していない段階で
  開発の請負契約をした。
したがって、何を作るのかが明確になっていないので、
  開発の請負契約の対象範囲が明確でない。


2)請負範囲が明確でないのに、
   契約範囲内であるか範囲外であるかを判定する
  手続きを定めていない
  (手続きがあったとしたらその手続きを履行していない)。
   そのため、
   一方的に追加要件と思われるものを
   範囲内に押し込めさせられている。


3)追加要件らしきものを受け入れるか否かを
  組織として判断をせずに担当任せにした。
  それでは交渉力として非常に弱い。

4)元請け企業との契約が不備である。
    元請けと自社との責任分担・業務分担を
    明確に定めていないので、
    業務遂行・円滑な進捗に支障をきたしている。


 5)全般的にエスカレーションが弱い。
  案件従事者が
  責任感から自分で抱え込む傾向があるが、
  そのことは決して良い結果を生まない。


これ以外にも案件固有の失敗要因もあります。

当社では、
失敗要因を分析しその回避対策をテンプレート化して提供し、
それに基づく研修を実施しています。
「案件成功対策研修」と言います。

この研修はほぼ10年の実績があり、
多くの成果を上げています。

ご関心ある方は、お問い合わせください。

0 件のコメント:

コメントを投稿