mark-wada blog

昨日、第4回BPM-J交流会で「ユーザ目線の実践的BPM」と題して講演を行なってきました。この会は、日本BPM協会の主催で行なわれるもので、BPMの事例や研究結果などを報告する場です。

今回が、「ビジネスコンポーネント指向開発」（wadit法）の最初のお披露目ということになります。（ワーキンググループの数人には見てもらっていますが）　
出席者の中には、IPA（独立行政法人情報処理推進機構）や日経BP、ITmedia　のひとたちもいて、反響はけっこうあったと自負しています。そのうち記事になると思います。

注目されたのは、業務コンポーネントを書類というオブジェクトの状態遷移ととらえたこと、ワークフローにミクロワークフローとマクロワークフローがあること、アプリケーションプラットフォームを3層構造にしたことあたりです。しかし、やはりというか、残念ながらオープンソースCMSのことをよくご存じない方が多く、そこのところを理解してもらうのに苦労した。

というのも、最大の目玉であったBPMとCMSの連携で実際に動くものをみてもらう目論見がもろくも崩れてしまったのです。恐れていたことが起きたのです。

もちろん会場には早くに行ってプレゼンの準備をしたわけで、今回は2台のPCと2台のプロジェクターでやることにして、デモ用のPCを立ち上げたまではよかったのですが、プロジェクターを接続してつなげたとたん、ああ砂時計が消えない。どうやっても戻らない。PCに詳しいひとに来てもらったがダメ。結局、再起動するはめに。

ところが、１台のPCに3つのサーバーをインストールしているという離れ業をしているので、起動に時間がかかる。しかも、ぼくにとっては難しい。結局間に合わず、最悪の場合を想定して用意していたキャプチャ画面を使ったパワーポイントでの説明になってしまった。

これだと、やっぱりダイナミックさや実際の動きが見られないので効果は半減です。いやー、実に残念であった。それでも、だいたいの理解を得られたのでほっとしています。

ということで、親子の合作であるwadit法がいよいよ始動です。まずは、知ってもらうこと、賛同を得ることから、徐々にパートナーをみつけたり、実際のプロジェクトを進めたりといったビジネスに展開できたらと思っています。

これから、このカテゴリーを「親子丼的ビジネス奮闘記」と称して、親子二人でビジネスに苦闘する姿を書いていきたいと思いますのでよろしくお願いします。

IT業界でビジネスをやろうとすると、当然のようにある程度知名度があるほうがいい。ひとに会ったときに“ああ、あの○○さんですね”と言われたらしめたものだ。ぼくは、もとの会社にいた時は狭い範囲だがちょっとは知られていたが、今は全く誰も知らない。

一方、息子の方はIPAの未踏ユースの準スーパークリエーターになったり、NHKのデジスタに出たり、最近はCDTube やZonTubeといったマッシュアップサイトでけっこう名が知られている。

だから、今度はぼくが少し露出して名前を売ろうかと思っている。その第一弾がおとといの講演であったわけです。

で、早速昨日のITProの最新ニュースに記事が掲載されました。

記事のタイトルが、“「BPMを実践しようとする企業にはWeb2.0が有効だ」、日本BPM協会が研究成果を報告”となっている。この記事を書いた記者とはもう何年も前から知っているので、そう間違ったことは書かないが、ニュアンスが微妙に違う。これは、こちらの主張と記者の観点とはずれてあたりまえなので仕方ないことなのだ。

というわけで、まずは日経BPから始まりましたが、少しずつ拡げていこうと思う。こうしたことをやっていくと実はいろいろな波及効果があるもので、その日経BPの記者と一緒にIBMの清水敏正さんに再来週会いに行くことになった。清水さんは、技術理事でSOAについての有名なアーキテクトの方です。

まずは親子で名前を売りましょうなんてまるで芸者の母娘みたいですね。

このエントリーのタイトルに“親子丼的”という言葉を使っているが、ただ単に親子でやるからそう付けたわけではない。この親子丼というのはそれなりの意味がある。

丼ものはいろいろあるが、ほとんどは、単品であって、組み合わせは少ない。なかには、無理やりくっつけたような鮭いくら丼とかがあるが、二つの素材がうまくミックスしてまた新たなものを生み出すようなものは親子丼くらいではないでしょうか。

さらに、この場合の二つはお互いにどちらかが上ということではなく、１+１が２以上になっていると思いませんか。すなわち、それぞれが離れてしまうと、たまご丼ときじ丼なんだろうけど存在感が薄いですよねえ。ところが、一緒になるとどうです立派な丼に生まれ変わるというわけです。

さて、賢い読者はおわかりでしょう。そうです「マッシュアップ」なんです。サービスとサービスを組み合わせて新しいサービスを生み出すのがマッシュアプですが、まさにこのことです。

単に並べておく組合せとは違い、１+１が２以上、あるいは新たなサービスを生むというところがポイントなのです。どちらか一方だと限界があったり、生かされないがそれが合わさると、いままで以上の機能が発揮されるとか、魅力的になるとかいったことである。

翻って、ぼくらのビジネスを考えてみる。ブログでも何度も言っているのが、企業の情報システムと個人が家庭で使っているネットシステムとは大きく乖離していて、壁があるというより、双方で相手が見えていないという問題がある。ビジネス側の人たちは、Web2.0のことをあまりよく知らないし、ネットの人たちはビジネスシステムには無関心である。スーツとギークの断絶である。

ところが、それぞれのアーキテクチャやテクノロジーを相互乗り入れさせたら、目からウロコのことがいっぱいあるのだ。ですから、ぼくらは、ぼくが長年企業で経験した多くの情報システムのことを語り、社長（息子）が最先端のネットの動向をレクチャしてくれると、そこでスパークするものが出てくると思っている。現に、いま進めているシステム開発技法はまさにこのコンセプトと技術とそして何よりも人間同士のマッシュップから生まれたものなのです。

当面は、この親子丼的な発想を忘れずにビジネスをやっていきたいと思っている。そのうし、お互いに離れて天丼やうな丼（なれればいいが）になるかもしれないが。

先日、ＩＢＭの清水さんというＳＯＡの権威のひとと会っていろいろと話す機会があった。いま、ぼくらがやっているＢＰＭやＳＯＡについて、デモをしてその評価をしてもらった。それなりに賛同も得られ、高い評価をいただいたので喜んでいます。ぼくのデモのあと清水さんにも若干ＳＯＡについて説明してもらったら、驚いたことにほとんど同じことを言っていたのです。

それで、お話は単にＳＯＡやＢＰＭにとどまらず、ＩＴ業界の構造にも言及していました。ぼくも以前から人月ビジネスから抜けられない今の業界について疑問を投げていたので盛り上がる。

清水さんは米国の事情にも詳しいので、日本との比較が面白かった。米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。

ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。

日本もこれまでのやりかたでは、欧米やインド、中国との競争に負けてしまう、というより、賢いユーザは気がついてくるはずだ。すでに改革をしているユーザ企業もあると思う。今後は、自社内にＩＴアーキテクトやプログラマーといったエンジニアを抱え、自力で真に自分たちの事業の役に立つシステムを構築していく動きにならざるを得ないのではないだろうか。というようなことを話してお互いに何とかしなくちゃと嘆いたのであります。

さらに、どうしてこうなってしまったという話題にも言及して、ひとつは、企業のＩＴ部門の弱体化･人材不足ともうひとつはベンダーへのアウトソーシングの流れではないかというのが論点となった。前者ではおしなべてまだ日本の経営者の意識として、ＩＴに突っ込んでこないことと名前の通ったベンダーにまかせておけばいいというのがあって、自社でリソースを抱えることのほうがコストがかかると思っている。このへんの意識が変わることが大事であるが難しい。

