MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

The struggle for KOSMOS Ⅲ Data Conversion．
（データ移行奮闘記）―This is it！―
たなべみのる田邊稔（メディアセンター本部課長代理）

定長のデータに変換するのは至難の業である。デー

1 プロローグ

ふるい

最初からそれが大変なことはわかっていた。

タを何度もゴリゴリと「（ 篩）」にかけて，新システム200 万件の書誌データ，500 万件の所蔵データ，多種仕様の型に合うように磨き上げて行く。いわば，多様なデータソースとフォーマット，「負の遺産」とデータのクレンジング呼ばれる遡及データ群，揺れる仕様，パッケージシ

また，データ移行とは過去（歴史）を知り，現状ステム（以下。Aleph）のデータ構造や機能の理解不と向き合い，未来へとバトンをつなぐ作業でもある。

足，海外ベンダーとの英語での不慣れなコミュニ

その意味で，我々データ移行チームは，新旧システケーションなど，眼前に立ちはだかる壁はいくつもをつなぐ「時代の架け橋」的役割を担ったといえる。

である。

あった。それでなくとも，データ移行とは神経を使うきめ細い作業である。どう考えたって簡単に行く
注1

3 移行方針の決定と覚悟はずがなかった。しかし，データ移行チーム のリーものごとを「選択する」ということは「決める」こ

ダーに私が任命された時，さほど大変さを理解してと。
「決める」とは「覚悟する」こと。
「覚悟する」といなかった。これまでもデータ移行は数多くこなしは「決めたことを遂行すべく，潔く前に進む」ことてきたし，今回は大半の作業をパッケージベンダーである。覚悟したら，あとは粛々とやるだけだ。

がやってくれるものと信じていたからだ。後に，そAleph というパッケージを選択した時点で我々は覚の予想が見事に打ち砕かれ，未知なる荒海に放り込悟をしなくてはならなかった。しかし，何をどう移まれることになろうとは，知る由もなかった。

行するか？など決めるべきことを決めていなかっデータ移行チームが，データ・システム・人とどう向き合い，どう戦ったか？の魂の記録。これがそれ だ！（This is it！）た。
だから，覚悟もできず，なかなか前に進めなかった。
2009 年 1 月末に日吉 AV ホールにて 3 日間かけて行われた Ex Libris（以下。E 社）とのデータ移行のキックオフミーティングは最悪だった。慶應側の2 データを移行する意味移行方針がまったく決っておらず，人によって言う言うまでもなく，データとはシステム上のコンテことがバラバラで E 社からの質問にそ の 都 度 フンツであり，システム検証に不可欠な存在である。

リーズし，まともに答えることができなかった。果

データとシステムはいわば「鍵」と「鍵穴」の関係ては，内輪揉めまで起こす始末。恥ずかしくて，情にある。車にキーを差して回さないと動かないのとけなかった。E 社から見たら，日本の大学のお粗末な同様に，データを流し込まない限り新システムは動姿は，いささか滑稽に見えたことだろう。先行き不き出さない。同時に，データとはシステムを映す鏡安な船出となった上に，このミーティングの衝撃かでもある。データを見ればシステムの内部構造がわら立ち直るのに相当時間がかかった。

かると言っても過言ではない。KOSMOS II のコア

E 社は，データ移行に限らず，自社の開発フレームシステムである CALIS とそれを取り巻く分散シの適用を強要してきた。自分たちのシナリオで顧客ステム群である中から ，KOHEI ，ちょいす ，を型にはめ込み，強引にサービスイン（以下。STP：

RUI 等，どれもデータ構造がユニークで，良くもSwitch To Product）へと持ち込む作戦だ。パッケー

悪くも KOSMOS I 時代からの歴史を引きずってきジベンダーなら至極当然のこと。しかし，それを受た。KOSMOS I のがっつりと階層化されたデータ群

