オフショア開発、ブリッジエンジニア、理由

オフショア開発ブリッジエンジニアが重要な3つの理由

10 View

はい、こんにちはオフラボの花井です

今回はオフショア開発のブリッジエンジニアについて説明をしていきます。よろしくお願いします。

オフショア開発アカデミーのご案内

オフショア開発について体系的に学べる情報サイト【オフショア開発アカデミー】では、オフショア開発の全体像やポイントを無料で学ぶ事ができます。

ご興味がある方はこちら

https://offshore-dev.com/ 

 

ブリッジエンジニアとは

ブリッジエンジニアとは日本側の企業とベトナム側の開発チームを繋ぐ間のポジションのことを言います。

日本人のお客様の希望の要件を聞いて、システムが開発できるように開発者に伝えることやシステム開発に関する情報をお客様に伝えると言うと想像しやすいかもしれません。

そのため、様々な情報が集中するため、オフショア開発では重要なポジションになります。

ブリッジエンジニアの業務

ブリッジエンジニアは様々な業務があります。ブリッジエンジニアと一言と言っても色々なタイプがありますので、なかなか「ブリッジエンジニアの業務はこれです」と言いづらいです。

日本のお客様の希望やサービスやシステムの内容をやりとりします。
そのため多くの情報を受け取り、整理し、開発ができる状態にすることが主な業務になります。
具体的には開発要件・開発ドキュメントの作成、スケジュール作成、開発者のアサインなどを行います。

開発要件資料の作成

開発要件とは、どんな機能を作りたいのか、どんなシステムを作りたいかを確認し、正確に開発できるように、機能の詳細やデザインの詳細を作成していきます。

当然、依頼するお客様はシステムを開発するプロではありません。そのため開発したいシステムの内容が機能が不十分だったり情報が抜けている場合があります。

そのため、開発要件を作るためには、お客様から内容を聞くだけでなく、修正しながら開発要件を作っていきます。

この場面でブリッジエンジニアのスキルが足りず、システムの機能が不十分になると、システムが動かなくなることもありますので、かなり重要な仕事です。

そして、システム開発とは家を建てていくようなものです。
お客様の要望を聞いて、サービスを理解し、将来どのようなユーザーがシステムを使うか、どのような機能が追加される可能性があるか、反対にサービスの性質上システムにしないほうが良い機能はないか(人的な対応が得意な部分)、機能がオーバースペックにならないか

現在のお客様の希望を聞いて、サービスの本質を理解し、何年も先のシステムの状況やユーザーを想像しながら開発要件を作っていきます。

システム開発の難しく、面白い部分でもありますが、お客様のサービスを理解しないと良いシステム開発は提供できません。
前述したようにシステム開発は家を建てていくようなものです。
後から「こんな機能は想定していなかった」、「こんな使い方は想定していなかった」などで、追加開発ができない、または大幅な費用が必要になることを避けなければなりません。

開発ドキュメントの作成

開発要件から開発ドキュメントと言われる開発の詳細要件を作ります。

例えば動作の定義やページ構成、データベースやテスト、サーバーの構成や性能を記載し詳細を作っていきます。

この開発ドキュメントを使って、開発者が開発ドキュメントの情報通りに開発していきます。

そのため、かなり正確な開発ドキュメントを作る必要があります。

開発ドキュメントが正確であれば、要件を満たしたシステムを開発する事が出来る可能性は高くなります。

しかし、もし開発ドキュメントが不十分だったりすると、開発をやり直すことも発生する可能性があります。

重要な業務の一つです。

開発スケジュールの作成

完成した開発ドキュメントに合わせてスケジュールを作っていきます。

開発期間や開発する順番など、実際に開発する手順通りにスケジュールを作成します。

開発者チームの構成

開発スケジュールが完成後、スキルや経験に合わせて開発者を任命していきます。

いわゆる上流過程と言われる部分をこの部分をブリッジエンジニアが担います。そのためブリッジエンジニアの質によって大きくシステムの品質が変わります。

ブリッジエンジニアのスキルが低いと何が起こるのか

ではブリッジエンジニアのスキルが低いとどのような事が起こるのでしょうか?

ブリッジエンジニアのスキルが低い場合に発生する内容を説明していきます。

技術的負債ができる

開発スケジュールや開発機能の理解が曖昧である場合には、技術的な負債が発生する可能性が高くなります。

技術的な負債が大きくなると、機能追加にかなり工数が余分にかかるようになります。そのため、既存の機能を変更する場合、その以前に作った機能が邪魔をして変更が難しい状況が発生します。

そのため、技術的負債が多くなるほど、費用が高くなることや開発期間が長くなります。

技術的な負債を大きくしないためにも、最初からプロジェクトの内容や開発に深く精通したブリッジエンジニアが関わる必要があります。

ブリッジエンジニアがプロジェクトやサービス、システムのスキルや理解度が大きく影響します。

開発機能の作り直し

開発要件と開発ドキュメントを作る時に誤解が生じてしまったり、開発要件にシステムの機能が欠けているなどの場合に作り直しが発生します。

例えばページを作って、そのページのデザインが少し指示と違うなど、そのようなレベルの話ではなくて、ごっそり機能自体がうまく動かないなどのレベルの作り直しになります。

