・この記事がお役に立つ人
・オフショア開発をぜひとも成功させたいPMやプロジェクト・オーナー
オフショア開発が始まって30年近くになりますが、いまだに失敗プロジェクトが多いのが現実です。失敗原因については以前の記事で解説していますので（下記参照）、ここでは成功要因について考察します。
必ずしも失敗原因の逆をやれば必ず成功する、という単純なものでもないところが面白いところです。
ここでは、まず他の人気の記事の成功要因について考察し、最後に筆者の考える成功要因について考察していきたいと思います。
※オフショア開発 失敗原因の詳細解説はこちらを参考にしてください
オフショア開発成功要因、検討の前提
前回の失敗原因の考察と同様に、まずは検討の前提を明確にしたいと思います。
前提とするオフショア開発方式のパターン
前提については、「失敗原因」のときと同じ設定です。
当記事では最も多いパターンである、日本の企業が現地のオフショア開発企業へ業務委託（請負契約）する場合を考えます（日本の親会社経由も含む）。
一般的にオフショア開発をする場合のパターンは以下の３種類と言われています。
①自社開発（オフショア子会社）
②オフショア開発企業への業務委託（請負）
※日系、非日系があるが日系を使うことが多い
③ラボ型開発（要員確保型、準委任）
今回は「②オフショア開発企業への業務委託（請負）」を前提とします。
また、委託する開発業務はWeb制作（ホームページ制作）ではなく、本格的なプログラム開発を想定します。（数十人月程度以上の規模）
オフショア開発の成功とは何か？
ここでは「業務委託開発（請負）」を想定しますので、以下の状態を成功と定義します。
・開発費用が予定通りに収まる
変更管理の費用は予備費内に収まる
受託企業では妥当な利益がでている
・開発期間が予定通りである（早くても可）
全ての機能が予定期日までに納品された
※開発遅れたため、フェーズを分をけて納品するなどはない
・検収の品質基準を満たす
成果物は品質基準を満たしている
必要なエビデンスは全て揃っている
・顧客満足度が高い
委託企業側の負荷は想定通り
変更管理案件でのトラブルはない（変更管理案件の費用は妥当）
※品質面で、リリース後に大量のバグが発生して業務が回らないなどの事象が発生することは、検収の品質基準に問題がある。単純にオフショア開発側の問題とは言えない（品質チェックできないのが問題）。もちろん瑕疵担保責任の範囲で修正作業は行ってもらう。
一般に「オフショア開発の成功要因」として考えられている要因の考察
まず始めに、「オフショア開発の成功要因」というキーワードでGoogle検索で上位表示される記事から、２社をピックアップして、その成功要因を詳細検討してみます。
Gogle検索で上位表示されて多くの方々の目に留まる記事なので、多くの方が参考にしたり、妥当と考えているものと推定されます。その妥当性を考察することは意味があると思われます
A社の考えるオフショア開発 成功要因の考察
A社では以下の7つを成功要因としてとらえています。
以下、具体的にそれぞれの項目について、一般的に妥当な物か検討します。
・オフショア開発成功への七ヶ条
2.開発進捗を明確化する
3.信頼できるブリッジエンジニアを雇う
4.全員にとってwin-winな関係を目指す
5.10割の品質を求め続ける
6.文化や国民性の近い委託先を選択する
7.先駆者の経験から学ぶ
実際の記事では各項目とその具体的な説明があります。
ただ、実際に顕在化したトラブルへの一次対応的なことが成功要因として列挙されているきらいが伺えます。
具体的に見ていきます。
積極的にコミュニケーションをとる
→コミュニケーションを積極的にとることで、信頼感と気持ちよい状態を作る、ということのようです。
趣旨は良く分かりますが、具体性に欠けていないでしょうか？。積極的にとは具体的にどうしろということなのか？人によって受け止め方やレベルが違ってくるので、表現があまり適切でないように思います。
本来は、立上げ当初に、コミュニケーション計画を立てて、委託先と具体的な手順を調整するべきものだと思います。また、コミュニケーションは多ければ良いというものでもないと思います。まずはやり方を決めて、クイックに改善していくことが重要かと。
開発進捗を明確化する
→進捗管理ができないのは論外です。
過去ののプロジェクトで進捗管理ができていなったのでしょうか。「できれば現地に行って確認したり・・・・」とありますが、現地に行かないと本当の進捗がわからないような委託先とは付き合わないほうが良いでしょう。
なお蛇足ですが、進捗管理方法も最初に決めておく必要がありあります。何も言わないと、感覚て30%完了、70%完了などという報告になりがちです。オンスケが翌週には一ヶ月の遅れなんて報告もよくあることです。
信頼できるブリッジエンジニアを雇う
→なんとなく言いたいことは分かります。
ただ、「信頼できる」とは？意味が曖昧です。ブリッジSEに求める要件を明確にすべきではないでしょうか。また逆に、信頼できないブリッジSE、とはどういうことでしょうか？
また、「雇う」とありますが、自社で雇うのか、委託先にお願いするのか不明ですね。
最近は翻訳ソフトの精度向上により（例：DeepLなど）、ブリッジSEなしでもプロジェクト遂行できる環境が整いつつあります。チャットレベルの英語ができれば、チャレンジしてみる価値はあると思います。
全員にとってwin-winな関係を目指す
→言いたいことはよくわかります。ただ、具体的ではありません。
何についてwin-winの関係を目指すのか不明です（たぶん金銭面、労務面かと思いますが）。
例えば、委託主が無理難題を言っても、それに見合うお金を払い期限を延長すれば別に問題はなく（逆にビジネスが増大する）、win-winの関係は構築できます。問題は例えば、予算やスケジュールの変更も無しに委託主が無理な要件追加・変更を要求してくることや、決められた役割分担を守らず、仕事を寄せてくる、などでしょうか。まあ、とても良くある話というか、必ず起こる話です。
これはスコープ管理の問題なので、プロジェクト管理者本来の仕事です。当然予測して契約段階で変更管理手順を決めるべき話でしょう。
10割の品質を求め続ける
→この成功要因の趣旨が理解できません。本文の説明を読んでも意味不明です。
成果物の品質が検収基準に達していないのに検収して、日本側で不備を対応するなど行うべきではありません。
開発がうまくいかないようであれば、きちんと改善案を双方で練って対応を依頼すべきです。最終的に時間切れならプランBを発動して日本側で全て作るか、A社の記事のように日本側で引き取ることも実際にあります（もちろん状況によります）。
なお、「品質」は契約時に「品質基準」を定めて、それをもとに検収するものです。感覚で品質を決めるものではありません。そもそもソフトウェア開発に10割の品質と言う考え方はありません（残存バグは必ずあるという考えです）。まあ、ここでは本来の品質の意味では使ってないようですが、使い方は正確にすべきかと思います。
文化や国民性の近い委託先を選択する
→仕事のやり易さ、と言う観点では理解できます。
ただ、委託する仕事の内容により、最もパフォーマンスの良いところに依頼すべきであり、それは国民性や文化とは関係ありません。
技術的にインドや中国の委託先がベストなら、そういう選択になると思います。
先駆者の経験から学ぶ
→これは仰る通りだと思います。
何事にもベストプラクティスはあるので主要なものは理解しておくべきでしょう。もちろんベストプラクティスなので、自分のプロジェクトの条件や状況によりカスタマイズ（適用可否も含め判断する）が必要でしょう。
※全般としての感想
この記事の筆者は一般的なソフトウェア開発プロジェクトにおいて必要となる、ソフトウェア・エンジニアリングやプロジェクトマネジメントなどにあまり親しんでいないように感じます。国内開発であろうとオフショア開発であろうと基本は変わりません。これらの知識は「先駆者の経験」そのものですので、ぜひ身に付けてオフショア開発にも役立てて欲しいものです。
Ｂ社の考えるオフショア開発 成功要因の考察
オフショア開発を成功させるための6つのポイント
2.下請け扱いせず、自社の開発チームの一員に加わってもらう
3.ドキュメント化と共有を徹底する
4.詳細設計まで日本で実施する
5.担当メンバーを固定してもらう
6.コスト計算を継続して実施する
こちららも具体的に見ていきましょう。
企業選定時に実績を確認する
→仰るっとおり、実績を確認するのはとても重要です。
ただ、実績は過去の事なので、「実績＝現在の会社の能力」と単純には評価できません。そのプロジェクトで中心となったエンジニアが転職してしまい、現在は再現できるスキルが委託先にないかもしれません。
現在も過去の実績が再現可能なレベルにあるのか、いろいろな面から検証すべきかと思います。
下請け扱いせず、自社の開発チームの一員に加わってもらう
→アジャイル開発的な発想でしょうか。
ここではかなり密な関係を言っているように思います。小規模な人数（10名以下とか）であればクイックに対応できる体制の構築は可能でしょう。でも、数十名とかになれば現実には難しいです。
また、請負契約であれば、指揮命令権は委託先にあり、個別に指示を出すことはできません。
委託元、委託先と明確に役割分担を決めて、対等に仕事をすれば済む話ではないでしょうか。別に成功要因というほどでもないと思います。
また、本当にクイックな開発体制にするのであれば、オフショア開発は選択すべきではありません。海外要員を日本に呼んでチームを作るべきでしょう。ネットの新商品開発や変更の多い会社では当たり前に日本でこのような体制を作っています。（何社か過去にオフショア開発を提案しましたがスピード重視ということで断られました）
ドキュメント化と共有を徹底する
→当然の話だと思います。
請負の委託開発であれば、開発仕様と決定事項はドキュメント化し、共有することは必須です。
当件を含め管理手順全般にについては、プロジェクト開始前に委託元・委託先の間で取り決めるべきです。
詳細設計まで日本で実施する
→言っていることは良く分かりますが、プロジェクトの状況によると思います。
全ての設計を日本側で実施し、オフショア側はコーディング・テスト（UT）を行う場合が多いのは事実でしょう。特に初めてであれば、リスク回避の観点からそうします。
ただ、委託先企業の熟練度によってはオフショアで詳細設計を実施したり、オフショアのエンジニアを日本に常駐させて基本設計を行う場合もあります。
担当メンバーを固定してもらう
→基本的にはそのとおりだと思います。
敢えて言うなら、特にキー・メンバーは異動させない、ということでしょうか。
どこのオフショア企業でも優秀な人材は少ないものです。そのため、プロジェクトの目途が立つと、別のプロジェクトに異動させることはよくある話です。
ただ、請負契約の場合は人を指定することはできませんので、ネゴシエーションの世界になります。
また、優秀な人材は転職する可能性が高いこともリスクとして考慮すべきでしょう。
コスト計算を継続して実施する
→意味が分かりにくいですが、「内製」と「外注」をうまく使い分けるために、それぞれのコストを絶えずモニタリングする、ということらしいです。 どちらが利益がでるかということで選択するということでしょうか。
コストをモニタリングすることは重要（当り前）ですが、「内製」と「外注」という観点だけに着目するのには多少違和感があります。
「内製」にするか「外注」にするかの観点は、コストではなくその業務が「コア」部分であるかどうかが大きいと思います。コア業務は会社自体の存続意義なので、手放したら業務が継続できなくなります。
逆に「コア」以外は「外注」に出して、コスト削減を図るというのが主流の考え方ではないでしょうか。外注先はいくらでも選定可能です。
【結論】オフショア開発の成功要因とは（重要6要因を解説）
ちまたでは「オフショア開発の成功要因」が話題になりますが、現実的には「プロジェクトの成功要因」をまず考えることが基本だと思います。
ここにオフショア開発特有の考慮点を加えるだけだと私は考えています。
結論
・システム開発およびプロジェクト管理の知識と経験のあるエンジニアをリーダーとする
（委託元企業において）
・委託先企業の選定は事前に決めた評価項目を基に行う
・担当するエンジニアと必ず面接して技量を評価する
・開発手順。管理手順を明確にし両社で合意する
・契約は一方が有利にならないようにするとともに、委託元（発注元）、委託先の役割分担を明確にする
オフショア開発の成功要因 詳細説明
十分なプロジェクト資金を用意すること
契約金額以外に予備費（コンティンジェンシー）を確保することは重要です。
プロジェクトで何が一番大変かというと、お金が無いことです。プロジェクトというのはお金があればたいていのことは解決できます。
オフショア開発に限りませんが、仕様理解の相違や止むおえない仕様変更は出てくるものです。そのとき予備の予算がないと仕事の押し付け合いになり、委託先との関係も悪化します。これは多くのプロジェクトで起こることです。
もちろん、潤沢なお金を用意することは無理なので、メリハリをつけるということです。場合によっては仕様を切る選択もします。
委託元（自社）のリーダー選定は的確に行う
委託元企業において、システム開発およびプロジェクト管理の知識と経験のあるエンジニアをリーダーとすることが重要です。
委託先に対して、きちんとした契約を結ぶ、明解な仕様書を渡す、的確な検収を行うなどのことが出来る必要があります。
委託元がいい加減なためにオフショア開発が失敗することは良くある話です。オフショア開発の経験があればなお可ですね。
少なくとも、それらの知識がある人がサポートできる体制を作ることが重要かと思います。
委託先企業の選定は事前に決めた評価項目を基に行う
委託先企業の選定にあたっては、単にフィーリングではなく、事前に洗い出した評価項目に基づいて行うべきでしょう。
コストだけでなく、企業規模（主に社員数）、実績（含む、得意分野）、開発標準の有無、経営者の資質、などが評価項目の候補になるかと思います。当然、開発依頼するアプリケーション分野の実績確認は必須でしょう。
評価項目に従って選定すれば、最低限のレベルはクリアできるでしょうし、失敗した場合の反省材料にもなり、次に繋がります。
担当するエンジニアと必ず面接して技量を評価する
エンジニアと必ず面接して技量を評価することは、オフショア開発では最も大切なことの一つだと思います。
オフショア企業の開発スキルは、会社に属するというようり個人に帰属する部分が大きいのが普通です。つまり、該当企業の技術レベルは、どれだけ優秀なエンジニアが在籍するかにかかっているのが実情です。
そのため、実際に参画するエンジニアと面接することはとても重要になります。
なお、優秀なエンジニアは流動性が高い（よく転職する）ので、転職した場合の代替策を委託先に確認しておくことも必要でしょう。
開発手順・管理手順を明確にし両社で合意する
開発手順や管理手順を明確にし、両社で合意しておくことはとても重要です。
また、これら手順にはオフショア開発特有の考慮点にも配慮します。
時間もないでしょうから、まずは決めて走ってみて、走りながらブラッシュアップしていってもよいと思います。何も決めずに走るのは最悪です。
開発手順が明確であれば、仕様書として何を渡せば必要十分かが明確になります。ブリッジSEの有無や、役割についてもここで決めます。
また、管理手順を決めることで、進捗、品質、コミュニケーションなどの方式を決めます。決める過程で例えばお互いどのようにコミュニケーションを図るか検討ができます。
煩雑な手順を決めるということではなく、全メンバーが認識できる簡潔な手順で十分です。Kick-Offミーティング等で全員に確認することが良いでしょう。
契約は一方が有利にならないようにするとともに、委託元、委託先の役割分担を明確にする
契約ごとは当然のことながら重要です。
プロジェクトがうまく進んでいるときは何も問題は出ませんが、いったんトラブルになると急に全ての歯車が狂います。
そして最後の頼みは「契約書」ということになります。最悪の事態を想定して「契約書」を作るべきでしょう。これは、国内もオフショアも関係ありません。
そういう意味で、契約書は片方が一方的に有利というのは避けたいものです。あとで禍根を残し、取引が長続きしません。
また、契約書または（受領する）提案書には役割分担を明記すべきと考えます。契約書に明記してあってもそれでも役割分担で揉めるケースはいくらでもあります。
特にオフショア開発の場合、外国人エンジニアは役割を狭く認識しがちなので、認識に齟齬が出ないよう十分気をつける必要があります。
まとめ
さて皆さん、いかがでしたか？
「【なるほど納得！】オフショア開発の成功要因はこれだ！」をご紹介しました。オフショア開発プロジェクトに邁進されているPMやプロジェクト・オーナーの方々の参考になったでしょうか。
もちろん上記に述べた考えは、特定の条件での一例であり、全てのプロジェクトに当てはまるわけではないことにご留意ください。
ご存知の通り、プロジェクトはユニーク性があるからこそプロジェクトであり、ひとつとして同じプロジェクトはありません。同じことの繰り返しなら通常業務になりプロジェクトではありません。
そのため成功要因についても、各社、各プロジェクト毎に特有の条件があることから、これさえ押さえればOKだろうと言うものが必ずしも当てはまらないこともあります。
このあたりは、各々のプロジェクトの状況に応じて取捨選択していただくしかないでしょう。
そういう意味では、A社、B社の考える成功要因も、各社ではそうであった、ということと言えます。別に間違いでも何でもありません。
受け取る側でどう解釈するか、ということが重要でしょう。
何はともあれ、このような議論がおおいにされて、今後のオフショア開発がうまく行くようになれば幸いです。
最後に、新しいオフショア開発サービスのご紹介して終わりにしたいと思います。
ピンポイントでオフショア技術者を採用するという新し考え方です。一考に値するかと考えます。ご興味がありましたら、当ブログのお問い合わせからご連絡いただきたく。
フィリピンにおける、オフショア開発に関するご質問、ご相談などもお気軽にお問合せください。
では、明るく、楽しく、前向きに、毎日をお過ごしください。
コメント