【オフショアとは】の記事では、オフショア開発のメリット及びデメリットを紹介しました。基本的に、エンジニア不足の解消や人材コストの大幅な削減などのメリット最大限を活かし、加えて積極的に適応して柔軟に対応すれば、企業は事業活動をますます拡大することができます。 しかし、実際には、多くの企業がオフショア開発を実施する前に慎重に調査したにもかかわらず、成功を収めることができず、さらに失敗したこという声を聴くこともあります。 理由は何でしょうか？本記事では、オフショアが抱える問題、並びにそれらの問題の解決方法を分析していきます。 オフショア開発が抱える問題 多くの企業は人材コストの大幅削減を目的としてオフショアを選択しています。しかし、実際に実施してみると期待したほどの効果が得られず、またコストが予想を超えしてまいました。その理由は、開発エンジニアの人件費以外にも他の費用がかかるからです。例えば、双方国間に橋渡し役としてブリッジSE、日本語から現地語に翻訳するコミュニケータなどというコストがかかります。または変更・修正が必要な問題が発生した場合のコストの増加、納期の遅れる場合、確定されたスケジュールに間に合わない場合にもプロジェクトのコストも増えてしまいます。従って、小規模プロジェクトに対して、削減可能だと思われる人件費以外のコストは増加される恐れがあります。その場合はコスト削減が効きづらいです。 言語の違いと地理的な距離により、双方が直接的に会談すること、かつ言語のニュアンスを相手に全て伝えることが不可能になります。また、曖昧な日本語表現では、聞き手は漠然とした理解しか得られず、顧客が望む結果を把握できず、製品の品質が保証されません。間違った情報を伝えたり、伝え忘れたりするとコミュニケーションエラーが発生しやすくなります。 ある文化特徴は日本人にとって当たり前なことだと思われていますが、外国人ならそうではないかもしれません。たとえば報連相文化であり、多くの外国企業には報連相の実施習慣がなく、加えて地理的な距離やコミュニケーションの困難により、顧客が進捗管理や製品の品質を管理することが困難になります。 近年、日本市場向けにオフショア開発企業には、プロジェクトに携わるうちに報告の習慣が身についたが、報告内容は日本人が望むるほど詳細になりません。そのため進捗を報告しても内容が正しくなければ、品質上の問題は依然として発生しています。 前回に記述されたOffshoreのメリットの1つは、優秀なエンジニアのチームを一定期間維持できることです。しかし実際には、何らかの理由より社員が退職したり、別のプロジェクトに異動しなければならなくなったりして、プロジェクトの人材が変更されることになります。新しく交代した要員はプロジェクトに慣れるまでに時間がかかり、ある時は交代要員の能力が以前の要員に及ばず、プロジェクトの品質に影響を及ぼします。 または、他社に比べて大幅に安いコストでオフショアサービスを提供している企業もありますが、それらの企業でエンジニア人材の質が高くないため、顧客が望む品質のある製品の提供は期待できません。 日本と海外では考え方や習慣、国民性が違います。日本人にとって、成果物が納期に間に合うことが厳密に保証すべきです。 しかし、国によって国民性も異なります。スケジュール通りに作業が進まずに、成果物が納期内に納品されないケースも少なくありません。 企業がオフショアへの進出を決定するということは、タイムゾーンの違いがあることを受け入れることを意味します。ニアショア開発であれば、問題が発生した場合、即時対応が可能です。しかし、オフショア開発の場合、何かトラブル等の発生や仕様の修正・確認等、すぐに確認したい事項が生じたとしても相手方が勤務時間外の可能性もあり、レスポンスが遅くなる場合もリスクとして挙げられます。そうなると、プロジェクトの進捗や品質にも影響が出てくる可能性があります。 解決策 前述したように、オフショア開発のコストには、エンジニア人材のコストだけでなく、ブリッジ エンジニア、通訳などのコストも含まれます。小規模プロジェクト (3 名未満) に対して、この追加コストは増加し、コスト削減というメリットがおそらく欠点になる可能性さえあります。 一方で、規模が大きすぎて多くの人員が必要なプロジェクトの場合、日本側がベトナムの働き方や文化に慣れていない時に、人事管理に困難が生じ、管理に時間がかかり、コストが増加します。 言語や文化の違いにより、伝える内容の誤解や理解不足を最小限に抑えるために、定例会議で報告する内容の作成基準やルールを定める必要があります。また、自分が伝えたいことを相手に理解してもらうことを確保するために、相手が彼の母国語で理解済みのことを説明してもらうなど、何度も確認する必要があります。 各会議の後には、双方の間で話し合われた内容を確認するために議事録が作成されなければなりません。報連相活動をプロジェクト実施上に必須要件として盛り込む。また、日本語を通じる国の開発会社を選ぶのも言語リスクを最小限に抑える方法です。 請負契約と異なり、開発会社に作業実装をすべて委託させます。ラボ型契約では、長期に締結する際に、日本側が人員を選定・決定する当事者となります。契約期間中は日本側の同意がなければ人材交代はできません。従って技術のレベルが高いスタッフが厳選・維持することができます。 各国には異なる慣習や文化があるため、オフショア企業がすぐに日本文化に適応することを要求するというよりは、積極的に理解して、変更しして、問題が発生した場合にバックアップ計画を立てる必要があります。 例えば、外国人エンジニアとコミュニケーションを取る際には、言いたいことが一部伝達する、曖昧的に話すということより、自分の希望や要望をわかりやすい言葉で明確に伝える必要があります。 または、オフショア国で休日など勤務時間外に仕事のサポートを要請できるとは期待できません。事前に合意がない限り、すべての問題が翌営業日に処理されます。 システム開発では業務フローをオフショア開発側に理解させることが必要となるので、多くの部門や企業と連絡を取り、話し合う必要があるプロジェクトがあります。しかし、関係者が増えれば増えるほど、コミュニケーションのコントロールが難しくなります。 そのため、単独の部門とのみやりとりするプロジェクトにはコミュニケーションに紐づくデメリットを抑えることができます。  まとめ どんな開発方法にもメリットやデメリットがあります。上記の問題でオフショア開発について心配しないでください。オフショア開発に不安がある顧客様へ、トライアルプランもご用意していますので、是非、詳しくはお問い合わせください。

