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時からだという。ううー時間をどこでつぶそう。で思いついたのが、一緒にオフ会に参加するOさんにオフ会の前に一杯ひっかけて行こうと言ったら付き合ってくれることになり、銀座のMで軽く呑んでいく。

参加者は9名で韓国家庭料理を食べながらワイワイガヤガヤ。今回は9名のうちぼくとSさんの二人が60歳くらいで残りの人が20代後半といったところ。ですから、親子ほどの年齢差がある。こんなオフ会も珍しいのじゃないのかな。でもSさんなんて、昨日は盛んに「Facebook」にはまったとか言って、こりゃ若いやつより進んでいる。こうして息子みたいな若者と酒を呑むのも楽しいものだ。

ということでBPMにどっぷり浸った一日であった。ああおかげでACミランと浦和レッズの試合をライブで観られなかった。
　

システム開発という場合、対象を何にするかで開発の様相がだいぶ違うように思う。ところが、世の中の議論はそこのところを一緒くたにしている。

この場合の対象というのは、片やプロダクト開発というか、ソフトウエア開発のことである。もう一方は、アプリケーション開発で特に業務アプリケーション開発のことである。この二つは、同じ開発といってもずいぶんと違うのである。もっと言えば。業務アプリケーションの場合に、開発という言葉が適当ではないのではないかと思う。

わかりやすい例え話で言うと、家を建てる場合、建築材料や工法は開発するというが、家を開発するとは言わないで建築するとか構築するとかと言う。システム開発の場合の業務アプリケーションは家に相当するから、業務アプリケーション開発と言わず、業務アプリケーション構築と言うべきなのである。

そもそも、このあたりの考え方が一般化されていないので、つい業務アプリケーションは開発するものだと思ってプログラミングし出すのである。

家の例え話をもう少し言うと、家にも建売と新規建築もあり、戸建と集合住宅もありという風にその用途や生活力でいろいろなタイプのものが作られる。ただ、それでもほとんどは真さらな状態からではなく、部材や資材の組合せで作られる。ユニット工法とかモジュール工法である。

ですから、オブジェクト指向開発だとか構造化技法だとか、よくわからない要求開発だとかが、ソフトウエアの開発には有効かもしれませんが、いかに業務アプリケーションの構築には無力なのかがわかるのではないでしょうか。

システム開発も建物の建築のようにできないものだろうか。そのためには、開発という概念を捨て去ることなのだ。部材や資材に相当するプロダクト、ソフトウエアを開発するのは当然必要であり、またそれを組み立てる工法も開発すべきものであるが、あとはそれらを使って組み上げるだけにすべきなのだ。

いま試行している「BPWeb2.0」のフレームワークというのは、まさにＳＩの世界を建築の世界並みにしようという考え方なのである。ＳＩすなわちシステムインテグレターというのは、本来そういう姿のものではなかったのか。システムインテグレーションがプログラミングしていたら何がインテグレーションだと揶揄されてしまう。

「BPWeb2.0」には、建築工法にあたる構築技法と部材･資材に相当するプラットフォーム、それと大工さんの養成である教育･研修といったプログラムが詰まっている。このフレームワークでシステム構築を行なえば、コードレスで、すでに出来上がったコンポーネントを組み合わせるだけで業務アプリケーションが構築できるのである。

この方法論は、低コスト化や短納期といったメリットがあるが、もっと大きな効果は来るべき「工事進行基準」という会計基準の変更への対応ではないかと思っている。このことについてはまた後で書く。
　

昨日、プロダクト開発とアプリケーション開発の違いについて書いたが、もう少し補足したほうがよいので続編を書く。というのも、「経団連、高度ICT人材の育成を政府が後押しする「ナショナルセンター」構想を発表」という記事がITProに出ていたからである。

あまり関係ないと思われるかもしれないが、ふとこの記事を見てここでいったい何を教えるのだろうかと考えてしまったのだ。

一応うたい文句的には、「ナショナルセンターは、政府が中核となり高度ICT人材の育成を支援する永続的な組織である。ICT人材の育成に欠かせない教員の能力開発や教育手法の研究、カリキュラムの策定などを行う」らしい。ここでいうICTとは、Information & Communication Technologyのことで、よくいうITとはちょっと違って、ネットワーク通信による情報・知識の共有が念頭に置かれた表現のようだ。ということは、対象となる技術はどうもプロダクト開発に近いところの技術のことのようだ。

ぼくは、最近強く思うのは、業務システムを作る技術をだれも言ってくれないことが非常にさびしい。しかも前に言ったように簡単にアプリケーション開発なんて言われ、ユーザの要求をコードに書いてあげればいいんだみたいになっていやしないだろうか。

いいですか、コンピュータシステムが登場して、それが業務に適用されてもう何年経つのでしょうか。20年30年いやもっとかもしれませんが、いまだに“開発”するんですか？会社の業務がそんなに変わっているんですか？　おかしいでしょう。

ですから、もはや“開発する“のではなく“構築する”のではないでしょうか。そうです、建設業のことも言いましたが、ビルは開発するのではなく建設するのです。英語で言えば、DevelopmentではなくConstructionです。Developeするのは都市空間とか居住空間なのです。ITで言えば、プラットフォームのことで、それは開発するのです。しかし、業務アプリケーションは構築するのです。

この業務アプリケーション構築技術を確立することと、この技術を教育することが抜け落ちているように思える。インターネットのコンシューマ向けの技術を追求するのもいいけど、むしろこの領域はオープンソース的なlコミュニティにまかせておけばいいのであって、国が介入するところではない。その方がうまく。

それより、ビジネスの世界、会社の業務プロセスのところの技術も非常に大事な領域で、そこで企業の競争力をつけ、日本経済を活性化させることも考えてよね経団連さん。
　

前々回、「工事進行基準」ということを書いたが、この「工事進行基準」というのは、SI（システム・インテグレーション）案件などで、プロジェクトの進捗状況に合わせて売上を“分散計上”するという会計処理のことである。

現行は「完成基準」といってシステム開発が完了し検収書を受け取ってから売上を計上する。この「完成基準」から「工事進行基準」への変更が2009年4月から行われるというのである。この方式は、すでに建設業やプラント・エンジニアリング業の会計処理に採用されている。だから、この変更はソフトウエア業界もたいしたことではないと思いがちであるが、実は大変なインパクトを与えるのではないかと思う。

工事進行基準だと、プロジェクトが始まる前に売上と収益が確定していなくてはいけない。これは今のSIerにとってはかなり難しいことなのです。売上もさることながら、収益もですから、原価がちゃんと見積もられていなくてはいけないのだ。

いまのおおかたの会社のやり方はプロジェクトの始まる前はだいたいのことを決めておいて、終わったあとお客さんとのあうんの呼吸で売上と収益が決まるという非常にあいまいなやりかただ。だから、最初の仕様は厳密なことはしないし、きちんとお客さんの承認ももらわないでやる。

そんなことだから、必ず仕様変更や追加が発生し、これは最初の仕様に入っていたはずだとかいや入っていないだとかやり合うことになり、どっちかが泣くことになる。どちらかというとお客さんのほうが強いからSIerの方が泣くのだが、その泣いた分は下請け、孫請けにしわ寄せがいく。

なぜこういうことになっているのだろう。従来からの染み付いた悪しき慣行や業界体質という問題もあるが、ソフトウエアであるがゆえの問題もある。

どういうことかと言うと、先ほど例をあげた建設業やプラント・エンジニアリング業などでは、出来上がりのイメージがつきやすい。どんな建物やプラントができるかがだいたいあわかるので、完成品や進捗状況がつかみやすいといえる。それに対して、ソフトウエアは見えないのだ。作ってみないと分からないし、今どのあたりまで進捗しているのかもわかりずらい。ここが他の業界と大きく違うところである。

そうなるとみな口をそろえて言うのは、「顧客との厳格な契約と正確な原価見積もり，精緻なプロジェクト管理などが必要だ」となる。それができりゃ苦労しないよという声も聞こえてきそうだ。そうなんですね、今のやりかたで管理強化すればいいやとう話ではないような気がする。もっと抜本的な改革をめざし、システム開発やプロジェクト管理のやりかたをゼロベースで考え直すことが必要なのである。

すなわち、顧客の要求と仕上がりのマッチングを事前にイメージできる“もの”を持たないといけない。そのためにはコードを書いてはダメだし、変更が容易にきくようにし、素早く作り上げるということが非常に重要である。これからはそういうフレームワークを用意する必要がある。「BPWeb2.0」はそういうフレームワークなのである。

ともあれ、この「工事進行基準」への変更は、単なる会計処理の基準が変わるというだけではなく、システム開発、プロジェクト管理のやり方が大きく変わっていく、いや変わらざるを得ないようになると思う。いままで「パラダイス鎖国」を謳歌していたわが国SIerの淘汰や変革をもたらすかもしれない。そんな予感もあながちおおげさではないような気がするのである。

昨日は、日本BPM協会のコンポーネント研究部会に出席。年末だったので参加人数が少なかったが、ＪＭＡＣの横川さんから「業務のモデリング」という講義で活発な議論があった。内容は、業務機能設計のフレームワークとか業務分類、粒度といった話題である。ＪＭＡＣで長年実施されたコンサルの経験から導き出された体系なのでそれなりの説得力があり、ぼくがそのとき言ったようにオーソドックスなまとめ方でわかりやすい。

この手法は、いわゆるトップダウンアプローチで、すなわち超上流の事業とはから入っていって、ToBeの業務モデルを設定し、業務プロセスのパターン化を行なうといったやり方である。ところが、このトップダウンアプローチの最大の問題は現実的な詳細モデルに落とし込めない、別な言い方をすると実装イメージがわかないことである。

さあ業務をこういうふうに分類しました、こういうプロセスにすべきですねと言ったところで、現実の業務というのはそんなに簡単に整理できなくて、会社ごと組織ごと担当者ごとに違うという事実を乗り越えられない難しさがある。

ここをどう克服していけるかが大きな課題なのだ。で昨日も言ったのは、業務のモデリングといったトップダウンアプローチはずっと以前からやられてきたことで、いろいろな手法も提示されていて、最近のことではない。ではなぜ、最近BPMが脚光を浴びるようになってきたのかということをよく考える必要があるという発言をした。

ただし、BPMはさまざまな定義がなされていて、中にはトップダウンアプローチのことを言う人もいて、モデリングしてベストプラクティスを作ろうということを指している場合もある。これは従来型の考え方であるので、あえてBPMと言わないほうがいいというのがぼくの意見だ。

しかし、このトップダウンアプローチは上述のような限界があるため、そこを突き破る可能性としてのBPMが登場したと考えてみたらどうだろうか。だから、ボトムアップアプローチとしてのBPMが、従来の課題を解決することが求められているのではないでしょうか。

ただ、どちらか一方だけでいいという話でもなく、お互いで補完しあう形が望ましい姿であろう。すなわち、ボトムアップでプロセスをつくり、そのプロセスの評価や改善をトップダウンで行なうというハイブリッドアプローチがベストだと思う。このあたりは、また「ユーザ目線のBPM」のリニューアル版という形で詳しく論じていくつもりだ。

研究部会が終わったあとは、近くの居酒屋で協会の人2人と昨日初めて参加した28歳の若いエンジニアの4人で今年最後の呑み会。いきなり、その若い子から、みなさんのようにいろいろな経験を積んでこられた方から貴重なお話を聞けて非常にうれしく思いますとかおだてられてしまい、その後はすっかりオヤジたちの独壇場で、基本的には説教はしていないつもり？だが、人生訓じみたことをしっかり言ったような気がする。（途中からは記憶薄い）

帰りはいい気持ちになったので、それを持続するために恵比寿から湘南新宿ラインのグリーン車で帰ろうとしたら、何と満席で、横浜まで立たされた。ああ、酔いも飛んでいってしまった。
　

この年末押し迫った時期ではあるが、やっと＠ITに会議室ができた。タイトルが「ユーザ目線のシステム作り：SOA（BPM＋Web2.0）」ということで、以前から言い続けているシステム開発のフレームワークについて議論していこうというものです。

BPMは今年かなり注目されるようになってきましたが、まだまだ認知度が低く、またBPMとは何かといった議論もあります。そこで、広くBPMに関係していない人たちも巻き込んで進めたいと思っています。おそらく、BPMのことだけではなく、SIer業界のこととかWEｂ2.0とはとかITエンジニアについてとか様々な問題が浮かび上がってくると思います。

＠ITの「BPMプロフェッショナル」の画面ではちょっと探しづらいところがあるので何とかしてくれるよう頼んであります。ただ、＠ITのメインポータルの会議室というカテゴリーにタイトルが出ますので、そこからアクセスしてくれるのではないかと期待しています。

このブログを見ている方もどうか会議に参加して意見をいってください。来年の２月にはセミナーでの講演も決まり、＠ITともども来年にはメディアにアピールできたらよいと思っています。

いよいよ明日から2008年です。それではみなさんよいお年を！

うちの社長（息子）が、ネトランの2007年の最優秀ウェブサービスを選出する「ベスト・オブ・超凄サービス大賞」という企画で、大賞を受賞した。

対象となったのは以前からここにも何回か登場した「ＣＤＴｕｂｅ」です。その他、「これ☆ほしい」というのと「札コラメーカー」もノミネートされていた。

これらはいわゆるMashUpというやつで、「CDTube」は、テレビでやっている「CDTV」のランキング情報とYouTubeのPVを組み合わせたサービスです。

そこの授賞理由と審査員のさとるさんのコメントが印象的だったのでこのブログで取り上げてみた。一部引用する。

一見、単純なマッシュアップと思われがちだが、誰よりも早く実装した点、また見やすいインタフェースと安定した運用で人気コンテンツになった点が、審査員の注目を集めた。

大賞を受賞したCDTubeはアプローチの面白さが際立っていた。テレビのチャンネルを模倣したマッシュアップサイトも多かったが、CDTubeはまるでそれ自体が1つのテレビ番組のようで、ネットに詳しくないユーザーにも分かりやすいテーマと見せ方なのが好感が持てる。これぞまさにマッシュアップ！ という分かりやすさ。大賞にふさわしい作品ではないだろうか。

そうなんですね「わかりやすい」というのが大事なキーワードです。どうしても独りよがり的な凝ったものを作りたくなるが、単純にした方が受けるのだ。まさに「Simple is　beautiful」であります。

それと安定した運用を評価してくれたのはうれしいんじゃないかな。

賞金いや開発支援金というのだそうだが、50万円もえらえるらしく、そうオヤジにも焼肉ごちそうしてよ。
　

きのうは忙しい一日であった。サンプル開発プロジェクトの定例会があって、そのあと日経BPの記者とお願いやら、よもや話などをして、そのあと中小企業向けASPについてコンサルをしている人と提案方法などについて打ち合わせ。

そのとき、すこし驚いたのは中小企業のIT化に対して思い違いをしていたことに気が付いたのだ。それは二つあって、ひとつが、中小企業はブランド志向だということと、もうひとつが若い営業を差し向けることが大事であるということ。

ぼくは、中小企業だから有名なものより無名でも安いものを提供した方がいいんじゃないかと思っていたらそうではないらしい。また、ぼくらのような年寄りが営業に行くと相手は遠慮してしまうのだそうだ。だから、お客さんが叱れるぐらいの若い営業が必要だといっていた。

それが終わったらそのコンサルのKさんと３人で会食。最初築地市場の中にある「魚四季」に行くが満席で入れない。ここは少し前に懇親会で使ったのだが、そりゃ安くて旨くて感激したので行ったのだが、時間もちょうど混むところであきらめざるをえなかった。仕方なしにこの近くの店に入る。

で、そこでのKさんの話のことである。

この人はぼくより歳がちょっと上の人ですが、元々は国産メーカーにいて、そのごDECにいたりして、その間OSに携わってきたのだ。それで、日本のITの黎明期のさまざまなことを裏話も含めて話してくれて非常におもしろかった。

それで思ったのですが、こういう人の話を誰かが残してあげないといけないのではないかと。以前、アシストという会社の社長であるビル・トッテンについて書かれた「起業家　ビル・トッテン　ITビジネス奮闘記」という本があって、それを読むと日本のパッケージビジネスの歴史がよくわかっておもしろかった経験があったので、ほかの分野、OSだとかネットワークとかについても誰かが書き留めてくれないかと思うのである。

今の人は、最初からマイクロソフトがあって、オラクルがいてとか思っているかもしれないが、つい数十年前は誰もがいまの状況を予想できていなかったのだ。そういうことを知っているひとの頭のなかにまだ残っているうちにぜひお願いしたい。

今日は雪がふるという天気予報だったので（いや本当は別の理由があったのだけど）、午後遅くなって東京へでかける。

今の開発方法論というのは機能とプロセスに注目しているのだが、実はそのほかに重要な要素としてデータがある。ぼくは以前、（Data Oriented Approach）という手法を勉強し、実践してきたのでデータということがとても気になっている。今の方法論は、データがきちんと整備されているという前提で成り立つものである。

そこで、以前から付き合いのあるデータの専門会社を訪ねる。この会社はデータの取扱いでは日本でも有数の会社で、かつて一緒に仕事もしたことがある。

そこで今のぼくの技法をひととおり説明し、意見をもらった。けっこう共感してもらったと思っているのだが、検討してもらうことにした。

そのあと、そこの副社長のHさんと営業のKさんと久しぶりに呑むことにする。特にWeb界隈の話が聞きたかったらしく、Web2.0やネットの話で盛り上がった。やはり企業情報システムに携わっている人たちはまだそのあたりの情報は少ないみたいで、こちらで話すことがみな初めてのようだった。

