「優秀な人材の確保と育成」が難しくなる一方の少子高齢化時代。企業が競合他社に先駆けて、戦略的な人材開発や人事配置を実現するためには「自社の人材の価値を正確に可視化し、いつでも最新の人事情報にアクセスできる情報基盤」が欠かせない。
しかし、多くの企業がこうした人事情報基盤の構築に挑んでいるものの、人事マスタの構築や周辺システムとのデータ連携などに手間取って思うような成果を上げられないのが実情だ。
この課題を企業はどのように解決しているのか──。AnityAが2021年4月20日に開催したイベント「戦略人事へのシフトを妨げる『人事マスター不在』問題、データ連携でどこまで解決できるのか」では、わずか1年で人事系システムの刷新と統合を遂行した楽天グループの事例をベースに、解決策を探るためのパネルディスカッションを行った。
本イベントの前半では楽天グループ株式会社 コーポレート情報技術部 プロダクトマネージャ 一見仁氏が登壇し、同社がここ数年間進めてきた「Workday全面導入によるグローバルHRIS（Human Resource Information System：人事管理システム）構築プロジェクト」について紹介した。その内容は別途、Darsanaの記事「困難だった人事系データの集約、解決のカギは『中間DB』経由の連携──楽天グループの人事戦略を支えるシステムとは」で紹介しているので、そちらをご一読いただきたい。
イベントレポートの後編では、一見氏のプレゼンテーションの内容を受けて、イベントの後半で行われたパネルディスカッションと、視聴者から寄せられた質問にパネリストがその場で答えるQ＆Aセッションの模様をお届けする。
パネルディスカッション参加者
・楽天グループ株式会社 コーポレート情報技術部 プロダクトマネージャ 一見仁氏
・Ascender Japan株式会社 カントリーディレクター兼CTO ブライアン・ツァイ氏
・ワークデイ株式会社 Japan Consulting Services マネジャー 石渡理氏
・モデレーター：株式会社 AnityA（アニティア） 代表取締役 中野仁
「HCM」と「ペイロールシステム」のどちらを上流に置くべきか？
中野： 楽天グループさんの事例で驚いたのは、わずか1年という短い期間でHCM（Human Capital Management：人材管理）システムのグローバル統合を成し遂げ、しかも世界中のすべての拠点や子会社で一斉に同じタイミングで運用を始める「ビッグバン導入」を敢行したという点ですね。これは本当にすごいことだと思いました。
それとともに、「中間データベース」という独自のデータハブの仕組みを導入して、システムの最上流に位置するWorkdayと、その下流に位置する各種システムとの間のデータ連携を疎結合モデルにした点もとても印象的でした。
データハブは、私も個人的にとても優れたアーキテクチャだと思っていて、いろいろなところで推奨しているのですが、この楽天グループさんのデータハブの仕組みは、Workdayの導入と同時並行で構築したのですか？
一見氏： 実は、この仕組みはWorkdayの導入前からあったもので、現在ほど広くは活用されていなかったものの、もともと提供していました。Workdayの導入に合わせて管理する情報の種類や量を増やすためにエンハンスを行ったというのが実際のところですね。
石渡氏： 私もWorkday側の担当者として楽天グループさんのプロジェクトに関わったのですが、このような仕組みを通じてWorkdayと他システムとの間を疎結合の関係にしてもらえると、Workday側の自由度がとても上がるので助かるんです。
例えばWorkdayは「組織」の考え方が、日本の一般的な業務アプリケーションとはかなり異なっていて、この点を上手に生かすことでWorkdayならではの良さを発揮することができます。しかしその分、他のシステムと連携する際には、Workday独自の組織の仕様を理解して合わせてもらう必要があります。
もし、Workdayと他システムとが密結合されていると、すべてのシステムの担当者にWorkday独自の組織の考え方について説明して回って対応してもらう必要がありますが、楽天グループさんが構築した中間データベースのような仕組みを間に置いて疎結合化されていれば、データハブでデータ仕様の差異を吸収できますから、Workdayの機能をより大胆に活用できるようになります。そういう意味では、これは非常に先見性のあるアーキテクチャだと思います。
中野： 一方でWorkdayのような外資系アプリケーションは、日本特有のペイロール（給与支払い）の考え方に対応するのが苦手な面もあります。ペイロールのアウトソースベンダーとしてさまざまな会社のペイロール業務を支援してきたブライアンさんは、このあたりについてどのような印象を持っていますか？
ツァイ氏： 確かに外資系ベンダー製品の大半は、日本特有の給与業務に必要なすべてのデータに対応しているわけではありません。実際、弊社のお客さまの中にもWorkdayをお使いの企業が何社かいらっしゃいますが、どこも「給与用データをどのシステムで管理するか」に悩んでいます。ある企業では、すべての給与データを無理やりWorkdayに突っ込んでいる一方、別の企業では別途ワークシートで管理したりしています。
石渡氏： Workdayの導入プロジェクトでは大抵の場合、ペイロールシステムとのデータ連携が必要になってくるのですが、そこで往々にして問題になるのが「Workdayとペイロールシステムのどちらを上流に置くか？」という点です。
当然、上流に置いた方がデータを出すだけで済むので楽なのですが、エンドユーザーの使い勝手を考えると、Workdayの画面を直接使ってもらうよりも、ペイロールシステムの操作性に優れたUIを使っていただいく方がいいことも多々あります。従って私たちとしても、一概に「Workdayを上流に置くべき」とは断言できないんですよね。
ツァイ氏： ペイロールベンダーの立場としても、必ずしも「ペイロールを最上流にしてください」と言うつもりはありません。それより大事なのは、「この情報はWorkdayが上流」「この情報に関してはペイロールが上流」というように個別に上流・下流関係を定義するのではなく、思い切ってすべてを片寄せしてしまうことです。
そうしないと、互いのデータの同期をとるのに本当に苦労しますし、まさにこのイベントのテーマである「人事マスタ不在」の状態に陥りかねません。
中野： 「正しいデータはどこにあるか」が分かるデザインをすることが大切で、誰かが明示的に決めなければならない。プロセスだけを見ていると欠落しがちな視点ですし、結果的に、データのダブルメンテナンスとレポート作成に膨大な手間がかかり、運用が非効率になりがちな部分ですよね。
安易にアウトソースするべきではない業務は
ツァイ氏： BPOベンダーに業務をアウトソースする際のもう1つの大きな問題が、「丸投げ」ですね。
お客さまから「業務のすべてを丸ごとアウトソースしたい」という要望をいただくこともあるのですが、たとえ双方合意の上できちんと計画を立てて、フルアウトソースがうまく機能したとしても、中長期的にはお客さま側で業務に関するナレッジやノウハウが徐々に失われていってしまう──というデメリットがあります。
その結果、いざ「アウトソースベンダーを変えたい」「業務プロセスを変えたい」ということになっても、業務プロセスが完全にブラックボックス化されてしまっているので、結局のところ業務を知っているベンダー側に頼らざるを得なくなってしまいます。
一見氏： ただ、アウトソースベンダーにとっては、結果的に顧客を囲い込めますから、そういう状況はむしろ好ましいのではないでしょうか？
ツァイ氏： 確かにそういう面もまったくないわけではありませんが、アウトソースベンダー側の担当者も未来永劫、その会社で同じ顧客を担当しているわけではありません。異動や退社で担当者が変わることは決して珍しくありませんから、ベンダー側のノウハウも徐々に失われていってしまうリスクがあります。
そうなると「顧客側もベンダー側も業務の中身を知らない」という「完全ブラックボックス化」の状態に陥ってしまい、現行業務にまったく手を付けられなくなってしまいます。
中野： 私もアウトソースサービスを使う側の人間として、一見さんと同じくベンダーロックインのリスクは常に、頭の片隅に置いていました。
でも、よくよく考えてみれば、アウトソースベンダー側でも人員の入れ替えは当然発生するでしょうし、その際に後任の担当者にすべてのノウハウが完璧に引き継がれる保証はありませんから、ベンダーに丸投げしているうちに、いつの間にか業務プロセスを把握している人間が企業側にもベンダー側にもいなくなってしまう、ということは十分あり得ますね。
そんな状態で業務プロセスに手を加えるとなると、もはや高額な費用を払ってコンサルタントを雇って、現行業務の棚卸や分析から始めなくてはなりません。
一見氏： 逆に言うと、どのような給与関連業務をアウトソースすることなく、自社に残しておいた方がいいと思いますか？
ツァイ氏： その会社特有のナレッジを必要とする業務は、やはり安易にアウトソースすることなく自社で持ち続けておいた方がいいと思います。
たとえば、とある金融系のお客さまは退職金制度の運用を弊社にアウトソースしていただいたのですが、先方の担当者が途中で替わったりしているうちに、制度や業務に関するノウハウが失われていってしまいました。
その後「制度を変えよう」という話が持ち上がった際、現行制度についてきちんと把握している方が先方におらず、検討がかなり難航した記憶があります。
中野氏： やはり主導権を安易に明け渡してしまうと、その後、いざ「現行の仕組みを変えよう」という話になったときに、自分たちではもうどうにもならなくなってしまうんですよね。
これはBPOだけでなく、システム構築においても同じことが言えます。外部パートナーにすべてを丸投げしてしまうと、いざ「システムを変えよう」と思っても自分たちにはノウハウがないため、結局は外部パートナーの言いなりになるしかありません。
このような外部パートナーとの「いびつな関係」は、いろいろな意味で不健全な形になりやすい。なので、「業務やシステムのコアとなる部分は、自社でしっかり持ち続けることが大事」だと思います。
データに関する主権を手放し、構築と運用ノウハウを「外部に丸投げ」すると、システムの刷新や修正を考える時に、仕組みの面でもコストの面でも副作用が強く出てしまう。また、システムは入れ替わることを前提にしてアーキテクチャを設計し、実装するための計画や体制を作っていくことが重要です。
そういう意味では、HCMシステムの入れ替えの可能性を当初から考慮した楽天グループさんのアーキテクチャ設計は、やはり先見性があったと言えそうですね。
HRISの必要性を経営層に理解してもらうためには？
中野： ここからは、視聴者の方々からの質問にお答えします。まず1つ目の質問は「人事マスタの整備をどの領域から行っていくべきか、領域の選定基準や手順といったマスタ整備のノウハウを教えてください」というものです。
一見氏： もし、将来的にグローバルレベルでワークフォースマネジメントやタレントマネジメントを本格的に行っていきたいと考えている場合は、やはり等級やグレードなどの情報はあらかじめグループ内できちんと統一しておく必要があると思います。
また「どこで何人の人たちが働いているか」というヘッドカウントの情報をきちんと管理できることはもちろんですが、加えてその人たちが、それぞれ「どんな仕事をしているのか」「どんな能力を持っているか」という情報を、グループ横断で共有できるようなデータ管理の仕組みを早い段階で整えておくことをお勧めします。
石渡氏： 日本の会社は、そうしたスキル情報を個別に管理することなく、所属組織の情報で穴埋めしようとすることが大半なのですが、例えば一見さんがかつてそうだったように、開発部門に所属しながら人事の仕事をしている人だっているわけです。
従って組織の情報だけでは、「その人が本当に何をしているのか」を正確に把握することはできません。「社員一人ひとりが何をしているのかを正確に把握できるような仕組み」がなければ「ジョブ型の人事」など決して実現できないと思います。
中野： ジョブ型に近い運用をしようとすると、「HRISに入力する必要がある属性情報」はグッと増えますね。旧来の管理は極端な話、人件費の予算と実績、そこに給与支払いができれば良いわけですから。一方、ジョブ型になると、職務の要件定義から評価までを細かい粒度で定義しつつ、評価とセットで管理する必要がある。さらに、人材の流動性が上がる可能性が高いので、データで残しておかないと運用が厳しくなる。
システム的に言うと、旧来はPayroll・TimeTracking（勤怠・労務管理）のような管理系システムが重要だったのですが、人材の流動性が高くなるにつれ、ATS・Performance（採用・評価）の重要度が上がるイメージです。
さて、次の質問は「情シスなど、テクニカルな部門発でこのあたりの必要性・緊急性を、リテラシーとセットでどのように経営・上層部に伝えたのか、その仕込み段階も含めてお聞きしたい」というものです。
一見氏： 経営陣と話すときはITの観点ではなく、あくまでも人事の観点から話を持って行く必要があると思います。ROI（費用対効果）を示す場合もシステム面の効果より、先ほど申し上げたようなワークフォースプランニングやタレントマネジメントなどの観点から効果を示さないと、経営層にはなかなか刺さらないですね。
石渡氏： 例えば「離職率」という数字1つを取ってみても、どれだけの人が辞めているかという「単純な離職率」ならどの会社でも簡単に弾き出せます。でも、本当に大事なのは、「辞めてもらっては困る優秀な人材がどれだけ辞めているか？」なんですよね。
経営にとって本当にインパクトがあるのは本来はこちらの数字なのですが、恐らく大半の企業は正確に把握できていないはずです。これをきちんと把握するにはやはりタレントマネジメントの取り組みが必要になってきますから、「そのためにもITの仕組みが必要なんです」という切り口で経営層を説得してみると効果があるかもしれません。
中野： その点、北米は日本と比べると人材の流動性がはるかに高いので、「優秀な人材が競合他社に引き抜かれないようにする施策」を行うために、タレントマネジメントに真剣に取り組まざるを得ません。
その結果、そうした情報を管理するためのWorkdayのようなHCM製品も、自ずとそうした機能の実装に力を入れるようになりますよね。「タレントマネジメント」という考え方自体が、「手放したくない人材を確保するための処方箋」として機能している気がします。逆に、人材流動性が低い組織ではタレントマネジメントの必要性が下がるような印象があります。
さて、続いて、「HRISの実装で成功している事例を聞いてみたいです」という質問もいただいています。
一見氏： 個人的には、かつて中野さんが手掛けたクックパッドさんの事例がとても印象に残っていますね。確かクックパッドさんではWorkdayのカスタマイズを極力避けて、なるべくデフォルトの機能だけで運用するという方針を掲げていたかと思います。
やはり標準機能をベストプラクティスとしてそのまま使うのが理想形だと思うので、そういう事例を見るととてもうらやましく感じますね。
中野： でも、楽天グループさんとは会社の規模も投資金額も桁違いですから……。やはり楽天グループさんほどの大企業となると、パッケージ製品をデフォルト仕様のまま使うというのは現実的にはかなり難しいだろうと思います。
石渡氏： ちなみに、とあるWorkdayのユーザー企業では、人事評価を人事部門が中央集権的に行うのではなく、現場のマネジャーにかなり権限を移譲して現場主導で行っています。
この会社は若いWeb企業なのですが、現場主導の人事評価に必要なさまざまな情報をWorkday上で管理していて、それらをマネジャーが自由に参照できるようにしています。
Workdayの日本法人でもまったく同じような運用を行っており、ある意味Workdayの標準機能を理想的な形で使っていただけている事例だと思います。
「中間データベース」のようなデータハブの仕組みをどう実現するか？
中野： ちなみに楽天グループさんの事例で紹介いただいた中間データベースの仕組みは、視聴者の皆さんも実に興味津々だったようで、多くの質問が寄せられています。
例えば「Workdayから中間データベースへのデータ投入はどういった仕組みで実現されていますか？」「中間データベースは一般的なRDBMS（リレーショナルデータベース管理システム）でしょうか？」といった質問が来ています。
一見氏： まず1つ目の質問に関しては、Workdayの「レポート機能」を使ってデータをファイルに吐き出して、それを取り込んでいます。2つ目の質問ですが、いわゆるNoSQLのデータベースです。インメモリーのキャッシュとして保存して下流システムへ提供しています。
石渡氏： 中間データベースでは、最新のデータだけを持っているのですか？ それとも過去の履歴データも持っているのでしょうか？
一見氏： 社員情報や組織情報は最新のスナップショット情報を全量で、トランザクション情報（採用や退職など）については履歴を含めて持っています。
中野： 「中間データベースは自社開発なのでしょうか？」という質問もいただいています。
一見氏： そうですね、自社でスクラッチ開発しています。
中野： 楽天グループさんほどの規模と開発力のある会社であれば、自社開発も十分に可能ですよね。ちなみにこれをスクラッチ開発ではなくパッケージ製品を使って実装する場合は、最近では「iPaaS（Integration Platform as a Service）」と呼ばれるソリューションが使われることが多いですね。
代表的な製品としては「Informatica」「MuleSoft」「Dell Boomi」などがよく知られています。国産製品であれば「ASTERIA」「DataSpider」あたりが挙げられるでしょうか。
多くの会社が、まず、製品や技術選定の話をしたがるのですが、「どの製品を選ぶか」というのは、データハブにとって本質ではないんですよね。本当に大事なのは、データをどう持つかという「データモデリング」、そのデータをいかにうまく管理して活用していくかという「データマネジメント」の取り組みです。
楽天グループさんが中間データベースを構築した際も、恐らくこのあたりにはかなり気を配ったのではないかと想像しています。
石渡氏： 中間データベースのような仕組みがないと、「何でもかんでもWorkdayに載せてしまえ！」という風になってしまいがちなんですよね。
例えばペイロールを例に挙げれば、「税額表の甲欄・乙欄」「家族が社会保険情の扶養に入ってるかどうか」といった、タレントマネジメントにとっては不要な情報までWorkdayに無理やり寄せ集めてしまうことも多々あります。
でも、楽天グループさんの中間データベースのように、Workdayとは関係ない情報も個別に外部から収集して別の形で管理できる仕組みがあれば、Workdayに本来不要なデータを無理やり突っ込んでしまって不自然な運用を強いられるような事態を避けられます。
ツァイ氏： ただし、規模がさして大きくない企業の場合は、中間データベースのような仕組みをきちんと構築・運用できるだけのリソースを調達するのが難しい場合もあるかと思います。現実的には1000人〜2000人規模の会社であっても、こうした本格的なデータハブの仕組みを導入・運用するのは結構ハードルが高いような気がします。
中野： 確かに、スクラッチ開発であれパッケージ導入であれ、たとえデータハブの仕組みを構築できたとしても、それをきちんと運用していくためにはそれなりのリソースを投入する必要がありますからね。
楽天グループさんが、わずか1年という短期間で、海外も含めた数万人規模にHRISを展開できたのは、データ基盤の存在も大きいと思っています。大企業の例を見ていると、普通はこの手のプロジェクトはもっと時間かかる上に展開がうまくいかず、システムとプロセスの構造がさらに複雑化するケースが少なくありません。「急がば回れ」で、データ基盤に投資し続けたのは導入成功の大きな要因だと思います。
一定以上の規模の企業で、アプリケーションと業務プロセスだけに手を入れようとすると、単純にシステムが散らかる結果になるんですよね。一方で、1000人規模の会社で、果たしてデータハブの運用やメンテナンスのための専任要員やコストを捻出できるのか、という問題もある。
楽天グループさんの事例もそうでしたが、データ基盤は「仕組みを構築して終わり」ではなく、その後、運用していくための組織や体制作りがとても重要になってくる。その問題をクリアできるかどうかが大きなハードルだと思うので、次のイベントで深堀りしようとしています。
戦略人事へのシフトを妨げる『人事マスター不在』問題、データ連携でどこまで解決できるのか
執筆
吉村哲樹
早稲田大学政治経済学部卒業後、メーカー系システムインテグレーターにてソフトウェア開発に従事。その後、外資系ソフトウェアベンダーでコンサルタント、IT系Webメディアで編集者を務めた後、現在はフリーライターとして活動中。
イベント企画・記事編集
後藤祥子
ITmediaエンタープライズの担当編集長を経て独立。現在はエンタープライズITの変革者に伴走するメディア「Darsana」の編集長として、変革者へのインタビュー、イベント企画、コミュニティ運営を手掛けている。ITとビジネスをつなぐ役割を担っているCIO、IT部門長へのインタビュー多数。モットーは、「変化の時代に正しい選択をするのに役立つ情報を発信すること」