Pleasanterで安全講習の承認完了後、運転者台帳の受講日を自動更新した実装例

Pleasanterで申請業務と台帳管理を行っていると、あるサイトで承認された内容を、別サイトの台帳へ転記する作業が発生することがあります。今回対象となったのは、「安全講習受講連絡」サイトで承認された受講日を、「業務用自動車運転者台帳」の直近安全講習受講日へ反映する業務です。

従来は、申請の承認完了後に担当者が対象者を台帳から探し、受講日を手作業で入力していました。しかし、申請件数が増えると、転記漏れ、日付の入力間違い、別の社員への誤登録などが発生する可能性があります。また、承認状況と台帳の更新状況を別々に確認しなければならず、担当者の負担も小さくありません。

そこで、承認フローが完了したことを契機として、社員番号で対象者の台帳レコードを検索し、該当レコードの「直近安全講習受講日」を自動更新する仕組みを実装しました。

別サイトのレコードを更新する処理では、単に日付を書き込むだけでなく、2つのサイトをどの項目で紐づけるか、いつ処理を実行するか、対象が見つからない場合にどうするか、再実行による二重更新をどう防ぐかまで検討する必要があります。本記事では、実際の処理の流れと、実装時に考慮した点を整理します。

今回自動化した業務

安全講習を受講した社員は、「安全講習受講連絡」サイトから受講日などを申請します。申請後は、内容の確認や承認を行い、承認フローが完了した時点で正式な受講実績として扱います。

一方、「業務用自動車運転者台帳」には、社員ごとの免許情報や講習受講状況などを登録しており、その中に「直近安全講習受講日」という項目があります。承認済みの受講日をこの項目へ反映することで、各社員が最後に講習を受けた日を台帳から確認できます。

従来は、承認後に担当者が申請内容を開き、社員番号や氏名を確認したうえで、別サイトの台帳を検索していました。その後、該当レコードを編集し、受講日をコピーして保存していました。

この作業は1件ずつ見ると難しくありません。しかし、担当者が更新を忘れた場合、台帳には古い日付が残ります。また、複数の申請をまとめて処理すると、別の社員へ日付を入力する可能性もあります。その結果、受講状況の確認や次回講習の案内に影響するおそれがあります。

そこで、承認フローの完了を検知し、台帳更新までを自動化しました。担当者は申請内容と承認結果を確認すればよく、承認後の転記作業を行う必要がありません。

使用する2つのPleasanterサイト

今回の処理では、申請を管理するサイトと、社員ごとの情報を管理する台帳サイトを使用します。サイトの役割を分けたまま連携するため、申請履歴と最新の台帳情報をそれぞれ適切に管理できます。

安全講習受講連絡サイト

「安全講習受講連絡」サイトには、対象者を識別する社員番号、氏名、受講日、申請状況、承認状況などを登録します。台帳更新に必要な最低限の情報は、社員番号と受講日です。

承認前の申請内容が台帳へ反映されると、差し戻しや却下になった情報まで正式な受講実績として登録されてしまいます。そのため、申請が登録された時点ではなく、承認フローが完了した時点で更新処理を行います。

業務用自動車運転者台帳サイト

「業務用自動車運転者台帳」には、社員ごとに1件のレコードを作成し、社員番号、氏名、所属、免許情報、講習受講日などを管理します。今回更新するのは「直近安全講習受講日」です。

台帳には原則として社員1人につき1件だけ存在する状態を想定します。そのため、同じ社員番号で複数のレコードが見つかった場合は、自動的にどれか1件を更新せず、異常として処理を中止します。

2つのサイトを社員番号で紐づける

2つのサイトを紐づけるキーには、氏名ではなく社員番号を使用します。同姓同名の社員がいる場合や、結婚などによって氏名が変更された場合でも、社員番号が一意であれば同じ人物を特定できます。

社員番号が未入力の申請は台帳と紐づけられないため、申請時の必須チェックも必要です。可能であれば、利用者が自由入力するのではなく、社員マスターなどから選択して社員番号を設定する仕組みにすると、入力間違いを減らせます。

処理の全体フロー

処理は、申請の承認完了を起点として実行します。最初に申請レコードから社員番号と受講日を取得し、社員番号を検索条件として運転者台帳を検索します。対象が1件だけ見つかった場合に、直近安全講習受講日を更新します。

安全講習を申請
  ↓
承認フローが完了
  ↓
申請レコードから社員番号と受講日を取得
  ↓
社員番号で運転者台帳を検索
  ↓
対象レコードが1件か確認
  ↓
直近安全講習受講日を更新
  ↓
更新結果とログを確認

検索結果が0件の場合は、台帳に対象社員が登録されていない可能性があります。複数件の場合は、社員番号が重複しているか、検索条件に問題がある可能性があります。どちらの場合も自動更新せず、エラーとして記録します。

