オフショア開発失敗事例と対策：法人向けSaaS新規プロジェクトのスケジュール遅延
こんにちは、オフショア開発の一括見積もり・サポートサービスのオフミツの花井です。
オフミツでは、オフショア開発の依頼とプロジェクトサポートを行なっています。
そのためオフミツでは、様々なオフショア開発の事例を目にする機会が多くあります。
オフミツで生じたオフショア開発事例
他のオフショア開発会社へ依頼して、その後オフミツが引き継いだオフショア開発の事例
などから
オフショア開発の失敗事例と対策について紹介しています。
失敗事例の原因と対策をオフショア開発に活かしてもらえれば幸いです。
※内容について、守秘義務からプロジェクトが特定されない範囲で記載をしています。
また特定の可能性があり、説明に不可欠な部分においては、類似の内容に書き換えている箇所があります。あらかじめご了承ください。
オフショア開発の無料オンラインセミナーはこちら
オフショア開発一括見積もり・サポート：オフミツ
https://offmitsu.com?utm_source=note&utm_medium=blog&utm_campaign=organic_h
法人向けSaaS開発新規プロジェクトのスケジュール遅延
この失敗事例は、社内に開発者のいない中小企業が業界特化型の法人向けSaaSの新規開発を行うプロジェクトにおいて、オフショア開発を依頼したがスケジュール遅延が発生したプロジェクトの失敗事例を記載しています。
プロジェクトの詳細
要点
業界特化型の法人向けSaaS
業界の特殊な知識は必要ないが、データの保存や連携が業界特有の者がある
依頼者側の担当者は開発経験がない
予算は400-600万円
オフショア開発会社はインターネットから検索
プロジェクトの遅延が発生している状況でオフミツに相談
詳細
社内に開発者のいない中小企業が同業者が使うことを想定した業界特化型の法人向けSaaSの新規開発を行うプロジェクト。
依頼会社には、SaaSの開発経験があるものはいないため、依頼企業の中から担当者がプロジェクトを管理している。
担当者は開発経験がないものの、機能の箇条書きと画面のデザインを手書きで作成して、依頼資料を作成したのち、システム開発会社に問い合わせを行う。
その後、国内の開発会社では予算が足りないことを受け、オフショア開発会社への依頼に切り替える。
オフショア開発会社はインターネットで検索して、打ち合わせ後に依頼を行う。
プロジェクト開始後、６ヶ月でスケジュール遅延のため、納期の２ヶ月延期、その後、納品の再延期したタイミングでオフミツに相談した。
プロジェクト開発の経過と開発体制
要点
オフショア開発会社の打ち合わせで機能要件の擦り合わせを行なった
デザインは、下書きからオフショア開発会社が作成する
開発スケジュールは６ヶ月と開発会社から明示した
テストについては特に打ち合わせで話はなかった
開発中は、日本語を話すベトナム人担当者が発注会社の窓口となった。開発スタッフとは直接話をしない
開発中の打ち合わせは週に一回のテレビ電話とした
詳細
オフショア開発会社に問い合わせ後に、打ち合わせを行い、事前に順にしていた機能要件について擦り合わせを行いました。
デザインは下書きから、詳細デザインをオフショア開発会社が作成することに決まり、依頼後にデザインを作成しています。
テストについては特に取り決めはしていない。
その後、開発スケジュールは約６ヶ月と決定し、開発がスタートしました。
開発中の打ち合わせは、週に一回テレビ電話で日本語を話すベトナム人スタッフ（非エンジニア）と打ち合わせを行うことに取り決めました。
失敗までの経緯
要点
プロジェクト中では、経過の詳細情報はあまり共有されなかった
納期の２週間前に２ヶ月の納期延期があった
納期延期後に不具合が発生、納期の再延期がされた
詳細
開発期間中の打ち合わせや報告では、あまり開発スケジュールの詳細については共有されなかったため、そのまま開発が進められましたが、納品の２週間前になって、納期の２ヶ月の延期をしてほしい旨の話をされた。
その２ヶ月後に開発は終了したが、検収時にエラーが発生したため、不具合の修正を依頼した。不具合が多く、システムの品質が悪かったことと不具合の修正に２ヶ月必要という旨の話をされたため、対応策や他のオフショア開発に依頼できないかオフミツに相談した。
失敗の原因
このプロジェクトでは、オフショア開発の失敗の典型的な失敗が多くあります。
大きく分けて、
依頼会社側のシステム開発経験がない
開発中の情報共有が曖昧
が失敗の原因になります。
依頼会社側のシステム開発経験がない
依頼会社側のシステム開発経験がなく、また担当者もシステム開発について知識の少ない非エンジニアでした。
そのため、オフショア開発会社との協議で、専門的な内容を指定できず、機能要件やテストが曖昧なままでプロジェクトが開始されました。
機能要件について、詳細を協議することはオフショア開発会社の役割の一つでもあります。しかし、依頼会社側に不備に気が付ける知識がなかったため、その役割が不十分であることに気が付かずにプロジェクトが開始されました。
開発中の情報共有
定期的に情報共有を行なっていたものの、詳細については状況共有する方法を決めていませんでした。
そのため、情報の詳細が伝わらず、結果、スケジュール遅延が発生する原因の一つとなっています。
対策案
具体的にどのような対策をすれば、このような失敗を避けることができるのでしょうか？
オフショア開発の開始前に要件定義やデザイン作成のフェーズを作る
オフショア開発をする前に、要件定義やデザイン、テストの作成のフェーズを作って、正確な依頼ができる書類作成をします。
プロジェクト開始後には、時間を作って書類を作成することや機能の変更があった場合にスケジュールの変更や追加費用がかかる場合があります。
そのため、システム開発を要件を作成するフェーズと開発フェーズに区切って、着実に進めていきます。
できれば、発注会社側にも開発者などのシステム開発の知見があるサポートがいると望ましいです。
開発中の情報共有について詳細を決める
開発中の情報共有について、開発の知見がない状態でもわかるように情報共有をする取り決めをしておくことが大切です。
例えば、機能ごとにガントチャートなどでスケジュールがわかったり、必要なドキュメントについては、定期的に報告してもらうことなどです。
また、システム開発の機能ごとの開発終了時にチェックする取り決めをしておけば、より分かりやすくなり、スケジュール遅延やプロジェクト情報の誤解などを早く察知することができます。
オフミツでのサポートと経過
このプロジェクトでは、最初に発注したオフショア開発会社に依頼を続けることが難しいとのことから、オフミツのサポートのもと、別のオフショア開発会社に依頼しました。
そこで実際にオフミツで行なったサポート内容を説明します。
オフミツでは
前のオフショア開発会社からの引き継ぎ
プロジェクト情報の整理
発注書類の作成
次のオフショア開発会社の発注サポート
を行いました。
前のオフショア開発会社からの引き継ぎ
まず、発注会社側もシステムの情報を正確に把握していなかったため、前にオフショア開発会社から情報の引き継ぎが必要でした。
オフミツでは、前のオフシャア開発会社と打ち合わせを行い、不具合修正の目処などを話し合い、情報共有と引き継ぎを行いました。
プロジェクト情報の整理
次に前のオフショア開発会社から引き継いだ情報とシステムのプログラミングコードを調査して、プロジェクト情報の整理を行いました。
発注書類の準備
続いて、システム開発を次のオフショア開発会社に発注するための発注書類の作成を行いました。
前の機能要件やデザインでは不備があったため
機能要件の洗い出し
デザインのチェック
テスト項目の作成
プロジェクト中の報告スケジュールと情報共有方法の取り決め作成
非機能要件（サーバ情報やセキュリティ要件）の整備
などを行いました。
次のオフショア開発会社の発注サポート
最後に発注会社の担当者様と打ち合わせを重ね、予算と対応の条件などを話し合い、複数の該当のオフショア開発会社と打ち合わせを行いました。
その後、一つのオフショア開発会社と話し合いを進め、プロジェクトの引き継ぎが完了しました。
その後、プロジェクト中のサポートを行なって、予定通り新しいオフショア開発会社から納品が完了しました。
まとめ
今回は、スケジュール遅延と納品後の検収時の不具合の失敗例をご紹介しました。
こちらの失敗例は、よくあるケースです。
事前に対応することで、失敗を避けることが十分可能です。
失敗を避けたい方、また現在、失敗していてプロジェクトを立て直したい方はぜひオフミツのサポートをご検討ください
オフショア開発一括見積もり・サポート
https://offmitsu.com?utm_source=note&utm_medium=blog&utm_campaign=organic_h