東京国立博物館の収蔵品管理システム
Collection Management System of Tokyo National Museum
村田良二*

Resume:
東京国立博物館では，収蔵品のデータを一元的に管理する収蔵品管理システムを開発している。すでに実際の業務において活用しつつ，さらなる機能追加や洗練のため開発を続けている当館のシステムについて，その概要に加え，開発プロセスやインターフェース・デザインの工夫など，具体的な実践を通して，収蔵品管理システムの姿を提案する。
1. はじめに用の流れが作られることであった。そのためには，東京国立博物館の所蔵品は現在 11 万件を超え資料情報の捉え方という面においてユーザであており，国内有数の規模となっている。館の設立

る専門家・学芸員のメンタルモデル（対象をどの以来長期間にわたって，これらの収蔵品および関ように心的に把握しているか）がシステム上のデ連する情報は絵画，彫刻などの分野ごとの担当部ータモデルとして適切に反映されていることが署が管理してきた。しかし 2001 年の独立行政法まず重要である。そして次に，システム上のデー人化以後，組織体制は収蔵品の分野よりもむしろタを用いることで日々の業務を効率化できるよ

業務区分を反映した形となり，分野の専門家のみうにならなければならない。博物館の業務においによる情報管理は非効率であるとともに現実的て，資料のデータは繰り返し様々な形で利用されに困難となっていた。

る。一元的なシステムがない環境では，例えば資このような背景の中，2005 年に東京国立博物料について記載すべき公的・非公的な様々な文書館の研究員に加えて外部の博物館・美術館関係者，に，そのつどコピー・ペーストして使っていると情報技術に関連する企業の専門家をメンバーというのが現実である。そのため，単に作業効率がして「博物館情報処理に関する調査研究プロジェ低いというだけでなく，新しい情報がつねに最初クトチーム」が編成され，博物館・美術館におけの情報源に反映されている保証もない。しかし，る資料情報システムと複数の館での情報共有の仮に一元的な管理システムが存在していたとしための基盤として「ミュージアム資料情報構造化ても，業務への適用の段階で多くの手間を要した1モデル」 （以下「モデル」という）が開発されり，システム利用のための学習障壁が高すぎたりた。

すれば，結局はそのシステムは十分に活用されな「モデル」の開発と平行しつつその成果に基づいであろう。その結果，やはり最新のデータを蓄いて，それまで館内に様々な形で分散していた収積することができず，そのためさらに活用されな蔵品のデータを一元化し，その情報を管理するとくなるという悪循環が起きる。これは博物館に限同時に業務での活用を支援するためのシステム

らず，多くの分野で失敗したシステム構築が陥るの構築を段階的にすすめた。これが現在の東京国罠でもある。

立博物館の収蔵品管理システムである。以下その悪循環ではなく，よい循環を作ることができる

理念，開発プロセス，および使い勝手を向上させかどうかが，システムが成功するか否かの分岐点るための様々な工夫について述べる。といえる。そこで，東京国立博物館の収蔵品管理システムでは，システムの積極的活用による最新2. システムの理念の充実したデータの蓄積，という循環を実現する「モデル」の開発において重視されたことは，ため，日々の業務を支援する機能に力を注いでいシステム化によって資料情報の円滑な蓄積と活る。具体的なレベルで指標を表現するとすれば，*むらた りょうじ（独立行政法人国立文化財機構東京国立博物館学芸企画部博物館情報課情報管理室）
原稿受理日：2008/10/30- 13 -

③村田：東京国立博物館の収蔵品仮システム

それは「定型的な作業において，コピー・ペース要性についての認識がユーザの間で高まったこトをどれだけ減らせるか」そして「さまざまな業とである。ユーザにとっては，システムは動いて務の情報をどれだけ集約できるか」ということにみなければわからない。その意味で，館内で直接なる。定型的な作業では，可能な限り自動化によ開発を行い，ユーザに使ってもらいながら段階的りシステムに肩代わりさせるべきである。例えば，に洗練させていくという方法が極めて有効だっ同じ作品リストを基にした会議資料を複数の書たということでもある。

