コンテンツ マネージメント システム

ウェブサイトイントラネット
ホームページ

text : フリージャーナリスト増田"maskin"真樹（Blog;metamix.com） illust : 小松恵

第12回 Wikiコラボレーションで企画を練り上げよう 3
総仕上げ〜本格的なコラボレーションをすべてWikiで

ウェブサイトイントラネット
ホームページ

メーリングリストとの組み合わせが強力

WikiはCMSの1つでありながら、複数の何らかの目的を達成する企画を練り、実トリームがあり（図1）、詳細な詰めが許さメンバーとのコラボレーションワークを変行するもの。非常に幅広い話題を詳細にれなかったり、流れ次第では貴重な情報える特徴を持っている。使い方や構造は特わたって議論する必要があり、それを企画が埋もれ、見落とされたりする可能性もあ異だが、より多くのユーザーに対して均等書としてまとめ、関係メンバー間でのコンる。議論をアーカイブすることの有効性をセンサスを確立することが不可欠となる。

主張する声はあるが、メーリングリストではに参加機会を与えられ、いったん慣れれば多様なコラボレーションワークに使えるス

ところがドキュメント化のスピードは想必要な情報を検索することすらかなりの労像以上に遅く、プロジェクトの活動とシン力を必要とする。実際、これがプロジェククロナイズさせることは困難を極める。多トチームにとって利益をもたらすかと言う環境に依存せずに、共通のユーザーインタくのプロジェクトチームが選択する対策と疑問が残ると言わざるを得ない。

ーフェイスでコンテンツの編集と管理がでは、ドキュメント化の選任スタッフを置いグレモノのアプリケーションだ。特に紹介しているツール PukiWiki は、ブラウザーやインストールするサーバーシステムのところがWikiは、そういった問題も見事きる。運営次第では、単なる企画書作りのたり、唯一全体を見渡せるリーダーやサブプラットフォームではなく、MLや掲示板をリーダーがそれを担当したりすることだが、まずWikiは、『ドキュメント』『コミュニケリプレースする重要なインフラになるだろ

そこで生まれるドキュメントは『要件定義ーション』という異なる2 つの要素を1 つう。

書』
といったアウトラインや必須要件のサのページに併せて持てる。ページのどこマリーにすぎず、詳細な議論やプロセスにでも「#comment」によってコメント入力との関係は除外されるか、かなり希薄になフォームを配置でき、必要なときに必要なってしまう。

規模の議論の流れを作れる（図3）。決めメーリングリストからWikiコラボレーションへ解決してくれる（図2）。

そこで、従来から積極的に活用されてき打ちされた議論の流れがなく、もちろんペたのが、メーリングリストを使ったコラボレージ全体を議論の場とすることもできる。

ーションワークだ。ところが、メーリングリ議論が行われているページに、公式ドキストではあらゆるやりとりをメールで行うたュメントに関連する情報が書き込まれ、そこの連載におけるWiki活用の目的は企め、細かい議論やプロセスが、メールボッの同じページ内で、限られた話題をぐぐっ画の練り上げである。数名からのメンバクス内で細切れになって保存される。まと深く詰めていくことができる。

ーで構成される「プロジェクトチーム」は、た、メーリングリストには、議論のメインス

116 +++ iNTERNET magazine 2004.02 +++また、Wikiではいったんばらばらに作成

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

したページを自由につなぎ合わせていくこ

員で、『カード』にさまざまな情報を書き込

3．理論の思考法ともできる。つまり溜め込んでいった情報み、それについて議論して、カードを大き4．SQL記述のルールを、あとから振り返って構造を付け加えてな企画用紙に並べていく作業」に近い。

5．UIはSEOを考えていくというワザも標準で行える。つまり、なんと自由で、創造性あふれる作業だろ6．ごめんなさいプロジェクトのメンバー全員で、多岐にわうか。

7．InfoArchive
8．FutureStream

たる、一見収拾がつきそうもない議論とド

ところがWikiで取り扱うのは形のないキュメント化が行われていたとしても、最情報 であり、始めはどんなページが生後にそれを整理してまとめることができるまれるか予測もできないものだ。要する