こんにちは 前の記事には、アジャイルとウォーターフォールの開発モデルの概要や徹底について理解していました。これらの開発モデルがオフショアプロジェクトを開発する際によく適用されている有名なモデルであります。但し、近年IT技術が進化し並びにビジネスのスピードが加速されるため、スクラム開発という他の開発手法がオフショア開発会社においてよく適用されている状態です。 それでは、スクラム開発とはどんな開発モデルのか、他の開発方法とどのように違うのかわからないという方もいるのではないでしょうか。本記事ではスクラム開発の特徴やメリットをわかりやすく解説していきます。 スクラム開発とは スクラム開発は、1990年代に米国の技術者によって生み出され、「スクラムガイド」で定義されています。その中、「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである」と定義しています。 すなわち、スクラム開発（Srum)とはアジャイル手法の1つで、少人数のチームに分かれ短期間の開発サイクルを繰り返し行うフレームワークです。 スクラム開発はチームを組んで役割やタスクを分散させつつ、コミュニケーションを重視するため、チームのコラボレーション向上を促し、インパクトの大きな仕事の達成をサポートする手法として人気があります。 スクラム開発の特徴 スクラムは「経験主義」と「リーン思考」に基づいています。その中、経験主義が知識や経験から生まれ、意思決定が観察によってなされます。リーン思考で、ムダを省き本質に集中します。スクラムが機能するのは3つの本柱を実現しています。詳細は以下となります。 スクラムの3つ本柱 透明性 透明性とは作業状況がわかるようになることです。作業内容及びよい事実も悪い事実もどちらともの状況はチームメンバーやその作業結果を検収する人に見えるようにしておくということです。透明性が欠けた状態では誤解を招き、無駄なものとなる恐れがあります。 検査 チームメンバーが進捗状況やプロセスなどに問題発生がないかどうかを確認するということです。検査は透明性の上に成り立ち、望ましくない状況や問題に気づくために積極的に行う必要があります。 適応 適応は検査の結果に基づき、プロセスやプロダクトの修正を行うということです。検査結果への対応はもちろん、作業中にも手法やプロセスの見直しが必要です。チーム全員が、前回より良くなっているかを問いかけながら、プロセスの改善やプロダクトの軌道修正をできるだけ早く行っています。　 それでは、スクラム開発モデルには具体的なステップが何でしょうか？チームメンバーは何をしますか？スクラム開発プロセスは、以下のように進行します。 スクラム開発のプロセス スクラムスプリントを始めるには、チームリーダーがやるべき仕事を決定し、バックログという一か所で文章化して、管理します。 スプリント計画セッションでは、そのスプリントでバックログのどの仕事に注力するのかを決定します。 スプリント期間中、チームはスプリント計画セッションでチームリーダーがまとめたバックログの内容に取り組みます。通常、1 つのスプリントは 2 週間続きます。ただし、チームに合わせてこれより短くまた長くする場合があります。 デイリーミーティングに進捗情報を共有し、予想外の障害があれば優先度を調整します。 スプリントレビューでは、スクラムチームのメンバーが完了した仕事を報告し、関係者の承認を受けます。 スプリントが終わったら、その感想を共有し、次回以降どういった点が改善できるかについて話し合います。この振り返りはレトロスペクティブと呼ばれます。 スクラム開発におけるルールは、「3つの役割」「５つのイベント」「3つの作成物」といわれています。具合を説明していきます。 スクラム開発で重要な3つの役割 スクラム開発には、「プロジェクトリーダー」がいることなく、スクラムチームに所属するメンバーは大きく３つ役割にわかれています。 プロダクトオーナー（Product Owner） プロダクトオーナーは「何を開発するか決める人」と定義されています。ユーザーの要望を把握し、ユーザーの体験談を開発チームに伝えることに重点を置きます。設計やコーディング、テストなどの開発作業には直接関わりませんが、進捗状況は把握します。 プリントプランニングの際には、POの方が必要な機能を選択し、機能優先順位を付けて、チームのメンバーに説明、共有するようにします。 スクラムマスター（Scrum Master） スクラムがうまく回るように全体を調整するチームリーダーの役割があります。おもな仕事はスクラムのルールや進め方を決め、開発チームが開発期間内に全てのタスクを終わらせることができるように進捗を管理し、開発チームが解決できない課題に取り組み、スクラムの仕組みや進め方を改善するのことです。 開発メンバー（Development Member） 開発者は、スクラムチーム内で、開発作業直接関わるメンバーのことです。プロダクトの開発どのものを専用的に担う役割です。開発者はお互いに支援をする、毎日進捗を共有するという責任を持ちます。チーム構成は通常10人以下で、人数が少ないほど生産性が高い傾向にあるといわれています。 スクラム開発の５つイベント スクラムイベント（Event）とは、スクラム開発を実践する上で必要なミーティングです。プロダクトの検査と適応の機会として設けられていて、スクラムに必要な透明性が実現できるようになっています。クラムイベントを実施することは、規則性を生み、スクラムで定義されていない不要な会議を最小限に抑えることができます。すべてのスクラムイベントは、単純に運用できるように、同じ時間、同じ場所で開催されることが必要です。 スプリント（Spint）とは、アウトプットを出すまでの期間のことです。スクラムチームでスプリントの期間を決めて、スプリント内のスクラムイベントを通して、検査と適応を行います。スプリント期間が長すぎると、検査と適応を小まめに実施できないので、リスクが高まります。スプリント期間を短くすると、より多くの学習サイクルが生まれ、リスクが大きくなる前に潰せます。ただ、スプリントは一ヶ月以内の期間で終了します。 スプリントプランニング（Sprint Planning） スプリントプランニングとは、スプリントのゴールを達成するために必要な作業を計画するイベントです。スプリントプラニングの中に、アウトプットまでの期間に何をするのかをチームで話し合います。プリントバックログ（スプリント期間中にチームが取り組む作業アイテムを明確にするための手段）を作成し、アイテムの洗い出しをしておきます。 デイリースクラム（Daily Scrum） デイリースクラムとは、スプリントゴールが達成できるか検査するためのイベントです。デイリースクラムには、スプリントゴールへの進捗状況を確認し、問題点、解決したことなどを共有し、必要に応じてスプリントバックログを修正し、今後の予定作業を調整します。 リファインメント（Refinement）  （任意） リファインメントとは、プロダクトバックログアイテムをより詳細にするイベントです。プロダクトバックログアイテムは開発チームが目標を達成するために、必要となるアイテムやタスクに優先順位をつけてリスト化した一覧に登録されているタスクのことです。POと開発メンバーはプロダクトバックログアイテムの内容や見積もり、優先準備などの内容を確認し、詳細化します。 スプリントレビュー（Sprint Review） スプリントレビューとは、スプリントの成果を確認し、フィードバックを得るイベントです。スプリントの成果(インクリメント)をデモすることで、フィードバックを引き出します。フィードバックを元に、プロダクトバックログの項目追加や優先順位の変更を検討して、今後に向けた改善策を見つけていきます。 […]

