v0.1.0：試作と方向性検証
Alexandrite v0.1.0を開発した。
これは完成版ではない。できることはかなり限られている。
けれど、自分の中ではかなり大きな意味を持つバージョンになった。「本のある場所」をつなぐ前段階、見えるようにするという発想を、最初に小さく実装してみた記録だ。
最初に確かめたかったこと
v0.1.0で試したかったのは、書籍管理アプリとしての基本機能を作ることだけではない。
Alexandriteというプロジェクトが、本当に「本のある場所」を扱うための道具になり得るのか。そのために、目の前にある本をどれくらい軽く登録できる必要があるのか。その登録体験に手応えがあるのか。
v0.1.0は、その最初の手触りを確かめるためのバージョンだった。
ただし、この段階で作っているものは、図書館業務システムそのものではない。公共図書館や大学図書館で必要になる、受入、所蔵管理、分類、貸出規則、利用者管理、除籍、統計、監査といった業務は、v0.1.0で扱えているわけではない。そこには長い実務の積み重ねがあり、既存の図書館システムが担ってきた領域がある。
v0.1.0で検証したのは、その前段にある、もっと小さな入口だ。
本を登録するという壁
書籍管理アプリでは、登録作業は一冊ずつ進めることが多い。
ISBNを入力する。タイトルや著者名を確認する。保存する。次の本を登録する。
一冊や二冊なら問題ない。でも、家にある本をまとめて登録しようとすると、すぐに面倒になる。百冊、二百冊となると、登録作業そのものが大きな壁になる。
これは個人の本棚だけの問題ではない。
小さな私設図書館、地域の文庫、研究室の本棚、喫茶店の本棚。そうした場所にある本を、誰かが「ここにこんな本がある」と表明しようとしたとき、最初に立ちはだかるのが登録作業だ。
どれだけ理念があっても、どれだけ面白い本棚があっても、本がシステムの中に登録されなければ、外からは見えない。見えなければ、探すことも、出会うことも、つなぐこともできない。
だからAlexandriteでは、この登録作業の負担をできるだけ小さくしたい。
カメラを閉じないスキャン体験
v0.1.0では、ISBNをスキャンするとバックグラウンドで書誌情報を取得し、その間もスキャン画面を閉じないようにした。
本を裏向きに積む。上からスマートフォンを構える。一冊スキャンされたら、その本を横にどかす。すると、次の本のバーコードが画面に入る。また読み取られる。
この繰り返しで、かなり軽快に本を登録できる。複数のバーコードがカメラに映るようにしてもよい。順次ISBNを読み取り、バックグラウンドでAPIを呼び出し、取得できたものから一覧に追加していく。
実際に触ってみて、これはかなり重要な体験だと感じた。
なお、v0.1.0では、書誌情報の取得元としてまずopenBDを使っている。現時点では、ISBNから最低限の書誌情報を取得し、登録の流れを検証することを優先した。将来的には、国立国会図書館サーチなども含め、用途に応じて複数の書誌情報源を扱えるようにしたい。
ISBNだけでは扱えない本
一方で、ここにはすでに大きな課題も見えている。
ISBNで登録できる本だけを前提にすると、扱える本の範囲は限られてしまう。
古い本。ISBNのない本。地域資料。同人誌など。バーコードが汚れて読めない本。タイトルはわかるがISBNがわからない本。
実際の本棚には、そうした本も普通に存在している。Alexandriteが本当に「本のある場所」を扱うのであれば、ISBNのある出版物だけを対象にするわけにはいかない。
v0.1.0を触ってみて、次に必要だと感じたのは、ISBNで登録できる本と、写真だけ残しておく本を同じ登録の流れで扱えるようにすることだった。バーコードを読める本はISBNとして登録し、読めない本は写真付きの未解決アイテムとして残す。あとから、その写真を見ながら書誌情報を補ったり、既存の本に紐付けたりできるようにしたい。
最初から完璧な書誌データを作る必要はない。まずは「ここに本がある」という事実を軽く残せればよい。
ただし、これは書誌データの品質を軽視するという意味ではない。最初の登録は軽くしつつ、公開したり、他の本棚や図書館と接続したりする段階では、出典や確認状態を持ったデータとして整理していく必要がある。
登録は本の存在を表明すること
ここには、Alexandriteのかなり根本的な考え方がある。
本は、書誌データだけではない。本は、どこかに存在している。
家の棚にある。研究室にある。地域の小さな文庫にある。喫茶店の棚にある。
そして、その多くは見えない。
Alexandriteがやりたいのは、単に本のリストを作ることではない。「どこに、どんな本があるのか」を少しずつ見えるようにすることだ。
そのためには、まず本が登録されなければならない。どれだけ立派な検索機能があっても、最初に本が登録されていなければ始まらない。
だから、Alexandriteにおける本の登録は、単なるデータ入力ではない。本の存在を表明する行為だ。
v0.1.0は、その登録のハードルをどこまで下げられるかを試したバージョンだった。
本棚は見る場所でもある
v0.1.0には、大きな課題が残っている。
特に大きいのは、書影との紐付けだ。現時点では、一冊ずつ詳細画面を開いて画像をアップロードする必要があり、登録する本が多ければこの時点でリタイアする人は多いと思う。
これは単なる見た目の問題ではない。
本棚を管理したい動機の一つに、眺める楽しさがある。背表紙や表紙が並んでいるだけで、思い出すことがある。読みかけだったことを思い出す。まだ読んでいないことを思い出す。関連する別の本を手に取りたくなる。
だから、書影や本の見た目は単なる装飾ではない。本と再会するための手がかりであり、本を手に取るための入口だ。
書影を扱う難しさ
ただし、書影の扱いには慎重さが必要になる。
表紙画像には、出版社、著者、装丁者、写真家、イラストレーターなど、さまざまな権利が関わる可能性がある。外部サービスから取得した書影も、取得元ごとの利用条件に従う必要がある。
v0.1.0では、まだそこまで十分に整理できていない。
一つ考えているのは、書影が取得できない本や、権利上そのまま表示しにくい本に対して、自動生成カバーを使う方向だ。公式の表紙を再現するのではなく、Alexandrite上で本を見分けるための仮のカバーとして扱う。これなら、書影が取れない本でも本棚表示が寂しくならない。
すべてはここから始まる
Alexandriteが描いている未来から見れば、v0.1.0はとても小さなものだ。
まだ図書館とはつながっていない。まだ横断検索もない。まだ貸出も予約もない。まだ本棚を眺める体験としても不十分だ。
けれど、すべてはここから始まる。
あらゆる人が、あらゆる本棚が、「ここにこんな本がある」と表明できるようにする。そのためには、本の登録を限りなく軽くしなければならない。
v0.1.0で、その可能性を少し感じることができた。
スキャンして、本をどかす。またスキャンされる。気づくと、自分の本が画面の中に増えていく。
その体験には、思った以上に手応えがあった。まだ小さな試作だ。けれど、Alexandriteが本当に作りたいものに向かうための、最初の確かな一歩になったと思う。
次回は、Alexandriteの技術スタックについて書く。個人開発として始めながら、将来的なWeb展開やFederationまで見据えると、どのような選択になるのかを考えてみる。
前回の記事：最初に作るもの：個人の本棚を管理するアプリ
次回の記事：
