Vol. 29 No. 2 May Wiki ML Wiki qwikweb ML foobar ML Wiki Wiki 1 qwikweb Wiki Wiki ML Wiki ML Wiki Wik

(1)

コラボレーションシステム

qwikWeb

の実装

江渡浩一郎

グループによる共同作業を支援するシステムとして，メーリングリストと Wiki を統合したコラボレーションシステム qwikWeb を実装した．本システムは，人々が一般的に利用する電子メールをコミュニケーションの媒体として用い，そこにコラボレーションのためのシステムとして Wiki を組み合わせることによって，知識の集約・構造化をシームレスに行えるようにした．本論文では，コラボレーションシステムに関わる背景から，設計，実装に係る知見を述べる．

I implemented a collaboration system “qwikWeb” which integrated mailing lists and a Wiki system. The system uses E-mail as daily communication media and a Wiki system for collaboration. The users can collect and manage knowledge seamlessly. In this paper, I describe background of collaboration system, design choice and implementation.

1 はじめに

近年，知識生産に関わる労働者は，1つの組織の枠にとどまらずに他のさまざまな専門家と共同作業を行うことが一般的になってきている．時間や場所を共有しない人々の共同作業では，必然的にインターネットが中心となる．本論文では，そのようなインターネットを使った小規模なグループにおける共同作業に焦点をあて，グループのメンバが互いにコミュニケーションを行いながら，共同で知識を集約・構造化できるシステムを構築する．まず，現在すでに広く一般に利用されているシステムから構成する要素技術を選定することとした．電子メールは，インターネットにおいてWebと並んでもっとも広範囲に利用されているコミュニケーションシステムである．Wikiは，ブラウザ上で容易にページを閲覧・編集できるコラボレーションシステムであ

Implementation of Collaboration System qwikWeb. Koichiro Eto, 独立行政法人産業技術総合研究所,

Na-tional Institute of Advanced Industrial Science and Technology (AIST). コンピュータソフトウェア, Vol.29, No.2 (2012), pp.140–157. [ソフトウェア論文] 2010 年 11 月 14 日受付. る．しかし，電子メールは知識を構造化して共有するのに向かないという欠点があり，Wikiは初心者が参加するにはハードルが高いという欠点がある．このような電子メールとWikiという2つのシステムを統合したコラボレーションシステムqwikWebを構築した．qwikWebでは，日常的に使いなれているプラットフォームとしての電子メールを入り口として用いることによって，日常的なコミュニケーションの延長としてコラボレーションを行うことができる．また，Wikiによる柔軟な情報整理能力によって，コミュニケーションから生まれた情報を円滑に蓄積・整理・共有できる．このように電子メールとWikiという多くの利用者に支持されているシステムを援用することで，学習コストを下げ，動機付けから行為までを短くすることを目指した． qwikWebは，高林哲と増井俊之によって開発された，平易な操作でメーリングリスト(以下，ML)の立ち上げや運用が行えるML管理システムQuickML を基盤技術として採用している．そのため，qwikWeb はQuickMLが持つ平易な操作性や管理者に負担が集中しないといった特徴を受け継いでいる． qwikWebシステムの利用方法を簡単に説明する．

(2)

図1 開設された Wiki．ML でのやりとりがそのまま Wiki ページとなっている． qwikWebシステムの利用は，まずMLの利用から開始する．利用者は，そのグループ名をfoobarだとすると，[email protected]にメールを送信することにより，MLを開設できる．同時に，同名のWiki サイトが作られる．この場合のWikiのアドレスは http://qwik.jp/foobar/となる．図1にqwikWeb のWikiサイトの画面を示す．このWikiサイトは， MLの参加者だけがアクセスできるプライベートな Wikiサイトとなる．MLに送られたメールは自動的にWikiページとしてWikiサイトに蓄積され，メールの件名毎に同じWikiページにまとめられるため，利用者は同じトピックに関するメールをスムーズに閲覧できる．メンバがWikiサイト上でページの作成・編集を行った際には，その編集についての報告メールがMLに送られる．これによって常にWikiサイトをチェックしていなくても，MLのメンバはいつWiki サイトが更新されたのかがわかる．このように，メールとWikiの特徴を組み合わせることによってコラボレーションをスムーズに進めることを狙ったシステムとなっている．本システムは，共同作業に関する既存システムの調査を元に，要素技術の選択やその組み合わせの手法を検討し，電子メールとWikiという2つの既存技術を統合したシステムとして設計することを決めた．そのような背景について2章で述べ，設計については3章で述べる．本システムの実装においては，当時黎明期にあった Webアプリケーションの構築手法から，先端的と思われる手法を積極的に用いて実装することとした．具体的には，プログラミング言語Ruby，メタプログラミング，アジャイルソフトウェア開発，RESTアーキテクチャスタイルなどを導入している．そのような実装に関する知見を4章で述べる．本システムは無償で使えるコラボレーションシステムとしてインターネット上で一般に公開した．それによって，特筆すべき利用が見られた．また，フリーソフトウェアとして公開することによって，実験環境以外の利用が見られた．本システムの運用結果と考察について5章で述べる．6章にて，本論文をまとめる．

2 背景

本システムの構想にあたり，既存のコラボレーションシステムやコミュニケーションシステムの調査・分析を行った．そこから既存システムの問題点について

(3)

まとめた．また，実装において背景となる知見についても述べる．

2. 1 既存のシステム

2. 1. 1 コラボレーションシステム

コンピュータを共同作業の道具として用いる研究は，

1968年にDouglas Engelbartが発表した NLS(oN-Line System，オンラインシステム)にまで遡る[3]．

Engelbartはマウスの発明者として知られているが，同時にネットワーク接続されたコンピュータを用いた

利用者間の共同作業，つまりCSCW(Computer

Sup-ported Cooperative Work)[7]という概念の生みの親

でもある．Engelbartに影響を受けたAlan Kayは，

1972年にDynabook構想[8]を発表した．Dynabook 間は無線接続され，利用者間で共同作業を行えることとされていた．このように，ネットワーク接続されたコンピュータ間の共同作業という構想は，パーソナルコンピュータという概念の誕生の段階にまで遡ることができる． 1991年，Tim Berners-Leeは研究所内の研究者間の文章共有を目的とした情報共有システムWorld

Wide Web (Web)[2]を公開した．異なった文化的背景・技術力を持つ人々が協調して作業を行えるように既存の文章フォーマットの最大公約数として

HTML(HyperText Markup Language)を設計した．

Berners-Leeによる最初のブラウザは閲覧だけではなく編集機能も備えており，ブラウザで閲覧しているページをその場で編集できた．後に普及したNCSA Mosaicなどのブラウザには編集機能は内蔵されていなかったため，最初期にあった閲覧と編集が共存する環境は失われてしまった．

1995年，Ward CunninghamはWebページの共

