ブログ

28/02/2023

3 minutes

オフショア開発における品質管理の課題と対策

ITシステム開発には品質管理の悩みがつきものです。品質管理ができていないと品質の低下はもちろん、納期の遅延や予算超過の原因にもなります。日本国内の人材不足やコスト高からオフショア開発を検討している企業も多いと思いますが、国内外を問わず品質管理は課題です。 オフショア開発には優秀な人材を確保できたりコストを抑えたりできるというメリットがある一方、コミュニケーションロスに起因する問題が発生する可能性があります。今回はオフショア開発における品質管理の課題とその解決策、高い品質を維持する方法について解説します。 ITシステム開発における品質管理の4つの課題 国内外を問わず、ITシステム開発にはさまざまな課題があります。発注側と受注側のオフショア開発会社のそれぞれに課題はありますが、大きく分けると以下のような問題が品質トラブルを招くことが多いと思われます。 発注側が受注側のオフショア開発会社に具体的な仕様を提示していない 開発のスタート段階で、仕様の概要は決まっているものの詳細仕様が決まっていないという問題です。仕様の詳細やテスト仕様も決まっておらず、受注側のオフショア開発会社にシステム仕様書やテスト仕様書の暫定版しか提示されていないような状況です。特に近年システム開発手法の主流になっているアジャイル開発では、優先度の高い要件から先に開発を進めていくので、全体の詳細仕様が決まっていない場合が多くあります。 アジャイル開発は仕様変更に強いという特徴はありますが、発注側が各機能の仕様を次々に決めないと開発が遅れ、品質問題を起こす原因にもなります。以前主流であったウォーターフォール開発でこの状態であれば、開発の後半になって深刻な品質問題を引き起こす可能性があります。 開発の初期段階で仕様やテストの条件が発注主を交えてレビューされていない 詳細の仕様が決まっていないという問題ではなく、発注主とオフショア開発会社で十分なレビューが行われていないという問題です。言い換えれば情報共有が十分になされていない状態で、発注側は意図が伝わったと思っている一方、受注側は仕様やテストの条件を十分に理解できていないような状況です。開発初期段階のレビューは、意図通りに仕様やテストの条件が伝わっているかを、口頭ではなく書面で相互確認することが重要です。 受注側のオフショア開発会社のレビュー計画とテスト計画が明確になっていない 発注主から示された詳細仕様やテスト条件を盛り込んだレビュー計画とテスト計画は、受注側のオフショア開発会社が作る必要があります。発注主は承認した開発計画が決めたとおりに進んでいるか、レビューでチェックをする必要がありますが、オフショア開発会社側の人員計画などが煮詰まっていないと、レビュー計画とテスト計画が曖昧になりスケジュールが遅れて品質問題に発展する場合があります。 開発手法の違いによる品質管理の方法が理解されていない 開発手法として現在主流になっているアジャイル開発と旧来のウォーターフォール開発では、品質管理の方法に違いがあります。両者とも品質管理に対する基本的な考え方は同じですが、ウォーターフォール開発では機能が利用可能になるのは開発終了時です。 一方アジャイル開発は、開発中であっても段階的に（機能ごとに）テストや評価ができるため、品質の確認時期に違いがあるのです。このような開発手法による品質管理の方法を理解していないと、テスト計画のスケジューリングを誤り品質トラブルの要因となってしまいます。 上記のような問題は国内の開発においても十分注意する必要がありますが、オフショア開発を委託する場合には以下のような問題にも注意する必要があります。 オフショア開発の委託時に注意すべきこと 言葉の壁によるコミュニケーション不足 オフショア開発を海外に委託する場合、一番問題となるのが言葉の壁によるコミュニケーション不足でしょう。先述のように発注側と受注側のレビューが十分でないと「仕様通りの成果物が上がってこない」、「修正を指示したのに直っていない」などという問題が発生しがちです。 ただし、このようなコミュニケーション不足は国内のシステム開発においても起きる可能性があるので、特にオフショア開発特有の問題というわけではありません。言葉の壁を解消する方策が重要ということです。 国民性や商習慣の違い 国民性や商習慣の違いによる問題も、オフショア開発においてはよく指摘されることです。ただしこちらも、ほとんどの場合はコミュニケーションやレビューの頻度を調節することによって解決できる問題です。日本国内においても企業ごとに文化の違いがあるように、開発手法や品質に対する考え方を開発の開始時に合わせておくことが重要です。 課題を解決し品質低下を防ぐには？ ITシステム開発の品質低下を防ぐには、以下のような事項に加えオフショア特有の課題を解決する対策が必要です。 開発前の準備（仕様決定、要件定義、テスト条件決定） 上流工程や初期段階での要件定義と合同レビュー テスト計画の策定と共有 プロジェクト管理の徹底 高いスキルを持つPM（Project Manager）の起用 品質評価基準の早期策定と共有 プロジェクト管理ツールの適用 オフショア開発の品質低下を防ぐ方法 コミュニケーションの障壁を取り除く 言葉の壁を取り除くには、ブリッジエンジニアを導入することが最適解です。担当者が英語でのコミュニケーションが問題なければ必要ないかもしれませんが、ネイティブのブリッジエンジニアを起用することで、国民性や商習慣の違いなどについてもカバーしてくれることでしょう。また、仕様書は英語化するなどし、共通のフォルダに格納していつでも閲覧できるようにしておくことが大切です。 曖昧な表現や口頭での伝達を避ける たとえ国内であっても、曖昧な表現で重要事項を伝達していては守られることがありません。これはオフショアでも同様で、重要事項を伝える場合は曖昧な表現を避け、口頭ではなく文章で指示しましょう。また、品質マニュアルや守るべきセキュリティの内容を明文化（英語）しておくことも大切です。 オフショア開発で高い品質を維持するためには オフショア開発では、開発人員を固定して効率的に開発できるラボ契約とアジャイル開発の組み合わせが最適な開発方法です。先述のようにアジャイル開発は品質管理の方法が従来とは違うので、その違いをしっかり理解しているオフショア開発ベンダーを選ぶことが高い品質の維持につながります。 日本企業の開発案件に豊富な経験と実績があるオフショア開発ベンダーと契約する オフショア開発の優れたベンダーと契約するためには、以下のような項目をチェックすることが重要です。 日本企業のプロジェクトを多くこなしているオフショア開発ベンダーを選ぶ。案件は数だけではなく、規模や内容もチェックする。 品質維持のノウハウを多く持っているかを確認する。また社内の品質管理チームが機能していることも確認しておく。 どのようなエンジニアが在籍しているかを確認する。コミュニケーション能力や管理能力の高いPMやブリッジエンジニアの在籍数も確認する オフショア開発の依頼は現地の事情に詳しい企業に オフショア開発はその特性から課題もありますが、それらは克服可能です。ブリッジエンジニアや明確な指示など、コミュニケーションの問題に対する対策を講じることが重要です。 また、一つの対策として、現地に本社を持つオフショア開発会社に依頼するのも有効です。現地の事情に詳しい企業ならば、国民性や商慣習の障害を回避し、高品質なシステム開発を実現できます。これらのアプローチを組み合わせることで、オフショア開発による高品質なITシステム開発を期待できることでしょう。 無料eBookのダウンロード チェックリストでわかる 失敗しないオフショア開発会社の選び方 オフショア開発会社選びの準備から開発開始まで、多様な角度からチェックポイントを網羅。チェックリストを活用して効率的な選定や基準作りに役立ちます。 今すぐダウンロード（無料）

28/02/2023

3 minutes

オフショア開発でコミュニケーションの壁を乗り越える基本的な手段とは？

