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社に作らせるのは分業とは言わない。
　

以前アマゾンの倉庫の話を記事にしたことがある。そのとき、示唆的なことが多く含まれたモデルであるとコメントした。

あの記事では、3つの特徴を言った。技術オリエンテッドということ、整理しない整理のしかた、人間がITを使いこなす“しなやかさ”である。

どれもこれもこれからのITを考えたときに非常に大事な要素であると思う。さすが、アマゾンだとも思う。昔アマゾンは登場したとき、物流のところがネックでビジネスがうまくいかないのではないかと言われていた。しかし、今のアマゾンを見ているとすごいなあと感心する。ボトルネックをどんどん外しながら成長しているようだ。

最初の技術オリエンテッドあるいはデバイス志向のようなことについてだが、特にネットの世界ではこうしたシーズ発想の動きは普通であろう。いま話題のｉPhoneだって、これまでの携帯電話のようにキャリアを使うための端末という発想から、デバイスができてそれをどのキャリアに乗せようかという逆転が起きている。

翻って、ビジネスシステムへそうした新技術や新規機能デバイスなどがなかななか浸透していかない。RFIDなどは使われているかもしれないが、携帯端末なんもっと使われてもいいと思うが遅く感じられる。

整理しない整理ということでは、コード体系のことを想起する。ぼくは実際に開発作業もしたこともないので少し乱暴かもしれませんが、コードって要るのでしょうか。これまでみんな桁数の問題だとかですごく苦労しているがそうした呪縛から開放できないのだろうか。ばかなことを言うな、本にはISBNコードという立派なものがあるじゃないかと言われてもちょっと違うような気がして、ということでこれ以上は言わないが、考える余地もなのだろうか。

最後の“しなやかさ”ということでは、アマゾンもシステムに全部任すと柔軟性に欠けるといっているように人間とITの共存が大事なことである。自転車に乗るにしても、車を運転するにしても自分で乗りこなさないと怖くてしょうがないですよね。化学プラントでもOut of Controlになった時の怖さは尋常ではない、すぐに手動に切り替えて“なだめる”のである。ですから、人間がシステムを使いこなすという位置関係は絶対に崩してはいけないのである。
　

昨日は、「SCC日本支部メンバーズ・ミーティング」に参加。このメンバーではないが、バイスチェアマンの渡辺さんから紹介され、いつものITC協会の小林さん、井上さん、BPM協会の宇野澤さんと出席する。

講演では、カリフォルニア州立工科大学の一色浩一郎教授の「米国における「経営とITの同期」の実態」とUMLモデリング協議会副会長の堀内一東京国際大学教授の「モデルとモデリングにおける海外最新動向」を聞く。

一色先生は２０代で渡ってからもう米国生活が40年になるそうで、日本語より英語の方が堪能でときどきあやしい日本語が出てくる。しかし、中味はアカデミックではなく実践的な話を中心にすごくわかりやすい。日本の大学の先生の場合だと、小難しい言葉で翻弄されてしまうが、一色先生は平易な言葉で丁寧に説明してくれて、しかし中味は濃いというものであった。こういうところも日米差がある。

実は、一昨日小林さんを除く上記のメンバーと渡辺さんと一色先生とで夜会食しながらお話をする機会をもらった。そのときの話も交えて日米の「経営とIT」の比較についてふれてみる。

経営とITに関しての体系を見せてもらいながら話をしたのだが、その中で経営に近いところでCIOは単にITだけではなく、経営にタッチしていなくてはいけないということで米国のCIOの肩書きで多いのが、SeniorVP&CIOとかExcectiveVP&CIOなのだそうだ。

そして面白いことを言っていて、米国のCIOは24・７といって24時間7日はいつも経営とITの同期ということを考えているが、日本では週に10時間だそうだ。そして、失敗すれば首になるし、成功すれば膨大な報酬がある。ここでも大きな違いがある。

また日本ではCIOというとぽつんと一人いるようなイメージですが、彼らは必ず「PMO」（Project Management Office）といって何人かのProgramManagerとProjectManagerをスタッフとして抱える。このPMOに入るやつは、要求工学をきちんと勉強した人たちである。先生の教え子はこういうところで働いている。

ちなみに、先生の行っている大学は90％以上の学生は企業で働いているのだそうだ。日本の学生はアルバイトこそすれただ学校へ通っているだけだ。しかも、教授もただ教えるだけでなく、彼らも企業のコンサルをしたりしている。そうでなければ教授になれないらしい。そしてつまらないカリキュラムだったり、授業が面白くなかったらやめさせられる。ここでも日米の差がでてくる。

さて、PMOの人たちが戦略を練って、SOW(Statement of works)として目標を作り、RFPに落としていく。ここまでは当然ユーザがつくるのである。そのあと要求仕様書に落としていくが、それまでのところが非常に重要で、これが日本はぜんぜんできていないところである。へたすると、ベンダーにSOWやRFPを書いてもらうところさえある。

ここはインドもまだまだなので、今のうちにこの領域をやれる人材を育てておかないとみんなもっていかれると強く警告していた。

それともう一つはEnterprise2.0のところで、これはどんどん新しい技術やサービスがでてきていてそれが企業にも入ってきている。もうEmail は使わなくなってきて、Podcastに変わっているらしい。ここでも米国の若者の活躍はすごいと言っていた。何よりもかれらには“Passion”があると言われたのが印象的であった。

聞けば聞くほど日米格差を感じてしまうが、あきらめるのは早い、単純な開発のところから上流の要求工学のところやEnterprise2.0へのシフトを早めれば何とかなると思う。そのためにもいま自虐的になっているIT業界を３Kから３Tに変えなくてはいけないと言って、一色先生は「日本IT維新会」というのを立ち上げました。

先生曰く、３Tとは、「楽しいIT、高い報酬、定時に帰宅」なのだそうです。米国の真ん中から日本を見ると歯がゆいのでしょう。でもそういう人がいてくれてすごくうれしいと思いませんか。ぼくもこの動きに連動して何か貢献できたらと思っています。
　

以前、書評で「会社の品格」のことを書いた。そして、その中に書いてある「仕事の品格」にも触れた。仕事とITは密接だから、その仕事をITに置き換えて考えてみた。

そこでも紹介した6つのポイントを内容も含めて仕事という単語をITに変えて提示する。

