トカゲの独り言

Pliggでは、記事を登録する際に入力したURLに対して自動的に接続・HTML取得して、そこからタイトルやトラックバックURLを持ってくる機能があります。

しかしながらこの接続処理はプロキシに対応していないため、プロキシ経由での接続が必要な環境ではエラーになってしまい登録ができません。

URL が正しくないかブロックされています: (http〜

これに対する解決方法には以下の2通りが考えられます。

1. 登録時に接続しないようにする
2. プロキシを経由して接続させる

登録時に接続しないようにすることによって、エラーを発生させなくすることができます。これは管理者パネルから設定可能です。

1. "god"でログイン
2. [管理者] ≫ [設定Pligg Beta 9] ≫ [Submit] ≫ [Validate URL] を"true"から"false"に変更

設定は簡単ですがHTML取得処理が行われなくなるので、タイトルが自動的に設定されなくなり、手動で設定する必要が出てきます。

URLに対して接続してHTMLを取得する処理を行っているのは、pligg/libs/link.phpの58-59行目になります。

$r = new HTTPRequest($url);
$xxx = $r->DownloadToString();

ここで使用されているHTTPRequestクラスをプロキシ対応させることにします。なおPHPのスクリプトは初めて書いたので、おかしい所があるかもしれませんのであらかじめご了承願います。

この改造では、PEARのHTTP_Requestを使用しています。XAMPP for Windows 1.6.1では最初からインストール済みだったので何もする必要はありませんでしたが、それ以外の環境ではインストールが必要かもしれません。

元のHTTPRequestクラスは、pligg/libs/link.phpの813行目以降にあります。これを全部削除（コメントアウトでもいいです）して、以下の記述に差し替えます。

class HTTPRequest {

    var $_url;
    var $_proxy_host;
    var $_proxy_port;

    function HTTPRequest($url, $proxy_host = null, $proxy_port = null) {
        $this->_url = $url;
        $this->_proxy_host = $proxy_host;
        $this->_proxy_port = isset($proxy_port) ? $proxy_port : 8080;
    }

    function DownloadToString() {

        $options = array(
            "timeout" => 20,
            "allowRedirects" => true,
            "maxRedirects" => 3
        );

        require_once "HTTP/Request.php";
        $req = new HTTP_Request($this->_url, $options);

        if (isset($this->_proxy_host)) {
            $req->setProxy($this->_proxy_host, $this->_proxy_port);
        }

        return PEAR::isError($req->sendRequest()) ? "BADURL"
            : $req->getResponseBody();
    }
}

パラメータの設定は以下のページを参考にしました。

• PHPでのHTTPアクセスを超簡単に行える「PEAR::HTTP_Request」:phpspot開発日誌

後は呼び出す際にプロキシ情報をHTTPRequestに与えてやればOK。コンストラクタの第2引数がプロキシサーバ、第3引数がポート番号になります。

// $r = new HTTPRequest($url);
$r = new HTTPRequest($url, "192.168.0.1", 8080);
$xxx = $r->DownloadToString();

設定ファイルにプロキシ情報を書けるようにしたほうがスマートになるとは思いますが……

これで作業完了と言いたいところなのですが、このまま動かすとrequire_onceのところでエラーが発生してしまいます。

Fatal error: require_once() [function.require]: Failed opening required 'HTTP/Request.php' (include_path='.') in C:\xampp\htdocs\pligg\libs\link.php on line 817

php.iniにPEARのフォルダを含めているはずなのですが、include_pathからその情報がなくなってしまったため、ファイルの読み込みに失敗しています。

悩んだ挙句ようやく理由がわかりました。pligg/config.php 2行目の記述が原因でした。

ini_set('include_path', '.');

なんでこのような記述があるのかよく分かりませんが……これをコメントアウトしたところ動くようになりました。

• CodeZine：ソーシャルブックマークを構築できるオープンソース「Pligg9.1」日本語版リリース（SBM）

Pliggというオープンソースのソーシャルニュースシステムの日本語版がリリースされたので、Windows上のXAMPPにインストールしてみました。

XAMPPはバージョン1.6.1を使いました。インストーラを使って"C:\xampp\"にインストールして、ApacheとMySQLをサービスで動くようにしておきます。

コミュニケーション ビジネス アヴェニュー 株式会社 | 1 Pligg 9.1 の無償配布

Pliggの無償配布ページの問い合わせページで必要情報を記入してzipファイルをダウンロードしておきます。インストール手順はzipファイルに含まれるREADME.txtに書かれていますが、大体以下のような流れになります。

1. ファイルのコピー
2. データベースの作成
3. 設定ファイルのリネーム
4. （アクセス権設定）
5. インストールスクリプト実行

zipファイルを展開すると"pligg"フォルダができるので、これを"C:\xampp\htdocs\"にそのままコピーします。

XAMPPでインストールされたphpMyAdminを使ってデータベースを作成します。データベース名はなんでもいいですが、とりあえず"pligg"、照合順序は"ujis_japanese_ci"にしておきます*1。

rootで使うのは気が進まないので、[特権]から専用のユーザ"pligguser"を作成し、"pligg"データベースに対する特権を与えておきます。

以下のファイルの名前を変更します*2。

• C:\xampp\htdocs\pligg\settings.php.default → settings.php
• C:\xampp\htdocs\pligg\libs\dbconnect.php.default → dbconnect.php

ファイルの中身は後で設定されるのでそのまま。

この後、README.txtの手順ではいくつかのフォルダ・ファイルのアクセス権を設定することになっているのですが、XAMPPのApacheはローカルシステムアカウントで動作しているので、アクセス権はいじくらなくても問題ないと思います。

後はブラウザからインストール用のスクリプトを実行するだけです。

http://<サーバのアドレス>/pligg/install/

ページ下部の"proceed to the next step and install Pligg."リンクをクリックして次に進みます。

DB情報を入力して[Check Settings]を実行します。

Database Name	pligg
Database Username	pligguser
Database Passwrod	(pligguserに設定したパスワード)
Database Server	localhost(そのまま)
Table Prefix	pligg_(そのまま)

入力内容のチェックが行われて、問題がなければ[Next]を実行します。

必要なテーブルが初期化されてすべてのインストール処理が完了になります。あとは http://<サーバのアドレス>/pligg/ にアクセスすれば使えるようになっているはずです。

DBを作成するときに適切でない照合順序を設定した場合、以下のようなエラーが表示されます（これは"ascii_general_ci"を設定した場合）

SQL/DB Error -- [Illegal mix of collations (ascii_general_ci,IMPLICIT) and (ujis_japanese_ci,COERCIBLE) for operation 'like']

この場合は以下の手順でDBだけ作り直せばよいはずです。

• 作成した"pligg"データベースを削除する。
• 照合順序を"ujis_japanese_ci"にしてデータベースを再作成する。
• pligg/install を再実行する。

タスク管理システムの構築をにらんで、非常に原始的というか単純なシステムをまず考えてみます。

例として以下のプロジェクトのタスクを管理することにします。

Linuxをインストールし、SSHをセットアップする。余裕があればsambaのセットアップも行う。

タスク管理システムに必要な機能を検討し、設計・構築する。

通常のタスク管理システムでは最初にプロジェクトを定義しますが、ここではいきなりタスクを登録できるものとします。タスクは以下のような属性を持ったものとします。

• タスク名
• 詳細
• 時間見積もり

サンプル用に以下のタスクを登録するものとします（とりあえず詳細は省略）

タスク名	見積もり
Linuxインストール	1h
SSHセットアップ	1h
sambaセットアップ	1h
機能検討	4h

通常のタスク管理システムではプロジェクトに属する形でタスクを登録しますが、ここでは非常に単純な管理方式として「登録したタスクにタグを付与できるようにして、プロジェクト名タグをつけることによってプロジェクトを分類する」ことにします。

ソーシャルブックマークがURLに対してタグを付与して分類できるのと同じように、本システムでは登録したタスクに対して任意のタグを付与できるという前提とします。

登録済みタスクに以下のようにタグをつけます（プロジェクト名は適当に省略）

タグ	タスク名	見積もり
[Linux]	Linuxインストール	1h
[Linux]	SSHセットアップ	1h
[Linux]	sambaセットアップ	1h
[タスク管理]	機能検討	4h

プロジェクト以外にタスクに付与したい情報としては、以下のようなものが考えられます。

• マイルストーン：リリース、イテレーション
• 優先度：高低、必須……
• 完了状態：未着手、作業中、完了
• 担当者：foo,bar,baz……

マイルストーンは日付を扱うのでちょっと別ですが、ほかの情報は全てタスクにタグをつければ実現できます。

タグ	タスク名	見積もり
[Linux][優先度高][完了][foo]	Linuxインストール	1h
[Linux][優先度高][作業中][foo]	SSHセットアップ	1h
[Linux][優先度低][未着手][bar]	sambaセットアップ	1h
[タスク管理][優先度高][未着手][baz]	機能検討	4h

タグを組み合わせた検索機能を実装すれば、必要な情報を取り出すことが出来ます。

fooさんの残作業	[foo] && ![完了]
Linuxプロジェクトの未着手作業	[Linux] && [未着手]

非常に原始的なタスク管理システムであれば、これだけでも十分かもしれません（マイルストーンがないので期限が設定できませんが）。

ただ個人的には、全てのタグがフラットで区別がないのが若干気になります。柔軟ですがタグの意味が存在しないため、タグの設定間違い（未着手と完了を同時に設定するなど）なんかを扱うことは出来ません。

そこで「タスクにタグをつける」だけではなくて「タグにもタグをつける」ことが出来るようにすればよいと考えました。とりあえず単なるタグの設定（タギング）に対して「メタタギング」と呼ぶものとします。

使用イメージはこんな感じです（Cの列挙型のようなイメージ？）

• [Linux],[タスク管理]に対して、[プロジェクト]タグをつける
• [優先度高],[優先度低]に対して、[優先度]タグをつける
• [未着手],[作業中],[完了]に対して、[完了状態]タグをつける
• [foo],[bar],[baz]に対して、[担当者]タグをつける

今まで「タギングによってタスクを分類」していたのに加えて、「メタタギングによってタグ自体を分類」できるようになります。

こうすれば「同一のメタタグを付与されたタグは1個しかタスクに付与できない」というルールを導入することも出来るようになります。

（メタ）タグをサポートするシステムをそのままタスク管理システムに使うことも考えられますが、あまりにも汎用的な枠組みなので、そのままでは特定システムとして使いにくいものになることが予想されます。

そこでタグシステムを汎用的な基盤として利用できるようにして、その上に使いやすいインタフェースを持ったシステムを構築する形がよさそうな気がします。

この基盤はうまく設計されていれば、ソーシャルブックマークやちょっとしたCMSなんかにも利用できるかもしれません（SBMであれば、タスクの代わりにURL＋コメントを管理する）

なんとなく自分のタスクを整理・管理したいと思って、既存のToDo・タスク管理システム（インストールして使うタイプや、Web上のサービスとして提供されているもの）をいくつか試してみました。

• Web上のサービス
  • Basecamp[www.basecamphq.com]
  • Backlog[www.backlog.jp]
• インストールするタイプ
  • activeCollab.[www.activecollab.com]
  • ShareToDo[31tools.com]
  • WorkStyle[sourceforge.net]

どれも優れたサービス・システムだったのですが、自分の考えていた形式とはちょっと違っていたため使い込むには至りませんでした。

自分が想定していた形式はこんな感じでした。

• プロジェクトのバックログにどんどんタスクを追加する
• タスクごとに見積もり（期間）を設定する
• 期限を持ったマイルストーン（リリース・イテレーション）を設定する
• マイルストーンにタスクを割り当てる（そのマイルストーンで実現するタスク）

「タスクの粒度をどの程度にするか」という所が気になりますが、おおよそこういうイメージでした。

登録したタスクに対して期限を設定する方法ですが、システムによって以下のように違いがありました*1。

Basecamp / activeCollab / Backlog	マイルストーンに期限を設定し、タスクをマイルストーンに割り当てる
ShareToDo / WorkStyle / Backlog	タスク自体に期限を設定する

自分の考えとしては、あくまでも「期限を持ったマイルストーンにタスクを割り当てる」なので、タスクごとに期限を設定するシステムは使いづらいと感じました。

ではBasecamp / activeCollab / Backlogでよいかというと、今度はタスクごとの見積もり（時間〜日数）を登録することが出来ないようでした。

タスクごとの見積もり（絶対的な時間でなくタスク間の相対的なボリュームでもよいかも）はスケジューリングを行うときに役に立つ情報だと思うので、出来れば管理しておきたい情報だと考えています。

あと見積もり期間があれば以下のような使い道も出来るかもしれません。

• マイルストーンに設定したタスクの総見積もり期間が、実際のスケジュールをオーバーしていないかチェックする
• 総見積もり期間と完了したタスクの見積もり期間を用いて、進捗率を概算する
• 同じ情報を用いてバーンダウンチャートを作成する

試してないのですが、XPlanner[www.xplanner.org]はXPに特化しているらしいので、イテレーション毎に見積もられたタスクを割り当てて、それを消化していく形になっているのではないかと思ってます。が、あまりにXPに特化しすぎているため使いにくいとの意見もあるようです。

なかなか望んでいるような形式のタスク管理システムはないもので……個人のニーズにぴったり合ったものなんてのはなかなかないでしょうから、自分で作ってしまうのが一番確実かも。

システム構築における、コーディングに入る前のいわゆる詳細設計のあたりに対するアイディア？の話題です。

アーキテクチャのモデリングでは「4+1ビュー」という、システムを複数の視点から捉えてモデリングする考え方があります。

同じような考え方をもっと実装寄りで出来ないかと考えてみました。すなわちいろいろな観点からシステムをモデリングし、そのシステムを「可能な限り」定義づけることが出来ないかということです。

「可能な限り」の意図するところですが、まず現在でもシステムを定義づけるための手法としてUMLを用いたモデリングというものは行われています。しかしながらUMLだけではシステムの一部分しか定義することが出来ないと考えています。例えばUIを持ったシステム（GUIアプリやWebアプリ等）の場合、画面の定義（画面上のコントロールの定義等）や画面遷移を定義する必要がありますが、これらはUMLの記述の範囲外です*1。通常は「画面仕様書」のような別の資料にまとめることになります。

このような場合に「Webアプリを定義づけるにはUIの観点が必要である」と判断します。もちろん「Entity構造定義の観点」のような今までUMLで記述していた観点も必要ですし、ほかにもロジック・ビジネスルールを定義づけるような観点も必要になるかもしれません。

このようにシステムを定義づけるための観点を「可能な限り」洗い出します。もっともシステムを完全に定義できるだけの観点を洗い出せるかどうかはよく分かりません。あと「可能な限り」洗い出すと1個のシステムでも結構な数の観点が必要になるかもしれません。

洗い出された観点ごとにシステムを定義していくわけですが、そのときに観点に応じた言語を導入します。

導入する言語ですが、例えば「Entity構造定義」であれば既存のUMLのクラス図を用いることが出来ますが、「画面定義」なんかだと、そんなものを定義する既存の言語というのは恐らくないので、既存の画面仕様書の見かけの書式などを取り除いた本質的な部分（抽象構文？）を作り出す必要があります。画面の定義だとこういうものが必要になるでしょうか。

• コントロールの種類（テキストボックスやチェックボックスなど）
• 入力可能文字数
• 入力可能文字種：数字のみなど
• 値の制約：100未満、日付として妥当など
• その他必要なものいろいろ……

全ての観点に対して「その観点から見たシステム」を定義するための言語を導入します。言語の表記方法についてはテキストであろうと図であろうとかまいません。

観点に対する言語が定義できたら、それを用いてシステムを定義します。これによって、UMLだけよりもかなり濃いモデリングが出来ることになると思います。

（もちろん現実問題として、観点の洗い出し・観点ごとの言語の導入・観点ごとのシステム定義には大きなコストがかかるはずなので、そんな単純な問題ではないとは思いますが）

この考え方をうまく進められれば、MDAにつながったりしないかなぁと考えています。Syntax/Semantics？の定義された言語を用いてシステムを完全に定義できたとすれば、後は自動化ができそうな気もします。

完全なシステム定義まで行かないまでも、いったん必要な言語セットが出来てしまえば、それを再利用するメリットも考えられます。

例えば「Webシステムを作る」と言った場合、「それならこういう言語セットを使ってシステムを定義すればよい」といった具合です。定義済みの言語を用いてシステムを定義することによって、設計のブレや設計漏れを少なくすることが出来ると思います。

その他問題点なども書きたいので続く

あんまり続いてない。

• 『見える化』を読んで(その1)[blogs.dion.ne.jp]
• 『見える化』を読んで(その2)[blogs.dion.ne.jp]

遠藤功氏の『見える化』本から少し離れて、見える化をテーマとした別の本について取り上げてみます。

普段は「表紙に"SE"なんて書いてある本は(ry」ということで見向きもしない*1のですが、見える化を扱っているということで食わず嫌いはやめて見てみました。

なるほど見える化のカタログ・Tips集といった感じでいろいろ使えそうなアイディアが詰まっていました。

しかしながら遠藤氏の本の観点から見ると、重要な点についてあまり触れられていないのが気になります*2。それは解決すべき"問題"の存在です。

遠藤氏の本では一貫して"問題"の存在を取り上げています。「基準を定め、現状を把握し、その差異を問題として認識し、それを見える化を用いることによって現場が自立的に問題を解決する」ことこそが重要である、という感じです。

『SEのための見える化!の技術』でも、文中にいろいろと問題となる点が記載されてはいますが、明確な意図を持って問題を取り上げるというところまで入っていないように感じられます。また、取り上げられている各"見える化"手法についても、どういう"問題"に対するソリューションなのかが明確にされていないようでした。

少し話は変わりますが、ソフトウェア開発において、コードを書く前の工程としてUML等を用いたモデリングを行うことが多々あります。このモデリング作業ばかりをいつまでも続けて、なかなかその先の作業に進まない状態を"分析中毒"や"分析麻痺"と呼ぶことがあるようです*3。

モデリング（あるいは分析）作業ばかりを続けてしまう原因としては、

• 「何かやり残したことがあるのではないか」と不安に感じるため
• （やろうと思えば）モデルをいくらでも進化／深化できるため

等が考えられますが、これらは「解決すべき問題が明確になっていない」というのが根本にあるのではないかと考えられます。すなわち「どこまでやれば十分なのか」が分からないため止め時が見つからないということです。

これに対する対策の一つとして、実現すべき機能を明確にするというのが考えられます。実現すべき機能は通常ユースケースやユーザシナリオ・フィーチャーという形で認識されます。この場合「解決すべき問題＝実現すべき機能」ということになり、その機能を満たせるだけのモデリングさえ行えばよいということで"分析中毒"に陥ることが防げます。

『SEのための見える化!の技術』の話に戻りますが、この本は上述したように「何の問題を解決するための"見える化"なのか」があまり明確になっていないようです。この状態は"分析中毒"に似た状態と考えられます。とりあえず目に付いた"見える化"の手法をいろいろ試してみるものの、目的（問題）が明確でないためいつまでもその状態に終始する（止め時・効果が分からない）、いわば"見える化中毒"に陥りかねない不吉な匂いがします。

あくまでも問題意識を持った上で、それを解決するための手法の参考にするためのカタログ集として活用するのがよさそうです。

やっぱり表紙に"SE"なんて書いてある本は……

『見える化』を読んで(その1)[blogs.dion.ne.jp]の続き

この本では、知識のモード変換のうち表出化に相当するものが"知恵の見える化"として取り上げられています。知識を表出化する＝知識の見える化とはなかなかうまい言い方だと感じました。

私も野中郁次郎氏・竹内弘高氏の書いた知識創造企業[www.amazon.co.jp]を読んで、知識の表出化(Externalization)・連結化(Combination)等の必要性は感じていましたが、それに対する適切な手法というのはなかなか見出せませんでした。

私が考えていた（ソフトウェア開発の分野における）知識の表出化というと、今まで携わってきたシステムに関する知識を整理・分析してパターン化したりして纏め上げるというイメージでした。もちろんこのような作業には手間がかかるため、必要だとは分かっていても導入は進んでいませんでした。

この本でもそのような困難さに触れているのですが、面白い点としてそのような知識の表出化は害をなす可能性があるとも書かれています。

しかし実際には、個人の持っている知恵を体系的・論理的に分解し、わかりやすく「見える」ようにするのは簡単なことではない。専門家やベテランと呼ばれる人たちの「頭の中」を「見える」ようにしようというのは難易度の高い取り組みであり、また、気をつけないと安易に「他人の知恵」に頼ろうとする弊害を生み出し、自分の頭で考えることがおろそかになってしまいかねない。

なるほど、確かに解法があったら何も考えずにそれを使おうと考える可能性はありそうです（あるいはググって出てきたサンプルを何も考えずにパクって「出来ました」って言うような感じ？）。

そんな「知恵の見える化」で心がけなければならないのは、問題解決の「答」を追求するのではなく、答を導き出すための「考えるヒント」を「見える」ようにすることである。

ということで、この本には３個の「ヒントの見える化」が挙げられています。

• ノウハウの見える化
• 思考回路の見える化
• ストーリーの見える化

「ノウハウの見える化」では、住宅設備の修理が事例として挙げられていて、いかにしてベテランが効率よく故障箇所にたどり着くかのノウハウを共有するというものです。

これはソフトウェア開発で言えばデバッグのノウハウとして応用できそうです。ある程度慣れた人であれば、発生する現象を見るだけで例えば「これはスレッド絡みの問題ぽい」とか言って、適切な位置にブレークポイントを設定してデバッグする、ということが出来ます。しかし慣れるまではなかなかバグの発生箇所にたどり着けないということもあるかと思います。そういう場合に「こういう現象はこういうバグの可能性がある」「こういう情報をデバッグログに出す」とかそういうベテランのノウハウがあると非常に役に立ちそうです。まさにソフトウェアにおける「故障箇所の修理」と

「思考回路の見える化」では、「メソドロジー」（方法論）や「考える道筋を見える化」として、結論ではなく思考過程こそが重要であるといった感じです。

これは例えば、クラス構造・パターンだけあって「こういう構造にすべし」というよりは、なぜそういう構造に至ったのか、どのような制約のもとでそういう構造になったのか、という思考のステップも重要であるとかそういう感じかなぁ、なんか違う気もするけど。

ここでは文書管理の事例が挙げられています。とは言っても単なる文書管理ではなく、文書同士に「使った」「使われた」という関係性を持たせて管理しているとのことです。

たとえば、建設案件の文書を開くと、そこで過去に使われた建設装置の技術文書に辿り着ける。さらに、建設装置の文書から、そこで使われている要素技術の文書を追跡できる。逆に、要素技術の文書から、その要素技術を使った建設装置の文書、さらに、その建設装置を活用した建設案件までさかのぼることができるのだ。

これはソフトウェア開発でもそのまま活用できそうです。開発の際にはいろいろな技術情報・文書を参考にしますが、これらをプロジェクトもしくはプロジェクトで作成する文書などに関連付けておきます。このような情報が蓄積すれば、技術情報を経由して同様の技術を使った別プロジェクトに辿り着くことができ、そこでの設計情報なんかを参考にすることが出来るようになります。またそのプロジェクトに関連付けられている文書を見ることによってより効率よく知識を広げることが出来そうです。

というわけで、知恵の見える化はぜひ試してみたいところです。まだ書くことがあるので続く。

ものすごく久しぶりの書き込み……

昨今ソフトウェア開発の分野でも『見える化』という単語を目にすることがしばしばありますが、そのものずばりのタイトルの本があったので読んでみました。普段よく読んでいるいわゆる技術書ではなくビジネス寄りの本でしたが、非常に興味深い内容でした。

この本で一貫して述べられているのは、「見える化というのは問題に対する取り組みである」という点です。

ソフトウェア開発というのは物理的な実体を伴わない*1ため、状況が見えにくい側面があります。そういう状況を改善しようとして、開発に関連するいろいろなものを見えるようにしようという取り組みはしばしば見受けられますが、この本の考え方からするとあまり適切な取り組み方ではないようです。

あくまでも業務における問題の存在を認識し、それに対する手段として"見える化"を導入することによって効果があがる、ということです。正確には"見える化"そのものが問題を解決するというより、問題に対する"気づき"を生み、そのことによって現場が問題を解決するための行動に移す、という一連のフローに寄与するというところです。

このようなフローを実現するには、現場が積極的に問題を見えるようにし、見えたものに対して一丸となって取り組むような体制が必要です。この本では"自立的問題解決能力"と記述されています。高い"当事者意識"を持って問題と向かい合うのはもちろんのこと、現状に満足せず常に高い目標を掲げ、その目標とのギャップを"問題"として認識し改善を続けていく、というのが"自立的問題解決能力"を持った目指すべき組織像のようです。

ただ現実問題として「自分の問題を見えるようにするのは抵抗がある」「なるべく他の人の問題に関わりたくない」というのが現場の本音としてありそうです。これについては、

• 個の責任による問題発見
• チームによる問題解決

を地道に浸透させるしかないのかもしれません。「問題を早期に見えるようにするのは良いことである」という組織の文化を育むことができるかどうかが鍵となりそうです。この本の最後にも以下のような記述があります。

「犯人探し」的なことで職場が右往左往することもあるかもしれない。しかし、「見える」「見せる」という新たな行動様式を組織内に根付かせるためには、やはり多少の軋轢はやむをえない。軋轢を乗り越えてこそ、新たな価値観や行動様式は定着するのだ。

ちなみに現場での自立的問題解決能力というあたりを読んでいて、(比較的)現場主導なアジャイル開発や自己組織化といった要素を思い浮かべました。自分たちでタスクや問題を設定してそれに取り組み、高い当事者意識(コミットメント？)を持って開発に望むというそのスタイルとの関連性の考えられそう*2で興味深いところです。

他にも書きたい要素があるのですが、眠いので明日以降に……

• 知識の見える化(知識創造、表出化)
• ソフトウェア開発との関連
• 他の"見える化"を取り上げた雑誌について

これは『データの囲い込みは知識利用の範囲拡大を阻害する？[blogs.dion.ne.jp]』の続きです。

前回のエントリでは、知識・情報を管理する便利なシステムがあったとしても、いったんそこにデータを登録し始めると、それらのデータはそのシステムからしか利用できない（システムに囲い込まれる）、という事を書きました。

データベース方面では、システム・プロセスからデータを独立させるような開発アプローチ（DOA?）がありますが、これはシステム・プロセスよりもデータの方が安定している・変化しにくいという性質を利用していると考えられます。まあ昨今のシステム開発においてこのようなアプローチが取られているかどうかは疑問ですが。

ここでデータの代わりに知識・情報で考えてみても同様のことが成り立つと考えています。

• 知識・情報はシステム・プロセス（要するに使われ方）から独立している
• 知識・情報は使われ方と比較して安定している（もちろん内容はアップデートしていかなければなりませんが）

このようなアプローチを採用する場合、システムから独立したデータストアが必要となります。DOAであればRDBMSがシステムから独立したデータストアの役割を担うことになります。同じように、知識・情報（というか非定型データ）を格納するためのシステム非依存のデータストアの役割を担うものとしてメタデータDBというものを考えてみました。

システム非依存な非定型データストアとして、単なるテキストファイルを使用するという選択肢も考えられます。テキストファイルにフリーフォーマットで情報を記述しておけば、さまざまなプログラムから簡単に利用できますし、（最近広まりつつある）デスクトップ検索システムによる検索対象としても使えます。

ただし単なるテキストファイルでは、その利用の仕方が限られてしまいます。検索する場合は全文からの検索になってしまいます。分類に関しては、ファイルシステムのフォルダ階層を利用して分類することが出来ますが、この場合複数の観点からの分類が出来なくなります*1。その他利便性のために付加情報・注釈(annotation)をつけようとした場合、単なるテキストファイルでは表現力が不足している（というか構造化されていない）ので、XML形式なんかで付加情報と本文を同居させることが出来ます。しかしながら、そのような付加的な情報をテキストファイルの本体部分に含めてしまうのは、いささか違和感を感じます。

このような状況に対して、メタデータDBでは以下のようなアプローチを考えています。

• ファイルシステム上のファイルに相当するものとして、ノード空間上のノードを導入する。ここにはファイルと同様に何らかのコンテンツを格納できる。
• ノード間はリンクによって関連付けられる。これはツリー構造に限定しない（閉路を含んでもよい）。
• ノードに対して任意のメタデータ（名前＝値）を付与可能とする。これはノードの保持するコンテンツには影響を与えない。
• ノード空間から、コンテンツ・メタデータ・リンクなどを条件としてノード集合を検索可能とする。

これによって上記のテキストファイルでの問題点が解決されると思います。

さらにメタデータDBへのアクセスをAPI経由で行うようにすれば、複数のシステムが同一のメタデータDBへアクセスできるようになります。従来であればファイルシステム上にメールのデータや文書データ・HTMLファイル・いろいろなシステム（BTSやBlog等）が管理しているデータなどが存在していましたが、それらを同一DB上のノード集合として表現できるようになります。

この状態までくれば、メールだろうと文書ファイルだろうと横断的に検索をしたり、統一されたメタデータを付与してグルーピングしたり出来るようになります。RDBのテーブル構造やODBのクラスのようなものはないので、登録されている全てのものが等しく操作対象になります。

……というようなものが存在すれば、いろんなシステムで入力されたデータが、そのシステムでしか利用できないなんてことがなくなって、蓄積された知識として幅広く使われるようになるのではないかと期待しています。今度はこのDBに対して囲い込まれることになるとも言えますが……

最近知識管理に興味があるのですが、そんな中こういう記事がありました（ちょっと古いですけど）。

QuestionLaborは，同異義語辞書を内蔵しており，同じ意味の言葉が使われている情報を探し出すことができる。1つの質問に対し複数の回答をつけることができ，最終的な回答に至るまでの履歴を記録できる。質問と回答はインターネットで公開することを前提にしており，簡単に公開することが可能。またWebブラウザ上のWYSWIG HTMLエディタで質問や回答を入力できる。

国内初のオープンソースCRMとFAQ管理システム，ネットワーク応用通信研究所が無償公開 : IT Pro ニュース[itpro.nikkeibp.co.jp]

フリーのFAQ管理システムが公開されたという記事ですが、FAQだけに囚われなくても、ちょっとした知識・ノウハウの蓄積なんかにも汎用的に使えそうです。

このシステムに対してどうこう言うつもりは特にないのですが、こういうナレッジマネジメントシステムやグループウェアを見ると、便利そうだと思う反面「データがそのシステムに囲い込まれてしまう」不安を感じます。

どういう事かと言うと、

システムに登録したデータは、そのシステムからのみ利用できる。すなわちそのシステムで提供されている機能以上のことは、いくらデータがあったとしてもできない。
別のシステムから別の用途でデータを利用しようとしても、利用できない（又は利用できるにしても容易には利用できない）。

ということで、あるシステムに登録したデータはずっとそのシステムの中でのみ利用されうる、という考えです。

このFAQ管理システムについて言えばPostgreSQLを使っているとの事なので、そのテーブル構造の情報を何らかの方法で入手すれば、別の用途で利用できなくはないかもしれません。ですが、あまり一般的なやり方であるとは思えません。

このようにいったんあるシステムを使い始めると、データがそのシステムに囲い込まれてしまい、せっかく登録した有用な知識・情報を多角的に利用することが出来なくなってしまうのではないかという不安を感じます*1。

これに対するアプローチとしては、以下のようなものが考えられます。

1. 出来るだけ広範な用途に対応できるように、システムの機能をどんどん拡大する。
2. データは囲い込んでおくが、別システムなどから連携しやすい仕組みを取り入れる。
3. いろんなシステム・用途から利用しやすくなるように、システムからデータを独立させる。

1番目はグループウェア的なアプローチです。Webメール・掲示板・スケジューラなどいろんな機能を盛り込んで、各機能からいろいろな形で情報を利用するようなイメージです。この場合たとえデータが囲い込まれていても、それに対して必要十分な機能が提供されるので不安・不満が抑えられます。ただし機能が肥大化して複雑になったり、コスト増加などが懸念されます。あと必要な機能が提供されていなかったらほとんど手も足も出ないことになりかねません。

2番目はWebサービスなんかで機能を提供するようなイメージです。例えばamazonは膨大な書籍情報を囲い込んでいて、通常はWebページから限定的にそれらを利用することになりますが、Webサービス経由でその情報を利用することによって異なった用途で情報を利用することが出来ます。もっともこの場合でも、結局はあらかじめ提供されているWebサービスの機能を超えることは出来ないですが。

3番目は、極端な例では「扱うデータを全てをテキストファイルにしてしまえばよい」というテキスト至上主義的な考え方です。そうすれば、例えばデスクトップ検索アプリを使って横断的にキーワード検索したり出来るようになります。しかしながらテキストだけでは表現力不足*2なところは否めないです。あと全文検索だけでは効率的な知識・情報検索には若干物足りなさも感じます。

というあたりを踏まえて、

• 複数システムから使えて
• プレーンテキストよりは表現力のある

メタデータDBの話に持っていく、という予定です（続く）。