まず「1．○○システムの構造上の問題のだ。もちろんページをグループ化して、に、上で述べたように、カードではなく正点」「4．SQL記述のルール」は、単独でド公式ドキュメント などとして整理するこ体のわからないページがどんどん作られるキュメントの中心的存在になるとは考えにともたやすい。

可能性があるわけだ。特にもっとも問題くいが、 内容が一目でわかる という意味となるのが「ページの名付けが不統一」とでは成功例と言えるだろう。ところが、「2．

いう問題だ。

運営コスト計算上の考察」「3．理論の思リファクタリングでコンテンツを高品質にたとえば、こんなページの名前が並ぶ考法」と言われても、何がしたいのかよくわからない。2 は「運営コスト計算ポリシWikiがある。

ー」とでもすればわかるかもしれないが、3つまりWikiによるコラボレーションワー
クというのは、「プロジェクトのメンバー全

1．○○システムの構造上の問題点は致命的だ。

2．運営コスト計算上の考察「5．UIはSEOを考えて」は伝わること

図1 メーリングリストにおけるコラボレーション
事象Aに関するエントリー1

図3 スレッドを含んだドキュメント
まったく別の流れで担当者が作成するドキュメント化

事象Bに関するエントリー2
議論の流れ

企画書
要件定義書

事象Aに関するエントリー3

事象Aに関するエントリー4

・どんな話題も1つの流れの中でこなさなければならない・スレッドという概念もあるが、複雑長期化した議論ではさらに混乱を生む・メーリングリストのデータをそのままドキュメント化できる可能性は低い

図2 Wikiにおけるコラボレーション
公式ドキュメント化
される部分

事象A

事象Aに関する
付随情報

事象Aに関する付随情報

非所属の付随情報

事象Aに関する
コミュニケーション

非所属の付随情報

事象Bに関する
付随情報

非所属の付随情報

公式なドキュメントとして使えるページの一部に掲示板機能を配事象B置したところ。 スレッド という部分が該当部分。プロジェクトの詳細部分がどういったプロセスで決定されたかが理解できる、極めて貴重な資料となる。議論がこのページにそぐわない方向に向かうなら、切り出して別のページに引っ越しをさせればいい。

事象Bに関する
コミュニケーション

・決め打ちされた議論のメインストリームがない
・どこにでもスレッドを作ることができる
・バラバラに書き記したページは自由に構造化できる・最終的に公式ドキュメント化する部分を抜き出せる

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D+++ iNTERNET magazine 2004.02 +++117

は伝わるのだが、別にWikiページにするまれてしまう可能性があるからだ。つまり、必要もない。これこそ一斉告知型のMLにどこにもインデックスされないし、分類もるようになるのだ。
ただ「いちいち Wiki の更新部分をチェ流したほうが適切だ。
「6．ごめんなさい」
もされないページだ。親のないページの質ックするのは手間」だという意見もある。

同様だ。Wikiは ページを残すこと を前が悪いかというとそうではなく、単純にごもっともである。PukiWikiの場合、更新提にしたシステムだから、時事性が高く一Wikiページ群（＝コンテンツ）の全体の構されたページのリストが左メニュー部に表過性の情報には合わない。

造上の問題となる。まとめ役となる人物が示されるが、どの部分が更新されたかはペ「7．FutureStream」は英語だという点いるのなら、メンバーが慣れるまでメールージを開き、グローバルメニューから［差で、ほかのページ名とは異なるが、短すぎやメーリングリストで使い方を教えたほう分］をクリックするしかない。あらゆるペーてよくわからない。
「8．InfoArchive」なら意がいいだろう。

ジでいくら詳細な動きがあっても、それを味はまだわかるが、ほかのページが日本語

このようにWikiによるコラボレーション

キャッチできなければ意味がない。そこで、中心なら、いずれ合わせる必要も出てくる

では、「ドキュメントの執筆」「ページ内の箇PukiWikiの「更新差分のメール告知機能」だろう。

所に関する議論」「ページリンクによるコを使ってみたい。

