ブリッジ・エンジニアの日常・まえがき
はじめまして、ジョンです。新卒で外資系IT企業に入社して、私が最初に命じられたポジションはブリッジ・エンジニア（インフラ領域）でした。
筆者の生い立ち
自分は生まれも育ちも日本ですが、母親がフィリピン人のため、英語とタガログ語を自然と身に着けました。日常生活程度は問題なくコミュニケーションは取れますが、ビジネスとなるとたまに認識齟齬を生んでしまう、なんちゃってトリリンガルです。仕事でもプライベートでも言語や文化の違いに苛まれてるそんな筆者。
このブログは誰が読むべき？
ブリッジ・エンジニアってなーに？って思ってる人、これから、もしくは今オフショア開発をやってる人、インフラエンジニアの人、興味がある人にぜひ読んでもらいたいです。
そのオフショア開発っていうのは何？
オフショア開発とは、システム開発などの業務を海外企業、または海外の現地法人などに委託することである。オフショア開発の主な目的は、発注側と受注側の経済的格差によって生じるコストメリットである。 受注先としては、人件費が安く労働力が豊富なインドや中国、ベトナムなどが主になっている。（一部抜粋）
要はすべての業務を単価の高い日本のメンバーがやるより、人件費の安い海外の企業に委託しようっていうのがオフショア開発。このオフショア開発をするのには日本と他国の双方のビジネスに精通してしないと難しいですよね。そこで必要な人材になるのがブリッジ・エンジニア。
ブリッジ・エンジニアって何？
ブリッジSE(ブリッジ人材/ブリッジエンジニア)とは、ITのスキルだけでなく言語や文化など両国間(例えば中国と日本)のビジネス習慣を熟知し、間に立って円滑に業務を進められるよう指示できるSEのことです。 SEの能力に加え、プロジェクトマネージャーとしての能力、そして言語力が求められていることが分かります。（一部抜粋）
そう、ブリッジ・エンジニアは日本と他国の架け橋となって、プロジェクトをドライブするかっこいい職種。個人的には海外のメンバーとコラボレーションをして、システム開発したり、運用保守したりする人たちをみんなブリッジ・エンジニアと呼んでいいと思っています。ただ、このブリッジ・エンジニアは上記の通りIT力、PM力、言語力の3つを兼ね備えなければなれない超ブラックな職種なのです。
え、無理じゃない？できなくない？
そう、無理なんです。できないんです。でもやらなければならないんです。あまりにも要求されるスキルが高いし多い。現場ではこれらの能力を完璧に兼ね備えたメンバーがいて完璧にプロジェクトを完遂させている.....なんてことはまーったくなく、認識齟齬からくる喧嘩やシステム障害なんてものは日常茶飯事。
え、じゃあどうしてるの？
毎日葛藤。結局、上述した3つの能力、IT力・PM力・言語力を身に着ける以外他ないということです。そこで私の失敗事例を基に虎の巻をここに記し、読者には最短距離でこの3つの能力を身に着けてもらおうというのが筆者のゴール。また、この3つの能力を醸成するヒントや実際に業務で役立った知識をシェアできたらなと思います。
ブリッジの考え方について#1
インフラエンジニアとして自分も手をバリバリ動かす人間なので、どうしても考え方がシステム寄りになってしまうのですが、この虎の巻的なブログを作るにあたって根本的な考え方が2つあります。1つが「Design for failure」えっどっかで聞いたことあるって思った方はきっとAWSのエンジニア。そう、これはAWSの受け売り。
Design for failureとは？
Design for failureとは、詳しくは下記のリンクを参照ですが、システムを運用保守するとき、基本どんなシステムにもサービスレベルの要件があります。たとえば「24時間止めちゃだめー」ってものがあったらどうでしょう。仮に1つのサーバでシステムを運用していたときに、突如停電でサーバが止まってしまったらお客さんに怒られちゃいますよね。24時間止めちゃだめって言ったでしょー！契約違反だよー！ってなりますよね。
できればみんなそのサービスレベルは死守したいわけですよ。利益を守るためにも。100%死なないはもちろんできないから頑張って100%に近づけよう。99.9999…にしようっていうのがAWSさんの考え方。
あらゆるSPOF（単一故障点）で冗長性を持たせるわけです。サーバを裏で常にもう1台かまえておこう。ということね。この障害を見据えた設計をしようっていうのが「Design for failure」。
前置きが長くなってしまったがオフショア開発をする際にも大事な考え方。あらゆる認識齟齬を生んでしまうポイントに事前に対策をうっておく。ってことです。
ブリッジの考え方について#2
もう1つはキーワードは「アジャイル開発」です。
アジャイル開発とは『すばやい』『俊敏な』という意味で、反復 (イテレーション) と呼ばれる短い開発期間単位を採用することで、リスクを最小化しようとする開発手法の一つです。（一部抜粋）
アジャイル開発とは素早くとりあえずプロトタイプみたいなものをつくってしまって、失敗の反省やユーザの声を取り入れて、徐々に品質を上げていこうという手法ですね。
毎回この話がでるたびに自分はスマホのソシャゲを思い浮かべるんですが、今や大人気となったスマホのソシャゲがリリースした当初って割とシンプルなつくりでえ、これ楽しいの？流行るの？なんてユーザが思っちゃうくらい簡素なものだったりするんですが、これがどんどんストーリーが盛り込まれたり、多機能になったりして面白くなっていきますよね。これもアジャイル開発の1つなのかなって思っています。
オフショア開発をするときにもこれって大事な要素の1つだなって思っていて、どこまでいっても人間なので、ヒューマンエラーはつきものなんですね。想定外の障害は発生してしまうものです。
ヒューマンエラーをなくすためにどうすればいいかを何週間もかけて考えるのはナンセンスです。機械的にチェックする方法を考えるか、人間がチェックする際のチェックポイントをまとめるかを素早く考えて、次はこうしよう。うまくいった？うまくいかなったね、じゃあ次はこれで。とブリッジの手法も適宜アジャイル方式で、とりあえずキックして品質を徐々に上げるほうに専念するほうが安定稼働までの近道です。
こうあたかも私は完璧にできていますみたいなトーンで話していますが、自分も反省の毎日です。ただ私が出くわしたケースをシェアすることで、読者が未然に防ぐことができれば、このブログを書くことの意味がでてくるのかなって思います。
まとめ
①ブリッジ・エンジニアはオフショア開発をするスペシャリスト
②このブログを読むと筆者の失敗からIT力・PM力・言語力を身に着けられる
③ブリッジも「Design for Failure」と「アジャイル型開発手法」の考え方で攻める
いいなと思ったら応援しよう！
