top of page

オフショア開発で開発費用の高騰、納期の延期が発生した失敗例

更新日:2022年5月27日

オフショアについてはマイナスのイメージを持たれている企業も多いと思います。しかし、コツをしっかりと抑えていれば開発費を安くできるため有益な選択肢だと思っています。


最近ではオフショア開発の利用がOKでもフロントには日本人必須という条件が多くなってきています。



【失敗例】依頼したものと違うものが出来上がった


限られた予算でボリュームのある開発をしなければならず、既存の開発会社に依頼を出したところ予算感が合わずに断られてしまいました。


そこで新規の開発会社募集に踏み切り相見積もりの結果、オフショア開発であれば予算が合うことから発注をしました。


社内にオフショア開発の知見を持つ人材がおらず、一抹の不安はありましたがブリッジSEが日本語に堪能であるとのことでしたので何とかなるだろうと発注をしました。


上流工程ではブリッジSEとエンジニア1名、開発フェイズでエンジニア3名を追加、合計5名でのプロジェクトになりました。


社内の業務管理システムの構築ということもあり、実際に使う部署や管理する部署からも企画会議に参加し、要件の洗い出しを行ったことで要件定義、基本設計書も練り込むことが出来ました。


週1回のオンライン会議にて進捗状況を確認する流れで本格的に構築に入り、1か月ほどしたところ言語の問題が深刻化していることに不安を覚えました。


ブリッジSEは日本在住の外国籍の方でJLPT(※日本語検定)2級を持っているということでしたが「話せる」ことについては問題ないのですが「理解」については怪しいところが目立ちました。


エンジニアに限っては全く日本語が話せないのでブリッジSE頼みでしたが、連絡が取れないなどの問題が発生しました。


また、定例会議で開発エンジニアが突然変わっていることが何度もありました。


アサインするエンジニアについて決まりを作っていなかったのですが3か月で3人ほど入れ替わっており、引継ぎがしっかりできているのか不安になっていました。


構築が完了しテスト環境下で稼働説明を依頼したときに問題が発覚しました。


要件は満たされているのですがこちらがお願いしていた構築方法ではなかったのです。

この辺りを問い合わせると最終的に要件は満たされているの一点張り。


さらに問題だったのはブリッジSEと連絡が取れなくなったり、なるはや回答を依頼しているのに回答が戻るまでに2日かかったりと連絡体制が確立されていないことがわかってきました。


日本の開発会社であれば30分で終わる会議なども、説明を1つ1つしていかなければ先方の理解度に不安があり、会議はだいたい1時間、長いと2時間になっていたことなどもあり最終的に納期が2か月ほど遅れる事態にまで発展してしまいました。


結果として当初想定していた予算を超える事態になり、依頼しているものと違うものが出来上がり、修正を依頼すると修正時間がかかりリース日の修正が必要となるため、こちらが譲歩するような形で無理やりリリース日に間に合わせました。



【失敗の理由】言語問題と商慣習、役割の取り決め


オフショア開発は使い方さえ間違わなければコストを抑えることが出来ます。


さて今回の問題において問題点を洗い出してみます。


・言語問題(日本語でのやり取りと理解度)

・商慣習の違い

・プロジェクトメンバーの固定化

・報告義務の強化


言語問題


オフショアで一番よく話題に上るのが言語問題です。日本語はマイナー言語であり行間を読ませる言語です。


言葉の裏側にある真意を読み取る言語


です。

言語の裏にある真意を外国人に完全理解してもらうのは不可能だと思っています。


言語問題による失敗開発を防ぐ方法として、依頼している案件と同じような案件を手掛けた過去実績があるメンバーをアサインすることが挙げられます。


言葉の問題は「話せる、読める」ということではなく「理解度」が一番大事です。


いくら饒舌に話が出来ても理解できていなければ意味がありません。

JLPTのレベルで判断するのではなく、経験の問題でカバーするしかないのです。


理解度を高めるには過去に同じような仕事を経験しているエンジニア、ブリッジSEにお願いするしかないと考えています。