（１）「納得感」のあるIT
・ 自分が顧客であるなら、喜んで自社の商品を買える
・ 自分のITを親しい知人に勧められる
（２）「使命感」のあるIT
・ ITによる「自己実現」「社会との接点を持つ」ことができる
・ 自分のITに、「命」を「使う」ほどの価値を、一人ひとりが求め、実感している
（３）「効力感」のあるIT
・ 自分の個性や創造性が発揮できるITであること
・ 個人に選択の余地があるIT
（４）「普遍性」のあるIT
・ その組織の中でしか通用しない特殊スキルではなく、社外でも通用する「普遍スキル」を身につけらえる
・ ITで、スペシャリティやプロフェッショナリティの向上を感じられる
（５）「貢献感」のあるIT
・ 自分のITが、どんなふうに会社の役に立ち、それが社会につながっているかがわかる
・ 誰かに貢献している実感、相手からありがとう！と言われる喜びがある
（６）「季節感」のあるIT
・ 心機一転、心が改まる機会がある
・ 「おかしいことを正そう」「挑戦しよう」などの積極的な変革姿勢が生じる

ということになる。何となく収まっているように思えます。ここでの“自分”はITを作る人と、ITを使う人が混ざっているが、かなり言いえていますよね。

これまでのITは上述のようなことまで考えてはいなかったような気がします。ということは、仕事のことをあまり意識しない作り方、提供の仕方だったようです。

作って渡して、それがどんな使われ方をされようが、かかった費用を請求するという「品のない」ビジネスだったのではないでしょうか。

そうです、これから品格のあるITを考えていこうではありませんか。品格があるITに携わる職場なら３Kにはなりませんよね。

同じような言葉や言い回しなのだが、実は中味は違うということがある。情報システムに関することでそうした誤解、曲解があったりする。

このブログでも何回も指摘しているので繰り返しになるが、ただ今まで書いたことを整理しておくということもブログを書く上で大事なことでもあると思うので、あえて同じようなことを書く。

よく混乱するワーディングには、ビジネスモデルとビジネスプロセス、要求定義と要件定義、ソフトウエア開発とシステム開発といったところがある。2番目の要求定義と要件定義についてはちょっと前のエントリーで書いてあるので、前後についてみていく。

ビジネスモデルというのは、事業の形態、収益のあげ方、競争のし方などで、戦略的な意味合いが強く、競争優位を保つためのモデルといえる。

それに対して、ビジネスプロセスというのは、戦略を実行するための業務遂行プロセスで、かなりオペレーショナルなもので、どちらかというとリソースの稼動効率を最大化してコストを最小化することに重点を置いている。ビジネスモデルはCEOの責任であり、ビジネスプロセスはCOOのミッションということでもある。

3つ目のソフトウエア開発とシステム開発である。ここでちょっと話がそれるが、開発という言葉を両者が使っているが、実態はどうも違うように思える。開発をしているのかどうかということである。ソフトウエア開発は、プロダクト開発といってもいいが、むしろソフトウエア製造とかプロダクト生産のような言い方が近いのではないだろうか。

また、システム開発はシステム構築のほうが似つかわしいと思う。業務システムはシステム屋が開発するのではなく、ビジネスをやっている人が開発するものである。

ソフトウエアを作ることとシステムを作ることはだいぶ様相がちがっていて、理解しやすいように例え話でいうと、自動車産業と運送業とかタクシー業の違いである。ソフトウエア（プロダクト）を作るのは自動車を生産するのに似ている。しかし、業務システムを作るということは運送屋が自動車を使ってビジネスやオペレーションをどうするかの仕組みを作ることと同じである。

このことは、よくIT業界を自動車産業になぞらえていう人もいるが、決定的な違いはここで、企業の情報システムを作るのは自動車を作ることではなく、自動車を使ったビジネススタイルを作ることなのである。だから、難しいのだ。

誤解を恐れず言うと、自動車生産のモデルは簡単だ。適当に予想してそれにあったようにモノを作り、売ればいいのだ。それがどんなところで、どのように使われようがどうでもいい。ベンツで田んぼのあぜ道を走ってスーパーにいってもいいし、トラックに人を積んでどうでもいいのだ。基本的にProductOutだからユーザの恣意に踊らされない。

それに比べると、システム開発は、様々なユーザ要求に対するソリューションとしてあるので、モデル化も難しいし、単純な方式化も大変なのである。だから、自動車産業のほうが上でITは劣位だなんてことはなく、システム構築でやっていることはかなり高度なことをやっているのだ。いや、まだできていないから、これからやらなければいけないと考えたほうがよい。

オレたちのやっていることはかなり高度な産業であるという誇りをもったらいい。それを矜持という。ITに関わる人間としての矜持こそ大切なのではないだろうか。

話はそれたが結局まとめると、それぞれの言葉は似ているようでちがうが、しかし関連性があってつながっているのである、それを表現すると、

「経営戦略から導き出された“ビジネスモデル”から“要求定義”を行い、モデルを実行するための“ビジネスプロセス”に落とし込み、そこからの“要件定義”に従って“ソフトウエア開発”されたプロダクトを活用して、“システム開発”を行う。」

ということになる。
　

いま、この間のスタロジのセミナーでの羽生さんの話に刺激されて、業務システムの変遷を考えている。そこで見えてきたのは、ぼくらの生きてきた時代がもろ変化のときであったなあと思ったのである。

ITの登場による変化はここ30年で起こってきて、この10年がすごい勢いで動いている。最初のころのITは企業や研究機関での電子計算機としてあったので子供では触れることがなかった。しかし、誰でも使えるようになるにはそう長い時間はいらなかった。

そう考えると、その30年をずっと見てきたのは、どの年代のひとたちなのだろうかと考えてみる。そうです、50歳から60歳くらいの人なんですね。われわれ団塊の世代なんぞは、日々変化するITを肌で感じた世代なのである。

この経験は、いったいどういうことなのだろうか。変化を実感するということは、変化をしていない時代を知っているから、それとの比較でああ今は大きく変っているのだなあとわかるような気がする。最初から変化の只中にいるいまの若い子たちはこの実感がないと思う。

これは、何もITだけではなく、多くものに大きな変化をもたらしている。例えば、1989年にベルリンの壁が崩壊して、東西冷戦の構図、社会主義体制の終焉を迎えたが、それからたった20年しかたっていないのに、米国の金融危機からはじまった消費型資本主義も終わろうとしている。この激動もぼくらの世代は目の当たりにしてきた。

それは単に変化を体感したということではなく、自分たちの価値観が大きく揺らぐ経験をすることの方がインパクトがあった。そりゃあ、敗戦による変化の方がはるかに大きいかもしれないが、それは一回きりのものであるが、ぼくらはいつも変化の風にさらされているような気がする。そのたびに立ち位置を確かめざるを得なかった。

さて、ITのことである。ハードウエア、ソフトウエア、プラットフォーム、インフラ、開発メソッドなどなどあらゆる領域で目を見張る“Change”があった。