後者では、ＩＢＭが先陣を切ったがユーザ系情報子会社を買収して、親会社のフルアウトソーシングをするのがはやった。さすがに最近は見直しがかかったと聞いているが、これにより、ユーザ系の情報子会社のスキルが消失してしまった。清水さんはＩＢＭのひとなのにこれについては反省していた。

これからは、日本でも内製化の方向に行くべきだと考えるが、その時のコンセプトあるいはアキテクチャはBPM on SOA が適していると清水さんもぼくも思っている。ただし、そのためには、清水さんが盛んに言っているように、ＳＯＡ、ＢＰＭの正しい理解が必要である。単なる技術ではなく、ビジネスのありよう、サービスの構造というもっとビジネス寄りの考え方であることをきちんと咀嚼できるようにならなくてはいけない。

これについては、清水さんは会った次の日に日本JAVAユーザ会セミナーでのパネルディスカッションにパネラーとして出ていて、そこでの発言がITProに掲載されているので参考になる。この記事を書いたのがぼくと清水さんを引き合わせてくれた日経BPのY記者です。

ぼくは、それと実践として使える道具もなくてはいけないということを言った。実はこうした道具と技法の提供がぼくら親子丼的ビジネスの柱のひとつなのである。

昨日、日本BPM協会のUさんと一緒に、ITmediaのSさんに会う。以前からぼくが開発した新しい開発技法について、どうやってメディアに載せていくかということを話していたが、昨日でだいたい具体的にどうするか決まった。それに基づいて、詳細な内容や進め方などについてぼくのほうでまとめることになった。

大まかに言うと、＠ITにある「BPMプロフェッショナル」という情報ポータルの一画にぼくのコラムというか意見が連載されて、それに従った研究会あるいは勉強会をBPM協会のWG4というワーキンググループで行なっていくというものです。

このプログラムのポイントは、ユーザ参画型であることと実際に動くツールを作っていき、それを実践する人たちをそこにどう糾合していくかというところです。

従来、こうした研究会やフォーラムのようなものは、得てしてベンダーやSIerのいわゆるIT業界のひとたちだけでやられている。しかし、いまわれわれがめざす「BPM on SOA」に基づく革新的開発技法は、ユーザの視点があるいはユーザ自身が開発できることが肝であるがゆえに、ユーザの参画が必須なのだ。

で、この場合のユーザというのは、まさにエンドユーザでITを知らないが実業務をよく知っている人が該当する。ところが、そういう人って見えてないですよね。どこにいるのかわからない。だから、ここのところで自分の手で役に立ついい業務プロセスを作ってやろうと思っているひとを見つけ出し、この世界に引っ張り出すのが大変なのだ。これについては、昨日の3人とも異句同音に嘆いていた。

もしそこがどうしても難しいのであれば、ユーザ系の情報子会社から捜すことになる。いかに、ユーザ感覚のものをつくっていけるかはここがポイントだ。

ものづくりのほうは、まだβ版なので参加してくれるみなさんと、よく議論しながらブラッシュアップしていきたいと考えている。

おそらく、オープンソースプロダクト開発のようなプロジェクトとはならないが、出来るだけ集合知を発揮できるようなやり方をしたいと思っている。

さて、いよいよメディアに乗っかっていくわけで、どうなるか不安でもあるが楽しみでもある。

一昨日、GoTheDistanceさんのブログエントリー「アメリカにはSIerなんて存在しない」がぼくのブログ記事をきっかけにして書かれている。そのエントリーがはてぶの人気エントリーのホットテン入りした。そのためぼくのこのブログのアクセスも急増した。

どうもSIerというものに何らかの問題意識をもっておられる方が多くいるのように思えた。ただ、昨日、GoTheDistanceさんも書いてあるように、若干誤解されるようなところがあったので、ぼくもそれについて補足する。

ぼくも、アメリカにSIerがいるとかいないとかは大きな問題ではなく、むしろ日本のIT業界におけるSIerという存在、あるいは役割はいったい何なんのだろうか。今のような構造でいいのだろうか、というようなことを言いたかったのだ。そして、こうした問題を考えたときに、ヒントとしてアメリカの企業のITに対するスタンスが参考になるのではないかということである。

まずは、SIerの定義になるが、これについてもぼくはそれほど明確にする必要もないと思っている。ぼくは、ユーザ側からしかITを見てこなかったので言わせてもらうと、本来企業の情報システム部門がやるべきことを、私たちはITのことはよくわかりませんので、おまかせしますのでよろしくやってくださいと頼む相手のことで、だから、決まったエリアがあるわけではなく、その企業ごとに必要な開発と運用をやってくれるという非常に便利な存在なのである。

こうした関係がいいのか悪いのか。これまでは、表沙汰にするのがめんどくさいのか、よくわからないのかあまり声高に議論されてきていないように思える。で、ここに来て何となくこのままじゃいけないんじゃないかと思い出してきたのではないだろうか。

これは、ユーザ、SIerのどっちが悪いという話ではなく、両方に問題がある。ユーザの中には、ITは自分たちにはよくわからないから専門家にまかせておけばいいやという経営者が多い。銀行のオンラインやPOS、配送システムなど事業の根幹に関わるものは、製造業が、生産プラントや生産ラインにこだわるように、経営者もしっかり見ているが、いわゆる一般的な企業情報システムは、ちゃんと期限どおり決算してよねと言うくらいじゃないだろうか。

そして、単にシステムコストを削減することに興味を持つだけとなる。いくら、情報システム部門がコストダウンより、付加価値向上のための投資が重要ですと言ったところで説得できる力をもち得ない。SIerに対しても、どうしてこんなに高いのよ、と言ったところで、それ以上指摘ができる技術力もない。

一方、SIerといえば、難しい専門用語を駆使して、これも必要、あれも必要とばかり、隣のスーパーに行くのに使うだけなのにベンツを売ることになる。そして、ユーザの要件をよく聞いて、経営に役立つシステムを作るんだと意気込んでも、ユーザはなかなか要件を言ってくれないで仕様が固まらない、最後はばたばたとプログラマーを投入して、何でもいいから仕上げて、それにかかった人件費はくださいとなる。

こうして、ユーザとSIerがお互いに嘆きあう構図はもうやめにしなくてはいけないと思う。本来、そこを接着すべき情報システム部門あるいは情報子会社が弱体化していることも問題なのだ。

これまで言ってきたことはみんなに当てはまるわけではないが、当たらずとも遠からずの情況ではないでしょうか。

いまこそ、ユーザを含めたIT業界全体の構造を変えていかないと相変わらず３K職場などと揶揄されてしまう。その改革の方向性として、アメリカの企業の内製化という姿がヒントになっているわけです。すなわち、SIer､ベンダー主導からユーザ主導へと舵をきることが、それこそ顧客満足度の高いシステムができるのではないでしょうか。

そのとき、SIerはどうすれば幸せになれるのだろうか。ぼくは、そのキーワードを「専門化」であると考えている。いま、頂上にあるメーカー系ゼネコンからピラミッド的に子、孫、ひ孫と階層化され、しかも同じようなことをやっている。これを解体して、ある領域に強みを発揮する専門会社群を形成するのだ。そして、それをネットワーク化して、適宜組合せを変えながらビジネスを展開するイメージだ。

実は、この考え方は見ようによっては、「BPM on SOA」に似ていると思いません。システムそのものの構造をビジネス（業界）の構造に当てはめるのです。

結局、「専門化されたところから生み出された高品質のプロダクトおよびサービスを使ってユーザが自分たちの手で自分たちの業務システムを組み上げる」というのがめざすところです。
具体的に、こうした考えに則ったプロジェクトを走らせますのでよろしく。

