メインコンテンツへスキップ

勤怠ルールの設定:勤怠グループを一括作成し、動的に調整する

概要

本ソリューションは、勤怠グループ管理をエンドツーエンドで自動化します。DingTalk オープンプラットフォームの勤怠グループ管理 API を使い、人事システムや OA システムなどの業務プラットフォームを DingTalk 勤怠と連携させます。

背景

勤怠管理において、組織は次のような課題を抱えています。
  • 複雑な勤怠ルール:固定シフト制、シフト制、フレックスタイムなど、複数の形態が混在しています。手動での設定は時間がかかり、ミスも起こりがちです。
  • 頻繁な人事異動:入社・退社・異動のたびに、勤怠グループのメンバーを手動で更新する必要があります。社員数 1,000 人以上の組織では、この作業に毎週数時間を費やしています。
  • システム間の同期がない:人事システムでの組織構成の変更が DingTalk の勤怠グループにすぐ反映されず、打刻データの誤りにつながります。
  • 一括操作ができない:管理者は複数の勤怠グループを一度に作成・更新できません。1 つずつ更新するため、非常に非効率です。

主なメリット

本ソリューションにより、組織は次のことを実現できます。
  • 勤怠グループ管理の自動化:API で勤怠グループを作成・照会・更新・削除し、手作業を一切不要にします。
  • スマートなシフト関連付け:新しいシフトを作成するか、既存のシフトを自動で関連付けて、勤怠ルールの正確性を保ちます。
  • 効率的な一括実行:勤怠グループを一括で取得・検索・更新し、運用効率を大幅に高めます。
  • システム間データの一元化:人事、OA、DingTalk 勤怠のデータをリアルタイムで同期し、データのサイロ化を解消します。

ユースケース

本ソリューションは、次のような代表的な業務シナリオに適しています。
  • 人事システム連携:人事管理システムの勤怠ルールを DingTalk の勤怠グループに自動で同期します。
  • 合併・買収:新たに買収した企業向けに、勤怠グループとシフト設定をすばやく一括作成します。
  • OA 作業フロー連携:承認フローの完了時に、対応する勤怠グループを自動で作成または調整します。
  • 権限の動的調整:部門の変更に応じて、勤怠グループのメンバーと管理者権限を自動で更新します。

代表的な業務シナリオ

シナリオ 1:人事システムから勤怠グループを同期する(一括作成と管理)

課題

従来のモデルでは、人事担当者が人事システムで新しい勤怠ルールを策定した後、DingTalk 管理コンソールにログインし、勤怠グループの作成、シフトの設定、メンバーの追加を 1 つずつ手動で行う必要がありました。社員数 1,000 人以上の組織では、勤怠グループは通常 20〜50 個あります。手動での設定には数時間かかり、シフトの誤りやメンバーの登録漏れが頻繁に発生します。

効果の検証

  • 自動化された作業フロー API ベースの自動化フローは次の手順で実行されます。
    1. 人事システムに新しい社員が登録されます。
    2. システムが社員の部門に基づいて、該当する勤怠グループを自動で特定します。
    3. システムが API で新しいメンバーを一括追加します。
    4. システムが結果をリアルタイムで検証・確認します。
    5. 打刻権限が即座に有効になります。
  • 主な利点
    • 完全自動のトリガー:人事担当者が人事システムに新しい社員を入力すると、API 呼び出しが自動で実行されます。DingTalk 管理コンソールへのログインや、手動でのアクション開始は不要です。エントリと同期が同時に行われます。
    • 正確なマッチング:システムが社員の部門 ID に基づいて勤怠グループの groupKey を自動で照会・照合します。勤怠グループの手動選択ミスによる打刻エラーを防ぎます。
    • 即時反映:社員一括追加 API でメンバーを一括追加した後、ID によるメンバー照会 API で結果を即座に検証します。社員は勤怠グループに参加した時点で打刻できます。
    • 監査証跡:API 呼び出しごとに、操作者、タイムスタンプ、勤怠グループ ID、社員の userId などの詳細を記録し、コンプライアンス監査とトレーサビリティの要件を満たします。

シナリオ 2:組織構成の変更後に勤怠グループを自動同期する

課題

部門の統合・分割や社員の異動が発生すると、人事担当者は影響を受ける各勤怠グループのメンバーリストとシフト設定ルールを手動で更新する必要があります。大規模な組織再編では、数十の勤怠グループが対象になることもあります。手動更新は時間がかかるうえに一部のグループを見落としやすく、社員の打刻エラーの原因になります。

