« 2007年2月 | メイン | 2007年4月 »

2007年3月 アーカイブ

2007年3月 1日

ユーザ目線のBPM(3)

ユーザとは誰のこと、そして何を考えているのか

ひと言でユーザといっても様々である。ひとによってはユーザ企業と言ったり、ベンダーにとっては自分たちの顧客企業だったりします。しかし、この括りだとあまりにも広すぎて、どんなものが欲しがっているのだとか、どういうサービスを提供したらいいかなど考えたとき絞りきれないことになる。そうすると、「システムを使う人」をユーザと呼んだほうがよさそうだ。

そういった観点から、企業の中で働いているひとを分類してみると、大きく、経営者(社長)、事業責任者(事業部長)、業務遂行責任者(部長、リーダ)、業務担当者ぐらいに分けられる。経営者は事業部長に事業の執行を負託し、事業部長はそこの部長やグループリーダに対し、事業運営上必要な業務プロセスを正確にかつ効率的に廻すことを指示し、部長やグループリーダは自分の部下ある担当者にオペレーションを実行させる。この役割をはたすために必要に応じシステムを使うひとたちがユーザということになる。

これは、主としてライン組織のことを言っているので、このほかにスタッフを入れてもいいが、システム的にはスタッフ業務のような不定形な支援業務は外して考えてもかまわないので、ここではライン組織にいるひとたちをユーザと呼ぶことにする。

いま、こうして言っていることは上場しているような企業を対象としているが、中小企業の場合は、経営者ひとりがほとんどの役割を持っている。

それでは、それぞれの立場のひとたちは、どのようにシステムを使うのだろうか。また、システムあるいはITに関して何を考えているのだろうか。

まずは、経営者についてみてみよう。経営者はITをどのように使い、その有用性をどう考えているのだろうか。実際の経営者との会話の中で語られたことを今から述べる。

ある時期危機に瀕していた会社を立て直し、中興の祖と言われたような立派な経営者のひとが、あるとき、会社の経営について語ったのだが、しみじみ「経営の歴史というのは、特別損失の歴史なんだ」と言った言葉がすごく印象的であった。

ひとつには、日々努力して積み上げたものが一瞬で消し飛んでしまう恐ろしさであり、また、ひとつの会社のことだけの問題ではなく、社会の一員であるの会社として、その社会環境の大きなうねりの中にいて、いつその波をかぶるかもしれない、そんな中での営みが経営でもあるということを言いたかったと思う。環境問題、事故、ファイナンスの失敗、海外プロジェクトの政治的リスク、合併、コンプライアンス等々、こうした問題で損失を被ることの経営に対するインパクトは大きい。

このような問題に対しITが貢献できるかと考えたとき、何があるのだろうか思ってしまう。ITで危険予知情報を流すことができるじゃないか、みたいに言われるが、本当に役に立つ情報を探し出して提供できるのだろうか。内部の財務データや与信データぐらいはできるかもしれないが、外部についてはおそらく難しいと思うし、経営者も欲してはいないだろう。

また、だいぶ前だがあるセミナーのパネルデスカッションで言ったこともユーザのITに対する考え方につながる話なので、ここで紹介しておく。それは、情報活用についての各社の取り組みを議論というより、紹介し合うようなものでしたが、そのパネラーとして参加して発言したことを少し長くなるが引用する。

情報活用行う上で重要なことがありますそれは3つの度ということです

1、3つの度とは、鮮度・感度・加工度
2、感度というのは情報の送り手と受けての意識がどれだけマッチングしているか、受け手の期待と送り手の洞察力が合うかどうか 
3.加工度というのが結構大事なことで、どういうことかというと、あるとき経営トップと話をしていたとき、事業部などとのヒアリングで分厚い資料を見せられて、どうかといわれるが、そのデータというのはたいていの場合自分たちの都合のいいように加工したもので恣意的なデータであるわけで、そんなものをみせられても困る。いっそ生のデータのほうがましだと言われたことがありまして、しかしだからといって生のデータを渡してどうですかというわけには行かない。どこまでに加工するかが重要なポイントではないか。

では経営に役立たせるためにはどんな情報を提供すべきなのだろうか
1、いまのような話となると、経営としては単なる数値データだけの情報ではもちろんダメ
2、数値データではない情報、内部情報だけではない外部情報も必要
3.死体解剖的な情報から生体ドック的な情報をどう提供できるかにかかっている
  過去のデータみてどうだったかではなく、これからどういう手を打つんだというための情報が重要
4.究極的な言い方をすると社長になれるCIOがどんどん出てこないと真に経営に役立つITを提供できない

ところが役に立つ領域もあって
1、情報活用を考えるとむしろ事業部長とか各部長のところが有効
2、なぜかというとちょうど情報がクロスするところで、経営からの情報、オペレーショナルレベルからの情報がクロスするところ
3、ここの裁き方で企業としての情報活用度が上がる
4.したがって、ここへ向けた仕組みを構築するのが効果的

というようなことをしゃべった。要するに、「経営に貢献するIT」なんて軽々しく言えないなということである。

ですから、大上段に振りかぶって経営戦略がどうのこうのといわず、“会社の業務がちゃんと動く骨太の基本構造をシステム化すること”が最重要で、それは、業務プロセスとそれに情報活用でオペレータやマネージメントを支援するシステムがあれば十分であると思う。オペレーショナルなレベルに近いところのシステム化ということである。

ですから、別の言い方をすると、事業部長や部長クラスのミドルマネジメントにとってはITは非常に有用なツールであると言える。

稚拙なたとえ話で恐縮ですが、経営者は性能のいい車と腕の立つ運転手だけがほしいのであって、自分の行きたいところに自分の思ったように運んでもらえばいいと考えている。余計な機能、例えばスピードが出ているから緩めろとか、この道が早いからこちらを通れとか、それこそもうすぐレストランだからそこで食事せよとか言ってくれるなと思っている。寄り道したいときもあるし、たまにはスピードも出してみたいときだってあるのだ。それは、経営者の頭のなかにあって、それが経営者のシステムなのだ。

よく、えらそうに小声でこれはすごい秘密情報だから、ここだけの話にしておいてくれ、とかさも自分は会社の中枢にいるえらい人かのように言う、まあだいたい中間管理職だがそういうひとがけっこういる。ところが良く考えてみるとそんなものはほとんど秘密情報でもないことが多い。もちろん、新商品の情報とかの本当に秘密にしなくてはいけない情報はあるが、最近はどんどん情報開示の方向であり、かなり少なくなってきている。

それで、その辺を喝破した経営者がいた。曰く「会社の秘密情報は全部オレの頭のなかにある」。そうなのです、最後の最後にどんでん返しとなる企業合併なんか典型です。

ということで、性能のいい車とカーナビくらいを用意しましょうというのがここで言いたいことです。

2007年3月 2日

東京スポーツ映画大賞

昨日、赤坂プリンスで開かれた「東京スポーツ映画大賞」受賞式に行ってきました。ぼくの昔の会社の先輩であるQさんの代理で出席です。Qさんは「三重映画フェスティバル実行委員会」の副会長をしている人で、その人に招待状が行って、遠いのでお前行かないかと言ってくれたので、二つ返事で招待状を送ってと頼んだのです。

この映画祭は全国のこうした地方映画祭の投票を参考にして、おそらく審査委員長であるビートたけしの意向で決めていると思うが、そういった関係で各地の映画祭に招待状が行くというわけです。ですから、となりに座った人が「長岡アジア映画祭」の人でわざわざ新潟から来たといって、パンフレットを渡され、ぜひ来てくださいとお誘いをうけた。

この映画祭も16回目で、映画に関する賞とともに「ビートたけしのエンターテインメント賞」の受賞式も同時に行われる。これも今年は7回目ということで、今回の目玉は何といっても特別賞のそのまんま東(東国原英夫宮崎県知事)でしょう。知事になって初めての師弟ツーショットということで大量の報道陣がかけつけ、わざわざ撮影のための時間を設定し、フラッシュがすさまじかった。もう、15分くらいでこれから宮崎に帰るといって去っていった。さすが、同じ特別賞の石原真理子もかすんでしまった。

賞の受賞者はつぎのとおり

第16回 東京スポーツ映画大賞

作品賞 「ゆれる」、監督賞 西川美和(「ゆれる」)、 主演男優賞 木村拓哉(「武士の一分」)、 主演女優賞 蒼井優(「フラガール」)、 助演男優賞 香川照之(「ゆれる」)、 助演女優賞 富司純子(「フラガール」)、 新人賞 木村祐一(「ゆれる」)、 外国作品賞 「父親たちの星条旗」、 特別作品賞 「日本以外全部沈没」

第7回 ビートたけしエンターテインメント賞

話題賞 山本モナ、 日本芸能大賞 春風亭昇太 、主演AV女優賞 青木りん 、主演AV男優賞 該当なし 、タイトル賞 該当なし、 特別賞 石原真理子 、特別賞 そのまんま東(東国原英夫宮崎県知事)

受賞者で出席していなかったのは、木村拓哉、蒼井優、香川照之だった。蒼井優と香川照之はビデオメッセージが届けられていたが、木村拓哉の表彰では表彰状とトロフィーを同じ木村である木村祐一にあげてしまった。ちょっときついしゃれでした。なんといってもぼくにとっては蒼井優ちゃんが来ていなかったのがすごく残念でした。

さて、それぞれ受賞者に対してたけしがコメントするんだけど、これがまたおもしろいのだ。全部を紹介することができないが、なかで印象的なことを少し。いま邦画ブームで洋画の興行収入を追い抜いたとかでみんな喜んでいるが、決してレベルがあがったわけではない、そのなかでは、「ゆれる」と「フラガール」の2本だけが評価できる。「武士の一分」なんかぼろくそに言っていた。「ゆれる」は低予算のなかで、きちんとした脚本でどちらかというと古典的なつくりであり、よくできた作品とほめていた。

面白かったのは、そこでひとつだけ注文をつけるとしたら、8ミリ映写機が登場するがそれが母親のかたみであったというのがどうも違和感があった、当時8ミリ映写機というのはオヤジのものであったはずなので、そこをもう少しひねれたらよかったのにと言っていた。ぼくも、この映画の感想に8ミリ映写機のことを書いたが、あの頃の雰囲気の象徴としての8ミリ映写機を小道具に使ったことにすごく感動した身では、たけしも同様の感じをもったのではないでしょうか。

一方「フラガール」は、もう題名を聞いただけで、どんな映画になるかすぐにわかった。実際の映画もそのとおりになっていた。しかし、そういう映画を高いレベルで作り上げられる力はたいしたもので、できるやつは少ないんじゃないかとこれも高い評価をしていた。

また、KカップのAV女優が、わざとオッパイぽろりとしたのに、間が悪くまったくしらけてしまったが、なぜか司会の江口ともみがKカップと聞いてすごく受けていたのが傑作だった。余談だけど、この江口ともみってたけし軍団のつまみ枝豆の奥さんでオフィス北野所属なんですね、道理でTVタックルなんかに出てるんだ。

あとは、「ゆれる」の若いプロデユーサーがスーツを着て靴がバスケットシューズをはいて登壇したら、たけしがこれをいじり倒して、この日の人気者になってしまった。 まだまだ、「日本以外全部沈没」という映画を作った河崎実監督だとか、東京スポーツの社長がぼくと同じように、「父親たちの星条旗」はよかったけど、「硫黄島からの手紙は」つまらなかったと言う話など、いっぱい面白い話があった。

今回、デジカメを持っていくのを忘れたため受賞式の写真が載せられないが、始まるちょっと前に携帯で撮影したのを載せる。背中が写っているのは石原真理子です。今度はちゃんと持って行くようにしたいと書くと、来年もきっと招待状が転送されてくるでしょう(笑)。いやー、楽しい一日でした。Qさんありがとうございました。

P1000033.JPG

ユーザ目線のBPM(4)

ユーザと作り手とのギャップ解消の方向性

前回、ユーザの望んでいるシステムはどんなものであるかを示したが、そこでは“会社の業務がちゃんと動く骨太の基本構造をシステム化すること”が重要であると言った。そんなことは、すでにやっているし、できているとみな言うのじゃないか思うが、“ちゃんと動く”ということと、“骨太の基本構造”というところがミソで、ここがほんとうにできている企業は少ないのではないでしょうか。そこを考えていこうと思います。

それには、ユーザとシステムの作り手がうまくコラボレーションしてやれているのかという問題と、システム開発の道具とそれによって作られたシステムの構造の問題が潜んでいると思う。

ここでは、前者のコラボレーションの問題について議論する。

“ちゃんと動く”ということは、ユーザの要求と作り手側の要求実現度と最適化レベルが両者のコラボレーションで行われていることが前提だ。

もう少し噛み砕いて言うと、ユーザはまずは現状の業務をベースにシステムを考える。いわゆるAsIsモデルがまずありきで、そこに今困っていることや変えたいことをそこに反映していこうと通常考えます。ただしこれだけで、あるべき姿ToBeモデルができるわけではありません。

そこで、作り手側の登場です。作り手側は、技術的に要求どおりできないことがあったり、運用上やめたほうがよいことなどが出てきます、こうしたできないことは反映しないと言うわけです。この反映のされ方が要求実現度です。ここを無理だ無理だと撥ねつけるのではなく何とか実現してあげたいとすることもあるし、逆にユーザもシステム技術上の無理難題を押し付けることはしてはいけません。このコミュニケーションが大事です。

そして、作り手側は技術的な観点から、こうしたほうがよいとか、こんなこともできますよという積極的なアドバイスをする役割を担っています。今日、この技術ドリブン発想は重要なことです。

システム開発というのは、家作りとか自動車作りに例えられることがありますが、決定的に違うのは使う人が技術が見えないことだと思う。家や車を買う人は何となくどんな部品でどんな技術で作られているのがわかっているのと、作る前に出来上がりイメージがだいたいできるが、システム開発の場合は、使う人はプログラムソース見たって全く分からないし、出来上がってみて初めてこのシステムってこんな風に動くのか分かったとか、そんなことになる。従って、技術を理解している人がきちんとそこを説明し、技術の活かし方や使い方を提案することが、プロのシステム屋のやることではないでしょうか。こうした、相互の歩み寄りで最適化が可能になるのです。

今はそこのところがどうなっているかというと、ユーザに言われたとおり作るか、システムの分からないユーザに意味不明の三文字熟語を並べ、極端な話勝手にシステムを作ってしまう、いわば両極端のケースが多いのではないでしょうか。

これからはこの中間のアプローチが必要で、そのためにはユーザと開発者(この場合はプログラム製造の領域近い)の距離を縮めることをしていかなくてはいけません。それができるのは、中間にいるコンサル、SEなどですから、そこを埋めていく努力をして欲しいわけですが、実際にはうまくできていないように思われます。

「ユーザがその業務、事業をスムーズに実行できるシステムを開発すること」をめざすのではなく、「ユーザがそのシステムを使って自分たちの業務、事業をスムーズに実行できること」をめざすという、この微妙な違いを理解する必要がある。

で、こうしたコラボレーションをベースとしたシステム開発の進め方でぜひ採用して欲しい考え方がある。それは「デザイン思考」という考え方で、そこにある「創造のプロセス」は、システム開発の場でも十分適用できるものである。

これは、慶応大学環境情報学部の奥出直人教授が提案していて、実際に企業のイノベーションを起すための方法論として注目されている。最近、「デザイン思考の道具箱」という本を早川書房から上梓しているので、その中から、基本的な概念を紹介する。

プロセスは全部で7つのステップから成っている。

ステップ1 哲学とビジョンを構築する
ステップ2 技術の棚卸とフィールドワーク
ステップ3 コンセプト/モデルの構築
ステップ4 デザイン- デモンストレーション用プロトタイプをデザインする
ステップ5 実証
ステップ6 ビジネスモデル構築
ステップ7 ビジネスオペレーション

こうしたプロセスは、まさにこれからのシステム開発のあり方に多くの示唆を与えてくれる考え方であると言える。次回にこの詳細について述べる。要は、ユーザや開発者が一緒になってシステムをデザインしていこうじゃないか、それが役に立つシステムを作ることにつながるということが今回言いたかったことです。


2007年3月 3日

