GYAOの窓際エンジニア 玉利です。
実は、GYAOのオフショア第一回は失敗しました。全員の言うことを全部ぶちこんで、「これからはNode.jsの時代だ」という技術企画さん（オフショア未経験）の言うことをそのままやってみました。予想どおりグダグダです。
_生春巻きも現地ではダイナミックな感じです_
最初に手痛い失敗をしてから、次回以降の案件は、未経験者の意見を完全に却下してまるっとRailsを使うことにしました。前回Node.jsで大炎上しているので、さすがにまたNodeとかいう人はいません。PHPもダメと言い切りました。理由は、フレームワークが「これ」という決定版がなく、教育資料が整ってないからです。速成には向いてません。
そもそも、RailsはDHH氏がbootcamp社で、開発者は皆リモートワークするという製品開発のために生まれたフレームワークなので、オフショアみたいなものには特に向いているのです。おすすめ書籍としてコチラ「強いチームはオフィスを捨てる」をあげておきます。
10年かかって先輩の技を盗んで一人前という長い伝統に支えられた徒弟制度的技術育成も否定しませんが、古伝を理論として整理しなおした近代的な体系を利用するほうが速成には向いています。
そして、新規PJはたっぷり設計とモデリングを行い、海外で働く前職の大先輩方のお言葉を思い出しながらやりかたを決めました。オペレーションズリサーチの思想と、
製造業の生産技術の仕組みを導入しています。
メンバー選定
かつて弊社グループでCI/CD推進のリーダーをしていて、テストコードの普及に苦労したN氏いわく「おっさんには何をいっても響かないので、真っ白な新卒若手を洗脳するんですよ。2年位やって若手がみんなテストコードを書くという状態になって、おっさんたちもしぶしぶテストコードを書くようになります」
ランチェスター戦略という経営の世界では有名な思想があります。今回使わせてもらったのはマーケットシェア理論「シェア4割を支配すればナンバーワンで安定した地位となり市場をリードできる」というものでした。まずテストコード含め、こちらの意図する品質のコードを書いてくれる人をチームの4割以上にすることが最初の目標になりました。
チームの最初のメンバーは、ほぼ新卒の若者にしました。プログラマー向きではない私の経験では、だいたい2週間あればPerl/Rubyはなんとかなります。純粋にビジネスロジックをエレガントに表現できればOKです。実は彼らに「Cの経験はある？」と聞いたのですが、「大学で習ったけど、覚えてない」ということでした。
彼らには、Railstutorialを60時間かけて一通りやってもらいました。ところが前の部署のPJが後を引き、時間が足りず尻切れトンボで実案件に突入することになりました。まあ、これはあとでなんとかなりました。第何章のどこどこを見なさい、という形で、実地演習中に補いました。
初期トレーニング
私が現地に出張にいって、横についてコマンドを一つ一つ教えて叩かせました。向こうも英語はしゃべれないし、どこが困ってるのか表現できないので、彼らが困るとコードのココがと指差すか、すぐ後ろにいる通訳を呼んで伝えてくれます。1週間くらい一緒にいれば案外なんとかなるものです。
そういえば、母親が働いていた紡績工場にも日本語を話せないスイス人エンジニアが来ていて、ちゃんと仕事して日本人の嫁さんまでもらってたので、なんとかなるものなのでしょう。私は20代のころ、中国語しゃべれないのに中国で仕事をしていたので、いけばなんとかなる、と思ってます。
AGPLなどのライセンス問題
商用につかったらマズイ、AGPLライセンス問題、これはRailsを使うことでほぼ解決しました。ベトナム人がライブラリ選定時にAGPLなどライセンスを気にしてくれることはないのですが、基本的にMITライセンスなのでよほどのことがない限り悩みません。
minitestがなかなか良い
日本のRails開発では、RSpecの利用が一般的だと思います。英語的な表現でかけて、仕様にコンバートできるというのは素晴らしいです。
ところが、DHHはminitestを推奨しています。こちらのほうが簡単にかけるのですが、あまり突っ込んだことができないという話も聞きます。
どちらもアプローチとしては正しいのですが、ベトナム人にテストコードを書いてもらうハードルを下げるためにminitestを採用しました。ちょっぴり日本語文献が少ないのですが、なんとかなります。
とにかく、メンバーの4割以上が進んでテストコードを書いてくれるというのをキープすることが、開発品質の維持に必要なことでした。
マルチリンガル対応で最初から開発する
Railsには、I18nの仕組みが最初からすぐ使えるように入ってます。普通のメッセージならリソースのymlを書けばいいのですが、プルダウンメッセージなどは日本語で書くとベトナム人が？？ですし、英語にすると日本のユーザーから小一時間問いつめられます。
しかたないので、コードで解決します。
まず、こういうDB設計書を書きます。
そして、modelの中でI18nのlocaleにより内容を出し分ける仕組みを書きます。
class HogehogeStatus < ActiveRecord::Base
# @note switch DB column when locale has set
def desc
case I18n.locale
when :ja then
self.desc_ja
when :vi then
self.desc_vi
else
self.desc_en
end
end
Model.desc を叩くと、localeに応じたdescriptionの文字列（プルダウンに使う）が帰ってきます。
このテクニックを教えておいて、DB設計書にlocale毎の日本語記載を入れておくと、最初からメッセージの国際化対応でつくってくれます。普通の部分については、英語で書いておくから、あとで日本側で翻訳のyamlを埋めてね、と送ってきてくれるので、助かります。
ベトナム人はベトナム語で考えて、日本人は日本語で考えられるのでお互い苦労しなくて済みます。いい時代になりました。