備品の貸出管理をアプリにする｜予約・返却・未返却の整理

備品の貸出管理をアプリへ移すなら、備品名と借りた人だけで管理してはいけません。現物ごとの個体ID、返却予定、返却後に再貸出できる条件を先に決めます。予約の重複を防ぐだけでは、返却遅れや破損した備品が次の予約へ渡る問題までは解けないからです。

予約は同じ備品IDの時間の重なりを確認し、貸出後は返却予定を過ぎた対象を識別します。さらに、返却受付の後に点検を置き、正常と確認してから次へ貸し出す運用なら、返却済みの備品も点検が終わるまでは貸出を保留します。

製品固有の仕様として引用する内容は、2026年9月28日に各公式ページで確認したものです。状態表と判断表は要件を考えるための設計案であり、実在する顧客の事例、導入実績、効果を示すものではありません。

備品の貸出管理アプリで最初に分ける二つの判定

予約表では「その時間に空いているか」を見ます。現物の管理では「いま貸し出してよい状態か」を見ます。この二つは似ていますが、同じ判定ではありません。

公式製品の例では、利用開始日時と終了日時を指定し、同じ物品の既存予約と時間が重なる新規予約を登録できない仕組みがあります。予約から利用開始、利用中、返却、利用履歴までを一連で管理する仕様です（備品の利用予約・予約管理｜tidie）。同一備品の二重予約を防ぐには、備品IDごとに予約期間を照合する考え方が直接対応します。

一方、貸出時には利用者、利用開始日時、利用終了予定日時を記録し、予定を過ぎた物品を期限超過として表示する仕様も確認できます（備品の貸出・返却管理｜tidie）。期限超過の表示から、返却登録がない対象を確認できます。現物が未返却なのか、返却済みで登録だけが抜けているのかは確認が必要です。次の予約への影響も、現物の状況と予約開始日時を照合して判断します。

管理項目は少なくとも次の単位に分けます。

• 備品マスター：備品ID、備品名、保管場所
• 予約：備品ID、利用開始予定、利用終了予定、予約者
• 貸出：備品ID、借用者、利用開始日時、返却予定日時
• 返却・点検：利用終了日時、点検結果、貸出停止理由、対応状況
• 次予約への影響：影響なし・要確認・影響ありの判定、返却・点検の完了見込み、振替・日時変更・取消の対応結果

この分け方なら、予約と返却後の点検結果が同じ備品IDへ結びつきます。貸出表を移す前に、現物の状態を変える記録と条件を決めます。

備品ID単位で予約・貸出・返却・点検をつなぐ状態表

予約の有無と現物の状態を一つの欄へ押し込むと、将来の予約が入っているだけなのか、いま貸出中なのかが曖昧になります。そこで、予約は時間枠として保持し、貸出可否は現物の状態に応じて判断します。

この表では「返却受付」の次に点検を置き、「貸出可」へ直行させません。破損や欠品があれば、返却済みでも貸出停止にします。

期限超過になった対象は、担当者が現物の返却状況を確かめます。すでに戻っていれば返却記録を補い、点検へ進めます。

引用したtidieの貸出・返却機能は、返却登録で利用終了日時を記録し、物品を再び利用可能にする仕様です。別の状態管理機能では、整備状況、外観、動作状態を物品ごとに記録し、「要点検」「点検中」「修理中」「清掃待ち」などの選択肢を設定できます。点検で正常と確認するまで貸出を止める制御は、これらの記録を結び付ける本記事の設計案です。導入先の製品で実現できるかは別途確認します。

返却遅延が次の予約へ及ぶときの判断表

時間の重なる予約を登録させなければ、予約時点の競合は防げます。ところが、前の利用が予定どおり終わらなければ、重なりのなかった次の予約にも影響が出ます。このとき次の予約を「履行可能」と自動判定しないことが要点です。

管理者は、返却と必要な点検・対応の完了見込みを、次の予約開始日時と照合します。間に合わない場合は「影響あり」として、代替備品への振替、予約日時の変更、取消から対応を確定します。見込みが不明な間は「要確認」を保ち、次の予約者への連絡内容と、対応を決める期限を記録します。間に合う見込みがあっても、実際の貸出は点検完了後です。

期限超過の表示だけでは、次の予約者へ何を伝え、予約をどう変更したかが残りません。確認や対応が未完了のまま閉じられないようにし、連絡と対応結果までを履歴に含めます。これで、未返却の把握が次の利用者への対応につながります。

貸出表から移す順序

既存の表を読み込む前に、運用の境界を決めます。移行作業全体の整理はExcelから業務システムへ移行する進め方も参照できますが、備品貸出では列の移し替えより先に現物との対応を固めます。

1. 各現物に重複しない備品IDを割り当てる
2. 現在の借用者と返却予定を備品IDへ結びつける
3. 将来の予約を備品IDと利用時間で登録する
4. 返却時の点検項目と、「貸出可」「貸出停止」の判定者を決める
5. 期限超過かつ次予約ありの場合の連絡先と、振替・変更・取消の記録方法を決める
6. 状態表の条件どおりに登録を拒否・保留できるかを確認する

とくに、表の中で同じ備品名が並んでいても、個体を区別できないまま予約を移してはいけません。予約、貸出、返却、点検の履歴が一つの備品IDでつながることが移行の基準です。

アプリ選定・開発前の受入条件

既製サービスと自社向けアプリのどちらを選ぶ場合も、次の業務条件を満たせるか確認します。方式の違いを整理したい場合は、SaaS・kintone・独自開発の比較も判断材料になります。

• 同じ備品IDの時間が重なる予約を登録できない
• 貸出開始時に借用者と返却予定日時を必須にできる
• 返却予定を過ぎ、利用終了日時がない備品を期限超過として識別できる
• 返却後、点検で正常と確認され、状態が「貸出可」になるまで次の貸出を開始できない
• 破損、欠品、要清掃などの貸出停止理由と対応状況を残せる
• 次の予約への影響が未確定な間は「要確認」とし、連絡内容と対応を決める期限を残せる
• 遅延または点検未完了が次の予約へ影響するとき、連絡と対応結果を履歴に残せる

現在貸出中の備品と次の予約を備品IDで照合し、返却が遅れた場合、返却登録だけが漏れた場合、返却後に破損が見つかった場合を試します。予約時間が重なっていなくても点検完了まで貸出を止め、次の予約への影響に応じて、確認中の記録や振替・変更・取消の結果を残せるかを確認します。

自社の貸出手順に合わせて状態、権限、通知、データ移行の範囲を詰めたい場合は、業務アプリの相談をご利用ください。初期開発と運用保守は個別見積もりとなるため、連携・移行・権限・データ出力の範囲を契約前に確認します。