mark-wada blog

前に、デブサミの感想で怒ったので、そのことに関連して続きを。業務システム開発というとまずはユーザから要件ヒアリングをして、それをどう実現するのかとか考えるわけです。

それできっとシステム屋さんは、「あいつらシステムのことをぜんぜんわかってないよな」とか、「コンピュータができることは決まっているのに無理なこと言うなよな」とか「それでいいと言っておきながらできてから変えるなよな」とかとかの嘆き節を奏でているような気がする。

ぬぬ、ちょっと待ってよ、誰が主役よということなのです。使ってもらえない、あるいは使う価値のないものを提供してもしょうがないのだ。

ユーザの要件をどうやって獲得するかというのが問題という。そのための要求開発だととか、ゴール分析だとか、そうそう要求工学っていうのもある。

ところが、そういった類のものをみるにつけ、何だか違うような気がするのはぼくだけだろうか。その感覚というのは、“おお、まえらユーザをバカにしていないか”ということである。

ユーザはシステムのことを知らないから（アホまでとは言わないけど）、オレたちがオマエらの仕事を分析して要件を引出してあげるよと言っているように感じる。ホントにそうだろうか？ぼくはそのスタンスが違うように思える。そもそもコンピュータシステムを作るわけではないのであって、業務システムを作るのである。

ちょっと脱線するが、みんなシステム開発って同じだと思っているけど、違っていて、いちばん分かりやすいのは、システムプロダクト（ソフトウエア）と業務アプリケーションは違うわけで、そこをちゃんと理解しておかないとシステム屋のおごりにつながる。

そもそもコンピュータシステムを作ることが最終目的でも何でもなくて、自分たちのビジネスを作りたいと思っているわけです。ビジネスそのものをITで表現したいのです。それって、ベンダーやSIerの人はわかっているのでしょうか。たぶんわかっていないのではないでしょうか。というより、わかったら自分たちのビジネスモデルが崩れるから思いたくないと言ったほうが正確かもしれません。

ですから、いままでのようなスタンスだとみなさんの利害関係をWin-Win化するモデルはないのです。ということは、モデルを変えていくしかないのであって、そのためにはシステムプロダクトを作る工程と業務アプリを作る工程を分けて考える必要があるというのがまず僕が主張する考え方です。
　

昨日の記事でシステム作りのモデルを変えていかなくてはいけないと言ったが、これは、何日か前に、はぶあきひろさんがブログで「黒船の大砲がソフト業界に構造改革を迫る：田中克己の針路IT：ITpro」についてコメントしていることにも関係していて、日経BPの田中克己さんの言う“ソフト産業も自動車のような産業構造に変革せよ”みたいな論調に、はぶさんがちょっとした違和感を覚えているが、それと全く同じかどうかはわからないがぼくも違和感がある。

自分でも以前からシステムプロダクトを作る工程と業務アプリを作る工程を分けて考える必要があると言っているように、「分業化と専門特化が工業化のキーポイント」と思っているので、「マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、 インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを構築する」というのもわかるのだけど、“自動車のようにはいかないよね”というのがぼくの考えである。

なぜって、できあがった業務システムと自動車とは同じですか？もしそうだとしたら、大企業がベンツに乗って中小企業は軽自動車に乗ればいいのですか？

違うよね。システムって自動車の使い方まで含めて考えなければいけない。トヨタが車の乗り方、使い方まで教えてくれるの？

だから、ソフト産業は独自のモデルが要るわけで、そこのところをしっかり考えないで、日本は自動車産業が強いからまねすればいいという話じゃない。乱暴な言い方をすると自動車産業なんてその業務プロセスは簡単でしょ。トヨタなんか４輪自動車しか作っていないんですよ。

ちょっと脱線したけれど、システム産業は導入する企業の複雑性をも呑み込んだシステム構築を行なうわけだから、すごく難しいモデルになるのだ。だからこれまでも何度も工業化とか言われてきたのに実現できていない。