例えば、ハードウエアだけをとってみても、よく語られるように、部屋いっぱいに鎮座していた汎用機が、今では一台のパソコンで事足りるのである。

ところが、羽生さんが鋭く指摘したように「業務システム」が変わっていない。少なくともここ10年は、画期的なツールやデバイスが現れているにもかかわらず旧態依然のままなのである。それは、何度も言っているように役所やレガシー企業内では、既得権益を守ることが第一であり、“変革は悪”だからである。

だからそこを動かしてみたいし、ぜひとも、ぼくらの目の黒いうちに、この業務システムの変革を見てみたいのである。

数日前の「本質を見抜く」というエントリーで雇用の流動化について書いたが、もう少し補足して説明する。そこでは、多様な雇用の流動化がワーキングプアや失業を減らし、働きやすい職場を作ることにつながるとうことを示唆した。

そして、そもそも何が問題なのかについて、好きなことができる環境をなかなかみつけにくいし、移動しにくいことを指摘した。

それとともに、関連することとして「新卒の過度の優遇」をここでは考えてみたい。

日本の企業、特に大企業と言われる会社では、定期的な新卒採用が基本になっている。そのため、この新卒の人たちをベースに会社の組織とキャリアパスが設計されているので、その新卒がどのように出世していくのか、出世させるのかで動いている。

ぼくには、この新卒の過度の優遇がかなり日本の企業の硬直性を生み出しているように思えてならない。ただ、IT業界のようなところや外資系の会社はこういうことが少ないのだが、一般の企業ではこれが大きいのだ。

ところで、今IT企業はそうではないと書いたが、実は間接的に影響を被っているように思える。それは、IT企業とユーザ企業との人的交流が少ないということである。ぼくは、この人の流れはどんどんやった方がいいと思うのであえて言っているのである。

IT企業の方は確かに転職もでき、ある程度流動性は確保されているが、ITを使ってもらうお客さんの企業はどうかというと、大部分のユーザ企業は、指摘したように厳然と新卒重視型組織になっているから硬直化して動きが悪いのだ。だから、ユーザ企業からIT業界へ流れていかない。

ユーザ企業の人たちにとっては、せっかく新卒で入ってぬくぬくとやっているのに、リスクをとってIT業界へ飛び込むことはしない。よほどメリットがある場合か、技術をもった元気のあるやつしかやらないということになる。

ある意味、こうしたことがITとビジネスとの乖離がなかなか埋まらない遠因でもあるような気がする。そのぬくぬく組が何もしないだけならまだいいかもしれないが、バリアになってしまっていることもあるのだ。だから、依然として、開発のときのユーザ側とシステム側の円滑なコミュニケーションが難しいのである。

もちろん、ユーザだけの問題ではなく、受け皿のIT業界が３K職場と揶揄されるようじゃ困るのだが、それはそれとしてユーザ企業でもITを経営に生かすためにも、まずはユーザ企業からのIT人材の供出はやったほうがいいと思う。だって新卒重視企業に人材を送るという逆の流れは激しく難しいからである。

こうしたことが、ぜんぜん進まないのはもちろんインセンティブが働かないのであるが、インセンティブが働くように、どこへいっても自分の力に見合った評価が得られるような構造にしないと、日本全体の人的活力が死んだままになる。これは、新卒でも本当はもっとよそで違ったことをやりたいと後で気付いてもじっと我慢するほうを選択するという場合もあるわけで、そうしたら双方が不幸になる。

だれもが、こんな時代は動かない方がいいと思いがちであるが、そうではなくてむしろ多様な流動化によって、“塩漬け新卒”を活性化させることも必要ではないかと思うのである。
　

こういう題名のテレビ番組があったし、本も出版されているようだが、見ていないのでその内容はわからないが、いまこの「クラウドの衝撃」を考えている。クラウドとは何かなんて定義は重要ではなくて、Amazon、Google、Saleforce.com（そのうちMicroSoftも参戦してきます）がやっていることを見ればいいだけで、それを「クラウド」と言うのだ。

ただし、それぞれがやっているクラウドは一括りにはできなくて三者三様である。AmazonのEC2やA3といったサービスはしケーラビリティとユーティリティ化されたインフラ提供であるし、GoogleはGoogleAppsのようなアプリケーション提供のプラットフォームであり、SalesForceはCRMという業務に特化したアプリケーションサービスであるわけで、競合していないことに驚かされる。

こういうことは言いたくはないが、日本はどうかというと愕然とする。何よりも日本のベンダは横並びであって、差別化も何もあったものではない。どこも同じことをし、よその真似をする。この“どこも同じこと”というのは、守旧的なビジネスでしかないのは必然で、革新的なことはどこにもない。

だから、日本のIT投資の実態調査でも攻めの投資よりも守りの投資が大幅に上回っているのである。ひとと違うことをすることのリスクを恐がって、まわりと同じように保守・運用だけやっていれば何とかなると思っている。もはやそんな時代は終わりを告げていることをクラウドは如実に表わしている。

この時勢でIT投資もままならないことはあるが、それでも世界はすごい勢いで変化している。その象徴がクラウドである。

ではこのインパクトを考えてみよう。前述したように、インフラからアプリケーションサービスまで、“あちら側”で大規模な供給システムが出来上がってきたのである。それも圧倒的な低コストで享受できるようになってきた。セキュリティがどうの、安定性がどうの（EC2は99.95％の稼働率を保証してしまった）と言っている間にそんなものはすぐにクリアしていく。

そうなると、わが国のITエンジニアはどうなってしまうのだろうか。保守・運用の人材が相対的に多いわけだから、かれらの多くが仕事がなくなっていくことを意味しないのだろうか。「クラウドの衝撃」の恐ろしさはここだ。

サッカーでもラグビーでもバックスをやっていたやつがいきなりフォワードやれって言われても，そう簡単に変われるものでもない。だから、急に運用をやっていた人間が明日から開発だと言われてもハイ分かりましたとはいかない。

そして、今の経済環境では、この1億2000万人の島の中だけで細々と食っていくしかないのだろうか。そういう意味では、全体のパイも縮小するわけで、なおかつビジネスドメインも変えていかなくてはいけないとなると大変なことである。さてどうするのだ。

だからといって、AmazonやGoogleと同じようなことは絶対できないし、なおかつ彼らを無視するわけにはいかないのだから、彼らの上で踊るしかないだろう。うまく踊るにはどうしたらいいのかそれを考えて行くことが進むべき道であろう。

BPMという観点で語っているが、やめようかと思う。なぜかと云うと、それだと何かはやりもののことをしゃべっているようで、本質から外れるからである。

