【2020年最新】「はじめてのオフショア開発入門セミナー」導入から注意点まで内容を全て公開

はじめてのオフショア開発入門セミナー開催

システム開発海外アウトソーシングの仕方

「システム開発を海外にアウトソーシングしたい」

「オフショア開発を導入するにはどうしたら良いの」

「オフショア開発企業にはどのような特徴があるの」

海外へシステム開発やアプリ開発をアウトソーシングすることをオフショア開発と呼びます。オフショア開発することで「開発コストの削減」日本で不足する「エンジニアの確保」という利点があります。一方ではじめてオフショア開発をするには、海外のエンジニアとどのようにコミュニケーションするのか、どの国に発注すれば良いのか、など多くの疑問があると思います。

今回は、2020年5月に開催した、はじめてオフショア開発を導入する方へ向けての入門セミナーの内容を全て公開します。。

＜このような方におすすめ＞

• 海外へのシステム開発外注を検討している企業の方
• 既存のオフショア開発でうまくいっていない方
• オフショア開発拠点をベトナムに立ち上げたい方
• エンジニア不足にお困りの方
• システム開発会社様、事業会社様

＜目次＞

＜第一部＞

• オフショア開発の導入前の準備
• オフショア開発の開始にあたって
• オフショア開発の活用と注意点

＜第二部＞

• オフショア開発のためのドキュメント一覧
• システム開発向けのシステムテスト基準

＜第三部＞

• オフショア開発におけるキックオフミーティングの目的
• キックオフミーティングで確認すべき重要な項目
• キックオフミーティング　デモンストレーション

＜動画＞

• オフショア開発を成功させるためのノウハウを動画公開

＜第一部＞オフショア開発の導入前の準備

オフショア開発とは

国内の企業が海外のIT企業にアプリ開発やシステム開発、ソフトウェア開発、CGなどのデジタルコンテンツの制作、運用保守管理などを委託（アウトソーシング）する方法がオフショア開発です。一般的にインドやベトナムといった人件費の安い国でオフショア開発を実施します。
日本では少子化による人手不足が続き、ITスキルをもつエンジニアは少ないです。企業はオフショア開発することで人材を確保でき、安定して開発を続けられるメリットがあります。

独立行政法人情報処理推進機構（IPA）の調査では日本企業の４５％がオフショア開発を導入した経験があります。

オフショア開発のメリット・デメリット

オフショア開発には、コスト削減、優秀なエンジニアの確保というメリットがあります。デメリットとしてはコミュニケーションに負荷がかかります。特に上流工程での認識違いによりあと工程が全てうまくいかずにプロジェクトが失敗してしまうケースもあります。

メリット	・コスト削減 ・優秀なエンジニアの確保
デメリット	・コミュニケーションに負荷 ・認識違いによるコスト増（品質不足、納期遅延）

 

オフショア開発国の情報

ここではアジア中心に各国のオフショア開発事情を取り上げます。

オフショア 提供国	外国語	特徴
中国	日本語：◎ 英 語：◯	対日本のオフショアの開発実績が多数あり、優秀な人材が多いのが特徴。漢字圏で日本語能力も高い。多くの日本企業が進出済みで優秀な人材の確保は難しくなりつつあり単価も上昇傾向です。コスト削減以外のメリットを求めて中長期に開拓するのが良い。
インド	日本語：△ 英 語：◎	欧米相手に実績が豊富で世界で最も注目されているIT人材が豊富な国。優秀な技術者が多く大規模案件が増えているが単価も上昇中。英語が堪能なので発注者側が英語必須。狙い目は成長段階の企業との業務提携や子会社化を進めることだが時間がかかる。
ベトナム	日本語：◎ 英 語：◯	政府が対日本向けのオフショア開発に力を入れています。優秀な国家大学でもIT教育に力を入れており豊富な人材が供給されています。IT人材以外への日本就労のための日本語学習も盛んで日本語能力は年々上がっています。
フィリピン	日本語：△ 英 語：◎	大学進学率が高く新興国の中でも優秀なITエンジニアが多い。欧米中心に仕事をしていることが多く英語のサイトやアプリ開発に慣れている。発注者が英語で業務ができると選択肢になる。マーケットしてソフトウェアを展開できる可能性も○。
バングラ ディッシュ	日本語：△ 英 語：◎	インドの北部に位置しているのでインドに似ている。技能能力は高く英語が堪能。欧米の案件の実績も豊富。中国やベトナムと比べても物価や賃金が急激に上がらないと言われている。
ミャンマー	日本語：◎ 英 語：◯	勤勉なので日本語習得スピードが速い。協調性があり、おとなしい性格なのでチームワークに向いている。アジア最後のフロンティアと呼ばれていて人材獲得競争は起こっていないが、ITインフラの整備は遅れている。停電が多い。女性ITエンジニアが多い。

参考）オフショア開発.com

オフショア開発国の人月単価

次にさらに上記６カ国の単価の比較と単価の上昇傾向を記載しました。上から順位人月単価の高い順で並べています。

オフショア提供国	人月単価 （万円）	単価傾向	GDP	メモ
中国	３５〜４０	↑	6.1%	沿岸部（上海、北京、大連など）単価が上昇、内陸部へシフト
インド	３５〜４０	↑	4.3%	欧米相手にオフショアが急成長中。優秀な技術者が多く大規模案件が増えているが単価も上昇中。
ベトナム	３０〜３５	↗︎	7.0%	ハノイ、ホーチミン中心、最近ではダナンなどが注目されている
フィリピン	３０〜３５	↗︎	5.9%	人口が１億人弱でリソースが豊富。英語で業務ができると選択肢になる。
バングラディッシュ	２５〜３０	→	7.9%	単価の幅が広く、高度な案件とコスト削減のための案件まで幅広く対応可能。物価や賃金も安定している。
ミャンマー	２５〜３０	→	6.5%	６カ国で最も単価が安い。日本語習得者も多く、中国、インドと比較するとコストが半分近くなるケースもある。

