中の人にお誘いを頂きまして、3月6日に京都大学付属図書館にて「利用者中心視点からOPACのあり方を考える」というお題でお話をしてきました。

要約や感想などは同大学私設ページに書かれていますのでそちらを参照いただくとして、こちらでは当日いらしてない人向けに当日喋らせていただいたことも含めまして、なるべく内容を共有できるように内容を公開しておきます。

（なお、自己紹介部分など一部のスライドは削っております。あしからず）

スライド＆スクリプト

1枚目

えーと、さて今日は大学図書館のOPACがどうあればよいのかということについて考えていきたいと思います。

2枚目

OPACが何かというのは、この場で話すのは失礼な気さえするのですけど、一応さらっておきますと、オンライン蔵書目録のことですね。利用者がリクエストした言葉を含む資料の一覧を返して、またその各書誌の情報や配架場所・貸出状況などが確認できるサービスを指す、というのが一般的なところかと思います。

3枚目

こと今回は大学図書館のOPACで話をしようと思っているのですが、慶應大学の上田先生の集計によりますと、去年の今頃の時点でだいたい平均してみると8割弱、78.6%の大学がウェブ上でOPACを提供しているそうです。21世紀になる手前、2000年では全体の半分も無かったことから考えますと、まぁ、おおよそ普及段階にあって、かつ一般に認知されてきたと考えていいんではないかと思います。

4枚目

そんなOPACですが、どうも見直しの時期に来ているのではないのでしょうか。日本の大学についてのものでなくて恐縮なんですが、アメリカのOCLCというところがアメリカ・イギリス・オーストラリアなどの6カ国の14歳以上の人達3000人程度にインタビューを行ってみたところ、情報探索するにあたってまず検索エンジンから検索しますよと答えたのが全体の84%、図書館ウェブサイトーこれはOPACと解して問題ないかと思いますがーから調べますと答えたのは1%でした。こと、対象を大学生に絞ってみても、同じく検索エンジンからと言うのが72%, 図書館からというのが14%, 図書館ウェブサイトからというのが10%でした。信頼性や正確性では図書館の方が優れていると答えているので、図書館そのものではなくOPACに何らかの問題があるのではと考えられるわけです。

5枚目

このいわばOPAC離れ…についてより詳しい原因はこれから考察するとして、ここで背景を簡単に考えてみますと、2点あるのではと思います。まず1点目にOPACが先に行ったように普及し、一般化したことで利用層が増えた結果、例えば論文はタイトルをそのまま入れても出ないから雑誌タイトルを入れて見つけるとか、あるいは新しいトピックに関してはまだまとまった本がないことが多いから新聞・雑誌記事データベースを使いましょうとか、そういうお約束をしらないで検索して失敗するということが目立ってきているのだと思います。もちろんこれはOPAC側でなんとかするべき事だと思いますが。

そして、その利用者が面倒見の良い、例えばスペルミスを訂正してくれたり、入力語全部を含んでいなくてもあるいは自然語で検索しても適当な資料をみつけてもってきてくれるだとかそういう柔軟な検索エンジンが普及した結果、OPACとのいわば「溝」が目立っているのだと考えられます。

6枚目

その検索エンジンの利用が利用者のOPACの利用に与えている影響も観察されていまして、ある研究ではサーチエンジン使用歴が長い利用者ほど、ある特徴的な傾向が認められるそうです。1つは、OPACでも検索結果が20万件でも2000件でも、その件数を見ないで、それに関わらず、だいたい最初の1,2ページだけを見て結果を判断する、という傾向です。サーチエンジンはページ数が進めば要求した情報とは離れていくような性質があるかと思いますが、これはそうした経験をふまえての行動だと考えられます。

また、サーチエンジンに特徴的な探索パターン、例えば自然文に用いる言葉（逮捕、検挙）を利用したり、検索語を多く設定するといった行動がそのままOPACでも使われるということです。そして、結果として、検索失敗つまり一件も検索結果が出てこなかったケース、ゼロ・ヒットが多発するようになったのだと考えられます。サウスカロライナ州立大学を対象とした調査では実行した検索の過半数でゼロ・ヒット、日本の短期大学を対象とした調査では全体の3つに1つくらいでゼロ・ヒットになっていることが判明しています。

皆さんもGoogleやYahoo!で検索することがあると思いますが、例えばその時に3回に1回全く結果が出てこなかったら、イライラするのではないかなと思いますが、同じようなことがOPACに起きていると言うことでOPAC離れさもありなんという感じはします。

7枚目

さて、その見直しの動きとして、使いやすいOPACを作って図書館サービスを向上させましょうと言うことでアメリカなど諸外国で次世代OPACと呼ばれる新たなOPAC開発の動きが盛んになっています。次世代OPACって何なのですか、というと、これはいろんな答え方があるんですが、久保山先生の書かれた論文にある具体的な記述を抜粋して表にしてみますとこういう感じになります。

このように伝統的なOPACに対して次世代OPACがありまして、伝統的なOPACでは一定の検索技術、例えば同志社のOPACで1990年代の資料だけ絞り込んで欲しいという時に年代欄に199*といれれば望みの結果が得られるわけですが、そうではなくてUIを整理してダブルスライダーを使うなりして、検索スキルがなくても直感的に絞り込みができるものにしましたと。

また、検索欄も特に詳細検索はそうですが、テキストボックスがダーッとおいてあって、普段耳にしないような言葉もダーッとあってというのではなくて、もっとシンプルでわかりやすく設計されていると。

加えて、検索結果も情報を文字だけではなくて、表紙や内容など資料に関連した情報も出すようにしましたと。具体的にはこういう風に対比できるわけですね。

8枚目

で、まぁ百聞は一見にしかずと言いますので、実際に次世代OPACと言われるもの、今回はノースカロライナ州立大学図書館（以下、NCSU）のOPACについてざっと見ていきたいと思います。

これがNCSUのトップですね。ここからCatalogを選んで…

これが検索画面のトップです。NCSUに加えて（横断検索サイトを別に用意するわけではなくて）他大学を含めた検索も可能になっています。

今回、例えば選挙制度について調べてみようと思って、”election system”で検索してみました。

左側に見えるのが分類別の結果一覧ですね。図書館員の方ならよくご周知だと思いますが、本にはいろんなメタ情報が付いています。書名、著者名、出版年、書誌形態…。そのファセット―切り口と訳されますが―毎に検索結果を分類し、直感的に絞り込みが出来るようになっています。カカクコムでご覧になった方もいらっしゃるかと思います。

右側の結果一覧は、まぁ割と普通なんですが、検索語との適合度（レリバンス）で並び替えられています（アルゴリズムは不明なのですが）。タイトルがあって、著者名、出版年、形態とまぁ普通ですが、所蔵状況が見られるになっていていちいち詳細画面で確認する手間が省けますね。

さて、左側のファセット分類から件名をもうちょっと詳しく出してみました。正直、似たような件名も多くあって若干探しづらいなと思うところはあるのですが…この中から…政治への市民参加を図るためには選挙制度をどう改善したらよいかを調べようと思ってたので、”democracy”で絞り込んでみました。

それで、その中からこの本を選んでみました。タブが使われていて、それほど情報がぎゅうぎゅうに詰まっているという印象はありません。「情報が多すぎる」という批判を受け止めた結果かもしれませんね。所蔵状況には、この本は貸出中ですがいついつまでに返される予定と書かれています。

他のタブを見ていくと、目次があって、本の紹介情報があって、全体として読者が自分にこの本は合うのかどうか判断しやすくなっています。

9枚目

次世代OPACの機能は今見た機能も含めて、ファセット分類による絞り込み機能、関連語の表示、適合度による並び替え、 コメント・レビュー機能、あるいはAmazon的なリコメンド機能など様々なものが考えられます。ここに挙げたのは一例で、次世代OPACと言われるものの機能要件を網羅的に集めていくとかなりの量になるのではと思います。

10枚目

それで、ではOPACを便利にするためにはこれらの次世代OPACの機能を取り込んで、開発していけばよいのかというと、これは単純にはYESとは言えないのですね。

11枚目

それは次世代OPACを取り込もうとする際に解決しておかないといけない課題が出てくるからです。それはつまり、取り込むための根拠があるか否かです。根拠というのは利用者に便利かどうかということです。便利にするためにOPACの開発を進めるわけですから、便利で使われる機能をつけなければ無用の長物です。むしろ今までのインターフェイスになれた人の行動をただ邪魔するだけになるかもしれません。

ですから、取り込んで新たに実装しようとする機能があるならばそれが本当に使われる機能なのかということはきちんと確認しておかないといけません。そのためにはただ便利であるという以上に、利用者の行動や要求にフィットしたものであるかどうかと言うことが考えられなければならないと思います。

また、現実OPACを開発されるベンダーの人としても開発資源が無尽蔵にあるわけではないですから、この機能を重点的に開発するといった指針やプライオリティを決めないといけません。その指針は取引先の図書館や何よりも利用者へのアピールという意味でも重要になってくるわけです。

12枚目

その根拠は利用者自身の行動を観察することによって導出できるのではないかと考えています。観察に基づく改善とありますが、まず利用者が普段どういう風にOPACを使っているのか、実際の利用風景を観察することで把握します。OPAC開発に限らず、ウェブシステムの開発では開発現場では利用者はこう考えるんじゃないか、いやいやそれは難しすぎるからきっとこうするよというユーザ像議論があると聞きますが、そのような個々人の考え方でどうにでもなるゴムのようなユーザ像ではなく、実際の現場という事実をベースにして考えていくわけです。

そして、その観察から得たことを整理して、つまり各シーン毎に利用者はこういう心境にあって、だからこういう風に行動するんだというように利用者の行動を整理して、利用者の考え方にあった情報を提供することで、開発者と利用者のギャップを埋めて、使いやすいサービスを提供するというわけです。

13枚目

ちょっと抽象的な話になったので具体的な話をしますと、アメリカにIDEOというデザインコンサルトタント屋さんがありまして、ここも観察による改善をデザインプロセスに取り入れています。あるテレビ局がこの会社で特集を組みまして、曰く5日間でショッピングカートをデザインし直してみてくださいというちょっと無茶ぶり気味なお願いをしたんですね。

彼らがどうしたかというと、まずショッピングセンターに出かけて人々が買い物をする様子を観察したんです。

• レジカートを基地にして店内を駆け回っている業者の様子
• 子供が店内を駆け回っている様子
• 店内が混んでいてレジがごった返している様子
• ショッピングカートを持っていて、ノロノロした人を追い抜くときや反対側から来た人をよけるときに、カートの後輪を持ち上げる様子

そして、そうした観察を踏まえてみんなでブレインストーミングをしながら、最終的にお披露目をしたのがコレです（スライド参照）。

カートはよくあるでかいカゴが一個入るのではなく、規格サイズの小さな手提げカゴが6つ入るようになっています。どうするとかというと、買い物客はこのカートを基地にして、このカゴを持って買い物に出かけます。そしてカゴをレジに持って行って、清算後に袋に詰め替えると、さっきカゴがあったところに袋が引っかけられるようになっています。レジカートを頻繁に持って歩く必要が無くなり、カートにまつわる煩わしさが無くなったわけですね。

その他にも、レジが込んでいるときに使えるレジスキャナ、子供を座らせるチャイルドシートなど買い物に関わる様々な工夫が凝らされています。もちろん、防犯上の点などまだ考えないといけない点は残されていると思いますが、個人的にはその制作プロセスは興味深かったです。

415208426X, clear

14枚目

ところで、利用者中心にものを作る方法論としては観察だけではなく、他のことも含めて一つのプロセスとして標準化・体系化されています（これ自体を話したいわけではないのでさらっと行きますが）。

まず観察ですが、利用者が製品を使っている現場を観察できればいいのですが、あまりそうも行きませんので、どんな風に使っているか教わるためにインタビューをします。そしてそこで得たデータを元に妥当なニーズ・解決案を導き、それに基づいて即席の解決案を作ります。そしてその試作品を再度ユーザに確かめて使えるかどうかを確認します。良くなかったら試作品にフィードバックして再度テストとそういう反復プロセスになっています。今回もこの方法を用いてやってみました。

15枚目

観察についてですが、今回は同じ大学の大学生8人にインタビューをお願いしました。インタビューにあたってはなるべくOPACだけにフォーカスをあてすぎて利用行動を狭くとらえすぎないように注意して行いました。インタビューの際は、具体的に、答えやすいように「前回図書館でどういう調べ物をしましたか、できればここで再現してみてください」と尋ねて、利用風景を再現してもらいました。

それで、インタビューの内容は音声に録っていまして、終わった後に忘れないようにというのと、共有しやすくしようというので文書化（物語化＝シナリオ）しています。そのシナリオについて取り上げてみようかと思いますが、今回は時間の都合上、申し訳ないですが、一人しか紹介できません。

たいへん申し訳ないですが、インタビューは学術的な目的以外で過度に使わないようにというお約束した上で行ったこともあって、インターネット上に広く公開することはちょっとどうだろうと思いますので、シナリオについては非公開とさせていただきます。論旨に大きく関わることなので、できればお見せしたいのですが…。

16枚目

