勤怠ルールの設定:勤怠グループを一括作成し、動的に調整する
概要
本ソリューションは、勤怠グループ管理をエンドツーエンドで自動化します。DingTalk オープンプラットフォームの勤怠グループ管理 API を使い、人事システムや OA システムなどの業務プラットフォームを DingTalk 勤怠と連携させます。背景
勤怠管理において、組織は次のような課題を抱えています。- 複雑な勤怠ルール:固定シフト制、シフト制、フレックスタイムなど、複数の形態が混在しています。手動での設定は時間がかかり、ミスも起こりがちです。
- 頻繁な人事異動:入社・退社・異動のたびに、勤怠グループのメンバーを手動で更新する必要があります。社員数 1,000 人以上の組織では、この作業に毎週数時間を費やしています。
- システム間の同期がない:人事システムでの組織構成の変更が DingTalk の勤怠グループにすぐ反映されず、打刻データの誤りにつながります。
- 一括操作ができない:管理者は複数の勤怠グループを一度に作成・更新できません。1 つずつ更新するため、非常に非効率です。
主なメリット
本ソリューションにより、組織は次のことを実現できます。- 勤怠グループ管理の自動化:API で勤怠グループを作成・照会・更新・削除し、手作業を一切不要にします。
- スマートなシフト関連付け:新しいシフトを作成するか、既存のシフトを自動で関連付けて、勤怠ルールの正確性を保ちます。
- 効率的な一括実行:勤怠グループを一括で取得・検索・更新し、運用効率を大幅に高めます。
- システム間データの一元化:人事、OA、DingTalk 勤怠のデータをリアルタイムで同期し、データのサイロ化を解消します。
ユースケース
本ソリューションは、次のような代表的な業務シナリオに適しています。- 人事システム連携:人事管理システムの勤怠ルールを DingTalk の勤怠グループに自動で同期します。
- 合併・買収:新たに買収した企業向けに、勤怠グループとシフト設定をすばやく一括作成します。
- OA 作業フロー連携:承認フローの完了時に、対応する勤怠グループを自動で作成または調整します。
- 権限の動的調整:部門の変更に応じて、勤怠グループのメンバーと管理者権限を自動で更新します。
代表的な業務シナリオ
シナリオ 1:人事システムから勤怠グループを同期する(一括作成と管理)
課題
従来のモデルでは、人事担当者が人事システムで新しい勤怠ルールを策定した後、DingTalk 管理コンソールにログインし、勤怠グループの作成、シフトの設定、メンバーの追加を 1 つずつ手動で行う必要がありました。社員数 1,000 人以上の組織では、勤怠グループは通常 20〜50 個あります。手動での設定には数時間かかり、シフトの誤りやメンバーの登録漏れが頻繁に発生します。効果の検証
-
自動化された作業フロー
API ベースの自動化フローは次の手順で実行されます。
- 人事システムに新しい社員が登録されます。
- システムが社員の部門に基づいて、該当する勤怠グループを自動で特定します。
- システムが API で新しいメンバーを一括追加します。
- システムが結果をリアルタイムで検証・確認します。
- 打刻権限が即座に有効になります。
-
主な利点
- 完全自動のトリガー:人事担当者が人事システムに新しい社員を入力すると、API 呼び出しが自動で実行されます。DingTalk 管理コンソールへのログインや、手動でのアクション開始は不要です。エントリと同期が同時に行われます。
- 正確なマッチング:システムが社員の部門 ID に基づいて勤怠グループの
groupKeyを自動で照会・照合します。勤怠グループの手動選択ミスによる打刻エラーを防ぎます。 - 即時反映:社員一括追加 API でメンバーを一括追加した後、ID によるメンバー照会 API で結果を即座に検証します。社員は勤怠グループに参加した時点で打刻できます。
- 監査証跡:API 呼び出しごとに、操作者、タイムスタンプ、勤怠グループ ID、社員の
userIdなどの詳細を記録し、コンプライアンス監査とトレーサビリティの要件を満たします。
シナリオ 2:組織構成の変更後に勤怠グループを自動同期する
課題
部門の統合・分割や社員の異動が発生すると、人事担当者は影響を受ける各勤怠グループのメンバーリストとシフト設定ルールを手動で更新する必要があります。大規模な組織再編では、数十の勤怠グループが対象になることもあります。手動更新は時間がかかるうえに一部のグループを見落としやすく、社員の打刻エラーの原因になります。効果の検証
-
自動化された作業フロー
自動化フローは次の 5 つの手順で実行されます。
- OA承認によるトリガー:部門の統合・分割や人事異動の承認が通過すると、システムが変更イベントを自動で取得します。
- 影響を受ける勤怠グループの特定:システムが変更された部門 ID に基づいて、関連するすべての勤怠グループを自動で照会します。
- API による一括更新:システムが DingTalk の勤怠グループ更新 API を呼び出し、メンバーリストとシフト設定を一括で変更します。
- リアルタイムのデータ検証:更新直後に、システムが照会 API を呼び出し、すべての勤怠グループのデータ整合性を検証します。
- 同期完了:勤怠グループの同期が完了し、更新された勤怠ルールが手作業なしで有効になります。
-
主な利点
- 自動トリガー:OA承認の承認フローが完了すると、システムが変更イベントを取得して同期を自動で実行します。手動での開始や監視は不要です。承認と同期が同時に行われます。
- 正確な一括処理:影響を受けるすべての勤怠グループを一度に特定して更新します。手動での確認による漏れを防ぎ、組織変更を 100% 反映します。
- リアルタイムの検証とフィードバック:更新直後に照会 API を呼び出してデータ整合性を検証し、エラー時には自動でアラートを送信します。勤怠ルールが正しく有効になることを保証します。
- 完全な監査ログ:API 呼び出しごとに、操作者、タイムスタンプ、変更コンテンツを記録し、コンプライアンス監査とトレーサビリティの要件を満たします。
実装ガイド
技術アーキテクチャ
本ソリューションは、DingTalk オープンプラットフォームのサーバー API をベースに構築されています。主な技術コンポーネントは次のとおりです。- 認証レイヤー:
Client IDとClient Secretを使ってaccess_tokenを取得し、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 を呼び出します。- サーバー API 勤怠グループの作成を呼び出し、勤怠グループの
idを取得します。
注意
本ドキュメントの例では、固定シフト制の勤怠グループを使用しています。 固定シフト制の勤怠グループを作成するには、勤怠グループ作成 API を呼び出す前に、シフトが存在することを確認してください。- シフトが存在しない場合は、サーバー API シフトの作成を呼び出してシフト ID を取得します。
- シフトがすでに存在する場合は、サーバー API シフト概要の取得を呼び出して既存のシフト ID を取得します。
-
勤怠グループ情報を取得します。
-
組織内のすべての勤怠グループの情報を取得する
- サーバー API 勤怠グループ概要の一括取得を呼び出し、組織内のすべての勤怠グループの概要を取得します。
- サーバー API 勤怠グループ詳細の一括取得を呼び出し、組織内のすべての勤怠グループの詳細を取得します。
- サーバー API 勤怠グループ概要の検索を呼び出し、名前で勤怠グループをあいまい検索します。
-
単一の勤怠グループの情報を取得する
-
勤怠グループの
idを指定してサーバー API 勤怠グループ詳細の取得を呼び出し、単一の勤怠グループの詳細を取得します。 -
groupKeyで勤怠グループの詳細を取得する- 勤怠グループの
idを指定してサーバー API groupId から groupKey への変換を呼び出し、勤怠グループのgroupKeyを取得します。 - 勤怠グループの
groupKeyを指定してサーバー API groupKey による勤怠グループ情報の照会を呼び出し、勤怠グループ情報を取得します。
- 勤怠グループの
-
勤怠グループの
-
組織内のすべての勤怠グループの情報を取得する
-
勤怠グループの
idを指定してサーバー API 勤怠グループの更新を呼び出し、勤怠グループの名前やシフトなどの情報を変更します。 -
勤怠グループの
groupKeyを指定してサーバー API 勤怠グループの削除を呼び出し、勤怠グループを削除します。
実装手順
ステップ 1:アプリ認証情報を取得する
- DingTalk 開発者コンソールにログインします。
- 対象のアプリを選択し、アプリの詳細ページを開きます。
- 基本情報 > 認証情報と基本情報をクリックします。
- アプリの
Client IDとClient Secretを控えておきます。
注意
Client Secret は安全に保管し、第三者と絶対に共有しないでください。コードにハードコーディングせず、環境変数または鍵管理システムに保存してください。
ステップ 2:API 権限を追加する
- アプリの詳細ページで、権限管理をクリックします。
-
権限の検索ボックスに次の権限識別子を入力し、申請します。
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 シフトの作成を呼び出してシフト ID を取得します。
-
シフトがすでに存在する場合は、サーバー API シフト概要の取得を呼び出して既存のシフト ID を取得します。
id を取得します。
勤怠グループ情報を取得する
-
組織内のすべての勤怠グループの情報を取得する
-
勤怠グループ概要の一括取得:サーバー API 勤怠グループ概要の一括取得を呼び出し、組織内のすべての勤怠グループの概要を取得します。
-
勤怠グループ詳細の一括取得:サーバー API 勤怠グループ詳細の一括取得を呼び出し、組織内のすべての勤怠グループの詳細を取得します。
-
勤怠グループ概要の検索:サーバー API 勤怠グループ概要の検索を呼び出し、名前で勤怠グループをあいまい検索します。
-
勤怠グループ概要の一括取得:サーバー API 勤怠グループ概要の一括取得を呼び出し、組織内のすべての勤怠グループの概要を取得します。
-
単一の勤怠グループの情報を取得する
-
単一の勤怠グループの詳細を取得:勤怠グループの
idを指定してサーバー API 勤怠グループ詳細の取得を呼び出し、単一の勤怠グループの詳細を取得します。 -
groupId から groupKey への変換:勤怠グループの
idを指定してサーバー API groupId から groupKey への変換を呼び出し、勤怠グループのgroupKeyを取得します。 -
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だけを渡してください。省略したフィールドは元の値が維持されます。