同編集システムとしてWikiWikiWeb (Wiki)[9]を公開した．利用者はブラウザからWebページの閲覧をしつつ，そのページを編集したい場合は「編集」というリンクを辿ることで編集画面が現れ，ブラウザ上で編集できる．当時Cunninghamはプログラミングにおいて繰り返し現われるパターンについて研究しており，同じテーマに興味を持つメンバとMLで議論していた．このMLに流れた情報を蓄積・整理するために作られたのがWikiである[5]．このように，最初期のWikiでは，コミュニケーションシステムとしてのMLを用い，その情報集約のためのコラボレーションシステムとしてWikiを使っていた．後に，Wiki はコミュニケーションにも用いられるようになり，コミュニケーションとコラボレーションが共存する環境へと発展していった．ネットワークが一般に普及するにつれて，コラボレーションのためのシステムとしてグループウェアが

誕生した．その代表例が，Lotus Notes†1である．Web

が一般に普及した後には，ブラウザ上で動くグループウェアが使われるようになった．サイボウズ†2のようにスケジュール調整機能やテーブル機能，1つの文書を共同で作成する機能を持つシステムが普及している．一般にグループウェアは多機能なシステムが多く，MLや掲示板に相当する機能から，データベース，共同での文章作成機能など，さまざまな機能を保持している．そのためグループウェアは，コミュニケーションシステムとコラボレーションシステムの両方の特徴を合わせ持つシステムと言える．一般的に数千人規模の利用者数を想定しており，メンバをグループ化し，階層化する機能を備え，それによって複雑なアクセス制御を可能としている．多機能であるため機能の習得には時間がかかり，また管理の手間も発生する． 2. 1. 2 コミュニケーションシステムもっとも代表的なコミュニケーションシステムは，電子メールだろう．電子メールでは，宛先欄に送信先メールアドレスを指定し，件名・内容を記入して送信すると，相手に送信される．宛先に複数のメールアドレスを記入することで同時に複数人にメールを送信できる．メーリングリスト(ML)は，そのような複数人への電子メール送信を自動化するシステムである． MLは1つのメールアドレスとして表わされており，そのアドレスにメールを送信すると，登録されている全てのメンバへとメールが配信される．MLの利用形態は，大きく2つに分かれる．アナウンス用MLは，多数の宛先に一度に情報を広報するためのMLであ †1 http://www-06.ibm.com/software/jp/lotus/ †2 http://cybozu.co.jp/

(4)

表1 既存のシステムが持つコミュニケーション要素とコラボレーション要素の分類 コミュニケーションコラボレーション修得の容易さ電子メール ○ × ◎ ML ◎ × ◎ 掲示板 ○ × ◎ ブログ ○ × ○ グループウェア ◎ ◎ × WikiWikiWeb △ ◎ ○ る．メールマガジン(メルマガ)などと呼ばれるML 利用形態もこの一種であり，少数の情報発信者と多数の情報受信者とに分かれている．議論用MLは，登録されたメンバが互いに意見や情報を伝えるための MLである．MLに登録されたメンバは誰でもメールを送信できる．企業内やサークルなど組織内での連携や共同作業ではMLによる連絡や協働が行われているが，それは主にこの議論用MLである．一般にMLのメンバの参加および脱退はMLの管理者が行う．少数の管理者のみが権限を持つことで，適切なメンバ管理を行えるという利点があるが，管理者に多くの負荷がかかってしまうという問題点がある．高林哲と増井俊之によって開発されたQuickML [12]は，平易な操作でMLの立ち上げや運用が行える ML管理システムである．QuickMLではメンバ全員がメンバの参加・脱退操作の権限を持つため，管理者 1人に負荷が集中するという問題が発生しない．掲示板は，さまざまなカテゴリーで分類された場に利用者がメッセージを投稿し，同じ掲示板を見ている他の利用者とメッセージを交換するシステムである． Web誕生以前からネットニュースというシステムが使われており，Web普及以後はWeb上の掲示板システムが一般的となった．各々のメッセージは，日付，投稿者名，タイトル，内容などのフィールドを持ち，一般に時系列に並んで表示される．情報を構造化する手段を持たないため，繰り返し同じ議論が発生するといった問題がある．ブログは，個人が自分の興味のあるテーマについて記事を執筆し，継続的に記事を公開するWeb上のシステムである．各々の記事は，日付，執筆者名，タイトル，内容などのフィールドを持ち，一般的には記事は時系列にまとめられる．閲覧者は各々の記事毎にコメントを残すことができる． 2. 1. 3 既存システムのまとめ既存のコラボレーションシステム，コミュニケーションシステムについて調査・分析した結果を，コミュニケーションとコラボレーションという2つの要素で表1にまとめた．コミュニケーションとコラボレーションの両方を兼ね備えたシステムとしてグループウェアが存在しているが，修得の容易さという面で問題があることがわかる． 2. 2 コラボレーションシステムの現状分析 2. 2. 1 既存システムの問題点筆者は，ターゲットとなる利用者の一例として，身近な研究者の共同作業に着目した．彼らは日常的にメールを主とする連絡手段を利用している．ある特定のメンバ間の連絡が一定期間以上持続する場合には，MLを使って連絡することが多い．しかし，ML を使った共同作業の場合には，情報の蓄積・整理・共有が難しいという欠点がある．添付ファイルを用いてファイルを共有している場合は，どのファイルが最新のファイルなのかがすぐにはわからなくなる．全てのメールを読んで修正や統合をしないと最新の状況が把握できず，知識の構造化や共有上問題がある．時系列に並べられたメッセージを基本とする掲示板やブログも，同様な問題を抱えている．このような共同作業を支援するためのシステムとしてグループウェアが存在している．グループウェアは共同作業を支援するために多種多様な機能を備え

(5)

