オフショア開発子会社の開発組織マネージャーをしているYoshimuraです。
この記事は、オフショア開発のキーパーソン「ブリッジSE」の仕事内容、役割、そして必要なスキルについて詳しく解説します。
この記事は次のような方々に特におすすめです。
・開発を依頼したいクライアントの方：「ブリッジSEに効率よく仕事を依頼したい」
→ ブリッジSEやオフショア開発会社への依頼方法について理解いただけます。
・就職活動中の方：「ブリッジSEに興味がある」「現在SEで転職を考えている」
→ ブリッジSEに求められるスキルレベルを理解いただけます。私自身、2度ブリッジSE職へ応募し、いずれも採用された経験がありますので、ブリッジSEとして求められる姿を具体的にご紹介できると思います。
なお、この記事内では、青色：クライアントの方 赤色：就職活動中の方 で色分けして具体的なご提案を記載します。
ブリッジSEとは？ブリッジSEの役割は？
ブリッジSEとは、「システム開発を行いたいクライアント」と「海外のオフショア開発会社」を繋ぐ役割を果たすSEのことを指します。ブリッジエンジニアやBrSEとも呼ばれます。通常のSEが要件定義や設計を行い、日本語を話すプログラマーにシステム開発を依頼するのに対し、ブリッジSEはさらに海外のエンジニアに依頼する必要があります。
ただし、「単に外国語が話せるプログラマーやSEでは務まらない」ことを理解していただきたいです。以下に示すように、ブリッジSEの役割は通訳だけでなく、様々なギャップを埋める必要があります。これらの役割を果たすことで、まさに「ブリッジ（橋渡し）」の役割を果たすのです。
- 語学力
- IT / SEスキル
- システム仕様（業界・業務・システム・要求仕様）
- 国（商習慣・国民性）
- コミュニケーション力・プレゼン力・信頼
- QCD（プロジェクトマネジメントスキル）
- 計画・スケジュール
なお、ブリッジSEの役割はクライアントやプロジェクトによっても多少変化します。例えば、クライアントが詳細な要件定義を行ってもらえるのであれば、ブリッジSEは伝達だけで済みます。オフショア側で上級エンジニアがいれば、設計をお願いする事ができるかもしれません。
ブリッジSEの仕事内容
当章では、ブリッジSEの仕事内容を３つの業務としてまとめます。
コミュニケーター業務
ブリッジSEは、会議の通訳や議事進行、資料の翻訳、プレゼンテーションなどを行います。
簡単なシステムの場合は、通訳者やコミュニケーターと呼ばれる方々(ブリッジSEと比較すると安価)が翻訳や通訳を行い、システム開発をする事もあります。その場合は、BrSEはSE業務やプロジェクトマネジメント業務を行いません。
クライアントの方は、ブリッジSEの省略できないか検討頂くとよいです。簡単なシステムであれば、翻訳ツールを使いながらチャットツールで開発依頼を行ったり、コミュニケーターに業務を依頼出来ないかご検討ください。できる限り細かい仕様をエンジニアに伝えることも意識されると良いと思います。
もしくは、クライアントメンバー内で語学力とSE力を習得された方がいらっしゃるのであれば、ブリッジSEの代わりとなって、エンジニアリソースだけを調達する方法もご検討ください。(ぜひ弊社にもご相談ください)
就職活動中の方に意識して頂きたいのは、コミュニケーター・外国人ブリッジSEの脅威です。単価の高い日本人ブリッジSEとして成果を出す為には、ちょっと言語が出来る・SEが出来るくらいでは差別化出来ません。詳しくは別記事の章をご参照ください。
SE業務
SE技能を持ったブリッジSEがいれば、先程のコミュニケーター業務の図よりもチーム人数が1人減りましたね。
ブリッジSEはPMと同行して、クライアントとの折衝を行うため、最前線に立つ役割を果たします。「クライアント ⇔ ブリッジSE ⇔ オフショア」の関係で、真ん中の一番重要な立ち位置です。SEと同様に、一連のシステム開発を担い、幅広いシステム開発局面（要件定義、設計、開発依頼、ベンダーコントロール、テスト、リリース）で意思決定を担います。
クライアントの方、就職活動中の方 両方に意識して頂きたいのは、オフショア開発企業はそれぞれ得意な技術や業界が違うという事です。見積り価格・給与だけを確認するのではなく、過去の実績を確認し、どこに依頼するのか・就職するのかで成功率が変わると思います。
例えば、技術で言えば、WEB系、受託開発、アプリ系、組み込み系、インフラ系など様々な分野に別れます。(弊社はアプリからフロント・バックエンドまで小規模・大規模システム問わず対応できる開発体制です。)
プロジェクトマネジメント業務
ブリッジSEがプロジェクト全体の進捗管理を担うことも多いです。開発タスクの采配、プロジェクトのQCD担保、クライアントへの進捗報告などを行います。このように1人で三役こなせるシニアレベルのブリッジSEは経験豊富で、QCDを上げる技を身につけています。
クライアントの方に特に意識頂きたいのは、コストメリットを出す為には開発者の確保人数を上げる必要があるので、自ずとプロジェクトマネジメントが必要となる点です。プロジェクトを安心して任せられる開発会社なのか見極める必要があります。なおコストメリットについて詳しくは別記事の章をご参照ください。
就職活動中の方はぜひこの3つ出来るブリッジSEを目指してください。海外で仕事をした経験や異文化での生活経験は資格試験だけでは測れない「生きた語学力」を証明する事になります。また、SEの方なら上流工程、ベンダー管理、メンバー管理のご経験などあると優遇されます。
ブリッジSEに必要なスキル
当章では、ブリッジSEに必要なスキルをできるだけ細かく記載し、コミュニケーター、SE、プロジェクトマネージメントの３分野にまとめます。
コミュニケータースキル
語学力・異文化理解
コミュニケーター・通訳者で代用する場合もありますが、複雑なシステム開発には、外国語が話せるだけでは務まらないことが多いです。やはり、語学力はブリッジSE業務のすべての基礎となりますので、言語4技能(リーディング、リスニング、ライティング、スピーキング)を満遍なくできる必要があります。英語で言えばTOEIC800点以上は目指したいです。
更に、国毎に時間・商習慣・国民性が違うので、そのあたりのケアにもあたります。例えば、納期や時間意識のサポート、完了基準や進捗報告の感覚のズレ、祝日や時差などを加味したスケジューリングなどです。
私はアメリカ人、インド人、フィリピン人、中国人などと仕事をした事がありますが、国や人種によっても注意すべき点は(あくまで傾向として)変わるので、その国の文化や歴史などを理解して、言動の背景を学ぶようにしています。
コミュニケーション力
クライアントはシステムや技術の事がわからない場合もあり、分かり易い言葉で言い直してコミュニケーションが出来る必要があります。また、オフショアは、日本語がわからず、お客さんの業務・業界・システムの全体像を知りません。話す相手の理解レベルに合わせたコミュニケーションを行う必要があります。
また、ブリッジSEが顧客折衝をする事も多く、クライアントのご要望を汲み取り合意形成を図ったり、成果物をアピールしご承認頂くプレゼン力なども必要となります。
理解力
以下の絵をご存知でしょうか。システム開発の難しさを表したIT業界で有名な風刺画です。顧客が必要なシステムを誰も理解できておらず、使い物にならない高額なシステムを作ってしまったという絵になります。
国内開発では「クライアント ⇔ SE」だったのに対し、オフショア開発では「クライアント ⇔ ブリッジSE ⇔ オフショア」となり、更に参加者が増えます。ブリッジSEの理解がシステムの完成度に直結するのです。
私は以下のような事を意識して完成度を上げています。
「わからない事はすべて解消する」
ブリッジSEの業務では、以下例のようにわからない事が沢山出てくるので、必ず理解した上でブリッジ業務をする必要があります。
・オフショアに〇〇の仕様が説明できない → クライアントに聞く。
・外部APIの仕様がわからない→外部ライブラリを読んでみる。分からなければ、担当者に聞く。
・お客さんにデモ。ここの動きわからない → オフショアに聞く(コードを読む)。
「阿吽の呼吸なない。」
ハイコンテクスト、ローコンテクストという言葉があります。ハイコンテクストは、暗黙の了解が多く、行間を読むようなコミュニケーション方法を指します。ローコンテクストは、前提知識やカルチャーの理解がなくても理解できるよう、シンプルでわかりやすいコミュニケーション方法を指します。日本は世界一ハイコンテクストな国だと言われます。
「空気を読む」「阿吽の呼吸」などは一切期待せず、すべて伝えきる事を意識しています。そして、その伝えたことが遵守されるよう担保するのです。
「仕様伝達を工夫する」
文章で伝えるのではなく、まとめられるなら、図・表にしてみる事も意識しています。
また、別の言葉に置き換えて確認してみたり、相手に理解を説明してもらって確かめたりもします。
ヒューマンスキル
システム開発はチームで協力しながら進めますので、多数の関係者がいます。その為、クライアント、オフショア、チーム含め、誰が何の役割・責任でプロジェクトに参画しているか把握した上で、コミュニケーションを図る必要があります。
例えば、私は以下を意識しています。
・体制表(組織、人、役割を整理)を整備し、関係者と合意をとります。
・各自の得意分野を把握し、質問をしたり、タスクを依頼します。
・チーム全体の評価を頂くクライアント・上司に対し、適切な報連相を行います。
・エスカレーションルートを確保し、困った事をスムーズに解決します。
また、システム構築は人が作るので、人間関係がスムーズでないと、いいシステムは作れません。問題・課題が起きたり、意見があった時に、役割を超えてすぐに包み隠さず相談しあえる人間関係が大事となります。人間関係を築く事が得意な方はブリッジSEに向いていると思います。
SEスキル
SE同様、プロジェクトで使われているプログラミング言語やシステム開発を理解し、開発環境の整備、設計、コード・動作レビューを当たり前に出来る必要があります。
設計力
ブリッジSEは要件定義・基本設計に関するスキルが必要です。要点を抑えてた要件定義ができていないと、何度もやり取りが発生し、工数がかさむ事になります。基本設計、詳細設計共にオフショア側で実施する場合もあると思いますが、何よりも土台となる要件定義は確実に出来る必要があります。
レビュー力
クライアントのご要件を一番理解しているのはブリッジSEです。その為、ブリッジSEが出来がってきた機能やシステムが正しく動くのかチェックできます。
以下は例ですが、このようなレビュー観点で確認していきます。
（もしくは、テスト観点表を作成し、オフショアで確認してもらう事もあります。）
・テストツールの適用範囲確認： テストツールで網羅的かつ正しくテスト出来ているのか。
・ブラックボックステスト： ユーザ要件に対し正しく動作するのか。
・単体テスト： テスト技法を理解し、各条件分岐で正しく動作するのか。
・内部結合テスト： サブシステム内の他機能との結合は正しく動作するのか。
・外部結合テスト： 外部システムやAPIとの結合は正しく動作するのか。
・他にも業務シナリオテストや負荷テストも必要に応じて実施。
技術力
プロジェクトの技術スタックが変わる事も多く、ブリッジSEは基礎的な技術力は身につけておく必要があります。そうすることで、プロジェクトを任せられた時に習熟速度が高く、応用が効くようになります。
例えばですが、以下でしょうか。
・プログラミング言語とフレームワークを習得した経験
・コンピューターサイエンスや(応用)基本情報技術者試験の学習
・大抵のシステムはDBを使うので、SQLの仕様経験（基本的なコマンドは調べずに使えるレベル）
・アーキテクチャの知識
・Git/Docker/Linuxコマンド
・サーバー知識(オンプレ/AWS/GCP)
また、実際のプロジェクトに入る時に、役割に応じて必要な技術のレベル感は違ったりします。プロジェクト着手時の勉強前に、レベル感を把握します。
例：技術的に難易度は低い案件のブリッジなので、概要理解で十分。
例：コードレビューして欲しいので、全体像と詳細まで理解。
プロジェクトマネジメントスキル
ブリッジSEは、QCDを適切に管理し、タスクの優先順位付けを行い、計画したスケジュールを遵守し納品する必要があります。
チームリーダー、プロジェクトリーダー、プロジェクトマネジャーとしてのプロジェクト従事経験があると、マネジメントスキルを活用してオフショアの稼働をスムーズに行えます。
また、プロジェクトの概要・全体像を正確に理解しておく事で、オーナーシップを発揮出来ると思います。プロジェクトにアサインされたら、プロジェクトの背景、概要、目的、目標、納期、サービスコンセプト を押さえます。大枠を理解した上で、プロジェクト → 機能 → 詳細 といった具合にオフショアともコミュニケーションが取れるようになります。また、システムの概要を知っているからこそ、レビュー時にあるべき姿が見えてくると思います。
まとめ
ブリッジSEの仕事内容、役割、そして必要なスキルをご確認頂きました。コミュニケーター、SE、プロジェクトマネジメントと幅広い活躍が求められ、改めてブリッジSEがオフショア開発のキーパーソンであることをご理解頂けたと思います。
クライアントの方：少しでもオフショア開発やブリッジSEについてご理解頂け、ご興味をお持ち頂けましたでしょうか。弊社のオフショア開発サービスについても、ぜひご検討頂けましたら幸いです。
就職活動中の方：ブリッジSEは、求められる事が幅広く、覚える事が多く、グローバルでチャレンジングなお仕事です。その分、プロジェクトが成功する度にエンジニア冥利に尽きます。英語が喋れて、技術力もあり、マネージメントも行える、とても市場価値を高められる職種だと思います。
皆様がブリッジSEとしてご活躍され、日本のエンジニア不足に少しでもご貢献されれば幸いです。弊社でもエンジニア採用中ですので、ぜひご検討ください。
ブリッジSEの方：こちらの記事でオフショア開発の課題意識とブリッジSEのキャリアパスについて執筆しております。ぜひ併せてお読み頂ければ幸いです。
最後までお読み頂きありがとうございました！