ますます、ネットとエンタープライズの融合をやっていかなくてはいけないという気がした。それと、ITベンダーの危機感が前より強くなってきているように感じられた。その会社は起業して20年経ったということだが、よくここまで来れたなあと感慨深げに語っていたのだけど、これからどこまで生き延びれるかみたいなことも言っていたので、みなさん心配なようですね。

てなことで楽しく過ごしたのだが、なんといっても呑んだところが新日本橋の近くだったのでそのまま横須賀線一本で帰れてらくちんであった。
　

昨日はBPMオフ会にでかけてきました。場所は勝どきのトリトンスクエアで昼からtoitoiさんの「BPM入門」とwkzkさんの「jBPM紹介とデモ」を聞く。途中飛び入りでtomsawadaさんがBPMの変遷とワークフローとBPMの違いみたいなことをしゃべってくれた。

終わったあと近くの居酒屋でもうひとつのBPM（ビールパーティみんなでしましょ）というわけで、呑みながらあれやこれやのお話で盛り上がる。ぼくは、一次会の前半はずっとhabuakihiroさんと会話。今ぼくがやっていることを話したらかなり面白がってくれたのですごくうれしかった。これはどうも次回の勉強会のテーマにするかもしれないとwkzkさんが言っていた。

そのあとは2次会で多くの若い人たちとしゃべって、結構酔っ払って帰途につく。大船駅に着いたら乗ってきた電車が最終電車だとわかってびっくりした。乗り遅れなくてよかった。他の人は4次会ぐらいまで行った人もいたようだ。

今回は驚くことなかれ５７名の参加があった。gothedistanceのブログをみてきた人、java-jaの人たちなどが初参加。早く終わったので、各自自己紹介する時間ができて、一言でもそれぞれのひとのバックグランドがわかって非常によかった。いろんな人がきていましたね。楽しかったです。

でもみんな熱い。若い人も熱いし、数は少ないがオジさんたちも負けずに熱い。仙台から来たHarryさんなんて前回も来てくれたのですが、前回はその日のうちに仙台まで帰らなくてはいけないので呑み会を途中で抜けたのですが、今回は会場の近くに宿をとって万全の構えで臨んでいました。燃（萌？）えてるよねHarryさん。

皆さんほんとにお疲れ様。そして、gothedistance、wkzkさんご苦労様でした。
　

昨日、「オープンスタンダード推進コンソーシアム（略称：OSAC）」の事務局の方とお話をする機会があった。事務局は三井物産戦略研究所がやっていて、ここの所長はあの寺島實郎でOSACの会長でもある。

OSACはオープンスタンダードの技術を使って電子自治体を推進するためのコンソーシアムです。そこが提供しているオープンソースソフトウエアで構成される共通基盤の相互利用を図ろうとしています。これらは無償で提供されています。

ただまだアプリケーションレベルの共有、共用化には至ってなく、データ連携レベルのものではある。標準アプリケーション、というか業務プロセステンプレートのようなものへ発展できるといいと思う。これからの課題ですね。

この団体は6年くらい前にできたのだそうですが、最初はほとんど見向きもされずに途中で存続の危機もあったようで、しかし最近は関心も高くなり多くの自治体が参加しだし、実際に使っているところも出てきたとのこと。

それでもまだまだ自治体のIT化は遅れているらしい。前にこのブログでも紹介した長崎県のことや北海道庁のケースなどは異例だそうだが、それでも徐々にではあるがIT化の機運は高まっている。そうした中での活動はすごくいいことであると感じた。

この活動は今は自治体が対象ですが、そこだけではなく地方の中小企業に対しても有効なアプローチであるから、そういった展開もありだと思った。そんなことを話したら賛同してくれて、何か始めてみたくなってきた。

夜は、昔の会社の部下と関連会社にいて一緒に働いたことがあるヤツと3人で久しぶりに新橋で呑む。その昔の会社のこととか今の仕事のこととかを遅くまで話す。彼らはいま会社の中堅どころであり、家庭的にも子どもが重要な時期だったりで大変だなあと同情してしまう。ぼくもその頃って子どもが小学生で会社でも大きなプロジェクトに入っていて、マンションを買って引っ越したりとかずいぶんと苦労したことを思い出してしまった。

誰でもが通る道ではあるのだが、改めて今の仕事環境、家庭状況の快適さを実感したのであります。
　

いま、ITベンダー3社と一緒になってBPMとWeb2.0的なソフトウエアの組合せでアプリケーションを構築する技法の確立とサンプルシステムの開発を行なっていますが、そのプロジェクトの最初のマイルストーンとしてセミナーでの発表があります。

2月21日に品川で日商エレクトロニクスが主催する「業務プロセス改革･改善実践のためのBPMセミナー」でこのプロジェクトでの成果について僕のほうから報告します。

他にも、この技法で使っているBPMツールである「SAVVION」とフロントエンドツール、これからチームソフトウエアと呼ぶことにしましたが、その「幕の内」「グルット」の紹介もあります。

今年は、BPMがブレークしそうですのでその正しい使い方のようなことを話せたらと思っています。講演時間が30分と短いのでうまく伝わるかどうか心配ですがとりあえず興味を持ってもらえることを願っています。
まだまだ席はありますので、ぜひ申し込んで聞きにきてください。
　

昨日は日系BPの編集委員の方とＩＴ業界のことについて意見交換を行う。われわれと同じようにＩＴ業界に対してかなり悲観的な感じであった。

既成の会社、特にメーカー系はどうにもならなくなっているように見える。そこにいる個人がどうのということではなく、組織として機能不全に陥っているのではないかとさえ思う。そうした会社のトップにしても今のビジネスの早い動きや技術の進展は全く理解の外のように思えてくる。

意欲のある若手がいくらそうした組織の中で挑戦的なことを言ってもつぶされてしまう。リスクを恐れるトップのもとでおもしろいはずがない。象徴的な話として、「今のＩＴ業界で仕事をおもしろがっている人がいるのだろうか？」と言っていた。

産学官というけれどどれもが全く分かっていない。えらい人が集まって何とか審議会をやってもそこから出てくるのは、「教育」「人材育成」だけである。いったい何を教えるのだ。どんな人材を作るのだ。

分かっていない他の例で言うと、ソフトウエアプロダクト（パッケージみたいなものもこれに入るかもしれない）を開発することと業務システムを構築することはぜんぜん違うということ。

みなさん、これを混同するんですね。だからシステム開発にもトヨタ生産方式を持ち込めだとか、いやそれはできないとかの議論になる。ソフトウエアプロダクト開発は、自動車の設計とか開発に近い話で、そこは似ているんですね。余談ですが、これって日本の会社は弱いですよね。グローバルで通用するソフトウエアを日本の企業が生み出していますかねえ。

でトヨタはそのあとにその設計に基づいた部品をベルトコンベアーにのせて組み上げるわけです。じゃそのやり方をお客様の業務システムを作るのに同じようにベルトコンベアにのせて作って提供できるかというとそんなことはできないのだ。なぜって、お客さんに車のようにこれに乗れって言えるかってこと。それはパッケージなわけで、みんな満足したのだろうか？

車のほうが満足度高いですよね。どうして？だってえらそうなことを言ったって車は俺たちの生活の一機能でしかありえないのだ。満足度の高い機能を提供するのはそんなに難しくはない。ＩＴはもっと高尚で広いのだ。生活や業務、言い過ぎかもしれないが経営をも表現しようとしているのです、機能だけではないプロセスやシステム、ひょっとしたらスタイルを提供できるのだ。

そんな世界がつまらないはずはない。

話題のヤフー買収の記事で買収額が富士通、日立、ＮＥＣ三社の時価総額を合わせたくらいの額だという報道があったが、あれは悪い冗談で、まとめて一社でいいということとおまえらのほほんとしているとパクッとされるぞという怖い話でもあると捉えてみたけどちょいと飛躍しすぎと買いかぶり過ぎかな。

ただ、ちょっと前にあったＴＩＳとインテルの合併は、インドのＩＴ会社による買収に対する防止策だったらしいのであながち冗談でもないかもしれない。

今はそういう時代なのだ。だから言うが、日本の特徴、強さは何なのか、さらに言えば、おれたちの“おもしろがれるもの“って何なのか、それを生み出せるのかというところに行きつく。