だから、業務システムをどうやって作っていくかということから考えいこうと思う。多分実はそこが大事で皆そう思っているが、新しい技術やサービスは出てくると、どうしてもそこに引っ張られて、それがビジネス的にどうなのかという風に考えない。新しい物がいいものだと錯覚する。IT一つでビジネスなんてそう簡単に変わるわけがない。

業務システムって本質的には何も変わっていない。しかし、業務システムが“本質的にどういうものなのか”ということを議論していないことや、そこのフィロソフィーがない中でＩＴの適用を議論するから、変なところに行ってしまう。

あくまでビジネスありき、ユーザありきです。だって、ビジネスやユーザに貢献できないシステムを作って何になるのですかということです。こういうことを言うとすぐにビジネスの経験がないからとか、ビジネスをやっている人がちゃんと仕様をかいてくれなければできないよという声が聞こえてきそうだが、そうだろうか。そんなことを考えてクリエイティブなことができた人がいただろうか。

ということで、これまで書いてきたことが中心となるが、もう一度本質的な立ち位置に戻って、ITというものが、実際のビジネスあるいは個人の仕事にどう貢献できるかどうかを考えていこうと思う。実は、ブログで書くということは、書いたら終わりではなくて、しつこく同じことを書くことも大事なような気がするのだ。

ということで、これから繰り返しになるかもしれないが、新たに読者になった人もいるし、もう一回確認したい人もいると勝手に思って、しつこく経営・事業とＩＴのことを語っていこうと思う。

さて、これから「再びビジネスとITを語ろう」というテーマで書いていきます。まずは、ビジネスの言葉で考えることの大切さをみていきましょう。

昨日もBPMという言い方をやめようと言いましたが、システムの言葉だとどうしてもビジネスの実相から離れてしまうように思います。ERPを入れること、CRMを入れること、Sales Forceを使うことといったところが目的化してしまうからです。

その原因は、ユーザ側もシステム側も両方に責任があると思います。ユーザ側では、自分たちで自らの業務プロセスをデザインできないでいることです。もちろん、一部の先進ユーザはできていますが、大部分は業務のデザインができていないのです。

目の前の局部的な業務は自分たちの方言で説明できるのですが、特に業務全体、あるいは会社の事業執行における位置づけなどといったところのデザイン力が弱いように思えます。俯瞰力がないという言い方かもしれませんが、要は全体を見渡せる力がないように思うのです。

従って、システム側に事例を示してもらうとか、パッケージの機能から説明してもらうとかしないと自分たちの業務を整理できないのです。

一方、システム側はすぐシステム機能の話をします。どの機能を使おうかというアプローチになります。業務の構造とか組織の機能とかいった観点の深堀ができないというか、しようとしないことがあります。

それは実際にその業務の経験がないからということもあるのですが、その固有性や特殊性に目がいってしまい、無理だと思ってしまうのです。

ところが、別の角度からすなわち共通性とか、標準性といった見方で見ていくと、基本的な骨格はパターン化でき標準化できることがわかります。

ということで、現状では双方が自分たちだけで通用する言葉で語っているためにお互いを理解できないという齟齬が生じているのではないでしょうか。

そのために、ビジネスの要求としてビジネスの言葉で提示した与件がシステムの実装になったときにシステム側の都合のいいように歪曲されてしまうということが起きているような気がします。

いまこれだけ技術が進化し、実現機能も多種多様化していることを考えてみると、ビジネスの言葉で表現した仕様がそのまま実装されていくというのは、できない話ではないと思うのです。

そのためには、ビジネス側はみんながわかるような平易で簡潔なデザインをする必要があります。ここでいうデザインとは簡単にいえば、個人の仕事および業務プロセスのオペレーションスタイルを作るということです。

質の高い仕事を迅速にこなすためのスタイルをデザインし表現できることが大切です。それは、楽しく仕事ができるにはどうしたらいいのかに対する答えになるように思うのですがいかがでしょうか。
　

悲喜子さんのブログで「要件定義に関するモヤモヤまとめ」というエントリーがありました。そのモヤモヤが、「要件定義は業務知識がないとできない？」というのと、「お客様自身は、本当に必要なものを気づけない？」です。このモヤモヤはよく分かるし、いろいろな議論があると思います。

ただ、｢要件定義｣（要求定義でもいいのだが）といった場合、それが何を意味しているのかをはっきりさせておかなければいけない。「要件」とは文字通り“必要な条件”のことだが、では“誰が必要としている”ことなのか、あるいは“どうしたいから条件を決めなくてはいけないのか”ということです。

ここの定義でぜんぜん変わってしまいます。すなわち、ユーザ側のもつ要件なのか、システム側の要件なのかです。それによって、条件も違ったものになります。

例えば、ユーザ側の要件であれば、ビジネス上あるいは業務遂行上でこんなことをしたい、あんなことができたらというのが要件になります。それは、ITを使わなくてもいいわけであって、むしろITを使わないほうがよかったりする場合もあります。

一方で、システム側の要件というのは、システム（IT）にとって必要なことであるから、システムの載せられるかどうか、システムが持っている機能に合っているかどうかとなります。すなわち、システム化要件という切り口になるわけです。

わかりやすいのはパッケージを使う場合を考えたらいいと思います。パッケージの持つ機能に合わせられるかというのが要件になるわけです。だから、要件定義をフィットギャップだと思っている人もいます。

こうしてみると、どちらも自分の都合のいいように定義しているわけでこれを共通定義にもっていかなくてはいけないと思います。そのときの軸足はやはりユーザ側であると考えています。根本的にビジネスあってのITだからです。ビジネスあるいは業務の要件をそのままITに落とすことができればいいのです。

こうしたとき、悲喜子さんの問いかけが問題になるわけで、お客さんだけで要件定義ができるのかということと、できないならシステムサイドで定義するにも業務知識がないからできないということになります。

それでこの問題は両者とも共通的に言えるのですが、まずお客さんだけで要件定義ができるようにすべきで、先進ユーザはほっておいても自分たちでモデル化できるが、そうではない会社がいっぱいあって、そこには、「何を決めるか」ではなく、「決めてほしいこと」をシステム側が整理してインタビューすればいいと思うのです。

どういうことかというと、ビジネスや業務の構造、オペレーションのし方、管理のポイントなどはかなり標準的なものであると考えています。すなわちパターン化できるわけです。そのパターンを当てはめてその“中身の空白”を埋めるようにするのです。

ここのところが重要で、今言ったことは業務知識がなくてもできるはずです。では業務知識が要るのはどこなのでしょうか。それは、その空白の内容なのです。一番分かりやすいのは「ルール」です。ある意思決定をするのにどういう基準で行うのか、何を制約としてみるのかといったことです。ここは、会社や業種固有の者があり、外部では窺い知ることはできないかもしれません。

