mark-wada blog

ビジネスプロセスと一括りで言っているが、実はいくつかの種類があることがわかる。大きくは次の３つになると思っている。

１） マネジメントプロセス（経営プロセス）
2） クリエーションプロセス（創造プロセス）
3） オペレーションプロセス（作業プロセス）

それぞれプロセスの持つ機能や形態が違う。

マネジメントプロセスというのは、経営判断や事業運営のプロセスになるが、あとの二つに比べるとフロー的な意味合いが薄い。これは、個人の意思決定が大きなウエートを占めることになる。すなわち、社長や事業部長が判断を下すプロセスである。

このプロセスで重要なのは、データ分析とプロフェッショナルサービスである。重要な決定では起こったこと、今起こっていることの事実をどう読むかということが大事である。恣意ではなく客観的な判断はデータをきちんと分析できるところから発せられる。

同時にその時、専門家にチェックしてもらうことも大切なことである。専門家というのは、法務や財務、最近では環境なんかもそうかもしれないし、コンプライアンス委員会のような組織かもしれない。

２）のクリエーションプロセスというのは、ちょっと前にも書評でも書いてあるように、創造のためのプロセスがある。このプロセスは大まかに言うと、ビジョンやコンセプトを考え、デザインする上流と実証してビジネスモデルをつくりオペレーションするという下流からなる。

このプロセスはあとのオペレーションプロセスと違って、課題が設定されているわけではないので、仮説検証型のプロセスになる。従って、ここで求められるスキルはコンセプト形成能力や仮説設定能力のように創造性のある力が必要になる。

最後のオペレーションプロセスすなわち作業を実行していくプロセスは問題解決型のプロセスで、課題が与えられ、それに応えるようなプロセスである。このプロセスが意思決定の連鎖で成り立つのである。

こうしてみるとタイプの違うプロセスがあって、それぞれに大事な役目があり、バランスよく機能させることが企業運営の要諦である。会社によっては、各プロセスで強弱があると思うので一度点検してみるとよいかもしれません。

こう書くと、IT投資をしてそれによってどんな効果があるのかということを言っているけど、もう少し考えてみると、根本的な問題として、何のためにIT投資をしたのかが微妙に抜けているように思う。

だから、別の言い方をすると、IT側の要請で投資することがあるのかという問いにぶつかる。そこで、少し歴史的にどうだったかを見てみることにする。ぼくは、そんなに詳しいわけではないが、ユーザ側にいて見ていたという立場からIT投資について書く。

まず最初のIT投資は、電子計算機という呼称からもわかるように、省人化というか、人間のやることを代替するという役割があったと思う。人間がやると時間やコストがかかるので、機械化し、自動化することで人を減らせるということである。だから、人件費削減が投資効果である。一人減らすなら2500万円かけてもいいなんて言われた。

ところが、やってきたのが経済成長である。この波に乗っていくには働き手の頭数が必要になってくる。成長の機会があるのにリソース不足でそのチャンスを逃すというような事態である。

その不足人材を補うために盛んにIT化が進められたのである。ここでは人員削減ではなく逆に人員ねん出のための投資になった。だから、まるまる一人減らなくても、省力化できればよしとした。これは、事業拡大によるメリットが大きいため、採算性もそこに組み込まれたりして大いに投資が促進された。

ところが、1990年代後半から成長は鈍化し、成熟された社会もっといえば停滞した社会へと変わっていった。そんなとき、省人化、省力化と唱えたところで誰も同意はしなくなったのである。もちろん、すでにかなりの人的合理化は進んでいたから、更にというのが難しかった側面はあるが、明らかにROIが確保できる投資は減った。

ところが、既成のITベンダーはまだこの亡霊にしがみついたりしていて、あり得ない提案をしているのではないだろうか。あるいは、情報システム部門も自分たちの存在意義を失いたくないがゆえにむなしいIT投資要求をしていたのではないだろうか。

では、いまの時代に必要なことは何なのだろうか？

ぼくは、「新しいあるいは変革されたビジネスモデルをITを使ったために、早く適確に実現させることできたというメリット」をめざすべきだと思うのである。ITがなかったら、俊敏に新しいビジネスモデルに対応した業務プロセスをオペレーションできないと思うからである。

ですから、変革をめざしたビジネスモデルをいち早く市場に投入して効果を上げるためにIT（業務システム）があるということをきちんと認識し、そのための投資を要求すべきなのだ。それができれば、事業から生まれた収益の何％かのリターンをカウントできることで、投資を正当化できるのではないでしょうか。

少しばかり、自治体の業務について調べていて気がついたのが、当たり前のように企業と同じだなということである。どちらかというと電子申請みたいなことが、自治体のIT化と思われるが、それ以後ににある業務プロセスのことである。

どうも、IT業界の人は業種業態の特殊性を強調するきらいがあって、そこの業務知識がないとシステムは作れないような言い方をする。それって、多分かなり下位レベルの業務プロセスのことを言っていて、業種業態というより属人的な要素が大きいところのことではないでしょうか。あたかも、その業種に特有のことみたいになっているようにみえるが、実は何のことはないその会社独自のやりかたであったり、あるいはその職場に昔からあったしきたりだったりする。

だから、まずは業務プロセスの抽象度を上げて眺めてみるとそうした特異性を排除できるのでだいぶ景色が変わってくる。あるいは、トップダウン的に大きなプロセスから落していってみるという方法でもいい。

で自治体の業務のことである。公共の仕事は一般の企業活動とは異質であるという論には、どこが違っているのかと問うてみたい。企業の活動は、簡単に言えば、製品あるいはサービスを作って、それをお客さんに販売して、売上げを上げ利益を出すことで、その活動のためのマネジメント機能やヒト・モノ・カネなどのリソース管理を行うことである。

基本にあるのは、売りものになる財やサービスである。では、自治体ではそれは何であるのかということになるが、言うまでもなく「住民サービス」であろう。お客さんは住民である。そして売上は税金や保険料になる。

ですから、住民からどんな申請（依頼）があって、その依頼に対して素早く的確に答えてあげるというふうにプロセスを捉え、その結果として保険料や税として賦課し徴収すると考えれば、基本的には企業の事業活動と同じに思えるのだ。

ただ、利益を出すものかどうかという問題があるが、これとて利益を出すように管理するのではないだろうか。もちろん、いっぱい儲けるということではなく赤字にならないように運営し、余剰金は新たなサービスの創出や既存サービスの向上に向けるということではないだろうか。これって、普通の事業活動ですよね。

ここで違うこともあるぞと気づかれたと思いますが、企業では財やサービスを売ってはじめてお金が入ってきますが、公共はまず税という形でお金を召しあげて、それをあとからサービスを提供してあげるというふうに考えられていることです。それは、国や自治体には税の再配分という役割があるからですが、どうもそういう意識が強すぎて、住民が欲していないようなサービスを平気で提供することになってやしないだろうかと思うのである。

昨今の民主党の施策はそんな感じが大いにするのである。ですから、少しだけでもいいから、サービスを提供して、それに対する対価として税や保険をいただいていると考えてみることも必要ではないだろうか。続きはまた。

さて、昨日は自治体業務と一般企業における業務の類似性について考えてみましたが、その自治体業務の構造をみていきましょう。この自治体業務というのは財務とか人事などの内部プロセスを除いた住民との関係が主体の業務の領域のことです。

大きくは、住民記録系、保険・福祉系、税系という3つのカテゴリーに分けることができます。ざっくりとその性格をみると、住民記録というのは台帳管理のことで、言ってみれば顧客マスタ、商品マスタ、取引先マスタといったマスタデータのことです。

保険・福祉系は健康保険や国民年金、介護保険、生活保護といった様々なサービスと主に申請に基づいて提供する業務プロセスです。いわゆる、顧客接点サービスプロセスですね。税は売上を管理する財務会計システムということになります。

以前、プロセス改革モデルということで、価値提供力（コンピテンシー）と組織能力（ケーパビリティ）が縦横で交錯する図を示したことがあると思いますが、ここで言っている業務はこの価値提供力ということになります。

この業務はほんとうに様々なものがあります。例えば、保健・福祉系だけでも400とか500くらいあると思います。もちろん似たようなものもありますが、ほんの少し違ったりしています。ですから、同じようなところは共通化するとかなりパターン化できることがわかります。

そのパターンは、相談－申請受付－入力－審査・調査－決定－印刷－発送といったものになります。これをみてお気づきかと思いますが、「Kailas」でいう業務プロセスのマクロフローパターンとほぼ同じになります。すなわち、依頼が来て、その依頼を受付けて、そのあと意思決定を連鎖させる、すなわち審査・調査・決定ということを行います。その結果を登録・報告のために印刷・発送することになります。

ですから、前回も申し上げたように非常に似通ったプロセスであり、同じように扱えるということがわかると思います。これはマクロのレベルでのプロセスを比較したからであって、もっと細かいところで見てしまうと、それこそ各自治体でみな違うし、人によっても別のやり方があったりします。

標準化や共通化というのは、こうした例外性や属人性を排したレベルで行わなくてはいけないということであり、逆にいえば、そうした適切な抽象度レベルあるいは粒度を設定すれば標準化・共通化できるということも言えるのです。

ところで、自治体業務における組織能力（ケーパビリティ）のほうはいったいどうなっているのでしょうか。この組織の能力というのは、サービス提供プロセスを実行するための組織的な活動の方向を示したり、支援するための資源を提供することなのですが、どうもはっきりしてないように思います。

ここらは、実際の場を知らないので軽々しく断定してはいけないのですが、少なくとも組織目標という機能に対しては弱いように見受けられます。すなわち、企業では、経営方針から、事業戦略があり、それを具体的に実行するための計画や予算が設定されます。

こうした機能は自治体ではどうなっているのでしょうか。予算は上から降ってくるから、方針なんて首長が変わったらすぐ変わるから、しょせん収入は景気に左右されるものだから、といって何も努力していないのではないだろうか。

ですから、システムという面から見ても、住民サービス提供プロセスはかなりイメージがわいて、しかも一般の企業との差異がないことがわかるが、もう一方のケーパビリティ管理がどうなっているのかがよくわからないのだが、公共にもある程度の経営感覚が必要だと思うのでより興味があるところである。

ちょっと前に、畑村洋太郎の「技術の伝え方」という本の紹介をしたかと思いますが、あの中で、技術は伝えるのではなく伝わる場を用意することだというようなことを書いた。そこで、ITを用いてここらあたりをどう設定するのかを考えてみたい。

実際問題として、技術をあるいは経験やノウハウを持っている人に対して、ハイあなたの持っているものを全部書きだして残して下さいと言ったとして、はたしてその通りに書いてくれるだろうか。

そうでなくても例えば、システム開発で要求定義をするときもどうやってユーザの要求を引き出すかが問題になる。よくやるのは、ヒアリングというやつである。教えてくださいというスタンスである。これは一見よさそうだが、ちゃんとした要求獲得には不十分だ。

M&ERPの渡辺和宣さんは、ヒアリングではだめで、インタビューによる要求定義を主唱している。要するに、答えの形をあらかじめ用意しておいて、その空欄を埋める感じで聞いていくわけです。その質問に対して隠れて気がつかなかったものも出てくると言っている。

それと同じように、仕事のやり方やものの決め方などの日常業務の経験やノウハウをどう引き出すかというのも、ただ待っているのではなく少し背中を押してあげるような仕掛けが必要なのである。

ただその場合、うまく形式化できるかという問題があって、どうもそんなにきちんと整理されてはいないのではないでしょうか。むしろ、そんな感じだとか、何だか知らんがとか、何となくこんな時はといった文脈的な理解が必要になると思う。この本にもあったように、“裏図面”というやつだ。それは定式化された表現ではなく、図やコメントとして存在する。

そこでKailasでは、Collaborative Workspaceという概念を提示しているように、経験がない人が行う行為を経験がある人がみているところでやらせるのだ。そして、それぞれの局面でノウハウを発現すべき時がやってきたときに、コメントをするのだ。

そのアドバイスは、現実に起きている場面でその事象に対するコメントだから当たり前のようにぴったりなものになる。こうして、自然と暗黙のうちにしまわれた知が引っ張り出されるというわけである。

実は、このことはコンピュータが登場する前は普通にやられていたのだ。それが、コンピュータが特にパソコンが机の上に置かれだしてから、どんどん仕事を孤立した形でするようになってしまった。ITが技術の伝わり方を阻害してしまったのだ。これを、元に戻そうではありませんか。
　　

Webを支える技術は、HTTP、URI、HTML、そしてRESTということを書いた。このおかげでシンプルで拡張性に優れたWebサービスが作られるようになった。ではこうした技術が企業において、あるいはビジネスの世界においてどんな恩恵をもたらしてくれているのだろうか。

こう書くと、それはEnterprise2.0のことですねという人がいる。数年前に言われていた概念で今はどうなっているのか知らないが、要するにメッセージングやSNS、ブログ、wiki、コラボレーションツールなどのWebの技術をビジネスに生かそうという試みである。

まあ、だいたいにおいてナレジマネジメントと似たようなニュアンスで語られる。個人の知的生産性の向上といった響きだ。だから、グループウエアの拡張みたいな使われ方になる。しかし、そんな使われ方がはたして正しいのだろうか。どうも違うように思うのである。

そんな時は、技術そのものが持つ特徴を生かすにはといった視点が必要なのではないだろうか。私的な世界ではやっているからそれを企業にも持ち込もうというのはいささか短絡的のような気がする。家でやっているように会社でもやりたいというのは、電車の中で化粧するようなもので、そんなことは企業では望んでいない。

では、そのWebのもつ特徴、言いかえれば、従来できなかったものができるようになったことは何なのだろうか。ぼくは次の３つのことを挙げることにしている。

　１） 双方向コミュニケーション
　２） オンデマンド
　３） ハイパーメディア