テレビ東京

テレビ東京がおもしろい。このテレビ局は、年寄りとサラリーマンにターゲットを絞っているようだ。懐メロや温泉めぐり、鑑定団を放送するかと思えば、かたやWBS、カンブリヤ宮殿とかガイアの夜明けというように、年寄りが好むものと経済の話を中心とした企業人向けに見るべきものがある。

歳を食った一応勤め人であるぼくにとっては、ここのチャンネルに行くことが多い。で、ちょっと前になるが、先週の日曜日の夜は楽しかった。日曜日だから経済の話ではないが、懐かしい人たちのオンパレードであった。

まず、日曜ビッグバラエティで「昭和を駆けたスター同窓会」というのがあって、メキシコ五輪で銅メダルをとったサッカー代表やベルばらの宝塚歌劇団、俳優座、西鉄ライオンズなどで活躍した人が、集まって同窓会を行うという企画。若い人はなかなかわからないと思うが、かれらはみなぼくらにとっては憧れでもあり、ファンとして一緒に少年期、青年期を過ごしたのだ。

特に、ぼくのうれしかったのは西鉄ライオンズで、ぼくは小さいときは野球少年だから、稲尾や中西、豊田、大下、仰木らのプレーに酔ったのを鮮明に覚えている。この放送で何がうれしかったかというとよく稲尾だとか有名な人はちょくちょく顔をだすが、そうではなかった準レギュラーであったとか控えであったという渋い選手が登場したことであった。河野、滝内、和田、梶谷とかいった人が出てきてすごくなつかしかった。

そのあとに、「ソロモン流」という番組でマイク真木の登場です。もう“バラが咲いた”一曲で一生食っていけるという、それだけこの曲はすごかった。単純な歌詞と曲でそこまで売れるとは思っていなかったのだが、結局、フォークソングブームに火をつけたわけで、その時代の新しいスタイルを提示したことが大きいのじゃないだろうか。ぼくも当然のようにギターを買い“バラが咲いた♪バラが咲いた♪”と唄ったのであります。

続いて、「みゅーじん」という番組では中村雅俊です。彼はいまだに人気が衰えず、毎年コンサートも開き、最近では舞台でもがんばっている。ぼくと似たような年齢だから、昔からずっと等身大のタレントとしてみてきた。最も印象的だったのは「俺たちの旅」というテレビドラマで確か日曜日の8時からだった思うが、毎週見ていた。カースケというのを中村雅俊が演じていて、他に田中健とか秋野太作(当時は津坂まさあきと言った)が出演していて、若者たちの友情や悩みなどを軽やかに描いていて、ぼくらは自分たちを重ね合わせて共感し、また勇気をもらったりしたものだ。

そんな中村雅俊が突然五十嵐淳子と結婚したときは、ぼくを含めて多くの男たちが嘆き悲しんだ。今の人は知らないでしょうが、「阿寒に果つ」という映画で観た五十嵐淳子(当時はまだ五十嵐じゅんと言った)は、もう言いようのない可憐さであった。もう許してあげるは中村君。

中村雅俊は、芝居と歌というようにマルチで活躍している。マイク真木もそうだが、こうしたハイブリッド型のシニア世代がどんどん出てきて残りの人生を謳歌するのを見せてくれることはいいことだ。 ということで、テレビ東京で昔のことを思い出しながら、ビジネス番組でなんか商売のネタになるようなことはないか探しているのです。



ユーザ目線のBPM(5)

システムをデザインする

それでは、奥出直人の言う「デザイン思考による創造のプロセス」にもとづき、情報システムの開発について考えてみることにする。

「デザイン思考による創造のプロセス」とは、“社会的背景や哲学的背景を踏まえた上での考え方、作り手の問題意識を表わす哲学を考えるところから始めて、具体的に何を作りたいかビジョンを決め、それを持ってフィールドワークに行き、どのようなものを作るかコンセプト/モデルを作り、機能やインタラクションを検討しながら実際の設計デザインを行い、実証する。つぎにビジネスモデルを構築して、実際の運営方法を決定する”プロセスのことと言っている。

そのそれぞれのステップについて追いかけるが、より重要なプロセスとして上流のプロセスの最後であるデザインするところまでを取り上げる。

まず、ステップ1「哲学とビジョンを構築する」ことだが、企業の情報システムであれば、会社の経営理念や方針あるいはもう少し狭くて部門の運営方針といったものが哲学やビジョンに相当する。さらに、最近よく言われるEA(Enterprise Architecture)もこれにあたるものである。

ついで、ステップ2「技術の棚卸とフィールドワーク」は、従来の方法では、ビジョンからすぐにコンセプトへとつなげるが、ビジョンとコンセプトを明確に分け、この二つをつなぐ作業として位置づけられる。この考えが非常に重要である。

技術の棚卸しとは、アイデアや技術をたくさん集めて並べ、それをビジョンに割り振ってみるやり方であり、フィールドワークとは、ビジョンに基づき自分のビジョンを実現してくれるだろう「師匠」のところに出かけ、弟子入りし、みずからの経験を拡大していく、その記録を分析して「ワークモデル化」した段階で「魔法のシナリオ」と呼ばれるものを書く作業を行なう。「初心者であることは素晴らしい。それは自分の知らないことを知って、驚き、不思議に思う、その差分が価値を生むからだ」ということである。

これを、システム開発にあてはめてみると、いわゆる現場ヒアリングという行為に相当するかもしれない。しかし、いま実際にやられているのは単に現状業務の手順や問題点を聞いているだけで、ビジョンをきちんと確立してから行っているわけではないし、そもそもデザインするというマインドを持っていないと言える。ここは非常に重要なポイントで、ユーザニーズを聞くということももちろん大切だが、実現したいビジョンを頭の中に入れて、そのために現場のエキスパートをよく観察して分析する姿勢が肝要である。

ステップ3はいよいよ「コンセプト/モデルの構築」に入る。コンセプトというのは、アイデアをいくつか組合わせて、具体的にどのような技術でそれが可能になるかを検討していき、そこで生まれたビジョンを実現するための具体的な方法とその構造をいう。なおコンセプトには技術の裏打ちが絶対必要であることを忘れてはいけない。そのコンセプトを実現するための基本構造や仕組みを選んだり作りだしたりする作業を「モデル」を作るあるいは探すと呼ぶ。

そしてダーティプロトタイプあるいはラピッドプロトタイプと呼ばれる原初的なプロトタイプを作っていく。このあたりのやり方は、システム開発でいうプロトタイピング手法であるが、この場合はコンセプト形成はやってない場合が多く、しかもプロトタイプというとどちらかと言うと画面や帳票といったユーザインタフェースが中心で、システムの構造やプロセスの動きなどは分からないため、ここでいうステップの作業とはずいぶんと違う。

これからの開発で必要なのは、システム全体が見渡せるプロトタイプができる道具が要るということ、その道具は簡単に安く作れ、ラフなものからだんだん精巧なものへ進化させることができ、それを皆で議論しながらやっていける、そんなものが欲しいのだ。プロセスモデラーやシミュレーターみたなものが機能を追加すればこれにあてることができる可能性がある。

また、コンセプトの一部はEAから引用してくることができる。 このステップでおおかたのシステムの構造やプロセスの骨格が決まってくる。

上流プロセスの最後は、ステップ4「デザイン- デモンストレーション用プロトタイプをデザインする」である。デザインとは、機能を考えながら必要な要素を集め、構造や仕組みをつくっていく作業である。

これは、まさにコンポーネント開発に他ならないのではないでしょうか。そして、大事なのは、見えるもの(プロトタイプ)を早く作ってそれを見ながらデザインしていくということである。

こうしてみていくと、「デザイン思考」ということが、情報システムの開発にも適用できる、いやこうした思考方法が非常に重要であることがわかると思う。

なお、デザイン思考を活用するために使いこなすべき道具として、「経験の拡大」「プロトタイプ思考(build to think)」「コラボレーション」の3つを上げている。

この3つについて簡単に言えば、「経験の拡大」とは現場の人間の動きをよく観察せよということであり、「プロトタイプ思考」は見えるものを実際に作りながらスパイラルアップして行こうというものであり、同じ言葉が話せる精鋭による「コラボレーション」で作業することと理解できる。

今回は、「デザイン思考」によるシステム開発プロセスの有効性について書いたが、実際のワークモデルなどより具体的な手法の話まではここでは言及しない。なお、次回は、道具としてのBPMの可能性について考える。

2007年3月 5日

ユーザ目線のBPM(6)

SAPの変化を見ると分かってくること

これまで、Whyと上位概念としてのHowを中心に、本当にユーザに役立つシステムを作らなければいけないこと、そのためにはユーザと作り手が一緒になってシステムをデザインするという思考が大事であるというようなこと議論した。

ここからは、どんな構造のシステムを作るのか、それをどんなMethodologyや道具を用いるのかというWhatとHowについて論じていくことにする。

まず、「道具としてのBPMの可能性」の前に、企業情報システムの変遷をみてみる。ここで教科書に書いてあるようなことを言ってもおもしろくないので、世界最大のERPであるSAPの変化の過程(SAPは進化と言っているが)を例に考える。

SAPのERPは現在「mySAP ERP2005」というのが最新バージョンであるが、その前1992年に投入されたSAP R/3というのが有名でこれによって大きく普及した。R/3というのは、メインフレームのシステムであったR/2からクライアント・サーバー型に移行したもので、今までばらばらであった基幹業務システムを統合し、システム間の整合性をとることに威力を発揮した。そしてよく言われたのが、バッチからリアルタイムへと変わるということで、その当時、一度入力するとすっと最後まで行ってしまうから入力するとき怖くて手が震えたといった話をしていたことを思い出した。このリアルタイムということには誤解があってそれについては後で述べる。

この時点でのERPの特徴は、統合化、リアルタイム化、標準化(グローバルスタンダード)であった。しかしながら日本ではこのうちリアルタイム性とグローバルスタンダードは合わないため、メインフレームで統合化されたシステムを持っているところは、それほど魅力があったわけではなかった。

そして、つぎに出てきたmySAP ERPで大きくコンセプトを変えることになる。それは、ESA(Enterprise Service Architecture)と呼ばれる、いわばSOAの概念を採り入れたことだ。そして、ポータル、データ連携、BI、マスタデータ管理などのシステム基盤であるNetWeaverをリリースしたのである。このESAのアーキテクチャは非常に重要でこの理解がないといくら新しいERPを入れても無駄だ。

わが国でもいま少しずつ分かってきていると思うが、おそらく本当にここを理解しいているひとは数少ないのではないでしょうか。だからまだ、アドオンをいっぱいして旧来型の作りにしているプロジェクトも多いかもしれない。どこがどう変わったかを検証すると、ここで議論しようとしているシステム開発の方法の参考になる。というか、結局めざすところは一緒なのだということがわかる。

新バージョンの価値をひと言で言うと「情報を起点としたオペレーションと管理」ということになる。すなわち、情報が業務のアクションを誘導することであり(これが最初に言ったリアルタイムということなのだ)、常に事業の状況を監視し、異常が生じたらワーニングする仕組みなのだ。

そのため必要なことは、シンプルで一貫化された業務プロセスでなくてはならないということと、それが可視化されていることが重要である。従来は、この業務プロセスがすでにSAPにあって、それを使えるかどうかと考えるイメージだったと思う。そして、もし自社のプロセスが合わない場合、2つの誤った方向に走ったわけです。ひとつは、無理やりSAPに合わせて窮屈な思いをする。もう一方は、現状システムを生かそうとしてアドオンの嵐となる。

これが新しいSAPの姿では、標準化された機能を組み合わせてプロセスを自社の要件に合わせて組み上げるイメージです。従って、自社のプロセスと機能(機能とプロセスは明確に分離することが肝要)を特定し、業務プロセスを個性化することができるのです。よく、ERPパッケージは要件定義する必要がないように言う人もいるが、このように要件定義が重要なステップになるのです。

「システムの枠組みにプロセスを合わせる」ことから、「プロセスに必要なシステムを組み合わせる」ことに大きく舵を切ったことをよく認識することが必要です。これって、なんかBPMでしょ。そうなのです。SAPの今の姿はSOA基盤に乗っかったBPMシステムなのです。

SAPという会社はこのパッケージだけに多くの人間を抱え、日夜開発にいそしんでいるわけで、それを考えるとIBMより大きな会社とも言えるし、そのシステム開発のトップランナーがこうした方向性を示していることは特筆すべきであろう。

余談になるが、奥出教授の「デザイン思考の道具箱」によれば、SAPの共同創立者であるハッソ・プラットナーはスタンフォード大学のデザインスクールに3500万ドルもの資金を提供して「デザイン思考」の研究を支援しているのだ。SAPの懐の深さを感じる。

疑わしきは罰せよ!?

「それでもぼくはやってない」では、「疑わしきは被告人の利益に」なるはずが、無実を証明できないため有罪になってしまったが、その理屈を他のところにあてはめるとどうなるのだろうか。

最近話題の「タミフル」は、服用後の異常行動との因果関係は証明されていないが、疑わしいと思える。タミフルの無実だって証明するのは難しいから、なぜ有罪とならないのだろうか。タミフルに冤罪はあるのか。冤罪がわかったとしてもタミフルの失われた人生を返せとなるのか、ならないのか。あるとすれば、タミフルを使用禁止したおかげでインフルエンザで死ぬひとが増えた場合だ。だから、厚労省も薬害と思われるのはいやだからではなく、薬には副作用があるがそれ以上に効能のほうが勝っているから使わざるを得ないとはっきり言えばいい。そうじゃないとなぜ使用禁止にならないのかという声が大きくなる。

そんなことを考えていたら、九州の光化学スモッグが最近増加してどんよりとした空が多くなってきたという報道があった。その原因はどうも中国らしい。中国大陸の工場や車から排出される汚染ガスが飛んでくるようだ。これも疑わしいという話だが、この場合は中国に光化学スモッグの原因がそちらにないことを証明しろもしできなかったら罰するぞなんて言えないですよね。そうなると、疑わしきは罰せずということになり、結局は疑わしいことが闊歩することになる。

と書いてみて、そうなんだぼくを含めて普通の人々は、こころの奥で疑わしくは罰すべきだと思っていることに気がついた。それが、「それでもぼくはやってない」のように冤罪を生む土壌になっていると言ったら大げさだろうか。

2007年3月 6日

ユーザ目線のBPM(7)

Webの世界を見ると分かってくること

SAPのような企業の基幹システムの話とは別に、Webの世界で起きていることを簡単にレビューしておく。

まずはWebサービスという概念であるが、当初はSOAP、WSDL、UDDIというどちらかというと技術的な側面が色濃かったが、近頃ではサービスという意味合いも出てきていて、例えば、GoogleMapsに代表されるように公開されたWeb APIを使ってMashUpされたWebアプリケーションが続々登場しています。

技術的にもSOAP/WSDLに似たRESTなどが出てきて、今後REST準拠のWebサービスが企業のシステムには入り込んでくる可能性もあると思われる。REST(Representational State Transfer)を説明するのはむずかしいのですが、基盤となるアーキテクチャスタイルのひとつで、といっても抽象的でよくわからないので、リソースの状態の表現、例えばヤフーから得られた東京の天気予報などを指しますが、それをサーバーからクライアントに転送することとでも言ったらいいのでしょうか。

GoogleMapsのようなWebサービス以外でも、del.icio.usのようなソーシャルブックマークサービス、flickerのような画像共有サービス、mixiのようなSNSといったサービスも揃ってきました。これらがすぐに企業システムに使われるかというとそうではありませんが、例えば、路線検索サービスが旅費清算システムに組み込まれるといったことは現実になっているわけですから、様々な形のマッシュアップが今後増えてくると考えられます。

マッシュアップは、SAPの説明のときに言った「機能を組み合わせてプロセスを作る」ことと同義であると言えないことはないと思います。

野村直之さんの「Web2.0 for Enterprise」では、超短寿命時代の企業情報システム実現のために採用されるであろう手法について予測している。

(1)「エンタープラーイズ・マッシュアップ」(クライアントサイド)

(2)「XMLDBのスキーマ拡充やミドルウエア」(サーバーサイド)

