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件でも、受講日が現在の台帳日付より新しいか、すでに同じ申請を反映済みでないかを確認してから更新します。

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

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

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