先頃のエントリーで「BPM交流会」のことを書いた。その中で、ぼくの行った講演のポイントの初めのところに“WhatがHowに優先する”ということを指摘したので、もう少し詳しく説明しようと思う。大変に大事なことだと思うからである。

Whatというのは、ビジネス要求を実現するための仕組みと仕掛けをどんなものにするのかである。それをどうやって作るかはHowであるが、まずは仕組みと仕掛けを設計しておくことが先決であると言っている。そんなことは当たり前だと思われるかもしれませんが、意外といいかげんになっていて、Howを優先しがちになっているのが現状ではないでしょうか。

どうしてこうしたことが起きるのでしょうか。ぼくは次のような3点があるように思っている。そのひとつが、システム化することはITを使うことだと勘違いしていることがある。ビジネス要求を実現するためには、システム化することは重要である。つまり、システムとして対応するのが会社としてのビジネス活動であるわけです。

ただし、ここでいうシステム化というのは何もITを使わなければいけないということではなく、ITがなくても仕組みと仕掛けはできるのです。仕事のどうやるのか、業務をどうやって進めていくのかといったことを定義するわけだから、最初はITを意識することはないのである。それをITばかり、すなわちHowばかりを頭に浮かべてしまうのである。

次に、ソフトウエアとかパッケージの中にWhatがあると思いこんでしまう人が多いということである。従って、そうしたソフトウエアやパッケージを入れさえすればWhatができてしまうと勘違いするのである。自分の力でソフトウエアやパッケージを導入したことがある人なら、どこにWhatがあるのだと思うだろう。

3つ目は、Whatを考えるのがシステム屋さんだということである。だからといってシステム屋さんが悪いと言っているのではなく、システム屋さんにまかせているビジネス側のスタンスがいけないと言っているのだ。

システム屋さんが、ビジネス要求を実現するための仕組みと仕掛けをどうするかと考えたとき、おそらくは、こえは要件定義の問題だと受け取るだろう。機能要求は何で非機能要求はこれだなんて発想になる。つまり、要求を定義してその通りにプログラム仕様書を起こしてコーディングをするというアプローチになる。

結局、コンピュータでやらせるにはという発想がしみ込んでいるから、案外手作業でやった方がいいことを無理やりIT化して、そこで多くの例外処理を作ったり、分岐・差し戻しの嵐になったりする。実は、実業務ではユーザは恣意的だし、例外はしょっちゅうあるのだから、決まりきったフローしか動かないITはやめた方がいいかもしれないのだ。

最初に戻ると、既成概念にしばられるとどうしてもHowを重視してしまうし、所詮最後はツールを使うんだから、そこから考えたっていいじゃないかとなったりする。そうした惰性に負けないよう、“WhatはHowに優先する”という大事なことは守りたいものである。

前回、“WhatはHowに優先する”ということを強く訴えた。ということは別な言い方をすると、システム側としてユーザが欲しがるようなWhatを提示できていないことを意味していているとも言える。だから、Howで勝負しようとする。どんなものが欲しいですかとユーザに聞いて、そのとおりうまく作ってやりますよというのが売りになる。

そして、作ったはいいがあまり使われないと、あなたたちがちゃんとどんなもにしたらいいか言ってくれないからこうなったと言い張るのである。そこには表面上はそうは見えないのだが、奥底にはルサンチマンの響きがあるよう感じてしまう。つまり、自分たちは弱者で強者であるユーザを恨むようにも思えるのだ。

システム屋として一生懸命説明してもなかなかユーザに分かってもらえないという嘆き節もよく聞こえるのであるが、ほんとうにユーザがわかるものを提示しているのだろうか。もちろん中には適当な要求であとはまかせたとか、その反対に本質的なことは忘れて枝葉末節のことばかり言うといったユーザもいるが、実際のところ、ユーザが思わず「君が言っているそんなものが欲しかったんだよ」とか「それはなかなか面白そうだね」と言うような提案をしているのだろうか。

もしできていないとすると、魅力的なWhatを提供できていないということになる。普通、商品やサービスという商材を買ってもらおうとするとき、その商材の魅力を目いっぱい訴えて買ってもらうのだが、業務システム開発は何を訴えているのだろうか。Howばかりをを強調しているのだろうか。

ところが、このHowを売りにするというのもビジネスモデル上矛盾したことになっていて、どういうことかというと、優れたHowは結局のところ低開発コストをもたらすから、売り上げを落とすことになるのである。だから、皮肉な言いをすると冒頭のようにユーザが仕様をあいまいにしていてくれた方がいいのである。

このことは、Whatを議論できる人が少ないことからも推察できる。業務システムあるいはBPMのWhatを突っ込んで考えている人があまりにも少ない。既成のものを無条件に肯定してしまっていて、それをどう作るかというHowばかり議論している。さもなければ、超上流のところとか、目的や効果といったWhyを一生懸命やるひとも多い。

例えば、よくある議論にBPMはなぜ普及しないのかというのがあって、ぼくも加わったりするのだが、いまいちむなしくなることがある。どうしたらユーザに使ってもらえるのだろうかという設問がなされて、やれトップに理解がない、情シス部門がやる気がない、いい事例がないからこれを何とかしなくてはといった答えが返ってくる。

でも、何か変だと感じるのはぼくだけだろうか。自分たちの力のなさを棚にあげて、買い手の非難をしているように思える。ビル・ゲイツがスティーブ・ジョブスがラリー・ページがマイク・ザッカーバーグがそんな根性だっただろうか。

彼らは、おれの作ったこんな素晴らしいものを使わない手はないぜと主張したのである。つまり、魅力にあふれたWhatの提案を続けたから今の成功がある。コンシューマプロダクトと業務システムは違うという反論があるかもしれないが、ほんとうにそうだろうか。

WhatはHowに優先するのだから、初めにWhatを固めておく必要がある。その時の思考アプローチとして守らなくていけないことは、オペレーションから発想するということである。なぜなら、Whatは使われてナンボ、ビジネスの役に立ってこそ存在価値があるからである。

これは自明であるかごとく思われるが意外と分かっていないというのがぼくの実感である。つまりそこまで考えないでシステムを作っていることが多いのである。使われようが使われまいが、あるいは役に立とうがそうでなくともどうでもよいから、ひたすら要件定義に従って作るだけなのである。

視点を変えて業務オペレーションからWhatを考えるとどうなるか。当たり前だが、仕事がうまくできる、業務を円滑進める、ビジネス成果をあげるためにどんな“What”が必要なのかと考えることである。これまでは逆にこのパッケージあるいはこの業務システムを使うと、こんなオペレーションになりますという発想のような気がする。

ですから、ITありき、コンピュータシステムありきで見るわけです。これって、どう考えてもおかしいと思いませんか。一旦白紙で考えてみてください。そうすると気がつくのは、業務オペレーションって、別にITを導入したときに初めて行うわけではありません、ビジネスが行われた時点、事業を開始した時点で業務オペレーションも始まるわけです。

これも当たり前の話ですが、業務オペレーションをしなくては事業運営がままにならないからです。ITがなければ、電話や黒板や立ち話で行っているのです。こうみていくとオペレーションから発想していけば、使われない、役に立たないシステムはできようがないのです。そもそも、こんな風に使いたいから、それができるものを作ってよねとなるわけです。

このことは、特別なことではなく、コンシューマプロダクトを作っている人はみな知っていることなのです。スティーブ・ジョブスはこんなことを言っています。「僕にとってのコンピュータは、人間が考えついた最も素晴らしい道具なんだ。それは知性にとっての自転車に相当するものだ」。ここで、自動車ではなく自転車であると言ってところがポイントで、要するに自分のスタイルを貫くために自分の力で自在に操れるものであると言っているのだと思う。

また、スタンフォード大学のテリー・ウィノグラード教授は、「人間を代行するコンピュータから人間の道具としてのコンピュータへ」と提唱しています。彼はGoogleのCEOのラリー・ペイジの先生だったのですが、かつては人工知能（AI）の第一人者だったのです。つまり、AIで人間の代わりをめざしたのですが、人間の営みはもっとあいまいで複雑だということに気がつきAIの限界を悟ったのです。

いま紹介した二人に共通しているのは、あくまで人間主体で考えるべきであり、コンピュータはしょせん道具であるという認識である。これは、エンタープライズのシステムにも適用すべき考え方だとぼくは思う。業務オペレーションから発想すると帰結するところはここなのである。

このシリーズを「IT再考」というタイトルにしたのは、明らかにシステム屋さんはITをベースに思考するので、ちょっと待てくれ、一旦そこから離れて考えてみたらという気持ちを込めているからである。だから、HowではなくWhatだぞとか、オペレーションなんだぞというメッセージを送っている。

ところで、今から、更に離れてしまうようなことを書く。先日テレビ東京の「カンブリア宮殿」を見ていたら、登山家の栗城史多が出ていた。今年もエベレストに挑戦するという。自分の登る姿をインターネットで動画配信してしまうという今時の若者でもあるが、ぼくがこの番組を見ていてすごくおもしろかったことがあった。それは優秀な登山家ということもさることながら村上龍も言っていたようにすばらしい営業マンであるということだ。

何しろ、この登山プロジェクトで費用が何と7200万円かかるのだそうだ。中継用の機材と人件費がその3分の1くらいだという。ただ登だけなら確か800万くらいで済むらしい。そうなると、この資金をどう集めるかが山に登るより難しい。スポンサーになってくれる企業、人を探しに奔走するのだ。アポなしの飛び込み営業もするのだという。

狙いは社長で、決定権のある人にダイレクトに行くのである。そこで断られても友だちを紹介してくれというのだそうだ。社長の友だちは社長だからである。そこで、スポンサーを獲得できるのはなぜなのか。それは、彼には明確な目標があるからである。挑戦するべき具体的目標を相手にぶつけるからである。この話をしたとき、いみじくも村上龍が「自動車は売れないですものね」と言った。

よく、営業のプロを自称するひとがいて、おれの手にかかればどんなものでも売ってあげるという手合がいるが、それは消費者をだましているに等しい。手段で何とかなるという営業テクニックを強調する本なんかもあるが、どうも変だと思うのはぼくだけだろうか。

営業の真髄は、買ってもらいたいものが明確にあって、それに命を賭けているぐらい惚れこんでこそ買ってもらえるということだ。そこで前々回の「魅力的なWhatを提供できているのか？」というエントリーを思い出してほしい。このことである。ITの世界の営業ははたして、自分が本当に売りたい、こんないいものだから使ってほしいと思って営業をしているのだろうか。ITだけではなく、他の商品でも同様であるが、成功している会社は自分が売っている商品に惚れている売り子がいっぱいいる会社だと思う。