参考）オフショア開発.com

オフショア開発の契約形態

この項目ではオフショア開発でよくある契約形態をご紹介します。プロジェクト開発の目的に応じて開発プロセスや契約形態も最適に選択する必要があります。

契約種別	内容	良い点	向いている プロジェクト
請負契約	原則、仕様書をいただき、それをもとにウォーターフォール方式で進めます。受託開発。品質や納期を担保します。	・納期と品質の担保 ・ 工期の短縮 ・トラブルが少ない ・ 固定費化しない	・仕様が決まっている ・ 突発した短期案件
ラボ型契約	準委任契約として一定期間クライアントの要望に応じたブリッジ、エンジニア、テスターの体制を担保します。ラボ型開発。	・ 仕様変更に柔軟に対応 ・ 優秀なエンジニアの確保 ・ ノウハウの蓄積 ・ 社内手続きの簡素化	・アジャイル開発 ・ R&D開発 ・ MVP手法の開発 ・保守運用 ・似た案件を連続開発

 

オフショア開発企業の探し方

オフショア開発企業の探し方ですが、ひとつはGoogle、Yahooなどのネット検索で「国名　システム開発」「オフショア開発　企業」「アプリ開発　海外アウトソーシング」などのキーワーで検索します。ふたつめも上記のようなキーワードで検索するとオフショア開発企業を紹介するメディアが出てきます。最後に展示会やセミナーに参加することです。

チャネル	メリット	デメリット	主なメディア・ 展示会
ネット検索	HPに情報豊富な会社 ＝体制が整っている可能性が高い	正攻法なので特になし
オフショア 開発 紹介メディア	一括で請求できる 国内国外の比較ができる	担当者にシステム開発の知識がない場合が多く、紹介精度は高くない。	オフショア開発.com オファーミー 発注ナビ など
セミナー 展示会参加	実際に担当者に会って話を聞ける	ローカル主体の会社が参加するケースが多く、社長は日本語堪能だが現地のブリッジとの格差があるので注意	ソフトウェア展示会 海外ビジネスEXPO JAPAN IT EXPO など

 

オフショア開発企業の選定のチェックポイント

いざオフショア開発を開始する際にどの企業を選べば良いかについてチェックポイントをいくつか例示しました。ビジネス観点、開発・技術観点にわけて複数の企業から選んでいきましょう。

項目	チェックポイント例
ビジネス 観点	日本法人、日本窓口はあるか。現地に日本人はいるか。
	契約書は日本語か英語か。
	支払いは国内銀行か、支払い通貨は？送金手数料や為替リスクを確認。
	問題が発生した場合の窓口にすぐに電話などで連絡可能か。
	セキュリティ対策は万全か。
開発・技術 観点	発注したいシステムの実績は豊富か。
	発注したいシステムの技術者は何人いるか。
	開発体制の提示、システム開発工程を理解しているか。
	技術トラブルや仕様の理解の際に日本語対応可能か。
	瑕疵担保をしてくれるか。
	旧正月などの長期休暇や休暇中の体制は？

 

オフショア開発の導入の流れまとめ

ここまで記載してきましたオフショア開発導入の流れをまとめました。

流れ	ポイント
オフショア開発国と企業を選ぶ	マクロの視点：国選び（複数の国を選ぶことも） 候補の国があったらその国へ訪問するのがベター ミクロの視点：企業選びのチェックポイント参照
オフショア開発企業と打ち合わせ	複数の企業と打ち合わせ オンライン、対面
NDA（秘密保持契約締結）	日本語で締結 紛争の際、日本法や日本の裁判所での実施 再委託に注意
見積もりを取得する	相見積もりをして安すぎないか、高すぎないか 適切な工程と工数が見積もられているか 見積書で概算でも要件や仕様理解のレベル感がわかる
企業と打ち合わせ	実際にプロジェクト参加をする人材との面談 ラボ型開発ではアサインされるエンジニアの職務経歴書をチェック
取引条件確認（契約書、覚書など締結）	日本での取引と同様な契約項目を網羅。日本語で契約できるか。
オフショア開発開始

 

オフショア開発の開始にあたって

オフショア開発の体制

オフショア開発の開発手法は、受託開発とラボ型開発が一般的です。
オフショア開発企業から提供される体制は大きく変わりません。
コミュニケーションは発注者とブリッジ（ブリッジSEやコミュニケーター）の間で行われます。

受託開発は原則として発注者からの仕様書に沿って業務指示や開発が行われます。コミュニケーションは確認がメインです。

一方、ラボ型開発の場合は発注者がブリッジを介してPM（プロダクトマネージャ）と相談や確認や提案など密にコミュニケーションをとってプロジェクト開発を進めます。

 

オフショア開発の工程

オフショア開発の工程は受託開発とラボ型開発に分かれます。
受託開発の工程はウォーターフォール形式で進行します。

ラボ型開発の工程はアジャイル方式と呼ばれる工程です。発注者と開発者が一体となって相談しながら開発を進めていきます。

オフショア開発の業務範囲

