メイン

BPM関連 アーカイブ

2008年3月10日

要件定義ということ

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

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

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

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

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

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

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

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

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

2008年3月11日

ソフト産業は自動車産業か?

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

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

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

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

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

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

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

2008年3月12日

BPMに対するサッカー的一考察

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

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

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

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

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

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

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

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

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

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

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

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

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

2008年3月17日

内部統制の熱気

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

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

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

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

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

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

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

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

2008年3月26日

海外BPM最新情報

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

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

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

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

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

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

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

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

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

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

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

2008年4月 7日

BPMオフ会でしゃべります

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

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

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

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

2008年4月 8日

社内SaaSのすすめ

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はプロフェッショナルサービスから、そして社内から始めたらいいのではないでしょうか。
 

2008年4月13日

第3回BPMオフ会

昨日、第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階に分かれてしまい、なおさら移動が困難であまり多くの人と話すことができなかったのが残念であった。はぶさんともほとんど話せなかったし、しかもはぶさんは珍しく1次会だけで帰っちゃったのだ。

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

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

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

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

2008年4月18日

SaaSはどうなるのか

いま、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から始めたらどうかと言っているのである。
 

2008年4月20日

SaaSはフルアウトソーシング?

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

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

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

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

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

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

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

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

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


2008年5月 1日

フリーダウンロードキャンペーン

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

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

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

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

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


2008年5月17日

きた~BPM!

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

参加者が千数百名ということで、午前中の基調講演は1ヶ所で行なわれたが、午後からの個別セッションでは5会場に別れた。ぼくは、ほとんど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)へ
・ビジネスの「産業化」=オペレーションエクセレンス
・機能指向からプロセス指向に
・モデリングは、目的の明確化、規則を定める、利用ツールの特定が重要
・規則とは、命名規則、プロセス層の数(3~4)/深さ、プロセス粒度、1枚に書くタスク数(15以下)、イアウト、色の使い方、コメントの使い方、分岐条件の使い方
・企業IS部門の役割、責務が重くなる(ビジネスとITの仲介)
・SOAによる段階的システム導入

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

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

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

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

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

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

2008年6月19日

潮目が変わる

これは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」で記事を書いていますので参考にしてください。
 

2008年6月25日

コラボレーションとコミュニケーション

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

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

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

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

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

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

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

2008年7月 1日

BPMオフ会

昨日は第4回BPMオフ会。3つのセッションがあって、iknowの紹介、YAWLと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さん毎度のことながらご苦労様でした。
 

2008年7月 5日

今大阪です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2008年7月10日

整理をしないという整理のしかた

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

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

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

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

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

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

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

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

2008年7月15日

IBMのジレンマ

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

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

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

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

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

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

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

2008年7月16日

業務プロセスの自動化

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

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

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

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

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

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

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

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

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

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


2008年7月22日

プログラミングファーストでもまだ中途半端

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2008年7月25日

経験と情熱、意欲とセンス

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

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

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

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

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

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

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

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

2008年9月17日

自動化のワナ

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

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

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

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

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

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

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

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

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

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

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

2008年10月 6日

ラグビー型システム

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

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

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

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

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

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

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

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

2008年10月15日

プラント情報管理とビジネス情報管理

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

化学プラントの管理の基本はプロセスコントロールである。それには、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というような名前をつけようかと思っている。

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

2008年10月17日

オペレーションからの発想

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

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

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

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

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

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

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

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

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

2008年10月27日

情報共有型ワークのすすめ

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

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

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

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

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

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

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

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

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

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

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

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

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

2008年10月28日

振り向けばSOA

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

ところで、いま渡辺和宣さんと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”というのは言いえて妙である。

2008年10月30日

競争優位の源泉

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2008年11月 2日

情シスの逆襲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2008年11月 3日

ギョイゾー!はヤバイ!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2008年11月 6日

サイモンの意思決定プロセス

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

サイモンの意思決定のプロセスというのは、
1. Intelligence Activity(情報活動)
2. Design Activity(設計活動)
3. Choice Activity(選択活動)
ということになる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2008年11月19日