ているため，グループのメンバ全員がグループウェアの機能を使いこなすことができれば，原理的には問題は解決するはずである．しかし実際には，グループウェアを利用した共同作業は，自発的に行われることはほとんどない．利用者はすでにMLによるコミュニケーションを開始していることが多く，確実に連絡がとれるMLを使って連絡をとってしまう傾向がある．また，近年は組織の枠を超えた共同作業を行うことが多く，その場合にはイントラネット内に設置されたグループウェアを使うことはできない．前述のように，グループウェアにはノウハウを修得する時間がかかるという欠点もある． 2. 2. 2 Wikiの特徴ここで，CunninghamによるWikiに着目する．2 章で述べたように，元々Berners-Leeが考案したWeb は利用者間の共同作業を目的としており，初期のWeb ブラウザは閲覧と編集が共存する環境だった．Wiki は，そのような初期のWebが備えていた共同作業のための環境，閲覧と編集が共存する環境を，現代の Webによみがえらせたという特徴を持つ．つまり， WikiはWebというメディアの特性を最大限に生かすことができる情報共有システムであると言える． Wikiによるコラボレーションの特徴を考えるために，利用者から見たメッセージの性質の違いについて，既存のコミュニケーションシステムとWikiの比較を行う．一般にメールや掲示板などのコミュニケーションシステムは，下記の特徴を持つ． 1つのメッセージにつき1人の執筆者が想定されている．そのため，一般にメッセージ毎に情報発信者の欄が1つあり，各々の文章は執筆者が主語となった特定の相手に向けた主観的文章として構成される．時系列にメッセージが並べられる．メッセージは送信・投稿時の日時で管理され，時間順にメッセージが並べられることが多い．各々のメッセージが独立している．各々のメッセージは独立した文章であり，他の文章へのリンクを文中に埋め込むための簡単な手法は提供されない．メールやネットニュースの場合は，メッセージ間の返信の連なりをスレッドとして表示してくれる場合がある．しかし，あるキーワードから別のメッセージへリンクを張るといったハイパーテキスト機能は存在していない．平文である．一般にメッセージは平文で記述することになっていて，見出しやリスト表記などといった文章を構造化する手法は用意されていない． Web誕生以後に生まれたシステムであるブログでは，構造化文章を記述できるし，リンクを埋め込むこともできるが，1つの記事につき1人の執筆者が想定されている，一般に記事を時系列で整理するといった点は変わっていない．これに対して，Wikiにおける文章は下記の特徴を備える．全ての文章は共有された文章となる．Wikiにおいては，各々のページは執筆者という欄を持たない．誰でもどのページでも書き換えられるし，署名を残さなければ誰が作成・編集したのかの情報も明示されない．各々の文章は誰が作成・記述したのかが自動的に明示されるという文化圏の常識からはかけはなれており，さまざまな文化的な摩擦が生じる．そのため， Wikiサイトの利用者間で作法を共有し，システム上の強制力は無いが，互いにそれを守ることでサイト運営が進められる．たとえば，元々のCunninghamによるWikiでは，各々のページはDocumentModeや ThreadModeなどの状態を持っており，ThreadMode のページでは各々の利用者の主観的文章を署名と共に投稿するが，DocumentModeのページでは主語を持たない客観的文章を書くという作法になっていた[5]．ハイパーテキストである．ページ中の特定の単語を鍵として，他のページに容易にリンクを貼ることができる．各々のページはリンクされた単語によって一意に意味が特定される．Wikiサイト全体で1つの全体的なつながりを持った情報を構築するという作法があり，リンクによるページ間の結びつきによってサイト全体が構築される．1つのページで全ての情報を網羅する必要はなく，既存の情報を参照すればよい場合には，既存のページへリンクを貼ることで，既存の情報への集積・再利用が促される．構造化文章である．基本的には平文で文章を記述できるが，文頭に「*」や「-」などの記号を置くことで，見出しやリストなどを容易に記述できる．そのた

(6)

め普段は平文で情報を追加しつつ，構造化が必要な場合には適宜編集することで，構造化文章へと発展させていくことができる． Wiki上の文章は，このような特徴を備えている．全体として，コミュニケーションにおける文章は，時系列に並べられた主観的文章の連なりであり，明確な構造を持たない．それに対してWikiにおける文章は，各々のページは標題となる単語によって一意に意味が特定され，相互にリンクされたハイパーテキストによってサイト全体で意味が構成される．この文章の特性の違いは，情報のフローとストックの違いとして説明することもできる．コミュニケーションにおける文章はフローとして流れていく情報であり，その場の状況に応じて必要とされる情報交換が行えればそれでよい．それに対してWikiにおける文章はストックとして蓄積される情報であり，必要に応じて何度も参照されることが想定される．Wikiによる再利用を前提とした文章は，結果として知識の蓄積・構造化・共有に大きく役立つと考えられる．つまり，コミュニケーション(フロー)とコラボレーション(ストック)の両方をシームレスに扱えるシステムが求められていると言える． 2. 3 実装における背景本システムの設計を行った2003年8月は，Web上で動くアプリケーション，いわゆるWebアプリケーションという言葉が使われる始める黎明期にあたった．ちょうどWebアプリケーションを実装するために必要な要素技術が誕生しつつある時期だった．その代表例がプログラミング言語Ruby†3である． 1995年にまつもとゆきひろ氏によって作られた国産のオブジェクト指向プログラミング言語であり，現在はWebアプリケーションを構築するための代表的な言語となっている．RubyでWebアプリケーションを記述するためのWebアプリケーションフレームワークとしてRuby on Railsが有名だが，最初のバージョンがリリースされたのが2004年7月である．当時は広く使われるRuby用のWebアプリケーション †3 http://www.ruby-lang.org/ フレームは存在していなかった．エクストリームプログラミング(以下，XP)[1]は， 1999年にKent Beckによって提唱されたソフトウェア開発手法である．ソフトウェア開発において良いとされる知見を極端なまでに実践しようという発想から考え出されており，各々の知見はプラクティスという言葉で表わされている．たとえばテストファーストは，プログラムのテストコードを先に書き，その後にテストケースを通過するように実際のプログラムを書くという順番で開発を進める手法である．現在ではより一般的にテスト駆動開発という言葉で説明されるようになっている． Webシステムの設計においては，Webを分散オブジェクトの実行基盤として用いるSOAP (Simple

Object Access Protocol)が提案され，HTTPをオブジェクト呼び出しモデルの基盤として使われることが見られるようになっていた．しかし，それに対

してHTTPの仕様策定で重要な役割を果したRoy

Fieldingは，2000年に博士論文の形でREST

Ar-chitectural Style[6]という，最初期のWebの設計

に立ち戻るような設計指針を示した．RESTは，Web をリソースの集合としてとらえ，各々のリソースは URIを持っていて，そのURIに対する少数の動詞 (メソッド)で操作できるように構築するというアーキテクチャのスタイル(設計指針)を規定している．この指針は，Wikiのようにページの表示と編集の組で設計されるシステムの理念とよく合致していた．

3 設計

3. 1 設計方針前節で述べたコラボレーションシステムにおける課題を利用者の立場から捉えなおし，本システムは，すでに慣れ親しんだメールによるコミュニケーション環境を出発点とし，徐々にWikiを使ったコラボレーションを行えるようなシステムとすることとした． MLを基盤としたシステムにすることによって，グループのメンバはメールによるコミュニケーションを随時行うことができる．また，メンバがWikiを使って編集を行った場合には，その情報がMLだけを読んでいるメンバにも適切に伝わるように設計すること

(7)

にする．日常的なコミュニケーション手段であるメールをシステム利用の入り口として位置付け，必要に応じてシームレスにWikiによる知識の集約・構造化・共有を行えるようにし，メールとWikiが連携するシステムを設計することとする． MLのメンバ管理の容易さを確保するために，ML 管理システムとしてQuickMLを採用する．QuickML の特徴により，管理者1人に負荷が集中するという問題が発生しない．グループウェアはコミュニケーションシステムとコラボレーションシステムを統合したシステムだが，管理と習得の難しさが問題となっていた．グループウェアには複雑なアクセス管理機構があるため，数千人規模の大規模な組織でも導入できるという利点があるが，本システムでは数人から数十人規模の比較的小規模なグループを想定しており，その場合は管理の手間が大きいということが欠点となる．本システムでは，グループのメンバは全員が同じ権限を持つという前提条件を置いた．もしどうしても利用者をグループ分けしたい場合には，目的毎のMLを別々に作成し，複数のグループを使い分けるという使い方を想定した． 3. 2 qwikWebの設計

