まだ明確な定義はない
前回は、Alexandriteが描く世界について書いた。「本のある場所」を、必要に応じてゆるやかにつなぐこと。それぞれの場所が、それぞれの役割を持ったまま、完全に孤立しない世界。
では、Alexandriteとは具体的に何なのか。
まだ明確な定義はなく、設計途中にある。実装もこれから大きく変わる。図書館業務についても、これから学ばなければならないことが多い。
個人開発者として、今の時点で見えている輪郭の記録だ。
「新しいILS」というわけではない
Alexandriteは、図書館システムとしての機能も持つ。
本を登録する。本を検索する。利用者を管理する。貸出や返却を行う。予約を受け付ける。通知を送る。職員向けの画面を用意する。
その意味で、AlexandriteはILS(Integrated Library System)としての側面を持つ。
でも、単に「新しいILS」と呼ぶと、少し違う。
個人の本棚も扱いたい。小さな私設図書館も扱いたい。研究室や会社の本棚も扱いたい。そのすべてを、同じ業務システムに押し込めたいわけではない。場所ごとに必要な機能は違う。公開範囲も違う。責任の重さも違う。
だから、今の時点ではこう捉えている。
Alexandriteは、個人の本棚から図書館まで、さまざまな「本のある場所」を扱い、必要に応じて接続するためのOSS基盤である。
ILSを作るのではなく、ILSを載せられる土台を作る
図書館システムを作るなら、まず貸出や返却を作る。予約を作る。利用者管理を作る。普通はそう考える。
でも、Alexandriteではその前に「土台」を考えたい。
本を登録できること。本の一覧を扱えること。本がどこにあるのかを表現できること。誰が何を見られるのかを制御できること。必要なら貸出管理を追加できること。必要なら外部の図書館や本棚と接続できること。
個人の本棚は図書館ではない。研究室の本棚も、公共図書館ではない。それでも、どれも「本のある場所」だ。
この共通部分をどう扱うか。そこにAlexandriteの中心がある。ILSは、その上に載る重要な機能の一つ。目的ではなく、重要な構成要素だ。
なぜILSを一つの「機能」として作るのか
Alexandriteでは、機能のまとまりをModuleと呼ぶ単位で考えようとしている。
蔵書を管理するModule。貸出を管理するModule。予約を扱うModule。通知を送るModule。検索するModule。個人の読書記録を扱うModule。外部サービスと連携するModule。
すべての場所に、すべてのModuleが必要なわけではない。
個人の本棚なら、蔵書管理と読書記録だけでよいかもしれない。研究室の本棚なら、蔵書一覧と簡単な持ち出し記録があれば十分かもしれない。地域の小さな本棚なら、公開用の一覧だけでよいかもしれない。公共図書館なら、貸出、返却、予約、利用者管理、統計、職員権限など、ずっと多くの機能が必要になる。
必要な機能が違うなら、最初から全部入りの巨大なシステムとして作るより、必要な機能を組み合わせられる構造の方が自然だ。
もちろん、Moduleに分ければ簡単になるわけではない。境界設計が必要になる。データの責任範囲を考える必要がある。Module同士の依存関係も出てくる。単純なプラグイン機構だけで済む話ではない。
それでも、個人の本棚から公共図書館までを同じ巨大な機能セットで扱うのは無理がある。だからModuleで作る。必要な場所に、必要な機能だけを載せるために。
どのようにつなぐのか
それぞれの本のある場所は、別々の運営主体を持つ。別々のルールを持つ。別々の責任を持つ。だから、すべてを一つの中央サービスに集める設計は合わない。
個人の本棚は個人のものであるべきだ。図書館の貸出記録は図書館の責任で扱われるべきだ。学校や研究室の本棚には、その場所の閉じた文脈がある。
それでも、必要なときにはつながってほしい。本を探すとき。近くにある本を見つけたいとき。ある本がどこに存在するのかを知りたいとき。
中央集権ではなく、接続の仕組みが必要になる。そこでFederationという概念が参考になる。
一つの中央サーバーにすべてを集めるのではなく、それぞれの場所が自分のデータを持ちながら、必要に応じて相互にやり取りする仕組みだ。Mastodonのような分散SNSが採用している考え方に近い。
ただし、図書館の世界にそのまま持ち込むことはできない。図書館を使う人は幅広い。子どもも、高齢者も、ITに詳しくない人もいる。「どのサーバーに所属するか」を利用者に意識させてはいけない。分散していることは設計上の重要な原則だが、利用者にとっては「ただの図書館体験」に見えなければならない。
Moduleは場所ごとの違いを受け止めるため。Federationは場所同士をつなぐため。Alexandriteではこの二つを組み合わせて考えている。
OSSとして公開したい理由
Alexandriteは、OSSとして作りたい。理由は無料で使えるようにしたいからだけではない。
仕様が見えること。データを取り出せること。必要なら自分たちで運用できること。特定の企業だけに依存しすぎないこと。こうした性質は、長く使われる基盤では大事になる。
既存の図書館システムや、それを開発・運用してきた企業を否定したいわけではない。図書館業務は複雑だ。安定運用も簡単ではない。長年支えられてきた仕組みがある。そこを軽く見てはいけない。
さらに、図書館は単に本を貸し借りする場所ではない。横断検索、相互貸借、書誌データの扱い、利用者情報の保護、著作権、電子資料、地域ごとの運用ルールなど、制度や現場の積み重ねの上に成り立っている。外から来た開発者が、技術だけで簡単に作り替えられる領域ではない。
だからこそ、閉じたまま独自に作り込むのではなく、できるだけ見える形で作りたい。間違っているところを指摘してもらえるようにしたい。図書館業務に関わってきた人、既存システムを支えてきた人、研究してきた人が、設計を読める状態にしておきたい。
そのうえで、別の選択肢もあってよいと思っている。中身を確認できる選択肢。小さく試せる選択肢。拡張できる選択肢。自分たちで運用する余地がある選択肢。そのために、OSSであることが必要になる。
SaaSも必要な理由
OSSだけでは足りない。
ソースコードが公開されていても、使えるとは限らない。サーバーを立てる必要がある。バックアップを考える必要がある。セキュリティも見なければならない。個人には重い。小さな団体にも重い。
自分で運用できる人だけが使えるOSSでは、届く範囲が狭くなる。だからSaaSも必要になる。
OSSは、自由と透明性のため。SaaSは、導入しやすさのため。この二つは矛盾しない。
自分で運用したい人は、自分で運用できる。運用を任せたい人は、SaaSを使える。最初はSaaSで試して、必要になったら自前で運用することもできる。そういう選択肢を残したい。
OSSで提供したいのは、Alexandriteの中核になる部分だ。本を扱う基本モデル、蔵書管理、Moduleを動かす仕組み、Federationに必要な基本機能、API、管理画面。基盤として必要な部分は、できるだけOSSに寄せたい。
SaaSで提供したいのは、運用を楽にする部分だ。ホスティング、バックアップ、アップデート、監視、サポート、簡単に始めるための初期設定。SaaSで売りたいのは囲い込みではなく、「運用の肩代わり」だ。ここは大事にしたい。
最初に作るもの
Alexandriteの構想は大きい。でも、最初から全部は作れない。
今考えている最初の形は、もっと小さい。個人の本棚を管理するアプリだ。
本を登録する。ISBNを読み取る。書誌情報を取得する。本の一覧を見る。外出先から自分の本棚を確認する。読書記録やメモを残す。本をコレクションに分ける。
まずは、本棚を登録する体験を気持ちよくする。高速に。迷わず。後から直せるように。完璧な入力を最初に求めないように。
この段階では、公共図書館と接続する必要はない。まずは、個人の本棚という小さな「本のある場所」を扱えるようにする。そこから、家族との共有、小さな本棚の公開、簡単な貸出管理へ広げていく。
公共図書館との接続は、その先の話になる。図書館との接続には、利用資格、個人情報、貸出記録、既存システムとの連携、責任分界点が関わる。まずは小さく作る。使ってみる。設計の無理を見つける。それから広げる。
既存ILSとの違い
大手ベンダーの提供するILSや、Koha、Evergreen、FOLIOをはじめとするOSS ILS。それぞれが長い歴史と思想を持っている。Alexandriteは、それらを置き換えるためだけに作るものではない。
一文で違いを言うなら、今はこう考えている。
既存ILSが「図書館業務を支えるシステム」だとすれば、Alexandriteは「図書館を含む、本のある場所どうしを接続するための基盤」を目指している。
もちろん、これは少し大きな言い方だ。境界はそれほど単純ではない。それでも、出発点は違う。Alexandriteは個人の本棚から始まっている。図書館だけではなく、本のある場所全体を見ている。ModuleとFederationを前提に考えている。
まだ決まっていないこと
決まっていないことは多い。
OSSのライセンスはまだ最終決定していない。MITのような寛容なライセンスが候補になるかもしれない。公共性やSaaSとの関係を考えると、AGPLのような選択肢も検討の余地がある。
Federationの実装方式も決まっていない。ActivityPubのような既存標準を使うのか。OIDCやOpenSearchのような技術を組み合わせるのか。独自プロトコルを定義するのか。できれば全部を独自に作りたくはない。既存の標準で使えるものは使いたい。その線引きを考えている。
同時に、Web技術の標準だけを見ていればよいわけでもない。図書館の世界には、MARC、BibFrame、Z39.50、OAI-PMHなど、長く使われてきた標準や仕組みがある。Alexandriteがそれらをどこまで直接扱うのか、既存システムとの連携層として扱うのか、あるいは内部モデルとは分けて変換するのかは、まだ検討が必要だ。
ここを軽く扱うと、単に新しいWebアプリを図書館に持ち込むだけになってしまう。Alexandriteでやりたいのは、既存の図書館標準を無視することではない。Webの技術と、図書館が積み重ねてきた標準や運用を、どう接続するかを考えることだ。
収益モデルもまだ決まっていない。個人向けに月額課金するのか。小さな本棚向けに低価格のプランを用意するのか。図書館や団体向けに別の料金体系を作るのか。公共性のある領域で、過度に収益を優先する見え方にはしたくない。同時に、継続できないプロジェクトになっては意味がない。ここは慎重に考えたい。
今の時点でのAlexandrite
改めて、今の時点でのAlexandriteを一言で表すならこうなる。
Alexandriteは、個人の本棚から図書館まで、さまざまな「本のある場所」を扱い、必要に応じて接続するためのOSS基盤である。
その中に、ILSとしての機能がある。個人蔵書管理としての機能もある。小さな本棚を公開する機能もある。それぞれをModuleとして作る。それぞれの場所をFederationでつなぐ。基盤はOSSとして開く。運用しやすい形としてSaaSも用意する。
まだ大きすぎる構想かもしれない。でも、最初に作るものは小さい。
自分の本棚を登録すること。自分の本を見つけやすくすること。本との関わりを記録すること。そこから始める。
考えながら、作りながら、少しずつ形にしていく。それがAlexandriteだ。
次回は、Alexandrite v0.1.0の開発記録を書く。大きな構想をいきなり完成させるのではなく、まず個人の本棚を管理する小さなアプリとして、何を作り、何を確かめようとしたのかを記録する。
前回の記事：Alexandriteが描く世界
次回の記事：最初に作るもの：個人の本棚を管理するアプリ
