2023.03.10

ODC とは ？メリットやデメリット・請負型との違いや成功させるコツを詳しく解説！

オフショア開発を利用するなら「 ODC 」がおすすめです。ただし、ODCには数多くのメリットがある反面、デメリットもあるので利用するにあたっては注意が必要でしょう。また、海外の企業を相手にするとあって、不安があったり、どのように利用すれば良いか要領がわからなかったりする経営者や開発担当者の方も多いかもしれません。

そこで今回は、ODCとは何か、メリットやデメリット、請負型契約との違い、ODCの具体的な流れ、さらにODCのプロジェクトを成功させるための秘訣について詳しく解説します。

ODC とは

ODC とは「Offshore Development Center」の略で「ラボ型開発」を意味します。ODC は、海外の開発会社に開発業務のすべてやその一部を委託するオフショア開発の一つです。

具体的には、発注者専属の開発チーム（＝ラボ）を社内に構築し、一定期間、（発注者の）指示にしたがってシステムの開発を行う契約スタイルを意味します。その特徴をわかりやすくまとめましょう。

• 成果物の納品を目的とせず、チームのエンジニア全員の仕事量に対して報酬を支払う
• 準委任契約にあたり、開発業務は丸投げせず発注者の指示と管理下で進められる
• 契約中の仕様変更は自由に行える
• 開発業務が終了しても契約期間が残っている場合は、報酬が発生する

以上が主な特徴です。

ODCの契約期間は、短くて1ヶ月、長ければ1年以上に及ぶこともあります。長期にわたって協働していると気心が知れてくるので、相性が良い場合はいったん契約が終了しても繰り返し同じ相手とODCを行うケースも少なくありません。イメージとしては、派遣エンジニアのグループを一時的に専属で雇用すると考えるとわかりやすいでしょう。実際には、ブリッジSEやプロダクトマネージャー（PM）もチームメンバーの一員となり、依頼主との窓口役やチームのまとめ役を果たします。

想定していた開発がすべて終了したからといって契約を前倒しで打ち切ることはできません。定められた期間中は、チームの構成員の数と労働時間に応じた報酬が発生します。そのため、別の業務を追加依頼して、その労働力を有効に使い切るようにしなければ費用対効果が悪くなってしまうともいえるでしょう。　　　　　　　　

ODC のメリット

続いてODCのメリットとデメリットについて解説しましょう。

メリットは、以下の6点が挙げられます。

• コスト削減
• 採用や人材育成が不要
• 仕様変更が可能
• 開発スピードが早まる
• 開発ノウハウが蓄積できる
• 複数の案件が依頼できる

それぞれについて詳しく見ていきましょう。

コスト削減

ODCを活用する最大のメリットの一つは、大幅なコスト削減が可能な点です。ODC先進国は、ベトナム、インド、中国、フィリピン、ミャンマーといった東南アジア諸国です。これらの国のITエンジニアの人件費は、上昇傾向が著しい日本国内と比べると大幅に安いのが特徴です。

具体的には、国内の人月単価が80万〜100万円前後といわれる中、ODCの場合は、高くて60万円弱、安い場合は18万円ほどのため、最大で80％以上のコストカットが見込めます。

例えば日本からのODC依頼先の半数以上を占めるといわれるベトナムと日本で比較してみましょう。ベトナムは高く見積もっても人月単価が40万円前後のため、仮に40万円とし、国内エンジニアの人月単価を100万円とします。そして３名のエンジニアをODCでアサインしたとしましょう。

企業によって人月単価はまちまちのためあくまでも一試算に過ぎませんが、金額の差は歴然としています。

※（ODCではエンジニア以外にプロダクトマネージャー（PM）やブリッジSEという発注者とエンジニアの架け橋的存在がいますが、人月単価はほぼエンジニアの1.2〜1.6倍くらいが目安です。コミュニケーションのフォロー役として参加することがある通訳者は、エンジニアの50〜60％くらいが相場です。国内での開発なら通訳者は必要ありませんが、ODC（上記の例の場合はベトナム）諸国の場合は、その分（通訳者への報酬）が加算されることもあります。実際にはエンジニアだけでチームが構成されることはなく、そこにPM（国内の開発でも必要）やブリッジSEが加わるため、両国とも上記の試算額より高額になる可能性があります。）

しかもODC諸国のエンジニアは、国内エンジニアに劣らないスキルや経験をもつケースも少なくありません。よって、品質を下げずに低コストで開発が進められるので、非常にメリットが大きいといってよいでしょう。

採用や人材育成が不要