それぞれを詳しく説明する必要はないと思うが、システム上でお互いに会話できること、自分の好きな時に情報を取りに行けること、そして多くのテキスト、画像、音声などにリンクで簡単にアクセスできることである。

この恩恵をまだ企業の業務システムで生かせていないと思う。ここで業務システムと言ったのは、いくらグループウエアみたいなところで言ったところで個人のリテラシーの差があったり、効果が表れにくかったりするわけで、そうではなくて誰もが日常的にやらなくてはいけない領域に持ち込むことが大事だと思うからである。

再三言っているように、企業の組織活動の基本は意思決定の連鎖であるから、その意思決定のスピードと質を高めることが大きなミッションであるはずで、そのためには、情報収集能力と判断力の向上、協働による集合知の活用、必要な時の俊敏な動きなどなど、先に言ったWebの持つ恩恵を享受できることが少なからずあると思うのである。

研究課題なんて大げさな名前をつけたくないのだが、ちょっと前まで「業務システムの再定義」というシリーズで記事を書き終えて、なんかまだもやもやして残っているものがあるので、そのことを考えようと思ったからである。

あの連載で言いたかったことの大きな柱は、企業活動とかビジネスのための業務システムと言うのなら、そのためのツールあるいは役に立つ仕組みにするにはどうしたらいいのだろうかという思いなのである。

その前提となる現状認識として、事業や業務とITが乖離したままであるということがあって、そこの一貫性を実現しない限り、経営者からITに対する信頼が得られないということである。だから、いくら経っても、経営に役立つシステムはどうしたらいいのかなんて議論が続くのである。

はやく、そんなことは当たり前で、重要なことはこんな新しいビジネスモデルをうまく実行してますとか、ビジネス環境が変わったので経営の仕組みもすぐにこう変えましたというようなことに関心がいくようにしなくてはいけないと思う。

なので、第一の研究課題は、ビジネスモデルとは何か、経営システムとは何か、それがどのような形でビジネスプロセスあるいはリソース管理に表現されていくのか、そして、どうシステムに実装されていくのかである。

このことは、できてますよ言う人もいるかもしれないし、そんなことは当然でしょという人もいるかもしれませんが、本当でしょうか。端的に言うと、いまあるERPでもいいですし、パッケージでも、レガシーでもいいのですが、あのシステムというかわかりやすく言うとあの画面でそうしたオペレーションができているのでしょうか。

最後は、経営にしても、事業あるいは日常の業務にしてもオペレーションという形で表現されてきます。オペレーションというのは、局面局面でそれぞれの人に与えられたミッションを責任をもって遂行するための意思決定のことです。それを、あの画面でできますかということに他ならないと思うのである。

いやー、経営コックピットとかポータルを作っているのでそこでできますよとか言われますが、おそらく作っただけのような気がします。モニタリングや分析することが経営とITの融合みたいに言わないでほしいと思う。

そして結局、オペレーションというからにはかなりどろどろとした現場まで行き着くのではないだろうか。軍隊と同じで参謀が図上でいくらいい作戦を考えても前線の兵士が動かなければ絵に描いた餅から抜け出ないのと同じような気がする。避けて通れない人間臭い話なのである。

そんなことを考えたのも、今週の初めにマジカジャパンの羽生さんと呑んだとき、自治体業務アプリケーションの話で盛り上がったのだが、羽生さんがかなり現場の泥臭いことでめげていて、綺麗ごとではないややこしい問題を解かないといけないということを聞いたからである。

ということで、ビジネスモデルから業務プロセス、オペレーションという落とし込みについてしばらく議論してみようと思います。
　　

数日前に面白いブログ記事を見つけた。日本のソフトウエア産業は「製造業」というタイトルでMITに留学している人が書いたもので、そのMITのソフトウェア産業研究で有名なマイケル・A・クスマノ教授がソフトウェア産業への取り組みかたが各国で違うということを言っているという内容である。

Europe: Software as a science －ヨーロッパにとってソフトウェアは「科学」
Japan: Software as production －日本のソフトウェアは「製造業」
Software as a service　－インドのソフトウェア産業は「（プロフェッショナル）サービス」
U.S.: Software as a business －アメリカのソフトウェア産業は「ビジネス」

なのだそうだ。これって面白いと思いませんか？

まず、ヨーロッパが「科学」というのも分かります。理論だとか体系化だとかが好きで、そこから入ってきますよね。そうしたコンセプト形成力はたいしたものです。ただし、頭でっかちなところがあって、実践的な面でどうかと思うことがあります。

インドの「サービス」というのもなるほどです。インドのITは後から参入してきていますから、ITはサービスであるという考え方が強くなったときにIT産業が興り、米国向けのサービスで地位を築いたということがあると思います。

アメリカはまさに「ビジネス」ですね。どんどん新しいことにチャレンジして、少々できが悪くてもかまわなくて、新規性に優れていればいいという発想で、うまく立ち上がったら高く売りぬくということだから、まさにビジネスです。

さて、日本は「製造業」というのも思わずうなずきます。それも、伝統的なモノづくり発想ですね。それも、近代的なものではなく職人芸に近いところもある。IT産業にいる人の中にもそう言っているひとがいる。

一概にどこがいいだとかわるいだとかは言えないが、ただ、日本の製造業の発想だけはやめてもらいたいと思う。なんだかんだと言ったって、事実として、世界から取り残されてしまったからである。今からでもいいから「科学」、「サービス」、「ビジネス」の一端を取り入れたらどうだろうか。

昨日、「生命保険のカラクリ」という本の書評を書いている時、ふと生命保険業界ってどこかの業界と似ているなあと思った。そうなんです、IT業界の実態とどこか共通点があるように思えてきたのである。そのことについて書く。

この本では、２つの章で問題点や課題が書いてある。「煙に巻かれる消費者－誤解だらけのセイホ」と「儲けのカラクリ－生命保険会社の舞台裏」である。これをそのまま、「煙に巻かれるユーザ－誤解だらけのシステム化」、「儲けのカラクリ－SIerの舞台裏」というように書き換えても本が書けそうですよね。

そして、その中身についても似通っている。生命保険という商品がさまざまあって、その内容もみな複雑にからみあってよくわからない。それでも営業のおばさんにプランの説明を受けて理解できないまま買ってしまう。ITもSEさんがわけのわからないIT用語で説明し、まあいいかというふうにして導入してしまう。

保険は何のために必要かを整理すると、3つしかなくて、所得保障と医療保障と貯蓄なのであって、そうした整理のあとに本当に必要かどうかを自分や家族の置かれている状況を鑑みて購入するべきなのである。これもIT導入になぞらえてみると、目的をはっきりせずに買ってしまうことがよくある。他の会社が入れたから同じパッケージを入れただとか、コストダウンなのか売上増なのかあいまいだとか、入れたはいいがあとの保守料でびっくりしたとか、多くの例がある。

もう一方の“儲けのカラクリ”についても同様で、保険料の決め方でもかなりリスクを乗せているわけで、そのカラクリは消費者はわからないのである。ITだってどうしてそういう価格になるかユーザにはみえない。情報の非対称性は同じようなものだ。

さらに、特約だとか、死亡保障と貯蓄を一緒にして総合保険だとかいって売っている。システムもある部分だけでいいのに、全体の整合が大事だとかいわれて、統合パッケージを買わされるのである。本でも単品主義のススメを説いているが、ITも目的に合った単品を入れられるようにしたいものだ。

そして、最も深刻なのは、生保もITももはやこのままでは売り上げがのびないということであろう。驚いたのは、生命保険会社の世界との比較で、保険料収入ランキングの1989年時点では、日本生命と第一生命が１，２位を占め、ベストテンに日本の生保が4社も入っていたのが、2006年では何と日本生命がかろうじて9位に顔を出すだけになってしまった。

さらに驚いたのは海外地域収入割合で、海外勢は軒並み50～80％くらいあるのに、日本生命はわずか１％なのである。これはもはやグローバル化の波に完全に後れを取ったということで、これも日本のIT業界も似たりよったりであろう。

こうしてみていくと多くの共通点があって、同じ課題をもっているように思う。そうした中で、ガリバーのような大手生命保険会社に立ち向かう「ライフネット生命保険」と同じようなベンチャーがエンタープライズ系のIT業界でも出てくることを願うのである。
　　

ソフトバンクの犬のオヤジが出てくるＣＭもなんだけど、最近流れているドコモの携帯のＣＭもいただけない。それは、「ひとりと、ひとつ。walk with you」編というのだそうだが、堀北真希と木村カエラが出てくるやつとか、岡田将生と渡辺謙が出るあのCMである。

堀北真希がファミレスかなんかでケーキを食べようとすると木村カエラが「食べ過ぎじゃない？」というあれである。木村カエラが携帯なのである。「四六時中いっしょのあたしですよ」、「ずうーとずうーといっしょにいるからさあ、私が。管理しちゃう」という。

渡辺謙は「私、携帯なんです、彼の」、「仕事でも、プライベートでも、いつだって彼のそばに私はいます。当然です。役目ですから。」という。

これをみていやな気分になるのはぼくだけだろうか。携帯に管理されるなんてトンデモナイと思わないのだろうか。どうも根底にITで人間のやること、考えることを代替させようという意識が流れているように思えるのだ。

ちがうと思う。その反対でITはあくまで道具であるから、ヒトが使うときだけ使うだけであって、うるさくつきまとうなというのが正しいと思う。道具の分際でヒトを管理しようなんて生意気言うなと言いたいのである。

ツイッタ―については、その良さや有用性がよくわからなくて、あまり使っていない、というかほとんどつぶやいていない。有名人ならその知名性から多くのフォロワーがついてくれるし、つぶやけばすぐに反応してくれる。ところが、ぼくみたいな無名人がいくらつぶやいても誰も相手にしてくれない。そんもののどこがおもしろいのかと冷ややかな目で見ていた。

さらに、SNSだとか掲示板だとかであまりいい思いがなかったこともある。掲示板なんかで反応が返ってくるのはいいのだが、うれしいものがある反面、明らかにチャチャを入れたり、反対することに生きがいを感じるような、斜に構えた批判的な人がいる。だから、そんなコメントに接するたびに気分が悪くなるから投稿もしないし、見もしなくなった。

ところが、最近気がついたのはSNSとか掲示板と全然違うということである。何が違うかというと、基本的に双方向のコミュニケーションではないことなのだ。ぼくは以前にWeb2.0の特徴あるいは良さの一つが双方向コミュニケーションであると言ったが、その双方向性が故に功罪合わせ持つのだ。

しかし、ツイッタ―はもちろん双方向のコミュニケーションも行うのだが、それで成立しているわけではなく、単方向の組み合わせという程度なのである。このゆるさが、爆発的な人気を呼んだのでハないかと思う。言いっぱなしでいいので斬り合わずにすむのである。従って、匿名の必要性が薄くなり実名でも恐くない。

ただ、ではフツーの人はいったい何のためにツイッタ―をつかうのだろうか。天気がいいとか、うまいものを食ったとか、そんな私的な日常性をつぶやいたところで誰も見向きもしないわけだし、仲間同士の会話であっても、それならメールや電話で十分だろうという話である。

かろうじて、ネット上あるいはメディアで話題になったトピックスについてつぶやくのが最低限の表現かもしれない。これとて、ぼくはしょせん“リアクション芸”であると言っているのだが、何かツッコミがあってはじめて成立するものだと思う。

次が、ある特定のジャンル、たとえば趣味のこと、音楽やスポーツのことなどに絞ることでしょう。ただこれとて、単につぶやくだけではその発信の価値は低い。結局、自分のオリジナルの考え、思い、知識、経験といったものを発信している場を裏で持っているということが大切のような気がする。

そういう意味で、ツイッタ―とブログはどちらか一方と言うのではなく、両方の組み合わせというのが望ましいのではないでしょうか。ツイッタ―がブログへの“呼び水”になるという位置関係のことです。と言いながら、ツイッタ―はマメじゃないとできないようで、どうもぼくのようなズボラな人間は使いこなすにはけっこう時間がかかるようなのである。

欧米発のソフトウエアはどうも管理的な色彩が強いように感じるのはぼくだけだろうか。ERPにしてもSales Forceにしても管理する側のツールという性格にみえる。これは、フレデリック・テイラーの科学的管理法を思い出させる。20世紀初頭にひろまった労働者管理の方法で基本原理は、稼業管理、作業の標準化、作業管理のために最適な組織となっている。

そうした考え方をいまだに引きずっているように思え、このソフトの機能どおりやれば効率の良い業務処理ができるはずだということである。ノルマを達成し、経営を安定させるためにはこうした管理プロセスが必要なのだという主張となる。

今の時代でも必要なのだろうか。もちろん、全面的に不要というわけではない。それこそルーティンの繰り返し作業では必要かもしれないが、そうではない部分の比重が増してきている現代では違った対応が要るような気がする。

だいいち、管理という言葉が好きになれない。つい営業管理システムとか購買管理システムとかいってしまうが、そのネーミングも気にいらない。システムが人間のやる業務を管理するという響きなのである。管理はあくまで人間がやって、それを支援するあるいは場を提供するのがシステムだろうと思う。

時として、管理プロセスによるコストダウンよりその管理プロセスを管理するためのコストの方が高くつくという破目に陥るというパラドックスを引き起こす。管理プロセスというと管理することが目的化するわけで、その目的を達成するためにはどんなコストをかけてもいいと錯覚してしまうのだ。

現代は、多種多様の客さまニーズに応えていかなくてはいけない世の中になって来ていて、画一的な管理手法では限界があるのではないでしょうか。そこでは、働いているひとのパーソナリティとか、組織としての協働動作だとか、それぞれの知恵と裁量といったことが重要視されてきて、それが差別化だったりするわけです。

