Wikiは、Web上でコンテンツを共有したり共同で編集したりする手段を提供する。従業員のチームワークとコミュニティを促進するとともに、電子メールの量を削減するためにWikiを利用し始めた企業もある。
しかし、単にWikiを社内ネットワークに導入するだけではだめである。導入プロセスを容易にし、導入の失敗のリスクを最小限に抑えるために、事前に適切な手段を講じる必要があるのだ。導入を成功させるには、以下の3つのステップを実行しなければならない。
Expired：掲載期限切れです - ITmedia エンタープライズ
以外にいい感じにまとまったので昨日の続きを書きます。
今日は、Wikiの用途とメリット、そして社内で活用されるためにはどうしたらよいのかという点についてまとめようと思います。
Wikiの用途
Wikiは便利なので何にでも使えますし、私は昨日書いたような用途に使っているのですが、こういう用途に使ったら便利なんじゃないかとモヤモヤ考えている用途は以下の2点です。
-
- 納品する運用ドキュメントとして利用
- 内部/外部設計書として利用
それぞれを掘り下げてみます。
納品するドキュメントとして利用
受注開発などのシステム開発をしていると納品という儀式があります。そのような場合にはプログラムと一緒に運用で使用するドキュメントもまとめて納品しますが、そのドキュメントをWikiで作ってみたいと思っています。
例えば運用で使うドキュメントで大事なことは読みやすさとメンテナンス性、そして情報を探しやすいことに尽きます。
読みやすさという点についてはWikiならではのメリットというのはありませんが、メンテナンス性と情報の探しやすさについては非常に優位性があります。編集箇所が分散しにくいという点と編集のしやすさはメンテナンス性に貢献しますし、インデックス作成が容易であることやキーワードリンク機能や検索機能が付いているWikiが多いことを考えると情報の探しやすさは申し分ありません。
欲しい情報が見つかりやすくて最新の状態に保ちやすいというのはすごいメリットです。
もちろん、ドキュメントの形式を明確に指定される場合もありますから必ずしも出来るわけではありません。社内規定もあるでしょうから、そういう場合はしょうがないです。フォーマットはこのテンプレートに従って、ファイル形式はPDFで...なんて言われるとWikiの使用は諦めましょう。紙ベースのドキュメントにしにくいのはWikiの弱点です。
とは言え、継続したメンテナンスがしやすい点や履歴管理などは運用ドキュメントに向いています。
内部/外部設計書として利用
これは上の運用ドキュメントでも述べたのですが、Wikiはメンテナンスがとてもしやすいです。
今まで、私は必要な設計書はすべてWordで作成していましたが、最初は頑張って作るのですがメンテナンスがおざなりになりがちです。最初に頑張って作れば作るほどメンテされにくいのは私が横着なせいだと思いますが、やはりメンテナンスがしにくいというのはドキュメントとしては致命的な欠陥です。
修正しやすくて、情報を探しやすいというのは設計書を作る上でも非常に優れている点です。
設計書を作る際にはテンプレートを使って体裁を統一するのが望ましいですが、WikiではWordのようにひとつテンプレートのページを作っておいてそれをベースに作り始める機能があります。これを使えば体裁も整えることが可能です。
また、同じWikiでもスキンを変えることで見た目を一変させることができます。こうすることで作成時と納品時のデザインをがらりと変えられるというのも大きなメリットとしてとらえています。
Wikiのメリット
もう上で散々書きつくした気がしますが、Wikiのメリットは以下の点です。
-
- メンテナンスしやすい
- 情報を探しやすい
- 履歴管理がしやすい
- デザインがキュート
最後のあたりはもう感覚の世界になってしまいますが、Wikiは非常に便利なので使い慣れてしまえばもうあばたもえくぼなのです。
印刷して観るような用途には向いてないとかそういうデメリットはありますが、そんなのは些細なことです。
使う人がWikiのメリットとデメリットを熟知して、メリットにほれ込むというのが一番大事なことだと考えています。
社内で活用されるためにはどうしたらよいのか
さて。
ここまで読んだ人であれば、個人で使う分にはもう十分な動機づけが出来たと思います。出来なかった人はもう4回読み直してください。
で、これを社内全体で使ってもらうにはどうしたらよいのかということですが、残念ながら近道というか特効薬というのはありません。昨日の記事にも今日の記事にも書いたとおり、メリットを周知してそれを徹底的に理解してもらうこと以外に広めることは出来ないのです。
逆に絶対にやってはいけないことがひとつだけあります。
それはCMSで情報共有しようということをトップダウンで押し付けてはいけないということです。上が決定してそれをただやれというだけでは失敗に終わるどころか時間の無駄にしかならないでしょう。
なぜか。
それはCMSを活用した情報共有というのが利用者の善意や表現欲をベースにして成り立っているからだと考えています。
自発的に情報を発信したいと思う人が発信しやすいと感じられる環境こそがCMSを活用する土壌であり、自発性以外の要因、例えば報酬や評価によって情報を発信させようという土壌では情報の信頼性や品質において不安を感じます。それは情報を発信することが目的ではなく手段になっているからです。
つまり、CMSを使った情報共有やドキュメントの整理は、あくまでボトムアップでなければスムーズに進まないのです。
これは非常に大事なポイントだと感じています。
もちろんそんな善意や本人のやる気がないといけないとなるとCMSを情報共有には使えません。
例えばドキュメント管理者をおくことで品質を確保しようとすれば、自発性以外の要因を土壌とした環境であっても十分な情報共有をすることは可能です。
ですが、私の考える情報共有のあるべき姿というのは、「みんなと情報を共有したい」という思いがベースにあるべきだと考えています。そうでなければ、CMSなど使わずに掲示板やPDFでの配布で十分です。
ではなくて、多くの人と情報を共有したいんだというオープンさを共有したいからCMSがよいのですし、そういう意味でCMSの活用条件の必要条件としてボトムアップであることを挙げたいのです。
何はともあれ、まずは使ってみて自分がつかいたいと思うものなのかどうかを試してみてください。
ちなみに私はPukiwikiを使っていますが、PHPは読みやすいですし完成度が高いのでとても満足しています。
おすすめです。