オフショア開発において、言葉の壁や文化の違いは円滑なコミュニケーションの障害となることがしばしばあります。異なる母国語や習慣を持つエンジニアとの間での誤解を回避し、プロジェクトの成功を確保するためには、適切な対策が不可欠です。本記事では、オフショア開発におけるコミュニケーションの壁を乗り越える上でもっとも基本的なオフショア開発の形態や方法について解説します。 適切なオフショア開発形態を選択する 適切なオフショア開発形態を選択する まずは、オフショア開発をどのような形態や方法によって行うかによって、コミュニケーションのしやすさが大きく異なってきます。オフショア開発の形態は、各企業やプロジェクトよってさまざまです。 代表的には、以下のような形態があります。発注元の企業は、プロジェクトの性質や要件、予算などを考慮して、最適なオフショア開発方法を選択する必要があります。 オフショア開発（オフショアリモート開発） 発注元の国や地域とは異なる国や地域に開発を委託し、プロジェクトの進行をオンラインツールやコミュニケーションプラットフォームを通じて遠隔で管理します。クライアントと開発チームは物理的には近くにいないため、リモートでのコミュニケーションが主要な手段となります。 オフショア開発（オフショアリモート開発） 開発チームや担当者がプロジェクトの発注元の国や地域に派遣され、クライアントの現地で作業を行います。オンサイトのメンバーは直接クライアントとコミュニケーションを取り、要件の理解やフィードバックの収集を容易にします。 ハイブリッドアプローチ 開発チームや担当者がプロジェクトの発注元の国や地域に派遣され、クライアントの現地で作業を行います。オンサイトのメンバーは直接クライアントとコミュニケーションを取り、要件の理解やフィードバックの収集を容易にします。 オフショア開発センター オフショア開発センターは、発注元の国や地域とは別の国や地域に、独立した開発拠点を設置する方法です。これにより、外部の開発会社とは独立した開発チームを持つことができます。クライアントが自社の拠点を持つことで、プロジェクトのコントロールとセキュリティの管理をより直接的に行うことができます。 言葉の壁や文化の違いを乗り越えて、コミュニケーションを円滑にする方法 1. 日本語でコミュニケーションできるブリッジSEを必ずアサインする オフショア開発チームと日本語でコミュニケーションを行おうとする場合は、しっかりと日本語で技術的なコミュニケーションができる人材が在籍しているオフショア開発企業を選定する必要があります。実際にメンバー選定する場合には、どの程度の水準でコミュニケーションが可能なのか、実際に面談するなどして確認しておきたいところです。 特に、日本企業のプロジェクトでは、確定した設計仕様の変更などが生じるケースがありますが、こうした場合にはコミュニケーションは特に重要となります。例えば、日本語で何とか会話出来るというレベルと、きちんと意思疎通できて安心感のあるコミュニケーションができるレベルでは、開発現場においてその差はとても大きなものとなるはずです。 オフショア開発企業によっては、日本語を流ちょうに話すものの、技術的知識やスキルが少ないコーディネーター（またはコミュニケーターと呼ばれる人）をブリッジとしてアサインするケースがあります。そのようなケースでは、技術的な意思疎通がうまく得られないという問題が生じ、コミュニケーションロスに苦戦する可能性があります。 一方、日本企業向けに特化した日本企業とのプロジェクトの経験豊富なオフショア開発企業であれば、オンサイトで日本在住経験があり日本語レベルが高く、日本文化や日本型の開発手順への理解度も高いSEが在籍しており、日本人SEが在籍している場合もあります。こうしたブリッジSEはドキュメントも日本語で作成しますので、会話や文字による意思疎通にも安心感が得られるはずです。 また、こうした日本企業向けのオフショア開発企業では、オフショア現地においても従業員の教育体制を整えて日本語教育を行っており、日本語能力試験のN1、N2に合格するレベルのコミュニケーションができる多数のエンジニアが在籍しています。 2. オフショア開発会社のエンジニアにオンサイト常駐してもらう オフショア開発における「オンサイト」には、多くのメリットがあり、コミュニケーションに関連するメリットが重要です。以下に主なメリットを列挙します。 コミュニケーションの円滑化 オンサイトメンバーが現地にいることで、クライアントとのコミュニケーションがスムーズに行われます。リアルタイムで会話をすることで、要件や課題の理解が深まり、ミスコミュニケーションのリスクが低減します。 フィードバックと変更への対応 オンサイトメンバーが直接プロジェクトの進捗を把握できるため、クライアントのフィードバックや要件変更に対応するのが容易です。迅速な対応により、プロジェクトの品質向上やタイムリーな納品が可能となります。 現地の文化や業界知識の理解 オンサイトメンバーがクライアントの現地にいることで、その国や地域の文化や業界のニーズをより深く理解することができます。これにより、より適切なソリューションの提供が可能となります。 信頼関係の構築 直接会って顔を合わせることで、クライアントとオフショア開発チームとの間に信頼関係が築かれやすくなります。信頼関係があると、プロジェクトの協力的な進行や問題の解決が円滑に行われるでしょう。 グローバルな視野の拡大 オンサイトメンバーが直接プロジェクトの進捗を把握できるため、クライアントのフィードバックや要件変更に対応するのが容易です。迅速な対応により、プロジェクトの品質向上やタイムリーな納品が可能となります。 ただし、オンサイトにはコストや時間の面での課題もあるため、企業はオフショア開発とオンサイトの組み合わせを検討し、プロジェクトの要件や条件に応じて最適な方法を選択する必要があります。 3. 日本側のPMがオフショア現地に常駐してマネジメントする 日本側のプロジェクトマネージャー（PM）がオフショア現地に常駐することには、いくつかの重要なメリットがあります。特に、コミュニケーション面においては以下のようなメリットがあります。 コミュニケーションの円滑化 現地にいることで、リアルタイムで会話をし、課題や進捗状況を共有できるため、ミスコミュニケーションのリスクが低減し、開発チームとのコミュニケーションがスムーズに行うことができます。 要件の適切な伝達 直接顔を合わせることで、誤解を防ぎ、要件の理解度を確認することができるため、要件やニーズをより正確に伝えることができます。 フィードバックの収集と即時の対応 オフショア現地にいることで、プロジェクトに関する質問や修正が即座に行われることが可能になります。フィードバックを容易に収集し、必要な変更に素早く対応できます。 文化的な違いの理解 オフショア現地の文化やビジネス慣習をより深く理解できます。これにより、開発チームとの間に信頼関係が構築され、円滑なコミュニケーションが促進されます。 緊急時の対応 緊急の課題やトラブルに迅速に対応できます。時間差がある場合、オフショア開発チームが問題に対処するのに時間がかかることがありますが、PMが現地に常駐することで、素早い対応が期待できます。 このように、PMがオフショア現地に常駐することで、コミュニケーションの円滑化やプロジェクトの成功に寄与します。ただし、常駐には様々なコストや準備時間の面での課題もあるため、プロジェクトの要件や条件に応じて、最適なアプローチを選択する必要があります。 4. 英語を共通言語にする 母国語としないアジアの国々も含めて海外のオフショア開発会社とコミュニケーションを取る際、共通の言語として英語を選択する理由は複数あります。 英語は世界的に広く普及しており、アジアの多くの国でも教育やビジネスで使用されているため、異なる母国語を持つ相手と円滑なコミュニケーションを図るのに適しています。 また、アジアの国々がグローバルなビジネス展開を進めているため、国際取引やプロジェクトにおいて英語が共通の言語として選ばれることが増えています。 さらに、英語を共通言語とすることで、文化的な違いを克服し、より明確なコミュニケーションが可能となります。アジアには多様な言語が存在するため、特定のアジア言語を共通言語とすると相手とのコミュニケーションが難しくなることもあります。しかし、英語は多くのアジアの国々で使用されているため、より広範な相手とのコミュニケーションが可能です。 […]

28/02/2023

3 minutes

失敗事例から学ぶ、オフショア開発成功への9つのヒント