翻って、例えばERPにしても、BPMにしてもクラウドにしても、売り込んでいるほうが本当にその良さをわかっているのか、魅力を感じているのか、それを訴えられるのか、もっと言えば自分が使いこなせるのか、そんな問いかけをしてみたらいかがでしょうか。BPMというなら、自分たちの営業プロセスを書くことからやってみらいいと思うのである。プロセスを書けないBPMの営業では困るのである。だいぶ脱線してしまって、ITから離れすぎたかもしれないが、最近大変気になっているところである。

このシリーズは系統だったものではなく、どとらかというその時々のトピックス的な記事も書いていく。とはいえあまり人の意見や主張にムキになって反応するのも好きではない。しかし、ちょっと言いたいことがあるのでそのことについて書く。

先日、ある勉強会というか、研究会のようなところで、プログラムの自動生成と言うことについて、ツールベンダーから話を聞く機会があった。要するに、データ分析結果と業務ルールを入力するとそこからロジックを推論して自動的にシステムが生成されるという。

これはDOAがベースになっている。つまりデータありきですから、結局単発のデータベースアプリケーションを作る時には有効なのですが、そうではないプロセスアプリケーションを表現することはできない。ERPやその他のパッケージやソフトウエアはほとんどデータベースアプリケーションですから、自動生成するメリットはあまりないように思うのである。ある意味で自動生成の行き着き先であるパッケージがすでにあるからである。

自動化を進めれば進めるほど自動化の必要性がなくなるという自家憧着、あるいはあるパラドックスに陥る。先に言ったようにいいパッケージというのは、自動生成された結果でもあるのだ。同じロジックばかりだとパターン化できて、それ以降は自動生成するのではなくモジュールを持ってくればいいだけになるからである。

ここでそのツールベンダーをとやかく言うわけではない。だいぶ前にでたITProの記事についてである。そのタイトルが「酒は出ないが『注文の多い酒宴』再び 」というもので書いたのはコンピュータ・ネットワーク局編集委員の谷島さんである。その中のメールの引用文ということで、こんな文章が載っていた。「ユーザ主体開発」「システム内製」を主唱する「システムイニシアティブ研究会」に関するものである。

ユーザー主体開発をどう進めるのか、といった点については色々な意見が出ました。五つの講演と質疑応答を聞いた私の感想をまとめますと「欲しい情報 を得るために欲しいシステムを欲しい時期に用意するには、企業の情報（データ）をあらかじめ整理しておくしかない」というものです。 　データ中心アプローチが提唱されてから30年近く経つのでしょうか。成果を挙げている企業は昔からありますし、取り組んだものの挫折した企業も昔からあります。 　ユーザー主体開発という王道を行くには、データ中心の王道を行かなければならず、そのためにどうすればいいかというと最後は、「やり方を変える」「考え方を変える」といった、いわゆるリーダーシップの話になります。

これを読んだ時に思わずずっこけてしまった。突っ込みどころ満載だ。おいおい、システムって「欲しい情報 を得るため」にあるんだっけ？「ユーザー主体開発という王道を行くには、データ中心の王道を行かなければならず」って誰が決めたの？「「やり方を変える」「考え方を変える」」と言いながら、30年近くはっきりした成果をあげられないものをやるんですか？

谷島さんといえば、よく知られた人で、その人がこんなことを言っていいのだろうか。システムイニシアティブ研究会のいう内製ってだいじょうぶなのかと思ってしまう。当たり前だけど内製化することが目的でも何でもないわけだから、ユーザ主体開発と言うんだったら、ユーザが本当に欲しいものは何かを決めれば、作り方は内製であろうが、外製でろうが、クライドであろうが、どうでもよくて、ほとんどは総合的な経済性で決めればいいと思う。次回にまた補足します。
　

前回、「DOAが王道？」というタイトルで日経BPの谷島さんの記事に茶々を入れたが、別にふざけてるわけでも何でもなく、むしろいま日本のITの世界で課題となっていることを象徴的に示しているように思える。その記事で指摘したように、「欲しい情報 を得るために欲しいシステムを欲しい時期に用意する」ことや「ユーザー主体開発という王道を行くには、データ中心の王道を行かなければならず」とか「やり方を変える」「考え方を変える」という主張は、一見正しいように見えるが間違っているということを言いたかったのである。

今のＩTや企業情報システムが抱える本質的な問題をすっ飛ばして、皮相的でテクニカルなエリアでしか議論できていないという、それこそが問題である。このブログでも何回も言っているようにＨowの議論に終始してしまう。ＷhyとＨow（日本語で言うと目的と手段）を議論するならまだいいのだが（この混同もしょっちゅうある）、その間にあるWhatをないがしろにしていることが最大の問題なのである。

Whatとは何か？道具のようなものから、組織とか、運動とか静的なものから動的なものまで幅広いが、その答えは「構造」である。やわらかい言い方をすると「カタチ」である。ちゃんと言うと構造化された構造体といったところだ。目的を達成するための構造（カタチ）、手段を選択するための構造（カタチ）が重要な位置を占めるのである。ここがあまり議論されない、というか日本人は苦手なのかもしれない。

話は飛ぶが、今あまり「構造改革」という言葉が出てこないが、それが日本の停滞の一因であるように思う。小泉首相時代に叫ばれたが、最近はあまり聞かない。今何かしないとまずいというＷhyはまあまあ共有されているが（今のままでいいという能天気な人もいるが）、増税だとか、自然エネルギーだとか、教育だとか多くの議論がなされるが、どんな形の社会、あるべき国の姿といったWhatについての深みがまるでないのである。

規制のない社会とか、セーフティネットの張られた社会とか、リベンジが効く社会とか、グローバル化にどう立ち向かっていける社会とかをどういう構造として設計し、構築していくかが重要だと思う。それと同じように。企業のシステムにおいても、会社の理念、戦略を実行していくためにはどんな組織であり、事業体であるべきか、それを支えるシステムの構造はどうあるべきかが問われているはずである。そこの議論をバイパスしているように思えてならない。

業務改革だとか、IT経営だとかといった上流、超上流の問題は、コンサルファームの人たちやらが多くのことを言っている。一方、開発だとかソフトウエアといったようなテクニカルな下流の領域では、エンジニアが自分語で何かを言っている。じゃあ、上流の人たちよ、あなたたちは、設定した課題を解決するための仕組みを設計・実装できますか、下流のひとたちよ、あなたたちは、書いたコードがビジネスにどう役立っているのか知っていますか。

ITに関するメディアもわかっているのかどうか、日経BP社が発刊している雑誌をみると分かる。「情報ストラテジー」と「ソフトウエア」「システムズ」の間を埋めるものがない。「コンピュータ」がやっているだろうか。もう一度、「何をすることが情報システムのミッションなのか」をよく考えようではありませんか。
　　

前回、少しそれてしまったようなので話を戻すと、システムって「欲しい情報を得るため」にあるのだろうか。もちろんそういった側面はあるのは否定しない。だが、ビジネスパーソンに情報を提供することが第一義なのだろうか。得た情報で何をするのかが重要であって、そこをITはどう関わっているのかという見方をした方がいい。

これまでの情報システムというのは、情報をあるいはデータを処理することが役目だと考えられてきた。「情報処理試験」なんていうのもあるくらいだから、コンピュータの中にインプット情報を登録して、それに加工をほどこし、データベースに格納し、それを検索・閲覧・帳票出力するということがシステムであると捉えられてきた。まさに「欲しい情報を得るため」である。

これって、もちろん必要なのだが、ビジネス上の仕事というか業務遂行に占める割合からいうといちばん大きなものではないと思うのである。要するに、「欲しい情報が得られれば」ビジネスができるのかというとそうではありませんよね。何のためにその情報が欲しいのか、得た情報を使って最終的に何をしたいのかが大事なことではないでしょうか。

その事業のビジネスモデルにあるサプライチェーン（デマンドチェーン）を効率的に運用して利益をあげること、それには、様々な局面で正確で質の高い意思決定を迅速に行うことだと思う。そのために「欲しい情報を得る」のである。だから、メインのシステムはこうした一連の意思決定プロセスなのである。ところが、従来のほとんどの情報システムは意思決定した後の結果だけを登録するという機能だけだったのである。

ビジネス活動に必要なメインのプロセスに対するシステム化をないがしろにしたままで内製化もへったくれもないのである。不思議なのは、データ登録システムならなぜ今さらせっせとコードを書いているのかということである。プログラムの自動生成のところでも書いたように結局は「欲しい情報を得るため」のシステムはパッケージ化できるのであって、そんなところに一生懸命になって内製化する必要はないと思うのである。

次の「ユーザー主体開発という王道」というのを考えてみましょう。ユーザーが主体となってシステムを構築するというのは正しいというか当たり前なのであるが、ここで使っている言葉でちょっとひっかかるのは、“ユーザー”と“開発”である。ユーザーとは誰のことを指しているのか、開発とは何を開発するのかということである。

ユーザーのことでいうと事業部門や部門の人たちのことなのか、情報システム部門の人たちのことなのかである。あるいは、ベンダーやSIerではない、ユーザー企業全体をさしているのかである。プログラムの内製化と言うなら事業部門や部門の人たちでは無理だから、情シス部門のことを指すのだろう。その人たちがコードを書くのだろうか。

そこを考える前に、“開発”ということをみてみよう。いったい何を開発するのだろうかと思ってしまう。みなさん、普通にシステム開発と言うのですが、業務システムを要件定義したあとプログラミングするのを開発というのでしょうか。業務システムというのはビジネス要求が定義されたときにシステムの開発は終わったと言えるような気がする。

ソフトウエアやパッケージは開発すると言ってもいいが、少なくとも業務システムの受託開発はあり得ないのではないかと思うのである。つまり、誰もやっていないような業務プロセスにするとかいうことはあっても、誰もやっていないようなコードを書くということがあるのだろうか。まあ、全くないと言うと反論がきそうなので、圧倒的なパフォーマンスを出すためにすごいコードを書くというようなことはありかもしれないと言っておきます。

結局、「ユーザー主体開発」というが、業務システムというのは古今東西ユーザー主体であることは疑いようのないことで、業務プロセスの設計はユーザーしかできないからである。で、設計ができたら、それをどう実装するのかは、実装のし方で、ユーザー自身がやってしまう場合もあるし、外部のベンダーを使って実装させる場合もあるだけなのだ。

実装もベタにコードを書く場合もあるし、フレームワークやモジュールを持ってくる場合もあるし、コンポーネントやパッケージでやってしまう場合もある。どれを選択するのかは、後々の運用を考えた上でどれが一番いいのかを判断すればよくて、ユーザー自身が内製しなくてはいけないというのは王道ではない。