商慣習の違い


日本の商慣習はホウレンソウが絶対です。また、事後報告は仕事において嫌われます、特に開発業種では人月による工数計算が一般的なので事後報告はNGです。


ではこの問題をクリアするにはどうすべきでしょうか?


日本式の商慣習に合わせてもらうしかないです。例えば、こちらから進捗をヒアリングしても先方から回答が無いことがあります。


理由をきくと、調査中で報告すべき進捗が無いから回答しなかった、という事例がありました。


進捗が無いから話すことが無い=話しても時間の無駄になるので構築に専念したい

進捗をもらう=詳細を把握することで今後の開発を効率化したい


どちらも向かっている方向は開発工期の短縮化です。しかし、実際には開発期間が延びてしまい失敗開発になってしまいました。


コミュニケーションによる商慣習については日本式に合わせてもらうことでリスク回避するしかありません。


そして設計まで自社で行うことが大切です。

詳細設計まで行うことで、フリースタイル構築が発生する確率を下げることが出来ます。


今回の失敗例も詳細設計書まで自社内で作り込むことで失敗開発を避けることが出来たと考えます。


プロジェクトメンバーの固定化


ブリッジSEが開発途中で変更になってしまう事態は避けなければなりません。

また、構築を進めるエンジニアが頻繁に変わってしまうことも問題です。


経験上、引継ぎがうまく出来ていると思えた記憶はほとんどありません。

半年ほどのプロジェクトであればメンバーの固定化をお願いすることはとても重要です。


1年以上のプロジェクトになるとメンバーの完全固定化を承諾してくれるオフショア会社はほとんどありません。


あくまでも他社の事情ですからこちらから無理強いはできません。


限られた環境の中で有効な手段として、メンバーの固定化は失敗の確率を下げることに大きく影響します。


報告義務の強化


進捗管理表、課題管理表など報告を徹底化することで、明後日の方向に向かった開発を避けることが出来ます。


慣れてくれば週1のオンライン会議でも問題はありませんが、初めてのメンバーで開発を行う場合、初月だけでも毎夕方に進捗報告を行い進捗の共有を行うことが大切です。


付け加えるならば、進捗報告会議の前に進捗管理表と課題管理表への記載を必須としておくことで会議の時間を無駄にせずにすみます。


報告義務を強化する一番のポイントは、「言わなくて大丈夫」と思っている箇所の見つけ出しです。


この認識のズレはオフショア開発を行うと必ずと言ってよいほど発生します。


また、認識のズレはオフショアに限らず国内開発会社でも頻繁に発生します。

ズレは常に発生するのだ、と普段から意識しているだけで失敗リスクの回避確率が上がります。


ちなみに弊社では


オフショア開発会社様ともパートナー提携をしている弊社で最近多くなってきている事例を書いておきます。


現在の開発で主流になってきているのは、クライアント様とやり取りをするポジションは日本人のアサインをお願いします、というものです。


このようなケースでは、弊社がパートナー提携しているオフショア開発会社様に日本人エンジニアをアサインしプロジェクトを成立させています。


弊社のエンジニアがクライアント様とヒアリングを行いその後、ブリッジSE(コミュニケーターの場合もあります)と開発方針についてすり合わせをすることで構築に従事するエンジニアに的確な指示が出せるような体制を取っています。


ブリッジSEが日本人というオフショア会社も増えてきてはおりますが、エンジニア経験が少ないと仕様が理解できていないことがあるため失敗率が上がってしまいます。


設計、構築フェイズでは経験が豊富なエンジニアが好ましいのです。


そのため弊社では外国人とやり取り経験のあるエンジニアをアサインすることでクライアント様の要望をしっかりと把握できる体制を取っております。


尚、インドやフィリピンなど英語圏、中国を含めた中国語圏のオフショア会社とお仕事をする場合、弊社でドキュメントを翻訳するなど徹底して認識ズレを起こさないような対応を行っています。


bottom of page