■手さぐり試験機設定

　導入はプリセットの試験機を作成し, 運用に合わせて調整して, 本採用機にするという手順で行われた。
　基本設定用のアンケート（注1）で望む設定を選択して提出したが，実際に動かせるものが一切無い状態で，説明書の画像イメージと文章だけで動きを想定するのは困難だった。
　根幹となる設定は後に修正することが困難であり，どの設定が多くの機能に関係し，より慎重に検討が必要なのかをこの時点で把握できていなかったことが，この後の作業に影響を及ぼすことになった。
　但し，当時を振り返ると，現行の仕組みとの違いが理解できたかどうかという状態だったので，この時点で詳細な説明があったとしても把握は難しかったと思われる。

■試行錯誤の試験機稼働：この動きは想定外

　試験機を実際に動かしてみると，動きが想定外ということが多く，その対応に正式稼働の2週間前まで追われることとなった。説明書には書かれていない，または説明書の文脈からは汲み取れなかった文化背景による常識の違いの影響は大きかった。設定と動作の関係性は常識と思い込まずに，細かい点まで試験および確認するのが望ましい。
　元々の構成員や，サービス提供体制が簡潔であれば，先に要望を出し，基本設定に微調整を加えるという今回の方式は有効だと思うが，構成員もサービス提供体制も多様な慶應では，調整の範囲に収まらず，後日大幅に設定を作り直すことになった。（図1）

■サービス規則の変更は難しい

　システムの適性から，現状の複雑なルールの反映は難しいと判断し，サービスが均一な図書館グループになるよう全館統一ルールへの変更をプロジェクト室から提案した。
プロジェクト室提案
　・全ての館で貸出区分が一律。
　・利用規則が一律。（貸出可否，貸出期間，貸出冊数，更新回数）
　・利用身分は4種類。（教職員，大学院生，学部生，その他）
　実際は館ごとの利用者ニーズの違いや，所属による利用の優先を図りたいなどの事情により，館ごとのルールが採用された。
　・利用身分は全27種類（旧54種類から削減）。
　・資料区分は88種類（旧66種類から増加）。
　・貸出パターンが800種類。
　・予約のコントロール設定パターンが760種類。
　提案した統一ルールからは貸出パターンに含まれる更新規則の全館統一が今回採用となった。
　ルールの変更は一朝一夕にはできないため，普段から現在のルールが最適なのかを意識して情報を収集しておくと検討の際に活用できる。
ルール変更を考えるポイント
　・本当に現在のルールが最適なのか
　・利用者ニーズに合っているか
　・実運用に適しているか

■肌で感じよう：閲覧トライアル
　2009年6月下旬から7月上旬にかけて試験機を全館に配布し，各館の現場担当者（代表2名程度）が操作体験をする機会を設けた。
　目的は閲覧モジュールを実際に触ることを通して，Alephの構成と基本の動き，Alephに対する現場担当者の理解を深めることであった。貸出・返却・更新・予約・収金処理の基本操作をシナリオとサンプルデータを使用して行った。
　操作体験から発生した要望，エラー報告を収集し，設定変更や運用調整を本格的に開始した。
　仕様制限が多く，現行サービスをそのまま移行するのが難しいと実感し始めた頃である。

■歴史の重さを振り返る：移行調整

　閲覧系データは利用者情報，貸出情報，課金情報，資料の貸出区分を移行した。Ex Libris社の提案ではテスト1回，本番1回のところ，テスト4回，本番1回の計5回の移行を行った。
　1次〜3次で結果を見ながら条件およびデータを修正していったが，実際の移行作業を行って気付かされた点があった。
　1次にて現在のルールで必須項目であるデータを移行条件の判定キーとして条件を作成したところ，期待した結果が得られなかった。調べてみると，過去は必須では無かったため，そのデータは判定キーとして不適格と分かった。現在の状態を分かっているだけでは移行条件を作成できず，担当者が過去の歴史を紐解きながら四苦八苦することとなった。場合によっては移行条件に合わせてデータ改修を行った。
　調整の甲斐あって，閲覧系の条件は3次データで固定となり，続く4次，5次（本番）は同条件での移行だったため，本番もほぼ想定通りの結果を得ることができた。

■2つの検討会議体