qwikWebは，要素技術としてQuickMLとWiki

技術を用いているが，利用者にとっては，MLとWiki の機能が連携したシステムと見えるように実装した． 1章で述べたように，利用者はqwikWebシステムにメールを送信することで，MLとWikiサイトを開設できる．このMLに登録されたメンバの集合を，グループと呼ぶ．作成されたWikiサイトはMLのメンバだけがアクセス可能である．メンバの追加はメールでもWikiでもいずれからでもできる．Wikiページは全てバージョン管理されているため，誰かが誤って削除しても復帰可能である． MLに送られたメールは，新たなWikiページとしてWikiサイトに自動的に蓄積される．メールにファイルが添付されていた場合は，Wiki上にてそのファイルが共有される．MLに送られたメールにはそのメールのフッタに対応するWikiページのアドレスが記述される．メーラからこのアドレスをクリックすれば，対応するWikiページを即座に表示できる．逆に Wiki上で誰かがページを作成・編集した際には，その編集行為を報告するメールがMLに送られるようにした．このようにして，メールとWikiを相互に行き来することを容易にした．利用者は，最初はMLによるコミュニケーションシステムとして使い，共同作業を行う場面になったら，Wikiによるコラボレーションシステムへとシームレスに移行できる．Wikiの利用では，さまざまなプラグインの利用など発展的な機能があるが，そのような機能があることを最初から知っている必要は無く，単に平文で文章を書いていくだけでよい．グループのメンバの中に1人でもWikiの使い方に詳しい人がいれば，その人の使い方を真似ることによって，自ずとWikiの習得が進むと考えた．このように，段階的に習得が進むように設計している．一般に，セキュリティの確保とユーザビリティの確保はトレードオフの関係にある．qwikWebにおいては，IDをメールアドレスとし，パスワードはシステムが自動生成したもののみを使えるようにした．パスワードを自分の好きな文字列に設定できる機能を提供すると，利用者はどうしても他のシステムと共通のパスワードを使ってしまう．システム管理者としてはシステム管理に万全を期するつもりだったとしても，万が一システム管理に問題が生じた場合の対応をあらかじめ考えておくことが重要である．本システムではユーザのパスワードを保持しないため，本システムの枠を越えて，他システムにまで影響を及ぼすことをあらかじめ避けている．システムの運用の際には，グループが使われなくなった際に，削除される仕組みをあらかじめ検討しておくことが重要である．qwikWebでは，MLとWiki サイトが1ヶ月以上使われなかった場合，警告の後に自動的に削除される仕組みとした†4． †4 しかし，qwik.jp 運用中にバグが見つかったため，現 時点では自動削除機能をオフにして運用を継続している．何度かデバッグを試みたが，解決しなかったため，安全側に倒し，現在は自動削除機能を使用していない．必要に応じて，管理者が目視で確認をした上で不要になったグループを削除している．そのため現時点では，定期的にグループ削除を行う手間が発生してしまっている．

(8)

4 実装

4. 1 実装方針

qwikWebは，要素技術としてのQuickMLとWiki

サーバが連携したシステムとして実装する．本システムのWikiサーバ部分(以下，Wikiサーバ)の開発においては，2003年当時のWebシステムにおける知見を最大限に活用し，単に実用的なWebシステムとしてだけではなく，Web上のシステムとして理想的な解は何かを考え，その理想にできるだけ近付けるように開発を進めることとした．さまざまな先端的なソフトウェア開発手法を取り入れ，それによって効率性・安全性・柔軟性がどのように変化するのかを観察した． 4. 1. 1 プログラミング言語実装に使う言語としてはプログラミング言語Ruby を選択した．Rubyは1999年に最初の書籍[10]が発売されるなど普及の兆しが見えていたが，2003年当時はまだ日本国内での利用事例が主だった．Rubyを使ったWebアプリケーションとしては，tDiary†5がもっとも知られた存在だった．Rubyは純粋なオブジェクト指向プログラミング言語であり，メタプログラミングを容易に行えるという性質を持つ．要素技術として使うQuickMLもRubyで記述されていることと，言語としての性質の良さから，Rubyを選択することにした． Webアプリケーションを構築する際には，現在では Webアプリケーションフレームワークを使って記述することが一般的である．しかし，当時は広く共通に使われるWebアプリケーションフレームワークは存在していなかった．Rubyで書かれたCMS(Content Management System)もほとんど存在していなかったため，tDiaryをCMSに転じて利用するケースも見られた．Wikiサーバを構築したいだけならば，どのような手法でも構築できるが，今回はWikiサーバを基盤としてさまざまなWebシステムにおける実験を行いたいと考えた．そのため，独自のWebアプリケーションフレームワークを構築する部分から実装す †5 http://www.tdiary.org/ ることとした． 4. 1. 2 Webシステム Webシステムを構築する際は，Apache httpd†6などのWebサーバ上で，CGIなどのインタフェースを使って連携させることで構築することが一般的である．しかしこの手法では，インタフェースの制約によって Webシステムとして実現できる範囲が狭まるという欠点がある．たとえば，CGIを使う場合はURIの設計の自由度が低くなってしまう傾向がある．Webシステムとして最大限の自由度を確保するために，Web サーバと連携して動くのではなく，Webサーバ自体を含めた単一のプロセスとして実装することとした． Rubyは標準ライブラリの1つとして，Rubyのみで記述されたWebサーバWEBrick†7が付属する．こ

のWEBrickをWebサーバとして使ったWebアプリケーションフレームワークを構築することとした． Webシステムの設計では，URIの設計を重視した． URIを見ることだけで，行おうとしている操作がわかるように，可読性の高いURIを用いることとした．その際の設計指針として，RESTアーキテクチャスタイルに準拠した．RESTでは，多様なリソースを少数のメソッド(動詞)で操作することを基本としている．Wikiは，さまざまなページを閲覧・編集の2 つの動詞のみで操作することを基本としている．このような類似点があることから，Webシステムの設計指針としてRESTを参考にすることにした． Wikiサイトの運営においては，Wikiページの編集だけでなく，Wikiサイトのタイトルを決めるなど，サイト全体に関わる設定を編集する場面がある．そのような場面では，Wikiサイトの設定項目を決める操作を別途システムに組み込むのではなく，そのようなメタなパラメータをも1つのWikiページとして扱い，メタなWikiページを編集することでWikiサイトの設定を切り替えるという手法を導入した．これによって，Wikiサイトの設定をする画面を実装することなく，単にページ編集のメカニズムをそのまま用いることで，設定変更を行えるようにした． Webアプリケーションフレームワークとしては， †6 http://httpd.apache.org/ †7 http://www.webrick.org/

(9)