(3)「軽量言語(Ruby on Rails等)の活用」(比較的小規模なサーバー)

(4)「“軽量”Webサービスやmicroformatsで連携」(必要な部分だけ作る)

これらを見ていくと自前のアプリを簡便な手法でWebサービス化したりして疎結合で安定したシステムを素早く作ろうという方向性が浮かび上がってくる。

業務プロセスのひとつの機能をサービスとみたてれば、これもまさにSOAの基盤の上にのったBPMと言えないこともない。

こうして、SAPとWebの世界を眺めていくと、最近の企業情報システムのあり方が見えてきたのではないでしょうか。そして、これらのアプローチや考え方、さらにはテクノロジーを融合して行こうというのがこの議論の大きなねらいのひとつなのだ。

なお、Web2.0の技術やビジネスモデルにについては後述する。

「デザイン思考の道具箱」を読む

社長(息子)がこの本おもしろいよと言ってもってきてくれたのがこれで、一気に読んでしまった。著者の奥出直人は慶応大学環境情報学部の教授で、社長は長いこと奥出先生の研究室にいて、あとがきで謝意を述べているひとたちに自分の名前が入っていることもあり、すぐに買ってきたようだ。

この本の趣旨は、「デザイン思考」によって新たな「創造プロセス」を築き「イノベーション」を起そうということ。

もはや従来型のアプローチではイノベーションを起すことができなくなってしまった。こうした考え方や方法論が経営戦略の立案やプロダクト、サービス開発に生かされてきているというものである。iPodの例などすごく面白かった。

創造プロセスは、哲学・ビジョンの構築→技術の棚卸とフィールドワーク→コンセプト/モデルの構築→デザイン→実証→ビジネスモデル構築→ビジネスオペレーションという全部で7つのステップから成っていて、それぞれにまた実際のワークモデルが提示されていて、非常に分かりやすい。

奥出先生はぼくも実際にお会いしてお話をしたことがあるが、知性のかたまりのようなひとで、大変な知識量と行動力、多彩な人脈など圧倒されますが、それと同時に理論だけではなく企業や大学の研究室などで実践におとしていることが素晴らしい。

ぼくは、いま企業の情報システムの構造と作り方を考えているが、まさにこの本に書いてある方法論こそ求めていたものであった。

それはそうと、タイトルがいいですね。デザイン思考という言葉とそれに道具箱と名づけたことが気に入った。そうなんです、何か作るときって道具が要るのに、意外とそのことについて言ってくれないし、おろそかにするひとが多いんです。道具とか技術の要素って重要であると思っていたので意を強くしたのであります。

2007年3月 7日

ユーザ目線のBPM(8)

道具としてのBPM

さて、SOA基盤に乗っかった業務プロセスをデザインするにはどうもBPMがよさそうだということになってきた。でもBPMとは何なんだろう。Business Process Managementというけど業務プロセスをマネジメントするって実はよくわからない。

そこで提案したいのは、BPMのMはMapper/Modeler/MonitorのMであることです。すなわち、業務プロセスをデザインするための道具(これとは別にエンジンとしての機能はもちろんある)と考えてしまったほうがわかりやすい気がするがどうだろう。

Mapperというのは、機能あるいはサービスをマッピングするツール、またはハブとして機能させることである。

Modelerは文字通りモデリングするためのツールで、しかもシミュレーションができることが必要である。このツールを使いモデルを描きながらシンプルで一貫化されたプロセスになっているかを検証していく。このとき、重要な機能として制約条件やルールによるチェックが自動的に行なわれることが望ましい。

例えば、プロセスのひとつの構成要素であるタスク(アクティビティ)のつながりの中で前のタスクのアウトプットが次のタスクのインプットになっているかだとかプロセスに重複業務や迂回業務が発生していないかなどをチェックしてくれて、それに従ってシミュレート(評価)しながら作っていくと、自ずとめざすプロセスができあがるというのが理想的である。

Monitorは業務の動きを監視し、異常の発見をおこなう。ここでは、パフォーマンスの監視というより、むしろ業務の流れの停滞を見つけたり、目標からの乖離などを探る役割である。

どうも、ITに限らないことかもしれませんが、概念的あるいは戦略的なことを大きな声で言う人がいますが、ではそれが実際に実行できるかというと、実は方法論を持っていないことが多いような気がします。

また、素晴らしい方法論でもそれが使えるのはごく限られた天才でしかなかったといったことも起こります。ですから、あるレベルのスキルをもった人(誰でもというのは無理ですが)が、それを使うとだいたいできてしまうという「方法(メソッド)」が必要となります。そのメソッドをBPMと結びつけてパッケージ化できたら素晴らしいと思います。このメソッドについては後でもう少し詳しく議論します。

そして、このパッケージを使いこなし、最適なビジネスプロセスを設計できる人をビジネスプロセス・デザイナー(BPD)と呼びたい。これまで、システムエンジニア(SE)と呼ばれるひとたちがいるが、そのネーミングからいくと、どうもビジネスのことをちょっとおろそかにしているイメージだ。だから、ビジネスエンジニア(BE)と呼んだほうがいいと思っていたが、それでもエンジニアという意味が単にモノを設計する感じとなるので、これからはデザイナーのほうがしっくりいくように思う。


2007年3月 8日

ユーザ目線のBPM(9)

BPM2.0

ここで、米国Intalio社のIsamel Ghalimiというひとのレポートを紹介します。この人はもう6年前にBPMのホワイトペーパーを描いた人でオープンソースベースのBPMSを提供しています。現在も盛んにBPMに関する発言をしていて、BPM2.0なんてことも言い出している。なぜ、ここで紹介するかというと、どちらかというとBPMは道具であるという視点でみているところがあるのであえて彼の意見を載せる。

まず、彼の言うBPM2.0について、Tim O'reillyばりに比較したものを抜粋して示す。

BPM 1.0                          BPM 2.0

Marketed to Business Analysts       Used by Process
Analysts

Starting with a Process Modeling Tool  Starting with
a CompleteBPMS

Multiple Tools from Multiple Vendors   One Single Tool
in Eclipse

BPEL, BPML, WSFL, XLANG, XPDL      BPEL

ARIS, HIM, UML, Proprietary Notations  BPMN

BPEL Editor                   BPMN Designer

Writing Code Behind the Boxes       Zero Code

Writing Deployment Descriptor Files    One Click Deploy

Application Connectors            Generating Web
Services on-the-fly

Bring your own Rule Engine         Rule Engine
Included

Bring your own BAM              Real-Time BAM
ncluded

Ad hoc Process Simulation          Native Process
Simulation

ただ、この中にはBPM1.0と2.0の比較であると必ずしも言えないものや、単に標準化されたことや技術的に集約されたことなども含まれているが、雰囲気的には、Process Design Toolのような感じがしませんか。

さらにおもしろいことを言っていて、

BPM 2.0 is not for non-technical business analysts. We’ll just let more technical process analysts understand business requirements and implement them directly into the process, while leveraging existing IT systems.

BPMは技術を知らないビジネスアナリストのものではなく、プロセスアナリストがビジネス要件を理解して、直接プロセスの設計・開発をしてほしいと言っている。また、

Neither top-down nor bottoms-up, it’s a middle-out approach, and it’s the only one that makes the gap any narrower.

このミドルアウトの考え方は、前に述べたようにユーザと開発者の距離を縮めることと同じ話なのだ

2007年3月 9日

ユーザ目線のBPM(10)

システムの構造とアーキテクチャ

ここまでで、SOAという言葉が何回か出てきたが、このService Oriented Architectureというのは一体なんなのか、どういう定義なのかと、言ってみたが、極端な話そんなことはどうでもよくて、要はビジネスサイドかつシステム技術サイドからの変更要求に早く、柔軟に対応できる仕組みを作りたいだけで、SOAを実行することが目的でもなんでもない。だから、SOAを実践した事例はこれですなんておかしな話なわけで、システムを作ったらそれがSOA的であったというのが正しいのであり、サービスをつないでシステムを作ればみんなSOAでいいのだ。

このあたりは、4~5年前に筆者がシステムの構造をどうしようとしていたかを説明するのがいいのかもしれない。

当時、メインフレームかオフコン上の基幹業務システムの外でいろいろなサブシステムや情報系システムが作られていた。それが、ほとんど連携しないで独立していた形でせいぜいFTPみたいなものでつながっていた。そこにやっとWebサービスのような技術あるいはEAIやBPMのようなツールが登場し、システム間の連携ができるようになったが、まだ多くの問題を抱え普及は大きくは進展しなかった。

ただ、システム間の連携という場合、まずはシステムを構造化することが大事であると考えた。「構造化する」とは、(1)全体を俯瞰したうえで、構成要素に分解し(2)それらの構成要素間の関係を分かりやすく整理し(3)統合化されたモデルを作ることであり、それぞれのレイヤで必要になる。

例えばEAでいうところの政策・業務体系では、業務をコア業務とサポート業務に分けさらにサプライチェンサポートとプロフェッショナルサービスや定型業務に整理してみることや、適用処理体系では、ERPを使うのか、手組みにするのか、外部サービスを利用するのかとか、もう少しシステム寄りで入力・出力系のアプリケーションをどう配置するかだとかになる。

こうして、アプロケーションやシステムコンポーネントを整理した後、重要になってくるのがシステムの骨組みをどうするか、そこの血流をどうするかである。

こうした、連携・協調に対する骨格としては、ハブ&スポーク型の構造が有効である。まあ、有名なあのFedExモデルだ。例えば、各アプリケーションで生成されたデータは一旦統合データベースに集められて、そこから各ユーザに配信されるというイメージだ。

このような、ハブになる仕掛けがいろいろある。いまデータの話をしたがデータの場合のハブはEAIやデータウエアハウスであり、帳票印刷・配布なんかも同じ考えができる。(その当時はこの統合プリントシステムがなかった) また、機能のハブがBPMであり、処理(プログラム)のハブはデータベースである。

こうしたハブ&スポーク型の構造が今でいうSOAにつながっていると思っている。FedExモデルも当初は単にモノを運ぶだけの仕組みであったが、最近は空港の近くに倉庫を持って物流・在庫管理を含めたサービスも提供するようになった。ということは、当初はハブ&スポーク型の構造でデータやその他の情報を行き来させるだけだったのが、サービスという形に変えて連携するSOA型に進化してきたのは、FedExと同じだと考えればわかりやすい。

ということで、最近ではハブが企業内だけにとどまらずインターネット全体に存在し、単純な構造から網の目のような複雑で柔らかい構造になってきている。ここで言ったようにこうした展開は、別にSOAを意識したものではなくある意味必然的にたどりつく道であるような気がする。繰り返すが、SOAを構築しましょうではないのです、柔軟で変化に強い仕組みが作りたくて、できたものがSOAだったということなのです。


2007年3月10日

ブログの書き方

ここ数日、何となく元気がでない。このブログもビジネス関連を続けているが、他のネタであまり書いていない。でもだんだん快復してきたので何を書こうかなあと思案していたら、そもそもブログというのは何なのかと考えてしまった。日記なのか、備忘録なのか、エッセイなのか、時事批評なのかと、でもこれは別に枠にはめなくてもいいわけで、自分の好きなように書けばいいだけという当たり前の結論。

ただ、自分はこういうブログを書くのだというちょっとしたポリシーは要るかもねということと、日記や備忘録ではなく、自分の考えとか思いを書きたいとなると、自ずとその書き方というものがあるような気がする。やはり、たかがブログだけれど、根底に誰かに読んでほしいというのがあるのだから、読みやすい、わかりやすい書き方というものもあるはずだ。

そんなことに関して、梅田望夫さんがなるほどと思わせるいいことを自身のブログに書いていた。梅田さんは、文章を書くときの重要な3つの要素を「構造化」、「想定読者」、「書き手の個性」だと言っている。

「構造化」というのは、対象を幅広い視点から俯瞰して理解することで、「想定読者」は文字通り誰に読まれたいのか、訴えたいのかで書き方も変わるということ、そして、「書き手の個性」ということで、前2つはいわば普遍的なものであるので、それだけだと同じものになるかもしれないので、書き手による差別化が要る。読者は実は文章の向こうの「書いてる人」を読みたいものだという。梅田さんはそういうことをいつも考えながら文章を書いているそうだ。まさにこの3要素は重要で、ぼくもすごく難しくて実行できているかお寒い話ではあるが努力しようと思う。

このような、文章表現のお手本は「天声人語」(他の新聞社も含めて1面下のコラムのこと。いまは、読売新聞の「編集手帳」のほうがおもしろいが)なのかもしれない。あの限られた字数のなかで、起承転結をきちんとさせて、読書をうならせる術はたいしたものだ。ただ、ぼくらとぜんぜん違うのは、参照するデータベースがものすごいから、関連する情報がぽんぽん飛び出すので、文章に重みがある。

それで今日の朝日新聞を読んでいたら、「~天声人語から書く~  現役高校生の天声新語コンクール」の記事があった。これは、「天声人語」の第一段落に続く文章を競い合うもので、その結果が出ていた。この第一段落というのは、「ニュースの関心度を測る物差しはいろいろあるが、現場が遠いか近いかもその一つ。地球の裏側の都市で五十軒焼けた火事よりも、隣町のぼや騒ぎの方が、とかく耳目を集める」でこのあとに文章を続ける設定である。

最優秀賞に輝いたのは1年生の女子高生で、高校に電車で通うようになって、駅までの間で見かけるものが新鮮で面白く感じ、それが毎日変わることを自分だけが気づくことかもしれないが、新聞で読む世界の出来事と同じくらい大事なことだというようなことを書いていた。すごくセンスのいい文章で感心させられる。きっと彼女のブログ(あるかどうか知りませんが)も素晴らしいのではないでしょうか。

しかし、受賞した9人のうち8人が女子高生という完全な女性上位という結果。最近の文学賞の受賞者も女性が多いし、文章を書く能力は女性が優れているのかなあと嘆いているのであります。男性諸君がんばりましょう。

ユーザ目線のBPM(11)

どうやって開発するか

さていよいよ、開発方法の話になります。開発というと忘れらない言葉があって、開発につきまとう2つのジレンマについてのことだ。その2つの大きなジレンマとは

1.アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと

・・・仕様を決定付ける科学的、工学的なモデルが存在しない

2.情報システムと人間の境界が、元来不安定であること

・・・実業務の様々な例外をコンピュータ上に乗せるか否か

ということで、このジレンマを克服しないうちは、前に言ったようにユーザとITがお互いに嘆きあう状況はいっこうによくならない。ただ、ユーザ側からみれば、ある意味当たり前で、システム屋が困ろうが知ったこっちゃないのであって、目の前にあるビジネスをどう切り回すかだけを考える。だから、ITはそこで役に立って当然で、ITが足かせになるなんてもってのほかなのだ。

極論すると、社長が“こうしたい”と言ったらすぐに実現しなくてはならない。昔、松竹新喜劇の藤山寛美がリクエスト公演というのをやったけど、お客さんが望んだものをすぐに提供できるのがプロのシステム屋のすることでしょう。それを、“うちのお客はわがままなことばかりで全く困る”と言っているようではダメなのだ。確かに無茶なユーザがいて頭にくることは分かるが、そんなやつらを軽くさばくのがプロではないでしょうか。プロの定義は「ひとのせいにしないこと」だ。こうしたユーザの“ぶれ”とそれともうひとつ変化のスピードを前提とするなら、どうも従来型のアプローチでは対応が難しいように思える。ということは、システムの作り方を変えていかなくてはいけない。だからこそBPMが有効な手段である可能性を感じて探っているわけです。さて、BPMは”ビジネス機能、あるいはサービスをコンポーネントとして持って、それをBPMで組み合わせてプロセスを作り、それらプロセスの集合が業務アプリケーションとなる”と考えていきたい。その最初のコンポーネントを業務コンポーネントあるいは業務モデルと呼び、それをどんな方法で作るのか、あるいはどこかにすでにあるのかといったことが最初の議論となります。このあたりの試みはもちろんだいぶ前から行なわれていて、いろいろな角度からの検討があります。その結果としてERPやその他業務パッケージになったものもあり、また、データモデリングという切り口で見ているものもあります。そこで、少し最近の動きとして、「要求開発アライアンス」と「DOA+コンソーシアム」という2団体に注目してみていくことにします。両者のアプローチは違うが業務フローや業務モデルを描くという点では共通点があり、BPMが必要とする業務コンポーネントの生成についてどう取り組んでいったらよいか非常に参考になるし、場合によっては連携も考えられる。次回にこれらの団体の考えていることとその利用などについて述べていく。

