日本図書館研究会第299回研究例会「図書館システムの調達の方法と課題〜成田市立図書館第六次システムの経験から」に行ってきた。〜後篇
前の記事の続き。しつこく繰り返しますが、xiao-2が聞きとれて理解できてメモできて、かつ思い出せた範囲。項目立ては適当。誤記・誤字ご容赦。特に質疑の後半は、活発すぎて取りこぼし多数。
再び、講師のお話。
- 発注者と受注者の意識のズレ
- 発注側としては、OPACで公開しているものはメッセージも含めて図書館がWebで公開しているもの。なのに、何だか分からないメッセージが入っていることは不満だった。メッセージの一覧を出して欲しいと求めても、「無い」と言われる。
- ただ、それはベンダだけが悪いというのではない。今回当館で導入したのは、他館にも入っているシステム。それなのに一覧が無いというのは、これまでのユーザは、そういうものを出せと言ってこなかったということ。つまり図書館自身が、自分たちのシステムを完全に理解せずになんとなく使っている。この状況が、本来は良くない。
- 打合せはどうしてもベンダ主導になりがち。業務システムやOPACでは、画面配置が大切なのだが、プレビューしてもらってコメントすることができなかった。結果、導入してから作り直しが発生。
- そういう事態がありうると予想されたからこそ、画面設計仕様書を事前に出していた。ガチガチに固めるのではなく、「この画面にはこの情報が必要」ということを指定する程度。でも無視されていた。
- 仕様の公示から提案まで、1ヶ月もない。打合せの段階になったら画面についてあれこれ修正してもらわなくてはならなくなるのは分かっていたので、事前に画面案を出してもらおうという趣旨だった。
- それでも、やはり手こずっている。あらかじめ仕様書を出して、それを見て「やれます」と手を挙げてくれた中から選んでも、こういうことになるのだな、と忸怩たる思い。
- ベンダー内部の事情としては、同じ図書館システムパッケージでも、担当館ごとにチームに分けて対応していたようだ。負荷分散ということだろう。だが、データベースやプログラムの設計にばかり意識が行って、図書館側の求めるものを「どう表現するか」という所まで意識がいかない傾向があるように思った。
- ベンダー側には、自分たちのシステムであるという意識があるのだと思う。図書館が提供するシステム、ではなくて。メッセージの書き方にも、そういった姿勢が現れる。
- たとえば、予約受取サービス。当館では遠方からの利用者が多いので、予約本を受け取る送付先として「自宅」という項目は設けていない。だが、画面には「自宅にお届けするサービスです」といった説明文があった。気付いて問い合わせたら「そうだと思っていました」と言われた。
- それぞれの機能の実現状況
- 自動貸出機
- ハードウェアの調達は割とうまくいった。2007年の導入時点では、とりあえずセルフにすることが目標で、タトルで貸出管理するシステムにした。だがうまく消磁できない（xiao2注：＝貸出処理ができない＝持って出ようとするとアラームが鳴る）*1ことがあった。
- 特にCD資料で失敗が多かった。タトルを貼る位置の関係で、自動貸出機の消磁機能の部分にうまくフィットしない。
- また自動貸出機の「処理完了」メッセージは正面の画面に出ていたが、利用者は手元しか見ていないため、メッセージが出ていない（＝貸出処理が失敗している）ことに気付かないケースがあった。
- 現在の機械では、資料を置く所の横に完了メッセージが出る。消磁失敗が減り、今は安心して見ていられる。
- 予約受け取りコーナー
- 実現に当たっては、実際に予約受け取りコーナーを設けている既存の館でどのように運用しているか、見て回った。三鷹市、府中市、葛飾区の図書館など。葛飾区では返却コーナーの隣に予約本受取コーナーを設けていて、これは導線上非常によい。方法としては皆ICタグを使っていて、バーコードとタトルで実施した前例は見当たらなかった。
- このコーナーの実施に際しては、仕様書作成の段階で業務フローまで含めて考えた。たとえば、バリアフリーのために近々館内のエレベータを新設しようという話があったので、導線検討に当たってはそういった要素も考えに入れた。
- 予約本受取コーナーには、BDSはつけていない。運用は今のところうまくいっている。サインはまだ改良の余地がある。またBDSがないことから、たまに貸出処理をせずに持って行く人がいるのは困った点。
- 予約資料の管理は、情報を出力した紙を挟んでいる。個人情報をなるべく載せたくなかったので、レシートには日付とその日の通番だけが印字されている。コーナーに設置された機械に利用者が自分のカードを読みとらせると、予約本のタイトルと置かれた棚の場所が出る仕組み。
- 返却仕分け機
- CTIによる督促機能
- 最初のうちはずいぶん苦労した。お化けみたいな変な声で、読み上げ機能も全然使えない。苦情も多かった。
- 座席管理システム
- これの調達に当たっては、図書館システム本体と一体にして調達してもよいのでは？というアドバイスを市の情報推進室からもらっていた。しかし、座席管理システムの開発ができないために図書館システム全体が落札されないといったリスクを恐れて、分けて調達することにした。
- 運用はうまくいっている。予約受付機については完全セルフ化が実現した。
- この手のシステムというのは、ありそうで意外となかった。他館でも、システム導入していてもシステムがやっているのは予約フローの一部だけといった場合が多かった。
- 前例としては葛飾区の図書館が、先方の現行システム導入の際に調達をかけていた。そこの話も聞きに行って参考にしたが、結局この形が一番良いということになった。
- OPAC
- 第5次システム導入の時のトラブルを繰り返さないよう、進捗管理には気を使った。月1回進捗会議を行い「現在の達成度何％、遅れ気味だが大丈夫」といった確認もしていた。だがOPAC導入では失敗。動かない、落ちるといった事態があった。
- 中間生成物のチェックをもっとすべきだったのかもしれない。スケジュール的にタイトだったのも事実。どうしたらよかったのか、今も分からない。
- 現在は改善されてきたが、OPACの導入当初は非常に残念な状況だった。こだわっていたパーマリンクや導線が、意図どおりになっていなかった。
- しかも、非常に遅かった。他の館に導入された同じパッケージのOPACを見てもそれほど遅くないのだが、理由が分からない。第5次システムで使っていたパッケージは検索の速さが売りの製品だったので、それより遅くなるだろうとは予想していたが、許容範囲を超えていた。
- 自動貸出機
- 図書館システム調達の問題点
- 用語の指す意味が統一されていない。たとえば「書誌」「ローカル区分」。語の意図するところが、ベンダーと図書館でややずれていたり、図書館でも公共と大学ではややずれていたりする。
- ここまで文句ばかり言ってきたようだが、ベンダーだけが悪いという訳でもない。向こうは向こうで苦労している。どこが旗を振れば、良い結果になるのか。
- 理想としては、業務システムとOPACとは分けたいと思っている。しかし、今回はそこまで実現できなかった。
- 発注側と受注側で、設計思想の違いは当然ある、それは予想していた。しかし互いの認識に齟齬のあるまま実作業に突入せざるを得なかった。たとえば「予約数」という言葉の意味するところが図書館側とベンダー側で想定が違っている。それを指摘して修正してもらうと、同じ言葉が他の部分でも使われていて全体が不統一になるといった具合。まだ安定運用できているとは言えない。
- ちゃんと調達をかけて、打合せで話すことはきちんとドキュメント化して、業者選定もきちんとしたつもり。それでもシステム導入は難しい。現在も進行中の状況。
- 質疑
-
- フロア
- 自分の勤務する館でもシステムリプレース中で、参考になった。今回のお話はハードウェア中心だったが、ネットワーク関係の話はどうか。セキュリティ強度など。
- 米田さん
- パスワードの暗号化は条件として入れた。システム自体は図書館内に設置しているので、あとはデータの暗号化など。
- フロア
- 審査の重みづけでは条件に入れなかった？
- 米田さん
- 当然出来るはずのものということで。
- フロア
-
- フロア
- セルフ化により作業が効率化されたことで、実際にサービスに好影響が出たか。特に職員の作業が減ったということになると、上からはすぐに定数削減されそうだが。
- また、情報化推進室との関係が良好なようだと感じた。自分の勤務している館では、システム担当部署の力が強く、図書館側で色々やりたいことに対しての締め付けがきつくなりがち。そういった制限をかけられたりしないのか。
- 米田さん
- 定数削減という結論には持って行かれないように、頑張っている。新しく分館ができたこともあり、この分館をこの人数で回すにはシステム側の工夫が必要だった。
- 成田市の場合、情報化推進室は余裕がなく、庁内だけで手いっぱい。図書館でできることは図書館でやってほしい、という感じ。
- フロア
-
- フロア
- 選定の過程で、第二次審査事項として「成田市立図書館のサービスの考え方の理解」という項目を設けているが、具体的にはこの「サービスの考え方」をどのようにしてベンダーに伝えたのか。
- 米田さん
- 公示された募集要項に書かれたことを、どう理解しているか、提案書にどう反映しているかということ。当たり前のことのようだが、提案書を出してきた中には、こちらの求めてもいない項目を勝手に出してくるようなベンダーもあった。
- 選定委員会には、技術の細かすぎる点は分からない。そういった点よりも、大枠の理解でブレがないことを確認した。
- 同じパッケージシステムを導入した他の図書館を見て回って、うまく動いているかどうか見るということもやった。ベンダーにとっても新しい部分があっただろう。
- フロア
-
- フロア
- 自分の勤務する館でリプレースを行った際には、図書館の業務内容はだいたい固まっているからということでパッケージを導入し、独自開発は極力避けた。開発すればどうしてもバグが増え、検証の手間もかかる。
- 今回のシステムで前面に出ていた目的として「数値分析できるシステム」というのがあったが、これはどういう内容か。
- 米田さん
- 帳票がメイン。資料一覧やタイトル一覧を吐き出せる。予約数や所蔵数のリスト。除籍していない資料の平均貸出数、などの表示機能を作ってもらった。
- フロア
- そういったものは、Accessでも使えば自力で出せるのでは。
- 米田さん
- 統計については、一年に一回程度なのでそれでもいい。ただ日々の除籍作業は毎日やるものなので、システムから直接見られるのが一番良かった。
- フロア
- 自分の館の以前のシステムでは、統計機能を作りこみ過ぎて使いにくくなっていた。サーバ側でデータを加工することはあまりしないで、なるべく生データに近い形で出し、クライアントで処理するのが一番良いのでは。
- 米田さん
- それは確かにそう。たとえばデータを出力するのにも、Excelで出すと重い。テキストで充分。
- フロア
- 調達担当の知らないうちに、現場から勝手に「こうしてほしい」という希望が出されてカスタマイズされているケースがある。
- 米田さん
- 成田市では、皆の希望を聞いてデータ出力仕様を決めたので、無駄な項目が入っているということはない。
- ただパッケージなので、当館では本来使わない機能がデフォルトでついていたりする。そうすると、いつのまにか現場で勝手にその機能を使って何かして、それでおかしなことが起きたりする。
- データ移行まで考えた上で、業務を組み立てることが必要。
- フロア
-
- フロア
- 米田さん
-
- フロア
- 当館では某社のシステムを使っているが、やはり遅い。ベンダーに問合せたら「システム本体ではなく、表示（＝Internet Explorer）が遅いんです」と言われた。IEのバージョンも古いし、業務自体もIEを使っている。そういう限界というのもあるのかもしれない。
- 米田さん
- その可能性はある。データベースの世界だとOracleが王者だが、それが図書館システムに本当に合っているのかどうかは疑問の余地もある。
- フロア
-
- フロア
- 自動返却機について。自分の知っているシステムの自動返却機では、利用者はポストのようなところに資料を入れておくだけで、バックヤードで職員がシステム上の返却処理を行っている。成田市のシステムでは、返却処理も機械でやってくれるのか。
- また、資料の予約が多くないというのは何故だろう。これだけ仕組みを考えているのに。
- 米田さん
- 三鷹市の自動返却機はICタグを使っているが、これはポトンと入れておくと、システムの方でいったん仮返却をして、後で職員が検本してから本返却の処理をするという仕組み。
- 成田市の自動返却機では、利用者が機械に資料を入れた時点で本返却になる。そのうちでも予約が入っている資料など、特に確実に処理する必要のあるものだけが分けられて改めて職員の手を通る仕組みになっている。
- ただし職員の手を経ずに返却されると、汚破損チェックができないという問題はある。そこで自動返却された資料については、返却後3日間だけ履歴が追えるようになっており、そこで担保していく。このことはプライバシーポリシーにも今後出していく。
- 予約が少ない理由は、自分たちにも分からない。他館では予約が200件入っているような人気小説などでも、普通に棚に並んでいたりする。複本数が取り立てて多い訳でもない。その意味では、人気本を読みたい人にはお得な図書館なのだが。
- フロア
-
- フロア
- 導入後に修正をしているようだが、最初の調達から追加費用は発生していないのか。
- 米田さん
- 成田市では、5年分の保守をまるごと調達した。ちょっとした機能追加などは、仕様書に「保守の範囲内で対応」としているので、そこで読める範囲のものなら実施可能。
- フロア
メモは以上。以下、ちょこっとxiao-2の感想。
今回、フロアからの質問が非常に多かったのが印象的。「話の途中でも遠慮せず質問してくださいね」と前置きして話し始める方は時々居るが、実際に話の途中から質問が引きも切らないという場面は滅多にあるものじゃない。皆さんの関心の高さの表れだろう。
裏返すと、それだけ聞ける機会の少ない話であるということでもある。公示されていた仕様書等を見る限り、ずいぶんかっちりと隙なく作ってあるように見えたのだが、それでも実際はスムーズに運ばないのだなと思わされた。こういう地道な苦労話はなかなかオープンにされることがないけれど、本当なら単純な手柄話よりもよほど為になる。迷いも含めてお話しいただいた講師の方と、主催者に感謝。
*1:参考：キハラ株式会社 LDS（ライブラリー・ディテクション・システム）※リンク先は、講演で出てきた製品とは関係ありません。
*3:NHK情報ネットワークと日販図書館サービス（NTS）が提供していたMARCらしい。
*5:この一連のやりとり、質問も回答もxiao-2には充分理解できていない。誤解している恐れがあるので、読む方もそのつもりで。
*6:2013/7/25 ブックマークコメントにより修正。Sorl-Wikipedia、英語でもどんと来いや！な方はApache Lucene-Apach Solrをご覧ください。コメントをくださったid:ceekzさんに感謝。
*7:このように聞こえたのだが、話題に疎い自分には「ソラ」が何のことか分からなかった。これのこと…？｜Kvasir/Sora http://kvasir.sandbox.seasar.org/
*9:レファレンス協同データベースでは「調べ方マニュアル」という名称らしい