いまこそ、課題を提示しあうのではなく具体的な回答を用意しなくてはいけない時代になった。
　

このブログではBPM（Business Process Management）とサッカーの話がよく出てきますが、大胆にもこれらをくっつけてみたらどうかという話である。

BPMという概念が出てきてシステムの構造化が進んだと思っているが、そのBPMはプロセスを表現していて、業務システムの骨格を形成している。フロントエンドのユーザインターフェースのところと、バックエンドの基幹システムとの間でそれらの橋渡しをしているミドルエンドシステムであると考えられる。

ということは、サッカーでいうミッドフィルダーと同じではないのかという仮説を立ててみた。そうなると、さしづめフロントのところがフォワードで基幹はディフェンダーになる。じゃあキーパーはどうなるんだ。監査とかコンプライアンスかもしれない。

これはあながち荒唐無稽な話ではなく、何となく似ているような気もしてくる。フォワードって決められたようにプレーしていたら点なんか取れないわけで、もちろん基本的なところはある決め事はあるんだけど最後は個人のアイディアだとかテクニックだったりで、相手守備陣を切り崩して得点する。だからかなり自由さや臨機応変さが要求される。

一方、ディフェンダーは、むしろ堅実で安全なプレーが要求される。バックスが守備でトリッキーなことをしたらえらいことになるから確実にやること、そして組織的な動きが大事になってくる。システムでは、基幹業務システムはまさにきちんとした正しい処理をしなくってはいけないのでディフェンダーの役割によく似ている。

さて、ミッドフィルダーである。最近のサッカーではこの中盤の重要性がますます増しているようだ。昔のサッカーはけっこう中盤を省略したゲーム運びも見られて、頑強なセンターフォワード、足の速いウィングめがけて、だいたいのところに球をけりこむ式サッカーがあった。また、こどものサッカー（こどもに限らず、レベルの低いおとなのサッカーも）にも中抜きが多い。

このミッドフィルダーの役目をBPNMが担っているように思える。フォワードであるフロント業務とディフェンダーである基幹業務をつないでいるのである。ミッドフィルダーはパス交換により自陣から敵陣に入り、フォワードにラストパスを送る。これは得点をあげるためのプロセスなのである。サッカーもこのプロセスがうまく形づくられたら得点を入れられる確率が高くなる。

ということは企業においてもプロセスをきれいに作ってスムーズなパス回しから新規顧客を獲得するとか、売上を拡大するとかをめざすべきなのだ。

おお、なんとうまくあてはまるのだ。というか、サッカーそのものがビジネスの縮図として見れないことはないということだと思う。言いかえれば、サッカーの監督は社長とか事業部長といった立場とも言える。

サッカーゲームで自分の好きなチームを作れるというのがあるが、ぼくは以前このゲームを社員教育に使ったらどうかと半分冗談で本気半分で提案したことがあるが、これをやらせると、攻撃的な子とか守備的な子とか、スター選手ばかりを集めようとするとかいろいろな意味で性格や考え方がでると思う。面白いと思いませんか。

話はちょっとそれてしまったが、このミッドレンジの重要性、プロセスの有効性がサッカーを見ているとよくわかるという話なのである。

この間のJリーグの開幕戦でレッズがマリノスに負けたのはこのことなのです。レッズがエジミウソン、高原という二枚看板で臨んだが、1点先取され、さらに永井と田中達也を投入し、さらに相手が10人になっても追いつけなかったのは、中盤でプロセスを形成できなかった、する選手がいなかったことに起因している。やみくもに昔のサッカー、ガキのサッカーをやったところで勝つことはできないのである。

ちゃんとプロセスをつくり、それをコントロールしましょうよというのが業務システムでもサッカーでも重要なのである。

金融商品取引法が2006年6月に成立し、2009年3月期の決算から、上場企業に内部統制報告書の提出・公認会計士によるチェックが義務付けられた。いわゆる内部統制、Ｊ-SOX法である。