2007年3月11日

お金の持ち歩き方

少し前に財布を落としてからじっと家にいておとなしくしている。財布を落としたことを嫁はん(この表現はOKなのかな?家内って言ってはいけないそうだから)からなじられるし、実質的にも、現金、キャッシュカード、クレジットカード、免許症、Suica、各種プリペイドカード、病院の診察券、会員カード、各種ポイントカード、呑み屋のおねえちゃんの名刺、みんななくなってしまった。とほほ。

大船の居酒屋で呑んでいてその店で財布からお金を出して、お釣りを直接ポケットに入れたところまで覚えていて、歩いて駅まで行ってすぐにタクシーに乗って、タクシー代はそのポケットにいれたお釣りで払った。そしてタクシーを降りて家に入ろうとしたら財布のないことに気づき、幸いタクシーがUターンして来たので止めて中を確かめたけどないのだ。ですぐ呑んでいた店へ電話したが見当たりませんという返事。万事休す。

その日のうちにキャッシュカードとクレジットカードを止めて、翌日すぐに交番に紛失届けを出し、二俣川に行って免許証の再交付をしてもらう。おお、金と時間のロス。しばらく買いたいものも買えない、呑むのも控えてという情けない状況になった。

ここでちょっと腹立ったのは、病院の診察券の再発行にお金がかかることで、ある病院で「再発行にはお金がかかりますがどうしますか?」、え、どうしますと言われても、よほど「再発行しなかったらどうなるんですか、診察してくれなんですか?」と聞き返そうと思ったがやめた。

ぼくは、いままで財布を持っていなかった。厳密に言うと、お金は財布に入れて持たないことにしていた。それと、カードや免許証は持ち歩かないことにしていた。なぜって、落とすかもしれないからで、よくズボンのお尻のポケットに半分出かかっている財布をみかけるが、そんなのを見ていると危ないからなのだ。それが、家で仕事をするようになると結構カードを使う機会が増えるし、自分を証明するのに免許証がいることもあって財布を買って使っていた。

というわけで、あれからは、財布は持たず現金をそのままポケットに入れ、カード、免許証は持ち歩かないことにした。まあ、みなさんも気をつけてください。

「サンマーメン」か「かつ丼」か

サンマーメンというのがある。知らないひとはサンマが入ったラーメンと思っている。これは、ラーメンの上にもやしやその他の野菜を片栗粉のあんで絡めたものである。冬の寒い時なんかでも中味がなかなか冷めないので汗をかくくらいだ。ぼくの大好きな料理で、おいしいですぞ。

以前、ぼくはこの料理は全国どこにでもあると思っていたら、何と神奈川県にしか(静岡県の一部にもあるらしい)ないのだそうで、びっくりしたが、そういえば東京にもないし、ましておや三重県では見たこともなかったと思いあたった。

このサンマーメンで有名な店が鎌倉の材木座にある。「中華 薊」という店で九品寺のすぐ近くにあり、テーブルで20席くらいの小さな店だがいつも混んでいる。ときどき行くんだけどだいたいがサンマーメンを注文する。やはりお客さんのほとんどがサンマーメンを頼むらしい。

ところが、ぼくが行っているときサンマーメンを頼む人が割と少ない。なぜだろうと考えたら、よくサンマーメンを頼むひとはガイドブックを持った遠くから来た人が多いようだ。近所の人たちは毎回サンマーメンを食べるわけではないので、そういうひとたちが多い時はそんなことはないということのようだ。地元密着の有名店はこういうことがよくある。

で、今日は、プールに行ったらあいにく競技大会があって一般の人が入れないとのこと、しかたなく、そこから北鎌倉に抜けて少し鎌倉を走ってみることにした。鎌倉駅を通り過ぎたところで、そうだ「薊」に行こうとひらめいて、そのまま直行。幸いにも駐車スペースが一台分空いたので待たずに入店。

さて、サンマーメンにしようかと思ったら、いやかつ丼だとなった。中華料理屋でかつ丼って邪道と言われるかもしれないが、ここのかつ丼はうまいのだ。中華料理屋特有のラードで香ばしく揚げたかつをのせ、ちょっぴり甘めでイケてるのだ。というわけで、本日はB級グルメの中華料理屋のかつ丼の巻でした。

P1000035.JPG

2007年3月12日

ユーザ目線のBPM(12)

「要求開発アライアンス」と「DOA+コンソーシアム」

「要求開発アライアンス」というのは、2003年5月にビジネスモデル研究会としてスタートし、2005年3月に「要求開発アライアンス」として発足した団体。豆蔵の人たちが多く参加していますが全部で13人が発起人みたいになっています。当初、「要求開発宣言」としてまとめられたものが、このアライアンスの趣旨を表わしているので、長くなるが引用する。

・情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。

・情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。

・情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。

・ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。

・要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。

・「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。

これに基づき、モデリングのやり方やビジネスフローの標準化など要求開発の方法論が提示されている。

体系的でよくできていて、例えば「モデリングガイドライン」というのがあって、その中に「ビジネスフロー編」があるが、まずUMLアクティビティ図から業務の流れとシステムの関係を捉え、そのアクティビティの粒度の基準があって、それを調整して標準化するやり方が書いてあったりします。

ただこうした手法も有効かと思うが、トップダウンアプローチ的なところがあり、もう少し泥臭いやり方でいいのではないかと思ってしまう。

DOA+コンソーシアム」は、2003年12月に設立された。一体ここは何をめざすのかですが、この会の代表幹事であるデータ総研の椿正明さんの言葉を引用してみます。ちなみに、その他の代表幹事が東京国際大学の堀内一教授、株式会社エス・ディ・アイの佐藤正美さんという、DOAをかじったことがあるひとはびっくりするメンバーです。(3人が一同に会することも含めて)

システムの上流工程にモデルアプローチを適用するのが正解とされつつありますが、DOAなのか、それともUMLによるOOなのかについては、迷っておられる方が多いように見受けられます。さらにOOについては「人の数ほどいろいろなやり方がある」、また「DOAについてもいくつかのアプローチがある」ということで余計な混乱を招いているようです。 われわれは、「情報システムの製品は画面・帳票であり、これと直結したデータがシステムの基盤を作る」として、「まずはWHATとしてのデータを固め、次にHOWとしての処理を考えるDOAアプローチが正解なのではないか」と考えます。そして90年代、メインフレームからC/S、あるいはERPへのシフト に追われているうちに、「DOA技術の継承が中断され、危機的状況にあるのではないか」と心配しております。そこで「これを解消したい」との思いから、かつてのIRM研究会を思い出しながら、「DOA+コンソーシアム」を立ち上げることにいたしました。

狭く簡単に言うと、DOAとOOは対立するものではなくうまく棲み分けすることができるはずで、そのためにはUMLとの融合あるいはOOPとの接続が論点だとしている。

BPMではデータについてはあまり議論されていません。業務の構造は、プロセスモデルとデータモデルで表現されるものですから、しっかりしたデータベースの構築は非常に重要です。そのためのアプローチはDOAが一番です。ですから、BPMとデータモデルはうまく連携する必要があります。従って、DOAでデータモデリングすることは必須になると考えます。

詳しくは次回に。

2007年3月13日

ユーザ目線のBPM(13)

DOAによるデータモデリング

DOA+の手法についてはいくつかあって、代表的なのが「T字形ER手法」、「THモデル手法(PLAN-DB)」、Xprime(Xupper手法)、「三要素分析法(渡辺法)」などである。それぞれ特徴があるが、THモデル手法を開発したデータ総研の椿さんの考え方を中心に書いてみる。

前にも言ったように、業務モデルは「プロセスモデル」と「データモデル」から成り立っていますが、この業務モデルは実装独立であることが重要です。例えば、受注という業務を考えたとき、顧客、商品、数量、納期、金額などのデータが扱われますが、これはいつの時代でも変わらないもので、変わるのは実現手段です。従って、業務アプリケーションソフトウエアは「業務モデル」を実装手段を用いて実現したものとなります。ここが今まで一緒くたになっていたと思われる。

さて、業務モデルの構成要素を椿さんは次のように定義しています。

クライアント側の要素  : 「人」と「IO」

サーバー側の要素    : データベース、エンティティ、データ項目


これらの要素をフロー図やIOイラスト、概念DB構造図、データ定義書などに表現するわけです。そして、こんなことも言っています。

われわれの夢は、今は価値がないとされる業務モデルのコンテンツが流通し、市場価値を持つようになることです。ある単位の業務モデルリポジトリのコンテンツをライブラリとして貯え、これを適宜選択・組合わせて、自社に合ったデータモデルを構築することができれば、「パッケージに身体を合わせろ」と言った妥協を大幅になくせるものと考えます。これをアメリカより、1年でも2年でも早く実現するのです。そうすれば90年代に付けられた差を一気に逆転する可能性すらあるように思うのです。

そうですよね、椿さんはもう70歳を越えて益々元気なひとで、そのアグレッシッブさには頭が下がりますが、ぜひ夢を実現していきましょう。

つぎにDOAの条件として、「データ先行・リソース先行・概念先行」ということになります。データをプロセス/処理に先行して考え、イベントデータ(受注・出荷・請求など)より先にリソースデータ(社員・顧客・商品など)を固め、物理データベースより概念データベースを先行するという意味です。 こうして、DOAで業務アプリケーションの開発をやってみると、データ構造からみてつぎの6種類に分類できると言っている。

A.建設:見積-受注-建設計画-建設-検収

B.生産財製造業:受注-生産計画-生産-出荷

C.消費財製造業:販売計画-生産計画-生産-受注-引当-出荷

D.卸業:販売計画-仕入-受注-出荷

E.小売業:販売計画-手配-販売

F.サービス:契約-設定(工事/担保)-サービス-検収


また、企業はこのように基幹系業務は、A-Fの6種類に分類できるが、企業にはこのほかに、次のようなリソース(経営資源)整備軸とも言うべき6種類の業務アプリケーションがあるとのこと。これは、別な言い方をすれば、コア業務システムを支えるサポートシステムとも言える。

1.人材調達・育成(人事)

2.市場開発・保守(CRM)

3.設備建設・保守

4.商品開発・改良(PDM・PLM)

5.資金調達・利殖(財務)

6.情報システム開発・保守

まあ、ここではDOAがメインテーマではないので、かなりざっくりとポイントだけ書いてみましたが、何となくBPMとDOAの関係がわかったでしょうか。

例えば、上記業務アプリケーションに必要なデータモデルがあるでしょうから(なかったら、この手法で開発する)、それを使ってBPMでプロセスモデルを生成するというスタイルは有効のような気がします。というより、データモデリングとうまく連動しないといけないのです。

この他、これから注目したいのは、羽生章洋さんのABD(Activity Based Datamodel)や仕事の流れを表現するマジカあたりで、気になるところです。

割烹着のある店

昨日は、芝公園で日本BPM協会の交流会があったのでそこに出掛ける。事例報告やWGの進捗などの説明があって、夜は懇親会となった。立食だったので歩き回ってひとしきりいろいろなひととおしゃべりをする。そのあと、その会の幹事のひとりであるUさんと約束していた2次会へ行く。どこにしようかと言うので大門の近くの小料理屋にする。

ここは、「新日本料理 美正」というのだが、何が“新”なのかよくわからない。少なくともメニューはここ5年くらい変わっていない。板さんと女将のふたりでやっていて、さかながうまい店で、お客さんはまあ年配のひとが多く、落ち着いたところです。以前の会社が芝公園にあったのでそのときはちょくちょく接待なんかに使っていたが、ホント久しぶりに行きました。いつものように、お刺身とぼくの好きなさよりをあぶってわさびマヨネーズで食べるやつを出してくれました。

で、これからはその女将の話で、このひといつも着物を着てその上に割烹着をしているのだ。いまの若い人は割烹着なんて知らないかもしれないが、ぼくらのおかあさんは皆割烹着を着ていたのだ。だからって、萌えているわけではありませんので念のために。

あるとき、お客さんがいなくなったので一緒に呑んでいたら、なぜか話がぼくがそのとき住んでいた白山のことになった。下の息子と1年半くらい暮らしたことがあって、いつも近くの焼き鳥屋に行っていて、そこの夫婦とも懇意になった。話が進んで、その焼き鳥屋の話になった。そうしたら私もよく知っていると言い出した。何ということはないぼくのちかくのマンションに住んでいることが判明。しかも、その焼き鳥の娘と自分の娘が中学の同級生でよく知っているという話。大いに盛り上がったのであった。

前にも、たまたまバーで隣合わせたひとがぼくの家のすぐ近くのひとだったという話を書いたが、世の中狭いなあという続編です。

そのとき女将に「ねえ近くなんだから休みの日に一緒に呑みましょうよ」と誘われてしまった。もちろん「ハイ」と答えたが残念ながら実現しなかった。だって、いまどき割烹着を着る人の歳ってわかりますよね。

2007年3月14日

ユーザ目線のBPM(14)

業務プロセスモデリングの進め方

ここでは、業務プロセスのモデル化を行い、できあがったプロセスからある単位(粒度)で切り出してコンポーネント化する作業のとっかかりのところを議論することにする。

まず、要件を定義していくとき、トップダウンアプローチなのかボトムアップアプローチなのか、AsIs先行かToBe先行かという問題があります。ここでいうトップダウンアプローチとうのは、経営管理あるいは事業運営上必要となる要件、いわゆるビジネスモデル的なハイレベル要件から見るもので、ボトムアップアプローチというのは、逆に業務フローをまわすための要件、いわゆるオペレーショナルなローレベル要件からみるものであるが、当然両者とも必要なアプローチであるが、筆者は最初はローレベル要件から入って、そこを固めてからトップダウン的にこだわり要件を付加していくやり方が現実的であると考える。

同じように、AsIsかToBeかの議論もAsIsから入ってTobeへ持っていくほうがこれまた現実的だと考える。

理想的には、経営戦略や事業戦略からあるべき姿を描くほうが、BPR的だし、新しいシステムによって会社を変えるんだという意気込みのある企業にはいい方法かもしれませんが、非常に難しいアプローチのように思えます。コンサルやベンダーはどちらかというとこのやり方を推奨してきます。

筆者も以前はそのやり方がベターと考えていたが、これだと、一旦既存のシステムや仕事のやり方を忘れてゼロベースで考えてください、そしてこうすべきだという姿を描いてくださいとなるわけですが、そう言われても普通の人はとても難しく、どうしても今もこうだからとか手持ちのリソースでは無理だとか思ってしまう。結局、現状ベースから抜け出せないことになる。それならいっそ最初からボトムアップでAsIsから入ればいいのではないかと考えるのです。

モデリングの進め方の概略としては、

1.現状の業務プロセス(AsIsモデル)を抽出します。

2.その業務プロセスをプロセス・アクティビティ・タスクなどに分類・整理して可視化します。

3.可視化された現状業務からプロセスと業務機能を分析・評価します。

4.プロセス・機能を共通化・標準化・一貫化したり、重複を排除したりプロセスを適正化します

5.事業要件などから追加・修正を行いTobeモデルを作成します

このとき、ただプロセスと機能のマトリックス表を埋めるだけになってしまうと、単なる現状追認業務モデルになってしまうので、どうやって適正モデルにもっていくかが重要なポイントとなる。そこは人の頭の中で考えてよ風の方法論があったりして困ってしまうことがある。だから、そこを属人性を排した論理的なメソッドが必要となるのだ。だれがやってもだいたい同じ結果になるようなルールやガイダンスが用意されているかとなる。

いまここで、適正モデルと言ったが、ほんとうは最適モデルと言いたいのだが、2つの点で最適モデルができるのだろうかと疑問になる。ひとつは、真の最適モデルが作れるのだろうかという問題で、何もかも満足できる成果物となりえないのでないかということです。

