1　はじめに
　ここでは，これまであまり表に出てきていない新システム稼働までの，不安，試行錯誤，葛藤，決断について書き留めておこうと思う。システムリプレースにおいては文書で残される記録の裏側に，迷い続けた紆余曲折が存在する。その記憶を多少なりとも残しておくことは，リプレースの経験を継承するためには重要である。特に，前システム（KOSMOS II）でのリプレースの経験が共有されていなかったために，新システム（KOSMOS III）での業務設計や意思決定において迷いを生じてしまったことが，今回プロジェクトの途中から私がKOSMOS IIIの責任者を引き受けることにつながった，と思うからである。個人的な見解も多いが，経験の継承としてご理解いただきたい。

2　なぜAlephだったのか？
　私は，システム選定期間はメディアセンターから離れていたため，その議論のほとんどに加わっていない。メディアセンターへ戻ってきてからは，2008年6月に「次期システム政策委員会」のメンバーとして海外パッケージ2社の選定段階から関わったが，システム選定よりも，その後の業務モデル設計のほうが重要だと考えていた。その後，次期システムプロジェクト室（以下，プロジェクト室）の責任者となるが，パッケージ選定に深く関与していなかったため，最終的に選定されたEx Libris社のAlephおよびPrimoに対する過度な期待もなく，選定結果を擁護する立場でもないため，業務の都合を優先して自由に意思決定できたことはやり易かった。

（1）システムリプレースの目的・背景
　リプレースの目的・背景について，今の時点で自分なりに整理してみる。
　a　KOSMOS IIの老朽化
　稼働してから10年を超えたKOSMOS IIは，コンセプトやアーキテクチャーが古くなり，システム保守期限との関係もあり，システム全体を見直す必要があった。KOSMOS IIでは，200万レコードの目録検索を高速に行うことやシステムレスポンスを保証することが最大の課題であった。サーバ負荷を軽減するため，機能毎に分散したシステムを構築し，システム間の整合性は夜間の一括処理で確保していた。ネットワーク環境においても，WIDE・SINET間の速度が遅く，NACSIS-CAT/ILLのレスポンスは保証できず，また発注で使っていた丸善の「ちょいす君」が実用に足る性能を発揮するには専用線を必要としていた。安定的な目録業務のためにはSINETでは心細く，「ちょいす君」の発注端末は一箇所に集中しておかなければならないという事情もあった。さらに，KOSMOS II稼働以降に付け焼刃でつくり続けてきた多数の周辺システムも古くなり，メンテナンスが難しくなってきていた。
　業務モデルの面から見ても，1998年10月に作られた集中処理機構は，発注，支払，目録，システムという極めて多くの業務範囲を含んでいたため，全体の流れを理解することが難しくなっていた。このままではいずれ業務維持が困難となり，機能分割も含めた見直しが必要となっていた。

　b　経費圧縮と新システム経費確保
　電子ジャーナル・電子ブックなどの購入経費が拡大する中で，これら電子資源のメタデータ作成や新しいシステム導入のための経費を確保する必要が出てきている。図書館予算が減少傾向であるため，経費を確保するには，既存システム経費の圧縮を考えざるを得ない。また，業務モデルの再構築がもたらす効率化による経費削減も重要な課題となっていた。

　c　紙と電子のデータ統合・連携システムの導入
　紙の場合は，現物を購入してその目録を個別に作成する業務が定着しており，そのための人材，予算もほぼ固定化している。しかし，電子資源によるサービスでは，グローバルに流通しているメタデータをそのまま利用するのが一般的である。この紙と電子を統合的にサービスしていくためには，新しいアーキテクチャーの下での，メタデータ連携が可能なモデルやシステムの構築が急務であった。

　d　スキル維持と人材育成
　10年間同じシステムが稼働していると，その間の人事異動などにより，業務とシステムを一貫して理解し維持していくことが困難になってくる。そのため，システムや業務モデルを再構築しながら，スキル維持と人材育成を行うこともシステムリプレースの重要な役割である。
　たとえば，請求記号の体系，資料のバーコードや利用券の変遷など，これまでは当たり前だと思っていたことでシステム的な問題が発生してくる。こうした問題を安易に回避せずに一つ一つ問題解決しておくことが，その後10年の業務・サービス基盤の構築につながるのである。

