IT導入・システム開発は見えにくい分契約をリスクなく交わしたいが、契約初期段階で既に失敗に向かっている

IT導入・システム開発を企画し、進めていくにあたってはITベンダーに委託することが多いでしょう。
ITベンダーはパートナーとして、プロジェクト成否を握る存在となります。

多くの場合は、プロなのだから任せておけば大丈夫、という気持ちでいる発注者も多いでしょうし、実際任せておいて問題ないケースもあります。しかし、失敗を繰り返した過去の教訓があったとしても、任せきりにしていて失敗することはあります。

逆の立場でベンダーから発注者を見ても、発注側の役割を期待していたが何もしてくれず、後々多くの問題が発生し、結果失敗した、という話は途絶えません。

そのような失敗を避けるために、当事者同士で契約を明確にしておき、リスクを軽減するように努めるのでしょうが、契約が初めから失敗に向かってしまっていることがあります。

IT導入・システム開発のプロジェクト作業が開始されたと思っていたが、途中で終わっており、そもそも契約が無かった

出版社にて情報管理のシステムを企画し、構築することとしました。それほど大掛かりなITシステムではないため、ベンダーと相談しながら、徐々に形が見えるようになってから、本格的に進める、ということとなりました。

このベンダーは、契約書を交わさなくてもある程度の仕事であれば受けてしまう体質のところであり、なんとなく作業は進んでいるという状態でした。

このまま完成してれば契約がなくてもなんとかなったかもしれませんが、この場合はベンダーの事情により、ベンダーが作業から撤退してしまいました。ベンダーも問題と思ったため、ここまでの作業請求はしませんでした。

ベンダーは経営事情により他に合併吸収される予定となっていましたが、その話が頓挫したことで急に資金繰りに問題が発生しました。よってそのまま仕事を続けるよりも撤退したほうが被害を少なくできると考えました。

しかし発注者側からすると、当てにしていたにも関わらず、撤退してしまうことで他に頼むか自分で対応するしかなくなりました。これまでの労力も考えると、被害を受けていると言えます。

このケースでは結果、発注側企業からの損害賠償請求に応じる必要はありませんでした。

契約書は交わされていませんでしたので、無かったことになった、といった単純なものではありません。契約書がなくても、口頭でも契約は成立するケースはあります。

このケースにおいては、設計段階で伝わっているべき仕様が伝えられておらず、ある程度は発注者自身が対応するつもりがあったということです。

お互いのところでもあったのですが、やはり契約そのものがない、といったケースは後から問題となります。特に発注したつもりでいたが、完成せずに逃げられる、といったこともありますので、お互いのために契約は明確にしておく必要があると言えます。

既存ソフトウェアを流用することで安い見積りで契約したが、実際は使えなかった

通信機器メーカーにて、組み込みソフトウェアの部分をITベンダーに委託して製品開発を行うこととしました。

発注側であるメーカーと受注側ITベンダーは何度か開発を行ってきており、製品仕様についてはお互いある程度理解できていました。

発注側は新製品は既存製品の内部ソフトウェアと類似部分が多いと思っていたため、ITベンダーとのその前提で委託内容を話していました。

ITベンダーは既存製品の既存ソフトウェアが流用できるとし、安い見積を提示し、契約しました。
発注側メーカーにおいては費用が抑えられたことから、採算に合うとし、プロジェクトを進めることとしました。

プロジェクトが進行していく中で、問題が発覚しました。

流用を当てにしていた既存ソフトウェアは、新製品では実はほとんど利用できないことが判明しました。

発注側メーカーとしては既に流用できる前提で予算を組んでいましたので、流用できないとなると新たにソフトウェアを作ることとなり、予算がなく頓挫せざるを得ません。しかし、発注側としては請負で発注しているため、流用できなかろうが、開発すべきだと主張しました。

一旦プロジェクトは中断しました。

結果、どうなったかというと、流用できず新たに開発する分は、追加費用を発注側が負担しなければならないこととなりました。