もうひとつは、よしんば最適モデルができたとしてもその寿命はどれだけあるのだという問題で、いまの世の中ではすぐに陳腐化してリニューアルしなくてはならなくなる。従って、苦労して最適化するより、その時点で最適に近いと思われるところでどんどん進めていって、絶えずアップデートしていくようなやり方ができないかということである。ですから、最適モデルというより、「適正モデル(Normalized Model)」としたほうが何となくマッチしていると思うのですがいかがでしょうか。

隠し剣 鬼の爪

これまで見逃していた「隠し剣 鬼の爪」を観る。ちょっと前にテレビで放映したのを録画しておいたのだ。これで、映画化された藤沢周平作品はみんな観たことになる。山田洋次監督の「たそがれ清兵衛」、「武士の一分」とこの作品の三部作と、2005年に封切られた黒土三男監督の「蝉しぐれ」の4本である。

どれがよかったかはひとまずおいて、両監督のことだが、実は黒土監督は山田監督の作品映画『幸福の黄色いハンカチ』で脚本家の一人として参加していたことから山田監督を師と仰いでいるそうだ。だから、「蝉しぐれ」も多少山田洋次の影響がないことはないが、この作品の良さはまるで日本画を見るようなすばらしい映像であった。

さて「隠し剣 鬼の爪」だが、山田監督作品では順序は違うが3本目となるとまたかよということになる。だいたい、同じパターンなのだ。みんな剣の達人だけど普段はそんなそぶりをみせないで、となりには妻ではない美しいひとがいて、いずれ妻になる。それで自らにふりかかる理不尽な圧力に最後はたちあがり敵をやっつけるみたいな展開なんですね。

まあでもこの「隠し剣 鬼の爪」という作品で面白いところは、友達3人における三様の男女関係が出てきて対比することができることかも。まず、主人公の片桐宗蔵ときえの関係、片桐宗蔵の妹を妻にする島田左門、謀反を起こし討たれてしまう狭間弥市郎とその妻、それぞれがまったく違う境遇が描かれる。

ついこれを今の時代にあてはめるとどうなるのかと考えてしまう。武士をやめて町人となり、きえと一緒に江戸にいく片桐宗蔵は、あるとき脱サラして田舎で農業をやりだす優秀なビジネスマン、島田左門は誰にでも好かれる役所につとめる好青年、狭間弥市郎はベンチャーを起すが借金が溜まって倒産する起業家とみたてたけどどうだろう。

まあ、この4本のなかでどれが一番よかったかはなかなか難しいので、マドンナの順で決めようかな。宮沢りえ、松たか子、木村佳乃、檀れいと並べてみたが、う~ん、引き分けでがんす。

2007年3月15日

ユーザ目線のBPM(15)

業務プロセスの適正化

前回、概略のモデリングついて述べましたが、今回はそれをもう少し詳細にみていくことにします。

まず、AsIs先行ですから、最初に現状業務プロセスの抽出を行いますが、これは一般的にやられているように業務フロー図(アクティビティ図という場合もあり)に書き出すことになります。既存システムがある場合はその画面や帳票から抜き出していきます。

また、業務としてのプロセスを捕捉するわけですから、システムで行っているものだけではなく、手作業や外部に委託している作業なども書きだします。業務フロー図は2次元ですから、2軸に何を記述するかがありますが、部署・役割―工程・プロセスというのが普通です。

こうして、AsIsベースの業務プロセスを抽出したら、プロセスと業務機能のマトリックス表(Excel)を作成する。対象プロセスは、プロセス・サブプロセス・アクティビティに階層化される。例えば、受注~売上計上―受注-注文受付というイメージです。

このとき、プロセスは始点と終点が明確になって完結していることが重要なポイントです。そのアクティビティレベルで業務手順、前後のつながり、参照情報、作業手段、帳票、担当者などを記入する。これにより、現状のプロセスと機能機能(アクティビティ)が整理されます。ここでのチェックポイントは、

1.業務プロセスと業務機能が全部抽出されていること

・・・抜けているプロセスや機能がないか

2.業務プロセスが自己完結していること

・・・業務がどこで終わっているか不明だったりしないようにする

さて、ここからToBeへ展開していくわけだが、具体的には、まずつぎのような視点で見直ししていく。

1.業務プロセスとデータが途切れず流れているか(一貫化のチェック)

2.業務プロセスが複雑で分かりにくくなっていないか(シンプル化のチェック)

3.業務機能で似て非なるものがないか(共通化のチェック)

4.同じ業務処理なのに部署によって違っていないか(内なる標準化のチェック)

5.業務機能で例外処理がないか、へんなこだわりはないか(外なる標準化のチェック)

6.電子化やシステムに置き換えられることはできないか(IT化のチェック)

とにかく”シンプルな”業務プロセスにすることが最も重要である。ムダのない単純な構造は美しいものなのです。

上記視点で業務プロセスと機能を見直していく。具体的には、二重入力・起票の有無、迂回路有無、重複作業、分岐処理などいくつかのチェック項目を設け、それを上述の表に追記していく。同時に共通化あるいは標準化できる業務機能を洗い出して、その機能を汎化や集約を行ないながら定義していく。

こうして、共通化、標準化された業務機能からなるシンプルで一貫化されたプロセスができあがる。この一連の進め方を業務プロセスの適正化と呼ぶ。ここをある程度自動化できないかというのが筆者の願いなのです。ツールが適正モデルに誘導してくれるイメージです。BPMSにこうした機能が具備されることを期待している。

さて、ここでとりあえず“きれいな”プロセスとなるが、あくまでボトムアップ的アプローチであるため、ハイレベルな要件があれば、このプロセスに付加して価値を高め、差別化を図っていくトップダウン的作業がある。“魅力的なプロセス”になるかどうかはここにかかってくる。ただし、ここはもちろん自動的にはいかないのでしっかり議論し、ベンチマーキングもしながら知恵を出すことになる。

2007年3月16日

ユーザ目線のBPM(16)

コンポーネント化

プロセスができたら、そこから機能(プロセスまで含む場合もある)をカプセル化して、コンポーネントを作成していく。まず、コンポーネントの分類と粒度ということから考えていこう。

業務プロセスは、業務サービス―業務コンポーネント―システム機能コンポーネントから成り立っていると考える。例えば、「販売管理」で「受注」~「代金回収」までのプロセスを考えると、そこには「出荷」という業務サービス(この単位でコンポーネントとしてもかまわない)があり、そのなかの「出荷指示」というアクティビティが業務コンポーネントになる。

一方、認証だとか帳票やコード変換といったシステム的な機能については、システム機能コンポーネントとして括り、共通部品的な使い方となる。もう少し、例示的言うと、

・業務サービス      :見積り、受注、発注、与信、クレーム処理、出金伝票承認・・・
・業務コンポーネント   :受注受付、在庫引当、検収、見積査定、出荷指示・・・
・システムコンポーネント:カレンダー管理、データ集配信、ロール管理、メール・・・

これらの粒度でコンポーネント化をしていきます。コンポーネント化は、MVC(model/view/control)モデルをベースにして行ないます。また、当然データベースがきちんと構築されているという前提です。ただし粒度については、これでは大雑把すぎますので、作業者がひとりで行える単位にするとか後続機能に後処理を依存させない単位にするだとかの基準は設ける必要があります。

ちなみに、大和総研の池田大造氏は、コンポーネント化の指針で、分割基準として、「最小構成単位」と「機能的な完結」,「コンポーネント構造」をあげていて、その中の「最小構成単位」でつぎのように言っています。

複数のアプリケーションを集めたコンポーネントの最小構成単位は,ビジネスで扱う人や物など「もの」として定義された対象物(エンティティ)の生 成から消滅までにしている。例えば債権についてのコンポーネントは,債権の発生から消滅に関する更新要求や参照要求への対応,ビジネスロジック(債権充 当,充当修正,滞納判定,滞納情報作成,滞納解消情報作成,回収代行債権返戻情報作成など),コンポーネント外部とのインタフェースを制御するデータ変換 部分を対象とする。コンポーネントは,情報として管理するものの最小単位ともいえる。

また、何でもかんでもコンポーネント化すればいいというものではなく、なかにはコンポーネント化に向かない機能もあるので、そういうものは無理してコンポーネントにしたところで再利用もされないわけなのであきらめます。例えば、スタッフの不定形作業なんていうのは難しいのではないでしょうか。 こうして作られたコンポーネントをライブラリーに格納して使い回していきます。

さて、このコンポーネントすなわち業務モデルは標準業務モデルであるのかという問題がある。前にも書いたが、標準化では、内なる標準化と外なる標準化という表現をした。内なる標準化というのはいわば社内標準であって、支店や営業所でまちまちであった処理慣習などを標準のものにすることである。一方外なる標準というのは、業界標準であるのかとかグローバルな目でみたとき固有性が排除されているのかといったことになる。

おそらく、業務コンポーネントのレベルでは、自社固有の部分は少なく、業務サービスのレベルで固有性が現れるのではないかと筆者は考える。従って、業界あるいは一般的に業務コンポーネントを共通利用するのは可能であるように思える。ですから、業務サービスはこの業務コンポーネントの集合ですから、その組み合わせで“クセ”が出ると考えられないか。このことは、逆に差別化する源泉でもあるわけで、他社と比べて違った業務サービスを持っていることが事業上で有利になるとも言える。「組合わせの妙」ということだ。

さて、業務サービスという言葉で言ったようにこのレベルでひとかたまりにして大きな粒度のコンポーネントにしてもかまわない。だから、狭義のERPや業務パッケージもコンポーネントと考えてもいいと思う。その場合は、カスタマイズやアドオンがほとんどないという前提での話しだが。

さらに、そうしたサービスを自分たちで作るのではなく外部から持ってくることも可能だ。例えば、与信管理のサービスを外部の信用調査会社のサービスを利用するとか、最近では福利厚生関連の多くは外部サービス化している。

次回にこうしてできたコンポーネントあるいは外部サービスを使ってシステム開発する「コンポーネント開発」について論ずる。

2007年3月17日

ユーザ目線のBPM(17)

ビジネスコンポーネント指向開発

コンポーネント活用の開発法には、「コンポーネントベース開発」とか「コンポーネント指向開発」などと呼ばれているものがある。しかし、いずれもソフトウエアのコンポーネントという考えが強く、ビジネスの視点が弱いので、ここではあえて「ビジネスコンポーネント指向開発」とする。

さて、コンポーネントを使って開発しようというのは、まずは早く開発できること、すなわち開発効率があがること、変更要求に素早く対応できることなのだが、これだけだと、まだ前に言った「開発の2つのジレンマ」の解決にならない。特に仕様がなかなか固まらないことへの対策は弱い。それでは、なぜユーザは仕様を決めないのだろうか、決められないのだろうか。

おそらく、一番大きな「理由はユーザが“なかなかその気にならない”ということではないだろうか。そうですよね、どんなプロジェクトでも尻に火が着かないとまじめに考えないものなんです。いくら、開発側が早く仕様を決めてくれと言っても、いま忙しいからだとか、自分じゃ分からないので現場の人に聞いてみるからちょっと待ってくれだとか言っていっこうにフィックスできないことが多い。また、逆にあれやこれや思いつくものななんでもいいから仕様に入れておけということになる。これをどうにかしたいのだ。

ということは、ユーザに早く本気モードにさせるのはどうしたらいいのだろうか。筆者は、とりあえず動くものをその場ですぐに見せることだと思う。見たものがすぐに稼動できてしまうのだということがわかると真剣に向き合ってくれるはずだ。ユーザの心理としては、紙に書いたものを見せられてもよくわからないし、周りのメンバーにも説明できない、実際の画面がどう動くのかとかをチェックしながら決めたいと思っている。それに、いくつかのケースを動かしてみて比較して決めたいのですぐにそれができるようにしてほしいのだ。Ismael GhalimiがBPM2.0で必要な機能としてOne Click Deployを揚げていたのはこういうことではないかと思う。

コンポーネントベース開発の概略手順はつぎのようになる。

1.対象業務プロセスの特定

2.プロセスと機能のマトリックス表の作成

3.コンポーネントライブラリーから適用可能ものを選ぶ

4.ライブラリーにないものは書き出す

5.BPMのモデラーを使ってフローを書くと同時に適正化を行なう

6.必要に応じてハイレベル要件を埋め込む

7.ライブラリーにないものは極力コンポーネント化

8.すぐに実装してユーザと摺り合せ、戻って修正・テストを繰り返す

9.システム本番稼動

この開発の特徴は、キーワードでいうと、モデル駆動型、イテレーション開発、テスト重視というところでしょうか。また、大事なポイントは、ユーザに見せてから稼動までを最短でやるために、実際に動くものを見せて、その場で修正してやっていくようなことでないといけない。他所からそんなことはシステムを知らないやつが勝手に言っていることだという声が聞こえてきそうだが、無理を承知で知恵をだすべきだと思う。

このプロセスで難しいのはモデリングと実装のギャップをどう埋めていくかだが、そこはいわゆるSE(最近はITアーキテクトとも言う)の登場でしょう。すなわち、ビジネスプロセスデザイナーが業務モデルをデザインし、プログラマーがコンポーネントをつくり、システムエンジニアそれを実装するという役割になる。それぞれの間でのコラボレーションや「摺り合せ」が開発プロジェクトを成功に導くのだ。

この開発形態は、ウォーターフォール型では難しく、アジャイル開発、手法としてはXPに近い形になると思うが、ユーザの人にとっては、むしろ、「セル生産方式」といった方がわかりやすいのではないだろうか。あのキャノンの生産方式で多能化された少数の人で最初から最後まで組み立ててしまうやりかたで、「ビジネスコンポーネント指向開発」も「セル生産方式」のように、数人で組み上げるイメージなのではないだろうか。

この開発方法は、(株)日立製作所 ソフトウエア事業部の桐越信一氏が提示している「コンポーネントベースモデリング」が非常によく整理されて参考になる。ただ、データモデルにあまり言及していないことと開発はフェイズドアプローチを言っているのがちょっと気になる。

また、「コンポーネントベース開発」ということで言えば、コンポーネントスクエアという会社ができていて、CBDスクエアというコミュニティを運営して、まさに「コンポーネントベース開発」について議論している。ただし、ここでは、参加がSIer中心のようで、ビジネスというより、どうしても開発側のシステム寄り視点になっている。だから、いい業務プロセスを作ろうというのではなく、再利用性が高いコンポーネントをどうやって作ったらいいのかという開発効率重視の考えが強いように思える。これは、再三言いますが、このコミュニティだけの話ではなく世の中全般に言えることのようです。

経営者の覚悟

ホリエモンが昨日東京地裁で実刑判決を受けた。この手の事件で執行猶予もつかない実刑判決というのは異例だ。粉飾決算の例ならカネボウだとか山一證券などがあるがいずれも執行猶予がついている。

なぜこうした厳しい判決が出たかというと、ほぼ間違いなかろう起訴事実を認めていないことと反省の色が全くないことだろう。事実認定については、それはそれで裁判として争えばいいが、ここで言いたいのは経営者としての責任について認めていないことで、これにはすごく怒りを覚える。

宮内被告が勝手にやったことで自分は何も知らなかったと吼えているが、100歩譲ってそうであったとしても、お前には責任があるのだ。

近頃、経営者が不祥事があると決まって報道陣の前で頭を下げる光景を目にするが、あまり感じがいいものではないとは思うが、経営者が知らないところで部下が悪いことをしたとしても、当然監督責任が問われるのだ。それが会社というものであり、「法人」としてのヒトの振る舞いだと思う。

また、今回でも堀江は“宮内のところで売上げがすごく伸びていたことは知っていたが、それは彼にまかせてあったから信用した”というようなことを述べている。これって、経営者としては全く失格で、そこでなぜ売上げの伸びが異常であったのか、その原因は何か、そういうことを精査し、財務状況をきちんと正確に把握するのは当たり前だし、それで経営が成り立っている。

さらに、会社の人事は経営者にとっても重いもので、経営者の権限の最大のものは人事権であると同時に任命責任は非常に大きい。だから、堀江が自分で任命した部下が不正を働いたのに私には責任ありませんというようなことをよく言えるかとあきれてしまう。

