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のツールなんかは高くて使えないよなみたいな声が出てくるのだ。そこが、今回のなんか物足りなさが残ったところなのである。

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

ちょっと前まで「業務プロセス設計作法」を連載していましたが、この設計法は従来の考え方とだいぶ違うと思っています。それは単にメソッドとしての違いというわけではなく、企業における人とITの関係が変化したということなのです。働き方が変わったのであり、ITの使い方が変わってくることを意味しています。

そこで今日からこのあたりについて少しずつ書いていこうと思います。今までもずいぶんとそれらしいことは書いてきましたが、繰り返しになる部分があるかもしれませんがもう一度おさらいしてみることにします。

それでは、人とITの関係がどう変わるのでしょうか？

結論的なことから先に言いますと、「ITに使われる」ことから「ITを使う」ことへの変化であると言うことができます。ええ、そんなことはすでにやられているから、今さら何を言うのという反論が聞こえてきそうですが、そうでしょうか。

企業の情報システムにおけるこれまでの主役はITであって、人間はITに使われていたのです。そのあたりを少し具体的にみていきます。

もともと企業情報システムの成り立ちは、「電子計算機」を使って会計処理や給与計算をすることであったと思います。そして、当時はその「電子計算機」は高価で、しかも使える端末の数も限られていたので一部の人たちだけが利用していました。

こういう状態では、人とITの関係はどうなっていたでしょうか。使い方としては、生産量だとか販売量や購買量などをコンピュータに向かってせっせと登録していました。コンピュータは決まった時間までに、決まったフォーマットで、決まった操作で打ち込むことを人間に命令していたわけです。

そして計算処理の手段がどんどんコンピュータに移っていくと、ますますコンピュータの言いなりに人間がデータ入力を行なっていくようになりました。

だから、一部の人は腹が立ったものだから、本来自分で打たなくてはいけないデータを事務の女の子にパスワードを教えて代りに打たしたのです。

この関係って今のようにERPや業務パッケージが導入されてもやっていることは昔とあまり変わっていないように見えます。相変わらず、データをメモして派遣の女の子に「このデータ、ERPに登録しておいてよ」と言っているのではないでしょうか。

この関係を逆転させることがこれからの企業情報システムの大きな課題であると思っています。

すなわち、ITが主役の企業情報システムを人が主役となれるかたちに変えることが求められているのです。それができてこそ、業務プロセスの可視化であったり、内部統制対応だったりするわけです。ITに使われたままでは、自分たちの意思を反映する仕組みとはなり得ないのである。自分たちの意のままに動くシステムこそビジネスに貢献できるものになるのです。

次回からもう少し掘り下げながら、どうやってそれを実現していくのかといった議論に持って行きたいと思います。
　

業務システムを考える場合、よくあるのはコンピュータでやれることから考えてしまうことです。パッケージを使っても、スクラッチで開発しても同じようにパッケージの機能がこうだからとか、プログラム的にはこうした方がいいよなといった思いが先にでてしまうことがあります。

前回にも言ったように人が主体的にITを使うようにならなければいけないと考えたとき、まずは自分たちの業務プロセスはどうなっているのか、どうしたらいいのか、自分たちの仕事は何をすることなのかといったことを優先して見ていくことが求められます。

これは当たり前のことですが、ついシステム化という風に考えてしまうと順番が逆になってしまいます。コンピュータシステムを作るのではなく、業務システムを作るのですから、やはり業務プロセスから入らなくてはいけません。

これまでは、どちらかというとシステムの枠組みにプロセスを合わせるかたちが多かったのではないでしょうか。特にERPなどは無理やりそれに合わせるというやり方になったりもします。そうではなくて、これからは自社のプロセスにシステムを合わせる方向に舵を切らないといけません。

なぜかというと、業務や仕事というのはあくまで人間が主体でやるものです。人間が判断し、処理し、決定し、改善していくものでしょう。こうしたことはコンピュータではできませんし、そこに自社の個性があるわけで、「企業は人なり」という意味はこういうことでもあると思います。

そう考えると、そこで働く人たちが気持ちよく、そして能力を最大に発揮して、さらにその人たちが成長していけるような仕事の仕組みを作ることがもっとも大事なことであると思うのです。そういうプロセスをまずつくることです。

そして、それらは人間系の業務とIT系の業務がほどよく調和されたものであるべきです。従って、まずはITは関係なく自社の業務プロセスを書き出すことです。そこで、ITに任すところはITに、そうでないところは人間に任せるというシステムの構築が必要なのです。

自分たちの意のままになる業務プロセスであり業務システムにしなくてはいけません。今までのように、実際に仕事に使っている人が、どうやって動いているのか、何を処理しているのか、“コンピュータに聞いてみなくてはわからない”というようなことをなくしていかなくてはいけません。

そうなれば、人がITを使うという風に主役の交替を実現できるのです。それでこそ、いつも言っているようにコントロール＆オペレーションが可能となります。
　

これはBPM（Business Process Management）のことである。昨日、日本BPM協会のコンポーネント部会に行く。これは毎月1回夕方開かれるのだが、もう昨日で16回目になる。

毎回、BPMに関するネタについてLightning talkがあり、それについてディスカッションするのですが、昨日はMさんから、SPQC（American Productivity and Quality Center）とSCOR（Supply-Chain Operations Reference-model）のモデルをマージした例について聞く。

これはトップダウン的なアプローチをとるときに使う業務プロセスのレファレンスモデルで、階層化されたフレームワークであるが、両者で得手不得手のところや、ラフなところや細かいところなど、違いがあるのでそれらの粒度を調整したという話でなるほどと感心させられた。こうした体系とかフレームワークは重要で「木を見て森を見ない」ことを避けるためにも必要なことであると思う。

それと、アメリカで行なわれた「BPM Tech Show」の報告。面白かったのは、AwardでBPMをうまく取り入れている企業や団体を世界中から選んでいるのだが、今回もさらに過去に遡っても日本の企業はどこも選ばれたことがないらしい。

また、アメリカのBPMというのは基本ボトムアップで、すなわち紙でやっている仕事をIT化したような事例が多いそうだ。少し意外だったが、アメリカの会社は結構ドキュメントが多いよなという話になった。しかしながら、そうしたボトムアップだけではなく、実行に際してガバナンスを効かしているという面ではトップダウンでもあるという話でこれも納得。

部会が終わったあといつものように数人で近くの居酒屋で呑む。そこで、わが国でもBPMに対するユーザやベンダーのスタンスがここへきてずいぶん変わったねという話をする。BPM協会へも相次いで日本IBMやSAP、マイクロソフトが入会するというし、先日のIBMカンファレンスでも注目度が高く盛況であったし、やっと認知されたのかなあと感じている。潮目が明らかに変わってきた。

ただ、気をつけなくてはいけないのが、みなさん本当にBPMを理解しているかなあということで、こうしたことはITではよくあるのだが、一過性のブームに終わってしまう、あるいはバズワードと化してしまわないかと心配するのである。

ですから大事なことは、「なぜBPMが登場したのか」、「今までのソフトウエアや方法論とどこが違うのか」、「どんないいことをもたらしてくれるのか」をしっかり議論して、腹に入れないことには、「なーんだ、今までと変わっていないじゃん」てなことになる。

しかしながら、ここを本当に理解している人が日本の中にどれだけいるのだろうか。ぼくにはほとんどいないのではないかとさえ思える。おそらく、従来の延長線上でものを考えているような人にとっては、単にプログラムで書いていたif文をワークフロー機能でやれるのでコードレスでいいねといういところで止まってしまうのではないだろうか。

BPMの登場は、「ITに使われている」ことから「ITを使いこなす」とういう変化をもたらすことが一番大きなことです。これについては今、このブログで「企業における人とIT」で記事を書いていますので参考にしてください。
　

さて前回、ITに任すところはITに、そうでないところは人間にということを言いましたが、ITに任せられないところはどこでしょうか。あるいは逆にITに任すものは何なのかです。コンピュータはあくまで論理演算の世界だから、セオリーがあるプロセスや機能はITに預けていけます。

ですから、非セオリー的なものがITではできないことになります。それは、人間が絡むところです。これは恣意的だし、人によってはやることや判断が変わってきます。すごくあいまいなところです。しかしながら、こうした人間的なプロセスは非常に多くの場面に登場してきます。ひとりの人間の仕事だけでなく、複数の人間が絡み合ったものまで無数の形態があります。

そして、これまではこの人間系の非定型的な業務処理はシステム範囲外に置かれていました。ここでITあるいはIT化といった場合、何を意味するかを少し考えてみます。

そこには二つの段階があるように思います。業務の処理そのものをITに任すことと人間が業務処理あるいは意思決定をするための支援情報や場の提供をITが行なうというものがあるように思います。

これまではどちらかというと前者の業務処理をITにやってもらうという意識が強かったように思います。後者の場合もないことはないのですが、どうも個人的な情報処理に対して存在していたように感じます。

例えば、メールやグループウエアというようなものがそれにあたると思いますが、あくまで個人の生産性であったわけで、基幹業務に近いところではなかなか利用されてはいませんでした。

ですから、基幹業務のところのIT化は、人間が業務処理あるいは意思決定をするための支援情報や場の提供という面では、あまりやられていませんでした。

しかし、トータルの生産性という意味ではコンピュータの処理時間は微々たるもので、そのコンピュータにデータを登録するための時間と出て生きた結果を解析するための時間が生産性を決めています。そこのコンピュータ（情報システム）の前後の業務のIT化が非常に重要になってくるわけです。

ところが、この領域はあいまいで不定形だからIT化が困難だったのです。そこでよーく考えてみると、この世界は決まった順序で情報が流れるとか、決まったルールどおりに動くとかではなく、情報があっち行ったりこっち行ったりしますし、決まったと思ったらまた戻るとか、根回しがいるとか、そんなプロセスですから、いわゆる逐次的なプロセスということではなく情報交換の広場、情報共有空間と呼んだ方がいいかもしれませんが、そうした広場なり空間をITで作ってやることが求められているのです。

こうした仕事の進め方は昔も今も基本は変わらないのであって、昔は電話やFAX、または机に集まっておしゃべり、黒板に絵や字を書いて議論して、そうしてものごとを決めていたのである。それが今やITを使って様々なことができるようになったのです。

例えば、SNS、ブログ、Wikiなどなどがそうです。そうなんです、昔のワイワイガヤガヤの世界を基幹業務システムの中にも組み入れることを提案しているのです。これらは既にWeb系の開発などでは当然のように採用された仕掛けなのであって、珍しいわけでははないので、いまの若い人たちのリテラシーでは軽く使いこなすことができると思うのです。
　

今回は、企業の組織の面から業務プロセスを見ていきます。

いまは組織がフラット化して、昔のように社長―副社長―担当役員―事業部長―部長―次長―課長―係長－班長なんていう大ピラミッド型ヒエラルキーはないと思いますが、それでも階層化はされているでしょう。

そうしたそれぞれの階層でプロセスのどこに責任を持たされているのでしょうか。また、そうした考え方で業務システム（業務パッケージ）はできているのでしょうか。

そこは多分はっきりしていなのではないでしょうか。

まず、企業情報システムの受益者はだれでしょうか。会社には、経営者、部門長、グループリーダ（課長）、担当者ぐらいにざっくりと分類できると思います。中小企業だと社長が部門長を兼ねたりしているでしょう。

社長というお仕事はそれほど業務システムを必要とはしません。逐一自社のビジネスの状況を見て経営するわけではありません。まずはそれぞれの事業の責任者に任せます。

そして、事業の責任者は自分の事業がスムーズに効率的に流れていることに責任を持ちます。しかしながら、作業局面での意思決定まではその下のグループリーダに任せることになります。担当者はグループの責任者が適切な意思決定ができるように情報を提供する責任があります。

こうして、現場の作業レベルから事業のマネジメントレベルまでそれぞれの段階で負っている責任の種類とその責任の所在が決まっています。ところが、そうしたことが判然としたシステム構造になっているでしょうか。確かに、承認権限を与えますからあたかもできているように思いますが、システムの構造としてそうなっているかは別の問題です。

上長が承認してデータ登録するというようなことは何となくわかると思いますが、グループリーダや事業部長が自分の責任となる業務プロセスを掌中に収めているでしょうか。

具体的に見ていくと、例えばある製品のサプライチェーン全体のプロセスが事業部長が見て、その中の出荷プロセスは、出荷業務グループの長が見ているというイメージになります。おそらく、そういう感覚ではなく、指定された入力を行なうこと、システムがアウトプットを出したことだけで見ているような気がします。

そこを変えていくには、グループリーダには意思決定のための情報共有の場、事業部長には業務プロセスのオペレーショナルなモニターの提供が必要になるのです。

そして、それぞれに特徴があって、作業レベルでは参加型の仕組みで絶えず情報が行き交いそこで生まれた集合知により意思決定の質とスピードが上がることです。業務プロセスでは人間系を排除したアクティビティを組み合わせることでドライで論理的なプロセスにすることです。

繰り返しますが、グループリーダは情報共有の場で意思決定の責任を負い、そこで決まったことをプロセスとして回し、そのプロセスが機能しているかどうかを部門長が責任を負うというかたちになります。これが、業務プロセスをオペレーションする姿です。
　

いま、ＩＴコーディネータ（ITC）協会の「BPMS研究会」という勉強会に参加しています。昨日は、ｍ＆ERPの渡辺和宣さんがSCORベースの業務プロセスを分解してアクティビティレベルの業務に落とし込んだ話や、トップダウンアプローチとかインタビューのやりかたなど、短時間で盛りだくさんの内容で充実の時間を過ごす。

この方法論で分解されたものは、かなりぼくのやっている書類ベースのコンポーネントに近いので、わりと簡単にコンバージョンできる。トップダウンアプローチとボトムアップアプローチの出会いである。

ところが、ITCには「プロセスガイドライン」というものがあって、経営戦略・IT戦略策定・IT資源調達・IT導入・ITサービス活用というフェーズに対してガイドラインが設定されている。しかしながら、これはあくまでガイドラインなので、ハウツーがないので精神論的にはわかるが、さてそれをどうやって実現するのか、実装へ落とし込むのかがないのだ。

だから結局、昨日は、このガイドラインと渡辺さんのトップダウンアプローチ、そしてぼくのボトムアップアプローチをどう整合させていくかということがこれからのテーマになるなあということで一致した。早速ITCの井上正和さんに参加してもらい検討することになった。井上さんはITCのなかでもトップクラスの人で問題意識も高く、非常によく勉強されている方なので、いい成果が出ると思っている。

そのあと、市ヶ谷の技術評論社に行く。Web+DB Pressの細谷編集長と面談。先日、スターロジックの羽生章洋さんから紹介を受けて、8月号に記事を書くことになり、その打ち合わせです。

Web+DB Pressの読者は主に開発に携わっている人たちなので、プログラミングなどの開発関連の記事が多いので、開発のところというか、実装のしかたみたいなことを書いた方がいいのかなあと思っていたら、細谷さんに、そういうことはあまり突っ込まないほうがいいのではないかと言われた。そこでぼくみたいな素人がスペシフィックなことを言っても、あっそうで終わり、いやばかにされるかもしれないのだなあとぼくが勝手に解釈した。

というわけで、だてに歳を食ってきたわけではないという線で、経験的なところを取り入れて、開発者の人たちからちょっと離れた業務プロセスのところ中心に書くことになった。さてどんなことになるのだろうか。8月号に出ますので乞うご期待。

ちょっと前に紹介した「不機嫌な職場」（講談社現代新書）という本では、いま職場がおかしくなっていて、要するに、関わらない、協力しないという関係になっていると書いてある。閉じた働き方、閉じた関係になり、タコツボ化がおきているという。

こうしたことは企業活動自体にも大きな影響を及ぼしていて、一つは生産性の低下である。協力しあえばスピーディに判断・行動できるのに、お互い押し付けあったり、知らんぷりして時間がかかってしまう。

もうひとつは品質の低下である。協力しあえないことで互いのミスが見落とされたり、問題を指摘しあわないといったことがおき、組織の自浄作用も失っていくという。

こうした状況を変えるためには、お互いがいつも知恵を出しあい、協力しあえる環境作りが大事である。
それと、これまでの日本の企業の特徴であったいい意味での「あいまいさ」が消えていっているような気がする。

これは、あうんの呼吸とか行間を読むとか察しろとかいうことでもあるが、良し悪しはもちろんあるのだが、あまりにも型にはまったことしかやらせない、あるいは決まったことしかやらないといった状況になってやしないだろうか。

一人一人の工夫や知恵で生産性や品質を上げてきたのがかつての日本の製造業だったはずだ。こうした個人やグループの裁量を信じるような環境も必要になるだろう。

ですから、これからは日本の職場に合わないような米国型成果主義をすて（まったく捨てろというわけではない。成果を正当に評価するこことは大事なことではある。）、みんなが協力し合って、それぞれが能力を発揮し、組織としても最大の力が出せる仕掛けが要るようになっている。

さて、こうした要請に対してITはどう対応しているのだろうか。ここのところがものすごく重要なところで、これまでのIT（ここでは業務システムのことをさす）は何も提供できていないと思う。むしろ、タコツボ化のシステムを作ってきたのではないだろうか。職場のみんなが協力し合い、個人の知恵を出し、質の高い仕事ができるような仕組みであっただろうか。

グループウエアやナレッジマネジメントの仕組みを作っているじゃないかと言う人がいると思うが、ここで言っているのは業務システムのことである。受注業務を営業の人、受注センターの人、製造の人、デリバリーの人などが、協力しあいながら、オーダーを受領するといったことである。

おそらくこうしたコラボレーション的な仕組みにはなっていないものがほとんどでしょう。基本的に、業務システムはシステムに担当がデータを登録して上長が承認して、その結果をまた違う部署の人がシステムを起動して見てから業務を行なうというスタイルではないだろうか。

これは、ITを意識しないで仕事を考えた場合、システムはその仕事の流れ、あるいは流し方と同じようになっているでしょうか。ひょっとしたら、ITがあるがために本来流れるべきフローとは違った動きをさせられているということもありえるのだ。

ここを変えていかなくてはいけない。どうするかというと、あいまいな処理を情報共有の場で実現するミクロワークフローと会社として決まったルールに則って回すマクロワークフローの組合わせの仕組みで、働いている人たちがしたい仕事の流れそのものを表現するものにするのです。

前回、ミクロワークフローとマクロワークフローの組み合わせがこれからの業務システムに必要になると書いた。これは実際にはミクロワークフローはCMS(Contents Management System)でマクロワークフローはBPMS(Business Process Manegement Suite) を使います。ではこの仕組みはどんないいことがあるのでしょうか。前回も触れているのでもう少し具体的な話をしたいと思います。

ずばり、業務の品質と時間（生産性）を向上させます。これらを少し詳しくみていきます。業務の品質とは一体どういうことでしょうか。

業務の品質というのは「意思決定のレベル」だと思っています。何も調査もせずに、あるいは誰にも相談しないで決めたものと、よく吟味して、いろいろな立場の人から意見をもらって決めた事はその品質は違ってきます。

従って、そうした参照情報へのアクセスやアドバスしてくれるメンバーが揃っている“場”が必要になるのです。こうした“場”はCMSで提供されます。ただし必ずしもCMSでなければいけないということではありません。要は、情報共有空間で集合知を活用して、そこで何かを決めて承認できるということであれば、SNSのようなものでもかまわいませんし、他のWebアプリケーションでもかまいません。

こうすると副次的効果としても、たとえば技術の継承みたいなことも可能になってきます。ノウハウを持った人がその場に参画し、若い人がやっている仕事をみて、必要に応じてアドバイスするという流れにすれば、そのコメントそのものがアーカイブされ、貴重な教育資料になるのです。またコンプライアンス上でも相互監視の仕事になりますから、不正なアクションはおこせなくなります。

一方、時間という面では、意思決定がスピーディになるということです。なぜかというと、情報共有の場では関連部署のメンバーやアドバイザー、承認者も最初からそこに参加することで、意思決定していく過程を見ているので、例えば承認伺いが来たときには素早く判断がつくというわけです。

これまでだと、紙で決済伺いが来て、それを見た上長はいきさつがわからないのでその経緯を説明しろとなる。言われた人間も自分が書いたものでないからまた部下にヒアリングするなんてことがおきていやしないだろうか。

また、BPMSではプロセスの進行をモニタリングしていますから、どこかのアクティビティで停滞が起きたりするとアラートを発するので、業務の進行を促してくれます。これも業務スピードを向上させてくれる仕掛けなのです。