契約時における見積条件に流用を見込んでいることや契約前にそれ相応の回数議論を重ね契約に至ったことで、追加費用は正当なものとなりました。また、このケースにおいては、発注側が製品の仕様をかなり熟知していることが前提となっていることも、追加費用を裏付けるものとなっています。

このケースとは別なケースでは、受注側の見積オーバーに対する追加費用が認められず、受注側が赤字のまま完成せざるを得ない状況となったというものあります。見積条件や変更管理方法などが契約時点であいまいだったことで、受注側が認められないケースとなります。

見積のミスはその後のプロジェクト進行上に多大なる影響を及ぼし、結果頓挫となることもあります。
発注側として例え有利に契約ができているとしても、期待しているITシステムが実現できない、納期に間に合わない、自分たちの労力が増えた、などといった問題は発生してしまいますので、慎重かつ確実に見積を把握し、契約したいです。

IT導入・システム開発は先が見えないから段階的に契約したが、プロジェクトのゴールはあくまでも完成

衣料メーカーにて基幹システムを開発することとなり、ITベンダーからの提案によるパッケージソフトのカスタマイズでプロジェクトを進めることとなりました。

規模の大きさやカスタマイズ仕様を確定してから進めたいという意向から、お互いの合意の下、段階的な契約により進めることとしました。

ITシステムの開発における段階的契約は、一般的に行われており、要件定義、設計、開発・結合テスト、総合テスト、移行などの段階フェーズにて分けて契約を進めます。次工程内容が不明確であることから、前工程で内容が明確になってから進められることでリスクが減ることを見込んでいます。

プロジェクトは途中仕様変更の増加などの問題が浮上しましたが、段階的に進められ、最終段階の運用段階となりました。本番運用にはなっていますが、試験運用的な位置づけとなっています。

最終段階で問題が残っていたのは不幸でした。このプロジェクトにおいては、運用できないシステムとなっていることがわかりました。
多くのエンジニアが、データ修正を毎日実施しながらでないと運用することができませんでした。

発注側メーカーとしては、発注したITシステムは完成していないとして、プロジェクト中止を決断しました。
最終段階の手前までは検収していますが、完成していないとみなしているため、遡って支払わないという態度でした。

結果的には、すべてではなくある程度は返還されたということになっています。

リスクを軽減するために段階的に契約してきたにも関わらず、最終段階で完成できていないという最悪の事例となっています。段階的に契約したとしても、やはりプロジェクトは完成がゴールであり、本質的には全体がプロジェクトである、ということが基本的な考え方となるでしょう。

一方で、全体として捉えていたはずが、あくまでも段階的に見られた、という事例もあります。

その事例では多段階契約を行い、設計で一旦終了しました。設計ができているため、開発以降は自分と他の安いベンダーで実行することとしました。契約が段階で区切られているため、後の工程をどうしようが構わないように思われますが、この時の当初の受託ベンダーは次工程の発注もある前提で、前段階での契約を安くしていました。よって、次工程の発注を求めました。

結果としては、当初の受託ベンダーの見解は認められませんでした。契約が全体とは捉えられなかったということになります。

段階的契約をすることで失敗に向かう、ということではもちろんありません。IT導入・システム開発においては、段階的にしても、前段階で不具合が完璧に潰れているとは言い切れず、どの段階になってもやはり難しい場面となる可能性はあります。全体として包括的に見て管理していくことと、個別の契約もきちんとこなしていくということが基本となります。

まとめ

IT導入・システム開発において、契約が完璧であればプロジェクトが完璧となるといったことはありませんが、開始段階での契約は最低限必要なことを合意した上で進めるべきです。

まず、契約が未締結のまま進められていることは、お互いのリスクとなりますので、絶対に避けなければなりません。

次に見積のミスは失敗に直結しますので、できる限り認識相違がないようにしていかないといけません。特に過少見積でプロジェクトが進んでいくと、かなりの確率で頓挫します。
そして、段階的契約を全体包括的にも捉えたうえで、認識相違なく進めるということです。