このような変化に対応したソフトウエアや業務システムを開発することが大きな課題だと思っている。それを使うと楽しく働けるクールなITが望まれるのである。

ちょっと前にプロセス設計はそう厳密な方法でやるものではなく、「作法」という感じの方がいいというようなことをエントリーした。そこで茶道の作法についてもふれたが、どうも世の中のいろいろなところにも作法があるなあと思ったのである。

それは、前にテレビをつけたら偶然に映し出された金魚すくいの映像にかぶって出てきた金魚すくいの作法である。夏の風物詩金魚すくいは子どものときワクワクしながらやったものでした。いつもうまくすくえずすぐにポイ（金魚をすくうための丸い枠に紙が貼ったやつをこう言うそうです）の紙が破れて、くやしい思いをしたのを覚えています。

その金魚すくいの作法です。まあ、作法と言うより極意といった方がいいかもしれないが、それは次の3つのことだという。

（１） ポイは斜めに入水させ、水中では水平に移動させる
（２） 金魚は頭から追え
（３） 尾ひれは外せ

たしかこんなことだったと思う。（１）はポイの紙面に直角に水を当てるとその抵抗で紙がすぐに破れてしまうからである。（２）は、尻尾から追うとすぐに逃げられるからで、頭からだと金魚はバックできないからすぐに捕まえられるというわけだ。（３）は、ポイに乗った後尾ひれを振って暴れて紙を破るので、その尾ひれを枠の外に出すのだ。

この作法通りにやるとおもしろいほど金魚がすくえる。ああ子どもの時に知っていればなあ。さて、これからは業務プロセス設計作法に無理やりこじつけてみる。あまり意味があるわけではないのだが、作法のレベル感をみるためにちょっとやってみる。

プロセスは依頼を受付るところから入り、その後は意思決定を連鎖させるというのはなんとなくポイを斜めから入れてに近いでしょう。金魚は頭から追えというのは、顧客接点のプロセスは始点から書いていけに似ています。最後の、尾ひれは外せは、わけのわからない非定型なものはプロセス記述から外せと同じようなことを言っています。

かなり強引な論考ですが、作法らしきところが似ていなくもないわけで、作法というのはこんな具合いの表現であるということができます。最終的には金魚がいっぱいすくえる、あるいはうまく業務が回っていくことにつながれば多少の個人差があってもいいのである。
　　　

情報活用というと、BI（Business Intelligence）だとかデータウエアハウスとかいったツールあるいは手法がすぐに出てくる。これはもう20年くらい前から言われているが、みんながとびついたわけでもなく、ごく先進的な企業を除いては重要なソリューションとはなっていないのではないでしょうか。

なぜそうなっているかには、大きく二つの理由があると思う。ひとつは、過去のデータを解析しても今時の変化の激しいビジネスでは不十分だということである。（リアルタイムデータを扱うBIもあるが、対象はだいたいが過去データである）もうひとつは、データそのものだけが役に立つのではなく、そのデータがどのように生成されたか、どのように使われたかという観点でもみなくてはいけないということである。

最初の例は、何回も出てきていますが、死体解剖から生体ドックへと言っているように、死んでしまってから（業務処理が終わってから）その死因（うまくいった、あるいはいかなかった原因）を分析してももう手遅れで対策の打ちようがないのである。しかも、注意すべきことは、特に失敗した時の解析は、ほとんどの場合自己弁護になる。こうなったのは予測不能な為替変動という外部要因のためだと言いわけを並べるのである。

いま必要なのは、生体ドック、すなわち、いま起こっていることをリアルタイムに近い形で監視し、そこに表れたデータを即座に解析し、必要なら対策を打つということである。病気になる前に、その兆候を察知して予防して欲しいのである。

さて、もう一方であるが、データというのはもちろんそのものに意味がある。売り上げがいくらだったから多いとか少ないとかである。しかし、それだけではなく、そのデータがどういうプロセスを経て作られたのかとか、そのデータはどのいうルールが使われて決定されたのかとかといった過程といっしょになって考えるべきだと思うのである。

言い換えれば、わけのわからない、ちゃんとしていないプロセスやルールから生成されたデータは正しい意味を表現していないかもしれない。大げさに言えば、ビジネスの実相をねじ曲げてしまう可能性だってある。あるいは、そのプロセス自体をみることでデータの隠れた意味を読みとれるかもしれない。

このブログで盛んに言っているプロセス志向というのは、こんなところにもその有効性が認められということがわかると思います。つまり、正しいプロセスから生み出されたデータこそがビジネスの実相を正しく反映されたものであり、そのプロセスの進捗に合わせてその時点のデータを取得して、それを吟味しながら修正動作を適宜行うことにより優れた事業オペレーションができるのです。
　　

ちょっと前の情報活用についてのエントリーで医療になぞらえて「死体解剖から生体ドックへ」ということを書いた。ということで、システムの問題はけっこう医療と通じるようなところがあるなあと思ったのである。

例えば、システム開発のことでいうと開発が目的化してしまい、それが本当に使われて役に立っているのか、業務の改善につながっているのかといった本来の目的から逸脱しているのではないかという指摘をしている。すなわち、いくら高価でいっぱい高級機能があるものを導入しても会社がつぶれたらおしまいだということである。

それと同じように、いくら高度な最先端の治療を行っても患者が死んだらそれまでなのである。結局、いい治療をするから治癒するのではなく、治癒した治療がいい医療であるということだ。システムも同様でいいシステムを入れれば効果がだせるではなく、ビジネス上の利益をもたらした仕組みが、例え簡単なシステムであってもいい業務システムなのだ。

こうした見方は、理論的にこうだからこうなるという関係ではないということを言っている。自然科学では、因果関係がはっきりしていて１+１＝２であるが（ひとによっては、自然科学もまだ決まっていないこともいっぱいあるというが、まあここでは論理的であると言っておこう）、その他の領域ではこうした法則科学では無理があることも多いような気がする。

そうなると、実際問題として有用なのは臨床学というようなものではないかと思うのである。つまり、現実に起こった事象から学びそれを体系化して次に生かすようなアプローチである。どうも、経済学でもそうだと言っている人もいるくらいだから、情報システム学なら（こういうのがあるのかどうか知らないが）なおさら臨床的にやるのがいいのだろう。

医療には臨床医というものがいるのに、業務システムの世界に臨床医のような役割のひとがいるのだろうか。システムを作るときには、じょうぶな身体を作るにはこうした処方をしたらいいとさんざん言うのだが、いざ動かしてみて病気になったらちゃんと処置してくれるわけではない。

ですから、ビジネスや事業プロセスが健全に動いているのか診断して具合が悪くなったら薬をくれ、場合によっては手術をしてくれるような「デジタルクリニック」というのをやったらどうだろう。最近、ビジネスアナリストだとかビジネスアーキテクトだとかいった名前がついた職種があるが、そういうひとは情報システムのお医者さんになったらいいのではないかと思うのである。
　　

Webの世界が従来とどう違うかについては、Web2.0技術をはじめとして多くのことが語られているが、最近思うのは、従来になかったものとして“場”の概念が入ってきたように思います。

従来は、場が抜けていて、線で結ぶ、あるいは点をつなげるという考え方であったように思うのです。場というのは、孤立していない、直線的でないということです。つまり、みんなの広場であり、複線的であるということです。

古来から人間が行き交うところや集まるところに場がありました。複線的で共同的な空間が世の中のダイナミズムの源泉であったのではないでしょうか。広場、市場、運動場、劇場、停車場などなど多くの場が形成されてきました。

そこでは、コミュニケーションを伴ったダイナミックな動き、あるいは協働的な活動などが行われています。この場における絶え間ない動きこそ新しいものを創りだす源泉だったのでしょう。それによって文化は生まれ、伝達されていったのではないでしょうか。

しかしながら、現代のわが国を見てもわかるように現実の社会ではこうした場が失われてしまうように映ります。都市でも地方でも共同体という意識がどんどん薄らいでいってしまっているのは皆さんが指摘するとおりでしょう。

そこで、最初に言ったようにWebの世界に場の概念が入ってきて、失われたものを代替できるかどうかは分からないが、そういう兆候が見られるようになってきたと思います。ソーシャルネットワーキングとかソーシャルメディア、ソーシャルアプリとかいったものです。そこでは、見ず知らずの人も含めて、人々が寄り合う場ができているのです。

もちろん、このことはいいことばかりではなく、悪いことも当然起こるわけですが、世の中はどこでも清濁併せてあるもので、その中で生きていくことが大切なのです。ですから、これからのITのやらなくてはいけないことの一つに“場”の提供であると思うのです。

既にWebの世界では、そのためのIT活用が進んできていますが、それと同じように企業や役所、学校の中でも場ができていくことを期待したいのです。それがITを生かす道なのです。ある意味人を阻害することで存在していたITがもっと人間と仲良くできるようになるのです。

場とは一旦立ち止まり、留まるところです。そうすることは何を意味するかというと、人々に考える時間を与えることでもあるのです。どうして、自分はここに来たのか、これからどこに行くのかを、そこで交わる人や風景との会話で自覚的に学んでいくのです。
　　

業務プロセスをどう書くかというのが今のぼくの大きなテーマですが、これは単にシステムユーザの人たちの問題というわけではなく、ビジネスをやっている人全般に当てはまる問題でもある。たとえば、システムを供給する側にいる情報システム部門のシステム提供プロセスとか、BPMツールを売っている会社の営業プロセスといったように、意外と見落としてしまうようなエリアでも、もちろんしっかりとできないといけないことなのである。

だが、そのとき考えてしまうのは、一生懸命ユーザに向かって、プロセスは大事ですよとか、このツールを入れるとプロセスがうまく書けますよと言っている、その張本人がちゃんと自分たちのビジネスのプロセスを書けるのかというと、ちょっとお寒い感じがするのである。

たしかに社内情報システムというエリアでは、難しいところがあります。本当の顧客はだれかとか、のお金を儲けるわけではないなとか、自分たちが勝手に商品を開発して作っていいのかといった問題が横たわっています。

しかし、ぼくはこうした情報システム部門にビジネスモデル感覚を持ってほしいと思っています。なぜなら、情報部門を持っている経営者はどう思っているのかということです。当たり前のように、ムダなことはするな、費用対効果があるものを提供せよと言います。これは、社内でもビジネスとして成り立つことをやってくれと言っているわけです。

問題は、収益モデルが描けないことにあります。できれば、内部取引として採算をみたらいいと思いますが、そこまでやっているところは少ないかもしれません。ただ、お金でなくてもいいので、貢献度のような尺度で評価したいものです。

一方、BPMツールを売っているようなところでは、おそらく、ツールを一生懸命売っていると思いますが、その商材を扱う事業のビジネスモデルやビジネスプロセスというのを、自らの手で書けているのかが疑問ですね。自分で、いい事業モデルやプロセスを書けない営業あるいは会社がユーザにいくらこれはいい商品ですよと言ったところで説得力はありません。

だから、ぼくがこの方法論とかを議論する相手は、自分の会社で実践している、あるいは実践できるポテンシャルがある会社、個人しか相手にするつもりはありません。そうですよね、ブラック企業が、みんなが幸せになると銘打って商品を売ったって誰も買う人はいませんよね。

これまでの、SierやITベンダーがダメなのは、自らのビジネスプロセスも書けないのに、それができると称して、商品売りまくったことだと思う。まずは、自分たちのビジネスのモデリングを自分が売っているプロダクト、ソリューションを使ってやってみてくれと言いたいのである。

ビジネスでもそれ以外でもいいのですが、理念とかビジョンとかいったかなり抽象度の高い概念について語られることも多く、また実装レベルというか、末端の活動、アクションもそれ相応の技術や技法といったものがある。

ところがその間を埋めるためのメソドロジーが貧弱であるような気がする。つまり、理念やビジョンをどうやって実践するのかという問題である。そこで出てくるのがモデル化である。○○モデリングなんて言い方もされますが、あるレベルで概念モデルを書くことです。

ではモデル化あるいはモデルとは一体何なのかになります。模型なんて言われるとわけもわからなくなるのだが、さりとてこれだと言うのも見つからないので「構造化されたもの」くらいにしておきます。あえて「もの」と言ったのは実体があるものからないものまで様々な対象があるからです。

そこで、構造化するとはどういうことかをみることにします。次のように考えています。

　（１）全体を俯瞰したうえで、構成要素に分解し　
　（２）それらの構成要素間の関係を分かりやすく整理し
　（３）統合化されたモデルを作ること

ここで重要なキーワードは、「俯瞰」「構成要素」「構成要素間の関係」「統合化」といったところでしょうか。こうしてできた構造がモデルなのではないでしょうか。

理念やビジョンによって築かれた世界を俯瞰することから始めるのですが、そこをあまりやらずにいきなり構成要素に行ってしまう傾向があるように思うのです。ですから、モデル化というのが重要ですよと言っているのです。

そして、モデル化ができたとするとリファレンスモデルというのができてきます。事例を重ねることで作られる場合もありますし、論理的な積み上げでできる場合もあります。こうなると、モデル化にあたってこのモデルを参照しようということになるわけです。習字のお手本みたいにしようとします。これは、当然早くできますからそういう意味では有効な手段となります。

ただ、全く同じものを作るわけではないので、それを参考にして個別化することになります。そこで注意しなくてはいけないのが、どうしてもモデル全体を参照することになるので、冗長化するという弊害です。どうしても必要ではないかもしれないところまでモデル比較をしてしまうのです。つまり、結果として、ムダなこともやって遠回りしてしまうので早くできると思ったのが逆に手間ひまがかかるという破目になってしまいます。

大企業の大きな組織に対して、根本的に見直しをするなんて場合は、それでもいいのかもしれませんが、部分的あるいは小規模のような場合は、むしろ、大きなフレームだけをリファーし、一からモデル化するというのが現実的なのかもしれません。こうした方法論が望まれていると思っているのですが。
　　