このようにページ名の付け方の不統一ンテンツの構造化」という基本作業が生は、Wikiコラボレーションに深刻な問題じる。これらをバランスよく行っていくことをもたらす。というのは、ページはいずれで、すべてのメンバーがページに分散し、インデックスとなる 親ページ にリンクさあらゆる項目に対して詳細なリファクタリれて整理されることが多いので、名付けにング（ページ内のコンテンツの再構成）を失敗すると「親のないページ」が大量に生行い、ドキュメントの高品質化を追求できカスタマイズして更新情報をメールで受信

本 誌 2 0 0 3 年 1 2 月号 のこの 連 載 でPukiWikiのインストール方法を掲載したときは、バージョンは「1.38」だったが、最新のPukiWikiは「1.42」になっている。このバージョンアップで、blogで一般的となっ図4 pukiwiki.ini.php設定ファイルの変更箇所（217行目から）たトラックバック（逆リンクを自動的に生成////////////////////////////////////////////////する機能）などの新しい機能の追加や、こ// ページの更新時にメールを送信する$notify = 1;

ここを1にするれから説明するメールによる告知機能のここを1にすると差分だけの送信になる（オススメ）

不具合などが解消されている。したがって、// 差分だけを送信する$notify̲diff̲only = 1;

バージョンアップはぜひおすすめする。な// To:（宛先）$notify̲to = 'wiki@metamix.com';

更新メールの送り先。プロジェクトのMLなどが適当

お、ここで紹介するカスタマイズ方法は、メールの送り主を設定する。リーダーや担当者など1.42に準拠することにする。

// From:（送り主）$notify̲from = 'leader@metamix.com';// Subject:（件名）$pageにページ名が入る$notify̲subject = '[wiki] $page';

メールのタイトル。wikiのところを// 追加ヘッダ

わかりやすい名前にする$notify̲header = "From: $notify̲from¥r¥nX-Mailer: PukiWiki/".S̲VERSION."
PHP/".phpversion();

クトリーのバックアップを忘れてはならな
い。また、1.3x系から1.4x系へのバージ// POP Before SMTP を実施$smtp̲auth = 1;

バージョン アップを実 行 する前 に、PukiWikiがインストールされているディレ

メール送信の前に受信が必要なプロバイダの場合1// SMTPサーバ名を指定する (Windows のみ, 通常は php.ini で指定)ョンアップでは、PukiWikiの設定ファイル「pukiwiki.ini.php」の構成が変更されてい$smtp̲server = 'smtp.metamix.com';// POPサーバ名を指定するるので、バージョンアップ後は設定しなお$pop̲server = 'pop.metamix.com';

す必要があることに注意してほしい。なお// POP のポート番号 (通常 110)$pop̲port = 110;バージョンアップには差分ファイルが用意// 認証に APOP を利用するかどうか (APOP 利用時は 1、以外は POP3)されているので、ほとんどの場合、該当箇$pop̲auth̲use̲apop = 0;

所にファイルをアップロードして上書きす// POP ユーザ名
$pop̲userid = 'xxxxxxxxxxxxxxxxx';

送り主アカウントのメールサーバーユーザーID// POP パスワード$pop̲passwd = 'xxxxxxxxxxxxxxxx';

るような簡単な処理で済む。
PukiWiki のカスタマイズは、ルートのパスワード「pukiwiki.ini.php」ファイルを編集することで行う（基本的な ページ名 や 編集
者名 、 URL の設定などは済んでいるも118 +++ iNTERNET magazine 2004.02 +++インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

のとして進める）。
「更新差分のメール告知機能」の設定は、設定ファイルの217行目あたりにある。図4で示すとおりに変更情「そのまま入力できる」
Wikiの隠れた魅力

ンやリスト、表組、コメント欄などの作成を省力化できる。特に今回のテーマである企画作りには必要十分な記述ルールがそろっていると言える。

報を入力すれば機能する。
設定ファイルを編集後、サーバーにア

ではWikiは万人向けのツールなのだろでは、 記述の簡便さ が人気のキーなップロードすれば処理は完了する。ペーうか。その答えがわかるこんなできごとがのかと言われると、そうではない。実は、ジの一部を編集すると、すぐにメールが送あった。

