オフショア開発プロジェクトに成功しました

こんにちは。ぐっさんです。
当社ネットオンの運営するサービス「採用係長」は７月初旬に大き目の改修＆新機能のリリースを迎えました。

「採用係長」料金プランの変更、新機能リリースに関するお知らせ（2023年7月3日（予定）から）

複数プロジェクトの同時進行・工期半年ほどの規模の開発で、ベトナムの協力会社さんにもご協力いただきました。

いわゆる「オフショア開発」の取り組みです。失敗が多いと囁かれがちのオフショア開発ですが、大きなトラブルなく開発完了することができました。

オフショアに限らず、大勢のヒトが関わるプロジェクトの失敗理由にはコミュニケーションのトラブルが多く挙げられます。今回は、協力会社さんとともに開発を進めるなかでのコミュニケーションのトラブルを抑えるためにどのような取り組みをしたのかを書いてみたいと思います。

分業体制

今回のプロジェクトでは、ネットオンにて要件定義や設計を済ませてから、協力会社さんに実装～結合テストをお願いしました。結合テストまで実施いただいたのちに、設計の通りに仕上がっているかのチェックも兼ねたシステムテストをネットオンで実施しました。

協力会社さんのメンバー構成は、日本語も堪能なブリッジSEさんが１名、実装を担うエンジニアが３～４名。
ネットオンはバックエンド・フロントエンド兼業のエンジニアが２名の体制でした。

準備段階

設計書

プロジェクト開始前に「まずブリッジSEさんには日本語で書かれたドキュメントを読み込んでもらい、ベトナム語に翻訳してもらって、ほかのエンジニアの方にも理解いただけるようにしよう」という想定でいました。

ので、かなり詳細なドキュメントを準備しました。

ネットオンのメンバーは日本語しか扱えず、協力会社さんのエンジニアはベトナム語しか扱えないため、通訳となるブリッジSEさん１名のコミュニケーションの負荷が高くなることが予想されました。
できるだけ、ドキュメントを読めば仕様がわかる状態にしておくことで、質問を減らす、エンジニア自身で解決できることを増やせるように気を遣いました。

雰囲気づくり

協力会社さんにはいわゆる「元請けと外注」というような線引きを気にしすぎず、１つのプロジェクトチームとして活動していただきたいという思いがありましたので、開発Sec.の大事にしている価値観や空気感を共有するようにつとめました。

「心理的安全性」というキーワードに理解を深めていただいたり、ワークショップを開催したり。

開発Sec.で普段行っていることと同じ取り組みを（ほぼ）同じように行いました。普段どんなことをやっているかは、マネージャーDの記事も読んでみてください！

心理的安全性を保つために：ネットオンでやっているチームビルディングについて

エンジニアチームのビルディングに有効なワークショップの選び方・作り方・企画の仕方

プロジェクト開始後

コミュニケーションツール

ネットオンの開発Sec.はフルリモート勤務、協力会社さんのメンバーはベトナム拠点勤務です。今回のプロジェクトではネットオンで日常的に使用しているバーチャルオフィスツール・ビジネスチャット等を協力会社さんにも使用していただいて、連携をお願いしました。

ツールの利用ルールや気を使ったこと

テキストチャットの利用においては、両社ともに日本語・ベトナム語を併記して使用するルールを設けました。

ネットオンにはベトナム語話者がいないため、チャットで送信するテキスト作成には翻訳サービスを利用しましたが、日本語 → 英語 → ベトナム語と段階をふんで翻訳する方が日本語 → ベトナム語に直接翻訳するよりも精度が高くなったため、２つの翻訳サービスを下記の手順で利用しました。

DeepLで日本語を英語化
Google翻訳で英語をベトナム語化
Google翻訳でベトナム語から日本語に戻して、意味が通じているか確認する

毎回、別の翻訳サービスで作った文言をブラウザ上でコピペして・・・と行き来するのが大変めんどうくさいので、各サービスのAPIを利用して、社内でこんなもの↓を作って利用していました。

また、

質問はYes / Noなど、選択回答ができる方法で行う。
情報を伝えたい場合は、言語(文字)だけに頼らずに、スクリーンショットや図をまじえて説明する。

といったことも気を遣いました。

ネットオンで日常的に使用しているツールについてはこのあたりの記事も読んでみてください！

ビジネスツール活用シーンのご紹介

バーチャルオフィスとリモートワーク

スクラム開発

ネットオンでは通常、２週間を１スプリントとしたスクラム開発を行っています。協力会社さんとの開発においても同様のスクラム開発を実施しました。

長期的なプロジェクトの最中には全体スケジュールに対する現在地点がわかりにくくなるため、スケジュールやタスク残量から逆算して「この２週間で、これだけのタスクを完了させられればオンスケ」という分量のタスク(チケット)を積み、「積んだタスクをすべて完了させること」を毎スプリントのゴールとして定めて日々の開発を進めます。

スプリントプランニング・レトロスペクティブ(ふりかえり)

毎スプリント最終日にスプリントプランニングを実施し、次のスプリントのゴールを決定します。

スプリントプランニングの前には、レトロスペクティブ(ふりかえり)を実施し、当スプリントでタスクを実行するなかで気づいた「良かった・継続したいこと」「改善したいこと」をメンバー全員で共有し、次スプリントへ活かす取り組みを行っています。

今回の協力会社さんとプロジェクトにおいては、言語や文化の差のあるなか、お互いに期待することがどうしてもズレていくことがありました。レトロスペクティブにて、「どんな事象が起こったか？」「どんな問題があった・何が不足したと考えられるか？」「そもそも問題であると感じていたか？」などを挙げ、「次からどう改善できるか？」両社で意見を出しあうことでズレを解消していきました。

朝会(デイリースクラム)

日々の進捗は朝会(デイリースクラム)で確認しますが、こちらも開発Sec.で日常的にやっているのと同じように「昨日やったこと」「今日やること」を報告することで確認していきます。また「困っていること」も発言してもらうことで、問題を一人で抱え込まずにチームで解決する取り組みをしています。

コードレビュー

前述のとおり、できるだけ詳しい設計書を準備＆翻訳して全員が読める状態にしていただきましたが、どうしても100%の理解には至らないものです。そもそも設計書に記載ミスや、設計ミスが含まれる場合もあります。

母国語が違えどエンジニア同士なら共通言語となるものがあります。そう、プログラミング言語ですね。

これは協力会社さんのエンジニアみなさんに配慮いただいたことなのですが、「とりあえず設計書を読んで理解した範囲でコードを書いて、プルリクエストを出す(コードレビューを依頼する)」という動きをスピーディに行っていただきました。これにより、母国語の違う人間同士であっても、コードレビューを通じて仕様の認識ギャップをうめていくコミュニケーションをとることができました。