オフショア開発が抱える「構造的な限界」を脱し、エンジニアが自身で価値を高める時代へ

～オフショア主流の日本が大嫌いだった大澤が、大手SIerを捨てEYSに来た理由～

エンジニア・株式会社2nd-Community/共同CTO。一橋大学経済学部卒業後、2001年大手SIerにエンジニアとして10年間勤務し、企業のシステム開発に従事する。2012年株式会社EYS-STYLE（現、株式会社2nd Community）に入社。会員向けサイト「セカンドコミュニティ」立ち上げにあたりRuby on Railsによる開発を担当。現在は、基幹システムから会員・一般向けサイトの開発、運用までを担っている。

オフショア開発では「日本エンジニアのプログラミングに価値はない」

エンジニアの価値は、どこにあるのか。世界情勢の変化とともに、求められる価値も大きく変わる。その変化を当事者として体感し、エンジニアの新たな価値を生み出すべく挑戦しているのが、2nd Communityの共同CTOとしてエンジニアを束ねる大澤 聡だ。大澤は一時期から盛んにおこなわれていたオフショア開発には、大きな問題があると指摘する。自身も前職となる大手SI企業で、中国で立ち上げたグループ会社でのオフショア開発をおこなっていた。「グローバルで展開する企業でしたが、当時は全社的なポリシーとして、日本のエンジニアは仕様策定まで担当し、プログラミングは中国でおこなうことが決まっていました。中国の方がコストを抑えられるので、『単価の高い日本のエンジニアがプログラミングするなんてとんでもない』とまで言われていましたね」

「オフショア側はビジネスを理解しないまま開発」には無理がある

だが、この体制では開発が思ったように進まない。そもそも、言語の壁はどうしても大きく、日本語の仕様を中国語に翻訳した結果、意図が変わってしまうことも度々起きた。また、中国のプログラマには仕様を渡すのみでビジネスについてのレクチャーは行わない。「現地でテストをしてほしいと伝えても、テスト項目をひとつずつ入力内容・出力内容まで細かく定めれば対応可能、という反応でした。ビジネスがわからないから仕方がないところはありますが、そこまで細かくこちらで指定するなら、その先はテスト自動化ツールでも実施できます。ツールと同じことしかできない、という状況で果たして意味があるのかは疑問でした」

もちろん仕様は日本でかなり細かく決めるが、完全に仕上げることは不可能であり、開発時に軌道修正する必要がある。しかし、「現地のプログラマはビジネスが分からないので、仕様の意図も分かりませんし、軌道修正されないまま開発が進み、意図したシステムができない、予定通りに納品できないという事態も頻発していました」

問題は起きるべくして起きていた、オフショア開発の体制

オフショア開発はその構造自体に無理がある、と大澤は続ける。「グループ全体でオフショア開発の体制をとっていたため、中国側は営業努力をしなくても仕事がくる状態でした。競争がない状態では、成果に対して責任を持たなくなるのも仕方ないところだと思います。なによりも物理的に距離があることで、どうしても“他人事”感が抜けず、協力してよりよいものにしようという意識にはなりづらかったのでしょう」現地にも品質を管理するためのクオリティアシュアランス部隊があり、品質を担保する意識はあったが、ここでもトラブルが起きた。「納品されたプログラムをこちらでテストしているのに、クオリティアシュアランス部隊がコードを変えていたことがありました。これでは実施したテストが無駄になってしまいますし、挙句この変更によってシステムが落ちるようになってしまい、大きなトラブルになりました」物理的な距離によるコミュニケーションの齟齬による溝は深まるばかりだった。

吹き出し　笑えないエピソードが続き、心も折れそうに……。プログラマなら誰でも「1人月」。開発現場にはマッチしない評価体制

中国側はとにかくプログラマと呼べる人材を増やそうという方針になっていたが、プログラマは人月換算されるため、生産性（スキル）が高くても低くてもすべて1人月としてしか評価されない。「システム開発は、スキルの低い人が100人いるより、スキルの高い人が1人いた方がいいものができる世界です。なにをしても1人月という評価ではマッチしません。さらに中国では2～3年勤務実績を作って転職する人も多く、経験を積んだ人材が定着しない問題もありました」

そのような環境でオフショア開発をしても品質に不備があることが多く、炎上プロジェクトも後を絶たなかった。「自分でコードを書いた方が早いんじゃないかと思うほど細かな仕様書を書きながら、日本のエンジニアはプログラミングしなくてよい、そこに価値はない、と言われる環境はなにかがおかしいと、離れることを決めました」

ビジネスもプログラミングも分かることが、これからのエンジニアの価値

そうして大手SI企業を離れた大澤が2nd Communityへと入社したのが、2012年のことだ。2nd Communityでは機能を少しずつ開発し、実際に動くものを見せながら調整・開発を繰り返すアジャイル開発を取り入れ、自身でビジネスからプログラミングまですべて担当する。また、きちんと個人ごとの成果を評価されるため、モチベーションや自分で責任を持つ意識も高まっていく。「一人ひとりのスキルや成果をしっかり見られていることが分かりますし、ビジネス側から出された要望に対して、これはやらない方がよい、違う方法がよいとエンジニアから提案することもあります。コードが分かるからこそできるビジネス提案があり、自分自身の価値を高められると実感しています」

オフショア開発では、システム全体について設計から開発、テストへと順次進め、後戻りを許さないウォーターフォール型が主流だったが、世の中でもアジャイル開発へと大きく変化し始めている。今求められるのは、一般的な機能はフレームワークを活用して、本当にビジネスに必要なところだけを開発するスタイルだ。「こうなると、仕様に合わせてプログラミングだけできる、プログラミングは分からず仕様だけ作成できるのではなく、業務もプログラミングも理解するエンジニアが1人いる方がよい、となります」

ビジネスを理解してコードを自分で書いていく。自分らしく働ける場所を見つけました。円安は追い風に。海外でも日本エンジニアが評価される時代へ

さらに昨今の円安が追い風となる。製造業では生産工場の国内回帰がニュースにもなっているが、システム開発においても、日本の経営者として、日本国内で開発する方が効率的という判断は十分あり得る。海外企業からも、日本のエンジニアの価値が注目されるようになるだろう。日本のプログラマは要らないと言われていた時代は終わり、これからはビジネスからプログラミングまですべてを理解して、求められるシステムを生み出せる人材こそが求められる。「オフショア開発のような大きな構造の歯車になるのではなく、本当に価値を生み出せるエンジニアがスキルを発揮できる時代になります。そういった人材は海外にも十分アピールできますし、円安は逆風ではなくむしろチャンスです。日本のエンジニアには今こそマインドを変えて、奮起してほしいです」