マクロSOAとミクロSOA

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

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

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

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

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

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

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

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

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

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

2008年11月20日

ギョイゾー!はイイゾー!

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

プログラムは、
1.どうしてBuriが必要になったのか
2.Buriの基礎
3.Buriエディタ自慢
4.Buriを使う場合の設計の勘所
5.ギョイゾー!生Live

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

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

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

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

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

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

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

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

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

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

2008年11月27日

発生点入力

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

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

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

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

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

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

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

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

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

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

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

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


2008年11月28日

開発体制が変わる

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

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

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

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

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

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

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

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

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

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

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

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

2008年12月20日

BPM-J交流会

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

1.キーノート
(1)BPMの基礎知識          :織田新一氏 SAPジャパン株式会社
(2)BPM市場の米国状況と普及課題 :宇野澤庸弘氏 日商エレクトロニクス株式会社
(3)SIの抱えるジレンマと解決方向  :岩田アキラ氏 日揮情報ソフトウエア株式会社
2.パネルディスカッション
(1)株式会社アイヴィスソリューションズ   代表取締役社長 横田 元 氏
(2)株式会社ビズモ               代表取締役 鈴木 高弘 氏
(3)株式会社アイ・ティ・フロンティア     執行役員 大三川 越朗 氏
(4)ニュートラル株式会社           取締役 渡辺 博和 氏
(5)岩田 アキラ氏
(6)織田 新一氏
 モデレータ 宇野澤 庸弘氏

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

今回のテーマが「BPM/SOA時代にITビジネスはどうあるべきか」であるので、そのことについて少しふれておく。

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

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

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

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

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

先週のBPM-J交流会はそんなことを考えさせられたセミナーであった。
 

2008年12月23日

SOA開発方法論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


2009年1月21日

ミニオフ会

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

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

息子と同じくらいの歳だから何か変な感じだけど、ブログで情報を知っているので、別段話づらいなんてことはないわけで、むしろ共通の話題があるから歳なんて関係なしにすぐに打ち解ける。もちろん、話の中心は、SOAやBPMで、ただぼくがひとりでしゃべってばかりいたようで申し訳なかった。(begiramaさん、悲喜子さん、ごめんなさいね)

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

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

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

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

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

2009年2月18日

プロセス志向イノベーションフォーラム

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

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

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

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

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

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

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

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

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


2009年3月31日

BPMオフ会

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

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

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

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

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

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

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

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

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

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

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

2009年4月17日

3文字熟語のワナ

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

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

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

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

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

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

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

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

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

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

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


2009年4月23日

いまさら聞けないBPM

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

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

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

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

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


2009年4月24日

第5回BPMオフ会

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

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

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

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

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

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


2009年4月30日

ビジネス臨床学

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

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

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

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

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

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

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

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

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

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

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

 

2009年5月 8日

取り残される日本のベンダー

この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も同じようなベクトルである。だから、わが国のベンダーが彼らを所詮新しい物を出してユーザを煽っていると非難している間にどんどん取り残されてしまうだろう。目を覚ませ日本のベンダーたちよ。
 

2009年5月21日

BPMのカテゴリー

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

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

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

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

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

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

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

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

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


2009年5月29日

IPAX 2009~日本の元気を、ITで!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009年6月10日

業務システムに工業デザインの発想を

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

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

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

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

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

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

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

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

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

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

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

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

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

2009年8月12日

YAPC::Asia 2009 で「BPM Framework”Kailas”」について話します

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

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

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

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

2010年9月16日

競争の作法

本を読んでいる時、たまに腑に落ちるというかはまることがある。これは、内容に合点がいくこともあるが、何より作者の思いに相槌を打つからである。そんな作者が書いた本である「競争の作法」(斎藤誠著 ちくま新書)に出会う。

何と言っても作法と言っているところがいい。いつも作法の言い回しが気にいって使っている身にとっては我が意を得たりという気がしないでもない。著者は経済学者なのだが、経済学の専門的なことがあまり出てこないで、この競争社会とどう付き合っていったらいいのかといったことが書いてある。作法とか心得といったところである。