昨今、ITシステム開発の現場では、オフショア開発という選択肢は一般的となりました。しかし、中には当初に想い描いた通りにはプロジェクトを進めることができなかったという声も聞こえてきます。そこで、本記事では、オフショア開発の失敗事例から学ぶ、失敗原因や成功へのヒントにについて紹介します。 オフショア開発で陥りやすい失敗事例 まずは、オフショア開発での失敗事例としてよく耳にする話題をいくつかご紹介します。 失敗事例１：仕様伝達に失敗し、納期が遅延してしまった 発注元の担当者は、発注先のオフショア開発会社に日本語ができるブリッジSEをアサインしてもらい、仕様と作業内容を文書にまとめてブリッジSEとミーティングを行って説明した。 ミーティングは日本語で行ったが、ブリッジSEも要求をよく理解してくれているように見えたため、日本語のコミュニケーションでも問題ないと判断していた。その後の進捗状況の確認でも、ブリッジSEからの報告は常に「問題なし」という回答があり安心していた。 しかし、次第にブリッジSEから1日に数回の質問が毎日のように届くようになった。担当者はその質問への回答作業に追われる日々となってしまい、レビューによる品質確認を行う時間を確保することができぬまま納期を迎えてしまった。 これは、オフショア開発会社への仕様の伝達がうまくいかずに作業の遅延が発生してしまったケースです。原因は、発注先の窓口となるブリッジSEとの日本語による意思疎通ができたため、仕様伝達のハードルは低かったと思い込んでしまったことにあります。 しかし、発注先のオフショア開発会社の窓口となるすべての人が技術面について知識を持っているとは限りません。 中には、主に通訳を役割とするコミュニケーターと呼ばれるべき人材にブリッジSEという肩書きを与えているオフショア開発会社も存在します。 このような失敗を回避するためには、窓口となるブリッジSEの日本語の言語能力の確認にとどまらず、そのブリッジSEの職務範囲や職能まで確認しておくことが大切です。 もし、オフショア会社の窓口担当者の技術的な内容の理解度に不安を感じる場合には、そのコミュニケーターを介して仕様伝達を行うのではなく、直接現地のSEと英語でやりとりを行う方がお互いの理解度を確認しながら進めることができるでしょう。その方が結果的には二度手間の発生を抑制でき、間接コストも削減することができるでしょう。 失敗事例２：度重なる仕様変更により、コストが増大してしまった 全体の仕様が確定しておらず、一部の仕様は暫定的なものとして見積を行い、そのまま見切り発車で発注した。 暫定部分は、発注後に五月雨式に仕様伝達を行ったものの、その後も仕様変更が繰り返され曖昧な仕様が残ったままだったため、ドキュメント作成やメールやチャットなどの仕様伝達の工数が増大した。 また、開発現場でも仕様の混乱や手戻りが発生し、当然スケジュールも大幅に遅延して収拾がつかなくなった。そのため、開発途中でブリッジSEと仕様確認の仕切り直しが必要となった。 その結果、コミュニケーションと開発の工数が増大し、最終的には、見積金額を大幅に超えてしまった。 これは、仕様が曖昧なまま発注したうえに仕様変更を繰り返した結果、コストと納期がオーバーしてしまったケースです。国内開発の発注においても発生し得るような例ですが、走りながら徐々に要求仕様を決めていくというやり方は、典型的な日本型の開発アプローチと言えます。 オフショア開発をこのような国内開発の感覚で行ってしまうと、信頼関係にひびが入ってしまい想像以上にトラブルを拡大させてしまう危険性があります。信頼関係がなければプロジェクトが失敗する確率は限りなく高くなるでしょう。そうなれば、金銭面でもトラブルに発展しまう可能性があります。 仕様を変更すること自体は問題ないのですが、問題は仕様変更をスムーズに進めるための段取りとコミュニケーションにあると考えられます。オフショア開発ベンダー側の状況を考慮して伝達することが大切です。 失敗事例３：日本語での意思疎通の失敗 ある過去に一度、開発を依頼したことがあるオフショア開発会社に、新規のプロジェクトを依頼した。初めて発注した際は、日本語でのコミュニケーションに多少の不安を抱いていたものの、アサインされたブリッジSEがとても優秀で、日本語スキルや技術レベルは事前の説明通りにレベルが高く、プロジェクトは無事成功を収める事ができた。 そこで、同じオフショア開発会社に別のプロジェクトを追加発注したところ、アサインされたブリッジSEの日本語スキルが低く、前回のブリッジSEと比較すると大幅に劣っていた。 事前に、コミュニケーション言語は日本語で行うとの取り決めていたものの、メールで質問を受け付けても一体何を伝えたいのか理解できないようなことがかった。そこで英文でのやりとりも試してみたが英語もさほど得意ではないらしく、結局、意思疎通はなかなか改善せず苦労した。 オフショア開発会社からの事前説明での「日本語コミュニケーションが可能な優秀な技術者が在籍している」との話に期待したところ、その事前期待が結果と異なっていて失敗したケースです。 たしかに、最初のプロジェクトにアサインされたブリッジSEは期待以上の能力を発揮してくれたため、次のプロジェクトでも期待するのは自然なことです。 初めての取引の際は、どこのオフショア開発会社もエース級の人材をアサインしてくるとうのはよくあることです。とはいえ、そのように優秀な人材が社内に多数在籍していて、発注者が希望するタイミングでいつでもアサインできるかどうかはまた別の話です。 このケースでは、エース級の人材は少数しか在籍していなかったり、または優秀な人材は別のプロジェクトに参加していて自社の案件にはアサインできなかったのかもしません。 顧客の要望に応じて、最適な人材を安定的にアサインできるかどうかは、オフショア開発会社それぞれの事情によって大きく異なります。特に、人材の豊富さは事業規模が大きいオフショア開発会社の方が有利でしょうし、また特定分野の人材であれば、小規模でもその分野に専門特化したオフショア開発会社なら最適な人材を確保できるかもしれません。 なお、日本市場に注力して事業を展開しているオフショア開発会社では、社内で日本語教育を行っていることは珍しくありません。しかし、その教育内容や方法も企業にとってさまざまで、営業やブリッジSEに限定して教育している場合もあれば、その他のエンジニアも含めて行う場合もあります。 また、日本語認定資格の取得を奨励し、資格取得手当てなどの制度を設けている企業もありますし、採用段階で選考基準として日本語のスキルレベルの高い人材や、日本国内でのビジネス経験や日本企業とのプロジェクト経験がある人材を多く採用しているケースもあります。オフショア開発会社選びの際には、そのような日本語教育のへの取組み状況状況も確認しておくとよいでしょう。 オフショア開発を成功に導くための９つのヒント 先述の陥りがちなオフショア開発での失敗事例のような問題は、実は日本国内での日本人エンジニアによる開発でも起こり得ることです。オフショア開発の現場では、とりわけ言語、文化、国民性の違いによるコミュニケーションのギャップが問題を生じさせる原因となる場合が多いです。そこで、ここではオフショア開発での失敗を回避し、開発プロジェクトを成功させへと導くための9つのポイントを紹介します。 1. コミュニケーション言語のスキルレベルを確認する 日本語や英語など、オフショア開発会社とのコミュニケーション言語を取り決める際には、コミュニケーションに支障がない程度の言語スキルを持っているかを事前に確認しましょう。 例えば、コミュニケーション言語を日本語にすると取り決めた場合、そのスキルレベルを客観的に把握する一つの目安としては日本語検定試験（JLPT）があります。日本語能力試験は、日本国内および海外で日本語を母語としない人を対象として日本語の能力を測定し、認定することを目的として行う試験です。試験はN1からN5レベルまでの5段階に分けられており、N1は最も難易度が高くなっています。 N1は幅広い場面で使われる日本語を理解することができるレベルで、N2は日常的な場面で使われる日本語の理解に加え、より幅広い場面で使われる日本語をある程度理解することができるレベルとされています。そうしたことから、外国人を採用する企業では、在留資格・ビザ取得の観点からもN1〜N2を選考基準としている場合が多いようです。 N1は日本語ネイティブでも満点を取るのが難しいレベルの試験と言われていますので、N1保持者であればビジネスシーンでの活躍を期待できるでしょう。しかし、必ずしもすべてのエンジニアがN1レベルを取得している必要はなく、担当業務に合わせて日本語能力がどの程度必要なのかを基準とするのがよいでしょう。オフショア開発の場合では、ブリッジSEの日本語能力は重要ですが、オフショア国現地で働くエンジニアには必ずしも日本語スキルは必要とされません。 なお、日本語能力試験の問題は文章読解と聴解のみのため、書く、話す、といった能力は測ることはできません。そのため、ブリッジSEをアサインする際には、面接やディスカッション、メールのやりとりなどを取り入れると良いでしょう。 2. 日本との文化や国民性の違いを認識し、明確に意思表示する 日本と海外では、考え方や仕事の進め方も異なります。日本では、物事をこと細かく伝えなくても相手は当然のごとく察してくれるだろうと期待してしまいがちです。しかし、海外では、相手に明確な意思表示をしなければ伝わらないコミュニケーション文化を持つの国の方が多いです。むしろ、相手に繊細かつ高度な感性を求める日本式コミュニケーションの方がガラパゴス的と言えるかもしれません。 こうした文化や国民性の違いによって意思疎通や相互理解がうまくいかなくなってしまうと、結果として品質低下や手戻りが発生してしまうことがあります。 本側から物事を依頼する時は、目的（なぜやるのか）、スコープ（何をやるのか）、タイム（いつまでに必要か）、コスト（いくら以内でやるのか）を可視化してプロジェクトの目的を一致させ、認識の食い違いを防止することが大切です。 また、開発先の文化や国民性を理解しておくと、誤解や思い違いを少なくできます。時にはやり方を日本式に合わせてもらうように強制するばかりではなく、お互いに文化が違う国であることを理解し歩み寄る姿勢も大切です。 3. 情報共有や取り決めは、可能な限り文書化する 日本では、話し手と聞き手の間に共有されていることが多いため、行間を読み、暗黙的なコミュニケーションが成立しやすい文化といえます。また、日本では会議の場での共有や明確化をすることが多くなりますが、口頭による伝達や暗黙知の共有が含まれるため文書化しにくかったり、伝達する内容が多く労力がかかるという理由から、文書化しないケースが度々見られます。 一方、海外では、共有する情報や経験が少ないため、文章や図解、数値などによって、誰が見ても理解できるような形式で客観的に表現された形式知によるコミュニケーションが行われること多々あります。これは、個人主義的な文化の国ほど強くなえる傾向が見られます。そのため、母国語が異なる国のメンバーと日本語で業務を進めるオフショアの場合には、仕様等を確実に文書化してデータベースで共有するのが望ましいでしょう。 過去にオフショアで失敗を経験した日本企業による教育指導的な役割によって、日本企業とのプロジェクト経験が多いオフショア開発会社ほどそのような体制が整っています。こうした取り組みは、転職率の高いオフショア開発の課題をカバーするためにも有効です。 また、口約束で決まったと思っていたことが後になって変更となり、問題になることがあります。決めごとは合意と承認があって成立するものですので、可能な限り文書化して相互に承認ルールを確認し徹底することが大切です。 4. 仕様変更と品質レベルに関する考え方の違いを意識する 日本では、度重なる仕様変更が生じても、それに対応することが当然であると考えられがちです。一方、オフショア開発では、契約締結後に仕様変更を行うことは一般的とは言えません。そのため、仕様変更を巡ってはトラブルが発生する可能性があります。 […]