（2）新システムの選択肢
　Aleph選定までの経過について，私見を交えてまとめてみる。システム選定に当たっては，選択すべき2つの潮流があったと考えている。
　1つは，KOSMOS IIを整理・維持した上に新しい検索サービスを追加することであり，もう1つの選択肢は，新しくパッケージシステムを導入することであった。前者は，カスタマイズの可能性が高く，慶應の業務に合わせ業務生産性を維持できるが，独自開発部分が大きくなるためシステム開発能力を維持しなければならない。後者は，パッケージであるため，システム開発なしに機能拡張が可能だが，慶應の独自業務には対応できないため，業務の再設計が必要となり，結果，生産性の維持が難しくなるという問題がある。その上，海外製品を選定することになれば，日本語化の問題や意思疎通，文化の問題など，導入に当たって背負う負担は深刻になる。
　システム選定では，この点を踏まえての意思決定と覚悟が重要であった。しかし，この議論が曖昧なまま海外パッケージ導入を半ば前提として検討が進んだため，リプレースの目的や業務への影響，準備に必要な体制，そして何のために「イバラの道を進む」のかという共通認識が曖昧となった。その結果，パッケージ機能の評価だけで選定が進んでしまい，業務モデルの見直し，パッケージでの業務適用範囲，外付けシステム開発の考え方などについての議論がなく，それらが未解決のまま，次期システム政策委員会へ意思決定が引き継がれることになる。
　更に，システムリプレースでは最大の課題である，現行業務の見直しによる経費削減について議論されなかったことは大きな痛手となった。KOSMOS IIへのリプレースでは，ダウンサイジングとPCの低価格化が根底にあったため，システム費用の大幅圧縮が容易に実現でき，それ以降のシステム拡張のための予算を確保することができた。今回のリプレースでも，日本語化，外付けシステム開発などの海外パッケージ導入に伴う付随的な経費が必須であったほか，今後の電子資源サービス拡大へ向けた経費を確保するための現行業務見直しの機会としなければならなかったにもかかわらず，経費として見積もられたのがパッケージ購入経費とサーバ経費だけであったところに，意思決定の甘さを感じる。結果として，海外パッケージを選定するということが先行してしまい，具体的な目的や手法が曖昧になったことは，導入を果たした今，総括すべきことであろう。

（3）パッケージの選定
　書誌フォーマットをMARC21とした場合，選定可能なパッケージは限られてしまうため，Innovative社のMillenniumとEx Libris社のAlephの海外パッケージが残り，最終決定は次期システム政策委員会へ引き継がれた。OCLCが開発中のシステムも話題になっていたが，リリースが間に合わないことから候補にはならなかった。また，一旦海外のパッケージへ移ることで，苦労してでも業務を整理してしまい，10年後に他のシステムへ移るというシナリオも不可能ではない，と考えてリプレースに踏み切る，という目算もあった。
　MillenniumとAlephの特徴は以下のように考えていた。
　【歴史と完成度】
　双方ともデータ構造は1980年代のアーキテクチャーを引きずっている古い業務システムのため，安定性は高いと思われるが，電子を管理する場合でも紙の管理モデルから離れることはできない。
　【販売戦略】
　・Millenniumはターンキーシステムであり，カスタマイズを行わない量販型。
　・Alephは国立図書館や大規模大学図書館を狙った拠点販売型。
　【製品戦略】
　・Millenniumは既存システム（紙の管理システム）の中に電子資源対応や新しい機能を付加。
　・Alephは電子資源のためのシステムを新しいアーキテクチャーで別製品として提供。
　【国内保守体制】
　・Innovativeは国内保守体制確立の可能性なし。
　・Ex Libris社はSFX等の導入実績から国内における保守体制を確立する可能性あり。
　システムは業務とサービスのためのツールであり，どのようなシステムを選択しようと，それが図書館の戦略に合致しているのであれば，それに合わせて業務ライン，サービスを組み立て直せばよい。パッケージを選定するのであれば，その特性に合わせた組織再編の覚悟が必要である。
　Ex Libris社は，電子資源管理のシステムを別製品（Verde）として販売している。価格戦略から製品を分けていると思われるが，電子固有のシステムは紙のシステムを引きずらないで済むというメリットがある。Ex Libris製品を選択するのであれば，紙の担当と電子の担当を組織的に分ける必要があると考えていた。次期システム政策委員会におけるシステム選定の議論は，既にSFXとVerdeが導入されていることやシステムサポート体制，価格などの点から総合的に行われた。他に，Google Library Project参加大学のシステムの多くがEx Libris製品であったことや，Google Book Search用のASP（Application Service Provider）が準備されているという動向も参考にし，最終的にAleph（図書館システム）とPrimo（統合検索システム）の採用となった。

3　AlephをKOSMOS IIIへ

（1）プロジェクト室の課題
　海外パッケージを導入することによるプロジェクト室の課題は以下のようなものであった。
　・パッケージの日本語化（表示，検索，ソートなど）
　・データ移行
　・パッケージの理解，習得
　・パッケージに合わせた業務モデルの再構築
　・パッケージのカスタマイズとパッケージ適用外業務のための外付けシステムの開発
　・トレーニング
　全体を通じての最大の問題は，製品の持つ文化を理解しEx Libris社側と相互理解を深めることであった。

（2）開発体制
　パッケージ導入に当たっては，Ex Libris社と直接契約を行い，SI（System Integrator）企業を別途探した。一般的にシステム導入では，図書館はSystem Librarianの役割を，SI企業がSystem Administratorの役割を受け持つことが多い。しかし最終的にSI企業を見つけることができず，その結果，図書館職員だけでAlephの導入，日本語化とシステム導入を行うという無謀なプロジェクトが立ち上がることとなった。