ということで小難しいことはいっさい書いていない。門外漢のぼくでもよく理解できる。これは冒頭でも言っているように、感覚的に似たものがあるからかもしれないが、冷静に考えれば考えるほど著者の言わんとすることに賛同する。この冷静さは、きちんとした(難しくなく簡単なもの)データで語っているからである。

さて、その言わんとするところを結論的に言うと、エピローグでまとめている次のことになる。

(1) 一人一人が真正面から競争と向き合っていくことである。
(2) 株主や地主など、持てる者が当然の責任を果たしていくことである。
(3) 非効率的な生産現場に塩漬けされていた労働や資本を解き放ち、人々の豊かな幸福に結びつく活動に充てていくことである。

こうした提言のもとは、2002年から2007年までの「戦後最長の景気回復」を果たしたと言われる現象をつぶさに分析したことにある。詳細は本にゆずるとして、かいつまんで言うと、この間みかけの豊かさをもたらしたが、幸福をもたらすことはなかったということをデータで示してくれる。

経済学でいう豊かさとは、生産活動によって生み出されたものの価値の総量であり、幸福とは、その生産されたものを消費することで享受できる効用の大きさである。「戦後最長の景気回復」期におけるこの豊かさは、2つの円安がもたらしたバブルにすぎなかったのだ。

そこで著者は、人々が幸福になるにはどうしたいいのかを考えるのである。そうすると競争がない平等な社会こそ皆が幸福になれると主張する人々がいる。それに対して著者は言う。いまの状況は「競争原理を貫いたから、平等原理に抵触した」のではなく「競争原理を大きく踏み外したので、所得分配上の深刻な問題が生まれた」という。

その詳しい理由は本を読んでもらいたいが、競争原理に向きあうということは、けっして利己的で自己中心的になることではなく、経済合理性や他者への配慮をもつことで、自分自身の中にある保身と嫉妬の心情を抑え込み、新しい生き方を考える契機として競争と前向きにつきあうことだと言っている。

それにしても日本人はどうしてこうも競争がきらいなのだろうか。きっと、この保身や嫉妬をもった人間が多いということかもしれない。このことについてのおもしろいエピソードを書いている。もし貧困化がさしせまった問題であったとすれば、貧困や格差社会に関する書籍があそこまで売れることははなかったはずだという。貧者は買う余裕はなく、冨者は興味がないからである。

ということは、そうした本を買うのは普通の人々なのである。この人たちは、自己保身から自分の給与が下がるのを避け、嫉妬から優れた他人の給与を引き上げるのを嫌悪する性向があるのだ。自他の給与格差が広がることを不快に思うのである。

たしかにこういう人たちは競争を忌避する傾向が強いが、だからといって職場から、学校から、役所から追いだすわけにもいかないから、さてどうしたものか。しかし、自分たちが幸福になれるような競争社会は可能だと思うので、一人一人がそのことを真剣に考え、取り組んでいくことなのだろ。そんなことを考えさせられる良書である。ぜひご一読を。
  

競争の作法 いかに働き、投資するか (ちくま新書)
posted with yusukebe.com::AmazonSearch on 2010.9.14
  • 齊藤 誠
  • 新書 / 筑摩書房
  • Amazon 売り上げランキング: 4278
  • Amazon おすすめ度の平均: 4.5
    • 5 1990年代バブル崩壊以降の日本は失われていない
    • 4 的確なマクロ分析と新たな競争観の提示
    • 4 幸せの尺度を変えれば幸せになれるのか?
    • 5 地道が大切!?
    • 5 今後の日本のあり方を示唆する一冊
Amazon.co.jpで詳細を見る

  

2012年2月15日

BPMの最新トレンド

BPMの最新トレンド

岩田研究代表の岩田アキラさんが、米国のBPMコミュニティ誌「BPTrends」におけるポール・ハーモンとセリア・ウォルフの最新の投稿について記事を書いている。それによると、BPMもだいぶ変化を見せてきたようだ。

大きく5つのポイントをあげている。

