要約

  • RemoFirstは9月9日、Workdayからの一方向の連携を発表した。Workdayへの書き戻しはなく、人員データの基準は同システムに置く。
  • 顧客向けガイドでは、承認済み休暇の後日の変更は同期対象外で、退職処理にも確認が残る。データの到着と手続きの完了は分けて考える必要がある。

取り込めた後に、何を直せるか

承認された休暇を取り込むことと、後から変更された休暇を正しく反映することは同じ機能ではない。RemoFirstの顧客向けガイドは、承認済み休暇の変更は同期されず、修正にはサポートへの連絡が必要だと明記している。

これは利用企業で確認した事故でも、新たに見つけた不具合でもない。公開文書が示す対応範囲である。最初の入力を自動化しても、その後の照合作業までなくなるとは限らない。この違いが、今回の連携を費用面から評価する手掛かりになる。

9月9日の発表によると、Workdayの人員データがRemoFirstへ入り、逆方向には書き戻されない。選んだ項目がRemoFirstの雇用関連業務に使われる一方、基準となる記録はWorkdayに残る。接続自体に追加料金はないとされるが、初期設定や例外対応に要する人の時間までゼロになるという意味ではない。

二つのシステムがつながっても、一つのシステムに置き換わるわけではない。どの変更が渡るのか、いつ渡るのか、その後の判断を誰が行うのかは、それぞれ確認すべき事項だ。

同じIDを見つけることと、最新状態を保つこと

休暇では、承認済みの申請だけが取り込まれる。RemoFirstはWorkdayが付けた申請IDを記録し、取り込み済みのIDを再び読み込まないようにする。同じ項目の重複取り込みを防ぐ仕組みであり、すべての修正版が反映されることの証明ではない。

同期を有効にすると、従業員、顧客、契約スタッフによるRemoFirst内での休暇の直接作成・編集も制限されるとガイドは説明する。編集を基準側へ集めれば、双方で別々の変更を加える事態を減らせる。ただし、同期の対象外となる変更には別の修正経路がいる。ここではサポート対応も、公開された運用の一部になる。

意味の対応付けも必要だ。Workdayの休暇区分は顧客環境ごとに異なり、RemoFirst側の区分へ割り当てる。受け手が扱う単位は半日と全日だとガイドにある。データ移動には、このような表現や粒度の違いが含まれる。これはソフトウェアの説明であり、休暇の権利や個別の給与計算を判断するものではない。

また、発表は人員変更のイベント処理と、定期的に取得する休暇情報を区別している。手動同期も用意されるが、対象外とされた変更まで直せるとは読めない。発表とガイドの間隔の説明も同一ではないため、全顧客に一つの更新周期を当てはめたり、即時反映と呼んだりするべきではない。

手続きの開始には、まだ判断が続く

Workdayの終了イベントからRemoFirstに作られるのは、情報を事前入力した退職処理の申請だ。ガイドは、完了前に顧客の確認が必要だとし、進めるか破棄するかを選べると説明する。開始を自動化することと、最終実行まで自動化することは異なる。特定の雇用終了の法的な効力を示す話でもない。

新しい人員の取り込みも、既存人物の初期対応付けとは別に扱われる。新規データは入社手続きへ進む候補であり、既存プロフィールへの自動統合ではない。入力の手間を省けても、人物の対応と処理を続ける判断は残る。

RemoFirstの連携一覧にはWorkdayのほか、人事や支払いのツールが並ぶ。既存の人事システムを保ったまま、反復作業を減らせる点が商業上の魅力だ。なおガイドは9月3日に更新済みであり、9日の発表を初めての公開と断定する根拠はない。

比べるべきなのは、手作業と「作業なし」ではない。二重入力に費やした労力と、対応付け、修正、確認に集中する労力である。後者が残ることと、連携に価値があることは両立する。