プロダクト開発ディレクター プロダクトディベロップメント室 アプリケーションソリューションユニット オフショアソリューション部 オフショア開発1グループ 小池 亮義 Akiyoshi Koike

大規模な開発プロジェクトが豊富で、
主体者として強い責任感を持って取り組める。

どのような魅力と可能性を感じて、リクルートを選んだのでしょうか。

リクルート入社以前は、SIerに勤めていました。要件定義、開発、テスト、保守運用など、エンジニアとして基本的な業務を経験。そんななか、30人規模のプロジェクトリーダーを経験したのですが、技術力よりも営業のような力を徐々に求められるように。エンジニアとしてのキャリアを歩みたかった私は、エンジニアとしてスキルを高められる環境を求め転職を決意しました。
転職先としてリクルートを選んだのは、リクルートがユーザー数の多いWebサービスを複数保有していること、それに伴い大規模プロジェクトが多いこと。また入社後に実感したことですが、リクルートには個を尊重する企業文化があり、それぞれの持つ強みを活かしながらプロジェクトに携わっていけます。より大きなプロジェクトに挑戦したい、強みを活かして勝負したいと感じる私にとっては、まさに求めている環境でした。

どうすれば事業にとってベストな開発が実現できるか。
協働者の声に耳を傾けつつ、一歩引いた視点で提言していく。

仕事内容とミッションについて教えてください。

入社以来、オフショア開発を担当する組織に所属しています。オフショア組織は特定の事業領域を担当するのではなく、プロジェクトごとに担当をアサインしていくような事業横断組織です。そのため、住まい領域、進学領域、結婚領域、SaaS領域…と常に多様なプロジェクトを担当できるのは、私が感じる面白さのひとつ。組織内の各グループでは5〜10案件が常時動いており、各プロジェクトに関わるフェーズや内容もさまざまです。ゼロから新規プロダクトを開発する案件もあれば、既存プロダクトの機能追加、古い技術で動いているシステムを最新の技術に刷新するプロジェクトまで多岐に渡ります。

リクルートのエンジニアとして私が大事にしているのは、社内外のステークホルダーの思考や力量を考慮しつつ、一歩引いた視点でプロジェクト全体を見渡し「リクルートのビジネスにとってシステム開発をどう進めていけば、広く社会に貢献していけるのか」を考えるようにすること。また、サービスの企画担当者からオーダーがあった場合も同様で、担当者の要望にそのまま応えるのではなく、開発要件を俯瞰して、こちらから提案することも大切な役割です。「この機能って本当に重要ですか。もしこれが今すぐ必要なければ、リリースを1ヶ月早められますよ」と、事業にとってベストな選択ができるように開発サイドからも積極的に提言しています。

コスト削減だけが価値ではない。
開発体制の選択肢を増やす、オフショア開発の価値。

仕事の面白みについて教えてください。

オフショア開発というと一般的にはコスト最適化を目的とする印象が強いかもしれませんが、リクルートのオフショア開発は決してそれだけを目的としたものではありません。例えば開発体制を柔軟に拡大できることもそのひとつです。日本は慢性的にエンジニアが不足しており、人を増やせないために仕方なくスケジュールを延ばして対応しているケースが多いと感じます。しかし、海外のエンジニアに開発を担ってもらうオフショア開発ならば、「一時的に大勢のエンジニアに協力を仰ぎ一気に開発を終わらせる」といった、国内だけではなかなか実現しにくい手法も可能で、状況にあわせて最適な開発手法を選択することができます。

そうした利点がある一方で、オフショア先とのコミュニケーションのちょっとしたズレが大きなトラブルに発展するリスクも高いですし、言葉の壁や思考の違いなどもあって、運用は決して簡単ではありません。ですから、入社してしばらくはオフショアに対する苦手意識が拭えなかった時期もありました。しかし、スキルもバックグラウンドもさまざまな人たちが集まったプロジェクトに身を置き、マネジメントによってプロジェクトを成功に導いていくことは、私がエンジニアとして目指す理想の姿。オフショアは、大規模なプロジェクトに携わることでエンジニアとしてスキルを磨いていけるだけでなく、開発マネジメントのスキルも磨ける最適な環境であり、自分を成長させながら積極的に取り組める仕事だと感じています。

