Li:d tech × Code4Lib Journal = Celebration !?
Code4Lib Journal へ投稿するぞ
いまから一週間前の2011.10.31に刊行された Code4lib Journal issue 15 にLi:d techメンバーが関わった記事が掲載されました。この記事の作成および投稿は“とあるメンバーの業務”として進められていたものでしたが、途中から Li:d tech メンバーが加わり Li:d tech における一つのプロジェクトとしても進行することになりました。ひとつのできごとの記録として、あるいは今後投稿される方の参考にもなるかもしれませんので、アブストラクトの投稿から実際に記事が掲載されるまでのスケジュールおよびメモをここにざっくりと掲載します。なお、本エントリーの文責はこのプロジェクトのいいだしっぺの長屋とします。
掲載までのスケジュール
| 日にち | できごと |
|---|---|
| 1.21 | キックオフミーティング。Li:d tech 結成！ |
| 2.1 | |
| 3.11 | Li:d tech メンバーが共著で Code4Lib Journal へ投稿することを決定。 |
| 4.13 | 進行状況から issue 14 への投稿を見送り issue 15 への投稿を目指す。 |
| 6.29 | Code4Lib Journal Issue 15 Call for Papers 発表*1。7.29までにアブストラクトを提出。 |
| 7.29 | アブストラクト送付*2。 |
| 8.8 | 編集委員から「興味があるから9.2までに Complete Draft を出してね」との連絡。 |
| 9.2 | Complete Draft 提出！ |
| 9.14 | 編集委員2名からコメント。「コメントを検討し Final Draft を9.30までに出してね」*3。 |
| 9.30 | Final Draft 提出！ |
| 10.31 | 原稿掲載！ |
心がけたこと
3週間で Complete Draft 完成 !?
2011.8.8の編集委員からの連絡で2011.9.2に Complete Draft を提出することになったわけですが「ってそれ、一ヶ月ないよ！3週間で英文原稿提出ですか!?」という状況でした。Complete Draft を作成した怒濤の３週間ちょっとのスケジュールをざっくりと載せます。
- 日本語原稿作成 (長屋：2日)
- メンバーコメント -> 修正 (3日)
- 英語原稿を作成 (長屋：5日)
- メンバーコメント ->
大幅というかほとんど修正 (6日) - 英文校閲発注 - 待つ (5日)
- 英文校閲結果を検討して最終原稿作成 (3日)
- 原稿提出！
という超過密スケジュールでした。これから投稿しよう！という方はある程度 Draft を作った段階で申し込むことをお勧めします。ただし、自分たちは英語原稿の作成前に日本語原稿をつくったこと、そして英文校閲を依頼したこと、の2つの過程で時間をそれなりに使っています。日本語で原稿を先に書く事にした理由は次の２点です。
- 共著メンバーとあらかじめ内容を共有するため
- 方法はなんであれ、全体像を言語化して書き出した方が内容および論理展開のまずさに気づける
かなり厳しいスケジュールでしたが、締め切りをすべて守りきった点は編集委員に非常に好感を持っていただけたようでした。なお、このプロジェクトでは日本語原稿および英文原稿のブラッシュアップ段階（メンバー全員によるコメント、修正）で Google Doc を使いました。
「仕事」と「課外活動」のあいだ
この Code4Lib Journal への投稿は、そもそも“とあるメンバーの業務”の一つとして取り組んでいたものでした。その過程でそのとき関わっていた Li:d tech というチームのメンバーを共著者として手伝ってもらうよう依頼し共に記事を作成し投稿しました。ですので「仕事としての側面」と「 Li:d tech の活動としての側面」という2つの側面を持っています*4。
Li:d tech は仕事と離れたところでの活動、つまり課外活動的なものだったわけですが、メンバーを共著として巻き込み業務として一本の記事を書くことで、
- 仕事と課外活動を「つなげる」
ということの足がかりに多少なりともなったのではないかと思っています。
Li:d tech というチームのこととこれから
ぼくたちは2011.1.21に Li:d tech というチームをつくりました*5。奇しくも30歳が3人、29歳が1人とほぼ同学年の4人が集まったことで自然と仕事のこと、生活のこと、恋愛のことなどとかく脱線しがちで tech な話題そっちのけになることも多いにぎやかな場所でした。「まずはこのメンバーで１年間やってみようぜ」というところから始めたので2012.1.21をもって解散予定です。長屋個人としてはこうして一つのチームとして楽しく取り組めた経験それ自体が大切な成果です。あとちょっと最後までこの4人で楽しんでやれたら、と思っています。
それから、最後に。大谷さん、ご結婚おめでとう！*6 （ from 坂井、林、長屋 ）
2011.11.7 「いいね！」の日に
*1:10月末掲載号のこの issue 15 に掲載希望者は7.29までに「 proposals, abstracts, or draft articles 」のいずれかを提出しなさいとのこと。
*2:自分たちが提出したアブストラクトはおよそ160ワード。詳細についてはCall for Submissionsを参照してください。
*3:この段階で Code4Lib Journal issue 15 への掲載がほぼ決定した様子。
*4:ただし、本エントリーは後者の視点、あくまでも Li:d tech というチームをベースとした活動の一つとしてその部分のみを書きました。
*5:大谷さん、坂井さん（オブザーバ）、林くん、長屋の4人。
*6:自他ともに認める Li:d tech 最大の成果です！このプロジェクトについてはまたどこか別の機会に。
パターン、Wiki、XP - 第3部：Wiki
第3部では、本書の動機となったWikiの起源について書かれている．パターンプラウザから始まるWiki誕生までの歴史、Wikiが備えるコミュニーケションの基盤となる機能、Wikiの設計原則とアレグザンダーの理論やXPのプラクティスとの共通点、Wikiを利用したWebサイトで最も良く知られているものの一つであるWikipediaの歴史、そして現在のWiki、といった構成である．
Wikiという他人の書いた記述を含めて書き換えることのできる極めて自由度の高いシステムを上手く機能させるには，参加者の合意形成を行いながら運用していく必要がある．そして，Wikiというのはコンテンツの蓄積だけでなく，合意形成のためのコミュニケーションの場としても機能する点である．本書によれば，現在の日本を代表するWebサービスであるはてなやニコニコ動画には，Wikiの特性が組み込まれているという．特にニコニコ動画においてその成功はユーザー自身が新しいコミュニティのルールを作っていたところであろうが，そこにWikiの特性が関与しているという発想はなかったので興味深い．
以下、抜き書き
- 12章 HyperCardによるパターンプラウザ
- パターンプラウザは、単に１人で編集する段階を超え、複数の利用者が共同で情報を編集・追加していく、共同編集の段階へと成長していきました。（p.116）
- 13章 WikiWikiWeb
- カニンガムは、ここで作ったしくみ（引用者注:Wiki）の名前に、メールや掲示板のような現実世界の何かを想起させる単語を使いたくありませんでした。Wikiという単語はハワイ語だったため新鮮な響きを持っていて、何の先入観も持たない単語として使うことができたのでしょう。(p.123）
- カニンガムは、「すべての問題を一気に解決する1つのアイデア」という考え方が好きです。(p.127)
- Wikiにカテゴリ機能を追加しなくても、カテゴリそのものも普通のページとして実現してしまえばいいと考えたのでしょう。(p.127)
- 「カテゴリ」と言いながらも、実際には階層構造ではなく分類が重なり合っているため、ツリー構造ではなくセラミティス構造であると言えます。（p.127)
- Wikiの各ページはあえて階層構造を持たず、フラットな名前空間の中で一元的に管理されています。このように情報をフラットに並べて管理するというコンセプトにおいて、両者（引用者注:パターンプラウザとWiki）は大きく共通しています。（pp.127-128）
- 14章 Wikiモードによるコミュニケーションパターン
- 編集が即座に反映され、ほかの人に伝わるという特製から、Wikiはパターン記述の場であると同時に、パターンについて議論し合うコミュニケーションの場としても機能するようになりました。（p.129）
- ページ記述のルールも議論をすすめるためのルールも、どちらもWiki上のコミュニケーションを円滑に進めるためのルールです。そのためここでは、両者を一体のものとして「コミュニケーションパターン」という言葉で表現します。（p.130）
- Wikiは、誰もが自由に、ほかの人の記述も含めてどこでも書き換えられます。それが、非常にラジカルですごいことなのですが、その代わりにそのような環境を維持するためには非常に大きな努力が求められます。議論を通じて合意や共通理解に到達することに価値を認め、各々が実践していくという文化を創り上げることが、Wikiにとっては非常に重要です。（p.137）
- 15章 Wiki設計原則
- 自分自身のソフトウェア開発と同じく、自分たち自身で良いとされるルールを考え、決めていくことが大切です。（p.145）
- Wikiのもつこのような特質（引用者注:参加者間の合意でコミュニケーションのルールを作り上げていくこと）は、コミュニティの活動と発展を助けるための有効な手助けとなります。（p.146）
- 無名の質を備えたコミュニティとは、生き生きとした持続性のある発展可能なコミュニティでもあるのです。（p.146）
- 16章 Wikiエンジン
- つまり人々はWikiBaseのシステムの中で、ページ中にリンクを埋め込む手法「WikiName」とテキストをHTMLに変換するしくみ「Wiki記法」の２つの機能に興味を持って。改良や提案を行っていたわけです。（p.154）
17章 Wikipedia
まとめ
最後に先月の「検索と発見のためのデザイン」から頻出する，「パターンランゲージ」について．アレグザンダーの６つの原理のうちの一つだが，その中でも「パターンランゲージ」は特に良く知られている．また，2010年から図書館界においても，この「パターンランゲージ」を活用して図書館のデザインを見直す試みが行われている．2011/3/5に筑波で開催されたラーニングコモンズデザイン会議（春）に参加した際，グループワークで既存のパターンを定期的に見直し改善していくパターンという，メタなパターンが議論にあがった．これは，アレグザンダーの６つの原理（1.有機的秩序の原理，2.参加の原理,3.漸進的成長の原理，4.パターンの原理，5.診断の原理,6.調整の原理）もまた一つのパターンとみた場合，まさに診断の原理・調整の原理で述べられているプロセスであろう．
パターンランゲージは，特に斬新な理論という訳ではなく，ずっと昔からある程度無意識に行われてきたことだと思う．ただ，それに明確な名前をつけ，一定のフォーマットのもとに整理したという点が優れているのだろう．そして，先人のパターンを活用できる私たちは，既存のパターンをただ使うのではなく，自分たちの状況に最適化して活用する，もしくは新しいパターンを作るという意識が必要ということを改めて感じた．
パターン、Wiki、XP - 第2部：ソフトウェア開発
第1部に登場した建築家アレグザンダーによるパターンランゲージ。次は、ソフトウェアの世界に取り込まれていく。第2部では、ソフトウェアの世界にどのように取り込まれていったのか歴史を追っていく。
大きく分けて２つの流れが存在する。ウォード・カニンガム、ケント・ベックによるプログラミングのパターンランゲージへの取り組みと、平行して起こったプログラミングに繰り返し現れる構造を再利用しようというデザインパターンの流れ。そして、同時代の関係者をつなげる学会やシンポジウムといったコミュニティの存在と徐々に統合、ブラッシュアップされていくソフトウェアの世界におけるパターンランゲージ。現実のソフトウェア開発現場においてパターンランゲージを適用し有用性を示すことになったChrysler社におけるC3プロジェクトの存在。
第２部はこのような流れになっている。
最終的にXPという一つの思想にまとめあげられていく過程をつぶさにみていくことで面白いと思ったのが、建築の世界で形作られたうまく成果を残すことができなかった思想がソフトウェアの世界と取り込まれ広がっていくその流れ。そして、人と人がつながることで思想自体を統合したり、ブラッシュアップしたりする役目を果たすことになるコミュニティの発生。
こっちの世界でうまくいかなくってもあっちの世界でうまくいって支持されている、というの一つの事例は自分にとっても今後ヒントになりそう。あとは、Li:d techも人と人が集まってやっているわけだけど、何かを生み出す流れになったらなあとぼんやりと思ったりして。
以下はほぼ抜き書きメモです(完全な抜き書きではなく手も加えてます)。
- 7章 オブジェクト開発
- ウォード・カニンガム、ケント・ベック p.56
- ２人は新しいプログラミングの概念について議論しては、考えた結果をテクニカルペーパーという短い論文としてまとめ、公表 p.56
- ウォード・カニンガム、ケント・ベック p.56
-
- ダグラス・エンゲルバート スタンフォード研究所
- コンピュータに関する会議(Fall Joint Computer Conference)で伝説的なプレゼンテーション p.58
- GUI:マウスによってポイントを動かし、画面上にウィンドウを開いて対話的にコンピュータを操作する p.58
- アラン・ケイはこのGUIをsmalltalkに取り込む p.58
- 1979年 スティーブ・ジョブスはPARCを見学し、Alto上で動くsmalltalkを見る p.59
- 1983年 GUIを搭載した初めてのパーソナルコンピュータ「Lisa」を発売 p.59
- 1984年 Apple「Macintosh」を発売。一般的な企業や個人でも変える価格帯で発売。GUIを瞬く間に世界に広めた p.59
- ダグラス・エンゲルバート スタンフォード研究所
- 8章 ソフトウェア開発へのパターンの適用
-
- ベックとカニンガムはパターンランゲージに興味 p.62
- Tektronix社内でベックとカニンガムは「パターンを使ったシステム設計」を試行 p.62
- ユーザインタフェースに関するパターンを５つ収集して、この５つのパターンからなるパターンランゲージをまとめる p.62
- システムの利用者が最終設計 p.62
-
-
-
-
- 1. タスクごとのウィンドウ(Window Per Task)
- 2. ウィンドウ内にペインはできるだけ少なく(Few Panes Per Window)
- 3. 標準的なペイン(Standard Panes)
- 4. 短いメニュー(Short Menus)
- 5. 名詞と動詞(Nouns and Verbs)
-
-
-
-
- 簡素ですが、非常にエレガントなデザインが実現 p.64
-
-
-
- ２人は結果を「オブジェクト指向プログラムのためのパターン言語の使用」という論文にまとめました。 p.64
-
-
- ２人は、プログラミングに関するパターンの収集も開始していました p.65
- 論文執筆の時点で10個ほど。20-30個のラフなアイディア。最終的には100-150個程度のパターンを収集できると予想していました p.65
- ソフトウェアの設計に繰り返し現れる構造をどのようにとらえ、他の人と共有できるかについて考え、論文としてまとめました。 p.66
- ２人は、プログラミングに関するパターンの収集も開始していました p.65
それと平行し、別のところでもソフトウェアに繰り返し現れる構造に目を向けている人がいた。
-
- コミュニティの発生
- OOPSLAは、このような同じ考えを持った人が出会う場として重要な役割を果たすことになります p.66
- コミュニティの発生
-
- デザインパターン誕生までの歴史
- 9章 デザインパターン
- GoF(ゴフ:Gang Of Four)
-
-
- デザインパターンという狭い範囲から始まったパターンの応用も、徐々に範囲を広げ、「町」「施工」といった違う粒度に相当するパターンも扱われるようになりました。 p.77
-
- 10章 プロセスへのパターンの適用
-
-
- これは、組織やプロセスを対象としたパターン、つまり「組織パターン」「プロセスパターン」という新しい考え方を発明したのだと言えます。 p.80
-
-
-
- コプリエンは組織が備えるべき「無名の質」についても言及しており、無名の質がソフトウェア開発を行う組織とプロセスの改善の糸口になるという考えを述べています p.80
-
-
-
- エピソーズは開発チームの組織やプロセスを記述したパターンランゲージで、ソフトウェア開発における問題解決のための文書のあり方やグループの構成方法、各役割担当者の心構えなどを提示 p.80
-
-
-
- カニンガムは、ソフトウェア開発にはドラマの起承転結のような流れと波があると考えました。そのためソフトウェア開発のさまざまな活動サイクルの単位を、メタファとして「エピソード」と呼びました。 p.81
-
-
- C3(Chrysler Comprehensive Compensation project:総合報酬プロジェクト)プロジェクト
-
-
- Chrysler社の給与計算プログラム、COBOL -> smalltalkに p.82
- Chryslerにはおよそ６千人の役員と10万人の従業員がおり、部署や役職によって給与支払いの制度と計算ルールが異なるため、複雑化 p.83
- プロジェクトは1993年に始まり1995年にはSmalltalkによる開発が始まっていたが、非常に難航 p.83
- ベックは今までコミュニティが培ってきた組織とプロセスのパターンを徹底的に実践 p.83
- C3プロジェクトで実践されたオリジナルのプラクティスは、ロン・ジェフリーズによって1997〜1998年ごろにまとめられ、Webで公開されました p.84
- Chrytslerの野心的な新システムは1999年まで開発が続きましたが、約1万人の月給雇用者をカバーするようになったところでプロジェクトは中止 p.87
- プロジェクトの体制や開発されたソフトウェアの品質については問題なかったが、ビジネス上の要求の変化によって中止の決定がなされたのだとベックは結論付けています p.88
- C3プロジェクト修了後も、Chryslerのシステムに関わり続けたメンバーたちがいるそうです。彼らはXPを適用することで、非常にバグが少ないプロジェクトを実現しています。 p.88
-
- 11章 エクストリームプログラミング
- ベック 「XPエクストリーム・プログラミング入門」を出版 p.89
- 「エクストリームプログラミング(Extreme Programming)」はベックが提唱するソフトウェア開発手法で、C3プロジェクトなどで培った経験に基づいて、ソフトウェア開発現場において良いとされる一連の行動指針を「プラスティス」と呼ばれる形にまとめあげたもの p.89
- ベック 「XPエクストリーム・プログラミング入門」を出版 p.89
-
- 「XPエクストリーム・プログラミング入門」-プロジェクトに関わる人々が共有して目指すべき４つの「価値」
-
- コミュニケーション
- シンプル
- フィードバック
- 勇気
-
- 「XPエクストリーム・プログラミング入門」-プロジェクトに関わる人々が共有して目指すべき４つの「価値」
-
- ４つの価値から導きだされる５つの基本「原則」
-
- 瞬時のフィードバック
- シンプルの採用
- インクリメンタルな変更
- 変化を取り入れる
- 質の高い作業
-
- ４つの価値から導きだされる５つの基本「原則」
-
-
- 「価値」と「原則」を達成するために、12個の「プラクティス」が提案
- 略
- 「価値」と「原則」を達成するために、12個の「プラクティス」が提案
-
-
-
-
- プロセスやツールよりも、人と人との交流を
- 包括的なドキュメントよりも、動作するソフトウェアを
- 契約上の交渉よりも、顧客との協調を
- 計画に従うことよりも、変化に適応することを
-
-
-
- 「XPエクストリーム・プログラミング入門 第2版」
- 「xpエクストリーム・プログラミング入門 第2版」が出版(2004年)
- 全体の構成から細部の記述に至るまですべてが新しく書き改められていた。
- ベック自身の経験や、XPを経験した他の多くの人々からのフィードバックによってXP自体が変化し洗練されていった
- 「XPエクストリーム・プログラミング入門 第2版」
-
-
- XPはアレグザンダーが建築の世界で目指したプロジェクトの推進方法を、非常に上手にソフトウェア開発の世界に取り込んだ p.103
-
-
- アレグザンダーの失敗
- 建築家は社会的な役割が固定化していて、建築家は設計する建築の詳細を最終的に決めるのは自分たちだという態度を放棄せず、利用者はそのような状況で自分たちの要求を適切に伝える術を知りません。そのため、アレグザンダーは最終的には建築家と利用者の間のバランスをとることに失敗したのだと語っています p.105
- 誕生して間もないコンピュータの世界であれば、利用者と開発者という社会的な関係を含めて新しくて意義しなおせるかもしれません。ベックは、「ソフトウェアでは、新たな社会構造を作る機会がある」(p.156)と語っています。つまりXPの本当の目的は「新たな社会構造を作る」ことにあるのです。 p.106
- アレグザンダーの失敗
-
-
- XPは、利用者と開発者が互いの垣根を越えて共同でソフトウェア開発へと向かい、生き生きとした、そして無名の質を備えたソフトウェアを実現しようと言う試みだったのだと言えます。 p.106
-
-
- 建築の世界から始まったパターンランゲージの影響は、一巡りしてソフトウェア業界からアレグザンダーへとフィードバックされました。 p.107
パターン、Wiki、XP - 第1部：建築
概要
3月の課題図書は江渡浩一郎さんの『パターン、Wiki、XP : 時を超えた創造の原則』です．
パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)
- 作者: 江渡浩一郎
- 出版社/メーカー: 技術評論社
- 発売日: 2009/07/10
- メディア: 単行本（ソフトカバー）
- 購入: 75人 クリック: 1,306回
- この商品を含むブログ (155件) を見る
この本は，今から1年半ほど前に出版されたものですが，先月の『検索と発見のためのデザイン』(原題は『Search Patterns』)に続けて読むのが良いだろうということでセレクトしました．幸いにして全員未読．←それがそもそもどうなんだw
構成
本書は3部構成になっていて，そのうち僕は序章 + 第1部を担当します．
- 第1部：建築
- 第1章：クリストファー・アレグザンダーによる美の原理の追求
- 第2章：アレグザンダーの6つの原理
- 第3章：パターンランゲージ
- 第4章：時を超えた建設の道
- 第5章：パターンランゲージによる建築の実際
- 第6章：アレグザンダーの現在
- 第2部：ソフトウェア開発
- 第3部：Wiki
本書のおおまかなストーリーは序章「パターン，Wiki，XPの起源へ」から伺えます．
2002年に職場での情報共有にWikiが導入され，その使いやすさと柔軟さに驚いた江渡さんはqwikWebという独自Wikiを開発するに至ります．その過程でWikiの定義・起源を追いかけていくようになり，最終的にクリストファー・アレグザンダーという建築家にまで辿り着きました．すなわち，
- 1960〜70年ごろ，クリストファー・アレグザンダーがパターンランゲージというアイディアを生み出した．
- 1987年，ウォード・カニンガムというプログラマがパターンをソフトウェア開発に活用しようとした．パターンを記述するためにHyperCardでパターンブラウザを開発．
- 1995年，彼はWikiWikiWebというweb版パターンブラウザを開発した．これが現在のWikiの原型である．
という系譜だったのです．このパターン→XP→Wikiという流れで本書は進められていきます．
引用・メモ
括弧内は引用です．
1章：クリストファー・アレグザンダーによる美の原理の追求
- 1936年生まれ
- ケンブリッジ大学の数学科→建築学科
- 「「何がものを美しくするのか」という原理」の追求
- 美しさ＝顔の造作の美しさではなく「笑み」のような快の感情につながるもの
- ケンブリッジに不満があり，ハーバード大学の大学院へ
- Christopher Alexander, Marvin L. Manheim, "The Use of Diagrams in Highway Route Location", Civil Engineering Systems Laborartory Publication, 161, MIT, 1962
- 博士論文「形の合成に関するノート」
- 1963年：カリフォルニア大学バークレー校の教授に
- 1964年：ベイエリア高速鉄道のプロジェクト
- ツリー構造は大切な関係性をそぎ落としてしまうという限界に気づく
- 1965年：「都市はツリーではない」
2章：アレグザンダーの6つの原理
3章：パターンランゲージ
4章：時を超えた建設の道
- 『時を超えた建設の道』(1979年)のなかで無名の質 (Quality Without A Name, QWAN)という概念を提出
- 自然都市が備えているような質？
- 賛否両論
まとめ
第1部では50年ほど時間を遡って，クリストファー・アレグザンダーの思想の系譜を追っていきます．
当初は数学的なトップダウンアプローチを取っていたアレグザンダーが，その限界に気づいてしだいにボトムアップアプローチを取るようになる．そのアプローチの根底にあるのがパターンという概念です．
第3章の冒頭で，パターンは「建設環境に繰り返し現れる課題を解決に導く具体的な方策を記述したもの」(p.33)と説明されていますが，そう言われても分かったような分からないような……．続いて挙げられている例を読んでみてもいまいち．最初は，パターンというのはベストプラクティス的な事例集というか，このパターンを組み合わせていくと何か良いものができあがるパーツみたいなものなのかなという印象を受けました．
ただ，どうもそうではないようで，
- 「レゴブロックを組み合わせて建築を作り上げるように，それぞれのパターンに適する実体があって，それを単につなぎ合わせるようなイメージを生じさせます」(p.45)が，それは彼の思想の正反対
- 「単なる部品集でも事例集でもなく，利用者と建築家をつなぐためのさまざまな工夫の集積」「利用者と建築家をつなぐ共通言語」(p.46)
- 「利用者の参加によって利用者と建築に関わる専門家とが合意形成し，有機的秩序に基づく建築を設計するために考え出された手法」（p.53）
などと解説されています．うーん．
どうもパターンという概念それだけに注目するのではなく，第2章で引用される「6つの原理」*1も合わせて眺めてみるとその意義が理解できるような気がしました．
- 有機的秩序の原理 (The principle of organic order)：計画や施工は，全体を個別的な行為から叙々に生み出してゆくようなプロセスによって導かれること．
- 参加の原理 (The principle of participation)：建設内容や建設方法に関するすべての決定は利用者の手に委ねること．
- 漸進的成長の原理 (The principle of piecemeal growth)：各予算年度に企画される建設は，小規模なプロジェクトに特に重点を置くこと．
- パターンの原理 (The principle of patterns)：すべての設計と建設は，正式に採択されたパターンと呼ばれる計画原理の集合によって指導されること．
- 診断の原理 (The principle of diagnosis)：コミュニティ全体の健康状態は，コミュニティの変遷のどの時点でも，どのスペースが生かされ，どのスペースが生かされていないか，を詳しく説明する定期的な診断に基づいて保護されること．
- 調整の原理 (The principle of coordination)：最後に，全体における有機的秩序の緩やかな生成は，利用者の推進する個々のプロジェクトの流れに制御を施す財政的処置によって確実なものとされること．
なるほど．ステークホルダーの共通言語としてのパターン．それをベースにして
- ユーザ参加型
- ボトムアップ
- 生成的なプロセス
- 定期的レビュー
といったアプローチでデザインしていくこと，デザインしつづけていくこと，これがアレグザンダーの思想なんだろう．そう考えればパターンを記述するフォーマットなんて(そのコンテキスト内で一定であれば)なんでもいいんだろうと思えてきました．
いずれにせよ，パターンというアイディアはそれが生まれた建築の世界ではぱっとした結果を残せなかったという印象を受けました．第2部以降ではパターンランゲージがソフトウェア開発の世界で花開くという話に続いていきます……．
６章 さわれる未来
6章「さわれる未来」では，まずユーザー調査の手法や，デザインの成果物のパターンが上げられ，それぞれの手法や成果物にそれぞれどのような意味があるのかということが述べられます．「検索のシナリオ」では，検索と発見の未来を想像させる幾つかのショートストーリーとその解説があります．感覚を利用した検索，セマンティック検索，ソーシャル検索がシナリオとして上げられています．最終節の「発見を体験する」では，拡張現実（AR）の例をもとに，検索と発見に関係する技術進化の速さと，そのような技術革新によりどような課題がもたらされるか述べ，その課題に対応するためには，本書で繰り返し述べられているようにこれまでのパターンを熟知するとともにそれを破ることが必要とまとめています．
抜き書き
- メソッドと成果物
- 控えめなユーザー観察に実効性が認められることはめったにない．（p.164）
- データはユーザーが用いる語句を教えてくれるが，彼らが何を探しているのか，それが無事見つかったのかは教えてくれない．（p.165）
- デザイナーが作る資料は，ただの説得材料じゃない．探索用の乗り物でもあるのだ．（p.165）
- 検索のシナリオ
- キーワードと統制語彙を用いる方法が，本当にベストなのか？それとも，言語の壁を越えられるだろうか？（p.169）
- 実際のところ，セマンティック検索はほとんど座興の域を出ていない．（p.172）
- （引用者注:セマンティック検索のアプローチよりも），クエリー再構成のデータやクエリー実行後のクリック結果からオートサジェストを実現するといった，もっと地味なアプローチの方が，より費用対効果が高いだろうというだけの話だ．（p.174）
- ソーシャルな行動の指標にリアルタイムにアクセスできれば，ある情報がニュースになるより早く通知を受けて気づくことができる．（p.177）
- 発見を体験する
- 体験の発見という，好奇心をくすぐられる協調的な課題に取り組むことも必要なのだ．（p.182）
- 検索と発見を目的とするアプリケーションのデザイナーとして，僕らはこれからの学習やリテラシーのあり方を決めることになる．知識の収集や整理をしたり，創造力を引き出す上で，検索はなくてはならない役割を果たす（p.183）
所感
図書館の検索のこれからを考えたとき，あらためて考えてみようと思ったトピックを２つあげます．
- 電子書籍が単に電子化した書籍から，電子書籍ならでは機能（ex.どこで読んだのか，どこにアンダーラインを引いたかなどソーシャルな情報を共有，動画や音声との融合）を本格的に備えるようになった時に，必要な検索機能は？
- 書籍の全文検索が可能になった時，それでもあえてコストをかけて追加すべきメタデータはあるのか？
現時点で，私に明確な答えがあるわけではありません．しかし，これらは既に一部では現実となっていることです．Li:d techの活動などを通して，問いを探し考え続けていきたいと思います．
5章 発見のエンジン
やや異色な章である。効率的に、素早く答えを見つけるための情報検索ではなく、タイトルにもあるように「発見」のための情報検索の話がメインになっている。平坦でまっすぐな道をずっと歩いていたんじゃわからない。寄り道をしながら楽しみながら意外なヒントを得る。そんなちょっとした仕掛けが凝らされている情報検索システムたちが次々に登場する。
- 「どれもGoogleのような生活必需品というわけじゃないが、検索のセレンディピティに独自のひねりを加えてくれる。僕らはセレンディピティを求めて釣り糸を垂れ続けなければならない。手っ取り早い答えはもう釣り上げてしまったからだ。発見のエンジンにはこれからの検索を編み出す責任がある。 p.162」
とあるように、確かに手っ取り早い答えはGoogleが教えてくれる。それ以外の「発見」につながるようなセレンディピティを生み出すような情報検索の仕掛けを具体的なウェブサービスを例に読み進めることができる。
- パーソナライズ機能や協調的フィルタリング、推奨システム、発見エンジンなどが成果を上げる可能性がある。だが、ソフトウェアのアルゴリズムでなんとかなるのはそこまで。<中略> 僕らの頭こそが本物の発見エンジンなのである。 p.139
以下、カテゴリー、トピック、フォーマット、オーディエンス、プラットフォーム、モードに場合分けをし紹介している。（「 」内が引用部分を示す、章-節の節は長屋が独自に付け足してます）
5-1 カテゴリー
IBMではイントラネット内で「Dogearというツールを公開し、BluePagesという従業員ディレクトリなどのサービスを展開 p.140」
していたという。Web2.0という言葉もない頃で、「ソーシャルデータをフル活用して検索とソーシャルネットワーキングを向上させるべく、企業内ソーシャル検索のプロジェクトも立ち上げ p.140」るなど先駆的な試みが行われていた。
けれど、数々仕掛けられたソーシャルコンテンツへと導いてくれる便利なタブをだれもクリックしなかったという。そこで「ソーシャルコンテンツがインターフェースの全面に出る p.141」よう変更したことで「クリック数はたちまち跳ね上がった p.141」という。
こうした成功事例を元にいくつかのサービスが行っている工夫をみてみよう。
5-2 トピック
- GoPubMed：検索結果をチャートやグラフで見る p.147
- Epicurious：食欲をそそるファセット型ナビゲーション。材料や料理の種類で絞り込み検索 p.147
- Urbanspoon：iPhoneをシェイクし検索結果を出す p.148
5-3 フォーマット
- oSkope：ビジュアル検索アプリケーション p.149
- Delicious：オートサジェストとタグによるフィルタリングと検索結果の視覚化を見事に融合している様子 p.149
- MrTaggy：ソーシャルなタグを頼りにした検索エンジン p.149
- LinkedIn：構造化されたプロフィールデータを活用 p.151
- 「写真専用の検索アプリケーションをデザインしているとするなら、それに特化した検索やインタラクションのモデルを思いのままに試すことができる。焦点を絞ることで自由が生まれ、自由から発見が生まれる。 p.151」
5-4 オーディエンス
- オーディエンスを限定した検索エンジン
- Baidu (kids,Elderly Search)
- Koogle：コーシャー(Kosher)版のGoogle。正統派ユダヤ教徒向け p.153
- International Children's Digital Librarty: 視覚的なファセット型ナビゲーションのモデル p.153
- ChemSpider : 専門職種のコミュニティ向けにデザインされたアプリケーション p.154
- 「ChemSpiderのように専門的なアプリケーションを開発する際に、化学者なら検索などお手のものだろうと思い込んだら大間違い p.154
専門知識と検索スキルをごっちゃにしてはいけない p.154」
5-5 プラットフォーム
Spotlight
AppleのMac OS Xのデスクトップ検索機能 p.155
- 日付によるクエリーの絞り込みや、サーバーや共有ドライブなどの特定の場所だけの検索を簡単に実行 p.155
- 標準的なリストかカバーフローのインターフェース p.155
- ブラウジングしてみたくなる作り p.155
Tivo
- 「Googleがインターネットで成し遂げたことを、いまTiVoがテレビでやっているのです。他のサービスには真似できない、優れた検索結果と革新的な発見を合体させてみること p.156」
- 「双方向テレビのデザイナーにとっては、異論はあるもののウェブがパターンライブラリーの役割を果たしている。しかし、iTVでの革新がいずれはウェブの方に逆流してくるのは間違いないだろう p.157」
Redbox
- アルファベット順索引と"ジャンル別一覧"機能によって、比較的小規模で構造化された映画作品カタログにアクセス p.158
5-6 モード
Aardvark
- 自分の友達や、友達の友達、クラスメート、同僚、果ては近くにいる赤の他人にまで広がるユーザーのネットワーク上で、回答者にふさわしい人物に質問を向ける高度なアルゴリズムを採用した"ヘルプエンジン" p.159
- ちょっとした人助けをしようという自発性をユーザーからうまく引き出している p.159
- ナレッジマネジメント用の革新的ツール p.159
Hunch
- ユーザーとソフトウェアを巻き込んで、デシジョンツリーを協調的に作り上げ、改良していく。 p.159
- 集合知による意思決定システム p.159
- 単純な質問と回答の連なりが、学習や発見を生む刺激となる場所だ p.160
- 興味深い答えをくれるだけではなく、ユーザーがきちんとした質問をするよう促す p.160
Ambiently
- 質問をするまでもなく回答を出してくれる p.161
- どんなウェブページからでも、ボタンをクリックするかブックマークレットを用いるだけで、それと類似した意味を持つページや関連トピックを扱っているページの一覧を示す「Ambient Page」を見ることができる p.161
- Ambientlyは専門家が用いるパールグローイングの手法を誰もがより手軽に活用できるようにしている p.161
StumbleUpon
- 必要なのは質問ではなくクリックだ。
- このセレンディピティエンジンの本質は関連度の追及というよりはランダムな発見の喜びにある p.161
- 検索ではみつかりっこない愉快なもの、面白いものを見せてくれる p.161
2/30(水)にもうちょっと編集予定です
4章 デザインパターン（前半）
4章では，検索においてこれまで良く使用されている10個のパターンについてと，そのパターン相互の関係性について具体的に解説しています．この記事では，4章前半部分のオートコンプリート・ベストファースト・横断検索・ファセット型ナビゲーション・詳細検索・パーソナライズ機能を扱います．
抜き書き
- オートコンプリート（Autocomplete）
- （オートコンプリートが解決する問題は）第一に，文字入力には時間がかかること．第二に，ユーザーがスペルを間違えやすいこと．第三に，入力するキーワードが思いつかない場合が多いこと．(p.89)
- 注目すべきなのは，オートコンプリートとオートサジェストは概念上は別物なのに，ほとんどのアプリケーションが省スペース目的でそれらを合体させていることだ．（p.90）
- 視覚的なオートコンプリート（p.90）
- ベストファースト(Best Frist)
- 横断検索
- 婦談検索は，データモデルが異なる複数の情報源から集めた動的なコンテンツを扱う場合に必要となるだろうが，そこには課題が生じる．まず何よりも，パフォーマンスがとんでもなく悪化するおそれがある．（p.99)
- 横断検索の実現によって，ファセット型ナビゲーションなどの高度なアプローチが難しくなる恐れもある．(p.99)
- すべてのコンテンツを一つの統合されたインデックスにまとめて，断片化を解消してもいい．（p.99）
- 横断検索が重要となる理由は，ユーザーがどこを探せばよいかしらないことにある.（p.100）
- ファセット型ナビゲーション（Faceted Navigation）
- キーワード検索に始まり結果一覧に目を通すまでの従来の流れの中で，統合的かつ漸進的検索とブラウジング体験を生むところにある．（p.102）
- コンテンツとその体系についての深い理解をもたらし，次に役立つさまざまなステップを示すカスタマイズされたマップ（通常は結果一覧の左側に表示される）の役目も果たす．
- ユーザーの行動とボックスが出会うところには，検索結果を絞りたいというニーズが必ず生じるからだ．（p.107）
- 詳細検索（Advanced Search）
- 詳細検索は往々にして，めったに使われない邪魔者でしかなく，エンジニアやデザイナーの手抜きを招く原因となる．(p.109)
- 詳細検索は横断検索と同様に，僕らがさらなるアイデアを探し求めるきっかけとなり，さまざまな実験や探索をおおらかに認めてくれる活動の場として役立つのだ．（p.112）
- パーソナライズ機能（Personalization）
- パーソナライズ機能はカスタマイズ機能と混同されがちだ．（p.113）
- ほとんどのアプリケーションでは大部分のユーザーがカスタマイズなどしていない．（p.113）
- 過去に欲しかったアイテムに基づいて現在または未来の興味関心や購入意欲を予測しても，失敗に終わることが多いというのが一番の問題なのだ．（p.114）
- 限られた状況でしか，過去の実績から未来の望ましい結果は予測できないだろう．（P.118）
ここであげられているパターンは，全てが等価ではありません．横断検索や詳細検索は，パターン自体よりも，それが生み出す可能性のあるもの，インデックスの統合や革新的な検索方法（鼻歌による音楽検索・手書き画像検索・色検索），への期待から取り上げられています．また，パーソナライズ機能もオートコンプリートやベストベットのパターンとの相性の良さを説明しつつも，動的かつ明示的に検索結果を調整できるファセット型ナビゲーションのパターンが有用であるケースが多いと指摘されています．そして，オートコンプリート・ベストベットは普遍性の高い重要なパターンとされています．この特に重視されている２つのパターンの大学図書館蔵書OPACへの適用を考えてみます．
- オートコンプリート
現状，国内の大学図書館システムベンダー大手４社（NEC・リコー・富士通・NTTデータ九州）でオートコンプリートの機能を有する蔵書OPACはありません．（3月1日追記．NECの図書館システム E-Cats Library にはオートサジェストの機能が含まれてました．サジェストの候補は数年間分の所蔵図書の書名・著者名のフィールドのデータを利用しているそうです．大谷の確認不足により失礼しました．）ただし，OPAC検索ログを使ったキーワード補完計画 - マイタンwiki で，近いことは試みられています．マイ探で試みられているように，蔵書OPACの検索ログを活用して，オートコンプリートは近いうちに実装されるかもしれません．この場合は検索語とその後にクリックした書誌の対応を調べることで，オートサジェストの機能も実現も考えられます．また，蔵書OPACをりようするということは，探しているコンテンツが図書・雑誌・論文といったものに限定されていると思われるので，タイトルフィールドのデータを利用してオートコンプリートの候補として活用できるのではないでしょうか？オートコンプリートというより，インクリメンタルサーチ - Wikipedia になりそうですが．
- ベストベット
先にあげた４社の蔵書OPACでは，タイトル・出版年・著者名・書誌IDなどいずれかの基準でソートした結果を表示させるようになっています．これをよりユーザーに最適な候補を上位に表示するにはなんらかのカスタマイズが必要です．一例として考えると，新しい情報を上位に表示するというのは，ユーザーにとって意味があることですので，これをベースにします．次に重み付けにつかえそうなデータは貸出回数です．ただ，単純に貸出回数を利用すると，古くから所蔵されている本が有利になります．同じ貸出回数でも，より最近借りられている本を重要と見なすなどの調整が必要となります．このほかに，大学ならではの教員のシラバス指定図書に重み付けをすることも考えられますし，パーソナライズが可能であるならば，ユーザーの所属する学部情報の活用や協調フィルタリングの手法をもとにユーザーに応じて表示順をカスタマイズできるはずです．
- 所感
OPAC同士の機能比較をするのは一部の研究者と図書館員だけです，ユーザーは比較するとしたら自分が普段利用しているGoogleなりAmazonとの比較のもとに，OPACを評価するはずです．この章のデザインパターンの様に，検索技術の世界で得られた知見をもとにきちんと取り込んでいく必要があると考えます．また，図書館のOPACについて考えるとき，ユーザーの労力を減らし，利便性を高めることは重要ですが，単館の所蔵目録の中から最適解とおぼしきものを提供するだけでなく，背後には単館の所蔵目録を越えた広範なコンテンツの世界があることをユーザに伝えることができるような検索サービスを提供したいと改めて思いました．