システムやソフトウェアを開発する手法と言えば、アジャイル開発とをウォーターフォール開発という２つの有名な開発モデルがよく耳にするでしょう。 ウォーターフォール開発とアジャイル開発はそれぞれ特徴が違います。ただし、近年ではアジャイル開発がよく使われるようになっています。オフショア開発中にアジャイル開発とウォーターフォール開発のどちらで進めた法が良いですか？ 本記事では、ウォーターフォール開発とアジャイル開発の開発手順の違い、またメリットデメリットについても解説させていただきます。 まずはそれぞれの開発手法がどんなものなのか、かつ特徴を見ていきましょう。 アジャイル開発とは アジャイル開発は現主流になっているシステムやソフトウェアの開発手法の１つで、「計画→設計→実装→テスト」といった開発工程を機能単位の小さいサイクルで繰り返すのが最大の特徴です。この開発型には優先度の高い要件から順に開発を進めていき、開発した各機能を集合体として１つの大きなシステムを形成します。 アジャイル型の開発では、各スプリント「計画→設計→実装→テスト」に分かれています。スプリントの期間は開発チームによって設定が変わりますが、1〜4週間程度が一般的です。あらかじめ厳密に仕様を決めなく、プロジェクトを進めながら柔軟に仕様変更・修正が可能です。アジャイル開発はプロダクトの価値を最大化することに重点を置いた開発手法です。従って、アジャイル開発が顧客ニーズや市場変化が変わる場合に向けると思われます。 ウォーターフォール開発とは ウォーターフォール型開発とは、開発手順を１つずつ確認しながら工程を進めていく手法のことです。開発作業を各工程に分けて進めますが、次のフェーズに進んでしまうと後戻りができない手法でもあります。その開発型の特徴は、一つ一つに工程に抜け漏れがないかどうか厳重に管理しながら進めていくことです。 ウォーターフォール開発では、開発工程を上流工程から下流工程へ順次移行していて、水が下に落ちていく様です。要件定義が詳細まで固められた上、定義した内容をもとに順に開発を進めていきます。 ウォーターフォールモデルの開発工程が「要件定義→基本設計→詳細設計→開発・実装→テスト→リリース」という６つに分けられています。最初に要件定義を確定、第一の工程が完了したら、次の工程に移動するといったように１つずつ工程が完了させていきます。 ウォーターフォール開発は、時間をかけて完成度の高いシステムを作る方法なので、市場や状況の変化に合わせて常に新しい機能の追加が必要なシステム開発には適していません。 アジャイル開発とウォーターフォール開発の違い 開発工程について ウォーターフォール型に計画からリリースまでの流れについて、企画の段階で全体像を定義して、設計書が出来上がったら製造の段階を進めます。変更や要望などを製造中で取り入れることはできません。テストは各工程で行うのではなく、テスト段階でのみ行われます。システムを利用できるのは、すべての工程が終わってからとなります。 一方、アジャイル型でとりあえずチームを組んで、要件定義や設計、製造、テスト、リリースといった開発の工程をひとつずつ分けて小さな機能単位で反復させながら完成させていきます。顧客の要望や変更などは開発期間中ならいつでも取り入れることはできます。テストも各工程でそれぞれ行われます。そのため、リリースまで軽量でスピーディーに対応できます。 それぞれのメリット・デメリット ウォーターフォール開発ではゴールが明確であるので、作業時間、量などを把握できて、スケジュール管理がしやすくなります。顧客の要件が定義して、やるべきことが決定しているため完成品の品質を維持でき、バグは少ないようになります。 ただし、その開発型は品質を重視した手法であるからこそ、完成するまでの期間が長くかかるものが多いです。もし途中段階で仕様の見直しをすることになった場合、完成まで時間が大きく遅れるだけではなくコストも膨らんでしまいます。また、テストを経て初期の段階でトラブルや不具合が発生した場合、開発をやり直す工程が多くなり、大幅な時間とコストがかかってしまいます。 アジャイル開発は、小さな単位で計画、設計し、製造してテストを繰り返しながら開発を進めるので、全工程が完了していなくても反復ごとに機能をリリースできます。したがって、スピード感のある開発や新機能の提供が可能です。開発しながら、顧客のフィードバックをもらって製品に反映することで、アジャイル型は柔軟性高いの手法であると見なされます。また、不具合が発生した場合に、戻る工程が増えることなく、1つの反復の中を見直しするだけでいいので時間もコストも抑えられます。 アジャイル開発のデメリットについては、最初から顧客の要件を決定せずに開発を進めるので、開発の方向性がブレやすくなります。完了までの時間が長引きいたり、コストが増加したりする可能性があります。 プロジェクトに適応するどっちの開発手法を選ぶ？アジャイルとウォーターフォールの使い分け ウォーターフォール開発とアジャイル開発には、それぞれメリットデメリットがある。そのため、プロジェクトの目的によって開発手法の選択も異なります。２つの上記手法のメリットをよく理解して、プロジェクトごとに開発手法を選ぶと良いでしょう。 ウォーターフォール開発が、大規模なシステム開発や建設プロジェクトなど、作業が明確に定義されている案件に向けています。 ウォーターフォール開発が向けてるプロジェクト 一方、アジャイル開発は、最初に要件を固めず、ユーザーや顧客の反応を見ながら開発するという手法で、優先度や作るものに変更の可能性があるケース、先に一部の機能をリリースしてその後機能を拡張させていきたいなどのプロジェクトにむけています。 アジャイル開発が向けてるプロジェクト 両開発手法を組み合わせて「ハイブリッド手法」で実施する 実際には、両開発手法のメッリトを最大限に活用するために、「ハイブリッド開発」を選択しているオフショア会社が多いです。ハイブリッド開発では、要件定義と設計の段階がウォーターフォール型ように進めていく、実装段階からアジャイル型ようなスプリント単位での開発に切り替わるということです。各スプリント間で、ウォーターフォール型のステップを取り入れて、チームが進捗や品質を管理しやくなります。 ハイブリッド開発を活用することで、途中で仕様変更を対応できながら、予算やスケジュールの不明確性といったデメリットを解消できます。 まとめに 両開発手法はそれぞれに特徴があります。開発手法を選択する際にご不明なところがございましたら、是非一度、弊社までお気軽にご相談ください。