　2008年11月から2009年10月までは全塾閲覧担当者会議で基本設定および運用方向性を検討し，2009年11月からは各館の現場担当者の代表者を閲覧Administratorとして招集し，実際の業務を見据えたテストおよび運用の検討を行った。
　この2つの会議体はシステムとサービス現場をつなぐ重要な役割を担い，円滑なシステム切り替えの礎となった。
　閲覧Administratorは11月中旬にAdministrator講習（2日間）を受け，各自自由に動作試験を行った。月2回程度の会合にて問題点の確認と運用の調整を行った。
　ここで障害となったのが，参加時期の違いだった。全塾閲覧担当者会議からの継続参加メンバーと閲覧Administrator招集時からの新規参加メンバーが混在したため，議論の経緯などの時期的な情報量の差が，新規メンバーを困惑させることがあった。
　システムの入れ替えでは，初期検討から導入まで一貫して担当する検討グループを組織して臨むことをお勧めする。

■稼働前日作業シミュレーション
　一括で移行されない予約情報およびデータ固定後にシステムを使用せずに行ったサービスについては稼働前日に手作業移行を行うこととした。
　前日に問題が発覚しても対応できないため，事前にテスト環境で手作業移行のシミュレーションを行い，必要な時間と手順を確認した。
　処理順番のコントロールが必要なため，作業を時系列でフェーズ分けし，全塾閲覧担当者会議主査がフェーズタイミングをコントロールしながら，各館にて担当者が本番同様の作業を行った。

■本番移行
　利用者に対するサービス停止の影響を最小限にするため，土曜，日曜，月曜祝日に金曜日の閉館後の時間を加えた3.5日間の作業時間で完了させることとした。必要な作業は，1）慶應側のデータ抽出，2）慶應側の内容確認および修正，3）Ex Libris側のデータ移行作業，4）慶應側での移行結果確認，5）手作業移行の5つである。
　具体的には以下のような手順で作業が進められた。
　・金曜日閉館後（一部開館していた館はシステムを使用せず運用）：作業1）作業2）
　・金曜夜〜日曜朝：作業3）
　・日曜：作業4）：プロジェクト室による確認
　・月曜（祝日）：作業4）続き：閲覧Administratorによる確認と作業5）
　・火曜日：朝から通常開館
　月曜日は閲覧Administratorが朝から各館にスタンバイし，データの確認を開始した。午前中に全館にて確認が完了し，12：30から手作業移行フェーズに移る。主査の監督のもと作業は順調に進み16：00に終了した。
　この後最初の利用者への自動通知サービスを送信し，結果良好の確認がとれ，予定作業が全て完了した。できることは全てやり終え，あとは稼働初日に備えるだけとなった。

■稼働

　稼働初日は，従来のシステムには無かったマウス操作とポップアップアラートを確定する操作に戸惑うスタッフもあったが，操作を慎重に行って対応した。大きな問題はなく全館無事に初日の閉館時間を迎えることが出来た。

■稼働後の再検討事項

　稼働から3か月が経過した頃，その時点での問題点を整理し調整を図った。
　・帳票系の見直し
　毎日使用する帳票は使い勝手を重視し，文字サイズや強調，位置などを調整。
　・外付け追加開発
　課金徴収の操作が従来と比べて煩雑なため，一定期間を経ても操作ミスがあまり減少しない。慣れによる改善が望めないと判断し，前日分のエラーを機械的にチェックするモジュールを開発した。
　今後も全塾閲覧担当者会議にて検討や調整を継続する。

■結び：システム変更に当たって大事なこと
データの移行
　・自分の持っているデータの内容を歴史も含めて理解する。
　・新しいシステムのデータの内容，データと機能の関連性をすみずみまで理解する（ように努める）。
　・データの移行先はその後の運用を含めて慎重に決定する。
運用の検討
　・利用者にとって最適なサービスルールは何かを考える。
　・利用者にマイナスの影響を出さずに運用が可能か考える。
システム変更
　・検討グループを組織する場合，設定から初期稼働まで一貫したメンバーで行う。
　・システムを使用する全員が一つのチームであることを意識する。
　新システムへの移行は何とか初期稼働を乗り越えたところであるが，ここまでの成果は，全塾閲覧担当者会議および閲覧Administratorを通じた全スタッフとプロジェクト室が一つのチームとして作り上げたものである。今後も検討や調整は続くが，チームで協力して障害を乗り越えていきたいと思う。

注
1）Ex Libris作成の基本設定内容を導入館が選ぶアンケートのこと．回答に添ってEx Librisが基本設定を行う．