極論すれば、会社の中で起きた不正はすべて組織の責任だ。経営者というのは、そうした覚悟をもって、会社をつくり、経営をしていくものなのだ。

再度、「会社はだれのものか」を書いた岩井克人の言葉を噛みしめてほしい。

会社のどまんなかには、実は、利益追求とまったく対立する経営者の「倫理」があるんですよ。これが入っていないと、そもそも会社制度がなりたたない。自己利益を追求する資本主義には、倫理が本質的に入りこんでいるというのです。

2007年3月18日

マラソンは走らなくちゃ

今日、「2007湘南国際マラソン」を見に行った。このマラソンのコースは江ノ島水族館の前をスタートして二宮IC折り返し、江ノ島ゴールのフルマラソンコース。ほかにも10kmのレースもある。参加人数があわせて1万人くらいだそうだ。

富士山に向かって走り、江ノ島に戻ってくる、途中相模湾を横目でながめながら、しかも箱根駅伝で走るコースとくりゃ、楽しくなるだろう。今日は、絶好の天気で寒くもなくくっきりと富士山も見えて最高の日だったんじゃないかな。沿道にも応援するひとがあふれてもうお祭り気分。第1回目としては大成功でしょう。

エリートの部では有名な選手が出てないこともあり、元旭化成の高尾憲司選手がぶっちぎりで優勝。ゴールにいたわけではないのでタイムは分からないが2時間22分くらいじゃないかな。3時間を切る選手もけっこういて単純にすごいなあと思ってしまう。

ゲストが来ていて、高橋尚子、千葉真子、間寛平が10kmを走っていた。間寛平は当初フルマラソンにエントリーしていたが、インフルエンザが治ったばかりだったそうで10kmに変更していた。Qちゃんカッコイイ。

見ていると走りたくなるが、もはや足腰はポンコツとなり、1kmも走れない有様、しょがなく見物にまわったが、お祭りは見るもんじゃなく参加するもんですね。というわけで、千葉ちゃんに手を振ったらすぐそのまま自転車でプールに直行。泳ぐのはだいじょうぶなので、いつもよりかなり長く泳ぎぐったりとする。ほんのちょっぴりマラソン完走気分。

下の写真は、上が高橋尚子で下が間寛平です。わかるかなあ?

P1000045.JPG
P1000046.JPG

2007年3月19日

ユーザ目線のBPM(18)

コンポーネントの粒度

ここまででは、コンポーネントとして、業務サービスという言い方をした小さな単位の業務プロセス、例えば「受注」というようなものもコンポーネントとみなすと、こうした大きな括りの業務サービスコンポーネントがあって、その下に「受注受付」のようなアクティビティあるいはタスク主体の業務コンポーネントがあり、それを動かす共通基盤的な仕組みとしてのシステム機能コンポーネントがあると言ってきた。それでは、それぞれのコンポーネントの粒度をどう考えていったらよいのでしょう。

システム機能コンポーネントについては比較的考えやすいと思うので、ここでは、業務コンポーネントについて考えてみる。

まず、抽象的な言い方だと、ビジネスの環境や組織が変わっても、それ自体変わらない部分をコンポーネントの単位とすることなのだが、例えば、会計処理なんかはそのプロセスはそう大きくは変わらない(法改正、制度変更はあるが)から、業務パッケージそのものがコンポーネントと言えないこともない。こんな場合は、それをひとつのサービスとして括ってもかまわない。

最近Webサービスという形でネット上にもこうしたサービスが登場してきている。有名なSalesforce.comのオンデマンドサービスはまさにまるごと外部のサービスとして利用できる。だから、他社と差別化する必要のない機能は、できるだけ個別企業ごとに作るのではなく、外部のサービス利用という形態が望ましい。

こういうことができるようになったとというのがSOAのもたらした効果なのだ。企業は、システムを“作る”、“買う”(パッケージを買うという意味)、“借りる”のバランスをうまくとりながら構造化を図ることが大事である。

さて、もう少し具体的に見ていくと、一番問題となるのは業務コンポーネントの粒度をどうするかだ。この中には、単なるワンアクションのようなものから、ワークフローを含んだ処理までが想定されると考えられる。「生産量登録」みたいなものから「見積依頼」というようなワークフロー的なコンポーネントのことである。

例えばこの「見積依頼」という業務処理を考えてみよう。工事の見積を行なうと仮定するとこの処理は、「仕様書作成」→「仕様書承認」→「見積依頼書作成」→「見積依頼受付」→「見積依頼」のように流れる。このとき、「仕様書作成」のレベルを一つの業務コンポーネントとして、それらをBPMでつないでプロセスを作っていくというのもありですが、少し細かすぎるような感じがする。

そこで、BPMとWorkFlowについてだが、厳密な定義があるのかないのか知らないが、似ているように思うし、一緒のように言う人もいる。よくわからないというのが正直なところで別にそんなことを考えなくてもいいと思う。むしろ、WorkFlowって一体なんなのだろうかと見るほうが大切で、仕事というのは、ひとからひとへシークェンシャルに流れていくものであるという前提でWorkFlowという概念が成り立っている。

確かに、稟議決済なんて仕事が流れていく典型であるけど、大部分はその前提を崩して考えてもいいような気がする。すなわち仕事が流れるのではなく、“状態が遷移する”と考えるべきだということです。だから、ワークフローというのは、フロー制御とステータス制御の2通りあると捉える。

以前、.NETのフレームワーク上で動くコンポーネントを開発し、それを使ったアプリケーションを構築することを試行したことがあったが、そのとき業務というのは、書類をイメージした「データコンポーネント」が転記されて受け渡されることだと規定したことがあるが、これと似ている。

また最近、こうしたことを気づかせてくれたのは、あるCMSツールです。それは、Ploneといって、オープンソースのアプリケーションサーバーであるZopeとそのフレームワーク上に構築されたコンテンツ管理システムなのですが、そのなかにワークフローの機能があるというのです。で、よく見てみると、“オブジェクトの状態とユーザロール”を中心に構築されているのです。簡単に言えば、共通の場で情報を共有してそのステータスをコントロールすることで仕事ができると言っているのです。

このあたりはまた後述しますが、粒度の話に戻ると、ここにヒントがあって、ここで言うオブジェクト単位で粒度を設定すればいいのではないかということです。では、そのオブジェクトとは何だろう。筆者は上述したように、それは「書類」ではないかと考えている。すなわち、仕事の単位は、書類(必ずしも紙でなくてもいい)を作成してそれに追記・転記して完結するということではないかと考え、それをコンポーネントと捉えたらどうだろうか。このように考えてもいい業務処理はわりと多いと思われる。

従って、従来WorkFlowといっていた部分は、StatusControlとし、対象となるオブジェクトを書類(広義)とし、その単位でコンポーネント化する。コンポーネントは例えば、PloneのようなCMS(もちろん他のWebアプリケーションでかまいません)みたいなものでできて、それらのコンポーネントをBPMを使ってプロセスにしていくというのがざっとしたイメージになります。

ミクロなサブワークフローは軽量Webアプリで、マクロのメインワークフローはBPMという構成です。言ってみれば幹線道路はBPMで作るが支線や私道は軽量フレームワークでさくっと作ってしまい、ジャンクションは標準の取り決めに従ってつなぐという感じになりますがいかがでしょうか。全部がこれでできるとは思っていませんが、挑戦してみる価値はあるように思えます。


靴とマメ

湘南国際マラソンのことを書いたらちょっとに前に見たテレビ番組が浮かんできた。毎週金曜日の夜、日本テレビで放映する「未来創造堂」という番組がある。木梨憲武が司会をして、何かにこだわりを持つゲストとともに、日本が生んだ発明家たちの人生を再現ドラマで紹介する番組で、非常に良質ないい番組です。さすがホンダの提供。

つい最近のもので、「マラソンシューズ誕生物語」というのがあった。メキシコオリンピックのマラソンで銀メダルを採った君原健二は、まだ有名になる前、能力は高いのに、いつも長い距離を走ると必ず足にマメができて力が発揮できなかった。あるとき彼のシューズの製作を依頼された鬼塚喜八郎という靴屋が苦労を重ね、マメができないシューズを開発し、それを君原にはかせた結果、オリンピックでメダルをとる選手までになったという物語である。鬼塚喜八郎という人は、その当時「オニツカ」という会社でいまの「アシックス」を創業した人である。

この番組を見ていて、ぼくの若い頃のことを思い出した。ぼくは、サッカーばかりやっていたサッカーばかだったが、当時のサッカーシューズのことである。いまでこそ、こどもまですばらしいスパイクを履いているが、当時はスパイクは高価(今から40数年まえで確か3~4千円です)で、なかなか買えなかったのです。それと、練習ではズック靴を履かされていました。それは、ズック靴だと足の指先にちゃんと力を入れ、足首を固定しないとボールが飛ばないし、足が痛くなるので基本がみっちり身につくというわけだ。確かにいいスパイクを履くと少々ポイントがずれても飛ぶのでいい加減な蹴り方になるかもしれない。

で、このサッカーのスパイクなんだけど、当時は地方の町の運動具店なんかには売っていないのだ。しかも、メーカーも限られていて、「ヤスダ」と「ミツナガ」くらいしかなかった。そのオニツカのスパイクもまだなかった。少しあとに有名な「アディダス」が日本に入ってきたが、とても手に入らない高根の花でした。

それでぼくらは普通に「ヤスダ」のある東京の茗荷谷まで行くのだ。これがひと苦労で、しかも、出来合いのものはないから、それがいちから型をとったオーダーメイドなのだ。だから、型どりとできあがったものを取りに行くから2回東京に行くことになる。でも、新しいスパイクを水色で「YASUDA」という名前が入ったサッカーバッグに入れ、見せびらかすように帰るのが大きな楽しみでもあった。

そんな苦労をして手に入れたスパイクだから、そりゃ大事にしましたよ。まず買ってきてすぐどうしたかというと、近くの靴屋に行って、つま先に皮をあててもらうのです。つま先が先に破れるんです。それに毎日油で磨きましたね。ポイントだって、当時は皮とアルミとゴムのどれかだったんだけど、ポイントが外れると自分で新しいのに取り替えていました。いまの子はちょっとでもポイントが減るとすぐに捨ててしまうので、ああもったいないとすぐに思ってしまいます。

ボールだって毎日練習が終わると一旦空気を抜いて、翌朝空気を入れて縫い目をオイルで磨くのです。そうやって、モノを大切に扱ってきたので、しつこいけど今の贅沢さはいい感じではないですね。やっぱり、ぼくらのそういった生活で養われた精神構造といまのこどもたちのそれとは違うのは当たり前かもしれない。

それでマメのことだが、ようやくにして買って、そしてしっかり手入れして履いても、これがまたすぐにマメができるのだ。かかとと指に必ず大きなマメを作る。もう痛くてしょうがないのだが我慢するしかないから、絆創膏を貼るけど今のようないいものはないからすぐはがれるし、かえってよくないこともある。

でもって、だんだん慣れてきてマメのでき方がゆるやかになって、おおしっくりいったぞと思ったら、悲しいかな、ああつま先に穴が開き、底がはがれてくるのであった。だから、もうたえずマメとの戦いなのだ。

ちょっとそれるがもう一つ戦いがあって、「ビフテキ」というヤツで、当時のグランドってもちろん土で硬くでこぼこしているので、スライディングでもしようものなら太ももの外側がもののみごとに擦りむけて、まさにビフテキ状態となる。これがまた、直りかけると決まって同じところを。ということで学生服のズボンがぐじゅぐじゅでたまにくっついてしまうのだ。おお痛い。

また話がそれた。いまはマラソンにしてもサッカーにしてもその他のスポーツのシューズはすごくよくなってびっくりする。マメができるなんて考えられなくなってきている。ところが、久しぶりに家の庭の落ち葉を竹箒で一所懸命掃いていたら、手の指の付け根にマメができてしまった。それはしょうがないか。


2007年3月20日

ユーザ目線のBPM(19)

Web2.0のインパクト

前回、オープンソースのCMSの話がでたが、いま話題のWeb2.0とBPMはどういうことになるのだろうか。ここは、前に言ったBPM2.0という意味ではなく、Web2.0の思想やサービスモデル、技術についてのことだ。

Web2.0というとつい、Google、Amazon、Yahooといった企業あるいはWikipedia、SNS、ブログ、Youtubeといったサービスに注目するが、実は重要なことは、そこにある思想と支える技術の両面をきちんと理解することではないでしょうか。
有名なO’Reillyが作成した下記「Web2.0ミームマップ」を見るとWeb2.0の概念がだいたいわかる。

meme_map_small.gif

このなかから、BPMあるいは企業情報システムと関連する記述を見てみよう。
まずは、情報のハンドリングについては、「情報の自己コントロール」「集合知の利用」「参加のアーキテクチャ」がある。すなわち、Wikipediaに代表されるようにみんなが知恵を出し合ってできたものが一番いいものができるということ、さらにSNS、ブログ、Amazonレビューのような皆が情報の発信者になれるということで、こうしたユーザを信頼する楽天的民主主義の色合いが強くでているのがわかる。

システムのつくりみたいな領域では、「プラットフォームとしてのウェブ」、「パッケージソフトウエアではなくサービス」「永久にベータ版」、「利用者が増えるほど改善されるソフトウエア」、「モジュール化とゆるやかな統合(コンポーネントとしてのウェブ)」といったところになるが、これまで議論してきたことに大いに関連していると思いませんか。Webの世界と企業情報システムサイドとがだんだん近づいてくるように思えます。

ただし、ここで重要なことはWeb2.0の世界というのは、既成の概念を打ち破るパラダイムシフトのことですから、企業にとっても情報システムだけの話ではなく、企業体質、組織、仕事のやり方などが変革されなければ受け入れられない思想なのです。次世代の企業をめざすのなら、Web2.0的体質にならなくてはいけないし、脱皮できた企業が生き残っていくような気がする。

Web2.0によってもたらされた変化はいったいなんなのだろうか。

企業にインパクトを与えるものとしては、まず参加型のアーキテクチャがあげられる。ブログやソーシャルネットワークに代表されるように誰でも情報発信できるようになったことが大きい。これまで情報交換はせいぜいメール(メーリングリスト)ぐらいでしたが、これからは社内ブログのようなものも出てくるでしょうし、社外に対しても積極的に情報発信していかないといけなくなるわけで、これは、結果的に情報共有、情報公開ということが非常に重要な要素となり、平気で「不都合な真実」を隠蔽するような企業は生き残れなくなる。

この参加型のアーキテクチャというのは、従来の階層型の組織では受け入れられない考え方で、組織をフラット化してこそ生きてくる。実は、前回ステータス管理という仕事のやり方について書いたが、これがまさに参加型のワークフローなのだ。

従来のように階層化された組織を順番に仕事を流していくやり方では、そのフローのなかで業務処理の状況がどうなっているのかわからないまま、自分のところに“さあ、承認お願いします”と来ても困ってしまう。最初から利害関係者が参加し、そこで意見交換しながら仕事を進めていけば、自ずと意思決定も早くなるのではないでしょうか。

また、オープンソースプログラムのようにネット上にソースを公開し、そこに誰でもアクセスでき、知恵を出し合いながら作り上げる。こうした、知的生産活動はいままでのように個人で仕事を抱え込み、また抱え込むことで自分の存在価値を確認しているようなやりかたと違い、「永久にベータ版」として早めに衆知にさらせば、知的生産活動で生み出される情報の質はかなり向上する。要するに、社内の情報を握っているだけで部長になるようなことがなくなっていくということだ。

いまや、こうした情報リテラシーをもった若者がどんどん会社に入ってきている時代だ。会社自体も会社2.0に変貌していかないと、入社したはいいが3年で辞めていかれてしまうのではないでしょうか。

さらに、これまで自分のデスクトップ上にあったデータをネットワーク側に蓄積するようになり、それを基にネットワーク側から様々なサービスが提供されるようになった。それとソフトウエアが無料で使え、インターフェースも標準化され、簡単にHack、Mashupできてしまうチープ革命といわれることがあります。

しかしながら、この恩恵を受けるには自己責任ということを覚悟しなくてはいけない。それができる企業は自らの手で自らの責任でシステムを構築していくことを選択すべきであろう。それがいやなら、相変わらずベンダーの言うとおりに、20%の機能しか使えないソフトウエアを買い続けることだ。

