失敗事例から学ぶ、オフショア開発成功への9つのヒント
昨今、ITシステム開発の現場では、オフショア開発という選択肢は一般的となりました。しかし、中には当初に想い描いた通りにはプロジェクトを進めることができなかったという声も聞こえてきます。そこで、本記事では、オフショア開発の失敗事例から学ぶ、失敗原因や成功へのヒントにについて紹介します。
オフショア開発で陥りやすい失敗事例
まずは、オフショア開発での失敗事例としてよく耳にする話題をいくつかご紹介します。
失敗事例１：仕様伝達に失敗し、納期が遅延してしまった
発注元の担当者は、発注先のオフショア開発会社に日本語ができるブリッジSEをアサインしてもらい、仕様と作業内容を文書にまとめてブリッジSEとミーティングを行って説明した。
ミーティングは日本語で行ったが、ブリッジSEも要求をよく理解してくれているように見えたため、日本語のコミュニケーションでも問題ないと判断していた。その後の進捗状況の確認でも、ブリッジSEからの報告は常に「問題なし」という回答があり安心していた。
しかし、次第にブリッジSEから1日に数回の質問が毎日のように届くようになった。担当者はその質問への回答作業に追われる日々となってしまい、レビューによる品質確認を行う時間を確保することができぬまま納期を迎えてしまった。
これは、オフショア開発会社への仕様の伝達がうまくいかずに作業の遅延が発生してしまったケースです。原因は、発注先の窓口となるブリッジSEとの日本語による意思疎通ができたため、仕様伝達のハードルは低かったと思い込んでしまったことにあります。
しかし、発注先のオフショア開発会社の窓口となるすべての人が技術面について知識を持っているとは限りません。 中には、主に通訳を役割とするコミュニケーターと呼ばれるべき人材にブリッジSEという肩書きを与えているオフショア開発会社も存在します。
このような失敗を回避するためには、窓口となるブリッジSEの日本語の言語能力の確認にとどまらず、そのブリッジSEの職務範囲や職能まで確認しておくことが大切です。
もし、オフショア会社の窓口担当者の技術的な内容の理解度に不安を感じる場合には、そのコミュニケーターを介して仕様伝達を行うのではなく、直接現地のSEと英語でやりとりを行う方がお互いの理解度を確認しながら進めることができるでしょう。その方が結果的には二度手間の発生を抑制でき、間接コストも削減することができるでしょう。
失敗事例２：度重なる仕様変更により、コストが増大してしまった
全体の仕様が確定しておらず、一部の仕様は暫定的なものとして見積を行い、そのまま見切り発車で発注した。
暫定部分は、発注後に五月雨式に仕様伝達を行ったものの、その後も仕様変更が繰り返され曖昧な仕様が残ったままだったため、ドキュメント作成やメールやチャットなどの仕様伝達の工数が増大した。
また、開発現場でも仕様の混乱や手戻りが発生し、当然スケジュールも大幅に遅延して収拾がつかなくなった。そのため、開発途中でブリッジSEと仕様確認の仕切り直しが必要となった。
その結果、コミュニケーションと開発の工数が増大し、最終的には、見積金額を大幅に超えてしまった。
これは、仕様が曖昧なまま発注したうえに仕様変更を繰り返した結果、コストと納期がオーバーしてしまったケースです。国内開発の発注においても発生し得るような例ですが、走りながら徐々に要求仕様を決めていくというやり方は、典型的な日本型の開発アプローチと言えます。
オフショア開発をこのような国内開発の感覚で行ってしまうと、信頼関係にひびが入ってしまい想像以上にトラブルを拡大させてしまう危険性があります。信頼関係がなければプロジェクトが失敗する確率は限りなく高くなるでしょう。そうなれば、金銭面でもトラブルに発展しまう可能性があります。
仕様を変更すること自体は問題ないのですが、問題は仕様変更をスムーズに進めるための段取りとコミュニケーションにあると考えられます。オフショア開発ベンダー側の状況を考慮して伝達することが大切です。
失敗事例３：日本語での意思疎通の失敗
ある過去に一度、開発を依頼したことがあるオフショア開発会社に、新規のプロジェクトを依頼した。初めて発注した際は、日本語でのコミュニケーションに多少の不安を抱いていたものの、アサインされたブリッジSEがとても優秀で、日本語スキルや技術レベルは事前の説明通りにレベルが高く、プロジェクトは無事成功を収める事ができた。
そこで、同じオフショア開発会社に別のプロジェクトを追加発注したところ、アサインされたブリッジSEの日本語スキルが低く、前回のブリッジSEと比較すると大幅に劣っていた。
事前に、コミュニケーション言語は日本語で行うとの取り決めていたものの、メールで質問を受け付けても一体何を伝えたいのか理解できないようなことがかった。そこで英文でのやりとりも試してみたが英語もさほど得意ではないらしく、結局、意思疎通はなかなか改善せず苦労した。
オフショア開発会社からの事前説明での「日本語コミュニケーションが可能な優秀な技術者が在籍している」との話に期待したところ、その事前期待が結果と異なっていて失敗したケースです。
たしかに、最初のプロジェクトにアサインされたブリッジSEは期待以上の能力を発揮してくれたため、次のプロジェクトでも期待するのは自然なことです。
初めての取引の際は、どこのオフショア開発会社もエース級の人材をアサインしてくるとうのはよくあることです。とはいえ、そのように優秀な人材が社内に多数在籍していて、発注者が希望するタイミングでいつでもアサインできるかどうかはまた別の話です。
このケースでは、エース級の人材は少数しか在籍していなかったり、または優秀な人材は別のプロジェクトに参加していて自社の案件にはアサインできなかったのかもしません。
顧客の要望に応じて、最適な人材を安定的にアサインできるかどうかは、オフショア開発会社それぞれの事情によって大きく異なります。特に、人材の豊富さは事業規模が大きいオフショア開発会社の方が有利でしょうし、また特定分野の人材であれば、小規模でもその分野に専門特化したオフショア開発会社なら最適な人材を確保できるかもしれません。
なお、日本市場に注力して事業を展開しているオフショア開発会社では、社内で日本語教育を行っていることは珍しくありません。しかし、その教育内容や方法も企業にとってさまざまで、営業やブリッジSEに限定して教育している場合もあれば、その他のエンジニアも含めて行う場合もあります。
また、日本語認定資格の取得を奨励し、資格取得手当てなどの制度を設けている企業もありますし、採用段階で選考基準として日本語のスキルレベルの高い人材や、日本国内でのビジネス経験や日本企業とのプロジェクト経験がある人材を多く採用しているケースもあります。オフショア開発会社選びの際には、そのような日本語教育のへの取組み状況状況も確認しておくとよいでしょう。
オフショア開発を成功に導くための９つのヒント
先述の陥りがちなオフショア開発での失敗事例のような問題は、実は日本国内での日本人エンジニアによる開発でも起こり得ることです。オフショア開発の現場では、とりわけ言語、文化、国民性の違いによるコミュニケーションのギャップが問題を生じさせる原因となる場合が多いです。そこで、ここではオフショア開発での失敗を回避し、開発プロジェクトを成功させへと導くための9つのポイントを紹介します。
1. コミュニケーション言語のスキルレベルを確認する
日本語や英語など、オフショア開発会社とのコミュニケーション言語を取り決める際には、コミュニケーションに支障がない程度の言語スキルを持っているかを事前に確認しましょう。
例えば、コミュニケーション言語を日本語にすると取り決めた場合、そのスキルレベルを客観的に把握する一つの目安としては日本語検定試験（JLPT）があります。日本語能力試験は、日本国内および海外で日本語を母語としない人を対象として日本語の能力を測定し、認定することを目的として行う試験です。試験はN1からN5レベルまでの5段階に分けられており、N1は最も難易度が高くなっています。
N1は幅広い場面で使われる日本語を理解することができるレベルで、N2は日常的な場面で使われる日本語の理解に加え、より幅広い場面で使われる日本語をある程度理解することができるレベルとされています。そうしたことから、外国人を採用する企業では、在留資格・ビザ取得の観点からもN1〜N2を選考基準としている場合が多いようです。
N1は日本語ネイティブでも満点を取るのが難しいレベルの試験と言われていますので、N1保持者であればビジネスシーンでの活躍を期待できるでしょう。しかし、必ずしもすべてのエンジニアがN1レベルを取得している必要はなく、担当業務に合わせて日本語能力がどの程度必要なのかを基準とするのがよいでしょう。オフショア開発の場合では、ブリッジSEの日本語能力は重要ですが、オフショア国現地で働くエンジニアには必ずしも日本語スキルは必要とされません。
なお、日本語能力試験の問題は文章読解と聴解のみのため、書く、話す、といった能力は測ることはできません。そのため、ブリッジSEをアサインする際には、面接やディスカッション、メールのやりとりなどを取り入れると良いでしょう。
2. 日本との文化や国民性の違いを認識し、明確に意思表示する
日本と海外では、考え方や仕事の進め方も異なります。日本では、物事をこと細かく伝えなくても相手は当然のごとく察してくれるだろうと期待してしまいがちです。しかし、海外では、相手に明確な意思表示をしなければ伝わらないコミュニケーション文化を持つの国の方が多いです。むしろ、相手に繊細かつ高度な感性を求める日本式コミュニケーションの方がガラパゴス的と言えるかもしれません。
こうした文化や国民性の違いによって意思疎通や相互理解がうまくいかなくなってしまうと、結果として品質低下や手戻りが発生してしまうことがあります。
本側から物事を依頼する時は、目的（なぜやるのか）、スコープ（何をやるのか）、タイム（いつまでに必要か）、コスト（いくら以内でやるのか）を可視化してプロジェクトの目的を一致させ、認識の食い違いを防止することが大切です。
また、開発先の文化や国民性を理解しておくと、誤解や思い違いを少なくできます。時にはやり方を日本式に合わせてもらうように強制するばかりではなく、お互いに文化が違う国であることを理解し歩み寄る姿勢も大切です。
3. 情報共有や取り決めは、可能な限り文書化する
日本では、話し手と聞き手の間に共有されていることが多いため、行間を読み、暗黙的なコミュニケーションが成立しやすい文化といえます。また、日本では会議の場での共有や明確化をすることが多くなりますが、口頭による伝達や暗黙知の共有が含まれるため文書化しにくかったり、伝達する内容が多く労力がかかるという理由から、文書化しないケースが度々見られます。
一方、海外では、共有する情報や経験が少ないため、文章や図解、数値などによって、誰が見ても理解できるような形式で客観的に表現された形式知によるコミュニケーションが行われること多々あります。これは、個人主義的な文化の国ほど強くなえる傾向が見られます。そのため、母国語が異なる国のメンバーと日本語で業務を進めるオフショアの場合には、仕様等を確実に文書化してデータベースで共有するのが望ましいでしょう。
過去にオフショアで失敗を経験した日本企業による教育指導的な役割によって、日本企業とのプロジェクト経験が多いオフショア開発会社ほどそのような体制が整っています。こうした取り組みは、転職率の高いオフショア開発の課題をカバーするためにも有効です。
また、口約束で決まったと思っていたことが後になって変更となり、問題になることがあります。決めごとは合意と承認があって成立するものですので、可能な限り文書化して相互に承認ルールを確認し徹底することが大切です。
4. 仕様変更と品質レベルに関する考え方の違いを意識する
日本では、度重なる仕様変更が生じても、それに対応することが当然であると考えられがちです。一方、オフショア開発では、契約締結後に仕様変更を行うことは一般的とは言えません。そのため、仕様変更を巡ってはトラブルが発生する可能性があります。
これはオフショア開発の場合に限りませんが、特に海外ベンダーに開発を依頼する場合は、要件定義書や仕様書の内容を明確に記載することが大変重要です。表現されない要件はシステムとして実現されません。
日本企業同士では通じる「伝えなくても相手が理解してくれるだろう」という暗黙の了解は海外では通用しません。それどころか「行間を読め」「そんなことは常識」「言った言わない」などの表現されない要件はトラブルの元になります。また、言葉にしたことがそのままの意味として理解されてしまうことが多いので、曖昧さや複数の意味として解釈できるような表現は避けることが賢明です。また「今までと同じ」というような伝え方も避けるべきでしょう。
要件定義は開発全体の成否を左右する重要な工程です。曖昧な要件のまま開発をスタートさせたり、要件を先送りしたりすることは、プロジェクトの失敗リスクが高まってしまい大変危険です。せっかくコスト削減できる予定であたったものが、かえって時間や工数が増えてコスト高になってしまう可能性もあります。
そうしたリスクを回避するためにも、システム機能要件のみならず、性能、信頼性、セキュリティ、移行・運用方法などの非機能要件、既存システム接続要件、プロジェクト特有の制約条件、将来を見込んだ稼働環境をしっかりと定めベンダーと綿密にすりあわせしておきましょう。数値化できる要件はできるだけ数値化しましょう。
かつての日本企業によるオフショア開発は、詳細設計以降のプログラム作成、単体テスト、結合テストまでの下流領域のみ担当するのが主流でした。しかし、近年では、ベトナムなどにおいて経験があり優秀なエンジニアを確保できるオフショア開発会社や、日本人PMやSEが在籍しているベンダーにおいては、上流から下流工程まで一気通貫で対応ができる企業も増えています。もし、要件定義書の作成が困難な場合には、そのような上流工程から対応可能なベンダーを選定するとよいでしょう。
なお、オフショア開発でもラボ型開発であれば、要件や仕様があいまいな状態なままで開発を開始し、短期間で改修を繰り返しながら運用することは可能です。アジャイル開発、スクラムなどといった場合でも、オフショアのラボ型開発が数多く活用されています。
5. 事前にレビューやテストに関する指針を示し、開発の初期段階でレビューする
念を入れて仕様書を作成しても、言語の違い、慣習や商習慣の違いから、発注元の意図を正確に伝えられていないことも想定しておく必要があります。これに対処するため、発注元を交えて早期にレビューすることが有効です。
このレビューは、早い段階で行うことがポイントです。受注側の設計書がまだ作成の途中でも、とにかく早めにレビューしましょう。早期にレビューする狙いは、いわゆる「ボタンのかけ違い」を早めに検出して軌道修正することです。最初に大きな認識違いがあったり、ソフトウェアのアーキテクチャに大きな考慮モレがあったりしたとしても、早期の段階であれば、手戻りは最小限で済みます。
この取り組みの狙いは、欠陥を見つけ出すことよりも、むしろ軌道修正を早期に施すことで「鉄則：バグを作り込まないで最初から正しく実装する」ことを狙ったものです。
6. 受注側のレビュー計画とテスト計画をレビューし、計画どおりに行われることを見届ける
品質レベルについて、どこまでの品質を確保するのかに関して考えの差があります。発注する際には、レビューやテストに関する指針を具体的に提示しておくべきでしょう。
受け入れテストはあくまでもサンプリングになるケースが多いので、受け入れテストの前に、受注側で必要十分なレビューやテストが行われることが必要です。
受注側でどんなレビューやテストを実施してもらうか、指針を発注元で示しておき、それに沿って受注側で具体的な計画に落とし込んでもらいましょう。受注側と日本とで品質に関する捉え方が異なることを受け、レビューやテストの観点・範囲に、発注元の要望を受注側に予め伝えておくのが無難です。例えば、異常ケースはどこまで想定してレビューしておくか、といったものが挙げられます。
また、計画倒れになってしまったり、表面的な取り組みになってしまったりしないように、レビューやテストが計画どおりに実施されているか、発注元で定期的に見届けるようにしましょう。
この取り組みは、「鉄則：作り込んだバグは可能な限り早い段階で検出して修正する」ことを狙ったものです。
7. 属人的な進め方をせず、仕組み化する
国内での開発でも言えることですが、「その人（担当者）しか分からない」という属人的なプロジェクトの進め方では、継続的に高い品質のサービスを作ることは難しくなります。
開発を行っていくうえで、コーディング規約や納品物の仕様など、絶対に守ってもらいたいと考えていることは、現地のブリッジSEと開発メンバーに背景含めて伝達することはもちろん、「担当者を複数配置する」、「社内Wikiやチェックリストなどの情報共有ドキュメントを作成する」、「ツールを活用してオープンな場でコミュニケーションを行う」など、仕組みでカバーするようにしましょう。
こうした属人化を解消する取り組みは、継続していくとチーム内で開発に対する意識や観点が揃っていき、コミュニケーションロスや手戻りが少なくなります。導入当初は効率が悪いと感じるかもしれませんが、結果的に数ヶ月後には以前よりも効率的に進行できるようになるはずです。
8. 綿密なコミュニケーションをとる
オフショア開発を成功させるうえで最も重要なことは、綿密なコミュニケーションです。コミュニケーションをとることで信頼関係が生まれやすくなりますし、またプロジェクト内での共通で理解できる言語を決めておくと、お互いの認識が一致しやすくなります。
また、ベトナムなどのオフショア開発会社には日本語や英語でのコミュニケーションが可能なブリッジ人材が多いですが、日本語や英語を母国語とせず第2、第3言語とする国の場合、言語能力は人によってばらつきがあります。以下の点に注意することにより、コミュニケーションロスを減らすことができます。
(1) わかりやすい日本語（英語）で伝える
言葉の伝達方法を工夫すると、外国人にも理解してもらいやすくなります。例えば、1つの文章には1つのメッセージだけを込めて表現することを心がけてください。これを行うだけでも文章が簡潔になり、とても理解してもらいやすくなります。
また、1つの文章の中で否定する言葉を2回使用して肯定を示す二重否定なども避けましょう。例えば、「追加できないわけではない」などという表現は避け「追加できる」というように簡潔な肯定文で伝えましょう。作業指示などは箇条書きにして順番をつけてリスト化することなども有効です。
その他、た複数の意味を持ったり日本独特の曖昧な表現は避ける、カタカナ英語や擬音・擬態語は避けるのが無難です。
(2) コミュニケーションツールやタスク管理ツールを活用する
依頼側と開発側の2者間だけのメールやインターネット通話の場合、コミュニケーションが可視化されません。しかし、slackやchatworkのようなチャットツールを活用することで、チームメンバー間でチャットのやり取りを可視化することができるようになり、伝達した情報の理解度の把握や認識のずれが発生した場合の検証などが可能になります。
また、地理的に離れた相手と文章だけのやりとりだけでは冷たいコミュニケーションになりがちですが、チャットツールを使うことで、相手の顔のアイコンが表示されたり、絵文字を利用したりすることで円滑なコミュニケーションに役立ちます。
ビデオ会議ツールも有効です。ドキュメント画面を共有しながら説明したり理解度を確認する上で役立つだけでなく、言葉を聞いているだけの状況よりも、相手の顔の表情を見ることができ、伝えたいことの伝達度をうかがい知ることができます。
(3) 開発プロジェクトの大切な仲間というマインドセットを持つ
少なくとも週1回はオンラインでミーティングを実施するなど、定期的なコミュニケーションをとることが必要です。ミーティングでは口頭のみではなく、形に残るように会話の内容をテキスト化することで認識の齟齬が生まれにくくなります。
また、たまには現地へ出張して、開発チームのメンバーと直接会ってコミュニケーションする機会を設けることも有効です。一緒に食事したり雑談したりすることは業務とは無関係ではありますが、仲間意識が芽生え、お互い気軽に声を掛け合える関係性を構築できるようになれば、目標意識の共有化や役割の明確化、また価値観の相互理解に役立つはずです。
9. 進捗状況をこまめに確認する
進捗状況をリアルタイムで確認できれば、失敗のリスクを低く抑えてオフショア開発を成功に導くことができます。プロジェクト進行の管理については、RedmineやBacklog、その他のプロジェクト管理ツールやドキュメント管理ツールを活用しましょう。
プロジェクトの規模によっては、ブリッジＳＥが複数におよびますし、タスクが埋もれてしまうこともあります。誰がどのタスクを持っているか、進捗状況はどうか、 漏れはないか、バグ管理などを可視化し即座に確認してフォローできるようなツールの活用は大変有効です。
また、各エンジニアにタスクの進捗状況や明日の予定タスクなどを、毎日報告してもらえるように事前にルール化しておくとよいでしょう。報告をする際に使用するツールや、報告の仕方なども事前にすり合わせをしておきましょう。進捗状況をこまめに確認することによって、オフショア開発の各メンバーの抱える仕事量やキャパシティを把握できれば、追加で割り当てることができる仕事量を見い出してタスクをチーム全体に効率よく分配することもできるでしょう。
プロジェクト管理ツール、ドキュメント管理ツールなどを使って随時確認できるようにしておきましょう。打合せや毎日の報告をする際の使用ツール、要件の伝え方や報告の頻度など、事前にすり合わせをしておくと開発がスムーズに進みやすくなります。
事前準備が失敗を避け、オフショア開発を成功へと導く
オフショア開発はIT人材の確保やコスト削減など、いろいろなメリットがありますが、「開発先の企業を選んですべて丸投げすればよい」といった安易な考え方ではプロジェクトは失敗します。
日本とは習慣や文化も違う国とプロジェクトを進めるため、明確な要件定義、綿密なコミュニケーションや慎重に進捗管理するなど、発注側もしっかりとしたプロジェクト管理が必要です。
また、はじめてのオフショア開発を進める場合は、実績がある会社や自社のプロジェクトに合った開発先を選ぶことが大切でしょう。
無料eBookのダウンロード
チェックリストでわかる
失敗しないオフショア開発会社の選び方
オフショア開発会社選びの準備から開発開始まで、多様な角度からチェックポイントを網羅。チェックリストを活用して効率的な選定や基準作りに役立ちます。
More From オフショア開発