最近では、エンタープライズシステムにWebの技術を活用しようという動きがよく出てきている。Twitterを使ってみたらとか、SNSで何かやろうなんてことを言っている。しかし、ちょっと待てよと思うことがある。それは、単に技術だけあるいはアプリケーションだけを入れれば素晴らしいことができるという錯覚であるのではないかということだ。

これでは、仏作って魂入れずという感じで、ほんとうの良さを発揮できないことになる。技術論も大事だが、その精神についてちゃんと理解しておくこともより大事なのである。

ぼくは、技術論的な見地から言うと、つぎのような技術がイノベーションを起こしていると思っている。

（１）双方向コミュニケーション
（２）ハイパーリンク
（３）オンデマンド

もっと中味のことで言えば、山本陽平君が書いた「Webを支える技術」（科学技術評論社）で言っているように「HTTP、URI、HTMLそしてREST」ということになるのだろうが、そこに至るまでの、コンセプチュアルな面の理解が欠かせないのだ。

それが何かをいろいろと考えてみたら次のようなことが浮かんできた。

（１）コミュニケーションの“場”の提供
（２）オープン性
（３）アジリティ

最初の、コミュニケーションの場は従来は“線”という概念が強く、電話やFaxはそうしたデバイスであった。それが、人々が同時に広場に集まるように“場”が設定されることができるようになった。ですから、そこでは双方向で会話が成立するのである。このことは情報共有のいきつくところでもある。

Webの世界は基本的にはオープンな世界で成り立っています。企業内で閉じた世界で仕事をするのであったらあまり意味がありません。あくまで、遍くみなの智恵を借りるにしてもオープンでなくてはいけません。自分のノウハウを出したら、存在感がなくなるので隠しておこうなんて思っている人たちがいたら成り立たないのです。

それと同じような話かもしれませんが、アジリティつまり俊敏性を必要とするような部署に有効なのであって、旧来型の過剰なコンセンサスが意思決定のメインであるようなところではこれまた意味がありません。稟議の決裁書を決裁済みと未決済の箱の中に入れて、気が向いたときに見るなんて上司がいたらどうにもなりません。

詰まることろ、Web技術やアプリを導入するには、会社の風土や動きをそれこそWeb的なものにしていかないと、一部の好き者が使うだけで終わってしまいます。これからの企業はこうした風土を醸成しないとグローバル化に遅れると思うのだが、そう簡単には行かないので、少しずつでもいいから浸透させていくのだろう。
　　

行動経済学でフレーミングという考え方がある。ものごとを見るフレームは人によって違う。それは、人間というのは思い込みがあって、それによりものごとに対する判断が変わってしまうということでもある。

例えば、手術に先だって死亡率１０％ですと言われるのと、生存率９０％ですと言われるのでは受け取り方が違う。またアンケート取って好き嫌いが５０％ずつになったとすると、半分が好きだとみるのか、半分もが嫌っているとみるかで違ってくる。このように人の見方で印象が変わってしまうことを言う。

なぜ、こんなことを言うかというと、いまビジネスモデルを書いたりしていると、どうもある種の「フレーミング」を行っているような気がしたからである。自分たちがやっているビジネスの捉え方、内外の環境を見ての評価、競合との位置関係などどれをとってもほとんどが意思とか願望が含まれているように思える。

ですから、ビジネスモデルは一義的に決まるものではなく、そのビジネスをやっている人の思いが入ってくる。だからダメだと言うのではなく、そのフレームを少し客観的な立ち位置から検分するというのが必要な気がするのだ。

つまり、理念やビジョンから、具体的なビジネス活動に落とすにはフレーミングを行っていくことと同じようなアプローチになるわけだが、そこには恣意的な部分があってもかまわないのであるが、注意しなくてはいけないのは、それを後生大事に持ち続けることによって変化対応ができなくなるという危険性があると言うことを認識することである。環境が変わったときには自分たちも俊敏に追随しなくてはいけない。そのためには変化対応力が不可欠なのである。

そんなときこそ、“フレームを変えてみる”という態度が大切であると思う。このことは、ビジネスの世界だけではなく、政治の世界もそうだし、それ以外でも適用すべきだろう。日本も成長国家から成熟国家へと変わったのだから、高度経済成長のときのフレームでは通用しなくなっているのだ。まだ成長していると見るのか、いや成長は止まったと見るかである。

このフレーミングの違いが生ずるのはどうしてかを考えてみると、ぼくは思想とか哲学に基づいた事実認識がその後のフレーミングに影響してしまうからのような気がする。端的な例は、同じ社会現象や政治状況でも自民党と社民党とでは対応の考え方が真反対になることがしばしば起こるのをご存じだと思います。市場に任すべきか公共が口を出すのかとか、バラマキか財政健全化かといったように同じ問題なのにやることが違ってくる。

ですから、政治にしても企業の事業にしても、大事なのは事実認識においては科学的で醒めた客観的な目で分析をしておいて、そこからは理念やビジョンに基づくフレーミングでモデリングするという態度が大事なのではないでしょうか。

昨年の夏から年末まで、ある中小企業の業務見える化プロジェクトに携わっていて、ハイレベルのプロセス設計が終わった。そのプロセスを見ていて、考えさせられたので、そのことについて少し書く。

この会社は、30人足らずでしかも福島に工場があるという会社なので、組織的にも数も規模も小さいから、一人ひとりの担当範囲も広くなる。いわば多能化された人の頭の中にいくつかの組織があるといった感じになる。

これは、中小企業であるとごく普通で別に驚くことでもないが、問題はそこの業務処理が個人の中でとどまってしまっているとか、あるいは属人的になってしまっているかである。そうでない場合は非常に効率的であると言える。大企業だと、組織の壁があってそれを越えるのに多大のコストがかかっていることからみると、意思決定も早いし、そのコストはミニマイズされる。

だが、実際にはそう簡単にはいかない。なぜなら、各人が持つ情報を開放して、共有するための手間がけっこうかかるので、目いっぱいの仕事をかかえているなかでは（中小企業の人たちの稼働率は高い）、そこまで手が回らないというのが多くみられる実態であろう。

もっと言えば、たたき上げのような人から情報の提供が受けにくいとか、みんなでそうしたことを話し合う機会さえなかなか取れないといった課題も横たわっている。従って、多くの中小企業では、仕事が属人的でばらばらになっているのではないでしょうか。

しかしながら、だからこそ中小企業がひと皮むけるために必要なことはまさにここのとろであると思う。今回のプロジェクトでも業務を見える化していく過程でとどんなことがわかってきたかというと次の3つの情報処理に関する問題である。

・情報（データ）が散乱していること
・情報が共有されていないこと
・情報をつなぐプロセスができていないこと

けっして、大それた問題でもなく、ごく基本のところができていないことに気がつく。日常的な忙しさにどうしても引っ張られて、少しずつ放置していくうちに、各個人の頭の中や自分のパソコンのフォルダーにデータが隠れていき、各人で閉じていくのである。

ですから、無理してでもいいから一度立ち止まって、保有情報や業務の棚卸をするとともに、上の3つの課題の解決をめざすことを勧めます。すなわち、情報（データ）を整備・一元化し、情報を共有する仕組みを作り、プロセスを作ることである。

これをどうやって解決していくかについては次回。
　　

前回、中小企業における問題を指摘し、その解決の方向性として、情報（データ）を整備・一元化し、情報を共有する仕組みを作り、プロセスを作ることであるということを提示した。そこらへんをもう少し堀り下げるというか、具体的な方策を検討してみる。

よく見かける情報の持ち方は、部署ごとで必要なものをそこだけで保有するということだ。つまり、営業は営業として必要な顧客データを持つし、経理担当は別に請求や支払い用の顧客データを持つわけである。

これは簡単に言えば、マスタがばらばらになっているのであるから、マスタを整備・統合して、一元管理できるようにすることとその管理責任者を決めることである。ごくごく基本のところであるが、できていない会社も多いのも確かだ。

情報の共有ということに関して言えば、いまやほとんどの会社にネットワークが引かれているので、単純にサーバー上に共有フォルダーを置いてもできるが、これまた多くの会社でグループウエアのようなものも入れているので、それを使ってもできる。

ただ、情報共有が意外と難しいのは、一方的な形での情報登録はすぐに破綻するということである。どういうことかというと、データを一生懸命入れたとしてもそれが自分のメリットにならないと疲れてしまうのである。自分がデータを入れることによって、皆の役に立つのと同時に自分の役にも立つというギブアンドテイク的な運用ができると有効なものになる。

そのためには、次のプロセスの問題にも関連するのだが、データの使われ方が、そしてその結果としてのビジネス成果が見え、かつ評価がされて、最初に戻ってくるというループが継続的に回っていることが大事になってくる。あなたが有用な情報を提供してくれたから、このビジネスがうまくいったんだよ、ありがとうというHappy Pathを実感することだと思う。

さて、最後のプロセスのことである。こうして、データが整備され、そのデータの出し入れや共有の仕組みを作ったとしてもそれだけではうまく仕事は回らない。各部署間を仕事が流れて結果を出さなくてはいけないからである。

もちろん、今それができていないというわけではありません。そうでなかったら会社として業務遂行が出来ていないことになるからです。要するにまがりなりにもやってはいるが時間がかかったり、手戻りがあったり、重複したりといったように非効率的になっているのである。そのためには、部署間の仕事の受け渡しや、各個人間の連携などをスムーズにするプロセスという概念を持ち込む必要があるのです。
　　

今回は、プロセスというところに焦点をあてて考えていきます。中小企業でプロセスという概念が少し乏しいと思うのは、最初の稿で言ったように、人が少なく多能化されているので、それこそひとりの頭の中でプロセスを動かしてしまっていると言えるからである。

しかしながら、今はいいかもしれないが、業容が拡大したりだとか、人を採用したりだとか、組織を改編したりしようとしたときには困ってしまう。ですから重要なことは人や組織に依拠せずにプロセスという考え方で業務を分解していくことである。

そうしたプロセスを作るときに中小企業の場合は特に難しいことを言ってもなかなか理解してもらえないということがある。一方で大企業の場合は、逆に構成員が歯車的な位置にあるので、階層的なプロセス構造から落とし込まないと分からないことがあると思う。

そこで、提案したいのは“プロセスとは書類の受け渡しである”ということである。実はこの考え方は、2007年にこのブログで「コンポーネントの粒度」というタイトルでこのことを書いている。単位業務とは書類を作成することで、そこで出来た書類を受け渡すのがプロセスであるという考えをずっと抱いています。

こうした考え方はわりと現場の人にとっては理解されやすいものです。例えば、見積もりというプロセスを例にとると、最初に「見積依頼書」というのが起こされます。そこには、見積して欲しい要望が書いてありますので、次にそれを確認するための「見積確認シート」といった書類になります。

そして、その確認シートに従って、商品の型式・仕様あるいは金額、納期などを決めなくてはいけなくて、次々に必要な事項が決まっていき、最終的には顧客に対する「見積書」に反映されていくわけです。つまり、書類に書くべき事項を転記していくと見積書ができあがるというイメージになるわけです。

別な言い方をすると、書類を“成長”させていくというのがプロセスでもあるのです。こうしたライフサイクルをどうやって完結させていくかという見方でみると、そこにはサポートするためのリソースであったり、参照する情報であったり、それこそ誰が書きこんで承認するのだというようなよくある書類の扱いと同じに考えればいいので比較的理解がしやすいと思うのである。

以上、中小企業の最初にやるべきことについて、データの整備、情報共有、プロセス化について書いてみましたが、実際にはそれらしきソフトウエアが導入されています。しかし、それらは、そのソフトウエアの範疇の使い方だけを教えるだけで、ほんとうにその会社のやり方に合わせるにはどうしたらいいのかは教えてくれていません。

大事なのは、ここで言っているその会社として必要なデータ整備、情報共有、プロセス化のやり方を既存ソフトウエアを意識せずに設計して、それに合うようにソフトウエアなりパッケージを使う姿勢です。ところが、問題はこうしたアプローチをとった時にマッチするソフトウエアがないということです。

例えば、プロセス化というと、BPMSを持ってくればいいじゃないかと言うと思いますが、そんな高価なものは中小企業には払えないということもありますが、むしろ30人規模で一人何役もこなしながらさくさくっと業務処理をしたいという要求には応えられていないということのほうが問題ではないでしょうか。

現実にどんな具体的ソリューションになったかはまた別の機会に報告することにします。
　　

こんなタイトルを思いついたのは、業務システムも同じようにならないのかと思ったからである。いつもびっしりと書かれた分厚いマニュアルをみながら苦闘するのでついそういう思いになるのだ。

それと、最近業務システム開発ということに関して、いくつかの問題に当たって考えさせられたからでもある。その問題は、ユーザ主体の開発という動きや単純な受託開発を避けるような話とかが聞こえてきたり、既成のソフトウエアをさわったりして感じたことである。

その問題の行き着くところは、もう何回もこのことについて書いているのだが、いまの業務システムにはオペレーションという視点が抜け落ちているよなあという感覚である。上記の問題の根源は、システム開発がまずありきというスタンスにあると思う。つまり、システムをどうやって作るかが優先しているのである。

このことを考える時に思い浮かぶのはiPhoneやiPadのことなのである。こうしたシステムはどうやって作るかが先に来るのでしょうか。違いますよね。ユーザがそれを使って遊んだり、コミュニケーションをしたり、情報を取得したりするために、どのようなUIにするとか、操作性をどうするのか、どんなことができてほしいのかといったオペレーションがまずありきですよね。あるいは、どういうスタイルでこれらを使うかという提案をすると言い換えてもいいかもしれません。