しかし、どういうルールで、どういう基準で決め手いるのですかということは聞くことができます。ですから、どういう決め事をどういう順番で流す（これを業務プロセスという）のかを明らかしに、その決め事の“決め方を”一緒に定義すればいいのです。

ですから、別の言い方をしますと、競争優位の源はルールにあり、業務プロセスにはあまりないのではないでしょうか。この競争優位の源、差別化の要因はユーザ自身が自らの手で定義しなくてはいけません。それを導いてやるのがシステム側の役割です。

従って、モヤモヤの答えは、要件をビジネス上の要件とすれば、要件定義でのシステム側の詳しい業務知識はなくても、意思決定のルールを引き出せる程度の知識があればだいじょうぶだし、お客さんが何をしたいかは、空白の箱を埋めていくような形で引き出せばいいのです。もしそれが出てこないようならそのプロジェクトは成立しないのであって、無理やり進めてはいけないのである。
　

今比較的簡単にシステム化とかIT化という言葉を使っていますが、いったい何をもってシステム化だとかIT化というのだろうか。パソコンを使って仕事をしたら、あるいはEXCELとメールで仕事したら、システム化したことになるのだろうか。

このシステムという言葉もなんとも広く使われているが、村上春樹の言うシステムとIT関連で使っているシステムではずいぶんと違うように思う。ここでは、業務システムという場合のシステムを考えることにする。

最初に言ったように、ITを導入することが、システム化したことになると安易に言ってはいけないように思う。業務システムは、別にITがなくても昔からあったわけで、それは仕事の仕組みだとか流れ、また組織そのものがシステムであると言える。

そう見ていくと、システムにはちゃんとした定義があるのでしょうが、ぼくは「情報の受け渡しの仕組みと仕掛け」のことと定義したい。そうなるとITは必要条件ではないのであって、その仕組みと仕掛けをより効率的なものにしたいという要請に応えるものとしてITがあるという位置づけなのです。ですから、ITを入れることがシステム化することであるという考え方は本末転倒になるでしょう。

そうなると、これまでのIT化システムは“情報の受け渡しの仕組みと仕掛け”ができているのかとみると、どうも不十分なような気がします。さらに今はこれに“見える化”という側面も強調されていて、それについてもできていないのである。

まずは、この情報の受け渡し（仕掛けと見える化はちょっと置いといて）をどうやるかが問題で、これは機械同士で行うだけでなく、当然、機械と人間、人間と人間の間でも情報の受け渡しがあるわけです。そこをITでやらなければシステム化できないというのが間違いではないでしょうか。人間同士でやってもかまわないのである。

問題なのは、そこで情報の流れが途絶えてしまったり、隠れてしまうことである。すなわち、IT同士でもあるいは人間同士でも、はたまたITと人間間でもいいのですが、情報が途切れずスムーズに流れることが肝要なのである。

現実には、企業規模や業態によって、様々な組み合わせがあるわけで、ITがあまり入り込んでなくても、システム化されている企業はあるはずである。従来のシステム化はITでやれるところしか対象にしていないので、下手するとそれまでうまくいっていたコミュニケーションを阻害してしまうケースもあるような気がする。ITを導入することがシステム化であるという発想に立つとそうなってしまうのである。

ですから、システム化ということを原点に立ち返りもう一度考え直してみると、これからは人間もITも混在することを前提としたコラボレーションの場を用意しなくてはいけないのと思うのである。
　

いま、オペレーション志向の稼動プラットフォームのためのフレームワークを開発しているが、その思想では、情報共有型のワークスペースを用意するということがポイントとなっている。このあたりはおいおい報告していくが、この考え方がそのままいまの開発プロジェクトの進め方にも当てはまる。

まあ、プロジェクトと言っても、社長（息子）とぼくの二人だから、適当にやればすむかもしれないのだが、それでもちゃんとやろうということにした。プロジェクト管理も多人数だと大変だが、少人数なら、乱暴に言えばタスクの進捗管理とコードを含めたドキュメント管理さえしっかりやっておけばいいように思う。

そこで、いま二人でやっていることを説明しようと思うのだが、どんなツールを使っているかを示したほうがわかりやすいと思う。それで、タスク管理には、バグ管理などにも使われるTracを、ドキュメント管理には、ソースコード管理に使われるバージョン管理システムの一つであるSubversionを使っている。

この両者はシームレスに連携できるので非常に使いやすい。また、Tracのチケット登録やタスクの完了などの情報やSubversionのコミット情報などが自動的にメールとGoogleトークに配信されるので、動きの早いコラボレーション可能になる。

具体的には、プロジェクトスケジュールと概念設計のところをぼくが書いてチケット登録やマイルストーンの設定をして、Subversionに設計書などをチェックインする。社長はそれに従ってフレームワーク設計をして、採用技術の調査、使用可能モジュールの探索などを行い、コードを書いてそれをSubversionに格納していきます。

ぼくは、コードを読めないので見ても分からないのですが、途中の会話や説明文を読めば何となく分かってきます。こうしておくと、お互いのタスクの進捗状況も分かるし、忘れや脱線がなくなるので、プロジェクトの管理もやりやすくなる。

たった二人だからできるのかもしれませんが、改めて、コラボレーションの有効性に気づかされます。結局、こうした仕事のやり方がこれからの主流になっていくように思う。

それは、システム開発の領域だけではなく、それ以外の一般的な業務においても同様になっていくと考えているわけで、だからこそ新しいフレームワークを開発しているのです。ですから、今のやり方を身を持って経験できることは非常に参考になっているのです。
　

昨年から約1年間、ITRの「企業IT力向上研究会」に参加していて、先週その成果発表会がありました。この研究会の目的は、「企業が実行可能なプラクティスの調査・研究と成果の共有・実践によって競争力向上に貢献すること」とうたっていて、7つの分科会で議論してきました。

この７つというのは、「IT戦略立案方法論」、「ITマネジメント力向上」、「ユーザ／ベンダー関係強化」、「IT人材力向上」、「企業ITアーキテクチャ策定手法」、「情報セキュリティ対応力向上」、「Web2.0技術企業活用」というものです。

ぼくは、最後の「Web2.0技術企業活用」に参加しました。ここでは文字通りWeb2.0技術（去年まではこの言葉も通用していましたが、最近ではすっかり影を潜めているが）を企業のなかにどう適用していくのかということについてずっと議論したわけです。

最初は10人くらいいたメンバーも徐々に減ってきて最後は4人になってしまいました。それでもかなり突っ込んだ議論ができ楽しい1年でした。こうした研究会だと最初の具体的なテーマや成果物の設定がなかなか難しく時間がかかってしまいます。本部会でも当初はどうしても社内SNSとかブログといった切り口、あるいはAjaxなどの技術からの切り込みといったことが遡上に上がったのですが、成功例や定着度みたいな壁があって、最後はやはり業務システムとの関係での提案となりました。