1.BPMは”IT活動”ではなく”ビジネス・マネジメント活動”との認識が広まった
2. プロセス改革アプローチを強調するプロフェッショナルの堅実な需要
3. プロセス・モデリングの企業内浸透と組織パフォマンス向上の多様なテクニック論
4. BPMS市場の変化
5. BPMへの国際的な関心の高まり

詳しくは記事を読んでもらえればいいのですが、岩田さんも最初に“この変化傾向は、日本BPM協会メンバー間でも予見していた事項で、同レポートを読んで「やはり..海外でも..」といった感想である。”と言っているが、ぼくもこの協会メンバーの一員であるので確かに最近の議論の内容によく似ている。

このたび日本BPM協会では「BPM推進フレームワーク」をリニューアルしたが、BPMは”IT活動”ではなく”ビジネス・マネジメント活動”という意識が強く働いている。従って、BPM推進には「プロセス改革推進」「プロセス開発」「プロセスオペレーション」の三位一体の取り組みが大事だと謳っている。

そして、それを担う人材として、ぼくはビジネスエンジニアとよんでいるが、レポートにあるようなビジネス・アナリストとかビジネス・アーキテクトといった人材が望まれるようになったのである。システム・エンジニアとかITアーキテクトではなくあくまでビジネス視点を持った技術者である。

3に書いてあることは、1に呼応しているわけだが、以前はBPMというとBPMソフトウエアを使ってシステム開発を行うという意味合いが強く、従ってユーザ側も開発方法だからベンダーにまかせればいいやという感じでもあった。

しかし、プロセスを設計することは、ITシステムを設計することではなく、自分たちの業務を設計すること、しかも業務は戦略や改革要求を実現するものとして設計しなくてはいけないことに気がついて、そうなるとベンダーなんかにやらせるわけにはいかないとなってきていると思うのである。

やっと、ビジネス寄りでBPMを考える機運が海外で出てきたことをうれしく思っている。日本では、いくら国内で声をあげてもなかなか取り上げてくれないので、海外でのこうした声が早く日本に届いて理解が進むことを願ってやまない。

2012年8月 1日

人種とスポーツ

いまちょうどロンドンオリンピックの最中でまさにあらゆる人種の人たちが一堂に会してスポーツで競っている。タイミングよく「人種とスポーツ」(川島浩平著 中公新書)を読む。ただ、著者はアメリカ研究者なので主にアメリカの黒人に的を絞って論議が展開する。黒人は本当に「速く」「強い」のかということに答えようとしている。

ぼくはよく冗談で足の遅い黒人やリズム感のない黒人を見たことがないという。やはり、オリンピックの陸上男子100m決勝でスタートライン立った56人は、ここ30年すべて黒人であることから白人に較べて黒人の方が圧倒的に足が速いと思いこんでいる。そう刷り込まれている。こうしたステレオタイプはいつから存在して、どのような理由で生まれ、普及していったのかを分析している。

まずもってなるほどと思ったのは、黒人の定義である。アフリカ大陸のサハラ砂漠以南の地、すなわち「サブサハラ」を出自とする人およびその子孫のことなのだそうだ。何となく肌が黒ければ黒人と思ってしまうがそうではないのだ。そして彼らが生まれつき身体能力が優れているという生得説も正しいのかどうか。

それを著者は、ベースボール、フットボール、バスケッットボールといったアメリカンスポーツと黒人の関わりの歴史からひも解いていく。これがおもしろいのだ。もちろん奴隷解放の以前なんてスポーツとは無縁であるが、その後南北戦争を経て徐々に黒人もスポーツに参加するようになってくるのですが、19世紀ではまだほんの一握りであった。

20世紀に入ると近代スポーツが広く愛好され、著名なアスリートが登場して来るがそれはあくまで白人であり、黒人は人種分離体制のもとで活躍の場は限られたものであった。だが、徐々にではあるが黒人の優れたアスリートが輩出されてくる。その理由の一つが、職業選択が極めて制約された中で、スポーツが開かれた新たな分野となったからでもある。