さて、こうやって利用シナリオを見てきましたが、ここからどういうことが読み取れるでしょうか。今回紹介したのは1人だけですが、できたシナリオをザーっと見てとその中でだいたい共通して見られるパターンがありまして、まず1つに「タイトルだけじゃわからない」（註：シナリオ中での発言）というところがありましたが、そのように判断材料が足りなければ棚に行って実際にその本を見てみたり、あるいはWeb上をサーチエンジンを利用して検索していたりするのです。

OPACでの情報探索というのは、欲しい文献があってそれを探して終わりという既知文献の検索だけではなくて、「このテーマについて知りたい」というような主題検索も多くあると思うのですが、その主題検索についても本を見つけてはいおしまいではなくて、まず例えばテーマ名などで検索する、すると概説書なんかが出てきてそれを読んでみる。すると、そこに自分の興味のあるジャンルのことが書かれていて、試しにそのトピックのタイトルでもう一度検索するとそのトピックに関する本がいっぱい出てくるというように本とOPACを往来しながらだんだんと求めている情報が明確化していくんですね。

17枚目

それで、そのようなパターンに近いなと思ったのが、Batesという方が仰っているベリー摘みモデル(berry picking model)です。これはウェブでの検索行動を説明するのによく使われるんですが、その行動が広い庭に散らばったベリーを見つけて、それを見つけたらまた次のベリーを見つけて拾うというように連鎖的に情報探索が進むことからこの名が付いています。

古典的な情報探索モデルは利用者は不変の情報ニーズがあって、それを検索して示すという形だったんですが、それと対照的にこのモデルでは最初は曖昧な要求なんだけれど、検索で得られた文書を読んでみて、そこで学習をしながらそれにつれて情報ニーズも具体的なものに変わっていきます。

例えば、「現代の教育問題について調べてレポートを書いてください」というレポート課題が出たとしましょう。それでとりあえず「教育問題」で検索してみて教育学の入門書を見つけましたと。読んでみると、いじめ・不登校問題、学力低下・ゆとり教育問題など様々なものがあるだろうとわかった。それで、じゃあゆとり教育に関心があるからそれをやってみようと言うことで「ゆとり教育」で本を探して読んでみると、今度は生きる力、習熟度別学習、詰め込み教育批判、総合学習とかまたいろんなものがあるとわかったと。それでそういう風に調査を進める内に最終的には「総合学習の前提となる基礎学力ってちゃんと育成できているのか」という批判があるらしいとなって、じゃあそれを考えてみようと例えばここまで具体的になるわけです。

このように探索過程でヒントを見つけながらだんだんと自分のニーズが明確になっていくというパターンがOPACでも認められると考えています。

18枚目

それで、ようやくOPACに何が必要なのかという話になってくるんですが、まず利用者がOPACを利用して図書を探す際、「タイトルだけではわからない」という声があったとおり、現状では判断材料は十分ではないと考えられます。棚に向かったり、Webを検索したりするのは判断材料を補う故での行動ではないかと考えられると思うのです。

実際に、大学生を対象にしてOPACでの探索行動を分析した調査があったんですが、ここでは結果の評価と判断は目次の情報が最も重視され、書名や件名だけでは十分ではないという報告がされています。また、冒頭にGoogleがOPAC利用に与える影響と言うことで、全体的に検索語に自然語が用いられやすいという話をしましたが、その自然語が目次によくひっかかるために検索ヒットの割合も目次の占める割合が過半数となっています。

そして、この具体策ですが、図書の目次に加えレビュー情報や内容紹介文など書籍の内容面に関わる情報を検索対象とし、また利用者に提示していく必要があるのではないかというところです。

19枚目

次に必要なのが、さきほどベリー摘みモデルということをお話ししましたが、その次のベリーにつながるようなヒントやキーワードをOPAC上で与えられないかということです。

ちょっとよくわからないと思うのでもう少し詳しく話しましょう。さきほどは教育問題を例に取りましたが、最初の「教育問題」や「ゆとり教育」についてリクエストがあった際にWikipediaの該当項目を表示して、ゆとり教育とはこういうもので、こういう流れの元に生まれてきたもので、こういう問題が指摘されていることを理解してもらうわけです。利用者はここから個別の項目について調べていくことができますし、あるいはカテゴリから上位概念である教育問題を概観することも出来ます。ちなみに、ある論文では併記という形ではなくてWikipediaの各項目間の関係を有向グラフにして整理して見せて、あるテーマにはどういう切り口があるのかつかんでもらう手がかりにしてはということも提案されていました。いずれにしろ、初期の曖昧な情報探索に対しては有効なのではと思います。

それとこれに関連して、これは心理学者が言っていることなのですが、一般に人は情報の質とは関係なく、手に入れにくい情報より持てに入れやすい情報を好むと。例えば、今レポートが出ていてOPACで本を探すんだけれども新しいトピックなのであまり出てこないと。でもたぶん新聞記事データベースだといっぱい出てくるんじゃ無かろうと。そうわかっていても、まぁ面倒くさいからOPACで見つかる本で何とかしてしまいましょう、と。

一見不合理とも思えますが、情報探索にはそうした側面もあるのですね。今回も、Wikipediaに限らないですが外部データベースの情報を併記していくことで、図書以外の論文記事などにも目を向けてもらうことが出来るはずです。

20枚目

そして最後3つ目に、検索結果に応じて利用者が情報を見つけやすいようにサポートすると言うことです。検索結果が多いときは多くが離脱するか絞り込みをするかどれかの行動を取っていたのですが、絞り込むにしても自分の情報ニーズを明確に表せるいい言葉が見つからないケースも多々あって、それがゼロ・ヒットを生むことにもなっていました。

そこで、次世代OPACの際に確認したファセット分類による絞り込み機能が使えるのではないでしょうか。ファセット分類では特にあるキーワードに関する図書のみ表示するとか、新しい年代の本のみ表示すると言ったことが割と直感的に行えるようになっていますので、それを利用してはどうかということです。まぁ、特に多い場合に限らず、使っていってもいいとは思います。

逆に結果数が少ない場合、もしくはゼロの場合は、検索がうまくいっていない可能性もありますから、例えばCiNiiやWebcatPlus連想検索などの外部データベースの情報を併記することで、結果として失敗となるクエリからある程度のものは救えるようになるのではと考えています。

ただ、これは表面的な対策であって、根本的にはやはりサーチエンジンで用いているような自然語も使えるように検索対象を広げていったり、検索語の部分的な一致でも拾ってくれるように主題検索機能を改善していったりする必要があると思います。

21枚目

細かな点を上げればこういうことは盛り込んだ方がいいというのは様々あるのですが、ひとまずご紹介するのはこれくらいにして、これをもとに試作品、プロトタイプと言いますが、それを作ってみました。プロトタイプは本番に開発する前に簡単な試作品を作ってそれをユーザに試してもらうことを繰り返しながら、本当に使えるのかどうかを確認して、致命的な誤りを早めに出すために使われます。

今回はペーパープロトタイプという紙でシステムを再現して、うまくタスクが達成できるかどうかを4回生に確かめてもらうことにしました。その時の様子をビデオに録っておいたので、5分に編集したものをお見せしたいと思います。

これも、先ほどと同様にお見せできません（ごめんなさい）。でも、一応プロトタイプは以下にお見せしておきます。結果から言えば、テストはおおむね成功でした。順繰りに検索結果を見ることなく、ファセットによる絞り込みを行い、自分の求める本（ニュートンの人物史的な本）をうまく探せたようでした。書誌についても、想定より多くの情報が示せたことに満足し、より多くの本を見てみようと探索を重ねていました。一方でメモ行為用に用意したチェックカート機能は認知されず、データベースも今回はスルーされており、本当に利用モデルにあっているのか再検討が求められまる結果となりました。

一覧画面

詳細画面

22枚目

ただ、やっぱりプロトタイプレベルだと提案としてはインパクトが薄いですし、実際に動くシステムを作って感触を確かめたいというのもあったので実際にOPACを作ってみました。

作るとは言っても、全くのフルスクラッチで作るのは時間がかかりすぎますし、データがない以上どうしようもないので、今回はデータそのものは同志社大学図書館OPACのデータ（我々が普通にOPACを利用する時に得るようなHTMLデータ）を許可を頂いた上で利用させていただいて、それを加工して新たな画面を構成する、いわば上からインターフェイスをかぶせるような手法を使いました。

以下で制作中のシステム画面を示します。なお、ファセット検索などが盛り込まれていないのはシステム制作上できないためです。

23枚目

さて、観察からのOPACの改善は一応ここまでで、最後に振り出しの疑問に戻ってOPACがどうあるべきかと言うことに関してお話しして終わりにしたいと思います。

現在のOPACは(1) リクエストされた語に対応した所蔵資料の一覧を提供し、 (2) 特定の所蔵資料の基礎情報と有りか（配置場所）を提供するという、ざっくりといえばこの主に2つのサービスを提供していますが、これだけでは利用者の情報探索には十分なものとはいえないんじゃないかというのが私の考えです。

24枚目

ベリー摘みモデルでも見ましたが、利用者は最初から明確に自分の情報ニーズがあってそれを示せるわけではなくて、むしろこの図のように探索の過程でそれを明確にしていくという過程もあったわけです。であるならば、最初に疑問を持ったところから最後にその疑問を解決するところまで、利用者が躓かないようにOPACが利用者の情報探索をもっとサポートしていくべきではないかと思うのです。

このような役割は、人力やリファレンスサービスなどの人的な面で解決を図ってきた所だと思います。もちろん、その役割を否定する意図はないのですが、それに加えてOPACがサポートできる局面もあるのではないかとも思うわけです。

そうした点からすれば、そもそも所蔵検索というシステムに疑義が発せられても良いはずです。なぜなら、利用者が求めている知識が学内に眠っているとは必ずしも言えないからです。そうした点からすれば、まずWebcatなどのデータベースで検索を行い、例えば京都大学であればその京都大学バージョンと言うことで、書誌の横に京都大学ではこれは所蔵しています、していません、これはうちにはないですが近隣の大学に置いていますとそういう風なシステムも考えられるのではないかと思います。

25枚目

まとめますと、OPACを所蔵検索だけではなくて利用者の問題解決をトータル、始めから終わりまで支援するための重要な学術環境と考えて整備していく必要があるのではないかと考えます。

IDEOではショッピング・カートの課題をこなしたあとに、「本当のイノベーションは買い物という行為をデザインしなおすことなのだ」と語られていましたが、それに倣って言うならば「OPACをあるべき姿を考えるには図書館で調べ物をするという行為をデザインし直す必要がある」のだと思います。

26枚目

はい、と、これで私の発表は以上です。多分に荒削りなところはあったかと思いますし、話せなかった点も多いかと思いますが、続いての質問やディスカッションで答えていければと思います。ご静聴ありがとうございました。

発表後の質問（一部）

頭で覚えている分なので不正確である可能性があります、あしからずご了承ください。

Q. 利用者はAmazonのレビューに違和感は受けなかったのか？また、Amazonのレビューは誰にでも投稿が出来、それを表示するのは不安ではないだろうか。

A. プロトタイプはそれほどテストを重ねていないので、あまり断定調では言えないのですけど、ごく自然にレビューに接していました。それはやはりAmazonのレビューを読んでいる人が多いからでは（推測）。それと、レビューの質についてですが、確かにAmazonは参考になるレビューも多いが、言いっぱなしのレビューも見受けられる。その選別を図りたいのであれば、例えば「30人中29人が役に立ったレビュー」のような(1) ある一定の人数に承認を受け、かつ(2) ある一定のレート以上で承認されているレビューのみを表示するようにすればいいのではないでしょうか。

Q. ファセット検索での絞り込みについて件名を表示することについてその妥当性についてどう思いますか。

A. 役に立つ局面もあるが、現状改善の必要があると思います。それは似たような用語が多いことや、曖昧な用語が多く選別には役に立ちづらいこと、「電子計算機」のような堅い件名が馴染みづらいことなどが原因ではないでしょうか。ある研究ではある検索語に対して、Wikipedia, Amazon, Google、これらネットリソースを総合して件名を抽出するというユニークな件名抽出方法が提案されていて、割とよい結果が出ているとのことでしたが、こうした研究を重ねていく必要があります。

Q. OPACではなくGoogle ブック検索を中心として、大学図書館はその所蔵状況を出すようにすればいいとの研究も出てきましたが、それについてどう思いますか。

A. 正直なところGoogleは賢いなぁと感じます。なぜなら、Google検索のように本文情報をきちんと提供しようとして、Google検索に慣れた人もシームレスに探せるようになっているようにしているからです（そういえば最近、Google検索にスカラー検索やブック検索が入り込むようになりましたね）。その点で、Googleブック検索をOPACとして捉えるというのはわからなくもない考え方なのですが、Googleブック検索が「1強」である状況で大学図書館がその選択肢を取ることは（Googleが私企業である以上は）危険なことでしょう。その選択肢が図書館サービスを向上させるとしても、そういったサービスが「3強」「4強」となって、乗り換えの選択肢が豊富に出てきたときに考慮すべきものであると思います。また、Googleブック検索では大学独自のサービス、例えばシラバスと図書詳細結果が連携するようなもの、が行いづらいのではないでしょうか。

勉強会を終えてみて

