オフショア開発特にひどい失敗例

はい、こんにちはオフラボの花井です。
今回はオフショア開発の失敗例の中でも特にひどい失敗例について説明をしていきます。

オフラボでオフショア開発をやりたい方が問い合わせをして、オフラボというオフション開発をサポートしながらやっていくサービスですので。オフショア開発を以前もやっていて今回のオフショア開発をやっていきたいんだけれども、失敗を避けていきたいというような形で依頼される方が多いです。

ですので、以前どういったところを失敗しているかところを聞いていくことが多いですけども、その中でもかなり酷かった例について今回の説明をしていきたいと思います。

オフショア開発は失敗はしやすいと言われる部分があるんですけども、オフショア開発を含めてシステム開発というのは失敗しやすいサービスだと言えます。

すごく多くの情報をやりとりしながら複雑なものを作っていきますので。やはり大きいものは失敗しやすい、小さいものがあれば失敗しにくいものなんですけども、そこはオフショア開発側がプロですので、うまく整理しながら進めていくことが通常です。

そう言っても失敗しやすいというところは否定ができないというところで、お互いで頑張っているんだけども、失敗してしまうというような例のは多くはありますけども、今回の例そういうものではないです。
明らかに酷いもので、頑張っていくとかそういう次元じゃないんです。

オフショア開発アカデミーのご案内

オフショア開発について体系的に学べる情報サイト【オフショア開発アカデミー】では、オフショア開発の全体像やポイントを無料で学ぶ事ができます。

ご興味がある方はこちら

https://offshore-dev.com/ 

技術選定

一つ目は技術選定にかなり問題があったケースです。これどういうことかと言いますとちょっと具体的な形になってしまうんですけども、試作品を作りたいと言ったお客様がいたんです。

できるだけで安く作りたいのでオフショア開発を利用しましたと、ただ、試作品をリリースしたんだけども、全然うまく動かないっていうところで、次にオフラボに相談されてきたというようなお客さんです。

よくよく中を見てみると、技術選定中で試作品にはあまり使わないような形で、具体的にはAngular.jsというフレームワークを使っていたんです。Angular.js自体は有名なフレームワークですし、それ自体は全然悪くないんですけど、Angular.jsは何かこう間違えたような形で使っていて、すごく不安定なシステムになっていました。

その不安定なシステムになっていて、動かない試作品なので、できるだけで早くリリースをして、ニーズを見たいんだけども、その動かない部分を直していくにはAngular.jsが邪魔になって、すごく難しくなっていたんです。

ですので、動かないし直すのも大変でお金もかかるというような状況が発生していました。

そのお客さんも結構困っていって、どうしましょうかということを相談はしていたんですけども、お金をかけながら直していくというような形で収まってきました。

ここでやっぱり試作品の時点でAngular.jsというフレームワークを採用したということも悪いですし、最後まで安定しないまま納品したという前の開発会社は、もう凄く態度も良くなかったんじゃないかなというところです。

その開発会社の方とも話しましたけども、やっぱり態度は良くなかったです。もう知らないですみたいな感じで言われてしまったので、ちょっと諦めて、こっちで対応した経緯のプロジェクトでした。技術はなかなか難しいですけども、しっかりチェックする必要があります。

ドキュメントがない（人質）

二つ目もひどかったケースのです。ドキュメントがないところでも、システム開発はドキュメント内容だとかドキュメントの不備というのはそれほど問題になることは多くないです。

なぜかと言うと、大体キュメントは書かないと開発できないことも多いですし、大事なことっていうのは指示に残しておかないと、後々チェックできないです。

どうだったかなっていうのを確認ができないので、ドキュメントは相手が作らなくても出来上がってくるものでもあります。その中でドキュメントを最後に納品してくださいとかドキュメントをしっかり整理してくださいというのは契約上の問題だとかにもなってくるので。

そこについてドキュメントをしっかり整理したものがあるかないかというのはよくある話というかトラブルになるケースはあるんですけども、今回はそういったものではないです。