そうなると、なぜ黒人から優秀なアスリートが生まれてくるのかについて諸説が出てくる。そのなかに「アメリカの黒人は生まれながらにしてスポーツ選手だ。綿畑でつらい仕事をしてきた世代は、アフリカ原住民の強さと伝統を失ってはいなかった」さらには「黒人のように多数の人間が、生存競争の激しい試練を乗り越えた集団はアメリカには存在しない。この点からいうと、黒人はアメリカでもっとも選び抜かれた種である」といった議論も展開され出す。

そして何といっても確たる地位を築いた最大の功労者はジャッキー・ロビンソンであろう。1947年にMLBのドジャースに入団したロビンソンはその後大活躍する。その影響は当時の時代背景もあって大変大きなものであった。第一に、黒人に対する偏見の軽減あるいは払しょくであり、第二に、スタジアムで展開されるチームプレーが白人と黒人の共働野可能性を示したこと、そして三番目にアメリカ社会の人種関係の将来像を示したことであった。

こうしたことから、ステレオタイプとしての生得説つまりもともと優れた身体的能力があるということが喧伝されて来るが、著者は根拠がないと言い切る。つまり、ひとくくりで黒人ということに無理があること、例えば西アフリカ、東アフリカでは違っている。陸上競技を見ても分かるようにウサイン・ボルトは西アフリカ、中距離は北アフリカ、長距離はケニアやエチオピアの東アフリカというふうにそれぞれ特徴があるのだ。

また、長距離王国ケニアにしても実はトップアスリートは一部の地域に集中している。ナンディという集団にほとんどが所属しているのだという。そこには特徴的なものがあって、強い精神力、生活習慣、経済活動(牛を強奪したあとひたすら走る)などが相俟ってそういった集団を形成するのだという。

つまり、生得的な資質ではなく様々な要因により得られた能力であるということ。家族や集団、部族といったもの、時間・時代的文脈、地理・空間的文脈、現象が発生する契機となる状況などである。比較文化人類学としてもなかなか面白いですね。
  

人種とスポーツ - 黒人は本当に「速く」「強い」のか (中公新書)
川島 浩平
中央公論新社
売り上げランキング: 7198

 

2012年8月12日

ワークショップ入門

今ぼくが仕事でやっているようなことは、メソッドがあってそれを習得してもらうというより、一緒になって考えて行きましょうという類のものである。先日も仲間のMさんと飲んでいたら、ぼくのやっていることはコンサルティングではなくカウンセリングであると言われた。どうもコンサルティングというのは、このようにやりなさいという教えを説くことだと考えているとしたら、ぼくのやり方は確かにコンサルティングではない。名刺の肩書きも変えないといけない。

ではカウンセリングの進め方は、1対1だと相対して話をするというイメージだが、複数の人間を相手にするとなるとワークショップ形式になるのではないかと思っている。そんなこともあって「ワークショップ入門」(堀公俊著 日経文庫)を読む。以前、このブログでも紹介した「ワークショップ」(中野民夫著 岩波新書)はどちらかというと広く概念的な感じであったが、こちらの方は実践的というかビジネス寄りである。

先々月からVCPCのワーキング活動の推進者をやっていて、その進め方もワークショップ形式を採用しているので勉強になった。これまでは、多くは講義方式というもので、講師がいてその人がパワーポイントを使って教えて、それを学習するというスタイルである。一方的な関係である。ぼくなんかこの歳になると2時間も何も喋らないでただ聞いているなんて耐えられない。そういう意味で双方向のコミュニケーションが主体のワークショップはもっと採り入れていい形式だと思う。

さてそのワークショップのキーポイントとなる要素は次の5つになる。「参加」、「体験」、「協働」、「創造」、「学習」である。これらを見ると、研修だとか会議だとかとずいぶん違うことがわかります。この考え方は、最近のネットの世界にも似ています。Web2.0なんて流行りましたがあの精神に似ていなくもない。

本ではワークショップのタイプを4つに分けています。
(1) 組織系(問題解決型)ワークショップ
(2) 社会系(合意形成型)ワークショップ
(3) 人間系(教育学習型)ワークショップ
(4) 複合型(変革型)ワークショップ