会場には図書館員の方も、それと今回はOPACベンダーの方もいらしてたのですが、次世代OPACについてはまだ模索段階で足並み揃えてという段階には時間を要しそうな印象を受けました（やってみたいけど、どうすればよいのかという段階）。せめて、同じベンダーのシステムで動いている図書館同士からでも横のつながりが強くなっていけばよいと思うのですが…。個別的に取り組みを進めていくのは難しいと感じた次第です。

ただ、私がこれを変えようにも、自分はあくまで提案レベルでしか物は言えなくて、最終的にどういう流れを作るかは現場の方達ですので、今回は原動力となる差し迫った危機感が共有してもらおうというのと、OPACのあるべき姿の探求への切り口として観察での改善ということを提案しました。勉強会中にも少し触れたのですが、もし実践をお考えなのでしたら以下でどんな感じかはつかめるかと思います。

4274201449

詳しい話は以下の本で。前者が上流工程（観察と分析）に詳しく、後者は下流工程（実装、テスト）に詳しいですね。

4797347104
4048672452

さて、ディスカッションでは、そうはいってもなかなか日々の業務に追われて余裕がない図書館（特に公共系）もあると思うので、ジョイントOPACや統合書誌目録の可能性（現状のNACSISよりもより大きな規模）についても伺ってみました。Worldcat localなんてグローバルな動きもあるそうですが、そういえばこういうのに参加するにもコストがかかるわけでどれくらいのものなのでしょうかね、聞いておけば良かったな。

ちなみに、システム自体は本当は去年末には公開予定だったんで、めちゃくちゃ公開が遅れてるんですよね。今月中になんとかβレベルでも出せるように頑張ります。あと、ユーザ中心設計（らしきもの）をやってみて疑問に思ったこと、うまくできなかったことについてはよい機会なので、それはまた別な記事にまとめてみようと思います。

反応

参加者の皆さん（やこの記事を読んだ人）が感想を書いてくれてるわけですが、みなさんとても丁寧に読み取ってくれていて恐縮します。

• システム担当ライブラリアンの日記 – 京都大学の図書系職員の勉強会
• egamiday3 – 次世代は永遠にやってくるのだ、幸にしろ不幸にしろ、というOPAC考え話。
• ウェブと図書館の狭間で – 次世代OPACに必要な視点

egamiさんが継続的な改善手法として提案を捉えてくださった点はその通りで、そこまで活かしてもらえれば御の字です。

それでじゃあまずどうするか、なんですが、えっと、ユーザテストをしていると、言及されている通りハッキリ結果が出てくるので、自分の描いたシナリオとどれくらいズレているかがよくわかるんですね（もちろん行動が理由とセットになっていて納得できるものでないとフィードバックに持って行きづらいのですが）。それで、まずはそうしたズレを感じる現状認識から始めるのがよいかなと思います。ズレは勉強会のように言葉でまとめて言っても伝わらない部分が多いですから、とっかかりとしてはショック療法的にユーザテストを体感してみるのがよいのではと。私が図書館員ならそこをひとまずのスタートにするだろうと思います。

参考：ユーザー目線を保つための、「簡易」ユーザビリティテストのススメ – Feel Like A Fallinstar

参考・引用文献

文献自体は探せばもっとあると思います（文献研究をしたい訳じゃないので、ある程度にとどめましたが）。ぐるぐるノオトやかめの歩みとライブラリアン再考を参考に探してみると良いかと。

逸村宏, 種市淳子

「短期大学図書館における情報探索行動：目次を付与したOPACのログ分析と検索実験をもとにして」『名古屋大学附属図書館研究年報』, vol.5, 2007, p.57-68.

「Webの探索行動と情報評価過程の分析」『名古屋大学附属図書館研究年報』, vol.3, 2005, p.1-11.

「大学生のサーチエンジン情報探索行動の分析：タイムサンプリング法を用いて」『名古屋大学附属図書館研究年報』, vol.4, 2006, p.1-12.

上田修一, 吉野貴庸, 石田栄美, 倉田敬子

「WWW上のOPACにおける既知事項検索の諸問題」『Library and information science』, vol.41, 1999, p.1-15.

「図書館目録利用者像の転換とOPAC」『第47回日本図書館情報学会研究大会発表要綱』, 1999.

石田栄美, 小泉公乃, 宮田洋輔, 國本千裕, 汐崎順子, 三根慎二, 倉田敬子, 上田修一

「大学生は OPAC をどのように見ているのか」『第55回日本図書館情報学会研究大会発表要綱』, 2007, p.101-104.

「画面遷移と利用者特性からみた大学生におけるOPACの閲覧」『2007年度三田図書館・情報学会研究大会』, 2007.

寺井仁

「図書館利用者の情報探索行動に関する実証的研究」『東海地区大学図書館協議会誌』, No.52, 2007, p.9-17.

松井純子, 河手太士

「図書館目録の将来設計：主題検索機能の提供を中心に（日本図書館研究会 第49回研究大会グループ研究発表）」『図書館界』, No.341, 2008, p.102-113.

工藤絵里子, 片岡真

「次世代OPACの可能性―その特徴と導入への課題―」『情報管理』Vol.51, No.7, 2008, p480-498.

久保山健

「次世代OPACを巡る動向：その機能と日本での展開」『情報の科学と技術』Vol.58, No.12, 2008, p.602-609.

増田英孝, 清田陽司, 中川裕志

「自動レファレンスサービスにむけて」『情報の科学と技術』, Vol.58, No.7, 2008, p.347-352.

越塚美加

「視点：図書館の使いやすさ」『情報管理』, Vol.47, No.5, 2004, p.358-360.

上田修一

『大学図書館OPACの動向』 http://www.slis.keio.ac.jp/~ueda/libwww/libwwwstat.html （確認：2009/3/1）

Marcia J. Bates

“THE DESIGN OF BROWSING AND BERRYPICKING TECHNIQUES FOR THE ONLINE SEARCH INTERFACE”,1989,
http://www.gseis.ucla.edu/faculty/bates/berrypicking.html （確認：2009/3/1）

スライドと著作権表記

資料内で用いた各画像は引用として用いましたが、権利は各著作権者に帰属いたします。なお、以下の画像はCreative Commonsの権利に基づき使用しました。

Office Men by DaPino

ダウンロード（PDF）

勉強会キーノート

もうちょっと言い換えると、このような場合には相手は必ずしもそのテーマに関する本を見たいのではなくて、そのテーマをばくっと理解したい、つまりテーマの見取り図を描けるようになるというか、このテーマはこういう構図になっていて、こういう事が議論されてるんですよ（以後、これをテーマ理解と言います）ということが知りたいのではないかと考えるわけです（仮説です）。

すると先の記事の潜在的な問題意識はこんな感じでしょう。利用者は結局何か問題を解決しに来ている（この場合だとテーマの理解）のだから、大学図書館の知のナビゲータ¹ であるところの蔵書検索システムが文字通り蔵書の存在と位置だけを示せば十分なのか、と。求める情報そのものを提示してもよいし、それができるシーンではそうすべきなんじゃないだろうかと。

で、あるならこの話はパスファインダーだけではなく、もうちょっとふくらみそうです。つまり、他のデータベース、Wikipediaのような百科事典では（信頼性の点から一歩引かないといけないものの）テーマそのものに対する情報が入手できますし、新書マップではテーマを理解するのに役立つ新書群が一覧でき、どういうことをおさえると良いのかわかるようになっています。テーマ理解をした後では、検索語も「洗練」されてくるかもしれません。

検索語「ユーザビリティ」に関するデータベース検索結果

なるほど、学術データベースサイトとの連携ってこういう時に必要なんですねー。いや、ARGの岡本さんも学術DBサイトのAPI公開を訴えていらっしゃるのですけど、その理由は論文を読む限りは、ブログアカデミズム的なものを花開かせるために、という感じなんですよね。ただ、「でもブログってすごいマイノリティしか書いてないんじゃ‥」と思っていて、APIが公開されると何がうれしいのかってとこがなんかわかったようなわからんような感じだったんですよ。

一応、その何が嬉しいのかってのをまとめてみると2点あって、

• 利用者のテーマ理解を助けようとする際に、単にそのテーマに関する本の存在（メタデータ）だけでなく、そのテーマに関する情報（データ）を直接扱いやすくなること
• 文献への接続点を増やして、より適切な文献をお薦めできる可能性を上げられること

というところ。

やっぱり仮説ではありますが、大学生がレポートをGoogleで検索してコピペする行動原理も、本棚行くよりウェブ見た方が早いでしょというコスト意識から生じているのかもしれません。だとすると、テーマ理解を助ける側面もOPACに持たせることで、そうした大学生の脱落を防げるのかもしれないですね。

余談。学術データベースサイトって適当に使ってますけど、一般に想像されるようなテキストやPDFを扱っているところだけではなくて、慶應SFC グローバルキャンパスや東大.TVのようなオンラインでの無料授業も同じくテーマ理解につながるという観点からその中に入れて良いと思っています。

1. 一応、これに訊いてみろ的な存在なのだからそういうことになるでしょう

• 卒論でいいところまで行けた気がする一方で、まだやりたいないところがあって開発に没頭したいのだけど、しょうもないバイト¹ とかで時間をつぶしたくない
• 他の人と交流することでもっと論を進めたい
• 自己満足じゃなくて実際に大学図書館の情報検索環境をなんとかしたい‥IPAによる広報効果に期待

このあたりがどうもこの企画の趣旨ともずれてないというか、お互い幸せになれそうだったんで応募してみたというところです。それなりに書類作成にも時間かけましたよ。

で、企画なんですが、えーと、実際のテーマ詳細説明書はパブリックに出来ないところもあるんですが、だいたいどんなものを作るのかビジュアルでわかりやすく示したシートを作ったので、替わりにこちらをご覧ください。

ページ一覧

P1. 表紙

P2. 大学生の右腕になります

「大学図書館って確かにいい本はあるんだけど探すのが面倒で‥」
そんなあなたのためにより使いやすい蔵書検索システムを考えました。本を探すときにあなたが考えていることをシステムに反映しました。例えば‥

1. 多くの利用者が選書の祭に出版年を判断基準の一つとしているので、出版年をベースに並び替え、わかりやすく表示しました
2. 大きさや厚みって本を選ぶ上で意外と重要ですよね、なぜ今までウェブ上でわからなかったのでしょう?
3. 検索キーワードだけだと検索結果もそれにあわせて平面的になりがち。検索語の連想検索結果も併せて表示しています
4. 引用表記の仕方がわからない?大丈夫、システムが面倒を見ます

P3. あなたが見ているものはウェブにありますか?

情報技術は、ぼくらが持てる情報を量的限界を飛躍的に伸ばしてくれました。しかし、ウェブであなたが必要としていた情報は本当に見つかったでしょうか?

例えば、図書館や書店に行った時に目的の本だけでなく、いろんな棚の本を読んでみて、違った切り口・着想から考えを捉え直してみる‥そんな発見を図書館の蔵書検索システムを使ったときに得られたでしょうか?

このシステムでは、そんなウェブが見失ったものを取り込んでみたいと思っています

P4. 蔵書検索システムではありません。問題解決サポートシステムです

あなたが本を探すのは、何らかの問題ー疑問、レポート..ーを解決したいからですよね。このシステムは単に図書館の本をご案内するのが目的ではありません。あなたの抱えている問題を解決するのが目的です。

ですから、まずテーマについて知らないという人のためには新書マップやWikipedia等の検索結果を見せますからそれを一通り読んでみてください。

もし、目的の本が見つかっても図書館に所蔵がないのであれば、
確実に手に入れられるように近くの図書館や書店の所蔵をお調べしましょう。

P5. ひらめきは場所を選ばない。システムも場所を選ばない

疑問やひらめきっていつも大学の中で出てくるわけではないですよね。たとえば駅のターミナルに降りたとき、友達の家で一緒に勉強しているときにふとあのテーマに関する本がないかな調べたくなったらどうしますか?

システムではGPSや地図情報などを活用しながら、いつでもどこでもひらめきを形に変えるお手伝いをしたいと考えています

申請概要

テーマのタイトル

「大学での学習・研究活動を加速させる本の検索システム」

テーマの説明

大学図書館を対象にしたこの蔵書検索システムには、従来のそれにはない2点の特長があります。

まず1点目が高いユーザビリティです。大学図書館利用者（大学生など）が蔵書検索システムを使って本を探す際には、ある一定の行動パターンというものが観察できます。例えばそれは、ここ10年くらいに発行された本を探すとか、利用状況に応じて図書の形態（新書・ハードカバーなど）から図書を探したりであるというものです。

このシステムでは、そうした検索時の行動心理を把握し、分析後ニーズとして捉えた後に、設計とユーザテストによってその問題を解決するという人間中心設計の手法を用いて、システム全体のユーザビリティを向上していきたいと考えていきます。それにより、大学生が学術研究を進めていく上での「ひっかかり」を取り除き、積極的に学術研究を行っていくための環境を整備していくことを目的にしています。

2点目は、例えばあらかじめ借りる本の目星をつけていたけど、実際に本棚に行って様々な本を見るうちに目的の本以外から参考になる情報を得るように、アナログならではの発想性や一覧性をデジタルのウェブでも実現したいと考えています。それにより、一面的になりがちなキーワード検索の問題点を乗り越えることが目標です。

