CLOSE

パネルディスカッション(全5記事)

「どのツールがいいのか」にはエンジニア視点が必要 技術者が人事を兼務するメリットとミッション

2017年2月17日、人事とITをキーワードに、エンジニアリングやテクノロジーに関する理解を深めるためのイベント「人事 to IT カイギ」が行われました。今回のテーマは「エンジニアのキャリアパスとしての人事」。その第2部では、グリーCTO藤本氏とクックパッド庄司氏によるパネルディスカッションが行われました。人事に新ツールを導入しにくい理由と、エンジニアが参加することのメリットについて語られた様子をお届けまします。

人事は、いろんなものを組み合わせられるほど成熟していない

モデレーター:採用はそういう感じ。次いくと、「ここ、こういうの使ってるよ」とか。例えば最近の労務だと「SmartHR」とか、すごく聞くじゃないですか。

藤本真樹氏(以下、藤本):あ~。

モデレーター:でも歴史あるからね、我々の会社はね。

藤本:そうなんですよね。けっこうこれ、本当その……難しい。当たり前ですけど、例えば、「システムの一部をナウいものに入れ替えたい」って思った時、人事の一部はいいとしても、結局全部つながるから、「じゃあ他の部のほうがどうか」「基幹システムはうちこれ使ってるんで」とかになる。

なんかね、「ここはいいんだけど……」みたいな話がけっこうあるね。まだそこがちゃんと結合して、いろんなものを上手に組み合わせることが簡単になるほどには成熟してない。それは正直あると思うんですけど。

モデレーター:じゃあ、SaaSとかはそんなにたくさん使っているわけじゃない?

藤本:使っているけど、……これ言っていいのかな?

モデレーター:言える範囲で。例えば「こういうの使ってる」とか。

藤本:わかんないけど、とにかく僕がソーシャルメディアがそんなに得意ではないので……。自分の話したことがソーシャルメディアに書かれるのが得意ではないので(笑)。って、まぁそんなたいしたこと話すわけじゃないんですけどね。

モデレーター:なにを気にしてるんですか、いいからしゃべってください(笑)。

(会場笑)

導入の障壁となる「人事マスター問題」

藤本:例えばなんだろう、それこそアメリカンなツールで、「SuccessFactors(サクセスファクターズ)」とか。

モデレーター:それ、なんですか?

藤本:うーんと、まぁ広く言うと、タレントマネジメントのシステムね。

モデレーター:タレントマネジメントってよく聞くけど、もっとわかりやすく。

藤本:人材……管理システム。

(会場笑)

モデレーター:人材管理システム? そのシステムは、なにをしてくれるんですか?

藤本:あれですね、ある程度の範囲の社員IDに紐づくデータの一元化をしてくれる。

モデレーター:あー、データを集約して。例えば?

庄司嘉織氏(以下、庄司):例えば、この人は前どこの部署に所属してて今この部署になったとか、こういうふうに出世したとか、年収がこれぐらい上がってるとかっていうのがすべて一元管理されている。だから「こいつはリーダーになって長いな」「ずっとヒラのままだけど給料も上がってないな」も全部見られる。

モデレーター:それ、クックパッドは使っている?

庄司:使ってない。そういうのはあるのは知ってるんだけど、導入は……。

モデレーター:マイクマイク。

(会場笑)。

庄司:導入は障壁が高くて。なんでかと言うと、まず人事マスターの問題になるんです。「人事マスターをどう持つか」みたいな。みんなエンジニアだからわかると思うんだけど、「LDAPと別管理するの?」とか、いろいろややこしい問題が出てきて、どうしようかってなって。

人事マスターって結局、経理とかとも連携しなきゃいけないんですね。誰がこれを使ったとか、振込のところでも連携しなきゃいけない。だから、「そこをどう連携するの?」と考え始めると、先ほどお話したとおり、本当に基幹システムの入れ替えってすごく大変なところにぶち当たって、今のところ入れ替えはしてない。入れ替えっていうか、ここに導入はできてない。

そのしがらみはシステム的なものか、社員感情か

モデレーター:スタートアップとかたぶんそういうものがないから、使うよね。例えば、KAIZEN Platformっていう会社は、立ち上がって2年ぐらいのスタートアップなんですけど。SaaS、すごく使ってて。採用も「Lever(レーバー)」っていう、Slackが使ってたやつを導入しているんです。

あと、タレントマネジメントシステムの「Namely(ネームリー)」っていう、360度評価とか。あとそういう人事データベース。「なんとかさんってこの人ですか」とか、それこそ給料とか、そういうのも使ってた。あとなに使ってたかな。

SmartHRは使ってなかったですけど、労務系は入ってて。しがらみがない分、どんどん使えるみたいな感じかな。

藤本:そのしがらみが、本当にそのシステム的なものっていう場合もあれば、社員感情というか、みんなの慣れ、あるいはそれを変えることによるコストみたいなものだったりする。それをどれぐらいぶっちぎるかはけっこう難しいね、みたいなことがあったり。

モデレーター:結局その時も「スタートアップだからSaaS使える」って言っても、結局なにをちゃんとどういうふうに持って、なんの問題解決に使うかっていう見極めは必要じゃないですか。