今回は、「ユーザー主体開発という王道を行くには、データ中心の王道を行かなければならず」、そのためには「やり方を変える」「考え方を変える」必要があるということについて考えてみましょう。王道というからには、みなさんのコンセンサスとして、システム開発は、データ中心でやるべきだとなっているのでしょうか。

その前に、上げ足とりで申し訳ないのですが、「王道」を行くのにやり方を変える、あるいは考え方を変える必要ってあるのでしょうか。ここで言っている「王道」というのは本来の意味ではなく、正攻法の基本形とか定石といったようなことだと思うが、そうだとすると今のやり方は、異質で特殊なやり方なのだろうか。

「学問に王道なし」と言うようにシステム開発に「王道」はないのではないだろうか。例えば、全く違った技術がでてきたとか、すごいパフォーマンスが得られたとか、画期的なビジネスモデルに対応しなくてはいけないといったことが起こったとき、当然攻め方が変わるし、従来の定石では通用しなくなります。簡単な例では、コンピュータのハード資源が限定的のときと今のようにそんな心配はしなくていい時代の開発は違ってくるわけです。

従って、これでなければいけないとか、「王道」とかいうのはおかしな話なのです。そこで、ユーザー主体開発という王道をいくにはデータ中心という王道を行くべきだという主張を皆さんはどう思われますか。まずは王道というのは言い過ぎだからそれを外すとして、DOAでユーザーが主体となって内製化するのが、今のもろもろの条件の中で正しい選択なのだろうか。

それを検討する際の大事な視座は、ユーザーが実際のビジネスをやるときに役に立つシステムを作るにはどういうアプローチがいいのかということであろう。ということは、ユーザーはどういうビジネスのやり方、業務の処理の仕方、お客さんとの接し方、意思決定のやり方をしているのかを子細に観察して、そこへITがどういう手助けができるかを探ることが原点となる。当初のコンピュータは、経理の人が、そろばん片手に計算していたのを助けたわけです。

ところが、私見ですがその使われ方がずっと引きずってきていると思っています。個人の労働生産性の向上のためのコンピュータの使われ方はすごいものがありますが、こと業務システムについては、データを登録して、演算・加工処理してもらうというのが主要な使われ方だったと思います。

これも何度も問題提起していますが、それはいちばん重要な業務なのでしょうか。もしそうなら、たしかにDOAのアプローチが有効かもしれません。どんなデータが必要なのか、そのデータはどんな属性をもつのか、そのデータを効率よく格納し、素早く取り出せるにはどんな箱がいいのかといったアプローチである。

しかしながら、よく考えてみると、そのデータって、どうやって作ったのかはどこに行ったのだろうか。作られたデータをどうやって処理するかがメインだから、極端な話どうでもいいことになってしまう。データがどうやって作られたかがすごく大事だと思いませんか。事業の成果って数字ですが、その数字は組織の意思決定としての結果でもあります。例えば、売上高は営業して、受注して、出荷して、代金を回収して初めて、数字がつくられるわけです。

このデータの生成過程こそ「プロセス」なのである。その過程というのは、例えば同じ売上金額だったとしても、それがネットから受注したのものか、一生懸命営業が足を運んだ結果なのかでずいぶんと違うでしょう。それが結果だけを注目してしまうと、なにも改善につながらなくなります。じゃあ、営業コストをそんなにかけるのではなく、これからはネット販売を増やそうとかに結びつくのである。

ということで、実際のビジネスの現場ではプロセスを中心にして組織的な活動を行い成果を上げているわけで、その流れをそのままITをうまく使いながら執行するのが「正道」でしょう。
　　

少し話を変えて情報システムの構造から、その構築のためのアプローチについて考えてみましょう。どういうことかと言うと、縦と横のブロックとその関係性のことである、と言ってもさらにわからないかもしれませんね。簡単に言うと、誰があるいはどんなITがその部分を担っているかをみたらいいと思います。

つまり、縦であると超上流、上流、下流なんて言い方があるように、コンサルティングファームの人が戦略からビジネス要求を出すところをやります。そのためにマイケル・ポーターを持ちだしたり、BSCとかKPIとかシックスシグマとか言います。

そして、SIerとかシステムベンダーと呼ばれる人たちが要件定義して設計をします。そこにはパッケージを持ってきてフィットギャップをしたりする場合や、プログラム仕様書に落とすこともあります。その後は、ソフトハウスや下請け開発会社のエンジニアやプログラマーが実装するわけです。垂直分離した形で割ときれいに役割分担がされています。

ところでこうしたやり方はどんなシステムにも当てはまるのでしょうか。開発方法論もアジャイルなんかが出てきて変わりつつありますが、もっと視点を変えて横の構造をみてみたらどうでしょうか。企業の業務システムというのは、簡単に言えば、オーダーをもらって、それに合った商材を提供して、対価として代金を回収し、成果を管理することなわけで、そうした流れを横の構造と考えます。

バリューチェンとも言いますが、それぞれの部位で構造や機能が違っています。お客さんからオーダーをもらうところ、商品を開発するところ、サプライチェーン、売り買いの機能、会計処理して決算をするところなどはそれぞれ違いがあることはおわかりだと思います。そこで、ここでの提案は横の機能をきちんと分離して考えようというものです。

冒頭に言ったように縦の役割分担は良くも悪くもなされているのですが、横については明確な線引きはされていません。つまり、どれもみなSIerやベンダーからソフトハウスから皆がああじゃないこうじゃないとやっているわけです。例えば、ERPがフロントエンドに出て行くとか、グループウエアが業務システムと言いだしたりしています。

縦は分離するのではむしろ境をなくして融合させるが、横ははっきりと分けた方がいいと思っています。極端な話、要求定義から設計、実装を一人でやってもいいと思う。しかし、顧客接点のところとサプライチェーンのところとERP（統合DBあるいは決算システムとしての）のところははっきりと分離させた方がいい。

顧客接点のところは、もちろん定型化されるわけではなく、個別対応が重要な機能であるから、それに向いたITが要るし、人も配置すべきなのである。サプライチェーンはビジネス成果を出すためのプロセス管理が肝ですから、業務の遂行を円滑に行えるシステムが求められるのです。ERPは結果の集約を行い事業成果、経営執行の結果を表現するものである。

情報共有・コミュニケーション主体、プロセス主体、データベース主体とそれぞれが特徴づけられるから、同じアプローチでは無理があるのだ。そして何より、各領域のインターフェースがはっきりしていることがある。つまり、顧客から問い合わせや引合が来るまでと、そこから商品出荷し代金を回収するまでと、その結果だけを受け取り決算するまでという風に取り合いも明確にできる。だから、既成のERPが変にでしゃばってサプライチェーンに出てくるなと言いたいのだ。むしろ、もっとシンプルな決算システムになってほしいと思う。

SOAというなら、マクロ的な見方をするとこうした考え方こそSOAの基本のような気がするのだがいかがでしょうか。コンポジットアプリケーションとか小難しいことを言わないで、水平分離して、各パートは極力シンプルにして、それらを有機的につなげるという考え方で行きたいものです。
　　

前回の垂直分離と水平分離に多少関係するのだが、○○管理システムという名前のシステムがやたら多いのが気になっている。この場合の“管理“という意味は何なのだろうか。対象は何で、どんなことをすることなのだろうかを少し考えてみたい。

まずは、対象ということで言うとリソース（経営資源）のようなものについてはわかりますよね。ヒト、モノ、カネの管理と言われるとああそうか思うでしょう。すなわち、ビジネスで必要となったリソースを的確にかつ素早く提供できるように管理しておくということである。

新規プロジェクトに人が要るとなったらそのメンバーを用意しなくてはいけないし、稼働率が上がったら予備の設備を動かさなくてはいけないとか、Ｍ＆Ａでは資金を提供しなくてはいけない。そのために、採用によって人材を確保するとか、スキルアップのための教育を施すことや、最新鋭の機器を購入するとか保守点検を怠らないとか、財務上の健全性を維持するとかがなされる。

管理という面ではもうひとつの側面があると思う。それは、実績データの管理である。管理というよりかは“分析“といった方がいいのかもしれないが、業績管理ということにつながるので管理という捉え方をする。つまり、管理とはどんなことをするのかというと、リソースの管理と実績データの管理ということが言えます。お気づきだと思いますが、これはＥＲＰシステムですよね。○○管理システムの集合がＥＲＰなのです。

ところで、システムとして持つべき機能はそれだけでしょうか。例えば、販売管理とか生産管理といったものを考えてみましょう。リソースの管理と実績データの管理だけではないのがおわかりかと思います。売るため、作るためのリソースと売った結果、作った結果だけを管理していればいいのでしょうか。

大事なのは、“実行する“ということがあります。ＰＤＣサイクルでいうとＤｏのところです。今までの管理という側面はＰ，Ｃのことを言っています。リソースPlanを立て、実績をCheckするわけです。しかし、重要なのは、戦略や方針に従い、計画通りに実行させることなのです。このDoを行うシステムがちゃんとあるのでしょうか。

世の中にある販売管理システムや生産管理システムにはほとんど備わっていないように思う。販売システムと生産システムが要るのです。ただし、ここでは一般的な業務を言っています。実は、先進的あるいは優良企業ではこの実行システムで差をつけています。例えば、宅急便の追跡システム、コンビニのPOS、銀行のATM、証券取引や電車の発券システムなどです。トヨタのJITとかキャノンのセル生産などもこの類かもしれません。これらは、独自のシステムを構築しています。

超大企業ならいざしらず一般の企業、特に中堅・中小企業はなかなか独自開発もままならないわけで、そこに安価で機能的なシステムが望まれています。この部分というのは前回にも指摘したようにプロセス主体で仕事を回すので、的確なコンセプトを持った「プロセス実行システム」が管理システムとは別に必要なのである。
　　

また聞き慣れない言葉出てきたと思っている方が多いと思います。それもそのはず初めて使う言葉です。意味は、ケミカルプロセスのようにビジネスプロセスも考えてみたらという提案なのである。なぜそんなことを思いついたかというと前回の議論とも関係している。管理システムと実行システムは違うという話である。

本ブログで何度も書いているようにぼくは若いころケミカルプラントで働いていた。ケミカルプラントは基本的にはプロセスがメインになっている。ケミカルプロセスには、大きく連続プロセスとバッチプロセスがあるが、ぼくがいたのはペトロケミカルの上流のところだから連続プロセスの方で、原料を投入するといくつかの単位操作を経て製品を生み出すのが連続的に行われる。原料投入から製品産出までがマクロプロセスで、単位操作もプロセスを形成していてこちらがミクロプロセスである。