しかし、この内部統制について、ひところの熱気がない。ＩＴ業界はちょっと前まではそれこそ第二のＹ２Ｋ（2000年問題）かと色めきたったが、今は静かになってしまった。

そうなんですね。何をしなくてはいけないかもはっきりしないし、すぐにＩＴ化するっていうことでもないし、要するに具体的にどうなるかがあいまいなのである。

結局各社様子見というのが多いのではないでしょうか。とりあえず最低限のことをやっておいて、何か指摘されたらそのときに直すというフィードバック的対応が賢いと気づいているようなのです。

ただ、それはそれでいいのであるが、そのあとに必ず実質的な内部統制の仕掛けが必要になってくる。そのとき、強制的なものではなく自発的で実効性のあるものが望まれるはずだ。基本は自分たちの業務プロセスが効率的で信頼性のあるものであり、会社のリソースが保全されていることである。

ですから。こうしたことを行なうには情報システムの対応も当然大事になってくるわけで、ぼくらがいまやっているBPMがそこをカバーすると考えている。

業務プロセスの可視化です。プロセスが見えていなければ統制も何もできない。皆さんすぐに承認ルートをちゃんとして、文書で記録してとかは言うのですが、プロセスをコントロールするという概念が乏しいような気がします。BPMの良さはそこのところです。業務の流れをモニタリングしてそれをコントロールする機能が有効なのである。

ではこの場合の制御対象は何でしょうか。ぼくは、「意思決定の質」と「処理時間」だと思っている。
　

一昨日、先月米国で開かれた「BPM Tech Show」について触れたが、岩田研究所の岩田アキラさんがそのレポートを書いているので、そのことについて考えてみた。

まず、最初に今回の参加で感じたこととしてつぎのことをあげている。

１．BPMNを採用するベンダの増加
それらのベンダは“コードレス”を基本コンセプトに謳う
２．BPM On-Demand（SaaS型BPMS）の登場
・Web2.0, Ajaxなどの最新技術を取り込み進化しつつある
・SaaS型BPMSは、まだ1年生であるが今後の成長が楽しみ
３．Ad-Hoc Process向けBPMSの登場
・プロセスが定まりにくいナレッジワーカー向けの課題解決型BPM+PMツールとは
４．BPMプロジェクトはユーザ主導型開発
・従来のSIerビジネスモデルは崩壊する
・ユーザ企業IS部門のエンパワーメントがBPM成功の鍵

自慢じゃないが、ここに書いてあることは全部もう1年以上も前からぼくが言っていること、やっていることだ。そういう意味ではやっと海外で認められたということなのだろうか。

いまぼくが提唱している「BPWeb2.0」の考え方は、ユーザ主導のノンコーディング開発をBPMSとWeb2.0の技術（フレームワーク）とサービスで行うというもので、全く上記の考え方そのものです。

BPMが今後のシステム開発に変革をもたらすと考えられるのは、そういうパラダイムシフトが起こせるかもしれないからなのです。それは、ここでも言っているようにIT業界そのものの構造変化をもたらす可能性さえ指摘できるのだ。

なぜって、ユーザ自身がSaaSで提供されるプラットフォームで、コードを書かずに自らの手で業務アプリケーションが構築できてしまうのだから。さてそうなったら、どこにSIerの入る余地があるのだ。

ただそうなると、問題となる、あるいは難しいところは技術だとかプラットフォームではなくなって、ビジネスプロセスそのものの設計になっていく。業務フローが書けたらあとは難しいことではなく、さくっと動くものができてしまうのである。

従って、今後は“きれいなプロセス”と“魅力的なプロセス”をデザインする力こそが、求められる重要なスキルとなる。