現在、オフショア開発では得意、不得意はありますが全ての業務を受ける体制や技術が備わってきました。企業や国によって特徴がありますがやはり対応実績を見ながら企業に業務を発注します。

	工程	対応	一般的な特徴
受託開発	企画	△	難しい業務・ユーザーフローは理解コストが発生
	要件定義	△	日本人がいる会社なら安心
	デザイン	△	お任せすると各国の特徴が出てしまう
	仕様設計	◯	内部設計は◯、外部設計は△
	開発	◎	得意
	テスト	◯	単体テスト・結合テストは◎ 性能テスト、セキュリティテストは実績のあるところに依頼
ラボ開発	アジャイル開発	◯	コミュニケーション能力のある人材の選定が鍵
保守・運用	保守・運用	◎	定型業務は効果が高い

オフショア開発の活用と注意点

ここから実際にオフショア開発を導入し、成功させるためにはどのようなことを注意すれば良いかまとめました。

オフショア開発で課題が発生するポイント

オフショア開発で課題が発覚してしまうのは、システム開発の下流工程です。ここで課題が発生すると品質の低下や納期遅延に直結してしまいます。
しかし、なぜ課題が発生してしまったかという原因に着目すると全ての場合上流工程での様々な確認漏れが原因となっていることがわかりました。

 

 

オフショア開発からベトナム進出へ

まずはオフショア開発で足りないリソースを補い、開発費の削減を目指します。さらに海外の優秀なエンジニアを確保するために現地に駐在員事務所を設立するのも良いでしょう。この時点で社内は徐々にグローバル化してきています。日本から現地に駐在員を派遣することで開発の効率も上がっていくでしょうか。

日本本社にも何名かの外国人が短期、長期の出張や駐在を始めます。現地の情報がわかると海外に自社の商品を販売できる可能性も高くなります。

ベトナムの優位性

近年オフショア開発では、ベトナムが最も注目されています。オフショア開発企業も非常に多くなっています。なぜベトナムが人気なのかをまとめました。

国民性	政府レベル、民間レベルでも日本と友好な関係を保っています。勤勉でまじめでおとなしい性格が多いです。オフはスポーツや旅行をしたり飲みに行ったり明るく活気のある性格です。
日本語能力	日本語学習者が６万人（世界８位：2015年）とありますが、すでに留学生は８万人（2019年）日本に滞在しているベトナム人は４１万人います。2016年、全土の小学校で日本語を「第1外国語」として教えることを目指す方針を発表しています。
技術能力	政府がIT産業と教育に優遇策を施行して力を入れています。基盤となる数学、科学の分野では国際的にも上位ランクに位置しています。
人材の豊富さ・若さ	ベトナムの国全体の平均年齢は２８才です。政府は2020年中に１００万人のITエンジニアを輩出しようと政策を打ち出しています。継続的に人材の供給が可能です。
地理的、物理的要因	ベトナムとの時差は、２時間です。始業時間は日本より早いので時差の影響が少ないのが特徴です。祝日が日本と比べて半分ほどしかなく稼働日数が長いのも特徴です。

 

オフショア開発で注意するポイント

オフショア開発で成果を出すためには長い目で見ることも大切です。日本はこれからエンジニア不足が深刻になると言われています。優秀な外国人エンジニアをどのように確保していくかという視点が重要です。また課題の発生ポイントである上流工程での確認作業が非常に重要です。

注意するポイント
過度な期待はNG	過度な期待をしない。中長期な視点を持つ。いきなり日本の外注費と比べ５０％のコストダウンは難しい。1年目は９０％、2年目は８０％などと徐々にコストダウンを実現していく。小さなプロジェクトは特に日本での外注費と比べてもコストダウンが難しい。長く大きなプロジェクトになるとコストダウンが可能になる。
発注者側もコミュニケーションの工夫を	発注者側の歩みよりも必要。コミュニケーションの工夫。優しい平易な日本語を使う。図や動画などで伝える工夫をする。細かく確認をする。
担当者と企業の 能力の見極め	ブリッジやコミュニケーターのコミュニケーション能力。 オフショア企業の管理能力の見極めが重要。 値段だけで判断しないこと
上流工程の確認をしっかりと	初期は確認の会議にも時間がかかりストレスがあるが、忍耐強くもれなく確認する。

 

オフショア開発を成功させるポイント

オフショア開発で成果を出すためのポイントは上流工程の確認をしっかりすることです。具体的には成功させるためには何がポイントかというと以下の２点です。

・できるだけドキュメントで明文化

・キックオフ会議で要件やルールの共通認識化

セミナー（当ブログ）の後半では上記を具体的にどのように運用していくかをお伝えします。

＜第一部＞まとめ

オフショア開発は日本のIT人材不足を解決するための一つの有力な手段です。オフショア開発企業も年々開発レベルやコミュニケーションレベルが上がり導入の敷居も低くなってきました。一方で「はじめてオフショア開発」を検討している企業様にはいくつかの不安があると思います。

• 「日本語でコミュニケーションできるのか」
• 「ただでさえ忙しいのに外国人と仕事をすることで負荷が上がるのでは」
• 「オフショア開発はよく失敗すると聞くよ」

私たちもオフショア開発を15年ほど経験してきた中で多くの失敗がありました。そのなかで失敗の多くが上流工程にあり、原因はコミュニケーションであるということに気がつきました。