他の部会ではかなり立派な成果を発表していたところもあり、参考になりました。ただどこも押しなべてメンバーの減少については異口同音に何とかしたいという意見でした。会社の業務として参加していないと、そうしても現状の仕事優先にならざるを得ないというふうになって自然と足が遠のいてしまうようです。

これで第1期が終わったので、次に第2期に入っていきます。基本的には今の分科会を継続していきますが、一部名称を変えたり、テーマの絞込みがあるようです。近々に新規加入を募りますので、興味のある方は是非参加してみてください。参考にITRの内山さんのITmediaエグゼクティブの記事を載せておきます。
　

一昨日のITproの「針路IT」の記事でソランがITホールディング（ITHD）の傘下に、またエヌジェーケーがNTTデータの傘下に入ったことに関することが書いてあり、そうした動きは、中国やインドの攻勢に対する生き残りのために規模が重要だという認識から来ているとしている。

この記事を書いた編集委員の田中克己さんは、一度お会いして話をしたことがあるが、その時にもそのITHDがインドの対抗として成立したというようなことをおっしゃっていた。多くのITベンダーのトップと会っている方なので、実感として日本のIT企業の危機を訴えています。

ただ、この規模の追求というのは正しいのだろうか。この場合の規模って何のことを言っているのだろうか。会社の大きさ、顧客の数、製品の多さ、従業員の数、いったい何をもって規模といっているのだろうか。

製造業などのような産業では、よく規模の経済学が指向される。特に装置産業のようなところでは、コストにおける設備の大きさと稼働率が支配的であるわけで、単純に言うと総固定費はあまり変わらないので、製品単位当たりの固定費は規模によって変わるから規模が大きければそれが強みになるのである。

ところが、IT産業で同じような理屈があるだろうか。その前に、議論が混乱しないようにIT産業と言ってもカテゴライズをした方がいいのでそうすると、ざっくり3つあって、すなわちソフトウエアプロダクト製造・販売、プラットフォーム・インフラ運用、システム構築・サービスといったところではないでしょうか。

このうち、プラットフォーム・インフラ運用については、先ほど言った装置産業と同じだから同様な規模の経済があてはまる。しかし、現在はネットによるプロダクトのデファクト化やクラウド化により、ワールドワイドでもほんの一握りの企業が主導権を握ってしまった。

では残りの2つのビジネスについてみてみましょう。最初のソフトウエアプロダクト製造・販売は規模が関係ないのはわかりますよね。グローバル規模で使われている商品があるじゃないかと言われますが、これは順序が逆なのです。規模があるから強かったのではなく、強くなれば規模がついてくるということなのです。

さて、システム構築・サービスですが、日本ではこれをSIerと呼んでいて、大小合わせてかなりの数の会社だが存在しています。そこで規模を追求して合従連衡がおきてくるでしょうか。この領域で規模がビジネスを強くできるでしょうか。

ぼくは、この規模拡大という発想ではいま日本のSIerが抱えている問題は解決できないと思います。もし、規模が優位性をもたらすなら、NTTデータがそして他の大手ベンダーが中小規模の会社を淘汰していなくてはいけないはずです。だから、規模ではなくビジネスモデルと業界構造を変えていかなくてはいけないのではないでしょうか。

構造については、この記事にも書かれているように、「大手ITベンダーや一部の大手ソフト会社ばかりに集中する多重下請け構造のために、ユーザー企業から直接案件を受注できるわけではない」という問題を指摘されています。こうした、硬直化した構造を解体して、優れたサービスとビジネスモデルもった“山椒は小粒でもぴりりと辛い”会社が公平に戦っていけるような世界が求められているように思います。

こんなにしびれたセミナーはいつ以来だろうか。昨日、サプライチェーンカウンシル（SCC）のメンバーズミーティングがあった。今回は、「BPM－DAY：BPM実践の課題を探る」と題して開かれ、SCCの他に日本ＢＰＭ協会、「IT価値と組織」研究会、ビジネスプロセス革新協議会などが連携したイベントでした。

午前の講演はいつも議論していることでもあり、講師も普段会っている人たちなので、午後から参加する。午後は、「IT価値と組織」研究会が主催する「「ひとのつながり」にも目配りするビジネスモデリング」でメインスピーカーは、オランダのデルフト工科大学名誉教授のJan Dietz氏である。彼が確立したDEMO（Design＆Engineering Methodology for Organization）について2時間にわたって紹介された。

この方法論は、Ontologyという概念に基づいて開発されたもので、オントロジーというのは、企業活動を捉えるとき、従来のような仕事のつながりを重視することから人間的な側面を見ていこうというもので、観測可能な表層の下に隠れた深層構造がり、もっとそこに焦点をあてる考え方である。

そうした理論と実践について説明してもらったのである。これがまたしびれた。こんなに目をかっとなって聞いた講演はほんと久しぶりだ。セミナーなどでのしびれ方は２通りあって、ひとつは“目からうろこ”でもうひとつが“共感の嵐”である。この講演は後者のケースでぼくがこれまで言ってきたことやってきたこととほぼ軌を同じくした方法論だったのだ。

第一部の理論編は最初が哲学的な話なのでついていくのに苦労したが、実践論に入るとわかるわかる、いちいちうなずいてしまった。これまで、このブログのIT関連の記事を読んでくれている方は認めてくれると思うが、以前から主唱していることを裏付けてくれているように感じているのである。その概念を表している図（ぼくが勝手にコンパクトにまとめた）を次に示す。

これをみるとおわかりだと思いますが、Infological（計算や加工といった意味を付与を行う処理）やDatalogical（データ転記のような単純処理）のような活動ではなく、その上流（というかビジネス寄り）にあるOntologicalのレベルでもモデリングが大事であり、そこをきちんとやろうよということを言っています。ぼくが言っているマクロプロセス（フロー）のところです。

長くなるので、ここで一旦切ります。つづきはまたアップします。

昨日、モデルの構造を書いた図でDEMO（Design＆Engineering Methodology for Organization）の概要がつかめたかと思います。Dietz教授によれば、B-Organizationのレベルで企業活動を記述するとほとんど変わらないプロセスができると言っていました。

そのことも以前から指摘していましたが、その下のレベルでは様々な非定型的な動き、すなわち“調整”活動があるのです。こうして、一段上のレベルで見ていくことによって、従来のフローの複雑さの9割を減らすことができるそうです。9割は大げさかもしれませんが、6，7割は減らせるというのがぼくの実感です。