ところが、そういうと業務のプロでないとできないとか、業務経験がないとだめだとかの話になるが、ほんとにそうであろうか？もしそうだとしたら、工学的でもなんでもなくて属人的な職人芸になってしまう。そこを何とか工学的にとまではいかないにしても、エンジニアリングの世界に落とし込みたいと思っている。だいたいできてきたのでそのうち紹介したいと思っている。

ビジネスプロセスの設計という面では日本人は強いのではないでしょうか。昨日も言ったように、米国なんかは単純な効率化までのようだし、日本は美しいプロセスを作る技術をもっていると思うので、ぜひ日本のIT業界（いまの構造ではない）がBPMを梃子に強くなってほしいと願っている。
　

今週の土曜日に開かれる「第3回BPMオフ会」でしゃべります。この会もだんだん参加者も増えてきて、内容も充実してきているように思えます。

今回、ぼくは今やっているBPMのメソドロジーについて１時間ほどの時間をもらってしゃべります。簡単なデモもやる予定です。昨年の夏のBPM協会のプレゼンでは直前になって突然動かなくなってしまって冷や汗ものでしたが、今回は準備万端で臨みたいと思います。ぼくの後に「BPM入門」をプレゼンするtoitoiさんにも環境を貸してあげることになっているのでちゃんとしておこう。

時間が１時間でいつもより長くもらえるので多くのことがしゃべれるけど、あまりいろいろなことを入れると足りなくなることも考えられるので気をつけて的をしぼっておかないといけない。

まだ、定員がいっぱいになっていないようですので興味のあるかたはぜひ参加してください。何よりも、終わったあとの「ビールパーティみんなでしましょ」が盛り上がること必須ですから、それだけでも楽しいですよ。
　

SaaS（Software as a Service）という言葉が踊っている。これからのキラーシステムのような言われ方もし、官民こぞって注目である。ところが、みなさんわかっているのだろうか。この場合のソフトウエアって何のこと、サービスって何のこと、誰が誰に対してするの、その提供の方法は、とかとかちゃんと定義されていないまま話が進んでいるように思える。いつものことだが。

こうした議論のとき感じる違和感はいつもシステム発想が強いことである。だからすぐに、以前のASPとの違いはとか、セキュリティがどうだとかになる。大事なのは、ここでもビジネス視点、ユーザ目線で、そういう観点でみていくと違ったものになる。

まず、ビジネスを行う上でSaaSで供給を受けたいものって何があるのか。業務機能から業務サービス、はたまた業務プロセスまでのどれをなぜ外部から提供してもらうのかと考えることになるはずだ。簡単に言えば、QCDFが担保できるかどうかになる。

ここでSaaSだと全部がいいことずくめに言われるが、大事なのはQとFの問題のような気がする。CDはある程度定量的な評価ができるが、QとFは定量化できないので判断がむずかしい。そうなると、いい品質のものが手に入るのか、柔軟な対応が可能なのかということが重要である。

これは両者は関係していて、いい品質のものが手に入るが、それは“標準化された良さ”であるということなので、そこは自社の要求に対して必ずしも対応してくれるわけではないという非柔軟性を許容することがある。

ある意味、SaaSはオープンソース精神でできているわけで、なぜかというと、多数に支持される“いいもの”だけが生き残るのからである。こうして民主化されたソフトウエアやサービスは時として自社固有性と軋轢を生む。

そこをどう考えるかになるが、結局主にここの優位性の評価で採用するソフトウエアあるいはサービスを規定することになるだろう。

そこで向いているものを探してみるとひとつには、ぼくはプロフェッショナルサービスではないかと考えている。例えば、法務、特許、税務、与信といったようなものである。こういうものは、標準化されたものこそ価値があるわけで向いているのではないでしょうか。

一方、固有性の問題があるようなら、限られた世界で使ったらどうだろうか。SaaSの良さを限定的な範囲で生かすのである。ぼくはまずは社内向けに、続いてグループ会社向けに
という風に自分の家から親戚にさらに知り合いへというような段階的な展開をしたらいいと思う。