Wiki のページ内では HTML が無視されられるようになる。メールだけでWikiコラ

この連載でWikiを取り上げてすぐ、筆る というのが、本格利用へのきっかけとボレーションの稼働状況を知れるので重者宛てに「Wikiとの出会いに興奮していなるもっとも大きな理由となっているのだ。

宝する（図5）。この設定では送信内容はます」という言葉が多数寄せられたのだ。

図7を見てほしい。これはあるウェブ開差分のみになる設定をしているが、十分に意外だったのは、IT 業界で活動するクリ発企画のWikiで、タスク内容を書き記す内容が予測できるのでそのほうが使いやエイターやディレクターなどその最前線でページを作っているところだ。
「*」で始まるすい。必要があれば、ウェブブラウザーを活動する人々が、Wikiをこれまで体験したいくつかの見出しの中に、 テンプレート開いてWikiをチェックすればいい（図6）。

ことのない新鮮なシステムだと捉えていた別の要件 という項目がある。その中に、メールと連動するようになってくると、メことだ。
「Wikiという名前こそ知っていたけ

アンカータグ「<a href=""></a>」やダブーリングリストとの差が歴然としてくる。当

れど、これほど柔軟で使い勝手がいいもルクォーテーション「""」が含まれる文字列

然、無駄なやりとりもなく、コンテンツののとは思わなかった」ということらしい。

が入力されている。通常、これらの文字列追加や構造の変更、議論だけが告知されもっとも評価されたのは HTMLタグをは、ウェブページ上に表示させようとするる。チームワークの活動状況がメールで使わない という点だった。前回解説したと特殊なコードを付加する必要がある。ウ

告知されるだけでなく、Wikiデータベース

とおり、Wikiクローン（Wikiベースのツー

ェブの掲示板などにそのままポストすると、にしっかり保存される部分は、画期的とし

ル、この連載ではPukiwiki）には独自の記

勝手にHTMLなどのタグと解釈されてさまか言いようがない。

述ルールがあり、それを使ってアウトライざまな問題を引き起こしてしまう。当然、

図5

図6 変更箇所をサイトでもチェックできる
どのページでどこが編集されたのか、変更箇所だけがメールで送られてくる。タイトルにはページ 名 が 表 示される。
行頭に「-」がついているのは削除された文章。
「+」
がついているのは追加された文章を表す。

実際、編集されたページで［差分］ボタンを押すと、どこが変更されたのかがわかるよ
うになっている。

図7 整形ルール以外のテキストはそのまま表示されるあるウェブ開発プロジェクトのタスクに関する情報を整理するページ。概要や要件、構成ファイルごとのメモや質疑応答を行う。画面を見てわかるとおり、入力したテキストはそのままブラウザーの画面に現れるため、利用者の手を煩わせることはない。

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D+++ iNTERNET magazine 2004.02 +++119

オンライン上でのコラボレーションのようメールやメーリングリストに情報を流す頻

確かに入力は楽だし、最新情報を共有な、業務の一環として頻繁に情報のやり度が減った。その分、Wikiに保存する情するのには成果があった。しかし、それらとりをする用途では使い物にならない。

報が増えたのかと言うと、そういうことでを整理して、 本という構造 を組み立てよ

ところがWikiの場合、入力後は、そのはない。無駄なコミュニケーションが減り、うと思ったとき、blogツールではそれがでままの形で画面に表示されるようになる整理されてまとまったドキュメントを作れるきなかった。Wikiで言う「カードをシャッフ（図7の右の画面）。つまり、入力した文字ようになったと感じる。更新差分のメールルして、好きなように並べていくこと」が列は、何の加工手続きも必要なく、Wiki

告知と連動することで、大きな改善をWiki

blogツールにはできなかったのだ（図8）。のシステムがウェブブラウザー上で適切にはもたらしてくれる。

この問題にはかなり早期に気が付いた。

表示されるように自動で処理を施してくれ

しかし、ほかのケースではどうだろう。