で明日は絶対にある。朝の来ない夜はない、春の来ない冬はない。(わー、ちょっと陳腐な表現）そして若い人に期待するのだが、ただやみくもに若けりゃいいってもんじゃなくて、そこは経験値との相関（どういうことかというと失敗しろよ、そこで勉強しようぜってこと）で考えることなのだと思う。
　

ちょっとまえにここでも紹介した「こんなに使える経済学」（大竹文雄編　ちくま新書）という本があるが、そのなかに“耐震偽装を再発させない方法”という章があって、そこに書いてあることが非常におもしろかった。

対象としているのはもちろん住宅業界の話ではあるが、IT業界にあてはめてもおかしくない、むしろIT業界のことを言っているように思えたので紹介しながら、SIビジネスの抱える問題を考えてみることにする。

本の内容を少し長くなるが要約して記述する。

2005年11月、マンションの耐震データ偽装事件が発覚し、大きな社会問題となった。まず、事件のポイントを整理しておこう。マンションの売買契約にあたっては、購入者とともに、建築主（デベロッパー）と呼ばれる販売業者が存在する。通常、建築主は直接マンションの生産には携わらず、ゼネコンなどの施工業者に発注し、設計の図面は、専門家である建築士に依頼する。

購入者は契約時点において、これから自分が住むマンションの品質について、極めて限られた情報しか持てない。施工業者は購入者の情報不足につけこみ、材料の質を下げたり、生産工程を簡略化し、生産原価を低く抑えれば、不当に利益を増やすことができる。建築士も、耐震データをはじめ、設計を過度に簡略化し、生産原価の削減に貢献すれば、不当な利益の分配にあずかることができる。

住宅市場では売買交渉当事者間に「情報の非対称性」があるため、情報上有利な立場にある建築主側には十分な品質を保とうという動機が働かない。こうしたインセンティの歪みによって、参加者が効率性を損なうような行動をする状況を「モラルハザード（自己規律の喪失）」と呼ぶ。

これまでも、住宅市場でのモラルハザードは深刻に認識されており、是正のための制度として「建築確認制度」が導入されている。だが、今回の事件では民間の検査機関にもモラルハザードが発生した。

一方、事後対策として、建築主は「瑕疵担保責任」を負う。これは、過失の有無の認定を必要としない「厳格責任原則」に従って問われる。こうした厳しい法運用がなされるならば、建築主は販売後に大きな負担をせまられないように品質向上の努力をし、効率的な資源分配が実現することが知られている。だが実際には企業は不正が発覚した段階で倒産すれば責任を回避でき、厳格責任制度も部分的には機能しなくなり、モラルハザードが発生する余地がある。

ここで、建築主をSIerと置き換えるとそっくりIT業界のことを言っていると思いませんか。ただし、SIには「建築確認制度」のようなものはないのですが。こういう制度を導入したらいいと言っている人もいるが、非常に難しいような気がする。

それと、「瑕疵担保責任」の問題にしても、ソフトウエアの世界で厳密に適用しようとしても無理があるので、あいまいになっているのではないでしょうか。例えば、マイクロソフト製品の不具合でシステムトラブルがおきたら瑕疵をどうやって認めるかとか困りますよね。

要は、ここで言っているようにインセンティブの歪みという問題がポイントなのである。システム開発の現場で問題になるのは、システムの購入者であるユーザができあがるシステムの品質を予見できないため、偽装されても何もわからない。いやシステム開発では基準、規則がないから偽装にもならない。お客さんが喜ぶものを作ろうというインセンティブがなかなか働かないことが問題なのだ。

それに対しては、「情報の非対称性」を是正することなのだが、これがまた難しい。今のような開発のやり方ではお客さんが出来上がり品質をイメージできないのだ。以前から何度も言っているように、作る側と使う側のイメージの共有が課題である。

もうひとつの対策はインセンティブが働くような制度的な対応であろう。この本ではそうしたことに対して欠陥発覚時における損害賠償額を給付される建築主への「賠償責任保険」を提案している。

保険会社がそれぞれの建築主を独自に審査し、物件の質に応じた料率で保険加入させるべきである。こうすると質の悪い物件を販売する建築主は高い保険料率を要求され、保険購入が全くできないグループも出てくるだろう。保険会社については、複数の企業間で競争が働くため、審査努力に関するモラルハザードは抑制されるであろう。 今後必要なのは、安易な規制強化ではなく、保険を含めた市場機能の効果的な活用を図る精度設計である。

この提案をSIビジネスに適用したらどうなるだろうか。まず、欠陥があったときに損害賠償を払うという仕掛けがなじむだろうかという問題がある。やっぱり難しいのかなあ。でもなかなかおもしろいので一考する価値はあると思うがいかがでしょうか。
　
繰り返すが、まずはやらなくてはいけないのは、「情報の非対称性」を是正し、インセンティブの歪みを失くすことである。
　

目黒の雅叙園で開かれていたDevelopers　Summit　2008に行ってきた。行ったといっても仕事の都合などで２日目の最後の2セッションという、ちょっとかじりのセミナであった。

このデブサミは去年に引き続いて2回目の参加であるが、去年は初めてだったせいもありちょっとした感動も味わったのだが、今年はあまり燃えない。というのは、ひとつには、テーマが拡散して絞りきれていない。だから参加者のとまどいもあったのではないだろうか。去年も言ったのだが、スーツとギークの分離みたいなところがある。それをデベロッパーという括りでやってもいいのだろうかということである。そこを融合するものが出てきたのだろうか。両者は歩み寄ったのだろうか。

そういう観点で、参加した２セッションを考えてみた。ひとつは、ケンシステムコンサルティング社長の高橋俊夫さんのXupperを使った業務設計と実装までと、もうひとつは要求開発コンソーシアムの牛尾剛さんと依田智夫さんによるこれまた超上流から実装までで実際の開発のライブをやっていた。

で、特に要求開発の話は期待大。ところがである、やっぱ裏切られたな。ここって重要なのところである。結局超上流（この言葉もよく分からないが）とか言うけど、最後は、開発のレベルに行くんだけどそれがRuby　on　RailesでWebサイトをつくることかって思ってしまう。そんなのフレームワークにもうあるじゃん、新たに開発することじゃないのだ。それよりもなによりもいきなりアプリが登場するわけで途中どうなっているのかまったく分からん。あれで、開発はこうやるとかわかったやつがいたのかなあ。まだまだ、コードを書くことが開発だと思っているように感じる。

一番カチンと来たのは上流はこうした要求開発手法でやって開発はオフショアでなんて言っていることで、安易にオフショアなんて言うなと言いたい。オフショアに持っていかない開発方法を考えるのがおれたちの使命じゃないのか、国内で開発してもインドに勝てることを真剣に考えないといけない。

ちょっと言葉を荒げていますが、ここのところがすごく大事なことで、昨日のデブサミの参加者はほとんどが若いエンジニアだったが、開発者が開発しやすい、腑に落ちる方法論を提示しないとますますビジネスとITの乖離ができてしまうと思うから苦言を呈しているのです。このことについてはまた別の機会に書く。
　

昨日はアレア品川で日商エレクトロニクスが主催する「業務プロセス改革･改善実践のためのBPMセミナー」でプレゼンをしてきました。

タイトルが少し長いのですが「エンドユーザ視点でのコラボレーションBPMへの取り組み　開発技法「BPWeb2.0」とは？」です。これまで作り上げた開発技法の説明といまやっているサンプル開発プロジェクトの事例を中心にしゃべりました。時間が30分と短かったので、かなりのスピードで話したのでみなついて来れたのか心配でしたが、割と好評だったようです。

他のセッションも日商エレのBPM戦略とSAVVIONのデモがあり、ぼくのセッションの後はタイムインターメディアの商品紹介、それが終わったら出光興産とオカラムのSAVVIONを使った事例紹介という具合になかなかいい流れのセミナーでした。だから出席した人もわかりやすかったのではないでしょうか。

やはり事例が迫力あるのですが、2社ともぼくが主張していることとほぼシンクロしていたことがよかった。最後に発表したオカムラの添田さんなんて終わりにぼくの技法を検討していると言ってくれた。懇親会でしっかり御礼を言っておいた。

ここで共通的な考え方として、コードを書かないこととシンプルでわかりやすいことがあげられる。両社とも内製しているわけで、そのときに必要な要件って今言ったことなのだ。逆に言えば、コードを書かなくてすむ、シンプルでわかりやすい技法があればユーザは自分たちで開発したい、またできると思っているのである。

セミナーのあとの懇親会でいろいろな人と話ができたのだが、ある経営コンサルの人と話していたら、ぼくの発表したことが「実に腑に落ちた」と言ってくれたときはうれしかった。おそらくこのセミナーに参加したかななりひとは、BPMってなんなのだろうか、BPMでシステムをつくるにはどうしたらいいのだろうか、といったモヤモヤを抱いていたと思う。そうしたモヤモヤを少しでも吹き飛ばせたのかなあと思っている。

懇親会のあとも、その経営コンサルの人たちと場所を変えて議論をした。いろんなひとの意見を聞くとすごくためになる。こうして少しずつ賛同者を増えてくるのが楽しみだ。
　

昨日、“OSACフレームワーク完成！”というセミナーがあってそれに参加した。OSACというのはオープンスタンダード化支援コンソーシアムといって、三井物産戦略研究所が事務局になっていて、電子自治体の効率的かつ円滑な構築を図るために、情報システムへの標準化（オープンスタンダード）技術の採用を推進する団体である。

簡単に言うとオープンソースのソフトウエアを採用してシステム連携の基盤のフレームワークを作り、自治体で共同利用してもらい、相互連携も可能にするというもの。具体的には、UNIX、Tomcat、Apache、JBoss、MySQLといったものをパッケージにしてある。

ねらいは、特定ベンダーによるロックインの回避やコストダウンである。それらを、フライトシステムコンサルティング、野村総研、電通国際情報サービスが提供している。

ただ、ぼくは標準化というと何となく首をかしげざるを得ない。標準を決めたとたんに新しい技術ができたりする時代であるし、この例でもそうだけど、オープンソースのソフトウエアをバインドしてフレームワークを作ったらそれ自体がオープンソースの枠組みから外れてしまうと思うのだが。ひとつのベンダーにロックインされるのを嫌っておきながらひとつのフレームワークに固定化されるという自己矛盾があるような気がする。

もうちょっとゆるいものでいいはずなのだが、つい標準化という錦の御旗にいいことだと錯覚しているように思える。できればいいが、非常に難しいのであえて言っている。それよりも、アプリケーションレベルの標準化のほうが意味があるような気がする。

例えば、お役所ではバックヤード業務ってどこも同じはずなのだから、同じものでも十分であろう。そういうことを思っていたら、懇親会でセミナーで事例発表していた北九州市の方とお話することができ、そこで出てきたのが、窓口業務とそのあとの業務の性格が違うねということで、そこは作り方も違ってくるよねということであった。

すなわち、窓口では依頼者によって様々な用件があり、決まりきったプロセスでは対応しきれない。そこで決まればあとはルーティンとしてまわせると言っていた。それは、ぼくが言っている３層構造プラットフォームで実現すべきという話をした。

あと、Seaser2のひがやすおさんが動く仕様書ということでプレゼンをしていた。生でひがさんのプレゼンを聞くのは初めてだったので感激。動く仕様書というのは、仕様を紙の上に書くのではなく、すぐその場で動くものを見せてそこでコードを書き直してしまい、そしてホットデプロイができるのですぐに確認できるというもの。これもぼくが言っているFace2Face開発というのと同じで、スピードを求められる昨今、こうした開発方法は必須のような気がする。

ただ、昨日のような場でひがさんのプレゼンは出席していたひとたちは理解できたのだろうか。ちょっと場ちがいのような気がした。

OSAC標準フレームワークの中にｊBPMが入っているが、自治体へのBPM導入はまだまだのように思える。まだ実績もないようだ。ただ、北九州市のひとも話していたようにBPMの出番がくると思われるので少しずつ教宣活動をすることのようだ。
　

OSACのセミナーの後BPMオフ会に行ってきました。夜の8時からだったのでOSACの懇親会が終わってかけつけてちょうどよかった。ただし、すでに若干酔っ払い状態。

今回のオフ会はサイボウズラボのid:n_shuyoさんのFlowrについてである。どうもFlowrを知って面白そうだということでid:yojikさんやid:wkzkさんが取り上げてそこからコミュニケーションができ今回の臨時オフ会になったとのこと。こういう動きもネットコミュならではの面白さですごくいいことだと思う。

昨日は30人弱の参加で、幹事のid:GoTheDistanceさん、wkzkさん、いつものid:habuakihiro、id:makotan、ToiToiさんや久しぶりのmatsuさん、それに結構初めての若い子がいっぱい。

Flowrの話はぼくにとってはかなりむずかしいのでよく理解できなかった。雰囲気としてひょっとしたらBPMのフロントやそこの連携にてきようできるかも知れない気がした。habuakihiroさんにもそんなことを言われた。中味はよくわからなかったので昨日昼飯を食いながらうちの社長にパーマリンクやらRESTfulのことを解説してもらった。

もちろんぼくのお目当てはビールパーティのほうでかなり入れ込んでしゃべってしまった。エロ爺がやたらまくしたててすいませんでした。

4月の第３回オフ会でしゃべることに正式になったようで、そのときのネタをずいぶんとばらしてしまったようで、4月はどういうプレゼンにするかよく考えてみよう。

今回、いろいろな人と話したが、shuyoさんや後から呑み会に参加してくれたTDDで有名なid:t-wadaさんと熱いトークができたので楽しかった。ｔ-wadaさんとは同じワダだし、親子でやっているという共通点があり、気になっていた存在であった。だけど、t-wadaさんがぼくのブログを読んでいてくれて、デブサミのことについて書いた記事の続きを書いてくれと言われてしまい感激した。スイス人でOpenWFEを作ったmettorauxさんとも会話できたしもうミーハー気分。

それにしてもいつものことだが、みんな熱いわ。こんなエロ爺さんに対しても全く若いひと同士のように接してくれるのがなんともうれしいかぎりだ。

今回も幹事のwkzk、ＧoTheDistance両名に感謝！

昨日はITC（ITコーディネータ）協会のトップの方と意見交換をした。協会のHPによれば「ITコーディネータは、経営とITの両面に精通し、企業経営に最適なIT投資を支援・推進することができるプロフェッショナル。」となっている。2001年に設立されて、毎年試験によりITCが誕生していて、もう全国で7000名くらいになっているようだ。

ただ昨日もお話を聞いていて、ほんとうにITCが活躍できているかというと疑問なところがあって、掛け声どおりにはなかなかいっていないようだ。

その理由は何なのだろうか。そのときにもぼくが言ったのだけれど、ITCの方がたが現場で中小企業の経営者とやり合うときの武器を持っていない、いい話し合いの場となるツールがないのだ。特にIT関連ツールで、経営分析をしましたまではいいのだが、では実際にすぐに使えるITを提示できているかというとそれができていない。成熟度診断はツールがあってそれでやれるのだが、そのあとに続かない。

ITというとどうしてもインフラからプログラミングみたいなことまで含めて非常に広範な技術要素を含んでいるのでひとりで全部わかっている人はいないので、何か相談がくると4、5人でチームを組んで行く。そうすると、中小企業のおっちゃんはびっくりしてうちにはそんなお金がないからEXCELでやるからもういいやとなる。

ここのところの考え方を全く変えていかないといけないというようなことを話した。簡単に言えば、ITCのところで情報システムを作るということはやめなければいけない。情報システムを作るのではなく、ビジネスを作るという風にすることが大事なのである。

お客さんのところに行って一緒になってそこの会社のビジネスの実相を可視化して、どうしたらいいのかを考えるということである。そのための道具立てを彼らにしてやることが重要で、だからコードを意識したり、システム機能がどうのこうのといったところから解放してやるのだ。そうすれば、ひとりでも経営者とやりあうこともできる。

昨日はそのためのソリューションということで先日セミナで発表した「BPWeb2.0」の話をした。かなり理解していただいたようで検討してもらうことになった。

ところで、他にもいろいろおもしろい話を聞いた。ITCは地方の中小企業との接点となっているので、そうした中小企業の悩みをもろに受けているところがあって、そこでよくあるのが2代目社長の悩みである。

どういうことかというと、創業者の父親は会社のことは何でも知っているが、IT化されずほとんどが自分の頭の中にあるのでよく見えない。一方、若い従業員も増えてきていいて、その子らは携帯も含めITを使って育っているので、会社でなぜITを使わないのかという不満がでるという。そこをなんとか結びつける、融合させる方法はないかと模索している2代目社長が多いのだと言っていた。

いま世の中はどんどん多様化しているが、そこでは一律の考えややり方で縛れなくなってくるわけで、多様化が進むと孤立化も起きてくる。ですから、多様化すればするほど多様化されたセグメント同士の境界に溝ができないようつなぎとめておくことが大事になる。それはある種のマッシュアップという考え方に近いと思う。以前にも指摘したが、今後、こうした境界領域での融合アーキテクチャの重要性が増していくものと思う。
　

昨日は、日本BPM協会の第6回BPM―J交流会に行ってきました。出席通知をするのを忘れていて、満席締め切りの中、急遽事務局に頼んでねじ込んでもらう。なおかつ、懇親会もむりやり潜入する。昨日の講演はオリンパスの石橋さんの「オリンパス修理サービス改革事例」とNECソフトの貞金さんの「学術情報サービスのプロセス改革事例」。両方とも事例なのですごく参考になる。

オリンパスの石橋さんは実は初対面でしたが、間接的によく知っている人で懇親会では共通項について話が進み盛り上がった。オリンパスの修理サービスの話は以前からよく知っていたが、あらためてうなずくことが多いプレゼンであった。こういう人がBPM協会に入ってきてくれるといいんだが。

石橋さんは、特にERPの導入をベンダーの力を借りずに導入した人で、ユーザ視点の発想がある貴重な存在である。結局言わんとしているところは、ベンダー丸投げはユーザ企業の責任放棄であるという言葉。

すごくよくわかるが、これが非常に難しく、じゃあ責任を持つべき人が誰なんだということ、そしてその人がこうした意識を持ち得るかということが大きな問題なのである。これは責任の所在という問題で、現実的には会社なのか、事業部なのか、もっと小さな単位なのかが重要となる。範囲が大きくなればなるほどITの理解が深まらないから、どうしてもリスクヘッジに走るわけで、そのスコープをどこまでにするかでそのプロジェクトの自立性が左右される。

オリンパスは、昨日話されたプロジェクトは成功したが、逆に失敗したプロジェクトもあるということで、成功要因のひとつにプロジェクト規模ということを強調されていた。具体的には30人くらいまでのプロジェクトに収めるべきだと言っていた。

そこで感じたのは、ビッグバンで全社システムを導入というようなプロジェクトがけっこうあるが、それは大変難しい舵取りが必要で失敗する例も出る。（今朝のニュースでスルガ銀行が基幹システムの開発の遅れでIBMを提訴したと出ていた。）
ですから、そう大きくないスコープで漸次拡げていくアプローチが有効のような気がする。そうなんですね、そういうことを可能にしたのが「BPM on SOA」なのです。
　

息子（社長）の友達にBPM（Business Process management）に興味がある社長がいるので会いたいということになり昨日東京駅の近くのうどん屋で会った。

「フオジンジャパン」という会社のみよしクンとつるクンである。あとから「おもろき」のかまたクンも来たので、社長と同い年26歳の会社経営者のそろい踏みであった。

「フオジンジャパン」という会社は、海外への業務移管やアウトソーシングを検討している企業向けに、各種の支援サービスを提供していて、今は中国の大連を根拠地として主にIT企業の事務処理のオフショア業務処理をやっています。

みよしクンは大学卒業とともに起業していて、つるクンにいたってはまだ大学院の博士課程の学生である。みな慶応大学の卒業生でつるクンが理工学部だが、他の子はSFCである。

前の日にTBSの「情熱大陸」で同じSFC出身の山口絵理子というバッグデザイナーが登場していたが、彼女はうちの社長と同じクラスだったという。みんなすごいなあ。そうぼくらの若いときのように安定した大企業への就職へのこだわりなんか何にもない。そして、日本だけでものを考えていない。輝いています。

BPMの話にいく前にいきなり四日市ばなしで盛り上がる。ぼくが、昔三重県の四日市で働いていたことを話したら、なんとふたりとも四日市に住んでいたというではないか。うちの社長も小学校4年生まで四日市で育ったのでびっくりして、世の中ほんとに狭いなあということに。

そのなかのおもしろい話を。うちの社長が小さいときコンビナートの煙突から煙がもくもくと出ているのを見て、空の雲はこうやってできるものだと思ったと言ったら、つるクンがぼくもそう思っていたということになって大笑いになった。

でBPMの話であるが、業務をオフショアにもっていくとき、まずやらなくてはいけないのは現状業務の洗い出しなのだが、相手が中小企業なので自社の業務プロセスが見えていないことが多いのだそうだ。

だから、プロセスを切り出してどうのという前に現状のプロセスの整理からやらなくてはいけなくなる。そんなことをやってもそれが成約に結びつくかは分からないわけで、効率がよくないというような悩みを言っていた。

そこで、ぼくが今やっているBPMSを使って業務プロセスを設計する方法について紹介をした。ちょうど、PCも持っていたので簡単なデモもしてあげたら、けっこう理解してくれて興味をもってもらえた。

結局、何度も言っていることなんだけど、業務プロセスの可視化とか見える化といっても、現場でそれができる道具がなければ、目の前に魚が泳いでいても釣竿とえさがなければつかまえられないのと一緒で、単なる評論家のたわごとにしかならないのである。

まあ、そんなことを話したのだが、ぼくのおしゃべりを熱心に聞いてくれてうれしかった。これからも協力することを約して分かれたのだが、こうした若い人と話すとなんと刺激的なのだろうか。

少なくとも、ぼくらがよく言ってしまう“まあいいや”とか“しょうがないや”といった言葉は絶対出てこないし、前をしっかり見つめている。この歳になっても、“おれもいっちょやったるか”という気持ちになった楽しい夜であった。

帰りの電車でかまチャンのとった「おせっかいプレー」におもわずわろてしまい帰路についたのであります。
　

昨日、うちの社長がサービスを開始した「ListPod」に関する記事が出た。CNETやITMediaなどに掲載されたのでみてください。

このサービスは簡単に言うと「YouTubeの動画をお気に入り（マイリスト）として登録できて、それがそのままPodcastを吐いてくれて、iTunes や iPod ですぐ見れる」という代物。容易にｉPｏｄで見れるというのが売りのようだ。

動画も携帯して視聴する時代なんですね。このサービスはひとつひとつは目新しいものではないが、その組合せというか、これもMashUpだと思うが、そういうデザインとスタイルを提案しているところがいい。身内ながら素晴らしいと思う。

実はこうした記事が出たのは、いくつかのメディアにプレスリリースを打ったからである。そんなことをあまり考えていなかったのでちょっと驚いたが、個人で出している人もいたりして、おもしろいとすぐに取り上げてくれるんですね。

こういったことで名前を売ってビジネスにつなげるというのは、人が資本のIT会社にとっては重要な販促活動なのである。ぼくもやりたいなあ。
　

ちょっと前にサッカーとBPMという話を書いたが、コメントで敵のことを書いていないというご指摘を受けた。それでそのことについて少し考えてみた。そんなことを論じてどんな意味があるのかということはさておき、分類学、定義力、整理術から考えてみた。

スポーツは明らかに戦いなのだが、その戦い方に違いがある。敵はおのれだなんて精神訓は置いておいて、スポーツは何と戦い、何を競っているのかということになる。

スポーツは明確に相手がいる場合とそうでない場合がある。言ってみれば、“闘う”と“競う”という二つがある。“闘う”というのは相手がいてそいつと戦うことをいう。ボクシング、レスリング、柔道、テニス、卓球、サッカー、バレーボール、バスケットがこういうものにあたる。

一方、競うというのがあって、目の前に敵がいないケースで、相手を倒すことではなく、何かが相手を上回ることで勝利することである。

競うものがいろいろあるが、主に次の３つ、すなわちスピード、距離、正確さと思うのだがいかがでしょうか。陸上、水泳、スキー、スケートなんては早さを競うし、陸上の投てきや跳躍は距離を競うし、体操、ゴルフ、射撃など正確さを競うわけです。より早く、より遠くへより正確にといわけです。重量挙げのように重さというのもあったり、フィギュアスケートやシンクロの華麗さというのもあるけどだいたいが先の３つのくくりでいけるでしょう。

でここでもうひとつの要素が入ってきます。それを、個人でやるのか、チームでやるのかという要素が入ってきます。ここまでが分類学です。

ここで分類ができるわけです。
１・個人で相手がいるケース
２、個人で相手がいないケース
３．団体で相手がいるケース
４．団体で相手がいないケース

この４象限表示はどこのコンサルが考えたか知りませんが、分かりやすいのはまちがいない。それぞれを見ていくと、第一象限は、例えば格闘技系やテニス、卓球の球技ですね。

第２象限は、陸上、水泳、スキー、スケートなどなどいろいろありますよね。

そして、第３象限も球技がこれにあてはまるし、まあむりやり体操や卓球の団体を入れるかどうかだけど本質論から言うと違うのではずしましょう。

さて最後の第４象限は何か？　そういうスポーツってあったけ？これがなかなか思いつかないのだ。無理やりいれるとしたら、ぼくにはエイトボートぐらいしか思いつかない。そりゃあ、ボブスレーとか、二人くらいで競うのはあるがこれは団体ではない。

むむ、ちょっと待ってくれ、じゃビジネスはどこにはいるのかなと考えてみると、この第４象限の戦いなのじゃないかと思うのです。だからビジネはスポーツにはない戦いをしているのだ。

ということは、もっと飛躍して言うと、例えば体育会系のやつをとったほうがいいなんて議論があるが、よーく考えてみると、スポーツ系だからビジネスにつながるというのもちと疑問であると思うのだけどどうだろうか。

何やらこうして改めて分類して定義していくと漠然と思っていたことが違った方向に明らかになることもあるんだなと思ったのである。

だから言いたいことは二つあって、ひとつはこうして分類して定義をしていくと何やら見えてくるものがあることと、ビジネスは多くのスポーツとちがって、団体で相手が見えないところで戦っていることがわかったことである。そうなのだ、実はそこを間違えている可能性がある。
　

よく世代ギャップという。このとき世代が離れれば離れるほどギャップが拡がるように言うがそうだろうか？

もちろん、世代というより個人の考え方や生き方のギャップのほうが大きいと思うが、昨今の団塊世代たたきに代表されるように、世代差がそのまま意識のギャップのような風潮はいかがなものかと思う。意識というのは物事に対する感じ方の問題でそれは世代とは関係ないように思える。

いまの年寄りはITのことがわかっていないと言われても、もしオレたちがキミらと同じくらい若いときにインターネットがあったら、ひょっとしたらオマエらよりすごいことをしたかもしれないんだぜ。だから単純にぜんぜんわかってないだとか、年寄りにはついていけないなんて軽く言うなよなと言いたくなる。

で世代ギャップの話に戻るのだけれど、どうも単に歳の差ではないような気がする。だって、いつの時代でも子供から年寄りまでの年代差を抱えた世代で構成されるわけで、ずっと世代ギャップを抱えて時代を経てたのだろうか？

違いますよね、おそらく時代の変化が激しいとき、言ってみればそんなことを考えている暇がないときは世代ギャップなんてだれも思わないし、そこを生き抜くにはどうしたらいか、その知恵をもっているやつが生き残るみたいなことだったのではないだろうか。

明治維新がそうだったように、大げさに言えばいまの日本はそうかもしれないのだ。だって、「パラダイス鎖国」を破らないと沈没するぜ。だから世代ギャップなんて言っている場合じゃなくてジャパンのプレゼンスをどうするか考えないといけないのではないのかと思う。

世代ギャップってあって当たりまえなのだ。どうしても人間って自分の生きている“とき”を基準に考えるもので、そのときの時代にあるものでしか経験できないわけで、その時々の技術だとか思想だとかに左右される。そういうものなのだ。

で話しを戻して、言いたいことは単なる年齢ではなく、共有した雰囲気とか浴びた時代の風とかの方が影響力があるような気がする。そうなると、親子というのがそうした共有関係にあるのではないかと思うのである。子供が小さいときって同じ音楽、テレビ、映画を見て、一緒に過ごしていたわけで、同じ風を感じていたはずなのだ。

だから、むしろ少し離れた年代の方がずれが大きいように思う。ぼくらは団塊の世代だがその後の年代は新人類と呼ばれ、ぼくらには遠く感じられたものである。

そういう意味で、「親子で起業」はコミュニケーション的にもいいモデルなのかもしれないと思うのである。
　

以前紹介した佐々木俊尚さんの「ウエブ国産力」という本にすごいインタビューが載っている。未来検索ブラジルの役員である竹中直純さんとの一問一答である。思わずすげえなあということと日本の技術者にも希望がもてるという思いが湧いたのですこし長くなるが引用してみる。

佐々木：
グーグルに行ってみようと思ったことはない？
竹中：
新規株式公開（IPO）の前だったら、グーグルは行ってみたら面白い会社だったたんじゃないかと思う。でも今はどうかなあ。もう優秀な人はグーグルにはいかないんじゃないの。だってさ、今さら行ってもつまらないよ。
佐々木：
技術者の理想の会社ではないということ？
竹中：
技術者の理想の会社だというメッセージを伝えているのは偉いと思うけど、それが本当に技術者にとって幸せなことなのかどうか。そういうことに疑問を持ってしまうんだよね。少なくとも僕がグーグルに行ったらつらい気がする。だってみんなでホワイトボードを囲んで、自分のやっていることをアピールするなんてねえ、そんなことやりたくない。合わせられないよ。
中略
佐々木：
最近のグーグルは対マイクロソフトを意識しすぎているように思える。
竹中：
SaaSを推進し、グーグルだけで何でもできるようにするという戦略を遂行しているのは分かるけれど、でもエクセルやパワーポイントの真似をしたソフトを作るのが、技術者として面白いか？グーグルが吸い込んでいる人たちって、みんな生粋の技術者で、世の中を自分の技術で変えたいと思っている人たちだよね。そいう人たちがどうしてグーグルで表計算とかワープロとか作ってるわけ？
おまけに自前じゃなくて、外から買ってきたいしてるしさ。みんな何しているんだよ。
佐々木：
結局のところ、いったい何をやろうとしているのかがわからない。
竹中：
いくらガワをそろえたって、コンテンツがナイトダメだよ。グーグルは入れ物産業をやろうとしているわけ？カネもあって企業的には自由度が高いはずなんだけどね。ただ、エリック・シュミットとか創業者連中がこれから何をしたいと思っているのか、ということが問われている。
佐々木：
それが一番重要な問題。
竹中：
まあわれわれブラジルはお金もないし、実績もないので、まずグーグルが今いる場所に向かうのが目標。でもそうやって考えると、それを達成してしまった彼らは、人生的な岐路に立ってるのかもしれないね。一生ビーチでお酒を飲めるカネはあるとおもうけど（笑）、それじゃつまらないと思うし。
佐々木：
この業界では、一生使い切れないオカネができてしまったら、その後どうするのか？というのが現実的な問題として存在している。
竹中：
あがっちゃったプログラマー問題ね。海外に行って悠々自適で暮らす人もいれば、オカネがあっても仕事を続ける人、あるいは満たされなくて社会貢献に行く人とか。ｄｒも満たされてても満たされなくても、本当のプログラマーだったらプログラムを作り続けるんじゃないかな。そこでプログラミングを止めてトロピカルカクテルに行っちゃうようなヤツは技術者じゃなくて、単なる資本主義の犬だよ。

中略、日本のこの世界でも、世界に通用する人が増えて着ているのは間違いない。それは自然なことだと思う。これからだよ。

これぞGeekという心意気ですね。これがコードで世界を変えようというノリにつながるのだろう。最後に言っているようにこれからどうなっていくのか期待を込めて見守って生きたいと思う。

ただ、ぼくなんか軟弱だから一生ビーチで美女をはべらせながらトロピカルカクテルもいいかなと思うのである。
　

ぼくの元職が化学会社であった関係で今も化学会社の知り合いが多い。昨日はその化学系の会社2社に営業に出かける。

ところが最初に訪問したＳ社では会ったのは前から知っているひとではなく、何とＢＰＭオフ会で会ったひとである。不思議なものである、知り合いの知り合いという関係でめぐりあうのである。

興味をもってもらったのは上流のプロセス設計の領域で、現状の受発注システムを改修したいのだが、どうやったらいいのか悩んでいるというのだ。20社くらいに使ってもらっていて、ＡＳＰとして提供しているのだが、それが各社ごとに作られてしまい、いまやスパゲッティ状態になっているとのこと。

なるほど、ぼくも以前にＡＳＰ提供の仕組みを作ってやったがやはり同じような結果になった。当時は技術的にもインフラ的にも仕方なかったのだが、今それがSaaSという形で実現できるようになってきた。そのとき気をつけなくていけないのが、各社ごとに作っていってはいけないのであって、どれだけ共用・共有部分をもてるかである。そうすることによってマルチテナント化ができて開発・運用・保守の効率化が達成できる。というようなことを話して、これからこうした上流設計を一緒に検討しようと提案して別れた。

次がずいぶんと長い付き合いになるJ社を訪ねる。この会社にはSAPの導入・運用に関することなどいろいろと教えてもらった。情報システム部長だったひとが情報子会社の社長になって、その下にいたひとが部長に昇格したばかりである。いとしきり、ぼくの技法を説明し、その後その二人と新橋でまた呑みながら話す。営業に行って逆にご馳走になってしまうといういまだ営業になりきれないぼくでした。

話題は１９年ぶりに情報システム部門に新入社員が入ったということから、最近のベンダーが自己保全に走っているとかといった話がでる。工事進行基準もあるが、最近は短期、あるいは単発プロジェクトの採算だけを追うために、長期的な信用関係がなくなってやりにくくなったという話になる。

また、三菱UFJ銀行を例にいまのプロジェクトマネージャも大変だねえということと、豪傑のようなプロマネがいなくなったとかいったことに話題が拡がる。

帰り際、この子会社の社長になったヒトは実はプラント制御の世界の専門家だったひとなので、プロセスといったらオペレーションとコントロールが重要だねというぼくの主張をきっちりと理解してもらったのがうれしかった。

この２社をまわっていろいろな話をして感じたのはスクラッチの開発でもだめパッケージでもだめ、じゃあどうしたらいいのだろうか、いままでのようにベンダーやSIerに投げてもだめ、さあどうしよう、ここでこれまでのモデルが変わっていくのだろうという思いが伝わってくる。

後で振り返るといまこそ変革の時だったのだなあと思うだろうということも言っていた。そう、いまそんなときがやってきたと思う。みなさん、そう感じてきている。そのときの主役はユーザであり、ユーザ系の情報子会社であるとぼくは思っている。
　

今日のITmediaのニュースにぼくら親子の記事がでた。

題して「ITは、いま　：鎌倉の自宅ではたらく、父子2人のIT企業」で岡田有花さんが書いている。先月半ばにうちに取材に来ていろいろ聞いていったことが載っている。さすが記者の人は違う。こちらが勝手なことをぺらぺらしゃべったので、これをどうやって捌くのか興味があったがよく整理してある。

ちょっと照れくさいが読んでみてください。これで仕事が増えるといいのだが。そうはいかないか。
　

昨日のITmediaの記事に対して、はてなブックマークがすごい勢いで付けられた。今日で500ユーザー数に届きそうだ。

そのコメントで親父のしゃべったことがかなり評価されていてびっくりした。ちょっと恥ずかしいくらいだ。正直そんな偉そうなことを言っている意識はなく、普段から思っていることを言っただけだったので、そうした持ち上げられ方にとまどっている。

単純におもしろいこと、楽しいことをやろうよ、そのためにはどうしたらいいかということだと思う。こういうことは年齢に関係ないことであって、いくつになっても持ち続けるべき心根だと思う。おもしろいことや楽しいことって自分でやりたいことであって、周りからやらさせることではないですよね。

ただし、それをやるにはいろいろなしがらみがあって、生活であったり、世間であったり、意気地であったり、自分自身を含めた抵抗勢力がいっぱい出てくる。それとどう折り合いをつけるか、あるいはそれをちょっとがんばってどけるかである。お金がないからできないという話でもない。

大上段にふりかぶって、これから好きなことをやりますなんて宣言しなくてもいい。潮時とかはずみというのがあるから、そのとき抜け出せばいい。

そのためには普段から自分のやりたいことを磨くことを忘れないようにするということではないだろうか。

皆さんにお褒めの言葉をいただいたのは、おそらく一丁あがりと思うことなくいつも前を向いていることに対してであろう。それは、ぼくが生来の楽天家で極楽トンボだからかもしれない。でもぼくはそんな自分が好きなナルシストでもある（笑）。

ぼくが好きな言葉を書いておく。ルイ・パスツールの言葉である。
「Chance Favors the prepared mind」
　

先日（5月2日）のITMediaの「鎌倉の自宅ではたらく、父子2人のIT企業」という記事が思いのほか反響があって、まだITMediaのアクセスランキングで29位にいる。あの記事の中では、主に仕事関係の話だったが、それ以外のことを少し。

ぼくが会社を辞めて家で仕事をするということになったら、3人が喜んだのである。まあ、息子のことは記事に出ているけれど、その他の2人はぼくの嫁さんとぼくの母親である。

嫁さんの方は、最初は「ええー、お父さん毎日家にいるのおー」と露骨にいやな顔をされた。だから、自分の家ではなく、向かいのばあちゃんの家で仕事をすると言ったら、顔がほころんだ。

一方、ばあちゃんはもうすぐ87歳になるんだけど、介護がいるというわけではなく元気でぴんぴんしている。しかし、最近はさすがにからだのことが心配なようでひとり暮らしが不安になっていた。だから、ぼくがばあちゃんの家の応接間をきれいにしてそこを事務所として使うと言ったら、そりゃあ良かったと言って喜んでいた。

まあ、いつも息子が同じ屋根の下にいてくれるということで安心だし、ときどき話し相手にもなってくれるということで暇つぶしにもなる。いつも、お風呂に入るとき、風呂の中で倒れるかもしれないからと言って「今から風呂に入るから」とぼくに言ってから入る。たまに、仕事に集中しているときに邪魔されることはあっても、機嫌のいい顔がみられるのでしかたがない。

ぼくの家は山の中にあるので、買い物やら病院、郵便局に行くのもけっこう大変なのだ。坂道なので行きはいのだが、帰りの登りはきつい。嫁さんも若い頃は自転車で出かけたりしたが、歳とともに元気がなくなり、ぼくが車で送り迎えをしたりすることが増えた。嫁さんは助かると言ってくれる。

それと、山の中ということは庭に葉っぱが舞い降り、雑草が激しく生えてくる。その掃除や草取りもぼくの仕事になっていった。まあ、家の中にずっといるより天気のいい日にする庭仕事もいいものだ。

仕事の場所が鎌倉というのもなかなかいい。いいというのは東京にほどよい距離感にいるということである。自然に囲まれているということである。いつもは緑に囲まれたところで静かに仕事をして、たまに東京にでかけていくというのはメリハリがあって快適なのだ。呑んで遅く帰っても次の日は家にいられる。

ただ、こんな生活が誰でもできるというわけではない。だいいち家がどこにあるのか、ばあちゃんの家が目の前にあるのか、周りに緑があるのかなど条件がそろうのは難しいかもしれない。たまたま、ぼくにはそうした条件がそろったのだろうが、みなさんもちょっと無理すればこうした生活に近いことはできないことはないと思う。

こんなことを言っているぼくにしても、若い頃は考えもしなかったし、できなかった。やっとこの歳になって、そうだこんな生活もあったのだと気がついたのだ。だから、皆さんも、いつでもいいから一度、肩の力を抜いて自分の今の生活スタイルをみつめてみたらいかがでしょうか。
　

昨晩は、スターロジックの羽生さんとWeb+DB Pressの細谷さんと銀座のしゃれた焼き鳥やで呑む。羽生さんとは昨年から「BPMオフ会」で顔をあわせているが、細谷さんは初対面だが、うちの息子（社長）は何度か会っているようだ。

このブログで「業務プロセス設計作法」というタイトルで記事を書いていたが、それが羽生さんの目に留まって、このことについて意見交換しましょうとなった。できたら、Web＋DB Pressで何か記事にしたいねみたいなことだったので、細谷さんも同席することになったというわけである。

のっけから、プロセスの始点と終点が大事だけどどこで切ったらいいのかといった話になる。それから、ほぼ３対２くらいの割合で羽生さんがしゃべり、ぼくがしゃべるという形で、そのしゃべりが4時間以上止まることはなかった。

羽生さんは、昨日はちょっといやなことがあって、落ち込んでいると言いながら、みるみる元気になっていつものハイテンションに復活だ。

そのときぼくも言ったのだが、業務プロセスとか業務システムについて語れる人って少ないよねということで、ITの人はどうしても技術寄りになるので、言語の話だとかのテクニカルトークは好きだけど、それをどこに活かすかというWhatのことの議論がなかなかない。

もうだから昨夜は、そうした業務システムのことでかなり盛り上がったのであります。羽生さんのめざしていること（例えば最近のギョイゾー!）もぼくがやろうとしていることも基本的には同じことなのでかなり共感する。

そしてそれは単なる技術、製品、開発方法といったところだけにとどまらず、文化論のような領域まで行く。

昨日羽生さんが言っていたことで象に残ったのことをひとつ。googleはまだ20世紀の企業だということで、マスで圧倒的な力でねじ伏せるようなやりかたであるというのだ。これから21世紀型の会社はもっと違ったやり方になるのではと言っていた。

まあ、濃い話ばかりで書ききれないくらいあるので別の機会に書く。あれだけしゃべってもまだまだしゃべり足りなかったのだが、家に帰れなくなるので途中でお開き、非常に楽しい夜であった。
　

昨日は、いつもお世話になっている日商エレクトロニクスのセミナーに行く。タイトルが「継続的最適化を支えるBPMソリューションセミナー」。

最初の基調講演みたいなものが、日本能率協会コンサルティングの小笠原一洋さんでからあり、経営とITという視点でのお話。最後に面白い話というか強い思いの話があった。

これまで経営はITにだまされてばかりいた。例えば古くはSISやMIS、最近ではERPやBIといったもので、いかにもそれを導入すれば経営に大いに貢献してくれると言われたが、本当にそうであったであろうか。それに較べていま登場してきたBPMは今度こそだまされない考え方であり、ツールであると強調していた。

まあ、小笠原さんはBPM協会の運営幹事なので手前味噌のところは少しはあるが、ある期待感はみなさんあるのではないだろうか。

また、講演の中で、わかりやすくBPMの位置付けを説明していましたが、不定型業務プロセスをカバーしていくのだと言って、ERPの周辺への適用を論じていた。ぼくが前から言ってきたことを代弁してくれていた。

あと、ソニックソフトウエアのＥＳＢの話があったが、結局簡単に言うとデータ連携のところを交通整理する機能である。確かに、今のシステムでもＷｅｂサービスとか出てきたが、あらかたがＦＴＰだし、ＨＵＬＦＴだっていっぱい使われている。

また、使い方もバッチだったり、クリティカルなオンライントランザクションだったりとか、様々な形態があるので、それをうまく整理してつなげてくれるというのは必要な機能のような気がする。ただし、中堅中小にはそこまで要らないので、結構大きな企業向けのような気がする。

最後は、アバイアのCEBPソリューションの話。アバイアという会社はルーセントから企業用の電話事業が切り離されてできた会社で、日本ではあまりなじみがない名前だが世界的な企業である。

CEBPというのはCommunications Enabled Business Processesのことで、「ビジネスプロセス・アプリケーションと統合して、プロセス・ユーザーや意思決定者とのリアルタイムなマルチチャネルのコミュニケーションによってイベントの予測、検出、処理を可能にする」とある。

要するに、電話、メール、インスタントメッセージなどとバックエンドの業務プロセスと連携させようというもの。たとえば、コールセンター業務などへの適用画想定される。なかなか面白い仕組みで、電話をまだコミュニケーション手段として使っているような業務にはいいかもしれない。いまぼくが主張している情報共有の場に持ち込むこともありかなと思った。

セミナーの参加者も結構多く、徐々にBPMも浸透してきたなあということが実感できた一日であった。
　

今日は、息子と一緒に起業してからちょうど2回目になる創業記念日である。もう2年も経ったのか、早いなあというのが正直なところである。

起業したときは、そんなに突き詰めて計画を練ったわけでもなく、はずみみたいなもので、まともな事業計画もないわけで行きあたりばったりの船出であった。よく言えば、走りながら柔軟に対応していこうよという感じである。

IT起業というのは、ここらへんがいいところで、大きな設備投資もいらないし、いざとなればネットで開発の仕事をとればいいやのノリでやれるところで、技術さえ持っていれば何とかなるのだ。しかし、難しいのはそれに溺れてしまい、そこそこで留まってしまうことだ。

ぼくらも当初はホームページ制作なんかの仕事を取りに行ったりして、近場でそういう仕事をたくさん取ってきて、それをベースに自分の好きなことを少しずつやろうやなんて考えてみたが、そんな簡単ものではなく、細かい面倒くさいことをやってもそんなに稼げないことが身にしみてわかった。

じゃあどうしたらいいのだ。まずは目先の収入を追うのはやめよう、それよりもいい仕事が向こうから来るようなことを考えよう、そのためにはぼくらのやりたいこと、できることを世に知らしめることが先決ではないだろうかという結論に至ったのだ。

焦るな、自分たちの存在感を認知してもらってからでも遅くはない。そういう基礎の上でビジネスをすることが軸がぶれない安定した経営につながると考えた。

このあたりは、先日のESPer2008という未踏ソフトウェア創造事業/未踏ＩＴ人材発掘・育成事業の元開発者・現開発者による集会で、うちの社長が「社長のウェブプレゼンスドリブン経営」というタイトルで発表していて、それをブログで書いているので参考にしてください。

そして、最初の1年は社長もぼくも名前を売ることに注力した。社長は、Perlのコミュニティを中心にそうした場で発表したり、CDTubeのようなマッシュアップサービスを送り出したりした。ぼくは、自分で開発したBPMの方法論を持ってその認知に奔走した。

2年目あたりから、そうした活動が少しずつ実を結ぶようになり、開発の仕事が入ってきたり、コンサルタントとして契約できたりした。一度こうして動き出すと向こうから仕事がやってくるという良循環をもたらす。

そうなってもまだ、めざすところには到底行き着いてないわけで、これからどう対処していくのかを大いに議論して行かなくてはいけない。

課題をいくつかあげてみると、ビジネスモデルそのものをどう確立していくかという創業以来の根源的な問題がある。すなわち、プロダクト開発なのか、受託開発なのか、サービス提供なのかといったことで、それぞれに難しさを持っている。さらに大事なのは持続性のあるビジネスでなければいけないという問題である。

中でも受託開発というと「泥のように働く世界」かよという意見もあるだろうが、ぼくはある意味このビジネスは必要な通過点であるような気がする。それは何よりもユーザニーズを肌で感じることの大切さを言っている。

ただ、これもユーザの言うことをただ聞けばいいと言っているわけではない。ぼくは受託開発にも“攻めの受託開発”と“守りの受託開発”があると思っている。

皆さんお分かりだと思いますが、言われたとおりに開発するのが“守り”です。それに対して“攻め”は、こちらからも提案や企画もするし、言われたこと以上のことができることを言っています。“攻めの受託開発”は魅力的なビジネスです。

そのためには、自分たちが保有する技術、ソリューション、サービスをお客さんにきちんと理解してもらい、それを使う価値を共有することが重要である。それができれば、目先の売上を得るためにやりたくない仕事、自分たちが得意でない仕事を取ってくることは必要なくなると思う。

そうは言ってもと言われるのは分かります。そうした声が出てくるのは既存のSIerやソフトハウスからだと思います。なぜかというと既に人を抱えてしまっているから、どうしても守りに入らざるを得ないのでしょう。

でも敢えて言いますが、それだとジリ貧になるのは目に見えています。どこかで“守り”から“攻め”への転換をしていかなくてはいけないと思います。

その点、起業から入る場合は、ひとの問題はないので、資金面だけ我慢できたら“攻め”から出発できるという有利さがある。

ビジネスモデルの確立という課題は、“攻めの受託開発”もやりながらどうするか模索していくことになるが、もう一つの問題はリソースの確保の問題である。

今は二人でやっているが、いくらいいビジネスモデルを作ったとしても、ビジネスを拡大するという前提に立てば、リソースが不足する。その対応をどうするかが大きな課題である。自分たちの技術や方針に共感してくれて、一緒にやってくれる人を捜すのはやさしいことではない。

しかも、二つのタイプの対応が必要になる。ひとつは量への対応であり、もうひとつは質とかレベルへの対応である。すなわち、同じようなスキルを持って量をこなせる人と自分たちの持っていない領域のスキルを持ったひとの確保ということである。

いずれにしろ、ぼくは何とかなると思っているのは、ネットの世界の可能性を思うからである。いま言ったようなリソースの確保にしても、別に同じ会社にいなくてもいいわけで、ネットワーク型の仕事体でかまわないし、そういう形態は当たり前になっていくような気がするのである。

さて、いよいよ３期目に突入するが、1年後のこのブログにどんな報告ができるか楽しみである。
　

昨日は、Web系の会社の人たちとミーティング。最初が、日本の草分けのような会社でそこでBPMの紹介とぼくが今やっているBPMS+CMS開発のことを少し説明する。最近は、こうしたWebの開発から入って、バックヤードの業務プロセスにつながる話が多くなっている。

やはり、顧客との関係性が重要になってきているということと、そこからのプロセスの効率性も問題になっているのだろう。

一昨日に行った通信系の会社でもショップでの応対作業のパフォーマンスを改善するためにプロセスの可視化をしたいという案件であった。

それが終わって、次もWeb系の会社の若い社長と呑むことになっていて、新橋の機関車の前で落ちあうことにした。こちらはぼくといつものUさんともうひとり名古屋から出てきたあるIT会社の役員で事業部長をしているTさんのおじさん三人組である。

そのTさんを待つっていたら、だれか近づいてくる。何だろうと思っていたら、「テレビ東京の者でですが、インタビューをお願いできますでしょうか」ときた。マイクとカメラをもった若い子も近づいてきた。

どうもUさんに向かってお願いしていたのだが、Uさんが固辞してしまった。結局あきらめてしまったが、いったい何のためのインタビューなのだろうかという話で、きっと株が暴落している事に関してじゃないのかということになった。

ところが、今朝の新聞をみたら、そうだノーベル賞のことだったのだと合点がいく。ただ、あのときノーベル賞のことを、聞かれても答えようがないなと思った。Uさんのそのあとの話で、以前にも街頭インタビューに会ったことがあって、そのとき大江健三郎がノーベル文学賞をもらったときだったという話だったから、よくよくノーベル賞に縁があるのだなあと感心した。

その若い社長は、中村祐介さんといって75年生まれです。もと記者で作家でもあります。「力道山」という本も出しています。ぼくは、この原作を元にして作られた映画を観ていたので、しばらくその話になる。

彼は、力道山を知らない世代なのに書けてしまうので大したものだ。でも逆に知らないからこそ客観的に見れるのでいいのかもしれない。ぼくらおじさんトリオは力道山世代だから、ひとしきり金曜日の夜はテレビのある家に見に行ったとか、三菱電機の掃除機がリングを掃除しているのをみてお袋がうちもあんなのがほしいなと言ったとか、そんな思い出話に浸る。

そこから、現代若者論みたいな話で、いまは出会いの場がぜんぜんない、ちょっと前まではナンパも一種の出会いだったのに今では怖くてナンパされなくなったということらしい。そうしたら、おじさんたちの得意技である、俺たちの時代はなあということにすぐに持ち込む。

おじさんたちの時代は、ナンパではなくダンパであり、合コンではなく合ハイだといったら、中村君はきょとんとしていた。ダンパはダンスパーティのことで、合ハイというのは合同ハイキングのことであると説明したら、かなり受けた。

でそんな話やら、日本のIT業界の黎明期に何があったのかをちゃんと残そうよねみたいな話だとかすごい盛り上がった。

ちょうど親子ほどの年齢差だが前にもこのブログでも書いたように、その親子の世代差のほうが分かりあえるのではないだろうか。なぜかというとぼくは、親と子として子供が小さいころから同じテレビを見、同じ歌を聞き、同じ景色を一緒に見てきたからではないだろうか。だから何となく波長が合うというか、理解の範囲内にあるのではと思うのである。

そんなわけで、親子ぐらい歳が違うひとたちとコラボレーションできたらいいなあと思っている。
　

　

昨日は、ある大手オフィス機器メーカーの開発部門に行く。行く前にプライベートなところでBad Newsが飛び込んできたのであまり気乗りがしなかったが約束だから出かける。

相手は、ソリューション技術開発の若い有能な2人の技術者である。一人がうちの社長のコミュニティ仲間だったので紹介してもらったのである。

目的は、今ぼくがやっていることを紹介して、それに対する評価を聞くことであった。いきなりビジネスをやろうなんて話ではもちろんない。

ひととおり説明し、いろんな話をしたが、さすがにもの分かりが早い。ユーザもSIerも全く変わってしまうことをすぐに理解する。やっぱりわかるやつはいるんだと意を強くしたのである。けっこう評価してくれたのうれしかった。

これからやりたいことや付加機能なども披瀝したが、できそうだとも言ってくれてこれまた喜んでしまった。この日も“オヤコラボ”の日でもあった。

てなことで、説明しているうちに最初の沈んだ気分もなくなって盛り上がっていった。もちろん終わってから戻ってしまったが。

彼らは開発部隊だから、おいそれとぼくのやっていることをやるわけにいかないだろうし、事業という視点も持ちにくい。ということで事業部門の人を紹介してもらうことにした。どうもぼくと一部同じようなことを考えている人がいるとのこと。ある4分割の図を見せたら、同じ図を書いている人がいるのだそうだ。その人に会わせてくれるという。

徐々にではあるが、理解者を増やし、実践者を増やしていきたいと思っているので、こういう機会を今後もつくっていこうと思う。

今月の24日に発売になる「Web+DBPress」Vol.47にぼくの書いた記事が掲載されます。タイトルが「実践的BPMのための 業務プロセスの設計作法」です。

このブログにも書いてあることですが、BPMアプリケーションを開発するためには、上位のプロセス設計が大事になってくるという主旨で、そのための設計作法について書いています。

一緒に社長の知り合いのYappoさんや、つい先日お会いした山本陽平さんも記事を書いているのでけっこう感激しているのです。

元々は8月発売の前号に載せるはずだったのですが、事情があって2ヶ月遅れとなりました。したがって、微妙に変えたいところもあったのですが、そのままにしてあります。

この雑誌は、若い開発者向けだそうですが、ぼくのような年寄りが書けるのかと逡巡しましたが、開発者にとって業務プロセスをきちんと捉えておくことは非常に重要であると思っていたので、そこに焦点をあてればぼくでも書けると思って引き受けました。

この記事は、スタロジの羽生章洋さんが技術評論社に紹介してくれて実現しています。羽生さんに感謝です。

さて、今月はこの記事が出るのもあり、また、社長が「エンジニアtype」という雑誌でインタビューされた記事も出て、そこに写真が載るのですが、そこにぼくの姿があります。

また、社長は新しいサービスについての記事などが雑誌に紹介された、あるいはこれからされるようで、親子で露出しています。というわけで、ウェブプレゼンス・ドリブン・マネッジメントの実践です。
　

昨日は、社長が最近一緒に仕事をした渋谷の若い人が経営している会社に社長と一緒に行く。Endeworksという会社で社長はPerl界隈では有名な牧大輔さん。1977年生まれだから31歳である。うちの息子よりも上だが親子ほどの年齢の開きである。

何しに行ったかというと、ぼくがいまやっていることを聞いてもらい意見をもらいたいということなのだが。ひょっとしたら、何か関連するものがあるのか、一緒にやれるようなことがあるのかということである。

こういう人は、理解が早いし、すぐに頭がこうやってコードを書いてみたいなところに持って行ってしまう。それで、少しは興味を持ってもらえたのかなあというのと、そんな難しいことではないと言ってくれた。

ただ、問題は誰がやるのか、やるにしてもビジネス的な観点ではどうなのかといった点が議論になる。これは、昨日だけの話ではなく、いつもついて回っていることである、すなわち、資金的な裏づけとその後のビジネスの展望が確保されたなかでプロジェクトに落とせるかという課題である。

ぼくのアイディアがそれに相当するかどうかは別として、日本でもシリコンバレーのようにベンチャーキャピタルが資金返済を条件としない投資をしてくれるような仕組みが欲しいということなのだ。そういうリスクを冒せる風土になってほしいと思うのである。ただ、今のような状況だと難しいだろうが。

ぼくが説明した中で、牧さんに指摘されたのは、やりたいことやろうとしていることはだいたいわかるが、それが既存のものとどこがどう違うかがよくわからないと言われてしまった。

確かに、ぼくはエンタープライズ系のシステムばかり見てきているので、従来型のシステムは最初から頭に入っているが、そこにいない人にとっては、従来型といわれてもどういうものなのかは分からないのだ。

つい、自分の常識が他人でも常識だという思い込みに陥ってしまっていた。ということで、その差異をしっかり説明できるような資料を作り始めた。

打ち合わせの後、牧さんの会社の若いエンジニアの人2人も交えて、近くの店で呑む。皆さん非常に仲がいいのが、その会話ぶりで伝わってくる。牧さんの会社は5人の会社なのだが、いわゆる普通の会社の形態ともちがい、一緒の事務所にいるんだけれど個人がネットワーク的やり方で仕事をしているといった感じなのである。こういうやり方も面白い。

まあ、牧さんのばかでかい“あら煮”と格闘している姿を見ていると、このエネルギッシュさがいいのだと感心してしまった。他の二人の貧乏話に大笑いをし、楽しい夜を過ごしたのであります。
　

うちの会社の事業年度は9月―8月なので、本来なら9月新しい年度の経営方針や事業計画をつくるのが筋だが、そんな大げさなものをという気持ちもあるし、けっこう忙しかったりするので、年末年始に落ち着いて考えるのがいいみたいで、家で風呂にゆっくりつかり、酒を呑みながら思いめぐらせることにしている。

いまワディットも3期目に入り、何となく進むべき針路のようなものがおぼろげながら分かってきたように思う。

最初の期は、なんとかなるわとたかをくくっていたが、全く仕事がとれず、どうなるものかと不安の船出であった。そしてあるときから考え方をがらりと変えた。目先の小遣い稼ぎを捜すのはやめよう、やりたくないことを無理してやらないことにした。

そうこうしているうちに2期目に入ると仕事も舞い込んでくるようになり、そこそこに売り上げも達成して、黒字になった。ただ、黒字といったって自分たちの給料次第でどうにでもなるので、細々ともらって黒字なのか、たっぷりもらってまだ儲かっているのかである。

確かに、給与額（役員報酬になるが）はそう多くはない、むしろ少ないくらいだと思うが、感覚的にはそこそこもらっていると感じる。ぼくは、以前はサラリーマンだったから、その感覚でいくと少ないが、何と言っても可処分所得の比率がぜんぜん違うから、まあまあの給与額なのである。

さて、今年の事業計画であるが、昨年は受託開発のようなこともやったのだが、今年はそこを控えて、自社サービス、自社プロダクトを中心に据えようと社長とは話している。まあ、受託開発の仕事は自社サービス、プロダクトの提供をやっていく上でどうしても通らなくてはいけない道であったと考えている。徐々にその軸足を変えていくということになる。

では、その自社サービスとかプロダクトとはいったい何なのであろうか。ここで、初心に帰って眺めてみると、親子で起業したということ、ネット系（ギーク・あちら側）とエンタープライズ系（スーツ・こちら側）を融和させるということ、Web2.0を企業に活かすということなどなど、そんなマッシュアップビジネスをやろうとしてたじゃないかと思うのである。

それをやります。従来の発想ではないフュージョンサービス・プロダクトです。今基本設計をしていますが、たぶん相当面白いことになりそうです。これは、最初はお金にはなりませんが、出来上がったあかつきには儲ける仕組みも考えようと思っています。さあ、わくわくしてきたぞ。
　

ここのところスタロジの羽生さんが立て続けにブログですごくいいことを書いているので反応したくなった。「営業マン」「起業・経営の必要条件」「制約が工夫と本質を磨く」である。

GoTheDistanceさんもこのエントリーに対してコメントしているが、ぼくはぼくなりのちょっと違った視点で考えてみた。羽生さんが書いていることは、会社でモノを作ってそれをお客さんに売って会社の経営を立ち行かせるには、何が大事なのかをこれだけの行数でほぼ言い尽くしてあるのに驚かされる。

ぼくも２年半まえに起業してまがりなりにも会社を経営しているので身につまされる思いで読んだのである。ただし、これは何も起業している人たちだけではなく、普通に会社で働いている人にとっても当てはまることでもある。

ブログの記事に言及する前に最近の問題も絡んでくるのでそのことに少し触れておく。いま、派遣だとか非正規社員だとかいう問題が喚起されているが、皮相的な議論はさておき、ぼくは本質的なところをよく考えておく必要があると思っている。

それは何かというと、働く価値というか生きがいをもって働くということはどういうことかということである。

どうも今の派遣などの問題では、何でもいいから職をくれ、給料をもっとくれと言っているようだ。そしてワークシェアリングだなんてばかなことを言う。こういうことは、裏を返せばノンワーキングリッチが何といわれようとも会社を離れないといっているのと変わりはない。

すなわち、働くということは、いやなことやりたくないことでも給料がもらえればそれでいいのだという振る舞いにつながるわけで、そんな主張をみんなしているのだろうか。

だから、事の本質は働く人それぞれが生きがいを持てる、あるいはそこまでもいかなくても好きになれる仕事に就けるという多様的な雇用の流動化が必要なのであって、派遣規制をするとか労働者を保護することではないのだ。

こんなことをいうと、必ずそんなことをすぐに出来るわけがないとか、だれでも好きなことができるわけがないと言う。そりゃすぐにできないし、みんながやりたがらない仕事をするひともいるだろうが、徐々にでもいからそういう構造にもっていくように舵をきることなのだ。

昨年、うちの社長(息子)が転職雑誌のインタビューを受けたことがある。社長は就活もしたこともないし、就職もしたことがないのになぜ転職雑誌に載るのかと思ったら、その編集者が、「起業も転職の一つです」と答えたのでなるほどと思った。

転職とは自分のやりたいことをやれる場所を探すことだから、確かに起業は既存の会社ではできそうにないので会社を起すわけだからそういうことだ。だから、社会構造的かつ心理的にも、こうした動きをもっと滑らかにできるようにしたらいいと思うのである。

ただ、ここで転職と起業の大きな違いがある。起業する場合、羽生さんの言う「起業・経営の条件」としての「財務と営業」の重要さである。買って頂く能力とお金の使い方の能力が不可欠なのです。だから、羽生さんの言うように、会社を作るのは簡単だが、この条件をクリヤーするのは並大抵のことではないのだ。

羽生さんはこれをOSのようだと表現していますが、従ってもっと大事なのはこのOS上で何を動かすかです。すなわち、どんなものを売るのか、何を商品とするのかです。それが魅力あるものであるのか、お客さまが欲しがるものなのだろうかとなる。しかし、それがあったとしてもお客様が来るのを待っていたら売れないわけで、それをどうやって売るかが“営業”なのである。

ぼくが営業で最も必要と思うことは、簡単に言えば「自分がほれ込んだ商品を売ること」である。これは営業だけに限らず、開発や製造でも同じで、「自分がほれ込んだ商品を開発することであり、製造すること」なのである。だから、最初に言っているのは、こういう誇りを持てる仕事をすることで報酬を得ることを志向しようよということである。

羽生さんのブログに出てくる営業の人たちは、ぼくの経験からも一般的によく見てきた。自分商品がそれほど好きでないのに売り込みがうまいやつとか、某社のように圧力団体のように大勢の営業がきて脅していく。ただ売れればいいという態度である。それではなかなか売れないと思うのだがけっこう多いパターンで、そういう人たちは”売れそうな商品”があるところにすぐに乗り換える。

逆にいえばほんとに自分が愛情をそそげるような商品があり、それがいいものであれば、必ず売れるはずだ。スタロジはギョウゾー！ができてうらやましい。ぼくらも今年前半には何とかいい商品をつくるつもりだ。

そして、そのいいものを作る上で意外と思われるかもしれないが、「制約が工夫と本質を磨く」ということが大事なのである。何でもお客様が望むことができるのがいいことではないだろうし、様々なお客様が同じことができるとは限らないだろうから、必ず制約というものが存在する。

ただし、その制約とは、これができない、これをしてはいけないということではなく、羽生さんの言う「型」にはめることだと思う。ただし、その「型」が本質的で、かつ適応的なものでなくてはいけません。

この本質を見極めるというのは、業務システムの領域について述べますが、システムからの発想では見えてきません。システムは単なる道具だからです。業務側あるいは使い手側から発想していくと、本質が見えてきます。

実はその業務は「型」があることに気がつきます。大変シンプルなものです。そして、それができれば、そこには「作法」が生まれ、そこで初めて作法を実行するためのインターフェースとしての道具（システム）が必要になってきます。

結局、「本質を見極めた商品を作り、それにほれ込んで売り込み、買ってもらったお客様に喜んでもらうこと、その結果、利益（給料）もそこそこあげられるということ」を働きがいがあることだと思えるようにしたいものです。
　
そのためには、繰り返すが、硬直的な労働市場ではなく、もっと流動的にすることだとぼくは思う。

社長（息子）が役員をやっている、といっても2人だけだが、「オモロキ」という会社がある。そことある出版社と組んで「ボケて」というタイトルの本が明日発売される。

この「ボケて」というのは、本の副題にもあるように”写真で大喜利”という感じで、ネット上で写真をお題にしてひねりのきいた面白いコメントを書き込むサービスで、そのコンテンツが本になったのである。

サービス開始してから5ヶ月ぐらい経ったのだが、一部熱狂的なファンもでき、かなりの作品がたまっているようだ。思わず吹き出してしまうものもありなかなか楽しいサイトですよ。こういう形の出版がこれから増えてくるかもしれませんね。

で本になると聞いて驚いた事が一つあって、どこで売るかである。それが、コンビにとAmazonなのである。いわゆる一般書店には並ばないのだ。そういえば、コンビニに多くの雑誌に並んで本が置いてありますよね。あの類の本として販売されるという。そして、初版の部数もそこそこ出るらしい。

そこで、全国のコンビニの数を調べてみた。セブンイレブンからam/pmまでの上位7社の合計が４５,０００店舗である。だから、1店舗1冊でも45,000部になる。たとえ、セブンイレブン一社だったとしても12,000店舗であるから、１店舗3冊置いても36,000部である。おおー5万部くらいいけるかも！？

ところで、一般書店の数はどのくらいだと思いますか。昨年半ばで16,400軒なんですね。それがどんどん減り続けているそうです。2001年は21,000軒あったのがそこまで減少している。こうしてみると書店の店頭販売より、コンビニやネット販売の方が部数をかせげるんですね。

この「ボケて」は600円ですから、どうぞ気楽にお買い求めてください。これを読んで大笑いしてボケを防ぎましょう。意味ちがうよ、そんなところでボケないでよ。ハイ。
　

2,3日前いつもBPMオフ会でお世話になっているwkzkさんのブログ「今年は違うよ、わきぶろぐ！」で「ボケて」というサイトが紹介されていた。

このサイトは実は僕の息子とその友達で作った会社「オモロキ」から提供されているものです。昨年の9月に公開されて、今年の5月にガンマ版にバージョンアップしたので、その紹介を載せようと思っていたのをそのままにしておいたので、この機会に遅まきながら触れておきます。

このサイトは「写真大喜利」といった趣で、ネット上の写真をネタにそこにひと言かぶせるわけです。見るだけでもおもわず吹き出すような言葉もあっておもしろいし、自分で投稿するとなおいっそう楽しくなります。

これに対する最大のほめ言葉は、WKZKさんが言った”本当にくだらなくて最高です！”ではないでしょうか。

この3月には書籍化もはたしましたので（コンビニとAmazonで売っています）、ぜひウェブと本の両方で楽しんでください。
　

うちの社長（息子）が提供しているサービスのひとつ「ListPod」がリニューアルされました。サービス自体は昨年からリリースしているのですが、ここへきてグレードアップしました。

http://listpod.tv/

ListPodというのは、YouTube 動画のオンライン Podcast 作成サービスで、ユーザーはお気に入りの YouTube 動画 をマイリストとして登録。 それらを Podcast として iTunes などのソフトウェアで読み込ませ iPhone、iPod といったモバイル端末で再生することができるものです。

いまユーザ数が5,600くらいで、このバージョンでは、ブラウザの言語設定が日本語以外だとメニュー等が英語表記されるように、 ローカライズしたので、海外のユーザーも増えることを期待しています。

OpenID によるログイン方式を使用しているので、すぐに登録されますし、使い方も簡単で、分からなかったらチュートリアルのようなものもついています。

自分好きな動画をもち歩いて、好きな時にそれを見る生活をしてみませんか。
　

昨日おとといと続けて新しい研究会がスタートした。両方とも呼び方は違うけれど、基本的にはみなが集まってあるテーマで議論して何か出てきたらいいなあという感じである。

おとといは、「SCOR-BPM&SOA要求開発手順構築コンソーシアム」という少々長い名前の研究会で、主催はSCC（Supply Chain Council）で、戦略的な領域とデータマネジメント、システム企画・設計というチームに別れ議論することになった。

ぼくの理解では、SCORというのは上流の業務のリファレンスモデルであるが、それをベースにシステムに落としていくときに、BPM&SOAというアーキテクチャを活用して実現するにはどういう要件があるのかを探るということと思っている。

ただし、あまり最初からSCORを意識すると視野が狭くなるので一般論的なところから議論したらいいと思う。ぼくは、システム企画・設計というチームに入ったので、そこでもユーザがシステムを使って業務運用をしたとき、必要となる戦略的な指針やルール、あるいはデータ項目は何かという観点で見ていこうという提案をした。

もうひとつの研究会は、以前「BPP（Business Process Pattern）研究会」というのを主宰して先月終わったのだが、メンバーからさらに続けていきたという声が上がったので、少し形を変えて、かつ新規メンバーも加えてスタートした。

だから、ここは若い人にコーディネートをしてもらって進めることになり、名前を「業務プロセス勉強会」というふうなった。この会は、30歳前後の若いひとたちが中心でそういう意味ではぼくは異質であるが気持ちが若いから（笑）まあいっか。

昨日は、SAPが出している「BPM Technology Taxonomy」というホワイトペーパーの読み合わせをしながら議論して、そのあとどんな勉強会にしようかという話合いを行う。まあ、勉強会といっても講義方式ではなくディスカッション主体でやろうということになり、毎回誰かが業務プロセスに関する話題提供をして、それについて議論するようにした。

いずれにしろ、最初のコンソーシアムにも若い人も参加しているので、既成概念にとらわれない若者らしい意見をどんどん出してもらい刺激をもらいたい。こういうところから少しずつでもいいから変化がおきたらいいと思う。

うちの社長（息子）の作ったサービスがマイコミジャーナルの記事になった。このサービスは、Twitterで自分部屋のエアコンの設定温度をつぶやくと、それが集計されて、平均設定温度などが分かる仕掛けだ。

最初にこんなの作ったけどどうと言われて、何これって思ったが、すぐになんじゃこれ面白れーとなった。単純なんだけど、なんていうか”つながり感”がありますよね。２チャンネルなんかのスレッドなんかとは全然違った情報共有ですね。

それと、こういうのってマーケティングに使えそうな気がする。Twitterの利用者がどんどん増えてくるとユーザがどういう反応なのかが即座に分かるし、ちょっとしたコメントも聞けるので、単なるアンケートなんかとは格段に違う情報が得られるはずだ。

第二段として「teletter」というのがもうすぐリリースされると思うが、これは今見ているテレビ番組のことについてつぶやいてもらうわけだ。これなんか、これまでのような実態がつかめてないと思われるモニタによる視聴率調査とはぜんぜん違った結果が出てくるかもしれない。

こんなことで、マスメディアの”すね”を蹴っていくと崩れおちていくのかもしれない。
　

昨日「仕事するのにオフィスはいらない」（光文社新書）という本を紹介して、そのなかにフリーランス的な働き方をノマドワークスタイルと言うと書いたが、僕自身もかなりこのスタイルに近いのでそのことについて書く。

ぼくのオフィスは自宅と同じ敷地内にあるばあちゃんの家の応接室をちょっと手入れしたものである。基本的にはそこで仕事をするのだが、自宅の自分の部屋で仕事をしている社長（息子）との共同作業や外部の人たちとの仕事をどうやっているかである。

社長とは以前はSkypeを使って会話をしているが、相対で話し合った方がいい場合は、ぼくの事務所に顔を出してもらうことにしている。ただ、かなりの頻度で昼飯を一緒に食べているので、そのときに業務連絡や懸案事項について会話しているのでそれで情報は共有できる。

最近は、共同のプロジェクトが走りだしたので、少しスタイルを変えて、Subversion、Trac、Googleトークという組み合わせで仕事をしている。それでお互いの成果物の状況やタスクの進捗をチェックして、チャットで意思疎通を図り進めている。まあうまく行っている。

外出は最近減ってきたが週2～３回東京へ出かける。それこそ佐々木俊尚さんじゃないが持ち物は、ネットブック（PCは3台持っていて、ほかには事務所にあるデユアルディスプレイのデスクトップとデモ用のThinkPadである）、Emobile、ケータイ、カード入れ（財布は持たない）、読書中の書籍1冊、自宅のカギとぼくは佐々木さんと違ってペンとノートは持つことにしている。

ノマドの人たちの問題は外のどこで仕事をするかである。よくあるのが、スターバックスやドトールとかのカフェあるいはマックやジョナサンといったファーストフードの店などであろう。

ぼくがよく利用するのは、「ルノアール」である。この喫茶店は少々値がはるのだが一番だ。その理由は、静かで落ち着くこと、電源がそばにあり使い放題であることであろう。前述したカフェやファーストフーﾄﾞ店だと下手すると隣に高校生かなんかの集団が来たらたまったものではない。下の息子はそのために耳栓をもっていくのだそうだ。（なるほど）

さらにいいのは、ビジネス席というのがあるところがあって、そこだとパーティションで区切られているので快適である。あの本にも書いてあったが、アテンションコントロールが大事だといっていたが、これは注意力、集中力のことで、ここでは自宅にいるよりはるかに集中して仕事ができる。

こんな生活をしているから、どこにいいスペースがあるというような情報も蓄積されてくる。たとえば、三軒茶屋のキャロットタワーの展望ロビーとかアトレ大井町の休憩所とか京王百貨店のエレベータ前とかレアーな場所が定位置になったりする。

そして、ぼくのお気に入りは夜ひとりで呑みながら仕事をすることである。仕事を終えて、そのまとめや課題をメモしたり、提案を修正したりする。そして、少し酔いが回っていい気持ちになるとブログの原稿を書くのである。

そこは、決まった呑み屋で決まった席で決まったつまみと酒なのである。そういう店が何軒かあって、そばと日本酒、魚と焼酎、ソーセージとワイン、ギネスとフィッシュ＆チップス、餃子に紹興酒といった具合にその日の気分で変えていく。

もちろん、通勤ラッシュは避けたいから午後しか東京では仕事をしない。困るのは帰りであるが、混みそうなときは、東京駅から並んで座るか、グリーン車で帰ってくることにしている。何ともはや昔の会社勤めのときと比較するとものすごく楽だし楽しい。ただし、これでお金が稼げればという話だが、ぜいたく言わなきゃなんとかなるものですよ。
　

昨日は、慶応大学の日吉キャンパスにある協生館に社長と行く。最初は電車で行くことになっていたが、朝顔をあわせて話をしていたら急に車で行こうとなった。二人とも電車が好きではなく、特にラッシュのときなど嫌になってしまうので、何となくそうなってしまった。

用件は、そこにある大学院のメディアデザイン研究科の奥出教授に会いに行ったのである。先生は社長の大学院時代の指導教授だったこともあり、いま二人でやっていることについてご意見をいただきに伺ったのである。

ぼくは初めて日吉キャンパスに行ったのだが、その協生館というのにびっくりした。昨年にできたばかりだそうで、新しいこともあるが、中の施設がすばらしい。５０ｍのプールやフィットネスクラブといったスポーツ施設、バーやコンビにさらになんと保育園まであるのだ。開放型のキャンパスというコンセプトである。

ミーティングのあとにも研究施設を見せていただいたが、もう研究室というものがないそうで、かなり混然と横断的な研究活動になっているようだ。そして、そうした研究から生まれた成果を事業化すべくインキュベーション展開できる場も用意してある。そして海外との連携も行っている。すばらしいのだ。

さて、その先生からもらったアドバイスは、やっていること自体については特にコメントはなくて賛同してもらえた。ただ問題はそれをだれに売るのか、だれに売ってもらうのか、どんな売り方をするのか、価格をどうするのかということで、そうしたビジネスモデルを描く段階になっているというご指摘をいただいた。

次回、そのビジネスモデルについて議論することになった。やはり、どんないいものを作ってもそれを買ってもらえる、使ってもらえなくてはいけないのであって、そこがすごく大事であるということを強調された。大学の先生でこうしたマインドを持っておられることに敬意を表さざるを得ない。

終わってから、社長と別れて新橋のルノアールで仕事をして、夕方に映画を観て、ビアホールで腹ごしらえをして、いつものように銀座の「M」で締めるという「ノマド生活」で一日を終える。
　

最近、Twitterが日本でも人気になっているらしい。アメリカなんかではかなり浸透していて、例のハドソン川緊急着陸や大統領選なんかでも話題になっていた。

このＴｗｉｔｔｅｒというのは、140文字以内で「つぶやく」だけというものだがそれが受けている。つい先日もうちの社長が公開した「＠eacon」のことを記事にしたが、今度は「twib（ツイブ！）」というサービスをリリースしたので紹介する。

これは、「Twitterホットエントリー」という機能で、Twitter上でつぶやかれたホームページのURLを集めて、人気順に並べるものです。一見して「はてなブックマーク」に似ていますが、利用者層や使い方など微妙に違っていて面白いです。

公開して、すぐにアクセスが始まりかなり注目されています。Japan internet.comやcodezineなどのにも掲載されています。

これはまだベータ版だからみんなの意見を聞いてどんどん機能を追加していくようだ。このあたりのユーザの反応を見ていると、こうしたプラットフォームがマーケティングのようなところで使われていくような予感がする。いわゆるアンケートとかモニタリングなんかにくらべリアル的にそして真に実態を表した答えとして返ってくるので有用であると思う。

皆さんも一度使ってみてはいかがですか？
　

盆が明けて今週から仕事モードに入った。月曜日にはBPM協会のコモンセンス部会で「SCORとBPMの接点を定義する」と題してプレゼンを行う。上流の戦略から落としてくるトップダウンアプローチであるSCORモデルとプロセスを設計していくボトムアップアプローチであるBPMをどこ出会わせたらいいのか、そこのつなぎ目をどう定義したらいいかというとで私案を提示した。

水曜日には、SCCの要求開発手順コンソーシアムの部会のメンバーでこれからの進め方を議論する。システム開発の構想・企画・基本設計を行うときに戦略的なことや事業などに求める要件は何かというようなことがテーマである。

そのあとは、前述の部会がそのメンバーの会社の事務所で行われたが、その会社には以前かなり深い付き合いをしていたので、誘われてそこの役員の二人と会食をする。ほんとうは業務プロセス勉強会の予定だったが、非常にお世話になったので断れずに勉強会をキャンセルした。ごめんなさい。

その会食した人たちの会社は中堅のSIや自社開発パッケージ販売など手がける会社であるが、昨今の景気はかなり効いてきているようで渋い顔をしていた。ただ、IT業界は変革時なのだから、逆にビジネスチャンスが大いにあると励ます。

そのうちのひとり専務のOさんは、ブルースハープを演奏する人で、いつもハーモニカを持ち歩いている。ぼくもブルースが好きだったので、そうした話でもりあがったり、前には南青山の「Blue Note Tokyo」で一緒にブルースのライブを聴きにいったりした。この日も、銀座の「M」で帰り際に久しぶりにブルースハープを演奏してくれた。

昨日は、昼に慶応大学の奥出教授のところに行って、いま社長(息子)と一緒に開発しているBPM Framework「Kailas」のビジネスモデルについてアドバイスをもらう。製品コンセプトや機能についてはお墨付きをもらったので、それをどう売っていくかの相談である。非常に面白いアイディアをいただいたので、それをどう具体化するか検討を始めた。

そのあとは、M&ERPの渡辺さんのプロジェクト会議で社長にまだできかけなのだが、「Kailas」のデモをしてもらう。基本的なところだけだったが、要望だとかいくつかのサジェスチョンをもらう。二人だけでやっていると見方が狭くなったりするので、こうした機会で幅広く意見をもらうのは大事だ。

そして、いつもの呑み屋でおじさん三人組の小宴会である。いつも熱い会話でNさんは終電にぎりぎりだといってあわてて店を出て行った。さあ、忙しくなるぞ。

昨日は、社長（息子）と二人でCalifornia State Polytechnic University, Pomonaの一色浩一郎教授とお会いする。先生は東京プリンスホテルで開かれているITCカンファレンスに登壇することになっていて、昨日からそのホテルに投宿しているので、そこで待ち合わせて、ITCカンファレンスのレセプションまでの１時間半でお話することができた。

趣旨はわれわれが今作っている新しいBPMフレームワーク“Kailas”を見てもらうことでした。まだ全部はできていないのですが、骨格のところがだいたいできたのでご意見をいただこうと思ったのです。

それを説明する前に、社長がやっている「CDTube」や「ListPOD」、「Twib」などのWebサービスも見てもらい、AmazonのEC2の話も飛び出し、そして、先生の教え子のアルゼンチン人がミリオネアになったことなど面白いことになる。

さて、その“Kailas”なのだが、予想以上に評価していただきうれしくなる。先生の専門は要求工学なのだが、そこでは要求を定義してそれを実装するためのよいツールがないのだそうだ。そこに”Kailas”は使えるという言葉をもらえたのである。

要するにシンプルで柔軟性に富んだものがほしいと思っていたのに合致するという評価なのだ。そして、もっとデザイン的に改良して“高級感”を出して、そしてマーケティングを良く考えることというアドバイスをいただいた。

やはり米国で教鞭をとっていて、しかも実際のビジネスに関わっている先生なので非常に感覚が鋭い。また、オランダでも教えていたり、各国を回ったりしていることもあって、米国だけにとどまらず、欧州、ロシア、南米、東南アジアなどの事情に詳しい。

ですから、世界の市場で10%しかない日本ではなく、40%ある米国で売りなさいと言われた。そうすれば欧州は米国で使われたらすぐに買うからということだそうだ。そして、大きな会社に買ってもらうことと言っていた。米国では、日本と違って、いいものであればどんな小さな会社が作ったものでも買ってくれる文化があるとのこと。

もし、もっと磨きをかけていいものになったら米国で売るのを手伝ってくれると言ってもらえた。だから、YAPCまでにもう少し、それが終わってからも手入れしていい商品にしようと、社長と二人で誓ったのである。

昨日は東京工大で開かれているYAPC::Asia2009にスピーカーとしてプレゼンテーションを行いました。YAPCというのは、Perl技術者を中心にしたカンファレンスで、ほとんどが若い子で、テクニカルな話題を中心にセッションが設定されています。

ですから、ぼくのような還暦を過ぎたおじいさんがスピーカーというのは始まって以来の最年長だそうだ。しかも、親子で掛け合いで行うのもおそらく初めてのようで、珍しがられました。

発表は、二人で作った「Kialas」というBPMFrameworkで、実際に動かすデモを中心にして説明しました。練習ではちょうどいい時間だったのですが、いざ本番となると余計な事を言いすぎて時間が足りなくなってしまい、最後はあわて締めくくるはめになった。反省。

この内容はエンタープライズ系の業務システムがテーマなので、このカンファレンスの入場者にとってはいささかなじみのないものなのだが、中にはこうしたものもあってもいいという思いで話した。

そうしたら、終わった後の懇親会で数人の方々から興味があると言われたし、いつ製品として提供されるのですかという質問までいただき、まったく異質でもなかったのかなあと胸をなでおろしました。

もちろん、ぼくは初めての参加なので、ほかにどんなセッションがあるのかと、プレゼンのあとずっと聞いてみた。最初は、技術的なことはまったくと言っていいほどわからないが、はてなやペパボ、リクルートの話などは何となく雰囲気的におもしろかった。

Perlのコミュニティというのは、非常に和気あいあいでフレンドリーな気風がありよさげです。どうも、PHPやJavaなどのようなメジャーな言語ではこうはいかないようで、あまり開発者が多くないがゆえにそうした雰囲気になっているところもありそうだ。

そして、社長にいろいろな人を紹介してもらった。ふだん名前だけ聞いていたり、雑誌などで見ていた人たちと直接会話することができて、もうミーハー状態であった。小飼弾さん、宮川さん、竹迫さん、Yappoさん、Otsuneさん、Tokuhiromさん、栗原さんなどなど。でもみんな若い。

その他、社長のLTもすごく受けていたし、M&ERPの渡辺さんもわざわざ聞きに来てくれて、参加者の最高齢を更新してくれました。すごく楽しい1日でした。ありがとうございました。

主催したJPAの牧さん、岡部さん、エマーソン、檀上さん、中川さんたちご苦労さまでした。いや今日ももう一日ありましたね。
　

昨日9月15日は会社創立記念日で、3年前の2006年に起業したのでいよいよ4年目に入ったことになる。ものすごく早かったというのが素直な感想だ。

3年前は、ちょうどぼくが故あって会社を辞め、息子が大学院を卒業するという節目で二人で一気呵成に会社を興してしまった。ただ、ぼくらの意識ではそう冒険をしているとは思っていなく、ある意味自然な帰結であるような気もした。

当時は、1円でも株式会社ができるようになっていたし、ITでの起業は大きな設備投資がいるわけでもなく、従業員を雇う必要もなかったので、その点は気楽なところがあった。

ただ、一番の問題は何でお金をかせぐのかという根幹の課題はもちろん抱えていたわけで、そこは悲観、楽観が入り混じっていた。

いまから思えば甘かったと思うのだが、とりあえずホームページでも作って糊口をしのぐかという感じで、いくつかの案件を扱ったのだが、これがなかなかうまくいかない。結局、坂本武典さんという日本画家のホームページを作っただけに終わった。

それは、何がなんでもホームページをつくりたい、あるいは作ればものが売れるとかという幻想が崩れていった時期であったためかもしれない。そして、受託開発の仕事を入れるようになり、またぼくはITベンダーにコンサルとして職を得て、一応まあまあの収益をあげられるようになった。

しかしながら、それは自分たちのやりたいことをとりあえず置いておいてということでもあったわけで、“それでおもしろいのかい？”というささやきが聞こえてくる。

このささやきに抗しかね、今年の春ごろから、お金はともかく、まずは自分たちのやりたいことを能動的にやり、その結果としてお金がついてくればいいじゃんというふうに変えていった。

その結果、息子（社長）は、自作のWebサービスを送り出し、ぼくはコンサルをやめて、自作の開発方法論を磨くことを始めていった。そして、それを合体する形でこの8月から「Kailas」の開発に到り、いま骨格ができ上がったので、これをベースにビジネス展開も開始することにしている。

こうしてふらふらしながらもやっと主体的な形のプロジェクトが動きだし、先が少しずつですが見えてきました。何よりもやっていて楽しいことがいちばんです。

ただ、このことは二人だけでやっているとは決して思っていません。社長や僕の周りにいる人々の知恵と力をもらってこそ叶えられると思っています。それは、とりもなおさず「Kailas」の精神でありコンセプトなのです。

さて、いよいよ4期目である。
　

いま、若い子が経営しているベンチャー企業と一緒にビジネスをやることで検討を行っている。彼らのサービス提供プロセスを弊社が開発した「Kailas」というフレームワークを使ってシステム化すると同時に、新規サービスの創出や運用などを一緒になってやろうということにしている。

このあたりの話はまた改めて書きますが、ここで言いたいのは、彼らのビジネスに対する構えや思考プロセスのことである。先日も、ぼくとうちの社長（息子）と相手の社長および共同創業者の4人でブレインストーミングを行ったのですが、頭が柔らかいし、一方で押さえるべきところはきちんと押さえているのには感心した。

ぼく以外の3人は、同じ大学でほぼ歳が一緒なのでまだ２７，８歳なのだが、おそらく大きな会社に入って、上から指示されたことをやっているだけの同年輩の子たちとはだいぶ違うように思う。

よくそうは言っても、経験を積むことが大事だという。だから「10年は泥のように働け」というような経営者もいたりする。今や将来の希望もなくなりつつある大企業で泥のように働こうと思っている人は少ないのではないでしょうか。

これまでは、泥のように働くことが将来のポストや処遇を約束されていたが、もはやそんなことはないし、だいいちその泥のように働いたことは、その会社にとってだけ生かされる固有なものでスタンダードとはかけ離れてしまっていたりする。

ですから、別に学生からいきなり起業するのもぜんぜん問題ないと思っている。ただ、やみくもに会社を作ったってだめなことは当然で、それができるための基礎的な心構えとスキルが必要だ。そこを間違わないようにしないといけない。意欲と体力だけあっても無理だし、いい技術があるからだけでも難しい。

では、そうした基礎的な心構えとスキルって何なのだろうか。それは、無知の自覚というか、いつも何かを知ることに貪欲で、それを入れ込むひきだしをもっていることと、何かを生み出すための思考プロセスをからだで知っていることではないかと思う。

そうした知のストックとフローのスキルをバランスよく持っていれば、どんどん起業したらいいと思う。しかしながらそこで思うのは、こうしたことを学校で教えてくれているのだろうかということである。

上で言っていることは、知識を詰め込むだけではないというのはお分かりだと思う。少なくとも、受動的ではなく能動的だし、固定的ではなく機動的ですよね。そしていつも進化し成長していくイメージです。こうしたことは学校では教えてくれない。

しかしながら、中にはこのあたりをきちんと教えてくれるところもある。それが、いま付き合っている子たちが学んだところで、何を知ったらいいのか、それを知るためにあるいは生み出すためにどういうプロセスでやったらいいかを教えてもらっている。

今の大学でありがちなのは、ノーベル賞学者を育てるわけでもないのに、ただ単にアカデミックなことを教えているとか、産学協同といってビジネス実務やモノつくりを教えたりする。そうしたものは必要ではあるが、それよりも、世の中で生きていくために必要なコアコンピテンシーであるコンセプトの作り方とか思考プロセス、デザイン発想などをきちんと教えた方がいいと思うのである。
　

先日、マジカジャパンの羽生さんのところに行ったら、今度セミナーをやるのでそこで「Kailas」の紹介をしてくれということになった。羽生さんの会社は、以前はスターロジックという名前だったが、今年の７月に社名もマジカジャパンに変えて、業務フローに特化することになった。

マジカというのは、自分の仕事を紙のカードに書いて貼ったりしながら業務フローを作成するためのツールです。世の中に小難しく高価なソフトウエアはありますが、そうしたものを使えばちゃんと業務フローが書けるというわけではありません。その点、マジカは実践的で、業務を簡単に整理でき、見える化できるものです。

弊社ワディットで開発した「Kailas」は、業務フローが書ければ、それをできるだけそのままで実装し、動かしてしまおうというフレームワークですから、マジカで書いたものをベースに業務アプリケーションを構築するという技法を提示しようと思っています。

もし興味のある方がいらっしゃいましたら、ぜひ参加してみてください。福岡県大野城市の事例などもあっておもしろいですよ。

日時　　　　：2009年11月9日（月）　開場10:00　開演10:30　終了16:00
参加費　 　：５，０００円（税込）
定員　　　　：50名（先着順）
場所　　　　：すみだ産業会館　会議室４ （丸井錦糸町店と同じビルの9階です）
詳細　　　　：セミナー案内

昨日は、マジカジャパン主催の「マジカカンファレンス2009」に出席して、ソリューションセッションで「Kailas」のプレゼンをさせてもらいました。短い時間だったので十分説明し切れていませんが、デモができたのでよかったと思っています。

「マジカ」というのは、業務フローを簡単に書けるツールで、そこで書いた業務フローから、「Kilas」へ落し込むとうまくいくというような話をしました。意外と業務フローが書けなかったり、書けたとしてもそれをITに載せられないという問題があるのですが、そうした問題に対する回答の一つを提示したと思っています。

カンファレンスでは、バージョンアップしたマジカの紹介を羽生さんがして（午前中だったのでぼくは聞けなかったのが残念でしたが）、そのあと事例が紹介されていました。そのなかで注目は、福岡県大野城市の森永さんの「市役所の保健・福祉４１２業務を総『見える化』」という発表は面白かった。

まずは、お役所の仕事って多くの種類があって、特に福祉関係が多いという話に驚いて、そして、内側の実態が面白おかしく紹介されて大変参考になった。なんと数千枚のマジカを書いたというのには恐れ入る。

何よりも、大野城市でなぜマジカを使うようになったという話が面白い。終わったあとの懇親会で森永さんの上司の見城さんも言っていたのだが、ひとことでいうと簡単だったからだという。世の中に、業務フローを書くのに、難しい記法があったり、ITのことを知らないと書けないとかいったものが多い。その点マジカはシンプルで誰にでも書けるということ。

そうなんですね、重要なのはこの“シンプル”であるということです。そうでないと、継続的に使ってもらうことはできないのです。

懇親会では、久しぶりに羽生節が炸裂し（以前の羽生さんが復活しましたというかパワー倍増しています）、また見城さんの毒舌も冴えわたり、圧倒されてしまいました。しかし、みなの思いは熱くてぼくも改めてがんばろうと思ったのである。

カンファレンスの様子は、ITproの高橋さんが、早速記事にしてくれていますので読んでみてください。
　

ほめられるということはもう無条件にうれしいものだ。ぼくは単純だからすぐに天にも昇る気分になる。

マジカジャパンの羽生さんが昨日のブログで、先日行われた「マジカカンファレンス」について記事を書いていますが、そのなかで、「Kailas」について、これ以上ないというほどの讃辞をいただいた。“感動しました”という言葉にはほんとびっくりしました。

ワディットさんのKailasですが、これまで何度かお話は伺っていたものの実物を見るのは初めてだったんですが…萌えた燃えた！　これは凄い！　ソフトウェアの完成度としてはまだまだ課題はあるんでしょうけど、根底のフィロソフィが凄い！　プロセス設計ヲタは見逃せない一品です。感動しました。

もう３年近く前のユーザ目線のBPMというブログ記事で、お会いしたこともなかったのですが、これから注目したいのは羽生さんのマジカですと書いている。そして、その年の5月に予想だにしなかった本人にお会いすることになる。BPMオフ会のキックオフでの出会いであった。

それから、折にふれていろいろな議論をさせてもらっている。業務プロセス、業務フローについて深く考えている数少ない人のひとりです。

上から目線で、あるいは類型的に言っている人はいるのですが、いざ現場へおろせるかといった見方をすると途端に実践的でないのが露呈するケースが多くあります。

所詮、紙の上の話であったり、コンサルのデータベースから引っ張ったものとかいったきれいごとの論理なのである。羽生さんは、そうではない泥臭いかもしれないが地に足がついたことを言える人である。

まあ、ほめ殺し合いになってもいけないのですが(笑)、ちゃんと理解してくれているひとからほめられることがうれしいのです。羽生さんありがとうございました。
　

社長が書いた記事が載っている「Web+DB　Press」のVol５４がもうすぐ発売になります。23日か24日だと思います。

この雑誌もこれで9周年だそうで、よく続いています。その号の特集記事をほとんど一人で書いています。題して「Webサービス即日開発」です。

これまで数々のWebサービスを開発してサービスインしていますが、そのことについて企画・設計・開発・運用・チューニングまで全部開陳しています。

ぼくが言うのも何ですが、よく書けてると思いますし、何せ文章が読みやすいというのがすばらしい。是非読んでみてください。

これで、親子で記事を書いたことになる。多分こうしたことはめずらしいことだと思うが、”Webアプリケーション開発のための技術情報誌”にオヤジが書いたことが稀少なのである。

社長はこれから本を出す予定もあるとのこと、ライター稼業もいいのかもしれない。

WEB+DB PRESS Vol.54

posted with yusukebe.com::AmazonSearch on 2009.12.20

• WEB+DB PRESS編集部
• 大型本 / 技術評論社
• Amazon 売り上げランキング: 225

Amazon.co.jpで詳細を見る

ハッカーというと、サイバー攻撃をする人みたいに思う人もいるかもしれないが、そういう人はクラッカーと言って区別する。そうではなくて、スーパープログラマーのことである。ギークと言うこともある。

先日、そんな人のすごさを目の当たりにした。いま、「Kailas」のブラッシュアップで牧大輔さんというハッカーと一緒に仕事を始めた。牧さんは、Perl技術の普及を行うJPA（Japan Perl Association）という団体の代表理事をつとめ、またendeworksという自分の会社を経営している人でまだ若いのにしっかりしています。

それで、このあいだうちの社長と一緒に渋谷の牧さんの会社にお邪魔して、現状のKailasのコードを見てもらったので、そのレビューと今後の進め方みたいなことで打ち合わせを行ったのだが、びっくり仰天した。

何が驚いたかと言うと、こちらの仕様とか要望を口でしゃべっていると、すぐそのまま擬似コードを書いてしまうのだ。それも単にそのまま書いているのではなく、設計から構成から全部即座に頭の中でやってしまっているのである。ぼくは、これにはただただ茫然とするだけであった。

どうみても、口でしゃべるよりコードでしゃべる方が早いし正確のようなのである。とんでもないことを見てしまったようで、帰りに社長と飯を食いながら、知らず知らずにすごいすごいを連発していた。このすごさは、並みのプログラマーが10人かかれば勝てるなんて次元ではない。何人かかっても届かないのだ。だって、できるものが違うから比較できないのだ。

これを見ていると以前から言っているように、コアなコンポーネントはこうしたスーパーギークにさくさくっと作ってもらい、それを使ってシステムを組み上げるのが最も効率的で質の高いものができると確信した。

社長が話していたが、若いプログラマーはこういう人をみたらきっとみな憧れるだろうと思う。そうなんですね、無条件にかっこいいから、こういう人をロールモデルにして、自分を磨いたらいいのではないだろうか。これはこの世界だけではなくどんな世界でも通用することなのだが。

ちなみに、4月に「カジュアルPaerl」のイベントとして「Perl初心者向け勉強会」で牧さんがライブコーディングをするそうですから、ぼくが感動したことを味わえますよ。
　

社長（息子）の書いた記事が、「Web＋DB PRESS Vol.５６]に載っています。今回のテーマは、「Twitter時代の技術者コミュニケーション術」と題して８ページにわたったものです。