そこでできる限り認識の相違がないようにドキュメントやプロセス、コミュニケーションを徹底的に整理しました。ドキュメントはサンプルを用意して発注者様の負担を極力減らしながら明確に要件を理解します。さらに開発工程の上流で必ず「プロジェクトキックオフ会議」を実施します。プロジェクトキックオフ会議前にチェックリストを用いて確認事項を整理しますが、プロジェクトキックオフ会議で二重で確認をします。上記のようなこともセミナーでは講演しています。

発注者側と受注者側の相互の工夫によってオフショア開発の効果を上げていければと考えています。

 

＜第二部＞オフショア開発のドキュメントを公開

＜第二部＞目次

• オフショア開発のためのドキュメント一覧
• システム開発向けのシステムテスト基準

オフショア開発のためのドキュメントとシステムテスト基準

オフショア開発の際に、要件と開発の認識のギャップを防ぐために確認をしっかりすることは非常に重要です。認識のギャップを防ぐためのオフショア開発で利用しているドキュメントとシステムテスト基準の説明いたします。残念ながらオフショア開発を利用して失敗してしまうケースがあります。主な原因はシステム開発のためのドキュメント基準がありません。システム開発の上流工程で、どのような資料が必要か、発注者、開発者のどちらの役割分担かも不明確なまま進んでしまって、システム開発の下流工程の納品前や納品後でのトラブルが発生してしまいます。オフショアを活用する時には選定するシステム開発会社はドキュメント基準があるかどうかポイントとなります。

システム開発上流工程で下流工程のトラブルを防ぐ

システム開発の上流工程を改善することでシステム開発全体が効率化され品質の改善や納期順守が期待できます。ここがオフショア開発を成功させる重要なポイントだと思います。システム開発での要求工程や要件工程を明確にするにはドキュメント化して伝えると間違いが少ないです。しかし、システム開発向けドキュメント化するためにはシステム開発経験や知識も必要になります。そこでONETECHでは発注企業を分類して、費用対効果を意識した必要かつ最低限のオフショア開発向けドキュメントの作成依頼や作成のサポートをしております。

発注企業により必要かつ最低限のドキュメントを定義

オフショア開発を利用する会社を３種類に分類しています。システムインテグレータ企業、中小システム開発企業と事業をしている企業です。企業の種類によりシステム開発の知識に違いがあります。役割分担や、期待されることも違いますので、システム開発工数をバランスしながら必要なドキュメントを作成しています。（オフショア開発向けドキュメント表へ参照）。

システム開発基準に沿ったドキュメントの提示

できる限り日本のシステム開発基準に沿って必要な設計書を基づいて作成します。システム開発での設計工程は設計書が主に下記の４カテゴリに分かれています。

・業務設計書：システムを適用した後に、現在の業務からの改善の効果を記載します。

・システム方式設計書：システムの面からどのようにサーバー、ソフトウェアを利用するかを記載します。

・アプリケーション機能設計書：システム開発のなかのアプリケーションの画面UIはどのようして欲しいかを記載。業務での入力情報と出力情報を記載します。

・非機能要件設計書：アプリケーションへ不正なアクセスなど防止、長期利用の時のアプリケーションは安定稼働するかを設計します。

システムインテグレータ企業（SI企業）

システムインテグレータ企業はITを使って構築する情報サービスのことを目指しますので、顧客から大規模なシステム開発の依頼を受けて、設計、開発、運用・保守までを請け負うケースが多いです。発注者側企業がシステム開発の知識及び経験に基づいて上記の４カテゴリードキュメント（業務設計書、システム方方式設計書、アプリケーション機能設計書、非機能要件設計書）をすべて作成しているケースが基本です。

中小システム開発企業

中小システム開発企業からは中小規模なシステムの依頼を受けて、設計、開発、運用・保守までを請け負うケースが多いです。発注者側企業がシステム開発予算をバランスしながら、システム開発のアプリケーション機能設計書を中心に作成するケースが多いです。

事業会社

事業会社は主に自社ビジネスのためのシステム開発をオフショア開発に依頼します。システム開発の経験や知識がすくないケースやドキュメント作成に慣れていないケースが多くみられます。システム開発の要求は企画書を見ながらヒヤリングをしていきます。仕様書はサンプルをお渡しして、サポートしながら作成してもらいます。要件と開発の認識のギャップを防ぐためにできるだけドキュメント化してもらっております。

オフショア開発のためドキュメントの一覧

下記の表はオフショア開発のシステム開発基準に基づいた詳細ドキュメントの一覧です。SI企業、中小システム開発企業、事業会社それぞれは一覧に沿って該当しているドキュメントを確認し準備をしていただいています。

	レベル①	レベル②	レベル③	サンプル
	SI企業	中小開発企業	事業会社
