MediaNet No.18（2011.11）〈特集〉KOSMOS Ⅲ導入後の現状と課題

テクニカルサービスにおける業務処理の経過と課題
さとうやすゆき佐藤康之（メディアセンター本部課長）

げた。端的に言えば，従来，本部で実施していた発1 はじめに2010 年 4 月 の KOSMOS III 本 稼 動 以 来，既 に 1

注業務は，ほぼ全て各地区で行うこととなった。ま

年半が経過した。予算管理や統計処理，各キャンパたシステム面でも，図書の発注処理が外部のシステ

スのメディアセンター（図書館，以下，各地区）で

１）
ムサービス「ちょいす君」
から，雑誌の発注処理が発生するインベントリや除籍などの蔵書管理，製本

２）
メディアセンターで独自開発した「KOHEI」
から，業務を含めると，テクニカルサービス（以下，TS）でAleph の発注・受入・雑誌モジュール３）を利用した

は 1 年がシステム機能全体を検証する一つの目安とオンライン発注と発注票出力による発注に移行したなる。言い換えれば 1 年間を通して大きな支障もなことが挙げられる。受入目録担当では各地区が実施く業務が遂行できたことをもって，TS の図書館シする発注業務を支援するため，旧次期システムプロステム導入作業は完了するといえるだろう。

ジェクト室メンバーと協力して Web 上で参照する

本稿では，KOSMOS III となって改められた発マニュアルを整備した。このマニュアルは本稼動後

注・受入・支払・予算管理・目録などの各業務処理も更新を続けており，地区の TS 作業を支援するだを確認するとともに，2010 年度における業務処理のけでなく，地区と本部にまたがった TS 業務の全体経過と導入後の改善として取り組んできた点を報告像を把握する上でも重要な資料となっている。さらする。なお各地区での業務処理を含めた全メディアにシステム面では，Aleph には慶應で必要とするセンターにおける TS は詳細な業務処理の積み上げデータ項目間の齟齬を防止する仕組みがないことにで成り立っているが，本稿で取り上げる内容は本部対処するため，発注レコード内の地区コードと予算受入目録担当（以下，受入目録担当）の分掌する業

コード４）の不整合などのチェック機能を備えた各地務を中心に概要レベルに留めることとする。また，

区 TS 担当が利用できる外付けプログラムを Aleph

TS において KOSMOS III は，Ex Libris 社の図書館導入後に整備した。発注業務を各地区で実施するにパッケージシステム Aleph 及びその周辺に慶應があたっては，地区内での業務フローの検討，作業担独自開発した外付けプログラムの利用が中心となる

当者の配置，取引書店との調整，システム操作のトことを予めご承知置きいただきたい。

レーニングなど各地区 TS 担当に相応の負担が生じたと思われるが，各地区とも大きな混乱もなく順調

2 発注に推移していることが 2010 年 7 月の全塾図書雑誌

発注業務は，TS 業務の中で最も大きな変化を遂

担当者会議５）で報告されている。

図 1. 図書受入数の年間傾向：縦軸は年間受入数に占める割合18

MediaNet No.18（2011.11）〈特集〉KOSMOS Ⅲ導入後の現状と課題

発注業務における量的変化は，月毎の図書受入数６）である。

で確認した。
旧システムで運用していた 2009 年度との比較で 6 月から 8 月，10 月から 11 月で増加し，123 受入・支払・予算管理月から 2 月で減少した（図 1 参照）。単年度の比較でAleph 導入後，従来は図書と雑誌で別々に分かれは Aleph 導入後の影響として言及できないが，今後ていた業務フローを統合するにあたって，本部内での推移を引き続き注視していきたい。

は雑誌担当と図書・情報管理担当を組織統合し，受また，図書発注のオンライン対応書店が 2 社から入目録担当に一本化した。また，発注を担う各地区3 社に増加したことにより，発注先書店の選定に少TS 担当と受入を担う本部の業務分担も図書と雑誌なからず影響が出ることを想定していたが，結果とで統一した。導入後の受入処理量は，事前の担当者して大きな変化は見られなかった。なお，導入前にトレーニングが功を奏したためか図書・雑誌ともに懸念された発注書誌レコードの入力が煩雑になる点