ぼくも日常的に社長と会話しているので、最近のネットでのコミュニケーションについてはすこしは知っているし、脇で見ていたりする。それで、感心するのは、コミュニケーションの基礎となるコミュニティの仲の良さというか、利他的なビヘイビアである。それは、裏返して言えば、そういう志や考え方を同じくする人たちだけで構成されているからとも言える。

だから、ここでのコミュニケーションは、当たり前のように企業内のものとは異質でである。つい、会社の中でも同じようやればコミュニケーションが活発になるとか、同じツールを使えばやれるじゃんとか言う人がいるが、そのよって立つ文化や気分が違うからなかなか難しいと思う。少なくとも昔風の既成会社ではとても無理だ。

ただ、全くだめだということではなく、少しでも彼らのよさを採り入れるようにしたらいいと思う。なぜなら、従来型の会社の文化・風土自体が今は見直されてきているわけで、「新しい酒は新しい皮袋に」である。

是非読んでみてください。

WEB+DB PRESS Vol.56

posted with yusukebe.com::AmazonSearch on 2010.4.24

• WEB+DB PRESS編集部
• 大型本 / 技術評論社
• Amazon 売り上げランキング: 271

Amazon.co.jpで詳細を見る

いま決算発表がピークを迎えているが、概して業績が最悪期を脱しているようである。新興国の需要が旺盛であることもプラスしているようである。例えば、家電なんかもアフリカなどでも売れているそうで結構なことなのだが、韓国製に日本製が押されているようでもある。