ブリッジエンジニアが関わる上流過程での不備は大きな範囲で影響が出てしまいます。

大幅な作り直しが発生するとスケジュール遅延や追加の費用がかかる事が発生しますので、影響が大きいと言えます。

無駄な工数の発生

最後に無駄な工数が発生することです。
前述した内容と同じ部分もありますが、誤解が生じたり、作り直しが発生したり、サービスを理解していなことで、無駄な機能を作ることや追加機能時に技術的な負債が負担になります。

そして、それは少なからずお客様にスケジュール遅延や追加費用という形で影響します。

ブリッジエンジニアがプロジェクトに大きな影響があることはわかっていただけたと思います。

ではどのようにブリッジエンジニアやオフショア開発会社を選べば良いのでしょうか?

ブリッジエンジニアの開発チームの分類

ブリッジエンジニアがどのようなスキルと持っていて、日本人もしくはベトナム人のどちらかが担当するかによって、特徴や難易度が変わります。
以下、パターンに分けて説明していきます。


①日本人ブリッジエンジニア×ベトナム人通訳パターン

もっともオフショア開発が成功しやすいパターンです。
オフラボでサポートしてるのはこのパターンです。

日本人のブリッジエンジニアが全て開発要件や開発ドキュメントを作り、それをベトナム人通訳がベトナム人の開発に伝える開発チームのパターンです。

日本人ブリッジエンジニアは開発者ですから、システム開発を熟知しています。
お客様と日本語で話をするためシステムに関する誤解も多くありません。

プロジェクトやサービスの理解をしやすく、このパターンでは質の高いシステム開発ができる可能性が高いです。

反面、日本人ブリッジエンジニアの費用は高いです。
このパターンの中で一番費用がかかりやすいオフショア開発だと言えます。

それでも日本国内のシステム開発会社と比べて2/3程度のシステム開発費用にすることができます。

②日本人営業担当×ベトナム人ブリッジエンジニアのパターン

これは結構失敗しやすいパターンと言えます。

なぜなら、日本人営業担当は開発者ではありません。
そのため、要件定義に不備ができる可能性が高くなります。

もちろん、日本人営業担当が要件定義を作成するのではなく、ベトナム人ブリッジエンジニアが要件定義を作成します。

しかし、前述したように要件定義はサービスの本質を理解し、何年も先のシステムの状況やユーザーを想像しながら作る事が必要です。

どうしても日本人ブリッジエンジニアと比べて、品質が劣ってしまいます。

これはベトナム人ブリッジエンジニアのスキルが低い事が原因ではありません、
日本人がベトナム人向けのサービスを作る事が難しいように、ベトナム人にとっても日本向けのサービスを作ることは、かなりのスキルが必要になります。

このことから日本人営業担当がベトナム人と相談の上、開発要件を作ったとしても、品質として劣ってしまいます。

良い点として日本人ブリッジエンジニア×ベトナム人通訳パターンに比べ費用は安くなります。
そのため、要件定義を作成しないような開発方法、例えばお客様の社内に自社開発チームがあって開発タスクを指示できるような、いわゆる下流過程のみを行う開発であれば、失敗は避ける事ができるでしょう。

③ベトナム人ブリッジエンジニア×ベトナム通訳

このオフショア開発のパターンは、ほとんどが失敗します。

なぜなら、前述した要件定義の不備に加え、日本語の誤解が発生しやすいこと、また日本のシステム開発の品質に達していないことがほとんどです。

日本人が開発チームにいない、または常駐していない場合はシステム開発の機能に誤解が発生しても気がつく事が遅くなることや、そもそも日本企業に納品するシステム品質とベトナム人のシステム開発の品質に大きな差があることを理解していないです。

特に大きな差となるのは、スケジュール管理とシステムのテストになります。

ブリッジエンジニアと関係ないように見えるかもしれませんが、お客様の希望したシステムを正確に作る視点が抜けているため、日本人が開発チームに常駐していません。

このパターンで成功したオフショア開発を見たことはありません。

しかし、このパターンは一番安いです。
そのため、要件定義とデザインが確定しているウェブサイト制作にとどめておくべきでしょう。
そうだとしても、管理コストや作り直しの面からお勧めできません。

まとめ

では、今回はベトナムオフショア開発のブリッジエンジニアについて説明をしていきました。今回の記事で説明したようにブリッジエンジニアはプロジェクトの成功に大きく影響する重要なポジションになります。
オフショア開発を利用する前にチェックをしてください。

今回に説明したブリッジエンジニアをプロジェクトごとまたは月額でサポートしているサービスを提供しています。

ご興味がある方は以下をチェックしてみてください。

では、今回はこれで終わります

関連記事

【オフショア開発失敗事例紹介】 決済サービスの申請トラブル

2022/11/28 オフショア開発の基本 詳しく

【オフショア開発失敗事例】決済システムの申請トラブル

2022/11/24 オフショア開発の基本 詳しく

【オフショア開発失敗事例紹介】テスト後の修正を拒否された事例

2022/11/23 オフショア開発の基本 詳しく

【オフショア開発失敗事例】タスク管理トラブル

2022/11/23 オフショア開発の基本 詳しく

【オフショア開発失敗事例】日本語での情報共有の誤解

2022/11/22 オフショア開発の基本 詳しく