だから、マニュアルも要らないのです。ユーザがこうやって使いたいというのを表現しているだけだからであり、さわっていれば使えてしまうのです。こんなことを言うと、個人ユースのことであって、業務システムとはぜんぜん違うと言われるかもしれないが、あえてオペレーションという観点から考えてみたらと言っているのです。

というのは、個人ユースでも企業情報システムでも、結局は情報をさばき、コミュニケーションを行い、意思決定しているのは全く同じだと思うのだがいかがでしょうか。家の中やプライベート空間ではITの高度な使い方ができているのに会社に入ったとたんにプリミティブなインターフェースだったらがっかりするのではないでしょうか。

ですから、ここであえて言っているのは、会社の仕事ってどのようにして行っているかをよく考えてみたらということなのです。そうするとまたぞろ、業種業態が違ったらとか、業務形態だって様々だからそんな簡単なものではない、あるいはiPhoneやiPadはしょせんツールでしょとか言われる。たしかにそうなのだが、ひとり一人の人間のとる行動局面で言えば、共通的な考え方でいいと思うのである。

もっと言えば、仕事を楽しく気持ちよくできるにはどんな道具であってほしいのか、どういう機能があればいいのかということを真剣に考えてみることだ。いまの旧態依然とした業務システム開発や中途半端な完成品となっているソフトウエアあるいはパッケージではここの観点が希薄なのである。

ぜひとも、マニュアルがなくても使えるお仕事システムを作ってほしいのです。（ぼくなりに考えたものは作っていますが）このことを第一に考えることなしに、速く開発するにはどうしたらいいのかとか、ユーザに作らせるためにはどうしたらいいのか考えても、従来型システムを作り続けている限りは、いっこうにエンドユーザが満足できないのではないか思うのである。

先日のエントリーで企業における業務システムでもオペレーションという観点を大事に考えて、仕事のしやすいシステムにする必要があるというようなことを書いた。それに関連して、「ホーレンソー」ということを考えてみた。

ご存知のように「ホーレンソー」というのは、「報・連・相」のことで、報告、連絡、相談をちゃんとやりなさいということで、よく新入社員教育だとか上司の戒めの言葉などで出てくる。仕事をするうえで大切なことだと教わるのである。

こうした戒めの言葉があるということは、それがなかなかできていないからとも言える。報告も連絡もましてや相談もしないで勝手にやるやつがいるからこそ出てきた言葉だ。ただ、この好き勝手にやってしまう輩は、時代とともに変わってきたように思える。

ぼくらの若い頃すなわち戦後の経済成長時代では、上司の言うことなんか聞かずに勝手に仕事をやってしまう豪傑のようなやつがいた。まあ、多少そんなことも許された雰囲気があった。

ところが現代では、むしろ引きこもり的な勝手があるように思える。つまり、自分だけの中で仕事をこなそうとしてしまうことである。この場合は、あとで事が発覚して困ったりする。昔の勝手はやっているのがある程度見えるのでまだましかもしれないが、現代の勝手は内にこもってしまうのでかえってやっかいかもしれない。

それはともかくとして、今でもいちいち報・連・相というのが要るのだろうか。もちろん全く不要だというのではなく、従来のような形のものが要るのだろうかということである。ITがない時代に生まれた言葉が、ITがこれだけ浸透した時代になっても通用することなのだろうかと思ったのだ。

ぼくらの若いころは、ITがなかったからどうしたかというと、電話と机の前や黒板の前でそれこそたばこを吸いながら会話をしていた。そんな時代では、確かにホーレンソーが必要であった。しかし、現代ではひとり一台のPCが机の上にあり、電子メールがある。そうした環境は以前に較べればホーレンソーがしやすいはずである。

ところがである。かえってそれが阻害要因になっていやしないだろうか。これは皮肉な話なのだが、PCが机の上に置かれたおかげで隣の人とも電子メールでやり取りするようになってしまった。あるいは、コンピュータで打ち出された帳票をただ置いていくだけなのである。

こうしたことは何を意味しているのかというと、ITがホーレンソーに対してあまり役に立っていないということなのである。もちろん、ITは“電子計算機”とか“レポート出力機”としては機能しているが、人が協力しあって仕事を進めていくことに限って言えば、言い過ぎかもしれないが、ITがなかった時代より退化しているとも言える。

従って、これからのITは、オペレーションしながらホーレンソーが自然にできるような仕組みと仕掛けを提供することが大きな使命であると思う。それはどんなものかと言うと、「仕事の場」を提供することで、つまり関係者が業務の遂行を通して、その場に集うことで自然なコミュニケーションが起こり、その会話自体が報告となり、連絡となり、相談となるというイメージです。

この考え方こそ、オペレーションを第一でみていこうというシステム作りの精神なのです。

先頃のエントリーで「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から離れすぎたかもしれないが、最近大変気になっているところである。

（１）　クラウドとは何か？

カジュアルBPMの連載が終わったので少しBPMから離れたIT関連記事を書いてみようと思う。テーマを何にしようかなと思案したが、最近やはりよく耳にする、目にする言葉がクラウドなのでそれについて考えてみることにする。

ここでクラウドについて詳しく解説してどうのこうの言うつもりもないしできないので、ひょっとすると間違った解釈をするかもしれない。だからといって、世の中でこれだといった決まった定義もあるようでなさそうなので、ある程度勝手に言ってもいいだろう。

とりあえず、＠ITの定義から、「クラウド」とはどんなことかを探ってみます。

インターネット上にグローバルに拡散したコンピューティングリソースを使って、ユーザーに情報サービスやアプリケーションサービスを提供するという、コンピュータ構成・利用に関するコンセプトのこと。

なるほど、こういうことならすぐに言いたくなるがインターネットができたときからやっていることなのではないだろうか。そういうと、続きの解説にはこう書いてあった。

従来のコンピュータ・ネットワークにおいて、ネットワークは単にデータやメッセージが通過する経路であり、エンドノードである個々のコンピュータこそが計算や情報処理を行う主体であった。これに対してクラウドコンピューティングでは複数のコンピュータがグリッドや仮想化の技術で抽象化され、ネットワークで接続されたコンピュータ群が巨大な1つのコンピュータになるという、パラダイムシフトの意味が込められている。

なるほど、なるほど、仮想化された複数のコンピュータ群が有機的に連携されることが違うのか。でもこれは情報の供給側の形態であって、情報の需要側であるユーザーには関係ないことなのではないだろうか。そういえば使い方についてこう書いてある。

インターネットやTCP/IPネットワークは、しばしばクラウド（cloud＝ 雲）と表現される。ここから、インターネット上の“どこか”にあるハードウェアリソース、ソフトウェアリソース、データリソースをユーザーがその所在や内部構造を意識することなく利用できる環境、ないしその利用スタイルを「クラウドコンピューティング」という。

なるほど、なるほど、なるほど、これだと複数のコンピュータが連携してなんて、ユーザーにとってはどうでもいいことだと言っているわけです。すなわち、サービスを作って供給する側、つまりそれでビジネスをしようとしている人たちにとって大きなインパクトがあるパラダイムシフトであるだけなのである。

このことはWeb2.0という言葉が出てきたのと似たような話で、さもすごい変化があると煽って儲けようというプロパガンダなのであろう。ただこれでは何か味気ない結論で先に進まなくなってしまうので、次回からはもう少し詳細に見ていくことにする。

（２）　クラウドのサービス

まずは、クラウドから提供されるサービスを考えてみましょう。このとき切り込み方として形態と構成要素という見方で分けるのがよさそうだ。構成では、パブリッククラウド、プライベートクラウドに分けられる。パブリッククラウドというのは不特定多数を対象とするが、プライベートクラウドは、同一企業やグループ内で提供されるものをいう。

一方、構成要素で見て行くと、○aaSという言葉を浮かべればいい。すなわち、HaaS、IaaS、PaaS、SaaSで、HはHardware、IはInfrastructure、PはPlatform、SはSoftwareである。HaaS、IaaS、PaaSは似たり寄ったりのところがあって、ハードウエアやネットワークまでだとHaaSで、さらにOSやストレージ、一部ミドルウエアなどまではIaaSで、更にアプリケーションの稼働環境までを提供するPaaSという具合に発展系の呼び名である。

ということは、ユーザが必要に応じてハードウエアからプラットフォームやソフトウエアまでのサービスをパブリックな環境あるいはいくぶん閉じたプライベート環境を通して獲得するということがクラウドのサービスといえそうだ。

次に、その特徴をみてみよう。クラウドだからインターネット上にサービスがあるということは確かだが、それ以外何のだろうか。前回に書いたように技術的な特徴があるのはわかるが、サービスという面で捉えるとサービスそのものに特徴があるというより、それが組合せることができるとか、すぐに簡単に使えるとか、そういったことのように思う。

つまり、サービス提供のし方だとか、パフォーマンスが発揮できる環境を作る基盤技術に特徴があるのでないだろうか。このことは、クラウド先進企業であるグーグル、アマゾン、マイクロソフトなどをみたらわかると思うが、大量のデータを早く処理するために膨大なサーバーを統括的に運用する技術だとか、スケールアウトが簡単にできるとかを売りにしている。

うちの会社でも、クラウドコンピューティングの恩恵にあずかっている。自宅に何台かのサーバーを持っているが、ウェブのサービスをどこで動かすかの最適化を考えている。例えば開発は自宅でやってサービスインするときはアマゾンのEC2にするとか、データが増えて着たらS3に移すとかいったことをしょっちゅうやっている。

この震災の時に立ち上げた「Anpiレポート」も海外のVPSサービスのLINODEを使って素早く立ち上げた。ほんと数十分で稼働させられるという驚きである。また、非常に助かるのは、安価にそして容易にスケールアウトできることで、しかも時間オーダーでやめたりできるというすごいフレキシビリティである。

どうも、このスケーラビリティが、エンドユーザまではいかないサービスプロバイダーにとっての大きなメリットであるような気がする。エンドユーザはこうした頻繁のスケールアウト要請はないのでメリット性は薄い。これが前回ユーザにとってあまり関係がないことだと言ったことである。

（３）　従来のものと何が違うのか

前回はクラウドのサービスにはどんなものがあるのかをみていき、その特徴について考えてみました。パブリッククラウドとプライベートクラウド、そしてSaaSやPaaSなどのサービスがありました。特徴としては、ユーザが必要に応じてサービスの組み合わせができることやスケールアップダウンが容易にできることなどを見てきました。

今回は、そうしたコンセプトがクラウドだから突然出てきたわけではなく、昔から考えられたことであるというのを振り返ってみます。似たようなものに、ASP（Application Service Provider）、ISP（Internet Service Provider）やアウトソーシング、データセンターなどがありますが、私自身がもう十数年前に指向した企業システムの構造化を紹介することがひとつの答えになると思います。

企業情報システムは1980年代にはメインフレームが主流で業務アプリケーションは全部その中で稼働し、高価な端末が置かれてそこで処理されていた。そして、そのメインフレームは自社内に設置され、そこにオペレーターを配置し運用されていました。主要な遠隔地には高速デジタル回線が引かれそこからデータの登録や帳票の出力がばなされていました。

その後、PCの導入でクライアントサーバー型のコンピューティングシステムが登場し、またインターネットが使えるようになり、集中型から分散型へと変化していきました。2000年代になると、そうした技術が成熟してきて、様々なコンセプトが提示されるようになりました。Webサービスなんて言葉も出てきましたし、RDB、プログラム言語、パッケージなど新しい技術が出てきました。

そんな状況で企業システムをどんな構造にするのがいいのかが問われてきました。また、連結経営の重要性だとか、グローバル化という流れもあり、企業も単体ではなくグループとして見て行かなくてはいけない環境になったわけです。

そこで、要請されたのは、ひとつのメインフレームにロックインされたものから、マルチベンダー化あるいは多様化された技術の採用、分散処理化といった統合システム、そして標準化、共通化したアプリケーションを使いまわすこと、インターネットの利活用といったことです。

そのために構想したのが、グループ会社向けASPでした。つまり、親会社の持つ業務アプリケーションと同じものをネットワークを介してグループ会社で使ってもらおうというものです。ですからグループ会社は、PCだけあればいいし、システム運用要員も不要というわけです。

さらに親会社では、メインフレームをベンダーのデータセンターへアウトソーシングしました。東京のビルの地下にあったハードを全部撤去して、データセンターにある新鋭のマシンに載せ替えました。これでPCだけで基幹システムを使えますし、オペレーターはいらなくなり、スペースも返すことができたのである。

これって精神はクラウドですよね。しかも親子でクラウドです。ハードウエアからソフトウエアまでのサービスをプライベートネットワーク（IP-VPN）の環境でユーザに提供することに何ら変わらないと思うのですがいかがでしょうか。

（４）　クラウドでしかできないことは何か？

前回、クラウドと言いながらも昔にやっていたこととその精神においてはかわらないではないかという指摘をした。しかしながら、やろうとしたことは同じでもやれていたかどうかは別の話である。そこを考える時に大事なのは、サービスそのものは変わったのか、その提供のし方が変わったのかである。

前々回にクラウドのサービスで形態と構成要素という切り口で見たが、その見方で分析すると、パブリッククラウドとプライベートクラウドでは、後者のプライベートクラウドは本来のクラウドとは違うように思う。これだと、昔の企業内ネットワーク（VPN）やベンダーのデータセンターと何ら変わりないのではないでしょうか。クラウドはパブリックでなければ意味がないと思う。不特定多数のサービスの良さを享受することが重要だろう。

次に構成要素だが、クラウドになったからといって、ネットワーク、ハードウエア、OS、ミドルウエア、アプリケーションがクラウド用に従来と違ったものになったのだろうか。確かに、分散コンピューティング技術や仮想化技術がなければできないという意味で基盤技術上の進展はあったが、それは大きな変化なのだろうか。変化をもたらす要因ではあるがそのものが変化ではないと思う。