対象が1件の場合でも、すぐに更新するのではなく、受講日の値が正しい日付か、申請が本当に承認完了状態か、すでに同じ処理が実行されていないかを確認します。

更新後は、台帳の保存が正常に完了したことを確認します。さらに、申請元レコードへ「台帳更新済み」の状態や処理日時を記録すると、運用担当者が処理結果を追跡しやすくなります。

別サイトのレコードを取得する方法

別サイトの台帳を更新するには、まず対象レコードを正確に取得する必要があります。今回の検索条件には、申請レコードに登録された社員番号を使用します。

社員番号を検索条件にする

実装では、安全講習受講連絡サイトから社員番号を取得し、業務用自動車運転者台帳の社員番号項目と完全一致するレコードを検索します。前方一致や部分一致にすると、似た番号の社員が検索結果へ含まれる可能性があるため、完全一致を使用します。

また、社員番号の前後に空白が含まれていると一致しない場合があります。検索前に空白を取り除く、文字列として桁数を統一するなど、登録ルールをそろえておくことが重要です。

同姓同名では検索しない

氏名は人が確認するための情報としては便利ですが、システム間連携のキーには適していない場合があります。同姓同名が存在するほか、漢字、旧字体、スペースの有無、姓の変更などによって一致しない可能性があるためです。

一方、社員番号が一意に管理されていれば、氏名が変更されても同じ社員として検索できます。検索結果を表示するログには、社員番号と氏名の両方を残すと、担当者が確認しやすくなります。

対象が0件・複数件の場合の扱い

複数件見つかった場合に先頭の1件だけを更新すると、誤った台帳を更新する危険があります。検索結果が想定どおり1件であることを確認してから、更新処理へ進む設計にします。

取得したレコードを更新する

対象レコードを1件に特定できたら、安全講習受講連絡サイトの受講日を、運転者台帳の「直近安全講習受講日」へ設定します。更新方法には、Pleasanterのサーバースクリプトから処理する方法や、APIを使用する方法などがあります。

実際のサイトID、項目名、APIの呼び出し方法は環境によって異なるため、以下は処理の構造を示す実装イメージです。

const employeeNumber = /* 申請サイトの社員番号 */;
const trainingDate = /* 申請サイトの受講日 */;
const approvalStatus = /* 申請サイトの承認状態 */;

if (approvalStatus !== '承認完了') {
return;
}

if (!employeeNumber || !trainingDate) {
throw new Error('社員番号または受講日が未入力です。');
}

const records = searchDriverLedger(employeeNumber);

if (records.length === 0) {
throw new Error('対象者の運転者台帳が見つかりません。');
}

if (records.length > 1) {
throw new Error('同じ社員番号の台帳が複数見つかりました。');
}

const target = records[0];

updateDriverLedger(target.id, {
latestSafetyTrainingDate: trainingDate
});

この例のsearchDriverLedgerとupdateDriverLedgerは、検索と更新の役割を表す仮の関数です。実際には、使用中のPleasanter環境に合わせて、サーバースクリプトまたはAPIの処理へ置き換えます。

更新前の日付を確認する

「直近安全講習受講日」という項目を更新する場合は、現在の台帳日付より古い受講日で上書きしないようにすることも重要です。たとえば、後から過去分の申請が承認された場合、そのまま更新すると最新の日付が古い日付へ戻る可能性があります。

そのため、台帳に登録されている日付と今回の受講日を比較し、今回の日付が新しい場合だけ更新する方法があります。同じ日付であれば更新不要として正常終了させると、不要な更新履歴を減らせます。

if (!target.latestSafetyTrainingDate ||
    trainingDate > target.latestSafetyTrainingDate) {
  updateDriverLedger(target.id, {
    latestSafetyTrainingDate: trainingDate
  });
}

更新履歴を残す

自動更新では、誰がいつ何を変更したかを後から確認できるようにします。Pleasanter側の更新履歴に加えて、申請元ID、対象台帳ID、社員番号、更新前の日付、更新後の日付、処理日時、処理結果などをログへ残すと、障害時の調査がしやすくなります。

承認完了時だけ実行する

別サイトの台帳更新は、申請レコードが保存されるたびに実行するのではなく、承認フローが完了したときだけ実行します。申請中や差し戻し中のデータを台帳へ反映すると、確定していない情報が正式な受講実績として登録されるためです。

保存するたびに更新しない

申請内容の修正、コメントの追加、承認途中の保存など、1件の申請に対して保存処理は複数回発生します。保存イベントだけを条件にすると、そのたびに台帳更新が実行される可能性があります。