ODCを利用すると即戦力の優秀なエンジニアを自社社員と同じように開発業務へ投入することができます。もし自社開発をするとなると、ラボの専属エンジニアの開発力を自社内でまかなわなければなりません。国内ではIT人材不足が徐々に深刻化しており、ニーズに適した人材を必要に応じて十分に確保するのは決して容易ではないでしょう。しかしODCを活用すればその必要がなくなるため、無理をしてエンジニアを正規採用したり、人材育成したりする手間やコストを省くことができます。

仕様変更が可能

ODCは決まった成果物を開発することが目的ではありません。特定の期間でまとまった仕事量を人材ベースで確保するための契約なので、途中で仕様変更することができます。実際の開発現場では仕様変更を迫られることが決して少なくありません。現に不具合が見つかれば柔軟に要件を変更したり、工数を戻したりできるアジャイル開発が従来のウォーターフォール開発を凌いで主流になりつつあります。そのニーズに合致するのがODCなのです。

開発スピードが早まる

臨機応変に仕様変更ができるODCは、大幅な修正作業を回避できるため結果として開発期間の短縮を可能にします。しかも実践力に長けた優秀なエンジニアを確保することができるので、開発スピードはさらに高まるといってよいでしょう。

加えて、インターネットとクラウドをフル活用しながら時差による優位性を利用した効率的な業務推進が可能な点も見逃せません。日本で就業時間が終了しても、時差によって相手国では業務を継続できます。逆に相手国で仕事ができない時間帯に国内で業務を進めることもできるのです。これらによってリードタイムを短縮することができれば、競争優位に立つと同時に利益獲得にも大きく寄与すると期待できます。

開発ノウハウが蓄積できる

ODCを利用することによって、開発ノウハウを自社内に蓄積することができる点も大きなメリットでしょう。ODCの経験が豊富な企業ほど優秀なエンジニアを多数抱えています。その仕事ぶりを間近で見ることによって学ぶことが数多くあります。それが自社の大切なリソースとなり、人材育成のチャンスにもなり得るのです。

複数の案件が依頼できる

ODCでは、その時々で開発を進めたい案件から優先的にエンジニアを投入していきます。しかも依頼する案件は一つとは限りません。ある開発が終了しても契約期間が残っていれば、さらに別の案件を委託することも可能です。また、開発の全体像が見えにくく、仕様変更の確率が高い研究分野の開発を手探りで行う場合にもODCはうってつけといえるでしょう。

レリパは、創業依頼、日本企業に特化してODCを進めてまいりました。日本語に精通したブリッジSEやエンジニアが多数在籍しており、お客様のニーズにあった開発を十分にサポートさせていただきます。開発スキルの高さとスピード、そして何より安価なコストは、多くの日本企業の皆様より高くご評価いただいております。基幹システムやソフト、アプリケーションの開発、またブロックチェーンやメタバースなどWeb3関連の開発についてもご検討なら、ぜひ弊社までお気軽にご相談ください。

ODC のデメリット

続いてODCのデメリットです。具体的には以下の6点になります。

• 品質や納期への責任が希薄
• コミュニケーションが難しい
• 人選に注意が必要
• 文化や習慣が違う
• 短期の開発には不向き
• 開発期間が余ると人件費が発生する

それぞれについて解説していきましょう。

品質や納期への責任が希薄

ODCでは、明確な成果物を開発のうえ納品するという契約ではありません。どちらかというとあるプロジェクトの一部分を必要に応じて開発依頼するというニュアンスが強いです。そのため品質保証や納期厳守の意識にやや欠ける面があると指摘されることがあります。国柄や企業、エンジニアによってその程度はまちまちで、決してすべてのケースにおいて共通するデメリットとは言い切れません。しかし、発注者はそのあたりについて心づもりをしつつ、タスクの管理方法には十分に注意を払う必要があるでしょう。

コミュニケーションが難しい

日本語が通じる場合は問題ありませんが、委託先に日本語が話せる社員がいなかったり、カタコトしか理解できなかったりする場合は、業務がスムーズに進まないことがあります。ODCでは、とくにブリッジSEが開発の大きな要となります。ブリッジSEが仕様を明確に理解し、それをエンジニアに余す所なく伝えることができれば想定通りの成果が得られる可能性が格段に高まるでしょう。

具体的には、「日本語能力試験」で定められるN1〜N5までの5つのレベルのうちN2以上の日本語能力があることが望ましいです。

N1が最高レベルです。新聞の論説や評論など、論理的にやや複雑な文章や抽象度の高い文章を理解でき、会話や講義、ニュースなどを自然なスピードのまま聞き取れるレベルになります。