ビジネスの世界だと(1)の問題解決型が多そうですね。今やっているのもそうなんですが、実際には複合型だともいえます。つまり問題解決と言いながらも実際には合意形成や教育学習といった効果もある。例えば、業務改革プロジェクトなんかも複合型ワークショップで進めるのが効果的です。現状の問題を抽出して課題として解決策を考え、その解決策はみなの合意を得る。そうした活動の中で参加者が成長するのである。

ただ、ぼくの立場からいうとこうしたワークショップを正しく導いていくのが難しいのである。そのためのスキルが3つあるという。「チーム・デザインのスキル」、「プログラム・デザインのスキル」そして「ファシリテーションのスキル」である。これらは非常に大事なスキルである。このように、キーポイントとなることをいくつかにまとめて整理してくれているのでわかりやすく、時々は開いて確認することにする。
  

ワークショップ入門 (日経文庫)
堀 公俊
日本経済新聞出版社
売り上げランキング: 39787
  

2012年8月14日

汚れた心

終戦の時にブラジル移民の中で勝ち組と負け組に分かれて骨肉合い食むような抗争があったことは知ってはいたが、詳しくは知ろうとも思わなかった。ところが、ぼくの映画友達のS君がわざわざチラシを送ってくれて一緒に観ようと誘われたのが、その史実に基づいて作られたという「汚れた心」という映画であった。

最初は、日本の映画だとばかり思っていたら、ブラジル映画である。監督もブラジル人の、ヴィセンテ・アモリンである。ナチス台頭下のドイツを描いた「善き人」で評価が高かった監督である。出演が伊原剛志、常磐貴子、奥田瑛二、余貴美子らである。

第二次世界大戦直後、タカハシ(伊原剛志)は妻ミユキ(常盤貴子)とサンパウロ州の小さな町で写真館を営んで暮らしていた。そこで暮らす多くの日系移民たちは情報を遮断されたままの状態であったので、日本軍の勝利を信じて疑わないでいる。そんな時、元陸軍大佐ワタナ ベ(奥田瑛二)たちが、禁じられている集会を開き、当局とトラブルになる。

そこから、ラジオ放送で日本の敗戦を知った組合長や通訳たちのグループと、ワタナベ、タカハシたち日本の勝利を疑わないグループが対立していく。ワタナベは"国賊"と断じて、タカハシに通訳の抹殺を命じる。タカハシは逆らうことができずに通訳を惨殺してしまう。そうなると対立はエスカレートしていき次々と粛清されていく。そんなタカハシの姿を見て妻のミユキは夫の元から去っていってしまう。

さすがにわずかではあるが、情報も入ってきて天皇陛下とマッカーサーの写真とかを見せられてくるとタカハシの中で、ワタナベに対して疑念を持つようになる。疑念をもつことはまた危険な状態に陥ることを意味している。そして、・・・。

もちろん、映画の内容そのものはフィクションではあるが、勝ち組と負け組の抗争はあったわけで、しかも8割は勝ち組だったといわれ、驚いてしまう。情報が遮断され、純粋培養された日本人にとって皇国日本が負けるわけがない、というか負けてはいけないと思い込んでいたのだろう。とくに移民として抑圧された人々にとってそこだけがよりどころだったのかもしれない。

映画を見終わってS君と歩きながら話していたとき、彼はJICAにいたので移民の帰国事業の手伝いをしたときのことをしゃべりだした。ちょうど沖縄から行った移民が帰ってくるというので迎えに行ったら、タラップで天皇陛下万歳と叫んだそうだ。それが、昭和48年だったという。戦後30年近くたってもそうした心情を持ち続けていることに驚かされる。

アモリン監督はインタビューで「これは適応とアイデンティティについてのストーリーであると同時に、サスペンスやラブストーリーにもなり得ると感じました。戦後ブラジル日系人社会のなかで起きた抗争の物語は、現代に生きる私たちにとって切実な問題――不寛容、人種差別、原理主義、真実という概念――を孕んでいます」。決して、あの時代、あの場所だけの特殊な物語ではないのだろう。

このような日本人の特異性についての映画を外国人が撮ることの意味を考えさせれた。ぼくは、成功したと思っている。こうした映画は客観化された目で見ないと成功しないと思うのでよかったのではないか。ただ特殊な物語ではないといってもアイデンティティとしての天皇ということや日本人の間に漂う空気感を外国人の観客はわかるだろうか。