また、本プロジェクトでは蔵書検索システムそのものではなく、そのユーザインタフェイスを開発することになりますが、それにより大学図書館の導入上のリスク・コストを下げることで、現状の大学図書館の情報検索環境を実際に変革していくことを考えています。

Project Shizukuとの違い

あなたが関係者の方（図書館情報学的な意味で）であれば、昨年I期の未踏ユースで採択された通称Project Shizukuと違いを気にかけておられるのではないかと思います。これについて、僕がテーマ提案書内で書いた説明ですがこんな感じです。

このプロジェクトとShizukuとの違いは以下のような点です。

1. ターゲットの違い。Shizukuが学校図書館およびその生徒を対象にしているのに対して、当プロジェクトが大学図書館およびそれを利用する大学（院）生を対象にしている点
2. 目的の違い。Shizukuは『利用者に「他の利用者とのつながりを創る」機能を提供することでコミュニティを活性化する』ことを目的にしているのに対して、当プロジェクトは「大学（院）生の学術研究の環境を整備することで、彼ら自身に良書をたくさん読んで、社会への意見を養ってもらう」ことを目的にしている点
3. 開発物の違い。Shizukuは次世代図書館システムを制作しようとしたが、当プロジェクトは次世代図書館システムにおけるユーザインターフェイスを制作しようとしている点

一方で共通点もあります。

1. アナログの感覚をデジタルに復活させようとしている点。既に述べましたが、例えば大きさ・厚みなどの本の物理的状態を示すことで、より直感的な選書が可能になります。仮想本棚の表示などアナログデータの視覚化という点ではShizukuと重なる点があり、日本十進分類法から隣にある本を表示する「おとなり本機能」など、利用者ニーズに合致する限りにおいて積極的に実現していきたいです。

応募する以上は採択されたいですが、採択されなくてもコメントをいただけるそうなので、まぁこれに関して少なくとも失敗はありません。自分がどれくらいの蛙なんかを知るのにもいい機会ですし。

えーと、いつものように何か思うところがあったら、気軽にコメントいただけると幸いです。

1次選考通過者への通知期限が過ぎました‥どうやらPMのお眼鏡に適わなかった模様。

そうか、1次選考ではコメントがいただけないのですね‥残念。就職活動もそうですが、落選原因がわからないのは結構モチベーションが下がりますね（いちいちコメントしてると大変だし、一次落ちってのはその程度のものなんだけどね）。

まぁ、どこが注目されてるか反応を見れたのでそれだけでも少しは収穫かな。プロジェクトはバイトと二足のわらじで頑張りますか。

1. 来年上京するための資金集め

iPhoneはモバイルデバイスにおけるユーザインタフェイスの発展可能性を感じさせるデバイスではありますが、疑問に思うところもあります。

まず、結論から言えばiPhoneの弱点はケータイウェブが見られないことです。この時のケータイウェブというのはNTTDoCoMo・au・Softbankモバイルの携帯電話における内蔵ブラウザで見ることができるインターネットのことですが、これがiPhoneのリアルなインターネットよりも使い勝手がよいんではないかと思う点を何点か上げておきます。

必要な情報がすぐに得られる

去年、まだ僕が就活していたときに、あるモバイル向けコンテンツ会社の説明会で「フルブラウザなどのリッチクライアントが普及していくと、オープンなウェブの中で戦いを迫られることになるから苦しくなるんじゃないか」と質問したら、「我々にはケータイ利用者がパッと情報を得られるよう、画面を最適化するノウハウがあり、それが強みである。」とお答えいただいたんですね。で、なるほどこれはケータイウェブの便利なところだと思うのです。

天気予報にしろ、乗り換え案内にしろ、あるいはGoogleのメールにしろカレンダーにしろ、既存のケータイウェブの資産はもうかなりあって、それらは携帯電話上で読みやすいよう数画面で必要な情報が得られるように最適化されていて、またUIの要素数自体があまりないのでPCウェブのようにどこで検索すれば迷うことも比較的少ないでしょう（TSUTAYA Onlineのように企業側の販促情報でできているようなところもありますけど）。

もちろん、iPhoneも技術的にはXHTML+CSSの知識があれば、最適化した画面設計をすることはできますが、大半のサイトはPCと同じ画面で見ることを要求されるので、自分の求めている情報がどこにあるのか、目を点にしながら画面を逐一探さないといけないという手間がかかります。HTML5など情報の意味がブラウザ側でより明確になれば、閲覧者の求めに応じた情報提供も可能になってくるでしょうけど、まぁまだまだ先の話でしょう。

ウェブブラウザが安定していて、信頼できる

ブラウザが勝手に終了しない（落ちない）という点です。iPhoneの場合、ブラウザが落ちるとそれだけで再起動に十数秒のロスになります（加えて直前に見たページもなくなっていたのなら、その再検索にさらに何分か必要でしょう）。乗り換え案内や天気情報などその特性上モバイルには即時性を必要とするコンテンツが多くあり、時間的なロスはデスクトップのそれよりか致命的なものとなりやすいでしょう。

僕がiPod touchを使っている時には（個人的に使い出によるでしょうけど）、だいたい3-4のタスク（ブログの閲覧だとか、はてなブックマークのリンク先を読んだりとか）に一回は落ちるんですが、こうやって勝手に終了されると、一回のタスクで下手にPCを使うことの何倍もの時間がかかることもあり、それならPCサイトブラウザで十分だよなぁと思うことが何度もあります（PCサイトブラウザを恒常的に使わないので、どこまで実用的なのかわからないところはあるんですが）

想定反論に対する再反論

ケータイウェブはお金がかかる

ちなみに、PCでは大体の情報が無料で入手できるのに対して、ケータイウェブはお金がかかる（パケット料金や課金コンテンツなど）との意見もあるかと思います。

パケット料金と課金コンテンツの話は分けて話すべきですが、まず前者に関しては「んー、そりゃiPhoneにも、むしろ携帯のそれよりお金かかってるんでないかい」でいいでしょう。後者に関しても、私はお金が必要だとは必ずしも思いません。ここでそう思うかどうかの差はおそらく情報に対して求めている水準の差なのだと思います。

つまり、GPSで目的地までナビゲーションしてもらったり、乗り換え案内で次の電車はどれくらいにくるのか調べようと思ったら、お金をサービス会社に払ってそれを得ることになります。ただ、普通に電車を乗り換えたり、一週間後の天気を見るようなよくある水準の情報に対しては無料で済ますことができます（ニュースの全文を読みたいならお金払え的な新聞各社はちょっと時代錯誤感がありますが）

さらにいえば、Yahoo!やGoogleなど広告でお金を得ていたりするモバイルコンテンツプロバイダもいますから、欲しい情報に対して必ず値札がついているという状況ではないかと思います。

ケータイウェブは簡単な情報しか出てこない

これは確かにある面ではその通りだと思います。あるコンテンツ（天気など）に対して8割が求める情報と2割が求める情報があって、欲しいのは2割の情報なのに、携帯では割愛されているなんて状況は、まだまだあります。

ですが、これは適材適所なのだと思います。狭い画面で誰でも彼でものニーズを満たそうと思って情報量をむやみに増やせば、それは回り回って8割の人の情報行動を妨げる結果にもなります。

ですから、この時はPCサイトブラウザやPCサイト変換プロキシ提供サイトなどを用いて、アクセスすればよいでしょう。もし、こうした情報しか必要ないのであれば、それはケータイウェブは適していないと言うだけのことです。

補足

いつものように補足ですが、別にiPod touch/iPhoneでのモバイルインターネットを全否定しているわけではありません。基本的なタスクがネイティブアプリケーションの充実により、快適に行えるようになれば状況も変わってくるでしょうし、それは却ってケータイウェブより使いやすく、より多くの人が求める情報行動をカバーできるようになるかもしれないですし、それはウェブ制作者として僕も望むところです。

ただ、ユーザビリティの指標における効果・効率・満足度のいずれも、ケータイウェブのそれに及ばない¹現段階では少なくとも今ケータイを持っているマジョリティに勧められるところではないと思います。

1. 満足度については意義もある人もいるかと思いますが、それはまず効果が満たせてからでしょう。人で言うなら会話が成立してからその会話が面白いのかどうか評価できるのと同じこと

たとえばセッション切れ（タイムアウト）問題

たとえば、ECサイトなどを作るときにはセッションを使いますよね。サーバ資源を有効に使うために、セッションの管理（保持しているセッションが多くなりすぎないためにセッションのタイムアウト処理をする）というのもごく一般的にされていることでしょう。しかし、ここでの処理方法って本当に正しいんでしょうか（といっても、私個人がセッション処理を実装したことがないので、経験がない分誤りがあるかもしれません。その際はご指摘お願いします）

セッションタイムアウトの例はGoogleで検索してみるといくつか見つけられます。これは、ウェブ上で買い物をしていて、ある程度の時間（30分にしているのをよく見かけます）反応がないと、今までの買い物かごが空になり、初めからやり直さなければならなくなるということです。

このセッションタイムアウト処理は、上の解説でも話したように、現実的にも技術的にも妥当な慣習である気はするのですが、果たして本当にそうなのでしょうか。

まず、インターネットはセルフ・サービスなメディアなので、「客層」は能動的に動く人に偏りますよね（『ユーザ中心ウェブサイト戦略』, p22あたり）。ECサイト、つまりウェブ上の買い物では、カートに入れてすぐにレジに持っていくような人ばかりではなくて、比較のために他の商品を見に行くような人も観察できるのではないかと思います^[要出展]。たとえば、Amazonで本を買うときにとりあえず精算の一歩手前まで来たけど、本当にこの本でいいのか、他にいい本がないのか、評判を検索してみたことはないでしょうか。

現実的には30分もカウンター前で精算を迷っていたら、「また後で」というのは至極当然ですが、遠慮不要なウェブ上では精算前に30分検索していても、特段おかしいとまでは言えないでしょう。

30分後に比較が終わって商品をレジで精算しようとしたら、買い物かごが店員に撤去されていた。買い物かごがあった場所にはそれに加えて、「セッションの有効期限が切れました。買い物を始めからやり直してください」とのメモ書きが¹ 。現実の買い物よりもお客の流動性が高いウェブで、果たしてお客さんは買い物かごにまた商品をせっせと入れ直すのでしょうか。

どう解決するか

私はこの状況を肯定できないので、解決策を考えます。セッションの有効期限を長くすると言うのはサーバの資源の問題もあって簡単に「サーバ増強で」ともいえないので、そうですね、お客さんが場を離れるときは、買い物かごに「ちょっとこの場を離れますが、購入を完全に諦めたわけではないので買い物かごはここに置いていてください」というお取り置きカードを置いてもらうのはどうでしょうか。

そうやって、明示的に購入する意志を表明してくれた利用者はセッションの有効期限を特別に長くしておきます。また、精算プロセス（発送情報の入力など）に入っている利用者もセッションの有効期限を長くしておきます。エラーでブラウザが落ちる可能性も考慮して、そういう人は特別にブラウザが終了してもセッションが無効にならないようにしておく必要もあるでしょう。

要するに、どの人にも一律に○○分と設定するのではなく、その人のサイト上での関わり具合によってセッションの有効期限を柔軟に設定する仕組みが必要ではないかなと思います（こういう処理って一般的ですか?だとしたら恥ずかしいですが‥）。

たとえば本の書影の表示方法

Amazonをはじめ、オンライン書店では、本の書影（ジャケット画像）を表示するというのはごく一般的になりました。個人的な感覚としても、モバイル版オンライン書店ですら画像が出なかったら不思議に思うくらいになりました。

でも、この書影の表示方法ってこれがベストで、これ以上改善できるところはないかと言うと全然そうではないわけです。ちょっとそれを説明しましょう。

僕らは本棚からどういう情報を得ているのか

さて、ユーザビリティの経験則（ヒューリスティック）として、実際の大きさがイメージできる商品写真を置くということが言われます。リンク先の記事では、ECサイト訪問者が家具や家電の購入を検討する際に、その製品が家の中に置くことができるかイメージをつかみたいという背景心理があるので、実際に使われている様子など大きさをイメージできる写真を掲載するといいと仰っています。

それで、この場合は家具・家電が対象になっているんですが、これは本も同じだというか、よりそうした情報が重要になると思うんですね。なぜなら本の場合、判型や厚み（ページ数）により本の内容（難易度や目的など）をある程度推定することができるからです。

えっと、論より証拠‥ですね。たとえば以下の2冊は高等教育に関する本² です。

1. 潮木 守一『世界の大学危機―新しい大学像を求めて』
2. 荒井 克弘, 橋本 昭彦『高校と大学の接続―入試選抜から教育接続へ』

これをまず単純に並べてみましょう。

次に、本の付随情報を書影画像に反映してみます。

前者と後者では、印象がだいぶ違うなと感じられたのでしたら、それは後者に本を選ぶときの重要な判断材料になりうる（と思われる）ものを加えているからです。

ちょっとこの写真を‥これは実際に棚に本を収めた写真なんですが、ここからどのような情報が読み取れるでしょうか。書名、著者名、出版社名、本の色、あるいは本の手触り‥もありますが、加えて、厚さ・高さ・書誌形態（文庫/新書/単行本、ソフトカバー/ハードカバー）も読み取れるでしょう。