おわかりのように仕事をオープンにしてそこにみんなを参加させて仕事をするということは、生産性と業務品質を向上させるのです。

昨日は第4回BPMオフ会。3つのセッションがあって、iknowの紹介、ＹＡWＬとOpen-WFEるの説明というラインアップ。いずれも外国人の方たちがプレゼン。

iknowは知る人ぞ知るSNS型無料英語学習サイトのこことで、楽しく英語が学べる仕掛けがほどこしてあって面白かった。

YAWLというのはYet Another Workflow Languageのことで、これをストックホルム大学の美しい女性教授Dr.Petia Wohedが解説してくれた。これはどうもワークフローパターンに基づいた言語のようなのだが、何となく雰囲気がわかるくらいで、全部英語ということもありさっぱりわからない。でも、WorkletとかDynamicWorkflowとか興味が湧くものがあったので少し勉強しようかと思った。

最後はJohnMettrauxさんによるRubyベースのオープンソースワークフローOpen-WFEるの紹介。この名前が「ruote」（るおてと読む）といってイタリア語で車という意味なのだそうだ。飲み会でOpenWFEというとOpenWifeと間違える人がいるのでそういう名前をつけたといって笑っていた。

そのときブランディングとしては、ちょっとひねった方がよくて、もしググッったとき車が出てきてしまうから、Googleのトップに出るような名前の方がいいんじゃないてなことを言った。まだ、コミッターが2～3人なのでこれからなのだが会社の仕事以外でこういうことをやっていること自体えらいと思ってしまう。

メインの飲み会は近くの居酒屋で前回よりかなり広い（笑）のでゆったりと会話を楽しむ。となりのとなりでは相変わらずの羽生節が聞こえる。始まるのが遅かったのですぐに帰る時間になってしまった。もう少し、Dr.Wohedと話したかったのだが、「wadaさん家に帰れなくなりますよ」という声で店をあとにする。遠いと終電を気にしなくてはいけないのでなんとならんかと思うのだが平日開催ではしょうがない。

ということで、今回もまた楽しいオフ会であった。wkzkさん、GoTheDistanceさん毎度のことながらご苦労様でした。
　

よくせっかくシステムを作ったのに利用してくれないとか、いいツールを与えたのに以前と同じやりかたでしかやらないとかいう声を聞きます。それはいつも情報リテラシーが低いとか意識が変わらなくて困るという話になります。

先日ある記事を読んだときもそんなことが書いてあったので紹介します。

6月11日に米国ボストンで開催された「Enterprise 2.0」イベントで、ブログやwiki、RSSフィードといったユーザー生成コンテンツツールを企業で利用する際には、中間管理職の存在が1つの大きな壁になっていると、パネリストらが論じ合った。 これは、懸念すべき事態といえる。一般に企業は、ビジネスプロセスを円滑に進める役割を中間管理職に求めている。彼らがブログやwikiを使用した情報発信に参加しなければ、仕事が滞ってしまうのではないだろうか。中間管理職が本当にそうしたツールを受け入れなかった場合、ワークグループのコラボレーションが散発的になったり、効果が薄れたりすると思われる。

これは米国の話だから、日本ではもっと大きな壁がありそうです。

ではどうしたらよいのだろうか。上の記事でもそうだが、ブログやWikiなどを対象としているが、こうした使い方では個人差も出るし、だいいちそれを使わなくても仕事ができることのように思えます。

今だって、電子メールより電話の方が早いし、ちゃんと伝わると思っている人がいるわけで、単なるコミュニケーション手段が今様なものを使えというのではインセンティブたり得ないのです。いくら嘆いても普及するのは難しい。

この解決策は、“それを使わないと仕事にならない”状況を作り出すことではないでしょうか。

この米国の例でもワークグループのコラボレーションと言っていますが、業務システムをオペレーションするのに使っていない、あるいは業務システムの機能に組み入れられていないのです。ですから、使わなくても支障がないやとなって使わない人も出てくるわけです。

ですから今提示しているようにフロントエンドにCMSをもってきて、その場のコラボレーションにより、ワークフローを回していくことにすれば、自ずとそのツールを使わないと業務の進行を妨げることになるので必然的に使わざるを得なくなります。

システムというのは自然と使わざるを得ないものになってこそ生きたものになると思っています。このような自律的な姿をどう実現させるのかが重要なポイントになるのです。
　

業務プロセスが化学プロセスと似ているという話をしたが、もう少し範囲を広げて考えてみることにします。前の話では連続プロセスのイメージがつよかったと思いますが、製造工場には上流の原料受け入れから、製造、保管、最下流の出荷まで各種の製造プロセスがあって、各工程のプロセスは連続プロセス、バッチプロセス、ディスクリートプロセスと混在した形でいりこんでいます。

連続プロセスは化学プロセスに多く、液やガスが一旦投入されると連続的に流れて製品が出てくるといったものです。バッチプロセスというのは、化学でいうと反応釜のようなものに原料を仕込んでそこで生成された製品をそこから抜き出して、また次の原料を仕込むようなものです。ディスクリートプロセスというのは半連続的に流れていくが機械的に搬送しながら流すようなものです。自動車の生産ラインもこれにあたります。

ですからわれわれ化学屋はこの自動車の組み立て型のプロセスがなかなかなじめないところがあります。プロセスの違いもそうですが、化学プロセスは基本的には組み立て型と違って展開型なのでそこもあります。化学ではレシピ（配合表）といいますが、組み立て系ではBOM（部品表）です。

もうひとつ、ベルトコンベアーのような流れ作業型のラインに対して、キャノンがやったようなセル生産方式というのもある。システム開発でいうとウオーターホールとアジャイルみたいなものです。

なぜこんなことを書いているかというと、生産プロセスのほうが業務プロセスよりもっといろいろなかたちがあったり、高度化されているから、そういうところを研究、学習し、活用することが必要であると思うからです。

さらに、そのシステム自体もはるかにすごいことをやっていて、例えば制御ステーションの考えなんかブレードサーバーと同じだし、冗長性なんかかなり高度な仕組みになっているし、EBSなんてプラント制御では最初からバス接続の方式である。また、データ活用なんかでも、データウエアハウスとかBIなんて言っているけど、プラント系ではリアルタイムデータを解析していたり、高度なシミュレーションをやったり、最適化制御もやられたりとすごい差があるように思える。だから、こうしたことをうまく転用することも考えた方がいいと思う。

でなぜ人とITなのかというと、生産プロセスはそれをきちんとコントロールしていることと、そのプロセス全体をオペレーションしている人がいるということなのです。ここのところが業務システムの弱いところではないかと思っているのです。
　

今あるユーザ系情報会社とフィージビリティスタディをやっている。その会社がASPで提供している販売あるいは財務会計システムの再構築について、ぼくのいまやり方が適用できるかどうかという検討である。

昨日はその大阪本社に行ってミーティングを行った。メールでそちらに行くのでよろしくと書いたら、みんな気合がはいっているのでそのつもりで来てみたいな返事が返ってきた。

議論の中心はBPM（Busness Process Management）を使うとどう変わるのか、どういういいことが待っているのか、どうやって開発したらいいのかといった基本的かつ根幹にかかわる議論になる。

すぐにツールの使い方や機能の話になることが多いが、ここの会社での議論は考え方だとかコンセプトから入って、そこをみんなで腹に入れようよというスタイルなので気に入っている。

BPMを検討するときの大事なところはここのところで、従来型の延長ではなく、新たな考え方で見ていかないとなかなか理解できない。

こうした詳細についてまた違った記事で紹介しますが、論点を少し書いてみると、今あるパッケージはスクラッチの手組み開発でスタートし、その後カスタマイズやアドオンをしているうちにスパゲッティ化してきたので、それを再構築するというプランである。
そこでは、あくまで今の延長でプログラムを整理し、部品化をして保守性を向上させるというやり方もあるし、まったく新たな基盤に開発コンセプトも変えてしまう、例えばBPMを採りいれるなどをするという選択肢がある。

そういう中でBPMの有効性を検証しているわけだが、BPMはプロセスオリエンテッドだから、もちろんプロセス設計から入る。そこでプロセスを書くのだが、いま動かしているシステムをベースにプロセスを書くと画面中心になるのだ。しかも、画面と画面をつなぐところに手作業のプロセスが入る。さらに、画面の中も実はプロセスになっていることがわかってくる。

いま、内部統制やら業務の可視化の必要性が謳われているが、このときプロセスを書けるかどうかがかなり重要な要素となる。そこで昨日は、ITを使おうが使うまいが、またシステムの作り方をどうするにしても、まずは業務プロセスを整理することをしませんかという提案を行なった。

BPMを実行する場合、一番の肝になるところであり難しいところは、「シンプルで一貫化されたきれいなプロセス」を書けるかどうかです。これができさえすれば、そしてその構造を崩さないかぎり、実現方法はどうやってもかまわないのである。

今度のディスカッションの論点は、まず一度プロセスを書いてみて、それをどう料理していくのかになる。面白くなってきたぞ。

昨日参加した人たちは皆熱心で、よく考えている方ばかりなのでついこっちも熱が入る。久しぶりの“ライブ感”を味わった。

終わって、近くの店で懇親会をしてもらう。そこでもITに限らずサッカーの話だとか大いに盛り上がる。

飲んだとき一緒だったY田クンからこのブログに自分のことを載せてよと脅されたので書かなきゃいけないのだが（笑）、Y田クンが何かいけるかもしれない感じがしたと言ってくれたときはうれしかった。

お互いに違った角度から見て、意見を言い合うという機会は非常に大事で、そこで違う見方をすぐ拒絶するのではなく、一旦受け入れて吟味してみるという姿勢が大事で、昨日はそういった議論ができたように思える。もちろんぼくの方もすごく勉強になった。

しかし、大阪は暑い。それに梅田の駅回りはわけがわからないし、エスカレータで左側に立っていたらどつかれるし、それよりも何よりも周りがみんな大阪弁だし、ああ疲れた。
　

有名なアマゾンの倉庫には、800万種類の本が保管されていて、注文が来るとその中から目的の本をアルバイトの子が即座に抜き出し配送していく。

そんなことができるためには、さぞきれいに整理されて棚に収まっていると誰でも思うでしょう。ところが、全く逆で整理しないでランダムに並べてあるだけなのです。これはあえてそうしているのです。要するに、最初に整理する手間（＝コスト）とピッキングの手間（＝コスト）のトレードオフなのである。アマゾンでは、はじめにきちんと整理して保管するコストの方が高くつくというのである。

実際にどうやっているのかというと、入荷した本は、ジャンルとか作者だとか無関係にならべていく。ただし、そのときバーコードで本の識別と棚番をマッチングさせるのである。そこで記憶したデータに基づき鉄砲のようなリーダが所定の本のありかをナビゲートしてくれるというものである。

なるほど、この逆転の発想はすごい。つい常識にとらわれて、モノは整理しておいておくものだ、そのほうが見つけるのも早く効率的だ、こんなことは当たり前だと思われている。そのためのハウツー本も売られている。ところが、逆のことをやるほうが簡単だし、効率的で低コスト化を実現する。

なんでもっと前からやればいいじゃんと言われるかも知れないが、そうは簡単なものではない。こういうことができる背景は、一番には高い機能を備えたデバイスのおかげだと思う。アマゾンでもバーコードリーダとピッキングするためのインテリジェントガンができたからこそ、こうした逆転発想の仕掛けができたのだ。

ここで、三つのことに思い至る。ひとつは、デバイスによってシステムが変わることがあるということだ。もう少し敷衍すると、新しい技術が業務システムもプロセスも変えうるということだ。ですから、技術はどんどん新しくなっているのに、エンタープライズ系の仕組みに技術オリエンテッドな考え方、なぜ出てこないのだろうかと思う。

もうひとつは、整理しないという発想である。システムを作るときって、データの正規化とか情報ディレクトリーなどきちんと整理しておこうという態度が普通である。しかし、ここもアマゾン倉庫的な発想ができないだろうか。もちろん大福帳型のデータ整理はあるのだが、抜き出すためにデータマートで整理している。

そういう意味ではGoogleの世界である。エンタープライズにも検索という概念がもっと入り込んできてもいいような気がする。本も情報だと考えると、アマゾン倉庫発想のビジネスインテリジェンス（BI）もありかなと考えている。
　
最後は、やはりシステムの限界ということでこのアマゾンの倉庫のような世界だと何でもITで自動化した方がいいように感じると思うが、ITは結局柔軟性に欠けるのであって、現実の世界はより”しなやかさ”が必要になるのだろう。この”しなやかさ”を発揮するのは人間が介在することで実現する。そうです、人間がITを使いこなしてこそ、トータルとして”しなやか”なシステムになるのです。
　

ずっと前にIBMのカンファレンスの記事を書いて、IBMのBPM／SOAへの取り組みを評価した。確かに全社的な動きとして今後注目のところだが、ビジネスモデルとの兼ね合いでどうなるのかといったことが興味深い。

どういうことかというと、このBPM／SOAというアーキテクチャあるいはトレンドはこれまでのビジネスモデルを大きく変えるドライビングフォースになりえるからだ。少なくとも、従来型のシステムインテグレーションは消えていくだろうし、あきらかにチープ革命とまで行かなくとも、低コスト開発に向かっているわけで、開発のところだけのビジネスは成立しなくなる。

だから、思うのである、BPM/SOAを進めれば進めるほど売上が落ちていくのである。ここの折り合いをどうつけていくかになると。単純には、他社のシェアーをとっていくか、新しい収益モデルを作ることになる。

IBMはこれまで、ハードウエアからソフトウエア、さらにサービスへの変貌、アウトソーシング化、オープンソース技術の取り込などその節目節目で戦略的に手を打って来ているので、いまの動向の中でそうした変革をどのように実現させていくのかが見ものである。

一方、国産のベンダーはどうやって立ち向かっていくのだろうか。少なくとも従来の延長ではどんどん先細りしていくのは目に見ているのだから、手をこまねいていては大変なことになる。

しかし、巨躯を素早く動かすのは大変なエネルギーが要る。だから、ひょっとすると身動きの早い、スピード感のある中小の会社がIBMの対抗軸として現れてくる可能性が十分あるような気がする。

巨象はシマウマは倒せるが蟻は踏みつぶせないのだ。

BPMのめざすところのひとつにプロセスの自動化というのがある。BPA(Business Process Automation)なんて言われかたもしている。さて自動化というのはどういうことなのだろうか。自動の対語は手動だから、手作業をITでやることが自動化なのだろうか。全自動洗濯機のように業務プロセスのStartからEndまで自動的に流すことなのだろうか。

まず、この自動化をしましょうということは現在は自動化できていないということで、それではどこがどう自動化できていないのかをみつけることが自動化を考える第一歩であろう。

企業情報システムやグループウエアなどの導入が多くの会社でなされているが、業務プロセスが自動化されているとは到底思えない。ひとつの目安は帳票があるかないかです。前にも書きましたが、帳票の使われ方として、まずは電子化されている業務と電子化されていない業務の橋渡しです。ですから、帳票があるうちは自動化できていないということです。はっきりいうと入力画面や検索画面と帳票や伝票を中心に業務システムを動かしているうちは無理です。

例えば、出金処理ひとつをとっても、よくやられるのはシステムにデータを入力し、そこから出金伝票を出し、押印して領収書を添付して上長の承認を得る。それが経理に行ってまたそこで承認して終わるみたいなことになる。その間は紙が回ってその流れにしたがって業務プロセスが回る。さて、これを自動化しようと思ったらどうしたらよいのでしょうか。

お気づきだと思いますが、情報を紙に乗せて動かすのではなく、情報はシステムで回さないといけないのです。業務フローに従って情報が遷移していくというようにしないと自動化はできません。紙が要るなら伝票にしても領収書にしてもスキャナーで読んで電子情報化して参照情報として一緒に回っていくということにするのです。

ただし、それだからといって全自動化ができるのかどうかという問題は残ります。それには、化学プラントなんかでもそうですが、センサーが信頼でき外乱を素早くキャッチできることと、変化を制御できるロジックができていること、最終的な安全弁があることなどである。

そう言われると業務プロセスの場合はちょっと難しそうですね。業務プロセスってかなり複雑で混沌としているし、何よりも相手がいることなので感知は大変そうですね。金融なんては金融工学なんて言葉もあるくらいだからできそうだが、一般的な業務では難しいようだ。

そうなるとまずは先ほど例にあげたように、画面や帳票主体ではなく、プロセスをまず作って、そのプロセスをITを使ってどう自動化するのかというアプローチでやるのが正解ではないでしょうか。

そのときたびたび言っているように自動化できるレベルとできないレベルがあるということで、BPMで描くフローは自動化できるのある。そこに乗せるまでのミクロワークフローは自動化というよりコラボレーションで実行せざるをえないのである。

だから、何でもBPMで自動化するというのには抵抗がある。化学プロセスでもどうしても御しきれないところは人間の手でやるのである。

ひがやすをｂlogで「プログラミングファースト開発の必要性」が書かれている。このひがさんのプログラミングファーストは以前あるセミナーでプレゼンを直接聞いたことがあるのでだいたいの考え方や内容も理解しているが、ぼくの感想はまだ中途半端のような気がする。まずはそのブログから。

プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。

プロトタイプ開発との違いは、最初に作ったものを捨てずに、本番で動かすものとして開発し続けること。アジャイルとの違いは、全工程をテレーション（筆者注：イテレーション？）でまわすのではなく、顧客と仕様をつめるところのみを何度も繰り返し仕様が固まるまで行なうこと。

これは、現在のような人月ビジネス化した開発における顧客とのコンフリクトを解消するための方策を考えた結果だ。ひがさんの必死さに頭が下がる思いだ。

ぼくは以前から２つの開発のジレンマということを言ってきている。すなわち、「結局アプリケーション仕様のほとんどが、ユーザの恣意でしか決まらない」ということ、もうひとつは、「実業務の様々な例外をコンピュータ上に乗せるか否か」です。ひがさんの方法論もここの対策だと思う。

これらジレンマを乗り越えるべくSIerやその開発者は日夜闘っているわけです。そして、それができないが故に最終局面での手戻り、頻繁な仕様変更などが起きています。こうした状態では一括請負のようなリスクはとれず、準委任契約のもと、かかった人月分の費用を請求することになるわけです。

この悪弊を打破すべくひがさんのような方が声高に叫んでいます。ほかの皆さんも現状に甘えることなく一緒に考えてほしいと思います。ただし、この問題は非常に重大かつ危険な問題をはらんでいます。自らの首を絞めることになるからです。

開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。

だから、今のままのほうがいいとどれだけの人が思っているのでしょうか。今までのビジネスモデルはいいわけありません。きつい言い方をすると、「情報の非対称性」を悪用してユーザをだましてきたのです。ユーザはだんだんと気がついてきています。

ぼくは、ユーザに長くいた経験でいうと、わけのわからないテクニカルタームで翻弄され、なぜこれだけのコストがかかるのか、あるいはかかったのか、分かるような説明ももらえず、仕方ないかといって経営トップから怒られながら費用を払った。

重要なことはこのユーザとベンダーとの間の「情報の非対称性」を是正していくことなのだ。その試みの一つが、ひがさんの言う「プログラミングファースト開発」である。お客さんに早い段階でシステムの出来上がりイメージを見せることができ、ユーザが得る開発プロジェクトに関する情報が格段に向上する。

だが、あえて言う。ひがさんの方法論ではまだ中途半端だ。

ぼくは、お客さんの前に出たらコードを直してはいけないと思う。その段階ではコードを書かずにコンポーネントの並べ替え、組合せでアプリケーションを表現できるようにすべきだと思う。

そうなれば、システム寄りの会話ではなくビジネス寄りの会話へとシフトできるはずだ。お客さんとはどういう業務プロセスにしたいのか、どういう業務機能を付帯させるのかといった議論になる。だから最初から請負契約ができる可能性がある。

そのための必要条件は、業務機能のコンポーネント化と業務プロセスのモデリングとデプロイである。ひがさんは確か以前からコードレスとうことを言っていて、コードの再利用やモジュール化といったプログラミングの効率化という観点だったように思います。

その考え方を業務プロセスや業務機能の領域まで拡げてほしいのです。業務をヒアリングしていちいちコーディングするのではなく、業務コンポーネントを予めコードも含めて用意しておき、それをつなぎ合わせて業務プロセスを構築するというふうにすることである。