アモリン監督の力量も高く、"汚れた心"を勝ち組が負け組に向かって言わせながら、自分たちに"汚れた心"が芽生えてくるように見せたり、勝ち組にそれには大儀がなくてはいけないし誇りや矜持がなければできない"自決"させなかったこと、ワタナベにハーモニカでふるさとを吹かせること、ミユキに鶏を殺させるなど感心する演出でおそれいりました。
  
kegaretakokoro.bmp
  

2014年6月 3日

調子があがってきたぞ

日本時間の今朝行われたサッカー日本代表の国際親善試合でコスタリカ相手に3−1で逆転勝利を収める。アメリカで合宿中の代表は当地フロリダのタンパで北中米地区を勝ち上がってW杯に出場するコスタリカと強化試合を行った。相手はFIFAランクで日本より上だから、その相手に勝ったのだから結果派よかった。

先発が、いつものメンバーから、長友、遠藤、岡崎、長谷部、柿谷に代わって、青山、大久保、大迫が入る。おそらく、あまり試合にでていない選手の連携を確認したかったのだろう。立ち上がりは、まだコンディションもピークではないこともあり、あまり連携がスムーズではないのと動きもよくない。でも少しずつ慣れてきて、前半11分に放った大迫のシュートくらいから日本もペースをつかむ。

その後も、大久保、青山、香川、本田、山口らがたて続けにシュートを放つが外れる。それにしても香川はシュートが下手だなあ。そうこうしていると、31分に左サイドを抜けられてゴール前にクロスをあげられるとエースのルイスに頭で合わされて先制を許す。コスタリカの持ち味である堅守速攻といったところである。このルイスはいい選手だが、今野が少し自由にやらせすぎたようだ。

1点リードされて後半を迎えると、大久保に替わって岡崎、青山に替わって遠藤を投入する。すると後半15分に、香川から逆サイドの本田に送り、それを本田がゴール前にセンターリングすると内田がスルーし遠藤が決めて同点に追いつく。やはり左右の揺さぶりは有効である。

その後、今野に替えて長友、内田に替えて酒井宏樹を入れ、さらに大迫に替えて柿谷を投入。コスタリカも疲れたようで日本のペースで進み35分に香川がスピードに乗ってゴールに迫り柿谷とのワンツーから右隅に決める。久々の香川のゴールで勝ち越しに成功する。香川はシュートは苦手だが、パスのようなシュートでもいいからどんどん打てば入る。

そして、試合終了間近に香川から岡崎に流したボールを岡崎がカラダを張って落とすとそこに走りこんだ柿谷がダメ押し点を決める。格上相手に3−1の勝利はWeb杯直前の強化試合としてはじょうできではないだろうか。前回のキプロス戦からみるとコンディション的にもだいぶよくなっているようだ。いい感じに仕上がってきている。

この試合でも本田と香川はフル出場させたが、本田はもう少しだが香川はキレが戻ってきたみたいだ。これで本番のメンバーと戦い方がだいぶ見えてきたが、山口螢の危険察知能力とボール奪取率、森重の対人の強さとフィード力がチームの武器になってきている。レギュラーを確保したのではないだろうか。あとはワントップをどうするのか、大迫のポストプレーは柿谷にはないものがあるので、今日の試合のように先発が大迫で、後半相手が疲れたときに柿谷か大久保投入というのがいいかもしれない。さあ、さらに調子を上げていこう。
  

2014年7月11日

第9回BPMフォーラム2014

7月8日に目黒雅叙園で日本BPM協会主催の「第9回BPMフォーラム2014」が開かれた。ぼくはずっと参加しているが、もう9回目ということでちょっとした感慨もある。今回のテーマは「事業モデルの進化に応えるビジネスプロセスを創る」である。このへんはぼくが入っているBPM協会のコモンセンス部会で盛んに議論しているところで、技術寄りの話からだいぶビジネス寄りに移ってきている。