Rubyを使っていること，プロセス内にWebサーバを内蔵しているためURI設計の自由度が高いこと， RESTアーキテクチャスタイルに準拠していることから，URIとプログラム上の処理を1対1に対応させることができる．そのため，メタプログラミングによってURIとメソッド名が自動的に対応する仕組みにすることにした†8．システムに処理を追加する場合には，そのURIに対応したメソッド名のメソッドを追加するだけでよい． Wikiの仕組みとして，ページ文中にプラグインを埋め込む仕組みがあることが一般的だが，本システムでもプラグインを柔軟に埋め込むことができるようにした．プラグインの仕組みとして，1行の中に収まるプラグインと，複数行にわたるプラグインの2種類を想定し，その両方のプラグインを柔軟に記述することができるようなフレームワークとした．これによって，Wikiサーバの運営者は必要に応じて独自の機能を追加することができる．ストレージとしては，データベースは使わずにファイルシステムをそのまま使うこととした．ストレージとしてMySQLなどの大規模なデータベースを使うとデータ操作の自由度が高まるという利点があるが，データの中身を見るのにSQLのインタフェースを使う必要があるなど，システムの保守・運用に手間がかかる．今回はWikiサーバを動かすという目的が特定されているため，サーバ管理の手間と照らし合わせて，ファイルシステムのみを使うこととした． 4. 1. 3 ソフトウェア開発手法一般に，実用に供するシステムと研究のためのシステムとは相反する性質を持つ．実用に供するシステムでは，システムの安定性を重視するため，新機能の追加は慎重になるべきである．それに対して研究のためのシステムは，思いついた新機能を即座に導入で †8 Ruby でメタプログラミングを採用した Web アプリ ケーションフレームワークとしては Ruby on Rails がよく知られているが，最初の公開は 2004 年 7 月であり，qwikWeb のソースコードを公開した 2004 年 4 月時点ではまだ登場していなかった．Web アプリケーションフレームワークの URL 設計手法にメタプログラミングを使用するアイデアは独自に考案したものである．しかし，Rails ではメタプログラミングを徹底的に活用しており，採用レベルには違いがある．きるシステムの方がよい．しかし，新機能を追加すれば自ずとバグも発生し，システムは不安定になり，場合によってはシステムが停止してしまうこともある．この両者を同時に実現しなければ，実用的なシステムであることと研究目的のシステムであることを同時に満たすことはできない．筆者は2001年ごろよりXPというソフトウェア開発手法に興味を持ってきた．XPは一般にチームでの作業を円滑に進めるためのプラクティスであり，1人で開発を進める場合には導入できない．しかし，テストに関わるプラクティスは導入できるため，本システムの開発ではテストファーストを導入することとした．まず最初にWebシステムとしての動作テストのためのコードを記述し，その後にテストに対応したコードを記述する．この手順を守ることによって，全ての動作に対応するテストコードが存在することになる．このテスト記述の徹底は，フレームワークの仕様設計にも影響を及ぼした．フレームワークの仕様を検討する際に，いかにテスト記述を効率的に行えるかという観点を導入した．コードの記述とテストの記述をできるだけ物理的に近付けるようにして，互いの記述を同時に見直していくことができる記述方法にした．このような工夫によって，実装の際に徹底した機能テストを行うことができた．なんらかの新しい機能を追加した場合でも，全機能テストを実行するだけで，他の動作に影響を及ぼしていないかどうかを確認できる．これによって，長期間にわたって運用を続けると同時に，適宜機能追加・変更が行えるような開発体制を作ることができた． 4. 2 Wikiサーバの実装 4. 2. 1 クラス構造 qwikWebの代表的なクラスを紹介し，クラス構造を説明する． Qwik::Config Wikiサーバ全体の動作を決める設定を保持する．Wikiサーバ毎に1つのインスタンスを持つ．Wikiサーバ動作中は変更されない． Qwik::ServerMemory Wikiサーバの状態保持

(10)

やキャッシュなどに用いる．

Qwik::Session WebブラウザがWikiサーバにアクセスし，情報がやりとりされ，切断されるまでの一連の流れをセッションと呼ぶが，そのセッション毎にSessionクラスのインスタンスが生成される．インスタンスは，ブラウザへの返答後に消滅する． Qwik::Request クライアントからのリクエスト情報を保持するインスタンス． WEBrick::HTTPRequestによる情報を元に生成される． Qwik::Response ブラウザへのレスポンス情報を保持するインスタンス． WEBrick::HTTPResponseへと変換され，クライアントに渡される． Qwik::Action 1つのセッション毎に，Action クラスのインスタンスが生成される．Config,

ServerMemory, Request, Responseの4つのイ

ンスタンスを受け取り，Action#runというメソッドが実行され，Request情報を元に必要な処理を行い，ブラウザに戻す情報をReponseに格納し，クライアントに返して，1つのセッションが終わる．セッション動作の中核となるクラスである．

Wikiサーバが起動すると，Config，ServerMemory

のインスタンスが作られる．ブラウザからアクセスがあると，Sessionのインスタンスが作られ，Requestと Responseのインスタンスの組を保持する．Request とResponseの組がActionのインスタンスに渡され， runメソッドが実行される．結果は全てResponseのインスタンスが保持しており，その内容をブラウザに返して，一連のセッションが終わり，Sessionのインスタンスが解放される．つまり，1つのセッションは， Requestインスタンスを受け取り，Responseインスタンスを返すという形で抽象化されている． Webアプリケーションは，Webブラウザと情報をやりとりすることによって動作する．そのため，Web アプリケーションのテストは，通常であれば毎回Web ブラウザを人間が操作することによって動作確認を行わなければならず，大変な手間がかかる．しかし，本システムのWebアプリケーションフレームワークでは，1つのセッションがRequestとResponseの組で抽象化されているため，テストしたい状況に対応した Requestインスタンスを作り，実行し，Responseインスタンスが保持する内容が期待した内容と合致するかどうかを調べることで，1つのSessionに対応した動作を確認することができる．このようにセッション構造の抽象化が，テスト記述に役に立っている． 4. 2. 2 Actionクラスの構造クラス構造としては，Session動作に関係するメソッドは，全てActionクラス1つが保持する構造になっている．Actionクラスは，Wikiサーバの動作に関するあらゆるメソッドが集まっていて，大クラスを形成している．クラス数が少ないため理解しやすいという利点があるが，結果としてKitchen-sinkのようにごちゃごちゃした構成になってしまい，機能間での名前空間の分離が適切にできなかったという反省もある†9．このとき，Actionクラスのメソッド名は，URIにおける識別子をそのままメソッドの一部として使う．ある特定のメソッド名のメソッドを定義するだけで，あるURIに対応した機能をすぐに追加できる．下記にその対応を述べる． plg ページ中に埋め込まれるプラグインを定義する．plg_helloというメソッド名は，Wikiページ中における{{hello}}というプラグインに対応する． ext ページを対象とした処理を行うエクステンションを定義する．ext_helloは， http://qwik.jp/foobar/TestPage.helloに対応しており，URIだけを見るとまるで拡張子のように見える．これは，TestPageというWiki ページに対してhelloという動詞で処理するという意味になる． act サイト全体を対象としたアクションを定義する．act_helloは †9 当時の筆者のメタプログラミングの知識が足りなかっ たことが原因である．現在設計しなおすのであれば，クラスの継承関係を用いて，各々の機能を別クラスとして設計できるようにするだろう．