こういうビジネスは典型的な売りこみ型で使え使えといって商品を売りまくのが常道であろう。昔、ソニーの営業が世界をまたにかけてテープレコーダを売り歩いたとか、そんな話があるが、今はサムソンやLGの社員が同じことをしているのだろう。そのうち中国勢も出てくるにちがいない。

で、日本よ負けるなという話ではない。そうした売り方ってどうなのということで、たしかに成長する国では、生活が豊かになるための需要は旺盛だからどんどん買うのだろうが、何となくそれでいいのだろうかと思ってしまう。

それは気分の問題かもしれないが、必要ないものを売りつけてやしないかといったこととか、自分たちの生活の真似を強要しているのではないかということである。このことは、成熟してくると顕在化して売れなくなるわけだから、あまり何でもかなんでも売ってやれというのは感心しない。

翻って今の日本のような成熟社会では、売り込み型のビジネスはなかなか難しくなってきているようだ。要するに、飽和しているわけで、そうなるとどうしても欲しいものしか買わなくなる。せいぜい、安いなら買ってもいいということでユニクロとか100円ショップが支持されるのだ。

だから、今は売り込むのではなく、どうしても買いたくなるようなものやサービスを作って、買いたい人だけ買ってよというスタイルが増えるのではないでしょうか。典型的なのがiPadでしょう。販売前から予約が殺到するというのだから、営業なんていらない。

