この記事は、Engineering Manager vol.2 Advent Calendar 2018 4日目向けに書きました。
弊社では、UUUM Advent Calendar 2018 も公開していますので、こちらもどうぞよろしくお願いします！
開発兼マネジメントを担当しているナカハシ（@k_nakahashi）です。
先日まで半年間、ベトナムのオフショア先と一緒に社内システムの開発を行いました。
個人的にオフショア先との共同作業は初体験でどうなることかと思っていましたが、とりあえず形にはなったのではないかと思います。
やってみて初めてわかったことが多かったですし、そのとき試した進め方や感じたことなどを書いておこうと思います。
何を作った？
今回オフショア先と開発することになったのは、Rails製の社内システムです。
ビジネス的に重要な情報を蓄積して長くメンテナンスしていくことが前提となるため、設計や可読性に関してはある程度の水準を達成する必要があります。
とはいえ、社内システムゆえにハードな非機能要件はありません。設計もスタンダードな、いわゆる「Rails way」なアプリです。
どんな協業先？
もともと弊社では、他のシステム開発でベトナムにあるFramgia社と協業しており、今回も同社にお願いすることになりました。
最初のオフショア先としてFramgia社を選定していた理由ですが、同社の他社との協業実績がすでに多くあったことと、サポート体制に信頼が置けそうだったからです。今回の開発のPM兼エンジニアの私は、それに乗っかった形です。
開発がスタートする前の月、ベトナム・ハノイにあるFramgia社のオフィスを訪問しました。
ハノイの街並みは、東南アジアらしいカオスっぷりが印象的でした。2車線の車道でも信号は少なく、徒歩で横断するにはおびただしい量のバイクをすり抜けながら進むスキルが求められます*1。
Framgia社が入居しているビルは、ベトナムらしい伝統的な街並みの中にいきなりモダンなデザインで建っていています。オフィスの中にはものすごいおしゃれなカフェとかあって、控えめに言って弊社よりすごいかも(?)w
そもそもエンジニアが全社で700人もいて、エンジニア組織としては相当な規模です。エンジニアのレベル区分も洗練されていて、今回の要件に合うような要因のアサインもしっかりやってくれました。
キックオフミーティング＋α
キックオフミーティングでは、開発してほしいシステムの概要や利用してほしいライブラリなどの要望や調整、開発フローの確認などを行いました。
この際に技術的な議論をしたのですが、質問の内容や深さも「このひと達WebやRailsのことよく知ってるなー」というレベルで、安心感が増しました。
弊社のRailsプロダクトではテストでminitestを採用していたのですが、彼らとの議論で今回はRSpecを使うことにしました。
弊社でも当然そういった議論はあって、RSpecのデメリットなどを認識した上で採用を見送っていました。ですが個人的には使ってみたかったしw、彼らの経験値を活かすのもよさそうと思い、こういった形にしました。（依頼を受ける側の彼らに「自分たちの要望を聞き入れてくれる」という風に思ってもらったほうが今後のコミュニケーションもうまくいくかも、という考えもちょっとよぎっていました）
夜は、チームのメンバーとキックオフディナー（というなの飲み会w）に参加しました。
今回私が担当するシステムの開発メンバーの他に、従来から継続して開発をお願いしているチームのメンバー、現地の日本人スタッフの方たちが一緒だったのですが、乾杯の音頭が日本の「カンパイ！！」の10倍位長い上にハイテンションですごかったw 基本的に私の英語の能力は壊滅レベルなのですが、通訳なしで少しでもチームメンバーと話せたのは、今振り返っても良かったと思います。
デカいボールの中に白濁な現地のお酒が出てきてコップですくって飲むのですが、口当たりが良すぎて危険だったことはよく覚えています。
チーム編成
チームの編成ですが、依頼する側の我々はPM・エンジニアとしては主に私一人で、技術的な支援（相談相手）としてチーフエンジニアのnazoさんやCTOのBTOさんなどのメンバーにときどき手伝ってもらうという感じでした。
オフショア先のFramgia社ですが、
- Railsエンジニア : 3名
- QAエンジニア : 1名
- ブリッジSE（通訳兼PM的なポジション） : 1名
というチーム編成になりました。
今回の開発では、以下のようなコミュニケーション上の制約が念頭にありました。
- ネイティブ言語*2が私とオフショア先とで異なる
- 物理的にフェイスtoフェイスのコミュニケーションは、基本的にない
- ビジネス上の背景やシステム要件は、全て私経由で伝える必要がある
一言で言うと「ツラい」のですがw、彼らもそういった状況は慣れたものなわけで、コミュニケーションやマネージメントをサポートしてくれるブリッジSEなる存在がこの辺のツラみを様々な形で軽減してくれました。
もちろんエンジニア間で直接コミュニケーションも取れるのですが、必要に応じてブリッジSEと日本語で連絡するというオプションがあるのはありがたいです。
進め方
今回の開発は、納品日に一気に納品してもらうウォーターフォール＆請負型ではなく、スクラム風スタイルで進めていくことにしました。
社内の他のシステム開発に倣って、一週間ごとに定例ミーティングを開いて作業と問題点の確認を行いつつ、コミュニケーション上の特性を考慮して以下のようにしました。
- Slackチャンネルを共有
- 週次定例ミーティングはSlack Callで
- 要件はGitHub Issueで私から共有・管理（この時点ではいわゆる「ストーリー」レベルの抽象度）
- 要件の分割・詳細化はFramgiaチームに任せる
- 開発環境の整備（開発環境のインフラ・CI・利用するユーティリティ的なGemの選定や組み込みetc...）は私が実施
- GitHubフロー、レビューは英語、マージは私とFramgiaチーム全員のエンジニアのapprovedを必要にする
- 日報などはもらわない（Framgiaチームに日毎の管理は任せる）
エンジニア陣の技術力は十分であるものの、（私の言語的な問題もあって）コミュニケーションコストが高いので、彼ら個人ごとの進捗管理は基本的にFramgiaチームでやってもらうという方針です。*3
ですが、彼らからの出口（マージ）は私を必ず通すことにして、このシステムに求められる保守性の担保をするようにしました。（ある意味力技ですが...w）*4
また、開発環境の整備に関しては希望要件を全部伝えるのは大変なので、ここは私が一気に実施することでコミュニケーションコストを抑えるようにしました。同様に開発の初期段階では、DBのスキーマ設計などは私が実施していました。（途中で先方の技術力がわかってきたため、それも含めてお願いするように変えていきました）
開発を始めてみて
要件まとめ＆レビュアーが私一人で、Railsの手練が3人＋αという体制、思ったより多勢に無勢という感じでしたw
もともとは私自身もコードを書こうと思っていたのですが、彼らの開発速度が速すぎて私のレビューが間に合わなくなり、Slackで「@nakahashi_k plz review 😘」というメンションを貰うこともしばしば。しかも彼らはPR作成時点でQAを済ませているため、基本的に品質もよかったです。
自分でコードを書く時間をなかなか取れなくて不本意ではあったのですが、黙っているとコードがpushされてきてそれをapprovedするだけ(?)で開発が進むため、なんだかゲーム実況をみているようなちょっと楽しい気分になっていました。
ありがたかった（うまくいった）ところ
私としては上記のように手がいっぱいになってしまうことが多かったのですが、週ごとの開発ミーティングのアジェンダ作成で先方が主導して作ってくれたり、仕様のQ & Aをスプレッドシートにまとめてくれるなど、PM業務もある程度手伝ってくれたため、助かりました。*5
またレビューも不安だったのですが、英語での議論も意外と何とかなるし、説明に困ったらコードをPRコメント内に多めに書いて伝えるようにするとスムーズに通じるため、思ったよりは苦労しなかった印象です。
なによりpushされてくるコードの品質がよかったし、指摘するといい感じに手早く修正してくれるのがよかったと思います。
うまくいかなかったところ
当初、こちらからのIssueによる仕様伝達も英語にして先方のエンジニアに直接伝えられるようにしようと思っていたのですが、私の英語力の問題で間に合わなくなり、結局私は日本語でIssue書いていました。
これに関しては、そのために先方にもブリッジSEがいるし、ブリッジSEがベトナム語に訳してくれるため先方のエンジニアもその方が楽そうでした。結果的にはこちらのほうがよかったかもしれません。
また、自分はPRの説明文に関しては割とちゃんと書いて欲しいと思う方なのですが、PRのテンプレートをコードベースに入れてはいたものの、ここの重要性がなかなか伝わらずに苦労しました。作業が必要になった背景などは確かにミーティングの議事録やQ & A集などをみればわかるのですが、PRの説明文にも多めに書いてもらうとレビューの時に安心感あったのですが。。。
とはいえ、全般的に開発はうまくいったし、ボトルネックは（前述の通り）私にあることが多かったですw
現在
以下の理由で、現在ではFramgia社のエンジニアチームによる開発は終了しており、内製に切り替えています。
- 稼働に必要な最低限の機能開発が終了した
- 開発内容に社内の他システムとの連携が多くなり、外注しずらくなってきた
彼らが開発したコードに関しては、基本的に私が目を通せていたので内容に関しては把握できていますし、社内の他のRailsアプリと設計も同様に開発してきたので、内部のエンジニアにも共有しやすいようになったと思っています。
まとめ
オフショア先であるFramgia社と一緒に開発した半年間は、振り返ってみるとあっという間でした。
この間のきちんと動くコード、作った経緯を記述したドキュメント群といった成果物は確実にありますし、一緒に作業していた私としても納得感のあるクオリティを担保できていたのではないかと思っています。
また、RailsのベストプラクティスやGitHubフロー、スクラム開発といった手法はもともとグローバルなものなので、国が違っても通じやすいものだと感心しました。なので、こういった手法を採用せずにオレオレ開発を続ける個人や企業の場合、オフショア先との協業はよりハードルが上がるでしょう。
何より、彼らのエンジニア陣の技術力の高さ、チームワークの良さに何度も助けられました。
言語や文化の違う会社との共同作業には不安もあったのですが、彼らとのコミュニケーションに関しても（少なくとも私にとってはw）ポジティブに進められたのは嬉しかったです。最後のミーティングは、お互いを褒めまくって終わりましたw
これからも、いろいろな形態のチームで開発を行うことが出てくると思いますが、ツボを押さえて楽しく作業ができればいいなと思っています。*6
*1:意外に慣れます。コツは歩きながら目でバイクに乗ってるひとを牽制すること
*2:話し言葉のことです。一応...w
*3:Framgia社内のマネジメントも洗練されていたので、そっちは利用させていただく方向
*4:そもそも、長く保守することが前提のこういったシステムを社外のエンジニアで開発するのもホントはよくないのですが、システム自体の需要の高まりとのバランスでこんな感じになりました
*5:これは、彼らからするとトラブル防止の意味もあったかと思います
*6:ハノイの街並みやベトナム料理、現地の方々の温かさなどすべてよかったので、またベトナム行きたい...！ 会社の近くのベトナム料理屋によく行くようになりました