オフショア開発に大切なこと、それは

こんにちは、データエンジニアの植村です。FLINTERSのブログ祭り企画として、今回はハノイにあるFLINTERS VIETNAM(以下FV)に5/4-5/18までの期間出張した時のお話を書きます。

現地に行った経緯

2024年1月よりFV内でのプロダクトの内部品質を向上するプロジェクトに参画していました。FVだけでは抱えきれなくなってきたタスクをFLINTERSと協力して解決して行こうという試みです。
FLINTERS内部でチームを結成し、セキュリティチェックやSLA/SLOの作成、開発プロセスの見直しなど行ってきましたが、オンラインでの限界を感じていたこともあり現地に赴くことになりました。

5/4 現地入り

飛行機から降りた瞬間に明らかに異変を感じました。数時間前までの春の陽気は一瞬で吹っ飛び、ハノイの熱気に変貌しました。これは熱い出張になるな(物理的に)。

1週間目 - 勉強会を開催 -

まず簡単に顔合わせの挨拶と、手始めにドラッガー風エクササイズを行いました。
お互いを知ったところで、具体的に何を行うのか、何を成果物にするのかの話し合いを行いました。話し合いの結果、勉強会の内容は

より良いコードの書き方(SOLIDの原則)
ユニットテストの設計の仕方(Right-BICEP、境界条件)

成果物には、

本番環境のプロダクトのDB設計の変更とそれに伴うリファクタリング

に決定いたしました。

特に素晴らしいと思ったことは、チーム全員が疑問点を全て解消しようとする姿勢です。勉強会では、周りの空気を読んで分からないまま質問もせずに進むこともよくあると思います。
だがしかーしFVにはそんなものはない！法則一つをとっても延々と話が続きます（ココそんなに議論するところある？と思うことも）

また、初日から彼らは私を快く迎えてくれました。お昼やお休みのプランも、何が食べたいか、何に興味があるかを聞いて提案してくれました。

2週目 - プロダクトに外部キー制約とユニットテストを追加 -

1週目に学んだことをプロダクトに適用します。具体的にどこまでテストの適用をするか。話し合った結果、

現状の機能に対してのユニットテストの作成
↓
DBの再設計とそれに伴うコードの修正
↓
リファクタリングされたコードに対してのユニットテストの作成

チーム内からさまざまな意見が湧き上がり、良い道筋を見つけることができました。

思い込み・先入観

FVに来る前は、私は比較的不安な気持ちでいました。
なぜなら私の業務はシステム監査のようなもので、例えるならばお姑が人差し指で埃をチェックするような業務と捉えることもでき、あまり歓迎されるものではないと考えていたからです。また、一度醸成されたカルチャー・マインドを変えていくことができるのかという点も心配の一つでした。しかし彼らはそんな私の不安を初日で吹き飛ばしてくれました。

むしろ私が彼らから学んだことがあります。それは

オフラインでのコミュニケーションにより生まれる熱量
分からないを許容せずお互いに教え合うこと

教えに行ったはずが教わって帰国しました。

改善点があるとしたら

コミュニケーションの取り方
お互いある程度は英語ができますが、英語でSOLID原則について議論をできるほどのレベルではないです。
なのでコミュニケーター(IT用語に成熟した通訳)を介してお互いの意見を伝えるようにしました。しかしどこまでニュアンスが正確に伝わっているのかはわかりませんし、何よりFVのエンジニア同士の議論などを全て翻訳することは不可能で、彼らが何に違和感を覚えて話し合いをしているのかわからないままで歯痒い経験をしました。

自分の知識不足
データエンジニアとしてキャリアを積んできたこともあり、データエンジニアリングやクラウドインフラであればプロダクトを中心にコードや設計の良し悪しの議論ができますが、あまり馴染みのないScalaやTypeScriptで書かれたバックエンドのコードを元にした議論展開はできませんでした。