blogツールの基本は、記事を時系列にアるのだ。これまで Wikiの整形ルールはあインターネットマガジンでの米国レポートーカイブすることで、たとえカテゴリーが作まり高度ではなく直感的とも言い難い となどでおなじみの長野弘子さんと執筆してれても、Wikiのようにアウトライン構造を説明したが、実は整形ルールがシンプルいる『ブログ式（仮題）』（英治出版、2004

作ることには向いていない。やはりblogであるため、かえってテキスト情報の表現

年 1月刊行予定 ※詳細は筆者の blogをツールの特性は、時系列に発生する記事力を活かせるというわけなのだ。

参照）の編集は、2人で密に相談しながらを公開するためのパブリッシュ型ツールだ

進めてきたが、そのコラボレーションツーったのだ。

ルとして最終的にWikiを採用した。

書籍の編集作業でのWikiコラボレーション

私たちはすぐにWikiに乗り換えた。整

実はその前形ルールを習得するまで少し手間取ったにblogを使ってコラボレーションを行おう

が、まもなくメモや記事をどんどんWikiにとしたのだ。

並べていくことができた。ある程度の情報Wikiは活用できたのか？

Wikiは、プログラマーやデザイナー、ラblogのツールもWikiと同じように、テキがたまった時点で、構造を再編集したり、イター、ディレクターなどさまざまな役割をスト情報の入力が極めて簡単だ。しかも、全体の編集感覚を見直したりすることが持つメンバーで構成されるウェブサイトのblogツールにはMovableTypeを使ったのできた（図9）。

企画開発チームなどにはとても適していで、カテゴリーによる分類もできる。とに実際の作業レベルでは、ほとんど問題はる。筆者は実際にそういったプロジェクト

かくあらゆる情報をここに納めて、考えが起こらなかったが、最後の最後になって問でWikiを導入してみたが、これまでこなしまとまった時点で整理すればいいと思っ題が発生した。アクセスが集中する情報量てきた同様のケースと比べて、圧倒的にていたのだが甘かった。の多い目次ページを、2人が同時に編集し

図8 失敗に終わったMovable Typeで書籍を作るコラボレーション

図9 Wikiで書籍を作るコラボレーション

情報が時系列で流れてしまい、あとでまとめることが難しくなる。

情報をインプットすることを積み重ね、あとから情報を関連付けて順序を入れ替えて再編集できる。

120 +++ iNTERNET magazine 2004.02 +++インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

てしまったのだ。 これは面倒なことになっっているのだ。

テキストファイルに保存されるので、二次た と慌てたが、そんな心配はなかった。

Wikiにも似た要素がある。Wikiのペー

複数のメンバーが同じページを編集しジには制限というものがない。どういったてしまっても、PukiWikiなら衝突の検知をタイプの内容を入力してもそれを受け入行い、どこが衝突している箇所かを表示しれ、結果としてそれぞれのページや各項目てくれる仕組みになっている。図10のよが関係性を生み出し、Wikiコンテンツのうに、ページ編集後に【更新の衝突】が告質が高まっていく。

加工がしやすいため、そういったアクションにも応えやすいのだ。

時代が追いついた今CMSの次なるステージへ知され、そこに自分が編集した箇所と、すWikiに限らずCMSに共通することだが、でに他のメンバーが更新した箇所が表示

インプット という観点でこれらのシステ

この連載が始まってはや 1 年。blog やされる。もし、同じ箇所を編集したのではムを見たとき、とにかく敷居が低く自由度

コミュニティー型CMS、Wikiといったツーないことが確認されれは、PukiWiki は自があると言える。特にWikiは、どんな単位

ルのハウツーを通じて、『CMS』という巨大動で衝突を解消して、更新をマージしてくで情報を編集してもいいし、文章を追加な論点への注目を高めていく狙いだったれるのだ。

したり文字を消したりすることも、ほかのが、今になってようやく これからは CMSだ という人が増えてきたようだ。

もし、まったく同じ箇所を同時に編集しページなどとのリンクを作ることも自由だ。てしまったのだとしたら、衝突の状況を見