そして、それは別の効果が生むことができる。以前指摘した「シャドーIT」の問題への答である。たとえば「社内SaaS」であれば、職場単位で自然発生的なシステム化を許すのではなく、ソフトウエア、サービスを中央で管理して、そこから提供するのである。その管理されたソフトイウエア、サービスをいつ、どこで使うかは部門に任すのである。

なお、ぼくが提案している「BPWeb2.0」を使えば、ソフトウエア、サービスだけではなく開発プラットフォームも提供できる。すなわち、ユーザはブラウザだけで自分たちの業務プロセスを構築、稼動ができるが、そのリソースはすべてIT部門の管轄下に置かれるイメージとなる。

どうも、SalesForce.comがSaaSの典型例としてもてはやされているが、ぼくは個人的にはあまり評価していない。営業のところってけっこう会社の肝のところのような気がするから、そんな風に思っているのである。繰り返すが、SaaSはプロフェッショナルサービスから、そして社内から始めたらいいのではないでしょうか。
　

昨日、第3回BPMオフ会に行ってきました。前回と同じ勝どきのトリトンスクエアで行なわれました。今回は、プレゼンを頼まれていたので最初のセッションで1時間ほど「ユーザ目線の実践的BPM」というタイトルで発表しました。

その他には、toitoiさんの「BPM入門2回目」、Intalioのニコラスさんの「モデリングから実装」、tomsawadaさんの「クラウドコンピューティング」、そしてマイクロソフトの小高さんの「ADO.NET Data Service – RESTfulDao」の話と、かなり盛りだくさんの内容で充実の勉強会でした。

toitoiさんのプレゼンで使うデモシステムはわけがあってぼくのPCに入っていて、前回そのデモが動かなくなってしまい冷や汗をかいた。だから今回はリベンジだなんて言われていたので、すこし心配であったが若干のミスがあったけど何とか動いたの胸をなでおろした。

ぼくのプレゼンが受けたかどうかよくわかりませんが、ビジネス寄りの人たちには関心をもってもらえたのかなあと思っています。今回は初めて参加の人が半分ぐらいいましたが、ベンダーとかユーザ系のかたが増えた感じで、技術的なこと以外の話もいいんじゃないでしょうか。

徐々にBPMということの認知度もあがってきたように思える。だからこそ、BPMって何という議論をしっかりとしていかないと変な方向に行ってバスワードにもなりかねないので、こうした場でもいろいろな角度から議論していったらいいと思う。

夜がメインの「ビールパーティみんなでしよう」なので、のどを渇かして月島のもんじゃ焼きや向かう。第1回目ももんじゃ焼きでもうもんじゃ通になってしまった。ただ狭い！。

2月の号外BPMオフ会のときも狭かったが今回もそれに輪をかけたように狭い。そこでもんじゃを焼くから暑い。途中で窓を開けっぱなしにしたので幾分涼しくなったが、ビルが進む。ぼくらの席は、もっぱらなぜか関西人のn_shuyoさんが上手に焼いてくれた。隣の席は失敗もんじゃを食べていた。

この狭いことで困るのは席を移動していろいろなひとと話ができないことである。昨日はしかも2階と3階に分かれてしまい、なおさら移動が困難であまり多くの人と話すことができなかったのが残念であった。はぶさんともほとんど話せなかったし、しかもはぶさんは珍しく１次会だけで帰っちゃったのだ。

だから、終わって店の外に出てから何人かのひととご挨拶。そうしたら、間接的に知り合いだったという人が3人もいた。要するに同じ人を知っていたというわけである。世の中狭いなあといつも思う。

2次会はwkzkさん、toitoiさん、Uchidaさん、hanedaさんと軽く呑む。ここで盛り上がったのは、hanedaさんが何とタレントだったってこと。テレビ・映画あるいはCMなどに出演しているのだ。アデランスのCMに出ていたのを見せてくれた。