け容れることは，慶應側に考える隙が与えられないが，KOSMOS II で緩やかに分散し，再度 KOSMOSこと（つまり，思考停止状態）を意味する。肝心なIII の固定長の世界へと収斂されて行く様は圧巻でことは，E 社のペースに呑まれずに，慶應のペースである。可変長の緩いデータを，バリデートされた固早め早めに手を打つこと。そのためには，迅速な意

32MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

思決定と仕様の明確化が必要だった。の作成がある。データ移行仕様書について，当初 E

そこで，我々はリスク回避のために「大きな英断」

社製のデータ移行仕様書（Data Conversion Specifi-をした。当初，旧→新コードのマッピングを含め，cation・図 2）のみで済ませようとしていたが，これ大半のデータ移行を E 社に任せるつもりだった。しでは現場との仕様確認や移行結果の検証が困難と判かし，日本のベンダーでも難しいデータ移行の細か断し，誰が見ても分かり易く，データの流れや手順い変換作業を E 社に英語で説明し，理解・納得さが一望できる「データ共通仕様」（図 3）を別途作成すせ，プログラムを開発させるのは得策とは思えなることにした。具体的には，1）
データソースの項目かった。そのため，『E 社に引き渡すデータフォーと 2）E 社に引き渡す項目，そして 3）ロード先のマットの種類をできる限り集約し，コード類をすべAlephテーブル項目の関連が一目でわかるようにした。て慶應側でマッピングし，E 社には右から左へデーなお，技術的には，後戻りのない形でしっかり作タをロードしてもらうだけにする』という大胆な方ることを考えた。システム屋の間では一度しか使わ針転換を行った。結果的に，この作戦は我々を成功ないプログラムを「ゴミプロ」と呼ぶが，「たかがゴへと導いたが，膨大なコードマッピング作業には相ミプロ，されどゴミプロ」。その場限りの「やっつけ当手を焼いたことは言うまでもない（図 1）。

仕事」ではなく，STP 後の運用に「つながる仕事」に

また，設計段階で工夫した点の 1 つに，共通仕様

図 1.

しようと誓った。

コードマッピング仕様〜 PatronStatus サンプル

図 2.

Data Conversion Specification サンプル33

MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

図 3.

データ共通仕様サンプル

4 移行データと これでもか のスケジュール

は本番を含めて 3 回の移行を予定していたが，結果移行対象データは，書誌関連はプリントのみとし，として，全 8 回もの移行を行う結果となった。理由

注2

また，最終的に著者電子リソースは対象外とした 。

は大きく 3 つある。1 つは，慶應側の仕様の揺れと典拠データも加わった。所蔵データは基本全件対象

E 社側の不具合対応遅延のため。次に，著者典拠の移とし，閲覧関連は利用者データ全件と現貸出デー行が加わったこと。そして，本番前に時間測定と手タ・未収金データのみとし，過去の貸出履歴や予約順確認のために，どうしてもシミュレーションを行

注3

詳しくは次データなどは移行しないこととした 。の表（図 4）を参照されたい。

いたかったことである。
また，運用上図書・雑誌の日々の受入をストップ

移行スケジュールについては，当初 E 社との間でできないため，差分移行を行わざるを得なかった。
差分移行は追加のみとし，更新と削除は対応しソースフォーマット移行件数ないこととした。というのも，更新や削除まで欲張っ

メイン書誌

CALIS

BinaryMARC 1,783,856て差分移行してトラぶった事例は枚挙に暇がないか

中から書誌

中から

BinaryMARC

104,835

らだ。それに，追加だけであれば，慶應，E 社とも通和装本・旧分類

GoogleBinaryMARC

101,956

常の新規移行スクリプトが流用できる。

著者典拠 メイン CALIS
中から

ASF-MARC

571,795
645,104★全 8 回の移行スケジュール

所蔵

データ種別

1）0 次（2009 年 5〜7 月）：サンプルデータ

図書
雑誌

CALIS

Text

3,597,389
1,658,100

雑誌所蔵範囲

CALIS

Text

77,118

利用者

CALIS

Text

61,103

貸出CALIS

Text

37,824

未収金

CALIS

Text

297

図書発注ちょいす Text

3,837

雑誌発注

KOHEI Text

16,017

