“不確実性”を技術で解決してこそ「エンジニア」――リクルートが挑む内製化への道（2/5 ページ）

[大内孝子，ITmedia]

スマホアプリのコモディティ化で「スクラム開発」へとシフト

　「社員エンジニアにしかできないから始めた」スマートフォンアプリの内製化だったが、急速に開発者も増え、コモディティ化していった。そこで新たな取り組みとして始めたのが「スクラム開発」へのチャレンジだったという。

　「スクラムを取り入れた目的は『エンハンス』にあります。ちょうどそのころから、リクルート全体としても大規模な開発だけでなく、日々の細かな改善にも注力するようになりました。そこで、社員エンジニアが活躍するフィールドを徐々に広げていきました」（宮川さん）

　それまで、リクルートは各サービスが年次で大型の開発プロジェクトを進めるケースがほとんどだった。それと同様に、基幹システムも4〜5年の保守切れに合わせて作り変える。ウオーターフォール型の大規模プロジェクトが年間に何本も走っているという状態だったのだ。

　少人数のチームで素早く開発を行い、ユーザーからのフィードバックを取り込み、PDCAを回しながらサービスを改善していく。全社でスクラムの研修を受け、さまざまなサービスで試行錯誤を繰り返したという。

スクラムマスター研修やプロダクトオーナー研修を社内で実施したという（画像提供：リクルートテクノロジーズ）

　その結果、求人サイト「タウンワーク」や学生向けの授業動画サービス「受験サプリ（現：スタディサプリ）」、POSレジアプリの「Airレジ」などをはじめとして、スクラム開発が威力を発揮したプロダクトも多々あったものの、一方でうまくいかないケースがあることも分かってきた。

　「リクルートのプロダクトの多くはメディア型で、広告による収益を得ています。そうなると、広告に関する部分については、エンジニア中心でUIやUXを気軽に変更できません。営業を巻き込むとなると、『スクラムで小さく素早くやろう』という話が適用できなくなってくるんです」（宮川さん）

内製が向く案件と、向かない案件をどう判断するか？

　また、開発の規模もプロダクトによって大小さまざまだ。納期が決まっている大規模な開発など、スクラムには向かない案件も多いことが改めて見えてきた。

　どういうケースは内製で進め、どういうケースはパートナー企業にお願いするのか。この判断基準があいまいになっていることが、スクラムが広がり切らなかった理由ではないか――。そこで宮川さんたちは、内製と外注の連携を模索したという。