今、ウチの会社はWebサイトの構築がメインのビジネスになっていて、といってもぼくが作るわけではなく社長が作るのですが、その中に販売サイトの構築もする案件があるので、それをどういうECサイト構築システムで作ろうかという議論をした。
当然オープンソースのものを採用するのですが、ある国産のパッケージについて調べているとき、その開発コミュニティサイトを覗いた社長が軽く荒れているようでと言ってきた。ぼくも覗いてみると詳しいことはよく分からないのだが、どうも機能不足のところがあってそこの機能をなぜ付けないかといった要求を出したが、その対応がぬるいと怒っているようだった。
これは、真のオープン開発とは言えないわけで、本来参加者は対等な立場で議論していくというgive&take精神でないと成立しないはずだ。オープン開発だから何でも要求すればやってもらえるみたいな考えはNGなのです。その辺がオープン開発の難しいところで、だからと言って全くみんなが均等に参画できるかというとそれもありえないわけで、実際にはリーダーがいて広く議論するが、最終的にリーダが仕様だとか、体系を決めていくというのがうまくいくのです。
だから、自由の裏返しに責任があるように、オープンには規律みたいなものがあるわけで、そこのさじ加減が大事なように思われる。
それと、もうひとつは、オープンソースに向いているものとそうでないものがあるような気がする。上述の例でもけっこう上位機能というか、アプリケーション寄りの高いレイヤーのところの議論なので、ここのあたりは論理性からだんだん離れていくから難しいようだ。いわゆる“そこは趣味の問題でしょ”みたいなところに入ってくる。
逆にフレームワークや開発ツールみたいな道具を作る下位のレイヤーでは、オープンソース開発がすごく有効であると思う。その道具の使い方になると前述したように好き嫌いみたいなことが出てくるので難しくなるようだ。
先月から、日本BPM協会のComponent研究会というBPM（BusinessProcessManagement）のためのComponentの必要性やそれを使ったシステム構築方法を研究するワーキンググループに入って議論しているんだけど、ここでもオープンソースでビジネスプロセスを開発したらどうかという話になった。
そのときぼくが言ったのは、それはかなり難しいのではないか、まず自分たちのビジネスプロセスを出せるのかという問題が生じる。ノウハウが詰まったものを競合相手に出しますかということです。それならノウハウが詰まったものじゃないところでやればいいじゃないかと言うかもしれませんが、そんなものはすでに業務パッケージのなかに埋め込まれているわけで、そうではないところを開発するところに意味がある。
また、参加者のインセンティブが何なのか、自分の知恵、技術、ノウハウを提供してどんないいことが待っているのかになると、もちろん金銭的なメリットはないのだから、名誉なのか、純粋な知的満足なのかそんなところなわけで、そうなると、企業の従業員が自分の仕事についてそのノウハウなりを出して喜ぶだろうか。あらかたこんなことを言った。ただ、まったく否定したわけではなく可能性はないわけではないので、これからの課題だと思っている。
最初の話に戻ると、結局上位の概念のところは、趣味が違うんだったらその違うものは違うように別々に作っておけばいいんじゃないか。すなわち、それをComponentとして持っておいて、それらを疎結合の組合わせでプロセスなりシステムを作っていく。各Componentは標準化されたものとし、それらの組合せの妙で個性化・差別化するという考え方が大事である。こういったこともその研究会で話した。
基本的にプラグインやMashUpも同じ考え方だとぼくは思っている。これから、ここの議論をしていこうと思う。