検索
失敗の原因を考察
それでは失敗の原因をリストアップしていく。
「ITプロジェクト版失敗原因マンダラ図」から全ての失敗原因を抽出する
※「ITプロジェクト版失敗原因マンダラ図」とは…筆者が所属している失敗学会は、失敗の原因を構成する要素を分類して関連を階層ごとに図示した「失敗まんだら」を提唱している。仏教で悟りの世界や仏の教えを示した図絵である連関図にヒントを得て、失敗原因に関わる全ての要素や関連、位置づけを一覧できるようにしたもの。この失敗まんだらをITプロジェクト向けに改変したもの。
下図のように39項目が選定される。
真の失敗原因を特定する
＜直接的な問題点＞
①PoC（概念実証）での検証時に問題なしと判断している。
②パッケージソフトを利用する場合はカスタムを最小限にすることを前提したサービスであることを野村証券側が理解していないし、受託側も強く伝えられていない。
■筆者が考える今回の問題点
1．野村証券側のPoC（概念実証）を商品説明会と認識間違いをした。【間違った顧客志向】
2．大手開発企業であれば丸投げしてもなんとかなると考えていた。【文化常識の違い】【想像力不足】
■筆者が考える対応策
1．パッケージソフトを利用する形態で運用する場合はカスタマイズを行うと、将来のアップデート時に多大な手間が生じることなどをプロジェクト開始前に経営側と現場部門とのステアリングコミッティを開催し、納得後に開発に着手する。
2．現場側はPoC（概念実証）をなぜ行っているかを理解した上で意見交換しながら進める。
外部委託利用前の考えの浅はかさが真の失敗要因
今回、メディアの記載内容を「ITプロジェクト版失敗原因マンダラ図」で真因の考察を行った所、発注側企業、特に声の大きな現場の担当者が知識を持ち合わせていないために発注した外部委託業者を「魔法の杖」のように使おうとし、「想像」することは行わず要求を丸投げしてしまい、技術を独自で学ぶことを放棄してしまったケースであるように感じた。
外部委託を使うことが悪いわけでなく、外部の力を借りるだけでなく、知識・経験をうまく自社に取り入れるような体制をとるべきであった。現在、どの企業でも自社の知識経験だけでシステム構築することは行っておらず、外部の知識は有効に活用すべきであるが、自分たちの「想像性」を放棄することとは違うため、企業として何を残すべきかは外部を利用する前に十分な検討を行っておくことを勧める。
佐伯 徹
特定非営利活動法人失敗学会
理事
《最新のDX動向・人気記事・セミナー情報をお届け！》
≫≫≫DXナビ メルマガ登録はこちら