1.業務設計書	〇	なし	なし
1-1.システム化の背景・目的	〇
1-2.システム化の対象範囲	〇
1-3.システム化業務一覧	〇
1-4.新業務フロー	〇
1-5.システム化業務説明	〇
2.システム方式設計書	〇	なし	なし
2-1.ハードウェア構成図	〇
2-2.ソフトウェア構成図	〇
2-3.ネットワーク構成図	〇
2-4.アプリケーション機能構成図	〇
3.アプリケーション機能設計書	〇	〇	△要件次第
3-1.画面設計	〇	〇	〇	〇
3-1-1.画面一覧	〇	〇	〇	〇
3-1-2.画面遷移図	〇	〇	〇	〇
3-1-3.画面レイアウト	〇	〇	〇	〇
3-1-4.画面入出力項目一覧	〇	〇	〇	〇
3-1-5.画面アクション定義	〇	〇	〇	〇
3-2.帳票設計	〇	〇
3-2-1.帳票一覧	〇	〇		〇
3-2-2.帳票概要	〇	〇
3-2-3.帳票レイアウト	〇	〇
3-2-4.帳票出力項目一覧	〇	〇
3-2-5.帳票編集定義	〇	〇
3-3.バッチ設計	〇	〇	△要件次第	〇
3-3-1.バッチ処理フロー（API)	〇	〇	△要件次第	〇
3-3-2.バッチ処理一覧	〇	〇	△要件次第	〇
3-3-3.バッチ処理定義	〇	〇	△要件次第	〇
3-4.テーブル・ファイル設計	〇	〇	△要件次第	〇
3-4-1.テーブル関連図（ER)	〇	〇	△要件次第	〇
3-4-2.テーブル・ファイル一覧	〇	〇	△要件次第	〇
3-4-3.テーブル定義	〇	〇	△要件次第	〇
3-4-4.ファイル定義	〇	〇	△要件次第	〇
3-4-5.CRUD図	〇	〇	△要件次第	〇
3-5.外部インターフェース設計	〇	〇	△要件次第	〇
3-5-1.外部システム関連図	〇	〇	△要件次第
3-5-2.外部インターフェース一覧	〇	〇	△要件次第
3-5-3.外部インターフェース項目定義	〇	〇	△要件次第
3-5-4.外部インターフェース処理概要	〇	〇	△要件次第
4.非機能要件設計書	〇	△コストバランス
4-1.性能設計	〇	△コストバランス
4-2.信頼性設計	〇	△コストバランス
4-3.拡張性設計	〇	△コストバランス
4-4.情報セキュリティ設計	〇	△コストバランス
4-5.テスト方針	〇	△コストバランス
4-6.移行方針	〇	△コストバランス
4-7.運用保守設計	〇	△コストバランス

システム開発のためのドキュメントのサンプル

今回はサンプルとして下記のドキュメントを紹介したいと思います。

• システム開発の知識がある企業（システムインテグレータ企業、中小システム開発企業）
  • 画面遷移図
  • 画面レイアウト定義書
• システム開発の経験の少ない事業会社
  • 仕様書

サンプル画面遷移図

下記のシートはドキュメントの変更履歴シートです。システム開発のドキュメントが新規作成なのか、ドキュメントの変更なのかをしっかり管理することで、認識のギャップが少なくなります。発注者側はシステム開発の発注者とシステム開発の担当者が異なるケースもあります。変更点により対応工数（コスト）が上がってしまうケースが多いのでシステム開発の発注者が承認する必要があります。

【変更履歴】
版	変更日	変更内容	変更理由	承認	審査	作成
Ver 1.0	2020/03/25	新規作成	－	AAA	BBB	CCC

下記のシートはドキュメントの画面遷移図です。

システム開発の設計工程で画面遷移図は全体システムの動きを明文化します。業務の要求で入出力及びデータ流れも明確にします。この段階で業務プロセスにどのようなプロセスがあるかを確認します。データ処理の流れがシステム要求を満たせるかを記載します。

サンプル画面レイアウト定義書

システム開発での開発工程のなかで、画面レイアウトを定義する必要があります。業務での操作および入出力データに関して必要な項目はどれか、また各項目に応じてどこに配置するか下記の構成を明記します。

• 画面の操作・表示
• 操作手順
• 画面出力処理
• 各項目定義（データタイプ、桁数など）
• イベント
  • イベントが発生する時にどのようにシステム処理するかを記入します。
• メッセージ
  • この画面で入力チェック、システムエラーが発生する時にどのメッセージを表示させるかも事前に定義します。

全体ユーザーインターフェースはどのようにイメージするかを記載します。

ここで画面に対して各項目の配置を記載します。

下記のイメージはこの画面にて操作と操作順番の情報、単項目のデータタイプ及び入力で処理チェックを記入します。

サンプル仕様書

事業会社はシステム開発の経験が少ないので、どのようなドキュメントが必要かを聞かれるケースが多いです。その場合は下記のサンプルをお渡ししながら画面のイメージと画面でどのようにデータが入出力されるかを定義してもらいます。システム開発を実施する際には下記のようなドキュメントから、上記のような画面遷移図や画面レイアウト定義書の作成を実施したり、サポートしたりします。

システム開発向けのシステムテスト基準

オフショア開発のためのシステム開発でのシステムテスト基準には機能要件と非機能要件があります。システムインテグレータ企業は顧客のシステム基準が高いため、基本的にシステム機能要件と非機能要件を両方実施します。システムテストの工数もかなりかかることで、プロジェクトの規模も大きくなります。中小システム開発企業は予算が限られていますので、コストとのバランスを取りながらシステムテストの基準を決定して実施することがあります。事業会社はシステムテストの経験が少ないので、システム開発を依頼する時に開発側から提案や確認で、どこまでシステムテストを実施するかを決定します。見積する段階でお互いの認識をすり合わせることでトラブルの回避ができます。

システムテスト基準

オフショア開発を利用する時にシステムテストの認識でもギャップが発生するケースが多いです。例えばコスト重視でアプリケーション機能を中心に開発します。いわゆる非機能要件と言われるコーディングレベルでのセキュリティーや、ユーザーの大量アクセスによるサーバーの性能基準などの事前定義ができないケースが多いです。その問題の対策ために、弊社は下記の表に沿って見積段階で基準及び任意項目を相談しながら決定します。

