とあるIT屋の独白

ITや経営について主に書きます

システム開発の訴訟とか見積りとか

少し前ですが、三菱食品システム開発プロジェクトにおいて、損害賠償請求が訴訟されたことが話題になりました。今回はこの件を事例にシステム開発の見積りについて、取り上げてみたいと思います。
まず、三菱食品の経緯ですが下記の記事にまとめられています。開発の遅延により、SIerであるインテック社に100億円を越える賠償を請求しています。ここでのポイントはインテック社に支払った金額以外にも、他社に支払った金額や現行システムの稼働コストも含まれている点です。

三菱食品、インテックに約127億円の損害賠償求める システム開発失敗理由に】
https://www.zaikei.co.jp/sp/article/20190306/498483.html

おそらくインテック社の開発遅れがプロジェクトの失敗の要因であって、他の開発費も請求されているものと思います。
インテック社の担当が3000社と取引するEDIシステムで、個社毎に処理を組まなければいけなく、聞くだけで胸焼けしそうな内容。真っ先に気になるのは開発の見積り。見積りと実態で乖離があるために失敗しかけるプロジェクトは、私もいくつか経験しました。今回の見積りに関して、下記の記事の分析が参考になります。

三菱食品インテック訴訟の見積もりを分析】
https://blog.aristo-solutions.net/2019/03/blog-post_6.html?m=1


個人的には問題が2点あると思ってます。
一点目は、上記の記事にある通りギリギリまで価格を下げた見積りに対して、工程毎の山積みが適切に行われていないとみられる点。山積みに関しては下記のサイトを参照。

【山積み表】
https://www.otrs.jp/kaizen/glossary/workloadchart.html

 

現場によっては山積みと呼ばれていないかもしれませんが、個人的にはこれは見積り時にある程度の目処をもっておく必要があると思ってます。プロジェクトは進めたけど要員が足りなくなって、遅れるなんて話はよく聞くので。
2点目は使用するパッケージやツールの選定が、適切であったか。今回であればJBoss BRMSが使われてるわけですが、果たしてプロジェクトの達成に適合したものだったのか。実現可能性を検討する作業がフィジビリティスタディと呼ばれるもので、ここがないがしろになると入れたはいいけど使いものにならなかったり、スクラッチでの開発が大量に発生したりしてしまいます。

フィージビリティスタディって何?いつやればいいの?】
https://www.brainpro.jp/itmgt/pjmgt/20050916095008

また、大規模開発の一括受注はベンダーにとってやはりリスクがあって、アジャイル的な進め方も候補にあげてプロジェクト全体の失敗リスクを下げる方法も考えられます。まぁ、こういうニュースがあると、無難なSES契約に流れてしまう気持ちも分かりますがね。。