そこで、現在の承認状態が「承認完了」であることに加え、承認完了へ遷移したタイミングであることを確認します。可能であれば、変更前の状態と変更後の状態を比較し、「承認中から承認完了へ変わった場合」に限定します。

再実行時の二重更新を防ぐ

通信エラーや一時的な処理失敗が発生すると、同じ申請を再保存したり、管理者が処理を再実行したりすることがあります。その際、同じ日付を何度も書き込むだけであれば結果は変わりませんが、更新履歴や通知が重複する可能性があります。

二重実行を防ぐ方法として、申請元に「台帳更新済み」「台帳更新日時」「更新先レコードID」などの項目を用意する方法があります。また、更新先の日付と申請の受講日が同じ場合は更新不要として終了する方法も有効です。

エラー時に考慮したこと

別サイトの更新では、申請元の保存には成功したものの、台帳更新だけが失敗する可能性があります。そのため、エラーを無視して承認処理を完了させるのか、台帳更新に失敗した時点で処理全体を止めるのかを決める必要があります。

台帳に対象者が存在しない

対象が0件の場合は、社員番号の入力間違いか、台帳への登録漏れが考えられます。新しい台帳レコードを自動作成する設計も可能ですが、必要な項目が不足した状態で台帳を作成する危険があります。今回のように既存台帳の更新を目的とする場合は、自動作成せず、エラーとして担当者へ確認を促す方が安全です。

社員番号が未入力

社員番号がなければ検索できないため、申請前の必須チェックで止めることが基本です。それでも空の値が処理へ渡された場合に備え、サーバー側でも未入力チェックを行います。

複数レコードが見つかる

同じ社員番号のレコードが複数見つかった場合は、どれが正しい台帳か判断できません。自動的に更新せず、台帳管理者が重複を解消してから再実行します。

台帳の更新権限がない

検索できても更新権限がなければ、レコードの保存に失敗します。処理を実行するユーザーやAPIキーに、対象サイトの参照権限と更新権限が付与されているか確認します。ただし、必要以上に広い権限を与えず、対象サイトと必要な操作に限定します。

更新途中で処理に失敗する

更新要求の送信後に応答が途切れた場合、実際には更新済みである可能性があります。再実行する前に台帳の現在値を取得し、すでに受講日が反映されていないか確認します。

自動更新後の確認方法

実装後は、正常系だけでなく、対象が存在しない場合や複数見つかる場合もテストします。本番環境で初めて異常系が発生すると、承認済みなのに台帳だけ更新されていない状態を見落とす可能性があります。

台帳の日付を確認する

テスト用の社員番号と受講日を使用して申請を作成し、承認完了後に運転者台帳の「直近安全講習受講日」が更新されていることを確認します。社員番号と対象レコードIDも確認し、別の社員を更新していないことを確かめます。

ログと更新履歴を確認する

申請元ID、更新先ID、更新前後の日付、処理結果がログへ記録されていることを確認します。失敗時には、どの条件で止まったのか分かるメッセージが必要です。

異常系をテストする

本番反映前には、テスト用サイトまたはテスト用レコードを使い、実際の承認操作から台帳更新までを一連で確認します。個別の検索処理や更新処理だけでなく、承認フローと組み合わせた状態で確認することが重要です。

まとめ

Pleasanterで別サイトの台帳を自動更新する場合は、更新用のコードを書く前に、2つのサイトをどの項目で紐づけるか、どの状態を更新の契機にするかを明確にする必要があります。

今回の実装では、「安全講習受講連絡」サイトの承認完了を契機として、社員番号で「業務用自動車運転者台帳」を検索し、対象者の「直近安全講習受講日」を更新しました。氏名ではなく社員番号を使用することで、同姓同名や氏名変更による誤判定を避けています。

検索結果が0件または複数件の場合は、自動更新せずにエラーとしました。対象が1件の場合でも、受講日が現在の台帳日付より新しいか、すでに同じ申請を反映済みではないかを確認してから更新します。

また、保存のたびに処理するのではなく、承認フローが完了した場合だけ実行します。申請元に更新済み状態や更新日時を記録し、再実行時の二重更新を防ぐことも重要です。

別サイト連携では、正常に更新できる処理だけでなく、対象者が存在しない、社員番号が重複している、更新権限がない、応答途中で失敗するといった異常系を含めて設計します。そして、申請ID、更新先ID、更新前後の値、処理結果をログへ残すことで、問題発生時に状況を追跡できます。

申請から台帳更新までを自動化すると、担当者の転記作業を減らせるだけでなく、更新漏れや入力間違いも防ぎやすくなります。別サイトを更新する仕組みでは、「誰を更新するか」「いつ更新するか」「失敗時にどうするか」の3点を明確にすることが、安定した運用につながります。