従来の処理数をほぼ維持することができたが，デーは，2011 年 7 月 1 ヵ月間の外部書誌データベースのタ移行のための受入停止期間の影響で，移行直後に検索総数のうち 17％ の検索が主に書店の受発注シ新着雑誌の受入滞貨が発生した。このため雑誌受入

７）

ステム に対して実施されていることから，発注のた担当者の延べ最大週 38 時間程度の残務，図書受入及めの外部書誌レコードの流用が有効に機能しているび目録担当者の応援などにより，2010 年 6 月中にはことがうかがえる。なお，一部の地区では図書見計解消することができた。なお寄贈図書の受入についらい発注分の納品データを発注書誌レコードに流用ては，従来，全て本部で処理していたが，Aleph 導入することも実施されている。

後は原則として各地区 TS 担当で所蔵情報に相当す

Aleph 導入後初めての外国雑誌契約更新作業は，システムからの継続リスト抽出作業や支払データのる ITEM レコードを作成し，受入目録担当に現物を送付して目録を作成する流れに変更している。

一括登録などの機能を検証しながら進める必要が受 入 業 務 に お け る Aleph 導 入 後 の 最 大 の 山 はあったことに加え，稟議・契約手続きを各地区で実2010 年度末の処理であった。年度末においては，受施することもあり，日程的に厳しい状況だったが各入と支払の会計期の地区 TS 担当及び受入目録担当が協力して対応にあおよび学内の決算スケジュールに合わせるため，例たり乗り切ることができた。

年詳細なスケジュールを立案して対応している。見ズレを防止するための対策

Aleph に起因する不具合としては，一度に大量の計らい発注図書の各地区から本部への送付は，1 次，発注票を印刷する際のプリンタ障害や，オンライン2 次と複数回の締切日を設定していたが，発注を各発注分の発注票出力への混入などがあった。いずれ地区で実施するように変更したため，これらの締切も各地区 TS 担当の運用や本部システム担当（以下，日設定は 1 回で済むようになった。これらに対応しシステム担当）による対処で対応している。また同た新しい年度末スケジュールに Aleph 導入後の受一書店，同一予算の発注を一度に大量に作成するた入業務が対応できるかどうかが最後の関門であっための一括発注処理は，不具合のため実現できていなが，書店納品最終日が 1 週間後に迫った時点で発生い（Ex Libris 社で継続対応中）。

した東日本大震災とその後の計画停電によるシステ

なお，「ちょいす君」「KOHEI」の利用終了に伴い，ム停止により，日程的に非常に厳しい年度末処理に過去の発注・受入状況の確認，過年度に遡った監査追い込まれた。この事態に対処するため本部では管対応などの目的で，図書は「ちょいす君バックアッ

財部・経理部に状況を説明しつつ，受入とそれに伴プデータ検索」，雑誌は「KOHEI バックアップデー

う学内の支払処理について非常事態の対応を要請すタ検索」として外付けプログラムを整備し，今後もるとともに，Aleph への入力を後回しにして学内経適宜過去のデータを参照できるようにしている。

理システムによる支払の先行処理も検討した。しか発注業務においては細かな懸案事項も残ってはいし結果として，専任職員，委託先担当者が一丸となっるが，概ね順調に推移していると考えている。今後て献身的な対処を行ったことにより，当初のスケの評価は，新たに発注業務を担うこととなった各地

ジュール通り年度内に全点の受入を完了させて事な区 TS 担当による詳細な状況分析が待たれるところきを得た。初めての年度末における全ての関係者の19

MediaNet No.18（2011.11）〈特集〉KOSMOS Ⅲ導入後の現状と課題奮闘に改めて敬意を表したい。

理のトレーニングを各地区の予算管理担当者を対象