BPMとは関係なかったけど、こうしていろいろなひとと知り合いになり、会話をするということがこうしたオフ会のいいところでずっと続けてほしい。

毎度のことながら、幹事のwkzk、GoTHeDistanceさんお疲れ様でした。感謝！
　

いま、IPA（独立行政法人情報処理推進機構）のベンチャー支援事業に応募することを検討している。委託費用が上限1800万円だから、われわれのようなベンチャーにとってはおいしい話だ。以前からこうしたベンチャー支援事業はあって、昨年も応募したが採用されなかった。

ところが今年は、すこし様相が変わって支援金額も多くなって、しかも全額になっている。そして何よりもSaaS型の事業モデルが謳われている。昨年から経済産業省は何かにつけてSaaSと言っている。そして、SaaS活用基盤構築事業も別途やっていて、そちらの方は規模も支援金額も桁が違うのだが、今回のものは、その基盤と連携したソフトウエアの開発事業を援助しようというものである。

ずいぶんと肩入れしているが、SaaSの定義というのか、どういうものがSaaSに該当するのかというのがよくわからない面もある。いまだと、Webアプリケーションなら全部当てはまるともいえないことはないので、あまり厳密に考えずに応募したらいいのかもしれない。

先日の、BPM協会のコンポーネント部会でもSaaSをテーマにして議論をした。なぜSaaSがいいのか、どういうメリットを期待して採用するのか、どんな形態があるのか、ASPとSaaSとどこが違うのか、BPMはSaaSとどう関連するのかといったことが論点になる。

SaaSの利点はコストと品質が主たるところではないのかとなった。ここでコストといった場合、従来型のパッケージをカスタマイズして使うコスト、スクラッチからプログラミングするコストから見ると確かにコストは安くなるかもしれない。ただし、コストが安くて早くつくれる技法があれば当然別の話ですよね。

例えばBPMでそこのあたりの開発がコストをかけなくてもできたら、何もSaaSで窮屈なソフトを使わなくてもすむかもしれない。あるいは、アプリケーションではなく開発プラットフォームをSaaSで提供というバリエーションの方がよいかもしれない。

それと、やはり融通性という面では制約がありそうで、自社固有要件はそれが汎用的でない限り（汎用的でないから固有なのだが）機能追加はしてくれないわけで、どこまで我慢できるかになる。

従って、BPMのSaaS化というのをどんな形でやっていくのかによっては、こうした課題を克服できる可能性がある。コンポーネント研究会だから、当然BPMSの末端にコンポーネントをぶら下げてアプリケーションを組むことをベースに検討している。そのとき、あちら側（SaaS）に何をおくのかが議論になる。一番簡単な例は、コンポーネントをサービスとして置いて、内側にあるプロセスで呼び出すという形態がもっともわかりやすい。

さらに進んで内部プロセスも含めて外部サービス化するということも考えられるが、この場合の問題は、セキュリティと継続性である。すなわち、自社の秘密情報をあちら側に置いてだいじょうぶなのかということとSaaS業者が突然やーめたと言って撤退したらどうなるのかという問題である。

そう考えるとまだまだクリアにしなくてはいけない課題があるように思える。だから、ぼくはまずはプロフェッショナルサービスと社内SaaSから始めたらどうかと言っているのである。
　

再びSaaSの話。SaaSは文字通りソフトウエアをサービスとして提供し、それを使って業務システムを動かすことだが、そのソフトウエアを作る部分と運用する部分をアウトソーシングしているというふうに考えられないことはない。

企業の情報システムというのはもちろんそのライフサイクルがあって、設計・開発・運用・保守というサイクルがある。これを自社で全部やるところは少なくて、設計・開発のところはベンダーやSIerに丸投げするのもある意味アウトソーシングであるわけです。そして、運用・保守もハウジング、ホスティングときてアウトソーシングとなっているケースもある。