式で出力するといった作業は，必要なデータの入力と書式の選択だけでできるようにする。業務ごとの情報を集約することも重要である。従来，様々な業務ごとの情報は，従来は貸与や展示や受入れなど，それぞれ個別に蓄積されていた。これでは，ある作品の履歴について知りたいときには，それぞれの業務ごとにデータを調べなおすか，業務データとは別に作品ごとにデータを管理しなければならない。前者では作業の効率が悪く，後者ではデータの一貫性を保つための作業コストが高い。しかし，これらを集約して扱うシステム
では，一つの業務をシステム上で作業した結果が
図 2. 平常展管理画面蓄積されていくため，様々な切り口で見ることが可能になり，しかも常に一貫性が保たれる。
現在は，収蔵品の番号や名称による検索，画像3. 開発プロセスを含めた詳細表示，資料をピックアップしてリスシステムの開発は 2005 年初頭から着手していト化するという基本機能に加えて，平常展管理，るが，「モデル」の開発と平行して，最初に行っ鑑査会議（寄贈，購入，寄託等を審議する），貸たのは既存データの分析と試験的な実装であっ与の各業務を支援する機能を実装し，運用していた。試験的な実装では，ユーザにシステムの具体る（図 1，図 2）。

的なイメージを掴んでもらうことと，技術的課題の洗い出しを主な目的とした。この段階では，すべての分野の資料を同じ画面から検索できること，画像サーバとの連携により文字データに加えて画像データを表示できることを最小限の機能とした簡単な試験版を構築した。このように実際に動くソフトウェアをユーザに提示することにより，ユーザ自身も必要な機能や希望を明確に表現できるようになる。委託による開発では要件定
義に長い時間がかかることが多く，動かしてみたらユーザのイメージと違っていたということが少なくないが，館内で直接開発することにより，そうしたリスクを避けることができた。

図 1. 検索結果一覧画面

技術的な検証では，実際のデータ量での検索のレスポンスタイムを実用的なものとするために実際の運用が進んで明らかになってきたこと必要なバックエンドの構成を検討した。その結果，は，業務支援に注力した結果システムの活用が進本システムでは MySQL に全文検索パッチであるんだと同時に，一元的なデータ管理の有効性と必Senna2を適用して用いている。フロントエンドは- 14 -

③村田：東京国立博物館の収蔵品仮システム

当初より Web アプリケーションとする方向であ開用データの出力，題箋用データの出力など，ったが，Perl 等のスクリプト言語と Java を比較

様々な段階で同じ情報が再利用される。また資料し，最終的には一定の規模のシステムになることのデータも展示での利用を通じて更新されるこが予想されたこと，オープンソースのフレームワとが少なくない。したがって，システムによる支ークが充実していることなどから，Java で開発援が極めて効果を発揮する領域といえる。

を行うことにした。なお，アプリケーションフレ

平常展の取りまとめをする学芸員と密接に打ームワークとして Spring framework を，RDB マち合わせ，試作を繰り返しながら実装をすすめた。

ッピングフレームワークとしては Hibernate を要件の定義は打ち合わせと実装の反復により採用した。

徐々に決まっていったため，文書化等によるオーこうした検証の後，改めて本格的なデータモデバーヘッドを最小限にできたと考えている。また

ルの構築と，続けてデータ移行を行った。基礎と運用が始まってからも不具合の修正を迅速に行なるデータ源には複数の候補があったが，信頼性えるのは，やはり内製のアドバンテージといえる。

や最新データの反映状況から，最終的には列品課運用が本格化するのには多少の時間を要した。

（当時）が管理していた列品管理簿（台帳に記載

これは平常展の計画や会議が行われるのが年度された基礎データを電子化したもの）と展示課後半のある時期に集中しており，それ以外の時期（当時）が管理していた陳列案データベース（平ではなかなか試用が進まなかったという事情に常展の計画や題箋の出力に使っていたもの）をマよる。しかし一旦運用が軌道に乗って以降，すでージすることとした。に平常展の業務には手放せないツールとなって「モデル」に基づき，資料にかかわる実体としいる。て人物・団体のデータなどを正規化（「名寄せ」

平常展支援機能の実装後，鑑査会議（購入，寄のような処理）する必要があったが，表記ゆれな贈，寄託，修理等を審議する会議）の業務支援，どが激しく，完全な自動処理は不可能であった。

貸与業務の支援と機能の追加を進めている。いず

そこで，頻出する表記のパターンについては一定

れも実際の業務の当事者と頻繁に打ち合わせ，明程度自動処理によって正規化し，残りについては文化されていない業務プロセスの分析を行い，実後日手作業で行う方針とした。

装と改良の積み重ねによって構築を進めている。