オフショア開発とは、海外企業にシステム開発業務の全部または一部等を委託する開発手法のことです。国内よりも優秀なエンジニアを確保し、開発コストも低く抑えることができるため、年々その手法を選択する企業が増えてきています。従って昨今でオフショア開発が盛んに行われています。 海外に業務を委託する際に、「契約締結はどうするのか」、「契約にはどのような種類があるのか」といった疑問する企業も少なくありません。オフショア開発における契約書とは委託先及び受託先を含むということです。オフショア開発の契約書には、各当事者の義務と責任が定められております。但し、契約種類によって、契約の対象が納品する成果物、あるいは受託先が行う労働であることになります。 オフショア開発には請負型開発とラボ型開発という２つのコンセプトがよく挙げられます。請負型開発とラボ型開発はどういう違いがあるか、かつどちらを選べば良いかなどの２つの開発形態に関する質問に対しては、本文でご分析していきます。 請負契約とは 請負契約とは、成果物を完成させる義務（完成責任）があり、受託先が作業結果の検収が完了された後に報酬を支払われる契約形態です。もしも納品物に不備や指摘があれば修正する義務があります。また、責任自体は受注側が負うことになるため、委託先は受託先に作業に対する指揮命令権がございません。 請負契約のメリットについて２つあります。 請負は具体的な納期と納品物の仕様を取り決めたうえで契約を結ぶ仕組みであるため、もし納品までに成果物の品質が基準に満たさない場合は、修正業務が発生されます。請負契約には受託先に対して納品・品質の担保責任が高く定められます。 委託先は成果物に対しての報酬を支払うのみですので、教育コストを大幅に削減することが出来ます。 請負契約においてデメリットは2つ挙げられます。詳細は以下となります。 もしも設計に不備があったままシステム開発を依頼してしまうと、不備を抱えた成果物がそのまま納品されてしまいます。請負契約において納品物に不備があった場合の修正は行ってもらえますが、発注後に追加で修正を依頼するのは困難です。仕様変更による追加費用が発生します。そのため、発注ときに、要件定義をしっかり明確にする必要があります。 海外会社に業務を委託するとき、委託会社において開発の知見・経験が蓄積されにくくなります。 ラボ契約とは ラボ契約とは半年や1年間など一定期間中に専属開発チームとして固定でエンジニアを確保し、発注者側の指示で開発を行う契約です。ラボ契約は作業要員と期間をベースにし、また開発チームは発注元の業務のみを行うため、期間中は専属のチームのように活用できます。 請負契約が成果物の完成を目的とするのに対し、ラボ契約は労働の代行を目的としている点が異なります。 プロジェクトをラボ型で実施中に、お客様はブリッジSE、またはプロジェクトマネージャーと直接コミュニケーションをとって、開発チームに作業内容を指示します。 ラボ型開発のメリットは主に以下の4点です。 ラボ型開発の期間に、途中でも仕様を変更したい場合は対応可能で、発生する可能性がある仕様変更に伴う追加コストはかかりません。 優秀な人材リソースを安定的に確保して開発できると、ボ型開発の委託先が発注側の業務体制や企業風土に慣れて、高いクオリティの成果物をスピーディーに納品できるようになります。優秀なエンジニアを確保し続けることができるため、持続的で安定した開発を実現できます。 優秀なエンジニアを一定期間確保することできるため、技術的なノウハウを蓄積しやすく、より効率的な開発をすすめることができます。開発ノウハウが溜まっていない技術を使用するプロジェクトでは、その分野に強いラボ型開発会社と協力すると、ノウハウを蓄積しやすい体制を構築することができます。 ラボ型開発では、途中で仕様変更をしたり、各種調整したりすることがよく発生されています。しかし、長期間人材を固定して行うため、急な仕様の変更でも柔軟的に対応することができます。 ラボ型開発には様々なメリットがある一方で、ラボ型開発にはデメリットがあります。 ラボ型開発は一定期間専属のチームを確保できる形態なので、期間中に定量の発注を続ければコストパフォーマンスが良いです。逆に、短期間の単発案件または作業量が連続的に発注しないと開発チームのリソースを無駄になってしまいます。あるいは、契約期間中であれば、作業の有無に関わらず費用が発生される。 ラボ型開発は長期間の開発なので、開発チームの構築が非常に重要になります。チームメンバーを選ぶさいに、単純にスキルが高い人材を集めること以外、開発内容や自社の文化など様々な要素を考慮し、開発内容に合っていて相性の良い人材を選んでチームを構築する必要があります。 さらに、請負契約と異なり、ラボ型開発では全てを片側に任せられるわけではなく、開発を円滑に進めるために、両方がチームとして協働する必要があります。双方も主体的にチームビルディングやマネジメントをする必要があることから、発注元の負担は請負契約と比べると大きくなります。 請負型開発とラボ型開発の違い オフショア開発の契約書締結までの流れ オフショア開発中に、契約種類にかからず大まかな流が同じになります。そのため主な流れは以下と成ります。 お客様の希望要件、また課題をヒアリングすることで、やりたいことを検討して、希望の仕様等定めるようになります。ヒアリング中に、オフショア開発側が様々な疑問なども確認を行って、対応できるかどうかを判断するようになります。 希望についてヒアリング・相談してから、秘密保守契約書（NDA）を交わするにします。 NDAを締結することより、双方は事前に相手許可なく案件に関わる情報が外部や第三者に漏洩しないように確保する責任を負います。 双方は案件状況や希望する条件等に合わせて開発方法また契約方式を決定します。 開発方式に関しては 要件や仕様を最初より決定できた場合、ウォーターフォールモデルで開発することがよく挙げられます。 もし、開発を進めながら設計や開発・実装等を進めていく場合、アジャイルモデルがよく選択されています。 開発方式が統一された上、基本契約が進められます。基本契約には各当事者の権利や責任に関する条件が指定されます。 調整・検討を行った条件を元に、受託先が見積もりを用意し、また提案書を提出します。見積もり・提案書を完了できるために、不明な内容や不適切な項目があれば絶対に明確する必要があります。なぜなら、契約を締結してしまった後では、項目や条件の調整が難しくなるためです。 委託先が見積もり・提案書に全ての項目や条件を承認していただければ、詳細契約締結（発注書）を進めます。 詳細契約及び発注書に金額、工数または支払い条件などが定められます。 まとめ オフショア開発にはさまざまな契約形態があり、それぞれに特徴があります。オフショア開発をご検討中の際は、是非一度、弊社までお気軽にご相談ください。貴社に最適なオフショア開発の形態をご提案いたします。