ITで起業するとなると、ビジネスの形態をどうするかをまず考えなくてはいけない。簡単に言えば、商材を何にするかである。ITでは大きく二つの流れがある。自らの企画でプロダクトやサービスを作って提供するというものともう一方が受託開発である。能動的なビジネスなのか、受動的なビジネスなのかである。あるいは、フローのビジネスかストックのビジネスかである。リスクという点からいうと受託開発の方がリスクは小さい。

受託開発にも自分たちで営業してお客さんを捜してくるというのもあるし、大きな開発会社の下請けとして仕事を回してもらうというのがある。ただ、いずれにしろ、受託開発というのは開発者ひとりあたりの仕事量と単価で収益が決まってくるから、仕事を安定的に獲るにはどちらの形態がいいかだけの差になる。

この場合、経営は開発者をいかに遊ばせないように間断なく仕事を持ってくるかに腐心することになる。これをぼくは「受託開発の罠」と呼んでいる。せっせと稼働率をあげることにだけ力を注ぐわけで、単なる人貸しと変わらなくなってしまう。結局、人のキャパシティの範囲でしかビジネスが拡大しないから、会社が大きくなっても単純に人数が増えただけの話で利益率が同じで面白くもない。

さて話は突然変わるが、ぼくが行く近所の床屋はぼくよりちょっと年下のオバサンが経営している。椅子が４つ置いてあって、そのオバサンともうひとりを雇い入れているのと見習いの女の子の３人で切り回している。そのオバサンはすごいおしゃべりで、ぼくは髪を切られながらうとうとするのが好きなのに、ずっと相槌を打たなくてはいけない。でも、ときどき面白いことを言ってくれるので感心することもある。

このあいだ、人を雇うことについての話になった。いま、同じ年頃のオバサンを雇っているが、そのちょっと前はオジサンがいた。なぜ辞めさせたのかと聞いたら、“その人、私の言うことを聞いてくれないんです。わたしは、お客さんの髪の毛はあまり短くしてはいけないといっているのに、その人はすごく短くしてしまうのです”、“でもなぜいけないんですか？”とぼく。“だって、短くしたら、お客さんの来る回数が減るじゃないですか”。すごいですねえ。立派な経営方針ですね。

この店けっこう繁盛していたので、さらにぼくが、“もっと人を増やしてもうけたら”と言ったら、“お客さん、そこが難しいところなんです。ひとり増やしたいが、その増えたひとり分を賄えるだけのお客さんが来てくれるかが問題なんです。私はその踏ん切りがつかないのです”ということだそうだ。

これって、受託開発に当てはまると思いませんか。若干こじつけ風ですが、受託開発も床屋と同じように、いつまでも関係が続くように仕事を残すとか、極端な話、わざと品質を落として、後のメンテでお金をもらうとか、ひとが何でもいいから働いている状態を作るだけみたいになっていないだろうか。また、前に言ったように人を増やすのもいいが、増やしたときは持ち出しとなり、しばらくして、また増やせるくらいになると、また思い切って増やすが、そのときは赤字ということの繰り返しになってやしないだろうか。

ぼくたちも、最初のころはWebサイトの開発請負みたいなことで稼ごうかとも考えたが、人の数に依拠するようなビジネスの限界を感じたのと、根っから自分たちが働かなくても自分たちが作ったものが働いてくれるのを願うというナマケモノ気質を考えたら、受託開発ビジネスは無理だと悟ったのであります。まあ、どうしてもやらなくてはならない時以外は積極的に動かないつもりです。

だからといって、簡単にプロダクト、サービス事業ができるかというと、とんでもなく難しいし、ある程度の時間と資金がいる。何よりも創造力が不可欠であり、そしてそれ以外にも製品化力とかマーケティング力だとか、さまざまな能力が要求される。まあ、それだけ挑戦しがいがあるということで、とりあえずここのところでがんばっていきたいと思う。

社長がついに昨日Shibuya Perl Mongersにデビューしました。Shibuya Perl MongersというのはPerlという言語のユーザのコミュニティで、東京地区得に渋谷周辺の人たちを中心に活動しているのでこうした名前がつけられている。定期的にイベントをやっていて、昨日は「テクニカルトーク#8」というプログラムです。

まあ、日本のPerlのトップ使い手が一同に会すようなところで、有名なシックスアパートの宮川達彦さんもサンフランシスコから来て“Guest Talks”でしゃべっていた。うちの社長は、一番最後で“Lightning Talks”で5分間だったけど「リビドー駆動開発によるPlaggerとCatalystを使った（Mashup）サイト開発」というタイトルでプレゼンをしていた。

ぼくがそこにいたかのように言っているが、実はこの模様はUstream.tvで中継してくれていたので、家でそれを見ていたのだ。回線スピードの関係でちょっと音声が聞き取りにくかったが、居ながらにして会場の雰囲気がわかるのだからすごいものだ。

ただし、ぼくには皆さんが言っていることが全くといっていいほどわからない。外国人のひとも英語で発表していたが、英語を理解するよりも難しい。

Geekの世界はこういうものなのかもしれないが、ITは幅が広すぎる。ビジネスからプログラムまで、これらをトータルで最適化するのは非常に難しいと思うが、よくわからないのだけれど、どこか本質的なところでつながっているような気がする。

まあ、これでPerlの使い手ともコネクションができたので、いまのビジネスプランで必要となったらコンタクトしてみようかと思っている。

昨日の様子は、社長のブログの「Shibuya.pm tech talk #8 で 「リビドー駆動開発によるPlaggerとCatalystを使ったサイト開発」を発表してきました」に詳しいので、そちらをみてください。

先月、社長の作った「これ☆ほしい」というマッシュアップサイトを「Mash up Award 3
rd」にエントリーしたことを書いた。ひそかにどれかの賞をとれるのではないかと期待していたが、残念ながらひっかからなかった。

今回、最優秀賞（100万円）に輝いたのは「ONGMAP.COM（オンジーマップ）」というGoogleMap上に様々な情報を表示させるもので、元祖マッシュアップというしろもの。受賞の評は次のようになっている。

マッシュアップの定番といえば「地図に情報をプロット」。この作品は、そんなマッシュアップの王道を、パラノイアックなほどに突き詰めた作品でした。国内 外のAPI、新聞社が提供するRSS、公的機関が提供するデータ、KMLファイルなど、様々な情報を地図・位置情報という切り口で統合しており、それら を、Extを活用した使いやすいUIで提示しています。この作品は、2007年現在の日本における地図系マッシュアップサービスの完成形のひとつでしょう。作者の熱意と愛を感じることができる作品でした。

マッシュアップサイトを作るときの攻め方は二つのアプローチがあると思う。ひとつは、公開されたAPIがあるのでそれを使ってサイトを作ろうというアプローチである。シーズ発想とでも言ったらいいかもしれない。もう一方は、こんな楽しいサイトを作りたいのでそのためのAPIを捜してくるという、ニーズ発想である。

「ONGMAP.COM（オンジーマップ）」は、両方の要素を持ったものではないだろうか。まずは、スポンサーから提供されたAPIをどんどん使おうという発想とGoogleMapの利用の仕方の逆の使い方をしたいという発想がうまくかみ合った例ではないだろうか。だから最優秀賞と成ったのではないかと思っている。

ところで、うちの社長のマッシュアップサイトは、負け惜しみで言うわけではないが、社長も言っているのだが、ニーズ発想、すなわちこんなものがあったらいいな、こんなことができたら楽しいなというところから考えているので、スポンサーのAPIをほとんど使っていない。それも評価をしてくれていない一因ではないだろうか。

もともと、このコンテストに合わせて作ったというより、面白いのができたので応募しようという感じだった。「はてなブックマークされた数」でいけば、「ONGMAP.COM（オンジーマップ）」の56ユーザにくらべて、はるかに多い221ユーザだったのだから。