28/02/2023

3 minutes

日本企業が抱えるシステム開発の課題と今後のオフショア開発の方向性とは

日本企業のシステム開発は、IT人材不足と開発コスト増加が大きな問題となっています。急速なデジタル化とテクノロジーの進化に追いつくための、適切なITエンジニアやデジタル専門家の確保が難しく、開発コストも上昇しています。この課題に対し、「リスキリング」と「オフショア開発」という解決策が注目されています。企業は、内部のスキル向上とグローバル競争への対応を目指し、オフショア開発を　人材戦略に活用することで、人材不足を克服し、競争力を高める展望が期待されています。 オフショア開発の現状 DX人材不足の解決策としても注目されている、オフショア開発の現状を紹介します。 オフショア開発の規模が拡大している 経済産業省が2019年に発表した「IT人材育成の状況等について」によると、日本では2030年までに約59万人のIT人材が不足すると予想しています。今後も優秀なエンジニアを確保するために、オフショア開発を導入する企業の増加が考えられるでしょう。 DX推進やシステム開発の需要拡大により、日本でのオフショア開発の規模は拡大しています。独立行政法人 情報処理推進機構（IPA）の調べでは、日本のIT企業の約45.6%がオフショア開発を導入している、またはなんらかの形でオフショア開発に関与しているというデータがあります。 【別記事】なぜ日本のIT企業のオフショア開発が活発化してるのか 中小企業の委託元が増加している 海外進出のため費用と手間がかかり、少し前まではオフショア開発を導入しているのは大企業が多い傾向でした。しかし、最近ではグローバル化が進んでいることや、オフショア開発のノウハウが蓄積されたことによって中小企業の委託元が増加しています。 委託先国としてベトナムが人気 オフショア開発の委託先といえば、かつては中国やインドが人気国でした。近年では人件費が安く、優れた人材が豊富で、真面目な国民性などの要因を持ったベトナムが人気を集めています。 オフショア開発の希望委託先国について、オフショア開発.comがまとめたデータ（2020年1月〜12月に「オフショア開発.com」に寄せられた開発相談の希望委託先国別ランキングより）によると、1位がベトナムで、全体に占める割合は52％でした。 【別記事】【2022年最新】オフショア開発の人月単価相場動向、人気のベトナムほか国別比較 日本企業のオフショア開発導入の目的の変化 昨今、日本企業のオフショア開発導入の目的が変化してきています。以前は、コスト削減が主な目的でしたが、企業のデジタル競争力を高めるDX人材不足の対応策や、品質の確保といった目的にシフトしています。 NFT、DeFi、Web3.0、メタバースなどの新しい風潮 スイスのIMDが発表している「世界デジタル競争力ランキング」で日本は2020年に63カ国中27位という結果で、2021年には28位と順位を下げています。日本の順位は年々デジタル競争力を高めている香港や韓国、台湾と比べると対象的な数値となっています。 日本企業のデジタル化が世界各国の企業より遅れている理由の一つに、DX人材不足が挙げられます。そのため日本で不足しているAI、IoT、ブロックチェーンなどの先端技術スキルを持った人材を補うために、オフショア開発導入に向けての動きが増しているのです。さらなる企業のオフショア開発導入の加速に向けた背景にあるのが「NFT」「DeFi」「Web3.0」「メタバース」などの新しい風潮です。 ブロックチェーン技術をベースにして唯一無二の「一点もの」を生み出せるトークンである「NFT」、金融エコシステムの「DeFi」、仮想空間の「メタバース」など、これらはIT業界やテック業界を越えてさまざまな業界で注目を集めています。これらNFT、DeFi、メタバースなどのブロックチェーン技術をベースにした各カテゴリーを包括する位置付けとなるのが「Web3.0」です。 Web3.0は「分散型のWeb」を意味し、巨大IT企業による支配からのデータの解放を目的としています。世界各国がWeb3.0推進への取り組みが進む中、日本の出遅れを防ぐため日本政府が2022年6月に経済財政運営の指針である「骨太の方針」にWeb3.0の環境設備を明記しました。日本のグローバルな競争力を高めるには、Web3.0のブロックチェーン技術は欠かせません。 オフショア開発における今後の方向性 こうしたことを踏まえ、日本企業のオフショア開発導の今後の方向性は次のようなことが考えられます。 オフショアの役割を下流工程から上流工程まで拡大する 実は、オフショア開発の対象業務は、国によって異なります。例えば、米国企業では、上流工程から下流工程まで任せるのが一般的です。米国のユーザー企業は多数のITエンジニアを採用し、社内のIT部門に配置しているため、基本的には自社システムの開発から運用まで内製化するのが主流です。これは、社内技術やノウハウを社外に流出させないためでもあり、日本のように自社のシステム開発を外部のSI企業に全てお任せするということはありません。 オフショア開発などの外部リソースを活用するのは社内でリソース不足が発生した場合です。また、ユーザー企業にとって開発プロジェクトが完了したら終わりということはなく、リリース後にブラッシュアップしていくことを前提として、アジャイル開発でによってサービスインまでの期間を短縮できるのが特徴ですなどので補うというにで、自社のエンジニアのスキルアップにつながっています。これまでの日本企業のオフショア開発では、海外の委託先には下流工程中心にまかせるのが一般的でした。 従来型の形態では、日本のエンジニアの技術スキルが低下する懸念もありつつも、日本企業が海外の企業と同じような導入形態にならないのは、顧客の要件定義が固まらないという課題があったからです。そこで、作業要領も含め日本での開発と同様に、要件定義を明確に行うことで課題の解消につながり、日本企業でも委託先に上流工程までまかせる動きが拡大しています。これにより日本のDX人材強化も期待できるでしょう。 DX領域にシフト 従来、日本企業が海外の委託先にまかせていたのは、基幹システムや既存システムが中心でした。しかしながら、日本企業が変化の激しいビジネス環境の中で優位性を確立するには、デジタル競争力を高めることが急務となっています。DXによる事業改革が不可避となっている昨今、AI、IoTといったDX領域へと業務の委託内容がシフトしています。 ここでDX領域を委託する際に課題に挙がるのが、海外の委託先にDX領域の開発をまかせてしまうため、自社のエンジニアのスキルアップにつながらないことです。課題の解決策として、上流工程、下流工程の分担を明確にしているウォーターフォール開発ではなく、チームを組んで海外のエンジニアと一緒に要件定義、設計、開発、テストといった開発工程を行うアジャイル開発の活用があります。 日本のエンジニアにとっても、海外の優秀なエンジニアと一緒のチームで働くことで、スキルアップにつながることが期待できます。大手のオフショア開発企業や弊社のエンジニアの技術レベルは高く、DX時代にふさわしい優秀な人材を確保することも可能です。 人材不足面でのオフショア開発活用 上記の1、2では日本のDX人材、エンジニアのスキルアップに向けたオフショア開発企業の活用についてお伝えしましたが、日本国内のIT人材不足はいまだ解消されていません。日本におけるDX領域の開発は急務ですが、依然としてレガシーシステムは稼働しており、メンテナンスや運用、開発のための人材が必要です。 しかし、日本のIT人材絶対数の不足もさることながら、日本国内の若いエンジニアにはPythonなどの言語が人気で、レガシーシステムなどに必要なCOBOLなどの昔ながらの言語は不人気という状態です。このような既存システム、基盤システムなどのレガシーシステムにおける人材不足面を解消するためにも、オフショア開発が活用されています。 オフショア開発導入はDX人材不足解消と育成につながる DX時代の人材戦略「リスキリング」の重要性 日本の近年、グローバルな競争が激化する中、日本企業はさまざまな手段を活用して競争力を高めることが求められています。日本のデジタル競争力を高めるためにはDX（デジタルトランスフォーメーション）推進が叫ばれるものの、国内のITエンジニアやDX人材などの人材不足が大きな課題となっています。 日本のITエンジニアやDX人材不足は、急速なデジタル化やテクノロジーの進展に追いつくことが難しくなっています。このような状況下で、企業は従業員のスキルアップを重視し、最新の技術やトレンドに対応でき、変化するビジネス環境に適応できる人材を育てる必要性があります。こうしたことから、日本のITエンジニアやDX人材不足を解消するため、「リスキリング」が注目されています。 リスキリングとオフショア開発の関係性 オフショア開発は、日本のITエンジニアにとって新たなスキル向上とグローバルな成長の機会を提供する重要な手段となっています。 オフショア開発を活用することで、日本のITエンジニアはグローバルなプロジェクト経験を積むことができます。異なる国や地域の開発チームと協力することで、異文化環境におけるプロジェクト管理やコミュニケーションスキルが向上し、柔軟性や適応力を高めることができるでしょう。 そして、オフショア開発では、リモートコミュニケーションが主要な手段となります。ITエンジニアは遠隔地の開発チームと円滑にコミュニケーションを取るため、効果的なコミュニケーションスキルを磨く必要があります。適切なコミュニケーションにより、要件の理解や問題解決がスムーズに行われ、プロジェクトの成功につなげることができます。 さらに、オフショア開発によって最新の技術トレンドにアクセスする機会が増えます。世界中の開発者と協力してプロジェクトを進めることで、新しい技術や開発手法を学び、実践する機会が増えるでしょう。これにより、ITエンジニアの技術力や知識が向上し、自己成長が促進されることが期待されます。 また、オフショア開発には異なる地域の開発チームと協力することが求められます。これにより、ITエンジニアはチームワークとリーダーシップのスキルを発展させる機会を得ます。プロジェクトの成功に向けて指導力を発揮し、チームと協力して目標を達成する経験を積むことで、エンジニアとしての成長が促進されるでしょう。 こうしたことから、オフショア開発の経験は、日本のITエンジニアのスキルアップとグローバルな視点の向上に寄与すると言えます。グローバルなプロジェクト経験、コミュニケーションスキルの向上、最新技術の習得、チームワークとリーダーシップの発展といった点に着目することで、オフショア開発がエンジニアのキャリアにプラスの影響を与えることが期待されます。 オフショア開発とリスキリングの組み合わせは、企業のデジタル化戦略を推進する上で有益なシナジーを生み出すことが期待できます。 無料eBookのダウンロード 保存版 オフショア開発入門ガイド2023 オフショア開発を始める前の気になる疑問を解決！オフショア開発を検討中の方に向けて、オフショア開発の基本的な知識から注意点までを解説します。 今すぐダウンロード（無料）

