蔵書点検方法で悩む

復職18日目。夢に見る勢い。

ここ最近、ずっと蔵書点検のやり方について悩み中でした。今まで、特に疑問なく利用していた図書館システムの「マッチングシステム」なのですが、これだとうちの図書館、凄く大変なの！と主張され、「そうなんだー、確かに大変そうだよね」と思いましたし、代わりにこういう方法でやってみてはどうかと、という提案に「ほうほう、なるほどー」と思ったので、担当者さんと係長が仰るならやってみてはどうかと賛同し、システムの部署にも相談にいって、実際に走り出したのですが。

蔵書点検は、ハンディターミナルで資料1冊ずつのIDを読み込み、そのデータのグループと、所蔵データのグループを「マッチング（照合）」し、全部あるねと確認する「マッチング方式」がうちの図書館の標準です。ちなみにマッチング（照合）時に、読み込みされたのに所蔵データがないものがあれば、「配置場所違い」（通常、請求記号などで区切ったデータ同士を照合するため、別の請求記号の範囲のものが書架にぽんと置かれているとこのエラーが出ます）、逆に読み込みデータがなくて所蔵データのみのものは「行方不明」、それ以外にもまあ、色々なエラーが出ますが、それらに全部対処して、ようやく蔵書点検は終わります。

今回新たに提案されたのは、「ユーティリティ方式」。ハンディターミナルでIDを読み込む作業は同じ、これをマッチングをかけるのではなく、ユーティリティでIDから所蔵データを呼び出して、手動でエラーに該当するものを探し出し、OKなものは蔵書点検の日付を入れる「最終点検日」欄を最新日付にしていくという方法です。この場合、行方不明本は最終的に「最終点検日」が、蔵書点検期間より前になっているものばかりになり、後からこれを呼び出してまとめて確認することになります。

「ユーティリティ方式」の利点としては、「マッチング方式」では、請求記号などである程度の「グループ化」をしたデータ同士を照合するので、必ず「グループ化」が必要ですが、それが要らないため、複数人でわーっと適当にハンディターミナルで作業しても、特に問題が起きないところ。それから最初に行方不明本のエラーの嵐に遭わないで済むこと。うちの図書館は休館しないで蔵書点検するため、使用中でどこか館内の閲覧席に持ち出されている本というのはとても多いのです。そのため、「マッチング方式」を使うと大量のエラーが排出され、悲劇的なことになりますが、「ユーティリティ方式」なら危ないところは日をおいて二度読みしてあげれば、これらのエラーを少し減らせることになります。（マッチングだとその度ごとに無い本が違うとき、2度目に無い本が不明本にされてしまいますが、ユーティリティ方式だと1度目か2度目のどちらかで存在すればエラーになりません。）

問題として、「マッチング方式」は標準システムとして使用していることもあり、1日の利用可能件数が万の単位ですが、「ユーティリティ方式」だとそれほど大量のデータを更新されることを前提としていないシステムなので千の単位になってしまい、膨大な量を処理するには、時間的な制約を受けるということ。それに標準的なやり方でないものを採用すると、システムの部署の監視対象を増やして、余計な業務を生じさせてしまう可能性が。

色々考えて、手順もトレースし、実際の作業も始めてみているのですが、なんだかんだで既存の方法の方が優れている、というか、ちゃんと蔵書点検のために特化した機能なのだな、と思えてきました。ここまでに結構、時間がかかりましたが。館ごとの特有な問題もありますので、とりあえず両方の方法を試すことを再提案。特にマッチング方式の得意とする、ある程度のサイズで綺麗なグループ化の出来る範囲でテストです。最初に「なるほどー」と思ってすぐに、「じゃあその方法、試してみましょう！」というのは、考えが浅かったかなーと思いつつ、でも実際に走り出してみて問題がよく見えるようになったのだから、それはまた必要なことだった、という気もしつつ…、何だかんだでまだまだ色々なところが「最適化」されていないのだなあ、と。でも時代はどんどん変わって、そのときごとに「最適」が変わっていくのだから、仕方ないのかもしれませんね。