ただし、無条件に無償のオープンソースを使うことを薦めているわけではありません。そこには、今言った自己責任ということとともに、技術に対する目利きと使いこなす技術力がいるため、やみくもにとびつくことはしないほうがいいと思います。自社のリソースを頭に入れて、そのメリット、デメリットをきちんと見極めることが大事です。

今回は、Web2.0の思想と企業の体質、組織などについて述べたが、次回はもう少し技術的な側面について考えてみる。

映画館が閉館する

藤沢でなんと71年間営業していた「オデオン座」が今月いっぱいで閉館することになった。理由は、興行収入の低下と社長の健康上の理由だそうです。いまは、市内にオデオン座、藤沢キネマ88、オデオン1番館、オデオン2番館の4館があり、洋画から邦画もふくめて多くの作品を上映してくれて重宝にしていたので非常に残念です。

以前にもこのブログにも書きましたが、大作だけでなくミニシアター系の作品を上映してくれたり、毎週水曜日がメンズデーで男だったらだれでも1000円で入場できるなど良心的な映画館であると評価していましたから、余計に惜しい気持ちがいっぱいです。

何よりも近くに映画館がなくなってしまい、これからどこに行けばいいのか悩んでしまう。藤沢にはもう一つ「フジサワ中央」という映画館があるが、ここは邦画専門だし、あきらかに年寄りとこども狙いなのだ。

オデオン座は71年前からあるから、ぼくが生まれる前で、もうホントもの心ついたときには、オデオン座で映画を見ていたことになる。また、わが青春の映画館でもある。学校さぼって観に行ったこと、何度笑いこけ、涙を流したことか、ああなくなってしまう。

最近は大型シネコンができてそちらのほうにお客さんをとられてしまったのだろうか。ぼくが会社をやめて映画館に足を運ぶことが多くなったから感じるのかもしれないが、平日でも年寄りのひとを中心にけっこう多くのお客さんがいたように思えて、だんだんよくなるのかと期待していた矢先なので残念でならない。

さて、来月からどこに行こうかな。

odeon.JPG

2007年3月21日

ユーザ目線のBPM(20)

Web2.0の技術は外せない

Web2.0の技術に関するキーワードを「WEB2.0 キーワードブック」(翔泳社)から拾ってみると、REST、XML、RSS/ATOM、URI、Ajax、Mashup、microformats、WebAPI、PageRank、Skype、があげられています。今後それぞれが多かれ少なかれ企業情報システムに影響を与えていくものと思われます。上記の本の執筆者は錚々たるメンバーでその分野の第一人者ですので、筆者が解説するのも無理があるので、サイボウズ・ラボの奥一穂さんが総括してくれているのでそこのポイントを抜粋する。

まずは、各要素技術をみるとき、サーバー間の連携、クライアントサイドへの処理の委譲、クライアント・サーバーモデルからの脱却という3つの流れを意識する必要がある。

従来型のウェブアプリケーションは、サーバー内に溜め込まれたデータを、サーバーサイドで処理して、ブラウザにHTMLとして配信するという手法でした。これだと、魅力的なアプリケーションを構築するためには、大量の商品情報やコンテンツを保有しなくてはいけなくなり、1社では限界がありました。

それをデータ公開という形で打ち破ったのがアマゾンです。そこでの技術でいえば、セマンティック・ウェブであり、Webサービスです。セマンティック・ウェブの基盤はRDF(ResourceDefinitionFramework)という文書モデルで、これに準拠したものではRSS1.0やFOAFが有名です。Webサービスはネットワーク上の複数のコンピュータで協調処理を行なうための取り組みで、基盤となっているのはSOAP、WSDL、UDDIといった規格です。

この両方ともに属さない技術としては、RSS2.0、XML-RPC、RESTがあります。この中では、RESTがHTTPの機能を多く使うため、ウェブサービスごとに異なる仕様が少なくなったり、ブラウザから動作の確認ができるなどのメリットから、RESTを活用したウェブサービスが増えている。

ウェブサービスに対応したとしても、ユーザが使ってくれなければ意味がありません。そこで出てきたのが、AutodiscoveryとMicroformatです。Autodiscoveryとは、HTMLページ内にXMLデータやXMLAPIへのリンクを埋め込む仕組みで、これに対応したWebサイトであれば、RSSリーダにHTMLページのURLをそのまま入力すれば、RSSリーダがそのページ内からHTMLタグを検出し、RSSの正しいURLを取得してくれる。一方microformatは、HTML内にXML等のちょっとしたデータを埋め込むことを言います。

クライアントの技術としては、Ajaxがあげられます。HTMLの表現力は決して高くありませんので、高度な目的のためにはブラウザでは力不足という認識でした。そこに、JavaScripとHTML、XmlHttpRequestオブジェクトを活用する優れたユーザインターフェースをもつ「Ajax」が登場したのです。入力インターフェースが格段に向上してきている。

その他、GoogleAdSenceで使われるClient-side IncludeやSkypeに代表されるP2Pなどがあります。

最後に、Web2.0的技術に共通する特徴は「目的を実現するためのチープなソフトウエア技術」であると言える。

こうしてみるとWeb2.0の技術というのは、ユーザ指向、サービス指向でその目的にあったものを簡単にさくさくできるための技術のようだ。ということは、いままで論じてきた「ユーザ目線のBPM」にとっては外せない技術であると言えそうだ。前々回提案したワークフローアプリケーションをWeb2.0の技術との組合せで実現しようということの意味をわかっていただけたでしょうか。

企業でいう顧客接点のところでは、Web2.0技術を使ったアプリケーションがすごく有効であり、単体のサービスとともにMashUpされたサービスがどんどん供給されてくる。ほんとうにびっくりするぐらい素早くMashUpサイトはできてしまう。

また、BPMとは多少ずれるが、それ以外の領域でも大いにWeb2.0技術が活用できる。例えば内外の同業他社情報、業界動向を持ってきて事業計画作成の参考にするだとか、全社に散らばっている技術情報を集めて技術マップを作るだとかといった様々な情報処理作業を伴う知的生産活動があるが、こういうところでも有効だ。ネット上の情報のハンドリングは企業内のそれとは比べものにならないくらい大量で複雑であるので、そこでできている技術をうまく利用できれば生産性が大幅に向上する可能性を秘めている。

たとえば、「YahooPipes」をご存知でしょうか。最近、米Yahooが発表した、RSSフィードによって得られるデータを組み合わせ、操作することによって新しいフィードを生み出すことができるマッシュアップホスティングサービスなのですが、簡単に情報の収集・加工ができてしまう。これなどは、情報ハンドリングの強力なツールになるでしょう。

今後、その他多くのWeb2.0技術が企業に浸透していくことだろう。

2007年3月22日

ユーザ目線のBPM(21)

だれがどこでやるのだ

今まで、Why、What、Howについてみてきましたが、最後に残りのWho、Where、Whenを考えておかないと紙の上の議論となってしまいます。最初の頃にも言いましたが、動いてなんぼ、役に立ってなんぼの世界であるので、具体的にどういう体制で、どういう組織で、どこに適用し、いつやるのだということを提示することも重要であると思う。

体制のことで言えば、業務プロセスのデザインをビジネスプロセスデザイナー、業務プロセスの実装をITアーキテクト(従来のSEの進化形)、プログラミングをスーパープログラマーというのが理想的である。このチームで「セル生産方式」のように一気に作り上げることが望ましい。たとえが悪いが、「必殺仕事人」「黄金の7人」みたいなものだ。ここで作られたコアシステムをベースにカスタマイズしたり、運用したりするのは、一般のひとがやっていくという役割分担になる。

ここで、軽量プログラミング言語を操る技術者をどう巻き込んでいくがポイントだ。たとえば、IPAの未踏ソフトウエアの卒業生を引き込むとか工夫する必要がある。

また、このビジネスプロセスデザイナーという役割をどうするか。前に、企業IS部門や情報子会社について、彼らはどちらかというとベンダー寄りであると書いた。ここでは、期待を込めて、この役回りを企業IS部門あるいは情報子会社が負うことを提案する。

従って、従来に比べ、さらに業務側にシフトしたスタンスとする。これは前にも言ったように、別にユーザと同じレベルで業務を知る必要はなくて、BPMという道具を使い、手持ちのコンポーネントを見せて、必要とする業務プロセスを引き出す能力をもつことでかまわないのだ。

情報子会社が本質的に抱える課題である自立化を実現するヒントになると考える。これは本題ではないのでこれ以上は言及しない。

ただし、こうした開発部隊をどう組織化するかは難しい課題である。次に述べる地方の中小企業に導入する場合など、必ずしも情報子会社でやれるとは限らないケースもあると思われる。全国規模のITベンダーの力を借りることも必要になるかもしれない。

さて、実際にここで論じた方法論や仕組みをどこにどうやって適用するのがいいのだろうか。その答えとして、中小企業への適用を行い、地域ごとのビジネスサポートセンター設置を構想する。なぜそう考えるに至った理由について、昨年「日経ソリューションビジネス」に掲載された記事が参考になるで引用する。この記事は「中堅・中小企業の市場に対する「これまでの常識」と7つの「新常識」」と題したものでベンダーに向けて発信されているが、状況を的確に捉えているのであえてそのまま載せる。

これまでの常識

①中堅・中小企業もまずは経営戦略を立案した上でシステム化すべき

②日本版SOX法は、上場企業などに適用され、中堅・中小企業には関係ない

③中堅・中小企業でも基幹業務システムを提案することが最も重要

④中堅・中小企業はシステムを導入しても単価が安く、あまり儲からない

⑤中堅・中小企業は、料金設定を安くしなくてはシステムを導入してくれない

⑥最新システムを入れる中堅・中小企業は、IT化にも理解があり進めやすい

⑦社内にIT部門をもたない中堅・中小企業が多いため、導入作業が面倒

これからの常識

①まずは効果を出しやすい部分からシステム化して、ITの重要性を示す

②たとえ適用されなくても、上場企業と取引するとき今後、内部統制が必須に

③業務コスト削減の基幹業務システムより、売上に直結するWebシステムの提案を

④システムより、付随する業務サービスに価値を認め対価を支払ってくれる

⑤短期間にシステムを開発してくれるなら、高い料金設定でも納得してくれる

⑥むしろ遅れている中堅・中小企業の方がスムーズにシステム化が進む

⑦中堅・中小企業の社員は、費用が安くなるなら積極的に導入作業を助けてくれる

これを見たらおわかりのように、「ユーザ目線のBPM」は、中堅・中小企業をターゲットにするのが適していると思いませんか。

また、社内にIT部門をもたない中堅・中小企業が多く、運用を自社で行なうのが困難であり、コア業務に集中するために運用は外部にまかせたいと考えている。従って、センター化してASPサービスとして機能させることが望ましい。

筆者は、全国の信用金庫単位でこのセンター(ビジネスサポートセンターと呼ぶ)を構築したらどうかと提案している。それぞれの信用金庫には多くの中堅・中小企業がぶらさがっています。その企業群が共同で利用できるビジネスシステムを提供することをめざします。全国に292の信用金庫がありますが、どこかひとつを選んでそこで実装し、モデル化して全国水平展開するというイメージでいかがでしょうか。

いつやるかは、全体スキームの確立状況をみて決めていくことになります。

日本の強さは中堅・中小企業の力によるところが大きいと考えられます。さらにそこを強化して行こうではありませんか。


落語のあとの落語のような話

昨日、恒例の「第30回 柳家小里んの会」があった。昼間にお墓参りをして、そのあとで池袋演芸場まででかける。お彼岸の1日としてはなかなかいいでしょ。

今回の演題は、「花見の仇討ち」と「明烏」。いずれも定番の演目で、「明烏」は8代目桂文楽の十八番。桂文楽の話を聴いたかどうか忘れてしまいましたが、柳家小里んも文楽とまではいかないまでも、品よくまとめていたように思える。ただ、時間が短かったせいか、若旦那と花魁の絡みがあまり描かれなかったのがちょっと物足らなかった。でも、相変わらずぼくらを楽しませてくれる話芸は健在だ。

昨日は休日だったので、ほぼ満席に近かった。やっぱり、お客さんも多いと熱気みたいなものが感じられていい雰囲気になる。

平日だと仕事の関係で来れない人がいるわけで、再三登場のぼくの行きつけのバー「M」のマスター夫妻、Kちゃん、お客さんのIさんなど顔見知りの人が何人か今回は休日なので参加です。「M」のママから缶ビールの差し入れがあり、それを呑みながらいい気持ちになったのであります。

それが終わってから、やはり一緒に聴きに来ていたWさんと彼の彼女のS子さんと3人で近くの居酒屋で呑む。時間がなかったのであわただしかったのですが、楽しいおしゃべりの中で、いつも指摘されるぼくの弱みをまた言われた。「wadaさん絶対脇が甘いよね」。そう言われても直らねえんだよ、あたしゃ。(急に落語調になる)

で、遅くなったので急いで池袋駅に行って電車を探したがうまく時間が合わず。まあ、大船に着いたらタクシーだなとあきらめて、直通の湘南新宿ラインに乗る。ところが、大船駅に近づくと待てよ、ひょっとしたらモノレール終電に間に合うかもしれないということで走ったのです。これがいけなかった。なんと、改札口寸前でコケた。どうなったかというと、手をひろげ左脇腹から落ちてひねったのだ。無茶痛い、でもみんな見ているから何もなかった振りをしてモノレールに乗り込み帰ってきたが、今もちょっと動くと痛い。

おお「あたしゃ確かに脇が甘い」!

今回も、ちょっと先ですが「柳家麟太郎の会」の案内をもらいましたのでお知らせしておきます。
日時  :平成19年5月17日(木)午後6時半開場、7時演
場所  :御園神社  大田区西蒲田7-40-8
入場料:前売 1,000円(当日 1,300円)
問合せ:西蒲田七丁目御園町会   090-3064-7272 桑田
     御園神社  03-3735-5096 鈴木

2007年3月23日

ユーザ目線のBPM(22)

最後に

ここまでの議論を整理してまとめると次のようになる。

・役に立たない正しいシステムを作るのはもうやめよう
・役に立つものができるなら、従来の作り方を変えようじゃないか
・それにはBPMを使ってコンポーネントを組み立てる作り方が有効なようだ
・BPMは開発と監視の道具であるとし、使い勝手を重視しよう
・BPMはSOAの基盤の上に構築するのが構造的によさそうだ
・コンポーネントは、Web2.0的技術あるいはサービスでさくさく作ってしまいたい
・早く安く作る事が重要でしかも変更や手戻りは当たり前と考えよう
・コア開発は、ビジネスプロセスデザイナーとITアーキテクトとスーパープログラマーのチームで迅速に、カスタマイズ適用と運用は“一般”チームで確実に
・小さく生んで大きく育てる思想で、非基幹系、中小企業向けから始めよう

この議論の表題を「ユーザ目線のBPM」としたが、これは筆者がエンドユーザであった時代、そしてIS部門、情報子会社でシステム構築を行なってきたときの経験から、どうもこれまでのシステム作りがメーカ、ベンダー、SIerの目線で行なわれてきたように感じられたので、あえてそのようなタイトルにした。
目線ということで言えば、最近「下流志向」という本を書いた内田樹氏がこんなことを言っている。

「目線」というのは「そこから何が見えるか」ではなく、むしろ「そこからは何が見えないか」によって特徴づけられる。例えば、本邦のテレビのニュース番組のほとんどは「おばさん目線」である。だから、私たちがワイドショーやニュースから知れることができるのは「日本のおばさんは何を知っているか」ではなく主に「日本のおばさんは何を知らないか」である。これはそれなりに有益な情報である。

この傳でいけば、「ユーザ目線」というのは、「システムについてユーザからは何が見えないか」、「日本のエンドユーザの人たちは何を知らないか」ということになる。この議論で“それなりに有益な情報”を提供できたのであろうか。おわり。

東京呑み歩き隊

