IT導入・システム開発のプロジェクトが頓挫するというのは、それほど頻繁に起きているわけではないかもしれませんが、頓挫までいかなかったとしても、発注側と受注側が険悪な状況となることは、しばしばあるのではないでしょうか。
頓挫を迎えるようなプロジェクトの末期状態とはどのような状態なのでしょうか。
ITシステムが完成していない
ITシステムが一部機能が実現できないという事例はあります。
医療関係のタブレットシステム機能のうち、機器の遠隔操作をする機能があったのですが、この事例においては、技術的問題が解決されず動きませんでした。
機能としては実装さているものの、処理がすぐ固まってしまい、実用に耐えうるものではありませんでした。
ベンダーは完成していると主張したのですが、契約当初の提案書にも載っているものであり、実用に耐えないものであれば、やはりその主張は通らない、ということになります。
技術的な難易度による問題もあるのですが、実現のレベルについて当初明確でなかったというのも問題でした。
発注側は一部機能が使えないまま受け入れることとなり、受注側は工数を掛けて作成したものの支払ってもらえませんでした。
途中段階で早々と頓挫した事例もあります。塾のシステムを構築するプロジェクトでの出来事でした。
比較的規模のある開発であったため、まずシステム要件定義を契約し、その後段階的な契約としました。
要件定義でシステムとして実施することを決めた後は、設計となります。設計の中でも、見える部分の設計と内部の設計があります。
見える部分の設計は基本設計と言われますが、このプロジェクトにおいては、基本設計段階で課題が山積しました。
システム要件定義を実施したに関わらず、設計に入り少しシステムが見えるようになってから、想定しているものが違っていることが見え始めました。
早い段階ではあったのですが、塾側としてはあまりにも想定外が多く、課題潰しに時間も要するため、中止を決定しました。
受注側でのあるITベンダーは実施した作業分までの支払いを求めることになりますが、設計は完了していないという発注側の主張とぶつかりました。
結果、この場合は一定程度の作業完成が認められたことにはなりました。
一見システム要件定義が形になると安心することもあるのでしょうが、よく見るとスカスカだったという事例でした。
アジャイルでもITシステムは完成しない
もう一つの事例として、アジャイルでの開発事例を挙げます。
アジャイルとは、優先順位の高い機能から開発・リリースすることを一定期間で行い、繰り返していく手法となります。
ITシステムは目に見えにくいので、だんだんと希望に合うものに近づかせるという意味では有効な手段です。
初めにやることを決め要件定義を行い、その後設計、構築、テスト、完了と一連の作業で進めていくウォーターフォール型とは違うということになります。
繰り返しリリースしますので、完成しなかったり頓挫したりするといったことは起こり得ないのではないかと思われます。
しかし、結果的に完成していないとみなされた事例がありました。
ECサイトの構築をアジャイルで契約していたのですが、結果からするとITベンダー側はそのサイトを構築する技術が不足していました。
できない部分を自分ができる技術に捻じ曲げて対応していたのですが、なかなか動くようにならず、残念ながら頓挫したということなります。
アジャイルの場合、契約が完成物納品を前提とした請負契約ではなく、一定期間をエンジニアが稼働して、繰り返し開発を行う、という準委任契約となっていました。
ITベンダーは準委任契約の時には、完成しなくても作業した日数分は支払ってくれるものと油断しがちです。
しかし、この事例では許されませんでした。準委任であっても何の完成責任がない、というわけではないということです。
アジャイルはいい面はもちろんありますが、発注側からするとずるずると完成が引き延ばされることにもなりかねないので、最初の契約時点での注意が必要ですし、実行段階においても進み具合をよく見ておく必要があります。
発注側仕様決定の遅延により未完成
どのようなITシステムを作成するか、企画・コンセプト段階からコンサルタントに依頼し、基本設計まで実施してもらったにも関わらず、完成段階に至っても仕様が決定せず、結果完成しなかったということがあります。
メーカーの経営情報システムの頓挫事例を挙げます。
経営情報システムは各所より情報を集めて経営として必要な情報を分かり易く分析し、見せるものです。
コンサルタントが基本設計まで行った後、ITベンダーが詳細設計を行っていきました。
完成間近の段階にはなったのですが、何かイメージと違うということで発注側と受注側で意見の相違が発生します。
発注側はデータの種類や切り口、データ反映タイミングなど、多くの仕様変更を要求しました。
これらは、発注側からすると実現しなければ、完成とは認められないような仕様でした。
ただし、実施すると費用は掛かっていきます。
結果発注側と受注側は揉めて、頓挫することなります。
この事例では、コンサルタントが作成した基本設計の不備が問題の起因となります。
しかし、ITベンダーはその不備を正しながら進め、さらに仕様追加の要求にも一定程度対応してきたということで、咎められませんでした。
つまり、コンサルタントの基本設計は発注側がよく確認したうえで、ITベンダーに発注しないといけないということになります。
また、経営情報といった要求が明確になりにくいものは、仕様の確定に遅延が発生しがちなので、実行範囲を明確にするよう注意が必要です。
未解決課題が累積してしまったことにより頓挫
もう一つ、典型的な末期状態について事例を紹介します。
未解決な課題が累積してしまったことによる頓挫の事例です。
ここで課題といっているのは、未決定な事項を含む完成への進捗を妨げているもの、あるいはこのままいくと進捗を妨げる可能性のあるものとしておきます。
ｅラーニングシステムの開発での事例です。
ｅラーニングシステムにおいては、多くの一般ユーザが使用するため、操作性の仕様決定に難航していました。
基本設計の段階で仕様が確定したいところですが、発注側にも様々な理由はあるにせよ、その後も決まらないことが多く、結果課題として累積していくことになります。
仕様の面だけでなく、ラーニングコンテンツを発注側から受注側に提供し、開発およびテストにて利用することになっていましたが、コンテンツ提供が遅れていました。
コンテンツはｅラーニングシステムと並行して作成していくつもりだったようですが、実際はコンテンツが用意できずにいました。
仕様の確定にデータ移行用データの未提供が加わり、進めていく上での課題が積みあがっていくことになりました。
受注側であるITベンダーは期限をもって、課題の解決を発注側に要求しましたが、要求には結局応えられませんでした。
発注側はこのままではまずいと思ったのか、システムは完成していないとし、契約解除に向かいました。
しかしやはりそれは認められません。
本事例は、発注側の実施すべきことの管理、いわゆるプロジェクトマネジメントの欠如による破綻の典型的な事例となります。
まとめ
IT導入・システム開発のプロジェクトにおいて頓挫の末期状態というのは、目も当てられない状況です。
金額や労力の問題があるので、やめようと言っても簡単にやめられるわけでもありません。
ここまでの事例でわかるように、受注側の力量が不足していてITシステムが動かないということもありますが、発注側の責任で頓挫したものもあります。
発注側と受注側の双方が、お互いの認識のずれがないかを逐次確認し合える関係になっている必要があるでしょう。
コメント