「オフショア」という言葉は、英語の「offshore」から来ています。「offshore」は「岸から離れた場所」を指します。「オフショアリング」また「offshoring」はビジネスプロセス、製造業、開発業などを国外に移動させるということです。 IT業界におけるオフショアとは  IT業界における「オフショア」とは企業が自社のIT関連業務の全部、または一部やソフトウェア開発・保守・運用などを、よりも人件費の安い海外にあるパートナー企業に委託することを指します。オフショアの主な目的はコスト削減やリソース補完のためです。 IT開発工程の一部を外部にアウトソーシングすることが「オフショア開発」と呼ばれます。オフショアがアウトソーシングとよく混同されがちですが、アウトソーシングは国内外問わずに社外に業務の一部を委託することを指します。基本的に、アウトソーシング形態の中にオフショア、オンショアとニアショアを含めます。 「オンショア開発」は自社内で開発を完結させるということです。「オンショア開発」のメリットは、言葉、文化の違いがないので意思の疎通が行いやすいことや、機密保持がしやすいことなどがあります。但し、高齢化社会が進むとともに、労働者特にITエンジニアの人材不足の状況が続いています。さらに、日本企業がIT化を進めるのに、IT業界の人件費が非常に高くなります。そのため、オンショア開発を行うと、人件費に関する問題を解決できなくなります。 「ニアショア開発」も「オフショア開発」と同様に外部へ業務委託する点は共通しているのですが、「オフショア」は海外へ業務委託するのに対し、「ニアショア」は国内の地方都市に業務委託する場合に使われます。「ニアショア」では、言葉、文化の違いがないので意思の疎通が行いやすいといったメリットがありますが、一般的に「オフショア」のほど開発コストを抑えることはあまりできません。 オフショア開発のメリット コスト削減 物価の高い、かつITエンジニアの人材不足の国である日本国などの先進国で開発することより、人件費や物価の安い海外でオフショア開発を行うことで、開発コストを大幅に削減することができます。 豊富な人材 プログラマーやエンジニアは、ベトナムなどの新興国を中心に人気を集める職業の一つであり、優秀な人材が多いだけではなくその技術力の高さも評価されています。 リソースの確保 海外の豊富な人材を雇用することで、足りない労働力やIT開発のリソースを補うことができます。また、オフショア開発なら、ラボ型を選択することができます。そのとき、開発チームを固定することになり、契約期間中は優秀なITエンジニアを自社要員として確保でき、柔軟かつ効率的に開発を進めやすくなります。 オフショア開発の問題 コミュニケーションの問題 海外とやり取りするとき、言語や文化の壁があるので、コミュニケーションの面で問題が起こったり、意思疎通がうまくできないと困ることになります。 また、言語も異なるため、日本語独特のニュアンスが伝わらず、従って求めている品質がうまく伝なく、高品質なシステム開発を担保できなくなってしまいます。 進捗や品質の管理 物理的に距離が離れているので、進捗や品質の確認をすぐに行えません。緊急時にオフショア開発会社と連絡がとれなければ、不安を感じるでしょう。 または、習慣のズレからくる問題により、計画よりも進捗が遅れたり、納期に間に合わなかったりするケースが生じます。報告通りに進捗管理を行い問題がないようでも、実際には品質が顧客の期待を満たしていない可能性があります。 小規模開発ではコスト削減 オフショア開発にはITエンジニアだけでなく、ブリッジSEやコミュニケーターも参加します。そのため、開発エンジニアの人件費以外にも費用がかかります。小規模な案件だと、人件費以外の費用がかさんでしまい、当初の想定よりもコストメリットが出ないことがあります。 オフショア開発現状、ベトナムが選ばれるのは なぜ？ かつてオフショア開発の中心は中国でしたが、近年ではインドの他、ベトナムやフィリピン、バングラデシュ、ミャンマーなどの東南アジアにその中心が移っている傾向があります。その中でも数多くの日本企業向けのオフショア開発企業が存在しています。 理由としては、先進国でのIT人材不足や人件費増加の状況により、新興国へオフショアを行うのは一つの効果なソリューションだということです。それで東南アジアはその豊富なIT人材や優れた技術力といったITリソースの確保を目的としたオフショア開発先として挙げられています。 オフショア開発白書(2022年版)によると、オフショア開発国の人気ランキングは以下のとおりです。 出典：オフショア開発白書（2022年版） このように、オフショア開発案件の国別割合はベトナムが50％近い人気のシェアを占めており、オフショア開発国のなかでは圧倒的な人気を集めていることがわかります。 ではなぜ、ベトナムが人気のオフショア開発国になるか、なぜオフショア開発を行う際にベトナムが選ばれるのでしょうか？ベトナムが日本企業より高く評価されている特徴やメリットが持つのでしょうか？  優秀なIT人材 ベトナムでは大学や専門学校などでコンピュータサイエンスなどのITの専門的な教育を受けたIT人材の数が年々増加しています。 TOPDevの2022年のレポートによると、ベトナム国内のIT人材人口は48万人となり、そのうち20代がベトナム人ITエンジニアの約54%と過半数を占めています。経験年数が2-3年が最も多く27.40%、4年以上のITエンジニアが約17.60%となっています。 出典：Vietnam IT Market Report – Tech Hiring 2022 ITの専門教育を受けた上で実務経験を積んだ豊富なベトナムIT人材は、日本企業にとって非常に大きな魅力の一つとなっています。 また、ベトナムのITエンジニアは基本的にコンピュータサイエンスなどのITの専門知識が持ったり、一流大学を卒業したので、能力レベルは高いと評価されました。 ベトナムのオフショア開発企業ではIT知識や日本語などの外語系資格の勉強に取り組むことが多いです。社内で学習慣を構築することはベトナムでソフトウェア開発会社の共通の文化となっており、自社の人材品質確保も行えるようになるのです。 ベトナムにおいて日本語は第二外国語として人気があるようで、日本語でやり取りできるエンジニアもだんだん多くなっています。日本語を使用できるIT人材を採用することが難しくありません。それは言語の障壁を取り除けて、顧客からの依頼を築くようになります。 安価な人件費 ベトナムでは、高い経済成長率を背景に人件費が上昇傾向にありますが、それでもまだまだ日本の人件費水準と比べると安い水準にあるというのが現状です。 ベトナムのITエンジニアの平均月給は、約13万円（986ドル/月）です。一方で日本のITエンジニアの平均月給は約41万円であり、ベトナムのITエンジニアの給料は日本のITエンジニアの給料の約30%となることから、ベトナムと日本のITエンジニアの給与の比率はおおよそ3倍となります。 （参照：ベトナムのITエンジニアの給料・単価相場と、円安の影響について【2023年最新版】） ベトナム人エンジニアの高いITスキルと比較的安価な人件費は、IT人材の高騰が進む日本企業にとってメリットとなっています。 先端テクノロジーの活用 （ベトナムIT市場レポート2022）をもとに、ベトナム人ITエンジニアのテックスタックは以下のとおりです。 出典：Vietnam IT Market […]

Ngày 20 tháng 3 năm 2023, Công ty PiraGo Việt Nam đã nhận được chứng nhận quốc tế về hệ thống quản lý chất lượng [ISO 9001:2015] và chứng nhận quốc tế về hệ thống quản lý an toàn thông tin (ISMS) [ISO/IEC 27001:2013]. Với chứng nhận ISMS, trong thời gian tới công ty PiraGo […]