そして、前述した二つのジレンマはそれを乗り越えるのではなく、受容してしまったらどうか。ユーザなんてわがままなものだ、例外業務はあって当たり前だと思うことである。そうしたら、わがままができる、例外を吸収できる場を提供してあげることなのだ。

いまかなり理想論的なことを言っているが、この件はみなさんおおいに議論して欲しいと思う。このブログでも再三言ってきているように、欧米からパッケージやソフトウエアを買ってきて、人月作業は中国・インドにもっていくなんていうモデルはくやしいと思いませんか。

ぜひ日本発の方法論を作って海外にもっていってもらいたのです。若いヤツがやらないんだったら、オジサンたちがやるぞ。
　

昨日、おとといと猛暑の中、東京まで出かける。そこは気楽な身なので半袖シャツ一枚で行く。勤め人のときは、真夏でもきちんと長袖シャツに上着、ネクタイ着用で過ごしたものであるが、さすがにそのスタイルはきついのでラフな姿に切り替えたのだ。

しかし、これがちと失敗だったのである。まずは駅まではもちろん暑いからいいのだが、電車に乗るとこれがけっこう冷えているのだ。横須賀線は昔からよく冷えていたが今もあまり変わらない。電車を降りるとまた暑い。それで会議が始まる。ところが2日ともなぜかエアコンの空気の出口のすぐ下に座ってしまった。こりゃ寒い。冷たいお茶が出るから内から外から冷やされる。

このアップダウンが歳とったからだにきくのである。マラソンではないが、スピードの上げ下げでスタミナを失うのと同じように温度の上げ下げで体力を弱らせる。今度からは、長袖のシャツかジャケットを持っていくことにする。

さて、この二日間はすごく面白いことになりそうな気配である。最初の日は、ぼくと同じくらいの歳の人ばかりで、これからお国を巻き込んで革命を起こそうという話（なんせ全共闘・安保世代だから元気がいい）。

昨日はうって変わって３０代の若い経営者とビジネスプロセスの話。ブランディング戦略を中心にした事業を起こした元雑誌記者の子なのだが、いまや単なるブランディングのことだけではなく、そのベースにあるべきビジネスプロセスをどうするかという課題がどんどん出てくるとのこと。

だからこういう局面でも旧来型のモデルが通用しなくなってきている。ITを前面に押し出した営業は通用しないことや、社内IS部門の弱体化がエンドユーザの不満のぶつけ先をこうした若い子に持っていったりしている実態がよくわかった。

この年齢のアップダウンは体力的な影響はないが、かなりインパクトがあった。しかし、これは会議室のクーラーとはわけが違って心地よいものである。

経験と情熱をもった年寄りと意欲とセンスを持った若者のコラボレーションが日本のＩＴを変えていく。
　

　いま、BPMが話題になっている。雑誌でも取り上げる回数や誌面が増えてきて、BPMを冠したセミナーも多く開催されているように思える。

ところがその中味は一律ではなく、百花繚乱とまではいかなくとも様々な切り口の提示がなされている。
もちろん、それぞれ特徴があるのだから、違いがあってもいいのだが、基本的なところで外れていたりするものもあるような気がする。

あまり変な方向に行ってしまうとバズワードにもなりかねないので、早めにゆずれないコアのコンセプト、技術、アーキテクチャ、技法などを整理しておいたほうがいいと思う。

このBPMは、事業運営からシステム開発あるいは開発後の運用まで含めた広範囲の概念である。それゆえ、その一部をもってしてBPMと言ってもらっても困る。まずはこの全体感がきちんと背景にあって語っている人が少ないことを指摘したい。

広範囲であるという意味は、ビジネスとITという昔から言い古されたフレーズかもしれないが、今度こそ本当に融合されるべきものだという意識がもてるかということでもある。

常々思うのだが、企業でITが導入されて以来、人間とITの位置関係は多少の変化はあったにしろ基本的に変わっていないのではないかと思っている。すなわち、ITが主で人間はそのITに使われていることです。

そこが今変わろうとしている。人間主体のシステムに変貌させるときが来たのである。そこを理解しないと意味がない。それができないと、単に業務フロー図作成ツール、もしくはIF文を書かなくて済むツールで終わってしまうのである。

そこで、BPMを正しく理解し、正しい導入の仕方を議論するために、なぜ変わろうとしているのか？どう変えたいのか？誰が望んでいるのか？どうしてできるのか？といったことを考えていきたいと思う。

前回、人間とITの位置関係が変わろうとしていると書いた。そのことについてもう少し言及する。まずこれまで変わってこなかったのだろうかという疑問がわく。

最初はホスト－端末の関係だったけど、クライアント－サーバー型になってITは奉仕する側になったじゃないかという人もいるかもしれません。でも本質的な変化だったのでしょうか。それは単にシステム的な役割分担が変わっただけで、人間とITの関係は変わってないのではないでしょうか。

ITの最初の登場は大きな電子計算機であり、そのときは順番待ちで使っていた。そういう状況ではコンピュータを使わせてもらっているという感覚でしょうか。そしてPCが登場して、パーソナル業務では自由に使えるようになりましたが、企業システムでは端末がPCに置き換わっただけでした。

そして前述したようにオープンシステム化しても基本となる位置関係は変わらないままだったように思います。すなわち、コンピュータシステムに命令されているかのように、決まったデータを決まったやり方で決まった時間までに打ち込むことであったのです。

しかし、よーく考えてみてください。会社の仕事というのは、組織としてやるべきことをその一員である個人が処理していくことです。それは自分たちが決めたルールに従って、自分たちのペースでやるべきもののはずです。そこに必要ならITを道具として使うというスタンスになるべきです。

そういう位置関係がこれから求められるのではないでしょうか。実はこうしたことはウエブの世界ではとうにやられていることなのです。ウエブの世界の主役は個人です。個人は好きなようにアクセスし、好きなサービスを選んで使います。そして、面白くなかったら消えていきます。ここでは徹底した顧客志向です。企業情報システムの顧客は従業員であるという意識はもっとあってもいいと思うのですがいかがでしょうか。

また機能的なことで言うと、ネットやウエブの最大の特徴はなんでしょう。別な言い方をすると、従来のコンピュータシステムと違う点はどこかということです。それは、「双方向コミュニケーション」、「オンデマンド」、「ハイパーリンク」ではないかと思っています。こうした機能の登場により、人間とITの関係もずいぶんと変わったものになりました。

逆の表現だと、「一方通行コミュニケーション」、「オンサプライ」、「ノンリンク」といったところでしょうか。これって、今の企業システムそのものでしょう。

ウエブでネットで普通にやっていることを企業システムに持ちこむだけでいいのです。だから、すごく難しい話というわけでは決してありませんが、最大の壁は既成概念にとらわれたシステム屋さんと今の仕事のやり方を変えたくないエンドユーザではないでしょうか。
　

人間が主役になって自分の導線あるいは組織のルールに従って仕事を進めるとなるとプロセス中心に考えざるを得ないことになります。

これまでにもデータ中心だとかオブジェクト指向といったやり方が提示されてきていますが、どうしてもコンピュータでハンドリングするデータはとか、プログラムモジュールに落とし込むためのオブジェクトはとかだったりして、いまいち現実のビジネスプロセスの表現という意味では物足りなかったのではないでしょうか。

いやちゃんとやればできるという声がDOA+コンソーシアムあたりから聞こえてきそうですが、少なくともユーザが見てすぐにわかるようなものになっていないのではないでしょうか。

やはり、いまユーザが実際に回しているプロセスの実相をそのまま表現し、それをあまり変えずに実装していくというのが必要なのだと思っています。ここの意識改革というか、発想の転換が大事になります。

少し話しは変わりますが、前回ウエブの世界と対比しましたが、いやあ、企業システムはクリティカルだから、ネットのシステムなんかと一緒にするなというようなお叱りをうけそうですが、そうですかねえ。これも考え方を改めたほうがいいのではないでしょうか。いまやウエブサービスの方がクリティカルであるし、パフォーマンスやキャパシティ要求も企業なんかとくらべると格段に厳しいように思う。

誤解されているかもしれないので整理をする。たぶん反論として、銀行のATMやそれこそ先日トラブルがあった東証のシステム、あるいはJRの発券システム、コンビニのPOS、宅急便のトラッキングシステムのようなものがあるという指摘があるかもしれない。いま議論しているのはこうしたその会社の本当の根幹をなすシステムは対象外です。

これらは、製造業でいったら製造設備であったり、生産ラインであったりするものだから、この議論でいっている企業情報システムとは一線を画しているので注意してください。

ですから、生産、出荷、販売、購買、会計、人事といった一般的な企業システムにウエブで行われていることを適用するのはそんなに難しいことではないと思いますがいかがでしょうか。

話は戻ると、ここではプロセス中心に考えることの重要性を言っているのです。顧客があるいは社員やマネジメントが一番わかりやすい考え方だからです。人が使いやすい、動かしやすいプロセスをつくり、コントロール＆オペレーションするというのがめざすところになります。

BPMへの期待は何かを考える前に、いまの仕組みで何が問題なのかということを考えていることにする。こういうときはだいたい使い手側と作り手側の両面から考えることが必要だ。ニーズの問題とシーズの問題である。それぞれにもつ問題点もあるし、相互の関係における問題も存在する。

ここで一番の問題は相互の関係性にあるような気がする。それはこのブログでも何回か取り上げている「情報の非対称性によるインセンティブの歪み」である。ユーザはITのことがよくわかっていない、ベンダーはユーザの業務のことがよくわかっていない、しかし作るのはコンピュータシステムであることからくるものである。

だからできたものの情報はベンダー側に偏ってしまう。いいですかここが非常に重要なところですが、“コンピュータシステム”を作るからこういうことが起きるのです。“動く業務プロセス”を作ってくれればいいのです。そうすれば、この情報の非対称性は解消されるのです。

こうした仕組みを提供してくれるのがBPMなのかもしれないと期待しているのです。喩えは少し無理があるかもしれないが、テレビゲームにある自分で好きなようにチームを作り選手を動かせるサッカーゲームのようなものがほしいのです。決してふざけて言っているわけではなく、おおかたの業務は結局こういうことではないのかと思う。

少々脱線したが、今の問題は事業を預かるマネジメントがその業務プロセスがどんな風にできているかがわかっていないことにある。そんな状態だから、いま何が起こって、これから何が起こりそうなのか、過去に何があったのか、という現在、未来、過去の事業の状況をつかめないでいるから不正や不祥事がおこるのである。

冒頭に設定したユーザおよびベンダーの個別の期待はどうなのだろうか。ユーザの期待は上述の説明で事足りそうだが、問題はベンダーサイドの期待である。ベンダーの最大の関心事が当然こういうことをやって儲かるのかということである。ここが非常に難しいところで、仕組みや仕掛けが革新的であれば、ビジネスモデルや収益モデルも従来とは違ってくるのは言うまでもない。

ここでは人月ビジネスの終焉だとかはあまり叫ばないが、ひとつだけ言っておきたいのは、IT業界ってこういうことが過去にもありましたよね。古くはハードウエア売りで添え物としてのソフトウエアからソフトウエア主体のビジネスへの転換、さらにサービスウやソリューションビジネスへの移行など、その都度対応してきたわけです。ですから、これからもきっとできると思いますがプレーヤーが変わっているかもしれませんね。
　

前々回にビジネスモデルが変わるというようなことを言ったが、おそらく今のようなソリューションがもつターゲット領域だけのビジネスを想定すると、かなりの生産性向上でコストも下がるのでパイが縮少して現状のベンダー数を食わせることができなくなるはずだ。それ以外でもオープンソースの使用割合の増加などチープ革命もあるので収益モデルが立ちにくくなる。

だからといって、嘆くなと言いたいのだ。実は、企業ではIT化の度合いはまだまだ低いのである。中堅・中小企業だけではなく、大企業においてもしかりである。ということは、いままでIT化されていない領域に拡大することによって収益を確保できる可能性は十分あると考えている。もちろん、そういうふうに事業構造を変えた企業が生き残っていくということは言うまでもない。

現状の会社業務をITを意識しないで書き出してみてください。いかに手作業が多いかに気がつくはずです。手作業でデータを固めて、それをシステムに投入するとか、いわゆる、調整、確認、連絡などの業務が多いことわかります。

しかも、そういうところで重要な意思決定をしていたり、手間がかかっていたりします。そこをIT化するのです。いっぱいありますよ。これまでのITはそれらを拾ってきていなかったのです。ですから、ここをＩＴ化していけばまだまだ仕事はあるのです。それによりユーザにとってもウエブの顧客接点からバックヤードまでがつながるメリットがあります。
　
おそらく、この空白地帯を埋めるのにBPMが威力を発揮すると考えている。バックヤードの仕組みでは重たいし、ウエブでは業務のところが弱いということだから、そこの橋渡しをBPMでやるということなのだ。さて、それを誰がやるのか。
　

BPMにおいて従来との違いでかなり大きなところは、BPMは事業戦略、IT戦略を実現するエンジンであることです。そんなことはすでに、ERPなんかで実現しているじゃないかという反論がきそうですが、ほうとうにできているでしょうか。

“戦略の実行”ということを考えてみて下さい。単にシステムを作ることではないということですよね。システム開発だけで戦略が実行できたとは思わないでしょう。意外とみなさんシステムを作りましたで終わってやしませんか。

そうなんですね、構築したシステムを日々動かしてこそできるのです。業務プロセスのオペレーションということです。目標との乖離を修正するためにオペレーションを変えるとか、BSCで設置したKPIを監視して所定値に収めるとかをすることが必要になってきます。

これまででも、こうしたことができるという人もいましたが、かなり難しかったのではないでしょうか。なぜなら、コントロールが効くシステムになっていないのにできませんよね。せいぜい死体解剖的に起こったことを解析することぐらいではなかったのではないでしょうか。

この概念こそがBPMが大きなインパクトを与えるものです。ですから、このことのために業務プロセスを可視化するのであり、責任をもっている人の掌中にプロセスをつかませてあげることなのです。

経営とITという言われ方で、戦略をITに落としこんでいくのだと意気込んでやりますが、つながっていたでしょうか。必要機能をアドオン、カスタマイズすることには熱心ですが、戦略は最初にえらいコンサルが入ってSWOTやBSCなどいろいろな手法を使って作るのだが、システムの開発が進むとそんなものはどこかに吹っ飛んでしまい、ただ動けばいいやというものができあがる。

繰り返しますが、これが従来のERPではなしえなかったことです。もちろんワークフローではいうまでもなくできっこありません。
　

BPMというとプロセスだけのようにとらえられる節がありますが、そうではなくて機能もデータも重要です。企業の情報システムは基本的には「機能」と「プロセス」と「データ」からなりたっています。

「機能」というのは何かというと、業務処理だったり情報処理でもいいのですが、インプットされた情報を加工して新たな情報をつくることとも言えます。ただこれだとかなり細かいことまで含まれてくる可能性があるので、ここでは“単位意思決定”という定義にしたいと思います。

そうなると、誰が意思決定するのかということでそれぞれの機能が変わってきます。システムを使うひとは大きく、顧客、オペレータ、スタッフ・マネジメントにわけることができます。

依頼･問合せ・苦情などをしてくる顧客、オペレーショナルなデータを生成するオペレータおよびその責任者、経営視点で戦略的な意思決定を行うスタッフや事業部長・部門長といった人たちです。

彼らに対する機能は違うことはおわかりになると思います。機能の主なものはユーザインターフェースになりますからわかりますよね。ですから一律ではなくそれぞれの立場にあった機能を提供していかなくてなりません。これ以上は本論を外れるのでここまでにしておきます。

さて、データですが、データにも種類があります。リソース系のデータ、すなわちマスタデータとイベント系のデータ、トランザクションデータでしょうか。ただ、もう少し広義に解釈して、これにビジネスルールを加えたらどうかと思います。

ビジネス活動の糧となるデータ、あるいは参照情報、それとそうしたリソースを使っておこなったビジネス活動で生まれたデータ、それと意思決定で従うべき業務ルールである。業務ルールはリソース系のデータと言えないこともないのでそちらに含めて考えてもよいでしょう。

ということでBPMアプリケーションを構築するとなると、必ずプロセス以外の要素である、機能とデータはきちんと設計していかなくてはいけない。そのなかでも上述したようにいくつかに分解できるので、適正に分解し、それぞれに適した設計、ツール選定などが必要になります。
　

いまの開発方法論ではどうしても上流設計とシステムに落とすところで結びつきが薄くなる。例えば、一生懸命業務フローを書いたのに、それがそのまま実装されることはなく、画面と帳票の設計にすりかわっていく。ええ業務フローはどこへ行っちゃったのということになる。

こうしたやり方では“システム化業務”といって、システム化できる部分だけをIT化して終わりである。IT化できるところがシステム化範囲となっているわけです。

ということは何のことはない、自動化できるところだけシステム化すればいいのだから、極端な話、上流設計はいらない。もっと簡単なのはパッケージやソフトウエアにある機能を使うだけでいい。

このブログを読んでくださっているみなさんはもうお気づきだと思うのですが、従来型の限界がここにあります。ですからここの発想の転換、逆の視点が今求められているのです。

ビジネスをオペレーションするには、IT化されていようが、そうでなくても業務プロセスとして一貫化されていなくてはいけません。そしてそれが見えていなくてはなりません。これが何度も繰り返しますがプロセス中心の考え方です。

そして、従来システム化されなかった部分であるコラボレイティブな業務がウエブサイトの情報共有空間で実現できるようになったので、そこと従来のトランザクション型の処理と一体化させることで一貫化された業務プロセスの構築が可能になったのです。

これが見える化でもあるのです。

もうひとつ大事なことは、設計と実装の乖離がなくなったことです。設計と実装が連続技としてできるということは、開発の手戻りとか仕様変更を回避できるようになります。

BPMの登場はここがポイントで、要求定義と要件定義がつながるのです。

ところで、どうして設計と実装の乖離がないかを説明しなくてはいけませんね。それは次回にします。
　

システム開発で設計というとこれまではシステム機能に寄っていってしまいます。どうしても、システム化あるいはコーディングするための設計になります。

ところがユーザが見ているのは自分たちのビジネスがどう実現できているかです。ですから、極端な話システム機能はどうでもいいのであって、自分たちの仕事の流れ、事業の実態が追えるかどうか、コントロールできるかです。

ですから、ビジネスを設計したらそれがそのとおり動く仕組みを提供する必要があって、以前“動く業務プロセス”というい方をしましたが、それがBPMでもあるのです。ただし、このときのアクティビティの定義が問題であまり細かすぎてもいけないし、大雑把でもいけないということです。

そして、上流の戦略から落ちてきたプロセスモデルがそのまま実装されるのが望ましいのです。従来はここに断絶がありました。システム化できる業務を抜き出してそこを実装するための設計・開発にはいるというわけです。

そうなると、ビジネスの連続した動きが見えなくなってしまい、そのシステムを動かすために人が動作するという逆転がおこるのです。

さて、この連続性を可能にするにはどうしたらよいのでしょうか。トップダウンアプローチとして上流から分解してくるプロセス粒度とボトムアップアプローチである実装を意識したプロセス粒度が合致することです。この設計と実装の交差点が定義できることが重要になります。

こうしたことができると上流から下流まで、戦略からＩＴ実装までがシームレスにつながり、ビジネス側の要求がどう実現されるのか、ＩＴの持つ機能がビジネスにどう生かされるのかが見通せるのである。

これがＢＰＭの非常に大きな特徴である。言い方を変えると、こうした良さを引き出せるＢＰＭを志向しないと意味がないのである。何度も言いますが、単なるワークフローでもなければ、プログラミングの自動化でもないのです。
　

いま、ぼくの周りで「経営とITの同期」ということが盛んに議論されている。先日もカリフォルニア州立工科大学の一色教授とのディスカッションでもこの言葉がでてきた。

ところでよくいわれるのが「経営とITとの融合」ですが、どうもよく考えると経営とITが融合するという状態がイメージできない。それよりも経営とITが同期するというほうがしっくりくる。したがって、これからは「経営とITの同期」ということにする。

ではその経営がITと同期するというのはどういうことなのだろうか。同期というからには経営側から見てもIT側から見ても整合的に同じように動くことを意味している。すなわち、

・経営に役立つITになっていること
・ITを使いこなす経営になっていること

だと言える。

これだと抽象的なのでもう少しわかりやすくすると、どういう状態のことをいうのかとなる。それは、

