2021年に実施された7つの中核事業会社および機能会社の統合を経て、リクルートでは、組織やシステムの統合・再編が進んでいます。
当然ながら、組織やシステムは単に「くっつければいい」という単純なものではありません。アクションの解像度を一段上げると、それぞれに紐付く人材や制度をどうするか、過去との整合性をどのように担保するか、など乗り越えなければならない課題が数多く見えてきます。
以前掲載したこちらの記事では、総合後のデータ組織におけるアジリティの高さ、個別最適と全体最適のバランスを紹介しましたが、これらはどのようにして成り立っているのでしょうか。
今回は、統合の裏側で人材制度や基盤システムの調整を推進し、組織価値の向上に大きな貢献を果たした、データ推進室の阿部直之さん、竹迫良範さんが対談。リクルートの社内事例にとどまらず、組織論、システム論といったメタ領域まで話題が及ぶ内容となりました。
※この記事は株式会社リクルートによるSponsoredContentです。
- 分権化から集権化へ。そこで生じた課題
- 「正々堂々と前を向く」ためのガバナンス強化
- 領域特化組織と横断組織がシナジーを生む「マトリクス型組織」
- 「適材適所」で組織の価値を最大化させる
- 「多様性と包摂」を地で行く組織を目指して
分権化から集権化へ。そこで生じた課題
── 今回は、2021年に行われたリクルート社の組織統合に伴い、データに関わるエンジニア組織にどのような課題があり、組織がそれをどのように乗り越え、そこからどのような知見が得られたのかをお聞きします。まずはじめにお二人の役職、立場を簡単に教えてください。
阿部 データ推進室のなかで、主に人材育成の側面からデータサイエンスやデータエンジニアリングなどの各データ技術に関する専門性強化を担うデータテクノロジーユニットを見ています。
阿部 直之（あべ・なおゆき）
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室
データテクノロジーユニット長
竹迫 私はデータ推進室で、前回記事で紹介したCroisのような横断プロダクト（複数事業領域での利用を想定して開発されるリクルートの社内プロダクト）の開発を担うデータプロダクトユニット（DPU）を統括しています。
竹迫 良範（たけさこ・よしのり）
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室
データプロダクトユニット長
阿部 概ね竹迫さんはデータに関する領域横断のプロダクト、僕はそこで活躍する人材を見ていて、ともに横断組織の人間という理解で問題ありません。
── 早速、統合時の“カオス”を深掘りたいのですが、リクルート社は一度分社化（2012年）していますよね。まずは分社化のタイミングにさかのぼって当時の組織体制をご紹介いただけると、統合時に噴出した課題の背景を知ることができるように思うのですが。
竹迫 分社化当時は権限の委譲が大きな目的でしたから、まずは大きく「機能会社（開発や管理など特定分野に特化し、リクルートグループ各社の事業推進をサポートする会社）」と「事業会社（事業を展開する会社）」に会社組織を分割し、各社にIT投資の執行責任者を設けたり、独自の人事制度を設けたりしました。
── なるほど。しかし、そうした権限の委譲は権限集中が欠かせない統合時に大きな障壁となったのではないでしょうか。
竹迫 はい。データ推進室の事例でお話しすると、統合（リクルート社の統合に先んじた2020年4月）前に各社からデータに関わる人が集まってふさわしい組織の形を議論したのですが、やはり「各社のデータ、そしてデータに強い人を1箇所に集めるのはなかなか難しいね」という話になりました。
── 具体的にどのような点に難しさを感じたのでしょうか。
阿部 大きく分けると「システム」と「組織」の2点だと思っていて。まずシステムの面では、各組織のデータ基盤に関する取り組みにバラつきがあったことです。使用しているプロダクトもシステムも違うので、まずはそのバラつきを可視化しなければなりませんでした。
後ほど詳しくお話ししますが、統合前に各社が作っていたプロダクトは全体管理されておらず、結果的に、データ基盤が分からない、名前を知っていても用途が分からない、用途を知ってても制約事項が分からない、という状況で有効活用できていませんでした。
竹迫 恥ずかしながら、リクルートの中の話を外部のカンファレンスで知る、ということも多かったですね。
阿部 そんなこともありましたね。もちろん組織のあり方も、人材定義や報酬テーブルなどの人事制度をはじめ、情報共有のあり方など、すり合わせなければならないことが山積みでした。
「正々堂々と前を向く」ためのガバナンス強化
── システムと組織の両軸で課題があったとのことですが、いずれも一朝一夕に解決するのは難しいように思います。課題の優先順位をどのようにしてつけ、どのようにしてそれらを乗り越えていったのでしょうか。
阿部 まずは足場を固めなければいけない、との思いでデータの持ち方やセキュリティ面からのデータ基盤のあるべき姿から議論しました。我々が2020年に制定・施行したパーソナルデータ指針に基づいて、全社的なガバナンス強化の流れを受けて「世の中で正々堂々と前を向いて」データを活用するには何をすればいいのか、どういうルールが必要で、どういうデータ管理や利活用の方法が妥当なのか。プライバシー専門組織での検討を強化するのに加え、データ推進室としても、そうしたトピックについて議論を深めて、データ基盤に関するガバナンスの強化を進めました。
私自身は一連の議論の中で、竹迫さんからもらった「ユーザーさんのデータは『お借りしているもの』」という言葉がとても印象に残っていて。単に個人情報保護法を守るだけにとどまらず、データの活用はユーザーのためになるものとする、結果的に会社として正々堂々と取り組むことができる、という状態を目指したんです。
竹迫 我々が取り扱うデータは「会社のもの」ではなく、お客様から同意をいただいて一時的にお預かりしているものです。他のデータと混ぜて使うクロスユースについては事前同意が必要ですし、利用目的を事前に明示することで「こういうクロスユースはある」「その用途以外には利用していない」とはっきり言えるようになる、と考えたんです。
──なるほど。「データは借り物である」という思想が大前提となって、そこにさまざまな施策が紐付いているわけですね。では、先ほどお話しいただいた課題は、具体的にどのような手法で解決していったのでしょう。
阿部 「システム」の側面では、まず各組織がどんなプロダクトを作っていたのかを知るため、プロダクトの情報を1箇所にまとめてカタログ化しました。それをやって分かったことは、情報整理の大切さ。「こういうプロダクトが欲しいというものを実は以前に作っていた」ということもあり、車輪の再発明を防ぐことを目指しました。
竹迫 リクルートは、それぞれの現場で必要だと感じたものを自分たちで作り始める文化があり、統合前は各社個別のシステムがそれぞれ独自に進化していました。そのため、整理する中では、実に数百種類ものプロダクトが出てきましたね。
阿部 もっとも、機能が完全に重複しているものは案外少なかったのですが、複数プロダクトの連携も含めて組織全体として有効活用をするためにも整理が必要でした。
そうしてプロダクトを整理するなか、安易な標準化や共通基盤化をやらないことも決めました。もちろん、元々の資産を有効活用する観点もありますが、共通化することで得られるコスト面などのメリットと個別ケースにおけるパフォーマンス低下というデメリットの可能性を天秤にかけた場合、無条件で全てを共通化することは必ずしも合理的ではありません。
──システムの統合と聞くと、標準化や共通基盤化をすることが前提となっているイメージがあるのですが……。
阿部 僕らは領域ごとの特性を踏まえて個別に判断しました。例えば、レコメンデーションの機能も、事業領域ごとにデータの特徴や量が全然違いますし、ドメイン特化で得られる性能面の良さを殺してまで標準化、共通化する必要はありません。
一方で、比較的低い技術レイヤー、例えばワークフローエンジンであるCroisのようなドメインロジックに影響しづらいプロダクトは共通化のメリットが出てきます。そのように共通化によってメリットを得られる箇所を見極めながら丁寧に進めていきました。
──見極めながら方針を決めるには時間や手間もかかりそうですが、現場の混乱は少なそうですね。
阿部 はい。ドメイン特化の良さを取るか、共通化を進めるか、どちらかに寄せれば話は簡単ですが、“健全に”対立させて判断した方が全体として最適なバランスになります。ただ片方に寄せただけでは、システム全体としてのバランスを欠いてしまいますから。
竹迫 例えば、昔Hadoopで作った各事業のデータ活用バッチを、共通のBigQueryの受け皿を作ってマイグレーションして段階的に置き換えていった、という事例はありましたね。
──リクルート社のシステム統合が共通化と個別最適化の軸の両面で進んだことが分かりました。そして、「えいや」でシステムを統一するのではなく、個別の事案ごとに判断するのが、結局は合理的であるわけですね。
竹迫 強制的に「この社内システムを使え」と指示したら、エンジニアもいい気はしませんから。
阿部 目指すところは決めつつも、技術的な選択肢は現場に委ね、目指すところへの「登り方」を一緒に議論したという感じですね。
── 「こういうシステムを使いなさい」ではなく「どういうやり方がいいか議論して現場で判断しましょう」という。
竹迫 はい。Croisの横展開では「Dev（開発）とOps（運用）を分けた」という話もありましたが、これもクラウド版のGithub.comとオンプレミス版のGithub Enterprise Serverのように、両方ともニーズがあるわけで、そこは組織のニーズに合わせて個別最適の道を探る方がいいと思います。
領域特化組織と横断組織がシナジーを生む「マトリクス型組織」
── ここまで主にシステムやプロダクトの側面から統合の内実を見てきましたが、組織体制にはどのような変化があったのでしょうか。
阿部 各領域のデータ戦略については領域組織が、セキュリティやプライバシーのようなガバナンス観点の基準はデータ推進室外の専門組織とも連携しながら、横断組織が主導で整備し、各事業領域は組織主導にするという組織体制をつくりました。
これが、領域に関する組織と専門機能に関する組織を交差させた「マトリクス型の組織」です。
── おおまかに、縦軸（領域組織）は個別最適化、横軸（横断組織）は共通化の取り組みを行っている、という理解でよいのでしょうか。
阿部 はい。領域組織が担うデータ戦略は、事業ごとのビジネス構造や業務フローを踏まえて定める必要があり、個別最適化のメリットが大きい分野です。
一方、横断組織が担うガバナンスや人材採用・育成は、業務効率化して各領域のパフォーマンスを最大化させる観点でも、共通化のメリットが大きい分野です。
この2年間はそのマトリクスの中身を調整しながら各ユニットの役割を整備してきました。
── Croisのような各事業領域で活用されるプロダクトの開発やデータのマネジメントは横断組織が担っているのでしょうか。
阿部 そうですね。（統合の）初年度にはまずデータ基盤やデータ関連アプリケーションに関する開発やデータマネジメントを行うユニット（データエンジニアリングユニット、データマネジメントユニット）を作り、そこと並列で横断プロダクトの開発とR&D（研究開発）を担うデータプロダクトユニットを追加配置していった形です。
戦略面で言うならば、ガバナンス強化の面では一定の成果が出てきたので、2022年からは縦軸の領域戦略を強化する方向にシフトしています。
「適材適所」で組織の価値を最大化させる
── さまざまな決断や取り組みの内容をお伺いして、リクルート社には議論の文化が根付いているように感じました。ただ、現場が議論して判断する上では情報共有も大切だと思います。例えば、先ほど話題にのぼったマトリクス型組織ではどのようなやり方を採用されているのでしょう。
阿部 事業領域をまたいだレビュー会を開くなど、人やナレッジをつなぐための時間を意識的に増やしています。
私自身も最低月1回は、自分のユニットのメンバー300名に話す時間を作るようにしています。最近の組織的方針や他領域の良い取り組みを雑談ベースで話します。
── 領域横断の取り組みでこそ、そうした情報共有の活動が必要になりそうですね。
竹迫 そうですね。そうした情報共有に加え、人や組織の個別の強みに着目することも意識しています。これは情報共有と同じくらい有効です。組織全体の力を高める上での方針は大きく分けてトップアップ（個別最適による組織価値の引き上げ）とベースアップ（全体最適による組織価値の引き上げ）がありますが、前者を目指す場合、新しい開発を始める際にまず阿部さんと連携する。阿部さんは現場のさまざまなニーズをくみ取った上で、「この横断プロダクトを使った方がいいんじゃないか」とアドバイスしてくれるので、知識や議論のレベルが引き上げられます。
阿部 ステークホルダーに情報を行き渡らせることが最初の一歩として重要なので、自分はそこに徹することが多いです。実際にどのように進めるかの選択自体は現場に任せています。その結果生まれてくる各領域の取り組みで、トップアップの動きを推進しています。
ベースアップの側面では、各領域のデータ基盤やデータマネジメントの成熟度を可視化して「どこを目指せばいいか」が分かるようにしました。その上で、人をベースに、ある領域で先行しているプロジェクトの事例を別領域に横展開する。例えば、住まい領域で活躍した人材をHR領域にアサインしたりするなど、形式知だけでなく人に属する暗黙知ごと展開していくイメージです。
凸凹（でこぼこ）を均して平均的な組織や人材をつくり上げるのではなく、それぞれの強みを活かしていく中で、全体のアベレージを上げていくのが私たちのやり方です。
竹迫 リクルートの場合、人と人がつながると、データがつながり、仕事もつながる傾向にありますね。
阿部 少し話はそれますが、リクルートには「よもやま（特に議題を決めずよろず相談をする場）」の文化があります。僕も若い社員から「『よもやま』させてください」とアポを打診されて、1 on 1で話すことがよくあるんです。役職者との距離の近さがある。
竹迫 「よもやま」で思い出したのですが、新入社員が社長に「よもやま」のアポを入れたという武勇伝もありましたね（笑）。私のところにも、よく「話をしたい」という人が来ます。
阿部 これも余談ですが、前職時代に地方でWeb開発などを行っていた僕にとって竹迫さんは「神」でした。竹迫さんがリクルートに入ってから、直接会ったときは緊張しましたね。リクルートは組織サイズも大きく多様性が高い分、このような出会いも多いです。
「多様性と包摂」を地で行く組織を目指して
── そんな阿部さん憧れの竹迫さんは、改めて組織統合を振り返って、今どういう思いですか？
竹迫 「日本の組織で長期間まだ解けていない課題を解決する道筋をつけたい」という思いを新たにしました。
私自身は最終的には日本全体のデジタル化を進めたいとも考えていて、それを達成するにはリクルートにいながら試行錯誤した方が解決しやすいと思っていて。例えば、日本の各自治体で動いているバラバラのシステムをどう統合するか、という“みんなが困っている難問”の解決方法は、リクルートの統合事例にヒントがある気がしています。
大企業は、ただ規模が大きいだけでなく、部門ごとに独自に発展してきた組織文化があって、それぞれ「城主」みたいな人がいます。システムの統合を進める上では、彼らにどういう順番で合意形成をしていけばいいのか。活用できるエッセンスが結構あったりします。
阿部 リクルートの分社化から統合までのプロセスも、自治を強めていた組織をまとめていく、という色合いが濃かったですね。
竹迫 まるで明治維新のような。
阿部 まさに。同じ社内でも、ビジネスモデルが違うと重視する部分が違う。素早く検証することを重視する組織もあれば、間違いがないことを重視する組織もある。両方大事なのですが、イデオロギー対決になりがちなので、そこをちょっとずつ解きほぐしてまとめていくことが大切です。
── システム統合、組織作りに続く最新の課題はなんでしょうか。
阿部 取り組んでいる課題の解像度をさらに高めることです。人材要件の定義も進めているものの、まだ完璧な形にはなっていません。まだまだ活躍できる素地を持つメンバーがいると考えていて、彼らがもっと活躍できる状態をどう作ればいいのかを日々模索しています。
例えば、半期ごとに行われる人材開発委員会では、直属の上長だけでなく他の組織長も交え、一人ひとりのキャリアパスについて議論します。その中で、この人はこういう得意分野があって、このプロジェクトにアサインすればより価値を発揮できる、といった議論を元に、さまざまなチューニングを実施しています。
竹迫 人事の仕組みは、私たちデータ推進室が先駆けて変えてきたところもありますね。与えられた制度をそのまま使うのではなく、環境に合わせて改善する、という考え方で。直近の例を挙げると、新たな取組みとして、データ人材のスキルセット定義やキャリアラダー設計、スペシャリスト職の新設といった施策が行われました。
── 人事制度も「システム」だから、どう改善するかというモチベーションで見てしまう感じですね。
阿部 そこはエンジニアの「性（さが）」かもしれません。
竹迫 インターネットのシステムを作っている人は、「システムは変えられるもの、自分たちで作れるもの」という前提で動いていますから。
── それにしても、やるべきことが山積みですね。
阿部 正直、時間が足りません。もっとたくさんの人に協力してもらいたい。
竹迫 先ほど凸凹な人材、という話も出ましたが、同時に人材の多様性も担保したいですね。短期間で一気にものを作る「狩猟民族」的な人と、地道な改善を積み重ねていく「農耕民族」的な人の両方が必要だと感じています。
阿部 マネージャーの役割は、彼らが交流する「市場」を整備するイメージです。お互いが大事にするところを尊重し合い、単に仲良くするというわけではなく、それぞれの意見をぶつけ合える。そういう意味での健全な対立構造をどんどん作っていきたいですね。
── 多様性の尊重と包摂（ダイバーシティ＆インクルージョン）を実践している形ですね。
阿部 はい。リクルートはけっこう「地」でそれを行っています。
竹迫 エンジニアだけでも、ナード（オタク気質）な人もいればビジネス系の人もいて、さまざまなエコシステムの中で自分に合った場所を探せる環境だと思いますね。
── ありがとうございました。
阿部さん・竹迫さんが所属するデータ推進室の公式ブログはこちら
株式会社リクルートではエンジニアを募集中！
今すぐの転職を考えていなくても、希望職種に関する情報やスカウトを受け取れるキャリア登録の仕組みも用意されています。少しでも興味のある方は👇気軽にクリック！
さまざまな取り組みの裏側やナレッジ、厳選した採用情報もSNSで発信中！
🎁 Amazonギフト券が当たる！ リクルートに関するアンケート 📝
※アンケートは終了しました。ご協力、ありがとうございました。
Amazon.co.jp は、本キャンペーンのスポンサーではありません（株式会社はてなのキャンペーンです）。
Amazon、Amazon.co.jp およびそのロゴはAmazon.com, Inc. またはその関連会社の商標です。
関連記事
そのほか旧リクルート各事業会社によるSponsoredContentもあわせてお読みください。
[SponsoredContent] 企画・制作：はてな
取材・構成：星暁雄
撮影：小野奈那子