検索・表示に加えてデータ更新のインターフェ

今後は，修理期間の管理，特別展での資料の利用ースを作成し，データを新しいシステム上で完全予定の管理などの機能を追加する予定である。に操作することができるようにするところまでが，最初の段階の開発であった。データ更新に関

4. インターフェース・デザイン

しては，更新処理を承認するプロセスを組み込む

開発過程において業務支援と同様に重視してことも考えられたが，実際の作業においてこの場いるのが，操作性，使い勝手のよさの追及である。

合承認プロセスがボトルネックになることは明システムがユーザによって積極的に活用されるらかであったため採用しなかった。むしろデータためには，見やすい画面設計や直感的な操作性のに不審な点があった場合にその原因を調査でき実現など，学習障壁を下げると同時に「使っていることが重要であると考え，更新作業はすべてロて楽しい」といった総合的なユーザ経験の向上がグをとり，誰が・いつ・どのデータを更新したか必要である。そこで，本システムにおいて行ったを後から追跡できるようにした。

インターフェース・デザイン上の工夫を紹介した

次の段階では，館内の業務のうち，収蔵品のデい。

ータを最も大規模に利用する平常展の管理を扱一つは，リスト作成の機能である。本システム

うこととした。平常展は各分野の担当が案を作成

では単純な資料のリストを作成できるほか，平常し，平常展調整室が取りまとめ，会議による承認

展，鑑査会議，貸与のいずれの業務支援機能におを経て実施される。この間，資料の選定や予定のいても対象となる資料のリストを作成する必要割り当て，会議資料の出力，実施の確認，Web 公がある。業務が異なっていても，「検索したデー- 15 -

③村田：東京国立博物館の収蔵品仮システム

タからピックアップし，リスト化する」というタいう視覚表現手法から着想したものである。

スクは共通している。そこで，どの業務支援機能

Sparkline とは，文中に埋め込むことのできる小でもリスト作成というタスクは基本的に同じ操さなグラフであり，変化するデータの様子を文章作で行えるようにした。具体的には，まず上部にに埋め込むことでデータと文脈を密着させて表ユーザが現在どの業務のどの案件について作業現する手法である。資料の使用予定のグラフではをしているのかを常に表示するようにした。そのこれに習い，検索結果一覧という文脈に視覚的な上で，検索結果や資料の詳細画面から作業中のリデータ表現を埋め込んだ。これにより，例えば展ストに追加したり，そこから除去したりするボタ示の計画をしているユーザであれば，展示の候補ンを配置した（図 3）。こうしてリスト作成のタとなる資料の使用状況を直感的に相互比較するスクを共通化したことで，業務ごとに操作の異なことが可能となる。

るタスクを最小限に抑え，学習障壁を下げる結果となっている。

この他にも，Web アプリケーションという表現力の制約された環境においても可能な限り直感的な操作ができるよう，JavaScript による動的な表示や，近年多く使われるようになった Ajaxと呼ばれる手法によるインターフェースを取り入れている。しかし，文化財のもつ多岐に渡る情報をもれなく，わかりやすく，操作しやすい形で提示することは困難であり，今後も改善の余地は大いにあると考えている。

図 3. リスト追加ボタンとグラフ

5. 今後の課題
博物館の主要な業務のうち，まだ支援機能が実

もう一つ特徴的なのは，資料の使用履歴のグラ現していない業務について，引き続き開発を続けフ表示である。これは，ある資料が展示や貸与なることが当面の課題である。同時に，前述のとおどで過去にいつ使用されたか，あるいは現在からりインターフェースのデザインには改善の余地将来にかけて予定が入っているかを表現する小があり，研究を進めたい。こうした探求で得られさなグラフで，検索結果一覧などに表示されるた知見は，館内の業務用システムの洗練だけでな（図 3）。この小さなグラフは，情報グラフィッ

く，一般の人々に文化財の持つ豊かな情報を提示

クスの専門家 Edward Tufte の著書 Beautifulする際にも必ず役立つことと考えている。

3

Evidence において言及されている Sparkline と村田良二「『ミュージアム資料情報構造化モデル』の構築」『ミュージアム』, No.602, 2006, p.47-66.
Senna 組み込み型全文検索エンジン. http://qwik.jp/senna/FrontPageJ.html, （参照 2008-10-29）
3 Tufte, Edward R. Beautiful Evidence. Cheshire, Conn. Graphics Press, 2006.
1
2- 16 -