１．業務プロセスを可視化しコントロールしている
２．戦略を実現するために事業全体の適正なオペレーションができている
３．業務パフォーマンスの把握と戦略へのフィードバックがなされている

ではないでしょうか。

まずは、自分たちの経営や事業運営の核となる業務プロセスをコントロールできていることが大事です。何をやっているのかがわからないで結果だけ見せられた、成績はこうでしたといわれても手の打ちようがありません。いまのプロセスの状態を見えることで制御が働きます。

さらに経営方針や事業戦略が狙い通りに実現できるように事業全体をオペレーションすることがもっと大切なことになります。

こうして動いた業務プロセスのパフォーマンスや事業の結果をきちんとモニタリングして、評価して最初の戦略立案へフィードバックさせます。

要するに大きなPDCAサイクルを回すことなのです。しかしながら、これまでの問題点は、この戦略から実際に動く業務プロセスへのつなぎが不十分であるということなのです。

この問題を解決するツールとしてBPMSがあります。すなわち、経営とITを同期させるフレームワークがBPMSなのです。
　

今日発売になる「日経SYSTEMS」9月号は「SOAアプリの開発基盤BPMツール」というタイトルでBPMSの特集を組んでいる。

ぼくもこの記事に関する取材を受け、ひとことだけ載っていたが、この記事について考えてみる。

まずは率直な感想は今のBPMの課題が浮かび上がったということである。どういうことかというと、事例として出ているものをよくみると２つのタイプがあることがわかる。

ひとつは佐世保重工の例にあるように機能とプロセスを分離して、機能をサービスとして外部化することでプロセスに組み上げるモデリングである。一方、他の事例では申請･登録系などを対象としたワークフローツールとしてのBPMSである。コードレス志向で開発生産性を高める方向に重きを置いたものである。

この二つの間で大きく違うのは、サービスの粒度である。前者は比較的大きな機能という捉え方ですすが、後者はそれよりも小さな粒度であるアクションレベルのものをＢＰＭＳでつなげている。

この二つでどちらが良くてどちらが悪いというわけではない。もちろん両方ともありだが、両方とも何かが足りない。

大きな粒度でプロセスを作ったときは、実装にどう落とすかという問題が残る。一方、ワークフローだとコアに近いところの業務プロセスへ展開した場合、膨大なアクティビティ数になってしまい、プロセスの可視化が難しくなる。

ということは、両者の課題をうまく解決すればいい。ビジネスモデルから業務プロセスへ落としこみ、それを動く仕組みとして実装していかなくてはいけないわけで、まずはビジネスモデルから業務プロセスへ連結性を維持するには大きな粒度がいる。それはそれで大きな流れのプロセスを作るのだ。これはマクロワークフローでもある。

次にその“粒”＝アクティビティ・機能の中を細分化されたフローに分解するのである。これはミクロワークフローで、申請・登録などはこれにあたる。

こうしたレベル化がポイントである。マクロワークフローとミクロワークフローに分けたが、言い方を変えると、固定的（静的）プロセスと変動的（動的）プロセス、あるいは戦略的プロセスと戦術的プロセスともいえるのではないでしょうか。

この記事からうかがえるようにまだまだBPMについての定義や体系が定まっていなく、人によって語っていることが違っていることも多い。

これから、いろいろな議論や実績の評価により、輪郭がはっきりしてくると思うが、単なる新しい個別のソフトウエアだとかアーキテクチャというだけではなく、業界構造やIT人材像なども変えていくほどの影響力があるということだけは確かだと言えそうだ。
　

経営とITの同期を議論していくと、経営の要求をどうITに反映させていくのかとう問題が出てくる。ここの議論での焦点は、「要求定義」と「要件定義」の違いである。

米国ではこの前者の「要求定義」のための「要求工学」というのがしっかりとあるというのは一色教授の話にもあった。「要求工学」というのは要求獲得―要求仕様化―要求検証―要求管理というサイクルを工学的にやろうという動きである。

日本にも要求工学はあることはあるし、要求開発というコンソーシアムもあるのだが、概して、「要件定義」に寄っている。どういうことかと言うと、システム化するための要件、システムとして備える要件に持っていってしまうということである。

そうなると端的にいえば、システム化できる業務だけに限った要求になってしまう。この時点で、経営とITの乖離が起きる。経営戦略の達成は何もIT化できる業務だけでできるわけではなく、手作業やコラボレーションなども重要な手段であるからである。

ここが従来の上流設計と言われるところの不備である。ですから、いつのまにかビジネス上の要求がとんでいってしまい、単なるコンピュータシステムを作ることになってしまうのである。

ですから、要求工学に則ってきちんと要求を定義し、それは崩さすIT化するという連続性を担保した要件定義にならなければいけない。

もう少し詳細化していうと、経営戦略たとえばバランススコアカードで設定したKPIなどを実現するための業務プロセスを大きな流れから徐々に分解していきます。このときは、人間系でやろうがITでやろうが関係無しに、業務のアクティビティとして定義します。そこで定義したアクティビティを定型ITとともに不定型なコラボレイティブな場とで実装していくのです。このあたりは、設計と実装の連続性のところで書いたとおりです。

こうしたレベルになってくるとオペレーショナルな観点で決めていくので、より柔軟に考えていけばいいのです。すなわち、使う人の使い勝手で変えてもいいし、新しい技術ができたら乗り換えてもいいのです。それは戦略的な要求を損なうものではありません。

ですからここでの議論である、｢要求定義｣と「要件定義」の違いを正しく理解することが非常に重要なことといえます。

先日、ITC協会の研究会のあとの呑み会で題記のような議論になった。

80年代を謳歌した日本産業界も90年以降、アメリカに置いてきぼりを食ってしまった。その原因は、IT化の質と量の差である。

アメリカも、80年代はまだコスト削減が主体のIT投資であったが、その投資対効果が疑問視され、もう少し戦略的に投資しなくてはいけないということに気がつき、その領域への投資額も増やしていったのである。

反対に日本は相変わらず維持保守のための投資が主体で、それ以外でも自動化による省力化だとかいった効率化を目指したものにカネをかけている。

要するに、日本では情報システムはコストと考えているが、アメリカでは投資というようにとらえているから、ROIをちゃんと評価してやっている。この差が大きいのではと言うような議論であった。このあたりのことは。野口悠起雄も「ジェネラルパーパステクノロジー」で書いている。

別な言い方をすると、コストと考えているうちは経営戦略も何もないのだから、前回に言ったような「経営とITとの同期」なんてことは関係ないのだろう。

しかし、前述したように日本経済の弱体化をもたらした大きな要因に戦略的IT投資ができていないことがあげられるわけで、そうなるとだんだん経営者もわかってくるので、これから有効なIT投資をどうしたらよいかという問いかけが活発になることが予想される。その答えは、いままで言ってきている経営と同期したITの構築ということになるのです。

IT化というのは基本的には作業や情報伝達を自動化することとも言える。人間でしかできない仮説立てと判断を除いて自動化しようとする。場合によっては判断もルール化することで自動的に答えを導こうというアプローチもある。

ところで、本当に自動化ができるのだろうかと考えてみる。前述した判断の自動化という問題をとりあげると、自動化が可能な条件というのは判断の結果が許容できるものなのかになる。言い換えれば、割り切りができる程度の事象なのかどうかである。

昔工場で働いていたとき、発電所の選択遮断のデシジョンテーブルを検討したことがあるが、こういう場合は、最終的に系統を切られてもしかたがないという割り切りの世界なので、事前にその得失を吟味して設計しとけばよいことになる。

逆にプラントなんかだと定常状態では自動化はできるが、スタートアップやシャットダウンといった非定常作業は自動化が困難で人間が操作して行なう。

実世界でも同じなのだが、むしろ割り切れないケースが多く現れる。例えば一番わかりやすいのは、お客さんがいて何かトラブルがあって、それに対してルールどおり自動的に対処しましたから、といったところで納得いかないお客さんがいたらそれで終わりだ。

ですから、あらゆるケースを想定してルール化しようとしてもできないのでこうした例外が発生してしまうのである。

いま判断というアクションについて言ってきたが、それ以外でも様々な例外や異常を想定して自動化の仕組みにするコストが、自動化しないで対処する場合のコストを上回ったら、それはわざわざ自動化する必要はないのである。

おそらくそうした吟味はされず、何でも自動化に向かい、どうしてもできないものはやめておくかといった事態になっているのではないでしょうか。ですから、そこをも少し、人間の判断や操作も入れながらシステムを構成することが大事ではないかと思うのである。

システムトラブルでも復旧に時間がかかったりすることは、複雑な自動化が遠因となっていることもあるような気がする。

BPMでもBPA（Business Process Automation）というようないわれ方もされるが、そこのところをよく考えないとかえって使いにくいシステムになる危険性がある。

そういった意味で、これからはITと人間がうまく共生していく仕組みが求められていくのだろう。
　

いま、BPMS（Business Process Management Suite）とCMS(Contents Management System)を組み合わせたアプリケーションプラットフォームを指向しているが、それを考えていたときふとこれはラブビー型のシステムだなと思ったのである。

以前にこのブログでBPMをサッカーになぞらえて書いていた。フロント業務がフォワードでバックヤード業務がディフェンダーでBPMはミッドフィルダーのようなものだと。ところが、システムのかたちを見てみるとどうもラグビー型のような気がしたのである。

すなわち、CMSのところがフォワードで、BPMSがバックスである。フォワードがラックやモールでボールを奪うとそれをバックスに渡してバックスはパスをつないで攻めるというのは、情報共有で処理し、後は決まったプロセスで受け渡すというのに似ていなくもない。

ラクビーはフォワードとバックスではずいぶんと役割やら必要スキルが違うのである。逆に言うと、どんなタイプの選手も受け入れられるスポーツなのだ。太ったやつ、小さいがすばしっこいやつ、足の速いやつ、頑丈なやつ、とそれぞれ働き場所がある。これだけ多様なタイプの選手が活躍できるスポーツは他には見当たらない。

ここで何を言いたいかというと、SOAというのはどうもサッカー型の仕組みを言っているように思え、でも現場を見るとまだそこまでできなくて泥んこになって、倒れこみながら、どっちに転ぶか分からない楕円のボール追っていくようなフォワードスタイルがあるのではないだろうか。

サッカーボールも不規則であるがラグビーボールはもっと不規則なのである。それを扱うには、束になってスクラムを組まないと扱えない。手でつかんだ後は、わりと確実につなげるというわけである。

サッカーは、洗練された、レベルの高い企業がやれることかもしれない。しかし、ふつうの会社はそうは行かないのが現実であるし、ボールを持っているやつの突進を助ける目に見えない動きも必要なのである。それが、BPMS+CMSであると考えているのだ。

ちなみに、昔のERPや汎用機の仕組みはアメフトだと思うがいかがでしょうか。
　

化学プラントにおける情報管理をどうやっているかを探り、それをビジネス情報の管理に適用できないかを考えてみることにする。

化学プラントの管理の基本はプロセスコントロールである。それには、DCS（Distributed Control System＝分散制御システム）と呼ばれる制御システムで管理する。その名のとおり、分散的に置かれた制御ステーションで個々の制御ループをコントロールし、バス接続された中央にあるオペレーションコンソールで監視しながらオペレーションする。

実はこれだけだと、部分的な制御が主体なので全体がどうなっているだとか、さらに全体最適化をどうするのだとか、過去のデータやトレンドを見たいといったことができないのでそうした俯瞰できるような仕組みが必要になる。

そうしたシステムで優れたものにPIという米国のOSISoftware社が開発したソフトウエアがある。このシステムの最大の特徴はリアルタイムデータベースにある。プラントデータというのは、非常に短い周期、例えばミリ秒のオーダーでデータが生成する。そうしたデータを全部収集すると大変なことになるので、それを簡単に言うと差分だけ採るデータ圧縮技術によって強力なプラント管理システムとなっている。

この話をすると長くなるので、このソフトウエアの主要な機能をみると、Process Book、Data Link、Batch Viewの3つである。Process Bookというのはデータをプロセス図上でグラフィカルに表示するものです。Data Linkはシステムに収集・蓄積されたデータを様々な切り口でとりだすものです。最後のBatch Viewというのは、バッチトレンドやガントチャートを作成して基準との比較などができるものです。

さてこうしてみるとこれらは、ビジネス分野でも応用できそうな気がしませんか。業務プロセスフロー上で今どのようにタスクが動いているのかを表示してほしいですよね。また、過去のデータの履歴を、例えば期間ごとに前年と較べてみたですよね。あるプロセスの稼動状況をあるべき姿とどう乖離しているのかみてみたいですよね。

ということで、BPMS＋CMSで開発した業務アプリケーションを一歩上のレベルに押し上げるものとして、業務プロセス管理システムを作りたいのだ。この場合は、Process Monitor、Data Box、Service Viewというような名前をつけようかと思っている。

さてどうなることか。米国ではこれに近いことを一部やっているようだが。
　　

システムを考えるとき、どういう発想を持ってみるかというと人それぞれで違うように思う。開発の視点から入る人もいれば、運用をまず考えたりすることもある。また、データからやパッケージから見たり、フレームワーク的な見方をする人もいるかもしれない。ところが、ユーザのオペレーションから発想する人はいるようであまりいないように思える。

すなわち、ビジネスプロセスをオペレーションするのにどういう仕組みが必要なのかという観点で見ることである。もしこうした視点で見た場合、システムを眺める景色がずいぶんと違ったものになるような気がする。ただし、ここでいうオペレーションは、個人的なものというより、組織としてのオペレーションを考えるので、業務プロセスの動かし方のことになる。

まず初めにビジネスにおけるこのオペレーションとはどういうことなのだろうか。いつも言っていることなのだが、オペレーションとは、「マスタデータや業務ルール、その他もろもろの情報を参照しながら、意思決定を行い、それをつないでいって最終的な意思決定結果をイベントデータとして生成し、それを登録する」ことである。

これって、化学プロセスでいう「原料を仕込んで、マニュアルや設計図を見ながら、単位操作を加え、最終製品にし、貯蔵する」というのと同じであることがわかると思う。化学プロセスではこれを当たり前にオペレーションと呼んでいる。

さて。このように定義すると、意思決定のための情報収集とその見せ方が重要であることに気がつく。すなわち、そうした関連する情報をどこから取得し、配置するかである。もっと言えば、それ以前に、必要な情報をしかるべきところに格納しているのかという問題がある。

今日では、非常に多くの情報があふれていて、その中から本当に有用な情報を持ってくるかが、質の高い意思決定ができるかどうかを左右する。この“情報のさばき方”のシステム化が大変大事になってきている。

これはいままでにはなかったことである。これまでは、むしろ情報を作ることに注力していたように思える。結果としてのデータを編集・加工することで新たな情報ができるということである。それはそれとして今でももちろん重要なのだが、結果を作るまでに参照する情報の量と質の問題も大きくなってきているように思う。

そのとき、基本としてやられてなければいけないのは、「データ辞書」と「業務ルールブック」がちゃんとあることだと考えている。同じ意味なのに違った名前のデータがあったり、人によってやりかたが違うといったことがないように、辞書とルールブックは必須になってくる。

このあたりの詳細については、次回に書く。
　

いま人間系のシステムとしてCMSのような情報共有型の仕組みを推奨している。それは、人間が絡むと非常にあいまいで、あっちいったりこっちいったりするからである。

しかし、だからといっていい加減ではない。むしろ議論をしながらいい方向に行こうということである。ここのところが非常に重要なことであるような気がする。ウエブ系の特徴はここにあって、孤立型バケツリレーはやめようよねという思想であると思う。

ネットで格差だとか疎外みたいないわれ方をするがぼくはそういうネガティブな側面はあるのは否定はしないが、それ以上に逆の仲間感があるような気がする。ただし、ここが閉鎖性を伴うとまずいのだが、ウエブにはそれに陥らないオープン性も一方の特徴としてあるわけだから、ドアを開けっぱなした仲間世界である。

これって、ぼくらの時代の人にとっては“縁台・縁側”なのだ。ぼくらの子供のときって家に鍵なんかしていないので、いつもよそのうちにあがりこんでも平気だった。夕方になると、縁台でおじさんたちがいろんなことを教えてくれた。

ぼくはそれをウエブに見ることがある。それをウエブ上に取り戻したいと思うのである。仕事はひとりぼっちではできない。いくらいきがってもできないのだ。

それをここのところわが国では、どうも自立とか自己責任とか言い出して、そういうことを単純にひとりでなんでもやれということだと感違いしているのか、あるいはひとのことをかまっていられないほど追い込まれているのかわからないが、ひとりで何でも処理できるやつができるやつだと思ってやしないのだろうか。

実はぼくも若いときはそう思っていた。すなわち、だれにも教えてもらわず、自分で何でもやってやれ、できると思っていたのである。それはそれで大事な資質だと思うが失敗した。

特に経験したことがないことが目の前に現れたときどうするかである。それは経験したことがないのだから、それでもあくまで自分の頭で考えるか、だれかに助けを請うかである。往々にして、自分でなんでもかたづけようとするが、うまくいかないのである。そのときどれだけ謙虚になって、教えを請うことができるかが、大げさに言えば人間の器になる。

ぼくは見た。若いとき、まだ化学プラントのオペレータのときである。ぼくが尊敬する人がいて、その当時はこの人は何でもわかっているすごい人だと思っていたのだが、ある緊急事態が起きたときに、もうなりふりかまわずぼくにむかって、“おいどうしたらいいのだ”と言ったのだ。

これはすごいことなのだ。結局、みんなで精一杯の知恵を出して解決することができた。それでぼくは鍛えられた。でも失敗だらけだ。「ほんとうにうまくやるのには人生は短すぎる」と思うのである。

ぼくみたいな年寄りはここのところは胸を張って言える。だから、いろいろな経験をしろと言いたいのだが、そう簡単ではなくて、経験はチャレンジしないと得られないということを肝に銘じることである。

話を基に戻すと、みんなで考えて決めたことは案外いいことだよねという精神は、けっこう今の企業のなかで使えて、むしろそういう方向がこれまで方向と違う、しかしかつての日本的な世界のよさを取り戻せるように思える。

でもこれだとひょっとして循環論だから、そうではなくて、進化した情報共有理論を誰か作ってくれないかなあ。
　

以前、ＳＯＡは終わったと書いて、ＳＯＡはあくまでアーキテクチャであり、概念だから、それを目的として構築するという話はないと言ってみた。

ところで、いま渡辺和宣さんとH・A・サイモンの意思決定プロセスをぼくの主張しているCMS-BPMSプラットフォームで拡張展開できるよねということを話している。

H・A・サイモンの意思決定プロセスというのは、情報収集（Intelligence activity）－情報設計（Design　Activity）－情報選択（Choice activity）であり、それはManagementであり、組織であると定義している。これはまさにいまやっていることに他ならないのだが、この話はまた書く。

こうして、サイモンのことを調べているとき、その延長線上に戦略情報システムが出てきた。その昔、SIS（Strategic Information system）と言ったやつである。それについて、「経営情報システム」（島田、高原　日科技連　1993年）に書いてあることがすごく印象的だったのでそのことについて書く。その中で、戦略的情報システムとは？ということに対して次のように記述しているので引用してみる。

「SISとは、経営戦略を実現するために。組織の基幹システムについて、情報技術を用いた組織内または組織間、あるいは両者間の業務結合により有機的に築かれた、差別化による競争優位のシステムである」としている。ここでのポイントとなるのは、情報システムが企業の競争優位を獲得する戦略に寄与しているならば、従来のどのような概念もSISとして位置づけ可能であるとしている点である。しかし、競争優位性の獲得という目的を達成するための手段は情報システム以外にも多様に存在し、また、SISの代表例と言われた情報システムも意図的に構築されたものではなく試行錯誤の結果としてでき上がったものであることを考えあわせると、「結果としてのSIS、振り向けばSIS」という言葉は味わい深い言葉である。

わーを、このなかでSISをSOAと言い変えてみてください。ぴったりでしょう。こうした見解が15年前に書かれているということは、同じような3文字が表われては消えしたのだろう。上の書いてあることってほんとSOAにも当てはまると思いませんか。

結局、そういうことなんです。“結果としてのSOA、振り向けばSOA”というのは言いえて妙である。

これまで、業務プロセスを可視化して、それを改善、改革して差別化を図るという文脈で語ってきたが、ここにきて少し考え直している。