この場合、プラントの生産プロセスは制御システムにより運転が行われる。温度、圧力、流量、品質などを設定された値に維持するように各種の条件を調節するわけである。その結果として成果物である製品を作り出し、貯蔵タンクに保持するのである。これが、ケミカルプラントにおけるプロセスオペレーションであるが、大事なのは、所定の製品を十分な品質で低コストで早く、そして状況変化に俊敏に対応することなのである。QCDFの確保である。

まさに生産実行システムである。現場のオペレーターがこれを行う。一方、こうした生産活動の結果として、先ほど言ったようなQCDFはどうであったか、予算や計画との差異はどうだったのか、トラブルはあったのか、改善の余地があるのかといった実績の視点で過去のことを管理するのが生産管理である。ケミカルプラントでは、実行システムと管理システムは明確に分かれている。

さて、いま巷にある生産管理システムというのはどうなのだろうか。どうもいわゆる管理システムがほとんどで実行システムは少ないように思う。スケジューラーを含めた計画系や部品表などのリソース管理はあるにしても、結局は実績の集計と分析になっているのではないだろうか。実行システム、すなわち生産の進捗を管理するところが、自動車だとかエレキなどはあるだろうが、全般的には弱いように思う。

さらに生産以外でも同様で、例えば販売管理というが、営業プロセスつまり引合からオーダーをもらうまでの実行プロセスで、その進捗をきちんとつかんでいるとは思えない。引合の案件登録はします、オーダーリストは作りましたで終わっていませんか。まあ、ステータス表示まではしているところはあると思いますが、ケミカルプロセスのようにコントロールしているでしょうか。

重要なことは、結果の管理でなく現在をいかにいい状態にするかという制御を行う必要があるということで、済んだことをほじくり返してああすればよかったこうすればよかったでは後の祭り（ぼくはこれを死体解剖と呼んでいる）なのである。ですから、実行プロセスをコントロール＆オぺレーションする仕組みと仕掛けをケミカルプロセスと同じようにビジネスプロセスにも持たせた方がよいと提案しているのである。
　　

前回、Chemical BPMという表現で化学プロセスとの類似性について言及した。そうなんですね、どこにでもプロセスがあって、というか世の中プロセスだらけといっても過言ではありません。生活の中にもありますし、個人の行動もプロセスに従って行われます。ですから、プロセス思考やプロセス的なアプローチはとても大事なことになります。

ところが、ITの世界でプロセスというとそれはBPMですかとか、ワークフローツールを使うのですかとすぐ言う。そして、自分たちがやっている業務のプロセスを設計するといった意識が薄い。普段行っていることがほとんどプロセスで成り立っていることを意識化できていない。例えば、IT営業の人たちが、営業プロセスを書けるかということである。

意外と書けないかもしれない。ソフトウエアやパッケージ、ツールを売りこむのはうまいけど、プロセス的な思考で段取りをしてアクションを起こしているのだろうか。ITだけから発想するとなかなか行きつかないことも多い。だから、いくらプロセス大事ですよと言っても届かないのだが、そこを改める方策のひとつとしてビジネスモデルから考えてみるという手がある。

まずはビジネスモデルありきという考え方です。ビジネスモデルというのは、大きな意味ではプロセスでもあるのですが、ビジネスの構造あるいは機能といったらいいかもしれません。具体的には、どこの誰に（顧客・市場）、どんな商材を（製品・サービス）、どの経営資源を（ヒト・モノ・カネ等）使って、どのように提供（サプライチェーン）して、どうやって儲けるか（商流）を定義することです。

ビジネスモデルもプロセスであると言ったのは、ビジネスモデルの執行は大きな流れがあるということです。つまり、顧客を獲得して、注文を受付け、提供する商品とその仕様および使用するリソースを決めて、商品を用意して顧客に届け、代金を回収することです。これは大きくはプロセスです。事業プロセスの基本形でどんなビジネスもこの形になります。

そして、いわゆる業務プロセスというのは、ビジネスモデルの各要素を更に分解したものになります。例えば、最初のどこの誰にという顧客とか市場といったエリアでは、新規顧客を獲得するためのプロセスだとか、商談プロセスなどがあるわけです。ビジネスモデルというのは、事業の特質が入り込んだものですから、そこから必然的にビジネス要求が出てきます。

つまり、その事業が他社との競争に勝って存在しているのはモデル上どこが強いのか、あるいは更に強くするためにどこを改善したらいいのかといったことが現れてきます。そこから出てきたビジネス要求を実現するのは何かというと業務プロセスになります。

だから、そこまで考えてからプロセス設計をしないとプロセスを書きますといっても単にいまやっている業務の流れだけを書くことになってしまいます。これでは、見える化にもなりません。従って、まずはどんな形でもいいからビジネスモデルを書くことを最初にやたらいいと思います。

逆の言い方、すなわち組織は情報システムであるといってもいいのだが、情報システムと組織は密接な関係になっていると思う。前回、ビジネスモデルが一丁目一番地だと指摘したが、そのビジネスモデルを実行する主体って何かと考えたときに組織であると言える。

個人が勝手にビジネスをしているわけでもないし、ほっといてもコンピュータがみんなやってくれるわけでもない。ビジネスモデルに対応した組織が編成され、その組織の一員として個人がいることになる。そして組織の構成員それぞれが何らかの形で関係し、連動して動いている。それはまさにシステムそのものであると言える。

組織と人のシステムが機能するためにコンピュータを使った情報システムが存在する。従って、両者は表裏一体で組織は情報システムに重なり、情報システムは組織を映し出す関係が必要だと思う。企業として営むべき事業のビジネスモデルが設定され、それを表現するビジネスプロセスが定義されたら、それを実行するために一体となった組織とシステムが構築されるべきなのである。

組織とシステムが表裏一体であるといったが、それなら組織論からシステムを考えてみたらどうだろうか。ここで特に強調したいのは、階層化の考え方で、サイモンは複雑な問題は一挙に対処できないから、問題を分解して組織目的の階層化を行うのだと言っている。当然組織の意思決定も階層化するわけで、課長、部長、事業部長のやるべき意思決定のレベルは違うのである。そうしないと組織全体の目的を達成できないからである。

こうして、組織が階層化されその各々のレベルで意思決定の責任者がいる。組織は意思決定の複合体系である。ということは、表裏一体である情報システムも階層化されてそれぞれの責任者がモニタリングしコントロール＆マネジメントができる情報システムがなければいけない。ところが現実の情報システムはそうはなっていないのである。

いやありますよと反論する人もいるかもしれない。経営コクピットなんて言葉があるのでそれがそうですよと言う。しかし、よくよく見てみると成果に対する分析だとか、リソース状況だったりする。特に上位職位の意思決定のためのシステムが貧弱というかないに等しいのである。担当者のタスク管理が主で、その結果を承認するという機能しかない。今のシステムでの承認という行為は意思決定ではない。

組織としての合理的な意思決定が会社を動かしているとしたら、従来のままだと情報システムの寄与は少ないと言わざるを得ない。さらにバーナードの組織論の3要素である「共通目的」「協働意欲」「コミュニケーション」を意識した情報システムになっているだろうか。どうも、実行部分は担当者のタスク管理までであり、上位者はその承認と実績データの分析結果を見ることだけになっているように思える。もっと、各階層でのオペレーションを意識したシステムが望まれるのである。

先日、家からさほど遠くないところにある中小企業を訪問する。その会社は従業員が20人弱で精密切削加工が主要事業である。最近はJAXAの仕事などもやっていて非常に技術力が高い会社である。そこのまだ30代半ばの2代目の常務の方と情報交換というか、先進的な中小企業がITに関してどんなことをやっていて、どんな課題を抱えているのかを聞きにいったのである。

うちの社長（息子）と二人で車で小1時間のところにある工場の2階にある事務所で席についたのですが、その机の上に置いてあるプロダクトが面白い。何に使うという用途が定まっているわけではなく、ただこんなものを作ってみたいから作ったのだという。極めつけは6足歩行のロボットである。まるで昆虫が這うように動く様は驚異的だ。それが単にサーボモーターだけで動かしているという。デザインとエンジアリングの融合なのだと言う。以前紹介したダイソンの社長と同じ言である。

さて、肝心のＩＴの話であるが、当方から紹介した話に興味を持っていただいたが、その一連の会話の中で面白いと思った彼の言葉が、いまの業務システムには「遊び心」がないということである。使っていても楽しくないし、やらされてる感はあってもワクワク感がないと。遊び心と言った瞬間にビビッときますよね。

例としてこれまた愉快だったのは、みんな見える化なんて言っているけど、本当に見える化したらどうかということで、お金の流れを「見える化」したいのなら、オーダーもらったらお金が落ちてくるとかにしたらどうかとか、データを登録したら、ごくろうさまでしたとか音声がでてくるようにしたらどうかと言う。

彼らたちは最初に言ったようにおもしろいこと、楽しいこと、気持ちいいことを作ってしまうという精神が根付いているから、今の業務システムみたいな型にはまった窮屈感に不満があるのだ。このことはこれからの業務システムを考える上で重要なことだとぼくは思う。このブログでも何度も主張しているように不機嫌な職場にならないためにも楽しく仕事をするためのツールとしてのITが望まれるのであう。

さらに、もうひとつ、自動化という問題である。彼は元いた会社で徹底的に自動化を推し進めたことがあるという。どうしたかというと、製作の手順を決めてそのとおりに動くように装置を設定してそのプロセスに乗せることをした。確かにそうすれば全自動が可能である。ところがである。それは洗濯機の全自動のように全くの定型であればいつもいつも同じパターンでかまわないのだが、現実の製品というのはなかなかそうはいかないでちょっとした差異も含めて違うプロセスになるのである。

ということはどうなるのかというと、注文が来るたびにプロセスを設計し、装置の設定プログラムを変え、段取り替えを行うのである。製作工程そのものは全自動になっているが、その工程そのものを随時設計するという設計も含めたマクロ的なプロセスが自動化できなかったのだ。そのため全自動化してコストダウンになるはずがかえって再設計や段取り替えのコストの方が上回り何のための自動化だったのかがわからなくなったという皮肉な結果だったのだそうだ。

これも非常に示唆的な話で、BPMでもビジネスプロセスオートメーションということを標榜する人もいるが今のような例でもわかるように何でもかんでも自動化することが合理的であるとは限らないので、ぼくの意識ではBPMでいうプロセスエンジンという機能の評価はそれほど高くないのである。

いつも同じようなパターンが数多くあるような場合では自動化という効果があると思うのだが、そうでもないケースでもプロセスエンジンで回そうとするのはどうかと思うのである。分かりやすい例で言うと、自動化したいがために分岐をつくることと分岐は人間の判断にまかすということの差異の評価をきちんとするということである。