どうもここがポイントで、そのうちどんなものでも私の手にかかったらたちどころに売ってみせますという営業はいなくなるのではないだろうか。それはネットやIT技術のおかげで、商材の情報がだれでもかなり深く入手できるので自分でその評価でできるようになったことが大きい。ほしいものを自分で見つけて買うことがた易くなったのである。

弊社もいちおうビジネスをやっているし、商材もあり、しかも営業はいないので、そんな商売をしたいなと思うのだが、儲かることはないだろうな。

うちの社長が作った「Ｔwib」というTwitterの投稿で引用されたウェブサイトのURLを集めて人気順に並べるサービスが、携帯からも見えるようになりました。

昨日、ネイキッドテクノロジーがもっている、携帯電話向けTwitterアプリ「Twittie（ツイッティー）」が、5つのTwitter関連サービスと提携したことが、日経産業新聞やＣＮＥＴなどからプレス発表されました。その5つのサービスの一つが「ｔｗｉｂ」というわけです。他には、 「togetter」とか「Q&Aなう」といったものです。

今はけっこうＴｗｉｔｔｅｒ関連のサービスが熱いですね。あっという間にメジャーなプラットフォームになってしまいました。そんな段階なので、その活かし方や利用についてはこれから様々なものが出現しては消えていくことでしょう。

