先日、図書館系大物SEのOさんに、都内某所で差し向かいで講義してもらった内容をベースに、クラウド化について簡単にまとめてみた。
私なりの解釈も入っているので、全てがOさんの喋ったことではないよ、念のため。
図書館システムにおいて「クラウド」と呼ばれているものには、次の３つのパターンがある。
１ SaaS(System as a Service)
２ シェアードホスティング
３ プライベートクラウド
県などが主導して複数の自治体に参加を求め、環境を共同利用する形が多い。
システム運用にかかるコストは、１＜２＜３の順で大きくなり、システムのカスタマイズ等の自由度は３＞２＞１の順で小さくなる。
自館でサーバを持ってシステムパッケージを利用するオンプレミス(on-premises)比べて、30％程度の経費削減効果があると言われており、新規導入時の構築期間も短くて済む。
また、サーバやデータがIDCにあるので、災害による影響を受けにくい(遠隔地にあるIDC近くの災害によって回線切断が起こり、思いもかけない影響を受ける可能性はある)。
一方、サービスの内容や速度はディスク容量や接続回線の品質に依存するので、一般的に蔵書数30万冊程度以下の小規模館が対象であり、自館所蔵分以外の新刊全点MARCは利用しないことが前提となる。
更に、サーバに負荷がかかるフルテキストサーチができないなど、資料検索のクオリティは低く、貸出・返却処理が輻輳する場合の処理スピードも期待できない。
ここではあんまり関係ないけど、ソフトベンダーの現場では、SaaSばっかりになっちゃうと中央集権的になっちゃうので、地方の現場レベルのSEのスキルが相当落ちるという笑えない問題もあるらしい。
MARCは、SaaSか否かには左右されないので、各館が個別にMARC会社と契約することになり、その点でのコスト削減は望めない。
TRC/MARCはSaaSでの利用を許諾済みとの情報があるが、どのMARCを利用するにしても、「第三者のサーバにMARCデータを格納することを制限する事項」がないことを確認して契約する必要がある。
県などが共同利用環境を構築し、市町村の図書館に参加を求める事例については、次の３つのパターンがある。
Ａ：単一アプリケーションの共同利用で単一ＤＢを使用
Ｂ：単一アプリケーションの共同利用で個別ＤＢを使用
Ｃ：インフラを共同利用しアプリケーションは個別
Ａでは、書誌データの統合が必要なので、データ中に独自の項目を持っていたりすると、それが消えることを嫌がって参加しない図書館(自治体)も出てくる。
このパターンで、県立を中心として市町村立が分館的なイメージ、県下統一書誌データという世界を構築するのは美しい世界ではあり、横断検索なんて面倒なことを考える必要もなくなるが、天下統一に様々な困難が生じるのは世の常であり、実現はかなり難しい。
となると、Ｂではどうかという話になるが、単一アプリ＝天下統一という点では同じなので、困難さは変わらない。
なので、考えるべき方向としてはＣをベースとしたＡとかＢとの組み合わせなのだろうな。
小さい規模の自治体であれば、県立の書誌をベースとしても何ら困らないし、サービスも基本的なことしかやらないので、アプリも標準のやつそのままでいいです、それで経費が浮かせれば、みたいな所が多いのではなかろうか。
書誌に特別こだわりがあればＢという選択肢もあるし、そうでなければＣということで、環境は使わせてもらうけど、サービスは独自にやるからほっといてという感じか。
この時に、トータルのコストが安くなるかというと、それはケース・バイ・ケースで何とも言えない。
高速な通信回線を別途用意しなければならないとかになると、その分の費用がかかるし、どうしても百年に一度の事態に備えてデータを二重化しなきゃいけないので、二ヶ所のデータセンターでミラーリングしてちょうだいなんて言い始めると、そこそこ相当な費用がかかってしまう。
参加する自治体(図書館)が多ければ多いほど、スケールメリットが出て共通部分のコストは下がるし、個別にシステム担当を抱える人件費も不要になるとは思うので、無秩序にばらばらにやるよりは効率は良いのだろうことは明らかだが。
いくつかの県で、共同利用の計画が進みつつあるらしいので、メリット・デメリットも次第に明らかになってくるのだろう。
以上、結論にもなっていないような気がするが、期待して読んでくれた人には申し訳ない。
これ以外に、最近のOPACの動向だとか、calilのこと、代官山蔦屋書店を図書館システムとして実現するために考えなければならないいくつかのことなんて話もしたのだが、それについては、気が向いたらいつかここに書くかもしれない。
Oさん、おつきあいありがとうございました。また近いうちにHさん交えて飲みに行きましょう。