効果の検証

  • 自動化された作業フロー 自動化フローは次の 5 つの手順で実行されます。
    1. OA承認によるトリガー:部門の統合・分割や人事異動の承認が通過すると、システムが変更イベントを自動で取得します。
    2. 影響を受ける勤怠グループの特定:システムが変更された部門 ID に基づいて、関連するすべての勤怠グループを自動で照会します。
    3. API による一括更新:システムが DingTalk の勤怠グループ更新 API を呼び出し、メンバーリストとシフト設定を一括で変更します。
    4. リアルタイムのデータ検証:更新直後に、システムが照会 API を呼び出し、すべての勤怠グループのデータ整合性を検証します。
    5. 同期完了:勤怠グループの同期が完了し、更新された勤怠ルールが手作業なしで有効になります。
  • 主な利点
    • 自動トリガー:OA承認の承認フローが完了すると、システムが変更イベントを取得して同期を自動で実行します。手動での開始や監視は不要です。承認と同期が同時に行われます。
    • 正確な一括処理:影響を受けるすべての勤怠グループを一度に特定して更新します。手動での確認による漏れを防ぎ、組織変更を 100% 反映します。
    • リアルタイムの検証とフィードバック:更新直後に照会 API を呼び出してデータ整合性を検証し、エラー時には自動でアラートを送信します。勤怠ルールが正しく有効になることを保証します。
    • 完全な監査ログ:API 呼び出しごとに、操作者、タイムスタンプ、変更コンテンツを記録し、コンプライアンス監査とトレーサビリティの要件を満たします。

実装ガイド

技術アーキテクチャ

本ソリューションは、DingTalk オープンプラットフォームのサーバー API をベースに構築されています。主な技術コンポーネントは次のとおりです。
  • 認証レイヤー:Client ID と Client Secret を使って access_token を取得し、API 呼び出しの安全性を確保します。
  • 勤怠グループ管理レイヤー:勤怠グループを作成・照会・更新・削除するための API 機能一式を提供します。固定シフト制の勤怠グループとシフト制の勤怠グループに対応しています。
  • シフト管理レイヤー:シフトを作成・照会するための API 機能を提供します。シフトは勤怠グループの前提となるリソースです。
  • エラーハンドリングレイヤー:包括的なエラーコード体系を提供し、問題の特定と解決を迅速化します。
API バージョン:サーバー API には新バージョンと旧バージョンがあります。パフォーマンスと機能サポートに優れた新バージョンを優先して使用してください。

前提条件

ソリューションを実装する前に、次の条件を満たしてください。
  • アプリの準備:社内アプリを作成して設定します。詳しくは、アプリの作成と設定を参照してください。
  • 権限要件:DingTalk の組織管理者またはサブ管理者の権限を持ち、次の API 権限を申請します。
    • qyapi_attendance_group_manage(勤怠グループ管理権限)
    • qyapi_attendance_group_read(勤怠グループ照会権限)
  • 開発環境:Java 開発環境(JDK 1.6 以降)と Maven ビルドツールをインストールします。
  • SDK の準備:DingTalk サーバーサイド SDK をダウンロードします。詳しくは、「サーバーサイド SDK のダウンロード」を参照してください。SDK は Java、Python、Go などの言語に対応しています。

コードの実装

ステップ 1:クライアント ID と Client Secret を含む、アプリ認証情報を取得します。 ステップ 2:勤怠関連の API 権限を申請します。 ステップ 3:アプリのアクセス認証情報を取得します。社内アプリの access_token の取得を参照してください。API を呼び出す際、アクセストークンによって呼び出し元の身元が認証されます。 ステップ 4:勤怠関連の API を呼び出します。
  1. サーバー API 勤怠グループの作成を呼び出し、勤怠グループの id を取得します。

注意

本ドキュメントの例では、固定シフト制の勤怠グループを使用しています。 固定シフト制の勤怠グループを作成するには、勤怠グループ作成 API を呼び出す前に、シフトが存在することを確認してください。
  • シフトが存在しない場合は、サーバー API シフトの作成を呼び出してシフト ID を取得します。
  • シフトがすでに存在する場合は、サーバー API シフト概要の取得を呼び出して既存のシフト ID を取得します。
  1. 勤怠グループ情報を取得します。
  2. 勤怠グループの id を指定してサーバー API 勤怠グループの更新を呼び出し、勤怠グループの名前やシフトなどの情報を変更します。
  3. 勤怠グループの groupKey を指定してサーバー API 勤怠グループの削除を呼び出し、勤怠グループを削除します。

実装手順

ステップ 1:アプリ認証情報を取得する

  1. DingTalk 開発者コンソールにログインします。
  2. 対象のアプリを選択し、アプリの詳細ページを開きます。
  3. 基本情報 > 認証情報と基本情報をクリックします。
  4. アプリの Client ID と Client Secret を控えておきます。

注意

Client Secret は安全に保管し、第三者と絶対に共有しないでください。コードにハードコーディングせず、環境変数または鍵管理システムに保存してください。

ステップ 2:API 権限を追加する

  1. アプリの詳細ページで、権限管理をクリックします。
  2. 権限の検索ボックスに次の権限識別子を入力し、申請します。
    • qyapi_attendance_group_manage(勤怠グループ管理権限):勤怠グループの作成・更新・削除に使用します。
    • qyapi_attendance_group_read(勤怠グループ照会権限):勤怠グループの概要と詳細の照会に使用します。
