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

人が増えアウトプットが増えれば増えるほど、知識の共有の困難度は急上昇します。前回の標準化はいわば知識を共有化するための下準備です。最終目的として位置するのが、知識の適切な共有、すまわちKnowledge Management…KMです。

あなたの組織はどれだけKMできてる？チェックリスト！

ちょっとノリを軽くしました（笑）。質問に途切れたところがあなたの組織のレベルです。

Q1　ファイル（知識）が…

A1 そもそも何もない→ある意味何もする必要ないです(-"-;;

A2 何かある→Q2へ

Q2　自分に関連するファイル（知識）の置き場

A1　どこに何があるか分からない→DBの整理が必要

A2　どこに何があるか分かる→Q3へ

ここから難易度上がります。

Q3　自分に関連しないファイル（知識）の置き場

A1　どこに何があるか分からない→DBの整理とインデックスが必要

A2　どこに何があるか分かる→Q4へ

Q4　自分に関連しないファイル（知識）の思考の軌跡（context、文脈)

A1　分からない→インデックスとチームポータルが必要

A2　分かる→最強の組織です！

Q2までは常識で考えて分かる範囲です。整理整頓してあれば少なくとも自分が手を出す範囲に関してはすぐにアクセスが可能になります。仕事する上で自分の手を出す範囲さえ整理されていないのは問題なので早急に直しましょう。

問題となるのは組織が大きくなったときに発生するQ3以降のケースです。「知らないことは知っている人に聞けばよい」はある程度有効ですが、これは中規模までしか通用しません。アクセスだらけになります。これを防ぐには他の人にもファイルの場所が分かるようなインデックスやポインタを作ることが必要です。手法としてはWebシステム、Officeファイルなどのリンクつきの文書がお手軽です。

「ファイルをDBに置くにはトップレベルまでたどれるリンクでつながっていること」をファイルを置く上でのCriteriaにすればこれが実現可能になります。

さらにQ4というのは非常に難しく、人が考えた軌跡を追える、つまり情報にcontextが付属している状態です。これを実現するためには莫大なリソースが必要です。リソースと言っているのはユーザがそのシステムを使用するリソースと、そのシステムをメンテする管理者リソースの２つです。どの程度のシステムにするかはトータルコストで決まるはずです。ここで求めるシステムに必要なものは情報にアクセスしたときにcontextが付属したDB、ポータルが作成できるものです。いわゆるグループウェアと呼ぶものにはポータル機能がついているはずです。これはＱ３でのインデックス機能はそれに値しないのか？という疑問があるかもしれませんが、インデックスの作成とＤＢの作成作業が別のものはユーザが全てその作業を行うという性善説に立っているので不可能です。ここで目指すポータルとは性悪説に立ち、ユーザは楽な方法があれば手を抜くという考えからＤＢを作る前にポータルを作る必要があるというシステムになっている必要があると考えています。

次回は具体的なシステムについて議論します。

予定

WSS,SPS,Notes,Wiki