雑誌書誌

KOHEI Text4917）最終本番（2010 年 3 月）
：フルデータ＋典拠

業者

RUIText

2,2958）最終本番差分（2010 年 4 月）
：差分データ＋図予算

KOHEI Text357

図 4. 移行対象データと最終本番移行件数（差分除く）

2）1 次（2009 年 8〜10 月）：フルデータ3）2 次（2009 年 11〜12 月）：フルデータ4）3 次（2010 年 1 月）
：フルデータ＋典拠
5）4 次シミ ュ レ ー シ ョ ン（2010 年 2 月）
：フ ル
データ＋典拠6）5 次シミュレーション差分（2010 年 2 月）
：差分データ書発注
0 次〜2 次移行では，仕様の揺れがあり，手探りだった作業手順が，3 次ぐらいから安定してきて，データ FIX から提出まで 1 ヵ月ぐらいかかってい34MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

た作業が，約 2 週間で提出できるまでになった。に修正してもらった。また，配置場所一括変更や一また，シミュレーションと最終移行では，E 社の括除籍など予め計画されているデータ整備についてデータコンバージョンセンターがあるドイツ・ハンは，2009 年 9 月末までで KOSMOS II 修正依頼を締

ブルクとの時差（東京−8 時間）を最大限利用できるめ切った。

よう時間単位の綿密なスケジュールを作成した。

書誌―所蔵リンク切れ整備，合綴本所蔵データ分
割，中からリンク整備，全除籍処理，KOHEI 書誌 ID

5 牙を剥いた所蔵データと 2GB の壁付与，書誌データ長修正などについては，期限ぎり

上記データ種別の中で最も苦労したのは，巨大なぎりまで追い込みをかけた。しかし，どうしても 4所蔵データのハンドリングである。所蔵データには，次のシミュレーションまでに間に合わないものが発Item Status（資料取扱区分）や Item Process Status

生したため，「とにかく Aleph に全データを移行し，（資料状態コード），Enumeration（擬似巻次）など改めて整備計画を立てよう！」と腹を括った。

コードマッピングが必要な項目が多数ある。数が少なければ，手作業でも変換できるが，500 万件は尋常7 E 社の評価と信頼性ではない。CALIS の所蔵形式から E 社に引き渡す

全 8 回のデータ移行を通じて E 社対応の総合評データを用意するのに約 10 日間を要した（ちなみ価は 65 点といったところだろうか。結果的に及第点に，書誌データ 200 万件は同じ MARC フォーマッは付けられるが，ロード後のインデックス生成を忘トでも約 3〜4 日間）。

れたり，利用者名などの日本語が文字化けしていてデータ移行プログラムの開発は，生産性（開発効も気づかなかったり，MARC フォーマットのタグ率）と他の開発者との互換性を考え，大半を MS-780!
785 の雑誌変遷リンクの要求仕様をなかなか理

Access2007 で 開 発 し た。KOSMOS II 時 代 の 資 産

解してくれなかったり，GUI での結果確認を怠った（Access クエリやモジュールなどの部品群）を最大りとお粗末な面も多かった。中でも 1 次⇒2 次で移限活かし，開発時間を短縮したかったからだ。しか行品質が大きく下がったのは誤算だった。結局，2し，大きな落とし穴があった。現状 Access の DB

次＆3 次のバグをシミュレーションまで引きずった（以下。MDB）
では，保存できるファイルサイズは最が，最後はきっちり決めてくれた。データ移行が終大 2GB までに制限される。また，Access ではデータわってから聞いた話だが，今回 E 社側はドイツの更新を行う際に，更新前のトランザクションログをデータコンバージョンセンターの K 氏がほぼ一人確保するが，すべて MDB 内部に保存されるため，サで対応したらしい。孤軍奮闘という点では共感を得イズが膨れ上がる。500 万件の所蔵データを一気にたが，いくら移行のエキスパートといっても一人で更新すると，300MB 程度のファイルが軽く 2GB をは無理がある。逆にミスを生むリスクも高い。最低超えてしまう。そのため，館別に所蔵データ処理用でも二人一組でクロスチェックを行う必要がある。の MDB を分けてから処理を行うこととした。それこれは慶應側にも同じことが言えた。今後の課題とでも，三田 1 館で 200 万件を超えるため，MDB の最したい。