システム開発向けテスト基準
テスト	テスト種類	項目		基準	任意
機能要件テスト	単体テスト			〇	〇
	結合テスト			〇	〇
	総合テスト			?	?
非機能要件テスト	評価テスト	セキュリティテスト	レベル1	〇
			レベル2		〇
			レベル3		〇
		ユーザビリティテスト		〇	〇
		障害許容性テスト		?	〇
	負荷テスト	性能テスト		〇
		ロングランテスト		?	〇
		ストレステスト		?	〇
		ロードテスト		?	〇
		キャパシティテスト		〇	〇

非機能要件テスト

非機能要件テストの中で評価テストやセキュリティテスト、負荷テストは初期の段階では最低限の基準で提供します。それをベースに発注者側にリスクとビジネスの要求をヒヤリングして必要に応じた非機能要件のためのコストの見積もりを実施します。発注者側にはビジネスの要求とリスクとコストの三点を評価していただき確認の上で非機能要件を確定します。

＜第二部＞まとめ

オフショア開発を利用する際には、システム開発の上流工程を改善することでシステム開発全体が効率化され品質の改善や納期順守が期待できます。ここがオフショア開発を成功させる重要なポイントだと思います。

システム開発向けドキュメントとシステムテストプロセスの認識のギャップがないようにするためのONETECHで利用している実際のドキュメントのサンプルを提示しました。サンプルを提示することでシステム開発の経験の少ない事業会社様でも安心してシステム開発の発注を行うことができます。またサンプルの提示によりSI企業などのシステム開発企業との認識合わせもスムーズに行うことが可能です。

オフショア開発会社を選定する際にはシステム開発基準があるかを事前に明確することでプロジェクトが円滑に進めます。

＜第三部＞キックオフミーティングのデモンストレーション

キックオフミーティングの目的

オフショア開発はコミュニケーションが難しいなどのデメリットを上げることができます。コミュニケーションがうまくいかないと、要件や仕様の確認が不足して、納期遅延や品質低下の原因になってしまいます。システム開発でのトラブルは主に開発工程の下流で発覚することが多いのですが、トラブルの発生の原因はシステム開発の上流の要求分析、要件定義、仕様定義の段階でのコミュニケーションとなっていることがほとんどです。キックオフミーティングは、トラブル発生の問題を解決するための
有効な対策のひとつです

キックオフミーティングでは、要件や仕様スケジュールの確認、開発メンバーの紹介や役割、作業分担を明確にし、プロジェクトの目的や目標とプロジェクト運営のルールなどの認識を統一します。

キックオフミーティングの実施タイミング

キックオフミーティングは正式な見積書で金額や前提条件が合意され、契約書や注文書をいただいたタイミングで実施となります。まさにこれから開発するためのキックオフとなります。

キックオフミーティングで確認すべき重要な項目

キックオフミーティングでは、確認すべき重要な項目は、以下の6項目です。
1つ目、プロジェクトの要件を確認の上、全体で目的やゴールの意識を統一
2つ目、見積もりした工数を元に基本計画をご提案、すり合わせ
3つ目、連絡手段の確認、日々のコミュケーション方法を確認します。
4つ目、進捗管理などコミュケーションルールを確認
5つ目、会議体の確認です。定例会議の有無など、密なコミュケーション方法をご提案します。
6つ目、事前に想定可能な課題やリスクなどを共有の上、お互いにリスク回避、また、事後のリスクを最小化する対策を検討するのが目的としています。

No.	項目
1	プロジェクトの要件確認
2	マスタースケジュールご提案、納期目標の確認
3	連絡手段の確認（メール、chatwork、slack etc)
4	進捗管理方法、報告ルールの確認（週一報告など）
5	会議体の確認（定例会議が必要か？）
6	課題・リスクの情報共有

キックオフミーティング　デモンストレーション

キックオフミーティングの概要

今回、デモンストレーションとして営業支援アプリを開発する前提でのキックオフミーティング資料となります。
仕様設計、アプリ開発と管理画面側の開発を対応する前提です。
あくまで参考の開発内容です。

〇デモンストレーション概要
プロジェクト名：チャット搭載営業支援アプリ開発
概要：お客様とのチャットで商談できる顧客管理アプリ開発、お客様やチャット情報管理できる管理画面開発
お客様やチャット情報管理できる管理画面開発

オフショア開発の開発体制

キックオフミーティングデモの前に、ONETECHの開発体制を説明します。
以下の図を参照ください。
左側のグループがONETECHベトナムとなります。右側がクライアント様で、
クライアント様ごとに、開発チームを作り、BrSE（通訳者）がプロジェクトマネージャーとクライアント様との間に入り、コミュケーションしながらプロジェクトを進めます。
ONETECHベトナム側の総括責任者やテクニカルリーダ-がサポートを行い、リスク管理をしています。
ONETECHジャパンの営業側でもコミュケーションサポートや上流工程の設計範囲のサポートも行います。
BrSEのダットは、日本語能力試験のN1を取得し100％日本語でのコミュケーションが可能でございます。

ONETECH開発体制

デモンストレーション

それではキックオフミーティングを始めさせていただきます。

〇アジェンダ

• 1.プロジェクト概要
• 2.マスタースケジュール
• 3.成果物定義
• 4.コミュニケーションルール
• 5.課題・リスク・Q&A

〇1.プロジェクト概要