31/01/2023

3 minutes

失敗しないオフショア開発会社の選び方｜開発パートナー選定のステップや比較ポイントを解説

オフショア開発の委託先国には様々な国々があります。また、オフショア開発会社の特徴も様々で、開発会社によって対応できる市場や得意分野も異なります。オフショア開発会社選びを間違えてしまうと、その後のプロジェクトが進むにつれて、納期の遅延や品質不良といった問題を引き起こしたり、プロジェクトの失敗リスクを高めることにつながりかねません。 本記事では、オフショア開発を検討している方に向けて、自社の開発パートナーとして最適な１社を見つけるために、オフショア開発会社のタイプや比較のポイント、パートナー選びの注意点などについて紹介します。オフショア開発会社選びにお悩みの方は、ぜひ最後までご一読ください。 オフショア開発の委託先国 オフショア開発では委託先をどこの国にするのかは大変重要です。コスト、言語、文化、時差、信頼性など、さまざまな要素を考慮して選択する必要があります。 オフショアとは？ オフショア開発とは、業務を海外に委託、アウトソーシングすることです。 特にシステムの開発や保守などの運用を委託することが多く、その場合は「オフショア開発」とも言われます。 オフショア開発とニアショア開発については、以下の記事も参考にしてください。 【別記事】オフショア開発とは｜メリット・デメリット・成功に導く6つのポイント 【別記事】オフショアとニアショアの違いとは？それぞれのメリット・デメリットと活用のポイント 人気のオフショア開発の委託先国はどこの国 オフショア開発の人気の委託先は、さまざまな要因により変化します。現在の人気はベトナム、バングラディシュ、ミャンマーなどの東南アジアの国々で、賃金がまだ安いことが大きな理由です。特にベトナムは、スキルの高いエンジニアが多いため人気があります。 かつては中国やインドも人気でしたが、人件費が上がってコストが高くなってきたので、件数は減っています。 オフショア開発における委託先の人気国については、次の記事を参考にしてください。 【2022年最新】オフショア開発の月先相場、人気のベトナム他国別比較 オフショア開発会社の分類 オフショア開発会社は国や企業によって様々ですが、その運営者の資本系列とターゲット市場によって以下のように分類することができます。 以下はベトナムを例にしていますが、他の国でも国名を読み替えてイメージしていただければいただければと思います。 ベトナム資本のオフショア開発会社 大規模なオフショア開発会社のターゲットはグローバル市場 欧米市場や日本市場などを視野に入れたグローバルな組織構成です。日本法人を設立して日本国内の大都市圏に拠点を設置し、日本企業向けに特化したITアウトソーシングサービスも提供しています。ITエンジニアの人材リソースの規模は1,000名以上と多く、小規模から大規模まであらゆるプロジェクトに対応できます。必要な人材を必要なタイミングで確保できるスケーラブルなリソースは、中小規模のオフショア開発会社では対応できない大きな強みと言えます。 また、日本企業とのプロジェクト実績も豊富なため安心感があるという点も大きな魅力となっています。 多彩な技術スタックで対応範囲も広く、オープン系、汎用系、Web系、組み込み制御などに幅広く対応しています。 例えば、BtoBでは、企業の基幹システムや情報システムなどの業務システムアプリケーションや、金融・物流・製造など様々な業種向けの基幹システム開発・構築・運用・保守、オンプレミス環境からクラウドサービスへのマイグレーション、また自動車や製造業界向けのCAD/CAEやIoT、AI開発などにも対応します。 さらに、IoT、AI、ブロックチェーンなどの先端IT技術にも積極的に取り組むほか、SFA、CRMの導入支援やローコードによる開発カスタマイズ、RPA導入支援などのDXサービスなども提供しています。 ECサイト、予約サイト、SNS、ゲーム、メディアなどのWebアプリケーションの開発においても、日本企業との豊富なプロジェクト経験を持っています。 中小規模のオフショア開発会社のメインターゲットは日本市場 日本への留学経験や、日系企業での勤務経験があるITエンジニアが起業した企業が近年増えています。従業員規模は10~50名と小規模な企業が多いため、日本に拠点がない場合もあります。しかし、経営者は日本への留学経験や日本のビジネス習熟を重視している若手起業家が多く、また日本語での意思疎通が可能な語学力を持っている場合が多いため、経営層とは比較的スムーズにコミュニケーションができるでしょう。 対応する領域は、Webシステムを中心と、会社ごとに得意分野は様々となっております。 日系資本のオフショア開発会社 アウトソーシング事業本体 日本企業からの委託先として、多く利用されています。従業員100名未満の小規模な企業から1,000名規模の企業まであり、それに合わせて顧客の日本企業もベンチャー企業から上場企業までさまざまです。開発会社の成長に従い、開発に必要な体力、経験、知見を培い、日本企業の細かなニーズにも柔軟な対応ができます。コストメリットもあり、SIerを通さずに直接発注する企業も増加しています。 対応する案件も、WebサイトやWebシステム、LP、業務システム、モバイルアプリ、ゲーム、XRなどさまざまな分野があり、得意な言語、契約形態、経営スタイルなどの選択肢があります。 大手SIerの海外開発拠点 日本の大手SIerの海外拠点で、メインターゲットも日本企業です。日本人スタッフも多く、日本語のコミュニケーションも可能でビジネス環境にも精通しており、大型案件や長期プロジェクトも安心して委託できます。 欧米資本のオフショア開発会社 アウトソーシング事業本体 主なターゲット市場は欧米で、日本法人がない場合が多く、コミュニケーションは英語及び資本系列の母国語になります。文化的にも、相手を察したり空気を読むといった、非言語的なコミュニケーションスタイルは通用しません。また、日本語によるコミュニケーションも期待できません。取引通貨は主にドル建てとなります。 オフショア開発会社選びでよくある失敗と対策 予想よりも工数がかかった 労働時間や技術者のレベルについて、委託元と委託先の意識や意見にズレがあることが原因です。対策には契約締結時に内容を細かく確認することや、プロジェクトを理解するためのコミュニケーション、こまめな進捗管理などが必要です。 仕様が依頼と異なる 仕様書の文言の解釈の違いが原因ですが、これも、委託元と委託先の意識や意見のズレに起因しています。上記と同じように、対策には契約時の確認やコミュニケーション、進捗管理などが必要です。 不具合が発生した、品質が基準を満たしていない テスト不足が原因ですので、テストの回数や内容、対応についても細かく決めておきましょう。 UIやデザインが不満 デザインやUIについては、日本人と委託先の国の感覚が異なることや、思い込みによるすれ違いが原因であることが多いです。事前に細かく打ち合わせし、すり合わせましょう。 委託するオフショア開発会社の選択 委託先を決めるには、どのように情報を収集し、どこをポイントに選べばいいのでしょうか。 オフショア開発会社の情報の集め方 オフショア開発会社の情報は次のようなところから集めます。 企業のコーポレートサイト、サービスサイト 委託先の比較サイト IT関係の展示会やイベント 知人からの口コミ […]