業務シナリオによって、必要な権限の組み合わせは異なります。実際のニーズに応じて申請してください。たとえば、一括インポートのシナリオでは、ユーザーの一括操作に関する権限も必要です。

ステップ 3:アクセス認証情報(access_token)を取得する

ステップ 1 で取得した Client ID と Client Secret を使い、アプリのアクセス認証情報を取得します。社内アプリの access_token の取得を参照してください。
ベストプラクティス:
  • キャッシュ戦略:access_token の有効期間は 2 時間です。メモリまたは Redis にキャッシュし、有効期限の 5分前に先行して更新してください。
  • 同時実行制御:複数のスレッドが同時にトークンを更新すると、競合が発生します。分散ロックを使用して防止してください。
  • エラー時のリトライ:ネットワークが不安定な場合は、最大 3 回まで、間隔を段階的に延ばしながら(1 秒 → 2 秒 → 4 秒)自動でリトライしてください。

ステップ 4: コア API を呼び出す

勤怠グループを作成する

本ドキュメントの例では、固定シフト制の勤怠グループを使用しています。
固定シフト制の勤怠グループを作成するには、勤怠グループ作成 API を呼び出す前に、シフトが存在することを確認してください。
  • シフトが存在しない場合は、サーバー API シフトの作成を呼び出してシフト ID を取得します。
  • シフトがすでに存在する場合は、サーバー API シフト概要の取得を呼び出して既存のシフト ID を取得します。
API 説明:サーバー API 勤怠グループの作成を呼び出し、勤怠グループの id を取得します。

勤怠グループ情報を取得する

  • 組織内のすべての勤怠グループの情報を取得する
    1. 勤怠グループ概要の一括取得:サーバー API 勤怠グループ概要の一括取得を呼び出し、組織内のすべての勤怠グループの概要を取得します。
    2. 勤怠グループ詳細の一括取得:サーバー API 勤怠グループ詳細の一括取得を呼び出し、組織内のすべての勤怠グループの詳細を取得します。
    3. 勤怠グループ概要の検索:サーバー API 勤怠グループ概要の検索を呼び出し、名前で勤怠グループをあいまい検索します。
  • 単一の勤怠グループの情報を取得する
    1. 単一の勤怠グループの詳細を取得:勤怠グループの id を指定してサーバー API 勤怠グループ詳細の取得を呼び出し、単一の勤怠グループの詳細を取得します。
    2. groupId から groupKey への変換:勤怠グループの id を指定してサーバー API groupId から groupKey への変換を呼び出し、勤怠グループの groupKey を取得します。
    3. groupKey による勤怠グループ情報の照会:勤怠グループの groupKey を指定してサーバー API groupKey による勤怠グループ情報の照会を呼び出し、勤怠グループ情報を取得します。

勤怠グループを更新する

勤怠グループの id を指定してサーバー API 勤怠グループの更新を呼び出し、勤怠グループの名前やシフトなどの情報を変更します。

勤怠グループを削除する

勤怠グループの groupKey を指定してサーバー API 勤怠グループの削除を呼び出し、勤怠グループを削除します。

注意

  • 勤怠グループに在籍中の社員がいないことを確認してください。事前に勤怠グループ詳細の取得 API を呼び出して確認します。
  • 勤怠グループに関連付けられたタスクや承認フォームなどを、他の勤怠グループに転送してください。
  • 必要に応じて、勤怠グループの履歴データをバックアップしてください。
  • 関係部門(IT、人事、総務など)に通知し、後続のクリーンアップを完了してもらってください。

よくある質問

  • Q1:勤怠グループの作成時に「シフトが存在しません」というエラーが表示された場合は、どうすればよいですか? A:固定シフト制の勤怠グループには、既存のシフトが必要です。まず シフトの作成 API を呼び出すか、シフト概要の取得 API を呼び出して既存のシフト ID を取得してください。その後、勤怠グループを作成します。
  • Q2:すべての勤怠グループの情報を一括で取得するには、どうすればよいですか? A:2 つの手順で行います。まず、勤怠グループ概要の一括取得を呼び出し、すべての勤怠グループの概要情報(id を含む)を取得します。次に、必要に応じて 勤怠グループ詳細の一括取得を呼び出し、詳細情報を取得します。
  • Q3:勤怠グループの id と groupKey の違いは何ですか? A:id は勤怠グループの数値型の識別子で、groupKey は文字列型の識別子です。勤怠グループの削除など、一部の API では groupKey が必要です。groupId から groupKey への変換 API を使って相互に変換できます。
  • Q4:勤怠グループを更新する際、すべてのフィールドを渡す必要がありますか? A:いいえ、必要ありません。変更するフィールドと勤怠グループの id だけを渡してください。省略したフィールドは元の値が維持されます。