mark-wada blog

デモといっても旗を持って行進するデモとは違います。きのう、ある研究会でいま進めている「ビジネスコンポーネント指向開発」の実際のデモを行なってきました。このブログの「ユーザ目線のBPM」でずっと書いてきたことです。やっと、実際に動くものができ、サンプルとして作ったアプリケーションをみてもらえるようになりました。

ところで、BPMとCMSのツールを使ってフローを作ったり、コンテンツやその構成はぼくでもできるのですが、BPMとCMSをつなぐのがもちろんできないので、社長にやってもらいました。実装に関してはここが肝のところで、BPMとCMS間のデータのやり取りを透過的にかつダイナミックにするにはどうしたらよいかという難問です。

社長に頼むのだから当然Web2.0の技術ということになります。当初は、Microformatsで記述して、RSSのDescriptionの中に入れる案で検討してたが、結局Ajaxを使うことになった。とこう書いてもぼくにはよくわからないが、社長は2日くらいでプログラミングしてしまった。社長曰く、プログラミングの時間はそんなにかからない（ちなみにコードは200行以下だった）、むしろ、プログラミングに入る前の採用する技術や言語、それと仕様を決めるのが、難しいし、時間がかかるのだそうだ。

で、このインターフェースとオープンCMSであるPloneの新規アイテムをつくってもらい、あとはぼくが開発した。ぼくは、自慢じゃないが本格的なプログラミングはしたことがないし、システム技術は詳しくない。そんなおじさんが開発できてしまうという画期的な技法です。すなわち、システム屋でないユーザ自身でも開発できるということである。ちょっと自慢。

やっと、武器が揃ったのでこれから攻勢に転じます。営業かけたり、セミナーで発表したり、雑誌で紹介してもらったりするつもりです。

こうした売り込みに際して必要なデモを昨日初めてやったわけです。難しかったのは、パワーポイントで説明しながら、実際のサンプルアプリケーションを動かせて見せるということで、しかも一台のプロジェクターとPCですから、いちいち切り替えなくてはいけないので、ちと混乱しました。次回は2台ずつでやれるよう準備しておきました。

ただ、この実際に動くものを見せるというデモの威力はたいしたものです。月並みに”百聞は一見にしかず”というところでしょうか。

今日までの3日間、読売新聞で「システムショック」というタイトルの記事が載っていた。首都圏の自動改札機トラブルなど大きなシステムトラブルが立て続けに起きているので、こうした特集を組んだのだろう。

その記事の中味は、ＩＴベンダー（この言葉を記者は初めて聞いたように書いていたのが印象的、認知度が低いんですね）の多重下請け構造や顧客との溝について書いている。論調としては、下請けの末端になるとコスト削減を迫られろくにテストもしないで収めるのでトラブルになるとか、ユーザ企業はベンダーの言いなりになっていて、企業の要求がシステムに反映されないといったように、どちらかというとＩＴベンダー側の問題点を指摘していた。

総合紙の記者だから、そんなにＩＴ業界に詳しくないと思うが、やはりＩＴ業界構造については問題ありと見えるのだろう。その記事によると、今年経産省の呼びかけでベンダーとユーザ企業の役員が産業構造審議会の小委員会で顔を揃えたそうだ。

とっくの昔にやっておかなくてはいけないことだろうが、役員同士で、しかも大手だろうから、ぼくはその会議の実効に期待はもっていない。だって、多重下請け構造の問題だって本当の末端の実態ってわかっているのかということや、いままでずっと大手ベンダーに丸投げしていたところが、急にユーザとベンダーの溝を埋めましょうと言ったところで表面をなでるだけの話のような気がする。

しかも、システムに対する思想や技術を今の延長のままで考えていたら何も変わらない。変革というのは、内側から、あるいは底からわーっとマグマが吹き出すように起こるのではないでしょうか。これまでの常識を打ち破るブレークスルーがなければいけない。ＩＴ業界（ユーザ企業も含めてかもしれない）は、一旦ゼロベースに落として再設計するぐらいのことをしないと「パラダイス鎖国」どころか、みんなが不幸せな国になってしまう。

今回の自動改札機のトラブルについて気になったことをもう少し。

システムに不具合が生じたのは日本信号社製のものだけだった。他の東芝やオムロンのものでは起こっていない。

現象としては、自動改札機は、始発前にＪＲ東日本などが作った合弁会社「ＩＣカード相互利用センター」から、盗難などで使用停止措置が取られたＩＣカード乗車券のデータが送られ、それを読み取ることで起動する仕組みになっているが、日本信号社製の改札機にプログラムミスがあり、一定量のデータが送られると異常が起きるようになっていたらしい。

おいおいちょっと待ってくれ、このプログラムというのは、３社とも同じになっているんじゃないの。そうか、他の２社で起きていないということは、別々に作ったのだ。ええー、同じプログラムを3社が別々に開発したということは、3倍の開発コストがかかっているじゃん。機械が違うからそうならざるを得ないってことなのだろうか。それとも、リスク分散？

だから、システム自体の複雑さも合わせて巨大なブラックボックスとなってしまっているような気がする。
全体があとで見てもその構造が分かるように疎結合されたモジュールの組み合わせになっていたのかどうかを知りたいものだ。そうしておいて、そのモジュールごとに分業するというのが正しいのではないでしょうか。同じものを3社に作らせるのは分業とは言わない。