(11)

図2 プラグインを記述するコードのサンプル http://qwik.jp/foobar/.helloに対応する．ある特定のページに対する操作というわけではなく，そのWikiサイト全体に対する操作を定義する際に用いる．このように，メタプログラミングによってメソッド名がそのままプラグイン名やURIに反映される仕組みとなっている．メソッド定義の実例を，図2に示す．ここでは，plg_helloとact_helloという2種類の機能拡張を行っている．

plg_helloは，ページ中に「hello, world」と表示

するというプラグインである．プラグイン引数をとる

ことができ，その場合はworldという表記が置き換

わる．ここで，プラグイン引数はメソッド引数という形で受渡しされている．

act_helloは，「hello, world!」というタイトルで，本文に「hi, there.」と書いてあるだけのページを表

示する．実際にはメソッド中でWikiページにアクセ

スしたり，なんらかの処理を行ったりする．このコード前半部分が機能拡張のメソッド記述であり，その後がテストコードの記述となっている．

(12)

test_plg_helloは，helloというプラグインの動作確認をしている．ここで，ok_wiという短縮記法のメソッドは，右にある引数をWiki記法のテキストだとして，それがレンダリング後に左のHTMLに置き換わることをテストするという意味である． test_act_hello は，Wiki サーバに対して「/test/.hello」というアクセスがあった場合に返すページをresに保持する．その結果となるHTML ページから，XPathによって指定されたエレメントを抜き出して，左側の要素と比較する．このように，ページ中のある特定の要素の中身を確認するというテスト記述を1行だけで書けるようにしており，このような簡略的な記法を用意することで，テスト記述に関わる開発者の手間を軽減できる．また，同じファイル中に機能のコード記述とテストのコード記述を同梱することによって，実装とテストコードとの対応関係をわかりやすくした．

5 運用

5. 1 アクセス解析実装したqwikWebを用いて，2003年8月から研究ベースの運用をqwik.jp†10にて開始し，2011年8 月現在も稼働中である．利用者は利用時に利用規約 (個人を特定できない形でデータが研究上利用されることなど)を承認の上，qwik.jpを利用することができる． 5. 1. 1 ML数の時間遷移 2011年8月時点でのML数は累計6,843個，利用者数は累計42,859人である．図3には，全グループ数，Wiki閲覧利用グループ，Wiki編集利用グループの累積値を示した†11．各MLの利用者数は，最大が 648人，平均は7.7人であった．半数以上が10人以下のMLであり，少人数でも手軽にMLを利用するという設計意図に合った利用状況と言える．また約 †10 http://qwik.jp/ †11 システム開発当初のログが残っていなかったため， ML は 2004 年 2 月から，Web は 2004 年 8 月から始まっている．また，システム障害のため 2011 年 2 月から 6 月までの Web サーバのログが保存されていなかったため，グラフが平坦になっており，正確な値が算出できていない． 75%のMLにてWikiが利用されており，多くの利用者はWikiも利用できる点を考えてqwikWebを選択していることがわかる．その中でもさらに53%のグループはWikiによる編集も行っている．つまり， Wikiを利用しているグループ中の70%は編集も行っており，Wikiを利用し始めたグループは，後にWiki の編集行為も行うようになることが一般的であることがわかる．2007年5月時点でのデータによれば， Wikiを利用した4,538グループの平均活動期間は 145.1日であるのに対し，利用していない1,116グループは42.4日であった．長期間利用するものほど Wikiが利用されていることがわかる．閉鎖ML数はその時点で約10%となっており，QuickMLにおける閉鎖ML数の50%と比較して低い水準となっており，知識蓄積に貢献していると考えられる†12． 5. 1. 2 利用者数の時間遷移利用者数の累積値を図4に示した†13．利用者数， Wiki利用者数，ML作成利用者数，いずれも純増している†14．利用者数の累計が42,859人で，そのうち42%(18,401人)がWikiの閲覧を行い，19%(8,230 人)がWikiの編集も行っている．Wiki利用MLが全体の約75%であり，Wiki利用者は約42%となったのは，前者はグループ中で1人でもWikiを利用していればカウントされるのに対して，後者は利用者単位のカウントであるためであり，Wikiを利用する人，利用しない人との傾向が分かれていることがわかる．グループにおけるWiki利用率が高いのは，多くの利用者がMLから誘導されてWikiを利用していたためと考えられる．MLを作成した利用者数は 10%(4,369人)となっている．1人が作成したML数の最大は40個，平均は1.6個であった．1人で最大 †12 2007 年 5 月の時点では，未使用 ML の自動削除機 能は正常に動作していたが，その後に自動削除機能を停止させたため，現時点では閉鎖 ML 数の数字は得られなくなっている． †13 図 3 と同様に，ML は 2004 年 2 月から，Web は 2004 年 8 月から始まっている．また，2011 年 2 月から 6 月までの Web サーバのログが保存されていなかったため，グラフが平坦になっている． †14 qwikWeb の仕様上，同一の利用者が複数のメール アドレスを使っていても区別できないため，正確には利用者数ではなくメールアドレス数である．

(13)

図3 グループ数の時間遷移

(14)

図5 時間帯毎の ML と Wiki との利用状況の違い 40個ものMLを立ち上げる利用者がいることから，管理者のコストが比較的低く抑えられていることが示されていると考える．約25%にあたる505人が2 つ以上のMLを作成している．一方，参加している ML数を見ると，18,519人のうち参加ML数最大は 48個，平均は1.3個であった．こちらも約20%にあたる3,515人が2つ以上のMLに参加していた．これは利用目的によって複数のMLを使い分けると想定した通りの使われ方になっていると言える． 5. 1. 3 時間帯毎のMLとWikiの利用状況の違い WikiとMLの利用形態の違いを，時間帯毎の利用総数の違いから調べた．図5は10分毎の投稿数， Wikiアクセス数，Wiki編集数であり，縦軸は投稿 (アクセス)総数における割合を示している．全利用者のうち機械的な方法によるアクセス(ボット)を排除している．17時の利用が減少しているが，これは定期メンテナンスのためである．利用者の国毎の分類などはしていないため，タイムゾーンは日本のものと仮定して分析した． WikiとMLの時間帯毎の利用の分布を比較する．まず，MLへの投稿には，12時∼13時30分，17∼19 時，そして21∼24時にピークがあることがわかる．それぞれ昼休み，就業終了時，就寝前にあてはまると考えられる．それに対して，Wikiの閲覧や編集は， 11∼12時にピークがあり，13時30分から17時30 分にむかってなだらかに上昇し，また21∼24時にむかってなだらかに上昇する．それぞれ午前の仕事，午後の仕事，夕食後の仕事にあてはまると考えられる．また，0時始まりのグラフであるため読みとりにくいが，0時(24時)ちょうどに大きな山がある．デフォルトでは1日の更新通知メールが0時ちょうどに送られるため，その送信を受けてWikiを確認する人が増えるためと考えられる． MLへの投稿はコミュニケーションであるため，休憩時間や業務の終了後に行われる傾向があるが，Wiki の閲覧や編集は作業と密接に関わるため，午前中，午後，そして夕食後といった仕事の時間帯に行われていることがわかる．特に昼休みの時間帯にはメールの利用とWikiの利用とが山型と谷型になっていて，明確に相反しており，休憩時間になったから作業の手を休めてメールでコミュニケーションするといった利用傾