ということでちょっとした時間の中でかなり中味の濃い話ができうちの社長も感心していたし、ぼくもかなり刺激を受けたので、少し楽しげな提案も考えてみたいと思うのである。
　　

前回、ある中小企業の若手経営者の話をしましたが、今回は先日見た「カンブリア宮殿」で取り上げられていた大垣共立銀行の話をします。同じようにそこの頭取が「遊び心」という表現をしたからです。ただ、ITとは若干離れるのですが、相通じるものは多くあります。

ここの地方銀行は、今年1月に発表された「日経金融機関ランキング2010」の顧客満足度調査で３位にランクされています。上位２行はネットバンキングなのでリアルの店舗をもつ銀行ではトップという快挙です。そして顧客満足度がちゃんと営業成績につながっていて、10年で預金高が１兆円増えてのだという。なぜそうなったかがすごいのである。

ここの土屋頭取というのは1993年に46歳の若さでこの地位についてから、様々な改革や新たなサービスを展開したのである。まず、徹底したのが「銀行は金融業ではなく、サービス業である」ということである。だから、動きの悪い行員に“おまえは銀行員か”といって諭すのである。

そしてユニークなサービスを仕掛ける。ATMでお金を出し入れするとスロットマシンになるんですよ。そこで当たりが出ると手数料がタダになる。何という「遊び心」だろう。それとか、公共料金を払うとポイントがたまるのである。主婦はポイントに弱いからすぐに行きそうですよね。

なるほどと唸ったのは、ドライブスルーATMだ。ドライブスルーで車が着くとATM機が運転手席の位置に合わせて動いて、そこで入出金や振込、記帳ができるのだ。これって便利ですよね。テレビでは、赤ちゃんをチャイルドシートに乗せたお母さんがインタビューに答えていたが、いちいち子どもを下ろしてベビーカーに乗せ換え、ATMで並んで操作することから較べて格段に楽になったと言っていたがまさに行き届いたサービスではありませんか。

さらに、コンビニ仕様の支店まで作ってしまった。なぜそんなことをしたかというとあるとき銀行でお金を下ろした人が隣のコンビニで公共料金を払っていたのを銀行員が見て衝撃を受けたというところから発想したのだという。これではコンビニに負けてしまうというものすごい危機感をもったのだが、自らがコンビニのような店舗にするという手を打ったのである

制服もコンビニ風で銀行では危険だからということで御法度であるトイレも設置、コーヒー無料サービス、雑誌立ち読み自由という。（住宅雑誌の下にさりげなくローンのパンフレットを置いておく）だから子どもまでやってくる。それでいいのだという。ずいぶんと銀行のイメージが変わったものだ。顧客目線でサービス提供という考え方である。

こうした発想ができるのは、ひとつには異業種企業での研修の効果が大きい。従業員は1年から1.5年、銀行とは全く違う業種の会社へ研修にやらされる。この長い期間の研修というのが意味があって、1カ月とかの研修はよくやられるのだが、これだけの長さだと受け入れる企業も本気度を感じるし、表面上のことだけではなく裏のことまでも学べるという。

ITとは直接関係するような話はほとんどないが、多くの示唆的な内容を含んでいる。まずは「遊び心」が大切ですよということ、異業種に学ぶ「越境の精神」、それと既存にあるサービスの転用あるいは組合せで新たなサービスを創造する「組合せ型サービス」といったことはどんな業界でもあてはまるのではないでしょうか。アップルのビジネスなんてある意味この通りですよね。

こうしたことは頭取一人のトップダウンでできたわけではなく、行員の意識改革という面が非常に大きいのは言うまでもない。重要なのは、トップが「銀行はサービス業である」という明確なメッセージを発したことで求心力も増したのだと思う。IT業界でもSIerはサービス業であると言っている会社もあるようだが、大垣共立銀行のように実行が伴わなかったら何もならないことを肝に銘じる必要があると思う。
　　

前々回と関連することを書く。全自動のワナの話をしたがそのことである。製造工程は全自動になったが、そのプロセスは頻繁に設計しなくてはいけなくて、それに伴う段取り替えや工作機械のプログラム設定に手間がかかってしまい、トータルでみたら本当に合理化になったのか疑わしいという話である。

先月初め、サイボウズから業務用のWebアプリケーションを手軽に開発できるPaaSである「Kintone」の販売が開始された。そのキャッチフレーズは、変化の早いビジネス環境に即座に適応するため、ファストフードやファストファッションのように気軽に使える「ファストシステム」をコンセプトとしている。

システム開発を高い技術と長い時間がなくても気楽にやれるというのはすばらしいことだと思う。うまくできれば使う人が自分の欲しいものをすぐに作れるようになるかもしれない。要件定義なんて要らなくなりますよね。ぼくも以前から注目していてやっと登場というところです。ぜひ使ってみてください。ただ、だからこそ気をつけなくてはいけないことがあります。

ひとつは、かつてLotus Notesで痛い目にあったシステムの乱立の問題です。気楽に作れるからちょっとリテラシーの高い人はみな好き勝手に開発してしまうかもしれません。似通ったものを部門ごとに作ってしまうのである。そこはガバナンスの問題で、情報システム部門が統制すればいいのだが、単に重複してはいけませんよとか、あなたの部署は今からだから、こちらの部署のものをそのまま使って下さいといっても聞いてもらえないかもしれません。

もうひとつは、最初に言った問題です。つまり、システム開発はそれこそ全自動とまではいかないにしろコードを書かないのだからかなり自動化された感じで作れます。しかし、問題はそのプロセスがちゃんと設計されているのかということなのです。いいかげんな設計だと似て非なるプロセスがここでも乱立してしまうのである。

プロセス設計のところできちんと標準化と正規化を行い、それを共通化して使いまわすことをしないと、簡単にシステム開発ができるかと似通ったシステムが多数できてしまうことになりかねない。つまり、大事なのは開発の生産性よりもプロセス設計の効率化のところなのである。

ここでプロセス設計の効率化と言ったのは、AsIsをそのままとか、細かいところ、例外、こだわりなどを正直に書いてしまうとかといったことを平気でやることで重複設計、手戻り設計、不再利用設計となり効率を落とすことを指している。つい、簡単にシステムが作れてしまうので、設計をないがしろにしがちなので注意する必要がある。

逆に言うと、実装独立でちゃんと設計できるようになればこれほど武器となるツールはないわけで、システム構築のサイクルの中で開発・実装工程の負荷が相対的に減少して、より業務に近いところに注力できるメリットは大きいのである。

プロセス志向で大事なことに顧客要求をきちんと分析し切り分けすることがある。プロセスは、顧客と事業成果を結びつけるところでもあるわけで、顧客が要求するものに的確に答えてこそ初めて成果につながるわけです。そうでないと、手戻りしたり、とんちんかんな答えを出してクレームがきたりとなって、結局のところ顧客満足度も下げることになる。

そして、実は顧客要求というのが一見正しいように見えているがよく吟味すると違っていたりすることがけっこうある。あるいは、非常にあいまいで、だいたいの感じで言ってきたり、単なる思いつきだったりすることもある。ですから、そこできちん本当の要求は何なのかを詰めておかなければいけない。

ただ、その方法をどうするかはケースバイケースで難しく定まったやり方はない。たまたま今扱っている案件での具体例で言うと、顧客要求として「特注品」の製作依頼というのがある。まず特注品だから当然のように類似品がないので独自の要件となるが、どこが独自なのかを見定めないと、案外独自と言っていてもそうでない場合もある。

というのは、要求を出してくる人にとって自分のドメインとか経験からしか発想しないから、自分にとって独自なだけであって、そのフレームからちょっと外れた領域では一般的であるというようなことはしばしば起きる。ということは、要求を受ける側はできるだけボーダーを設けず幅広に考える必要がある。特注と行ってきたのが標準品で済んでしまう場合もある。

もうひとつの例では、お客さんからのクレームをどう受けて返すかがある。クレームといっても単なる苦情から、壊れたから直してくれという依頼とか、返品、部品の交換などいろいろなケースがある。それらをそのまま聞き入れてしまうと、全部異なったプロセスで処理するという大変なことになる。

大事なのは前にも言ったことがあるのだが、分類学－定義力－整理術ということになるのだが、いささか抽象的なので噛み砕いて言うと、要するに顧客要求をいくつかの種類に分け、それぞれで定義をし、案件ごとに収納するということになる。上の例で言うと、クレームの種類にはどんなものがあるかを考える。切り口をどうするかである。

例えば、有償か無償かとか、モノが動くのか動かないのか、クレームなのか通常の修理サービスなのか、正常品に対するものなのか不良品に対するものなのかなど対立概念を持ってきてまず二つに分けるというのが現実的であろう。この際に考慮するのは、受付けた後のプロセスの類似性をみて括り方を決めることをする。

このケースで私だったらどうするかというと、クレームが不良品に対するものかそうでないかで最初に交通整理をします。正常品でも、マニュアルが不備だとか、問合せの返事が遅いっだとかといった苦情や、単に返品したいとか、通常の有償サービスを受けたいといったものがあります。これらと納品したものに欠陥があったとか、使ったらうまく動かなかったとか、普通に使ったのに壊れたとかいうクレームがありますが、それを最初に区分してしまうのです。

後者の方は、欠陥の具合などから今後の設計変更を行うとか、明らかに前者と違うプロセスを経ることになるのでそうしたわけです。このようにして、要求をきちんと整理して確定してから、後のプロセスにエスカレーションすることが大事だということです。とうことで、顧客の要求をそのまま信じるのではなく別の角度からよく吟味すること、要求を分類して後のプロセスが冗長的にならないようにすることが非常に重要なのである。意外と見逃しているところでもあり注意したいものだ。
　　

ここからは以前、書評で紹介した清水博さんの著書「生命を捉えなおす」（中公新書）から、ITと関連深い概念についてみていこうと思う。この本に書かれているのは生命とは何か、生きていることは何かであるが、それはものずごく普遍的なことで、生命も企業活動も生きていて、それの全体がシステムであると言えるので同じように考査してみようと思うのである。

まずは、「分ける」と「分かる」ということです。分析を意味する「分ける」という言葉は「分かる」から来ています。近代科学では分析することが何かが分かる手段でした。できごと全体を要素にまで分解して、これこれがこれこれの原因であるという風にして、因果関係をつけることをします。これで何となく分かったような気になるわけです。