そしてこうした情報によって、その本での伝え方や書いてあることが難しいか簡単かがだいたい推定できるんですね。たとえば、新書なら極度にハードルは高く設定していない、逆に専門書ならある程度の前提知識を求められると思っているのではないでしょうか。実際に、大学生に伺ってみても、レポートの締め切りまで時間がないときは新書で適当な図書を探すなど、書誌形態で本を選ぶ傾向も見られました。ですから、上述した本の大きさ、厚さ、書誌形態などの情報は本を選ぶ上で結構重要な情報で、そういう情報を半ば無意識的に本棚から得ているんですね。

しかし、翻って先ほどの検索結果から、僕らはこうした情報を得られるでしょうか。書影画像はだいたい似たような高さで、ペラペラな画像として表現されています。もちろん、本の詳細（個別）画面からそれらを文字情報として確認することはできます。

しかし、であるよりも一覧画面でそれが確認できた方がより直感的なのは間違いないでしょう（それが現実の情報行動なのですから）。現在制作中の図書館蔵書検索システムでは、こうした考察を反映したものにしています。

編集後記

紙面の関係上³ 、今回、いろいろ思った中の一例をまとめました。総じて、リアル店舗で行ったらハテナと思われるようなことが、ウェブ上ではほいほいまかり通っているのはいつも疑問に思います。

啓蒙というのは苦手なので⁴ 、個人の考え方、あるいは「そうあってほしい論」にとどめますが、ウェブを作る人間としてウェブで何か作るにあたっては、そのサービスを利用する人がどういう人なのかを考えてサービスするのは当然として、加えて現実での類似行動に照らしてみて、おかしいところはないのか。またインターネットという媒体の性質を考慮すると、この行動は妥当といえるのか、をクリアにしてからだろうと思います（といっても、設計による解決策からじゃなく、使っている人の利用状況をきちんとわかってからじゃないと=コミュニケーションを取る上で相手が誰なのか知ることが必要だろうと一応注釈しておきます）。

1. 図書館情報学をかじってない人に「機関リポジトリから論文をダウンロードできます」と言うようなものですね
2. 子細な分類になると全然違うんですが
3. あんまり長いと誰も読まないので
4. 正確には啓蒙のやり方にもいろいろ方法があるんじゃないかということです

PDFファイルは昔からブラウザ上の表示には難がありました。動作が重く、ブラウザを固まらせたり、ブラウザ側のコントロールGUIを全く別のものにすげ替えてしまったり…。詳しいところはニールセン氏のコラムに譲りますが、そのせいでPDFファイルにリンクを張るのをためらうこともあります。読み手としても「詳細はPDFで」なんて言われたら面倒くさくなってタブを閉じる人もいるでしょう。

これに対する対策として、ニールセン氏は要約を記したゲートウェイ・ページを用意しておこうと仰っているのですが、これでは不十分でしょう。というのは、これはあくまで「ショック」を和らげるだけでしかなく、先のリンク先で挙げたユーザビリティ問題が棚上げされているからです¹

彼の言うようにPDFが印刷物に合わせたテキストである以上、問題の完全な解決は難しいかと思いますが、一方で解決できる問題も結構あるんじゃないか、ということで今回試しに作ってみたのがオンラインPDFリーダです。

えっと、じゃデモとして試しに適当なPDFを表示してみましょう…。最近読んだ図書館蔵書検索の論文PDFにしましょうか。

ウェブページを普通に表示するときほど可読性は良くないのですが、それでもいくつかの問題は解決できてるんじゃないでしょうか。

ブラウザが固まってしまう問題

変換に時間がかかることはあっても、固まることはないでしょう(巨大なファイルを一気に変換しようとしない限り)

ブラウザ側のコントロールをすげ替えられてしまう問題

言うに及ばず。

検索できない問題

内容からテキストを抜き出して掲載しているので、ブラウザ標準の検索機能で検索できるようになっています。試しに先のPDFで「とりすぎず」で検索してみてください。

コンテンツの単位が大きすぎて、部分部分にリンクを張れない問題

ページ指定が出来るので、ページの一部分だけをウェブページとして抽出することが出来ます。例えば、3ページ目だけとか3ページ目から10ページ目までという表示方法ができます。

大きさも3段階で変えることができます。「小さい」はざっと全体を眺める場合、「普通」は通常のプレビューとして、「大きい」はPDFをブラウザ上で全部読みたい場合に向いています。

なお、動作としてページ指定が無い場合は最初の5ページ(PDFが5ページ未満の場合、そのページ数だけ)だけ表示しています。これは全ページを変換してしまうと処理時間がかかりすぎてしまうためです。これについては、今後ページを少し読み込んでおいて、後から動的に追加していくことで、体感速度を早くしていこうと思っています。

汎用PDFゲートウェイとしてオンラインPDFリーダを使う

と、ここまで書いてからPdfMeNot.comというほとんど同じサービスがあることに気づきましたorz(ただ、こちらはFlashを使っていて検索ができないほか、拡張子にPDFが付いていない場合はPDFとして認識されないようです)

さて、こちらのサービスではブックマークレットやブロガー向けのPDFリンク書き換えスクリプトなどサービスを汎用PDFゲートウェイとして使えるようなツールを提供しているようなのですが、私もそれに倣ってみることにします(コードが短いので、ある程度参考にさせていただきました)

ウェブ利用者向け

GreaseMonkeyスクリプト

FirefoxブラウザでGreasemonkeyアドオンがインストールされている場合、以下のスクリプトをインストールすることで、リンク先末尾に「.pdf」が付くリンクを自動的にオンラインPDFリーダーへのそれに変換します。

GreaseMonkeyスクリプト

ブックマークレット

リンク先末尾に「.pdf」が付くリンクをオンラインPDFリーダーへのそれに変換します。ご使用の際は、まず以下のリンクをブックマークに入れてください。その後は、そのブックマークをクリックするとご使用いただけます。

ブックマークレット

ウェブ制作者向け

以下のタグを <head>タグ内に書き込むことで、リンク先末尾に「.pdf」が付くリンクをオンラインPDFリーダーへのそれに自動的に変換します。

HTMLソースコード

<script src="http://pdf.openvista.jp/pdfconvert.js" type="text/javascript" charset="utf-8"></script>

その他の情報

URLの構成

オンラインPDFリーダのURLは以下のようなルールで出来ています。

http://pdf.openvista.jp/[サイズ]/[ページ指定]/[PDFのURL]

サイズ

省略可。small(小さい), medium(普通), large(大きい)のいずれか

ページ指定

省略可(その場合は最初の5ページを表示)。p1のような感じでページを表示ページを指定できる。p1-5といったように複数ページを指定することも出来る。

PDFのURL

必須。PDFのURLを指定してください。

更新履歴

2009-01-20

最新のPDFファイルを取得し直す機能を追加

キャッシュしたPDFを検索エンジンが取得しないように設定

2008-10-20

フォントをより美しいものに差し替えました

表示サイズをより大きくしました

2008-10-18

一部のPDFにおいて文字が表示できない問題を解消しました

2008-10-12

使用するPDF表示ライブラリを変更の副作用で、一部のPDFファイルが検索できるようになりました

2008-10-11

初リリース

実装予定の機能

• Googleブック検索ライクな埋め込みプレーヤーの提供
• ページの動的追加

参考にしたリンク

今回のサービスはXpdfPopplerというオープンソースのPDFリーダライブラリを利用させていただきました。素晴らしいライブラリを作られた作者さんに感謝。

いいかも。ただpopplerじゃなくてxpdfなのは何故なんだぜまあxpdfも「終わった」わけじゃないのかもしらんが

id:ttamoさんのブックマーク

それは単に知らなかっただけですよ。試しに変えてみたら、コピー不可のPDFファイルも表示できるようになったのでこちらにしておきます。

• チュートリアル/PDFの操作 – MyTeXpert
• pdftoppm – MyTeXpert
• 「PDF をダウンロードさせる」@水無月ばけらのえび日記
• 渋谷でサボるエンジニアの日記» ブログアーカイブ » サーバー上でPDFをHTMLに変換する

謝辞

以下のサイトからアイコンをお借りしました

• Mayosoft® Studios
• DryIcons | Free Icons | Aesthetica 2.0 Icon Set

1. 「最善は善の敵」という現場のコストを考えた彼の主張の一貫性には納得していますが

1. 目指すところは本のGoogle先生
2. OPACの問題点
   1. なぜOPACを問題にするのかーなぜ本を読むとよいのか
   2. OPACのどこが問題か
3. プロジェクト定義

9784797347104, caption

ご無沙汰になってしまいましたが、図書館の蔵書検索システムの話。次世代OPACってなんだろうという記事では、次世代OPACの機能要件を全集合として幾多挙げてみたのですが、もちろんこれを全部実装するというわけにはいきませんし、できません。

まず、そうした機能要件から出発するのではなく、現在のOPACの問題でどう解決したいかということをきちんと決めておかないといけません。このデザイン活動における問題の定義について、棚橋さんは『ペルソナ作って、それからどうするの?』の中で、次のように書いています（p188-192.）。

1. 問題を発見し、それを解決することがデザイン活動の意義である以上、全てのデザインは問題を発見（=定義）することから始まる
2. ユーザビリティやユーザエクスペリエンスなど、ユーザ中心視点でデザインを行いたいならば、当然その問題も（資料請求数を増やすなどの）ビジネス視点ではなく、ユーザ視点（=ユーザにとっての有用性¹ ）で定義される必要がある
3. ユーザ視点で問題を定義するならば、当然問題はユーザの現実の生活や仕事の現場から見いださなくてはならない。
4. 問題をどう定義するかは、哲学の問題。哲学とは人々の暮らしや仕事がどうあればよいか、どうあるのが望ましいか（=あるべき姿）についての考え。ユーザ視点での問題の定義にはこの哲学が必要となる。
5. このあるべき姿と今ある現実とのギャップを把握し、そのギャップを埋めるために必要となる具体策がビジョンとなる

というわけで、前の記事とやや繰り返しのようになるところがあるかもしれませんが、私の考える「あるべき姿」を書いておきたいと思います。

目指すところは本のGoogle先生

私達は本を探す手段はたくさん用意されています。つまり、地元の本屋さんや公共図書館、大学図書館、あるいはネット上の書店などいろんなところで本を手に入れることが出来るわけです。そして、そのいずれにおいても（部分的ではあるけども）ネット上で在庫の有無が調べられるようになっています。

今は人間がOPACを探して在庫を調べたり、実際に足を運んでみたりして探しているわけだけど、これを機械が自動的に調べてくれればもっと早く目的の本が手に入れられるようになるのではないでしょうか。

求めている本の場合だけであればそれはちょっとしたスピードアップですが、それだけではなくて現実の書店で本を探しているときに得られる発見、「あれ、こんな本も出てるんだ、どんなのだろ」とか「これ知らなかったけど意外と良い本かも」といったような検索志向だと見つからない発見も一緒に得られるような本のナビゲータ、今風に言うなら本のGoogle先生² を作りたいと思っています。

本屋や図書館を足で回っていると前者のスピードはどうしても落ちてしまいますが先のように道草を食いながらの新たな発見があります。一方でオンラインでの本の検索では求めている本は瞬時に出せるけど、頭の中にある本以外は出てこないと言ったような（目先の効率性と発想力との）トレードオフの問題が出てきます。

この両者をできるだけ犠牲にしないような「効率的な」³ 本のナビゲータで、みなさんの血肉となっていくような（みなさんそれぞれの）よい本を見つけていってほしいと考えています。まとめて「よい読書生活をおくるためのツール」と言ってしまうとちょっと曖昧模糊となっちゃいますね。

OPACの問題点

なぜOPACを問題にするのかーなぜ本を読むとよいのか

はい。で、このあるべき姿を書いた次に、どうして大学図書館のOPACに焦点を当てるのか。それはもっと私が大学が本を読むいい機会だと考えていて、そのために大学図書館のOPACをより便利なツールにしたいと考えているからです。以下、少し長々とした理由になるので読みたい方は読んでください。

まず、大学というのは社会人になる一歩手前のモラトリアンが社会に対しての考えを固めるよい機会だと思います⁴ 。高校までが正解探しゲームであるなら、大学以降は自分という文脈と目の前の問題から答え≠正解を導き出すことで自分の考えと考え方を固めていく時と行えるのではないかと思います。

しかし、NHKでも取り上げられたレポートコピペ問題⁵ を見るにつけ、考えること=面倒くさいという風潮が流布しているようにも思えます。

考えるというのは確かに頭が疲れるという意味では面倒なことかもしれませんが、例えば考えること以外にもスポーツを続ける内にその上達のコツを発見したり、友達と映画を見た後に感想を話していると隠れた演出の意図を発見して感心したりと、新たに何かを発見することはなかなか面白いことです。ただ、その発見も記憶の引き出しがなければなかなか得にくいものです。

引き出しを増やすと言う意味では、ウェブにはいろんな知識が転がっています。が、それこそ同じ物が入っている引き出しを何度もつけてしまったり、引き出しがあっても中身がなかったりと広く引き出しを付けていくには向いていないかもしれません。一方で本を読むというのも一つの手段です。精神論や既知の事しか書いていない本でなければ、しっかりとした引き出しを作るよい手段になります。