Aleph 導入後，支払業務の管財部・経理部との窓に開催した。初めてということもあり，各地区担当

口は，旧本部情報管理担当から本部総務担当へ変更

者と本部の担当者が連携して処理の各ステップを確されたが，各地区 TS 担当との連絡や事前の請求書認しながら対応し，スケジュール通り問題なく完了や支払データの確認作業，入力作業は，引き続き受することができた。

入目録担当及び本部電子資源担当で実施している。

予算管理についても，その効果を実感できるのはまた，従来，図書は「ちょいす君」，雑誌と電子資源主に各地区の予算管理担当者となるため，今後の各は「KOHEI」で分かれていた支払も Aleph へ入力す地区による状況分析と評価に期待するところであることとなり，支払は全て Aleph で管理できるようる。になった。システム面で小さな障害はあったが，学内の経理システムとの連携を含めた全体としては，
この 1 年半の間，特に問題もなく機能している。支

4 目録
Aleph 導入後の目録業務における主な変更点にに関わる部分だけに稼動後の慎重は，和書の書誌レコード基準の物理単位への変更，な検証と運用が求められるが，本部の各担当では従著者名典拠作業の追加，単一目録システムでの多言来以上に慎重に処理を進め，2010 年 11 月時点で 4語対応などがある。

払業務は

かね

月以降の学内経理システム向け支払データの執行金

和書の書誌レコードの物理単位への変更は，書誌額合計と Aleph 内の支払データが反映される外付レコード流用率の向上による効率化と電子ブックなけプログラム「予算管理表」の内容に大きな誤差がどの電子資料との親和性８）向上を狙ったものだが，生じていないことを確認した。

2010 年度における和書の流用率は前年度から 2％

予算管理も Aleph 導入によって大きく改善した。

程度増加している。Aleph では目録モジュールから

特に，従来，図書と雑誌で分かれていた予算コード目録担当者が直接外部の流用元書誌データベースをが統一されたことにより，予算の消化状況を管理す検索できるようになった。洋書の主たる流用元である上で大変分かりやすくなった。外付けプログラム

る OCLC の検索を例にとると，旧システムにおけるの「予算管理表」を確認するだけで，その時点の予受入時の自動書誌レコード調達システムと，一旦ダ算の消化状況を即座に確認できる。但し，リアルタウンロードしてから一括処理で目録システムに登録

イムの予算管理は執行金額の裏付となる発注・受する OCLC 専用ソフトウェアとの検索件数比率は入・支払の各処理が直ちに反映されるため，当初は2009 年度でそれぞれ 44％ と 56％ だったが，2010旧システムとの処理の相違（1 日遅れ）に寄る数字の年度は 99％ が Aleph の目録モジュールからの検索解釈をめぐって若干の混乱もあった。しばらくしてに変わり，目録担当者の作業効率の改善につながっ各担当者がリアルタイム予算管理にも慣れたこともたことがうかがえる。さらに，流用元に国立情報学あり，2 年度目に入った 2011 年 8 月時点では既に当研究所や韓国の延世大学図書館，中国国家図書館が初の混乱は忘れ去られている感がある。

追加されたことも流用率の改善に貢献したと考えら導入後の予算管理における重要な通過点としてれる。和書の書誌レコードの物理単位への変更には，予算年度更新処理があった。慶應では年度毎によって目録処理数が増加する一方で，流用率向上に予算コードを作成する運用としたため，次年度の受よるオリジナル作成数が減少することによって，全入を開始する前に予算コードの年度更新が必要とな体としての処理効率が向上することを期待しつつ，る。予算コードの年度更新作業は，次年度用コード今後も継続して検証したい。の一括作成及び新規分の手作業での追加，予算額のKOSMOS I で実施されていた著者名典拠作業は，設定，発注中となっている発注レコードについて次KOSMOS II で廃止（書誌レコード個別の標目調整年度用コードへの一括付替などの作業がある。これで対応）した経緯があるが，Aleph では著者名標目のらは各地区の予算管理担当者が実施することになっ大がかりな一括調整を容易に実施するために再開すているが，導入後 1 年経過した段階での初めての処ることとなった。一方で，各目録担当者は，Aleph理となるため，2011 年 3 月に改めて予算年度更新処