この自由度は、参加するメンバーの情報さて、次回からどうするか。さまざまな思ながら、再度更新作業を行えばいい。もの取り扱い能力を求めるが、よけいなこと惑が錯綜するが、実はこの原稿を執筆しし、編集上のミスで、誰かの更新を消してを考えず、目標に向かってまっしぐらに突ているこの時点で方向が確定していない。

しまったとしても、グローバルメニューからき進むことを許してくれる。

CMSの新しいステージへの扉を開ける内［バックアップ］を選択すれば、変更前の状態に戻せる。

Wikiが持つ特性からその適用を考察してみる

ただ、組織内で企画を練り上げるため容を考えていきたいと思っている。にWikiを使うとしたら、数十人での運営はなお、例によってこの連載と連動した考えにくい。また、サスティナブル（継続可Wikiを用意してある。アドレスは下のURL能）なツールとして捉えないほうがいいだになるのでぜひ利用してほしい。これまで

ろう。質が悪化するようなら、Wikiによるの連載で紹介したり利用したりしたリソー

チーム運営からは一度離れた方がいい場

スはここに継続して蓄積していこうと思う。

合もある。Wikiのデータベースは、単なる

http://www.metamix.com/pukiwiki/

3回にわたってWikiクローンの1つである「PukiWiki」
を解説してきて感じるのは、ビジネスにおいてWikiは、アイデアをまとめて企画を練り上げるという使い方に最大限の効果を発揮するということだ。メン

図10 同時に更新して衝突しても大丈夫

バーの1人1人が自由にかつ十分に個人の能力の発揮を追求でき、Wikiはそれらをつないで成果物にまとめられる性質を持つ。
そこで筆者が思い浮かべたのがニューヨークの『オルフェウス室内管弦楽団』だ。
1972年に創設されたオルフェウス室内管弦楽団は、世界唯一の 指揮者のいないオーケストラだ。全米屈指のプレイヤーから構成されるこのオーケストラでは、メンバー全員が持つ創造性へのあくなき追求が、結果として良質なサウンドを生み出す。
指揮者がいないことでばらばらになるどこWikiでは同じページを異なる2人が同時に更新していも衝突したところを検出してくれる。

ろか、各人が能力を発揮することが、オーケストラという総体の質を高める構造にな

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D+++ iNTERNET magazine 2004.02 +++121

［インターネットマガジン バックナンバーアーカイブ］ ご利用上の注意
この PDF ファイルは、株式会社インプレス R&D（株式会社インプレスから分割）が 1994 年～2006 年まで発行した月刊誌『インターネットマガジン』の誌面を PDF 化し、「インターネットマガジン バックナンバーアーカイブ」として以下のウェブサイト「All-in-One INTERNET magazine 2.0」で公開しているものです。

http://i.impressRD.jp/bn
このファイルをご利用いただくにあたり、下記の注意事項を必ずお読みください。
z 記載されている内容（技術解説、URL、団体・企業名、商品名、価格、プレゼント募集、アンケートなど）は発行当時のものです。
z 収録されている内容は著作権法上の保護を受けています。著作権はそれぞれの記事の著作者（執筆者、写真の撮影者、イラストの作成者、編集部など）が保持しています。
z 著作者から許諾が得られなかった著作物は収録されていない場合があります。
z このファイルやその内容を改変したり、商用を目的として再利用することはできません。あくまで個人や企業の非商用利用での閲覧、複製、送信に限られます。
z 収録されている内容を何らかの媒体に引用としてご利用する際は、出典として媒体名および月号、該当ページ番号、発行元（株式会社インプレス R&D）、コピーライトなどの情報をご明記ください。
z オリジナルの雑誌の発行時点では、株式会社インプレス R&D（当時は株式会社インプレス）と著作権者は内容が正確なものであるように最大限に努めましたが、すべての情報が完全に正確であることは保証できません。このファイルの内容に起因する直接的および間接的な損害に対して、一切の責任を負いません。お客様個人の責任においてご利用ください。

このファイルに関するお問い合わせ先
All-in-One INTERNET magazine 編集部
im-info@impress.co.jp
Copyright © 1994-2007 Impress R&D, an Impress Group company. All rights reserved.