えーと、読書に関する授業の小レポート⁶ のようですが、要するに最初に言ったように本を読むためにもっとOPACが便利になったらいいなと言うことです。

OPACのどこが問題か

私が問題だと思っている点は主に3つあります。

1. 検索が大学図書館内に閉じていること
2. 検索結果に工夫が足りないこと
3. 他のデータベースとのつながりが見られないこと

まず1つにOPACが大学図書館内に閉じているというところです。未所蔵の場合、情報学研究所のデータベース（NACSIS Webcat）を使って他大学の所蔵を検索することは出来ますが、それも大学図書館に閉じています。利用者は図書館で入手したいのではなく、本が入手できればよいのですから、公共図書館や他の書店などにも手を伸ばしていくという方策は当然考えられるはずです。

考え方としては誰がではなく、利用者の問題を解決することが第一というのが元になっています

次に検索結果の表示にあまり工夫が見られないことです。私が一般の大学生をターゲットにして行った調査では、数多くの大学生は検索結果から目的の本をリストアップする過程において、過去数年間に発行された資料・ページ数が厚すぎない資料を重点的にリストアップし、それ以外の資料を除外する傾向が見られます。それはそうした古い本はせっかくまとめられた内容も古く、現在にそぐわないこと（今では既に自明のことが扱われているなど）があるからです。検索効率⁷ を考えれば、読まれやすい本を上位に置いておくほうがよいでしょう（ちなみにこれ以外にも数多くの共通した検索行動やそれを裏打ちする心理が観察できるのですが、それはまた別の機会に）

3つめに問題だと思うのは新聞・雑誌記事データベースなどの大学生だからこそ使える有用なデータベースとのつながりがほとんど皆無であることです。例えば、比較的勉強方法に熟達している大学生を調査してみると、新しくまだ本にまとめられていないトピックについてはOPACにかけても検索結果が乏しいので代わりに雑誌・新聞記事データベースを使うといった適材適所の使い分けをうまく行っているのですが、そうしたデータベースの存在を知らず、右往左往している大学生が多くいるのもまた事実でした。そうしたデータベースを知らずとも、多くの学生はOPACは使うのですから、こういう問題はOPACの設計次第で解決可能なものです。ですから、「図書館利用教育」とか「情報リテラシー教育」という名目で曖昧にするのは危険なことだと感じます。

そして、先に書きましたが検索志向ゆえにおこる閉じた探索方法こそが第4の問題です。

さて、ここまで書いて気づいたのですが、OPACというのはOnline Public Access Catalogの略、すなわちオンライン公共蔵書目録のことです。私が蔵書に限らず、利用者の求めたい、求めているはずの本を見つける検索エンジンを志向するのならば、それはもはやOPACではないはずです（適した資料が図書館にあるとは限りませんから）。これからはOPAC 2.0などと流行言葉を使わず、本の検索エンジンと言ってしまった方がいいのかもしれませんね。

プロジェクト定義

さて、今回考えたことを、最後に先に挙げた棚橋さんの本の中で挙げられているプロジェクト定義書の例（p.198.）に従って、まとまったドキュメントにしておこうと思います（ちょっと論文調になりますよ）

プロジェクトの目的（哲学）

大学生が本の探索する過程においては、様々な問題が存在する。特に学生の資料検索の中心になっているであろうOPACには、ウェブ上の検索エンジンが日々改良されるのとは対照的に多くの課題が伺える。

具体的な問題の検討に移ろう。まず第一に検索の範囲は文字通り当該図書館内あるいは他の大学図書館になっているのだが、実際には本は書店など様々なところでも入手可能であり、彼らの情報探索ニーズを掴み損ねる危険性がある。第二に彼らの検索行動には新しく出版された本を重視するなど一定の行動パターンが観察できるが、現在のOPACには検索結果にはそうした工夫が活かされていないものが多い。第三に雑誌・新聞記事など大学では実際の資料にアクセスできる貴重なデータベースと接続しているだが、それは「使い分け」を知らない学生には手が届いていない現状があり、OPAC側での工夫が求められる。最後に現在のキーワード型検索自体の問題点として、指定したキーワードに関連した資料を得ることが難しく⁸ 、情報探索の視点を広げていくような提案が必要である。

私はOPACのあるべき姿として、これらの問題を解決し、図書館に限らず目的としているような資料を効率的に探す手段にしたいと考えている。それにより、より時間を資料の検討に割いてもらい、彼らの血肉となるような本をより多く消化していってもらえるのではないかと考えている。

なお、このOPACは決して「勉強専用」のものではなく、小説やライトノベルなど広く彼らの読書生活をサポートするツールにしたいと考えている。

プロジェクトのゴール（ビジョン）

先に書いたように、OPACが脱OPAC（脱館内所蔵検索）を志向しているならば当該図書館の本の貸し出し冊数や来館者数の増減でその成果を図ることは難しい。また、OPACへアクセスしたユニークユーザ数も比較する基準がなく、同様に難しく、仮に設定しても裏付けの薄い数値となり目安として意味のあるものとなるかは疑問である。

そこで今回は、幾人かに実際に課題を課した上で資料調査の手段としてOPACを使ってもらい、その場合と従来のOPACを用いた場合とを相互に主観的定量化を行ってもらう。そして、その値が従来のOPACを上回っているという条件をこのプロジェクトのひとまずのゴールとしたい。期間の都合上、正式な計測は難しいが、継続的に利用状況を伺っていきたいとも思っている。

ターゲットユーザ

大学生から大学院生。特にまだ図書館やOPACに比較的不慣れな大学1-2回生をより重視したい。

まず大学1-2回生の想定ユーザ像について。彼らは初年次教育によりレポートの書き方や調べ方など基礎的な図書館利用教育を受けているとは思うが、実際にはまだ数本のレポートをこなしたり、授業の参考にするためにOPACをたまに利用する程度であろう。よって、基礎的なOPACの使い方は習熟しているが、データベースの使い分けなどはまだ難しく、時にGoogleやYahoo!などの一般の検索エンジンを頼ってしまい、考えがなかなか深まらないことも多いと思われる。

次に大学3-4回生の想定ユーザ像について。演習科目などをこなす日々が続き、指導教授からの指導やまた蔵書検索での限界も感じていたこともあり、論文・雑誌記事データベースを使う癖が徐々に身についていくと考えられる。3回生がサークルの執行を行うところもあり、また就職活動も3回生の秋口から冬にかけて本格化することから、3-4回生の中頃においては本を読む機会が限られていくことが考えられる。逆に4回生は順調に就職活動を終えた者、および卒業論文制作を本格化する者が増えることから本を読む機会が増えていくものと考えられる。

最後に大学院生の想定ユーザ像について。大学教授にも共通することだが、その研究分野の棚に並んでいる本や著者は大方把握しており、OPACを書籍検索ツールとしてだけでなく、新しい本があるか検索するツールとしても利用していると考えられる。論文・新聞記事データベースは日常的に利用しているが、研究分野に従って特定のデータベースに偏っていることも考えられる。教授などから薦められた本を借りることが多い。

実現の方法

OPACのUIの開発および全国の図書館・書店を網羅するデータベース制作作業をPHP言語によって行う。その際、効率的な開発のためにフレームワークとしてCakePHPを採用する。

近隣の図書館蔵書の検索にはWebcat Plus 一致検索および独自に開発した図書館データベースを、書店の在庫検索には書店在庫検索サービスを利用する。また、発見を得るためにはWebcat Plus 連想検索などの連想検索結果や想-IMAGINE Book Searchなどの複数の検索結果を比較検討する手法を検討したい。

制約条件

期間の都合上、実際のOPACシステムを作ることはできないので、OPACシステムを利用するUI部分を設計することになる

1. ヤコブ・ニールセンのSmall usabilityに対置されるところのutility
2. 正確には目的としているものは雑誌かもしれないので文献のGoogle先生と言わないといけないんですが、響きで萎えちゃいます
3. 効率的とは早く目的の知識を探すことでは必ずしもないでしょう
4. というのは大学を持ち上げすぎかもしれませんが、少なくとも私にとって大学以前と以後での社会観は大きく変わりました
5. 特集自体はあまりいいものとは思えませんでしたが
6. コピペする人はこのブログのライセンスに従って、URLを入れておいてくださいね
7. もちろん効率が全てではありませんが
8. 引用文献を根掘り葉掘り辿っていくなどある程度リテラシーのある学生においてはこの限りではないが、そうしたリテラシー教育をこの研究では前提にしない

どうやって「一般人」をわかるのか

「わかっている人」によって考えられた「これがニーズだろう」という思いこみをベースにしたような開発志向の手法では、一般人を理解しようとするのは困難です。ですので、そのようなアイデアありきではなく、まずターゲットする一般人が日常的にウェブにおいてどういう行動・利用をしているのか把握するところから始めないといけないよねということを述べました。アイデア発ではなくユーザ発で考えるという感じでしょうか。

マーケティングはこの辺、理論と数字によって一般人を理解しようとしていると感じるのですが（もちろん、それも重要ではあって一概に否定するわけではないですが）、どうもそこからは「一般人」の実際の利用シナリオは具体的には浮かび上がってきません。

4274201449,caption

そこで、ユーザ中心設計という方法を用います。ユーザ中心設計手法（UCD）はユーザの利用状況に注目し、観察し、それに基づいて解決策を提示しながら改善を図るプロセスです。

樽本氏の『ユーザビリティエンジニアリング』という本では、このユーザ中心設計手法のポイントの1つとしてユーザの参加を挙げています。

ユーザの参加

ユーザの視点で考える場合に”想像上”のユーザの視点では無意味です。それでは、従来の設計となんら変わりはありません。そこで、ユーザ中心設計のインタビューやテストには、必ず”本物”のユーザに参加してもらいます。

樽本 徹也『ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック』

ユーザ中心設計（正確には人間中心設計）はISO13407で定義されていますが、具体的なプロセスはこんな図で説明されます。

先の”本物”のユーザに参加してもらうユーザ中心設計のインタビューやテストというのは、この図で言う「ユーザ調査」や「ユーザビリティ評価」の段階で行う手法にあたります¹ 。

例えば「ユーザ調査」ですが、これはインタビューを行ったり、アンケートをとったりするわけではありません。そうした手法は様々な観点からあてにならないということが言われていて、実際それを役に立つツールにするためには結構な経験が必要になるようです。ではなく、むしろユーザの行動を観察することによって、その利用状況をあぶり出すというのがユーザ調査の本質です。

具体的にはコンテキスト調査法などの手法が使われますが、詳しくは無料公開されている件の本の第1章² や棚橋さんの記事などで確認できます。

UCDの実践にあたって

ただ実際のところ、未経験な人がいきなりこれをできるかというと少し留保をつけざるを得ません。

というのも、こうしたユーザ設計手法を行う上で必要な経験やノウハウ、あるいは根底にある考え方が（日本の）ウェブや私たちにまだ蓄積されていないと感じるからです。

例えば、先のユーザの利用状況を調査するコンテキスト調査にしても、生データを得るのが目的であるのにそれを要約してしまうとか、あるいはその調査の意図を鑑みないで手法ありきで行ってしまったがために質問方法自体がまずく、役に立たない生データを量産しちゃったり。ユーザテストなんかでも同じ事は起こりえますね（参考：ユーザーテストはこうやります、およびユーザーテストはテスト設計が大事）。

考え方が浸透していなかったり、経験が蓄積していないがゆえに結果の善し悪しに非常にバラツキのある手法になってしまう。これが実際に役に立つようなユーザデータを生み出すことが難しくなっている要因なのではないかなと思います。

それゆえに体系だったUCDの手法は一部の専門家が行うものになってしまって、私たちはヒューリスティック評価手法のようなプロの一般論をありがたがるくらいしかできない、そんな状況があるように思います。

最初はみんな初心者

4501532009,caption

とはいえ、それで終わっていては何の進展もありません。

最高は適切の敵であるという言葉があります。ユーザビリティ工学の先達であるヤコブ・ニールセン氏が著書の中で、最高・最善（専門家の求める厳密な手法など）を求めるとコストが高くなって取るべき方法が無くなってしまう状況を憂慮して引いた言葉です（ニールセン氏はこういう現実的な話し方が非常に上手な方です）。

ですので、トライ&エラーを重ねつつ習得していくしかないでしょう。

先に挙げたユーザ調査法である「コンテキスト調査法」ですが、具体的には以下のようになっています。

（略）インタビューアが弟子、ユーザが師匠となって、師匠の体験を弟子に”継承”しようとします。基本プロセスは以下のようになります。

1. インタビューアはユーザに”弟子入り”する。
2. ユーザ（師匠）は仕事を見せながら説明する。
3. インタビューア（弟子）は、不明な点があればその場でどんどん質問する。
4. ひと通り話を聞いたら、インタビューア（弟子）は理解した内容をユーザ（師匠）に話して、間違っていないかどうかチェックしてもらう

（略）

この手法の最大のポイントは、ユーザが”教える”つもりになることです。いったん教えるつもりになれば、ユーザは結論だけを話すのではなく、自分の体験を始めから終わりまで、なるべく順序立てて詳しく説明してくれます（実際には、話の順序が入れ替わったり、途中が抜けたりするので、インタビューアが適切な質問をして補正する必要があります）。