プロジェクト概要についてです。
以下のようにチャット搭載営業支援アプリのシステム開発を対応します。
チームは、6人体制で開発期間は約4ヶ月間を想定
技術要素は、アプリはReactNativeで、管理画面はNodeJS、PHP LaravelとMySQLで対応します。
今回は、コスト削減できるReactNativeでご提案
開発工程は仕様設計、UIモックアップ（APP）、コーディング、テストの４ステップ
動作条件については、記載の通りとなります。

• ■プロジェクト名：チャット搭載営業支援アプリ開発
• ■チームサイズ：6人
  （PM:1人、PG:3人、Tester:1人、BrSE:1人)
• ■開発期間：2018年5月14日～2018年8月31日
• ■技術要素：
  • ・FrontEnd：React Native
  • ・バックエンド：NodeJS（API、コア）
    • PHP Laravel 5.4（CMS）
    • MySQL（データベース）
• ■開発工程：仕様設計、UIモックアップ（APP）
  • コーディング、テスト
• ■動作条件　- iOS 13
  • – Android 8/9
  • – Google Chrome 最新版,Apple Safari 最新版
• ■範囲／範囲以外：見積もり内容に準ずる

(※今回はデモのためセミナー用の架空の設定の要件で進めています)

サンプル見積書

(※今回はデモのためセミナー用の架空の設定の要件で進めています)

〇2.マスタースケジュール

次は、マスタースケジュールについてです。
事前に約1週間の準備期間から開発を着手します
設計書は、約3週間、開発については、最初にモックアップをご提出の上、約2ヶ月間
テストについては仕様書作成とテストの実施で2ヶ月間を想定
クライアント様のテストは、8月1日週から受入テストと不具合の修正期間とします。
8月末が最終納品です。
その後、受入サポート期間となり、期間中の不具合については、瑕疵期間として対応します。

(※今回はデモのためセミナー用の架空の設定の要件で進めています)

〇3.成果物の定義

次は成果物定義についてです。
マスタスケジュールでも説明していますが、
納品は5回で、検収完了後の成果物の最終納品は8月31日を予定です。
全て電子ファイルにて納品いたします。

項番	成果物	リリース予定日	備考
1	仕様設計書	2018年6月12日	電子ファイル
2	UIモックアップ（APP）	2018年6月12日	電子ファイル
3	中間納品、ソースコード一式（開発完了時点）	2018年7月3日	電子ファイル
4	中間納品、テストレポート、ソースコード一式（結合テスト完了時点）	2018年8月1日	電子ファイル
5	最終納品、テストレポート、ソースコード一式	2018年8月31日	電子ファイル

(※今回はデモのためセミナー用の架空の設定の要件で進めています)

〇4.コミュケーションルール

次はコミュニケーションルールについてです。
コミュケーションについては進捗報告・課題報告・QAなど100％日本語で対応します。
中段の図は、左側が弊社ONETECH、右側はクライアント様です。
①～④は、内部の管理ルールで、朝会/週報など責任者含めて情報共有を徹底しています。
クライアント様には、⑤と⑥のコミュケーションをお願いしています。
5について、Q&A、課題管理。こちらは、発生時に随時、メールにて報告いたします。
管理方法は、Googleスプレッドシートで想定しています。
6については、進捗報告や定例会議のルールです。
進捗報告は、週一回メールで報告、定例会議は週一で実施想定です。

No.	種類	内容	内部/全体	コミュニケーションツール	頻度
1	朝会	チーム内の進捗・課題確認	内部	内部	毎日
2	日報	チーム内の日次作業報告	内部	内部	毎日
3	勉強会	チーム内の仕様理解・横展開活動	内部	内部	随時
4	週報	週次の進捗報告・振り返り	内部	内部	毎週
5	QA,課題報告	Ｑ＆Ａ，課題連絡	全体	メール・Googleスプレッドシート	随時
6	進捗報告・定例会	進捗報告・課題確認・改善事項・確認事項	全体	進捗報告：メール、会議：Skype	毎週

〇4.コミュケーション詳細

プロジェクト会議のお願い
次に、クライアント様にお願いしている会議を説明します。
会議の参加者は、ONETECHの営業、開発責任者、開発チーム、QAチーム、クライアント様で定義します。
キックオフミーティングは全員参加します。
定例会議については毎週実施し、進捗報告、課題・リスク報告、QAなどの流れでお互いに認識に差異が発生しないように議事録を作成します。
緊急会議については、適宜で対応します。
仕様変更や技術課題が発生時に、実施いたします。
最後に、プロジェクト終了時に振り返り会議をお願いしています。
プロジェクトを通しての課題、全体評価、改善すべきところを両社にて意見を交換します。
今後の品質改善の活用いたしますので、ご協力お願いいたします。

営業：OTJ、開発責任者：Manager、開発チーム：team,QAチーム：QA、発注者:client

No.	会議	時間	参加者	目的
1	キックオフミーティング	プロジェクト開始	全員	プロジェクトキックオフ
2	定例会議	1回/週 　月曜日　11:00～	OTJ、Team、Client	会議の目的は以下の通り。 ・プロジェクトの進捗報告 ・問題・課題の報告 ・Q&A確認（適宜） ・仕様説明（適宜）
3	緊急会議	適宜対応とする、(1) 問題・課題が発生した場合 (2) 仕様変更要求があった場合	OTJ、Team、Client	(1) 問題・課題の対策を検討 (2) スケジュール・工数への影響を分析する。
4	プロジェクト振り返り	プロジェクト終了	OTJ、Manager、Team、QA、、client	・プロジェクト評価 ・教育定義 ・ご指摘・対策案検討 ・今後の防止対策を検討

〇5.課題・リスク