で書誌レコードを作成する際に最も時間のかかる作

20

MediaNet No.18（2011.11）〈特集〉KOSMOS Ⅲ導入後の現状と課題業として著者名典拠の作成を挙げている。システム

使用して，使用頻度の高いタグ９）を事前に設定しておの機能的な面でも課題を残しており，Aleph の次期いたり，既定値を入力しておいたりすることによっバージョンでの改善に期待するところである。て，入力漏れの防止も期待できる。また，ユニコー

また，Aleph で単一目録システムでの多言語対応ド対応のシステムになったことにより，以前は入力が可能になったことにより，和書・洋書とは別の業できなかった文字１０）の扱いが容易になるとともに，務フローで対応していた中国書や韓国書が単一の業検索時の漢字異体字変換テーブルも充実したため，務フローに統合された。二重の業務管理が不要と字体を気にせずに目録を作成できるようになった。

なったことは業務効率の改善に寄与するだろう。

GUI 操作では，2 つの書誌レコードを 2 分割されなお Aleph 導入を機に，業務委託先の目録担当者た画面に同時に表示することによって統合や分割のは原則として流用した書誌レコードの修正作業に特操作が分かりやすくなった。また，多くの機能がマ化し，流用を伴わないオリジナル作成及び雑誌目録

ウス操作になったため，初心者でも理解しやすく効は専任職員の担当とすることし，業務委託範囲の整率の良いトレーニングも期待できる，一方で，操作理を行った。

速度ではキーボードのみの操作が主となっていた旧

Aleph 導入後の目録業務の最大の懸念は，各目録システムとの比較でマイナスといった声もある。

担当者が短期間にシステム操作に習熟し，前述のよなお，2011 年 2 月には 9 ヶ月間の運用をふまえたうな変更点を織り込んだ上で，従来通りの新規受入

Aleph 検索インデックスの見直しと，それに伴って資料の量を処理できるかという点にあった。また，必要となる検索インデックスの再生成作業を実施しシステム移行に伴い中断した遡及入力作業を早期にた。従来，検索インデックスの再生成には長期間に再開することも課題であった。結果としては，Aleph及ぶシステム停止が伴うため，4 年に 1 回程度の導入当初の 2010 年 4 月から 5 月にかけては 1 日のサーバ・ハードウェアの更新時に実施するのが精一処理冊数が対前年度を割り込んでいたものの，6 月杯だった。Aleph の場合は，2 日間程度のシステム停からは前年度並みの処理量に転じ，その後は移行に止期間があれば検索インデックスの再生成作業が可

よってデータ整備が必要になった案件の処理に取り能なため，利用者サービスの運用が許す範囲で年 2掛かることもできるようになった。遡及入力作業も回程度実施できれば，細かな目録基準の変更に伴う2010 年 10 月には再開することができ，月平均で対検索インデックスの改善を今後も継続して実施でき前年度 50％ 程度の冊数を処理できるまでに回復しると考えている。一方で，目録担当としては作成した。年間を通した新規受入資料の目録処理量としてた目録レコードがどのように検索され，どのようには，ほぼ 2009 年度と同規模になっている。この間，表示されるのか，2 種類のシステムを検証する必要

受入目録担当では目録マニュアルの更新・整備を進が生じている１１）。

めるとともに，日々発生する問題とその解決方法のほか事例や不具合などを担当内のポータルサイトに5 データ整備掲載して情報共有を図っている。また，専任職員に手作業によるデータ整備案件は，データ移行に関よる委託先目録担当責任者への迅速な業務指示が効連するものと Aleph 及び Primo の仕様による制限果をもたらしたものと思われる。に関連するものに大別できる。まずデータ移行に関目録システムが変更になったことによる影響とし連するものとしては以下のような案件があった。ては，Aleph の目録モジュールに装備されている機・重複発注レコードの統合能によるものと，各種操作が GUI（Graphical User