別の角度からみてみると、費用やコストあるいは運用とか人的リソースの問題があるかもしれない。システム開発をしなくていいし、買ってこなくていいということでいえば一時的な費用から従量料金的な費用になることはその通りであるが、これとてリースで買えばあまり変わらないのではないだろうか。

大きなコストダウンが見込まれるのだろうか。規模の経済学が働く可能性があるが、デメリットもあるのでどうなのだろうか。運用の問題では、ハードウエアやインフラのお守が無くなるから、そうした人材がいらなくなるという面があるが、アプリケーションの運用はどうなるのだろうか。

けっこう悩ましいことは、クラウド化によって情報システム部門の業務が変化するということだ。こうした変化はある。つまり、情報システム部門は現状でかなりシステム運用にリソースを割いていますが、それがなくなるわけだから、別の機能を持たせるように役割を変える必要が出てくるのである。

理想的には、システム運用から本来果たすべき役割である事業とITの橋渡しをすべく変貌するというのがあるが、そう簡単にはいかない。なぜなら要求スキルが全く違うからである。ただ、早晩そうしたシフトは必ずやってくるのでそれに備えた方がいい。

結局、クラウドでなければできないことは何だろうかと考えたとき、サービスそのものが新たに出現するのではなく、その提供のし方、つまりその機能的な側面と性能に現れてくるのではないだろうか。必要なサービスを多くの候補から選べるようになり、それぞれを組み合わせることができるようになったとか、大量の処理が可能になったとか、早くなったとかといったことである。

そして、それを突き詰めていくとコストに集約される。すなわち、クラウドはコストダウンをめざしたソリューションなのである。言い換えれば、いろいろな角度からその費用対効果を吟味して、見合うようならそのサービスを買ってくるという態度が大切なのだろう。

（５）　クラウドと業務システム

ここからは業務システムについて考えていく。最初にクラウドはサービス供給側の変化を強調したが、使う側それもエンドユーザにとってのクラウドということになる。つまり、クラウドコンピューティングによってもたらされるサービスを使うことでどんないいことがあって、今までと何が変わってくるのかといった論点になる。

まず初めに言いたいひどい間違いは、エンドユーザの人が、“これからうちの会社でクラウドコンピューティングを導入します”なんて言うことである。クラウドを入れることが目的化するのである。何のためにクラウドを使うのか、クラウドにあるどういったサービスがいいのでそれを使いたいのかをしっかりと見極めないと本末転倒である。

クラウドになって、素晴らしい業務システム、まあ業務アプリケーションでもいいが、出てきたのだろうか。クラウドでしかできないものが登場したのだろうか。もし、既存のものをクラウド上に乗せただけだとしたら、それを使う意味は何なのだろうか。それは前回指摘したように導入コストとか運用コストで選択されるだけである。

もし、業務システムをクラウドにするとしたら、それが使い回しできるものでないと意味がない。ということは、標準化、共通化できるものが対象であろう。それに対して共通化できない差別化されたもの、あるいは競争優位点を持ったものなどはむしろクラウド化しない方がいいのではないだろうか。

業務システムの議論で陥りやすい誤りは、手段の話ばかりに終始してしまうことで、新規の技術やアーキテクチャはどんどん出てくるが、それらはみな手段のことばかりである。ただ、クラウドというのは、従来のシステムを作るため手段から、使うための手段に変化してきていることは評価できると思う。

しかしながら、使うにしても使うものがよりいいものに変わったのであろうか。使い方の前に使うものの構造だとか機能だとかを進化させていかなくてはいけないのに、それができていないように思う。だから、クラウドにあるものを使ったところで、役に立たない、事業に貢献できないシステムを生み出すことには変わりない事態になるのである。ただ、すぐにやめられるというメリットはあるが。

結局、業務システムという捉え方をすると、クラウドの影響は少ないと言わざるを得ない。ちょっとした情報系のシステムや個人の生産性向上ツールなんては、クラウドが有効かもしれないが、企業のコアの業務への適用は難しい。それは、繰り返すが、他の会社と同じ仕組みにして競争するなんてことはナンセンスだからであり、固有の仕組みは固有のインフラ、プラットフォームでいいと思うからである。

（６）　クラウド化するための要件とサービス

前回、前々回で企業のコアな業務システムはクラウド化には向いていないという指摘をした。ただだからといって、全く無関係というわけではなく、実は大いに関係してくる面もある。業務システムにとっては、そこで必要になるサービスを取得する場所でもあるということである。

何回も言っていることだが、クラウドを目的化してはいけないということ、クラウドを入れることで何でもできてしまうという誤解をしないことの裏返しとして、あくまで主体は業務システム側にあって、そこがクラウドにあるサービスを使いたかったら使えばいいだけの話なのである。

昔、クライアントサーバーなんて言われたこともあり、今ならＳＯＡかもしれないが、要するにサービスという概念を正しく理解して、誰が何のためにどんなサービスを使うかを定義することが大事なのである。サービスの欲しがり手（クライアント）とサービスの出し手（サーバー）のリレーションシップである。

そして、必要なサービスをそれがあるところから持ってくるという授受を適正に行うのが業務システムの重要な機能なのである。業務システムは、そのオペレーションのために様々なサービスを依頼して、提供してもらうことを行う。ただ、それが当然のようにみなクラウドにある必要がなく、キャビネットの中でも人の頭の中でもいいのです。

ですから、必要なサービスがクラウドにあったらそれを使うというだけのことです。その時、クラウドでしかできないサービスは何かということで、4回目に議論したことである。そこをもう一度整理すると、クラウド以外の他のところでは、機能として持っていないのか、機能として持っているが性能がでない、機能・性能はあるがコストが見合わないのかをみて、どの理由でクラウドを使うのかという選択となろう。

最初の機能のところはそうでもないだろうが、あとの二つの威力はすごいと思う。簡単な例で言うと、顧客から引き合いとか問い合わせがあった時に初めてのお客さんだとどこにあるのかがわからないからその場所を知ろうとするなんてことは必ずといっていいほどあります。

昔はどうしていたかというと書棚から地図を引っ張り出して、ページをめくって見つけ出し、そのページをコピーします。ところが今はどうでしょうか。Googleで検索して終わりですよね。同じように、その会社の概要を知りたい時は、それこそ会社四季報をまためくりながら、または帝国データバンクの情報を見るわけですが、今ならウエブサイトを見れば一発でわかります。

このように、クラウド上にある情報は格段に早く、安価に手に入れることができるようになりました。ですから、クラウド時代では情報を使う側の要求レベルが非常に重要になってきます。クラウド上にいっぱいサービスがあるから、それを使えばいいという単純なことではなく、自分たちの業務システムで必要なサービスは何か、そのために使う情報は何かを設計できるスキルとそれはどこにあるのかを見つけ出すスキルが要求されてくるでしょう。

（７）　最後に

今回でシリーズも７回目であるが、最後にしようと思う。始めた時はもう少し何か書けるか思ったが、意外と早くネタが尽きた。それだけクラウドというものに深みがなかったということだろう。つまり、サービス供給側でのインパクトは大きいが、エンドユーザにとっては新規性や斬新性に乏しいのである。

なぜこんなことになっているのか考えてみると、ITについて議論を戦わせるリングがごちゃごちゃになっていることに起因しているように思える。例えば、このシリーズでも出てきたように、ITサービスを供給する側の話なのか、サービスを受ける方の話なのかを混同して議論してしまうことである。だから、あちら側ではすごいと言ってもこちらでは大したことがないとなる。このあたりは別のシリーズ記事を立てようと思っている。

さて、クラウドであるが、繰り返しになるがあくまで供給サイドの変化であって、しかもパラダイムが変わるような話ではなく、大規模分散サーバーで大量のデータを早く処理するというパフォーマンスとそれを運用する可用性がとてつもなく向上したということなのだと思う。Google、Amazonといったパブリッククラウドがそれを実現しているのである。

そして、最終的にはコストに集約されてきて、費用対効果が見合うかどうか、そしてそれに重要なファクターとしてリスクを加味して判断するのだろう。コストとリスクは必ず相反するから、トレードオフとしてバランスをみて選択すればいい。

日本の企業では、パブリッククラウドとか言って狭い閉じたエリアでやってますよというのがあるが、これは厳密にはクラウドではないのではないでしょうか。３回目にも書いたようにデータセンターやVPNとどこが違うのかと言いたいのである。だから、無理やりクラウドと呼ぶ必要性はない。

先日、前にいた会社の元部下と呑む機会が会って、いろいろと話をしていたら、クラウドのことに話題になった。別にクラウドを意識してやっているということではなく、やっていることが結果的にクラウドだねという話である。

どういうことかというと、ぼくがいた頃にグループ会社向けにネットワークの提供とアプリケーション使用サービスを始めた。親会社の情報子会社の最大のミッションはグループ会社のIT化支援にあるという信念からである。ハードからソフトまでの共通利用と運用の一元管理が、全体の高ストダウンにつながると考えたのである。このことは3回目に書いたことである。

ところが、その当時は単体経営から連結経営へシフトする時期ではあったが、まだグループ会社の独立性が高く、自前でシステム部門をもったり、地元のベンダーと仲良くやったりとあまり協力的ではなかった。だから、少しずつ糾合していったのである。

ところが、ここにきてグループ各社がこぞってグループネットワークに入りたいと言ってきているのだそうだ。おわかりのように、震災の影響である。直接的に被害に合った東北のグループ会社からはもちろんのこと、全く別の地域の会社からも問い合わせがあるという。ぼくから言わせると、最初から気づいてくれよと言いたいが、やはり何か起きないとその気にならないものなのだろう。

ユーザからみるとクラウドなんて言葉は知らないと思うが、これがクラウド化なのである。「カジュアルBPMのすすめ」というシリーズでも指定したが、システムの送り手（作り手）側の発想ではもう限界なのであって、ユーザ（使い手側）の感覚をもっと大事にしたアプローチが必要だと今回も強く感じたのである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以前「「応援したくなる企業」の時代」（博報堂ブランドデザイン著　アスキー新書）という本を紹介したとき、その中にある7つの不思議前提というものを見直すことが重要だというようなことを書いた。その7つの不思議前提というのは再掲すると、

・ 「ターゲットにモノを売る」というまちがい
・ 「差別化のポイントはどこ？」という不見識
・ 「ニーズはなんだ？」と問うあやまち
・ 「勘でものをいうな」がもたらす損失
・ 「どんなアウトプットが得られるんだ？」と問う不利益
・ 「下から意見が出ない」という勘ちがい
・ 「仕事にプライベートをもち込むな」という非常識

であるが、それぞれについてIT業界絡みで考えてみようと思う。

まずは、「ターゲットにモノを売る」というまちがいについてである。本の著者は「ターゲットを攻略する」という言い方からもわかるように軍事用語であり、攻撃的なニュアンスがある。しかし、こうした“買わせる”“売りつける”でいいのだろうかということである。

ITももちろん例外ではなくて、普通にマーケティングの一環としてターゲットを設定する。ターゲットは大企業にするのか、中小企業向けなのかとか、2000年問題だとか内部統制だとかいったエポックがあると一斉にそれめがけて売り込む。

そんな時の言い分は、顧客志向であり、消費者目線である。しかし、その前に送り手発想と受け手発想という二項対立概念を踏襲したままでは意味はなく、単に視点を変えただけになってしまう。つまり、いつまでたっても作る人と使う人という区分けの中で、使う人の要求を聞いて、作る人が要件定義するというやり方では、二項対立概念を引きずったままだと思うのである。

この本では、それを解決するには、「ターゲット発想」から「コミュニティ発想」へ転換せよと提言している。システムを作る人と使う人が一体となって、ビジネスの成功めがけて協力し合う姿が浮かぶ。しかしながら、非常に難しいのも確かだ。どうしても収益モデルが書けないから、既成のベンダーやSIerでは無理なので、新しいプレーヤーが出てこないとできないかもしれない。

ただ、希望はWebの世界が、技術的なものもさることながら、その精神の部分でもかなりエンタープライズに入り込んできたこと、そして、クラウドのインパクトである。以前、ユーザにとってはクラウドにあまり積極的なメリットを見いだせないと指摘したが、このコミュニティ発想を後押しする環境という意味では可能性を感じる。
　

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)

posted with yusukebe.com::AmazonSearch on 2011.9.19

• 博報堂ブランドデザイン
• 新書 / アスキー・メディアワークス
• Amazon 売り上げランキング: 5334

Amazon.co.jpで詳細を見る

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

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

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

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

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

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

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

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

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

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

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

いま、外ではセミが鳴いている。今朝の新聞では、岩手県の小学校の校庭で桜が咲いたという記事があった。どうなっているんだろう。季節が狂ってしまったのだろうか。でも、セミナーやシンポジウムは季節通り花盛りだ。今週もGartnerのシンポジウムが3日間台場のホテルで開かれた。

個人では行けないのだが、あるところから招待状をもらったので2日間だけ聞きにいく。テーマが「「最前線」に立て　・ITリーダーが導く再成長のシナリオ」となっているが、中身をみると再成長のシナリオをどう書けるのか見えてこないように感じた。米国からのコンサルタントを中心に聞いたのだが、インパクトはなかった。

会場で出会った知り合いの若い子が、今年は外人のスピーカーが少ない、きっと日本を見限っていて中国に目がいっているんじゃないかと言っていたが、そんな気にもなる。セッションの分類が、「CIO」「ITインフラストラクチャ＆セキュリティ」「アプリケーション」「ITマネジメント＆ソーシング」「未来志向」であるが、これはという新鮮味にも欠ける。

