海外に開発拠点を置くオフショア開発。コスト面で大きなメリットが見込める反面、開発クオリティの維持や企業風土を伝えるのに難があるといったデメリットもあった。
現在、コスト削減を実現しつつ、国内開発を上回るほどの納期短縮・クオリティ向上を実現しているのがリクルートテクノロジーズ。リクルートグループ全体のサービス・プロダクトの基盤作り、ITの実装、そしてマーケティングを行っている企業である。「リクルートでは2000年頃に一度オフショア開発を試み、かなり手痛い失敗をした経験がある」と、リクルートテクノロジーズの執行役員でITマネジメント統括部兼ITソリューション統括部の片岡歩氏は振り返る。それでもなおこの分野に情熱を注ぎ込んだ意図と、試行錯誤の末にたどり着いた成功の秘訣を聞いた。
若手の声から、12年ぶりにチャレンジしたオフショア開発
――リクルートテクノロジーズがオフショア開発に着手したきっかけを教えてください。
リクルートグループでは、かつて2000年頃にインドでオフショア開発を試み、かなり手痛い失敗をしたことがあります。その後は「うちの会社はオフショアに向かないのではないか?」という雰囲気が広がった時期もありました。
しかし2012年頃になると、国内が不景気に陥る中、いかにしてコスト競争力のあるサービスを作るかという発想から、社内でもコストダウンを実現する手段が必要となっていました。そんな中、「オフショアにチャレンジしてみたい」という若いメンバーが現れたため、試験的にやってみようと考えたのが、オフショア開発に再チャレンジしたきっかけです。
――12年ぶりの再挑戦の結果、どのようなものが見えてきたのでしょうか?
初めはすべて、手探りな状態でのスタートでした。最初は数十人月規模の小さなプロジェクトから試してみて、続いてもう少し大きなプロジェクトをやってみて…。少しずつ失敗を積み重ねながら試行錯誤を重ねた結果、徐々に勝ちパターンが見えてきました。
例えば、結局オフショア開発であろうが国内開発であろうが、重要となるポイントは一緒でした。きちんと開発者に対して要求を伝えられているか? コミュニケーションできているか? というポイントが極めて大事なのです。きちんと伝えるためには、事前の明確な要件定義が必要。その点は国内開発においても同様です。
こうしたポイントを押さえられていれば、現地の人員単価が安い分、現地に我々のメンバーを多く送り込んでも、パートナー企業と国内で開発していた時以上にコストダウンが可能となります。その結果、むしろオフショアの方が開発スピードを今まで以上に上げたり、品質管理を徹底したりすることが可能であるとわかり、良い循環が回り出すようになりました。
また、メンバー育成という点でも大きな効果が見込めることがわかってきました。リクルートの大きなサービスの開発を担う責任と向き合うことで、若いメンバーでもすごく育つ…言語が通じない相手でも、自らの頑張る姿を通して、意欲や想いが伝わり、チームとして一丸となって開発を推進することができる。軸さえつくれば育つモデルができるのではないのかと今は考えています。
現地で一緒に取り組む、伴走型開発モデル―重視すべきは開発への意欲
――国内とのコミュニケーションはどのような手法を使われていますか?
現在は、日本国内で要件定義を行った後、開発工程時に現地入りするという「伴走型モデル」を採用しています。開発時は、国内の日本人と、現地の日本人を、テレビ会議で結ぶサンドイッチ構造のコミュニケーションを行っています。
例えば、常設のテレビ会議システムは24時間つながっており、国内の別の支社よりも近い感覚です。だいたい3カ月に一度、本人と会っていれば、業務の要件だけはテレビ会議だけでまったく問題ありません。現地のインフラが整備できてきたということも勝ちパターンの一つですね。
ベトナム人のスタッフの中に弊社の求めているコンテキストを理解してもらえる人も育ってきているため、今後は非常駐のモデルも検討しています。
――現地に行く社員の方はもともと海外の経験がある方ですか?
違います。海外経験よりも良いサービスを作りたいというモチベーションを重視しています。
現地では、1人の日本人スタッフに10人程度のベトナム人スタッフがつくのですが、指示が曖昧だと動いてくれません。要求をシャープにしなくても、日本人同士だと機能してしまうところあるじゃないですか。でも彼らにはそれがない。言葉がわからないから察してはくれない、ということを実感しました。
当初は全員で英語のコミュニケーションをしようと決めていたので、英語が得意な人、海外が好きな人をアサインしたのですが、技術も英語もできる人が少なく、ボトルネックになってしまいました。逆に、プロジェクトを進行する上では、英語ができなくても「良いものを作りたい」という当事者意識をもって開発がちゃんとできる人の方がフィットすることがわかってきたのです。
長い目で見る。それがオフショア開発の秘訣
――トラブルは発生しませんでしたか?
最初に一般的なオフショア開発の問題点について仮説を立てました。例えば、開発や製造だけ実施すると要件が伝わりづらいとか、プレイヤーが増えすぎると伝言ゲーム状態になってしまい効果が出にくいとか…。それに対して、例えば基本設計から一緒にやろう、ブリッジSEを置かずに現地に行こう、通訳なしで全員英語でしゃべろうとか、全部裏返しでやってみました。
しかし実際に実施していく中で、設計から携わってもらっても、要求の背景が伝えきれずテストがしきれない、現地入りした社員と国内との連携が希薄になる、英語力が開発のボトルネックになってしまう、というよう問題も発生してきました。そこで、要件定義からの全工程を一緒に行ったり、常設型テレビシステムを導入したり、文書のみ英語にして会話には通訳を置いたり…というような改善を行ってきたのです。
「うまくいかない可能性も十分にあるが、改善していくことが大切だ」というのがこのモデルの 宿命であり、醍醐味だと思っています。改善していくプロセスを続けることで良くなってきているのも事実ですし、オフショア開発で得たやり方を日本に逆輸入することもできるようになるなど、開発モデルとしてもかなり磨かれてきました。
新しい分野にチャレンジしてどう改善していけるかというのが我々の取り組み、ひいてはリクルートという組織文化の強みだと思っているので、今後もずっと続けて行ければと思っています。
――もしも他社がオフショア開発にチャレンジする場合、これまでの知見をもとにアドバイスをいただけないでしょうか。
一個のプロジェクトで結果を出せというのは不可能です。ある程度の時間軸…例えば3年、5年、といった時間軸でどう育てて、どう投資してというプランを立てて、ここまで待とう、という覚悟を持てないならやめられた方がいいのではないかと思います。
もう1つは、現場を見ていろいろと試行錯誤することが必要だと思っています。初めは言葉も通じず、うまくいかないことも多いので、ちょっと失敗した時に「スキル不足だ」「経験が足りない」と判断しがちだったりするのですが、そこをどうやって丁寧に現場とコミュニケートして、一つ一つ克服していけるかが重要です。
この2つを意識すれば、たぶんうまくいくと思います。もしチャレンジするのなら、長期的に見て、実験からやってみるのが良いのではないかと思います。