大規模開発プロジェクトのドライビング（６）～Knowledge Management後編

実はGW中です。日々忙殺されていると本業以外に眼が行かなくなるもの。寝るのとゴルフは十分やったので今度はお勉強。ちなみに休む・遊ぶ・勉強を同じぐらいの割合でできるのが自分の理想の休日～。ってことでKM後編です。

○Context（文脈）付きDB

本当はもっとたくさん種類があるのかもしれませんが自分の知っている範囲でとりあえず挙げます。

・WSS,SPS

Microsoftの製品です。それぞれWindows Sharepoint Service, Sharepoint Portal Serverの略です。これらはMicrosoftが進めるWindows server強化の一環（多分）で、WSSのほうはWindows Server2003の無料アドイン、SPSはWSSの上位互換になっています。基本としては単層のポータルならWSSで済みますが、WSS同士をノードを作成して繋いだり、SQL serverを使って検索機能をつける場合はSPSが必要になります。基本的にまだ歴史の浅いソフトなので使い勝手の面で劣ることがありますが強力なメリットとしては、Microsoftの有り余る開発力を使って開発が継続されていくことと、Microsoft Officeファイルに対しインデックス付きの検索をかけられること※です。

※自分では試してないです。

※NamazuでOfficeファイル検索ができますが、日本語の文法解析やファイル構造解析がそれぞれ別ソフトなのでそこで限界が決まってしまうところがあると思われます。

現在のオフィス環境においてはMicrosoft Officeファイルを高効率で処理できることが重要なポイントの１つなので、（独占的で好きになれないという感情は置いといて）非常に魅力的な製品であるといえます。デメリットとしてはやはり歴史の浅いソフトなので拡張性、可用性、堅牢性の実績が未知数というのがあります。

・Lotus Notes

現在はIBMの製品です。ポータル・DBとしては歴史が長く、IBMで全社的に使われているので実績は十分です。したいことは大体出来ますがそれはサポート部隊の能力に寄ります。

以上が大規模プロジェクトにおけるKMとしてのDBの紹介です。

・Wiki

小・中規模までならWikiぐらいがちょうどいいかもしれません。メンテナンスコストが抑えられます。

http://pukiwiki.sourceforge.jp/

○Officeファイル検索

インデックスを作らない検索ならばOffice2003からOfficeアプリケーション上から検索を行うことが可能です。今手元に環境がないので詳細は書きませんが、「ファイル」のメニューから検索でそれが可能です。検索範囲はローカルからファイルサーバ上まで可能、検索はファイル名からファイル内まで選択できます。インデックスを作らず一つ一つのファイルを解析していくので検索対象が大規模な場合は注意してください。

○移行に関して

大抵いままでの仕組みを変えようとすると文句を言われます。なので一番楽なのは新しくDBを作る際に変えてしまうこと。途中から変える場合はなるべく最終的に負荷が増えない方法をとるのが好ましいです。人と場合によりますが、自分が好む方法は1から2に移行する場合は1.9ぐらいの移行技術を使用します。中途半端に1.5ぐらいのものを使用すると移行しない人がいたり、もう一段波が来るので最終的に二度手間になるケースが多いです。

以上KM関連でした。

次回は集団ヒステリーに打ち勝つ方法を考察します。