31/01/2023

3 minutes

オフショア開発とニアショア開発の違いとは？それぞれのメリット・デメリットと活用のポイント

世界的な労働力不足や人件費高騰が見込まれるなか、その傾向は日本においても例外ではありません。国内の幅広い業種で人手不足感が強まっています。さらに、新型コロナウイルスの感染拡大を受け、各企業はDX（デジタルトランスフォーメーション）化を急いでおり、IT人材の需要は高まっています。そのため、IT技術者の求人倍率は急伸し、ほかの職種と比べて転職後の賃金も上昇しています。 IT人材不足と人件費高騰という2つの問題を抱えていることから、システム開発には外部リソースを活用せざるを得ません。そのような状況において、解決策のひとつとして、オフショアやニアショアの活用が進んでいます。 海外人材を活用するオフショアと国内人材を活用するニアショアは、業務をアウトソーシングするというところは同じです。しかし、実際に活用する場面では、さまざまな違いがあります。そこで本記事では、オフショアとニアショアの概要、またそのメリット・デメリットや活用ポイントについて紹介します。 オフショア開発とは オフショア（offshore）とは、もともと「海外の」「岸から離れた」「外国に移す」という意味で、業務を海外に委託、アウトソーシングすることです。特にシステムの開発や保守運用などの業務を委託するときは、「オフショア開発（offshore development）」と言われます。 委託先は海外のシステム開発ベンダーや海外現地法人などで、ベトナムやインド、フィリピン、中国などにある企業への委託が多くなっています。 オフショア開発の目的 オフショア開発が増えている理由は、次のような目的があるからです。 国内では不足しているIT人材の確保 海外ではエンジニアへの教育に力を入れている国も多く、IT人材を豊富に確保することができます。 人的コストの削減 日本よりも人件費（エンジニアの給料）が安い国に委託すれば、大きなコスト削減につながります。ただし、人件費の安い国がどの国なのかを調べておく必要があります。例えば、かつて中国は人気のオフショア開発の委託先国でしたが、現在の中国の人件費は高騰しており、日本と同程度か、上海など地域によっては日本よりも高額になっており、かつてのようなコスト削減効果は薄れています。 詳しくは、別の記事【2022年最新】オフショア開発の人月単価相場動向、人気のベトナムほか国別比較を参考にしてください。 現地市場への参入の足がかり 他国の市場に自社のソフトウェアを投入するためには、ある程度のローカライズが必要です。現地のエンジニアに委託すれば、その地域の事情に合わせて、適切なローカライズができます。 オフショアはどんな分野で利用されているのか オフショアは特にIT分野で多く利用されていて、委託する内容はさまざまです。 ソフトウェア開発 Webシステム開発 ソフトウェアやシステムのローカライズ システムの保守運用 また、人的リソースが大量に必要な業務もよく委託されています。 コールセンター データ入力 画像編集 オフショア開発のメリット 海外に業務を委託することには、次のようなメリットがあります。 大きなコスト削減が可能 人件費の安い国を選べば、大きなコスト削減が可能です。当然ですが、人件費の高い国を選ぶと逆に高いコストがかかります。 技術力の高いIT人材を確保できる 海外ではIT人材の量も質も豊富です。特にAIやディープラーニングなどの最新技術に対応できるIT人材は、日本では不足していますが、海外では見つけやすいのです。 人的リソースが大量に必要な業務にも対応できる 人材が豊富なので、大規模開発やコールセンター、データ入力など、大量の労働力が必要な業務も委託しやすいです。 契約形態をいろいろ選べる オフショア開発の場合、その契約形態は、請負型開発（請負契約）、ラボ型開発（準委任契約）、BOT方式などがあり、コストや業務内容に合わせて選べます。契約形態については、別の記事「オフショア開発会社はどうやって選ぶ？選び方とそのポイント・注意点」を参考にしてください。 オフショア開発のデメリット オフショア開発には次のようなデメリットもあります。 遠隔では管理が難しい 海外への委託でも、業務の管理は日本の委託元から行います。そのため、トラブルが起きても対応が遅れがちです。日本のビジネスに慣れた現場責任者の育成にも時間がかかるため、業務がスムーズに進まないことも多くなります。 品質に対する意識の差がある セキュリティや品質に対する意識は、国ごとに違いが出やすいものです。日本のやり方に慣れた開発会社でなければ、開発中のセキュリティ対策や品質管理でトラブルが発生しやすくなります。 コミュニケーションが難しい 海外の開発会社やエンジニアとは、言語、文化、商習慣、時差、スケジュール感覚など、細かなところで違いがあります。時差が大きいとオンラインミーティングもしにくく、トラブルの原因になりがちです。そこで、開発会社のマネージャーや、委託先と委託元の間に入ってくれるブリッジSEの役割が重要です。 カントリーリスクがある 国によっては、為替変動、国際情勢、国内情勢などの影響により、プロジェクトが途中で終了するリスクもあります。 ニアショア開発とは ニアショア（nearshore）とは、海外ではなく、国内の地方企業に業務を委託することです。システム開発の場合は「ニアショア開発（nearshore development）」と言います。海外に委託する「オフショア」よりも近いので、「ニアショア」と呼ばれています。 ニアショア開発の目的 ニアショアも、オフショア同様にコスト削減を目的としています。東京よりも地方の方が人件費や固定費が安いため、地方に業務を委託してコスト削減しているのです。 ニアショアはどんな分野で利用されているのか ニアショアでは日本全国、さまざまな地方にシステム開発を委託しています。また、地域の特色を生かしたニアショアもあります。 沖縄 コールセンター、BPO（業務プロセスの委託）センターが多い […]

