BrainCopy

Wikiに注目しています。KMをサポートするツールとして。ここでは、何がいいのか、どんな限界があるのかなどを考えたことを記録したいと思います。

情報をためる場所というより、情報へのリンクを示す場所としての利用を想定しています。一番の成功例は、なんといってもWikiPedia[1]です。Wikipedia自身の持っている情報は、いつでもだれかが書き換える可能性があり、確かにきちんとしたアカデミックな文書を書いているときにWikiPediaからの引用はあまり使いたくないですね。それより、WikiPediaのいいところは、下のほうにあるReferenceの情報です。そこから情報のソース・出所に飛ぶことができるわけです。すばらしい！

ここ数カ月、自分もワシントンで得た知識をこのWikiに残そうとしているわけですが、書き方を突き詰めていくと、あのWikiPediaに行きつくような気がします。日記としては見づらいという意見が多いのですが。

つまり、KMに使おうとすると、社内版WikiPediaを作ることになるんじゃないかなと思っています。WikiPediaでいうReferenceのリンクを社内の既存の情報源、技術文書や会議情報などに張るというイメージです。

• コンテンツの構築を簡単に開始できること

Wikiは、ネットワーク的につながっていれば、どこからでも編集が可能です。単純なHTMLのように、ローカルでHTMLファイルを作って、FTPを使ってアップロードするといった手順は必要ありません。

• リンクを張りやすいこと

このページにもリンクがいたる所にあると思いますが、Wikiはリンクを張りやすいです。

• 自律性

コンテンツをユーザ側が自律的に組み立てていけるだけの機能が付いてます。構成を変えるのにもソフトウェア技術者を呼ぶ必要はありません（Newman 2009, 6）。

• おもしろい

創造性を刺激するパレットだと（Newman 2009, 6）。趣味の世界ですか！？

• 入力が面倒なところがある

DBへの入力であれば、入力フォームを作り、今日の日付の自動入力や、入力者のアカウントから、部署名、名前など引っ張ってこれる情報の自動入力など、可能な限りの入力支援を行いと普通は作るので、その場合、入力の手間は最低限で済むかもしれない。ただ、主となるコンテンツを入力する手間はそんなに変わらないと思う。

• 全文検索以外の検索（メタデータを使った詳細検索など）は、やりにくい

例えば、日付による検索。DBであれば、日付という項目にその情報が入っていると、いつからいつまでといった詳しい検索が可能になってくるはず。Wikiでは、すべてテキストで記録されるため、全文検索的な動きになり、細かい検索は難しいだろう。

• DBの情報表示の柔軟性がない・データの一貫性を阻害するおそれあり

DBであれば、格納されている１つの情報をいろいろな形で表示できます。例えば、情報一覧画面があって、その一覧画面から情報詳細画面に飛べるシステムを考えると、DBの場合は、件名や日付などは、一つのデータをそれぞれの画面から参照している形になるはず。しかしWikiの場合は、それぞれを直接書くことになるはず。一つの情報を別の画面で表示するという考え方がWikiにはない。そうすると片方の件名を修正して、リストの方を修正し忘れるとか。情報によって、DBがいいもの、Wikiがいいものに分かれてくるのでしょう。

• Wikiを使うには

どうもアメリカではPBWiki[2]というWIKIサービスの人気が高いようです[3]。

• 複雑システム

これは、まさに複雑システムだ！むかしPukiwiki+TouchGraphで面白いことができたはずなんだけどな。

1. WikiPedia Contributers. 2009. WikiPedia top page. http://www.wikipedia.org/
2. PBwiki. 2009. Top page. http://pbwiki.com/
3. Raftery, Tom. 2008. Enterprise wikis reviewed.Tom Raftery’s Social Media. http://www.tomrafteryit.net/enterprise-wikis-revie...
4. Newman, Steven. 2009. The Evolution of Web-Based Collaboration at NASA & The Wiki-way Forward. PMChallenge 2009. http://pmchallenge.gsfc.nasa.gov/docs/2009/present...