適化（ファイル圧縮）を繰り返しながら変換を繰り返した。正直この作業は心身ともにかなり堪えた。
結局，本番移行では時間が足りないと判断し，一部Perl で処理を行うことにした。

8 E&K 効果〜愛すべき未来へ
ハンブルクとの時差もあって，データ移行作業を平日の深夜〜朝方や休日に自宅でやることが多かった。睡魔に襲われて寝落ちしたり，とっ散らかって6 ぎりぎりまで追い込んだデータ整備

パニックを起こしたり，気がふれそうになる瞬間も「できる限り，過去のデータ不備を引き継がず，多々あった。そんなとき，いつも自分を鼓舞してく

デ ー タ を き れ い に し て か ら Aleph へ 移 行 し よれたのが，EXILE 注 4 と KREVA 注 5 の音楽だった。

う！」という基本方針の元に，不備データを抽出し，EXILE のアルバム『愛すべき未来へ』の透明感のあ一括修正できるものは本部システム担当で対応し，るバラードと KREVA のアルバム『心臓』のエッジ

個別処理の必要なものは図書・雑誌テクニカル担当の利いたナンバーを交互に iPod でガンガン鳴らし35MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部ながら，孤独で泥臭い作業を乗り切った。正直，彼謝辞

らの音楽がなければ深夜・休日作業を頑張り通すこ

CALIS データ抽出やデータ整備など多大なる協とはできなかっただろう。 彼ら輝かしい E&K は，力をいただいた有限会社アユソフト殿，複雑な著者暗中模索する我ら E 社と Keio を 愛すべき未来

典拠データ作成を快く引き受けてくれた京セラ丸善へと導く一筋の光となった。

システムインテグレーション株式会社殿，ちょいす図書発注データをご提供いただいた丸善株式会社殿に深く感謝したい。また，度を越した在宅作業に不9 エピローグ
兎にも角にも，無事にデータ移行が完了し，STPを迎えられてほっとした。成功したのは，言うまでもなく，データ移行チーム全メンバーと仕様確定や結果検証に関わってくれた全スタッフの努力の賜物に他ならないが，個人的に成功の要因を上げるとすれば，それはリーダーの「大いなる勘違い」と「根拠のない自信」かも知れない。これが自分の最後の仕事（いわば集大成）という気概と 俺はプロだ！ ，俺がやらなきゃ誰がやる！ という自己暗示。それに「絶対うまくいく！」というあてのない自信。それらが，自分を駆り立て，心折れることなくメンバーと共に最後まで走り抜けることができた。
最後に，これだけは自信を持って言えることがある。
『このメンバーだから乗り越えられた！』と。各メンバーがプロ意識を持ち，心を鬼にして臨んだからこそ成功に漕ぎ着けたのだと確信している。

満はありながらも傍で支えてくれた家族に，この場を借りて心から感謝したい。

注1） データ移行チームは，次期システム開発プロジェクト室の各モジュール担当 4 名（目録 1，受入 1，雑誌 1，閲覧 1）とシステム担当 2 名（内 1 名はリーダー田邊）の 6 名で構成．
2） 電子リソースは，情報探索ツールの KOSMOS（Primo）へ直接ロードすることに決定したため．
3） 予約については，データ FIX 後に CALIS から貸出中!確保中!
移動中の予約リストを作成し，データ移行後〜STP
直前に閲覧担当者が手で Aleph にデータを移植した．
4） EXILE（エグザイル）は，日本の音楽（J-POP）とダンスパフォーマンスの融合を目指す 14 人組のヴォーカル＆ダンス・ユニット．
5） KREVA（クレバ，本名：畠山貴志）は，日本の男性ヒップホップ MC，トラックメーカー，作詞家，DJ．慶應義塾大学環境情報学部（SFC）卒．

36