2017 Volume 60 Issue 2 Pages 110-118
埼玉医科大学における2016年4月の図書館システム更改に至るまでの検討過程および情報共有方法について報告する。図書館システム選定の方針は，（1）仕様書は作成しない，（2）カスタマイズは行わない，（3）チェックリストを作成し各社のシステムを評価する，である。選定の結果ベンダーを変更し，データ移行を行った。2016年3月末に全図書館職員が参加する運用会議を開催し，システムの使い方の意識を合わせた。情報共有にはNAS（Network Attached Storage）およびチャットツールSlackを用いた。これらのツールの使用により，システム担当者の負荷が軽減されることが確認できた。
学校法人埼玉医科大学（以下，本学）は2016年4月に図書館システムの更改を行った。ベンダーの変更を伴ったため事例として報告する。
本学は1972年に医学部のみの単科大学として埼玉県入間郡毛呂山（もろやま）町に開学し，1978年に大学院医学研究科を設置した。その後2006年に保健医療学部を3学科（看護学科・健康医療科学科・医用生体工学科）で開設し，2007年に保健医療学部理学療法学科を開設した。現在は毛呂山・川越・日高・川角（かわかど）の4つのキャンパスにて医師・看護師・臨床検査技師・臨床工学技士・理学療法士等を養成している。全キャンパスの学生数は3,809人，教職員数は1万230人である（2016年3月31日現在）。
4つのキャンパスのうち毛呂山・川越・日高キャンパスには附属病院が併設されている。3つの病院の病床数は合計約2,725床である。毛呂山からの距離は日高までは約3km，川角までは約5km，川越までは約30kmであるため徒歩での往来は難しい立地にある。
本学の図書館は各キャンパスに設置されており，毛呂山キャンパスの図書館を本館とし他を分館とする構成である（以下，地名のみで各キャンパスの図書館を指す）。
蔵書冊数は表1のとおりである。年間受入には研究室に配架する図書・雑誌も含まれている。日本医学図書館協会（JMLA）に所属している大学図書館の蔵書冊数の中央値注1）（表1にJMLA中央値として記載）と比較すると本学の蔵書数は中央値より多い。
毛呂山の利用者は主に医学部生・教職員・病院職員であるが，キャンパス内に埼玉医科大学短期大学および関連法人の埼玉医療福祉会看護専門学校があることから，短大生・看護専門学生も利用している。川越は病院内に設置されているため主に教職員・病院職員に利用され，臨床実習中の医学部生にも利用されている。日高は保健医療学部3学科の学生および教職員・病院職員に利用されている。川角は理学療法学科の学生・教職員が利用している。2015年度の来館者数は，毛呂山2万9,524人，川越1万6,184人，日高4万2,696人，川角9,077人である。
人員配置は毛呂山8人，川越3人，日高3人，川角2人であり，毛呂山と川越にはそれぞれパート職員2人・1人を含む。収書・整理業務は各館で行い，閲覧に供している。文献複写業務は，学内文献複写に関しては各館で依頼・受付を行っているが，学外文献複写は本館で取りまとめて依頼・受付を行っている。
図書館システムは2006年に導入し，2011年にはベンダーの変更を伴わない更改を実施した。この保守期限が2016年3月までであったため，2015年1月からシステム更改の検討を開始した。また，10年間同じシステムを使用していることから，より本学に合うシステムを検討したいという要求が図書館内にあったため，ベンダーの変更も併せて検討した。
新システムは，図書館職員による検討，図書館委員会での検討，学内稟議（りんぎ）による決裁，という流れで決定される。
図書館職員による検討では特に委員会は設けずに，システム担当者1人がシステム更改業務の取りまとめを行い，必要に応じて職員に作業を割り振った。職員の間で方針を定める際には，システム担当者から各館の職場の責任者へ伺いを立てて了承を得た。
こうして選定したベンダー案を教員により構成される図書館委員会で検討し，その決定内容を学内稟議に諮る。
3.2 選定の方針2015年3月に図書館職員の間で選定方針を議論した。そこで決定した方針は，（1）仕様書は作成しない，（2）カスタマイズは行わない，（3）チェックリストを作成し各社のシステムを評価する，というものである。
資料を受け入れて目録を作成する，貸出・返却を行う，相互貸借の状況を管理する，資料の取得価格を管理する，という基本的な機能は各社のシステムで実現されていた。このような共通部分を仕様として記述する工程を省略したかったため，仕様書を作成していない。
カスタマイズは一度行うと次回更改時に考慮しなければならないこと，システムのバージョンアップによりカスタマイズ部分が動作しなくなる場合はバージョンアップを諦めざるをえない可能性があることから行わないこととした。
チェックリストは各館から提案された業務ごとの要求をまとめた。全体で94項目あり，業務を閲覧，相互貸借，収書・整理，蔵書点検，サーバー運用，OPAC，その他に分けて記載した（表2）。今回の更改は旧システムの継続を視野に入れつつ，他のシステムを検討しているため，チェックリストの作成において旧システムで実現できないことの列挙とならないよう注意した。ただし，旧システムにはOPAC検索において書名の一部で検索した際にヒットしない書誌がある，貸出データ等の出力に自由度が少ないという問題があり，これらに関しては特に改善したい点であるため，チェックリストに記載した。
表2の各項目を設けた意図の一部を以下に述べる。
3.3.1 閲覧カウンターでの利用者対応を念頭に置いて要求を整理した。たとえば資料の有無を問われて資料検索画面から検索して所蔵が貸出中だった場合に，そのままその画面から予約を行いたい，という要求から「資料検索画面から予約できる」という項目を設けた。
3.3.2 相互貸借学外の図書館に申し込んだ複写文献の到着を利用者へ文書で連絡している。この文書には複写文献の著者名・論文名が記載される論文関係事項という項目がある。旧システムからこの文書を出力すると，画面上では正しく表示されている論文関係事項が途切れることがあったため「字数制限がない」という要求を挙げた。これに対して，字数制限はNACSIS-ILL注2）の制限であるため，どのベンダーもNACSIS-ILLに準拠しているという回答になる。しかし，文書に表示される範囲はベンダーごとに「フォントにより異なる」「Excel出力なのでセルの幅を変えて対応できる」のような回答が得られた。新システムでは画面上でも出力した文書でも論文関係事項が途切れることはなくなった。
3.3.3 収書・整理図書・雑誌に共通する発注や所蔵に関わる部分，図書として必要な項目，雑誌として必要な項目に分けた。図書・雑誌で管理したい情報（所在・巻・号・通号等）は旧システムの項目から作成した。本来はどのような項目で管理するかを図書館内で議論して作成すべきだと思うが，その機会を設けられなかったため旧システムで管理している情報を移行できるか，という視点で各候補システムを評価することとした。
書誌は総合目録データベースNACSIS-CAT注3）に準拠していることから，また，発注・所蔵データは各システムに図書館側で自由に設定できる項目があることから，これらのデータに関しては旧システムから問題なく移行できると考えていた。これを確認するために各システムに旧システムからの移行先となる項目があるかをチェックリストに記載した。
3.3.4 蔵書点検過去に実施した蔵書点検において必要であった事項から項目を作成した。
3.3.5 移行時のデータ出力費用更改を検討し始めたときに発覚した「他社システムへ移行する際のデータ出力が有料である」ことを今後回避するために「他システムへの移行時のデータ出力に費用が発生しないこと」という項目を設けた。
3.3.6 OPAC利用者がより検索しやすくなるよう項目を作成した。この部分は旧システムで実現できないことが他の項目よりも多く列挙されている。
3.4 選定における課題このチェックリストを用いた選定では，項目内容に対して「できる」と判断する基準を定めることが困難であった。3.3.1の項で述べた「資料検索画面から予約できる」に該当する具体例を示す。
あるシステムでは貸出・返却画面の中に資料検索画面を開くボタン（A）と予約画面を開くボタン（B）がある。Bのボタンを押して予約画面へ移動しても資料検索は行えるが，Aの検索画面からは予約を行えない。このとき，Bから予約を行えるため「できる」とも考えられるが，利用者から「資料を探している」と問われている最中に資料検索画面ではなく予約画面を開くことに違和感があるため「できない」と判断した。この問題は後述のように複数人で評価の妥当性を協議することで基準のブレを避けることができると思われる。
また，各候補システムで用語がばらばらだったために注意が必要だった。登録番号という言葉を例に挙げる。「図書館資料として登録したバーコード以外の番号」という意味で使うシステムと「バーコード番号」を指すシステムがあった。他にも受入日・整理日・検収日等の日付に関わる用語には齟齬（そご）が生じやすかった。言葉の意味の取り違えを防ぐために，本図書館内での意味を明確に伝えることで対応した。
3.5 選定とその結果JMLAの会員統計注1），雑誌資料1）を参考にして5社のシステムを検討した。検討したシステムは，CARIN-i（京セラコミュニケーションシステム），E-CatsLibrary（NEC），iLiswave-J（富士通），LIMEDIO（リコー），ネオシリウス（日本事務器）である。2015年1月から6月にかけて各社からシステムの概要説明・デモの実施を受けた。また，数社のシステムは2か月程度，試用した。
チェックリストには図書館のシステム担当者が「○」「×」を記入し，他の職員と各項目の評価が妥当であるか協議した。各社のデモおよび試用により，閲覧の貸出・返却等の機能，収書・整理で1冊の資料の発注・受入・整理に関わる機能，相互貸借の機能等は確認できたが，資料の一括発注，リンクリゾルバとの連携可否，利用統計の出力，緊急時貸出機能の有無等は各社に問い合わせて回答を得た。
2015年6月に職員の検討が終わってチェックリストの記入が完了し，図書館委員会にて図書館としての意向が決定された。幸い「○」が最も多いシステムの価格が最も安かったため，議論はスムーズに進行した。2015年10月に発注が行われ，データ移行の打ち合わせが始まった。
データ移行は，旧システムからの対象データ抽出，新システムへのデータ登録という流れになる。本データ移行ではデータ抽出の工程を新システムのベンダー（以下，新ベンダー）に依頼した。これは旧システムのベンダー（以下，旧ベンダー）のデータ抽出費用見積もりより新ベンダーの見積もりの方が抑えられた価格であったことによる。新ベンダーの説明は「自社で扱っているデータベースではないため多少の試行錯誤は必要となるが，そのデータベースからのデータ抽出実績はある」とのことだった。図書館としてはデータ抽出に失敗するリスクを含んだ決断となった。
4.1 移行仕様の検討旧システムが管理しているデータを新システムへ移行する際の仕様を検討した。この移行仕様の初版は旧システムから抽出したデータを基にして，新ベンダーが作成した。システム担当者はこれに対して移行先の変更や漏れているデータの指摘を行った。
このタイミングで旧システムから移行しない項目の洗い出しを行えた。たとえば旧システムでは所蔵情報に言語区分が存在したが，書誌のタイトル言語・本文の言語の項目で表現できていると考えられるので言語区分を移行しなかった。そのほか移行しない項目107件を検討し，そのうち105件を移行しないこととした。移行しない項目には貸出履歴が含まれている。新ベンダーから旧システムの貸出履歴と貸出中のデータが一致していないと連絡を受け，図書館としてどう対応するか協議した結果，貸出中のデータを信じ，貸出履歴を諦めることで意見はまとまった。しかし，分館の責任者から事前に，貸出に関する利用統計を旧システムから出力する必要があるとの指摘があり，旧システムから貸出の利用統計を出力した。貸出履歴を移行できないことの原因として，データ抽出費用の価格差，旧システムのデータベースに関する新旧ベンダー間の知識の差，旧システムの設計等を考えられるが特定できない。
入力時に選択肢が表示される項目にはコードを割り当てる必要がある。旧システムではコード間に階層構造をもつが，新システムは階層構造がない。たとえば所在の表現を丸カッコ内のコード番号とすると，旧システムでは所在1：毛呂山（2），所在2：図書館（201），所在3：1階事務室（20101）となっており，新システムでは所在：毛呂山 図書館 1階事務室（901001）となる。階層構造を大きく変更せずに移行する方針とし，32件のコード表について旧システムと新システムの対応表を作成した。
4.2 サンプル移行移行仕様・コード表の作成がある程度完了した後にサンプル移行を行った。2015年10月までに旧システムに登録されたデータを対象に実施した。この結果，資料ID（貸出時に使用するバーコード番号）の重複，雑誌として登録しなければならない資料の資料区分が旧システム上で図書として登録されていたケース等が発見された。これらは手作業で旧システムのデータを修正して対応した。
本標題の数と標題ヨミの数が合わないというワーニングもあったが約3万件の書誌が対象となるため対応できず，そのまま移行した。
サンプル移行の結果，移行仕様・コード表の修正すべき点を修正し本番移行を行った。
なお，本番移行後に発注番号で検索できない数百件の発注データが発見された。ベンダーと協議し，図書館側で移行の要不要の判断，移行する場合のデータの発注状態の決定を行い，ベンダーに再処理を依頼した。
新システムではOPACのトップページにお知らせやカレンダーを掲載でき，図書館のWebページのように表示できた。これを受けて既存の図書館Webページの新システムへの移行について検討を行った。
新システムに図書館Webページを移行するとHTMLで直接コンテンツを編集する必要がなくなり，職員は誰でもWebページ管理が行えるという利点がある。しかし，次回の更改で他のシステムが採択された場合は，新システムで作成されたコンテンツの移行が困難となる。自ら作成したコンテンツを管理できない状況になることは望ましくないため図書館Webページは新システムへ移行せず，既存のWebページを継続して管理することとした。
5.2 その他の事項の検討方法システムから利用者へ配信するメールの種類（延滞時，予約資料確保時など），OPACのデザインや表示する項目，発注番号や文献複写の受付番号などの番号体系等を図書館内で検討した。その際は検討事項の一覧表をExcelで作成し，学内のNAS（Network Attached Storage）に格納して，各キャンパスの担当者のアクセスを可能にし，一覧表の更新を行った。メールで連絡し合うと，更改の過程を文書に記録する際に過去のメールを探し当てながら作業を進める必要がある。これらの負担軽減のため，検討と記録を同時に行えるようNASを活用し，検討事項を管理することにした。
NASは図書館が独自に導入しており，各キャンパスの図書館から一つのハードディスクを操作することができる。NASにアクセスする際は図書館職員ごとに設定されたIDとパスワードを用いる。同一のファイルを複数人で同時に編集することはできない。これにより，（1）検討事項のファイル作成，（2）各キャンパスへ連絡，（3）各自ファイル編集，（4）ファイル確認，という流れで作業が行え，工数が削減できた。
5.3 運用会議の開催 5.3.1 目的新システムの使い方を全館で統一するために，本学の全図書館職員が参加する運用会議を2016年3月26日に開催した。ここでの使い方とは，各項目に入力する内容，および新システムの機能や手順を指す。
各項目の入力内容については，たとえば備考とメモという入力項目があった場合に，これまでどちらに何を入力するかが統一されていなかったので，OPACを見た利用者の混乱を招いていた。旧システムでは職員の間でそのような議論がないまま運用されていたため，今回の移行時に時間をかけてデータの整理を行う必要があった。次回更改のとき，データを整理する作業が軽減されるよう，項目ごとの入力内容を規定する作業が必要であった。
ベンダー開催の操作説明会において，新システムでの発注等の個別機能や操作手順は説明されている。しかしその説明には本学では使わない機能や手順も含まれている。そのため，本当に必要な機能や手順を整理し，決定する機会を設ける必要があった。
5.3.2 会議の内容運用会議は，（1）管理する業務範囲の決定，（2）入力する文字の種類の決定，（3）収書・整理等の業務ごとに新システムの操作を確認，という流れで行った。
（1）は支払いの記録以外を対象範囲と決定した。（2）は半角カナ・全角英数字記号は使用しないことと決定した。（3）では，たとえば担当する職員が図書の発注から受入・整理・配架までを新システムで行う方法について，実際に画面を見ながら操作方法を確認し，職員の間で意識を合わせた。
（3）の過程において，入力が不要な項目の洗い出しを行った。新システムでは不要な項目を非表示にして誤入力を防ぐことができる。
5.3.3 利用者サービスの見直しと業務負荷の軽減操作方法を確認する過程で利用者サービスの見直しを行った。旧システムではキャンパス間で資料を移送する際に，相手館の利用者に貸出処理を行ってから学内便に載せていた。学内便は到着に1～2日かかるため利用者の実際の利用期間が短くなる。この点を運用会議で改善したいと提案して話し合った。その結果，キャンパス間で貸出する場合には返却日に1～2日を加えるように改善できた。
また，所蔵データの項目のうち必須入力の項目名を赤字で強調することで，項目名を探す労力が削減された。そうした見直しは職員からの評判がよく，小さな変更でも効果はあったと思われる。
データ移行の漏れやシステムの設定・操作方法の確認が運用開始直後に発生すると予想された。キャンパスが複数あるため，ある館で起きた現象が他の館で起きることも考えられる。各キャンパスから図書館のシステム担当者へ電話で連絡する方式にすると，担当者は何度も同じような会話をすることになりトラブル対応に専念できなくなる。また，メールで各職員に同報して連絡する方式にすると，案件ごとに誰に同報するか考える必要があり，送信までに時間がかかる。これらの問題を解決するために電話・メール以外のツールを検討した。
検討の際に重視したことは，やりとりの内容が職員間で公開されること，個人ではなく内容によって連絡先を分けられることである。SkypeやLINE，Googleメッセンジャーなどのメッセージアプリを検討したが，すでに個人で使っている職員も多く，個人としてアカウントを作成してからグループとしてつながる方式であるため公私混同が起こりやすいと考えて除外した。
6.2 Slackの導入検討の結果Slackというチャットツールを採用した。これはSlackのサービス内にまずグループを作成し，そこにメンバーを追加していく方式である。Slackは，グループ内に話題ごとの部屋であるチャンネルを作成でき，そこに個人を紐（ひも）づけることができる。そのチャンネルに新たな投稿があった場合は紐づけられた個人へアラートが送信される。また，そのチャンネルに紐づけられていない個人でもその投稿内容を読むことができる。
チャンネルを業務ごとに作成し，それぞれ担当者を紐づけた。これにより「図書のことを質問したい」と思った職員は，図書のチャンネルに投稿するだけでレスポンスを得られ，誰に同報するかを意識しないことで迅速に情報共有が行えるようになった。
6.3 運用開始後の状況当初の予想通り運用開始直後の2016年3月から6月までは質問や確認事項が多発し，多いときは1週間当たり約120件のメッセージがやりとりされたが，Slackによる情報の共有と議論が行われたためシステム担当者はトラブル対応に注力できた。
なお，無料版のSlackは閲覧できる投稿が最新の1万件に限られるため，図書館として保存すべき運用に関する投稿はNASのWordファイルに転記し，情報が失われることのないようにしている。
図書館側からベンダーへサポートを依頼する際は，各キャンパスの図書館の担当者が各館で発生した問題をベンダーへ連絡する，という体制とした。各館から同じようなサポート依頼を行わないよう，Slackでサポート依頼を行った旨を報告し，NASにサポートの内容をExcelで記録し，情報を共有した。
これまで報告してきた更改部分とは別に，本学の短期大学図書室にシステムを新規導入することが2015年9月に決定した。導入するシステムは大学図書館と同じ新システムである。
登録対象は目録上，図書1万5,336件，雑誌2,969件であり，登録作業は次のように実施した。（1）資料へのバーコード貼付は全図書館職員で行う，（2）登録データの作成はシステム担当者1人で行う，（3）データの登録はベンダーに依頼する。
資料のNCID（NACSIS-CATの書誌レコードID）とバーコード番号を対応させた表を登録データとして作成した。このような形式とした理由は，打ち合わせ時にベンダーより，NCIDをキーとしてNACSIS-CATから書誌をダウンロードできると説明があったためである。
全資料へのバーコード貼付には9日間かかり，登録データの作成には2か月間で約190時間を費やした。ISBN（国際標準図書番号）が目録に記録されていればある程度機械的に資料とNCIDを対応づけられるが，既存の目録はISBNを記録していなかったため，手作業で目録とNCIDを対応づける必要があった。
以前から短期大学図書室と相互利用を行っていたが，図書館システム導入前の蔵書を調べる手段は，紙媒体の目録のみであった。共通のシステムを使うことによる最大のメリットはOPACにより5館の所蔵資料を一括して検索できることである。
今回の図書館システム更改は運用会議の実施によりデータの入力方法や操作方法を統一でき，利用者サービスの改善と業務負荷の軽減を行えたことが収穫である。ベンダー選定の際，チェックリストで評価した結果，「〇」の多い上位4社の得点の差はわずかであった。「どのベンダーのシステムを使うか」よりも「基本的な機能をどのように活用するか」の方が，移送資料の貸出期間のような利用者サービスへ与える影響が大きいと感じる。
また，情報の共有体制を整えることで取りまとめを行うシステム担当者の負荷を軽減できることが確認できた。
更改を通して図書館運営者としての問題に気づくことができた。特に顕著な例は短期大学の資料を図書館システムに登録する作業である。極力費用負担が発生しないような登録方法を模索するためにベンダーと協議や交渉を行ったが，このような話し合いのできる職員がシステム担当者1人しかいないことが課題である。1人の職員による更改の知識の占有を防ぐために，副担当をつけて実務を行うようにすべきであったと思う。
最後に，データ移行・導入・保守の際に大変お世話になった図書館システムベンダーの方々に感謝を申し上げる。
1981年生。2004年から4年ほど組み込みシステム開発に携わり，2009年より司書となる。中央大学，愛知県立芸術大学，都留文科大学を経て，2013年より現職。現職では外国雑誌やデータベースの契約，図書館システムとWebページ管理を主に担当する。
