コラム「人事とIT」

人材データの一元化は想像しているよりハードルは高い、が、それを超えるだけの価値がある。(4/4)

2018.03.06

何故、人材データの一元化は簡単ではないのか?③

「自分たちで簡単に項目が設定できる」ことが、本当に拡張性を担保するのか?

「何故、人材データの一元化は簡単ではないのか②」で記したように、戦略的な人事での活用が進むと、「扱いたいデータの種類の幅が広く、変化する」。 そのため、そうした状況に対して、多くのパッケージ型のシステムでは、特定のフィールドにおいては自分たちで自由に項目設定ができる、という形になっている。 ベンダーに頼むことで時間とお金を取られることがなく、自分たちで思うようにコントロールできるので、 多くのユーザーがこのサービス提供のあり方を肯定的に捉えているようだ。しかし、ここには落とし穴もあることは、覚えておく必要がある。

まず、人材関連のシステムであるため、項目設定を人事担当者が行うケースも少なくない。 情報システム部のメンバーに、人事がどのような項目を、何の目的で管理しているか知られることを避けたいと考えるからである。
しかし、そうした人事担当者たちは、どの程度までデータが格納されるRDB(リレーショナルデータベース)の特徴や構造を理解しているだろうか。 ユーザーとしてシステムの活用方法は理解しているだろうし、ある程度構造に関する知識を持っている人もいるだろう。 しかし、複数のデータを期間で管理し、基準日時点での過不足ないデータを確実に取り出すために、どのような管理構造にすればよいのか、 そこまで理解をしてシステムを設定できる人事担当者は存在しないのが一般的な状況だろう。
しかし、システムのマニュアルには「誰にでも、簡単にできる」とあるため、人事とシステムの知識を比較したら、圧倒的に前者の質と量が勝っている人たちが、 項目追加をしていくことになる。

人事の立場とシステムの立場の違いが明確になる例がある。「異動」と「昇格」の扱いである。 一般的に「異動」と「昇格」は、社員の社内でのステータスを変更する一連の発令業務であり、基本的に同時期に行われる人事業務である。
人事の観点からは、ひとつのカテゴリに括るのが自然な業務だ。対してデータベースの視点から考えてみよう。 「兼務・兼任」という制度がある会社であれば、「異動」は同じ日に複数のレコードが発生する種類のデータ、『1:nタイプ』のデータである。 一方、等級・グレードは一人の社員が同時に複数持つ、ということは想定されない。 つまり、「昇格」は、同日にはひとつのレコードしか発生しない種類のデータ、『1:1タイプ』のデータである。 そして、「異動」も「昇格」も、滞留・経年計算を求められる、期間で履歴管理をしたいデータである。

こうした性質のデータを、どのようなテーブル構造の下で、どうやって項目を設定したらいいのか。

人事的な視点を重視すると、 一連の発令行為としてひとつのテーブルで一括管理をした方がいい、という結論になりやすい。一方で、データベースの視点を重視すると、 レコード発生のキーが異なる期間管理の履歴データなので、別のテーブルで管理することが合理的だと考えられる。 もちろん、ひとつのテーブルで管理することが間違いではないが、そうした管理方法を選択した場合には、 項目設定の仕方をどうしたら、それぞれの期間計算ができるようになるのか、基準日で切り取れるようにするには何を考慮したらいいのか、 を考えていく必要がある。また、自由であればあるほど、自社で追加した項目の設定意図を、担当者が変わる際にきっちりと引き継ぐことも重要だ。

実際に、「自分たちで自由にデータベースを拡張できる」とうたっているシステムからの入替案件を受注することがある。 その会社は異動が多いらしく、入れ替えのシステムの担当者が頻繁に変わっていた。データベースから現存しているデータをすべて抜き出してほしいと依頼すると、 そもそもデータベースの構造全体像を把握できている人が存在しないのだという。自分たちが理解できる範囲でデータを取り出して使っているそうだ。 そこで、提供ベンダーに連絡してもらった。しかし、そちらも、ユーザーで自由に管理できるものなので、全体像が分かる人はいないという返事。 全てのデータを抜き出す手伝いはできるが、百万単位の費用がかかるとのことだった。そのお客様は予算を確保し、 データベースにあるデータをすべて抜き出してもらった。そしてたどり着いたのは、何百という雑多なテーブルの山だった。
この例はかなりひどいケースではあるが、実際に運用を誤るとこうした状況になってしまう、という実話である。ここまではいかないにしても、 人事の視点ばかりでデータベースを構築していってしまったので、履歴管理がうまくできていない、基準日でデータが取り出せないという例は、 残念ながら、ごく普通に起こっている。「自分たちで自由に項目が追加できる」こと自体は悪いことではない。 ただ、上記のような状況があり、落とし穴もあることを理解した上で、選択をすることが肝要なのである。

◆◆◆

 人材データの一元化には、そこまで苦労しても真剣に取り組む価値がある

規模の大きい企業で人材マネジメントシステムを導入する場合、いくつかのフェーズに分けて、最終的な形にしていくことが少なくない。第一フェーズは、データの一元化と他システムの連携となるケースが多いのだが、そこで興味深いことが起こる。それまで散在していたデータを、様々な形で取り出し、リスト化したり、分析ができたりするようになると、今まで見えていなかったこと、気がついていなかったことが日の下にさらされることになり、頭で考えていたことよりも大事なこと、喫急の課題があることに気がつくことがあるのだ。そこで、第二フェーズの内容が、導入前に予定していたことではなくなる。それほどに、データを活用できるように一元化し、見るべきものを見えるようにすることは、パワフルなことなのだ。

これから日本の労働人口が減っていくことは避けられない。働く人の属性・価値観共に、多様化が進む。(年齢、性別、文化、働くことに対するスタンス・・・)どんなに技術が進んでも、 人がまったくいない状態で進むビジネスはないはずである。
では、「人」はどうやって、大きく変化していく環境の下、健全に活躍し、成果を出していくことができるのか。地道に仮説検証を繰り返すしかないだろうと感じている。 そのために、人材データが一元化され続けていくことは、重要な要素のひとつであることは間違いない。

2018年2月28日


バックナンバー

年月から絞り込む