というのは、いろいろなタイプの業務プロセスを設計していくとどうもパターン化できそうだということが分かったからである。まだ、本当にそうだかわからないがそんな気がしだした。

プロセスはほぼ同じ構造になる。結局、ビジネス活動は、Ｈ・Ａ・サイモンの意思決定プロセスに準じて行動される。その要素は、個別のアプリケーションによって相違があるわけではなく、共通的な構造となっている。ただし、その構成の違いによって業務が特徴づけられるといえる。

そう考えると、業務プロセス自体に差別化要因を内包できるのだろうか。言い換えれば、プロセスの違いによって、競争優位を発揮できるのだろうか。

確かに、プロセスの効率性とかオペレーションエクセレンスという面は否定はしないが、それではコスト競争力というだけのような気がするのである。もう少し、差別的な意味合いを見出そうとすると、プロセス以外のところに求めざるを得ないのではないだろうか。

でここで言いたいのは、いまの議論からいくと、プロセス以外のデータとかルールとかいった観点の色を濃くする必要があるのではないかということです。これが前のエントリーで指摘したことである。

そこでは、意思決定のための情報収集の重要性と大前提である「データ辞書」と「業務ルールブック」の存在に言及した。この3つがプロセスとともに非常に大事なものになる。ここでは、そのデータとルールが実は競争優位の源泉ではないかという仮説を提示する。

というようなことを言うと、かなりの人がそれはＭＤＭ（Master Data Management）であり、ＢＲＭ（Business Rule Management）ですねという。そういうことではないことに注意しなくてはならない。これらは、あくまで管理システムであり、その前にどういうマスタデータ、どういう業務ルールを持つのかが重要なことなのであって、そこを忘れると、ただのシステムの話になっては本末転倒になる。中味が問題なのである。

マスタデータというのは、まさに企業がそれを原資として活動を行うものである。具体的には、製品・商品、顧客・取引先、従業員・組織などである。

人に例えてみればわかるように、優秀な人は、高いレベルの知識やスキルを持っていて、それを発揮できる良質の職場やクライアントを持ち、気心の知れたスタッフと一緒に活動するという姿が思い浮かぶことでしょう。ちょっと物騒なところでは戦争で戦いに勝つには、相手に応じた武器であり、兵站であり、兵士である。

マスタデータというのはそういうものであり。それはすぐに獲得できるものではなく、ビジネス活動をしながら、成長していくなかで確保されていくものである。ですから、それは企業の体力であるとともに、差別化するためのものでもあるのだ。

同様なことが業務ルールブックにも言えて、必ずしも論理的にあるいは一義的にアクションのしかたが決まらないのは皆さんいろいろな局面で出会うと思います。もちろんマクドナルドのようなマニュアルもあるかと思いますが、企業の中ではそうはいきません。

そうなると、経験だとかノウハウだとかといった暗黙知の世界も大事になります。ですから、現実問題としては、そうして知識やノウハウを顕在化して、それをルールブックに仮登録したらよいと思います。それで、そのルールが恒久的なものであると認知されたら、正式ルールになり、さらにそれが定型的なシステムにできるならそうするというサイクルを回すことが大事になると考えている。

トヨタが強いのは、プロセスというよりもトヨタウエイを完遂できる人材と忠実な部品メーカというリソースと、現場の知恵を生かすルールブックがそれを可能にしているようにぼくには思える。

情報収集のところも含めて、ここのところをどんな仕組み、仕掛けにするかをいま思案しているところである。
　

先日、情シスオフ会というのがあって、当初ぼくも参加することにしていたが、急遽所用で欠席した。ぼくは元々情シスにいたので、このオフ会に興味があってぜひとも参加したかったので残念であった。

参加していろいろと議論してみたかったので、ここで情シスの課題だとか、あるべき姿などについて書いてみることにする。

そもそも、情シスがどうしてできただとかといったことはぼくも知らないし、あまり意味がないように思うので、現状について考えてみる方がよい。

では今の情シスが抱えている問題は何なのであろうかという問いに対する答えはおおかた次のような答えになるのではないでしょうか。“ビジネスのことにもITのことにもそれほど強くないが、両方のことを考えなくてはいけない中途半端な存在ということ”。

日本には伝統的にSIerという存在があり、彼らがビジネスのところに関してもある部分入ってきてやってくれているので、情シスはエンドユーザとSIerの橋渡しをするだけでよかった。

しかし、これは限界があって、SIerはもちろんビジネスの深いところはわからないから、結局そこでギャップが生じる。そのギャップはシステムそのものの構造もそうなってしまうのは必然で、経営や事業とITとの乖離が一向に解消されないという事態になっているのだ。

それを招いている要因は、経営の情シスに対する価値観という外的なものと、情シスの人間の目的意識やモチベーションという内的なものが相まっていると思う。

わが国の多くの経営者は残念ながら情報システムに対する評価はあまり高くない。ITを経営や事業に生かすという考え方が希薄である。仕事というものはシステマチックにできなないもので、人間力が大事で、最後は気合で乗り切れみたいな気分がまだ残っているのかもしれない。

それでは、情シス部門に経営者自らがミッションを与え、しかるべき人材を投入するというコミットメントはしないということになる。もちろん、どこの会社もそうだといっているわけではなく、最近はITを重視する経営も増えてきてはいるが、製造業を中心にまだまだなような気がする。

一方、内部の問題は、そこにいる人たちのアイデンティティは何かということにつきる。いったい何を目標にして、学習しスキルを獲得し、それが会社に貢献でき、自分も成長していけるというキャリアパスを描けるのかということである。

相対的に評価の低い部門でずっと生きていくのか、それはITの専門家になることなのか、ITの経験を生かして事業部門に戻って活躍したいのか、こういったもやもやがいつもあって、いつのまにかモチベーションも失せ、何となく日常を過ごせばいいやとなってルーティンワークにいそしむようになる。

これを、解消する目的で分社化すなわち情報子会社を立ち上げるという策がある。しかし、それが必ずしもうまくいく解決策とは限らないことが悩ましいのである。ここのところは別の機会に書く。

では、こうした問題点を抱えているのであきらめるしかないのだろうか。でここで強く言いたいのは、そんなことで嘆くな、これからチャンスがあると。

今のような経済情勢では、GoTheDistanceさんの言うように内製化に向かうのは必然であるが、じゃあ、従来SIerがやっていたことを情シスができるのかという問題がある。それは、できるまでに時間がかかったり、質がおちたりするわけで、やってはいけないことなのだ。

だから、情シスでもできる、あるいは情シスこそやるべきだというやり方に変えていくことが非常に重要なことなのである。従来の延長線上ではだめで方向を変えなくてはいけない。

では、どうしたらいいのだろうか。その答えが「BPM」にあると思っている。企業のシステム構造がBPMの登場により、経営あるいは事業とITのギャップを埋めて同期しようとしています。それと同時にユーザとベンダーの関係、もっと言えばIT業界の構造をも変えようとしています。この構造変化に情シスも呼応するべきだと言いたいのだ。

BPMというのは、経営・事業とITの間に位置しているとすると、もうおわかりと思いますが、その位置そのものが情シスの存在に対応しているのです。すなわち、経営や事業における戦略やユーザ要求を理解し、それをプロセスに落とし込み、ITの部分はSIerにやってもらうように要件を提示するという姿である。

これこそ、情シス（情報子会社）がやるべきエリアであり、ビジネスやITに詳しくなくても務まるはずだ。極論すると、経営とITをつなげる接着剤の使い方を知っていればできる。

変な言い方だが、冒頭に言った“中途半端な存在”だからこそやれると考えるポジティブ発想をもってもらいたいのである。これができれば、情シスのステータスは格段に向上するはずだ。非常に期待している。

ということで、wkzｋさんとGoTheDistanceさんには、「情シスオフ会」と「BPMオフ会」には密接な関係があるということで、合同オフ会をやってもらえたらいいなあと思っている。
　

先日の情シスオフ会でスタロジの羽生さんが「ブリスタ」を惜しげもなく公開して、そのすごさにびっくりしたとwkzkさんのブログに記事が出ていて、その中にこんな記述があった。

