IT屋の自分はいかにして人事領域に興味を持ったのか
私は現在データドリブンHRコンサルタントと名乗っていますが、学生時代の自分にこんな風になってるよと言っても、まったく意味不明だと思うことでしょう。新卒で入社するまで会社もビジネスパーソンのこともまるで知らず、組織というもののイメージを持っていなかったからです。
実家は専業農家でしたし、高校生まで第一次産業中心の片田舎に住んでいましたので、会社も会社員のこともさっぱりわかっていませんでした。以前どこかに書いたように、新人研修を受けている段になっても役職の順序も分からず、「課長とか部長とか分かんないな。でも聞けないよな、コレ」とか思っていました。よく入社できたものです…。
さて、そういう組織人の常識を持ち合わせておらず、かつコミュ力も高くないIT屋が会社に入ったわけですが、その後紆余曲折を経て人事×ITの仕事をすることになりました。その接点を振り返りつつ、エンジニアがドメイン知識を身に着ける重要性とコツをお伝えしていきます。
「給与計算事務ができる本」の衝撃
新卒でITベンダーに入社した後、しばらく新人研修が続きました。その終わりが近づいた頃、私の配属先が公共セクターのSE部門であることがわかりました。
ちょうどe-Japan戦略が盛り上がっていたところで、全国自治体のデジタル化を推進する部隊に配属されたのです。ただし、その業務領域は広く、具体的な配属先はグループ面談で希望を聞いてから決めるという話でした。
そのころのデジタル領域は住民サービスを担うGtoC、政府間の情報交換を担うGtoG、そして庁内事務のデジタル化を行うin Gの3つの領域に分かれていました。
この中で一番人気だったのはGtoCでした。何となく開けたイメージもあって、新人の中でも元気な人が手をあげていた記憶があります。私はこうした場面で一歩引いて冷静に考える癖があり、うーんと考えている間にGtoCやGtoGが埋まっていきました。
そんなとき、大学の同級生が市役所に入った後に「役所のシステム使いにくいんだよ。お前SEになったんだろ？何とかしてよ」と言われたことを思い出しました。そこで、何となく直観でin G（内部事務）を選びました。地味そうだけど何かできることがあるかもしれないと考えて。
そして晴れて希望通り内部事務向けのソリューション開発部隊に配属になり、その中で人事給与システムを開発しているチームへの配属が決まったのです。
はじめての上司であるチームリーダーと面談したとき、一冊の本を手渡されました。何だろうと思ってみてみると「図解 給与計算事務ができる本」でした。これが人事給与との出会いです。
キュウヨケイサン…？ 表紙を見てみると出勤簿や年末調整などさらにさっぱり分からない単語が載っています。本を読むのは好きでしたが、正直まったくそそられません。そのことに大いなる衝撃を受けたのを覚えています。
その後、睡魔と戦いつつこの本と格闘していきましたが、給与計算という業務への関心はなかなか高まりませんでした。
いつの間にか労務管理マニアへ
SE1年目の終わりに転機が訪れました。人事給与から庶務事務ソリューション開発チームに移籍となったのです。
庶務事務というのは、一般企業でいうと労務管理や総務事務に相当するもので、勤怠管理、休暇・時間外計算からはじまって、諸手当や人事関連の届出事務全般を指します。
今日の組織においては、この庶務事務や総務事務に相当する部分の大半はデジタル化されていますが、当時は紙中心の事務からデジタルへの移行で盛り上がっていたのです。単に申請書や管理台帳をITシステムで実現するのではなく、業務フローを一新するBPRでもあり、それなりに大規模なソリューションでした。
当然ながら製品開発も挑戦的なものであり、非常にエキサイティングな経験となりました。受託SI中心の会社にあって、プロダクトベースのビジネスというのも自分の指向性にあっていました。今日でいうところのプロダクトマネジメントを担当させていただき、本当に楽しかったのです。
ドメイン知識の点から考えると、庶務事務（総務事務）というのは、人事給与の周辺事務という位置づけになります。給与計算や人事の昇格事務の発生源となる情報のエントリーを担い、またその結果を受け取って従業員へフィードバックする役割を担うからです。逆に考えると人事と給与のハブになる業務なので、広範囲に学ぶことができます。
庶務事務における業務仕様は人事給与や財務会計よりも軽いとみられていましたが、ふたを開けてみると独特の難しさが潜んでいることがわかりました。勤怠や事務という本来連続的な業務を離散的にモデリングする必要があるからです。
その極みが「時間外時間数の計算」でした。時間外を集計するだけならSQL一発では？とイメージできそうですが、中身はかなり複雑です。例えば、
勤務時間帯や休日区分に応じて割増率が変わる。
週の勤務実態に応じて、振替手当25/100を支給する。
月初に時間外の単価が変わる可能性があるが、その区切りが団体によって異なる。
勤務割り振りによって、夜間手当と深夜割増を計算上分ける。
以上のような複雑な仕様を踏まえた上で、その変動を捉えて遡及自動計算をしなくてはならない。
など、労働基準法を順守し、なおかつ団体独自の規定を守って正確に自動計算をしようとすると、とてつもなく複雑な業務仕様となるのです。その上、単なる台帳型システムともバッチ中心の計算系システムとも異なり、事務フローに柔軟に対応するUXも必要です。
そして毎年やってくる法改正にも対応する必要があります。例えば、2008年の労基法の大規模改正に挑んだときには、顧客から事務手順（仕様）が出てこない中で先回りして想定仕様を作って開発したこともありました。ある種の博打だったのですが、後に公式に厚労省から出てきた事務手順が想定と同じだった時、相当に嬉しかったのを覚えています。
こんな形で、気が付くと結構な労務管理事務マニアになっていました。
そうです。あれほど給与計算事務に関心がなかったのに、開発現場にダイブしている間にマニアになるほど興味を持つことになりました。逆にいえば、市場の変化を捉えながら強いプロダクトを作るには、どうしてもドメイン知識が必要になるのです。
これが人事業務に興味を持つことになった「はじめのエピソード」です。
HRテクノロジーからピープルアナリティクスへ
SEを8年ほど続けた後、手上げで研究所へ異動しデータサイエンティストへ転身しました。そこで4年半ほど修業。そしてAI関連事業部に移って様々な案件をこなした後、ようやくHRテクノロジーに取り組むことができました。具体的には労務管理や人事異動業務のDXの新規ビジネスをすることなりました。
そんなとき、社内関係者の方から「HRテクノロジーをやっているのだったら、人事部門の人を紹介してあげるよ」とお誘いがありました。そして、社内人事部門の上級管理職の方とお話することになったのですが、どこか緊張していた記憶があります。
会社員とは不思議なもので、どの会社にも必ず人事があるにも関わらず、日常的な会社員生活を送っていると「人事の人」と直接お話することはあまりありません。
特に組織が大きくなればなるほど、人事戦略や施策に関与している人と会話する機会はめったにないのではないでしょうか。
ということでやや緊張しつつもミーティングが始まり、私が当時やっていたHRテクノロジーの取り組みについてお伝えし、アドバイスをいただきました。
そうしたところ「面白いことやってるね。これからピープルアナリティクスのミーティングがあるんだけど、来てよ。時間あるよね？」という話に。正直時間はなかったのですが、こういうときは流れに身を任せた方がよいと思って後続の別件をキャンセルし、ミーティングに参加させていただきました。
実はこの時、ピープルアナリティクスなるものをはじめて耳にしたのですが、何かありそうだと思ったのです。
そして、誘われるままに参加したミーティングで目にした光景は今まで経験したSE業務とも、研究開発業務とも、そしてHRテクノロジー製品開発業務とも異なるものでした。
よくわからないけど、わからないから知りたいし気になるという気持ち。これは私の人生にしばしば登場する感覚で、その感覚に従えばたいてい困惑を含んだ面白いことが待っているのです。
これはもっと知る必要があると直観し、工数を度外視してまたもやダイブしてみることにしました。
そこから、社内ピープルアナリティクスチームへ技術アドバイスをしつつ、チームの活動をソリューション開発からピープルアナリティクスへシフトしていきました。つまり、社内外の人事業務をデータで支援する仕事に変わったのです。
これはふとした好奇心からの行動ではありましたが、人事業務そのものに興味を持つ大きな転機となりました。
人事データ分析ダンジョンを攻略する
その後、ピープルアナリティクスに取り組んでいったわけですが、他の分野のデータ分析業務と比べると随分雰囲気が異なるように感じました。データ分析の方向性や目的を決めることに苦戦していたのです。
そこで、人事業務のことを知るべく、人事関連図書を積み上げていきました。例えばこんな本です。
こうした本を読むことで、何とか話題にはついていけるようになりましたが、やはり議論の流れを理解することができませんでした。何となく自分だけが浮いているように感じてしまうのです。
データ分析には目的が必要で、できればKPIのような数値的なターゲットがあることが理想です。しかし、そういった議論に持ち込もうとすればするほど上手くいかなくなるのです。
何が悪いのか分かりませんでしたが、少なくともステークホルダーの本音にアクセスできていないことは明らかでした。まさにダンジョンに迷い込んだような感覚でした。
こうしたピンチのとき、私は本屋でウロウロします。
新しい視点を手に入れるべく、「家の本棚にない」本を探すわけです。
そしてこれらの本に出合うことができました。
どの本も理系的な発想からは出てこない内容で、難解ではあるものの驚きの連続でした。特に3冊目の「現実はいつも対話から生まれる」は、そのタイトルだけでどえらいインパクトがありました。
また、エドガー・H・シャインの本はどれも示唆的で、直線的でない柔らかい考え方に感銘を受けました。それと同時に、これまでの自分に足りないことが何かを示す本でもあり、もっと知りたくなったのです。
こうした本をちびちび読みながら、現実のピープルアナリティクスプロジェクトで粘っていると、少しずつ人事担当者の言葉の背景が分かるようになりました。そうした活動で得られた知見を「人事データ分析ダンジョンの攻略法」と題してお話しました。
こうして、ピープルアナリティクスという仕事を通じて、人事というものへの関心を深めていったというわけです。
「好奇心」と「分からない」が混ざったところから、興味が生まれたといってもよいでしょう。
まとめ
このnoteでは、人事業務に関心のなかったエンジニアがいかにして人事のドメイン知識を身に着けたのか、実例からご紹介しました。
各エピソードの中心にあるのは、好奇心です。
そして、その好奇心を生む前提に、分からないことや仕事にダイブしてみるという行動が潜んでいるように感じます。
データ分析者やアプリケーションエンジニアがビジネスの世界で成果をあげようとすれば、対象業務のドメイン知識を獲得することは重要です。とはいえ、何に惹かれるかは人それぞれでしょう。私の場合はそれがたまたま人事だったわけですね。
この記事を読んでピープルアナリティクスを知りたくなった方は、ぜひ以下の記事を読んでみてください。