プロジェクトの失敗に挫けず、
開発マネジメントの改善活動をスタート。

これまでの経験の中で印象に残っているエピソードを教えてください。

ある失敗をきっかけに、オフショア開発に抱いていたネガティブイメージを払拭できた事が特に印象に残っています。それは2018年頃のことです。WebサービスのDS(ダイナミックサービング)化プロジェクトを、オフショアで引き受けることになりました。PHPで組まれているSP版の既存ページを、PC版と同じJavaにコンバートするというものでした。そこで、オフショア先のメンバーに試しに数ページつくってもらったところ、問題なく移行できているようだったので、このまま進めるように指示を出しました。しかし、その後上がってきたものは細部の詰めが甘く、まともに動作しているとは言えないレベル。慌ててシューティングに入り、ギリギリ納期までに間に合わせましたが、開発マネジメントをする自分の役割としては反省点の多いプロジェクトでした。

ですが、ここでオフショア先のせいにせず、「二度と同じことを繰り返さないためには我々のマネジメントをどう変えれば良いのか」と考え抜いたことが私の転機になりました。この失敗を糧に、プロジェクトの成功率を上げられる開発マネジメントの改善活動に踏み出したのです。失敗の原因はなにか、それを未然に防ぐには何が効果的なのか…。過去の事例から傾向も洗い出し、導き出した仮説を次のプロジェクトで検証するなど、実践的なトライアンドエラーの繰り返しを意識高くやり続けブラッシュアップしていきました。
この活動は、リクルートの横断領域で多様なプロジェクトを実行している私たちの組織特性とも相性が良かったと思います。さまざまな案件でマネジメント手法の効果検証をしていく機会が豊富にあり、そんなトライを続ける中で、「開発各論における現場感を持ったマネジメント」と「大人数を動かす開発マネジメント」がプロジェクトの成功に大きく寄与することが分かりました。オフショア開発は必然的に大規模なプロジェクトになることが多いので、技術的各論を理解しプロジェクトの工程を熟知することで、いかに開発工程で発生しうる課題を減らせるか。また、大人数で開発する際は各工程の開発ルールをある程度定義することで、トラブルが発生した際に全体を見渡した上、打ち手が講じやすい。こういった成功の方程式が見えたからこそ、オフショアに対してこれまで以上の可能性を見出せるようになりました。

オフショアで培ったナレッジを活かして、
エンジニア人材の新たな育成スキームをつくりたい。

リクルートで働く魅力と、今後の目標について教えてください。

上述の改善活動を通して私が魅力に感じているのは、個人の強みや興味を尊重し、それぞれの得意なやり方で組織に貢献することを良しとするリクルートのカルチャーです。手段や方法は個人の意思に委ねられている部分も大きいからこそ、私はオフショア先の問題に当事者意識を持って本気になって取り組めたのだと思います。それに、開発マネジメントの改善活動に乗り出したのは、誰かに言われたからではありません。私の場合は、「本質的な課題を見つけて打ち手を検討する」といったやり方が得意だったため、そのやり方で事業やその先にいるユーザーの役に立ちたいと強く思い、研究を始めました。
さらに、立場を越えてフラットに意見しやすいところもリクルートで働く魅力です。「誰が言ったか」ではなく「何をしたいか」を大切にする文化があるからこそ、入社年次や役職に関係なくチャンスを自分次第で創り出せます。

私の改善活動も自分が思っていた以上に展開し始めています。もともとはオフショア開発の成功率を上げたいと思って始めた活動でしたが、効果的な開発マネジメントのポイントを整理・解明していった結果、他の開発組織からも「若手メンバーにオフショア組織を経験させて、開発マネジメント力を鍛えて欲しい」といった声が寄せられるようになってきました。そうした意見もあることから、今は自分が所属するオフショア組織に「エンジニア人材の育成プラットフォーム」としての新たな可能性を感じています。だからこそ、今後は人材育成スキームをつくることにも挑戦したい。私たちのもとで育ったエンジニアが10年後20年後にリクルートのシステム開発を引っ張る人へと成長していくことが、私の目標です。

記載内容は取材当時のものです。

データ推進室の
特設ページはこちら

データとテクノロジーで社会価値を最大化せよ。

おすすめのインタビュー記事

to top