N2は、N1よりはやや平易な文章の概要を読んで理解することができ、まとまりのある会話やニュースの概要が正しく把握できるレベルです。

これがN3以下となると、ブリッジSEや直接日本側の依頼者とやり取りする必要のあるエンジニアとしてはやや不安要素が残るのでおすすめできません。　

人選に注意が必要

ODCは多くの場合、数ヶ月〜1年間くらいに渡って濃密に交流をしながらともに開発業務を進めていくことになります。そのため、発注者との相性は非常に重要です。エンジニアとしては優秀でも発注者側の要望に耳を傾けず、自分流のやり方を押し通すようでは途中で開発業務が頓挫してしまう恐れがあります。あるいは報告もなしに自分の考えで勝手に開発を進めてしまい、後になって大きく修正しなければならないということがあってはなりません。とくにODCの場合は、仕様変更を頻繁に行う可能性が高いので、発注者の意図を柔軟に汲み取る姿勢があるかどうかは、プロジェクトの成否を大きく左右するといってよいでしょう。その意味では、ブリッジSEを含めて性格が柔和で素直、プライドを誇示しすぎず過去の仕事ぶりでも発注者からの評判がよい人材を選ぶことができれば非常に安心です。

そのためにも、事前に面談をおこなったり、信頼のおける知人から紹介をうけたりして、契約後に後悔しない対策を施すのがよいでしょう。

文化や習慣が違う

同じアジア圏内でも、日本とODC諸国とでは文化や習慣に大きな違いがあります。例えばインドネシアはイスラム教徒が非常に多く、1日5回の礼拝が習慣化しています。とくに正午頃や午後3時頃は、仕事中でも礼拝を優先するケースが少なくありません。1回の礼拝時間は5分ほどのため、仕事にはあまり影響しませんが、日本ではまずあり得ないのであらかじめ理解しておくことは大切でしょう。

他にも中国の春節のように日本とは異なる時期に正月を祝う慣習もあります。ベトナムなら「テト」という旧正月の連休が1年間でもっとも盛り上がる大事なイベントで、企業でも１週間以上休みを取るのが常識となっています。

また日本と比較すると仕事の進め方もややゆっくり目で緩慢な傾向が強いです。日本人であれば行間を読み、言外のことも忖度して、気を利かせながら仕事を行うケースがあります。しかし、ODC相手国の場合はその要素が幾分欠けていることもあり得ると認識しておく方がよいでしょう。したがって、とくに最初のうちは進捗状況についてくどいくらいに確認をしたり、伝えたことが理解されているか復唱してもらうようにしたりといったタスク管理が必要です。

短期の開発には不向き　

ODCは、見ず知らずのメンバーどうしてチームを組んで開発を進めていきます。そのため気心が知れるまではある程度の時間を要するのが一般的です。言葉の問題しかり、仕事の進め方しかり、報告の内容やタイミングについても勝手が違って最初はギクシャクすることがあるかもしれません。そのため、もし1ヶ月も満たないうちにODCが終了するとなるとチーム構築が十分でないまま区切りをつけることになり、あまり協働する意味をなさない可能性があります。少なくとも3ヶ月以上にわたる契約の方が、ODCには適切といえるでしょう。

開発期間が余ると人件費が発生する

契約期間が短すぎるのも良くありませんが、開発内容に対して長すぎても期間が余ってしまう可能性があります。ODCの場合は、当初予定していた開発が完了しても契約期間が終了するまでは、その間のエンジニアへの報酬を支払い続けなければなりません。

例えば、一人当たりの人月単価が30万円として、エンジニアが３名の場合を想定しましょう。もし契約期間がまる1ヶ月余ったとすると、何もしなくとも90万円のコストが発生することになるのです。よって契約前からこのようなケースを想定し、他の開発業務を依頼するなどしてチームメンバーの仕事量を使い切る工夫をしなければ費用対効果が下がってしまいます。

ODC と請負型契約の違い

オフショア開発には、ODC以外にも「請負型契約」があります。請負型契約は、開発業務を丸ごと相手企業にアウトソーシングする契約スタイルのことです。決まった成果物の完成品を納期通りに納品するのが原則となります。ODCとの違いを表にすると以下の通りです。

仕様が明確になっている場合は、請負型契約がおすすめです。継続性がなく、そのプロダクトの完成のみが目的の場合も、請負型契約がよいでしょう。逆に仕様が明確ではなく、途中で変更する可能性がある場合はODCが適切です。また開発内容が継続的で、信頼関係があり気心が知れたメンバーとの開発を繰り返し望む場合も、ODCがおすすめです。