「未来志向」にしても、イノベーションとかいう話なのだがネットの世界で起きていることを解説しているだけで、企業に与える影響だとか、ビジネスがどう変わるのかというエンタープライズ領域での言及があまりなかった。それと、昨年はけっこうあったそうだが、BPMのセッションがほとんどなかったのはどうしたことか。聞いたセッションの中から少し感想を書いてみます。

ゲスト基調講演でNTTデータの副社長のかたが「グローバル時代の戦略構築への示唆」と題して話されていました。わが国のトップIT企業がどういうことを考えているのかを聞くいい機会だと思って期待していたのだが、残念ながら何も感動しなかったし、ちゃんとした戦略がないのかとがっかりした。海外売上比率をあげることとか、M＆Aがグローバル化と言われても首をかしげたくなる。

グローバル化が叫ばれてから久しいのに、いまだにその戦略の絵がきちんと書けてないようだし、自虐的にうちの会社は非グローバル企業の代表選手だなんて言っているようでは何をかいわんやである。戦略に則ってこうした海外展開をしていますとか、グローバルの中での事業ポートフォリオはこうしていきますとか言ってほしかった。これでは、ガートナーが中国に行ってしまうのはしかたがない。

ぼく的には今回の注目はサイボウズの青野社長の「No-Emailの次は「No-Excel」cybouzuクラウドで実現する次世代ワークスタイル」である。ちょっと前にサイボウズデヂエを使ってカジュアルBPMを実践したこともあって、その後継とも見られる「kintone」のデモも含めた紹介を聞きたかったのである。

ここでもキーワードのひとつはもちろんNo-Excelである。ぼくが情報システム部門に移った17年前にも、MailとExcelで仕事をこなすスタイルはあって、しかも講演でも指摘されたように“エクセリスト”と呼ばれのような達人がいて、他のひとがわからないマクロを組むという例がいっぱいあった。そのひとがいなくなると手に負えなくなって情シスに駆け込まれ困ったこともあった。

それを解消すべくということで、もうひとつのキーワード「ファストシステム」を提案している。すなわち、ファストフードやファストファッションのように欲しいものがすぐに手に入り、かつ信頼性が高いシステムインフラを用意するというコンセプトである。これはぼくが“カジュアルBPM”を標榜しているのと同じなので共感できる。

そして、そのための機能として「データベース＋プロセス管理＋コミュニケーション」が必要だとしている。これも、ぼくは、「プロセス＋データ＋機能」と言っていることと軌を一にしている。ですから、コンセプトと必要機能に対する考え方は非常に素晴らしいと思う。ただ、だからこそあえて言っておきたいのだが、3つの機能のうちどれが最も重要なのかというのと、データベースとプロセス管理の意味をもう少し広く深く掘り下げてほしいのだ。

つまり、データベースをインとアウトの2つの方向で考えてほしいのであって、そこに登録するというインの考え方だけになっているが、一方でアウト、すなわち有用な情報が入っているデータベースからデータを取り出して参照するという機能が要るということである。また、プロセス管理というからには、プロセスの進捗が俯瞰できないと管理はできないのでステータス表示だけだと弱いのである。

ただ、まだ基本形を作ったという感じなのでそこからブラッシュアップしていけばいいものができると思う。繰り返しますが、コンセプトと必要機能設定はすばらしいので、それを真に実行できるシステムインフラにしてもらいたいと思うのである。だいぶ、講演のことから離れてしまったのですが、面白いプロダクト、サービスになる可能性がありますので皆さん使ってみてください。
　　

さて、次の「不思議前提」は「「差別化のポイントはどこ？」という不見識」である。これもマーケティングでは普通にやられていることで、差別化戦略なんて言われ方もするように、戦略立案の時に差別化のポイントはとか、競争優位点は何とかいったチェックをします。

そのために多くやられるのがケーススタディというやつで、同業他社分析とか、業界分析などを事例研究という形で行われます。ところが、これには2つの危険性が潜んでいると指摘している。当たり前のようにやっている「他者との競争に勝つためには、どこを差別化するのか」といったケーススタディアプローチが“不見識”だというのである。

その二つの危険性というのが、
１．すでに存在している商品やサービスと同質化してしまうこと
２．既存のフレームに知らぬまにとらわれ、斬新なアイデアが生み出せないこと

なのだそうだ。たしかにケーススタディというと既成の商品やサービスと似たり寄ったりのものしか生まれてこない。ITの場合だって、プロダクトにしても、ソリューションにしてもどこの会社ものでもほとんど変わりがないものばかりである。

これは、ユーザ側にも責任があっていつも他社比較をやるのはいかがなものであろうか。他社比較も同業ユーザの事例を持ち出すのと、ベンダー同士の比較を要求する。それを示さないと投資ができない、あるいは投資してくれないというのである。こうした横並び姿勢がある限り、ちょっとした拡張機能を差別化と言ってみたりするわけで、同質化の危険はつきまとう。

つぎの、フレームにとらわれてしまうということですが、この場合のフレームという意味は、ある商品やサービスが市場に投入されたとき、それらが生活者に違和感なく受け入れられる範囲のことを言います。業界というのもフレームにあたります。さしずめ、IT業界というのも既成のフレームですね。

フレームにとらわれるというのは、既成の商品カテゴリーとかサービスエリアなどに縛られてそこから抜け出すような発想ができないことをいっている。ITにおける3文字熟語なんていうのも狭い概念としてのフレームを形成してしまう。ERPはこんなものだからその範囲で機能の特徴をだそうとするから、それはERPの枠を越えるわけではない。

そこで、著者は「シェアアプローチ」から「新市場創造アプローチ」へという提案をしている。そのためには、既存の業界の枠を外す“越境”の力が必要で、「進んで異物をミックスする」アプローチを推奨している。ケースを参照するなら他業界を見ることで、それを模倣すればいいという。例として、サウスウエスト航空は長距離バスを参考にして業績を伸ばしている。

かつて「カジュアルBPMのすすめ」というエントリーでカジュアルBPMを「コピー機を売るように売りたい」と書いたのはこのことである。“越境”することで見えてくるものがある。単に受託開発とか、クラウドで提供とかではなく、ブティックを開店してそこのカリスマ店員にソフウエアを売ってもらったらどうだろうかとか面白いですよね。

業界という意味では、例えばIT業界も建設業界のまねをしてみたらどうかとか、システム開発はセル生産方式にしたらとか、逆にユーザ企業のプロジェクト管理をITのプログラマーの開発プロジェクトを参考にしたらとか、様々な“ケーススタディ“　ができるので検討してみたらいかがでしょうか。

実は、本でも言っているように、このことは日本人が得意としたところでもあるのです。異文化を模倣して、それを自らの文化に何の違和感もなく融合してしまう力は素晴らしいものであるから、ぜひその精神でITの世界を見直してもらいたいものだ。
　　

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)

posted with yusukebe.com::AmazonSearch on 2011.9.19

• 博報堂ブランドデザイン
• 新書 / アスキー・メディアワークス
• Amazon 売り上げランキング: 5334

Amazon.co.jpで詳細を見る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前回、差別化のポイントはどこという観点でケーススタディを行うと、同質化とフレームにとらわれる危険性について書いたが、ちょっと見方を変えて、実例をあげて“差別化のための差別化“という話をしようと思う。要するに、差別化をしなくてはいけないから何でもいいから競争相手と違うことをしようとしているが、それは顧客にとってはマイナスになってしうことが往々にしてあるという話である。

例をあげよう。シャツのことである。ぼくは作業着でもあり、外出着でもあるシャツ、それもスーツの下に着るようなものではなくカジュアルなものをいつも着ている。だからみてくれよりも着心地で選びたいので、気にいった者が見つかればそれをいつまでも着ていたいと思っている。

ところがである。最近では、1年経つともう翌年には同じものがないのである。そりゃあ、一流の店の高級なものであれば、そうしたことはないと思うが、一介の庶民である身にとってはユニクロであり、街の洋品店なのであるが、そこでは新物デザインと称して毎年形状や材料や色目も変えてくる。まだ流行もしていないのに今年の流行ですと宣伝する。

幅がゆったりして気に入ったのに細身になって窮屈になるとかはまだいい方かもしれないが、どうしてこんなことをしなくてはいけないと思ったのは、ボタンが厚くなっていてはめるのにひと苦労するなんてこともあって何のためだか意味がわからない。それとか、襟の内側に赤い線がわざわざ入れてあるなんかなんじゃこれと思ってしまう。きっと他社との差別化なのだろう。トラディショナルと言うなら変えるな。

ITも同じようなことがある。競って他社との違いを強調する。それがほとんど必要な機能というわけではないケースである。他よりと同時に去年より、前バージョンよりとどんどん膨らんでいく。頑なにこれだけしかできないけど継続していきますというITはないのだろうか。コンシューマ系にはありそうだが、ビジネス系には少ないように思う。

サイボウズがもうすぐ発売する「kintone」という製品は、No-Excelというコンセプトなのですが、企業内にはびこるExcelアプリケーションを置き変えようと言っている。Excelのマクロを使って作るのはいいのだが、本人しか直せないとか、ブラックボックス化してしまうとかの弊害が出てくるので、もっと簡単にわかりやすいツールを提案しています。

Excelは最初は単なる縦横計算できるだけぐらいのものだったにちがいないが、だんだん機能が追加されいつのまにか複雑なソフトウエアになってしまった。本来なら、他のところで別のソフトウエアで持った方がいい機能もとりこまれていった結果だと思う。これからは、単なる縦横計算に強いカリキュレータというだけで十分である。

必要最小限の機能をもったシンプルでつかいやすいツールを組合せることで複雑なあるいは高度な要求に答えて行ってほしい。ですから、差別化の方向を機能の増加拡大ではなく、その逆の機能をそぎ落として、シンプルさを差別化のポイントにもって行くことも考えてもらいたのである。
　　

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

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

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

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

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

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

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

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

よく顧客志向だとかお客さんのニーズをよく把握してといった言われ方がされるが、そうした生活者の声を聞き、それに応えていくという「ベネフィット発想」はうまくいかないのだという。つまり、改善してほしいという要望をすべて改善したからといって、商品が売れるようになるとは限らないのだ。

どうしてかというと、生活者が本当のニーズを自覚できていないからである。それと最近では、生活者の多くは必要以上に自分たちにすり寄ろうとしたり、おもねったりする企業を評価していないのである。

このあたりは、ITもぴったりあてはまる。開発プロジェクトでユーザ要求を一生懸命聞いて作ったはいいが、いざ使う段になるとそんなものは使いものにならないとなることはしばしば経験することである。

理由も同じように、ユーザの担当者が本当のニーズを把握していなかったり、そういう立場にいなかったりするからでもある。それと、これも同じようにユーザもだんだん賢くなってきたのと、情報がいっぱいあるので、何でもできます、やりますとか、こんないい機能があるので使ってみましょうとか、今度の新製品はおたくのニーズに合っていますとかいう甘言は見通せるようになってきた。

では、これからはどうしたらいいのかであるが、従来のようなニーズに応えることで支持を集めようとするアプローチではなく、生活者が企業やブランドの側にみずから歩み寄ってくるような関係を構築すべきだという。

そのためには「企業のビジョン」を示すことが不可欠であり、あるフレームのなかで競合企業を意識しつつ差別を図る「相対アプローチ」ではなく、その企業ならではの信念や理念にもとづいた「絶対アプローチ」が必要なのだという。

業務システムを生業にしているIT企業でこの「絶対アプローチ」を実践している会社は何社あるだろうか。同じようなパッケージをちょっとした機能の差で差別化していると主張したり、よそよりも早く開発できますよと喧伝するソフトハウス、最新の技術要素が入っていますよと叫ぶソフトウエアは「相対アプローチ」であり、もはや時代遅れなのかもしれない。

さらに、いま言っているのは「ビジョン型であるが、もうひとつ「スピリッツ共感型」とういうのもこれから注目されるという。典型的な例があの大型バイクのハーレーダビッドソンである。熱狂的な愛好者が支えるパターンである。これは、ITではコンシューマー向けの製品にはある。アップルが代表的なものであろう。しかし、MacBookやiPod、iPadを思うように、SAPに愛着を持つ人がいるだろうか。
　　

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)

posted with yusukebe.com::AmazonSearch on 2011.9.19

• 博報堂ブランドデザイン
• 新書 / アスキー・メディアワークス
• Amazon 売り上げランキング: 5334

Amazon.co.jpで詳細を見る

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

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

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

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

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

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

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

ビジネスの世界に“勘”を持ちだすことはありえない。ちゃんとした調査データをもとにして、論理的に詰めた合理的な結果が尊重される。しかもそれを明確な言語として表現されなければいけない。しかし、本では本当にそうだろうかと問うている。

前回も生活者が本当のニーズを自覚していないという話をしたが、同じように定量調査からの数字データは本質的なニーズに切り込めないのである。ハーバードビジネススクールのジェラルド・ザルトマン名誉教授によると、人間は頭のなかにあることのうち５％程度しか言語化できず、残りの９５％は無意識下におかれたままだそうだ。といういことは、「ニーズ」も９５％は無意識、つまり自覚されていないと言えそうだ。

となると、無意識の部分、つまり“勘”のようなことが重要になってくる。吉本武史氏によると勘とは、身体的な経験やノウハウがありながら言語化できない状態を指すのだそうだ。「判断に迷った場合は、無意識に訊いてみるほうが結果として判断を誤らないことが多い」、つまり最後は“勘“だということである。たしか、あの前サッカー日本代表監督の岡田武史も同じことを言っていた。

このことをIT業界絡みで考えていくと、2つの課題が見えてくる。ひとつは、ユーザの無意識下に置かれたニーズをどうやって引き出すのかという問題と、もう一つは業務システム上に“判断に迷った場合は、無意識に訊いてみる”仕掛けをどうやるのかということである。