(15)

図6 ML を中心に利用したグループの利用履歴 図7 Wiki を中心に利用したグループの利用履歴 向の違いがうかがえる． 5. 1. 4 グループ毎のアクセス解析次に，WikiもMLも利用しているグループでの利用状況について，2007年5月に分析したデータを見てみる．ここでは投稿数が50件以上，Wikiページ編集回数50回以上，継続期間が1年以上のMLに注目した．この条件を満たすMLは全3,110個のうち 64個あった．各月の投稿数と編集回数の大小を比べてみたところ，8割にあたる54個のMLが編集回数よりも投稿数の方が多い月が多かった．図6はMLを中心に利用したグループの例である．縦軸のMLへの投稿回数は累計の値であり，Wiki閲覧回数，Wiki編集回数はそれぞれの累計の値をその時点でのユーザ数で割った値である．つまり，1ユーザあたりのWiki閲覧・編集回数を算出している．横軸は月である．メールの投稿件数は継続的に増加して図8 ML が中心だが，一時期に Wiki を集中して 利用するグループの利用履歴(1) 図9 ML が中心だが，一時期に Wiki を集中して 利用するグループの利用履歴(2) いるが，Wikiの閲覧・編集回数は最初に一旦増加した後に落ち着いた状態となっている．図7はWikiを中心に利用したグループの例である．メールの投稿件数は最初の1年程度は増加し続け，その後は横ばいとなっている．Wikiの閲覧・編集回数は継続的に増加しており，Wikiを中心に使っていることがわかる．図8は定常的に増加するメールの投稿数に対して， Wikiの編集回数が一時期急増した例である．メールの投稿件数は一定して増加傾向にあるが，Wikiの閲覧・編集は最初は増加せず，グループ開始1年後くらいに急激に増加し，3ヶ月間後にまた落ち着いた状態となる．通常はMLで連絡をとっているグループが，共同作業をする際に一定期間だけWikiを活用したの

(16)

だと考えられる．通常はコミュニケーションシステムとして利用し，必要な時にコラボレーションシステムとしても使えるというqwikWebの性質がよく現れている．図9は同様に一定期間だけWiki閲覧・編集が増加した例である．グループ開始から半年後の1ヶ月間にWiki閲覧・編集が増加している．MLへの投稿は日常業務での連絡として定常的に利用されているが，Wiki閲覧・編集は特定のイベントのために使われるため，その時期だけ活用されているのだと考えられる． 5. 2 利用者アンケート qwik.jpの利用者を対象に，アンケート調査を行った．qwik.jp上で，2004年2月23日から2009年9月 30日の間に運用されているグループのうち，最低でも1回はWikiへのアクセスがあったグループの利用者をアンケート対象とした．前述のように，qwikWeb の仕様上複数のメールアドレスを利用している場合でも区別できないため，メールアドレス毎の調査となっている．対象グループのメンバに対して，アンケートへの協力依頼のメールを一斉配信し，利用者はWeb 上でアンケートに回答した．アンケートは，Wikiグループにおける利用者のスキル・役割とWikiグループの活動との関係を分析するためのものであり，21項目からなるが，ここではそのうちのqwikWebの設計に関わる2項目の回答について説明する． Q9 あなたは各グループのqwikWebをどのように利用していますか(複数回答可) 1. メーリングリストに流れるメールを読む (86.7%) 2. メーリングリストに投稿する(70.1%) 3. Wikiを閲覧する(48.7%) 4. Wikiを編集する(37.6%) 5. 1. 2節での調査における結果から，アンケート調査を行った2009年9月30日当時の値をとると Wiki閲覧が46%，Wiki編集が20%となっており，それと比較すると，Wiki閲覧が48.7%，Wiki編集が 37.6%と，Wiki閲覧は比較的近い値だが，Wiki編集は半分程度の値で，アンケート調査に回答した利用者はWiki編集に関わる利用者である傾向が強いことがわかる．MLに流れるメールを読む利用者が86.7%であり，13%の利用者はメールを読まない利用方法をしていることがわかった．これは単にグループに登録されただけで，送られたメールは無視している，または単にWikiとしてだけ使っているという使い方が想定できる． Q13 あなたはqwikWeb をどの程度使いこなせますか(複数回答可) 1. メーリングリストに流れるメールを読むことができる(94.7%) 2. メーリングリストに投稿できる(92.1%) 3. Wikiにログインして閲覧できる(86.5%) 4. Wiki のページを作成したり編集できる (73.1%) 5. 書式(「*, **, -, --」など)を使って，見出しやリストを作成できる(67.3%) 6. リンク表記を用いて，ページ間のリンクを作成できる(58.8%) Q9では，実際にそのグループにおいてWiki閲覧やWiki編集を行ったかどうかを聞いているのに対して，Q13においてはqwikWebを使いこなせるかという質問である．前述の，Wiki閲覧48.7%，Wiki編集 37.6%とは変わって，Wiki閲覧が86.5%，Wiki編集が73.1%であり，スキルとしては身につけているが，単にやっていないだけというスタンスの利用者が多いことがわかる．これは，qwikWebにおいては通常はMLによるコミュニケーションのみを行い，必要になったときに初めてWikiとしての利用を開始するという使い方を想定しており，そのためMLによるコミュニケーションのみを行っている利用者であると考えられる．また，書式を使えるのが67.3%で，ページ間のリンクを作成できるのが58.8%と，編集できる人の割合(73.1%)から徐々に下がっている．このように，Wikiを使って編集できることから，Wiki記法を使えること，ページ間のリンクを作成できることといった段階で徐々にスキルを発展させる使い方ができること，つまり段階的にスキルを修得できることは Wikiを使う大きなメリットであり，設計思想に合致

(17)