・雑誌の発注書誌レコード統合Interface）に変更されたことが特に大きかった。目・雑誌の受入メモなどの再入力

録モジュールの機能に関しては，作成した目録レ・雑誌所蔵への和洋区分入力

コードの正確性を自動的にチェックするバリデー

・除籍済書誌レコードの非表示フラグ設定

ション機能の改善を中心に，2010 年度で約 150 件の・重複書誌レコードの統合設定改善をシステム担当と共同で実施し，作業しや・固定長データ部の図書出版年エラー修正すいように改善した。さらに，テンプレート機能を・版表示メモの ITEM レコードへの移動

21

MediaNet No.18（2011.11）〈特集〉KOSMOS Ⅲ導入後の現状と課題

・一部雑誌書誌レコードのフォーマット変更
これらにはデータ移行計画立案時に想定されていた案件と移行後に発覚した案件が含まれている。以下に具体例として「重複書誌レコードの統合」がどのような作業であったかを簡単に説明する。

6 その他
前章までに言及しなかったその他の業務に関連する事項を報告する。
各地区で行っている請求記号の付与についても重要な変更が加えられた。従来，請求記号が重複しなAleph へのデータ移行は，業務停止を最小限に留いように自動付与するシステムであった「マリエーめるため全件の本番移行と，本番移行後に追加され１３）に引きル」は，外付けプログラム「請求記号付与」た差分移行の 2 回のフェーズに分けて実施された。

継がれた。Aleph にはデータ項目間の論理的な整合

特に差分移行分として旧システムで受入を行う際性に基づいて自動入力する仕組みがないため，「請求に，他地区に所蔵があり既に完成された書誌レコー記号付与」では請求記号の自動付与のほかに，付与ドがあっても，新規受入分をあえてその書誌レコーされた請求記号に基づいて複数のデータ項目を設定ドとリンクさせずに別個に作成するようにした。こするという新しい機能が盛り込まれた。導入後にはのため移行後に重複する書誌レコードが発生するこ管理者機能も整備され，「マリエール」ではシステムととなり，これを解消するための作業が移行計画で担当が行っていた請求記号体系の管理作業が各地区決定されていた。この作業は利用者を混乱させぬよTS 担当でも対応できるようになった。

う移行後速やかに実施することが求められ，受入目外付けプログラムの中で最後に稼動したのが「除録担当では移行直後から開始し，約 9,000 件の作業籍報告」と「標準統計」の集計プログラムである。
「除を 2010 年 5 月中に完了した。なお，その他の作業に籍報告」は，毎年，管財部，経理部に報告する単年ついても全て 2010 年度中に完了している。

度における各地区別の除籍資料数の報告であり，「標次に仕様による制限に関連するものとして以下のデータ整備案件があった。

準統計」は当該年度のメディアセンターの業務規模や活動を報告する統計表で学内外に提出する各種統・書誌レコード長の分割修正計報告の基礎となるものである。
「標準統計」のうち・2,000 バイト超タグの分割修正

TS に関連する数値は資料の受入数や購入資料費のどちらも KOSMOS II の目録システムと Aleph!

実績額などがあるが，例年，システムから抽出したPrimo で扱える書誌レコードの最大長が異なるためデータを元に作成していた。Aleph 導入によりデーに発生した案件である。Aleph の書誌レコード長のタベースの構造が全く異なることとなったため，シ制限は，移行前に KOSMOS II 上で解消していたが，ステム担当が一から抽出・集計プログラムを開発し本稼動後に書誌レコードを Aleph から Primo へ転なおした。集計結果は，前年度と比較した際に妥当送する際に Primo の書誌レコード長制限に抵触すな数値となることが求められ，何回かのプログラムることが判明した。このため，一部の書誌レコード修正により正確な結果が得られるように調整が行わについて改めて Aleph 上で ITEM レコード単位にれた。