レリパは、ODCでも請負型でもお客様のニーズに合わせて開発のお手伝いをさせていただきます。ブリッジSEに加えて翻訳者や通訳者が、すべてN2以上の日本語能力を擁します。日本の皆さまの商習慣を熟知したスタッフが全面的にサポートいたしますので、オフショア開発ご用命の際は、ぜひ弊社までご連絡ください。

ODC とアウトソーシング

業界に関わらず、システム開発にあたってはアウトソーシング（外注）を利用する例が非常に多くみられます。アウトソーシングは、開発業務をすべて委託するのが基本です。作業管理や作業指示、作業結果の管理は受託した企業側が行います。成果物を納品する責任を負うという意味では、オフショアの請負型開発契約に似たイメージといえるでしょう。

一方ODCの場合は、相手企業に丸投げをせず、発注者側がイニシアティブをとる準委任契約です。進捗状況を把握し、チーム全体の仕事状況を細かく管理、もし意図と違った状況が見うけられれば即修正を指示します。その意味では、別々の企業同士でありながらも、純粋なアウトソーシングと比べると一体感があるといってよいでしょう。

ODC の流れ

ODCの流れを説明しましょう。具体的には、以下の通りです。

ODC 企業の選定

まず大切なパートナーとなるODC企業を具体的に選定します。

探し方としては、

• 知人の紹介
• セミナーやウェビナーへの参加
• ネットで探す
• マッチングサイトを活用

などが挙げられます。

レリパは、日本企業に特化したODCにより、多くのお客様にお喜びいただいております。安価でスピーディーな開発により、さまざまなソリューションをご提供いたしますので、まずは気軽なご相談からでもお問い合わせください。

初めてODCを行う場合は、信頼のおける知人から紹介してもらうのがおすすめです。その方が、何のつてもなく見つけ出すよりもある程度勝手がわかっているだけ安心なうえ、コストも安くしてもらえる可能性があるでしょう。難しい場合は、それ以外の方法を選択するしかありません。ただその際は、予算以外にも日本語の理解度や、開発目的に合致した企業か、また必要に応じてブリッジSEやエンジニアだけでなく通訳者やデザイナーが在籍しているかも確認しておくとよいでしょう。

仕様書の作成

ODC企業選定と並行して行うのが、仕様書の作成です。

• 何を
• なぜ
• いつまでに
• いくらで

開発したいのかを社内でしっかりと議論、精査していきます。ODCの場合は請負型のように仕様が明確化されていない場合もあるでしょう。その際は、何が不明瞭で、その理由や原因がどこにあるのか、といった課題も忘れずに明記しておくようにします。

仕様書が明確かつ詳細であるほど、ODC企業との間で情報共有がしやすくなります。相互の考えに齟齬がなく同じ目的に向かって歩調を合わすことができれば、プロジェクトの成功率は確実に高まるでしょう。そのためにも仕様書作成には最大限の注力が必要です。

仕様書に最低限記載しておくべきことは以下の通りです。

• 画面遷移図
• イメージ図
• シーケンス図
• レイアウトや操作性についての細かな説明

これらの要素が網羅された仕様書があるとODC企業との間で非常に話が進みやすくなります。最初の段階で仕様書が100％採用されることは難しいかもしれません。妥協しなければならない点もあれば、逆に想定以上のパフォーマンスが可能なケースも考えられます。そこは委託先のリソースやスキルによっても違いがあるでしょうし、ことによっては予算を変更する必要が生じることもあるでしょう。

開発実装

仕様書が固まったら、その内容に沿った設計を行い、開発を進めます。ここで重要なことは、開発をODC企業に丸投げしないことです。イニシアティブは、発注者側が握るようにしてください。最初のうちは毎日主要メンバーによるミーティングを行い、進捗状況を確認しましょう。でなければ知らないうちに想定とは違った方向に進んでしまうことが多々あるからです。

ある程度軌道に乗れば数日〜１週間の一度の打ち合わせでもよいかもしれません。ただし、ODCの場合は途中での仕様変更が入ることがあります。その際には、仕様書同様、できるだけ詳しく具体的に変更内容を伝えるようにしてください。そしてその内容が確実に反映されているかを、頻繁に確認する必要があるでしょう。

テスト・修正

システムが実装できたらテストに移ります。この段階でバグが発生したり、想定していた通りのイメージで稼働しなかったりした場合は、すぐに修正を行います。契約期間内に完成形にまでこぎつけることができなければ、チームは解散してしまうのでその後の修正は困難になります。修正できるとしても再契約や追加費用が必要となるので、期間内に目的のフェーズを終了させるように努める必要があるでしょう。

ODC でプロジェクトを成功させるコツ