ドキュメントがないことで、その中にパスワードやアカウントの情報というものがあったんです。何が起こったかと言いますと、オフショア開発の依頼者側と開発会社側でトラブルになっていて、トラブルの内容は色々あったんですけども、お金についてはそういった納品物に落としどころが見つかってきたんですけども、その落としどころで有利に進めたいがゆえに開発会社がドキュメントが渡すことを人質に取ったんです。

これどういうことかと言いますと、パスワードとかアカウントの情報を教えてほしいんだったら、その条件をのんでほしいというような言い方をしてくるんです。

これはちょっとこんなことする人いるんだと思うぐらいの酷さだったんですけども、ドキュメントがないということで、その納品するシステムを今後も使っていきたい、改善していきたいんだったら、この情報必要ですよねみたいな感じで、言ってきた開発会社が来ました。

これもお客さんすごくかわいそうな形だったんですけども、何とか必要な情報だけ聞き出して、ドキュメントのようなものっていうものはもらえなかったんですけども、なんとかパスワードとかアカウント情報というものだけもらえました。その後、開発継続できたっていう経緯のプロジェクトです。

サーバーが開発会社

最後の三つ目もひどかったです。サーバーが開発会社の契約になっていたというところです。
これはサーバーだとかデータベースだとかドメインもそうなんですけども、基本的には当然なんですけども依頼する会社側のものなんです。ですので、かかわったデータだとか、開発中に使ったデータっていうものは開発会社のものではなくて、依頼者側にやっぱり権利が帰属するのが通常だと思います。

そこはなぜかサーバーを開発会社が契約をしていて、その納品の時に色んなトラブルがあったんです。作ったものが間違ってたとか、うまく動かないところがあるとか、そういったトラブルがあって、うまく落としどころを見つけながら、ここまで進みましょうとかここは契約内容に入ってるので、しっかりやって下さい。

そういった形で進めていくことが多いんですけども、これは人質みたいとっています。

サーバーが開発会社なので、どうするんですかみたいな感じになったわけです。納品の時にこれは開発会社がうちのものなので納品できませんと、納品物がほとんどない状態になっちゃうんです。どうなるかなと思いながら、どうするんですかというような話をしながら、やっていくとほとんど納品物が無くなってしまいます。

これはどういう契約なんでしょうみたいな形になって唖然としたんですけども、ですので、サーバーを開発会社が契約していること時点でちょっとおかしいなと思いますし、それがトラブルになった時に人質の納品できませんというような内容もどうかと思うんですけども、ですので、ここもひどいなと思った事例です。

結局プログラムのコードだけ別で納品してもらって、サーバーは次のオフショア開発会社に改めて作ってもらって構築してもらって、そこでサーバー載せ替えっていうような形で引っ越しする形です。

引っ越しする形で対応したというプロジェクトでした。

これも余分にお金がかかってしまったところで、お客さんがすごくかわいそうだったところなんです。

結構ひどかったです。ですので、オフショア開発のひどい例として色々なトラブルがあるんですけども、こういった致命的なトラブルっていうのも時々起こります。

契約内容のチェックでここに限りますどういったものを納品されてるとか、どういったものはドキュメントとして、しっかりこっちに伝えてくださいとか、契約する時にはちゃんとこっち側契約するので、伝えてくださいと勝手に進めないで下さいとかそういったことは事前に契約内容で決めておいて、こういった致命的なトラブルが起こらないように進めていくことが大事だと思います。

今回はオフショア開発のひどい失敗例ということでお話させていただきました。これはかなりひどい例です。めったに起こらないんですけども、やっぱりこういうの起こるのかもしれないと思って、先に対策しておく、気をつけておくというのが大事になってきますので。こういうところで対策をして、オフショア開発を利用していただければなと思います。

オフショア開発ラボ型に関する興味がある方はぜひオフラボ・オフミツをご利用ください。

では、今回はこれで終わります。