やっぱりあそこ(KAIZEN Platform)も今エンジニアが人事部長やっていて、最終的な判断もやっている。バックオフィス……そうそう、須藤(憲司)さんがやってて。まぁなんか、そこにやっぱり目が要るんだなっていうのは感じましたね。

藤本:まぁそういう意味では、僕ら、まだまだ人事担当になりたてなので、これからですね。

モデレーター:でもその基幹システムの、人事マスターをきちんと整えないと、それこそHRTechの波に乗れないぜっていうのも、エンジニアリングをやったことがない人でも……まぁ、わかるのかな?

庄司:いや、わかんないんじゃないかな。

藤本:うちの場合はどちらかと言うと、けっこうそういうことをすごく気にしている人がいて。人事でもそういう人もいたりするし、情シスもけっこう考えるし。だからそれをすごくドライブしたり、あるいはそのマジョリティの意見にして、「そういうことにコストかけるところまでいければ、それをちゃんと後押しするだけで進む」っていう意味では、ちょっとラッキーだったなと思っていたりしなくもない。

「どの道具がいいのか」はエンジニアリング視点がないと選べない

モデレーター:そうですね、そもそも、……そもそもだよ? そういう流れがないと、「人事マスターのデータベース作りたい」を仕事にできる感じがしないよね、普通のミッションとして。

例えば情シスの担当でもいいし、あるいは人事でもいいんだけど、今みたいに「エンジニアが人事になりました」みたいな文脈なしに、そういう「IT化ゴリゴリ進めるぜ」というミッションを負うことは起こるのかな?

(会場笑)

あとはね、労務でしょ? でもだいたい、それこそリモートワークとかも、エンジニア視点があったからこそ実現……。

庄司:これ、エンジニア視点っていうより、うちはすごく端的にわかりやすくて、先ほど言ったように世界中に支店があるんだよね。だから、場所とか時間にこだわっていたらもう業務にならないんだよね、そもそも。それがあった。だから、とりあえず時間はやめよう、と。

リモートワークについて今「試験導入」と言ってるのはなぜかというと、会社に制度として入れるんだったら、ちゃんとリモートでもミーティングとかが本当にストレスなくできる環境まで用意をしないと入れられない。だから今は「トライアルです」って言ってる。

今ハングアウト(GoogleHangout)を使うのかZOOMを使うのかとか、リモートのミーティングとか、全社の会議とか、それもどうしようかねぇっていうところを今選定していて。でも、それ待ってても仕方ないから、とりあえず部長権限で「自分の部下を自身の判断でリモート勤務可にしてもいいぞ」っていうぐらいで動かしてるという感じです。

モデレーター:たぶんリモートワークの経験ない人はピンとこないと思うんだけど、リモートワークってむちゃくちゃ道具が重要なんですよ。

僕、一時やってたからわかるんですけど。マイクを性能いいやつを使う・使わないかだけでもぜんぜんその快適さが違うし、あとビデオチャットのツールとかも、適当なものを選ぶとすごくストレスに感じるんですね。めっちゃくちゃ話しかけたいのに「聞こえてますか? 聞こえてますか?」「聞こえてませーん」とかやって、それだけで会議が終わっちゃうみたいな。

(会場笑)

「どういう道具がいいんですか?」っていうと、多少なりともエンジニアリングの視点がないと選べない。じゃないと、すぐSkypeとかになっちゃう。Skypeはリモートワークに向いたツールじゃないんですよ。

基幹システムを入れ替えるのが大変な理由

なんかないんですか? 特別。さっきのbotみたいな話とか。

藤本:いやぁ~。あれ、でもそっか、2014年末くらい頃までうちの会社にいた人は知ってるけど。そもそも「俺は人事興味あったんだなぁ」と今にして思うのは、2014年末ぐらいに、自分の考えた超使いやすい社員データベース検索ツールを作ったんですよ。そこに今、ちょっとずついろんなサービスを足していて。

モデレーター:そこに社員マスターを乗せていきたいっていう?

藤本:いや、マスターは、一次情報は別にあって。ビューアー以外やってはいけないっていうのをポリシーとして持ってるんだけど。とりあえず今は勤怠情報を全部、そこにインポートしていこうとしています。

そこへいくと、例えば「勤怠と退職だったり評価だったりの相関はすぐ取れるような装置ができるね」ってなって。みんなで見たら楽しいなと思ったけど、先ほど言ったACL問題にぶち当たって、とか。

モデレーター:ちなみにACLっていうのはちゃんと説明しないとわからないと思うんで。アクセスコントロールリスト。要するに、アクセス権限ね。

藤本:そうかぁ。

(会場笑)

モデレーター:なるほど。話を聞いていると、バリバリツールを導入しまくってるわけではないけど、エンジニアリング的な視点を入れて道具を選んだり、自分でちょっと作ったりみたいなアプローチはけっこう始めてますよ、ぐらいの感じですかね?

庄司:だから、けっこう基幹システムを入れ替えるのがめんどくさい。めんどくさいというかすごい大変なので、それまでの間、今動いてるイケてない基幹システムをうまく動かすためのユーザースクリプトとかはいっぱい書いてる。

(会場笑)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!