システム開発のトラブルあるある

現場の協力が不可欠

システム開発のプロジェクトが こじれ、訴訟にまで発展した事例がITproの記事で紹介されていた。

この記事では、旭川医大がNTT東日本に発注した病院情報管理システムのプロジェクトでトラブルになり、裁判にまで発展した、というもの。

記事は3本にわたり、経緯を含め詳細に記載している。

● システム裁判は対岸の火事ではない、ユーザー企業が陥りがちな三つの罠
● 失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決
● システム開発の失敗を巡り裁判に至るまで、旭川医大とNTT東の2010年
　

パッケージでの導入に現場部門が反発

記事によると、パッケージでの導入が決まったことに現場担当が強く反発した、とある。
ブログ「自社の業務フローはそのままに、営業進捗管理システムを導入する」でも書いたが、既存のパッケージを導入することで開発コスト・期間が抑えられるが、汎用的な仕様であるパッケージをベースにした場合、今までの業務フローをパッケージに合わせて変えて行く必要がある。

特に現場のスタッフは「従来の業務フローが変更になる」ことに強いアレルギーがある（自分の業務が増える、もしくは面倒になるとの思い込み）ので、しばしば反発を招く。

モックレベルの試作動作検証で現場の意見を反映させる

また（パッケージではなく）オリジナル開発とした場合でも、モックレベルの試作品を実際に担当者に操作してもらい、意見を反映させることで現場が「参画意識」をもち、導入時の抵抗感もぐっと少なくなる。

弊社でシステム案件を手がけるときは、以下の2点にウェイトを置く。
① 既存の業務フローを一気に変えず踏襲したまま、無駄やミスの多いところをシステムに置き換えていく。
② 担当者レベルにモックでテストしてもらい、意見を仕様に十分に反映させる。

ITproの事例のような大規模案件になってくると、モックと言えども簡単に作れるものではないかも知れないが、、モックでの要望を3回くらい繰り返すうちに 皆が納得できる仕様になる。
その時点で仕様凍結し、それ以降は完成後の機能変更・機能追加とするように両者で確約し、実際の開発に進んでいくのが望ましい。

一見回り道に見えるが、実は最短

モックを作ると、それだけで工数が必要となり 一見返って手間がかかるように思える。事実、モックなど作らずに仕様書レベルで仕様を決めていった方が手っ取り早い。
しかし、システム工程全部、さらにはその後の運用までを考えると、完成後（テスト工程）の実際に使い始めての仕様変更要望が大幅に削減できるし、現場作業者の抵抗も格段に少なくなり、実は効率的なのだ。

裁判ではユーザ側の「協力義務」違反が認定された

件の控訴審裁判では、失敗の全責任はユーザー企業（旭川医大）の「協力義務」違反が認定（過失割合100％）された。
システム開発のプロジェクトでは、何らかのトラブルが発生することが ままある。特に工程遅延などで納期が延びそうになる場合、、担当者レベルではそれまでの経緯、特にユーザー側の確認が遅れたり、提示すべき資料（原稿や画像等含む）などが遅れるなど自身に非があることは認識しているのだけれども、社長やトップの意思決定者はそれが見えていないため、一方的に開発側（ベンダ側）の責任を追求してくることも少なくない。
こういったトラブルや誤解を防ぐためにも、要所要所で意思決定者に状況報告をあげていくなど、コミュニケーション不足による誤解やトラブルを防ぐようプロマネ（プロジェクトマネージャー）がコントロールしていく必要がある。