実は、「Ｔｗｉｂ」の特徴の一つにリアルタイム性というのがあって、瞬時に多くのＴｗｅｅｔｓを取ってくるので母数がかなりのものになっていることがあります。そうなると、この膨大なデータから必要なデータだけを抽出すれば、いろいろなところ、例えばマーケティングなどに利用できるという可能性があります。ですから、検索のアルゴリズムをうまく機能させればおもしろいことになります。

そんなことで、来月半ばくらいに検索サービスと一体となった商品をリリースすることにしています。このサービスは個人ではなく、（株）ワディットとして展開する予定なので、会社として初めてのWebサービスとなります。ですから、法人向けも意識するので重要なのは安定した運用なのです。まあ、いずれにしろ、お金を稼ぐのは大変ですね。
　　

来月から、標記のタイトルで勉強会をすることになりました。主催は日本BPM協会で、毎月1回、計6回開催し、ぼくがその勉強会のリーダを務めます。

BPM(Business Process Management)というのは、注目はされているみたいですが、いまいち普及していないというのが現状ではないでしょうか。その理由は、いろいろあるかと思いますが、まだユーザの方々の認知度というか、有効性の実感というか、ほんとうにビジネスの役に立つものなのかがつかみ切れていないことがあるように思います。

このBPMという考え方はいくらベンダーやSIerがいいものだと唱えてもユーザがその気にならないことには始まりません。従来のようにソフトウアやパッケージを導入してそれを使いましょうというわけにはいきません。ユーザ自身が自分たちの業務プロセスを設計できなくてはならないからです。