まあ、受賞できなかったのは残念だったが、Mashupediaの「マッシュアッパーを追う！」という企画で、社長のインタビュー記事が出た。先週、Mashupediaの人がわざわざ鎌倉まで来てくれてインタビューと写真撮影をして帰って行った。ぼくは、関係ないので挨拶だけして、奥に引っ込んでいて、ぼくの事務所でインタビューを受けていた。

こうしてみると、マッシュアップサイトをけっこう数多く作っていたのに改めて驚かされた。これが、ビジネスになるのかというとアフィリエイトだから、そう簡単にお金が入ってくるというわけにはいかない。だから、なかば趣味みたいに考えて楽しむこととそこでいろいろな技術的なことを確かめる場のように割り切ることなのかもしれない。それとアイディアが枯渇しない限り、数多く送りだすことですね。

最近、ぼくらが使っている「Savvion Business Manager（SBM）」のライセンサーであるSavvion,incの日本における販売代理店が日本プロセスから日商エレクトロニクスに変わるというニュースが発表された。

SBMというのは、ビジネスプロセスのモデリングやシミュレーション、フローエンジン、モニタリングなどの機能を持ったBPMSuiteのことである。

最近のエンタープライズ系のITでは注目の領域で、SOAと絡めてブレークしそうな気配です。

こうしたソフトウエアは、欧米のものが多く、従って日本に販売代理店を置いてそこでビジネスを展開することになる。このときのビジネススタイルは様々で、大きくは、単なるプロダクト売りなのか、ソリューションまでやるのか、その先の運用やサービスみたいなところまでやるのかがある。

これまでは、比較的プロダクト売り、すなわちライセンスを販売し、ロイヤリティとその後の保守料をもらうという商売が多かったように思う。これだと、英語とITがわかる社長とあと数人のスタッフがいればできてしまう。しかし、このような形態だと不安定なビジネスを強いられてしまう。

例えば、ライセンサーの気まぐれでいきなり販売代理店の契約を破棄されたり、技術者がすぐに転職してサポートがおろそかになったりする。現にぼくの経験でも仏製のあるBIツール＊）を使っていたが、そのツールベンダーがそれまできちんと対応してくれてぜんぜん不満がなかった販売代理店をいきなり切ってしまい、すごい迷惑を被ったことがあって、直接フランスに文句を言ったことがある。

おそらく、これからは単なるライセンス商売は立ち行かなくなるのではないかと思う。なぜかというと、いまの趨勢を見るとオープンソースソフトの影響が大きいと思うが、ソフトウエア自体の価格がどんどんと無料化の方向に向かっている。

ということは、今後のビジネスは、ソリューションとかサービスという領域で勝負しなければいけないようになってきている。

そんな中、Savvionの代理店が日商エレクトロニクスに変更したことの意味は、この流れを象徴しているように思える。ついちょっと前にも日商エレの今回の責任者と話をしたが、ぼくが言ったようなことをしっかりと考えていて、自分たちのリソースを生かしたサービスという方向性を語っていた。

ということで、ぼくの今進めている開発方法論についての実行母体として大いに期待しているのである。

＊）実は、このBIツールというのは、ビジネスオブジェクト（BO）という製品でBIではかなり名の知れたものです。そのBOがなんと独SAPに買収されたと7日に発表があった。驚くなかれ、その買収額が約8000億円というからたまげてしまいます。でも、SAPのCEOのカガーマン（この人とは2年前に会ったことがある）が、ソフトウエアライセンス収入を伸ばすと言っているが、上でも述べたようにちょっと方向が違うように思えるのだが。

昨日、日商エレクトロニクス主催のセミナー「～成功事例に学ぶ、ITによる業務革新～　ビジネスソリューションフェア2007」に行ってきました。

前にも書いたように日商エレが「Savvion」というBPMツールの代理店になって、BPMベンダーとしての意気込みを表現する場でもあったようだ。本腰を入れだしたのは最近なので、まだ咀嚼しきれてないところもあったが、数多くの参加者もあり盛況であった。みなさんのBPMについての関心は一段と高いなってきているようだ。

だが、ぼくの感じでは、本当にBPMを理解している人も少ないし、人それぞれにBPMの解釈が違ったり、これぞBPMの事例だというのも少ない。

そうした中で昨日のセミナーで最も注目したのは、（株）岡村製作所の添田 恒広氏の「BPM活用事例、BPMによる業務改善の実践」という講演です。この例は、旅費精算を含む申請業務のワークフローを「Savvion」を使って実現したもので、全社の営業系の社員に適用して作業時間の短縮など大きな業務改善につなげた事例で、非常に参考になるものです。

実は、ぼくは添田さんを知っていて、というより、もう3年か4年前になるが、ぼくが「Savvion」を紹介したのです。以前いた会社に別件で訪ねて来られて、その時のディスカッションでBPMシステムを試行している話をしたのだ。でもこうして苦労されて全社規模で実行されている話を聞いてうれしかった。懇親会で久しぶりに顔を合わせたら覚えていてくれて目で“何とかできましたよ”と言っていました。

今回の（株）岡村製作所の事例は、どちらかというとフローのルールが決まっていて、そのルールにそってプロセスを回すタイプであるが、今後の課題にもあがっていたが、決まりきったプロセスではない営業の仕事などをどうやってシステムに乗せていくのかといったことを検討していく必要がありそうだ。ぼくらが提案している方法がそれには有効であると考えているので、ぜひ一緒にやっていきたいと思っている。

さて、このセミナーで日商エレ以外の人で知っている人は添田さんを含めて４人であったが、それ以外の人たちも紹介してもらった。セミナーのあとの懇親会はこのような新たな出会いがあるのが楽しいのです。

で何人かの人とお話しをしたのだが、面白いことが二つあって、ひとつは、ほとんどの人がフリーランスなのだ。ひとりで会社を作ってやっているような人で、人材紹介とか管理会計のコンサルとかIT会社のセールス指南だとかそんなことを個人ベースでやっている。まあ、ぼくもお仲間なのですが、まだまだ、ビジネスの規模、範囲には足元にも及びません。

もうひとつは、世の中狭いなというお話です。そういう人たちと話していると、だいたいがいろんな会社を渡り歩いているんですね。多いのは、IBMとDEC（今はコンパックに吸収された）です。そんなとき、ぼくが○○さんを知っている、○○さんと一緒に仕事をしたというと、あああいつはオレの部下だったとか、同僚だったとか、共通の知り合いが突如出現する。昨日もそんな話ばかりでびっくりした。

セミナーの懇親会が終わったあと、日商エレのＵさんとＩＴ会社の社長のＫさん（この人とは初対面である）の3人で目黒のＫさん行きつけのワインバーで呑んだのだが、そこでもＵさんとＫさんは元DECで一緒に仕事をしていた関係なのでその頃の話になって、共通の知人に電話をしたりしていた。

ところが、Ｋさんにぼくがよく知っている人がいてその人は元DECだと言ったら、ええあいつはオレの部下だったという答えで驚いてしまった。さっそく、ぼくがその人に電話をして、黙ってＫさんに替わったらびっくりしていた。

そんなことがあって、みんなで世の中って狭いなあと改めて感じ入ったのであります。こうして、つながりのつながりから新たな人脈ができていくのだろう。リアルmixiですね。当然のように、Ｋさんには一緒に協力してもらうことをお願いしたのであります。

ひと言でITといっても幅が広いということは前にも述べた。そうですよね、上流（超上流という人もいる）のビジネスとか業務とかいった領域から、実際に物を作る、プログラミングだとかデバイスだとかいった領域まで、すごく広いし深い。

