【2021最新】はじめてのオフショア開発と失敗事例と成功事例(xR、AWS、マイグレーション)
ONETECHは2015年にスタートして2021年に7期目を迎えました。6年間で80社以上200を超えるプロダクトを納品してきました。特に近年ではxR領域、AWS、マイグレーション分野に力を入れております。2021年9月に実施したセミナーでは、オフショア開発の失敗事例と成功事例を整理し紹介しました。オフショア開発とは何かとどうすれば成功するかを本ブログにて公開したいと思います。
本日のアジェンダ | セミナー中のお願い |
第一部 オフショア開発とは ・オフショア開発導入前の準備 ・オフショア開発の契約や体制 |
1.質問に関して
発表中の質問はチャットでお願いします。 |
第二部 オフショア開発の失敗事例と改善 ・失敗事例 ・失敗要因と改善 ・改善と対策①開発 ・改善と対策②保守運用 |
2.発表中は音声をミュート
発表中は音声をミュートでお願いします。 |
第三部 オフショア開発の成功実例 ・xR開発事例 ・VB6マイグレーションの事例 ・WEBシステムをAWSでサーバレス構築運用事例 |
3.セミナー録画について
本セミナーは録画しております。 |
第四部 質疑応答 時間の許す限り質疑応答 |
4.発表資料について
後日アンケートにお答えいただいた方に |
第一部 オフショア開発とは
- オフショア開発導入前の準備
- オフショア開発の契約や体制
オフショア開発の導入前の準備
- オフショア開発とは
- オフショア開発のメリット・デメリット
- オフショア開発国の特徴や単価(ベトナム)
- オフショア開発導入の流れ
- オフショア開発企業の選定方法
オフショア開発とは
国内企業が海外のIT企業にアプリ開発やシステム開発、ソフトウェア開発、CGデジタル、コンテンツの制作、システム運用保守管理などを委託(アウトソーシング)する方法がオフショア開発です。
日本企業の45%がオフショア開発を導入しています。(独立行政法人情報処理推進機構(IPA))
オフショア開発のメリットデメリット
メリット | ・コスト削減
・優秀なエンジニアの確保 |
デメリット | ・コミュニケーションの負荷
・認識違いによるコスト増 |
オフショア国の特徴
オフショア 提供国 |
人口 (‘19) (億人) |
外国語 | 特徴 |
中国 | 14億人 | 日本語:◎ 英 語:○ |
対日本のオフショアの開発実績が多数あり、優秀な人材が多いのが特徴。漢字圏で日本語能力も高い。多くの日本企業が進出済みで優秀な人材の確保は難しくなりつつあり単価も上昇傾向です。コスト削減以外のメリットを求めて中長期に開拓するのが良い。 |
インド | 13億人 | 日本語:△ 英 語:◎ |
欧米相手に実績が豊富で世界で最も注目されているIT人材が豊富な国。優秀な技術者が多く大規模案件が増えているが単価も上昇中。英語が堪能なので発注者側が英語必須。狙い目は成長段階の企業との業務提携や子会社化を進めることだが時間がかかる。 |
ベトナム | 1億人 | 日本語:◎ 英 語:○ |
政府が対日本向けのオフショア開発に力を入れています。優秀な国家大学でもIT教育に力を入れており豊富な人材が供給されています。IT人材以外への日本就労のための日本語学習も盛んで日本語能力は年々上がっています。 |
フィリピン | 1.1億人 | 日本語:△ 英 語:◎ |
大学進学率が高く新興国の中でも優秀なITエンジニアが多い。欧米中心に仕事をしていることが多く英語のサイトやアプリ開発に慣れている。発注者が英語で業務ができると選択肢になる。マーケットしてソフトウェアを展開できる可能性も○。 |
バングラ ディッシュ |
1.6億人 | 日本語:△ 英 語:◎ |
インドの北部に位置しているのでインドに似ている。技能能力は高く英語が堪能。欧米の案件の実績も豊富。中国やベトナムと比べても物価や賃金が急激に上がらないと言われている。 |
ミャンマー |
0.5億人 | 日本語:◎ 英 語:○ |
勤勉なので日本語習得スピードが速い。協調性があり、おとなしい性格なのでチームワークに向いている。アジア最後のフロンティアと呼ばれていて人材獲得競争は起こっていないが、ITインフラの整備は遅れている。停電が多い。女性ITエンジニアが多い。 |
参考:http://www.offshore-kaihatsu.com
国別の開発単価
オフショア提供国 | 人月単価 (万円) |
単価傾向 | GDP 成長率 (‘19 ) |
メモ |
中国 | 35〜40 | ↑ | 6.1% | 沿岸部(上海、北京、大連など)単価が上昇、内陸部へシフト。 |
インド | 35〜40 | ↑ | 4.3% | 欧米相手にオフショアが急成長中。優秀な技術者が多く大規模案件が増えているが単価も上昇中。 |
ベトナム | 30万円〜35万円 | ↗︎ | 7.0% | ハノイ、ホーチミン中心、最近ではダナンなどが注目されている。 |
フィリピン | 30〜35 | ↗︎ | 5.9% | 人口が1億人弱でリソースが豊富。英語で業務ができると選択肢になる。 |
バングラ デ ィッシュ |
25〜30 | → | 7.9% | 単価の幅が広く、高度な案件とコスト削減のための案件まで幅広く対応可能。物価や賃金も安定している。 |
ミャンマー |
25〜30 | → | 6.5% | 6カ国で最も単価が安い。日本語習得者も多く、中国、インドと比較するとコストが半分近くなるケースもある。 |
参考: https://www.globalnote.jp/post-12798.html
IMF統計に基づく実質ベースGDP(国際総生産)の前年比伸び率
実質GDPは名目GDPから物価変動による増減分を取り除いたもの。
参考:http://www.offshore-kaihatsu.com
ベトナムの優位性
国民性 | 政府レベル、民間レベルでも日本と友好な関係を保っています。勤勉でまじめでおとなしい性格が多いです。オフはスポーツや旅行をしたり飲みに行ったり明るく活気のある性格です。 |
日本語能力 | 日本語学習者が6万人(世界8位:2015年)とありますが、すでに留学生は8万人(2019年)日本に滞在しているベトナム人は41万人います。2016年、全土の小学校で日本語を「第1外国語」として教えることを目指す方針を発表しています。 |
技術能力 | 政府がIT産業とIT教育に優遇策を施行して力を入れています。
基盤となる数学、科学の分野では国際的にも上位ランクに位置しています。 |
人材の豊富さ・若さ | ベトナムの国全体の平均年齢は28才です。政府が2020年中に100万人のITエンジニアを輩出しようと政策を打ち出しています。継続的に人材の供給が可能です。 |
地理的、物理的要因 | ベトナムとの時差は、2時間です。始業時間は日本より早いので時差の影響が少ないのが特徴です。祝日が日本と比べて半分ほどしかなく稼働日数が長いのも特徴です。 |
オフショア開発の契約や体制
- オフショア開発の契約形態・開発手法
- オフショア開発の体制
- オフショア開発のコミュニケーション
- オフショア開発の工程と業務範囲
オフショア開発の契約形態
契約種別 | 内容 | 良い点 |
向いている |
請負 契約 (受託) |
原則、仕様書をもとにウォーターフォール方式で開発を進めます。受託開発。
品質、納期を担保します。 |
•納期と品質の担保
•工期の短縮 •トラブルが少ない •固定費化しない |
•仕様確定案件
•短期案件 |
ラボ型 契約 |
準委任契約として一定期間クライアントの要望に応じたリソースを確保。
ブリッジ、エンジニア、テスターの体制を担保します。 |
•仕様変更に柔軟に対応
•社内手続きの簡素化 •優秀なエンジニアの確保 •ノウハウの蓄積 |
•アジャイル開発
•R&D開発 •MVP手法の開発 •保守運用 •似た案件を連続開発 |
開発手法
受託開発はいわゆるウォーターフォール型で、水が上流から下流に下るように開発していきます。上流工程の要件定義や使用定義をしっかりすることで下流工程も明確になり、トラブルが減ります。
一方でラボ型開発はアジャイル開発で進めることが多いです。柔軟に開発できたり、MVP手法やリーンスタートアップ手法のようにスピーディーに市場でテストをするなどの工程でよく用いられます。しかしながらドキュメントやプロセスをスキップしてしまう傾向がありしっかりとルールを決めていかないとトラブルになることも多いです。
オフショア開発の体制
受託開発とラボ型開発での違いは特にコミュニケーションかと思います。受託開発はウォーターフォール型で仕様が決まっているケースが多いので、コミュニケーションは仕様の確認です。ラボ型開発はアジャイル開発なのでブリッジと発注者が確認相談を繰り返します。ラボ開発の方がコミュニケーションや開発能力(業務理解能力や技術力)が要求されます。ラボ開発の成功のかぎはブリッジの能力がポイントとなります。一方で優秀なブリッジSEはあまり多くはありません。
オフショア開発のコミュニケーション
弊社の場合は全て日本語で対応可能です。オフショア会社によって日本語能力はばらつきがあります。やはり日本に拠点があるかどうか、日本人がいるかどうかで当然日本語能力は変わってきます。(しかしながら日本人や日本在住のコストがかかるので費用が高くなります)。コミュニケーションは日本拠点がある場合は日本企業と同じ手法で行われます。もちろん対面面談やクライアントへの訪問も可能です。
オフショア開発の工程と業務範囲
オフショア開発はウォーターフォール型で開発(製造)やテストを主体にするのが失敗は少ないです。ドキュメントに書いてある通りに開発する方が失敗は少ないです。
もちろん企画や要件定義段階からサポートすることも可能です。しかしながら複雑な業務でベトナムや海外では馴染みのない業務フローだと業務を理解するための時間とコストが発生します。
またデザインは最近ですとグローバルなユニバーサルデザインは問題なくなってきていますが和風とか侘び寂びを表現するような日本独特なデザインは苦戦します。
オフショア開発導入の流れ
流れ | ポイント |
オフショア開発国と企業を選定 | マクロの視点:国選び(複数の国を選ぶことも)
候補の国があったらその国へ訪問するのがベター ミクロの視点:企業選びのチェックポイント参照 |
オフショア開発企業と面談 | 複数の企業と打ち合わせ
オンライン、対面 |
NDA(秘密保持契約締結) | 日本語で締結
紛争の際、日本法や日本の裁判所での実施 再委託に注意 |
見積もりを取得 | 相見積もりする。安すぎないか、高すぎないか
適切な工程と工数が見積もられているか 概算でも見積書で要件や仕様理解のレベル感がわかる |
発注企業の担当者と面談 | 実際にプロジェクト参加をする人材との面談
ラボ型開発ではアサインされるエンジニアの職務経歴書をチェック |
取引条件確認
(基本契約書、覚書など締結) |
日本での取引と同様な契約条項を網羅
基本取引契約書、業務委託契約書 発注書、発注請負書など日本語で契約できるか |
オフショア開発 開始 |
企業選定のチェックリスト
観点 | チェック | 内容 |
ビジネス | ✔️ | 日本法人などの日本窓口はあるか。現地に日本人はいるか。 |
✔️ | 契約書は日本語か英語か。契約は日本法に準拠しているか。 | |
✔️ | 支払いは国内銀行か、支払い通貨は、送金手数料や為替リスクも確認。 | |
✔️ | 問題が発生した場合の窓口にすぐに電話できるか。 | |
✔️ | 非機能要件は確認されたか。セキュリティ対策は万全か。 | |
開発・技術力 | ✔️ | 発注したいシステムの実績は豊富か。 |
✔️ | 発注したいシステムの技術者の人数は十分か。 | |
✔️ | ドキュメントの品質は問題ないか。サンプルの提示依頼。 | |
✔️ | 開発体制やシステム開発工程はしっかりしているか。 | |
✔️ | 技術トラブルや仕様の理解の際に日本語対応は可能か。 | |
✔️ | 瑕疵担保をしてくれるか。 | |
✔️ | 旧正月などの長期休暇や休暇中の体制は? |
上記のようなチェックリストを作り数社の比較をされると良いと思います。また小さなトライアルをして発注者側の担当者もオフショア開発を経験されるのも良いかもしれません。
第二部 失敗事例と改善
- 失敗事例
- 失敗要因と改善ポイント
- 改善と成功のためのポイント
- オフショア開発を成功させるには
ここでは弊社の失敗事例をもとに、なぜ失敗してしまったのかを分析します。
失敗事例(1):複雑な業務で業務理解が不足
老舗の医療器具の管理システム | |
■システム概要
医療器具を、発注、製造工程、在庫、デリバリー |
■発生してしまった事象 システムを使う関連部署やユーザーが多く、 業務が複雑で要件に漏れがあり 何度も仕様変更とやり直しが発生 対策としてモックアップを作って確認フローを入れたが 担当者に承認されたのにも関わらずやり直しが発生 |
原因 | ポイント |
業務理解 | 発注者側のシステム担当者の業務理解の不足
受注側の業務理解の不足 |
業務範囲 | 受発注側の業務範囲の事前合意が曖昧
業務範囲が一部空白(どこまで提案するかが曖昧) |
ドキュメント | ドキュメントの品質とドキュメントの不足
(業務フロー抜け漏れ、システムのシーケンスなど不足) |
レビューの徹底 | 現場承認をとったモックが最終的に否認されやり直し
原因は担当者と弊社の業務理解の不足 |
失敗事例(2)リーンスタートアップの落とし穴
スタートアップの広告代理業のクーポン発行システム |
|
■システム概要
指定された広告商品をSNSで投稿すると |
■発生した事象 SNSサードパーティーの仕様変更 スマホのカメラの仕様差分(iOS/Android)よるハードル プロジェクト途中でのビジネスモデルの変更(リーンスタートアップ)と担当者の変更、さらに納期は決まっており、設計不足、テスト不足でバグが多数発生 |
原因 | ポイント |
業務理解 | 数回のビジネスモデルの変更(ポイントの交換方法)により、ビジネス理解と業務フローの理解が追いつかなかった |
業務範囲 | SNSやOSの仕様やポリシー確認などを受発注者どちらの責任で確認するか曖昧 |
ドキュメント | アジャイル的な開発でドキュメントの不足、ドキュメントなしですぐに着手 その結果担当者変更の際に仕様がブラックボックス化してしまう |
レビューの徹底 | 仕様変更が発生しても納期は変わらず、ドキュメントなし、レビューなしでシステムがブラックボックス化 |
失敗事例(3):保守運用の定義不足
住宅販売会社の顧客管理チャットアプリの保守運用 |
|
■システム概要
住宅販売会社の顧客管理や営業支援をする |
■発生してしまった事象 お客様が先に問題を検知して それを弊社の方で修正、後手に回ってしまう 障害時にタイムリーな報告ができない 重要な問題の切り分けができない |
原因 | ポイント |
業務範囲 | 24/365の対応はしていないが、保守時間外に問題が発生した時にどのような対応をするかが曖昧 |
業務定義 | 監視項目や保守業務の定義が曖昧で、クライアントに暗黙で要求された管理業務を行なっていない(クライアントアカウントのSSLやOSSの更新切れ) |
ドキュメント | 保守運用の設計ドキュメントはあったが、いつ誰が何を対応するのかが曖昧になっていた |
報告の徹底 | 障害発生時に状況報告などをタイムリーに共有できずにクライアントに何度も問い合わせをさせてしまった。報告方法が属人的だった |
課題が発生する箇所
上記のような例から問題が発生してしまうポイントはほぼ上流工程にあります。テスト段階で仕様の誤認であったり仕様の漏れであったり、設計ミスであったりすることがほとんどです。クライアントが受け入れてテストの段階で、期待通りにシステムが動かないケースがありますが、ほぼ前述した原因です。
次に多いのが途中工程での第三者のレビュー不足です。仕様や設計に問題がなかったとしても仕様通りにプログラミングできていない場合に工程ごとのレビューで気づくことができます。しかしながらレビューというプロセスをスキップして「完了しました!」という言葉を信じて下流工程で後悔することがよくあります。
失敗要因と改善のポイント
成功のための改善ポイント
- ドキュメントの整備
- 開発工程の管理の見直し
- キックオフ会議の徹底
- 保守運用の定義
先の失敗事例を減らして成功につなげていくかを紹介します。
改善1.ドキュメントリストの整備
改善点 | 内容 | 効果 |
業務範囲明確化 | 全ての業務をリスト化 | 業務仕様がチェックリスト化されて漏れがなくなり発注者、開発者の統一見解テンプレート化されているので業務品質の標準化 |
ドキュメント | 必要なドキュメントをリスト化全てのサンプルも用意 | |
要件明確化 | 非機能要件をリスト化 |
見積詳細例
ONETECHでは失敗事例をいかにして改善していくかということを毎週定例会議話し合っています。結果的に開発プロセスと必要なドキュメントや品質基準を明文化しています。それをいくつかご紹介します。
業務範囲、業務内容、30種以上のドキュメント雛形
非機能要件のリスト化
改善2.開発工程管理の見直し
改善点 | 内容 | 効果 |
工程の標準化 | 全工程を標準化 | 工程が標準化され 抜け漏れが減少進捗が見える化し 問題発生予知や 対策の迅速化発注者側に遠慮して 依頼遅れの減少 |
レビュワーの設定 | タスクごとのレビュー担当者を設定 | |
クライアントのタスクを明確化 | 発注者側のタスクと納期も明確化 |
改善3.キックオフ会議の徹底
改善点 | 内容 | 効果 |
キックオフ会議の標準化 | キックオフ会議での確認項目を標準化 | 見積もり時に要件確認あとに
さらにキックオフでの再確認 |
内部キックオフ | 事前に社内での認識合わせ ベトナムと日本 |
|
キックオフ会議の徹底 | 新規開発、追加開発、運用保守 プロジェクト開始時に必ず実施 |
キックオフ会議 チェックリスト
キックオフ会議で確認する項目
No. |
項目 |
1 | プロジェクトの要件確認 |
2 | マスタースケジュールご提案、納期目標の確認 |
3 | 連絡手段の確認(メール、Chatwork、Slack etc) |
4 | 進捗管理方法、報告ルールの確認(週一報告など) |
5 | 会議体の確認(定例会議が必要か?) |
6 | 課題・リスクの情報共有 |
改善4.運用保守の設計書の定義
改善点 | 内容 | 効果 |
保守業務の定義 | 保守業務を標準化 | 保守業務が定型になり 安定 |
保守契約キックオフ会議 | 保守契約の際のキックオフ実施 | |
レポートの標準化 | 障害時の状況がわかるようにレポート定義 レポート頻度も定義 |
改善4運用保守の業務定義
保守運用業務 |
内容 |
運用保守設計書 | 保守業務を定義します。業務は要、不要に応じてカスタマイズ |
運用スケジュール | 1ヶ月毎や定期的に発生するタスクをスケジュール提示 |
システムタイムスケジュール | バックアップやメンテナンスのスケジュール |
サーバー構成 | サーバー構成図 |
監視・通知設計 | 監視項目、アラート通知設定(Zabbix、Cloud watchなどを利用) |
手動管理項目 | 自動監視以外の管理設計 |
バックアップ・リストア | バックアップやリストアの設計 |
障害時運用 | 障害時の対応方法 |
保守レポート | 毎月の保守レポート |
保守体制 | 保守体制の提示 |
緊急連絡体制 | 緊急連絡先の提示 |
失敗要因と改善のポイント
オフショア開発を成功させるポイント
価格だけでなくしっかりとした開発管理体制があるか
属人的でなく標準化できているか
ブリッジも重要だがコミュニケーションだけの問題ではなく
業務の標準化できているか
お客様に満足していただくために
第三部 オフショア開発の成功実例
- xR開発実例
- AWSでのWEBシステムの構築・運用の実例
- VB .NETへのマイグレーションの実例
xR開発 成功例1)製品・サービスをVRプレゼンテーション
xR開発 成功例2)研修・安全教育 VRトレーニング
xR開発 成功例3)医療系機器 操作トレーニングVR
xR開発 成功例4)AR操作マニュアルアプリ
xR開発 成功例5)3Dホログラムを活用したHoloLens(ホロレンズ)
販売元:株式会社アクアクリエイティブラボ様
オフショアxR開発の成功のポイント
xR開発は3D空間の仕様をどのように定義していくかがポイントとなります。アジャイル的に開発していくことが主流ではありますが、それでも最初に質の高い仕様定義書があるとないとではあと工程のコストが大きく変わってしまいます。開発者側だけでなく発注側も何度もやり直しが発生し辟易としてしまいます。
質の高い定義書を作るために、紙芝居のような絵コンテや画像や動画などのリフェレンスを用意することが重要です。そしてプロトタイプを作って確認したりするなど中間納品とフィードバックを細かく繰り返しながら製造していきます。
Web開発 AWS運用 成功例1)ハウスメーカーの顧客管理チャットアプリ
Web開発 AWS運用 成功例2)広告代理店デジタルギフト発行システム
Web開発 AWS運用 成功例3)アーティストのファンクラブWEBサイト
Web開発 AWS運用 成功例4)マニュアルサイトAWSマイグレーション
Web開発 AWS運用 成功例5)eラーニング試験作成ツール開発
オフショアWEB開発の成功のポイント
- 設計に適切な時間をかける
ビジネスの目的から、システム設計、将来の保守運用を視野に入れた拡張性やセキュリティ対策など機能部分だけでなく非機能部分にも時間をかけて設計することが重要です。また要件定義や仕様設計を両者が合意して進めることが重要。
- 保守運用について考慮して設計
ビジネスを成功させるためにスピードやコストダウンは重要です。しかし適切な設計をしないと保守運用する際に余計なコストが発生します。そこでコストダウンをしようとしても修正が発生し時間もかかってしまいます。
- ローコードやサーバレスや運用自動化を選択
ONETECHでもまだ多くの経験はないのですが、今後はローコード開発、サーバレス設計、運用自動化など開発や運用に時間をかけずにビジネス部分に集中できるようなシステム環境づくり重要だと考え、積極的に提案しています。
VB.NET マイグレーション 成功例1)水産加工業の生産管理システム移行
課題 | 解決 |
VB6.0の保守切れのためセキュリテイリスクがあった 移行のための大きな費用も足枷になっていた |
最新のVB.NET2017への直接アップデートができないため、VB.NET2003へ移行してから2段階で2017版へ更新 自動変換率80%でコスト削減 |
DATA | |
業界 | 水産加工業 |
対象システム | 生産管理、営業管理、会計管理 |
アプリケーション環境 | Windows XP → Windows 10 64bit |
データベース | Oracle 9i →Oracle 19c |
規模 | 51人月 |
STEP | 430KLOC |
費用 | 1900万円 |
VB.NET マイグレーション 成功例2)運輸業の基幹システム移行
課題 | 解決 |
VB6.0の保守切れのためセキュリテイリスクがあった 大規模なシステムのため移行計画が困難 |
最新のVB.NET2017への直接アップデートができないため、VB.NET2003へ移行してから2段階で2017版へ更新 自動変換率80%でコスト削減 |
DATA | |
業界 | 運輸業 |
対象システム | 営業管理、会計管理、車両管理、給与管理 |
アプリケーション環境 | Windows XP → Windows 7 32bit |
データベース | Oracle 10g →AWS RDS for Oracle19c |
規模 | 159人月 |
STEP | 1048KLOC |
費用 | 4600万円 |
VB.NET マイグレーション 成功例3)病院予約システムパッケージ移行
課題 | 解決 |
VB6.0の保守切れのためセキュリテイリスクがあった 移行のための大きな費用も足枷になっていた |
最新のVB.NET2017への直接アップデートができないため、VB.NET2003へ移行してから2段階で2017版へ更新 自動変換率80%でコスト削減 |
DATA | |
業界 | 医療 |
対象システム | クリニック予約システム |
アプリケーション環境 | Windows XP → Windows 10 64bit |
データベース | PostGre SQL Cloud |
規模 | 13人月 |
STEP | 120KLOC |
費用 | 520万円 |
マイグレーションの費用感
ONETECHマイグレーション生産性:10KLOC/MM
オフショアでマイグレーションするメリット
- 理解コストが少ない
オフショア開発ではよく業務やシステムの理解力が課題となります。
マイグレーションは現行システムの機能をそのまま引き継ぎますのでソースコードでシステムを理解することができます。
通常のシステム開発と比較するとコミュニケーションが少なく、理解コストが削減されます。
- コスト削減
日本での人月単価が100万円〜120万円だとするとベトナムオフショア開発の人月単価は30万円から40万円です。一人当たりのコストを6割から7割近くコストダウンすることが可能です。
- 開発リソース
ベトナムの平均年齢は28歳です。日本と比べ非常に若者が多く、また国家としてITエンジニアの育成に力を入れています。
まとめ
はじめてのオフショア開発の紹介はいかがでしたでしょうか。オフショア開発のメリットはなんといってもコスト削減です。全ての企業活動分野でDX(デジタルトランスフォーメーション)が叫ばれている中で、海外のリソースを活用をする企業もどんどん増えています。しかしながらオフショア開発企業を選ぶ際には、人月単価が安くても開発期間が長くなってしまったり発注者側の確認時間が想定以上にかかったりしてしまっては結局高くついてしまいます。人月単価などのコストの比較ではなく、標準化された開発プロセスを実行している企業かの見極めが重要です。オフショア開発をうまく利用してぜひ御社のDXを加速させてください!
ONETECH紹介
会社名 |
株式会社 One Technology Japan |
ONETECH ASIA JOINT STOCK COMPANY |
GROWUP JV JOINT STOCK COMPANY |
設立 |
2015年8月 |
2013年7月 |
2018年9月 |
代表 |
河本直己 |
グエン ラム タオ |
グエン ラム タオ |
事業 |
オフショア開発営業 |
オフショア開発拠点 |
ベトナム進出支援 |
所在 | 神奈川/川崎市 東京/渋谷区 |
社員数:170名 (パートナー含む) (2020年3月) 本社 : ホーチミン市 |
本社 :ホーチミン市 |
講師の紹介
株式会社One Technology Japan
代表取締役
河本 直己
かわもと なおき
・1996年〜
新卒で商社入社
・2002年〜
コンサルティング上場企業
- 事業開発部モバイルコマース事業立ち上げ
- ITと出会う
・2005年〜
モバイルITスタートアップ企業
- 取締役
- ベトナムエンジニアと出会う
・2015年〜
株式会社One Technology Japanを創業
- オフショア開発事業
- 人材事業
- 飲食事業
- 東京下北沢ベトナムサンドイッチ
「バインミーバーバー」
第四部 質疑応答
よくある質問
ホーチミンでは8月に入ってCovid-19デルタ株が猛威を奮っていて現在ロックダウンをしています。外出制限など厳しい規制が敷かれています。
質問 | 回答 |
弊社指定のツールは利用できますか。 | 利用できます。全体的な効率やセキュリティの観点で相談して決めます。 |
コーディングルールはどうなっていますか? | 各言語によってONETECHコーディング定義に基づいて管理しています。 |
クラウドサーバーの利用は可能ですか? | 実績としてAWS(Amazon)が多いですが、国内国外のメインどころの実績はあります。サーバーの設計、設定、運用も可能です。 |
指定したライブラリや、SDKで開発できますか。 | 開発可能です。 |
理解能力が心配ですが大丈夫ですか。 | 面談で担当ブリッジとコミュニケーションが可能です。属人的な能力依存ではなく、できるだけ要求を明確にしてコミュニケーションします。 |
担当者が退職などで変わってしまって引き継ぎが心配です。 | 弊社の組織はプロジェクトごとに必ず上長を設定して開発しています。設計からプログラミングまで基本一人での開発はありません。引き継ぎもルール化しております。 |
開発デバイスはありますか。 | スマホデバイスやAR,VRなどの流通しているデバイスは用意しています。最新モデルは日本から送って開発するケースも多いです。 |
ラボ開発の場合、事前に担当者の履歴書は確認できますか。 | はい、可能です。面談も可能です。 |
コーディングの生産性の基準はありますか。 | コーディング:5.5K Step数/人月
コーディング、単体テスト:3.2K Step数/人月 |
情報漏洩などの対策はしていますか? | 社員の開発端末にはアクセス制限しています。ご要望によって専用ネット環境で管理します。社員とは秘密保持契約を締結しています。 |
プログラムソースはもらえますか。 | 契約によってお渡し可能です。著作権等の権利もお渡し可能です。 |
ソースコードのコメントは何語ですか? | 平易な英語で記載しています。 |
テストケースは何語ですか? | テストケースに基づくテストはベトナム語で実施します。クライアントの要望に応じて日本語でも対応可能です。 |
瑕疵担保期間はありますか。 | はい、あります。基本は検収後6ヶ月間としています。 |
日本でのオンサイトの対応はできますか。 | はい、対応可能です。短期、長期により在留VISAの扱いが変わりますが実績もございます。 |
ベトナムへ常駐は可能ですか。 | はい、可能です。サポートもいたします。 |
ベトナムとの時差はありますか。 | ホーチミンもハノイも時差は2時間です。ベトナムが2時間遅れのイメージです。日本の午前10時が、ベトナムでは午前8時です、 |
ベトナムには初めていくのですがサポートできますか。 | はい、可能です。ホテルの手配のサポート、空港へのお迎え、観光の手配のサポートも可能です。 |
ベトナムのコロナの状況はどうですか。 | ホーチミンでは8月に入ってデルタ株が猛威を奮っていて現在ロックダウンをしています。外出制限など厳しい規制が敷かれています。 |
駐在員事務所や現地法人の設立はできますか。 | はい、可能です。すでに数社の実績があります。 |
ベトナム人エンジニアの採用はできますか。 | はい、可能です。2019年は20名が弊社のサポートで日本企業に就職しました。 |
ご静聴ありがとうございました。