また、BPMNやUML、ER図による記述についても言及していて、人間系のところが書けないので限界があるとも言っていました。このあたりのことは同じように既存メソッドの限界を指摘していた身にとっては十分理解できるのです。

ここで、前回のOntological aspect modelの三角形をもとに実際のモデリングの方法について、どんな成果物を作ればいいのかという見方で図示したものを掲げる。より具体的でわかりやすいと思います。

ただ、Dietz教授の前に発表していた専修大学の小林教授によれば、DEMOの骨の理論であるLAP（Language/Action　Perspective）を作った有名なTerry Winograd スタンフォード大学教授の言として、Ontolpgyを活用したモデリングは現在けっして主流ではないが、そのうち認知されるようになるだろうと予想していると言っていました。

さて、こうしてDietz教授の話をききながら思ったのは、こうした発想あるいは体系化はヨーロッパから生まれてくるのではないかということです。どうもアメリカから生まれるようには思えない。

ステレオタイプ的に言えば、アメリカのITは、自動化や効率化という観点であるから、あの三角形のInfologicalとDatalogicalの領域は得意かもしれないが、Ontologyのところは弱いように思う。人間を無視した「モダンタイムズ」のイメージである。

ですから、これまでの日本のITもアメリカ型の合理化ツールという捉え方ではなく、“人間のつながり”という面を重視したヨーロッパ型の考え方を採り入れた方がいいように思うのである。このヨーロッパ型の考え方は日本に合っているのではないでしょうか。

ですから、この機会にぜひこの考え方を注入した日本発のシステム開発方法論とそれを表現するオペレーションプラットフォーム（DEMOはまだ実装方法ができていないのだ）を創っていくべきなのだが、もうお気づきだと思いますがKailasがそこを実現することをめざした方法論であり実装技術なのです。

オントロジーのオの字も知らなかったのですが、同じようなことをしていたことに自分でも驚いていると同時に意を強くしています。かたや学問的に理論的におさえてきて作られたものでありますが、Kailasは単純で仕事の実相に近付けるモデルを考えた末にたどりついたものです。ただ、目的は同じですからこうなるのは必然のような気もします。
　　

企業のシステムをみていくと、幾重もの層があることが分かります。すなわち、戦略のようなものから、ビジネスモデル、ビジネスプロセス、ビジネスアクティビティ、アクションといったことになります。

ところで、そうした各層の特質をみていくと、定型的なものと非定型的なものとに分けられます。さらに定型と言っても、形なのか動きなのかに分けることができます。すなわち静的な定型と動的な定型です。

冒頭の話のなかのビジネスプロセスをとって見ても、プロセスの要素と順序が決まり切っているのか、それが定型的でもそのオペレーションがいつも変わるような非定型なのかといったことである。ですから、4つのタイプに分かれることがわかります。

　１． 型が定型的で、動きも定型的　　　　　　→アクション、トランザクション処理
　２． 型は定型的だが、動きが非定型的　　　→ビジネスプロセス、アクティビティ
　３． 型が非定型的だが、動作が定型的　　　→ビジネスモデル
　４． 型が非定型的で、動作も非定型的　　　→経営戦略

ちょっと強引なところがあるので、こういう区分で合っているのか不安ですが、定型を反復的というみかたをすると少しはわかるかもしれない、それよりもなぜこんな分類をしたかというと、これによってシステムのコンセプトあるいは構造が変わるし、変えなくてはいけないと思うからです。

例えば、非定型ということは多分に人間の心理的な要素が入り込んだものであると言えます。合理的、機械的にはいかない部分で自動化が難しいところになります。ですから、重要なのはシステムがいかに人間と対峙するかということなのです。

ここのところを、従来の情報システムは混同していて、全部定型化の方向へと向かったように思える。情報システムというのは、そのプラットフォームは自然科学かもしれないが、それを使っている領域は自然科学ではなく人文科学の分野であるでしょう。

それこそ行動経済学だとか心理学、あるいは認知科学、デザイン学などの人間を扱う学問の上に築かれるべきだと思うのである。そういったことについて、いつもよく理解していて示唆的な発言をされている鈴木雄介さんの先日のエントリーが参考になります。

そこで言っている。“ソフトウェアは人と仕事をインターフェースすること”で、それはどういうことかというと、“人間がやろうとしている課題を的確に表現し、解決までのプロセスを導き、たどり着けるように支援し続ける。”ことだと言っています。まさにここがポイントなのです。
　　

いま、自治体の業務アプリケーションについて検討している。もともとこの領域にはあまり興味がなかったのだが、以前福岡県大野城市の方々とセミナーで一緒になってお話をしたことや、Kailasで公共向けのアプリケーションを組んだらどうなるのかという問い合わせがあったりしたので、少しばかり首を突っ込みだしたのである。

こうした公共のシステムは共通化されてあるものと思っていたが、どうもそうでもないらしい。ということは、各自治体でばらばらにやっていたり、程度の差があるようだ。でも何か標準があるだろうということで捜したら、(財)全国地域情報化推進協会(APPLIC)というところが出している「地域情報プラットフォーム標準仕様書」（2009年）の中に「自治体業務アプリケーションユニット標準仕様V2.1」というのがあった。

早速、これをダウンロードして見てみたが、うなってしまった。そこには、住民記録、福祉、税など２６の業務ユニットの一覧があり、それぞれについて、機能、機能構成図（DMM）、機能情報関連図（DFD）、インターフェース仕様、データ一覧、インターフェース一覧などが書いてある。

それでなぜうなったかというと、これに基づいてシステムを作るとどういったシステムになるかとか考えたとき、はたと頭を抱えたというわけである。いちばん業務の実態を表現できる業務プロセス（少なくとも業務フロー）が書いてないのである。しかたがないから、機能一覧とDFDからみていくことになるが、その機能一覧にどういうことが書いてあるかを障害者福祉の一つの機能の例で示す。

12.2障害者福祉サービス認定管理　　　　　　　　　　　　　　注）下線は筆者
　　12.2.2申請受付　　　　　　　　　　 ：申請を登録する
　　12.2.2判定ソフト用ファイル作成　：ファイルを作成する
　　12.2.3支給決定　　　　　　　　　 　：支給決定情報を登録し、受給者証を出力する
　　12.2.4負担上限額管理　　　　　　 ：負担上限管理書を出力する
　　12.2.5契約内容登録　　　　　　 　 ：事業者との契約内容を登録する

こう書いてあるものを見てみなさんどう思いますか。これだと、これから作られるものは、登録・出力システムしかできませんよね。データをシステムに入力して、帳票を印刷して出す仕組みをつくることになってしまいます。

