見出し画像

【オフショア開発失敗事例】相見積もりで一番安かった開発会社を選んだ結果

この失敗事例はオフショア開発請負型で、費用の比較のみで開発会社を選んだために、開発が完了しなかった失敗事例です。
オフショア開発アカデミーのご案内
オフショア開発について体系的に学べる情報サイト【オフショア開発アカデミー】では、こちらの内容やその他の情報について学ぶ事ができます。
ご興味がある方はこちら

失敗の解説

複数のオフショア開発会社から見積もりを取得すると、様々な価格の見積もりを取得することができます。システム開発の費用について、内容がわかりにくく、一番安い開発会社を選んだ結果、システムの開発が完了しなかった事例です。

プロジェクトの主な問題

この失敗事例では、オフショア開発会社が当初に見積もった工数を大幅に超えたこと、また開発開始時に機能要件が曖昧だったため、納品の状態が曖昧になり、納品の状態が依頼者から主張できなくなったことです。

上記のことから、オフショア開発会社の利益が減り、対応できなくなったことと納品の状態が曖昧なため、対応する義務や責任の所在が曖昧になったため、対応不可になりました。

具体的な対策方法

オフショア開発の費用の内訳は、開発者やブリッジエンジニアの費用と開発工数に余裕を持たせた費用の2つに大きく分けることができます。

開発者やブリッジエンジニアの費用は、スキルが高ければ、高くなります。またブリッジエンジニアは日本人が対応する方が費用が高くなります。

この費用が高いと、経験が豊富な開発者が開発することで、開発スケジュールの遅れが発生しにくいことや追加機能を開発するときに技術的負債が少ないことから費用が少なくなるメリットがあります。ブリッジエンジニアが日本人の開発者の場合は、的確な開発指示を行うことや開発工数の削減などをメリットがあります。

まず費用が安くなる要因を理解し、その後の問題の発生と比較する必要があります。

また、問題が発生したときに、主張できない事態を避けるため、納品時の状態を明確にする必要があります。

具体的には機能要件の詳細資料の作成とテストケースの作成を行う必要があります。

その後のプロジェクトの経過

この失敗事例では、機能の不十分を主張できる要素がなく、契約書やドキュメントに記載されている内容では、納品の状態を飲まざるを得ない状況でした。

そのため、お客様は、開発したオフショア開発会社には交渉せず、そのままの状態で納品してもらい、弊社での残りの修正を行いました。

この記事が気に入ったらサポートをしてみませんか?