すなわち、ビジネスの要求をきちんとITにつなぐことが重要になってくるわけで、じゃあそれは誰がやることなのだとなってきます。それは、組織的にも立ち位置的にも適任なのが、企業の情報システム部門や情報子会社の人たちです。

こうした部門は、いままでは、業務のことは現業部門、ITのことはベンダーにとられ、単なるメッセンジャーボーイ的な役割かあるいは日常の保守運用部隊でしかなくて忸怩たる思いをしていた人もいたと思います。そうなのです。ついに活躍の場が与えられたのです。

ビジネスとITの橋渡しこそ情シス部門や情報子会社の存在感を発揮する絶好の機会なのです。そのためには、どうしたらいいのか、どんなスキルをつけたらいいのかを真剣に考えなくてはいけないのです。

ということで、頭の柔らかい35歳以下の若手エンジニアの方々を相手に大いに議論していこうと思っています。興味のある方はぜひ下記サイトから申し込んでみてください。

日本BPM協会「情シス若手勉強会申し込み」
　　

ちょうど1年前に公開した「Twib!」をリニューアルしました。「Twib!」というのは、「Twitterホットエントリー」というもので、Twitter上でつぶやかれたURLを集めて、人気順に並べるものです。それを今回新しい機能を追加して、ユーザインターフェースも手直してリリースしました。主な改善点は次のとおりです。

1. インターフェースデザイン刷新
2. バズワード機能の追加
3. 「今、影響力のあるユーザー」表示
4. 100以上のサービスのエンベッド(埋め込み表示)に対応
5. Twitterで特徴的な「写真」「動画」「ライブ」のカテゴリ分け
6. RSS出力の改善により自社ドメインの影響力を図れるように
7. クローラーの修正

詳しくは、「ゆーすけべー日記」をみてください。

最近は、Twitterの影響力が増しているので、このサービスがひょっとするといろいろなところで使われるかもしれない。ネット上でもけっこう反応があり、Yahooニュースでも書かれましたし、他でもとりあげてもらっています。もしよかったら使ってみてください。

http://japan.internet.com/busnews/20100827/4.html
http://journal.mycom.co.jp/news/2010/08/27/054/
http://www.oshiete-kun.net/archives/2010/08/twittertwib.html
　　

先日、「Publica」という名の合同会社の方たちと情報交換をした。合同会社というとちょっと聞きなれない名前ですが、2006年に施行された会社法で新しく設けられた会社形態です。「持分会社」という分類になるそうですが、米国などにあるLLCに似たような会社のようです。

会社の形態はともかく、この会社はある勉強会の仲間だった6人の若者が作った会社です。みな30歳前後で、まだみな本業を持ちながら参画していますが、その本業が非常にバラエティに富んでいて可能性を感じます。

なぜ、彼らとこうした出会いがあったのかというと、メンバーの中のひとりに昔から懇意にしているIT関係の人間がいて、彼からこんな会社を立ち上げたのだが、そこでやりたいことをWebアプリとして作ってくれないかという打診がwaditにあったというわけである。

そのやりたいことを聞いて、社長（息子）と話しているうちにこれはおもしろいかもしれないし、われわれもけっこう近いことを考えていたので大いに反応したのである。そのコンセプトが「潜在住民」という概念でその定義は、「（過去にその街に住むなどしており、）離れた後もその地域に感情的なつながりを保ちつづけている人々」ということである。詳しくは、Publicaのホームページをみてください。そうした潜在住民と地方、あるいは潜在住民同士を結びつけようという理念である。

まあ、ひとことで言うと社長もぼくもそのワーディングとビジョンに惚れたのである。最近とみに言われている地域活性化の起爆剤になるかもしれない。少なくとも可能性が感じられる。だからこそ、その実現方法（実はこれってビジネスモデルでもある）をよーく練る必要もあり、軽くやるのもいいがそれではもったいないような気がして、メンバーの人たちと社長とぼくとで情報交換の場を持ったというわけである。

その場では、様々な意見やアイディアがでてすごく楽しかったし、何かできそうな予感がしている。そこでも出ていましたが、地域の活性化というと従来はどうしてもどれだけ中央からお金を持ってこれるかというように交付金をあてにしたり、ご当地グルメを”新たに開発”したり、単なる観光名所案内をするだけだったりとかが主流のような気がする。

どうも、これからはそんな静的で単線的なものではなくて、動的で複線的な関係性、つまりヒト、モノ、カネ、情報が輻輳しつつ有機的につながっているという自律分散型ネットワークの世界を作ることだと思う。さて、どんなモデルが描けるのか楽しみである。
　　
[IT関連の記事を別のブログに移します]　＊この文章はしばらく掲載します。
IT関連の記事のエントリーを「wadit blog.」に移行しました。正確に言うとITでも仕事に関すること、つまり息子と一緒に創ったwaditという会社でやっていることに関係する記事は、基本的にはそちらに掲載されますので、そちらの方を見てください。もちろん、こちらの方も変わらず書き続けますので、今後とも両方のブログのご愛顧をよろしくお願いいたします。

来月の12月16日から4回にわたってぼくが世話人を務めます「続・情シス若手勉強会」（日本BPM協会主催）を開催します。ぜひ興味のある方は参加してください。この勉強会は“続“とあるように昨年に始めたもので今年は2回目となります。対象が情シス部門および情報子会社の35歳以下の若手エンジニアですので、このブログの読者で直接本人が対象となっていなくても、部下にそういった人がいる場合もあると思うので勉強のために送りだしてみてはいかがでしょうか。

この勉強会はただ一方的に知識を詰め込むような講義形式ではなく、みんなが自分の頭で考えて議論する場を提供することをします。若手のエンジニアは普段目先の業務に追われ、じっくりと考える時間とか、同じ年代の外部の人たちと接する機会も少ないと思います。そうした日常からちょっと抜け出てみてはいかがでしょうか。

テーマは、BPM協会主催ですのでもちろんBPMに関するものです。BPMそのものがどんなものであるかは「BPM入門セミナー」で学ぶことができますが、勉強会ではBPMとはこうだというより、あなたの考えるBPMはどんなものなのかということから始まって、BPMを実践することが大事であることを肌で感じてほしいと思っています。だからといって、押しつけるわけではありませんし、正解があるわけではありません。自分で納得できるやり方を模索してほしいのです。

そのために、今回は事例研究的なプログラムを用意しました。抽象的な話より具体的な例を題材にした方がよりわかりやすいからです。事例もかっこいいものというより身近にあるもので実際に戦略からビジネス要求、プロセス設計、実装、オペレーションまで行ったものですので実効性のある議論ができると期待しています。

ぜひ皆さんのご参加をお願いいたします。お申し込みはこちらから。

もうひとつは、12月22日にVCPC（バリューチェーンプロセス協議会）というところが主催するメンバーズミーティングで「非定型業務のIT化の事例と構築方法」と題して講演します。実際に今野製作所様で行ったシステム構築についてお話することになりました。ほとんどお金をかけずに手持ちの汎用ソフトで超短期間で作って、その結果売上をほぼ倍増させたという例を解説しますので是非聞きにきてください。

会員のかたでなくても有料ですが聴講できますので、こちらからお申し込みください。

このたび「ListTube」というiPhoneアプリをiTunesストアでリリースしました。社長（息子）が作ったもので、初めてのiPhoneアプリになります。Webサービスの「ListPod」という名で使ってもらっていたものをiPhone向けに開発し直したものです。

YouTube動画をiPhone内のプレイリストにしてシンプルなインターフェースで楽しむというのがコンセプトのアプリで簡単な使い方になっています。

・プレイリストを名前を付けて作る
・YouTube動画を探す
・ワンタップでプレイリストに追加
・プレイリスト内の動画を連続再生

iPhoneアプリというのはけっこう難しいという印象で、そんなに儲かるものではないと言われています。確かにそうなのですが、アップルの審査やチェックが厳しいのもリリースを難しくしている面もありますが、今回の経験でいろいろ聞いてみると逆にアップルのそうしたきっちりとしたやり方があるから、アプリの質を落とさない、あるいは操作感の統一といった標準化ができているとも言えます。

このあたりは、欧米流の良さだと思います。一方、ビジネス的な観点からは、アプリの値段をどうするかが悩むところですが、定価170円に設定していますが、いまのところクリスマスセールということで半額の85円にて販売中です。ただ、面白いところは個人の裁量だけで全部できるというところがあります。社長曰く、このビジネスの特徴は以下のようなことだそうだ。

・課金モデルがビジネスモデルとしてシンプル
・UIで勝負できる
・価格競争もできる
・スタンドアローンのアプリならば運用がいらない

さらに言えば、世界に発信できるのでグローバルに耐えられるアプリだとその潜在的なユーザー数は半端ではないということもある。だから、挑戦しがいのある個人ビジネスかもしれない。IPhoneユーザのみなさん、是非ダウンロードしてみてください。