こうしたIT領域は全部が連続的にあるいはボーダーレスにつながっているわけではない。例えば、簡単なところでは、設計・開発・運用というサイクルを見ても、設計と開発の乖離だとかが当然起こる。

また開発でもエンタープライズ系とパーソナル系でも違う、さらにエンタープライズ系のなかでもビジネス系と組み込み系でも違うというように、様々な切り口で括られている。そして、これらは往々にして携わっている人間も分かれてしまっている。

まるで、リアル世界の縮図をみるようでもある。国ごと、人種ごとに境界を引いているようにIT世界も同様で、しかも鎖国をしているようにも思える。

この独立主義（孤立化）は、おそらくスキルの差に起因しているような気がする。だから、そのスキルを持っている、使えるひとたちで部落を作ることになる。細かい話だと、私はJavaしか使えません、Oracleだけしかわかりません、なんてことにもなる。

ここを何とかしたいのだ。

そこでマルチスキルを持ったバウンダリーエンジニアが必要となるのだ。世にバイリンガルとかマルチタレントとかいう言い方があるが、それだと同じ世界の中で複数のスキルあるいはタレントを持っているイメージだが、そこに異種世界においても高いスキルやタレントを保有し、両方を融合できることが望ましい。

例えば、複数のプログラム言語を操れるのだとバイリンガルですよね。また、金融システムに詳しい人が流通もよく知っているというのはマルチタレント的ですよね。このあたりは、どうも水平的なマルチであるので、それを垂直方向にもマルチにもっていくということです。オールラウンドプレイヤーといった感じかもしれない。

具体的に言うと、ビジネスとＩＴとつなぐ、あるいはデザインと開発を一貫してできる、といったことである。いまこうした境界のところに溝ができていて、そのためにシステム品質が悪かったり、システムが悪構造になり、また開発の効率性が損なわれたりしているように思う。

以前、SIerのこれから進むべき道は「専門化」ということを書いた。こういうと何かひとつのことに専心することのように思われがちだが、そういう人もいてもいいが、専門化するがゆえに境界をしっかりみているエンジニアが必要になってくる。

専門化するということは、境界線を引くということに他ならないわけで、そうなるとどこに線引きをし、どういう関係で周囲と連携するのかが問われる。専門化することとは孤立することではない、まさに、バウンダリーエンジニアの出番なのです。

そこで、親子丼的ビジネスでは、まずぼくとしてはビジネスのところにどうやってITを生かしていくのかを追求し、業務プロセスを広く設計できるスキルをもつことにしている。また、社長は、デザイン思考ができること、そしてそれを実際に動くモノ作りへ落とす技術をもつことができる。Mash up サイト制作なんてまさにそれで最初から最後までひとりで素早く作ってしまう。

さらに二人の間にある溝を埋めていくことになる。スーツとギークの融合だ。これは、ニッチとも違う、システムインテグレーションともちと違う、バウンダリービジネスあるいはフュージョンビジネスといったものかもしれない。今まであまりやれていないところですので、ここが狙いどころだと思いませんか。さあ、どうなるか、とにかくチャレンジだ。
　
　

昨日から、日本BPM協会の「コンポーネント部会」が今までのやり方から変えて再スタートとなった。要するに、全体をなめることから、テーマを絞ってやろうということです。そこで、どういうテーマにするかについて、ぼくから提案を行なった。

提案したテーマは、「ビジネスコンポーネントベースのBPM開発に合った業務プロセス設計ガイドラインの作成」ということ。いわゆる上流の部分の設計をどうやっていくかを検討しましょうということで、これだとBPMSがなんであろうと適用できるので共通テーマとしてはいいのじゃないかと思う。

この上流設計については、オブジェクト指向やDOAあるいは要求工学、要求開発など多くの方法論がある。また、業務のモデリングというアプローチもある。しかしながら、上流から下流の開発、実装までをスムーズに流れるものは少ないように思える。

オブジェクト指向にしても業務設計のところは弱いといわれているし、DOAは逆にプロセスの開発･実装には向いていない。また、トップダウン的なモデリングのアプローチだと、詳細なアクティビティレベルまで落とし込むのが大変だ。

そこで、実際の開発技法を意識して、そこにうまく落としこめるプロセス設計法をみんなで議論しましょうということをお話した。そのためには、コンポーネントベースの開発についての理解が前提となるわけで、昨日はそこの議論が活発に行なわれた。これまで、意外とこのあたりの議論ってなされてない面があって、いろんな意見が出て面白かった。

キーとなる部分は、コンポーネントを何とするかということで、ぼくの進めている「ビジネスコンポーネント指向開発」では、「書類のライフ」という定義をして、そこは不定形、不安定な業務処理を情報共有型のCMSで表現しようとするものである。ここの部分が、皆さんが腑に落ちるかどうかが重要であり、この入り口部分の議論をさらに深めていったほうがいいような気がした。

というわけで、BPM協会で設計ガイドラインの作成を始めていきます。

この会合の前に、B社の取締役のMさんと打ち合わせ。ぼくの方法論を使った事例構築のお願いをする。Mさんはユーザ会社出身なので、業務コンサルで、多くのプロジェクトを手がけたプロです。興味を持っていただいたようで一度社長（この人も有名な技術者）に会ってくれということになり、来月初めに来訪することになった。

また、別の会社、CMSを自分のところで開発した会社で、ここにもアプローチしていて
フロントのCMSの開発部分がやれる可能性がある。

まあ、そんなこんなで、ここにきて徐々にネットワークができつつあるので、早く組織化して進めていきたいと思っている。
　

昨日は忙しい日であった。たまにはそんな日もあってもよい。昼ごろから東京へ出かける。けっこういろんなところを回るので有楽町で自転車を借りることにする。駅前の無印良品の店で貸してくれる。ママチャリだけど三段ギアの自動点灯ランプ付きだ。都内はこれで十分である。

まずは、溜池山王にあるB社を訪問。S社長にぼくの開発技法をプレゼン。デモも見てもらったのでかなり理解が進んだと思う。結局、この技法を使ってサンプル開発をしてもらうことで合意する。さらに新規案件で適用できるようなものを探っていくこともお願いする。

サンプル開発も既に開発し終わったシステムを対象にすることにしたので、従来型の開発との比較ができるという願ってもないプロジェクトになりそうだ。ビジネス的にどうなるかはこれから詰めるにしても事例ができることは今後に弾みがつく。

ミーティングが終わって、予定は日展にいくことにしていたが、午後4時半からのトワイライトチケットで入るつもりだったので、若干時間があったので、近くを自転車で徘徊する。実は前の会社がアメリカ大使館の横にあったのでこのあたりはよく知っているので、どうなったかを見たかったのだ。ところがものすごい変わりようにビックリで、もちろん前の会社があったビルはなくなっているし、よく行っていた食べ物屋なども無くなっている。

そんなことに驚きながら六本木をめざす。途中、東京ミッドタウンを横目に国立新美術館に着く。今年から日展は上野からこちらに移動した。新しい美術館はあの黒川紀章のデザインになる。日展に行った目的は、ぼくらが今ホームページの制作を行なっている日本画家の坂本武典さんがまた入選したので、その絵を観に行きたかったからである。

坂本画伯は以前にも紹介しましたが、若い（確か今年31歳）にもかかわらず日展入選8回目となる。春の日春展を合わせると何と18回の入選となります。すごいでしょ。案内のメールに「今作品は部屋の中で椅子に憩う女性像を描きました。黄色と白を基調に、鳥かごのある部屋をあたたかな空気感と若い女性の凛とした中にも安らかに憩う姿を表現出来ればと描いた作品です」と書いてあったので、その作品を観たかったのです。はたして、作品はそのとおりいつもの青年像を描いた作品とは違う穏やかな雰囲気のいい絵でした。