樽本 徹也『ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック』 p.28-29

この時の基本テクニックとして、樽本氏は3つのポイントを挙げています。

教えを請う

何を教えて欲しいのかハッキリさせて、ユーザに伝える。正確にはだんだんとフォーカスを絞るという感じ

根掘り葉掘り

ユーザの行動がはっきり理解できるように、またその行動に自分の憶測・解釈を交えないために、少しでもわからないところがあったらそのままにせずきちんと質問する

確認する

誤解しないためにもユーザにその理解した内容をきちんと確認する

例えば、学生の人であれば身近な人（「一般人」的な友達）と話すときに、この手法をこっそり用いて、どんな利用形態をしているのか観察してみてはいかがでしょうか。そこから何か新たな知見が得られるのではないかと思います。

おまけ

とはいえ、僕自身それほどこうした手法に精通しているわけではありません。むしろ今も、本当にこの手法を行っていけばわかるのかどうか確認しつつという感じです。

このユーザ中心設計というのはウェブデザインに限らず、もっと大きいくくりで考えたほうが良い気がして、最近はこの本を読んでいます。すぐにとはいきませんけど、この本を読んで発見したことがまとまったらまたレビューとしてまとめたいと思います。

9784797347104,clear

ちなみに以前に次世代OPACの話をしましたが、これもアイデアありきの開発志向で突っ走ってしまうような気がして、今見直し中です。うーん、ウェブサービスってちゃんと考えてみると大変だなぁ。

関連エントリ

• ウェブユーザビリティについて考え始めたい人にオススメのウェブページ集
• ウェブユーザビリティについて考え始めたい人にオススメの5冊
• 高齢者のサポート無くしてネットに将来はないんじゃないかな

1. もちろん、わかりやすくいっているだけで、その他の段階でユーザが登場しないと言うことではありません。その他のプロセスでも必要によって、ユーザを登場させて調査・評価・ニーズの探索などをする必要があるでしょう
2. 具体的な手法が展開されているのは2章なんですが

そのためにMaking OPAC 2.0なんてシリーズネタも書いているんですが、えーと、まず次世代のOPACとは何なのかということをまだ整理できていなかったですので、整理がてら書いておきます。

まず、世の大学図書館系ブログでは期せずして最近このOPACネタが少し言及されていたりして、例えばこんな話。

書籍に限らず情報収集するのには、まずGoogleさんをひきます。理由、そっちのほうが情報が網羅的だから。

それが、学内にあろうが、学外にあろうが、書店にあろうが、ネットに流れてようが、最終的に入手できりゃそれでいいんであって、とりあえずはまず、何がこの世に存在してるかを、端からつつっと並べてみろよ、ここへよ。
と魚屋の客みたいなことを言いたくなってしまうのは、「書誌をひく→所蔵を知る」という流れからしてみれば、当然のことと言えるかもしれないですが、さあじゃあこうなってくると、どんなにがんばったって所詮は単館所蔵データベースでしかない図書館目録さんの、いったいどこに勝ち目があるんだろう、ていう話になってきてしまうわけですよ。

egamiday3: loser – 負け続ける図書館目録

なんてな、ウェブが便利になったからもう大学図書館のOPACって役に立たなくなったよね、みたいな話はよく聞くところで、千葉大の竹内さんやとか)) と言ってます。

かくいう私も引用主の仰っていることが研究動機でして、どうにも利用品質が悪く、利用者の情報探索要求に応えきれていない感のあるOPACを何とかしたいと前から常々思っておりました。

ハイ。で、閑話休題。話を戻して、OPAC 2.0もとい次世代OPACに求められる要素ってなんだって話ですね。少し頭の中を整理してみて書き連ねてみました。図書館情報学徒としては結構な素人ですので間違いもあるかと思いますが、その際はコメントでお知らせいただけると幸いです。

次世代OPACに求められる要素

他の図書館・書店・ウェブサービスとの連携

個人的な重要度

★★★★★

例えば、竹内さんの論文ではamazonが成功した要因の一つとして、マーケットプレイスなど中古商品も豊富に取りそろえて収録範囲を広げることで、amazonに行けば何かあるという利用者の期待に答えることに成功したからと答えています。

これと同様に、OPACでも利用者がそこで本を求めている以上、たとえ図書館に本が無くてもここにいけば入手できるよと指し示すことがOPACに求められる役割ではないでしょうか。OPACが単なる単館所蔵データベースで閉じている限りにおいては、こうした期待に応えることは出来ません。それ以前に、大学図書館であればその大学を卒業すれば用済みになるようなところではなく、生涯ずっと使える存在として役割を考え直す必要があるかと思います。

よって、他の図書館や書店あるいはオンライン書店などと緊密に連携を取っていくことで、利用者の情報探索要求に誠実に答えることこそ、まずOPACが前提として持っておかなければならないところなのではないかと思います。

より精度の高い検索機能

個人的な重要度

★★★★☆

検索エンジンの利便性は発展できる余地はまだまだ残されていますが、それでもその精度は年々増してきているように思います。

例えば、検索語の関連語や併用語を提案してきたり、検索語のゆらぎを吸収してくれたりすることによって、ゲンミツに検索していた結果よりも望んでいた結果が得られるようになりました。

OPACの中心機能が「検索」にある以上、検索の精度向上は次世代OPACの本丸といえるのではないでしょうか。

リンクしやすいURL

個人的な重要度

★★☆☆☆

amazonが発展した理由とされる物のひとつにURLがリンクしやすい恒久リンク形式になっていたことがよく挙げられます。すなわち、amazonのように http://library.com/book/0123456789 のような形でその本の情報（書誌データ・貸し出し情報等）が参照できるようになれば、図書館へのリンクも増え、それにつれOPACの認知度も増え、より利用が増えるかもしれません。

ビジュアルデザインの見直し

個人的な重要度

★★★☆☆

OPACのページは文字一辺倒で、書影も用いず、一般に地味とされるビジュアルを持ったところも多く見受けられました。

ビジュアルはデザインの中の一要素であって、過度にビジュアルデザインに傾倒すると、ユーザビリティを損なう危険性があるものの、書影などを積極的に利用して理解しやすいページ構成に変えていくことで、利用者の検索行動がスムーズになるでしょう。

また、Talk to Myself – 書架で回りの本を見るで言及されているようなアイデアと併用してみると実用的にもリアル書架のいいところを取り入れられると思います。

ユーザレビューの記載など利用者参加型OPACへ

個人的な重要度

★★★★★

amazonは単なる書誌情報が持っていない情報、すなわちユーザーレビューを持っていて、この情報の豊富さもamazon成功の要因としてよく語り草になります。

特に学術の世界では、ほとんど誰も見ないような本もあり、そういう本は大抵amazonでもレビューされていません。しかし、大学図書館でそのような「マイナーな本」に需要が多くあるのであれば、ユーザレビューという貴重な第二の書誌情報を蓄積することで、利用者の図書選定の役に立つのではないでしょうか。それは単に書誌情報にレビューを併記するという意味だけではなく、検索順序の並べ替え材料にもなり得るでしょう。

また、ソーシャルタギングも利用者参加型OPACの一条件です。ソーシャルタギングとは利用者が自由に図書のキーワードを設定することが出来るという機能で、国立国会図書館のPORTAでもこのソーシャルタギングの機能を実装しています。

ミシガン州のアナーバー地域図書館は、こうした機能を意識的に取り込んでおり、Social OPACとの呼び名が付いています。

ソーシャルブックマーク機能と出典管理

個人的な重要度

★★★★☆

感覚としてはamazon上の書籍ページをはてなブックマークにブックマークするのと似たような感じですね。

ただ、単に文献をブックマークするではなく、それを一括で出典形式にして出力できるなど出典管理ソフトライクな機能をOPAC自身が持つようになると良いのではないかと思っています。

書誌情報の様々な形式での出力と積極的な公開

個人的な重要度

★★★☆☆

書誌情報をXML形式、RSS形式、MARC形式、または種々の文献管理ソフトで使用できる形式などで出力することで、外部のソフトウェアやサービスとの連携がスムーズになり、文献管理のコストが大幅に減ります。

また、これは意味としては書誌情報をAPIなどによって積極的に公開することとほぼ同義ですこれにより、外部ソフトウェア・サーバから書誌情報を利用できるようにすることで、例えば所蔵図書館マップのようなユニークなシステムや横断検索などがしやすくなります。検索結果をRSS形式で出力すれば、ある分野で最近図書館に入った図書を手軽に追うことが出来るようになり、学生や研究者向けのツールとして役立ちそうです。

これは環境整備の話なので、利用者の利便性に直接関わることではないのですが、結構重要な点だろうと思います。農林水産研究情報センターの林さんもその講演の中で重要性を訴えています。

国立国会図書館のPORTAはこうしたAPI公開に積極的で、様々なメタデータがSOAP/RESTなどを経由して取得できるようになっています。OCLC Worldcat, LibraryThing, Google Book Searchなど海外もデータ公開に積極的なところは多く、OPACにもこの流れが広がっていくことに期待したいところです。

図書館貸出記録の活用

個人的な重要度

★★★☆☆

岡本真さんの論文でも書かれていますが、例えば今までまるで活用されていなかった図書館の貸出記録を利用して図書館サービスを向上しようという物です。例えばamazon.comなどのオンライン書店のように協調フィルタリング手法を用いてレコメンデーションを行い関連した本を薦めたり、検索表示順序に優先度をつけたりといった具合です。

これには大きく2つの批判があります。一つは図書館の自由に関する宣言3条に見られるように、利用者個人のプライバシーを侵害してしまう危険があるのではないかということ。これに対しては個を特定できないような運用体制にする必要があるが、それに縛られすぎては図書館サービスの向上は見込めないのではないかという再反論もあります。

もう一つは、レコメンデーション自体の問題で、その場合利用者は、精度が低く満足のいくような本を薦めてくることが少ない、あるいは押しつけがましく不快であるなどといった印象を持っているようです。これについてはそもそもレコメンデーションが利用者視点から役に立っているのかどうか調べてみる必要がありそうです。

いずれにしろ、貸出記録はこれだけでなく、既に図書購入の際の参考にもなっているよう（桃山学院大学総合研究所紀要 共同研究報告「大学問題の社会学(2)｣によります）ですから、図書館サービス向上のために活用が進む可能性も十分あるでしょう。

連想検索の活用

個人的な重要度

★★★☆☆

上記のレコメンデーションと類似していますが、こちらはデータを言語的に解析し、ある図書に関連した図書を導き出そうというものです。

オープンソースの汎用連想計算エンジンとしてGETAがあり、Webcat Plusなどの書誌目録検索サイトでも利用されています。

また、OPACとしての関連図書の実装例としてはプリマス州立大学ラムソン図書館があります。

参考リンク

情報の科学と技術：利用者のプロフィールを考慮した連想検索OPACの構築(特集:図書館とWeb2.0)

ファセット分類を利用した結果の絞り込み

個人的な重要度

★★★★☆

ファセット（facet）とは、英語では「切り口」と言うことです。ものには様々な切り口がありますよね。例えば、本ならば出版された年だけでも「2000年以降」「1999年-1980年」「1979年-1960年」「1959年以前」と様々な結果があります。他にも出版社でも「岩波書店」「中央公論新社」「筑摩書房」…と挙げればキリがないですが、一応有限分の結果があります。

ファセット分類とはこの切り口によって、ものを分類する方法を言います。ファセット分類における切り口はそれぞれ排他的（重なってはいけない）で、またその切り口を重ねていくことで結果を絞り込んでいくことが出来ます。

それを活かした例で私たちがよく知っている物は、iTunesのスマートプレイリストでしょうか。各楽曲につけられたさまざまな属性（「アルバム名」「アーティスト名」「レート」…）を材料にして、検索・絞り込みを行ってその条件にマッチした曲のプレイリストを自動で作る機能です。

これに限らず、コンピュータ上では多くのファセット分類の活用例が見られます。例えば、賃貸物件検索サイトでは「家賃」や「駅からの距離」など複数の条件＝ファセットから家を探せますし、製品比較サイトでも例えばパソコンのCPUのタイプやHDDの容量など様々なファセットで結果を絞り込んでいますよね（そういえば、最近作ったSmartFeedもそうですね）

OPACでも、このような絞り込みを行っていくことによって、欲しい本により早くかつコストをかけずにたどり着けるようになるかもしれません。

参考にしたリンク先

• 明示的に宣言されます。: ファセット分類およびそのWebへの適用について。
• ファセット分類 – Wikiウサギ – ドブロク[DOBUROKU]
• 情報設計の脱MECE化がファセット分類

FRBRに基づいたOPAC

個人的な重要度

★★☆☆☆

この節は用語の定義を具体化して用いているため、しばしば正確ではなく誤解される危険性があります。お読みの祭はそれをご承知ください。なお、より詳しい方からのわかりやすいコメントをお待ちしております。

どこも小難しいことしか書いていなかったので、うまく理解できているかは少し自信ないのですが、私立大学図書館協会の講演内容を頼りに、出来るだけかみ砕いて書いておきます。

FRBRとは”Functional Requirements for Bibliographic Records”の略、日本では書誌レコードの機能要件と訳されています。

