人事部門必見！大手法人向け統合人事システム「COMPANY^®」（カンパニー）導入奮闘記

SE統括部で「COMPANY^®」データ移行・開発サービスを担当する清野です。

大手企業であるA社に大手法人向け統合人事システム「COMPANY^®」を新規導入するため、現行の人事・給与システムからのデータ移行を支援することになりました。その後、データ移行における様々な課題を乗り越え、無事に本番稼働を迎えることができました。本記事では、1年以上にわたる新規導入プロジェクトにおける移行作業の道のりを記載します。

ラックが「COMPANY^®」導入時のデータ移行を支援した背景

通常、「COMPANY^®」を新規に導入する場合、「COMPANY^®」の各プロダクトの設定に合わせて、現行システムからデータ移行を実施します。お客様にて現行システムからデータを抽出してデータ移行を実施しますが、お客様側で作業工数を割くことができない、または変換ツール作成など技術的部分で課題がある、などの場合はラックのようなソリューションパートナーが移行作業を支援いたします。

ラックでは、大手派遣会社の人事管理システムにおけるシステム開発、運用・保守作業の実績を豊富に有しておりました。それらの実績を通して、人事・給与、就労といった領域の業務スキルを蓄積していたため、A社のデータ移行案件を「COMPANY^®」の販売元である株式会社Works Human Intelligence（以下、WHI社）からの紹介を受け、スキルやノウハウをもったメンバーで体制を組成し、データ移行作業を開始したのが背景になります。

A社のデータ移行の規模感は以下となります。

• 人事、給与、Web、就労の利用で約40データ
• 移行対象員数は、約10,000名
• 発令数は、約100,000件

要件定義で実施したこと

「COMPANY^®」の新規導入支援はWHI社、現行システムからのデータ移行はラックが担当する体制でプロジェクトを進めました。開始より数ヶ月は、通常のシステム構築と同様で要件定義に入ります。

プロジェクトを開始した始めの2ヶ月は、導入側は基本計画フェーズのため、各プロダクト（人事・給与、就労、Webサービス）の利用情報のヒアリングを実施しました。データ移行側は各プロダクトの打合せに参加し、進め方の確認や情報の共有をします。

その後、導入側は詳細計画フェーズに入ります。現行システムの項目と「COMPANY^®」の画面項目を結びつけるマッピング作成を行うため、データ移行側は実質的な要件定義を開始しました。データ移行に向けて現行の情報ソースを集め、必要な移行プログラムを作成し、「COMPANY^®」へ登録することが目的となるので、要件定義ではデータ移行用のマッピング作業と移行方式の検討を実施しました。

データ移行用マッピングと移行方式の検討

各プロダクトで作成した項目のマッピング資料をベースに、現行システムからファイルとして抽出した複数の情報ソースと、「COMPANY^®」の情報項目を結びつけるデータ移行用マッピングを作成しました。このデータ移行用マッピング資料が、次工程のデータ移行プログラム設計のインプットとなります。また、現行システムから抽出した情報ソースをA社から提供いただき、情報ソースの内容確認と必要であればデータのクレンジングや不足データの補完を依頼しました。

データ移行方式の検討を進めるにあたり、移行プログラム言語は比較的開発体制が組成しやすいJavaに決定しました。データ移行で使用するDBの選択は、通常であればMySQLやPostgreSQLとするところですが、データ移行用のみのDBで用途が限られていることを考慮し、インストール作業が不要なSQLiteを選択しました。

データ移行プログラムの設計から開発、テストの工程はウォーターフォール型です。一方でCOMPANY^®の導入は、最適な業務フローの実現のため設定検証を細かく繰り返すアジャイル的な手法で進んでいきます。

この場合、開発、テスト工程における手戻り作業の影響を小さくしていくかがとても重要で、ラックでは言うなれば、ウォータフォール型＋アジャイル型のハイブリッド型で工程計画を設計段階で立案し、作業を進めていきました。

一方で、開発におけるシステムアーキテクチャーについても工夫をしました。通常の業務系アプリケーション開発においては、Webシステムを簡素化するために何かのJavaのフレームワークを適用するのですが、今回のデータ移行プログラムはバッチ処理のみであるため、フレームワークは適用不要と判断してPure Javaを用いた開発を実施しました。

テストはローカル環境で単体テストを実施し、その後「COMPANY^®」の検証環境にデータを登録、テスト作業を実施しました。テスト移行では、現行システムから抽出したデータを使用し、検証環境に登録完了した情報をA社に確認いただきました。

今回、通常の開発工程とは異なるハイブリッド型で進めたため、課題も発生しましたが、ラックにとって多くの知見が得られたと感じております。

移行データを「COMPANY^®」へ投入する

「COMPANY^®」は、組織情報等のマスタ情報を設定後、発令情報を登録することで後続の情報の登録が可能となる仕組みです。この発令情報の登録のテスト移行に大きな山場が待っていました。

A社の発令情報はかなり複雑であるため、A社の人事部門リーダー、およびWHI社の業務コンサルと共に対応にあたりました。発令情報の登録は、現行の人事システムの情報を基に「COMPANY^®」の情報形式にするため、発令情報を新たに作り上げる作業が必要でした。そのため、テスト移行当初は各発令に不整合が発生し、多数のエラーが発生してしまったのです。その後、エラーのパターン分けを行いつつ、一つ一つ原因を解明し、移行プログラムを改良していきました。

発令情報の取込み開始当初は、A社とラックの担当者が対応検討会を開催し、エラーの解消を実施しました。この期間が、今回のデータ移行の山場だったと感じます。

発令情報の取込み以降は、後続の情報をテスト移行後にA社に結果を確認いただき、本番環境へのデータ移行をします。本稼働へ向けて最終的なデータ移行を実施し、問題が発生したら都度解消しながら進め、A社で実施される本稼働判定会議へ臨みました。

結果、Web Service領域において、いくつかの海外拠点からの利用で想定通りに動作しない事象が発生し、一部条件付きとなりましたが無事「承認」の運びとなりました。給与領域においても、判定会議により承認され、計画通り本稼働を実現することができました。

おわりに

A社の「COMPANY^®」導入におけるデータ移行では、プロジェクト全体を通して「COMPANY^®」へ登録した移行情報の洗い替えといった、プロジェクトの進捗に大きな影響を与えてしまうような問題は発生しませんでした。大きな問題が発生しなかった要因としては、WHI社とラックのしっかりとしたプロジェクト体制、また、なによりA社の積極的な協力体制が挙げられると思います。

「COMPANY^®」の導入プロジェクトは通常のシステム導入とは異なり、IT部門中心ではなく人事部門が主体となって進めます。A社では、人事部門の方が各プロダクトのリーダーとなり、大きな責任感を持ってプロジェクトを推進したという点と、A社とWHI社、およびラックを含めたコミュニケーションプランを確立し、1年以上に渡るプロジェクト運営を円滑に推進できたという点が、計画通りに本稼働できた大きな要因であると感じております。

人事・給与システムは、企業にとっての根幹に関わるシステムであるため、各社固有の規定や複雑な業務運用があります。しかし、「COMPANY^®」という統合人事システムを導入することで、固有の規定への柔軟な対応や業務運用の効率的な改善といったことも可能になりますので、今後ますます導入が進んでいくと思います。

ラックは今回の案件で得られたノウハウ、知見を活かし、今後益々「COMPANY^®」データ移行・開発サービスを確立、拡充し、お客様への支援を提供していきます。

プロフィール