日展の後は、新橋である人と待ち合わせなので、もう暗くなった六本木通りを引き返す。自転車を返し、新橋のさかなや「いさむ」に少し早いけど一人で待つつもりで行ったら、なんと貸切で入れず。仕方なしに、もうひとつの行きつけの中国家庭料理の店「一味玲玲」に行く。

そこで久しぶりにママに会いたかったのにいないのだ。で店の女の子に聞くと100mほど離れたところに新しい店を出したのでそこに居るとのこと。餃子とビールだけで店を出て新しい店「玲玲」に行く。ところがその店は明日正式開店ということで本来ならお客さんを入れないがということで特別に入れてもらう。

そこで、待ち合わせの人が来るまでの間、その中国人のママとひとしきりおしゃべり。どうして新しい店をだしたのか聞いてみたら、古いほうの店はそれなりに知られるようになったが、若いお客さんが増えて店が騒がしく、落ち着きがなくなってしまい、昔からのお客さんが遠のいてしまったので、そういうお客さんに戻ってもらいたくて作ったという。だから会員制なのだそうだ。

店の内装にしても落ち着いた雰囲気ですごくいい。しかも、昔のようにメニユーがなくて、その日その日に考えついた料理が出てくる。これが、普通の中華料理屋と違って家庭料理なので面白いメニューもあり、これぞ家庭の味という感じでうまいのだ。

そうこうしているうちに今晩呑み相手が登場。まだ２０代後半のY君で大手ITベンダーに勤めている。ぼくの子どもみたいなものだ。なぜこうなったかというと以前のエントリーにも書いたのだが、BPMという切り口でブログを調べていたら行き着いた。彼は「GoTheDistance」というブログを書いていて、その中でBPMに関心を示していた人なのです。でこれまでもBPMのオフ会で顔を合わせていたが、最近ぼくのブログにコメントをいただき、会いたいということになって実現した。

昨日は、呑みながらぼくの技法の説明やデモも見てもらった。まあ、彼もおおかたの理解をしてくれたが、こういうことを自分の会社のなかで挑戦しようと思ってもなかなか難しいことや自分たち既存SIer自身の首を絞めることになるかもしれないことなどを話してくれた。若いけれどもしっかりとした考えをもったひとでいつの日か一緒に仕事をしてみたと思っている。

この日は、社長もある仕事を始めた日でもあった。ある、ホスティングサービスの会社のシステム変更に伴うコード（ちなみに言語はPerlです）のリニューアルみたいなことで、週2～3日程度の仕事です。

ということで、ぼちぼち親子ともどもまだ自転車操業かもしれませんがビジネスが動き出しました。まあ、「玲玲」のママも言っていたが、「お金のために働いちゃだめだよ。自分もお客さんも楽しくなるように働いて、その結果としてお金が入ってくるのが一番です」ということだと思う。

新装なった「日展」の会場です。

　

昨日は、横浜のO社を訪問。以前このブログでも採り上げたことがあるが、SAVVIONのユーザで申請業務のシステム化を行い、その事例の報告をした会社です。昨日は旧知の課長さんにもお会いでき、当方で開発した方法論を見てもらった。

というのも、そのセミナーで申請業務のような決まりきったプロセスはBPMシステムに乗せやすいが、例えば営業系で受注するまでの業務など、不定形で不安定なプロセスをどうするのかが課題であるというようなお話をされていたので、日商エレの方々と一緒に訪問したのである。

最初に、どんなことで困っているのかという話を聞いたが、要するに最近の営業の仕事と言うのは守備範囲が広くなってきていて、商品のライフサイクル全体に関わる必要が出てきているとのこと。すなわち、ただ商品やサービスを売るだけではなく、たとえば廃棄まで考えるとか、仕事のスタイルまで設計して提案しなくてはいけないとか、多様な営業形態に対応しなくてはいけなくなっている。

さらに、営業マン自体も最近の若い人のなかには、昔のひとのようにWBSを書いてそれに従って、スケジュール管理をしてといったことができなくってきていて、マネージメントをどうするかといった問題点も指摘されていた。

こうした、課題に対して答えられるツールやソフトウエアがないので、いろんなソフトウエアの使える部分を持ってきて組み合わせるのかなあというようなことを話されていた。ただ、このあたりの仕事のやりかたは、案件ごとに違ったり、顧客によりその接点が違ったりと、なかなか標準的なやり方にならないため、システム化は難しいのではないかとも話されていた。

そこで、ぼくがCMS－BPMの仕組みでやれば、かなりそうした課題の解決につながる可能性があるということを説明し、実際に動くものを見せた。サンプルは設備工事案件について、仕様書作成、見積依頼書作成から購買部門が業者に見積を出すまでのプロセスであったが、すんなりと理解していただいた。

やはり、実際に動くものを見てもらうのは相手の理解が早いということと、それ以上に自分たちのやりたいこととの対比でイメージを膨らませることができるので非常に有効である。で、みてもらった結果、面白そうだということになり、こちらのほうで要件をまとめて提案書みたなものを作ることにした。

その打合せのあと、日商エレの人と今後の進め方について話し合う。来週からサンプル開発も含めたプロジェクト計画についてのアドバイスをすることになった。いよいよ、ビジネスとして動き出した。
　

一昨日は、日本BPM協会主催の「BPM-J交流会」に出かける。これはこのカテゴリーの最初にエントリーしたように、前回は、ぼくが「ユーザ目線の実践的BPM」というタイトルで発表した集まりです。

今回はウルシステムの吉川昌澄さんの「BPMSのスウィートスポット　～導入成功事例に見る4つの狙いと7つの業務～」と日本能率協会コンサルティングの田中 良憲さんによる「顧客サービスプロセス改革の実践ポイント　～金融・通信サービス業における改革事例に学ぶ～」であった。

最初の吉川さんの発表では、日米のBPM導入成功例４１社（対象はSAVVION社のSBMを導入した会社）を分析し、それがどのような目的に、どこの業務領域に適用されているかをわかりやすく整理していた。

また、田中さんのものは、これも通信業、リース業、保険業の事例にもとづき、BPMを推進するための改善サイクルのレベルを３つにわけ、それぞれの取り組みを紹介してくれた。

いずれも、事例から導かれた報告なので説得力があり、非常に参考になった。こうしてみると、BPMの適用可能性というのは広く大きくなってきているのがわかる。まだ日本では成功事例が少ないが、徐々に増えてくるものと思われる。

ぼくらのやっていることも、もうちょっとしたらプロジェクトを回して、実績があがってくる予定なので、早くいい結果を出し発表していきたいと思っている。

昨日は、その「BPM-J交流会」で講師をつとめたウルシステムの吉川さんを訪ねる。こちらの仕組みのデモをみてもらって、協力を要請する。いろいろお話していく中で、吉川さんがBPMに取り組まれたのが2000年頃だと聞いて、さすが年季の入っている人は違うなと感じたのである。

最近、BPMとかSOAとかSaaSとか言われだしていますが、昔から追っかけたものにとっては、多くはにわかアナリスト、にわかコンサルタントで、はやりものに飛びついているだけと思ってしまう。

だから、どこかの受け売りみたいで本当にわかっているのかと言いたくなる。結局、自分たちが何をやりたいのか、どういう仕組みにしたいのかがあって、それを必死に自分の頭で考えて、そこでたどりついたのがBPMだったりSOAであるという、そういう人こそが本当のところがわかっていると思う。

夜は、BPM協会のコンポーネント研究会の定例会に出席。Tibcoのオープン化の話を聞く。BPMベンダーにもWeb2.0採用やオープン化の波が押し寄せているようだ。BEAも先日「Dynamic Business Application」というコンセプトを打ち出してきているし、そこらあたりがやかましくなってきそうだ。