どういうことかと言うと、まず利用者は書誌レコードを見て、図書を発見し、他の似たような本と区別して識別し、入手したい本を選択し、そして入手できるかどうかなどを判断しますよね。その過程で利用者がそのプロセスをスムーズに行うためにはどのような書誌データを作ればよいのか…そのモデルを示し、指針となるのがFRBRといえます。

では、具体的にこれに従うと何がうれしいのか。まず、上記の行程（発見・識別・選択・入手）によって、それぞれ著作に付いている情報（属性）で重要なものは違ってきます。例えば、発見の段階ではタイトルや著者名、識別の段階においては版、入手の段階ではそれが貸出できるものであるかが重要になります。これを定義しておくことで、その各ステップにおいて属性の優先度をつけるという判断がしやすくなります。

もう一つ例を挙げましょう。例えば、源氏物語といえばあの紫式部の著作を思い浮かべるかと思いますが、オリジナルがそのまま伝わっているわけではなく、今私たちが読める源氏物語はその写本（コピー）が元となっていますす。それに校注が付いていたり、抜粋版になっていたり、また子供向けに優しく書き下されていたり、あるいは英訳されていたりするでしょう。また、出版社も一つではなく様々な所から出ていますし、それぞれに版違いがあります。このように同じ源氏物語でもいろいろ存在するわけです。

これらはそれぞれ同じ源氏物語とはいえませんが、同じ源氏物語というグループに属するものです。ですから、FRBRに基づいて書誌データを作ることでこれらが関連づけられ、もし利用者がこれらのうちの1つを検索して見つけたときに、同じグループにある別の源氏物語を提案することが出来るわけです。

しかし、考えてみればわかりますが源氏物語のような1つの著作が多くの本になっているというのは、現在でも判型の違いなどで分かれていたりはしますが、そう多くはありません。世界中の書誌データを集めて、整理・組織化しているOCLCという機関に収録されている著作3200万をサンプル抽出してみても、独立した著作の内、約78%には1つの著作には1つの本（版違いなども含めて）しか載っていませんでした。

よって、実際利用されるケースで上記のような利便性が向上するシーンは限定的な物なのかもしれません。

参考にしたリンク先

• 私立大学図書館協会講演
• CA1480 – 動向レビュー：AACR2改訂とFRBRをめぐって−目録法の最新動向− / 和中幹雄 | カレントアウェアネス・ポータル
• E588 – FictionFinder：巨大総合目録WorldCatをFRBR化する試み | カレントアウェアネス・ポータル
• FRBR のその後：FRBR 目録規則？FRBR OPAC?
• FRBR のとらえる「書誌的世界」：FRBR を中心に
• すばらしいFRBRの新世界

その他関連リンク

上記にまとめきれなかったリンク先を（かなり雑な分け方ですが）まとめて書いておきます。

動向レビュー的な資料

• CA1624 – 次世代の図書館サービス？―Library 2.0とは何か / 村上浩介 | カレントアウェアネス・ポータル
• 新しい技術を採用したOPAC、公共図書館でも導入（米国） | カレントアウェアネス・ポータル
• 京都大学図書館機構 – ハーバード日記 : 司書が見たアメリカ : 【5. ALA2007レポート】 by egami
• sushi-kuinee (Su-sanの ライブラリー): Library2.0、OPAC2.0–図書館におけるWeb2.0的な試み

OPAC 2.0に注目したもの

• CiNii – 情報の科学と技術 56(11) 特集「図書館とWeb 2.0」
• E687 – 望ましい大学図書館システムとは？＜文献紹介＞ | カレントアウェアネス・ポータル
• E566 – 21世紀の図書館目録とは？ ＜文献紹介＞ | カレントアウェアネス・ポータル
• はてなブックマーク – 書架 / opac
• 次世代型OPAC「Scriblio」
• 図書館退屈男: うぇぶ2.0の器量を伏して
• Library in the Web2.0 environment

各種組織の報告文書などへの反応

• NDLの「書誌データの作成・提供の方針（2008）」 | カレントアウェアネス・ポータル
• 国大図協、『今後の図書館システムの方向性について』を発表 | カレントアウェアネス・ポータル
• 蔵書検索（OPAC）はどこに向かうのか－書誌調整連絡会議の報告を受けて

OPAC 2.0とされる大学図書館OPAC

• Ann Arbor District Library
• Lamson Library

他にあったら、以下のWikiに追記してください。

おまけ

ちなみに私はProject Next-LのようにOPACそのものを作ることは考えていません。それでは、かなり大きなプロジェクトになってしまいますし、まずもって今すぐ利用できるサービスになるまではかなりの時間を要するのではないかというのがその理由です。

データは公開APIやスクレイピングなどから取得することになるので、システム内でのデータの利用は難しいものとなります。その制限の中でどこまでできるかということになりますが、出来る範囲で実装を重ねていきたいと思っています。

1. 関東では4年生っていうんですよね

全般的に見て

良いところ

• コネクタ類はそれぞれどれをどこにどう接続したらいいかのわかるようにアフォーダンスが設計されていて○
• 独特の操作体系なのにそれに慣れるまでほとんど時間と精神的コストをかけなくて済むのも○
• フィードバックを絶えず返すことで、ユーザが進行を確認しながら困惑せずに進められるように出来ている。これはテンポの良いSEとWiiリモコンの振動（＝視覚・聴覚・触覚）のフィードバックもかなり大きい。ウェブアプリでも音のフィードバックが普通に使えたら楽かもしれないなぁ。

改善して欲しいところ

自分の位置を見失いやすい（あるチャンネル内にいてもチャンネル内のトップなのか少し進んだところなのか）ように感じます。上部にタイトルバーをつけるか、パンくずリストをつけて現在位置を示すとよいのではないかなと思います（Wiiオプションのようなアイコン型パンくずリストも面白いですね）。

ただ、使っていて思うのは老齢者でもよく見えるようにナビゲーションのサイズには慎重になっている（小さすぎず、目立たなすぎず）感じがして、「限られたテレビ画面のサイズをどう使うか」に頭を使っていることがよくわかるので、なかなかこれ以上ナビゲーションを増やすの難しいかなとも思うのですけどね。

ショッピングチャンネル

良いところ

ショッピングチャンネルのソフト受信をするときのUIとか特に遊び心もあって良い。コナミ・パワプロシリーズがディスク読み込み時にやっていたバッティング練習を思い起こさせる。こういうものばかりなのは問題ですが、こういう余裕も忘れちゃいけないなと。

改善して欲しいところ

ナビゲーションボタンの位置関係の問題

上記画面はクレジットカードでWiiポイントを追加する例です。ある画面では下部ナビゲーションがもどる OKとなっているのに、次の画面では はい いいえとなっています。

最初の画面を見た時点でユーザは「右側に進む側のボタンがあるのだな」と推測する可能性がありますが、次の画面の同じ位置には逆（戻る側）の操作があるので、誤動作によりせっかくの入力がムダになってしまう可能性があります。

Wii全体としては、上記の推測のように左側に戻る系統のボタン、右側に進む（あるいは決定する）系統のボタンが配置されている（進行形ボタン配置とでも言いましょうか）のですが、特にダイアログボックスを中心にして、はい いいえ形式（確認形ボタン配置）の逆の位置関係を持ったナビゲーション併用されているために、このようなケースが起こっているのだろうと思います。

もちろん併用するには何か理由があるのでしょう。後者は重要な操作（操作が不可逆的であるような）を実行する際の確認に用いるものであって、すぐにボタンを押すユーザーにきちんと意思を確認したいという意図があるのかもしれません。

ただ、その場合は操作自体が不可逆であるのですから、いずれのボタンを押したときにも、きちんと確認ダイアログを出した方がよいでしょう。

どちらかに統一した方がよいと言い切りたいのですが、進行形ボタン配置は数多くの家電に利用され既に数多くのユーザのメンタルモデルになっていると言えますし、確認系ボタン配置も同様に、特にWindows OSなんかで多く利用されているので、どちらを逆にするのもメンタル・モデルに反したナビゲーション配置になるので難しいところです。

デフォルトではWiiから会員登録できない

ショッピングチャンネルを利用する際に、Wiiにクラブニンテンドーの会員IDを登録する設定がありますが、なぜここで未登録ユーザーが登録できないようになっているかちょっと疑問です。

インターネットチャンネルが有料なのでというのは商売上の都合ですから関係ないと思われますし、それならそれで会員登録できる簡易アプリを配布するか組み込めばいい話だと思います。

メールアドレスが必要なので、デフォルトでメールを利用できない¹ 環境にあるWiiからは登録できないようにしていると仮定しても、そもそもなぜメールを使う必要があるのか（メールの代替としてWiiの伝言板に同じ内容を送信すればよい）という話になるでしょう。

任天堂としても調査対象は増やしたいところでしょうし、会員登録できるようにした方が良いんじゃないかなと思います。

978-4903065069,caption

ちなみにニールセン博士の本では、優れたログイン画面のUIとしてamazon.comのそれが触れられています。このUIは1つ目のテキストボックスでアドレスを入力し、2つ目のラジオボタンで新規登録か登録済みの会員かを問うています。物理的に登録スペースとログインスペースを分断し未登録ユーザが（自分の取りたいIDで）ログインをしてしまうなどといったことなく、2種類のユーザタスクの処理をすることが出来ます。

無料追加チャンネルの位置づけ

無料チャンネル追加は、現在はショッピングチャンネルの無料ソフトウェアという位置づけですが、ショッピング＝有料ソフトウェアの販売と捉えるユーザも少なくないように思いますから、チャンネルー例えばアップデートチャンネルーを別に設けて、そこで更新できる方が良いのじゃないかな。現状、Wiiの更新もWiiオプションの奥にありますが、それもここにまとめたらいいのではないかなと。

Wiiウェアの購入情報

Wiiウェアは購入材料として事前に入手できる情報を増やした方がよいと思います。一番良いのは体験版（プレイ内容・回数限定版など）がプレイできることですが、コスト上厳しいのであればユーザの感想を書き込めて参照できるようにしたり² 、プレイムービーを参照できるようにするだけでも、だいぶ購入の抱いていたミスマッチが下がり、ハードルも下がるのではないでしょうかね。

余談。思い起こせばディスクシステム以来、ニンテンドーパワーや64DDなど、任天堂はこの手の書き換えソフトに何度もトライしてきたが、いずれも失敗してますね。高価な拡張システムを購入する必要があったことがその原因として挙げられますけど、その点Wiiウェアはこの心配はありません。

しかし、中古屋に売ることが出来ない点は現在も同じで、これはハードメーカ・ソフトハウスにとっては好都合ですが、ユーザにとってはミスマッチが起きたら最後、それを売ってリスクを軽減することも出来ず、結果として購入の意識的なハードルは高まったはずです。それはWiiウェアにも同じでしょう。

もちろん生産・投資コストが少なく済み、アイデア勝負のソフトもいろいろ出せるというWiiウェアのコンセプトは理解するとしても、コストが小さいからといってユーザにそれほど説明をしなくて良いのだという意識は持つべきではないでしょう。購入に際して、その検討材料はもう少し欲しいなという気がします。

ちなみに、この歴史的な背景については蔵 琢也氏の「任天堂の成功と失敗」という論文（PDF）がわかりやすくかつ詳しくてオススメです。

その他

テレビの友チャンネル（良いところ）

番組表が自在にスクロールできるのは便利。単なる番組表ではなく、みんなの意見を反映した番組表にもなるというのは新鮮で楽しいですね。

テレビの友チャンネル（改善して欲しいところ）

一画面の情報量がもう少し欲しい。設定からテレビ番組名欄が局のロゴアイコンに切り替えられるといいかな

起動時の表示設定（フォントサイズや表示する時間数など）はいつも一定の物ですが、前回終了時に表示していた表示設定を次回起動時に自動的に設定できるようになると便利だと思います

みんなの投票チャンネル（改善して欲しいところ）

都道府県の選択画面ですが、テレビの友チャンネルやお天気チャンネルなどは選択肢が1項目づつ移動するのに対して、投票チャンネルは1画面ずつ選択肢が移動するようになっていまして、一貫性に欠けるのではないかと

全体として思うのは、お茶の間に近いゲーム機だなと。ゲームをしなくても楽しいゲーム機というと語弊があるかもしれませんが、多くのチャンネルを用意して、WiiConnect24を用意して毎日触れる接点を作っている³ のは実感を持って思いました。

ちなみに、これから早速スマブラXとシレン3でもやろうかなと。それとWiiはゲームキューブのソフトがそのままプレイできるので、お金はないけど面白そうなゲームをやってみたい人にはGCソフトは良いかもしれません。任天堂の良作GCソフトとしてはゼルダ（子供リンク）シリーズやスマッシュブラザーズDX、カービィのエアライドあたりでしょうか。

ゲームなんて受験以来4-5年ぶりですが、今のところ母も楽しんでますし、なかなか良い感じです。

B000KFDO3A, clear

1. インターネットチャンネルを購入すればウェブ経由でウェブメールが利用できる
2. システムを作る余裕がないならインターネットチャネルと連携して単にGoogle先生にクエリを渡すだけでもよくて
3. それでも購入後、遊ばなくなったユーザも結構多いようですが