IT導入・システム開発のプロジェクトは、最初は希望を持って、未来を見つめてスタートするものですが、実行段階でだんだんと雲行きが怪しくなる時があります。
発注側に問題がある場合もあれば、受注側に問題がある場合もあります。
ここでは、受注側に問題があったケースを見ていきたいと思います。
ITベンダーの知見の不足によるITシステムプロジェクトの頓挫
会員管理システムの開発をITベンダーに依頼した案件がありました。
このシステムは元々存在しており、発注側が数年前に別なITベンダーに依頼して作ったものでした。
その時のITベンダーは既に関与しておらず、発注側の担当者が管理していました。
会員数拡大に伴い、機能拡張を行うため、再構築を図るプロジェクトでした。
プロジェクトを進めていくにあたって問題が出てきました。
再構築を請け負ったITベンダーは元々作られたシステムの言語・環境等の技術面での知見が不足していました。また、会員は発注側会社の独自なセミナーコンテンツビジネスモデルの考え方で管理されているため、ITベンダー側で理解するのに苦労を要しました。
一方発注側のほうは、既存システムについてビジネス面も技術面でもある程度知見があったにも関わらず、プロジェクトにおいてはITベンダーに丸投げであり、ほとんど関与していませんでした。
プロジェクト最初の段階から、既存システムを見て、新しい要件を取り入れたうえで再構築してほしい、という要求の元スタートしていました。
プロジェクトが進んでいくうちに、既存システムで実装されているものが実現されていない、という点が多々発見されました。
発見されるたびに、新システムへの実装を行ってきましたが、同様の問題が次から次へと出てきたため、当初予定より6か月遅れました。
完成に近づいてはいるものの、やはり未実装機能が残っており、完成していないという扱いとなり、結果的には頓挫しました。
既存システムの知見を受注側が持っていないことでの問題ではありますが、発注側の関与についても先んじて取り決めたほうがよかった、という事案です。
ITベンダーの体制変更により、進まなくなったプロジェクト
証券取引を行うシステムを開発するプロジェクトでの出来事でした。
このITシステムは証券業務を知っていないと理解できないばかりでなく、機密性の高い内容でもあったため、慎重に進められました。
システム要件定義を行い内容を確認したうえで、基本設計の契約を行いました。基本設計も実現性をきちんと確認してから開発に移りたいという発注側の要望で、契約を区切っていました。
基本設計までの完成度は高いと判断し、ITベンダーはリーダの変更を伴う一部担当者変更を実施しました。これは、要件定義を行えるリーダはITベンダーにとって貴重であり、他の新規プロジェクトに割り当てたかったのが最たる理由でした。
その後、プロジェクトが進むにあたって、問題が出始めます。
基本設計は完成度が高かったものの、非常に専門的かつ機密性の高いシステムを扱ていることから、あえて言葉で説明していないような処理要求があることがわかってきました。
当初参画していたリーダは理解できていた部分もあったのですが、新たに入ってきたリーダや担当者にとっては、想像もできないことが多く発生していました。
さらにその後は余りにも無残な状態となっていきます。
手戻りでの作り直しが多く発生のため、エンジニアが徹夜で対応をしていたものの、追いつきません。結果大幅な遅延となってしまい、損害賠償責任が問われます。
途中で体制変更を行うことに問題はないのですが、変更しても問題ないことをよく確認していないといけません。また、発注側は受注側の体制を細かく指示することもできませんが、体制に問題がありそうであれば、早い段階で是正を要求したほうがよかった事案です。
ITベンダーのプロジェクトマネジメント不足に起因したITシステムプロジェクトの大幅遅延
プロジェクトマネジメントという言葉は実に広範囲な行為を指します。プロジェクトを進めるにあたってやるべきこと管理することと捉えられますが、何を管理するか、という点で広範囲となります。
やるべきことというのは、作業の進捗が主な点です。それ以外に、技術的な事項であったり、発生した課題を裁いていくというのもプロジェクトマネジメントに含まれます。
受注したITベンダー側でプロジェクトマネジメント不足により、大幅に遅延してしまった事例がありました。
自治体の財務管理システムの導入に関わるものでした。
ITベンダーの提案に基づき、現状業務とのフィット・ギャップを分析した上で、IT導入プロジェクトが進められました。
データ移行やテストが行われる段階となり、フィット・ギャップ分析では見つかれなかった現状業務や扱っているデータと導入システムとのずれが発見されました。
そのずれは課題と認識されていましたが、ITベンダーは導入しようとしているパッケージシステムの仕様しかわからず、発注側の自治体の業務の理解が不足していました。それにより、課題への対処が遅れ遅れとなる傾向でした。
発注側の現状業務と受注側のシステムとのギャップによる課題であり、IT導入プロジェクトにおいては
よくあることではあるのですが、その課題を発注側と受注側とどちらの責任において対処するのかは、時と場合によります。この場合は、受注側が提案の中で、現状業務を新システム導入まで導くということを謳っていたため、受注側が課題に対処する責任が重いと判断されました。
受注側ＩＴベンダーは課題への対処を自らのプロジェクトマネジメント責任の範囲と捉えなければならなかったということになります。
プロジェクトは大幅に遅延したことで、ITベンダーは赤字となってしまったようです。しかし発注側も予定より遅れたことで、何らかの不利益は被っています。
受注側のコミュニケーション上の問題による途中契約解除
通信関連会社の基幹システムにおける機能改善での事例です。
この事例は極端な事例なので、あまり起きることではないかもしれませんが、コミュニケーション上の問題は小さい問題であっても発生しがちではあるので参考としてください。
発注側はITベンダーに機能改善の要求を伝え、契約をしました。
ITベンダーは当該会社のシステム開発の経験がありある程度見識があったため、簡易的な要求確認にて、作業に取り掛かりました。
その後、ITベンダーから確認や連絡は一切ありませんでした。
完成に近づき、ITベンダーは納品しますという連絡だけをしてきました。
発注側として、機能の確認を行ったところ、要求の解釈違いにより、想定していたものと違う箇所がいくつかありました。
ものはできているというITベンダーの主張に対し、できていないとする発注側会社とは対立し、発注側としては契約解除を申し入れました。
打合せを実施しなかったことに対し、受注側ITベンダーは非を負いました。
ただし、発注側においても少しはコミュニケーションに非があったとのことで、一定程度の完成分の金額は支払うこととなっています。
まとめ
IT導入・システム開発をITベンダーに依頼した場合、例え立派な提案書が出てきたとしても、あるいは契約をきちんと結んだとしても、実行中に受注側の問題でうまくいかなることはあります。
実際始めてみたら、受注側に発注事案における知見が不足していたり、体制を変更されてしまったり、プロジェクトマネジメントやコミュニケーションが不十分であったりと、様々な理由にて依頼したものが出来上がらないという事態に陥ります。
仕事を請け負った受注側のITベンダーにすべての責任を負ってもらうこともできますが、できればそうならないように事前に確認できることは行い、実行中もまめに確認していくことが必要となります。
コメント