分割しなおす作業が必要となった。対象となる書誌レコードの件数はわずかであったが，非常に多数の7 今後の課題

ITEM レコードがリンクする書誌レコードであった

Aleph 導入後の TS 業務は，全般的に概ね順調にため作業には相当の時間を要した。一方，2,000 バイ推移している。特に以下を実現できたことは大きなト超タグの修正は，Aleph 上で書誌レコード中の 1成果といえるだろう。

つのタグに入力する文字数が 2,000 バイトを超える場合に発生する不具合への対応である。両案件とも2010 年 11 月までに全ての整備作業が完了した。
これらのほかに継続作業中の案件として，著者名
１２）

典拠レコードの整 備，〓（ゲ タ）文 字 の 修 正，
KOSMOS I 時代の不要な書誌レコードの一括削除があり，鋭意作業を進めている。

22

・発注業務を各地区 TS 担当が行うことによる処理の透明性の確保
・発注・受入システムの図書雑誌統合
・予算コードの統一による支払処理の一本化，予算管理のリアルタイム化
・本部における受入目録業務フローの一本化とこれにあわせた担当組織の統合

MediaNet No.18（2011.11）〈特集〉KOSMOS Ⅲ導入後の現状と課題・書誌レコード流用率の向上と多言語対応による目録業務フローの効率化
約 1 年半に渡り例年通りの業務量を確実に処理でタ更新などにおいて 1 点 1 点手作業で対応する必要がなくなる，また，各地区で必要なときにタイムリーなデータ抽出が実施できるようになるだろう。

きたことは，TS 業務における Aleph 導入の成功を標準統計用の外付けプログラムは，各地区での利示すものとして評価できると思う。この点において用を予定していたが，統計の対象となるデータの抽さらに東日本大震災と計画停電という突発的な事態出スケジュールや統計提出の締切時期などに細かなにも対処できたことは，ある意味で業務組織やフ制限があり，システムに対する負荷も大きいため，ローの堅牢性を証明する結果になったといえる。し2011 年度末に向けてシステム担当と運用の再検討

かし一方で，次のような問題や課題もある。

を行う予定である。

一つは「雑誌の別冊や臨時増刊などで明示的な巻

これらの問題や課題を一つ一つ丁寧に解決しつ号表示などを持たず，固有のタイトルを持つ資料」のつ，業務の安定運用とさらなる効率化のための改善扱いである。このような資料について図書のように点の洗い出しも進めていきたいと考えている。

個別の書誌レコードを作成して検索に提供したいとの声がサービスの現場では根強いが，Aleph の仕様

8 おわりに本稿では，KOSMOS III 導入後の業務処理の変更

では雑誌発注に基づいて受入後の資料を図書のように個別の書誌レコードを持つ形に変更することが困点と 2010 年度の経過を中心に報告した。

１４）

難 なため，一部の特定タイトルに限り全地区で統Aleph の導入による業務の変更は多岐に渡るが，一して発注段階から全て図書発注として処理するこ

それによって全地区における TS 業務全体がどのよとを全塾図書雑誌担当者会議で検討している。

うに改善されたのか，今後発生するメディアセン

また，著者名典拠作業の効率化についても再検討

ターを取り巻く様々な環境変化に柔軟に対応できるが必要と考えている。本来，著者名典拠レコードを基盤となりえたのか，総合的かつ中長期的な評価が単独の図書館の目録作業で維持するのは業務負荷の必要と思われる。

観点で現実的ではない。一方で，均質の取れた書誌本部及び各地区 TS 担当者にとって 2010 年度はレコードを維持するためには，書誌レコード中の著困惑と忍耐の 1 年間だったと思う。日々発生する

者名標目の一括修正などは 重 要 な 作 業 で あ る。

様々な疑問や問題に対処しながら業務遂行のために

Aleph の場合，著者名典拠レコードを維持すること邁進されたことに対して，この場を借りて全 TS 担で，容易な一括修正が可能となるが，目録の業務効当者の労に心から感謝したい。また，各地区 TS 担当