ところが、「生きていること」の自然科学的な原理については、このように分析しても、なかなか浮かびあがって来ないのです。ここで生きているという状態を考える前に逆に生きていない状態とはどういうことかを考えてみます。生きていない系の運動は各要素が勝手にランダムな運動をしていることが特徴なのだという。非生物が自発的には動かないように見えるのは、その構成要素のランダム運動が、互いに相殺しあって運動として外に現れないからだ。生きていない状態というのは要素の無秩序な運動状態というわけである。

従って、生きているということは、秩序の高い運動が自発的に出現している状態をいうのである。それには構成要素の運動そのものに何らかの形で秩序が出現している必要がある。このことを踏まえて情報システムのことを考えてみよう。企業のビジネス活動において、生きている状態、すなわち「秩序の高い運動が自発的に出現している状態」が望まれるとすると、業務システムもその状態を継続的に維持できる仕組みと仕掛けがなくてはいけない。

企業体を生物であると見立てたとき、各要素である構成員が勝手にばらばらに動いて、それが相殺し合うような状態だと死んだ会社といえる。そうした会社があるのはわかりますよね。おそらくつぶれてしまうのだと思います。その反対に、構成員がみな目的に向かって秩序よろしく行動しているような会社は優良会社と言えるのではないでしょうか。

秩序を保つには皆がめざすべき目的がちゃんとあるということが大事なのである。少し極端かもしれませんが分かりやすい例でいうと、デパートの人ごみのなかで平静に買い物をしているときはランダム行動ですが、誰かが「火事だ！」と叫んだら、皆一斉に階段に向かって動き出します。これはある意味秩序だった運動なのです。

業務システムの話にいくと、そのシステムに参加する人が勝手に動いてもらっても困るわけで、そのためにもどこをめがけて参加者が動いているのかが分かるようにしなくてはいけません。おそらく、既成のシステムではそんなことは考えていないだろうと思います。ERPにデータを打ち込んでいるとき何のためにこうした行動をとっているのかなんて考えませんよね。

つまり、「死んだシステム」になっているのではないでしょうか。冒頭に言ったように一生懸命分けてみて、分かったようなつもりになっているということも同様に「生きたビジネス」を捉えていないような気がするのである。

次はマクロとミクロの話です。前回、全体を要素にまで分解してみても分かったことにはならないという話があったと思いますが、その観察の対象物（系）のことをマクロと言い、それに対して、その構成要素をミクロと呼んでいます。「生きている」というグローバルな性質はマクロな性質でです。

先走って言うと、このことからも、生きた情報システムはマクロのレベルが非常に大事になるのです。どうも、これまでの情報システムはミクロの構成要素にばかりに目がいっていたのではないでしょうか。ただそうは言っても、マクロはミクロで構成されているわけですから、マクロな性質が構成要素によってどのように決まるかを考えていく必要があります。

このとき、注意しなくてはいけないのが、どういう物差しを持って見るかということがあります。例えば、どこかの雑誌に老いた女のひとと若い女性の写真があったとします。それを顕微鏡でのぞけば繊維のかたまりかもしれません。また、遠くから眺めると、人間と動物の違いは分かるとしても、老齢のの女性か妙齢の女性かはこれまた判断がつかないのです。

つまり、適当な尺度で見ないと本当のことは分からないと言うことである。情報という世界でもそういうことがあって、情報があり過ぎるということは、情報の山の中から、「欲しい情報を選び出さなければならない」ことを意味していて、「欲しい情報を選び出さなければならない」という状態は、結局は情報が足りないという状態と同じことなのです。

このことって、考えさせられますよね。卑近な例で言うと、最近ビックデータという言葉がはやっているが、どうも情報を見るための尺度がちゃんとしていないのに情報の山を提示してもだいじょうぶなのかと思ってしまう。何もビックデータではなく、スモールデータでも同じで、情報を選ぶ物差しがなかったら、ビックであれスモールであれ有用な情報を取得できないのである。

また、尺度というのは目的で違ってくる。要素のふるまいを見たいのか、集団のふるまいを見たいのかで、観測の尺度が違ってくるわけです。これを会社の組織という系で考えてみると、大胆な見方をしてみると、個人と組織という区分けになるかもしれない。

ですから、どういう視点で見たいのかという目的に応じて観測の尺度を変えていくことになります。各要素の中味に深く切り込む微視的アプローチはよくやられていてそれなりに重要なのですが、粗視化していくことも同様程度に重要なのである。「木を見て森を見ない」状況にはならないように気をつけたいものである。

これまでの情報システムの作りは、ここでいう構成要素であるミクロの領域での議論が盛んで、森を見るという意識が薄かったように思われます。それは昔からIT側の視点がシステム開発の現場で支配的だったからだと思う。つまり、構成要素でしか過ぎないITが表に出過ぎていて全体の系に対してシステム的にどうするのかというマクロ視点が欠けていたのではないでしょうか。

マクロというとつい上流設計のことを思い浮かぶ人が多いと思いますが、ビジネス戦略的な見方というのではなく、システム構造を見渡せる俯瞰力のことを言っています。構造化するということはこのことで日本人の弱いことのひとつはここだと思うのですがいかがでしょうか？
　　

前回、マクロとミクロの話として観察の対象物（系）のことをマクロと言い、それに対して、その構成要素をミクロと呼ぶとしました。そして、ものを見る時、適当な尺度で見ないと何がどうなっているのかが分からないということを言いました。今回は、マクロの系の状態というものを見ていきます。また、生きていることはどういうことかも考えてみます。

ここで、構成要素が規則正しい配列になっているマクロの状態と配列が乱れたマクロの状態を考えます。あるマクロの状態が乱雑なほどその中のミクロな状態をたくさん含むことになります。そうすると、秩序の高い低いを、その状態に属しているミクロの数が少ないか多いかによって表現することもできます。そして、無秩序さが大きくなる傾向があり、それを「エントロピー増大則」というのです。

これを組織にあてはめると人数が多ければ多いほど秩序が乱れる方に向かうわけです。業務でいえば、例外とか個別処理とかが多くなるとその業務プロセスが不安定になるのです。ですからできるだけミクロの構成要素を少なくする、すなわち標準化、共通化、あるいはコンポーネント化していくことが大事になるわけです。

さて、自然界には、エントロピーが増えることによる自由度増大の傾向と内部エネルギーの減少による安定度の増大の傾向が見られます。従って、秩序ができるのは、自由度の要求と安定度の要求の二つのうち、安定度の要求が勝った場合です。例えば低温で結晶が規則正しい形態をとるような場合があります。こうしたメカニズムによってでてきる秩序が「静的秩序」となります。

一方で、多種多様な生命現象に共通的な特徴は何かと考えてみた結果、多くの生物学者の意見は「それはマクロな系に秩序（生物学的）が自発的に出現することである」だという。こうした、生体の形態にみられるような秩序を動的秩序と呼ぶ。

ここでまとめると、生きている状態は、特定の分子や要素があるからというわけではなくて、多くの分子や要素の集合体（マクロな系）が持つグローバルな状態（相）であり、生きている状態にある系は、高い秩序を自ら発現し、それを維持する能力を持っているということになります。

ここにおいても、会社の業務やその情報システムにヒントを与えてくれます。“高い秩序を自ら発現し”というところに惹かれます。つまり、動的秩序、あるいは動的な平衡が保たれてこそ生きた状態なのだから、システム的にもこの生きた状態を作れるかどうかでシステムの本当の価値が生まれるわけです。

現在の情報システムは、見た目は動的になっているように見えますが、フィードバックループが働いていないという点だけとっても静的な域を出ていません。状況に応じて柔軟に変化できるようなシステムが望まれるのですが難しいですね。
　　

前回「生きている状態は、特定の分子や要素があるからというわけではなくて、多くの分子や要素の集合体（マクロな系）が持つグローバルな状態（相）であり、生きている状態にある系は、高い秩序を自ら発現し、それを維持する能力を持っている」という話をしました。ただ、エントロピーなどが出てきて難しくなるので、ここからは秩序の自己形成系と情報ということを考えていきます。

清水先生は、生きた自然はエネルギーではなく情報によって支配されていると言っています。系が生きているからこそ情報という量が必要になってくるのであって、生命に関係ない統計的な系に情報の量を使う行き方は必然性がないのだという。こんなことは考えてもいなかったのでちょっと驚きである。自然科学の世界に価値観とか美意識といった要素を持った情報はなじまないと思うが、生きたものとして扱うにはこの概念を入れ込む必要がありそうなのである。

このことは、人間の活動をも含めた自然を理解するにはここはどうしても通らなければいけない橋なのだという。そのために情報という量の本質をはっきりさせる必要がある。前回、マクロとミクロの話をしましたが、情報というのは、粗視化していることに相当するマクロな状態の中から、逆に、ミクロな状態を指定するものなので、情報に従って、ミクロな状況を選ぶことは微視化してモノを見るということになる。

またエントロピーが出てきて恐縮ですが、情報をもらうということはマイナスのエントロピーをもらうことであると考えていいわけです。エントロピーの増大は秩序を乱すことだから、情報は秩序を与える方に作用するのである。

このように、マクロな眼とミクロな眼の行き来により森を見たり木を見たりするには「情報」というものが媒介しているということが分かる。言い換えれば、マクロとミクロという相とその構成要素という構造としてモノを見るということが必要ということでもある。このことは、生きた情報システムの構造にも当てはまるような気がするのである。

マクロ的な業務の流れがあって、これがビジネス活動を表現していて、そこでは細かなアクションは見えていないが、全体としてどう進んでいるかを捉えることができる。それを、眼を細めてみるとマクロを構成するミクロとしての要素が見えてきて、それは情報、例えば依頼情報とか前提情報とか事実情報とかいったものが介在して、その状況をつかむことができる。

プロセス志向のアプローチで盛んに言っている2段プロセスというのはこの概念に近いのである。企業あるいは組織という生命体はマクロ的な視点で眺めることで生きているのか死んでいるのかが分かるのであって、データを登録するとかの個人のタスクレベルでは分からないのである。ですから、マクロとミクロという概念は非常に重要なのである。
　　

しばらく「生命を捉えなおす」から考えるというシリーズで書いてきたが、一旦ちょっと休んで別の話題で書いてみようと思う。業務システムの実装ということについて考えてみたい。これまでは要件定義に従ってプログラミングをして作り上げるケースが多かったが徐々にできあがった業務アプリケーションが出てきて、一部はわざわざコードを書かないでもよいということが起こってきた。

このことはすごくよいことで、何がよいかというともちろんプログラミング工程がはぶけるということもあるが、大きいのはシステムの品質が確保されていることだと思う。つまり、製作時のテストも入念にできるし、多くのユーザーに使われることでバグ出しなどの不具合の修正が終わっているから安心して使える。スクラッチで開発したものは、時間に追われることもありテストや手戻りで大変である。

