・当記事がお役に立つ人
・はじめてオフショア開発を外部に委託する、新しい委託先に依頼するという人
オフショア開発において外部の委託先を選定するのは非常に難しいものです。また、いくつかの候補先からどのような基準で選定すればよいのかという問題もあります。
オフショア開発では日本国内とは違った特有の事情もあります。具体的に開発委託先企業の選び方と委託のための準備作業を見てきたいと思います。
委託の準備をする
オフショア開発を委託する前にはいくつかの準備作業があります。
オフショア開発全般のについては、以下の記事ををご参照ください。
委託する案件を決める
まず、委託する案件を決める必要があります。
最初から大きな案件や複雑な案件を依頼するのは危険です。かといって小さすぎると委託先の評価や課題が見えにくくなるので、適度な大きさ、複雑度がよいでしょう。
ポイントは以下でしょう。
・自社の典型的な業務である
・案件の複雑度はやや易しい程度
・評価が可能な適度な開発規模（10～20人月程度）
・社内に仕様を熟知している要員は多数存在する
担当責任者を決める
担当の責任者を決めることは重要です。
できれば専任にして、今後のオフショア開発拡大の期待を示します。 また、語学より業務やシステム開発に精通している必要があります。
求められる資質は以下でしょう。
・該当業務に精通している
・開発を一気通貫で行ったことが複数回ある
（どのように開発するかを熟知している）
・海外に興味がある、海外出張は好きである
委託範囲・委託形態（含む開発環境）を決める
委託範囲や委託形態を決めるのは重要です。
オフショア開発を他社の要員で行う場合は以下の２つのパターンがあります。
【委託開発のパターン】
・委託開発（請負）
・ラボ型開発（準委任）
ご説明する必要もないでしょうが、お試しで委託先企業を使う場合は請負の委託開発が無難です。
また、委託開発の場合は通常ウォーターフォール開発で行います。
※ラボ型の場合はウォーターフォール開発、アジャイル開発のいずれかになる場合が多いです
次に委託範囲ですが、通常オフショア開発では主に製造工程を行います（力仕事の部分）。仕様書を作ってもらうのはスキル的に難しいので、まずはCoding, UT, 統合テストなど仕様書（テスト仕様書）があればある程度任せられる範囲が望ましいです。
【委託範囲】
・製造工程を委託する（開発・テストフェーズ）
・設計までは自社で行う（仕様書類は自社で作成）
・業務系受け入れテスト、システムテスは自社
※開発フェーズ分けは各企業により異なります（為念）
また、開発をどのような環境で行うかも決めなければなりません。通常はいかのいずれかでしょう。
【開発環境】
・クラウド上の開発環境で行う
・オフショアにローカル環境を作ってもらう
のいずれかで開発することになるでしょう。
クラウドで行えば、仕様書や成果物管理などは楽になりますが、現地のネットワーク状況やセキュリティ面での考慮が重要になります。
引渡し資料と成果物を決める
委託先に引き渡す開発資料と受領する成果物、および請負契約ですから、検収のクライテリアを決める必要があります。
引き渡す資料は、まずは自社の開発資料一覧とサンプルを渡して、開発可能なレベル感かどうかを確認するとよいでしょう。
ウォーターフォールであれば、必要な資料にあまり差異はでないと思いますが、事前のすり合わせは重要です。後でトラブルの種にならないようにしたいものです。
逆に、委託先が必要な資料のすり合わせに対して真剣でないと、ちょっと危ないかも知れません。
委託失敗時のプランBを策定する
いくら委託先のことを調べ、調査・面談をしても、プロジェクトがうまく行くかわかりません。
はっきり言って、初めてのオフショア開発、初めての委託先はリスク大です。
委託先がうまく開発できなくても、自社業務に支障が出ないよう、「プランB」を持っておくべきです。
通常はオフショア開発にかかる費用より、業務が稼働しないことによる「機会損失」のほうが大きいです。
開発委託先の選び方
自社内でのオフショア開発の委託準備作業と並行して、開発委託先の選定を進めます。
委託する国を決める
まずは、どこの国に委託するかを決めます。
というのは、オフショア開発の国別に特徴が大きく異なるからです。また、委託先企業を絞るためにも、委託する国を決めることは重要です。
委託する国の決め方は以下の記事で詳しく解説しています。
委託企業の主要選定ポイント10
次に、具体的に委託企業の主要選定ポイントを見ていきます。
主要な選定ポイントは10個あります。
①企業規模
委託先を選定するのに企業規模は重要な指標です。
たぶん、自社の企業規模や、委託する開発種別により企業規模は異なることでしょう、
自社がある程度の規模で、委託する業務が基幹業務であれば、
・ある程度の規模がある（100人以上が望ましい）
・人材管理、経理、アドミなど組織がきちんとしている
などが望まれるでしょう。
逆に、Webサイト制作やフロント系開発中心であれば、機動性や柔軟性に富んだ小さめの規模の会社のほうが小回りがきいて良い場合も多いです。
②得意分野と開発実績
その会社の得意分野と開発実績を確認することは重要です。
・自社の依頼したい主要案件の分野が得意である
・同上の分野での十分な開発実績がある
必ずしも過去の実績はあまりあてにはなりませんが、実績があるということは、その分野のスキル人材がいる可能性が高いといえます（証明にはならない）。
少なくとも、求めるスキル分野の実績が少ない、得意ではない企業を選ぶことは避けたいですね。
③開発標準化の有無
委託先が開発標準化を持っている、開発手順がパターン化されている会社は安心感があります。
つまり、開発が成功する再現性が高いということがいえます。
逆に開発標準化がないと、個人に依存した行き当たりばったりの開発になりがちなので、再現性に疑問が残ります。
できれば、以下の事柄を企業宛て確認すべきでしょう。
・自社の開発標準化、開発手順がある
・品質管理基準が策定されている（計数管理）
・レビュー方式が策定されている
④経営者の経歴と企業マインド
経営者の経歴と企業マインドは、該当企業の今後を考えるうえで重要です。
まず、経営者は以下の資質が重要でしょう。
・経営者が信頼できる
・経営方針に不審な点はない
・経営状態に不安がない（信用調査も実施）
こてこての技術者出身の経営者であれば、特定の技術が高い会社であることが多く、人材も技術志向の人材がたくさん在籍する場合があります。
でも、技術に偏重するあまり、管理面がずさんになって、納期や品質に問題がでてしまうことも多々見られます。
またこれとは逆に、営業指向の経営者で、話はよく分かってくれて管理面もきっちりしているが、会社として技術的に高くない、なども見受けられます。
経営者とその会社の特徴を見極め、適材適所で仕事をお願いするのが良いでしょう。
⑤担当エンジニアのスキル・実績
委託先を決定する上で最も重要なことは、実際に担当するエンジニアのスキルと実績です。
残念なことに、オフショア企業において「真の開発スキル」はエンジニア個人に依存するというのが実情です。
会社自体にスキルが蓄積している、というのはほどんど幻想にすぎません。
一般的に、特定の出来るエンジニアが他の普通レベルのエンジニアを引っ張って会社が成り立っています。
普通レベルのエンジニアだけでは、開発期間やコストの増大、品質の低下を招きます。
そのため、特定の出来るエンジニアが他社に転職すると、いきなりガタッと開発力が下がることは珍しくありません。
委託先を選定する場合に最も重要なのは、きちんと担当エンジニアの面談をすることに尽きます。
少なくとも以下は確認したいですね。
・担当エンジニアに必要なスキルがある（面談）
・担当エンジニアに実績や経験がある（面談）
・新しいスキルの吸収に積極的である
重要なのは、スキルのある要員をアサインしてもらうことです。オフショアの場合スキルは組織ではなく個人に依存することを肝に銘じましょう。
⑥ブリッジ要員のスキル・実績
ブリッジ要員が入る場合は、ブリッジ要員のスキルや実績も重要になります。
いろいろなパターンがありますので、どのようにブリッジ業務をするのか、スキルはどうなのか面談で確認する必要があります。
開発経験の豊富な日本人のブリッジ要員が現地で対応するのがベストです。日本にいる場合は英語が不得手な場合が多く、現地コントロールに不安が残ります。
日本語のできる現地人が、現地でブリッジ要員になる場合があります。開発経験があるかが肝でしょう。通訳だけの場合も少なくありません。
また、英語や現地語のできる日本人が現地でブリッジになる場合があります。
本格的なシステム開発経験がない場合がほとんどで、経験不足からトラブルの原因になる場合も少なくありません。
➆サポート要員の有無・役割
現地のエンジニアのなかで、本当に出来るエンジニアはほんの一握りです。大半のエンジニアはパットしないというのが普通です。
小さな案件の場合、できるエンジニアがアサインされないことも多いです。
その場合に、できるエンジニアや経験豊富なエンジニアのサポートがどれだけあるか、ということが重要になります。
いくら請負契約とはいえ、できなかったら機会損失の被害は被るので、開発体制は蔑ろにできません。
きちんと委託先企業内でのサポート体制を確認すべきです。
⑧提案書を評価する
委託先候補企業の提案書を見れば、信頼できるかどうかがすぐに分かります。
例えば以下の項目が入っているか。
・委託側と受託側の責任範囲
・変更管理の取り扱い
・現地との具体的なコミュニケーション方法
など
これらの事柄は、後でトラブルになりやすい事項です。提案してくるということは、これらトラブルになりやすい事柄に対して経験が豊富で、対応力もあると考えられます。
開発のパートナーとして信頼がおけるというものです。
⑨エンジニア、ブリッジの単価
エンジニア、ブリッジの単価が安すぎる、高すぎるというのは考えものです。
もちろん、スキルと対応した単価になっていれば良いのですが。
現地での人材流動性はどこも非常に高いです。
ですから、エンジニアやブリッジのスキルと給与は完全にリンクします。
スキルが高くて単価の安いエンジニアは基本的に存在しません。
もし、ラッキーにもそのようなエンジニアに巡り合ったら、逆に転職して途中でいなくなるリスクを考えておくべきでしょう。
⑩リモート開発の実施有無（自宅開発）
コロナの影響で、大手のオフショア企業の大半は自宅でのリモート開発が普通になっています。
自宅開発を許すかどうかも選択肢の一つになるでしょう。
自宅開発になるとどうしてもセキュリティの心配がでてきます。
たまにの会社出勤時にパソコンを紛失したとか、家族に情報が筒抜けなど、いろいろリスクは考えられます。
実際、オフショア開発でセキュリティを完全にコントロールすることは困難なので、気休めにしかなりませんが、自宅開発の有無を委託のための考慮ポイントにすることもありだと思います。
現地視察での評価
委託先企業を決めるのに現地視察は欠かせません。
今はコロナで現地視察は難しいですが、Web会議と実際に直接現地にいくのとでは大きな違いがあります。
会社のロケーション
まず、会社のロケーションがどこにあるか、ということがあります。
実際の開発では現地に行くことも多くなるので、できれば交通の便の良い、行きやすい場所が好まれます。
また、優秀なエンジニアを募集するのにも、良いロケーションは有利になります。
ただし、便利な場所は家賃が高いので当然費用に跳ね返ります。
あまりにも現地の一等地（日本でいえば六本木ヒルズ？）であれば、経営者の考えを聞いてみたほうがよいかもしれません。
会社・エンジニアの雰囲気
現地視察で最も重要なことは、会社・エンジニアの雰囲気を感じることです。
黙々と開発にいそしんでいるのか、ガヤガヤと自由闊達にしているのか、会社それぞれで特徴がでます。
その企業が日系であれば静かなことが多いですし、現地資本であれば自由な雰囲気が多いように思います。
自分の社風に合うかどうかという観点で見れば良いと思います。
人材管理責任者の資質
忘れてならないのが、人材管理責任者の資質です。
通常、HR（Human Resource） Managerと言われる人です。
HRは採用や人事管理を中心に行う部署で、人財命のオフショア開発企業ではかなり重要なポジションになります。
良い人材が採用できるか、良い人材の離職を防ぐか、会社の雰囲気を良くするか、というのはHRの手腕にかかっています。
良いオフショア企業には、しっかりしたHR Managerがいることが多いです。
選定のポイントとしてあまり重要でないもの
委託先企業を選ぶ際の選定のポイントとして考慮すべきものとして挙げられているもので、特に重要ではないものがありますのでご参考として記載します。
特段の契約条件
「瑕疵担保責任がありますので安心です」、なんて記事もこのまえ読みましたが、請負なら瑕疵担保責任は当り前なので論外です。
いずれにしろ契約条件は当事者同士で決めるものなので、選定のポイントにはなりません。
セキュリティ
オフショア開発にセキュリティを求めてはいけません。
選定のポイントとして「セキュリティがしっかりしていること」を挙げる記事もありますが、基本的に考え方が間違っています。
オフショア開発企業でセキュリティが十分会社なんてありません。儲からないところにお金はかけませんし、また少しくらいお金をかけてもほとんど有効ではありません。エンジニアが悪意を持って情報を盗もうとしたら、一般的な対策では防ぎようがありません。
オフショア開発の場合、機密情報や個人情報は絶対出さない、ことを徹底するしか対策はありません。
もしセキュリティ要件があるのなら、自分で徹底的な対策を打つしかありません。「鬼滅の刃」ではありませんが「殺生与奪権を相手に与えてはいけません」。
＞＞ご参考 オフショア開発における本当のセキュリティ対策とはどんなものか？（近日記載予定）
委託開発開始後の評価と対応
委託開発開始後の注意点はいろいろな記事や論文で述べられていますので、いろいろ参考になさることをお勧めします。
基本的なことを愚直にやっていくしかありませんし、いろいろな問題が起ころうことを前提にPDCAを回していくしかないでしょう。
一般的にあまり言われないことですが、委託開発開始後に考えるべき重要な事項をいくつか記載します。
経営層との定期MTG
委託開発開始後に委託先の経営層と定期的な会合を持つことは重要です。いわゆる「ステアリング・コミッティー」などといわれるものです。
プロジェクトなので問題や課題は必ずでてきます。
現場レベルで解決できるものは良いのですが、スケジュールやお金にかかる件は、裁量権限の問題で現場で対立しやすいものです。
このような場合は、両者のトップマネジメント同士で解決する（握る）しかありません。
感情的な対立になる前に、経営レベルでどうにかしたいものです。
ダメなら途中で開発を止めてプランB発動
委託開発がどうしてもだめな場合、相手を責めるだけでは何も解決しません。
開発自体をいったんストップし、プランBを発動して自社の機会損失を最小限にすべきです。
ずるずると開発を引き延ばし、コストを垂れ流すのは最悪です（よくある話ですが）。
委託開発部分の遅れが、他の部分の開発やサービス全体のリリースなどに影響するのは絶対避けるべきです。
終了後の評価と対応
当り前のことですが、委託開発終了後に両社でプロジェクトを評価するのは重要です。
モノできたからOKではなく、当初意図したとりにできたのか、期間、コスト、品質の面から計数をベースとして評価するとともに、発生した課題や問題について、どうすべきだったのかを評価することは、その後のオフショア開発をする上でとても有効です。
まとめ
さて皆さん、いかがでしたか？
「【初めてのオフショア開発】開発委託先企業の選び方と委託のための準備作業を解説」をご紹介しました。オフショア開発会社を選定する上での参考になったでしょうか。
オフショア開発が始まってもう30年近く経ち、ソフトウェア開発をするうえで、当たり前のことになっています。
しかし、当たり前とはいうものの、いまだに開発がうまくいかずにコスト削減ができない、逆にコストが増えた、品質に満足できない、など問題が山積しているようです。
この記事が、これらの問題に少しでもお役にたあてれば幸いです。
最後に、新しいオフショア開発サービスのご紹介して終わりにしたいと思います。
ピンポイントでオフショア技術者を採用するという新し考え方です。一考に値するかと考えます。ご興味がありましたら、当ブログのお問い合わせからご連絡いただきたく。
では、明るく、楽しく、前向きに、毎日をお過ごしください。
コメント