そう見ていくと、SaaSって別に特別なことではなく、情報システムのライフサイクルのほとんど全部をアウトソーシングしていることに他ならないのではないだろうか。

今までは、フルアウトソーシングというと、自社でハードウエアをもたないで運用をやってもらうというイメージだったけど、それはよく考えるとフルではないのだ。業務アプリケーションのところは自分たちで作ったものを運用してもらっていた。それらも入れて初めてフルアウトソーシングと言える。だから、SaaSでやっと真のフルアウトソーシングになったということなのかもしれない。

そう考えてみたのは、従来言われていたフルアウトソーシングはどうも成功したとは言いがたく、むしろ今は下火になっているように思えるからである。そんな中でまたさらに進んだフルアウトソーシングってありえるのかなあと素朴に思っているのである。

これまでのフルアウトソーシングが拡がらなかった理由は、エンドユーザの要求がアウトソーサーに届かなくなってしまったことで、ここでも“情報の非対称性によるインセンティブの歪み”がある。ユーザ要求を聞くことが決してアウトソーサーを利することにならない。そして最初はコストダウンとして始めたがだんだんとコストダウンのインセンティブがどこかに行ってしまう。

SaaSはこうしたことはだいじょうぶなのだろうか。いやSaaSはユーザ自身が必要なサービスを選んで使えばいいから、ベンダーの言いなりにはならないという意見が当然ある。ということは、SaaSを適切に活用するにはエンドユーザ部門が直接自分たちの必要なソフトウエアをもってきて使うことになる。

そうなると、情報システム部門のガバナンスが効かなくなり、シャドーITが蔓延しかねない。そうした矛盾を抱えていることをよく考えておく必要がある。やみくもにコストがかからない、すぐにやめられる（そんなに簡単に使いものにならないからやめますなんてできませんよ）、手間がかからないからといって飛びつくのはどうかと思うのである。

あくまで自分たちの手でやってみてこれはもう外に出してもいいという風にしないと、結局は高いものについたり、役に立たないものを使ったりというようになってしまうような気がする。そんな簡単に打ち出の小槌は手に入らないのだ。
　

今月の21日からSavvionのフリーダウンロードキャンペーンが始まった。7月21日までの3ヶ月間限定であるが、無料でモデラーが使えるのでぜひ試してみてはいかがでしょうか。日経ITProにも記事が出ていますので参考にしてください。

この無料のダウンロードは既に米国では行なっていて、日本でも大学向けにはやっていたのがやっと一般にも提供されるようになった。こうして、実際にツールに慣れてもらうのがBPMSの理解に役立つので、多くの人に使ってもらいたいと思っている。

まずは、BPMNに準拠したプロセス図の書き方を学ぶことから始まるが、大事なのはシンプルで一貫化したプロセスが描けるかである。

モデラーでは基本的にはアクティビティというコンポーネントを並べていき、分岐を発生させたり、管理アダプターをつないだりすることになるが、このアクティビティに何を持ってくるかがキーになる。

まあ、何はともあれ使ってみてください。

昨日、IBMの「IMPACT JAPAN SOA CONFERENCE」に行ってきた。まずはその盛況ぶりにびっくりした。場所は恵比寿ガーデンプレースにあるウェスティンホテル東京だったのだが、会場となった地下2階のフロアーは人で溢れていた。カンファレンスの後のカクテルパーティは部屋に入りきれずロビーみたいなところも開放していた。

参加者が千数百名ということで、午前中の基調講演は1ヶ所で行なわれたが、午後からの個別セッションでは５会場に別れた。ぼくは、ほとんどBPMに関するトラックで発表を聞いたが、その中でも言っていたが、SOA関連のセッションがいろいろあるなかで最も人気が高かったのがBPMがらみのものなのだそうだ。

こんなことは去年では考えられなかったわけで、やっと今年ブレークしていくような、そんな感じがした。SOAは浸透したので次はBPMだということなのでしょうか。