ですから、究極には業務システムをそうした個別アプリを組み合わせて、あるいは機能付加して組み上げて作れるとうれしいのだ。ノンプログラミング開発であるが、プログラミングの自動生成ではなく、むしろプログレスシステム構築と言った方がよい。開発という意味合いより構築である。DevelopmentではなくConstruction とかAssemblingという感じである。

この流れの行き先は業務アプリケーションの家電化だと思うのですがいかがでしょうか。ただし、単純なデバイス的な意味だけではなく幅広くとらえています。例えば、家電というのは、快適な家庭生活を送るために必要に応じて、あるいは経済的な事情も加味して買っていくわけです。そして何よりも自分たちのライフスタイルにあったものを選択していきます。

その時、自分たちのライフスタイルを、そして使いたい家電をコンサルタントを頼んで設計するでしょうか。それと同じように企業経営、事業運営も自分たちで決めてその結果としてのビジネススタイルを実現するための電化製品を買うという風にならないのかと言っているわけです。

ですから、ビジネスにおける洗濯機、掃除機、テレビ、冷蔵庫は何なのかを考えてみたいのです。家具とかインテリアとは違う家電なのです。ある特定の活動を助けてくれるものを家電と呼んでいるのです。例えば、汚れたものを洗うという洗濯機に相当するのがクレーム処理アプリであったりする。

家電化と言っていることで大事なことは何かというと、使える道具、使われる道具から選択するということがある。つまり、家庭で買う家電は使ってみたら不具合があったとか、想像していたものと違ったということはほとんどないから、ムダな費用が発生しない、だいたい期待通りの効果があげられる。

では、今の業務システムはどうなのかと考えると、多くのシステム開発における成果物が実運用にさらされた時に使えないあるいは使ってもらえないという結果になっているという報告がなされている。それは、家庭でいえば、家の中のゴミを取ってくれる道具を作ってくださいと頼んで、何ヶ月か経って掃除機という装置が届いたが、使ってみたら大きなゴミはいいが小さいゴミがとれなかったといったような話なのである。

家庭の世界ではそんなことはあり得ないわけで、企業とか業務システムの世界でも家電のように出来合いのものをさっと持ってきて、取扱説明書もろくに読まなくてもコンセントに差し込む（ダウンロード）とすぐに使えるようになってほしいと思うのである。

クラウドのめざすところはそこではないかと思うのである。そのとき忘れてはいけないのはユーザに使ってもらえるものを作ってそれをクラウドに置いておくということで、従来のようにシステム屋がはいこんなものを作りましたよではダメなので、そこの発想を転換しなくてはいけないのだ。
　　

最近、いわゆるSIerと呼ばれる業態がヤバそうだという話が聞こえてくる。富士通の3万人のSE職の転換とかが話題になった。おそらくどこのSIerも相当の危機感を抱いているのちがいない。従って、そこで働いているエンジニアのかたがたもこれからの行く末に悩んでおられると思う。

そこでちょっと旧聞に属する話で恐縮なのですが、いくつかのブログ記事についてコメントしておきたいと思う。流しておけばいいのだが、どうも根本的なところで勘違いしているようで気になっていたのであえて取り上げておくことにする。まずは、GoTheDistanceさんの「｢SIerでのキャリアパスを考える｣というイベントに登壇しました」というエントリーで（別に個人的にどうのというのではなく一般論として取り上げてみたのである、湯本君ゴメン）、そこでのプレゼン資料を公開され、その解説が書いてある。

最初の問題提起として、「僕が常々問題にしているのは「上流工程と下流工程が分断されていること」です」と言っている。そして、その工程を分断させないためには、アジャイルでありプログラミングファーストなのだが、それらの開発手法を現実のものにするのは大変難しく、その理由が人月見積もりにあるとのこと。どうも問題の設定と組み立てがおかしいと思うのである。じゃあ、人月見積ではなくて一括請負とか成功報酬契約とかすれば解決するのだろうか。

この上流と下流との分断については、小野和俊さんも中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーを持ちだして同じようなことを言っている。ここのところは重要なのでその中島さんの有名なエントリーの文章を見てみましょう。こう書いてあります。

プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューする のは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。もちろん、レストランに行く側の立場になってみ れば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理 したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。

ぼくはこの意見には与しません。「エル・ブリの秘密　世界一予約のとれないレストラン」という映画をご存じだろうか。まだ、上映しているというからロングランが続いている。エル・ブリというのはスペインにある小さなレストランであるが、毎年多くの人が予約したがるがなかなか予約ができないという大変な繁盛店です。

そこのシェフがフェラン・アドリアで、この人の創作する料理が出されますが、彼はいっさい調理をしません。料理のアイデアは出しますが、実際に作るのは別の調理人がするわけです。つまり、上流と下流は分断されています。シェフがレシピだけ書いてキッチンにも立たないレストランなのです。フェランは言います。おいしさより驚きだと。

お客さんがああ楽しかった、こんな体験ができてうれしかったといった感動を与えるような料理を作るには上流も下流も意識する必要がないと言っているのではないだろうか。この話からちょっと角度を変えてみてみると、エンタープライズ系の業務システムというのは料理なのかどうかという問題があります。この話は次回に。
　

昨日は午後から東京に出ていたので、時ならぬ嵐でまた帰宅難民になるのかと思ってしまった。日暮里で呑んで嵐をやり過ごしてから、東京駅に行くと電車はだいぶ遅れてはいたが動いていてほっとする。さて昨日のエントリーの続きです。

ぼくは最近、昼メシを自分で料理することにしている。同じ敷地にある家に住んでいたぼくの母親が老人ホームに入ったので台所が使えるようになったからである。以前から昼メシは自分で何とかしてくれとヨメさんに言われているので外食していたのだが、自分で作ることにした。

なぜこんなことを書くかというと、別に他人が書いたレシピでも作れるということを言いたかったのだ。実際によく利用するのはクックパッドなのだが、そこから自分の好きな料理、あるいは手持ちの材料をどう使ったらいいのかなどの情報を得る。そして、適当なレシピを印刷して脇に置きながら作るのである。自分で言うのも何なのだが、まあまあのものができあがる。

さて、ここで問題を整理してみよう。仕様を書くのがレシピでプログラミングが調理だという話になっている。料理ではレシピを見ながら料理だってできるし、フェラン・アドリアのようにレシピは作るが調理をしないというやりかたもある。ただ、業務システムが料理なのかというとどうも違うように思えるのだ。

多くの人が混同するのだが、ITという括りであたかも同じように語られるのが、業務システムの開発とソフトウエアの開発である。営業システムとか生産システムといったものが業務システムで、MSのオフィス製品だとか、DBMSだとか、パッケージのようなものがソフトウエアとすると、それぞれを開発するやり方は違うと思いませんか。

ということで、前回の議論で言っている上流・下流分断論とか、料理をしないでレシピだけ書いている料理人はプログラムもできないのに仕様書を書いているエンジニアと同じ論にしても、何のためのプログラムを書いている時の話なのだろうか。業務システムなのかソフトウエアなのかである。

ソフトウエアを作るときのことであれば言わんとすることはわかる。なぜならプログラムを書くからである。しかしながら、もしそうであったらフェラン・アドリアのように分断されてもいいと思うし、ましておやジョブズのようにコードを書くわけではないがある意味立派な仕様書を書いているに等しい。つまり、プログラム仕様書なんてさして重要ではないのだ。コードをどう書くかではなく、どんな商品にしてどんな使われ方に対応できるかといったユーザ目線でのスペックが重要だからである。

そもそも、プログラム仕様書を書くのが上流でコードを書くのが下流というのもおかしいと言えばおかしい。本当の上流というのはもうちょっと上のレベルでどんなものをつくるのか、何ができるのか、こんな風に使ってほしいといったことをデザインすることだと思う。そこでデザインされたものを作りだすためのプログラム仕様書作成からプログラミングはプログラマーの仕事にしたらよい。だから、分断される箇所を変える必要があり、そうすることでプログラマーの地位も向上するのではないでしょうか。

では、業務システムのほうはどうなってしまうのだろうか。それについては次回。

さくらが満開だ。家の近くは桜の名所なので多くの人がハイキングがてら見物に来る。今日は天気もいいので絶好のお花見日和のようだ。ただ、桜も寿命があってこのあたりの木は老齢化してきて毎年少しづつ花の数が減ってきているのがさびしい。

さて、このシリーズちょっと間があきましたが続きです。先週末もあるソフトウエアベンダーさんと話をしていましたが、ユーザさんも含めて少しづつ現状のITの問題に気づいてきているようで、方向としては使う人が主導する、あるいは自分たちで作ってしまう形の進め方になっているように感じられた。

前回、上流と下流の分断の問題をソフトウエア開発のケースで論じたので、今回は業務システム開発のエリアの話をしましょう。まずは、業務システム開発とソフトウエア開発とでは明確に違うということを指摘したいと思う。大きな違いは、プロダクトアウトかそうでないかです。

業務システムというのは、特定のユーザの特定の要求により、その要求に答えるようにシステム構築を行います。一方、ソフトウエアというのは、不特定多数の想定ユーザために作り手側で要件を決めてプロダクトをあらかじめ作ってそれを売るということをします。だから、極論するとソフトウエアは使われなくてもいいというか、勝手に作ってしまうわけですが、業務システムは使われなったら意味がありません。また、ソフトウエアは自分たちがこうしたいというものを作るから当然コードを書かなくてはできません。

世の中この違いをあまり理解していないのではないでしょうか。もしちゃんとわかっているなら、なぜ業務システムでいつも特定のユーザの特定の要求に対して特定のコードを書くのでしょうか。まるで料理を作るその時に、醤油や味噌を一から作り出していつように思えてなりません。おそらくこの瞬間でも世界中で同じコードを多くのプログラマーが書いているのないででしょうか。だから人月の罠にはまるわけである。

なぜ、“コードはソフトウエアを作る時に書いて、業務システムはそのソフトウエアを使って組み上げる“ことができないのでしょうか。プログラマーは、役に立つ魅力あるソフトウエア（ツール）を産み出すことに自分のスキル、意欲を傾注したらいい。そして業務システムを作る人は、業務プロセス、仕事スタイルをデザインできる人がすればいい。後者こそ本来のSIerのめざすところではないでしょうか。こうすればユーザ自身に作らすことも可能になる。GoTheDistanceさんがブログの最後にこう言っています。

一番大切なことは「自分が使っていて楽しい、自分が作っていて楽しい」そういうサービスなりシステムなりに触れて、どのような問題解決をITで行うことが自己実現に繋がるのかを見いだすことだと思います。

