[木内里美の是正勧告]

崩れたパートナーシップと回復への道(vol.24)

2010年9月9日(木)

企業経営にITを活かすことが、企業の差異化のための標準装備になっていることは以前にも書いた。そのために必要な情報システムの出来不出来で装備の善し悪しが決まる。ITが進化するとともに情報システムは複雑な作りになり、ユーザーとベンダーの協働作業が欠かせない。しかし失敗プロジェクトや「動かないコンピュータ」の事例は増え、損害賠償裁判事例に事欠かないくらい、両者のパートナーシップは崩れている。

なぜパートナーシップは崩れたか

汎用機時代にはベンダーと企業のシステム部門は一体感があった。メーカー毎の独自環境に依存せざるをえない大型汎用コンピュータでは、メーカーを選択した段階で一蓮托生の関係になる。ベンダーからは技術担当者が送り込まれて常駐し、様々な問題をユーザーと解決した。システム担当者は独自環境を学びつつ自らプログラムを書いた。ベンダーは開発、運用、保守までを一貫して行うことからユーザー企業の風土や業務を理解し、相互のパートナーシップは拘束力で守られていた。

1980年代後半から1990年代半ばにかけてオープンシステム時代に突入し、ベンダーとユーザーの関係は著しく変わった。オープンとはいえ、決して統制のとれた開かれた環境ではない。「問題未解決の=open」の組み合わせであり、ベンダーだけがマルチになった。この頃、ユーザー企業は盛んに情報子会社を設立し、開発や運用や人事の受け皿にしてきた。優れたものを低コストで迅速に活用できるオープンシステムの流れは止められない。インターネット時代になってより顕著になっている。しかしベンダーとの関係は多くがシステム開発の納品で切れてしまい、リスクを大きくした。パートナーシップが崩壊するという代償を払うことになったのだ。

ベンダーとユーザーの議論

この問題について、経済産業省が設置したCIO戦略フォーラムのパートナーシップワーキングでは、2年にわたってベンダーとユーザーが議論し、改善の方策を探った。ベンダーとユーザー、ならびに代表するそれぞれの協会が一堂に会して生々しい実態の議論をする─稀有の活動と言っていい。

議論が集中したのは、要件定義の不確定問題と見積りの不透明性問題であった。ユーザー企業がどんなにしっかりしていても、要件をきっちり定義してシステム開発に掛かれるわけではない。それが情報システム構築プロセスの特性である。だからこそアジャイル開発で採用している繰り返し開発や、プロトタイプ開発のニーズが出てくるのである。契約上は変更管理をどうやるかの合意形成が重要になる。それを前提に見積りや開発リスクを可視化し、共有すべきであるというのが共通認識になった。また両者の間に入ってファシリテーション(協働促進)やプロジェクト管理代行をする第三者機関の有効性も確認された。

この記事の続きをお読みいただくには、
会員登録(無料)が必要です
バックナンバー
木内里美の是正勧告一覧へ
関連記事

トピックス

[Sponsored]

崩れたパートナーシップと回復への道(vol.24)企業経営にITを活かすことが、企業の差異化のための標準装備になっていることは以前にも書いた。そのために必要な情報システムの出来不出来で装備の善し悪しが決まる。ITが進化するとともに情報システムは複雑な作りになり、ユーザーとベンダーの協働作業が欠かせない。しかし失敗プロジェクトや「動かないコンピュータ」の事例は増え、損害賠償裁判事例に事欠かないくらい、両者のパートナーシップは崩れている。

PAGE TOP