31/01/2023

3 minutes

ラボ型開発（ラボ契約・ODC）とは？請負契約との違いメリット・デメリット

アプリケーションなどのソフトウェアを開発するにあたり、自社内で開発する内製と、自社以外の企業に開発を依頼する外製の2つの開発初方法があります。 内製では、自社の技術開発力の向上につながるというメリットがある反面、専門知識を保有する技術力の高い社員のエンジニアの存在が不可欠であり、またプロジェクトの遅延やシステム完成後もエンジニアの維持確保が必要になるというデメリットもあります。そのため、専門性の高い部分を全て外部に委託することができ、プロジェクトの遅延も発生しにくい外製によるソフトウェア開発を行う企業が多くあります。 昨今では、そうした開発リソースを、国外の外国人エンジニアの活用によって確保するオフショア開発が盛んに行われています。今回は、オフショア開発のなかでもラボ型開発と呼ばれる形態について、その概要やメリット・デメリット、ラボ型開発に向いている案件について解説します。 ラボ型開発（ラボ契約・ODC）とは ラボ型開発とは、海外のリソースや企業を活用して開発する「オフショア開発」の一種で、「ラボ契約」「オフショア開発センター（ODC）」と呼ばれることもあります。ラボ型開発はオフショア開発における契約形態のひとつで、近年は請負契約よりもラボ型開発を含む準委任契約が多い傾向にあります。 請負契約 仕事の完成までを請け負う契約。発注者は要件を明確に定義し、ベンダーは作成された仕様書に沿って設計・開発から実装・テストまでを行い、期日までに成果物を納めるというもの。 準委任契約 特定の業務を遂行することを定めた契約。請負契約とは異なり、成果物の完成の有無は問わない。準委任契約は、さらにラボ契約とSES契約に分けられる。 SES契約 エンジニアを発注元に常駐させる。ラボ型開発同様、エンジニアチームを組んでプロジェクトを進めていく。より流動的な案件や、エンジニアを教育したい場合などに用いられる。 B-O-T方式 現地オフショア会社が人材リソースを確保し安定運用後にチームを丸ごと買い取る方式。Build（設立）、Operate（運営）、Transfer（委譲）を略した言葉。 請負契約では、ベンダーが納品した成果物に対して報酬が支払われます。一方で準委任契約ではベンダーが行う労働そのものに対して報酬が支払われるため、請負契約とは異なりプロジェクトの内容や進捗状況に応じて柔軟な変更が可能です。 近年では、ラボ契約とSES契約の両方を活用する「ハイブリッド型」の契約形態をとることも多く見られます。例えば、プロジェクトのキックオフから1〜2ヵ月間はSES契約で業務に慣れてもらい、その後帰国してラボ契約で働いてもらったり、人数を減らしたりするといったケースです。 オフショア開発について、詳しくは以下の記事で紹介しています。 【別記事】オフショア開発とは｜メリット・デメリット・成功に導く6つのポイント ラボ型開発と準委任契約の違い ラボ型開発（ラボ契約）は準委任契約の形態のひとつです。システム開発における委託契約は前述の「請負契約」または「準委任契約」によってなされますが、請負契約が成果物の完成を目的とするのに対し、準委任契約は労働の代行を目的としている点が異なります。単純に「準委任契約」と言う場合はシステム開発以外にも使われ、準委任契約のなかのシステム開発における形態がラボ型開発ということになります。 ラボ型開発（ラボ契約・ODC）のメリット ラボ型開発には、以下のようなメリットがあります。 一定期間、専属開発チームとしてメンバー固定でエンジニアを確保できる ラボ型開発では期間を決めて契約するため、期間内であれば継続的に案件の発注が可能です。期間内にいくつか連続して案件が入る場合でも、案件ごとにチームを組み直したり、一から情報共有をしたりする手間が省けます。 近年、東南アジア諸国のエンジニアは日本国内のエンジニアと遜色ないか、よりハイスキルなことも少なくないため、優秀な人材を中～長期間にわたり確保できます。 中～長期間腰を据えて案件に取り組むことで、ラボ型開発の委託先が発注側の業務体制や企業風土に慣れることができ、安定的に開発できるのも大きなメリットです。優秀な人材リソースを安定的に確保して開発できれば、機能を拡張しバグを改修する作業や業務を進めるための時間的リソースも確保しやすくなります。それにより、エンジニアも高いクオリティの成果物をスピーディーに納品することが可能になります。 自社内に開発経験やノウハウを蓄積できる ラボ型開発では、同じエンジニアメンバーと一定期間協働するため、自社内に開発ノウハウが蓄積しやすいのも大きなメリットです。ノウハウが蓄積できれば、別の案件でも開発スピードが改善されたり、チーム間で円滑なコミュニケーションがとれたりと、さまざまな良い影響が考えられます。ノウハウ蓄積も目的に組み込む場合、その分野に特化した企業とラボ型開発を行うのもひとつの方法です。 要件がはっきり定まっていないプロジェクトでも取り組むことができる ラボ型開発では、請負契約と異なり成果物が明確に決まっているとは限らず、途中で仕様変更をしたり、各種調整したりすることも容易です。企画や施策が確定していない状態でも、協働しながら進めていけるでしょう。請負契約のように、仕様変更や調整について追加費用が発生することもなく、契約期間内なら自由にリソースを使えます。 例えば、ラボ型契約で5名のエンジニアに開発を依頼した場合、最初の4カ月は全員に新規のアプリケーション開発を依頼し、その後の2カ月は3名が追加機能の実装を担当し、2人に細かいバグ対応や改善を担当するなど、フェーズや状況に応じて臨機応変かつ柔軟にチームを動かすことができます。 ラボ型開発（ラボ契約・ODC）のデメリット ラボ型開発には、以下のようなデメリットがあります。 開発チームの立ち上げや維持にコストがかかる ラボ型開発は一定期間専属のチームを確保できる契約なので、一定量の発注を続けられる場合はコストパフォーマンスが良いです。一方、契約期間内はコストが発生し続けるため、依頼する案件の業務や作業量が極端に少ない場合に予定よりも早く開発が完了しても、その後に依頼する案件がない期間があるとその分は余計なコストとなり、請負契約よりもコストが高くなってしまう可能性があります。特に、単発の案件や短期の案件の場合は割高になってしまう可能性があり、チームを中長期に渡って押さえておくメリットが得られにくいでしょう。 契約期間中は人材リソースを無駄にしないように、一定の業務量を発注できる準備を行っておくとよいでしょう。少なくとも3カ月以上の開発が必要となる案件か、複数の単発・短期の案件を準備しておき、リソースを余らせないようにするのがおすすめです。 発注者が主体的にマネジメントする必要がある 開発をスムーズに進めるためには、チーム構築のほかに体制作りが必要です。特に、ラボ型開発では請負契約のようにすべてを発注先に任せられるわけではなく、チームとして協働する形態となるので、コミュニケーションが特に重要になります。このように、発注元が主体的にチームビルディングやマネジメントをする必要があることから、発注元の負担は請負契約と比べると大きくなります。 特にオフショア開発では、日本語が堪能な委託先に依頼できるとは限りません。国内に日本法人や支社があるオフショア開発会社を選んだり、開発技術だけでなくコミュニケーション言語の能力も含めて人選したりして、コミュニケーションに齟齬（そご）が生まれないような体制作りが必要です。 チームビルディングに時間がかかる ラボ型開発では、初めにチームを構築します。チームメンバーを選ぶ際には、単純にスキルが高い人材を集めればよいとは限らず、開発内容や自社の文化などさまざまな要素を考慮し、開発内容に合っていて相性の良い人材を慎重に選んでチームを構築する必要があります。 また、チーム構築から実際に開発に入るまでは一般的に半月～3カ月程度の期間が必要なため、その期間も考慮しなくてはなりません。 また、ラボ型開発では、発注元がチームの一員となって開発を指示する必要があります。成果物の仕様にズレが生じないようチェックしたり、メンバーに体制や企業風土についてレクチャーしたりすることもあるでしょう。チーム結成後の滑り出しがうまくいくとは限らず、チームとしての機能が軌道に乗るまではある程度時間がかかることを念頭に置きましょう。 ラボ型開発（ラボ契約・ODC）が向いている案件 ラボ型開発は、以下のような案件に向いています。 定期的に発生する案件がある 業務委託したい案件が定期的に発生するのであれば、ラボ型開発がおすすめです。特に、既存のアプリやサービスの運用・改修をする場合に向いているでしょう。契約期間中は自社専属の開発チームを確保でき、案件が変わるごとにチームを再構築したり、一から情報共有したりする必要がありません。 そのため、開発案件が途切れず発生するけれど人員が足りないという場合にラボ型開発を利用すれば、案件ごとに依頼先を探したりすり合わせをしたりする手間がかからず、コストやストレスの軽減につながるでしょう。 仕様変更や修正が生じる可能性がある ラボ型開発は契約期間内であれば追加費用なしで対応してもらえるので、完成形がはっきり決まっていない案件や、仕様の追加や変更が生じやすい案件に向いています。請負型に比べてコストが抑えられるだけでなく、中～長期にわたって同じチームで作業していくので、指示を的確に理解して適切に作業してもらいやすいでしょう。 また、AI等の先端技術を用いたIT開発や、完成形が定まりにくい研究開発の要素を含むという場合にもラボ型開発は向いています。 アジャイル型開発の案件である システムやアプリの開発には、大きく分けてウォーターフォール型とアジャイル型の2つの開発体制があります。 ウォーターフォール型 開発の最初の段階で要件や仕様を詳しく決定し、すべて完成してからリリースする。 アジャイル型 […]