そうそう、それはmark-wadaさんのいう対面式で開発を行うというあのお話と一緒だなぁと。mark-wadaさん強敵ですよ、これは。正確にはmark-wadaさんだけにいうことじゃないんだけど、ま、そこまでは書かない(^^;

それで、こりゃ一言おうかと思ったのだが、具体的に分からなかったのでやめておいた。いつか羽生さんに聞こうかなと思っていたら、羽生さんが、そのあとブログで「ギョイゾー！の裏側」というタイトルで記事を書いていた。びっくりした。ここまで書いていいのかということとここまでやっているんだという驚きである。

読んですぐに分かった。分かったといっても、ぼくは中味のことはまったくといっていいほど理解できないと思うが、そうではなく「ブリスタ」のコンセプトと設計内容、機能のことである。

羽生さんがぼくの強敵だとはぜんぜん思わない、というより羽生さんの方がはるかに先に行っているし、実践でがんがんやっているのには正直言って脱帽です。

しかしながら、wkzkさんも言っているように、ぼくが考えていることとまったくと言っていいほど一緒なんです。羽生さんに一緒にするなと言われるかもしれないが、図々しくそう書かせてもらっています。

もはや、システム開発は製造工程が律速でも何でもなく、要求定義（要件定義じゃないですよ）が大きなウエートを占めています。要求定義がきちんとできたら、その成果物が一貫で実装まで行ってしまうというのがめざすところです。

このことに関して羽生さんのエントリーではこう書かれています。

このようにスタロジは、基本的にはお客様とフェイスするチームと仕組み作りチームに分かれています。そして相対的にですが圧倒的に時間がかかっているのがお客様との打ち合わせです。この打ち合わせの時間も、ブリスタのおかげで恐らくは一般的なプロトタイピングなどと比較すると随分と短い時間でやれていると思いますが、結局はお客様の「うん、こういう業務でいいんだよ」という確信にたどり着くまでの時間次第ということになっています。業務上の確信という点ではマジカ！を使ったりもしていますが、何にせよ意志決定ということがテーマなわけですから越えるべきテーマは色々とあります。

この意思決定をしやすくする仕組みというのが重要で、自分たちの業務を分かりやすく整理してやる必要がある。それも含めて課題として、

今のところ、お客様と打ち合わせをして作るものを固めるところの時間短縮が課題です。またそれと連動する形で、打ち合わせ通りになっているかを検証する時間の短縮も課題です。開発については手書きの業務ルールを出来るだけ打ち合わせ段階の資料からそのまま落とせるようにするということを考えていますが、これはあと2年ほどはかかるかと思います。

と言っています。これらの課題をどう解決していくのか。難しいのは、いいツールを作ったらできるのかという問題でもなく、その気にさせるファシリテーションみたいなことが要求されるのだろう。

それと、業務ルールというのは、必ずしもいつもきっちり決まったものがあるわけではないので、なんとなくあるものから徐々に固まってルールに昇格するようなところがあるので、ある種の成長あるいは進化プロセスとして組み入れることが要るのではないでしょうか。

ここはぼくも一生懸命考えているのですが、羽生さん、2年なんて言ってないでもっと早く作らないと、ぼくが作っちゃうよ。（笑）

羽生さん、もうこれはヤバイですよ。これはイノベーションです。イノベーションというのは、優れたことをすることではありません、方向を変えることを言います。これは情報システムの作り方の方向を明らかに変えることです。（ぼくはBPMベースで同じことを主張しています）

それと、「スタロジはいわゆるウォーターフォール型というスタイルで仕事をしています」と言われますが、行き着くところは違うんじゃないかと思う。だって、仕組み作りチームは、案件ごとに動く必要がなくなるわけで、お客様とフェイスするチームだけで開発が終わってしまうのではないかと思うのです。これもすごい。

いずれにしろ、スタロジの仕事に敬意を表さざるをえません。と同時にうらやましくてしょうがありません。羽生さん、いいですよね仲間がいてああじゃないこうじゃないと議論しながらやっているのでしょうね。ぼくも入りたいな。

ぼくは基本的にひとりなので、しかもコード書けないし、システム設計もできないし、けっこうつらいものがあります。でもがんばります。
　

以前の記事で少しばかりH・A・サイモンの意思決定プロセスのことを書いた。これについて、彼の著書である「システムの科学」も参考にしながらみていくことにする。

サイモンの意思決定のプロセスというのは、
１． Intelligence Activity（情報活動）
２． Design Activity（設計活動）
３． Choice Activity（選択活動）
ということになる。

すなわち、情報活動で意思決定のための情報を収集し、問題点を明らかにし、設計活動で、問題解決のための代替案を提示し、選択活動でそれらを評価し、満足解（最適解ではない）を得るというプロセスのことである。

これは、業務プロセスそのものではないかと思うのである。サイモンも「意志決定は管理（Management）とほぼ同義である」と言っているように、経営は意思決定であり、組織は意思決定の分業化されたシステムのことでもある。

こうしたサイモンの意思決定論は記述的意思決定論とよばれるが、他にも規範的意志決定論と呼ばれるものがある。これは「意志決定者に対して、いかなる決定を下すべきかの規範ないしは処方箋を提供することを主目的とする」ものである。

一方の、記述的意思決定論というのは、「現実の意思決定行動の記述を目的とする」もので、実際に、人や組織はどのように意思決定を行なっているのかを実証的に説明することである。

この理論を乱暴にBPMにこじつけていくと、規範的意思決定はトップダウンアプローチであり、リファレンスモデルやベストプラクティスに基づき、より近い解を提示することと言えないこともない。そうなると、記述的意志決定論はボトムアップアプローチでAsIｓを描いて、そこからToBeへいくという姿勢である。

サイモンは、規範的意思決定論と相違するのは、人間はそんなに合理的にはできていないといういところであると述べている。

古典的な経済学や決定論では、いつも合理的にふるまう「経済人」や「経営人」がいるという前提にたつ。そうした人間は合理的な行動をとるから、最適基準を提示できるという理屈になるが、そんな人間なんてどこにもいないというのがサイモンの主張である。人間は限られた状況においてのみしか合理的な決定、判断ができないというあの有名な「限定された合理性」である。

話はちょっと飛ぶが、これは今の金融危機あるいは経済学の破綻も似たようなところがあって、経済は必ずしも経済学的には動かないもので、心理的な行動による面もかなり大きいことが今回の状況で証明されている。サイモンは昔からそういうことを指摘していたのである。

日常的なビジネス活動の局面においても必ずしも皆が合理的な意思決定をするとは思えないのであって、そこをどうやるかが問題となる。

また、サイモンは意思決定のタイプとして、「定型的意思決定」と「非定型意思決定」があると述べている。前者は反復的、ルーティン的で、モデルに依存でき、プログラム化される意思決定である。それに対して後者は、問題の本質と構造が複雑で不明確、アドホックな非構造的意志決定である。

さあーて、これはまさに定型業務プロセスと非定型業務プロセス（機能）と同じことを言っている。こうした分解は、解決する技術が違ってくるので大事なことだと思う。

では、人間はこうした限定的な合理性しか持ち合わせていないとなると、どうしたら“より合理的な”意志決定ができるのだろうかということになる。その答えの一つが、組織による意思決定の分業化なのである。合理的な意思決定をするための装置としての組織である。

これは、具体的には、意思決定の前提を伝達するコミュニケーションシステムを機能させ、組織の分業により、より合理的な意思決定をおこなう仕組みを確保することである。

限定合理性あるいは不確実性という前提のもとでとりうるシステムは、最初に述べた意思決定プロセスを実行できる環境のことであり、それはとりもなおさずこれからのBPMがめざすところなのである。
　
その具体的な仕組みとして、ぼくはWebサイトによる「情報共有の場」を提供することで、”納得あるいは満足できる”意思決定を行なうことを提案しているのである。
　

最近、HA・サイモンの影響か、階層化ということをすぐにしてしまう癖がついた。階層化ということは、マクロとミクロに分けることでもある。ぼくは経済学には疎いので何もいえないが、経済学にもマクロ経済学とミクロ経済学というものがあるらしい。その伝で、マクロとミクロで分解していくと面白い。

で今から、SOAを眺めていくことにする。ちょっと前にSOAは終ったとか書いている手前、こんな記事を書きたくないのだが、まだまだSOAといている人がいるのであえて書く。SOAもマクロのSOAとミクロのSOAがあるということである。

ぼくがやっているなかで、BPM on SOAと標榜しているので、SOAについて言っておく必要があると思うので、あえて、そのＳＯＡをミクロとマクロに分解してみる。

そうすると、どうも世の中で多くの人が言っているサービスの単位が、マクロであるような気がするのである。IBMというような大手ベンダーがそういっている、ぼくのようにBPMをやっているものにとっては大きすぎる粒度なのだ。その粒度でシステム間連携をできるの大きなグローバル企業でしか必要としないな気がするのである。

だから、もっとミクロ的な場面で有効に使うべきであり、それはBPMの先っちょの仕組みをサービスとして規定することが必要であると思う。

この低レベル階層でのサービス化が重要なのであって、マクロで必要な企業なんてほんの一握りであり、それを追いかけるより、泥臭く、しかし実効のあがることが基本なのです。どうも本に書いてあるような格好いいことは必要なくて、ほんとうに現場で泥まみれになることが必要だと思う。

ここで、ちょっと前にSAPの人が、サービスの定義をしていたので、それをみてみる。クラウドコンピューティング時代に対してアプリケーションのサービス化を進め、2008年度中に2800個のサービスがそろう予定だそうだ。

サービスとは例えば「製品IDで在庫を検索する」「従業員番号で上司を検索する」「お客さんIDで請求伝票を検索する」といった粒度のものだ。

そうなのだが、ええーと思いません。こんなこととっくの昔にやっていることだと思うのですが、何かもっと深い意味があるのでしょうか。

もっと、業務処理、機能といった色合いの強いものがサービスだと思うのですが、まあ、定義はいろいろ合ってもしょうがないので、あまり目くじらたてずに自分流の定義でやっていくことにする。
　

昨日は、スタロジの「ぶり祭り２００８」に行く。「Buri」や「ギョイゾー！」のことは、多少知っている程度だったので、実際に聞いて、見てみてかなり分かった。この間、羽生さんが、ギョイゾーの裏側というエントリーで書いていたことを読むだけでは理解できなかったことが明らかになった。

プログラムは、
１．どうしてBuriが必要になったのか
２．Buriの基礎
３．Buriエディタ自慢
４．Buriを使う場合の設計の勘所
５．ギョイゾー！生Live

よかったのは、最初にここに至った歴史的背景について1時間以上も羽生さんがしゃべってくれたことである。何か新しいことができるためには、背景というか、状況を冷静に分析することが不可欠で、その認識が的確であれば必然の結果として出てくる。

そういう意味では、業務システムの観点から見ると、ここ10年間、アーキテクチャ、インフラなど情報技術の領域ではめまぐるしく進展しているにもかかわらず、何も影響されていない、そして何も変わっていないという言葉は重い。

それと、昔の環境だったからあった機能みたいなものも、今だったら必要ないのにいまだにそれにしがみついていることをやめなくてはいけない。遺物となったコード体系、肥大化した変換プログラムなどなど。

だから、これまでの延長線上で考えるのではなく、不連続線としての変革のアプローチが必要なのである。そうしたビヘイビアをスタロジは持っている。

さて、羽生さんは終わってから、もっとみんな感動してくれるかと思ったらそうでもなかったのでがっかりしたというようなことを言っていたが、ぼくは、声を大にしては言わないが、けっこう感動している。

こういうことって、その場ですぐわあすごいとなかなかなれないことがある。白鳥の水かきじゃないけど、上から泳いでいる姿だけ見ていると、水面下で一生懸命水をかいているのがわからないのと同じように、出来上がったものだけをみると、なかなかその裏ですごいことをやっているのを忘れてしまうもので、実際に同じことを自分でやってみて初めてそのすごさに気がつくということなのだろう。

設計の方法などいろいろ議論したいが、おいおい書いていくことにして、プロセスの切り方についてだけ書く。この辺は以前ちらっと羽生さんと話したことがあったが今回でBuriにおけるプロセスの切り方がわかった。

エンティティレベルで切って、それらのステータスを管理するというのが基本で、長いプロセスになる場合はそれらをつないで構成する。エンティティというのは、例えば申請プロセスであれば、「申請書」でそうした書類というオブジェクトを状態遷移させることと定義できる。この書類の状態遷移が業務処理を表わしていることは同意見でぼくもそういうことを提案している。

しかし、UIを含めてこの開発がほぼ二人でやっているというのは驚きだ。そして、この二人がいい距離感なんだな。お互いに干渉しないというか手を出さないというか、ぼくは人間疎結合だといったのだが、その結果、システム構造的にも、シンプルな疎結合ができあがる。UIからは、何でもtoNextStatusをなげるだけでいいということになる。

Buriとギョイゾー！がIT業界の変革をもたらす起爆剤にならないかとひそかに願っている。それには、少しずつでもいいから実績を積み重ねていってほしいと思う。
　

リアルタイムシステムという。以前、SAPはリアルタイムのシステムだからと言われていた。いったいこれは何のことだろうか。バッチではないという意味でもない。その場で入力したデータが即会計システムに行って、決算ができるということなのだろうか。

リアルタイム経営とも言われる。目の前の事象にすぐに反応することがリアルタイムなのだろうか。どうも違うような気がする。

じゃあ、経営はどうやるのか。ぼくはあまり語る資格はないのだろうが、目先のことに右往左往することではないような気がする。むしろ事業やプロジェクトの責任者がリアルタイム性を望んでいるのではないだろうか。

最初の設問に戻ってリアルタイムシステムって何だろう。リアルタイム性は必要なのだろうか。たぶん、リアルタイムなんて言わないで、簡単に業務処理をいかに早く行うことだと言えばいいと思う。そして、そのための要件のひとつに「発生点入力」があるということを強調したい。

これまでのシステムでは、これがなかなか出来ていない。発生したデータをつかむ人とそれをシステムに投入する人が違うというのが、そもそもリアルタイム性を損なっている。

事業責任者やマネージャーはすぐに最新の情報を得たいのは当たり前のことだ。ただ、それは必要条件であって、それがあれば的確な判断ができることとは別問題だが。

それはそれとして、データが発生したらその場で入力されるのが、適切な判断をするために必要だということはわかると思う。

しかし、それがなかなかできない。どうしてできないのかである。それは、システムそのものの形態がそうなっていることである。今のシステムはデータ入力マシンになっているから、登録オペレータにデータを入力させることで事足りてしまうからである。

だからなおさら、データを入れる人のメリットとそれを使う人のメリットがつながらないということである。

自分が入れたデータがどう使われているか知らない、自分のためにならないことだったら、いいかげんでいいやとなるのは仕方ないけど人情である。だから、自分が入れるデータは自分の仕事に役立つこと、それができなくても、せめて自分が自分の仕事として入れてるデータがその場でそれを使う人に見られているというふうにすることだと思う。

発生点入力というのは、こうして組織としての業務の処理スピードを上げるためには必須なのである。そのためには、繰り返すが、データ発生したそこにいる人が入力するか、人が違ってもその人の参加意識を醸成することがポイントのような気がする。

それと大事なのは、そういうことができる仕組みに変えていかなくてはいけない。すなわち、システムはデータ登録マシンではなく、組織的に仕事をやっていくための情報処理マシンであるという形態にするということなのである。それが、ＢＰＭのめざしていることであるのは言うまでもない。
　

先日、スタロジの「ぶり祭り２００８」でギョイゾー！を見てて、こりゃこれからの開発プロジェクトの進め方や体制がずいぶんと変わるなと改めて実感した。

羽生さんはスタロジの開発はウオーターフォール型だと言っていたが、いわゆる従来のような形とはぜんぜん違う。これまでは、ユーザのひとからヒアリングして、それを持ち帰ってコーディングする。

そのヒアリングする人とコーディングする人は違っていて、設計書を書いては、プログラマーに流す。その結果を持ってユーザに持っていってレビューする。そうすると、必ず仕様変更や手戻りが発生し、設計からやり直すと大変なことになる。

なぜこういうことがおこるのであろうか。まず、ヒアリングした相手が、すべて“正しい“仕様を提示できるわけではない。そのひとがこうだと思っていることに過ぎない。

だから、よくあることは、Aさんから聞いて開発して持っていったら、Bさんが現れてそんなことではないと否定されてしまう。やり直しということになる。開発現場ではこれがくりかえされる。

それを打破するには、ヒアリング－レビュースタイルはもうやめて、その場で要求をすぐに動くものにして見せてしまうことである。上述の例でも、キーパーソンは忙しいからすぐに出てきてくれないのだ。

だから、最初は担当に適当にまかせ、自分は最後に確定するときに出てくればいいと思っている。ということは、最初がすぐに最後になれば、決定権のある人が最初からその気になってくれるというわけだ。

そして何より、少人数で開発できてしまう。ぼくは、これからの開発に必要なスキル人材は、まずは、プロセス設計ができる「ビジネスプロセスデザイナー」、システムインフラを設計（特にセキュリティ）、運用する「ITアーキテクト」、フレームワークやインターフェースを開発する「スーパークリエータ」である。あとデータを管理する「データアドミニストレータ」であろう。

そして、ビジネスプロセスデザイナーがユーザと対話しながらプロセス設計を行い、それができれば、ほぼ自動的に動くものができるというイメージである。

先日のスタロジでも、その役目を羽生さんが演じていて、要求を聞きながらフローを作ってしまった。あとは、二人のスーパークリエータが作ったエンジンとＵＩですぐに動かして見せた。それでいいのである。

そういう開発こそが、本来的には“アジャイル”であると思う。これをギョイゾー！がやっているのだ。これはすごいことだと思うが、いままで何回も言っているように、SIerの死活問題だから、役所が公務員改革をやらないように、SIerからは出てこない発想でもある。

国内だけを考えていればいいかもしれないが、グローバルに目をむけたとき、BPMが標榜しているコードレス開発は欧米では進んでいるだろうし、インド・中国がやりだしたらどうなるのかおわかりだと思う。

先週の木曜日に、日本ＢＰＭ協会のＢＰＭ－Ｊ交流会に出席する。今回で7回目ということで年2回開催だから始めてから3年半経ったことになる。今回のプログラムは下記の」とおりで、今回はじめてパネルディスカッション形式を採用。ただ時間が少なかったせいで、活発な議論とはいかなかったがこれからもやったらいいと思う。

１．キーノート
（１）ＢＰＭの基礎知識　　　　　　　　　　：織田新一氏　ＳＡＰジャパン株式会社
（２）ＢＰＭ市場の米国状況と普及課題 ：宇野澤庸弘氏　日商エレクトロニクス株式会社
（３）ＳＩの抱えるジレンマと解決方向　　：岩田アキラ氏　日揮情報ソフトウエア株式会社
２．パネルディスカッション
（１）株式会社アイヴィスソリューションズ　　 代表取締役社長　横田 元　氏
（２）株式会社ビズモ　　　　　　　　　　　　　　 代表取締役　鈴木　高弘　氏
（３）株式会社アイ・ティ・フロンティア　　　　　執行役員　大三川　越朗　氏
（４）ニュートラル株式会社　　　　　　　　　　　取締役　渡辺　博和　氏
（５）岩田　アキラ氏
（６）織田　新一氏
　モデレータ　宇野澤　庸弘氏

さて、もう7回目ともなると、宇野澤さんも言っていたとおり、当初のＢＰＭとはといった議論はかげをひそめ、どう実践していくかというフェーズになってきたように思う。それだけ認知され、興味を持った人が増えてきたことでもある。

今回のテーマが「ＢＰＭ／ＳＯＡ時代にＩＴビジネスはどうあるべきか」であるので、そのことについて少しふれておく。

ＢＰＭをもってどういうビジネスがあるのか、やっていくべきかという議論である。そう考えたときに、ＢＰＭはどういう分野、どういうビジネスエリアをターゲットにすべきかということになる。

セミナーの報告でも、ＳＡＰなどのＥＲＰとの関係で語られたものがあったように、まずＢＰＭはいままでシステム化されていない領域をねらうのか、ＥＲＰがやっているような領域を切り崩していくのかということがある。乱暴に言えばＥＲＰあるいはレガシーの基幹システムとよべるようなものに喧嘩を売るのか、すみ分けるのかである。

現実的には、今の段階ではＥＲＰ切り崩しは難しく、そのフロントエンドシステムとして機能させるか、ＥＲＰの苦手な顧客接点のところに存在感をおくのであろうが、いずれは侵食していくものとぼくは思っている。

以前から言っているようにＥＲＰはエンタープライズデータベースとして、決算システム化すべきだと思う。そこへつなぐための骨格としてＢＰＭが重要な位置を占めていくと考えている。

そこへいかないとビジネス規模も大きくならない。それよりも何よりもユーザにとってコストパフォーマンスに優れたシステムにはならないからである。

先週のＢＰＭ－Ｊ交流会はそんなことを考えさせられたセミナーであった。
　

ＳＯＡやＢＰＭについてブログで書いている人に“悲喜子”さんがいる。以前ＢＰＭオフ会で会ったこともある。彼のちょっと前のエントリーに「ＳＯＡ開発方法論」というのがあった。それを読んでいてSOAについて悩んでいるようなのでコメントを返そうかと思ったが長くなりそうなので、このブログで書くことにした。

SOAの開発方法論について簡潔かつ明快に述べた資料は、容易に見つけることができません。まず単純に量が少なく、見つかっても英語であったり、英語の直訳調の文章であったりします。内容も抽象的なものが多く、苦労して英語を解読したにも関わらず、理解が進んだようには思えないこともしばしばです。ボンヤ リとして見つけにくく、見つけたものを読んでみてもボンヤリしてしまう…まるで蜃気楼です。

私はＳＯＡはバズワードだと思っています。最近ＳＯＡという言葉もあまり聞こえてこないような気がします。もうクラウドに行っています。

ＳＯＡというのはまずサービスの定義もちゃんとされていないのに一人歩きしていったのではないでしょうか。それよりも何よりもＳＯＡは具体的なシステムや技術をいうのではなく、あくまで概念であり、考え方です。ですから、会社の大きさだとか業種業態、あるいは経営方針でも違ってきます。これをすればＳＯＡだというものがないのです。だから蜃気楼なのです。

従って、それを目的化してはいけないのであって、柔軟でアダプティブな仕組みであればそれはＳＯＡであると思えばいいということです。

ですから、ＳＯＡを先に作ってそれからＢＰＭだとか、ＳＯＡの開発方法論というのはナンセンスであると思っています。

だから、「SOA開発方法論」はありません。ＤＯＡやＯＯと並べられないのです。さらに言うと、開発方法論というと業務システムをどう作るかが書いてあるものでなくてはいけません。ＳＯＡで業務システムは作れません。あくまで、ＳＯＡという考え方の基盤の上にアプリケーションを作ったとなります。

私は、このＳＯＡという考え方に基づく基盤というものを「機能・プロセス・データを分離独立して、それらを疎結合すること」と定義し、そこで初めて柔軟な構造が作られると思っています。

この機能のところを狭義のサービスとして捉え、その粒度を機能の性格や特性に応じて適切に決めていくことが大切になってきます。

例えば、SalesForceのような大きなアプリケーションをサービスと言う場合もありますし、単に承認するというのもサービスでもあるのです。このサービスを論理的に定義してこそ方法論へとつながっていくのです。そこがあいまいなままだと方法論にはなりません。

また私は、業務システムというのは、「リソースデータを参照して、単位業務（情報）処理（＝機能）をフローで流して（＝プロセス）、イベントデータを生成すること」だと規定しています。

プロセスのところは、BPMSが登場してだいぶわかりやすくなってきました。データも以前からのDOAで特にリソースデータはモデリングできます。後は機能のところを論理化することだと思います。

そこで単位業務処理とはなんなのかをはっきりさせることで方法論に辿り着くことができます。それが、このブログでももう2年ほど前から提案している「ビジネスコンポーネント指向開発」という方法論です。

まだ、データのところが弱いのでいま補強していますが、それができたら、この機能、プロセス、データの設計から実装までの全体を論じたものでなるはずです。

SOAの開発方法論が蜃気楼のように捉えどころがないのは、企業秘密に属するような隠蔽されたノウハウだからでしょうか。筆者はそうは思いません。同じ開 発方法論であるDOAやOOA、OOD、OOPは広く知られているからです。もちろん、SOAの開発方法論にも、それぞれ機密に属する部分もあると思いま す。しかし、それ以前に一般的な記述があって然るべきかと思います。

最近、業務プロセスそのものに企業秘密があるのだろうかと考えている。いまでは、それはないのじゃないかというふうに思うようになっています。だって、仕事を進めていくこと、そして、勘定科目データを生成することはそんな秘密なことでもないように思う。じゃあどこに秘密が隠されているのだろうか。

それを考えるときに、「業務プロセスのパフォーマンスは何をもって測るか」を考えたらいい。このパフォーマンスの違いが差別化や競争力を生み出しているなら、そのパフォーマンスを生み出している要素こそ企業秘密ではないのでしょうか。

それは、「意思決定の質と速さ」と私は思っています。もちろん会社の競争力はそれだけではなく、事業ポートフォリオだとか人材だとかもっと違ったものがありますが、ここでは事業オペレーションの領域のことをいっています。

この意思決定の質と速さはプロセスの違いからくるものではありません。サイモンは意思決定プロセスを、Intelligence、Design、Choiceの3つのActivityであるとしていますが、それをもう少し具体的に言うと効果的な情報取得と競争優位性のある合理的な業務ルールにあると思っています。それによりいい意思決定（手戻りがないと言い換えてもよい）と迅速な判断ができるということだと考えています。

この効果的な情報取得と合理的な業務ルールがそれぞれの会社のノウハウであり、それをを持っているか、そして絶えず進化させているかが重要であるのです。

ということで、業務プロセスだけなら一般的な記述があるのです。それをある作法に則って作って、そこに情報収集の仕組みと業務ルールの進化サイクルを盛り込めばそこの会社のより高次の業務プロセスができると思うのですがいかがでしょうか。
　

昨日は赤坂で30歳前後の若いITエンジニアの悲喜子さん（こんな名前ですが男です）とbegiramaさんと三人で呑む。ニ人は大手ベンダーに勤めていて、SOAやBPMに関してブログで発信している。

以前、悲喜子さんとは彼の記事を見て声をかけてBPMオフ会に誘ったことがあって、それから注視していた。できのうは、その彼のブログから、彼の会社の先輩であるｂｅｇｉｒａｍａさんを知り、一緒に呑むことにしたのである。

息子と同じくらいの歳だから何か変な感じだけど、ブログで情報を知っているので、別段話づらいなんてことはないわけで、むしろ共通の話題があるから歳なんて関係なしにすぐに打ち解ける。もちろん、話の中心は、ＳＯＡやＢＰＭで、ただぼくがひとりでしゃべってばかりいたようで申し訳なかった。（ｂｅｇｉｒａｍａさん、悲喜子さん、ごめんなさいね）

二人はすごくいろんなことを考えていて、悩んでいて、そして何より意欲的だ。だから、何回も勉強をしたいとか勉強会みたいなことができたらと言っていた。(勉強会しようかな）

それと、自分たちのキャリアパスをどう設計していくかも彼らにとっては重要なことのようだ。ＩＴ業界というのは、レガシー企業のように年功序列・終身雇用ではないので自らで設計しなくてはいけない。しかも、身近にロールモデルもなかなかいないので余計に大変だ。

でも、ぼくだってこの歳になってやっとわかったところがあって（遅いか）、30歳のころは同じように悩んでいた。まあ、失敗を恐れず何でもやってみることかもしれない。そのうちできなくなるんだから。

こうして、ブログで知り合って、リアルの場で話をするという関係はいいとぼくは思う。それができる条件は、自分の考えをきちんとブログに書くことである。そこに共鳴や同志的感情も湧くわけでそれをリアルの場で確認するということだと思う。

視線が同じだと話していても面白いし楽しい。あっという間に時間がたってまた会うことを約して店を出る。あぶなく終電を乗り過ごしそうになった。
　

昨日は、日本BPM協会主催の「プロセス志向イノベーションフォーラム」に出かける。最近、東工大の飯島先生が議長をつとめる「プロセス志向イノベーション推進会議」というのができて、そこが企画したものである。

「プロセス志向イノベーション」というのは、主旨に書いてあるが、“組織を越え顧客・取引先をも含めた仕事のつながりを自在にデザインし、ITを有効に活用したビジネスモデルを創出すること”となっています。

そのために、BPMやSOAといったものが活用されるということです。確かに、プロセスの重要性は企業内外問わず大きくなってきている。それがITの進展とともに今までできなかったことが可能になったのである。

ぼくは、午後から受講したので、ベンダーによるワークショップが主だったが、そこではいままではこの手の話をすると「BPMとは」とか「SOAとか」という説明から入っていたが、今はその理解が進んでいて、どう活用するのかという話から入れるようになったと言っていた。ただ、まだ従来型のワークフローとどこが違うのといったところが説明しきれていないような気がした。

やはり、面白かったのは最後の二つのユーザ事例で、特に「セブン- イレブンのビジネス改革と情報システム」が印象深かった。一番感心したのは、ビジネスモデルがITの先を行っているということである。

たとえば、ハードウエアスペックが貧弱だったとき、もっと多くのデータ活用をしたかったができなかったとか、ネットワークパフォーマンスが出なかったので情報交換に支障をきたしたとか、要するに、やりたいことがあってそれを実現できるITが登場するとすぐにそれを採用するのだ。従って、これは世界で初めてですという言葉がぽんぽん飛び出す。

よく考えるとこれが本当の意味で“ITを有効に活用したビジネスモデルを創出すること”につながるのだ。その逆が多いですよね。ベンダーがはやりのITをもってきて、これを使うといいですよと言われ、じゃあ入れてみるかじゃビジネスモデルを創出するどころではなく、新規ITの実験場になってしまう。

ですから、セブンイレブンのIT化からは、はやりの三文字熟語はでてきません。すごく考えさせられたプレゼンテーションであった。

こフォーラムでは旧知で久しぶりの人を含めて多くの人に出会った。なかでも、すごく驚いたのは、会場でぜんぜん知らない人に突然声を掛けられて「いつもブログを見させてもらってます」と言われたのである。しかも、そのMさんはぼくの家の近くに勤務されていて、年齢もほぼ同じで、ブログに書いたことに興味と共感をもっていただいたようだ。今度、家の近くでお会いすることを約して別れたのである。こういう出会いもあるのですね。意見交換できることを楽しみにしています。
　

第5回BPMオフ会が4月23日に開かれます。詳しくは、"今年は違うよ、わきぶろぐ！"で書いてくれていますでそれをみてください。今回は、「Oracle OpenWorld Tokyo」のOTNラウンジの一画に設けられる“Unconference” で１次オフ会を行ないます。２次はいつものとおりビールパーティです。

それで、昨日はその発表者が集まってBPMオフ会のオフ会を行なう。結局しゃべるのは6人になる。はじめはLTという感じで軽くしゃべるのかと思ったら、どうも1時間半の時間をもらえるということで本格的なセミナーチックなものになった。

ぼくはまだしゃべることを何も決めていなかったが、他の人は既に宣言していたので、それぞれがかけ離れないようだいだいのストーリーを決めたので（羽生さんがバシッと決めて、市川さんがまとめてくれた）、それにあったようなテーマをとりあえず設定する。

主題は、“誰でもわかるBPM”とか“BPMの明日はどっちだ”とかいろいろな意見がでたが最終的に「いまさら聞けないBPM」になる。

このタイトルはぼくもいいなあと思う。というのは、昨日も言ったのだが、昨年半ばあたりからBPMの認知度も高まってきて、それ以前だと、BPMとはというところから説明しないと分からなかったのが、いまはそれをとばしても皆ついてくるようになった。

しかし、そこが曲者でいろんな人が入ってくるというのと裏腹に異なったあるいは間違った理解も増えてくるわけです。そうなると、基本的な部分はいつのまにか隠れた前提になって、より応用的、詳細技術的なところにいってしまうことになる。

ですから、BPMをはじめて勉強しようと思うと、基礎的な部分は知っていて当たり前だという雰囲気なのでそもそもBPMとはという疑問が投げれなくなることもあるような気がする。だから、そういう意味で原点に立ち返る議論を折々でやることは大切なことだと思う。

打ち合わせが終わってから、羽生さん、脇坂さん、大井さんと4人で近くの焼き鳥やで呑む。青山にこんな店があったんだという“おしゃれではない”店。女将さんがいきなり、何のスポーツ帰りですかと聞く。そういえば、ぼくを除いてみな図体がでかいのと荷物をしょっていたかららしい。しまいには蔵前からですかと言われてしまった。

それはそれとして、いつものように羽生節が炸裂でほんといつも聞いていて楽しくておもしろい。ぼくは、いまかなりフリーになったので、遠くから応援していた「ギョイゾー」をもう少し近くで応援しようと思う。

BPMが認知度が高くなったからといって、実際に導入という場合の敷居はまだまだ高いので、効果を実感するにはいろいろな会社で導入しないことには始まらないので、みんなで協力して広めたいのである。

4月23日の「BPMオフ会」１次、2次会（飲み会）ともぜひ参加してください。
　

IT用語では、３文字熟語が定番である。みなさん、あまりいい印象で話さないが、便利だからつい使ってしまうのではないでしょうか。中には、自分で勝手に３文字を作ってしまったりする人もいる。実はぼくだってBPPなんて言葉を作っている。ただ、３文字に替わって日本語で説明しようとするとかなり大変なことになる。

だから、概念やその意味するところを簡潔に３文字で表現できるということはある程度評価できるが、ときどきその弊害がでてくるように思う。それが、実体のないバズワードだから困るということもあるが、あるいは、定義が人によってまちまちになってしまうといったこともあるが、問題は思考のアプローチをねじ曲げてしまうことにあると思う。

それはどういうことかというと、３文字熟語が提示されると、それを理解しようとする態度がそれを招いているのではないかと思うのである。その言葉はどういうことを意味し、何をすることなんだという思考アプローチとなるからである。

ERPとはなんだ、SOAとはなんだ、CRMとはなんだ、ということを学習して、それを理解しようとする。でそれをいいものだと思うと（ときどき売れるものだと考えるひともいる）、それを普及しようとする。いいものだから使えというのだ。それを、受け売りという。人のふんどしで相撲をとるともいえる。

一見、そんなことは当たり前にやられているし、悪いことではないと思うでしょう。しかし、問題は、そうした結果自分の頭で考えることをやめてしまう思考停止の状態になるからだ。

ですから、それとは違う思考のアプローチが必要になってくる。自分の頭で考えたフレームに合うコンセプト・技術・サービスを採用するというアプローチである。それを考えるときに忘れてはいけないのが、何度も言っているビジネス視点・ユーザ目線である。使う人の役に立ってこそITの存在価値があるのだから、その視点でしっかり自分自身が考えることが重要なのである。

先日お会いした気鋭のITベンダーの社長さんが言っていた、これからは、for Userからby Userへと意識を変える必要があるということがすごく印象に残っている。

これまでITの作り手側はユーザのためにいいものを提供してあげるということを言う。ところが、そのいいものというのは、作り手側がいいものだと思っているだけだし、それも誰かが作った３文字熟語で表されるものを勉強し、その学習結果を売っているだけである。

そうではなく、ユーザ自身でできるようにサポートするのがITの本来の役割なのではないでしょうか。

最近、ぼくもBPMの普及というようなことを声高には言わないようにしている。BPMのよさはだれよりもわかっているつもりだが、ユーザがほんとうに知りたいのは、BPMの意味ではなく、自分たちのビジネスや業務に役に立つのか、企業が従業員が幸せになるのはどうすればいいのかである。

その幸せになる仕組み・仕掛けを一緒に考えた結果として、BPMがいいねと言ってもらいたいのである。
　

いよいよ、本日BPMオフ会です。前に案内しましたように、1次オフ会がOracleOpenWorldの”Unconference"の一環として開かれます。それが終わったあとが、2次オフ会で近くの居酒屋で行なわれます。

最初のオフ会は「いまさら聞けないBPM」と題して、6人のスピーカがそでぞれの立場でBPMについて話すことになっています。

ぼくも、その一人として「ビジネス視点、ユーザ目線から見たBPMがもたらす価値と変化」ということで、この価値と変化を理解しないでBPMを導入しても何も起こりませんよと言おうと思っています。他の5人も熱い人ばかりなのでおもしろいことになること請け合いです。

２次BPMオフ会の楽しいのは、ビールを飲みながら、年齢や会社を越えて和気藹々おしゃべりができることです。ぼくは、いつもほぼ最年長ですが、息子みたいな歳の子達と普通に話すと若返ります。

さて、今回は１次オフ会の模様が何とネット中継されます。会場に来られなかったひと是非見てください。
http://www.ustream.tv/channel/otn_japan
　
　

昨日は、５回目となるBPMオフ会があった。今回は、通常の土曜日開催ではなく、平日午後5時からということで、若干趣が変わっていた。しかも、第1部がいま東京国際フォーラムで開かれているOracle Open Worldのなかで行なわれた。

昨日、ご案内したとおりぼくを含めて6人のスピーカーによる「いまさら聞けないBPM」というテーマのプレゼンである。ひとり10分だから、簡潔にしゃべらないといけないので難しい。スピーカーの皆さんそれぞれ違った角度からのトークでまあまあだったのではないだろうか。まあ、羽生さんのファシリテーションで助けられた面が多分にあるのだが。

その羽生さんも言っていたが、Oracle Open WorldでもSOAという言葉は結構あるのだが、BPMは少ないように思う。もう少し浸透しているのかと思っていたが、このセッションの最後に質問を受けたら、“このBPMというのは何の略ですか？”というのが飛び出してびっくり。どうも途中から参加した人だったのだが、Oracleのフォーラムに参加している人の中にでもBPMをご存じない人がいたことに少し驚いてしまった。

近頃は、BPMの認知度が高まって、以前はBPMとはということの説明から入ったが、最近では、それをとばして、BPMをどう使っていくのかというところからはいっていけるようになったと言っていたのでありゃーとのけぞった。

その後は、帝国劇場の地下のそば屋で楽しい2次会です。今回は、最初に言ったように従来と変えた形式だったので、初めて参加するという人の方が多かった。そして相変わらず若い人が多く、一緒に参加したMさんがぼくより上だったのでかろうじて最年長は免れたが、親子のような年齢差である。

しかし、酒が入れば歳の差なんか関係なく熱い会話が飛び交うことになる。いつも言っているように、こういうオフ会は目的というか、関心事のベクトルが合っているから、初めて会ってもすぐ打ち解けて話せる。そして、お互いが勉強になる。いつものように楽しい夜であった。

先日のBPM協会コンポーネント部会は、季節がらなのかニューフェースが４人も出席して、新旧メンバーによるBPMへの思いを話しあった。

そこで話をしながら、あるいはその後のディスカッションで改めて、そうだ今唱えている「プロセス志向」はすごいパラダイムシフトを起こさせるトリガーになると意識させられた。

単にプロセス志向で業務システムを開発しましょうということでは全くないのである。プロセスを中心においた途端にその周辺のもろもろのことについて、従来とぜんぜん違う考え方をとらないとやっていけなくなる。

例えば、プロセス志向におけるデータベース設計はどうするのか、画面設計はどうするのだ、そもそも従来と画面のイメージが変わるかもしれないとか、開発プロジェクトの構成も進め方も違うだろうというようなことである。

まずは、影響を与える領域はどんなところがあるのだろうか。

１）要求分析・定義
２）プロセス設計・I/O設計・データベース設計
３）開発・製造
４）システム構築プロジェクト
５）保守・運用
６）要求人材・スキルセット
７）ユーザとベンダーの関係・収益モデル

こんなところが浮かんできます。おそらく、上記の全領域に少なからずのインパクトを与え、従来の考え方と大きく変わっていくのではないかと思っている。

これから、そこのあたりを少し詳しく見ていきましょう。ただし、他にもシステム構成とかクラウド・SaaSなどのインフラとかもあるかもしれませんが、それはプロセス志向に限った事ではないので言及しません。

どうも見わたしたところプロセス志向のための開発方法論がまだないと思うので、みなさんよく考えてほしいのだが、とりあえず我流であるが自分が思うことを書いていくことにする。
　

この未曾有の経済危機に対して経済学というものが役に立っているのだろうか。経済学というくらいだから、学問なわけだから、ある現象をみて、この現象はこういう原因で起きているから、こここう直せばよくなるという処方を示せると思っていたら、どうもそうではないらしい。

政府の大型財政出動をやれやれという人もいるし、その反対のことを言う人もいる。すぱっとわかるようなものではないらしい。じゃあ、どうして経済学なんてものがあるんだろうかと思ってしまう。

経済学といっても範囲が広く、行動経済学というようなものがあるかと思うと金融工学のようなものもある。心理学もありゃ工学もあるというわけである。しかし、どれをとっても自然科学に近いようなものではなさそうだ。

どうしてかというと、現象を起こす要素が多すぎて、しかも複雑に絡み合うからきっと大変難しいのである。だからこういうものは、うまくいっているときには、あたかも説明できたように感じるが、うまく行かなくなったときには役に立たないことになる。

これって、実は医学も同じことが言えて、病気になって初めて、医学が登場してくるが、ちゃんと論理的に治療できるわけではない。結局、乱暴な言い方をすると、同じような症状の人が前にいてその人は、こうした処方をしたらうまくいったから、それと同じようにしてみますというのが、採りえる方策となる。これを臨床医学という。

経済についても、病気になったら過去の状態と照らし合わせて対処法を考える態度が必要だと思うが、今の状況に置き換えると、アメリカは過去の日本の状況を反面教師としてそこから学ばなければいけないのだが、その評価がまちまちなのである。

おそらく、そうした病気をちゃんと総括していなかったのではないのだろうか。ほんとうの原因やほんとうに効いた対策などの見極めをしていなかったのではないかと思う。

さらに、飛躍して言うと、化学工場におけるプラントでも似たようなことが言える。化学プロセスというのは、ほかの生産プロセスと違って、目的の製品が狙い通りにできないという特徴がある。ちょっとびっくりするかもしれませんが、これだけ科学技術が進歩してもできないのです。なぜかと「化ける」からである。

こうしたプロセスでは、きちっと予測できないので、どうするかというと「臨床」的にみるのである。ある原料を仕込んである条件で処理した結果のデータを解析して、次に生かすというようなやり方である。

これらのことを、業務プロセスでも考えたほうがいいと思う。すなわち、業務プロセスを動かしてみて、その結果をうまくいったものも、うまくいかなかったものも全部蓄積し、そこから、その時点での処方箋を作っておいて、データが増えるたびにアップグレードするといった動的な仕掛けである。

ついつい今やっていることに結び付けてしまうが、どうも突き詰めていくと本質的なところでは共通した考え方に収斂していくことがあるという思いが強くなるのである。
　

プロセス志向でインパクトを与える領域として、ますは要求分析・定義について考えてみましょう。

そもそもこの領域は、日本においてはあまり重要視されていないように見受けられます。要求工学というような言われ方でアメリカなどでは盛んですが、わが国ではここをちゃんとやっているプロジェクトは少ないように思います。

経営戦略から事業オペレーションへ落とし、それを執行するためのＩＴはどうあるべきかというアプローチができていないということです。これまでは、パッケージをまずもってきてそれに当て込むようなやり方でＩＴ導入が行なわれて、しかもそれが経営戦略に合っているかというところまでいかずに、とにかくシステムを入れるんだというふうになっています。

なぜそうなっているかというと、ひとつは経営者のＩＴへの理解と期待が希薄であるということ、もうひとつは、実際に経営戦略や事業オペレーションをＩＴが実現できていないことにあると思います。すなわち、使う方と作るほうがお互いに信用していなくて、意思疎通できていないことにあります。それを、相思相愛の関係にもっていってこそ投資対効果もでるというものです。

プロセス志向というのは、業務プロセスが経営戦略から事業オペレーションにもっていくための重要な手段であると位置づけています。ですから、マネジメントにあなたのやりたいことをこの業務プロセスを使って実現してくださいという訴求ができるようになるのです。

どこにどのくらいの速さで行きたいかを決めてください、それに従ってカーナビ付きの車を運転してその目的地に行ってくださいというのが、簡単に言えば、プロセス志向におけるシステムの役割で、その車に相当するのが業務プロセスなのです。

プロセス志向以前は、システムは事業オペレーションの結果を登録するためのものであって、いささか飛躍するが「死体解剖」でしかなかったのです。良かったか悪かったかがわかっても、もう過去のことだから手の打ちようがないのである。ですからそれを「生体ドック」に変えていかなくてはなりません。いまどこが悪いのか、その程度はどのくらいなのか、どんな処方をしたらいいのかが分かることが望まれています。

そのためには、業務プロセスを可視化し、その動きがモニターできることが必須なのです。ですから、みなさんお気づきだと思いますが、プロセスを作って終わりではなく、それを自在にそして効率的に動かしてみて初めてプロセス志向といえるわけです。

逆に言えば、そうしたことができれば、マネジメントもＩＴの有効性を認めてくれるはずで、相思相愛の関係も生まれてくると思います。
　

このITProのIBMとCISCOに関する記事を読んで日本のベンダーの方々はどう思うのだろうか？これを何も感じないようならもう手遅れになる。

［IBM IMPACT 2009］「開発者はパブリック、企業システムはプライベートで支援」、米IBMがクラウド関連の新製品を披露

［Citrix Synergy 2009］「企業向けシステムもセルフサービスの時代に突入」、米シトリックスの年次カンファレンス始まる

最初のIBMの記事では、BPMソフトをSaaSとして提供する「BPM BlueWorks」と、企業内でクラウド環境を構築するためのアプライアンス製品「WebSphere CloudBurst」が紹介されている。

「BPM BlueWorks」では、「BPMソフトをSaaSとして提供することで、同一のビジネスプロセスにかかわる担当者同士が同じ画面を見ながら作業できるようになるなどコミュニケーションが格段に良くなる」と言っている。

そして、グループウエア機能である「Lotus Live」の技術を利用しているそうだ。これはわかりますよねえ、BPMのフロントエンドにグループウエアを持ってきて、コラボレイティブな場と連動させるのだ。

クラウドを企業内に適用させる意味は、セキュリティの問題解決やコストダウン、スケーラビリティなど多くのメリットがあると考えているわけです。実は、前にも言ったのだがこうした技術を、グループ会社を多くもつような大会社に持ち込むのはありで、社内SaaSやそれこそ社内SNSなどネットで行なわれているようなものを企業の範囲でやるのは有効なのである。

それに対して、CISCOの方は、「セルフサービス」ということを言っている。「消費者向けセルフサービスに慣れ親しんでいる世代が今後、入社してくる。こうした世代は、パソコンだけでなくスマートフォンなど、自分の好きな端末を利用しながら、自分で利用したいアプリケーションを選びたいと思うだろう」と言っている。

そうなんですよね、パソコンもさわるのがいやという世代がだんだん退職していき、携帯やネットでばんばん情報と戯れていた人たちが仕事をしに来るわけです。

そういう人にとって、今の企業の環境はどうなのだろうか。これから、確実に変わって行くように思われる。そこに対して、働く人が快適に過ごせるものをITが提供していくことが求められている。

両社が言っているところで重要なのは、「選択の自由」とういうことで、多様化する現代ではそのニーズに答えることが必要になる。これまでのように、担当に勝手にやらせたらまずいから、決まったことしかできないようにしようという経営とIT部門の思惑はもう終わりだろう。

まあ、昔は技術的な壁があったのでできなかったという側面はあっただろうが、いまや技術的な進展はすさまじいのでその制限もなくなったのである。

この2社以外でも、SAPやOracle 、Microsoftも同じようなベクトルである。だから、わが国のベンダーが彼らを所詮新しい物を出してユーザを煽っていると非難している間にどんどん取り残されてしまうだろう。目を覚ませ日本のベンダーたちよ。
　

今回は、プロセス設計・I/O設計・データベース設計について考えてみましょう。要するに設計方法が従来と変わるのかどうかということです。技術的な詳細については語るスキルもないのでここではコンセプチャルな面から捉えていきます。

まず重要なのは、“画面・帳票設計から入るな”ということです。これはけっこう象徴的なことで、従来からやられているのは、画面・帳票設計や業務フロー、データフロー設計といった外部設計があり、そしてプログラム仕様を作る内部設計といったやりかたです。（この外部と内部の設計という考え方がよく分からないのだが）

プロセス志向はあくまでプロセス中心でみていくわけで、プロセスありきから入っていきます。ですから、I/Oもプロセスが機能するためにどうあるべきかが問われてきます。データを登録するためにどんな画面が必要かという見方ではないのです。

もちろん、プロセスを回すためには、データを入力することがトリガーにはなるのですが、あくまで主体はプロセスで画面や帳票の存在意義は相対的に低くなってきます。

プロセスを回すためには、そのプロセスの構成要素であるアクティビティ（あるいはタスク）での処理の仕方がやりやすい、あるいは早くできるなどを重視した設計になるわけです。そうなると、従来型の画面では限界があるのがわかると思います。より自然な仕事のやりかたに近づけたいのです。

今はここのところがWebで実現できるようになったおかげで、単にデータを登録する画面ではなく、個人あるいはグループでコミュニケーションをとりながら処理（意思決定）を行なうことができる場が提供されるようになったのです。こうしたやり方は通常の仕事の進め方なわけで、ITがあろうとなかろうと行なわれていたことです。

昔はだれかの机のまわりに集まってワイワイガヤガヤやりながら、場合によっては電話やFAXを使って仕事をしていたわけです。今は電子メールが大きなウエイトを占めるようになり、隣に座っているひとともメールで会話するなんてことにもなっています。

このような仕事のやり方をネット上の共有的な空間でやれば、遠くの人も参加できるし、仕事がどう進んでいるかが見えるようになります。そうした時の画面と帳票はどうあるべきでしょうか。

まずは情報伝達のためだけの帳票は不要になると思いませんか。それと、少なくとも一人で画面に向かって作業して、それが終わったのでメールしてあるいは紙を流して承認を依頼するようなことは自然ではないように思えるのですがいかがでしょうか。

さて、次にデータベースの設計ですが、この領域でもプロセス志向だと変わるように思います。それを考えるときに、「データ志向」との対比の中でみるとわかりやすいかもしれません。

DOA（Data Oriented Approach）の場合のデータベース設計は、まずは画面や帳票からデータを抽出します。大ざっぱに言うとそこからリソース系のデータとイベント系のデータに分け、それぞれにリレーションをはり、ER図を書くということを行ないます。

ただ、これだと既存のシステムがベースですから、基本的にIT化の範囲で設計するということになり、非システム化領域をどうするのかという課題が残ります。また、イベントデータを時系列で並べるとプロセスになるかもしれませんが、やはりそれではフロー図になれた人にとってはわかりずらさは残ります。

ですから、今言ったようにデータ志向はどうしても画面・帳票主体になってしまい、プロセスの意識が薄いままであり、ビジネスの実相がつかみずらくなります。そういったことでプロセス志向のほうがユーザにとってわかりやすいものになっているのだと思います。

さて、そのプロセス志向におけるデータベース設計はどうなるのでしょうか。プロセスの目的と構造を考えてみましょう。そもそもそのプロセスが存在するのは何のためでしょうか。そのプロセスで処理した結果をビジネスの成果として蓄積することです。その成果はほとんどの場合「データ」として格納されます。

データには、イベントデータとリソースデータの２種類がありますが、まさしくイベントデータはこうして生成されます。リソースデータ（マスタデータ）の生成も、同じようにプロセスを経ることには変わりありませんが、それはデータ管理のためのプロセスです。

ですから、設計という観点から言うと、マスタは、プロセスとは離して、独自に設計した方が言いように思います。マスタというのはその会社の活動のもととなるリソースですから、もちろん様々なプロセスにも使われるし、戦略的な意味も込められる。それは、最初にきちんと分析して設計しておくことが大事であると考えています。

話はイベントデータに戻ると、プロセス志向だとデータをプロセスごとにもつのかという問題が出てきます。それだと、データの重複や管理の煩雑さがおこると言われそうです。

しかし、重要なのは、“プロセスの正規化”をきちんと行なうということで、重複するプロセス、似て非なるプロセス、標準化されないプロセスなどを排除することなのです。そうすれば、分散してデータをもってもかまわないし、必要に応じて仮想化で統合すればいいのです。こうした考え方に依拠したデータベース設計方法論が望まれるのだが、これをだれか作ってくれないだろうか。
　

さて、いよいよ開発・製造という段階のことになります。プロセス志向という場合、少し拡張して考えた方がいいと思います。すなわち、単にあるがままのプロセスを作っていけばいいというものではないわけで、前回にプロセスの正規化ということを言ったと思いますが、ある程度型にはまったもものにする、いわゆるパターン化をしましょうということです。

そのために必要なのは、「シンプルで一貫化されたきれいなプロセス」であることは何度も繰り返して言っていることですが、そのようなパターン化ができれば、いちいちコードを書く必要がなくなるということが重要なのです。最初からフレームワーク化しておけばいいからなのです。

ただし、このシンプルなプロセスは、パターン化できるレベルの話ですから、そのもっと下のレベルではあいまいなプロセスがあることも何回も言っていますが、そのレベルではゆるくして“場”を与えるようにするだけなのです。そこでは、仕事の流れをいちいちコードで記述するのではなく、情報共有させ、人が動きをつくるようにしておけばよいのです。

ここがプロセス志向の開発に及ぼすインパクトです。ユーザと対峙する開発プロジェクトでは原則コードを書かないことが大きな意味を持つのです。

少々脱線しますが、そもそも“業務システム開発”と言ったとたん、ええーとなってしまいます。こういう場合いったい何を開発するのでしょうか。“業務プロセス”を開発するのでしょうか、“ITシステム”を開発するのでしょうか。

開発というのは何もないところから新たなものを作ることだから、今までなかった新業務プロセスを作るということなのだろうか、もしそうなら、ITは関係ないはずです。ですから、システム開発プロジェクトでやることではないのです。

ではITシステムを開発するのでしょうか。それだったら、逆にどうしてそんなプロジェクトにユーザが入らなくてはいけないのでしょうか。それは、IT側で勝手にやればいいと言われてしまいます。だから、“開発”というのはそぐわない言葉なのです。

問題は、言葉だけのことではなく、実際のプロジェクトで“開発”をしてしまうことにあるのです。だから、思ったものと違うとか、それじゃだめだから変えてとか、最悪デスマーチとなるわけです。

もっと容易に“システム構築”ができることをめざすべきです。以前にも言ったことだが、家を建築するとは言うが開発するとは言いませんよね。家を建てるときにトイレを開発したりしませんよね。

あえて開発と言えば、部屋の形とか生活スタイルのところです。それは、むしろ好きなようにアレンジするといった方があっているような気がします。だから、プロセス志向の開発は、開発するのではなく構築あるいはアレンジするということになります。

そのためには、予め部品やフレームワークあるいはアダプターを用意しておき、それをユーザと顔をつき合わせて組み合わせてしまう工法が求められるのです。

もちろん、部品やフレームワーク、アダプターはコードを書きます。そこを開発プロジェクト段階ではなく、その前に製造しておくことが必要です。

こうすれば、いまのIT業界よりましな建築業と同じような業種になってくると思うのですがいかがでしょうか。
　

プロセス志向はシステム開発プロジェクトのすすめ方にも影響を与えます。まず大きな観点として、プロジェクト規模という側面と開発工程という側面から見てみましょう。

最初のプロジェクト規模では、これまではかなり広い範囲を一気に導入するビックバン方式がとられる場合も少なくはありませんでした。ERPの導入などはこの方式の方が、無駄なインターフェースを作らなくてもいいとか、データ移行と整合性の維持が容易といった理由からよく行なわれています。

ただ、これだと非常に多人数のプロジェクトとなり。そのマネジメントが大変でそこの調整コストが甚大となってしまいます。その点、プロセス志向では、部分的、段階的導入がやりやすくなると考えられます。

プロセス志向というのは、プロセスがシステムの骨格を形成するということだから、広義の解釈ではSOAという概念の上に成り立っていると言えます。このSOAの考え方は、一度に全部のサービスを一斉に動かさなくてもよく、しかもサービスの挿げ替えが可能ということですので、ビックバンではない導入方式がとれるというわけです。

一方、開発工程というところを考えてみると、従来のウオーターフォール型の開発は減ってきたとはいえまだまだ行なわれているのではないでしょうか。とくに大規模になればなるほどこの方式になります。

このウオーターフォールというのは、最終的にはシステム化要件からきちんとプログラム仕様書を起こし、それに基づいてコーディングするというのが前提ですから、前回の開発編で述べたようにコードを書かないシステム構築になっていった場合は、おのずと限界があると思います。

ですから、プロセス志向のプロジェクトでは、ユーザ要求から、それを実現するためのプロセスを設計し、コンポーネントを組みたてて実装してしまうわけですから、テクニカルスペシャリストというより、業務をよく知った人が少人数で作り上げてしまうという形態がとれるのです。

実際には、ユーザのひととFace to Faceでテンプレートを見せながら、ああじゃないこうじゃないと言いながら、組み上げるイメージです。セル生産やイテレーションの要素が入ったものになります。そうしたアジャイル的なシステム構築となるはずです。

そうなると、プロジェクトメンバーで必要な人材は、ユーザの人たちとプロセスをつくっていくビジネスプロセスデザイナー（ビジネスアナリスト）、システム構成を考え、セキュリティや運用設計ができるITアーキテクト、そしてできたらデータ管理をするデータアドミニストレーターがいれば、プロジェクトが回せることができます。

そして、この構築段階のプロジェクトでは登場しませんが、部品やフレームワーク、アダプターを予め作っておくクリエータの存在も重要です。これだけ少数精鋭にしておけば、非常に短い構築期間でしかも質の高いシステムを作ることができます。

こうして、プロセス志向は、ウーターフォール型開発から少数精鋭によるアジャイル的な開発への移行を促すのです。では、従来のコーダーはどうなるのでしょうか。これについては、人材編で書いていきます。
　

BPMを語るとき、それをカテゴライズして、HumanCentricBPMとIntegrationCentricBPMに分ける考え方が多くある。これは出自も影響しているから仕方ないのかもしれないが、こんなふうに分けてだから何なのという思いが最近強くある。

それぞれで構成要素や機能が違っているのでそれによって適用箇所を弁別しているといっているのだろうが、後ろにBPMとつけているとなると２種類のBPMがあるように錯覚する。

だいいち二つを切り離してBPMが成り立つのだろうか。切り離す必要もないし、いつも両方含まれているものだと思う。

二つに分ける考え方の背景には、業務プロセスには人間系のものとシステム系があって、それぞれを違う作りにするものだと言っているように聞こえる。これも、毎度のことだがIT側の勝手な言い分であって、ユーザの人が、今度うちの会社では人間系のシステムを導入しますなんて言うのだろうか。

そうではなくて、大前提が人間が仕事をして、それがつながっていき、その結果を出す、言い換えればその会社の事業活動の成果を作り出すことが業務であると考えると、それには、人間が絡むし、システムで自動化したり、最終的にはコンピュータの経理計算に預けていくわけです。

ですから、人間系とシステム系に分けることはナンセンスだし、今言ったプロセスがスムーズに流れる仕組みを作ることが求められるだけであると思う。

どうもITの世界はそうした技術寄りのカテゴリー分けが好きで、これはこういうジャンルのものでといったことを盛んに言う。そしてその違いを議論したりするのだが、それがあまり意味のないことだと気がついていない節がある。

IT用語辞典よりビジネス用語辞典の方がはるかに大事である。しかし、そういうものはほとんどないから、同じ業務プロセスなのに違う作り方で作ったシステムがゴマンと現れることになる。

BPMに限らず、こうしたことが起こるのは、上述のようにIT側の都合でカテゴライズすることも一因であるような気がするのだがいかがでしょうか。
　

一昨日、IPA（情報処理推進機構）主催の標記のイベントがあったので出かける。当初インフルエンザの影響で来場者はマスク着用とのことで、もし持参していなかった場合は入場をお断りする場合もありますというお達し。ところが、会場ではマスク姿もまばらで、まあそんなものだろう。

一昨日のお目当ては、特別講演「「信頼性に関わる実証的な試みの提言～重要インフラ情報システム信頼性研究会報告書から～」とパネルディスカッション「要求プロセスの実践と追跡性」である。

前者の特別講演は、東京大学大学院の中尾 政之教授による失敗学の話である。この人のことは以前「失敗は予測できる」（光文社新書）という本について書いているので、実際にお話を聞けるということで期待していた。

演題のポイントは、機械のようなハード的な失敗とソフトウエアの世界のものとの比較あるいは応用についてであったが、ぜんぜん違うという話である。

何が違うかというと、ひとつは、枯れた技術とそうでないという点で、例えば原子力発電の技術なんてはもう何十年も設計変更はしてないが、ソフトウエアはしょっちゅう新しい技術が登場してくる。それと、失敗の解析やそうしたデータベースがあるかないかということである。

ソフト開発プロジェクトで多くの失敗がありながら、そのデータが残っていない。その原因は、人が死んでいるかどうかということらしい。日航ジャンボ機の事故についても話してくれたが、やはり裁判になるから原因などの究明は徹底的にする。

しかし、ソフトウエアの世界では裁判にほとんどならないから隠れてしまっているのだというような話だったのだが、大方の内容は本で読んだことで新鮮味覇なかったので、関心をもっていた肝心の重要インフラ情報システム信頼性をどう確保するのかということについてはこれからということらしく、若干肩透かしをくらう。

次のパネルディスカッションは、コーディネータが玉井哲雄東大教授で４人のパネリストから、開発現場での要求プロセスをどうやっているのかについて議論することであった。最初にパネリストから予め用意されていた設問にコメントする形で始まった。その設問はだいたい次の４つである。

１． 要求プロセスはどの程度確定しているのか
２． そこではどのような手法を使っているのか
３． 要求の実施レベルや仕様品質とそれらがプロジェクトの成否とどう関係するのか、それをどう把握しているのか
４． 追跡はどのように行なっているか、それが信頼性にどうつながっていつのか

ところが、答えがばらばら。だから話が拡散して何が焦点なのか、論点なのかはっきりしなくなってしまった。ここで宇宙開発の話をしてもなじまないだろうし、要求定義と要件定義が混ざっているし、開発工数とその見積の話になったり、わけがわからない。唯一、IBMの榊原さんだけがまともで、そういう言う意味で国内SIerの限界を感じた。

結局、要求プロセス（この言葉もおかしい）というが、システム要件定義のほうにすぐにもっていってしまうし、相変わらず人月ビジネスをベースにして考えている。そして、ユーザ側への責任転嫁といういつもながらのパターンである。

そんな認識の中で、IPAが研究会などでこうすべきだといった方法論やツールを推奨したところで誰も使わない。少なくともIBMは独自でやるはずだ。

IPAの注力しているのが「見える化」ツールとデータベースということらしい。その重点対象分野が、「セキュリティ」「ソフトウエア・エンジニアリング」「人材育成」「オープンソフトウエア」ソフトウエア開発」の5つなのだそうだ。

ところが実際にやっているものは、「セキュリティ」「人材育成」あたりではないでしょうか。それはそれで意味があるように思えるのだが、そのほかの分野のところは一体何をやろうとするのだろうか。まあ、この話は別の機会にしましょう。

話を元に戻すと、要求プロセス（要求獲得プロセスといったほうがいいと思う）で今後重要なことはというまとめの質問に対して、これも榊原さんが言っていたが、非機能要件の記述とビジネスルールの抽出が難しいのでここを何とかしたいと言っていたのが印象的で合意したのである。
　

なぜプロセス志向が保守とか運用に影響を及ぼすのかを考えてみましょう。一見変化がないように見える領域ですが、実は大きな変化というか、変革をもたらすのです。というより、ここが非常に重要な意味を持つようになってきます。システムを作ることより、それを保守し、運用することのウエイトが相対的に高くなってくるのです。

プロセス志向では、業務プロセスを効率的に動かしてこそ事業に貢献できるということを重要視しています。オペレーションエクセレンスが主要目標になります。それは一時的ではなく、継続的な営みでもあり、不断のブラッシュアップが欠かせません。

こうしたパラダイムに適応した保守・運用とは一体どういうことになるのでしょうか。従来の保守・運用管理はシステムがダウンしない可用性や安定性を保持し、正しくデータを更新することに重きが置かれていました。いわば、ちゃんと決算ができることを担保することです。

ところがプロセス志向では、もちろん今のことは大事であることは言うまでもないのですが、それに輪を掛けて業務プロセスの稼動状況を把握し、適正にオペレーションできているかが大事になります。そのために、BPMSにはプロセスの制御や監視の機能が装備されています。

大事なのは、その機能を有効に使うには、“だれがどこに責任をもってオペレーションしている”かを明確にする必要があるということです。いままでだと、どちらかというとシステム側の稼動についての責任という見方でしたが、これからは、ビジネス側のプロセスオペレーションの責任が問われていくようになります。

実際にそうしなければ意味がありません。だから、基幹業務ではアウトソーシングなんてできないはずで、しっかりと自分たちの手でControl&Operation をしなくてはいけません。
　

先日、いつも見る数少ないテレビ番組のひとつである「情熱大陸」で水戸岡鋭治という工業デザイナーが紹介されていた。この人は、九州の鉄道車両のデザインを手がけるというユニークなデザイナーで、番組でも猫電車が登場していた。

年齢が62歳だからぼくらの同じ団塊の世代である。すごくエネルギッシュな人で見ていて感動したので、その人が番組の中で語ったことで印象に残ったことばをいくつか書く。

・ 売るためではなく使うためにデザインする

工業デザインの本領はこの“使うため”ということが非常に重要で、えてして見てくれだけでかっこいいものを作ればいいとなりがちだが、この機能性を追求することを忘れてはいけない。

・ 良いデザインではなく正しいデザインをする

ここらあたりも分かるようで難しいところだ。この違いをぼくなりに考えてみた。“良い”ということは、皆あるいは多くの人にとって“良い”ことはあり得るのだろうか。かなり難しいことのように思える。それに対して“正しい”ことは、普遍的であり、どんな場合にも通用することのように思える。ですから、まずは“正しいデザイン”をすることなのである。

・ 並走しないと若い人は育たない

上からの目線で教えてやるではなく、一緒になってやってこそ覚えるし、育つのだ。

で、この番組を見ていて、そうだ業務システムにも工業デザインの考え方を採り入れたらいいのではないかと思ったのである。この後見た「カンブリヤ宮殿」に出ていた川崎和男のこともあって、なおさら意を強くしたのである。

これまでの業務システムのユーザインターフェースをとってみても、決して使い勝手をよく考えてデザインされているわけではないと思う。大体のケースではIT開発者が従来の形態をなぞるようにして決めていることが多い。あるいは、最近ではウエブデザイナーが見た目はかっこいい画面を作ったりしている。

そうしたユーザインターフェースは本当の意味で使うひとのことを考えているとは思えないのである。どんな人がどういう仕事をこなすためにその画面を使っているのか、どんな機能がそこでは優先度が高いのかといった考察がなされているのだろうか。

場合によっては、同じ業務でもやる人によってインターフェースが変えた方がいいかもしれない。システムを操作するんだから、もう少しその操作性に気を使った方がいいと思う。

どうもこれからはこうした発想を持つ必要があると最近特に感じるようになった。そのためには、「使うための正しいデザインを若い人たちと一緒に考えて行こう」と思うのである。
　

ここに、「ITスキル標準　V3　2008」がある。これを参照しながら、プロセス志向における必要人材やスキルセットを考えていきましょう。

プロセス志向と言った場合、まず浮かぶのはプロセス設計のところだと思います。ビジネス要求を解析してそれを業務プロスに落とし込むところです。そこの役割を担うのはITSSではどのスキル標準なのでしょうか。

基本戦略系のコンサルタントでしょうか。それともソリューション系のITアーキテクトあるいはアプリケーションスペシャリストでしょうか。どうもいずれもちょっと違うように思います。ということは、業務プロセスを設計する人材のスキルセットがないということになります。

経営とITの融合とか言っていてもそこの橋渡しをする人材を定義していないのです。先日もこのITSSに実際に携わっているひとと話したときも、ここが抜け落ちていることを認めていました。

これからはビジネスアナリストとかビジネスプロセスデザイナーといった、名前はともかくとして、そうした役回りの人材を置くことが非常に重要になってきます。経営戦略や事業実行方針をちゃんと理解し、それをITで実装するところをマネジメントできる人たちである。

さて、先回のプロジェクト編でも書いたように、プロセス志向では、少数精鋭で素早くプロジェクトを回していくようになるわけで、そうなると、必然的に多能化ということは避けられないと思います。ですから、ITSSにあげられているような細分化したスキルではなく、もう少し広い範囲の能力が要求されてきます。

そして、大きくビジネスエンジニアとテクニカルエンジニアの2極分化と相互融和が図られるものと推測しています。すなわち、ビジネスの要求をきちんと理解し、その業務プロセスをどう実装するのか、どうオペレーションしたらいいのかを的確にユーザに提供できる人材とビジネスを俊敏かつ効率的に回すための仕組みに必要な機能を設計し、コーディングできる人材である。さらに、この異質の人材同士でコミュニケーションが取れることも必須である。

ITSSもそうですが、各企業のなかでもこうした必要人材の配置を急ぐ必要があると思います。ただし、そうはいってもという事がもちろんありますので時間がかかるかもしれません。さらに、こうしたスキル価値が変化するわけですから、従来のように仕様書に基づいてコードを書いていた人たちはどうなるのかという問題があります。

きれいごとで言うと、ビジネス寄りにいくか、クリエーターとして究めていくかになりますが、もうひとつは、運用エンジニアとして生きる道もあるような気がします。運用といっても従来のようなシステム運用というより、ユーザが行なうビジネスオペレーションに対するサポートという領域が重要になると思っています。

少なくとも、これからの必要人材スキルは変化していくものと思われるので、ITSSにとらわれないで今のうちに準備しておくことかもしれません。

さて最終回は、ユーザとベンダーの関係の変化、あるいはIT業界にもたらす影響などについて考えてみましょう。

これまでの議論で、システムの構造から設計・開発や運用のやり方、プロジェクトの進め方、必要人材など多くの領域でこれまでとは違ったものになっていくことがお分かりになりましたでしょうか。

そうした変化は当然、ユーザとベンダーの関係にも影響していきます。直接的には、プロジェクト体制やマネジメントが変わって行くでしょう。

ここでこれまでの両者の関係をみてみましょう。簡単に言うと「情報の非対称性によるインセンティブの歪み」が特徴的であるように思います。

どういうことかというと、情報システムに関する情報は、専門家であるベンダー側のほうが圧倒的に情報を持っていて、ユーザ側の持つ情報は多くはありません。まずは、この情報のアンバランスがあります。

こうしたアンバランスがもたらすものは何かというと、悪く言うとベンダーが何をしてもユーザはわからないということなのです。ですから、ユーザはベンダーから開発にこれだけ人月がかかりましたからお金をくださいと言われても、高いけどしょうがないなあと言って支払うのです。こんな関係がいいわけありません。

こうした歪みを修正できる可能性がプロセス志向にはあります。なぜなら、ユーザが自分たちで作りたいと思ったシステムがそのまま実現できるようになり、しかも初期の段階でその姿が見えるようになるからです。

専門的、技術的なものは隠蔽されたビジネスコンポーネントをベースにユーザとベンダーが会話するのです。

こうしたことは、ユーザにとっては僥倖ですが、ベンダーにとってはどうでしょうか。問題はここにあります。このモデルでは、おそらく従来のようなコストとは全く違ったものになるはずで、大方のケースで低く抑えられるようになります。

ウオーターフォール用にたくさん抱えた人材を遊ばせることになりかねないので大変なことになってきます。だからといっていつまでもユーザが知りませんということはないのであって、徐々にユーザは気が付き出しています。

普通に考えれば、ITはそもそも使われてナンボですから、使われ方や使うものが変わったら、当然そのビジネスモデルも変化するのです。それを、自分たちのビジネスを守るために、ユーザに不当に費用を負担してもらうなんてことは本末転倒なのです。

そういう意味では、ベンダー側がユーザより先んじてビジネスモデル、収益モデルを変えていく必要があるのですが、どうも自己保全に軸足がいっているようでお先が思いやられます。こんことをしていると、わが国のSIerと呼ばれる会社はどうなるかはおわかりですよね。
　

このところBPMとSOA関連のエントリーをいろいろ書いていますが、それは業務プロセスのパターン化が可能で、かつ、実装が容易なアプリケーションフレームワークを、今まさに作っている、という理由からです。

ただ、ブログエントリだとどうしても細切れになるので、どうやって業務プロセスを設計するのかということと一連のモジュールやプログラムを組み合わせて、どうやってフレームワークを作るのかという話を YAPC::Asia 2009 でさせていただくことにしました。

YAPC::Asia 2009 は9月10日(木)と11日(金)の2日間、東京工業大学大岡山キャンパスで開催されます。すでにチケット販売も始まったので、興味のある方はお越しいただければ、と思います。

・YAPC::Asia 2009
・Yet Another BPM Framework”Kailas”