実際に、業務をしている人たちはこうしたシステムを望んでいるのだろうか。おそらくそうではないと思うのです。なぜかというと、こうした業務の目的はデータを登録することではなく、帳票を出力することではなく、住民に対する的確で温かいサービスを提供し、満足を得てもらうことにあるわけで、そこを支援できるシステム化が必要だからである。

結局、システム屋の発想でしか見ていないことがわかると思いますが、ITで何をやらせるか、ITでできることはこれですよというIT主体の視点なのです。これまでの業務システムはこうしたアプローチでずっと作られてきた結果、実業務と乖離したままであるような気がする。

このギャップを埋めるものとして、プロセス志向を主張しているのであって、そして、そのプロセスに実業務の実相を表現することで人間主体の業務システムができると信じているである。
　　

羽生章洋さんの会社（株）マジカジャパンから「ITマジカ！」が発売されました。発売されましたと書いたのは、従来の「マジカ！」と違ってこれはライセンス販売だからです。エンドユーザや情報システム部門向けとソフト会社やSIer向けに価格設定がなされています。

詳しくはホームページに載っていますが、「ITマジカ！」は、「マジカ！」が要求定義だとすると要件定義のための道具になります。つまり、ITにいつ、何を、どのようにさせたいのかをカードに書くということです。

カードも肝は、“リクエスト”、“アクション”、“レスポンス”の3枚です。こう書くとおそらく本ブログの読者はすぐに「Kailas」で言っていることと同じじゃないかと思われるかもしれませんね。羽生さんとは基本的に同じ考え方だと勝手に思っていますので、突き詰めると似たようなものになるのは必然なのです。

そして先週の羽生さんのブログに「業務フローと構造化技法とマジカ！」というエントリーが出ていますので、それを読むとより理解が深まると思います。マジカ！で扱う仕事とITマジカ！で行う処理は違うのです。違うというのは、それを行う人もそうですし、仕事の性格も違うのです。こうした違いを階層化することで構造化したわけです。

ここでちょっと気になることがあって、“一段上のレイヤーにおいては業務フロー即ち全体の仕事の流れが流れることが大切なのですが、そのレイヤーに対して日常的に責任を持つ人はいないので、個別のタスクが止まらないかどうかが表面上の気になることとなります。”と書いていますが、これが日本の企業の問題であるように思います。業務プロセスを指向するのはここを可視化して責任者を決め、プロセスの進捗に責任を持たせることが望まれるからだと考えています。

そして、今後の課題としてマーケティングプロセスに注目しています。この顧客接点のフロントエンドプロセスは、従来あまり議論されていなくて、ERPのようなバックヤードプロセスがだいたいいきわたってくると、今後はより重要になってきます。

このマジカ！とITマジカ！はおもしろいですよ。「Kailas」でいうマクロフローとミクロフローという2段プロセスの概念をカードを使ってビジュアル的に表出させるということをうまくやられています。現場の方々もわかりやすいと思いますのでぜひ使ってみてください。
　　

ITproに連載された記事でいつも感心し参考になるものに「ダメな“ユーザー企業”を叱る！」というのがある。前シリーズ「ダメな“システム屋”にだまされるな！」も好評ですぐに書籍になった。著者は佐藤治夫さんで、元野村総研にいてその後スタッフサービスのCIOを務めた人である。

実は、ぼくはその佐藤さんを知っている、というか佐藤さんが野村総研時代に一緒に仕事をしたことがある、というか正確に言うと仕事をしそうになったことがある。あるプロジェクトの依頼先の一つだったが、残念ながら最後の最後でうまくいかった。その時の対面にいた佐藤さんとのおつきあいはおもしろいものであった。

話はそのことではなく、つい最近書いた記事についてである。その記事は、「日本の国民性は情報化に向かない？」と題したもので、その「“シロウト”が情報システムに口を出す」というくだりのところでちょっとひっかかるものがあった。そこにはこう書いてある。

例えば、自動車産業を見た時、クルマの機能、性能、デザインなどについて“シロウト”が何かを言っても、そのまま製品開発に反映されることはありません。安全性、快適性、工場での生産性など、シロウト考えでは及ばない観点があります。ですから、利用者も自動車メーカーも監督官庁も、みんな“プロ”の技術者に任せるべきだと考えています。 　一方で、情報システム産業を見た時、情報システムの機能、性能、デザインなどについてシロウトに大きな発言力があります。安全性、信頼性、開発・保守の生産性など、シロウト考えでは及ばない観点・・・かと思いきや、“ユーザー企業”の中の権力者が「私は聞いてない」「自分は反対だ」「おれは責任を持たない」と叫べば、それまでの検討内容はどうにでも曲げられます。 　日本では、プロであるはずのシステムエンジニア（SE）という名の技術者が、その資質を持たないことも多く、これが“ユーザー企業”の中の権力者が幅を利かす根本要因になっています。

つまり、情報システムはクルマではないのであって、クルマに相当するのは「ソフトウエア」や［ハードウエア］、何とか「パッケージ」までではないだろうか。情報システムとはそうしたソフトウエアやハードウエアを使ってつくるシステムなのであるからちょっと違った意味である。ソフトウエアを作るには”シロウト”はやはり口は出しません。

逆に、クルマの例で見ると、情報システムに似ているのが、クルマを使うバスとか、運送とか、宅配や引越システム、土木作業、タクシーなどのシステムのことに相当すると思う。手段とそれを使ったサービスシステムという区分けがあるように思うのである。

そう考えると違う景色が見えてくる。情報システムは企業では業務システムと言い換えてもいいので、その業務システムを構築するということは、クルマを作る人とそれを使ってサービスを作る人は明確に分かれているように、サービスを作る人が担うものです。

ところが現実には、SEと言われている人たちは、自分たちの仕事はクルマを作ることだと思っている。佐藤さんも勘ちがいしている。だからそこでサービスシステムを作りたい“ユーザー企業”の中の権力者との齟齬が生じるというわけである。何を作るのかがかけ離れているのだからこんなことになる。

とりわけSIerと呼ばれている業界の間違った常識が一向に改まらない限り日本のIT業界の不幸は続く。ソフトウエアとかツールを作ることとサービスシステムを作ることは全く違うことを早く気がついてほしいものだ。だって、トヨタやホンダは日本通運にもならないし、クロネコヤマトにもならないのだから。

ダメな“システム屋”にだまされるな!

posted with yusukebe.com::AmazonSearch on 2010.7.30

• 佐藤 治夫
• 単行本（ソフトカバー） / 日経BP社
• Amazon 売り上げランキング: 59987

• Amazon おすすめ度の平均:
  • 身につまされる想いがあります
  • 全てのシステム屋システム開発企業経営者は一読を！

Amazon.co.jpで詳細を見る