ODCによってプロジェクトを成功に導くコツについて、「避けるべきリスク」と「検討するべきポイント」の２つに分けて解説しましょう。

ODC を利用する際に避けるべきリスク

「責任範囲を明確にしておく」

プロジェクト開始にあたって、発注者と受注者双方の責任範囲を明確にしておく必要があります。

設計や実装はどちらがどこまで行うのか、テストの実施者や参加メンバー、想定していた開発案件以外の案件が発生した場合の費用負担基準、開発が終了した後のサポート体制に至るまでできるだけ明確化し、文書化のうえ合意しておくと安心です。

「コストばかりを重視しすぎない」

コストばかりに気を取られ、委託先を見積もりが安いという理由だけで決めてしまわないように注意してください。あまりに安価な場合は、エンジニアのスキルが低かったり、開発実績が少なかったりする可能性があります。ODCでは途中で開発がストップしてしまい、そのまま関係もフェードアウトして結局コストでも大きな損失が発生するケースがあります。そうならないためにも、コスト以外のファクターを勘案し、総合的な視点でパートナーを選定するように努めましょう。

「日本語が通じない」

日本語が通じない、あるいは通じにくいのは、ODCでは致命傷になりかねません。英語でコミュニケーションが図れる場合はそれでも構いません。しかし、相手先の日本語能力のみならず自分たちの英語力も含めて危うい場合は、契約を見送った方が無難でしょう。日本語能力N2以上のスタッフが常駐しているか、そして実際にやり取りしてみて会話や理解度に問題がないかをしっかりと確かめるようにしてください。

「時差や行事による損失」

相手国によっては、時差が3時間を超えるケースがあります。それが開発上優位に働くことがあるのはすでに述べました。しかし、時差があることでリアルタイムでの情報共有や問い合わせ、緊急時における指示などがうまくいかない可能性も否定できません。

また、契約期間が短いとか、急ぎの案件の場合は、行事による長期の休暇と重なると開発ペースが遅れる恐れもあります。相手国のカレンダーや、それに伴うビジネス慣習についてよく調べておく必要があるでしょう。

ODC を利用する際に検討するべきポイント

「開発実績の確認」

開発目的とODC企業の開発実績が合致しているかを十分に精査する必要があります。ITシステムやアプリケーションの世界は日進月歩です。ユーザーが求めるUI（操作性）やライバル企業が導入するシステムの機能性は常にアップデートしていると認識して、そのニーズと仕様にあった的を射た開発が可能かどうかをよく確かめなければなりません。例えばAI技術を活用するなら、システムをプログラムするスキルのみならず、精度の高いデータをどれだけ保有または収集できるかが重要です。ブロックチェーン開発でも、開発言語以外の特殊な知識やルール作りに関する知見が求められます。その意味では、実際にどのような成果物を開発した経験があるのかを事前に提示してもらうのがよいでしょう。

「報連相の徹底とルール化」

文化や国民性の違いから、意思疎通がうまくいかず関係がこじれてしまうことが珍しくありません。そうならないためにも、厳格なタスク管理を行い、進捗状況をつぶさに把握するべく「報連相」の徹底を促すことが重要です。ただ相手先に依頼するだけでは足りません。こちらから「何日の何時から何をテーマにミーティングを行うか」を常に指定していく姿勢をもちましょう。ビデオ会議による対面での報告がよいのか、チャットやメールでのやり取りで済ますのか、どの会議を定例化するのか、参加メンバーや内容によって細かく仕分けるのもおすすめです。

「事前面接が可能か確認」

ブリッジSEやエンジニア、通訳者といったキーパーソンとは、事前に面談するのが望ましいです。こちらが求めることを理解できるか、また人柄や表情などは、実際に顔を見ながら話をしてみなければわからない面があるからです。開発がスタートしてから後悔しても遅いので、ぜひその前に直接コンタクトをとって、開発スキル以外の雰囲気や相性を確かめるようにしましょう。

まとめ

ODC は、上手く活用すると発注者にとっては非常に有利に働きます。コストが安く、優秀なエンジニアを確保でき、ノウハウの蓄積も叶います。何より開発スピードを早めることができる点も見逃せません。

ただし、コミュニケーションや開発実績、仕事への考え方や取り組む姿勢は、ODC企業によってかなりの差があるので注意が必要です。プロジェクトが成功するために、記事内でご紹介した十分な対策を取ることをおすすめします。

レリパでは、日本企業の皆さまの開発を強力にサポートしており、すでに多くのお客様から喜びのお声を頂いております。ODCをご検討なら、ぜひ弊社までお気軽にお問い合わせください。