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

失敗事例から学ぶ、オフショア開発成功への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. 仕様変更と品質レベルに関する考え方の違いを意識する 日本では、度重なる仕様変更が生じても、それに対応することが当然であると考えられがちです。一方、オフショア開発では、契約締結後に仕様変更を行うことは一般的とは言えません。そのため、仕様変更を巡ってはトラブルが発生する可能性があります。 […]

ラボ型開発（ラボ契約・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つの開発体制があります。 ウォーターフォール型 開発の最初の段階で要件や仕様を詳しく決定し、すべて完成してからリリースする。 アジャイル型 […]

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

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

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

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

Salesforceのカスタマイズや開発を行うにはオフショア開発が安心

Salesforceは、自社に合わせてカスタマイズして導入する必要があります。また、Salesforceを利用してシステムやアプリを開発することも可能です。カスタマイズやシステム開発にはスキルやノウハウが必要なので、ベンダーを利用したオフショア開発をおすすめします。

【2022年最新】オフショア開発の人月単価相場動向、人気のベトナムほか国別比較

オフショア開発で最適な国を決定するときには、コスト、言語、文化、時差（タイムゾーン）、信頼性など考慮すべき要素がいくつかあります。詳しくは『オフショア開発とは｜メリット・デメリット・成功に導く6つのポイント』でも紹介していますのでご覧ください。本記事では、オフショア開発に最適な国を知る上で重要となる、各国の人月単価と国ごとの特徴について紹介します。 オフショア開発国のITエンジニアの人月単価相場 ITエンジニアにかかるひと月あたりの人件費を人月単価と言います。人月単価は、コスト削減を目的としたオフショア開発で最適な国を決定する際の1つの尺度となります。昨今の日本国内のITエンジニアの平均人月単価の相場が80~100万円前後と言われています。 それでは、オフショア開発委託先の国の人月単価相場はどの程度低いのでしょうか。人月単価相場は、それぞれの国の物価や人件費、ITエンジニアの技術力の差などによって異なります。以下の表は、株式会社Resorz（オフショア開発.com）が発表した『オフショア開発白書 2022年版』によるオフショア開発委託先の国のITエンジニアの人月単価相場を元に当社が作成したものです。 日本企業のオフショア開発の聡明期から委託先として主流だった中国とインドは、他国に比べて人月単価相場が高めになっています。また、中国とインドのブリッジSEの相場が昨年から高騰しており、日本との人件費の差がかなり縮まって相場的にはコスト削減効果は薄れています。なお、最新の北京や上海のSEの人月単価は下記の表よりも大幅に値上昇して「日中逆転現象」も発生しています。 一方、ベトナム、バングラディッシュ、ミャンマーなどの東南アジアの国々の相場は、日本の相場と比較してもまだ魅力的な人月単価相場となっています。 特に、ベトナムは、ITエンジニアのレベルが高い人材が多い上に、人月単価相場は急騰することもなく安定的に推移しており大変魅力的な国となっています。 また、バングラディッシュでは、PG、SE、ブリッジSEの相場が急騰しており、今後が気になるところです。 ITエンジニアの人月単価相場は、必要とされるリソースの需要と供給のバランスによって左右されるほか、各国の経済状況や雇用状況、為替変動などの影響により変動します。円安・円高などの為替変動によるリスクを回避するために、円建ての取引きやその他の為替リスクヘッジ対策を行うことも重要です。 オフショア開発で人気の各国の特徴と国内事情 ベトナム ベトナムは、日本のIT企業に人気No.1のオフショア開発国です。ベトナムは古くから日本が政府開発援助（ODA）などで支援をしていたこともあり、親日派が多いことで知られています。また日本の電機メーカーや自動車メーカーや二輪メーカーが多く進出しており、身近に日本を想起させるものが多いことも日本への親近感を強くしている理由です。 ベトナムは社会主義国ですが、安定した政治と高い経済成長率を保っています。柔軟で慎重な金融政策により、消費者物価指数は年率4%未満を維持しており、世界でも急速に経済成長を遂げている国のひとつです。 IT政策の面では約300の大学と専門学校でICTトレーニングを提供し、ICT履修生徒数は約55,000人を数えるなど、インダストリー4.0向けのデジタル人材を国家戦略として積極的に育成しています。充実したICT教育により、高度なスキルとモチベーションの高い豊富なIT人材プールを保有しています。IT人月単価は中国、インドよりも安く、バングラデシュ、ミャンマーよりはやや高めです。 中国 オフショア開発の黎明期に人気No.1だったのが中国です。中国は文化大革命後に驚異的な経済発展を遂げ、今やGDPでは日本を抜き世界第2位となりました。政情は中国共産党一党独裁であり、国の事情に応じて規制がすぐ変化するのが難点と言えます。これをカントリーリスクと捉え、中国から撤退する外国企業や日本企業も近年は多くなっています。 中国は人口が多く、IT人材も豊富で高度な技術力を持つ優秀なITエンジニアがいることが特徴です。一方、人月単価は相対的に高騰しており、直近では日米逆転現象も起こっているケースが見られます。また、転職を繰り返すジョブホッパーが多いので、人材の入れ替わりが激しいことは覚悟しておく必要があります。 インド インドは中国と並び、昔からオフショア開発が盛んな国です。中国と同様に人口が多くIT人材も豊富で、高度な技術力を持つ優秀なITエンジニアがいることが特徴です。なお、未だにカースト制度の影響が残っているため高度な教育を受けられる人は限られています。 日本とは友好関係にあり、円借款によりインド国内では上下水道の整備や鉄道の拡充などが行われています。インドのオフショア開発は欧米企業との取引が多く、コミュニケーションは英語が中心です。IT人月単価は相対的に高めです。 フィリピン フィリピンもオフショア開発では人気の高い国です。フィリピンには、以前から日本が積極的に経済援助しているため両国の関係は良好です。日本企業も多く進出しており、ソフトウェアを中心としたIT人材も比較的多いと言えるでしょう。 ただし、フィリピンは近年こそ政情的に安定はしていますが、治安には問題があります。犯罪率は年々減少しているものの、強盗や殺人などの重大犯罪が多く、赴任や出張などの際にはセキュリティに注意が必要です。コミュニケーションは英語が中心です。IT人月単価はベトナムと同程度で、バングラデシュやミャンマーよりもやや高めです。 バングラデシュ 人件費によるメリットと年21％のICT市場の年間平均成長率（バングラデシュICT省2019資料より）を背景に、近年ポストベトナムと呼ばれるほど注目を集めてたのがバングラデシュです。バングラデシュは全方位外交を進める国であり、近隣のインドをはじめ、中国、アメリカ、日本などと友好関係にあります。 日本からは政府開発援助として資金提供しており、運輸や電力などのインフラ整備を積極的に行っています。しかし、原材料・部品の現地調達の難しさや通関に時間を要すること、電力不足・停電、従業員の賃金上昇など、まだ不安定な要素が多いことが課題となっています。 国としてはIT立国を目指しており、教育投資の結果、近年はIT人材が急増しています。人月単価はベトナムやフィリピンより安く、ミャンマーより若干高い水準。ただしインターネット環境など、ITのインフラ整備がまだ追いついていなかったり、電力需要が日々増加しており電力需要が発電能力を常に超えているため、しばしば停電を強いられることなどが難点となっています。 ミャンマー 以前から日本はミャンマーに対して多額の政府開発援助を行っており、日本との関係が深い国です。IT系大学のトップレベルの優秀なIT人材でも買い手市場と言われ、人月単価もバングラデシュより若干低い水準で「アジア最後のフロンティア」などと呼ばれて注目を集めた時期もありました。しかし、まだまだ発展途上のためにITインフラが整っておらず、輩出する人材数はそれほど多くなく技術レベルにも差があります。 2021年2月1日に国軍によるクーデターが発生して1年以上を経過しましたが、現在もなお同国は揺れている状態です。これまでに国軍の弾圧により多くの民間人の死者や拘束者が出ており、2022年になった現在も増加しています。クーデターに加えてコロナの影響も加わり経済状況は悪化しています。このような状況下において、進出している日系企業のビジネスへの影響が懸念されています。 オフショア開発委託先の選定は総合的に判断 コスト削減を目的としたオフショア開発では、ITエンジニアの人月単価だけに注目することは危険です。オフショア開発国を選定する際には、優秀な人材やスキルの供給源として長期的な視点で関係性を築いていくことも大切なことです。そういった視点を加味したうえで、IT人材が豊富であることや、人月単価、政情や治安など総合的にバランスがとれているベトナムに人気が集中している点はうなずけます。 また、何よりオフショア開発のプロジェクトを円滑に進められなければ、オーバヘッドにより人件費オーバーになってしまう危険性もあります。オフショア開発の委託先となるパートナーが信頼関係を築くことができる相手なのか、優秀なIT人材が確保できるのか、自社の開発プロセスで必要な工程をアウトソーシングできるのか、言語やコミュニケーションの壁をどのように乗り越えられるのかなど、日本企業とのビジネスが円滑にできるかどうか、実績や経験も踏まえて総合的にチェックしておきましょう。 無料eBookのダウンロード 保存版 オフショア開発入門ガイド2023 オフショア開発を始める前の気になる疑問を解決！オフショア開発を検討中の方に向けて、オフショア開発の基本的な知識から注意点までを解説します。 今すぐダウンロード（無料） 無料eBookのダウンロード チェックリストでわかる 失敗しないオフショア開発会社の選び方 オフショア開発会社選びの準備から開発開始まで、多様な角度からチェックポイントを網羅。チェックリストを活用して効率的な選定や基準作りに役立ちます。 今すぐダウンロード（無料）