オフショアは「単価が安いエンジニア」ではなく「開発のゆとり」――リクルートが“新規プロダクト開発でオフショア”を選択した理由とは：リクルート事例に見るエンジニアとしての価値の高め方（4）（1/3 ページ）

リクルートでの新規プロダクト開発事例からエンジニアとしての価値の高め方を探る本連載。第4回目となる今回は「オフショア開発の活用」にフォーカスし、新規プロダクト開発でも頼りになるオフショア開発チームを立ち上げる方法と、安定した開発体制を構築するポイントについて解説する。

[今井宏明，リクルート]

　変化の激しい市場の中で新規プロダクトをリリースするために、リクルートテクノロジーズ（2021年4月1日にリクルートに統合）が実際の開発事例を基に「どのような開発プロセスや体制を作り上げていったのか」「どのような技術選定や設計をしていったのか」を紹介する本連載。

　第2回、第3回は本開発フェーズにフォーカスし、不確実性が高いプロダクト開発で注意すべきポイントについてまとめました。メンバーのアサイン方式やプロセスの定義、テストの進め方などプロジェクトを進めていくための基盤を整備することで不確実性が高い新規プロダクト開発でも、エンジニアが着実に前に進める状態になりました。

　しかし、ここで問題が発生しました。想定より開発ボリュームが大きくなり、現時点でのメンバーリソースでは期間内に開発が終わらないことが分かったのです。そこで今回のプロジェクトでは「オフショア開発チーム」と連携してこの課題を解決することにしました。

　本稿はどのようにオフショアチームとの体制を整え、プロダクト開発を進めていったのかについて4つのポイントに注目して説明します。

1. リクルートにおけるオフショア開発スキームとは
2. なぜ新規プロダクト開発でオフショア開発を活用しようと思ったのか
3. 今回のプロジェクトでのオフショアチームとの統合体制の特徴
4. オフショア開発における今後の可能性

リクルートにおけるベトナムオフショア開発とは

　リクルートは今回のプロジェクトの前からベトナムでのオフショア開発にチャレンジしています。2012年から始めたこの取り組みは、数々の試行錯誤を経て「LaRue（ラルー）スキーム」というオリジナルの開発手法として確立しています。

　オフショア開発は海外に下流工程を委託し、完成物を納品してもらうのが一般的だと思いますが、LaRueスキームは下記の2点が異なります。

• 開発のほとんどの工程をオフショアメンバーと一緒にやり遂げる
• 単価差を利用することで発生する予算の「ゆとり」を最大限活用

　日本のエンジニアが「日本の企画担当者」と「オフショア先のエンジニア」の橋渡し役となり、要件定義フェーズの段階からそれぞれのエンジニアが連携しながら進めます。こうすることで、プロダクトの早いタイミングで日本とベトナム双方のメンバーの理解をそろえることができ、円滑な開発が可能になります。

要件定義からテスト工程までベトナム開発メンバーが対応

　オフショア開発は多くの場合、国内で開発を進めるよりもコストを抑えることが目的になります。リクルートにおけるオフショア開発では、単にコストを節約するのではなく、プロジェクトを洗練するための“ゆとり”として活用する狙いもあります。

　ゆとりがあれば「メンバーを増員する」「さまざまな開発技術の検証をする」「チームメンバーのスキルアップを目的とした育成プランを検討する」などプロジェクトやチームを長期的に成長させるための取り組みにコストを投資できます。

　ではこれを踏まえて、今回のプロジェクト「リクナビHRTech採用管理」でオフショア開発を活用しようと考えた理由について説明します。

リリースの先を見据えた体制構築

　リクルートはベトナムでのオフショア開発を活用し、多くの事業領域で成果を上げています。筆者もオフショア開発チームでのプロジェクト推進を経験しており、実際にベトナムへ行って現地のメンバーの立ち上げを実施したり、日本とベトナムという離れた拠点同士で連携しながら案件開発を推進したりしていました。

　このような背景や実績を踏まえて、今回のプロジェクトでもベトナムオフショアチームと連携できないかと考えました。「決められた予算の中で最大限の出力を確保すること」が主な目的ですが、それ以外にも大きな狙いがありました。それが「将来的なプロダクトの安定運営を見据えた開発体制の構築と維持」です。

　プロダクトリリースという短期的なゴールを目指すのであれば、コストの問題さえクリアすれば日本国内で開発者を募れば済む話です。しかし、プロダクトリリースはあくまでもマイルストーンの一つです。その先にある「プロダクト拡大と安定運用」も考えておくべき重要なテーマです。

　前述した通り、オフショア開発チームと連携することで開発組織の全体にゆとりを確保しやすい構造になっています。ゆとりは定常的に発生するため、プロダクトリリース後も開発チームを改善する活動に時間を割けます。ベトナムのエンジニアを育成したり、新規参画者向けの立ち上げコンテンツを拡充したりするなど「体制維持に向けた施策」にも取り組めるでしょう。

　こうした理由から今回のプロジェクトではオフショア開発チームとの連携を決めました。

　ただ、懸念点もありました。今回のプロジェクトは要件が流動的に変わる可能性があり、柔軟な対応が求められます。それまで実践していたオフショア開発スキームはウオーターフォール型の開発が基本だったため、やり方を変える必要がありました。

　ベトナムのオフショア開発チームで対応しているプロジェクトはレガシーな技術を利用することが多く、今回採用した「React」「Kotlin」などの技術は実際の案件で使用したことがない、という点も懸念でした（ちなみに技術選定の流れについては次回の連載で説明します）。

開発フローの違い

　こうした幾つかの懸念がある中でベトナムのオフショア開発チームを立ち上げるためには、さまざまな打ち手が必要になります。ここからはその内容について説明します。