濱生快彦
1　長い前書き
この小文では、平成19年9月に実施した、業務システムの更新について報告する。私は現在、庶務エントランスチームに所属し、新たに稼動した図書館業務システムiLiswave-Jに関する業者対応の窓口を担当しているが、この担当になったのは平成19年4月からであり、その前年は文庫の業務を担当していたこともあって、システムの更新に関するプロセス全体について知る立場になかった。したがって、私にはまず、編集委員会から与えられたこのテーマについて、十分に応えられるのか疑問に思うところがあるのだが、一応現時点では、システムの管理の窓口業務を担当していることもあるので、せめて自分がかかわった部分を中心に記録し、報告に代えさせていただくことにしたいと思う。そもそも今回の業務システムの更新は、全学的な取り組みである、全学IT化推進プロジェクトの一部という位置づけでもあり、構想やシステム要件の確定についても、 ITセンターの協力を得ながら、次長、事務長、各チームリーダーをメンバーとする図書館システム会議を中心に検討が進められた経緯がある。検討の内容は随時、課員に周知されていたものの、当時収集・整理業務の担当であり、むしろ現在の業務の進め方が新しいシステムでも可能なのかどうか、フローを見直す必要がないかなど、システムの機能面に着目していたため、今となっては検討の経緯を正確に報告することが私にはできない。図書館活動報告としては、いささか中途半端なものになることは否めないが、こうした経緯によるものと理解していただければ幸いである。さて、上記のような制約はあるものの、まずは把握している限りでの今回の業務システムの更新にいたる、経緯とねらいについて、記述しておく。旧システムは、平成14（2002）年に導入した、日本電子計算社製のLINUSというシステムであった。このシステムは、本学図書館としては、初めてNacsis-catの書誌フォーマットに準拠したシステムであり、かつ自主開発でない、初めてのシステムでもあった。このシステムには、葉務上の必要から多くのカスタマイズを実施したこともあって、本学の図書館業務にフィットしていた面もあったものの、導入から4年以上経過し、サーバーの容量不足や、多言語に対応していないなど、いくつか深刻な課題が明確になってきていた。そこで、200万冊規模の大規模図書館に導入実績が多いこと、クライアントに資源をもたず、システム運用が容易であることなどから、富士:通社製のiLiswave−J (1)を、可能な限り標準の機能を使い、カスタマイズを最小限しか実施しない方針で導入することになった。導入するシステムをiLiswave−Jに決定した後、図書管理、雑誌管理、関覧業務、目録業務、相互利用（ILL)、OPACなどの利用者サービスごとに、機能の詳細をそれぞれの担当が詰めていき、機能を確定していった。この機能の確認のなかで、カスタマイズ実施の要否、標準の帳票を使えるか新たに本学用に作成するかどうか、などが詰められていった。本稿ではiLiswave−Jの機能の紹介は割愛するが、旧システムに比較して、仕事をシステムにあわせることにより、カスタマイズの部分は最小限に抑えることができたのではないかと思う。機能の検討と平行して、データ移行や、ハードウェアの更新（サーバー、PC）に関する計画も立てられた。残念ながら、すべての検討にかかわることができなかったこともあり、ここでは、データ移行と、運用テストから稼動までに実施したことを報告しておきたいと思う。
2 データ移行について
一般に図書館の業務システムというのは、巨大なデータベースであるが、各社が提供するデータベースには、たとえば根幹の部分が同じORACLEであったとしても(2)、仕様がそれぞれ異なっているため、あるシステムを他のシステムに移行する場合に、単に本棚の本を別の部屋の本棚に移し変えるというわけにはいかない。データベース固有の仕様と、移行先の仕様と一致していることはほとんどありえないため、システム間のデータ移行には、それなりの労力が必要になってくる。データベースの仕組みは、私の理解するところ、巨大な一覧表（テープル）がいくつも収められたもので、なおかつ、ある一覧表の項目のうち、いくつかの項目は、別の一覧表にも収められていて、一覧表相互のデータの参照、更新が可能になっているようなものであるかと思う。これらの一覧表の中にデータを書き込み、修正し、削除することで、閲覧業務、発注業務、支払業務、目録管理、ILLなどの機能が実現されている。たとえば、閲覧業務であれば、貸出が実施されると、貸出返却を管理するテープルに、資料のID、利用者のIDなどが書き込まれ、資料のIDから、他の一覧表にあるタイトルなどの書誌事項を呼び出したり、利用者IDから、別のテープルにある利用者の資格（学生なのか教員なのか等）を参照し、その資格から、貸出規則を参照して表示したり、といったことが実現できる。さて、いずれの図書館システムであっても、システムが実現しようとする目的は図書館で行われている業務を管理するという点で一致しているものの、データベースに収められた一覧表の内容がいちいち異なっているため、移行前のデータベースのデータを、移行後のデータベースのどの一覧表のどの項目に収めることが適切なのかということが問題になってくる。ある一覧表から、別の、しかしほぼ同じ目的の一覧表に内容を書き写すのに、項目が一致している場合は、単に該当の項目を探し出し、必要なデータの範囲（古いものは不要なので移行しなくてもよいなど）を特定すればよいが、項目が一致しない場合、たとえば前の一覧表では、 2つの項目を使って表現していたものが、移行先の一覧表では一項目で表現しなければならない、といったことが起こりうる。つまり、データ移行とは、記載された項目が異なる一覧表の間で、データを書き写すことといってよいかと思う。データ移行の作業は、業務システム更新に関する検討の初期から当時の電算担当メンバーを中心として、開始されていたが、職員の人事異動等の関係で、平成19年の4月から体制を改め、事務長の下にメンバーを集めてプロジェクトチームを作り、集中的に検討を実施した。プロジェクトチームでは、LINUSで使用していたテープルをすべて洗い出し、移行する必要があるかどうかを検討した。その後、移行が必要となった項目について、テープル全体の移行が必要なのか、一部であればどの項目が必要なのかを特定していった。また、テープル名だけでは内容が分からないものは、その都度データの中身を参照して、最終的に必要なものかそうでないかを特定した。最終的に移行する必要がある項目を、富士通側に提供し、富士通はその内容を元に、iLiswave－Jのテープルに該当するものを割り当てて、移行仕様書を作成した。といっても、富士通はLINUSのテープルの内容や、各テープルに記載された内容を、本学の図書館がどのように葉務で使用してきたかは、把握していない。そのため、今度は、富士通が作成した移行仕様書を、本学のプロジェクトチームのメンバーと共同で、逐一相互に誤解がないかを確認していった。また、富士通からは仕様を作成する過程で発生した疑問・課題を検討事項一覧という台帳にまとめていただき、必要な調査を行った。たとえば、本学図書館では請求記号を４段目までしか使用していないが、５段目に入力されているデータはないか、あるいはあったとしてもiLiswave−Jで保持可能な長さ以上のデータがないかなどを、SQLによりデータを抽出し、調査していった。また、コードが１対１で対応しない場合の対応表や、複数のコードを、 1つのコードにまとめるための変換表などを、必要なものを富士通にリストアップしてもらい、作成していった。並行して、移行のためのスケジュールも検討した。今回は年度の途中でのシステムの更新になるため、支払いデータなどは、子算を完全に執行していない状態でデータを動かさなければならない。そこで、支払いのステータスを勘案して、支払いを終えた状態か、もしくは発注中の状態のデータだけになるように、受入業務のスケジュール変更を、収書の担当に依頼したり、配送を一事中断するためのアナウンスを閲覧業務の担当者に依頼したりした。図書館の閉館日であった9月15日出から3日間をデータ移行の実施日として、貸出、返却、ILLなどの直前まで書き換わっていくデータの移行日とし、書誌データ・所蔵データ・支払いデータなど、早めに凍結できるデータを閲覧データより前倒しして、 ９月3日(月)に移行するようにスケジュールを立てた。結果、最終的には、図書書誌データ1,794,011件、雑誌書誌データ31,892件、図書所蔵データ2,320,845件、発注データ39,909件、継続発注中データ14,523件、雑誌一括所蔵データ56,832件のデータを移行することになった。思ったよりも移行後のデータにトラプルは生じなかったが、それでも本稼動になって、必要なデータが移行されていないことに気づいたり、パッケージの障害と思った課題が、実は移行データに起因するものだったというケースも出てきている。また、直接にデータ移行が理由で生じたわけではないが、同一のNCIDを持つ書誌が複数存在していたり（LINUSでは複数存在することがシステム上は許容されていた）、物理単位の書誌とNC書誌が混在していること、書誌にはNCIDがセットされているにもかかわらず、NCには登録されていない（NCの所蔵IDがセットされていない）データも多数存在していることなど、移行の結果分かった課題も山積しているのが現状である。LINUS以前に登録された、物理単位の書誌については、個別に書誌の差し替えを実施するには、件数が多すぎるため、将来的にはは、iLiswave-JのAuto機能を使って計画的に差し替えていくための検討が望ましいと思われる。 NC書誌であるにもかかわらず、NC所蔵IDがないデータについては、Nacsis-catへの所蔵データの登録漏れと思われるので、いずれかの時点で調査して登録していく必要がある。
3　稼動までの作業について（運用テスト）
次に、本稼動前の最終のテストとして実施した運用テスト（一般には結合テストとも呼ばれるようである）について記録しておく。 iLiswave-Jの機能の確定は、それぞれの業務担当者が、富士通の担当者と話し合いながら詰めていった。その成果物は、薬務フローとして提出されることになるが、運用テストでは、この薬務フローを元に、想定した業務がiLiswave−Jを使用して支障なく実施できるかを検証するものである。システムの担当者が、すべての業務を知っているわけではないので、テストは各薬務の担当者と協力して、画面の操作性を含めて実施した。具体的には、 8月の上旬10日ほどを集中してテストにあて、業務担当者が棄務フローに従って、データのパターンや、処理のパターンをできる限り洗い出して、リスト化し、実機を用いてテストしていった。ここで見つかった課題は、取りまとめて富士通に伝え、本番稼動までに修正してもらう必要があったが、想像よりも多い350件を超える課題がみつかった。本来であれば、本稼動までにすべてを解決することにこしたことはないが、まず課題を、障害なのか、こちらの意図がうまく伝わらなかったことによる仕様の変更要望なのかを仕分けし、かつ重要度をつけていった。運用テストの直前に実施したシステムテストについても多量の課題が明らかになっていたが、これについても同様の仕分けを行い、本番稼動までに、障害と判明しているものと、重要度が最重要となっているものについては、必ず解消してもらうよう依頼した。一方、障害が解消したかどうかについては、それを指摘した担当者のチェックが必要であったため、直前は、図書館内に作業場所を設け、富士通が派遣したSE、課題を提出した職員を中心にかなりあわただしく作薬を進めていったが、何とか予定を変更せずに、 9月18日以本番稼動にこぎつけることができた。現在も新たに、発見した障害や要望、Ｑ＆Ａなどは、連絡票と呼んでいる書式にまとめ、重要度をつけて、処理して行っており、運用テストの課題処理の方法を踏襲している。
4　終わりに
冒頭に申し上げたとおり、筆者が書くことのできる内容がいろいろな意味で限定されるために、図書館システムの更新についてという依頼に十分応えられていないとは思うが、主として自分がかかわったことを中心に報告として記録させていただいた。現在も、新たに発見される障害や、Ｑ＆Ａ、システムへの要望事項を連絡票の形で富士通と日々やりとりしながらよりよい葉務システムとなるように努力しているところである。引き続き、関係の皆様のご協力をお願いしたいと思う。また、システムの更新のタイミングは５年に一度くらいという話をよく耳にするが、５年に一度のタイミングにこの業務にかかわらせていただくことができたことは、幸福なことであったとも思う。
注注
(1) iLiswave-Jについては、芦田宗明、野村一成「新大学図書館パッケージ：iLiswave-J」 (FUJITSU 57 (2) 2006）や、富士通社ウェブサイトなどを参照のこと。 (2)実際にはiLiswave-JのデータベースはPOSTGRESと呼ばれるもので、ORACLEが搭載されていたLINUSととは異なっている。 (はまお　やすひこ　図書館事務室)