ただ、この会合でも議論になったが、オープン化はいいんだけど、収益モデルをどうするかが問題だねという話で、ユーザインターフェースはオープンソースでいって、BPMのところはしっかりライセンス料をとりますねというモデルが成立するかどうか難しいのではないだろうか。ぼくらのビジネスもここらあたりは議論になるが、悩ましい話だ。
　

ビジネスというと商材をどうするかになるが、今の段階ではまずはその商材を揃えていくというところに注力しなくてはいけない。パッケージやソフトウエアのライセンス売りにするのか、それを使ったソリューションとするのか、さらに保守・運用までてがけるのかといった選択がある。

われわれの考えは、単なるプロダクト売りではなくサービスを売ろうと考えています。特に、ビジネスプロセスがメインとなると、その会社全体のビジネスをどんな構造にし、どのように運営していくかといったところまで踏み込まないと、本当にお客さんが喜んでもらえるかわからないことになる。

使ってもらえないものを売って儲けようとは思わない。ですから当然のようにソリューションからさらにビジネスアウトソーシングのようなことまで視野に入れて考えています。

ということになると、商材としては、開発技法、アプリケーションプラットフォーム、ビジネスコンポーネントやプロセステンプレートのライブラリー、運用サービスといったところになるのはないでしょうか。

さしあたってやらなくてはならないのが、事例の構築です。商品を売るにはプロモーションビデオがあったほうがいいのと一緒でサンプルプロセスに対して動くものが必要です。そういったものをひとりではできないのでコンソーシアム的にやって行こうと考えていますが、こうしたやり方の場合問題になるのが成果物の権利の帰属をどうするかです。

従来の考え方でいくと、権利化してそれを寄与度に応じて配分するようなことになるが、前回も指摘したようにオープンソース化という流れが加速されている中では、それに逆行していくような気がする。

その前に、権利化ということに関しても、以前はビジネスモデル特許とかがもてはやされた時もあったが。今はあまり聞かない。おそらく、特許をとるのに時間がものすごくかかるから、そんなことをしているよりどんどんビジネスを始めたほうが得策なのではないでしょうか。しかも、最近のWebの世界は著作権にしてもいいものは万人に開放すべきだという考え方になってきているように思える。

そして、ソフトウエアの無料化の動きである。

だから、これから始めるプロジェクトをオープンソース精神でやるという手もあるが、まだビジネスシステムの世界では早いように思える。そこの世界にいる人たちのマインドがそこまで行っていないと思う。従って、ぼくの提案しているのは、「限定的なオープンソース開発」ということになる。

どういうことかというと、思いや考え方を同じくする人たちを限定し、しかしその中ではオープンソースで行くというやり方である。現実解としてはそんなところではないでしょうか。でもなお、収益モデルの描き方は課題として残る。悩ましいところだ。
　

前回、プロモーションビデオのようなサンプルシステムが必要であると書いたが、その開発プロジェクトが動き出すことになった。

昨日、一緒に仲間になってくれそうな会社を訪問した。タイムインターメディアという名の会社で、主な商品としては、検索ソリューションの「Kabayaki」、CMSの「幕の内」、イシュートラッキングシステム「グルット」などである。この三製品についてデモを見せてもらった。逆にこちらからもいつものデモを見てもらう。そのあと、コラボレーションが可能かどうか話をした結果、おもしろそうであるとなって、プロジェクトに参画してもらうことになった。

ここで、世の中せまいなあという話です。いまぼくらが扱っているCMSは、オープンソースの「Plone」というやつであるが、これはPythonという言語で書かれたZopeというフレームワークで動くものである。この「幕の内」というCMSも同じようにZopeのフレームワークを使っている。だからこの会社にアプローチしたというわけではない。

最初は、日商エレの人がタイムインターメディアの社長を知っていて、ぼくにこういう会社があるんだけどどうだろうと紹介してくれたのだ。そうしたら、ZopeやPythonを扱っていたのでぜひ一緒にやらせてと言ったというわけだ。

というのは、デモシステムの開発のとき、Ploneのカスタマイズやコネクターの製造などで、わからないことが出たときの対応で苦労したからである。デモシステムはうちの社長がPloneのコミュに聞いたりしながら何とかやった。

でそのときこの周辺の開発者を当たっていると、だいたい主導している人がわかってきて、その人たちを巻き込もうと考えて、幾人かの候補を検討した。そこでS氏という個人にお願いしたのだが、彼は忙しすぎて3回ぐらい会って立ち消えとなってしまった。そんな折にタイムインターメディアに行ったわけで、そうしたら出てきた人が何とSさんというぼくが候補としてあげていたひとたちの中の一人だったのだ。

ということでレベルの高い技術者も確保できたのでプロジェクトが思ったように編成できそうだ。そのプロジェクトは今のところ、プロセス設計のところがBizMo、BPMが日商エレクトロにクス、CMSがタイムインターメディア、全体統括がwaditという体制で、来月からあるプロセスを対象に実際に新しい開発技法でやってみることになります。

そうそう、サンプル開発のプロジェクトと開発方法論に名前をつけました。プロジェクト名は、「NewBiT」です。これは参画各社の頭文字である、Ne（日商エレ）、ｗ（wadit）、Bi（BizMo）、T（TimeInterMedia）からとっています。また、メソドロジーの名は、「BPM＋Web2.0」で略称は「BW2」です。2月にセミナーを予定しているので、何とかそこに間に合うようにがんばろうと思っています。

タイムインターメディアの後は、日商エレに戻って今後の進め方の確認。いくつかのポテンシャルユーザに対する提案書や「BW2」のビジネスプランを作成することになった。どんどん具体的になっていくので楽しくなる。

それが終わって、東銀座の「越洲」で前にいた情報子会社の社長で今は相談役になったKさんと久しぶりの会食。ここは相変わらず酒も肴もうまい。

夜中遅く帰ると社長がまだ起きていて報告がてら話をしていたら、28日、29日に「SaaS World 2007」が六本木のミッドタウンで開かれるが、リクルートのMashupAwardのブースで、Mashupperたちのライトニングトークがあり、そこでしゃべるとのこと。

SaaSというと、エンタープライズ系のことと思っていたら、こんなこともプログラムに入ってきていて驚いてしまう。やはり、ビジネスサイドでもネット系に関心が出てきたということなのだろうか。ぼくらのやっていることも広義のMashupだから、早く世の中に送り出したいと思うのである。
　

いよいよサンプル開発プロジェクトがスタートです。いろいろ考えた結果、このプロジェクトのコードネームも手法の名前も前に言ったのとちがうものに変えた。プロジェクトのコードネームが「Kailas」で、手法というかBPMフレームワークになるが、「BPM+Web2.0」（略称：BPweb2.0）です。

「Kailas」というのは、カイラスと呼びますがチベットにある山の名前からとっています。正しくは、Kailashといいますが、呼びやすくｈをとりました。チベット仏教やヒンズー教などの聖地といわれ、まだだれも登ったことのない未踏の山です。だれもやったことのない新しい手法であることの気持ちを込めています。登った時の見晴らしは素晴らしいものであると確信しています。「BPweb2.0」は最初のBW2から直接的でわかりやすい方がいいと思って変えています。

きのうは、そのプロジェクトの第１回目のミーティングを行ないました。4社からメンバーに集まってもらい、プロジェクトの主旨や概要について、ぼくの方から説明し、会社紹介、自己紹介を行ないました。

そのあと、ターゲットにしている「店舗修理受付プロセス」について、実際にいま従来型の開発方法で行なっている会社から説明を受けました。そのとき、このプロセスは、店舗修理だけにとどまらず、いわゆるカスタマーサービスの領域のひとつであるので、汎用性が高いプロセスです。ですから、いいものができたら水平展開できる可能性が大きいのでおもしろいことになりそうだ。

