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というものが、実際のビジネスあるいは個人の仕事にどう貢献できるかどうかを考えていこうと思う。実は、ブログで書くということは、書いたら終わりではなくて、しつこく同じことを書くことも大事なような気がするのだ。

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