OPAC改善委員会報告 (旧OPAC改善・検討WG) 2005.11.21(月) メディアセンター本部システム担当 課長代理 田邊 稔 1.委員会発足までの経緯 内的要因 システム要因 サーバ性能による制約 KOSMOSⅡ開始以降「無策」 要望は個人の頭の中 提案・討議する場がない 繁忙期を乗り切れない 負荷が怖くて大胆な改修ができない Google，Yahoo!世代の台頭 OPACへのクレームと期待の高まり 図書館界全体にとっての脅威！！ 外的要因 全塾PSや本部テクニカルでも少しづつは改善していた。 但し、利用者サービス指向の改善ではなく、どちらかというと スタッフ業務指向の、いわば「小手先の改善」であった。 利用指導の限界！？小手先の改善では立ち行かない！ 次期システム（2008年KOSMOSⅢ）まで我慢できない！ 2005.9サーバ機器リプレースへの期待！ 片手間でなく専担で検討できるフレームワークが必要 アドホックなものでよいから集中的に検討できる委員会を設立せよ！ OPAC改善・検討ＷＧ発足 2.活動状況 • 実施回数：全14回（旧WG 8回、現委員会 6回） – WG：2004.11.25∼2005.3.31、委員会：2005.4.1∼11.9 • メンバー：全13名（旧WGより変動なし） – 主査1名、本部5名（4名+記録1名）、三田2名、日吉2名、理工1名、 信濃町1名、藤沢1名 • ミッション – – – – KOSMOS→KOSMOSⅡで割り切った内容の再確認 利用者サービス指向のOPACを実現させること 本部と各地区の総意で改修を進めること KOSMOSⅢへつながる改修とすること 3.これまでの検討フェーズ（合意形成過程） OPAC改善・検討WG ※メンバー交代なしが「吉」と出る OPAC改善委員会 要 望 事 項 の 洗 い 出 し 意 味 と 必 要 性 の 確 認 詳 細 分 析 ・ 整 理 技 術 動 向 調 査 工 数 ・ 難 易 度 調 査 優 先 度 ・ 仕 様 決 め 改 修 作 業 ／ 辞 書 系 改 修 作 業 ／ 表 示 系 テ ス ト 検 証 ・ 確 認 9/24 本 番 リ リ ｜ ス • [当初]本部 vs 地区の構図、地区内でのズレ（悪循環） – 本部を含め地区間・地区内での誤解や温度差 – 要望の言いっ放し、無責任な発言、不毛な議論 等々 • [現在]みんなで知恵を出し合いコラボする集団へ（好循環） – 言いたい事は言ってコンフリクト、なぜ必要なのか？を徹底的に追究 – 感覚（定性的評価）だけでなく、数値（定量的評価）を重視 4.検討課題例／著者名典拠について • 国内における典拠の問題点(2002.12.26時点) – – – – 目録慣行における名称典拠コントロールの軽視 利用しやすい標準的な典拠ファイルの不在 国際的な名称典拠ファイルとの非連携 典拠作業に関する労力負担 • １大学で典拠ファイルを維持するには稼動がかかる し、外部参照ファイルにも問題が多い→的を絞る – 「著者名標目記述の揺れ」→標目調整作業＋一括修正を維持 – 「参照形による著者名検索」→著者名(人名)データベースを作成 • 簡易的な人名同義語辞書やSeeAlsoをつくる？ – 小手先でやっても混乱を招くだけ • 今すぐ解決できる問題ではない！ – KOSMOSⅢへのメイン解決課題の１つとする！！ 5.スケジュールと各フェーズの改修ポイント • 第一次フェーズ(2005年9月サーバリプレースまで) [14件] – システム基盤の見直し • OPACパフォーマンスを最大限発揮できる構成 • ハードウェア、データベース、アプリケーション共に「テコ入れ」 – インデックスを中心とした改修 – 検索窓（１-Window）とスペースのAND検索の実現 – 電子ジャーナルの搭載 • 第二次フェーズ(2005年度後期、2006年度) [53件] – 英訳、ヘルプ、デザインなど利用者ナビゲーション中心の改修 – バグや仕様変更を含め、第一次分の積み残し案件対応 – 電子ブックの搭載 • 第三フェーズ（2008年度KOSMOSⅢ） [5件+α] – 認証システム(keio.jp)を基盤としたサービス群 • オンラインリクエスト、My Library、ブログ、RSS、各コミュニティ連携… – 次世代サービスの先取りと連携 • 学術ポータル、機関リポジトリ、リンキング、パーソナライゼーション… – 著者名(人名)データベースの作成と運用 6.検索エンジンとOPACは違う！ ~図書館が向かうべき方向性 • Google、Yahoo！を代表とする検索エンジン全盛期 • “Googleの脅威” • • – 「われわれのミッションは、世の中にあるすべての情報を、Googleを 通じて得られるようにすること（創業者ラリー・ページ、サーゲイ・ブリン)」 – 『Google Print』、 『Google Scholar』、 『Google Earth』、『Google Talk』、『Google BlogSearch』 など次々と猛スピードで驚くような サービスを提供し続けている Google、Yahoo!∼“誰でも引ける、直感でわかる、ノイズ多い” – 簡単なインタフェースかつ高性能な検索エンジンを搭載したシステム OPAC∼“図書館通に受ける、洗練されている、敷居が高い” – 図書館の伝統的な目録検索を中心としたセマンティックなシステム • RLG／RedLightGreen – 図書館らしさを払拭、GoogleやAmazon.comを徹底的に意識 ＝＞淘汰ではなく“共存・連携”へ 参考）検索エンジン vs OPAC比較表 OPAC コンテンツ/書誌 フォーマット データ登録 検索/更新方式 書誌規則／MARC （組織化） 人間の判断による 検索精度 インデックス方式 （正規化処理） 高 検索特徴 適合率（近似値ヒット） 検索エンジン HTML，XML （非組織化) 半自動登録・自動 更新 全文検索 （非正規化） 低(SEOなど別の工 夫あり) 呼出率（広範囲ヒッ ト） ※（典拠）明治大学 2004年度図書館活用論Ⅱ第10項 図書館目録検索と検索エンジン−インターネットでの検索− 7. システム基盤の改善 • システム基盤 – ハードウェア • OPACパフォーマンスを最大限に引き上げるための構成 • ストレージ周りの強化（Enterprise Virtual Array 3000の採用） – データベース（Cache’） • Bit Map Indexの採用（負荷の高い検索ほど効率が上がる） →理論上、検索速度が最大100倍UP – アプリケーション • Cache’Tempの採用（ディスクではなく、メモリ空間を利用） → I/Oによるオーバヘッドの削減 • OPAC負荷テストによる評価（2005/9/8実施） – Generic Wordを数パターン用意し、本部スタッフ総勢41名で一斉入 力＆ボタン押下（３回繰り返し）→平均1.97秒，最大6秒 – CPU占有率(物理Max300)：1回目Max:268、2回目Max:172、3回目 Max:151 8.周辺環境の整備 • サーバセキュリティの強化 – ファイアウォール機器(Netscreen-204)の新設 – OSレベルでのファイアウォール(Linux - iptables) • ASPの採用（携帯OPAC、OPAC横断検索） – Web版OPAC改修に伴う稼動を最小限に留めることができた • 予算の先行投資 – 2005年度十分な改修ができるよう、2004年度CALIS保守の残予算 （約250万）を全てOPAC改修に振り当てた →足りない分は2005年度予算より充当（KMSIと合意） • 戦略的なログ解析ツールの整備（感覚から数字へ） – ログにセッションＩＤを追加→利用者挙動の追跡が可 – 解析ツールの作成→見たいときにすぐ見れるもの – 現在、本部システム担当で作成中（約80％） 9.OPAC検索ログ解析事例 • 簡易検索の実現により「1000件オーバー発生で諦 めて立ち去る利用者が多い」と言われるが本当？ ■データ調査対象期間：2005年09月23日（21時）∼10月31日 ■検索ログ件数（セッションID数／総数） ①全ログデータ数 443,863件／723,523件 ②①中の1000件超数 11,693件／ 18,253件 ③②中の追加検索数 7,803件／119,131件 ■HIT数1000件以上の分布 1001 - 2000 ：8633件（★） 4001 - 5000 ：1625件 2001 - 3000 ：3181件（★） 5001 - 10000 ：1785件 3001 - 4000 ：1777件 10001 ：1252件 ■結果＆考察 A)全検索ログの内、HIT数が1000件以上の割合は約2.5％ B) A)の内、追加検索へ進む割合は約67％ C) A)の内、HIT数3000件以内(1001-3000件)の割合は約65％ 「意外にまじめな利用者が多い（＝冷やかしは少ない）」、 「一覧表示の制限を3000件に引き上げれば大半が救われてしまう」 10.今後の方向性 • 2006年度で改修を一旦凍結する！ – あとはKOSMOSⅢに託す（＝KSⅢに注力したい） • KSⅢに向けたWebサービス全体の見直し – – – – – – – 次世代サービス検討委員会（？）の設置 認証システム(keio.jp)との連携強化 My Libraryなどのパーソナライゼーションサービス OpenURLをベースとしたリンキングサービス 利用者の習熟度別ナビゲーション Googleなど全文検索エンジンとの共存、連携 RSSなどのメタデータによるコミュニティ連携 • データ整備とシステム改修の両輪 • 予算削減との戦い→KSⅢへ移行できるか？ • なぜリプレースのか？再確認が必要
© Copyright 2024 Paperzz