おととい痛めた脇腹をかばいながら、昨日続けて東京へ出掛ける。浜松町にあるN社でミーティング。そこの事業部長のUさんとは以前待ち合わせの約束をしておきながら、前の晩に家の階段でしこたま腰をうちつけ、急遽面談キャンセルしたことがあったので、「年とってからころぶとたいへんですから」またまたひやかされてしまった。昨日は、無理をおしても行きたかったが、そのかいがあって面白い話になりそうなので痛みも少し飛んでいったような気がする。

そのあと、浅草橋の「あさだ」に行く。しばらく途絶えていた「ソバ屋で憩う会」です。 初めは、上野の蓮玉庵にしようとしてたら、何と閉店が19時半だと言われて、え、それじゃ30分も居られないやとなって急遽「あさだ」に変更です。そばやは終わるのが早いから気をつけないと。

今回は、いつものKさんとともに居酒屋めぐりをしていた元部下のI君、N君も合流して4人で酒とそばを楽しむ。「あさだ」は創業が1854年とかなりの老舗。いまの店主は8代目だそうだ。ここの名物は鴨鍋のようだが、それは頼まず、たらのめ、ふきのとう、稚あゆのてんぷら、かもの燻製などを賞味、酒は岐阜の篝火の燗にする。

Kさんの趣味は「鉄道模型」で半端じゃなく凝っています。何十万円もする機関車を買っては、それを同好の士が集まるところで見せびらかすのだそうだ。N君が「ぼくも子どもの時は鉄道少年だってんです」と言ったものだから、しばらく、OゲージだとかHOゲージだとかの話で盛り上がっていましたが、ぼくにはよくわかりません。

最後は、せいろを食べて店を出る。そばは適度に歯ごたえがあっておいしいですよ。また転ぶといけないので若干抑え気味で家に帰る。 で、これからも4人でやりましょうということになり、「東京呑み歩き隊」を結成したのであります。

2007年3月24日

字幕屋さんのウップンばらし

「字幕屋は銀幕の片隅で日本語が変だと叫ぶ」という長たらしいタイトルの本を読む。著者は、太田直子といって、映画字幕翻訳を始めて約20年、手がけた作品1000本あまりのいわゆる「字幕屋さん」。

これがなかなか面白い。普段字数を制限されることばかりであるのが、本ならいくらでも書けるので、はじけている感じです。

何といっても一番おもしろかったのは、セリフの長さと字幕の字数が決まっているということ。1秒のセリフなら翻訳文は4文字以内、2秒なら8文字、つまり「1秒=4文字」なのだそうだ。要するに人間の字を読むスピードに限りがあるので長たらしい文章は読み切れないのだ。だから、セリフをそのまま翻訳したら「1秒=4文字」ルールに収まらないことが多く、短くまとめなくてはならない。

従って、こうした「要約翻訳」がゆえの悩みがいっぱいでてくるわけなのです。なかには、吹き替え版と字幕版を比較して違うとクレームをつける人も出てくる。例えば、吹き替え版では、「なぜもっと前にそれを言わなかったんだ?」が、字幕版になると「なぜ黙ってた?」となるわけです。

そのほかにも、「私」「ぼく」「おれ」のどれをわりあてるかとか、教養、常識がなくなってきて、当然常識として知っているだろうことがわからないので固有名詞ではなく一般的な言い方になるとか、「知識の基準」をどこにおくかが難しいそうだ。

それとか、配給会社の注文で意味を変えてしまうこともあるということで、感動と涙を誘うために反対の言葉を叫ばすとかがあるとのこと、そうなると映画も捏造なのかと驚く。

まあ、字幕屋だと清水俊二か戸田奈津子くらいしか名前が浮かんでこないけど、こういう人もいたのだと再認識。字幕屋のその内幕が半分愚痴って半分楽しんで書いてあって、いちいち納得しながら一気に読んでしまった。

これから、映画を見るときは少し字幕のことを気をつけて見てみようと思っています。

2007年3月25日

さすが欧州レギュラー組

キリンチャレンジカップの日本対ペルー戦で、日本が2-0で快勝した。2点とも中村俊輔からのフリーキックからの得点。よくいう“流れの中から”の得点ではなかった。まあ、中村俊輔と高原の個人技なんだけど、それ以外でも短い練習期間にもかかわらずまずまずの連携だったんじゃないかな。

でも、やっぱシュートが少ない。ボールをつなぐのはいいのだけどフィニッシュまでいかないのだ。このくせは日本チームにずっとあって、ボールを回すのに目的意識がいっていて、何がなんでも点をとることに意識が向いていないように思う。ボールを受けて、次に渡す相手をさがし、空いている選手がいたらそこへパスするということになる。だから、みんながゴールに向かって攻めあがるという感じがない。フリーキックの場合は、それこそみんながそういう意識になるわけで、それで2点もとれたのだから、流れている局面でも意識としてフリーキックのような態勢になればいいのにと思うがそうはいかないのだろう。

昨日は、交替で出てきた選手がいい動きをしていた。だからといって先発で使えばと思うでしょうが、そうはいかないのであって、相手が疲れたときだからできただけかもしれない。でもそのなかでも中村憲剛がすばらしい。動きに切れがあるし、ポジティブなパスが出せるいい選手だ。それは、ぼくの独断的な意見かも知れないが、シュート力のあるパサーであることがそうさせているような気がする。

それにしても、今回はやはり欧州で現にレギュラーを張っている2選手の実力を見せつけられた試合でもあった。ガンバレニッポン!

2007年3月26日

脳科学に行きつくのか(その1 錯視)

最近、脳科学がはやりなのか、茂木さんの本を筆頭に多く出版されているし、マスコミにも取り上げられている。だからというわけではないだろおうが、様々な分野の人たちがなんか最後は脳でしょみたいに論じている。で、それらを紹介しようと思うが、全く違った分野のお話です。まずは、「錯視」のことから、「心理経済学」、「プログラミング」に至るのですが、面白いですよね、このバラエティさは。

こんな話が書けるのは、まさにインターネットのおかげです。これまでだったら、大学の先生の研究がどんなことをやっているのかなんて調べようがなかったのに、今はインターネットでだいたいの研究内容や成果がわかるようになっています。それと、インターネット本来的に持つの最大の利点であるハイパーリンクにより、関連情報が“いもずる”式に得られる。そういう意味では、ものすごく情報取得コストが安くなった。

さて、最初の「錯視」のことだが、簡単にいうと目の錯覚のこと、これは見間違いとは異なる正常な視知覚の現れだそうです。これは心理学の研究領域の一つなんですね。知覚心理学って言うらしい。よくわかんないけど、例えば「渦巻き錯視」の場合、“人間の脳の高次視覚野には渦巻きパターンに特異的に応答するニューロンがあって、渦巻き錯視はこの渦巻きニューロンが同心円を渦巻きと間違えて応答することによって起こる”という仮説がある。

まあ、ここでいくら説明しても分からないので、一番いいのは実際にみてもらうことなので、今の仮説を立てたひとで、この研究の第一人者である立命館大学の北岡明佳教授のホームページを見てください。絶対びっくりしますよ。

2007年3月27日

スケーターイヤー

さあ問題です。つぎの言葉はいったい誰が言った言葉でしょう?

「はい、なんかだんだん年をとっていくごとに涙もろくなっちゃって・・・。昔は人前で泣くのは我慢していたんですけど、最近は止まらなくて」

答えは、「世界フィギュア2007東京」2位になった浅田真央の言葉です。ええ、弱冠16歳の子がいうセリフかなあ。

そういえば、優勝した安藤美姫も以前、「私年だから真央ちゃんみたいな若い子と同じようにはできないの」みたいなことを言っていたと思うが、その美姫ちゃんだって19歳ですよ。なんかこれみんな、ぼくたちおじさん、おばさんの言う言葉でしょ。

確かに最近の子どもたちはやたら年食ったみたいなことを言う。ぼくの下の息子もハタチになったとき、「ああオレも年だなあ」と嘆いていた。

彼らが、ぼくらの歳になったらなんと言うのだろ。

それにしても二人はよくやった。美姫ちゃん、真央ちゃんおめでとう。おっと、おばさん(失礼!でも彼女らの感覚だとこうでしょ)の 中野友加里の5位もすばらしい。

2007年3月29日

粘り強い「アルファギーク」

皆さん、アルファギークって知っていますか。Tim O'Reillyの定義だと「産業を変化させる力を持つ新しい技術に早いうちに飛びつき、ああでもないこうでもないといじくっているうちに、技術が進むべき方向性を示し始める、先鋭的で飽きっぽいエンジニア」となる。

昨日そのアルファギークのひとりだと思われるS氏に会う。実際に会ったときに、あなたのようなアルファギークのひとと一緒になって仕事をしたいんだと言ったら苦笑いをしていました。いまぼくが進めている「ビジネスコンポーネント指向開発」でコンポーネントをオープンソースCMSであるPloneを使おうとしていて、そのPloneの使い手の第一人者です。彼の事務所のある桜新町のカフェで、こちらのプランを説明し、協力を要請しました。S氏の思いも聞いてみましたが、うまくコラボレーションできる感触を得たのですごく喜んでいます。

さて、アルファギークの定義で最後に「飽きっぽいエンジニア」といっていますが、S氏に限ってはそんなことはありません。PloneというのはZopeというフレームワークから成っていて、プログラム言語はPythonですが、S氏はそれらについて、ずいぶん前から日本での普及や実際の適用などを実践している、決して飽きっぽくはないアルファギークです。

彼の話のなかで面白かったのは、“Python Paradox””という話で、これを“Plone Paradox”と言ってもいいらしいのだが、JavaやPHPは技術者の数がすごく多いが、上から命令されたりして、受身でやらされている人が多いため、スキルレベルが低い。一方ploneの場合は、技術者人口は少ないが、自らその価値を認め、能動的にチャレンジしている人が多いためだれでも技術力があるといっていた。

企業はやはりこういう人たちの力をもっと引き出す努力をすべきだと実感したわけです。

打ち合わせの後、サザエさんに会いにサザエさん通りをぶらっとして、半蔵門線につながっているので、九段下の「一茶庵」をめざす。ところが着いてみると“本日6時から満席です”という張り紙。まいったということでさて次は、どうせ最後は銀座の「M」だから、銀座まで出ることにする。

半蔵門線を三越前で乗り換えて銀座線で行こうとしたら、何をぼけーっとしていたのか清澄白河まで行ってしまい、引き換えして三越前でおりたら、しまった乗り換えにいっぱい歩かなくてはいけなかったのだ。ひどい話で桜新町から2時間かかって銀座に到着。それでもそばにはこだわって、五丁目の「田中屋」に向かうが、ひとりで入ると席は空いているのにしばらくお待ちくださいと軽くあしらわれる。しかたなしに(というと怒られるかもしれないが)「泰明庵」に行く。

ここは相席でもあいていれば入れてくれるので奥の席に相席で座る。前の席にはぼくと同じくらいの年配のひとが本読みながら呑んでいる。とそのひとの呑んでいるものが気になった。栄養ドリンクのビンに入った液体をそば湯で割っているのだ。ついすいませんそれなんですかと聞いてみた。単に焼酎だったのだ。それから一気に会話が始まり、そばの話、ラーメンの話から白髪や教育の話やらで大いに盛り上がる。そうしたら、「M」のマスターがひょっこり現れる。軽く目で挨拶を交わし、相変わらずそのおじさんとしゃべり続けることに。

適当なところで退散して「M」に入る。マスターが“え、ひとりなの”と聞くからひとりですよと答えたが、どうも「泰明庵」で話をしていたのが連れだったと思っていたらしくびっくりしていた。「M」には久しぶりのIさんと会う。ぼくが昨年住んでいた白山のマンションのあとをねらっていたらしく、なぜ出るとき教えてくれなかったのかと言われ、もう一度空いてるか確認しておきますといって許してももらった。その後、もうひとりのIさんが登場して、ブログの話で盛り上がり、これまたせっかくコメント書いたのに返事がないと怒られた。てなことでこの日は結構濃い一日であった。

あ、サザエさんがいた!

P1000049.JPG

2007年3月30日

春爛漫

女子プロゴルファーじゃないが、わが家の桃と桜が一緒に咲いている。

まさに、春爛漫という感じ。一気に来ましたね。

P1000048.JPG
P1000051.JPG

2007年3月31日

脳科学に行きつくのか(その2 心理経済学)

「日本人はいじわるがお好き?」というタイトルで講演している先生がいる。大阪大学の教授で西條辰義という経済学者です。実験経済学というらしいのだが、実験により人間の経済行動を究明していく試みを実践している。この話は、昨年10月に日経新聞に連載されたのでご存知の方もいると思いますが、これが無茶おもしろいので紹介する。

有名な“囚人のジレンマ”というのをご存知だと思いますが、それに似たような実験を行なっている。まず10ドルを持っている2人の個人がお金を出し合って公共財(たとえば道路)をつくる場面を想定する。

そして、10ドル出すか出さないかの二つの選択肢があり、二人が出したお金の合計額に1.5を掛けた分の利益が、一人だけではなく双方に戻ってくるとする。ここで二人とも10ドル出せば、拠出金の総額は20ドルになり、これに1.5を掛けた30ドルがそれぞれに戻ってくる。

一方、自分は出さずに相手に出させた場合、拠出金は10ドルで、戻りはそれに1.5を掛けた15ドルがそれぞれに入る。従って、自分は手元の10ドルと戻りの15ドルで25ドルとなる。相手は15ドルである。逆の場合では、自分が15ドルで相手が25ドルとなる。もちろん二人とも出さないと利得は手元の10ドルのままである。

これからみると、自分の利得を増やすことだけ考えるなら、相手がどうであれ、自分は全額出すのがベストだと分かる。ところが、実験ではあまり出さないひとがいるのだそうだ。

上述の例のように相手が出して自分は出さないと、こちらの利得が相手より上回ることができる。このように、自己の利得を多少なりとも犠牲にして相手を痛めつける(出し抜く)行動を「意地悪(スパイト)行動」というらしい。

こうした実験を日米で行なうと、このスパイト行動をとる人が日本人に多いという結果が出たという。要するに日本人は意地悪が好きということになる。

さらに、それを証明するような実験をおこなう。公共財供給への参加の問題を明示的に扱う実験で、最初のステージで参加か不参加を選択する。参加を選択した被験者のみが次のステージで相手の参加・不参加の意思決定を知ったうえ、公共財供給のためのお金を出すというものである。

相手が参加するなら、自分は参加せず相手が供給する公共財にただ乗り(フリーライド)すればよい。もし相手が参加しなかったら、自分の利得が最大になるようなやり方で公共財にお金を出せばよいということになる。

この実験でも日米で差が出て、日本人は自分は参加するものの相手が参加しない場合、自分の利得を最大にするようにはお金を出さないそうだ。自己の利得を最大にするように公共財を供給すると、参加しなかった人がその便益を得てしまう。それが我慢できず、自己の利得が減ってでも過小にしかお金をださない。これは、まさに「意地悪」行動そのものである。

公共財をみんなで作ろうとすると、日本人はただ乗りをめざすが成功しない。というのは参加者が不参加者の足を引っ張るからだそうだ。日本社会は「強調型」といわれるが、内実は皆で仲良くことにあたっているのではなく「協力しないと後が怖い」ということかもしれない。

ね、面白い話でしょ。例えば、京都議定書のような問題だとか、それこそオープンソース開発みたいな局面でも米国人の考え方と日本人の考え方の違いがあるのかなと思ってします。

おっと、この話と脳科学とどう絡むのかだけど、実は、こうした経済的な意思決定が、ひとの脳のなかでどのように行なわれているか調べてみようという「ニューロエコノミスト(神経経済学者)」という研究者たちも現れているそうだ。

fMRIという機械で脳をスキャンするらしいが、意地悪されている脳は反応しないが、善意を受けている脳は反応するなんてことが分かるらしい。要するに、意地悪に鈍感になろうとする脳の働きが観察されるのだそうだ。うへー、そのうちおまえの脳は、けちだとか太っ腹だとか分かっちゃうのかなあ。ああ怖しや。


About 2007年3月

2007年3月にブログ「mark-wada blog」に投稿されたすべてのエントリーです。新しい順に並んでいます。

前のアーカイブは2007年2月です。

次のアーカイブは2007年4月です。

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

Powered by
Movable Type