基調報告が協会の事務局長である横川省三さんで、事業モデルやビジネスプロセスについてわかりやすく説明してくれました。事業モデルというのは、顧客、提供価値、実現の方法という要素とそのつながりと定義し、事業モデルの進化には、事業戦略と組織能力が大きく関わるという指摘です。そして、ビジネスプロセスとは、提供価値の実現方法を仕事のやり方として規定したもので、BPMは価値向上を実現する経営手法であるとしている。

そして、その経営手法としてのBPMの特徴は「戦略に対応するプロセスを創る」と「変化を捉えるプロセスを創る」です。前者では戦略起点でものを考えるのが、後者は柔軟なIT基盤が重要なポイントであるという。これは、非常にうまく表現していて理解が進むと思います。プロセス構造を創るというスタティックな面と、日々変化に対応するプロセスオペレーションというダイナミックな面の両方が相まって初めて経営に貢献できるものになるというBPMの特徴が良く出ています。

続いての基調講演1では、前東京海上日動システムズ社長の横塚裕志さんから「「ビジネスプロセス」というブルーオーシャンに船出しよう〜東京海上日動システムズで実践したBPMアプローチ〜」と題して講演があった。横塚さんは以前から知り合いで、会社の若手の人たちに参加してもらってちょっとした勉強会をやらせていただいたこともあります。ビジネスプロセスを本当に理解している数少ない経営者のひとりです。

前々からよく言われていたことですが、ソフトウエア開発の方法論を180度変革する必要があるといいことで、「お客さまの価値をデザインするための方法論」「ビジネス部門とのコラボレーション」「作らないで作る」ということを提唱されました。具体的には「Design Thinking Agile」「ワークショップ」「クラウド上でのSaaS組み合わせによる開発」ということだという。もうまったくぼくの主張とぴったりです。そして、SEよBAになれとも言っていました。

基調講演2はTMJ社長の林純一さんの「事務処理プロセスにおける「可視化」の価値〜人の「判断」を可視化し、プロセス改善を続けるTMJのアウトソーシング事業〜」で、TMJというのはベネッセホールディングスのグループ会社でコンタクトセンター事業が出発点でその後バックオフィス事業にも進出した会社です。

この会社は、TQC活動が盛んで日科技連の「QCサークル石川馨賞」を受賞するなど「小さな改善」活動を競争力に進化させるという目標を掲げています。そうした動きの中で、サービスプロセスの可視化ということで製造業から学び「業務の量」「業務の質」「業務のプロセス」「業務の実施」「業務の変化」を見えるようにしたのだ。林社長が最後に言われた「見えないものは、管理できない」「管理できないものは改善効果も測定できない」「見えるようにすることは、伝えられる形にすること」といった言葉が印象的であった。

間にいくつかのセッションがあって最後に基調講演3として、産総研の和泉憲明さんと札幌市の長沼秀直さんから「札幌市における基幹系情報システム再構築の推進〜利用者主導のシステム開発による現場力向上のアプローチ〜」という報告があった。いわゆる大規模開発の難しさを包括フレームワークで解決するという試みである。

札幌市でどんなことをしているのかをざっくりいうと、産総研包括フレームワークに基いて基盤を整備したことが大きいようにみえる。つまり、「文書基盤」「業務アプリ」「システム基盤」に構造化したことだ。そして、技術的にはオープンなものを採用することで、随意契約のワナから抜けたのだそうだ。札幌市の人も言っていたが公共のシステムはどこも一緒だから、こうした取組が全国にひろがればいいと思うがなかなか難しいようだ。

今回の入場者が前回の1.5倍だったので、BPMも少しは隆盛になってきたのかと思う。終わったあとの懇親会で言われたが、欧米ではもうBPMは当たり前で、もうそれが前提でシステムが考えられているとのこと。それにしては日本は周回遅れ以上かもしれない。来年は今年の倍になるくらいに企業の意識を高めていけたらと思う。
  

About BPM関連

ブログ「mark-wada blog」のカテゴリ「BPM関連」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

前のカテゴリはBPMの正しい理解のためにです。

次のカテゴリはカジュアルBPMのすすめです。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type