率を落とさずにこの作業を実現するためには，どこ者の全塾図書雑誌担当者会議を中心とした課題対処までの内容を著者名典拠作業として盛り込むべきへのご協力に改めて御礼申し上げる。

か，早急に再整理する必要があると考えている。
データ整備も今後の課題として残っているものが注ある。継続中のデータ整備案件のほか，データ移行

1）「ちょいす君」 は，丸善株式会社が提供する書籍発注シによって生じた巻号表示やソート用巻次，発行年月ステム．専用回線を介して同社の商品マスタファイルを次のデータ整備も計画したいと考えている。なお，利用しながら図書の発注・受入作業を行い，KOSMOS II

Aleph 導入とは直接関連しない KOSMOS II 時代かへの一括データ転送処理で目録作業と連携させていた．

らの継続案件もあることを念のため付記しておく。

2）「KOHEI」も「ちょいす君」同様，KOSMOS II とデータシステム面では，Aleph の各モジュールに装備さを連携させて利用していた．

れていて主に一括処理を実施する各種「サービス」
プ

3） Aleph はサーバ及び PC 上で動作するクライアントのプ

ログラム群の積極的な活用を進めていきたい。2011

ログラムで構成されていて，クライアントのプログラム

年 9 月時点で，各地区には配置場所変更に伴うデーは，このほかに目録，閲覧，ILL，設定管理の各モジュー

タの一括更新が保留となっている案件がある。一部

ルがある．にシステム担当による作業を必要とするものもある

4）「地区コード」 は各地区メディアセンターに割り当てらが，「サービス」を上手く活用できれば，これらのデーれた識別コード．
「予算コード」は，主に資料購入に必要

23

MediaNet No.18（2011.11）〈特集〉KOSMOS Ⅲ導入後の現状と課題な予算の区分をコード化したもの．どちらも Aleph 導入に伴いメディアセンター独自のコード体系として作成した．
5） 各地区 TS 担当と本部受入目録担当の代表者で構成する会議体．全メディアセンターの TS 業務全般に関する案
件を検討，協議する．筆者は主査を担当．
6） 本来は発注数で比較すべきだが，Aleph 導入前後で比較に耐えうる統計数字は受入数のみとなっている．最近の書店の発注から納品に要する期間から判断して受入数でも大まかな発注数の傾向を把握できると判断した．
7） Aleph から流用可能な受発注システムを持つ書店としては，紀伊國屋書店，図書館流通センター，AMAZON がある．但し，これらは外付けプログラムのゲートウェイ機能を利用している．
8） 特に多巻物図書などの場合，電子版の目録は PDF などの電子ファイル（物理）単位で作成されることが多い．
インターネット上の電子書店なども，この単位で本の表紙画像や目次などが提供されている．
9） メディアセンターの目録は MARC21 に準拠している．
タグはデータ項目をあらわす 3 桁の数字．例えばタイト
ル・責任表示は 245 で表す．
10） 音標符号付きのアルファベットや JIS コードにない漢字など．
11） 利 用 者 用 検 索 イ ン タ ー フ ェ ー ス と し て KEIO-OPAC（Aleph WebOPAC）と KOSMOS の 2 種類が提供されるようになり，それぞれで検索機能や検索インデックスが異なるため．
12） KOSMOS II ではユニコードを入力できなかったため，一部の文字を〓（ゲタ文字）で置換していた．
13）「請求記号付与」 は各地区の請求記号体系にあわせ，「請求記号付与 1〜4」のバリエーションがある．
14） Aleph の ITEM レコードには，1 冊毎の資産管理に必要な全てのデータ項目が準備されていない．システムを資産台帳として機能させるためには，発注・受入・支払といった各処理段階のデータ項目と ITEM レコードの関係を維持することが必須となる． 一方で， 図書の発注，雑誌の発注では発注・受入・支払におけるデータ項目の持ち方が異なるため，雑誌発注で納品された 1 冊を図書に変更することが難しい．

24