総括から先に言うと。さすがIBMということで、BPMを的確に理解して、その体系や製品群にしてもちゃんとしたものを提示していた。ただし、物足りなさもあるのでそれは後で記す。

元々は昨年の秋にIBM本体から発表されたSmartSOA（ちなみにぼくは1年前に作った体系にSmartBPMという名前をつけようとしたらすでにあったのでやめた経緯がある。SmartSOAはいいんですね）をベースにして、今年4月にラスベガスで開催された「IMPACT 2008 CONFERENCE」の日本でのSOA版といったところです。IBMのSOAに対する熱気が伝わってきます。

こうしたIBMの全社的な取り組みに比べて、NEC、富士通、日立、NTTデータなど日本の大手ベンダーの感度のなさは情けなくなる。もう間違いなくIBMやOracle、SAPに引き離される。Oracle 、SAPもまたBPMに対する力の入れようは加速している。

もう何年来もBPMの有効性を叫んできた身としてはうれしい限りである。これが一過性のバズワードになることはありえないので、正しく導入することを啓蒙したいと思っている。そういう意味ではIBMの今回のプレゼンは間違ってはいないものでさすがだと思った。

個々のセミナーについてのコメントは別途するかもしれませんが、いくつかのキーワードあるいはキーメッセージについて書いておく。

・“Sense＆Respond”（感知して応える）
・差別化は“オペレーション”の革新から
・ドキュメント中心処理／意思決定入力によるアウトプット
・プロセスの自動化／エンジニアリングの考え方
・高頻度反復型の業務改革
・KAI（Key Agility Indicator）
・ビジネスアナリスト（業務理解能力、可視化・分析能力）
・ビジネスプラットフォームを作る（SOUP：Service Oriented United Process）
・ヒューマン・タスクの実現／ビジネス･ルール外出し／パッケージ活用
・ワークフローからBPA(Business Process Automation)へ
・ビジネスの「産業化」＝オペレーションエクセレンス
・機能指向からプロセス指向に
・モデリングは、目的の明確化、規則を定める、利用ツールの特定が重要
・規則とは、命名規則、プロセス層の数（３～４）/深さ、プロセス粒度、1枚に書くタスク数（15以下）、イアウト、色の使い方、コメントの使い方、分岐条件の使い方
・企業IS部門の役割、責務が重くなる（ビジネスとITの仲介）
・SOAによる段階的システム導入

詳しくは、当カンファレンスのサイトに資料がそのうちアップされますのでそこを見てもらうとよいと思いますが、
このキーワードおよびキーメッセージを見て思うのは、これってぼくが1年以上前に言っていたことと同じじゃんということである。IBMの人はぼくのブログを読んでいるに違いない。（笑）

まあ、だからこそIBMを評価しているんだけれど、ただ今回で足りないことがある。発表しなかっただけかもしれないが、具体的なプロセス設計、開発の実践論ところが抜けているのだ。

いわば、トップダウンアプローチ色が強い、BPRの進化形というイメージで語っていることがいささかIBM的の香りがする。大上段に構えて、ビジネスを分析して、モニタリングして改善していくんだということがかなり強く出ている。

そんなことは先進的な大企業しかできないのであって、おおかたの企業は、まずはプロセスを見える化することで、それを実践的な話としてどうやっていくのかが最大の課題なのである。プロセスがきちんと作れていなのにモニターしてもしょうがないのだ。

だから、ユーザからの質問でもSOAは中小企業には適用できないのではないのかとか、近くの席に座っている人がいみじくも言ったのだが、どうせIBMのツールなんかは高くて使えないよなみたいな声が出てくるのだ。そこが、今回のなんか物足りなさが残ったところなのである。

でもいいのだ、そこがぼくの狙いどころである。巨象にはできないことをやるのだ。そう、“ラストワンマイルは俺のものだ“