それと、従来型のものと比較していくとき、こういう業務プロセスというのは、ただプロセスを作ったらおしまいではなく、そのあとのプロセスコントロールとモニタリングがどうしても要るよねという議論になって、従来型でそこまで仕組みを作るのかという話になる。やはり、ビジネスプロセスのライフサイクルをマネージすることが要求されると、BPMSのようなツールが必ず必要になる。そんな議論もあった。

プロジェクトはこのあと業務フローを描いていくわけだが、それをどうやって描いていくのかが議論になる。業務フローさえ描けてしまえばあとのBPMSはそんな難しいことはない。要するに、“美しいプロセス“をどういうふうにして、誰が描いてもだいたい同じようなものになるかが最大のポイントである。

いま、従来型で開発しているといった会社では、詳細な業務フロー図を市販のツールを使って、ある記法に従って描いているのだが、描く人によって描き方がバラバラで困っているというようなことを話された。

さあ、来週の第2回の定例会でそのあたりの議論をしていきます。

この会議の後、日商エレのUさんと米国SAVVION社に今年の3月までの6年間在籍したというKさんと近くの「つきじ天辰」で会食。

Kさんは35歳と若いのだが、いま外資系の会社でデータベース管理ソリューションのコンサルをしている。何回か書いたと思うが、プロセスをやっているとデータを忘れたりする。だから、プロセスだけではなくデータも見てバランスを取らないといびつなシステム構造になってしまう。そこが大事なみたいな議論をして、今ぼくらがやっている「Bpweb2.0」のことも話したら、以前米国SAVVIONでも同じような議論をしていたというようなことなので、すぐに理解をしてくれた。これから何か一緒にやろうねということで握手。

ここはてんぷらもてんぷらもうまかったが、さしみもいける。てなわけで最後のかき揚げ丼まで食べて呑んで大満足。その帰りに久しぶりに銀座の「M」に寄る。いつもの楽しいおしゃべりをして帰るときに、マスターからビジネス開始記念にワインを一本いただく。マスターはいつも何かいいことがあるとワインのプレゼントしてくれる。ありがたいことだ。
　

ＢＰＷｅｂ2.0のサンプル開発プロジェクト（Kailas）は、これから業務プロセス設計の技法とCMSのカスタマイズに入っていく。業務プロセスの設計技法は大体できているのだが、それを知らない人が設計をしてBPMのモデラーで書いたらどうなるかを見てみることになる。

ちょっと意地悪かもしれないが、何もルールや作法がない中でプロセスを書くとどうなるかは結構重要なことである。逆に言うと、ルールや作法の有効性が見えてくるはずだ。世にプロセスフローを書くツールや記法は多くあるが、ほとんどがお絵かきツールであり、書く人によってできあがりのフローが違ってきてしまうということと、実装を全く意識していない。

これでは書いたはいいが、いったい何が正解で、さあそれからどうしようとなる。ですから、重要なことは実装をイメージした、というよりすぐに実装ができるようなプロセス設計が求められるのである。そうすれば、ユーザにもすぐに理解してもらえるし、できあがりのイメージが湧いてくる。

昨日は、SAVVIONのインストラクターをやっている女性にモデリングをお願いしたのと、CMSのカスタマイズのお願いをタイムインターメディアのSさんにしてきた。

モデリングは、どんな人がやってもある程度同じようなものができるかということと、実装につながるものになるかという課題を解決することができるかがポイントである。

一方、CMSの方は、「Plone」を使うか、タイムインターメディアの製品である「幕の内」を使うかの議論になったが、「Plone 」をカスタマイズすることに決定。Plone は何でもできるCMSであるが、何かするにはそれなりの技術がいるというものである。それに対して「幕の内」は、用途を外部発信サイトに絞って、ユーザでも比較的構築しやすいようにカスタマイズしたものである。

従って、このトレードオフの関係をどうアジャストするかになるが、今回のアプローチとしては、広いところからだんだん絞っていくことを選択したので「Plone」となった。

やはり、問題はBPMとCMSの連携のところでどういう方法でやるかがこれからの議論になる。いつの時代にもシステム間の連携をどうするかが重大な問題となる。データ連携なり、アプリケーション連携なり、ここのところをどうするかをずっと悩んでいる。そのために、MQだとかEAIとかSOA、MashUpなどが登場してきている。

ここって、わかっている人が少なくて、単一アプリを作る人はいっぱいいるが連携となるとなかなかわからないというのが現状である。というわけで、今回もまたBPM側のAPIのところが焦点になるというか、そこをよく調査してということになった。（オープンじゃないことも起因）。

さて、僕は自慢じゃないけどまともなコーディングをしたことがない（実は30年前に回帰分析のプログラムをN-88Basicで書いたことはある）ので、CMSの話ができるかなあと危惧していたが、実現したい機能やこんな技術はどうかといったことを話していくとこれが通じるのだ。技術論議は共通の目的、あるいはひとつのゴールといったほうがいいのかもしれないが、そういうものがあるので、比較的話せるものなのだ。

ところが、これがビジネスのことになると、必ずしも答えはひとつではないし、どうしても思惑だとか、計略だとかが入り込んでくる。だから、問題はこれからのビジネスの話でちょいと頭をひねらないといけないなと思っているのである。
　

昨日は、午後一番からBPWeb2.0のサンプル開発プロジェクトの第2回定例会。議題は業務プロセスフローの描き方の検討と簡易プロジェクト管理ツール「グルット」の説明を行なった。プロセスフロー図の描き方でについては、再三言っているようにBPMでは、フロー図さえ描ければぜんぜん難しくない。ですから、いかに“きれいな”フローを描けるかが非常に重要なポイントとなる。

昨日はまず、既に描いてあるBPMNの記法に則ったフローをベースに議論。論点は、業務フローの描き方のルール、作法をどうするかということと、描いたフローをユーザが見て自分たちの業務がわかるかどうか、そしてできたフロー図から実装の姿が見えてくるのかということであった。

どうも今のBPMの論議でBPMNで描けとか言われるが、確かに記法を統一することは意味があるかもしれないが、ぼくはそんなに重要ではないと思っている。単なるお絵かきになっていて、先に言った論点でいえば、描く人によってまちまちなものになるし、ユーザが見てもよくわからないし、さてそこからどう実装するのだということになる。だから、もっとわかりやすくすぐに実装ができ、ユーザに見てもらえるものが真のBPMであると考えている。

具体的にはどうするかはだいたいできているけど、もう少し議論をして最終化して行こうと思う。

さて、「グルット」ですが。これはIssueTrackingSystemとなっているが、簡易的なプロジェクト管理とかToDo管理あるいはタスク管理のようなツールで、EXCELライクの使いやすいソフトです。いま、これを顧客接点である依頼受付業務に適用しようと考えている。

BPMのプロセスの起点となるコンポーネントである。プロセスは当たり前ですが、始点があって終点があって成り立つわけで、この始点となるアクティビティは何なのだろうか。

そのひとつとして依頼受付というのがある。コールセンター業務といったらわかりやすいかもしれない。そこで受付けがなされると内部的な処理プロセスが動きだすのである。内部的なプロセスはBPMになる。昨日の説明やデモで一応の理解をしたが、使えそうな目処がたったので組み入れることになった。

定例会のあとは、BPMのオフ会忘年会です。このBPMオフ会というのは、BPMに関心がある人たちをネットで集めて意見交換や勉強をしようというもので、今年の5月に立ち上がった。まだ、一回しかオフ会をやっていませんが、夜の呑み会は3回目になります。ぼくは、全部出席しています。

ところが昨日のオフ会の開始時間がなんと夜の8時からだ