前者の問題では、システム開発の局面で要求定義を今はどうしても「論理、言語重視」的なアプローチになっていやしないだろうかということである。簡単な例では、現状調査と称して定量的な数値を図ったり、きちっとしたワークフローを定義したりする。コンピューターは論理を示さないと動かないからそうなってしまう。

しかしながら、本来は数値化が難しいはずの人間の行動に、科学的なアプローチをもちこもうとすると限界があるように思う。客観的事実だと思っていたものは多くの場合解釈の結果であり、じつは主観的なものなのである。だから、できたシステムを使うとそんなに簡単に割り切れるものではないよとか微妙に違うんだなとか嘆かれたりする。

だから、これからは「文脈、非言語重視」、つまり言語化できない暗黙知を捉える方向へ重心を移したらよい。本では、ビジネスエスノグラフィーが注目されていると言っていて、エスノグラフィーとは「民族誌学」のことで、「フィールドワークによる観察」と「解釈」によって、他者を理解しようとするアプローチである。この態度は要求定義にも適用したらいいと思う。

後者の問題は非常に難しい問題である。システムの中に“勘”でタスクを実行するような機能をどう埋め込むかであるから、実にITの対極にある話である。勘とは、身体的な経験やノウハウがありながら言語化できない状態であるから、勘を働かすことができるための情報を的確に提示することかもしれない。

あるいは、人間はイメージ（映像）やメタファー（比喩）によって思考すると言われるように、そうしたイメージやメタファーの力を借りるというのもあるかもしれない。それと、業務にもストーリーやコンテクストを取り入れてパターン化するという手もありそうだ。起承転結からなるストーリーはプロセスであるという意味でプロセス志向のねらうところでもある。
　　

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)

posted with yusukebe.com::AmazonSearch on 2011.9.19

• 博報堂ブランドデザイン
• 新書 / アスキー・メディアワークス
• Amazon 売り上げランキング: 5334

Amazon.co.jpで詳細を見る

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

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

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

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

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

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

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

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

例えば、旅行を企画するとしましょう。あなたは、旅程を細かく決める派ですか、それともなりゆき派ですか。前者のように綿密に計画を立て、だれもが行く場所とか、定番の名物を食べるとかするとある程度の満足感は得られますが、それで楽しいでしょうか。

一方、後者の場合は全部はずれだったなんていうリスクもあるが、自由に行動することによって、思いがけない感動を得たり、すばらしい人との出会いがあったりする。どちらがいいのかということではないのだが、これからのビジネスを考えるとき、楽しさとか気持ち良さのような価値が注目されるようになるとどうも後者のようなアプローチが大切になるのではないでしょうか。

本では「ソリッドプロセス」から「フレキシブルプロセス」へという言い方で柔らかな発想を提案している。従来のプロジェクトマネジメントは後者型で市場調査を綿密に可能な限り精緻なゴールイメージを描いて進めているし、PMIが策定したPMBOKなんかもそうした「ソリッドプロセス」を推奨している。

作るものがはっきりしているものと、モノやサービスを考えながら、これから生み出していこうというケースではやりかたが当然違っていて、ITで考えてみると、プロダクトや組み込みソフトなんては比較的ゴールが見えているので「ソリッドプロセス」ですが、サービスシステムなんていうのは、はっきりとしない場合が多いように思う。

業務システムというのもある種のサービスシステムだから、「フレキシブルプロセス」でシステム構築したほうがよさそうだ。ところが、特に従来型のウオーターホール開発なんていうと、きっちりとアウトプットを定義して作るし、パッケージなんかも見え見えのゴールを持ってくるわけである。

最近のアジャイルなんかもそうだが、デザインの世界でもIDEOが言っている「プロトタイプ発想」だとか、「ベータ版」の考え方などのように、ゴールを決めないで完成形をリリースするのではなく、完成形をめざしてつづけるというアプローチが重要になってくると思う。開発者と使用者が一緒になって、ワークショップのような形態をとりながらこうしたアプローチで作り上げていくことが主流になるのではないでしょうか。

別の角度から見てみると、業務システムの中にも同じような考え方を注入する必要がでてくると思う。つまり、業務そのものも「ソリッドプロセス」から「フレキシブルプロセス」へと転換させるのである。フローやルールといったものを固定して、その通りに遂行するのではなく、案件や条件変更にそれこそ動的に対応していくイメージだ。

もちろん全部がそうだと言うわけではなく、ERPはソリッドプロセスでいいわけだが、顧客接点のサービスプロセスでは、多様なお客さんにきめ細かく応対しようとしたら、「フレキシブルプロセス」にしないといけないのである。苦情が来ていつも決まりきった答えしか返さなかったらどうなるかを考えたらわかるでしょう。

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)

posted with yusukebe.com::AmazonSearch on 2011.9.19

• 博報堂ブランドデザイン
• 新書 / アスキー・メディアワークス
• Amazon 売り上げランキング: 5334

Amazon.co.jpで詳細を見る

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

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

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

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

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

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

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

本では、従来のマネジメントにおいては成長期ではトップダウン型の組織運営が主流だったのが、成熟期に入るとなかなかイノベーティブなアイデアが出てこなくなって、そうした状況を打破するために現場の視点や若手の発想に期待してボトムアップ型に移行する企業が多くなったと言っている。

そうだろうか。日本ではずっとボトムアップ型、せいぜいミドルアウト型が主流でトップダウンは少ないと言われたと思う。ただ、イノベーションを起こすような、あるいはトップランナーはだいたいがトップダウン経営であったのではないでしょうか。ですから、成長期はボトムアップ型でも十分戦えたのが、成熟期では生き残れなくなってきたというのがぼくの見立てなのだがどうだろうか。

ただ、トップダウンとボトムアップという二元論ではないと言うことである。上下の関係ではなく横の関係を強化せよということで、それが管理型組織から共創型組織へということになる。確かに上意下達的な動きだとか、現場の改善といったものではクリエイティブなことは難しいであろう。トップダウンでもなく、ボトムアップでもないハイブリッド型の組織が望まれるのである。

システム開発のエリアでも同じことでウォーターフォール型の開発はトップダウン的であるが、最近のアジャイルだとか、ウエブ系の開発者がやっているような開発形態は共創型組織である。コラボレーション型あるいはネットワーク型とも言えるやり方である。この方が、みんなの知恵を生かす集合知を得やすいのである。

ただ、ビジネスの社会ではそう簡単に共創型組織に移行できるわけではない。特に大企業ではアメーバみたいに組織が乱立されたら困ってしまうわけで、もう少し緩やかな形が現実的だろう。それに対して提案されているのが「「ビジネスワークショップ」とか「ビジネスキャンプ」と言われるものである。数十人程度のメンバーが集まり、参加者が自発的に発言したり、発想したりしながら一緒に課題の解決に取り組むというスタイルである。

これは、社内だけに限らず会社間、更に異業種の会社と、あるいはお客さんと一緒になったワークショップなどがこれからは盛んになってくるかもしれない。TPPの話を持ち出すまでもなく、タコつぼから抜け出していかないと取り残されていくのは明らかなのだから、開かれた世界を作り出していくことが肝要である。

こうした動きに対してITはどうしたらよいのでしょうか。ひとつは先ほど言ったようにトップダウン的な開発形態ではめまぐるしく変化するビジネス環境に追随できないからアジャイル的な開発に持っていかないとビジネス側から不満が飛んでくるはずである。また、共創型ビジネスを支援するための仕組みをどう構築するのかという課題も生じている。

みんなの知恵が出しやすい場をつくるとか、知恵の集合をアーカイブする、あるいはメンバー同士のコミュニケーションを活発化させるとかいった機能を充実させる必要があると思う。このあたりは、ウエブサービス系の世界ではすでにかなりのところまで実際にやっているので大いに参考にしたらよいと思うのである。

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)

posted with yusukebe.com::AmazonSearch on 2011.9.19

• 博報堂ブランドデザイン
• 新書 / アスキー・メディアワークス
• Amazon 売り上げランキング: 5334

Amazon.co.jpで詳細を見る

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

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

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

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

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

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

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

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

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

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

会社の中や仕事をしているとき、家庭を仕事にもち込むなとか個人的意見を言うな、趣味を仕事にするなとか言われます。当たり前のように思いますが、はたしてそうだろうかと疑問を呈しています。従来のような「公私分離」から「公私混同」してもいいのではという提言である。

つまり、いまは企業に必要なことは、改善や工夫を重ねて精度と効率を上げていくことではなく、生活者に「しあわせ」をもたらすことであり、そのためにはこれまでの延長ではなく不連続の連続といった発想の転換、イノベーティブなアイデアが求められているのだ。その一つは論理性、合理性だけではない、前に「「勘でものをいうな」がもたらす損失」でも言ったように勘や暗黙知を重視すべきときなのかもしれない。

仕事にかかわる世界だけで発想しようというやり方には限界がある。どうしても、決まりきったルールの中でしか考えないとか、ずっとこうやってやってきたからという頭を変えられないのである。そんなとき、そこから抜け出た世界、つまりプライベートな世界を取り入れることでずいぶんと景色が変わると思う。こうした“越境”を大いにやったらいいと思う。

このことは、「IT再考」という記事に書いた「遊び心」にも通じることで、そのうち「公私混同」の情報システムが現れてくるのではないでしょうか。人間は頭のなかにあることのうち５％程度しか言語化できず、残りの９５％は無意識下におかれたままだということだから、言語化できない知識や情報の共有がおろそかにしてはいけないのだ。

昔はこれを赤提灯だとか職場慰安旅行やたばこ部屋でやっていたのだが、ビジネス的で公的な部分ばかりを強調したため、それらがだんだん無くなって、すなわち私的な部分の発露を封印するようなかたちでつまらない職場になっていった。さらに、組織やチームとしての創造性もまた失われていった。

では、「公私混同」の情報システムってどうなるのだろうか。飲みニュケーションをシステム上でやるというわけにはいかないが、システムを使って協働で業務を行っている中で、多少の私的な会話をいれてみるとか、その仲間と仕事の後居酒屋に行くとか、自由なコミュニケーションができるといいかもしれません。

結局、業務に参加しているメンバーが義務的にやらされているのではなく、自ら積極的に関与して、より良くしようというマインドを持てるような場をITが提供できるかだと思う。「仕事にプライベートをもち込む」というのは、好き勝手なことを言ってもいいんだということではなく、「I think that・・・ 」と言えることだとぼくは思う。

自分はこう考える、私はこう思うというのをどんどん発していけるようにすることが大事なのである。会議で、あるいは社内メールでわざわざ「これは個人的な意見ですが」と断りを入れなくてもすむようにしたいものです。ぼくの言う“Collaborative Workspace“とはそんな雰囲気を想っているのです。

これでこのシリーズを終えるが、普段常識だと思っていることを不思議がり、再設定してみるということと、今自分がいる世界とは違う世界からの考え方とか意見を取り入れることで一旦既成のフレームを壊してみることも大事であることを言いたかったのである。
　　

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)

posted with yusukebe.com::AmazonSearch on 2011.9.19

• 博報堂ブランドデザイン
• 新書 / アスキー・メディアワークス
• Amazon 売り上げランキング: 5334

Amazon.co.jpで詳細を見る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ちょっと前のITmediaの記事に「中小企業のIT化、スマホやクラウドに注目集まる――矢野経済研究所調べ」というのが載っていた。目にしたとき思わず“ウソでしょう“と叫んでしまった。中小企業の人がそんなことを思っているのかと驚いたのだが、案の定調査の対象がソリューションベンダーであった。

調査は2011年9月から11月にかけて、中小企業のIT化について実績がある全国のソリューションベンダーを対象に実施したものだそうだが、これは事実ではなく単なるベンダーの願望でしょう。最近はIT投資が減速しているから、比較的未開拓である中小企業を攻めようとしているようなので、煽っているだけのように思える。

このところ中小企業のIT化に関係することが多く、実態がけっこう見えてきているのだが、中小企業の7割にスマホの需要があるとは思えない。何のために、何を見たいからスマホを使うのだろうか。その前に会社のパソコンで何をみているのだろうか。中小企業のパソコンの普及率は高いが使っているのはメールとExcelなのである。ちゃんとしたシステム化ができていないのにスマホもへったくれもない。

クラウドについても「有効である」「今後は有効である」を合わせると95％のベンダーが有効性を認めているという。これも、クラウドだとかSaaSという前にやることがあるでしょうと思う。どうも、はやりのデバイスだとかサービスに飛び付くのだが、肝心の元のシステムが未整備だと、いくら高機能のものをもってきたところで何もならない。

そして、何でも中小企業をひと括りにして語るのも間違いである。昔からの町工場みたいなところから、若い子が立ち上げたIT企業みたいなものまで千差万別であり、さらに経営者の質でも大きな違いがある。進取の精神に富んだ意欲的な経営者とか、冒険はしない堅実派の経営者とか、親から譲られたけどやる気はない2代目とか様々なタイプがある。

ただそうであっても、共通的に言えるのはビジネス環境が大きく変化している中では何らかの形でITを活用してオペレーションの効率化や経営の高度化をしないと生き残れないということである。その時、中小企業においてはまだまだ基幹の業務システムの整備ができていない。かろうじて決算ができているという会社が多いのではないだろうか。

そんなところに、クラウドだとかスマホといっても猫に小判となると思う。ですから、いま中小企業に求められているのは、本当の意味で基幹となる、お客さんを獲得して、注文をもらい、商品やサービスを届け、代金を回収する業務プロセスをきちんと設計し、日々のオペレーションに供することが第一義であるように思う。
ここがちゃんとできて初めて、経営者が自社のビジネス活動の実態を把握でき、現場では日常業務を円滑に回せることができる。ソリューションベンダーというからにはこの領域のソリューションを提供するのが使命ではないだろうか。それとも“ソリューション”というのはどういうITを使ったらいいかという解決策を提示することなのだろうか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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