23/12/2022

3 minutes

ノーコード開発で何ができる？どんな用途に向いているのか理解しよう

ノーコード開発は、今注目されている開発手法です。ノーコードツールを使えば、高い専門知識を持つIT人材でなくてもアプリケーションやWebサイトを開発でき、コストも開発期間も抑えられます。IT人材の不足が大きな問題になっているなかで、新たにIT人材を雇用したり育成したりしなくてよいのは大きなメリットです。 しかし、ノーコード開発はコーディングしないため拡張性や汎用性が低く、できることには限界があります。今回はノーコード開発の概要と、できることとできないことを説明します。 ノーコード開発とは ノーコード開発とは、コーディングせずにシステムやサービスを開発すること、またはその開発環境のことです。開発環境はノーコードツールとも呼ばれます。コーディングは一般的にプログラミングとも呼ばれるもので、プログラミング言語を用いてプログラムを書くことです。 ノーコード開発ではコーディングが不要なので、高度なスキルや知識がない、非IT人材でも開発できます。そのため、ユーザーが現場で必要なアプリケーションを開発でき、現場のニーズに合わせた開発が可能です。システム開発の担当者との打ち合わせも不要なので、開発時間を短縮できます。 そのため、ノーコード開発はIT人材不足を補い、デジタイゼーションを進め、DXを推進する方法のひとつとして期待されているのです。 ノーコード開発では、コーディングの代わりにツール上で用意されたコンポーネントと呼ばれる部品を組み合わせて開発します。コンポーネントを使うため、必要なものを素早く開発することが可能です。 ただし、コンポーネントのないものは作れないので、自由度は低く、オリジナル部分の多い開発や大規模開発には向きません。また、コーディングの余地がないため、カスタマイズや拡張も不得意です。 ローコード開発との違い ノーコード開発と似たものに、ローコード開発があります。ローコード開発とは、ほとんどの部分をノーコードで開発できるものの最小限のコーディングが必要な開発手法や、その開発環境のことです。コーディングするため、ノーコード開発よりも高い汎用性や拡張性があります。 一方でノーコード開発はソースコードの記述をせずに開発でき、開発に高いスキルは不要です。ただし、コードが使えないため、細かな部分での修正や調整ができません。また、ノーコード開発は開発ツールによってできることが変わります。 従来のように「すべての部分をコーディングで作成する」場合はフルコード開発と言います。最も難易度が高く、専門的なスキルが必要ですが、自由度や拡張性も高い方法です。 ローコード開発や、IT人材不足との関係については、次の記事を参考にしてください。 「ローコード開発とは？ IT人材不足解消の切り札として注目される新しい手法」 ノーコード開発、ローコード開発、フルコード開発の違い   ノーコード開発 ローコード開発 フルコード開発 コーディング 不要 少し必要 必要 スキル 高いスキルは不要 高いスキルは不要だが、ある程度のスキルは必要 高いスキルが必要 拡張性、自由度 低い コーディングにより確保可能 高い拡張性と自由度がある 開発期間 短い 短い 長い ノーコード開発が向いている場合 ノーコード開発は次のような場合に向いています。 スモールビジネスを行う個人である場合ネットショップ運営やアプリ制作などのスモールビジネスに使えます。また、ほかの業種でも、スモールビジネスを行う個人が必要なアプリケーションを制作することも可能です。 小規模なソフトウェアベンダーである場合小規模アプリの開発を行うベンダーで開発環境として使えます。 スタートアップ・ベンチャーである場合開発期間を短縮し、効率的に事業を始められます。 部署内で小さなアプリケーションが必要な場合情報システム部門に頼らず、短期間で欲しいアプリケーションを制作できます。その他、開発コストを抑え、短期間でサービスをリリースしたい場合に向いています。 ノーコード開発でできることとできないこと その性質上、ノーコード開発にはできないことがあります。特徴と限界を理解して使いましょう。 ノーコード開発でできること Webページ制作企業・団体のWebサイト、商品のサービスサイト、ECサイトなど。 Webアプリ制作フロントエンド、バックエンド、データベースといったWebベースのアプリケーション。 業務の自動化・効率化のための小さなアプリケーション制作日常的な業務を効率化する小規模なアプリ、単機能に特化したアプリ、データ管理アプリなど。 モバイルアプリ制作業務に利用するスマートフォンアプリ。 ノーコード開発でできないこと ノーコード開発では、次のようなシステム開発はできません。 大規模で複雑なシステム開発拡張性や自由度が低いので、複雑なシステム開発には向いていません。 独自部分の多いシステム開発ツールに装備されているコンポーネントを使って開発するため、独自部分の多い開発はできません。 ツールの対象となっていない分野の開発ノーコードツールにはそれぞれ対象とする分野があります。 ゲームのように表示速度が重要なシステムの開発ノーコードで開発した場合、ページの読み込み速度が遅くなる傾向にあります。 […]

15/12/2022

3 minutes

ローコード開発とはIT人材不足解消の切り札として注目される新しい手法

ローコード開発は、基本的にはコンポーネントの組み合わせですが、ある程度のコーディングが可能な開発手法です。ノーコード開発とは異なりコーディングできるため、外部との連携といった拡張性や自由度もあります。ただし、ツールによってできることには制限があります。