した使い方がなされていることがわかる． 5. 3 特筆すべき利用事例このqwik.jpを利用したグループのうち，特に目立った利用をしたグループをいくつか紹介する． qwikWebを書籍の共同執筆環境として使った事例がある．高林らによる『Binary Hacks —ハッカー秘伝のテクニック100選』と，荒川らが翻訳した『Rと Bioconductorを用いたバイオインフォマティクス』である．著者によれば，各々の執筆分担をWikiページとして分割し，Wikiページとして完成させるという手法で共同執筆が行われた．コミュニケーションとコラボレーションの両方をシームレスに行えるという特徴からqwikWebを選択したとのことである．さらに，国内のさまざまなイベント運営の連絡用 MLとして使われている．Rubyに関する国内最大のカンファレンスである日本Ruby会議の運営にも活用されており，スタッフ間のイベントに関わる情報共有に使われている．また，東京大学大学院情報理工学系研究科の情報理工実践工房では，20件以上のソフトウェア開発プロジェクトがqwikWebを利用している．技術評論社『Software Design』誌2005年8月号より2006年7月号まで，12回に渡ってWikiに関する記事が連載され，その連載の1つとして「qwikWeb 徹底解説」[4]が掲載された．連載を支えるコミュニケーション／コラボレーションシステムとしても qwikWebは利用され，最終回においてqwikWebを利用した編集作業の実態[11]が紹介された．連載で使われたグループは，後に参考になるように一般公開された†15．記事によれば，qwikWebが選ばれたのは「後から追加されたメンバにもプロジェクトの見通しが良いこと」，「メールとドキュメントの両方が閲覧可能であること」などの理由である． 5. 4 qwikWebの普及 qwikWebは，2004年4月22日よりGPLによるフリーソフトウェアとして一般に公開している．そ †15 http://qwik.jp/wikibana-gihyo/ のため，実験環境として公開しているqwik.jp以外にも，さまざまな組織の内部で利用されている．一般に組織内部での利用は外部からはわからないため運用結果を知る機会はあまり無いが，直接つながりのある担当者から聞くことのできた運用結果についてまとめる．沖電気工業株式会社のソフトウェア開発部門では， 2005年から2008年にかけて，組織内連絡に qwik-Webを使っていた．累計30∼70ユーザによって10 前後のMLが使われていた．2008年に利用を停止した理由は，組織の再編成による影響が大きいと語っている．受託システム開発大手の株式会社永和システムマネジメントでは，2006年にqwikWebの利用を開始し，40個のMLにて，累計127人のユーザによって利用されている．重複も含めて数えると374人となり，多くのユーザは複数のMLに重複して登録されていることがわかる．社内部門やグループの運営，社内外の開発プロジェクトなどがメインの用途であり，現在も継続して利用している．社内では基幹システムに位置付けられていると語っている．株式会社ウニークスでは，qwikWebシステムを社内にインストールするサービスを提供している†16．また，システムのカスタマイズも有償で請け負っている．このように，フリーソフトウェアとして公開しているシステムであるが，受託開発大手の情報共有システムとして採用され，qwikWebのインストールやカスタマイズを提供する会社が現れるなど，高い完成度をもったシステムとして受容されていることがわかる．

6 まとめ

本論文では，MLとWikiを統合したコラボレーションシステムqwikWebについて，背景となる知見と設計，実装と特筆すべき運用について述べた．利用者はMLによる日常的なコミュニケーションを出発点として，必要に応じてWikiによるコラボレーションを取り入れることができる．MLに流れるメールは †16 http://qwikweb.jp/

(18)

Wikiに蓄積されるため，必要に応じて適宜参照することができる．蓄積されたフロー情報を元に，必要に応じてストック情報としてのページを作成・編集することで，グループにおける知を共有・構造化できる． qwikWebは，ちょうどWebアプリケーションの実装が頻繁に行われるようになる黎明期に実装を開始しており，そのため，Ruby，メタプログラミング， REST，XPなど，先端的な技術を積極的に取り入れて実装している． qwikWebの特筆すべき利用事例として，雑誌での連載を支える連絡媒体，2冊の書籍の執筆媒体，イベント運営の連絡媒体として利用されることとなった．フリーソフトウェアとしてリリースしたところ，さまざまな会社の内部情報共有に使用され，そのうち2 社にインタビューすることができた．インストールやカスタマイズなどを有償で請け負う会社も誕生している．これまでの活動で，コミュニケーションとコラボレーションをシームレスに融合したWeb上のコラボレーションシステムの構築という当初の目的を達成できたと考えている．今後はqwikWebの活動で根本的な理念として考えてきたコミュニケーションとコラボレーションのシームレスな連携を，メールとWiki の組に限らず，さらに多様な情報の流れへと接続し，より有意義な知の集積・構造化が行われるようなシステム基盤の構築へとつなげたいと考えている．謝辞本論文は，博士課程における指導の結果生まれている．指導教官の竹内郁雄先生に感謝の意を表する．参考文献

[ 1 ] Beck, K.: Extreme Programming Explained: Embrace Change, Addison Wesley, 1999. (翻訳：ケ ント・ベック，XP エクストリーム・プログラミング入門 — ソフトウェア開発の究極の手法，ピアソンエデュケーション，2000)

[ 2 ] Berners-Lee, T.: The World-Wide Web, Com-puter Networks and ISDN Systems, Vol. 25, No. 4-5(1992), pp. 454–459.

[ 3 ] Engelbart, D. and English, W.: A Research Cen-ter for Augmenting Human Intellect, in Proceedings of the 1968 Fall Joint Computer Conference, ACM, 1968, pp. 395–410.

[ 4 ] 江渡浩一郎: qwikWeb 徹底解説, Software Design, 5 月号, 2006, pp. 102–111.

[ 5 ] 江渡浩一郎: パターン，Wiki，XP：時を超えた創造の原則, 技術評論社, 2009.

[ 6 ] Fielding, R.: Architectural Styles and the Design of Network-based Software Architectures, Ph.D. Thesis, University of California, 2000.

[ 7 ] Greif, I.: Computer-Supported Cooperative Work: A Book of Readings, Morgan Kaufmann Pub., 1988. [ 8 ] Kay, A.: A Personal Computer for Children of All Ages, in Proceedings of the ACM National Con-ference, Xerox Palo Alto Research Center, 1972. [ 9 ] Leuf, B. and Cunningham, W.: The Wiki Way:

Quick Collaboration on the Web, Addison Wesley, 2001. (邦訳：ボウ・ルーフ，ウォード・カニンガム， yomoyomo 訳，Wiki Way — コラボレーションツール Wiki，ソフトバンクパブリッシング，東京，2002) [10] まつもとゆきひろ, 石塚圭樹: オブジェクト指向ス

クリプト言語 Ruby, アスキー, 1999.

[11] しばむらしのぶ: qwikWeb 上の Wiki つまみぐい — Wiki つまみぐい運用の舞台裏, Software Design, 7 月号, 2006, pp. 113–115. [12] 高林哲, 増井俊之: QuickML：手軽なグループコミュニケーションツール, 情報処理学会論文誌, Vol. 44, No. 11(2003), pp. 2608–2616. 江渡浩一郎独立行政法人産業技術総合研究所社会知能技術研究ラボ研究員．1997年，慶應義塾大学大学院政策・メディア研究科修了．在学中よりメディア・アーティストとしてアート作品を発表する．《WebHopper》 (1996)，《インターネット物理モデル》(2001)，《 Mod-ulobe》(2005)など．2010年，東京大学大学院情報理工学系研究科博士課程修了．博士(情報理工学)．著書に『パターン，Wiki，XP』(技術評論社)．ホームページ：http://eto.com/