（3）システム集中・業務分散へ
　a　業務モデルの再構築と外付けシステム切り出し
　Alephの採用決定によって，業務モデルの再構築が本格的に行われることになり，Alephに移行する業務の選別が行われた。全ての業務をAleph上で動かし，KOSMOS IIで問題となっていた，分散システム間のデータ連携や受入時の予算管理のリアルタイム化を実現しなければ，統合システム導入の意義は半減することになる。
　適用範囲の選別で最も問題になったのは，慶應独自で開発を行っていた雑誌受入システムである。独自開発ゆえに雑誌受入業務を効率化するための多くの機能が備わっており，Alephに移行することで生産性が低下することは明らかであった。不安は大きかったが，パッケージの利点を活かすため，全ての業務をAlephに移し，システム集中型の業務モデルを構築することとなった。
　KOSMOS IIでは，システムが分散し，それらをつなぐネットワークも弱かったため，それを補うために業務組織を集中してきた（システム分散・業務集中）。KOSMOS IIIは集中システムであるため，業務組織を分散しても運用が可能であった。組織的には，業務をできるだけ“発生源”へ分散し，紙資料の管理の流れと電子資源管理の流れで組織の分割を意識していくことになった。集中処理機構の業務を見直し，発注業務と予算管理を各館に移した。集中処理機構は受入・目録業務だけとなり，メディアセンター全体での機能再編を実現した。業務上は必須であるものの，Alephでの対応が不可能と思われる機能を外付けシステムの対象として切り出し，慶應側で開発することとした。この開発予算を確保するために，既存システムの改修凍結や業務委託費の圧縮を行う必要があった。外付けシステムの切り出しは，業務モデルの設計およびAlephの解読・理解と同時進行で行ったため，見極めが難しいケースも多かった。また，Ex Libris社に機能要望を理解してもらうことが難しく，文化の違い，英語でのコミュニケーションの難しさを痛感することとなった。

　b　目録運用細則の変更と著者名典拠の復活
　新システム稼働にともなって目録業務の生産性が低下することは明白であり，その効率化を進める必要があったこと，加えてAlephでは目録データ長の制限が厳しくなることなどから，目録運用細則の見直しを行った。目録の生産性を確保するには，書誌データ流用率を上げること，流用した書誌の修正量を減らすことが必要であった。更に，電子資源サービスとの融合を考慮し，最初の業務機械化の時点から20年以上続いてきた著作責任単位での目録運用を廃止することとした。また，図書館の目録データとしての特性を生かしていくため，12年ぶりに著者名典拠を復活させた。

　c　OPACとKOSMOS
　Alephは紙資料の管理システムとして位置づけ，電子資源の管理はVerdeやSFXで実現することを前提としていたので，Alephの目録データベースを検索対象とするOPACモジュールは紙資料に対する検索サービスと位置付けた。Primoをベースとした新検索システムKOSMOSは，Aleph側から紙資料のデータを収集し，これと電子資源のデータを横断的に検索することで，全体の資料検索を保証し，その検索結果からの全文リンクサービスを実現することとした。
　KOSMOSはN-gram方式（文字単位での索引語を切り出す方式）での検索エンジンのため，これまでの単語単位での検索とは異なる。利用に与える影響は大きく，サービス開始に当たっては，レファレンス担当を中心とした検討と，KOSMOSをサービスの前面に据えていくという覚悟が必要であった。

　d　閲覧システム
　KOSMOS IIの閲覧システムは，現状の慶應でのサービス・業務を分析した上で開発したものであったため，慶應にとって最も効率がよいものである。どこの館でも貸出ができ，どこの館でも返却できるという「どこでも貸出・どこでも返却」は，慶應の蔵書管理において生命線であったが，これを海外パッケージのシステムで置き換えることが容易でないことは誰にでも理解できた。そのため，慶應の複雑な貸出規則をAlephに実装し繁忙期を乗り越えること，同時にMy Libraryの利用を実現させることが重要な課題であった。慶應に特有な規則を海外パッケージに対応させるための検討が行われ，Alephの理解が十分でない段階から，閲覧規則の実装作業を進め，稼働試験が何度も行われた。本番稼動は果たせたものの，引き続き課題の多い部分である。

　e　安定運用の実現へ
　2010年3月23日，予定通りAlephは稼働を開始し，PrimoはKOSMOSとして，館内検索端末での認証方法などについて間際まで調整を続けながら，4月1日からの正式稼働に漕ぎ着けることができた。未だに多くのトラブルと格闘しながらシステム安定稼働へ向け努力が続けられている。
　AlephとPrimoの運用についてはメディアセンターの業務・サービス全体に影響があるため，メディアセンター所長主管のシステム調整委員会とシステム担当課長（筆者）主管のシステム調整ワーキンググループが設置され，安定運用へ向けた活動が強化されている。また，Ex Libris社との調整も数多く重ねている。
　海外パッケージ導入のための覚悟も準備もほとんどできていない中での，図書館員だけのプロジェクトであったが，結果として，業務モデルの再構築，「電子情報環境担当」部門の設立，既存システム部分の経費圧縮，システムリプレースの経験共有などが実現でき，なんとか今後に向けた業務・サービス基盤ができたと思っている。