これを誰に対して言っているかです。ここには前に言った混在があります。すなわち、「自分が使っていて楽しい、自分が作っていて楽しい」そういうサービスなりシステムを作るのは、プロダクトデザイナーとプログラマーです。どのような問題解決をITで行うことが自己実現に繋がるのかを見い出しお客さんに提示するのがSIエンジニア（ビジネスエンジニア）ではないでしょうか。

実はこの混同はソフトウエアベンダーにもあります。その象徴的な例として、BPMツールのことを言うと、BPMツールがなかなか売れていないのですが、その理由はソフトウエアを買うところとBPMを買うところが違うのです。つまり、ソフトウエアというのはあくまでシステム開発のフェーズで使うものとして捉えられるのでどちらかというと企業では情報システム部門が対象になります。

しかしながら、BPMはそうではなくて現実のビジネスに貢献できるよう業務システムをどう構築するのか、それをどうオペレーションしていくかが大事なので、当然のように事業部などの現業へのアプローチが必要になるわけです。ここは、システムの作り方も売り方も違っているわけです。

要するに、上流・下流の分断の問題ではなく、最大の問題はIT業界全体が顧客ニーズがわかっていないということに尽きます。顧客の定義さえできていないし、提供すべき商材の意味も理解していないから、ユーザが欲しくないものも一から作りだして結局使われない。それではそこで働く人たちにとって何のために自分のスキルが活かされているのかが見えない悲劇であるということになります。そこにはそもそもITとは何かという根源的な問題も潜んでいるように思えます。この話はまた次回に。
　　

この話は最後になります。これまで上流・下流の分断の話が、ソフトウエアの開発と業務システムの構築の混同により、議論がちぐはぐになっていることを指摘した。つまり、業務システムを作る商売をしているSIerがソフトウエアを作ることと勘違いして、相変わらず業務システムのためにプロジェクトごとにコードを書いていること、ソフトウエアのようなプロダクトアウトの発想であること、また顧客ニーズをわかっていないことのために起こっている問題なのであって、まずはそこの勘違いを正すことではないでしょうか。

そもそも業務システム“開発”というところで間違っているのである。業務システムは開発するものではありません。ITが無くても業務システムは厳然として存在するわけです。もちろんIT化プロジェクトで新たに業務システムを開発することもありますが、それはIT化とは別の問題です。ですから、開発された業務システムを効率的に、円滑に動かす仕組みを”構築”するというのが正しいのではないでしょうか。

要するに、ITは何かという根源的な問いに対する答えがこんなところにもあるように思います。これは、何も業務システムやビジネス向けに限ったことではなく、ソフトウエアやコンシューマ向けアプリにも当てはまるはずです。さて、ここでスティーブ・ジョブズにご登場願おう。

僕にとってのコンピュータは、人間が考えついた最も素晴らしい道具なんだ。それは知性にとっての自転車に相当するものだ。 　　　 　　　　　　　　　　　　　　　　　　　　　　　－Steven Paul Jobs－

さて、この言葉もう一度かみしめてみるとおもしろい。自転車を作る人と自転車に乗る人を考える。みなさんもうお分かりだと思いますが、自転車をつくる人、つまり機能や構造をデザインしてそれを製作する人がソフトウエアエンジニアでありプログラマーです。その自転車に乗ってどんなライフスタイルを実行するのか、どんな仕事をするのかをデザインしてスタイルを確立するのがユーザ自身であり、それをサポートするSIエンジニアでありビジネスエンジニアです。

さて、SIerにいるエンジニアのみなさん、あなたはどちらのエンジニアをめざしますか？と言ったところで、こうしたキャリアパスがないので無理なことを言うなという声が聞こえてきそうです。ですから早急に作ってもらいたいと思いますが、そのためのビジネスモデルの変革や制度設計ができていないのが大問題ですね。

どうしたらよいかは、地道だがユーザの声を徐々に反映し、大きな流れにしていくということだと思う。これだけビジネス環境の急激な変化やグローバル化の嵐にさらされている企業はすでに声をあげ始めています。もちろん大前提は、供給側が顧客ニーズを吸い上げた本当にビジネスに貢献する、日常の仕事に役に立つ業務システムを少しづつでいいから提供し続けて、それができるエンジニアを増やすといった対応を行っていくことなのだろう。

だから、大事なのは問題解決型にしろ、仮説検証型にしろ、問題と仮説の設定がすべてといっても過言ではない。そこを間違わないようにしよう。従来の延長で考えるのをやめよう。実は、問題や仮説はそのときの置かれている環境に大きく左右される。時代はものすごいスピードで変化している。そういう意味ではWebの世界に較べて業務システムのエリアの硬直化は目を覆うばかりだ。若い人がなぜそれに気づかないのだろうか。そこに日本のITの未来はある。
　　

クラウドがもてはやされている。バズワードに近いと思うのだが世の中こぞってクラウドだと言っている。IT業界は、何でもいいからはやりの言葉を作って、ユーザーを煽りたてて売り込むことを絶えずやり続けるという商法だからまたぞろ出てきたなと思う。ただ、そうは言っても新たな変化ももたらしていることは確かだから、きちんと評価して必要なものは採り入れるようにしたほうがいい。

そのとき、自分の立ち位置として業務システムにとってクラウドとは何なのかという視点があるので、「クラウド時代の業務システム」というテーマで書いていくことにする。おそらく、GoogleやAmazon、SalesForceなどからの切りこむのはよくやられるのだが、一般的な企業の業務システムについての論及はほとんどないので議論してみたい。

まずはクラウドとは何かをみていくことにします。小池良次さんの「クラウドの未来」（講談社現代新書）では、“脱パソコン時のビジネスモデル”という定義をしているが、ビジネスモデルと言った途端にメーカーとかメディアの視点になってしまうので、ユーザサイドというか利用する立場で考える。

簡単には、「インターネットの向こう側にあるサービスを使い、サービス利用料金を払う形態のこと」になる。従来のコンピュータ利用は、ユーザー（企業、個人など）がコンピュータのハードウェア、ソフトウェア、データなどを、自分自身で保有・管理していたのに対し、クラウドコンピューティングではそうしたものは保有せずにただ利用するだけになる。

サービスには、よく言われるSaaS、PaaS、IaaSなどがある。すなわち、ソフトウエアやアプリケーション、運用環境や開発環境、そしてインフラやハードウエアなどである。これらはデータセンターの中に置かれていてみなで共有して使うことになる。多くのユーザでシェアすることになるのでコストダウンにつながる。やはり、このメリットが一番大きいと思う。

コンピュータの利用形態の大きな流れとしては、メインフレームを中心にしたホスト集中型からPCの出現によるクライアントサーバー分散型へ移行し、インターネットの登場によるネットワーキングの時代になり、こうしてクラウドという小池良次さんによれば、“超集中と超分散”の形態へと変化したことになる。

こうしてみると、集中と分散を繰り返していることになる。だから、そこは変わらないわけだから、クラウドが全く新しい画期的なものであるというわけではない。個別単体的なものから広範なネットワーク的なものへと集中と分散が変化したことがわかる。ただそれも急にやってきたものではなく、例えばデータセンターなんて以前からあったものだし、ASP（Application　Service　Provider）という形態もあったし、ネットワークコンピューティングとかユーティリティコンピューティングといった言われ方もしてきた。

ということは何がクラウドなのかよくわからないのである。結局、これまで断片的にあるいは段階的にこうあってほしい、こんなことができたらいいなあと考えてきたことが技術の進歩があって現実のものになってきたということかもしれない。次回はもう少し従来からの進化を議論してみます。

前回、クラウドは従来からの願望が技術の進歩によって実現されたということを指摘した。ではその技術とは何なのか。クラウド自体はコンピュータの利用形態だから、新しい技術というわけではない。つまり、新しい利用形態を可能にした技術は何かということになるが、標準インターネットプロトコルと仮想化されたサーバー運用技術ではないだろうか。

当たり前のようになったインターネットだが、当たり前になったことがすごいことだと思う。昔は、独自の仕様のものばかりで互換性のない専用技術しかなかったのだ。そういった意味では、ネットワーク以外でもハード、ソフトともに標準化が進んできた。そして、ユーザー数や処理量の増減に対応できる仮想化技術はクラウドにとっては大きなインパクトを与えたのではないだろうか。

クラウドでは不特定多数のユーザがある意味勝手気ままに使ったり、やめたりするわけだから、負荷の変動は激しく、柔軟性を持ったスケーラビリティが求められる。うちの会社でも、アマゾンEC2とかLinodeといったサービスを利用しているが、使用申請したり、停止したりが簡単にできる。それが、世界中で行われているから変動は半端じゃない頻度で起きてくる。これができるようになって飛躍的にユーザビリティが向上したし、クラウドの価値がここにある。

だから、パブリッククラウドとプライベートクラウドの大きな違いはここにあって、プライベートクラウドは本当にクラウドなのだろうかと思うのである。結局、煎じつめると標準化されたインターネット技術と仮想化技術のおかげでクラウドという利用形態が現実的なものになったのではないだろうか。

もちろんそれだけではなく、他にあげるとすると様々なデバイスの登場もクラウド化を後押ししていると思うが、案外忘れてはいけないのに“課金モデル“があるように思う。利用させるということは利用料を徴収しないと意味がないのは言うまでもないが、しかも頻繁に使用停止やスケールアップダウンを繰り返される中できちんと課金するシステムは必須であるからである。

さて、ここまでは技術的な進歩がクラウドコンピューティングの到来を促したことを指摘しましたが、どちらかというとパフォーマンスの圧倒的な向上がもたらしたもので、利用形態という意味ではまるで違ったものが登場したわけではない。では、クラウド以前にあったデータセンター、ネットワークコンピューティング、ASP（Application　Service　Provider）などとどう違うのかみてみましょう。

基本的な構造とか形態は変わりないと思うのですが、まずはほとんどがプライベート利用でした。データセンターと言っても、ホスティングというか、自社のマシンを預かってもらうということが主だったもので、謳い文句的には、複数のユーザでシェアするからコストダウンが図れると言われても、知らない会社と相乗りなんかいやだとなって単独で置いておくことがなされていました。まあ、それでもインフラや運用リソースは共用できるのでそれなりの効果はありました。

もうひとつ、これから業務システムの話に入っていきますが、その時に注目すべきはASPのことです。ASPという言葉が出てきたのは2000年頃だったと思いますが、あまり世の中では知られていなかったし、実際にやられたところもあったかなかったというくらいでした。このASPは結局業務パッケージの共同利用みたいな形になっていきましたが、SaaSの登場までは表に出てきませんでした。ただASPという考え方は業務システムのクラウド化にとって重要なものですので次回議論していきます。