次に課題・リスクについてです。
現時点で考えられるリスクを共有します。
開発期間が短く(2ヵ月未満) リカバリー期間がない為、課題が発生した場合、納品に遅れが出てしまう可能性があります。
事前に認識をしっかり合わすようにしますが、もしも課題が発生してしまったタイミングで迅速に報告します。
迅速にすり合わせすることによって、リスク管理を徹底できる想定です。
また、緊急会議にて対策を相談いたします。

No.	課題・リスク区分	課題・リスク内容	解決方針・解決策
*	リスク（サンプル）	リリース時のプログラムは、ご希望と差異が発生する可能性があります（業務上の差異）	■【軽減策】 仕様書を作成します： 基本設計書(画面定義、イベント処理定義、メッセージ….）、画面モックアップを提出の上、認識のすり合わせをいたします。ご承認をいただいた上で、開発工程に着手します。
*	リスク（サンプル）	プログラムテスト段階（7月）で設計画面の変更が発生する可能性がありますので、リリース計画に影響する可能性があります	■【軽減策】 ・５月のデザイン決定時に、開発計画をご提案、コーデイング及びテストを実施します。開発期間でレイアウト変更が発生した場合、変更数によってリリース日を再度ご相談させていただきます（現在の想定：仕様変更の対応は６月、最終納品は８月末）
1	リスク	開発期間が短く(2ヵ月未満) リカバリー期間がない為、技術課題が発生した場合、リリース日に影響がする可能性があります。	■【軽減策】 – プロジェクトの初期フェーズで、早めの課題抽出と即時アラートを徹底します。 – 問題の即時発見するために、進捗報告や課題管理を徹底する ■【回避策】 問題が発生した場合、緊急会議にて対応策をご相談します

(※今回はデモのためセミナー用の架空の設定の要件で進めています)

あくまで仮のプロジェクトでしたが、こちらがキックオフミーティングのデモンストレーションとなります。

割愛している部分が多々ありますが、プロジェクトによっては、1時間以上かかるケースもあります。また慣れてきますとスキップできる部分も出てきますので３０分ほどで終わるケースもあります。

＜第三部＞まとめ

かつて業務に忙殺されキックオフミーティング自体をスキップしてしまったことがありました。それが原因で意思疎通が図れなくなってしまいました。結果的に品質低下、納期遅延を招いてしまいました。
発注者側も開発者側も日々の業務に追われなかなか確認をする時間が取れないケースもありますが、最後に悪い結果になってしまうと、さらに時間やコストを奪われてしまいます。オフショア開発だけでなくシステム開発の上流工程で要件や仕様を確認することは基本です。オフショア開発では言語の壁により確認することが難しく感じられますがこのようにフォーマット化することによって要件や仕様または意思疎通のギャップを埋めることができます。

こちらでキックオフミーティングの大切さはご理解いただけたかと思います。

ONETECH ASIAの代表のタオからメッセージ

初めましてONETECH ASIAの代表のタオと申します。
本日は貴重な時間をいただきありがとうございます。

オフショア開発をやっている中で重要なポイントを話したいと思います。
私が７年日本で住んで日本の文化や日本人との仕事のやり方を理解しました。
しかし残念ながら実際にオフショアでいつか担当していたプロジェクト失敗したことはあります。

一番勉強になったのは、ひとつの日本語の単語で表現をしますと「明確」という言葉です。

何かを明確にするために、色々資料化が必要かと思いますが先ほどTuanさんが説明した中でも設計書というものが非常に大切だと思います。
UIから業務ロジック、システム設計を明確しないと開発する際に色々課題が発生してやり直すことが多くなってプロジェクトが失敗してしまうケースが多いです。

もう一つは皆様がよく聞いているかと思いますが、それはコミュニケーションです。
言葉の壁、文化の違い、人間性、意識の違いがありますので、認識がずれてしまう可能性が高いです。
業務内容、技術、品質への考え方、スケジュール、課題、リスクなどの認識をお互いに共通化することは大切です。
プロジェクトの開始時点のキックオフの時に認識の再確認、コミュニケーションルールを定義することがとても重要です。

またプロジェクトの進行中に仕様変更、課題が発生することがよくあります。コミュニケーションをしっかりすることにより情報共有をしてお互いに理解することで、大体の問題を解決することができました。

開発プロセスには、色々なものがあります。設計書はビジネスサイドでも技術サイドでも理解できます。曖昧ではなく全て明確にして、お互いに認識の抜け漏れがないようにうまくコミュニケーションをすることがプロジェクトのひとつの成功要因だと思います。

「はじめてのオフショア開発セミナー」について

ONETECHでは２、３ヶ月に一回「はじめてのオフショア開発セミナー」を開催しています。コロナ禍のなかオンラインで開催することにしております。質疑応答をしていただけますとより有意義なもとなると思いますので、ご興味のある方はぜひご参加ください。

問い合わせ先:sales@onetech.jp

 

［投稿者］

株式会社One Technology Japan

代表取締役　河本直己（かわもと　なおき）

• 1973年群馬県生まれ
• 高崎経済大学在学中に中国を放浪
• 繊維専門商社９年間勤務
• 一部上場コンサルティング企業の事業開発部でモバイコマース事業立ち上げ
• モバイルインターネットスタートアップ企業で取締役に就任
• 2015年に株式会社One Technology Japanを創業
  • オフショア開発事業
  • 人材採用教育支援事業
  • 東京下北沢ベトナムサンドイッチ「バインミーバーバー」開始