メイン

IT雑感 アーカイブ

2006年10月29日

読みかけの本

「シネマと書店とスタジアム」と言っておきながら、本の話が出てこない。別に本を読んでいないわけではなく、最後まで読んでいないのだ。要するに読みかけのままで置いてあるということだ。まず、福田和也が「悪の読書術」で絶賛していたので白州正子の「遊鬼―わが師わが友 」を読んだのですが、ちと高度な教養や美の世界にはついていけない感じで止まっています。

それと実は村上春樹なんです。えっと驚くと思いますが、村上春樹が読み切れないのです。あの分厚い京極夏彦の「鉄鼠の檻」も読めるのになぜなんだ(意味が違うか)。 それで、息子から文庫の「風の歌を聴け」を借りて読んだのだが、どうも以前読んだことがあるなあと思いながら読み進めたが途中で止まった。そうなんです、これが面白いことにふと自分の本棚をあさっていたら、同じ本が出てきたのです、しかもちょうど途中でやめたと同じところに頁の折り返しがあったのです。そうなんですね、数年前も同じところでやめているんですね。

それでどうしてなんだろうかといろいろ考えてみて思い当たったのは、同じ世代であることじゃないかと思い至ったのです。どうしてそう思ったかというと、ちょっと前に上原隆と関川夏央の本を立て続けに読んだのだけど、あまり気持ちよくなかったのです。実は彼らも同じ団塊世代の作家で、読んでてホントよく分かるんです、そうだったねそういうこともあったよねという感じになるが、また同時にその当時のいやだったことや恥ずかしかったことなどが思い出されてくるわけで、なんとなく嫌な気分になるというわけです。と言いながら沢木耕太郎も同世代です。ただ「シネマと書店とスタジアム」は評論みたいなものだから情緒的でないところで受け入れられるのです。だから「深夜特急」は読んでいないのです。少し意識しすぎているのかもしれませんが団塊世代の作家の本は苦手ですね。

昨日やっと読み終えた本が出てきて、もう気楽に読める本ということで奥田英朗の「延長戦に入りました」です。これはスポーツに関するエッセイですが、普通のスポーツエッセイとはちがって、著者があとがきで”冗談の通じる人には最良の爆笑本だと信じています”言っているように変なネタで大いに笑わせられる。たとえば、傑作だったのは「ボブスレーの2番目の選手は何をしているのか?」のコラムなんか抱腹絶倒ものですよ。奥田英朗は、「インザプール」「空中ブランコ」「邪魔」「最悪」というところを読んでいますがホント面白いです。冗談好きのあなたにお薦めです。

ところで、「最悪」を読んだと言いましたが、正直言うとこれまた読みかけで置いてあるのです。なぜって、この本を読んでいるとき、人生最悪のことが続けて起こったんだもの。

2007年8月21日

デモは説得力がある

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

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

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

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

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

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

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

2007年10月17日

システムショック

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

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

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

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

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

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

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

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

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

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

2008年7月17日

アマゾンモデルの意味すること

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

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

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

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

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

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

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


2008年8月 8日

ITの品格

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

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

(1)「納得感」のあるIT
・ 自分が顧客であるなら、喜んで自社の商品を買える
・ 自分のITを親しい知人に勧められる
(2)「使命感」のあるIT
・ ITによる「自己実現」「社会との接点を持つ」ことができる
・ 自分のITに、「命」を「使う」ほどの価値を、一人ひとりが求め、実感している
(3)「効力感」のあるIT
・ 自分の個性や創造性が発揮できるITであること
・ 個人に選択の余地があるIT
(4)「普遍性」のあるIT

・ その組織の中でしか通用しない特殊スキルではなく、社外でも通用する「普遍スキル」を身につけらえる
・ ITで、スペシャリティやプロフェッショナリティの向上を感じられる
(5)「貢献感」のあるIT
・ 自分のITが、どんなふうに会社の役に立ち、それが社会につながっているかがわかる
・ 誰かに貢献している実感、相手からありがとう!と言われる喜びがある
(6)「季節感」のあるIT
・ 心機一転、心が改まる機会がある
・ 「おかしいことを正そう」「挑戦しよう」などの積極的な変革姿勢が生じる

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

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

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

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


2008年9月 4日

違いを知ること

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ということになる。
 

2008年12月 1日

IT革命を身体で感じた世代

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

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

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

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

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

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

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

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

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

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

2009年1月19日

雇用の流動化

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

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

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

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

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

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

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

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

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

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

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

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

2009年2月11日

クラウドの衝撃

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

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

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

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

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

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

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

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

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

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

2009年6月25日

再びビジネスとITを語ろう

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

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

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

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

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

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

2009年6月26日

ビジネスの言葉で考える

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

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

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

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

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

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

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

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

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

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

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

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

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

2009年6月30日

要件定義の定義

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2009年7月 9日

システム化再考

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

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

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

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

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

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

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

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

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


2009年7月10日

紺屋の白袴にならないために

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

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

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

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

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

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

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

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

Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド
posted with yusukebe.com::AmazonSearch on 2009.7.10
  • 菅野 裕 今田 忠博 近藤 正裕 杉本 琢磨
  • 大型本 / 技術評論社
  • Amazon 売り上げランキング: 30472
  • Amazon おすすめ度の平均: 5.0
    • 5 プロジェクト管理の必須本
    • 5 入門から実務まで
Amazon.co.jpで詳細を見る

入門Subversion―Windows/Linux対応
posted with yusukebe.com::AmazonSearch on 2009.7.10
  • 上平 哲
  • 単行本 / 秀和システム
  • Amazon 売り上げランキング: 49625
  • Amazon おすすめ度の平均: 4.5
    • 5 Subversionを使えるようになります。
    • 5 初心者には適した解説本
    • 4 個人から小規模の開発用途までに必要十分な内容
    • 3 概念を学びたい人には適してます。
    • 4 バックアップツール
Amazon.co.jpで詳細を見る

2009年7月20日

企業IT力向上研究会

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

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

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

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

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

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


2009年8月10日

企業におけるプロセスの種類

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

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

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

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

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

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

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

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

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

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

2010年1月24日

IT産業と規模の経済学

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

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

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

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

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

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

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

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

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

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

2010年1月27日

Enterprise Ontology

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

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

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

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

第一部の理論編は最初が哲学的な話なのでついていくのに苦労したが、実践論に入るとわかるわかる、いちいちうなずいてしまった。これまで、このブログのIT関連の記事を読んでくれている方は認めてくれると思うが、以前から主唱していることを裏付けてくれているように感じているのである。その概念を表している図(ぼくが勝手にコンパクトにまとめた)を次に示す。
ontology.bmp
これをみるとおわかりだと思いますが、Infological(計算や加工といった意味を付与を行う処理)やDatalogical(データ転記のような単純処理)のような活動ではなく、その上流(というかビジネス寄り)にあるOntologicalのレベルでもモデリングが大事であり、そこをきちんとやろうよということを言っています。ぼくが言っているマクロプロセス(フロー)のところです。

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

2010年1月28日

Enterprise Ontology(つづき)

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

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

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

ここで、前回のOntological aspect modelの三角形をもとに実際のモデリングの方法について、どんな成果物を作ればいいのかという見方で図示したものを掲げる。より具体的でわかりやすいと思います。
ontology2.bmp
ただ、Dietz教授の前に発表していた専修大学の小林教授によれば、DEMOの骨の理論であるLAP(Language/Action Perspective)を作った有名なTerry Winograd スタンフォード大学教授の言として、Ontolpgyを活用したモデリングは現在けっして主流ではないが、そのうち認知されるようになるだろうと予想していると言っていました。

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

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

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

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

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

2010年3月22日

重層構造から見えるもの

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

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

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

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

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

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

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

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

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

2010年4月 2日

業務システムの作り方が間違っている

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

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

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

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

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

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

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

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

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

2010年4月19日

IT雑感-IT投資効果

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

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

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

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

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

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

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

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

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

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

2010年4月27日

IT雑感 -自治体業務の構造-

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

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

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

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

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

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

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

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

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

2010年4月28日

IT雑感 -自治体業務の構造(続き)-

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

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

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

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

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

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

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

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

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

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

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

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

2010年5月 6日

IT雑感-技術の伝わり方

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

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

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

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

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

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

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

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

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

2010年5月11日

IT雑感-Webの恩恵

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

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

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

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

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

 1) 双方向コミュニケーション
 2) オンデマンド
 3) ハイパーメディア

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

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

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

2010年5月14日

IT雑感-研究課題

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

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

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

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

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

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

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

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

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

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

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

2010年5月30日

IT雑感-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産業にいる人の中にもそう言っているひとがいる。

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

2010年6月 9日

IT雑感-保険屋とIT屋

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

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

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

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

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

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

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

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

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

2010年7月14日

ITマジカ!

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

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

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

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

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

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

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

2010年7月16日

IT雑感-ドコモのCM

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

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

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

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

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

2010年8月 1日

情報システムについての誤解

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

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

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

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

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

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

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

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

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

ダメな“システム屋”にだまされるな!
posted with yusukebe.com::AmazonSearch on 2010.7.30
  • 佐藤 治夫
  • 単行本(ソフトカバー) / 日経BP社
  • Amazon 売り上げランキング: 59987
  • Amazon おすすめ度の平均: 5.0
    • 5 身につまされる想いがあります
    • 5 全てのシステム屋システム開発企業経営者は一読を!
Amazon.co.jpで詳細を見る

   

2010年8月 7日

ツイッタ―再考

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

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

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

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

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

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

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

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

2010年8月21日

管理プロセスのワナ

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

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

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

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

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

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

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

2010年9月 5日

~第2期  SI事業者向けBPM実践ワークショップ(3回シリーズ)

日本BPM協会主催の標記ワークショップが開かれます。前回好評だったので第2期となります。BPMが普及していくと、だいぶ開発の様相も変わってきます。従って、SI事業者もこれまでのやり方を変えていかざるを得ないと思います。

そのためには、BPMとは何ぞや、実践をどうしたらいいのかといったことを学ぶことが大事になってきます。このワークショップでは、事例の紹介とかディスカッションが取り入れられていて、実践的な研修となっていますので、ぜひ受講されることをお勧めします。申し込みは、下記サイトからです。

日本BPM協会「SI事業者向けBPM実践ワークショップ申し込み

2010年9月11日

金魚すくいの作法から

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

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

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

(1) ポイは斜めに入水させ、水中では水平に移動させる
(2) 金魚は頭から追え
(3) 尾ひれは外せ

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

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

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

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

2010年9月13日

ほんとうの情報活用

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

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

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

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

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

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

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

2010年9月16日

デジタルクリニックのすすめ

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

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

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

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

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

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

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

2010年9月20日

“場”という概念

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

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

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

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

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

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

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

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

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

2010年11月18日

紺屋の白袴

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

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

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

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

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

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

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


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

2010年12月 1日

モデル化の必要性とモデルのワナ

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

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

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

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

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

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

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

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

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

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

2010年12月 6日

Web技術の活用の前に

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

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

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

(1)双方向コミュニケーション
(2)ハイパーリンク
(3)オンデマンド

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

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

(1)コミュニケーションの“場”の提供
(2)オープン性
(3)アジリティ

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

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

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

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

2010年12月 9日

フレーミング

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

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

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

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

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

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

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

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

2011年1月 6日

中小企業の情報化の課題(1)

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

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

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

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

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

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

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

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

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

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

2011年1月 9日

中小企業の情報化の課題(2)

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

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

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

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

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

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

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

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

2011年1月13日

中小企業の情報化の課題(3)

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

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

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

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

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

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

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

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

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

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

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

2011年1月19日

なぜiPhoneやiPadにはマニュアルがないのか

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

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

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

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

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

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

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

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

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

2011年1月25日

ホーレンソーはもう古い!?

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

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

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

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

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

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

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

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

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

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

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

2011年9月10日

クラウド考

(1) クラウドとは何か?

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

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

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

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

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

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

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

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

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

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

(2) クラウドのサービス

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

一方、構成要素で見て行くと、○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を使って素早く立ち上げた。ほんと数十分で稼働させられるという驚きである。また、非常に助かるのは、安価にそして容易にスケールアウトできることで、しかも時間オーダーでやめたりできるというすごいフレキシビリティである。

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

(3) 従来のものと何が違うのか

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

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

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

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

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

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

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

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

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

(4) クラウドでしかできないことは何か?

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

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

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

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

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

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

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

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

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

(5) クラウドと業務システム

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

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

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

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

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

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

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

(6) クラウド化するための要件とサービス

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

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

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

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

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

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

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

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

(7) 最後に

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

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

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

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

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

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

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

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

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

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

2011年9月29日

不思議前提とIT ― 「ターゲットにモノを売る」というまちがい

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

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

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

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

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

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

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

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

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)
posted with yusukebe.com::AmazonSearch on 2011.9.19
  • 博報堂ブランドデザイン
  • 新書 / アスキー・メディアワークス
  • Amazon 売り上げランキング: 5334
Amazon.co.jpで詳細を見る

  

2011年10月 6日

Gartner SYMPOSIUM Itxpo2011

いま、外ではセミが鳴いている。今朝の新聞では、岩手県の小学校の校庭で桜が咲いたという記事があった。どうなっているんだろう。季節が狂ってしまったのだろうか。でも、セミナーやシンポジウムは季節通り花盛りだ。今週も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つの方向で考えてほしいのであって、そこに登録するというインの考え方だけになっているが、一方でアウト、すなわち有用な情報が入っているデータベースからデータを取り出して参照するという機能が要るということである。また、プロセス管理というからには、プロセスの進捗が俯瞰できないと管理はできないのでステータス表示だけだと弱いのである。

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

2011年10月10日

不思議前提とIT ― 「差別化のポイントはどこ?」という不見識

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

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

その二つの危険性というのが、
1.すでに存在している商品やサービスと同質化してしまうこと
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で詳細を見る

  

2011年10月19日

不思議前提とIT ― 「差別化のポイントはどこ?」という不見識(余聞)

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

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

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

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

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

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

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

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

2011年10月27日

不思議前提とIT ― 「ニーズはなんだ?」と問うあやまち

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

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

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

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

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

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

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

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

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)
posted with yusukebe.com::AmazonSearch on 2011.9.19
  • 博報堂ブランドデザイン
  • 新書 / アスキー・メディアワークス
  • Amazon 売り上げランキング: 5334
Amazon.co.jpで詳細を見る

  


2011年11月 3日

不思議前提とIT ― 「勘でものをいうな」がもたらす損失

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

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

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

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

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

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

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

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

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

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)
posted with yusukebe.com::AmazonSearch on 2011.9.19
  • 博報堂ブランドデザイン
  • 新書 / アスキー・メディアワークス
  • Amazon 売り上げランキング: 5334
Amazon.co.jpで詳細を見る

  


2011年11月14日

不思議前提とIT ― 「どんなアウトプットが得られるんだ?」と問う不利益

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

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

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

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

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

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

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

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

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)
posted with yusukebe.com::AmazonSearch on 2011.9.19
  • 博報堂ブランドデザイン
  • 新書 / アスキー・メディアワークス
  • Amazon 売り上げランキング: 5334
Amazon.co.jpで詳細を見る

  


2011年11月20日

不思議前提とIT ― 「下から意見が出ない」という勘ちがい

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

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

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

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

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

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

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

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

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)
posted with yusukebe.com::AmazonSearch on 2011.9.19
  • 博報堂ブランドデザイン
  • 新書 / アスキー・メディアワークス
  • Amazon 売り上げランキング: 5334
Amazon.co.jpで詳細を見る

  

2011年11月29日

不思議前提とIT ― 「仕事にプライベートをもち込むな」という非常識

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

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

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

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

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

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

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

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

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

「応援したくなる企業」の時代 マーケティングが通じなくなった生活者とどうつき合うか (アスキー新書)
posted with yusukebe.com::AmazonSearch on 2011.9.19
  • 博報堂ブランドデザイン
  • 新書 / アスキー・メディアワークス
  • Amazon 売り上げランキング: 5334
Amazon.co.jpで詳細を見る

  

2011年12月 7日

中小企業のことをわかっているのでしょうか?

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

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

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

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

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

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

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

2012年3月12日

コア業務とノンコア業務

ちょっと前のITLeadersの特別レポートで、「【座談会】グローバル化担う企業ITの課題とIT部門が果たすべき役割」という記事があった。対談しているのは、カシオ計算機のCIOの矢澤篤志さんと、ITコンサルティングの桑原里恵さんで、司会進行が編集長の田口潤さんである。矢澤さんと桑原さんはご両人とも知っていますが、日本の情報システムの世界ではぼくは大変評価をし、尊敬している人である。

この座談会で大変有意義な議論がなされているので少し紹介しておこうと思う。お二人の意見が至極まっとうで的確なので参考になる。まずは、「「業務」に対する既成概念を変える」ということで、グローバル化とリアルタイム性に言及したあと、「ノンコア業務」と「コア業務」に話が行く。矢澤さんは、会計・購買、調達・物流、人事、EDI、コミュニケーションなどはノンコア業務でここは徹底的に標準化し、インフラは統合することが必要で、そこはERPを利用すればいいのだと言っている。

ところが、コア業務はどうなのかという話になって、桑原さんは、ノンコア業務はERPのデータフローで基本的にまかなえるが、そこにコアとなる「事業のシステム」の層を重ねる構造にしなければならないと指摘し、そこを履き違えて、直接ERPの機能に求めにいったために、全体が複雑化し、事業とのギャップが起こったのだという。

同じように矢澤さんも、ERPは当然ながらすべてカバーできると思っていたが、よくよく見てみるとERPには“幹線”しかなく、事業によって異なるサプライチェーンを担うという発想が元々ERPに組み込まれてないことを知ったという。コアとノンコアの仕分けが重要だという指摘である。コア=事業システム、ノンコア=企業システムという桑原さんの区分けも参考になる。

こうした議論はみなさんあまりしてこなかったように思うが、お二人の指摘はぼくが以前から言ってきたことと同じなので意を強くした。ただ、桑原さんとはもうだいぶ前にERP導入で一緒に仕事したことがあるのですが、その当時はまだここまではっきりとおっしゃっていなかったように思う。みんながERPに走ったこともあり、世の中の期待がいつのまにか実現できるものだと思いこんでしまった節がある。

ただ、矢澤さんのノンコア業務の分け方として会計や人事はいいとしても購買、調達・物流などは一部はコア業務に入ると考えられる。ですから、機能別に仕分けるのではなく、データ確定前後で分ける方がよいように思う。つまり、データが確定してそれを登録、格納し、集計やレポート化などの業務、すなわち決算系の業務とリソース管理系をノンコアと位置付けたいのである。まさにERPのやっていることである。

ただ、コア業務の重要な要素は「プロセス」なのであるが、その議論はなかった。いずれにしろ、日本のITベンダーやシステム屋さんたちはまだまだERPを基幹業務(コア業務)だと思っている人がけっこういるが、ここでの議論のように、他社と差別化なんてできないものがコアであるわけがない。早くこのことに気がついて真のコア業務を見極めてそこに資源を投入していかないとグローバル競争に負けてしまうだろう。
  


2012年3月29日

「しこう」のすすめ 

ITに関して感じたことをIT雑感として別のブログで書いているが、こちらの方に載せることにする。もう一方の方は主にテクニカルな話にしようと思う。さて、今回は「しこう」ということについて書いてみる。仮名で書いた意味は、いろいろな漢字に当てはめて考えたいからである。

ITをうまく使って役に立つ業務システムを構築するのがぼくのミッションだと思っているので、そこを「しこう」という言葉を使って表現してみる。よくオブジェクト指向とかデータ志向アプローチとかが出てきて、「指向」と「志向」の違いって何だろうなんて考えたのがきっかけである。たいしていい思いつきでもないのだが、たまにはこんなお遊びもいいのではないでしょうか。

プロセス「志向」で業務をながめ、柔軟な「思考」でよく考えて、顧客の「嗜好」にあったシステムを、オブジェクト「指向」的な技術を用い、とりあえず早くプロトタイプで「試行」してみて、よしとなったら広く「施行」することこそが、「至高」の業務システム構築方法である。

強引にこじつけた風でもなく語呂合わせができたと思いませんか。「志向」と「指向」の違いがどうも「志向」には思いとかこころざしのような趣があって、「指向」は客観的、あるいは技術的といってもいいかもしれませんが、めざすべき方向性を言っているように思う。ですから、業務をプロセス中心、プロセス先行でみて行くというのは意志(意思ではなく)として持ちたいと思う。

ただ、お客さんの嗜好にあわせるということには異論があるかもしれませんね。嗜好という言葉の意味は「ある物を特に好み、それに親しむこと。好み。」とある。顧客の好き嫌いで作るものを変えていいものだろうかという意見である。確かにそういう面はあるのだが、“それに親しむ”というところに注目してみたらいかがでしょうか。

最近のスマホやiPADなどのITデバイスをみてもわかるように自分の気にいったものを買い、それを可愛がって使い回すということがユーザの態度である。ここのところはコンシューマ向けのデバイスやサービスという領域だけの話にとられがちであるが、これからはビジネスの世界、企業の中でも大事なポイントになってくるのではないでしょうか。

それと、「試行」から「施行」という流れも重要で、つまり早い段階で使うものを見せて試しに動かしてもらうことでさらに要求をだしてもらったり、確認してもらうことがますます必要になってくると思う。紙の上で設計書をみているより、まだ未完成でも動かしてみることの方が仕様がためが早いし、運用になってからの手戻りが少なくなる。

さてこうした業務システム構築のやりかたがぼくの「私考」にとどまることなく、多くの人が取り上げてくれたら、ぼくは「至幸」を感じるのである。
  



2012年4月12日

【IT雑感】取り残されたプロセス目線

コンピュータが登場してからもうだいぶ経つわけですが、このコンピュータを搭載したITが様々なところで人間がやっていたことを代替してきました。ほとんどがこの代替機能であったということが言えると思います。ですから、システム化という表現もするのですがITがあったからシステム化できたというより、もともとあった人間のやっている”システム”の一部をITで代替しているというほうが当たっているように思います。

つまり、人間がやるよりも早くできるとか、より多くの処理ができるとか、より高度な計算ができるとかといった効率化が主でした。さてそういった代替はどんな場面で起こってきたのでしょうか。コンピュータの元々の使い方は“電子計算機”ですよね。つまり、そろばんや電卓の替わりに高速で大量の計算をやってくれるものとして登場したわけです。

そして30年近く前のころは、経理部電算課という名前があったように経理の人たちがそろばん片手に決算をやっていたのをコンピュータがやるようになって格段に決算業務の効率化が図られました。様々な事業、業務から発生した仕訳データを集約して、格納して加工して会社の成績をはじき出すことをしていました。

その一方で、個人の労働生産性向上ツールとコミュニケーションツールとしての位置もだんだんと確保していきます。前者の代表はマイクロソフトオフィスで、後者は電子メールです。それに加えるようなものとしてグループウエアやインターネットといったものが入り込んできました。

手書きで書いていた文書や表がITツールに置き換わっていき、電話やFAXに替わって電子メールが行き交うようになったわけです。さらに、キャビネットにあったキングファイルは少しづつ減り、手帳がITの中に収まり、ダイレクトメールやチラシがWebサイトとなってきました。こうして、計算機能と個人の労働生産性向上機能はITの恩恵を非常に受けて大きな進歩をとげたのです。

ところが、取り残されたところがあります。それがプロセスです。そこにコンピュータはどう入り込んでいるのかという観点でながめた時になかなか見えてこないのです。前にみたように従来のやり方はどうしていたのかを考えてみると、帳票に行き着きます。帳票というのは帳簿と伝票ですが、この場合は伝票のことになります。帳簿はストック表現で伝票はフロー表現です。

ですから、プロセスというのは伝票を回すことで成立していました。それがITに置き換わっているでしょうか。部長の机の上にある決裁伺い箱はなくなったでしょうか。いや、人事や総務に出す申請書なんてはペーパレスになっていますよと言われるかもしれないが、それは個人プレーのワークフローであって、ここでは組織としてのチームプレーのことを言っています。

伝票がなぜあるのかというと電子化されたシステム間をつなぐものとして存在しています。この電子化されたシステムというのはいまでもほとんどの場合データベースアプリケーションになっているので、その間の受渡しに伝票を使わざるを得ないわけです。

だいぶ前になりますが、SAP導入を先進的に行った会社にヒアリングに行った時の衝撃を今でも覚えています。最初はアドオンを極力避けたいということで始めたのに結果大量のアドオンが発生してしまうのですが、なんとその7割が帳票だというのです。ERPを入れても帳票が減らないのです。

ということで、どうもITがプロセス機能を代替してくれていないのが現状のような気がします。これまで取り残されてきています。ですから、大切なのは“真の伝票レス”の仕組みを作ることかもしれません。それがプロセス志向アプローチのめざすところなのです。
  

2012年6月19日

中小企業こそBPMを

BPM(ビジネスプロセスマネジメント)の必要性をずっと説いているのだがなかなか理解されないことも多い。説く相手は別に区別しているわけではないので、大企業でも中小企業でも、あるいはベンダーでもユーザーでも分け隔てはしていないのだが、最近特に感じることは、分かってくれそうなのが中小企業ではないだろうかということである。

以前「大企業と中小企業の違い」という記事のなかで、大企業の硬直した組織の問題を指摘したが、そうしたところへBPMを適用するのは大変だと思う。

その点、中小企業の場合は、組織の垣根もないし、経営者がやろうといえばすぐにできるというように柔軟性があるから適用への障害は小さい。そこで、もう少し掘り下げて企業規模とIT(情報システム)のあり方について考えてみたい。

情報システムというのは会社の組織を写像したものであるから、組織の構造の実態をみていくと情報システムがどうなるのか、どうすべきなのかがわかってくる。(ただし、組織を意識して情報システムを作れということを言っているのではありませんので注意してください)情報システムの形態を表現するのによく集中と分散という切り口を使うのでそこから組織も眺めてみる。大企業の組織は分散型で、中小企業は集中型であると思う。

大企業は、きちっと組織が分かれていて、ヒエラルキーもちゃんとしている。そうしないと大きな組織は運営できないからである。軍隊に近い組織が管理上は望ましいのである。ただそうなると縦割り組織の悪いところがでてきて、横の関係が薄れて個別最適を指向するので横断的な業務がスムーズにいかないことが多い。お役所が典型的である。

一方、中小企業は機能的には大企業と同じものが要求されるのに人数が少ないので、一人がかけ持ちして、しかも縦も横も見るので分散しようがなく集中というか、大きく括った組織にならざるを得ない。これはいいとか悪いとかということではなく、管理上いたしかたないのである。

そうした組織形態に対して情報システムはどうなるのだろうか。ここで情報システムと言っていますが、BPMの観点から考えていきます。単なるデータベースアプリケーションだったらどちらも同じです。ちょっと話はそれますが、何度も言っているように従来のようなデータベース主体の情報システムは、会社の強みも弱みも含んだ特徴を表現できていないから、大企業であろうが中小企業であろうが同じものにしかならないのです。

では、ビジネスプロセスという見方から考察すると、組織の形態とは逆の情報システムが望まれるのです。すなわち、大企業の分散的な組織に対しては集中型のビジネスプロセス、中小企業の集中型の組織に対しては分散型のビジネスプロセスというわけです。組織的な弱さをビジネスプロセスシステムが補うことでバランスさせるようにすべきだということです。

大企業というのは、どうしても縦割りの部門最適になってしまいますが、そこを横断するビジネスプロセスを構築して、そこに集約するように持っていくことが必要になってくるのではないでしょうか。まずは、各部門は自分たちの組織という意識ではなく、会社として、ビジネスとして活動しなくてはいけないビジネスプロセスに集中させて、その中で自分たちの役割をはたすということである。

一方中小企業は逆に、組織の中で人に仕事がついていってしまう弊害をなくすために、いったん属人的になっている業務を人からひきはがし、客観的なビジネスプロセスに落とし込むことが大事になってきます。つまり、人に、特にできる人に集中していた機能を分散させることが必要です。こうして、ビジネスプロセスは分散したものにしておき、その中のアクティビティを割り振るわけですが、その時かけ持ちしてもかまいません。

重要なことは、組織や人に依拠しない乾いた眼で整理されたビジネスプロセスをみるというアプローチでシステム構築をすることです。そうすれば、できたプロセスを誰がどうオペレーションするかは、その会社の規模や形態あるいは組織構造で決めていけばよいのです。順番を逆にすると、組織に依存したシステムが作られ、例えば組織変更や事業統合などが行われた時に、そのたびにシステムの大きな変更を余儀なくさせられるということになる。結局、組織が分散だから集中型のシステムがよいというのではなく、普通に組織に依存しないビジネスプロセスを書いたら、組織形態の弱さを補正するように働くということだと思う。

プロセス志向アプローチの最大のメリットはここにあるのだが、最初に戻るのだがそれを実行してくれるかどうかが問題。どうも集中させるより分散させる方が効果的で簡単そう(既得権益を守ろうということもない)なので中小企業の方がBPMを適用しやすいと思うのである。
  

2012年6月21日

サッカーも業務システムもミッドフィルダーが重要

ちょっと前にサッカーのレベルについて記事にしたが、そのときレベルが低いとボールのところに集まってそこからわあっと運んでいく、また中盤を省略してロングボールを蹴り込むといった話をした。ぼくは、選手時代はほとんどが中盤をやっていたが、いちばんつまらないのが自分の頭越しにボールが行き来するときである。こんなときはつまらないと同時にたいていは負け試合となるのである。

なぜかというと、単調なので相手が守りやすいこと、多くの選手を生かしきれないので戦力的に損をすることだろう。やはり、中盤できちんと組立て多くの選択肢の中から最適解をみつけていくというのが正しいのだろう。そんなことを考えていてふとこれは業務システム同じだなと思ったのである。

会社の業務機能をみてみると、フォワードとは、営業、商品開発者、安価調達者、人材採用者、製造者、出荷担当であると思う、すなわち、モノを売ったり買ったり、作ったりといったことで得点を稼ぐところで、ディフェンダーというのは、経営管理、経理、資金調達、法務、税務、リソース管理部門の人たちといったところかもしれない。それではミッドフィルダーは誰だ。

あれえ、そういう人たちはいないのだろうか。どうも、人がいるかいないかは置いといて、そうした機能がおろそかになっているように思えてくる。つまり、中盤を省略して、仕事が進んでいやしないだろうか。ミッドフィルダーの頭の上を行ったり来たりしてやしないだろうか。組織としての組み立てに問題があるように感じるのである。

このことは業務システムを見てみると明らかになる。業務システムは組織を写像するから、中盤の仕組みが見当たらないのである。フォワードには、CRMだとか、SFAだとかグループウエアだとかがあり、バックスとしてはERPや会計パッケージがあるが、その間を埋めるものが少ない。

いやちょっとまってください。フォワードってちゃんとしたものがあるのだろうか。競争相手に競り勝って得点を稼ぐようなシステムが整備されているのだろうか。それはそれとして、これからはフロントとバックヤードをつなぐミッドフィルダーをきちんと置き、ビジネスあるいは業務プロセスをちゃんと組み立てて実行することが望まれる。ただ、これを階層を増やし、余計な部署を置くというふうには考えないで機能として持たせるようにすればよい。

ビジネスはスポーツだとまでは言わないが、団体競技としてのサッカーをみているとシナジーがいろいろあるようで学ぶことが多いのである。
  

2012年7月 5日

やぶにらみIT論

「IT断食のすすめ」(遠藤功、山本孝昭著 日経プレミアシリーズ)という本の書評で「仕事ができない、あるいは仕事をしていない人がPCで遊んでいるだけなのでその人たちに断食させても影響がない」というちょっと辛辣な表現をしてみたのだが、よく考えてみるとそれは辛辣でもなんでもなくて、ある面事実でははないかと思うのである。

この論旨は、本では電子メールとインターネットと個人の机上PCがIT中毒を生んでいてそのために本来の仕事ができなくなっているというトーンなのだが、だからといって断食してITから離れればもっと質の高い仕事ができるのかというとそんなことはありませんよということである。

「ウェブはバカと暇人のもの」(中川淳一郎著 光文社新書)という本もあったように、たしかに暇だから使う面は否めない。つまり、企業のなかでIT中毒が蔓延しているとすると、バカが増えたわけではないが、暇人が増えたということになる。これは実に皮肉なことである。IT化が進んだ結果、暇人が増えて、その暇人がやることなくて机上のPCで遊んでいるということではないか。

いまPCでメールやネットで遊んでいる人の数と時間をPCがなかった昔に当てはめるとどうなってしまうのだろうか。それだけの人が、それだけの時間、新聞を読んでいたのだろうか。そうなんですね、昔は暇な人が少なかったのだ。で、そこから大幅なホワイトカラーの削減が行われたわけではないので、少ない人数で仕事がこなせるようになったのである。これってITのおかげでしょう。

だから、とりあえずはIT化の効果はあったということが奇しくも証明されたというわけである。と変な話ということで終わらせてもいいのだが、最初に言ったように暇な人にIT断を進めても無意味だから、ならばいったいどうしたらよいのだろうか。IT中毒にならないような状態をつくるにはどうしたらよいかである。

今は自分の机上のPCとにらめっこしていると仕事をしているように見えるし、自分も仕事している気になってしまう。そうした状況が許されるのは、必須の業務の一部がそうしたやり方でやっているからである。大事な仕事もどうでもいいことも同じようなやり方、すなわちPCに向かってメールとExcelとパワーポイントでやっているからである。

大事な商談もアフターファイブの飲み会の相談も外から見たら同じなのである。ということでおわかりだと思いますが、大事な仕事をプライベートと同じような隠れたインフォーマルな空間からオープンな空間にさらすことをすべきではないでしょうか。必要なITを使った仕事はここだけですよといったことを皆が意識することで、PCで遊ぶことを減じていったらどうだろうか。自然とそうなって行く雰囲気を作る方が、強制力を働かすよりも効果的であるように思う。

ただ、それでも暇な人が減るわけではないので、根本的な解決策にはならないのですが、少なくとも企業として必要な業務がPCを道具としてだれがどれくらい使ってやればできるかがわかるのでムダな部分が明らかにできるという効果はある。

結局、飛躍して大きな話になってしまうかもしれないが、企業だけではなく日本の社会全体が暇になったということで、現代人はみな暇つぶしの手段を探していて、その主たるものがITデバイス(インターネット、Webサービス、携帯、ゲーム)ということかもしれない。えー、それって日本は成長していないってこと?

2012年7月19日

CIO不要論

こんなことを書くと天に唾するようで非難されてしまうかもしれないのだが、どうも日本ではCIOがいないからダメだとか、きちんと経営としてITを見ていく機能が必要だといった議論が当然のようにされているが、本当に正しいことなのだろうかと疑問に思えてきたのである。最近でも政府CIOを置くというような話も聞こえてきて、それを歓迎する声も上がっている。

しかしながら、もうちょっと真剣にその是非を論じた方が良いのではないだろうか。ぼくは欧米の国でCIOが活躍してそれによって大いに業績をあげた(ITが貢献していないと言っているわけではない)という例をあまり聞いたことがないのだが、そうしたCIOという役割もアメリカ的な経営組織論から来ていると思う。それが日本でも必要なのか、それよりも最初に言ったようにCIOそのものが必要なのかどうかである。

端的に言おう。ITはあくまで道具であり、主体は人間がやることであり、そこに必要に応じてITを適用するという主張をしていると何やらCIOって何をするんだろうと思うからである。いやCIOはChief Information Officerだから企業の「情報」に関する最高責任者だから必ずしもITに限ったことではないと反論されるかもしれないが、一般的には情報化戦略を立案する人であろう。となると情報化は目的ではないので案外ミッションが不明確なのではないかと思う。

あくまで業務システムやITインフラはビジネス活動や業務が戦略、事業方針、ビジネス要求に従ってきちんと機能するにはどういった仕組みと仕掛けを用意するかになるから、重要なことはビジネスモデルからビジネスプロセスを設計して、それをどうやってオペレーションするかにかかっているわけで、ここはCIOの仕事ではないのである。

すなわち、COOと情報部門長でやってしまえばいい話でわざわざCIOなんて置く必要がないのではないだろうか。繰り返すが、情報化することが目的なら必要かもしれないが、オペレーション(業務執行)ありきなのだから、むしろ必要以上のことをやってしまう危険性もある。日本ではCIOと呼べるような人は少ないが、考え方として企業の情報化戦略を立案しなくてはいけないという思いは強いようにみえる。

その前提として、全社的に統一、統合化したほうがよいという頭があると思う。しかし、これからクラウドの時代になってくるとなおさらなのだが、ITを総括的に管理しなくてはいけない理由が希薄になってくるように思う。もちろん、決算の仕組みとかエンタープライズリソース管理、従業員サービスなどは全社的な統合システムで管理しなくてはいけない。

しかしながら、事業ごとのサプライチェーンや営業プロセスなどは事業ごとに違ってもかまわないし、むしろその事業の特性に合ったものを使った方がよいわけで、最近では事業の統廃合などが頻繁に起きるから、スクラッチで作っていたら間に合わないなんてこともある。そんなところはクラウドでスケールアウト、スケールアップが容易なシステムにしておく必要がある。それはもう企業の情報化戦略といったものではなく、事業オペレーションに付随した装置とか機械といったイメージになるのではないでしょうか。

NC機械とかロボットを統括管理するChief Equipment Officerなんて役回りはいないでしょう。ということでCIOは不要で実際に事業オペレーションをやっているところでIT化というか、これからはどんなサービス、ソフトウエア、デバイスを選んでくればよいとなる。つまり、CIOが要らなくなる、そんな時代が到来するのではないでしょうか。
  

2012年8月30日

作ることと使うことの違い

コンピュータソフトウエアに関係していると、ソフトウエアにも性格が違うものがあってそれを混同している節に出会うことがある。性格の違いというのはどういうことかというと、簡単に言うと何かを作るためのソフトウエアなのか、それともそれを使って何かアクションするためのものかである。

ちょっとわかりずらいので例をあげて説明する。ドローイングツールというのがある。Visioみたいなお絵かきソフトです。この手のソフトウエアは、図面とかカタログとか書類みたいなものまで、要するにオブジェクトを作り上げて終わりみたいなものです。つまり、静的なものを起こすためのツールという位置づけになります。

一方、図を書きながら絵を描きながら、字を入れながら何かのアクティビティを行うというためのソフトウエアが必要となります。これも例で言うと、マインドマップというツールがあります。あれは、マインドマップを書くというのが目的ではなくて、いかに頭の中にある考えや発想を引き出して整理するかというためのツールです。これは、その図を使いながら発想の引き出しと整理というアクティビティのためで、図が変化してどんどん広がっていくという意味で動的なものです。

ドローイングツールにはマインドマップも描けますよといううたい文句になっていますが、それでマインドマップ活動をやっている人はいますか。やはり、使い勝手が悪いので、専用のマインドマップツールを使っているのではないでしょうか。こうした例からもわかるように「使うためのツール」が少ないことに気がつきます。すみません、言い遅れていますが、エンタープライズ系のしかも業務システムの話ですので間違わないように。コンシューマ系は逆ですよね。作るものというより使うためのツールばかりです。

なぜこんなことをつらつら書いているかというと、いま業務プロセス設計をどうやってやろうかと思案しているのだが、当初はアナログ的に紙と鉛筆、あるいはホワイトボードでと考えていたのだが、どうももうちょっとかっこよくスマートにできないかと思いだしたからである。あとあとの再利用のための記録として残したり、実装のフォーム設定に落としたりできたらいいのではないかということである。

そうしたとき、アクティビティを並べたり、その属性を書き出したりということ、ワークショップ的にみんなでなんだかんだ言いながらやるためのツールってあるのかなと思ったのである。それで最初に言ったことをドローイングツールにあたっていて感じたのである。実はすでに4年前に似たようなのは作ってあってそれをカスタマイズしようか、新たに作ろうかと検討している。

できたらまた紹介しようと思いますが、話は戻って、作ることと使うことを間違わないようにすることが大事で、このことはことソフトウエアだけに限った事ではないような気がする。道具とかもっと広げると商品そのものも言えることかもしれない。すなわち、道具とか商品の作ることが目的ではなく、それを使って何をするのか、逆に何をしたいからその道具や商品を使うのかということが重要なのである。

これまた、飛躍するのだが、日本のものづくりというところにも関係することなのだが、得てしていいものを作ればいいというだけでは意味がないし、ビジネス的にも成り立たない。もっと使うということを意識し、積極的に使い方をも提案していくくらいなものづくりが望まれるのではないでしょうか。
  


2012年9月 6日

ビジネス活動にプロセスはどのように入り込んでいるのか(1)

いま、バリューチェーンプロセス協議会(VCPC)のワーキンググループ活動で「BPMアプローチによるITシステム構築研究WG」というのを主宰しているのが、このBPMアプローチというのは、簡単に言うとプロセスを中心に業務を考えてシステム化しようという考え方になります。

そこで議論しているうちにこのアプローチで何でも通用するのかという質問がきます。つまりできるできないというより得手不得手があるのではないかという指摘である。それはその通りで何でもかんでもプロセス中心でいいのかというとそうではなくて適している領域があるということです。

そうであると次の2つのことをクリアーにしておく必要があります。すなわち、得手不得手な領域はどこなのか、では不得手なところは別のどんなやり方が適しているのかということである。それを考えるときそもそもビジネス活動のうち異なった性格の領域がどこにあるのかをみていく必要がある。つまりビジネス活動の構造化ができていないと何とも言えないわけです。下の図は、超簡単に書いた模式図です。
businessStructure.bmp
水平方向の、Requirement-Process-Resultというのがメインストリームになります。顧客からの要求を受けてそれに応えるプロセスがあって、そこでの結果が事業成果として記録・報告されるわけです。これがメインストリームであることは多分異論はないと思いますが確認しておきましょう。わかりやすいのは、起業するときでもいいのですが、ビジネスを始める時って最初にあるのはここですよね。これはビジネスモデルの根幹です。

こうしたメインストリームを流すためにPlanである事業方針から予算のような計画とドライビングフォースとしてのResourceがあります。事業におけるビジネス活動は、ポリシーや計画に則って、お客さんの要求に対して様々な経営資源を活用して処理していき顧客満足を与えることなのである。

この絵で真中の領域でProcessと書いてあるのでここはプロセス中心アプローチが有効であるはずです。では、他の領域ではどうなのでしょうか。プロセスというのは意思決定の連鎖ですから、決めごとがいくつかあってそれを順次決めていくという業務があるのかどうかになります。まずはメインストリームのRequirementのところになります。

その前にRequirementというのはどの範囲を指すのかがあります。お客さんを獲得するところ、正確にいうと、商談に乗ってくれそうなお客さん(まだぼやっとした要求の見込み顧客)をつかむところまでなのか、実際に商談を経てオーダーを出してくれるお客さんにするまでを含めるのかです。ここでは、後者はProcessのところに含めることにします。どちらにするかは重要ではなくて見込顧客を顧客にするプロセスは全くのプロセスだからそうした方が都合がいいという意味です。

では、お客さんに商品を認知させて興味を持ってもらい、引合・見積に行ってもいいなああと思わせるのはプロセスなのだろうか。もちろんマーケティングプロセスというのがあるくらいだからプロセスと言えないこともないが、不特定多数を相手にすることが多いから、コンタクトのしかたもまちまちなので、プロセス中心アプローチはなじまないような気がします。顧客との関係性をどう構築するかといったアプローチになるのではないでしょうか。

その他については次回に。

2012年9月14日

使い方という視点

もうだいぶ前になるが、テレビはあまり見ないのであるがたまたま飲みながらチャネルを回していたら、スマステーションという番組をやっていた。SMAPの香取慎吾が司会でそういえば稲垣吾朗が月一回映画の解説をしているので見たことがある。そこで超便利文房具を紹介していてそれを見てびっくりしてしまった。別に文房具から遠ざかっていたわけではないが驚くべきグッズがあるのには唖然とした。

紹介された中でも面白かったのは、片手で書いても滑らない「スベらないメモ」、細かい部分もラクラク糊付けできる「消えいろピットほそみ」、下敷きなしで簡単カット「スコッチ(R)安全ペーパーカッター」、シャープペンシルなのに鉛筆の書き心地の「大人の鉛筆」、修正液の塗り間違いを修正できる「消ゴムではがせるミスノン」などなどである。

中にはこれはというものももちろんある。スマートフォンでメモが作れる「メモプリ MEP―B10」は、別にスマートフォンのメモに書いておけばいいじゃんと思えるし、香りに癒されるアロマボールペン「リロマ」も、においを嗅ぎたくないときどうするんだろうとか、ツッコミを入れたくなるが目くじらたてるものでもない。

これらを見ていると思うのだが、商品としては全く新しいものではない。メモであり、糊であり、カッター、シャーペン、消しゴムである。つまり、商品そのものの新規性というわけではない。何が受けるのかというとその使い方なのである。ただ単に書ければいいとかくっつけばいいいい、あるいは消せればいいというのではなく、それを使って生活する局面でほしい機能を提供しているのである。

とっくに飽和していると思われる文房具の世界でもライフスタイルと密接に絡み合った新商品の開拓の余地はいっぱいあるのだ。斬新であっと驚くような新製品なんてそんなにあるわけがないのであって、こうしたちょっとした工夫である程度のマスをもった商品化が可能なのである。

といった思いで見ていたら、ふとITはどうなっているのだろうかと思いだした。ただITといっても広くて、Webサービスとかスマホアプリなんていうのは文房具に似ているが、業務ソフトはどうだろうか。どうも新しいスタイルの訴求という面では弱いなあと思う。ましておや、業務システムでは全くと言っていいほど離れているように感じる。

そこがこれからの業務システムの目指すところであると思う。すなわち、データ登録したら癒しのメロディが流れてくるとか、お客さんの苦情の程度を絵文字で表すとか、ちょっと遊びすぎか、要するに学生が勉強を楽しくやれそうな文房具と同じように、働く人たちが楽しく仕事ができるためのITを考えたいものである。

そのために大事なことは使い方という視点で見ることだと思う。今の業務システムは、作った人がどんな使われ方をしているのかをちゃんと把握していないことが問題なのでまずはそんなところから直していったらどうだろうか。
 

2012年9月27日

建設業界とIT業界

例えば、IT産業は建設業を似ているが、建設業に比べて日本のIT産業はなぜこんなひどい状態なのだろうかという議論がある。確かに業界構造的は似ているかもしれないのだが、本当に共通項として括っていいものだろうか。括れなかったら何が違うのだろうか。その違いから何かが見えてこないだろうか。

その前に一言でIT業界といっているが様々で、普通は「インターネット業界」「パソコン、その他ハードウエア業界」「ソフトウエア業界」「通信関連会社・プロバイダ」といったジャンルに分けられます。ここでは、「ソフトウエア業界」のことを言っていますので間違わないようにしてください。ソフトウエア業界でもさらにソフトウエアそのものを作っている企業とソフトウエアを使って業務システムなどのアプリケーションを作っている会社とに分かれますが、後者のようなアプリケーションを作っている領域に焦点を当てることにします。建設業も同じようなのですが、こちらは家を建てることや建造物を構築することに該当します。

似ているところはというと、受託請負であること、要求定義から要件に落とし込んで設計・開発を行うこと、大手ゼネコンを頂点にした多重下請け構造になっていること、末端に零細の中小企業が多くあること、仕事のやり方がプロジェクト管理主体などだろう。こう見ていくとやはり似ているなあと思う。

では逆に違う点というか、どちらかにできていてどちらかにできていない点は何なのだろうか。建設業界を眺めると談合、JV(企業共同体)、建築基準法、設計事務所、不動産屋の存在など、建設業界の特徴をあげることができる。ところがIT業界はなかなか取り上げるものがない。ということは、業界特有のビジネスモデルが確立していないことを意味していて、だからこそこうした議論がなされるのかもしれない。

ここであげた建設業界の特徴をよく吟味すると共通的な意味がくみ取れる。何だと思いますか?要するに、談合できるような、JVを組めるような、法的な枠組みがあるような、設計屋さんとして食っていけるような、中古も含めた物件を売買できるような、そんな商品であり仕事であり、ビジネスなのである。それはいったい何なのだろう。

それは、汎用的であり標準化されたものであり、顧客ニーズに対する適合性がよい商材をエンジニアリングとして提供していることにあると思う。だからこそ、同業と組んでもできるわけで、中古でも使いたいという人がいるわけである。IT業界でこんなことができるだろうか。JVというケースも公共などではないことはないが、同じ仕組みを別々に作らすなんてことがやられる。どこかで要らなくなったシステムを買ってくるなんてことも、銀行のオンラインであったようだが少ないと思う。

だからといって単純にIT業界はダメだと言っているわけではなく、このことをヒントにして考えてみるのも意味があるのかと思うのである。今言ってきたことですごく感じるのは結局“役に立たないシステムが半数以上ある”ということに尽きる。なぜIT業界は使ってもらえないような商品を平気で生み出しているのだろうか。少なくとも、建設業ではあり得ないと思う。(グリーンピアのような別の意味で使ってもらえないものはあるが)

つまり、建築物というのは、作る前も作っているときもどんなものができて、それをどうやって使うのかという具体的なイメージを作り手と使い手が共有しているからなのである。できてから、思っていたものとぜんぜん違ったものだったなんてことがないのだ。ところが、業務システムではこうしたことが結構あって、出来上がってから変更が頻発したり、使いものにならないのでそのまま放ってあるなんてことが起きる。

IT業界がダメだというのは結局ユーザの信頼を勝ち得てないからであるのだから、役に立たないものを平気で提供している限りはダメな業界であり続けるだろう。ですから、単に建設業界と比較してダメだと言っても始まらないので、どうやったら本当にユーザに喜んでもらえる役に立つシステムをエンジニアリングできるかを真剣に考える必要があると思うのである。
  

2012年9月29日

文書の編集が仕事そのもの?

文書作成ソフトとかドローイングツールとか、データベースソフトなどに編集機能というのがある。字句の修正や入力フォームを追加・修正したりできる機能である。新聞や雑誌の編集作業と同じようなことである。こうした作業こそ仕事そのものではないかと思うのである。なぜこんなことを言うのかというと、プロセスを記述してそれを動かす時、何やら編集作業をしているように思えるからである。

プロセスというのはフローを表現するわけだから、順番があることになる。つまり、ある意思決定をして、それが終わると次の意思決定に移るとなる。その意思決定は同じ人がやらない場合もあるから、一旦終わらせておいてから次の意思決定に進むことが多い。後のほうは追加となるわけである。また、差し戻しのようなこともあるがそれは修正ということになる。

結局、依頼に対する回答書という文書を追記・編集しながら完成させるのがオペレーションといえないこともないのである。例をあげると見積依頼に対する見積書という文書を作成する場合、納期を記入したあとその文書を一旦保存して、そのあとに金額を追加記入という編集作業を行うわけである。見積書作成という業務オペレーションはこんな形で行われるのである。

ただ、これらのソフトイやツールはこのことを意識していない。要するに、字句や図の編集にフォーカスしていて、編集作業のしやすさとかには気を使っていない。編集作業はなぜか裏の作業のような感覚になっている。まだ未完成だからよそには見せないでこっそりやりましょうという感じである。だから、決してやりやすいようにはできていない。完成してから見てください、そこはきれいになっていますよというわけである。

これは業務システムを考えた場合であって、たとえばオープンソフトやWebサービス開発なんかではやられていると思う。プログラムソースをみんながコミットして作り上げるイメージだ。勝手にやられても困るのでチケットで管理しましょうといったやり方である。そういった感覚をITツールに持ち込んでほしいと思う。

この間も業務システムを開発するシステムベンダーの人だちと話をしていても、まだまだアウトプット重視というか、できあがったものだけで評価するクセみたいなものがあって、そこに至る過程を軽視する傾向があるのではないだろうか。これは、自分たちの仕事の部分だが、業務システムに対しても同じような姿勢があると思う。

仕事は段取りしたあと実行して終了するというのが基本だが、その途中経過というのは編集作業によく似た動作なので、それがスムーズにできるようなソフトウエアを作ってほしいと願っている。それってワークフローがあるじゃんという人がでてきそうだが、決められた順番どおりに編集作業ができるかどうかやってみてから言ってほしいと思う。
  

2012年10月 2日

システムの構造化

構造化というのは、超簡単に次元を切って、その中に共通的な要素を括っていれることだと言えないこともない。4次元まで考えると頭がパンクするのでとりあえず2次元くらいでもいい。縦と横、上下、深さと広さといった区分けである。等分で区切る場合もあるし、階層的に切る場合もある。

こうした構造化をするかしないかで思考の収束スピードが格段に違ってくる。堂々めぐりをしないですむし、次の一手が浮かびやすくなる。システムを考える場合も当然構造化すべきである。プログラミングの世界ではおなじみであるが、業務システムの場合を考える。様々な局面でこの要請はあるが、そもそも業務システムはどんな構造の上になりたっているのだろうか。この場合は、どういった階層化がなされているのかということになる。

つまり、財務会計システムとバーコードシステムは同列に扱っていいのかという問題である。当然、レベルもやっていることも違うよねということがわかる。それをもう少し体系的に考えるとどうなるのだろうか。まずは呼び方がいろいろありますよね。業務システム、情報システム、コンピュータシステム、ITシステム、業務パッケージ、業務アプリケーション、ITツール、ソフトウエア、オペレーティングシステム、データベースシステムなどなど。

システムの呼び方とその構成要素の呼び方が混在しているようなので、システムそのものの上位概念から見ていく。ここでの議論はビジネスのジャンルでの話です。大きなくくりでは、業務システムとなるでしょう。このブログの別のエントリー「ビジネス活動にプロセスはどのように入り込んでいるのか」でも書いたように、事業すなわちビジネスモデルを執行するための仕組みが要ります。このレベルでは、ITを使っているとかいったことは関係ありません。人が手でやっても業務システムとなるわけです。

そこには、人や組織あるいは文化・風土のようなものも含めてシステムは出来上がっています。そして、その中のひとつとして情報システムがあります。ビジネス活動に必要な情報をやりとりする仕組みです。大方は物理的なものというより情報という形で扱うのです。商品にしても、そこに載せてある情報が商品価値であるとも言えるからです。

ただ、情報というとコンピュータという風に思いがちであるが、別にデジタルでなくてもアナログの紙であっても構わないのです。むしろ全部がコンピュータでできている情報システムというのはないのではないでしょうか。紙を電子化すればそうなるかといっても、人の頭の中の情報を使っているなんてこともあり得ます。

さあ、こうなると次はITシステムということになります。情報システムの中にITを使って情報を処理する部分です。いま、上位の業務システムからだんだんと下位に落としてきましたが、このアプローチでみていくと大事なことが分かってきます。情報システムの中にITシステムがあるということはどこまでITを使ったらいいのか、別の言い方をすると、どうだからIT化する意味があるのだろうかということである。

使う必要がなかったらIT化しなくてもいいのである。ITシステムのさらに下位にはデバイスのようなものだとか、機能的ソフトウエアといったものになるのだが、これも同様でいくら新しいデバイスが出ても必要性のチェックがあって採用すべきか決めるべきなのである。従来のよくある間違いは、下から構造化してしまうことにある。はやりのデバイスがある、いいパッケージが登場したといって、それらを組み込むことが第一義的になってしまうのである。

構造化してものを考えることが大事だというのはこうしたことなのだ。今日の業務システムの問題点を構造化、体系化という観点でとらえなおす必要性がありそうだと強く感じるのである。
  

2012年10月 8日

現場に行かなくてもコンサルできる

プロセス中心アプローチの良さがなかなか伝わらないのだが、それでも少しずつではあるが理解者が増えていると思う。先日もぼくがお手伝いをして半年前にだいたいのシステム化が終わった会社の人と話をしていて、こちらも意外だったことを口にされたのでちょっと驚いたことがある。

「現場を一度も見ないでコンサルを受けたのは初めてでした」という言葉である。別に批判的に言っているわけではなく、むしろ好意的な印象であった。その会社はばりばりの製造業だったが、そういえば現場(工場)にいかなかったなあと改めて思った。もちろん工場から責任者が参加してはくれていたが、実際に目で工場を見たわけでもない。それでも、どうしても現場を見なくてはという必要性は感じなかったのである。

このことはけっこうプロセス中心アプローチの重要なポイントを示している。業務の改善なり業務プロセスの改革といった場合、普通は現状どうやっているのか、どこに問題があるのかといったことを、現場の様子を見て、聞いて分析することがやられる。しかし、それだけでは、単に作業上の問題であったり、手順の不備だったりといった現場改善の域を脱しない可能性がある。

そうした現場の作業というのは作業のための作業ではなくて、上位概念としての業務プロセスがあって、そのプロセス上必要なアクティビティとして行っているという意識が大事なのである。つまり、きちんとした業務プロセスを描くことによって、その作業の意義や求められるパフォーマンスも分かってくる。そこを押さえておけば作業改善のポイントを気づかせてくれるのだ。だから、現場に行かなくても大方のやるべきことが見えてくるはずである。

日本では現場の意識が高く、それがものづくり日本を支えているという理解が一般的ではあるが、もちろんそれは否定することでもないのだが、一方でそこに焦点を当てすぎると木を見て森を見ない“虫の眼”になりがちである。そんなときに大事なのは全体を俯瞰する“鳥の眼”である。だからといって、どちらか一方だけでよいというわけではなくバランスをとらなくてはいけない。

管理者の人は現場を見る眼、現場の人はビジネスや業務プロセスという観点で見る眼を養うようにしたいものだ。プロセス中心アプローチのめざすところはまずはプロセスを中心に据え、そこを先行させて業務システムを考えましょうという態度ですから、鳥の眼からまず眺めて、そこから虫の眼で直していこうということである。この順序が逆にならないようにと言っているのである。

だから「現場を見ないでコンサル」は、別段奇をてらったわけでもなく自然と出てくるアプローチで、そのプロジェクトでもそうだったのだが、業務プロセスを分析・再設計しているうちに現場でどうしたらよいのかが浮かびあがってきて、いちいち現場にいってああしろだとか言わなくても参加している現場の人が率先して改善し出すのである。
  

2012年10月15日

ITアーキテクト不要論

以前「CIO不要論」というのを書いたが、あの記事の趣旨は、ビジネス上重要なことはビジネスモデルからビジネスプロセスを設計して、それをどうやってオペレーションするかにかかっているわけで、ここはCIOの仕事ではなくCOOの仕事であり、ITは所詮道具だからオペレーション側の人間が使いやすいものを選ぶだけの話だということであった。

それと同様な意味でITアーキテクトといわれるような人も不要だと思うのである。ただ誤解してもらっては困るのですがあくまで業務システム構築のところの話です。そんなことを思った直接の理由は、ITProの記事の「ITアーキテクトの視点」というコラムのなかの「ITアーキテクトは何をしているのか」という連載を読んだからである。

そこでは、システム開発の各工程における成果物を示し解説が加えられている。「要件定義」「基本設計」「詳細設計」「実装・テスト」「保守運用・移行」というごくオーソドックスなシステム開発のライフサイクルが並んでいる。

まず最初の要件定義工程でひっかかってしまった。ITアーキテクトが作成すべき成果物は次の5つだという。

(1)Vision Document
(2)利害関係者マップ
(3)概念機能モデル図・概念データモデル図
(4)非機能要件定義書/品質特性シナリオ
(5)グランドデザイン

(1)のVision Document、つまりシステム化の目的とか狙い、どんなものを作るかといったことですが、これってITアーキテクトが書くのでしょうか。すでにあるところでITアーキテクトの出番なのではないでしょうか。まあ、確認するという意味でそれはよいとしても次の利害関係者マップというのがよくわからない。説明には下記のようなことが記されています。

ITシステムにはさまざまな利害関係者がいて、その利害は対立していることが少なくありません。この利害の対立を認識しておかないと、ある利害関係者から見たら受け入れられない仕様であった、ということになりかねません。システム化対象の業務を理解するには、ITシステムを取り巻く利害関係者を押さえておかねばなりません。それをまとめたものが「利害関係者マップ」です。

もう最初のところでええーとなる。“ITシステムにはさまざまな利害関係者がいて”というのがそもそもおかしいと思いませんか。害がある人がいるのならシステム化はやめたらいいのだ。というか、システムを作るというのはビジネス上でやらなければならない目的、目標があってそれに対して組織、人がシステムを使って役割を果たすわけであって利害があるというのはどういうことなのだろうか。BABOKでもステークホルダー要求というのがあるがこんなことを言ってるわけではない。

その他の成果物は、「概念機能モデル図・概念データモデル図」「非機能要件定義書/品質特性シナリオ」「グランドデザイン」なのだそうだ。これとて、システムのことばかりでビジネス上あるいは業務オペレーション上の課題をどう解決するのかという視点が見えてこない。ユーザの人(それこそ利害関係者)がこの成果物を見て何がわかるというのでしょうか。
  

2012年10月19日

ITアーキテクト不要論(続き)

CIOもITアーキテクトも要らないよと書いた。言い過ぎのようにも思えるのだが書いていて別段トンデモナイことでもなく自分でも納得している。ただ、前回も言ったように全く要らないということではなく、業務システムを作る上では邪魔だと言っているのである。少なくとも、エンドユーザにとってはコンタクトする必要のない人種なのだとまたまた過激なことを言ってみる。

例の連載の2回目で基本設計工程の5つの成果物を提示している。

(1)論理データモデル図
(2)パッケージ図(永続化視点)
(3)パッケージ図(機能視点)
(4)アーキテクチャー設計ドキュメント
(5)アーキテクチャー評価ドキュメント

これとて、ユーザの人たちはさっぱりわからないと思います。こんなものができたとしても自分たちの業務システムがどんなものになるのか想像がつくでしょうか。システムを作るため、あるいはシステム屋さんが実装の仕方として残しておくためには有用かもしれませんが、どんな使い方になるのかの答えを提示しているのでしょうか。

情報システムは単純化すれば、入出力システムです。入力データを永続化し、要件に応じてデータを加工して出力します。この「入」と「出」の折り返し地点 にデータベースが存在します。つまり、データベースの構造はシステムの「土台」となり、この土台の良しあしが変化への対応力を決めるといっても過言ではありません。論理データモデル図は、この土台の論理構造を示したものです。

これは、最初の成果物である「論理データモデル図」について記したものです。やはりひっかかりますね。ええー、データの出し入れが情報システムなんですかと突っ込みたくなるのである。もちろん、論理データモデルは大事で土台ではありますが、そこに乗っかる上ものはどうなっているのだろうか。それがパッケージ図なのだろうか。永続化視点と機能視点という分け方もわけわかりませんね。

ぼくは自分でこのようなやりかたでシステム開発をやったことがないし、コードも書けないのでトンチンカンなことを言っているかもしれないが、繰り返しますが、システムを作るというのは、作ってくれと頼んでいる側のユーザとコミュニケーションを取りながらやるべきものだということは間違ってはいないでしょう。

その時に、ここに書いてある成果物(さらに下流の詳細設計とか実装なんてなったらなおさらちんぷんかんぷんです)でユーザとやりとりできるのでしょうか。極論すると、テレビがほしいと言ったら設計図とか配線図なんか要らなくて取扱説明書とかユーザーズガイドがあればいいでしょう。つまり、業務システムを構築する場合にはたえずお客さんが簡単に理解でき、使うイメージがわくようなドキュメントを介しながら作り上げなくてはいけないのである。それはITアーキテクトの仕事なのでしょうか?
  



2012年10月31日

システム開発のSTP

CIO不要論とかITアーキテクト不要論とか、ちょっと尖ったことを言ったのだが、誤解されるといけないので補足しておこうと思う。そこででてきたのがSTPというのでまたびっくりされたかもしれない。STPというのは、マーケティング戦略などで使われるSegmentation、Targeting、Positioningというあれである。

つまり、顧客や市場を細分化して、狙う市場や標的とする顧客を決め、どこにポジショニングをするのかといったことである。これは企業がビジネス活動を行う上では多かれ少なかれ必ずやっていることでもある。このことを少しシステム開発においても適用して考えてみたらどうかと言っているのである。

顧客や市場と言っても業種、業態といった括りではなく、会社が行っているビジネス活動領域を想定した方がよい。セグメンテーションではそこを定義していきます。以前、企業活動モデルというのを提示したことがありますが、あれで見ると、「Plan」「Requirement」「Process」「Resource」「Result」という領域が示されています。

ここから各領域をどういった商品がターゲットとしているかを見てみましょう。Planは戦略立案から計画作成のようなところです。パッケージのようなものも多少ありますが、基本的に非定型的なのでシステム開発という商品の出番は少ないでしょう。次のRequirementのところは顧客との直接的な接点ですから、今やWebシステムになっていて、改変が激しいから従来型のシステム開発とは違ってきます。

Processにいく前に後の二つを先に見ていくと、Resourceでは、人事・給与、設備管理、資金管理といったようなところですので大方は専用パッケージが出回っています。Resultは事業成果をまとめるところですから、ここにはERPがあります。奉行シリーズからSAPまでラインアップされています。会社はこれがなければ動きませんから、どこの会社でも既に入っています。ですから既成市場であり競争相手がたくさんいるレッドオーシャンなのである。

ということで、今のブルーオーシャンはProcessなのです。ここをターゲットにすることが望まれています。ところが、この領域の特徴は、文字通りプロセス主体であり、なおかつ非定型業務が多いというものです。当たり前ですが非定型というのは、決まりきった手順でもないし、しょっちゅう変わることもあるということ意味しています。つまり、従来のシステム開発の手法では対応できないのです。言い方を変えれば、対応できなかったからブルーオーシャンとして残っているのです。ですから、そこに従来の商品を持って参入しても難しいのは目に見えているでしょう。ポジショニングとしては非常に弱い。

最後の砦であるProcess領域は日ごろのビジネス活動に密接に関係していて、戦略的な意図やビジネス要求をそこで叶えるものだから、ビジネス環境や経営方針が変わったらすぐに直さなければならないわけで、その都度システム開発会社に頼んで改修あるいは追加開発なんかしている暇と金はないのである。

ユーザ自身がさくさくシステムを作り、変更し、自分たちのビジネスは円滑に遂行できるようにするという姿からは、CIOやITアーキテクトの必要性が見えてこないのである。CIOやITアーキテクトは従来のシステム開発スタイルでは必要だったかもしれないが、そこはもう飽和だし、成熟しているので役割は終わったのではないだろうか。むしろ、これからはシステムに対してビジネス要求を出すCOOやビジネスプロセスを設計できるデザイナーといった役割が重要になってくると思うのである。
 


2012年11月 8日

概念化スキルの重要性

いま、ビジネスモデリングだとか業務プロセス設計のファシリテーターをやっていますが、その時に必要な能力は概念化スキル、あるいは抽象化スキルであると実感しています。概念化スキル、抽象化スキルとは、対象となることがらに対して、本質的なものだけを抽出して、典型となる構造や機能を組み立てる力であるとぼくは定義しています。

ではどうしてこうしたスキルが必要かということを考えてみましょう。ビジネスモデルや業務プロセスを設計するといっても、自分が経験したことが対象になるなんてことはほとんどありません。全く経験のないことばかりです。自分が経験して知っていることを直接使うわけにはいかないわけです。そんなときにどうしますか。

このビジネスの本質は何のか、この業務プロセスの基本骨格はどうなっているのだろうかというアプローチをとることになります。それができないと、細かいところ、癖のあるところ、固有性といった部分をそのまま取り入れてしまいます。その結果、悪構造の業務プロセスになるだけではなく、応用力がきかなくなり変化対応力を失うことになります。

だからといって何もないところから概念や抽象モデルはもちろん生まれてきません。当然ですが、自分の経験から想起することになります。ですから、経験をスペシフィックなものと捉えるのではなく、一般化するクセをつけておくことが大切です。経験の再利用性を高めるために必要なスキルというわけです。

こうした態度でビジネスや業務を見ておけば、よくSEに業務知識が必要かなどといった議論に対して、特定の業務知識は要らないということができます。本質的な部分を抑えることができれば、どんな業務にも対応できると思います。どうも日本人はここのあたりが弱く、特に現場のやっていることが常に正しく、特定のことがらが一般論となってしまうといった傾向があります。

このことは、少し飛躍するかもしれませんが、職業についても言えるように思います。自分の就いている職業を概念化、抽象化できないから転職もできないという事態があるのではないでしょうか。このことが硬直した労働市場を生み出している一因かもしれません。そうですね、逆に抽象化しすぎていることもあります。“私は部長ができます“という笑ってしまう文句がそれです。

さて、それでは概念化スキルとか抽象化スキルをどうやって身につけてらいいのだろうか。ぼくの実践方法はブログを書くことである。TwitterやFacebookだと特殊性や断片といった言葉になるから、概念化され、抽象化されたものとは程遠い。なのでBlogなのであるが、これも日常の生活臭ぷんぷんの日記とか単なる紹介記事ではだめで、あるテーマに対して、自分の主張、意見、評価といった文脈が記されてものでなければいけない。あれえ、この記事はちゃんと書けているのだろうかちょっと心配になったぞ。
 

2012年11月 9日

システム作りとシネマと書店とスタジアム

ぼくのブログは、「シネマと書店とスタジアム」というのを標榜している。すなわち、映画鑑賞レビュー、書評、スポーツ観戦記を書いていこうというわけである。それに、ITの話がはさまったのが基本形である。ITといっても主に企業の業務システムのことである。それぞれは、一見無関係に見えているが、最近どうも共通点があるのではと思い出している。

ということでシステム作りを映画や本、そしてスポーツと並べて見ることにする。さてどうなることやら。まずは、映画であるが、映画作りはずいぶんと変わってきている。昔は東映、松竹、東宝といった大手映画会社が専属の俳優や監督を抱えて、次から次へと制作していた。しかしながら、今は製作員会方式が多くなっている。法律上は任意組合と言うらしい。要するに幹事会社が複数の会社に対し出資を募り資金リスクを分散し、利益が出た場合はこれを出資比率に準じて分配する方式である。

これって、ゲームとかWebサービスなどの開発は似たようなことがやられてる。ただ、業務用ソフトウエアはあるかもしれないが、業務システムの場合難しいだろう。基本的に請負型だから、多重下請けにしてリスクは分散しているかもしれないが、利益が出て分配ということはない。でもこれからのクラウド時代では、映画のような形態もあり得るような気がするのだが、いかがでしょうか。

ただ、プロデューシングとかディレクション、シナリオといったことはかなり似ていると思う。映画はまずはプロデューサーが企画し、人を集めてチーム作りをする。それが済むと、監督が俳優を使って演出する。これは、プロジェクトリーダーがメンバーに役割を持たせ動かすのと同じである。そのとき重要なのは脚本がしっかりしているのかということで行きあたりばったりだとよいものはできない。

さて、本はどうでしょう。これは業務システム、もっと言えば業務プロセスは“物語”であるということに共通点があるように思えます。というかそういった見方をすべきだと思うのです。従来の業務システムには物語がなかったと思います。本で言ったら、辞典とか、図鑑とか情報集といったものに近い、つまりデータベースを作ることだったような気がします。

しかし、ビジネス活動というのは、物語本と同じように起承転結があります。何を書きたいのか、どう始めてそれをどう展開して結末につなげるのか、それと同じような構成から成っています。業務の始まりは何か、途中は何をすることで進捗させるのか、結論は何か、何ができたら業務は終わるのかといったことです。そこには、登場人物が生き生きと躍動する姿があります。

最後のスポーツについては、ぼくはサッカーのことばかり書いているのでサッカーとの比較になります。企業活動により似通っているスポーツはサッカーでもあります。チームスポーツであり、組織的かつ戦略的でロールがきちんと決められているからである。攻める人、守る人という役割もそうだし、攻撃的に行くのか守備的に行くのか、どちらサイドから崩すのか、要求スキルは何なのかなど、企業の組織活動とよく似てる。

また、システムの構造とサッカーのフォーメーションがまた似ている。Requirement、Process、Resultというのがフォワード、ミッドフィルダー、ディフェンダー/キーパーという構図に重なるように思う。以前にも言ったことがあるが、弱いサッカーチームは、必ずミッドフィルダーの存在感がないところである。バックスからミッドフィルダーの頭越しにボールが行ったり来たりするゲームをする。業務システムもこれまで中抜き、すなわちプロセス抜きできたが、強いサッカーチームと同じようにきちんとプロセスでつなぐことをすることが大事である。

こんな風にして比較してみるといろいろと面白いことがわかる。実は、これはちょっと前に書いた概念化ということでもある。概念化、抽象化することで共通点や本質を見つけて参考にする、あるいはいいとこどりをするという態度が大切であるということにもつながる話なのである。
  

2012年11月21日

職種名

IPAのITスキル標準によれば、職種を11種類に分けている。マーケティング、セールス、コンサルタント、ITアーキテクト、プロジェクトマネジメント、ITスペシャリスト、アプリケーションスペシャリスト、ソフトウエアデベロップメント、カスタマサービス、ITサービスマネジメント、エデユケーションである。昔は営業とSEとプログラマーぐらいだったように思う。

さらに、これを職種ごとに35の専門分野を設けていて、それぞれの専門分野に対応して、IT技術者個人の能力や実績に基づいて7段階のレベルを規定している。こんなに細分化してどうするのだろう。だいいち、この領域の技術は日進月歩でどんどん変わっていくから規定したところですぐに陳腐化するという事態になる。もっと気楽に大雑把にやればいいのではないだろうか。

例えば、最近ではどんどんWeb系のサービスや技術あるいはデバイスも入りこんできているが、Web系の技術者にこの標準を当てはめるのだろうか。そして、クラウドの登場やパッケージ、ツールも充実してきた今日ではシステム開発の概念も随分と変化してきている。こういった変化の激しい時は、細分化して硬直的に規定するのではなくもっと柔軟にしておく必要がある。

そう言う意味では、上流の要求獲得・定義、プロセス記述・設計、実装・業務適用といったぐらいのジャンル分けでシステム開発プロジェクトは動かせると思うのである。プロジェクトマネジメントやITアーキテクト、プログラマーがいないのはおかしいと思われるかもしれないが、従来の発想だと必要かもしれないがこれからの開発はこれらの職種が要らないプロジェクトにすべきなのだ。

先日、カリフォルニア州立工科大学情報工学部の一色浩一郎教授にぼくも参加した中小企業の業務見える化プロジェクトの実際を見てもらった。一色先生は要求工学が専門で、ビジネスアナリストの養成にも力を入れている。この事例を見て先生はかなり高く評価してくれて先生のセミナーにも一部取り入れられるかもしれない。米国の大学の先生が足立区の小さな会社の事例を熱心に聞いてくれて素晴らしいと言ってくれたのには驚いた。

終わったあと、一緒に食事をしながら話したのだが、そのなかに「ビジネスアナリスト」という言葉について議論になった。一色先生の頭の中では、要求獲得からプロセスデザインあたりまでをイメージしている。それに対して、ばくは“アナリスト“というネーミングだと、どうしても”分析する“という捉え方をしてしまうということを言った。分析して終わりという風に感じられるのだ。

そうしたら他の人にも同じように指摘されたといって、それではプロデユーサーというのはどうかと言われる。そこでぼくは映画作りの例を持ち出して、プロデユーサーだけではだめで、演出家とシナリオライターがいると言った。先生は元々ビジネスアナリストをジュニア、ミドル、シニアと3段階に分けていたので、そうだジュニアをビジネス(プロセス)デザイナー、ミドルをビジネスディレクター、シニアをビジネスプロデユーサーと呼ぼうと手をたたいていた。

たかが呼び名、されど呼び名ということで意外と重要なのである。誰でもすぐに理解できるような名前が未だにないからなのだが、先日もそのことで集まりを持ったりした。さて、どうなるのだろうか。少なくとも官製の細かい呼び名はやめたほうがいいと思う。
  

2012年11月23日

生産管理システムとひとことで言うけれど

○○管理システムという呼び方が嫌いなのだが、リソースに関して管理というのは許すとしても、販売管理だとか購買管理、生産管理というのはどうも気にくわない。人材管理、設備管理、資金管理なんていうのは、対象物をビジネス活動で有効に活用できるように常に管理しているということだから、何となく管理というイメージでもおかしくはない。

しかしながら、販売・購買、はたまた生産といったことを管理するというのはどういうことなのだろうか。リソースとは違うというのは、その名のもつ性格でも分かる。つまり、リソースの方は名詞形である。人材、設備、資金というのは名詞である。ところが販売、購買、生産は動詞形である。売る、買う、作るです。その中間的なものに、在庫、物流といったものがあります。

そして動詞形のものは動きを伴ったものですから、状態を変化させるという意味でプロセスが主体になっていることが分かると思います。さらに、販売・購買と生産とではまた相違があります。外部プロセスか内部プロセスかという問題である。外部プロセスというのは顧客やサプライヤーと接点を持っているといることである。一方、内部プロセスというのは、もちろん間接的には顧客やサプライヤーとはつながっていますが、基本的には、自分たち都合というか、自分たちのペースでプロセスを動かすことができるという意味で内部プロセスなのです。

ということは、生産管理(とりあえずそう呼びますが)というのは、他の業務形態と一線を画したものであるように思います。その辺を少し見て行くと、大きく業務機能の構成は、計画、プロセス(実行)、リソース、アフターサービスとなりますが、生産では、生産計画を立て、それを主に設備と人を使って生産プロセスを動かし製品を作りだします。また、できた製品が返品されることもあります。

ということなのですが、待てよ、そうかなあという疑問が湧いてきます。つまり、本当に内部プロセスだけなんのかという疑問です。標準品などのように作りだめして在庫としてもつのだったらわかるのですが、そうではない受注組立生産(BTO)、受注設計生産(ETO)では、お客さんの注文に答えて作るので外部プロセスだとも言えます。

どうして、そんなことを言うのかというとどちらも同じような生産システムと言っていることが気になったからである。しかも、最初に言ったように生産管理システムと言っている。受注生産型では、大事なことはお客さんとの関係性であるから管理というのもおかしい。作り手側の都合だけで決められないし、行ったり来たりの調整が多い。場合によっては、一緒になって新製品を開発することもある。

例えば、今の生産システムでは、オーダーを集約して、それらの生産スケジュールを立て日程展開するといったことが行われる。しかし、受注生産の場合集約は難しく、一品料理的なさばき方になるはずである。計画もあらかじめ作れるものではない。

従って、生産を一括りにしていることがおかしくて、今のシステムに合った生産型ももちろんあるが、そうではないものもあるわけでそこへの対応がうまく出来ていないように思うのである。これからはデルモデルなどのように顧客と密接に結びついた生産が増えてくるから生産システムも変化していかなくてはいけないと思うのである。そうです、よりプロセス志向になるのです。
  

2012年11月29日

オペレーションの重要さをもっと知ろう

ちょっと前のChikirinの日記に「リーディングカンパニーが積み上げる珠玉のオペレーション」というタイトルの記事がでていた。彼女は“時代の先端的な技術”よりも、“各業界のリーディングカンパニーが長年かけて作り上げた超高度なオペレーションシステム”の方に興味があると書いていて、アマゾンがすごいと賞賛していた。

そして、オペレーションというのは、一朝一夕でできわけでもなく、ひとにぎりの優秀な奴がいればいいというけでもなく、それを極めるには時間もかかるし、多くの人の知恵もいるというわけである。だから一旦築き上げると他はなかなか追随できないのである。ここが非常に重要な視座であるのだが、意外と気づいていない人が多いような気がする。

よく差別化だとか競争優位といったことが語られるのだが、すぐに戦略的なことだとかビジネスモデルなどが焦点となるが、実のところ優れたオペレーションシステムにこそポイントがあるのである。なぜならば、戦略もビジネスモデルも立派なものができたとしてもそれを実行して初めてビジネスに貢献できるからである。その実行するプラットフォームを作ることが大切なのである。

日本BPM協会から出された「BPM推進のステップとキーポイント」には3つの輪が示されている。PC(Process Change)、PD(Process Development)、PO(Process Operation)のことで、プロセス改革推進、プロセス開発、プロセスオペレーションのサイクルが継続的に回っていることが大事だと言っている。業務オペレーションの主要な部分というのは、プロセスオペレーションだから、ここが強調されてことは大きな意味があるのだ。

PCというのは、ビジネスモデルと事業戦略からビジネス要求を引き出し、それを埋め込むハイレベルのプロセスを特定するフェーズのことで、そこでフォーカスされたビジネスプロセスを設計するのがPDで、できたプロセスを実際に動かして成果を出すのがPOである。この3つのフェーズをみたとき何が重要なのかというふうに考えてみてください。実は、どれが一番ということではなく、それぞれが大事であるのだが、その割には今までオペレーションの問題が軽視されていたと思うのである。「役に立たない正しいシステム」を作り続けて来たというのはこのことが原因である。

今言ったようにそれぞれのフェーズがどれも重要なのは言うまでもないのだが、重要さの性格が違うことも理解しなくてはいけない。PCでは、経営あるいは事業という視点で俯瞰してみるということが大切で、いわば大局観である。PDでは、大局観から生まれたビジネス要求を実現するためにどういった仕組みと仕掛けにするかという意味で、布石である。

そしてPOである。泥臭い話であり、人間が表に出てくる。実際の斬った張ったの戦いの場なのである。いくらいい戦略を立ててもここで負けたら何にもならない。4隅の死活争いである。戦争だって最後は前線の戦いや兵站線で勝敗が決するのである。そうだったら、もう少し、オペレーションから発想してもよさそうだと思いませんか。

つまり、オペレーションで勝ちたいけどシステムの動きが悪いから何とかしてくれとか、オペレーションが回っていないのでプロセスを変えてくれとか、お客さんの望んでいることはちがっているよといったことが起きる。こうしたことがこれまで捨てられてきたように思う。これを拾い上げるようにしたいのだ。つまり3つの輪のサイクルをどこからもスタートして連動させるイメージだ。

こんなことを言うと、部分最適になるとか、木を見て森を見ないようになるとか言われかねないのだが、繰り返すがこれまでPCとかPDに重心があったものを少しでも移動させたいからなのである。ただ、ここでいうオペレーションは人間主体でITを利用して行うものであって、コンピューターに任せて自動化することとは違うので間違わないようにしてもらいたい。
 

2012年12月 4日

デフレとSIビジネス

デフレが止まらないという。デフレとは「一般物価水準の継続的下落」のことであるから物価がどんどん下がっているということになるが、どうもそんな実感がない。下げ止まったように思うのだがどうなのだろう。また、デフレが困ったという感じもぼくにはない。むしろ物価が低いから家計的には嬉しいという単純な思いなのだが、世間ではデフレが景気を悪くしている原因だという人がいる。

物価が下がると売る側の利益が上がらないから給料もあがらないので困るのだろうか。デフレが継続する要因は、デフレギャップだという。デフレギャップとは実際の需要が現実の供給力を下回る総供給>総需要という状態のことである。買う人が少ないのにモノがあふれているから物価が下がるらしい。

SIビジネスはどうなっているのだろうか。ある特定の物価のことを言っていけないのですが、デフレのようですね。需要に比して供給過剰なので業界は大変なことになっているみたいだ。と書いて見たが本当だろうか。どうも、世の中的にはデフレが原因で景気が悪くなっているのではなく、景気が悪いからデフレになっていると考えた方が良さそうなので、いかに構造改革や生産性の向上を行って成長率を高めるしか方法がないように思える。

だからである。SIビジネスも同様に構造改革と生産性向上を図ることを考えたらどうだろうか。そして重要なのは、この構造改革と生産性向上を同時にやることが重要で一方だけではない。例えば、生産性向上というのはクラウドのソフトウエアを使ってさくさくっと作ってしまうと、それだけとると開発費も安くなり、人も余ってくると考えたら逆効果と思うだろう。

ベンダーの人たちと話をしていると必ずこのことになる。アジャイルだとかクラウドだとか、途上国へのアウトソーシングといったコストを抑える方向へどんどん進むのは彼らのビジネスにとっては縮小を意味することになるので避けるしかないという。しかし、そのまま手をこまねいていてはジリ貧になるのは火を見るよりも明らかである。

デフレ論でも労働生産性を上げると失業が増えてしまうからデフレを助長するという議論があるが、それはその業種あるいは業態だけ見ればそうかもしれないが、需給ギャップが逆になっているところへのシフトをすることで全体の需要を押し上げることも可能なのである。介護サービスのエリアでは人手不足であるというし、中小企業の求人もあるのだ。

では、SI業界はどうなのか。ここで考えて欲しいのは、この業界の中だけでも構造改革の余地があるように思える。つまり、需要側が飽和になっているのだろうかということだ。大企業はそうかもしれないが、中堅・中小企業はもう何もないのだろうか。新たな業務領域でのIT化の要求はないのだろうか。グローバル化が安いコストを求めることだけなのだろうか。どうもまだまだそこらあたりの掘り下げが不十分だと思うのはぼくだけだろうか。
  

2012年12月16日

CPO

近頃は、チーフなんちゃらオフィサーという呼び名が出回っている。代表的なのがCEO(Chief executive officer)、COO (Chief Operating Officer)、CIO (Chief information officer) といったところでしょう。ならば、CPO(Chief Process Officer)というのがあるのだろうかと調べてみた。調べたといってもWikipediaで見ただけだけどこれがあるんですね。

ちなみにそこには36のChief Officerが載っていました。さてCPOですが、その説明があってこう書いてある。

A chief process officer (CPO) is an executive responsible at the highest level of an organization. CPOs usually report direct to the CEO or board of directors. They oversee the business process activities, are responsible for defining rules, policies, and guidelines to ensure that the main objectives follow the company strategy as well as establishing control mechanisms.

さすが米国だ。ちゃんと的確に表現してあるし、かなり高位の職種として規定しているのが見てとれる。企業戦略を実現するためCPOがやるべきこととして、プロセス活動の監視、ルール・ポリシー・ガイドラインの定義、コントロールメカニズムの確立が挙げられている。まさにプロセスマネジメントの何たるかを言っている。

日本にはCPOと言われるような人はいるのだろうか。はっきり私はCPOですという人は見かけないが役割として担当しているという人はいるかもしれない。なぜCPOなんて言い出したかというと、先日あるセミナーでぼくが関係していた会社の社長が事例発表していて、終わったあと一緒に帰りながら話題になったからである。

発表は「静脈流プロセスの改善」と銘打ったもので、通常の生産・販売・出荷という「動脈流」に対して、納入以後のクレームだとか修理依頼といったお客さんからの要求への対処プロセスの改善というテーマである。実は動脈流も大事なのだが、忘れがちになるが静脈流がけっこう重要で、最近ではそこからビジネスも生まれてくるといったこともある。

実は、その改善されたプロセスを作って実装したのが社長の妹さんで、業務チームのリーダーをやっている女性である。彼女はもちろんITの専門家でもないし、むしろITなんてというほうなのだが、その彼女がプロセス中心の考え方で業務を捉えるとわかりやすく、またそうしてプロセスを設計すると簡単に実装できるということに気がついて、ことあるごとに社内でプロセスという言葉を発しているという。

営業や設計の若い子が何か言ってくると、それはどのプロセスのどこのことを言っているのかとか、このプロセスのここがちゃんとできていないからダメなんだとかいうのだ。なので、その話を聞いたあとにそりゃあまさにCPOだと言ったのである。ところが、それに対して口の悪いおじさんが(けっしてぼくではありませんよ)それは「チーフ・プロセス・オバサン」だと叫んだのには一同大笑いであった。そんなオバサンが増えるといいなあ。
  

2012年12月27日

サービス学会

ある人から誘われて昨日東京大学で開かれた「サービス学会設立記念会」に出席した。サービス学とはいったいなんのことだろうというのは後にして、メンバーがすごい。会長が新井民夫芝浦工業大学教授・東京大学名誉教授、副会長が伊藤元重東京大学教授と秋草直之元富士通社長・現相談役という布陣である。そして、文部科学省、経済産業省の局長が祝辞を述べるという豪華なもの。要するに産学官そろい踏みである。さらに発起人がそこから197名が名前を連ねている。

さてサービスとは何なのか。みなさん気楽にサービスという言葉使っているが、それぞれが違った言い方、捉え方をしているし、括ってしまうと何だか亡羊としてしまうということがあると思う。新井先生はそこの辺の定義のあいまいさやそれに対する批判を紹介しつつ新たな定義を提示する。

従来よく言われるのが、4つの特性、つまり無形性、同時性、異質性、消滅性である。特に異質性が強調されてきた。ところが、これだけでは限界というか一面的なようで、新たな定義をほどこした。その定義が、「提供者と顧客との相互のインターラクションによる価値創造」なのだが、またこれもよくわからないので、もう少し噛み砕いて言い方をしていて、それが「提供者が、受給者の望む状態変化を引き起こす行為」ということになる。

このほうが分かりやすいと思う。つまり、人間って、自分がより気持ちいいとか楽しいとか、いつもと違う新鮮さとかを望んでいてそれを提供してくれるのをサービスと思っているのだ。ただ、気をつけなければいけないのは"受給者のわがまま"なのだ。マクロ的にはポピュリズムであるとぼくは思う。だから、提供者と受給者の思いのバランスが大事になるのではないだろうか。

わが国ではこれまではどちらかというと提供者が良いものを作れば受給者が喜ぶはずだというスタンスが色濃かったが、それを受給者側に寄せる必要があるのだろう。新井先生も製造業のサービス化とか製造業=製造代行サービスであるという表現をしていたのはこのことであろう。今後の日本の成長に欠かせない視座であるように思う。

サービス研究における取り扱いテーマが、Theory、Service Management、Service Design、Service Marketing、Service Application、ICTである。また、こうしたテーマに対する研究展開プロセスが、観察―分析―設計―適用である。広範な領域を対象としているのがわかると思います。こうした広い範囲を対象に体系化し方法論を導き出すのは大変難しいことだと思うのだが、出来たら素晴らしい。

それと粒度を揃えた議論に向けてということで、システム階層レベルとコンテキスト依存性の2軸で整理してくれていて非常にわかりやすい。すなわち、システム階層をマクロ視点で見るのかミクロ視点でみるのかということと、コンテキスト依存性が高い生態系的なのか依存性が低い構造的なのかである。そのちょうど中心にあるのが業務プロセスマネジメントなのである。

今ぼくは「ビジネスサービスのつくり方」というタイトルでブログを書いているが、まさにサービス研究にチャレンジしているとも言える。サービスのコンセプトを考え、それをデザインし、マネジメントする仕組みをITを活用してつくり、実用に供するというテーマである。講演を聞いて、広い視野でサービスというものを考えなくてはいけないことを教えてもらった気がする。

この記念会に行く前はどうせ学者さんたちが頭の中でこねくり回すことをするのだろうと思っていたのだが、よく聞いてみるとかなり実践を意識していることもあって、興味がわいてくる。副会長の伊藤先生の経済学からみたサービスという話もおもしろく、人間の能力とかICTを超えたところの仕組みが重要であるとか、変化を先取りしたサービスが大事だといったあたり、単純なシステム化、IT化への注意に聞こえて参考になった。

sa-bisugakkai.JPG

2013年1月18日

人と組織から離れることが大事だなあと思う

ここの場で何回も言っているのでまたかと思われるかもしれませんが、会社の業務を人と組織からではなくプロセスから見ようということをしつこく言っている。なぜかというと、これも繰り返し言っているが、ビジネスを始めるときに人と組織から考えないからです。こんな組織でそこに誰それを配置してということを先に考えて起業はしません。どんなビジネスをやりたいのか、どんな商品を作って売りたいのかがさきにあるはずです。

そういったビジネスモデルがありきでそれをオペレーションするために人がいて、一人ひとりの範囲が広くなって限界になってしまうから組織を作って役割分担をし、さらに大きくなると階層化していくというのが簡単な組織論です。ところが、既成の会社や組織があると、ついそこを前提で見てしまうのである。そうなると今ある組織や人の配置でビジネスが決まってしまったりするわけで、それでは本末転倒である。

だから、事業の構造が変わったら組織も人も変わるというのが普通なのだが、なかんづく日本の古い体質の企業は、組織も人も大きく変えようとしない。だから、M&Aや合併したしても、両方の会社の組織を並列で残したりする。こうした逆発想の組織論が日本企業の弱体化につながっている面があると思う。

業務システムをつくる場合にもこの間違いがあって、現状分析をするのだが、いまの組織における業務項目、作業内容を列挙し出すのである。そして業務分析と称して、作業量とか作業時間を測定して、どこにボトルネックがあるから、人を増員しなくてはいけないなんてことをする。もちろん、人的パワーの効率化ということは必要かもしれないが、順番が逆なのだ。だって、業務モデルとか業務プロセスを見直したら、そんな作業は重複していたり、場合によってはいらないかもしれないなんてこともある。

つまり、起業のときだけではなく、いつの時代でも絶えずビジネスモデルとビジネスプロセスを進化させて、環境変化に適応させることが重要である。そこをきちんと抑えておいて、できた新たな業務オペレーションを適正に行うための組織設計、人材配置を行うのが正しいやり方だと思うのである。イノベーションというのも既成の組織とか人からいったん離れて、新しいモデルを創出して、そのあとまた人と組織とITをくっつくてけていくというプロセスを踏むものだと思う。

実はこのことは、さまざまな局面でも言えることで、例えば就職もそうであって、現存する会社はたまたま今の既成社会に存在しているだけであるわけだから、何をしたいのかではなく、単にそうした会社に入りたいだけというのも似たようなところがある。本来は、自分のライフモデル、ライフプロセスがあって、それにマッチするような会社を選ぶというのが筋だ。だから、もしフィットしなかったら転職すればいい。だが、日本ではこれも大変難しいのだ。

もっと大きなことをいえば、政治の話で国家の姿をどう描くかみたいなことにもつながるのだが、ここでの議論の延長で言うと、構造改革をしないといけないのにあまり注目されていないことがぼくには恐ろしいことのような気がするのである。

2013年2月 8日

なぜ、ユーザ自身でシステム構築しろと言っているのか

ぼくはいつも自社のシステム化をベンダーまかせにすることはやめるべきだと主張して、できるだけユーザ自身でシステム構築をすることを推奨しています。その理由は、自分たちの要求がちゃんと理解されたシステムができない、つまり作り手側と使い手側のギャップがあるので、結果使われないシステムができてしまうという問題を指摘しています。

このことを別の切り口で考えてみましょう。まず、経営者がなぜIT化をしようとするのでしょうか。それは、今以上に売り上げをあげたいとか、同業との競争に勝ちたいといったことを志向するからです。そうすることで、会社は生き残り、さらにトップをめざすわけです。IT化はそうした戦略や目標を実現するための手段として有効だからプロジェクトを起こすのです。

そういう経営者あるいは事業責任者は自分がこうしたいああしたいという戦略があるからシステム化しようとするし、どうしたいかの思いがあるはずです。もしそれがないようならその会社は早晩つぶれる運命にあるというのが現代の市場原理です。つまり、つぶれないようにIT化しようとする。

逆に、自分でデザインできずにベンダーに任せてしまうようだとそんな会社はつぶれてしまうでしょう。動かすまでどんなものだかわからないとか、できたはいいが使いものにならなかったなんてことになったら生き残りが困難になってしまいます。すなわち、会社がつぶれないようにするためにIT化するのに、つぶれてもしかたないような対応をするという矛盾をはらんでいるわけです。

従って、自分たちが本当に強くなるようにシステム化をするのなら、基本的に自分たちの手で作り上げないと意味がないのです。高度経済成長のような時代なら、みんなで食っていけるような全体のパイの増大があったからそれでも大丈夫でしたが、いまや大きな成長は望むすべもなく、ぎりぎりでやっている中では、すぐに役に立つものを作らないと大変なことになってしまう。だから、ユーザ自身がデザインして実装して動かしてしまうようにならなければいけないのです。

ですから、システム構築モデルが変わったのです。ITは専門家の分野だから、専門家に任せたほうがよいという論理はいまや通用しないのである。だいいち、業務システムを構築する場合、ビジネスの専門家とITの専門家とどちらが前に出るべきかは自明だと思う。ところが、業務システムはITシステムであるという間違った理解が抜けきらず、ITは難しいから専門家に任せばいいという変なモデルがまだ残っています。

おそらく多くの人たちは気づいているのだが、結局人を減らすといった合理化ができないからあえて言わないのである。いままで受託開発で養っていたプログラマーの職をなくすわけにはいかないからである。これは、IT業界だけの問題ではなく、日本の産業構造全体を変えていく話です。結局、労働市場の流動化とか解雇規制緩和といった問題になっていくのだが、本来なら縮小して、配置転換すべきなのに保護し、残してしまうから産業そのものの競争力を失っているのである。

ユーザ自身でシステム構築しないことが、自分の会社をつぶしてしまうとともにITベンダをも衰退させてしまうという悪循環を引き起こしていることを認識すべきだと思うのである。

2013年2月22日

プロセス中心アプローチを阻む壁(1)

いま薦めている「プロセス中心アプローチ」の大事なことは、いったん組織と人から離れて当該ビジネスにとって必要な業務プロセスを描いてみましょうというところです。よくスイムレーンを書いて組織間をまたぐ業務フローを書いたり、人と人との連絡経路を書いたりしますが、そんなものを先に書いたらだめだと言っています。

あくまで最初は組織と人を意識せずに乾いた目で書くことを薦めてします。なぜこのことが大事かというと、ビジネスのそもそもの成り立ちはどうなっているのかを見ることで問題の本質が見えてくるからです。わかりやすく言うと、ビジネスを始めよう、起業しようとしたときに最初に確立することは何かということです。

分社化して子会社を作るなんていう場合とか個人事業主を除けば、組織とか人ではありませんよね。まずはビジネスモデルから入るのが普通でしょう。多くの場合はビジネスにできそうな商材があるから始めると思います。その商材を売って儲けるためにどうしたらよいのかがあり、そのための業務プロセスを考えるはずです。

業務プロセスが確立したら、その業務プロセスをちゃんとオペレーションするためにどんな組織がよいのか、誰にやらせるのがよいのかといったことが決まってきます。そういう順序です。これは何もスタートアップだからではありません。既存のビジネスでも必ずこの原点に戻って自分たちのビジネスを捉える態度は大変重要なことだと思うのです。今日のようにビジネスを取り巻く環境がめまぐるしく変化すると、しょっちゅうビジネスモデルの変更を余儀なくさせられます。

そんな時に、いきなり組織や人を変えて対応するのがよいことでしょうか。新しいビジネスモデルに対応した業務プロセス変革とオペレーションの変更をするでしょう。ですから、くり返しますが、ビジネスはプロセスを中心に、あるいはプロセスを先行させて捉えることが大事なのです。こうしたコンセプトがなかなか受け入れられないのが日本の企業のような気がします。

そのことは良いか悪いかは別にして欧米とはちょっと違った環境になっているからではないでしょうか。どちらかというと欧米では管理的な要素が強いので決められたプロセス、定められたマニュアルに従ってワークすることが求められています。一方の日本では、働く人の知恵だとか職場の工夫といったことが評価され、実際に取り入れられてきました。従って、プロセスからではなく、組織と人をどう生かすかという観点が濃いこともあると思います。それは、ある時期は日本の強さでもあったわけです。しかし、こうした組織や人には柔軟性に欠ける硬直性がどうしてもつきまといます。

ただ、先ほど言ったように激しい環境変化やグローバル化などに対して俊敏に対処するには動きの鈍さは致命的になりかねないと思うわけです。組織と人の特性は長い時間をかけてできあがるわけで、逆に言うと変化するのも遅いのです。根付いてしまった文化的、風土的な性格はそう簡単に変えることができないのです。
 


2013年2月28日

プロセス中心アプローチを阻む壁(2)

前回、日本の企業にある組織と人の文化的、風土的な特性が素早い変化の要請に応えられていない。また、そのことがプロセス中心アプローチがなかなか受け入れられないことを指摘した。ここでは日本企業と欧米企業との差異という表現で日本的な面を強調したが、日本の企業という大きな括りで論じるのもちょっと乱暴な感じがする。

プロセス中心アプローチを様々な会社に適用していく過程で見えてくるのは、会社の規模でだいぶ違うなあということである。つまり、大企業、中堅・中小企業、小規模企業では壁の所在がそれぞれ違うように感じられたのである。この区分けは厳密なものではなくて、感覚的に従業員数で数千人が大企業で、数百人が中堅・中小で数十人が総規模といった感覚です。

どうも、どこに壁があるのかという意味でいうと、大企業は組織で、小規模企業は人にあって、中堅・中小はその中間といったふうに思われます。ご承知のように大企業には多くの組織があります。大企業というのはいきなり大企業になったわけではなく、そこまで成長するのにそれなりの時間を要しています。ですから、前回例示したような起業からはだいぶ経過しているので、スタートアップの時のそもそもビジネスモデルに立ち戻ることが少なくなって組織から考えてしまうことが増えてしまい、組織の肥大化、冗長化が進んでしまうような気がします。


そうした企業にプロセス志向を持ち込むとどうなるのでしょうか。まずはプロセス間を行き来することが多く出てきます。一つのプロセスで5部門にまたがるなんてざらにおきています。そこへ、いったん組織を離れてと言ってもなかなか受け入れられないのです。その大きな理由は、今身につけた仕事のやり方を変えたくない、ある意味既得権益を守りたいという意識です。そうした意識が強いので今までどおりでいいじゃないかという主張を崩すのは大変なのである。

一方の小規模企業になるとどうなるのかというと、こちらは人が壁になります。数十人規模ですから、そんなに多くの組織を作れるはずがありません。もしそんなことをしたら兼務ばかりで、一人は多くの帽子をもたなくていけなくなります。それでも、この手の会社では一人何役というのが普通です。特に仕事が出来るキーマンには集積していきます。そうなると、全体のワークボリュームがその人のパフォーマンスに左右されるということになります。

さて、そこにプロセス志向を持ち込んだらどうなるのでしょうか。この場合は大企業とは逆になります。大企業は組織間をどう融合し連動させるかが課題なのですが、小規模企業では、個人の持っているアクティビティをどうやって引き剥がして、分割再配置するのかがやるべきことになってくるわけです。

中堅・中小はこの中間的な位置にあると思いますが、その濃淡はあるように思います。つまり、大企業病に罹りかけているのか、ベンチャー気分が抜けずに管理がきちんとできていないといった具合である。大企業のそして小規模企業の悪い面を正し、両方良さを発揮したところが大企業へと成功していくのでしょう。

こうして見ると気がつくと思うのですが、プロセス中心で組織と人から離れてビジネスと捉えていくと、そこに現れてくる壁こそが、これからのグローバルな戦いで生き残るために取り除かなくてはいけないものだと思うのです。じゃあ、どっちの壁の方が厚いのかというとぼくの個人的な感想は中堅・中小や大企業のほうでまだ小規模企業のほうが変われるハードルは低いと思う。なぜなら、経営者の危機感と覚悟の差があるからです。
 

2013年3月 6日

プロセス中心アプローチを阻む壁(3)

これまで、プロセス中心アプローチを阻んでいるのはユーザサイドの組織風土だったり企業規模だったりについ考察してきたが、今回は提供側の問題を考えてみたいと思います。つまり、ユーザが業務改革や情報システムの導入といったプログラムを実行したいと思ったときに誰がそうした要求に的確に応えて提供できているのかという問題である。

そもそも、プロセス中心アプローチというのは、ビジネスの実相を捉えて、それが効率的であるいは顧客満足度を高めるような仕組みにし、実際にオペレーションして結果を出したいということから起こるものである。それは再三言っているようにITシステムを作ることだとは限らないということを忘れてはいけません。現状においてはここに問題が隠れているような気がします。

ITシステムを開発するためのSIerなりソフトハウスはいます。ITシステムを構成するソフトウエアを供給するITベンダーはいます。戦略を立案したり、業務分析をしたりするコンサルタントはいます。では、そういう人たちはプロセス中心アプローチで考えることができるでしょうか。残念ながら、ほとんどの人はそうではないように見受けられます。

ITシステムの開発というと、多くの場合は「データベースアプリケーション」を作ることをします。既存の帳票や画面からデータを捕捉してデータベースを設計します。そして、データの登録・検索・レポート出力を行う画面を作成します。ソフトウエアベンダーは、決められた機能を保有した「道具」を提供するだけで、それを使ってプロセスをオペレーションするという感覚ではありません。

一方、SWOT分析だとか、マイケル・ポーターの競争戦略といったようなことは、ビジネスモデル的であっても、その戦略をどうやって実現するのか、ルーティンとしてどう実行させて行くのかには興味ありません。また、業務分析というのも一見プロセス志向と思われがちですが、これは基本的には個人の作業レベルの話であって、業務量分析でありビジネスプロセスの分析とはちょっと違っています。しかも、現状分析が主体でToBe化も作業量の平準化といった切り口ですから、ビジネス要求をどう反映するのかという視点が欠乏しています。

こうして見ていくと、現状の供給サイドのコンセプトが旧態依然としたもので、ビジネスの環境とか、形態がかなり変わっているのに追随できていないように思います。そういうと、内部統制でちゃんと業務フローも書いてプロセス管理を徹底するようになったではないかという反論がきそうです。そうでしょうか。たしかに業務の手順などをきっちりと書き出したことはやられたと思いますが、多くの場合はただ文書化したというところでとどまっています。実際の、オペレーションに供さなければ意味がありません。

それよりも、もっと本質的なチェンジがあるように思います。それは守りから攻めです。つまり、間違ったことをしないように、正しい手順通りにやるためのプロセス管理から、いかに新規の顧客を獲得するのか、いかに顧客満足度を高めるのかというためのプロセス管理である。人間は間違えることがあるという前提に立つこと、そして何かを生み出すためのプロセス管理である。そうした考え方でユーザに提案できるところがどれだけあるでしょうか。

だから、供給サイドの変革が求められているわけです。そのためのポテンシャルを持った人として、ITコーディネータとビジネスアナリストに期待しています。ただ、今のままでは物足りないので、ITシステムを導入するためのITCではなく、ITを道具として提案できるITCになること、分析するところで終わるのではなく動かすまで面倒をみるビジネスアナリストです。こうした人たちが出現すれば壁は越えられるかもしれない。
  

2013年3月11日

コンピュータはあくまで道具である

常日頃、コンピュータに使われるのではなく、コンピュータと競争するのではなく、あくまで人間が主体的に道具として使うことだといっている。ところが、どんどん仕事がコンピュータに置き換わっていくので、そのうち単純労働はおろか何もかもがコンピュータで出来てしまうのかもしれないないように思ってしまうこともある。

将棋でプロ棋士がコンピュータに負けたとか、人間と同じようなことができるロボットができたというような話を聞くとそうかもしれないと思いそうになる。しかし一方で、人間の行動や思考は機械的にはいかないものであり、実際の生活や仕事でも単に機械的ではない熱意とか信頼とか好き嫌いといった感情を伴ったような行為は残ると思う。だから、いくらコンピュータががんばっても、創造的な仕事と肉体労働は残り、問題はその中間的な部分が置き換わり二極化すると言われている。

そんなことを考えていたら、また酒井穣さんのブログに触発された。「人間から、コンピュータを引き算する未来」というタイトルで「機械と競争」という本を紹介している。そこでは、コンピュータがどんどん人間の働く場を奪っているのは確かだが、そう悲観することはなく、どうしても人間に勝てないところがあると言っています。"近代社会では、感情は理性の奴隷であるべきでした。これが終わり、僕たちは「感情の世紀」に向かおうとしているのかもしれません"と表現していますが、それをチェスでのコンピュータと人間の戦いの例で紹介しています。

1997年、人間最高のチェスの名手であるガルリ・カスパロスはIBMが1000万ドルを投じて開発したスーパーコンピュータ「ディープブルー」に敗れた話はみなさんご存知だと思います。さて今はどうなっているのかですが、試合が「フリースタイル」になっているのだという。フリースタイルというのは、人間、コンピュータ、人間+コンピュータの三パターンの戦いになったということである。さて、どれが一番強いのか、本にはこう書いてあるそうだ。

「優勝者は、アメリカ人のアマチュアプレーヤー2人と3台のコンピュータで編成されたチームだった。 2人はコンピュータを操作して学習させる能力に長けており、これが決め手になったと考えられる。対戦相手にはチェスのグランドマスターもいたし、もっと強 力なコンピュータを持つチームもいたが、すべて退けた。(中略)[弱い人間+マシン+よりよいプロセス]の組み合わせが、一台の強力なマシンに勝った。さらに驚いたことに、[強い人間+マシン+お粗末なプロセス]の組み合わせをも打ち負かしたのだ」

実におもしろい結果だと思いませんか。「弱い人間+マシン+よりよいプロセス」という組み合わせというのが示唆的ですよね。このプロセスというのが具体的に何を指すのか判然としないのですが、アマチュアプレーヤー2人はコンピュータを操作して学習させる能力に長けていると言っているのでCBR (Case-based reasoning)のような技術に優れていて、それを活かすプロセスができていたのではないでしょうか。(酒井さんの言う 「コンピュータを学習させる力」とは、人間からコンピュータを引き算して残るもの、すなわち人間の感情なのではないでしょうか)とはちょっと違うのですが)

つまり、弱い人間というのがミソで、へたに専門能力を持たない方がよいのである。おそらく、専門家はどうしても自分の知識や経験のフレームから抜けられないから硬直的である。戦いは相手があることだから、硬直的では直ぐに見破られてしまうわけで、機に敏な柔軟性こそ重要なのである。少し手前味噌で言うと、プロセス志向では、業務に精通する人でなくてもプロセスが書けるというのも同じようなことを言っているわけである。

このパターンは、チェスだけでなく経済のどのシーンでも有効である。医療、法律、金融、小売り、製造、そして科学的発見においてさえ、競争に勝つカギはマシンを敵に回すことではなく、味方に付けることなのだ。
  

2013年3月12日

「ビジネスをプロセスとして捉える」

昨日は、田町にある東工大のCIC(キャンパスイノベーションセンター)で行われたシンポジウム「ビジネスをプロセスとして捉える」にでかける。主催が「科研費基礎研究A「ひと」のつながりを重視したビジネスプロセスのモデル化」研究グループで、代表者は東工大の飯島淳一教授である。経営情報学会や日本BPM協会などが協賛して告知もしたので出席者も多くほぼ満席であった。途中で東日本大震災の犠牲者を悼んで黙祷も行った。

演題と講演者は次です。
・ 「ひと」のつながりを重視したビジネスプロセスのモデル化・・・飯島教授
・ Enterprise Engineering in practice ・・・Martin Op'tLndアントワープ大学教授
・ 「ひと」のつながりを測る変数群・・・妹尾大 東工大准教授
・ 「ひと」はなぜビジネスプロセスを嫌うか・・・末松千尋 京都大学教授

初めの2つはDEMO(Design&Engineering Methodology for Organization)という理論についての発表である。この理論については本ブログでも何度か取り上げたので読んだ方もいるかと思いますが、Ontologyという概念に基づいて開発されたもので、オントロジーというのは、企業 活動を捉えるとき、従来のような仕事のつながりを重視することから 人間的な側面を見ていこうというもので、観測可能な表層の下に隠れた深層構造があり、もっとそこに焦点をあてる考え方である。

ここでは詳しい理論の説明はしませんが、ぼくが今推進しているプロセス中心アプローチとの関連でお話します。飯島先生は、DEMOへつなげるためにビジネスをプロセスとして捉えることの重要性を強調していました。ビジネスプロセス志向性が高いと、部門間連結が進み、機能間コンフリクトがなくなり、組織内に一体感が生まれ、企業業績が向上すると報告していました。さらに、仕事をプロセスとして見るだけではイノベーションにつながらなくて、重要なのはプロセス管理や評価をきちんとやることだとも言っています。

また、BPMを二つの観点から比較していて、すなわち「しごと」のつながりを重視した"リエンジニアリング"と「ひと」のつながりを重視した"リデザイン"である。前者は、活動の仕方が詳細で実装の表現となっているのに対して、後者は、意思決定や新たな価値の創造だけにフォーカスするデザインの表現である。後者が大事なのだが、ぼくがプロセスとは意思決定の連鎖であると言っていることに符号すると思う。

Martin Op'tLnd教授は、DEMOの創始者であるオランダのデルフト工科大学のJan Dietz名誉教授の下で学んだ人で社会人から研究者に転身したので実践的な発表であった。ただ、飯島先生が前フリである程度の説明はされたとはいえ、難しい理論の説明も含めて1時間ぐらいだったのでほとんどの人は分からなかったのではないうだろうか。ぼくは、3年ほど前のセミナーでJan Dietz教授の話を直接聞いていたので大体は理解できたが初めてだと相当きついだろう。

ただ、ちょっと残念だったのは、事例が3年前と全く同じであったことで、まあ典型だからということだろうと思うのだが、最新のものが聞きたかった。それと、前回もそうだったのだが、その事例が、「ビザの宅配」「レンタカー」と「Air FranceとKLMのアライアンス」なのだ。これでは両極端だと思いませんか。かたや、単純なリクエストに対するトランザクションに対して、かたや企業関連携というレベルや範囲もだいぶ違うのである。一般の企業ではその中間的なプロセスがほとんどなのだからそういった事例を取り上げてもらいたい。

後半の二つでは、妹尾准教授が「ひとのつながりに関する3つの変数」ということで、「外部連携」「内部連携」「協力と信頼」をあげて、それぞれの特徴とか位置づけや変数の測定方法などについて論考していた。そして組織の吸収能力(新しい価値や外部情報を認識して吸収し、商業目的に応用する企業の能力)と外部連携と内部連携が密接な関係にあることを指摘していた。

最後の末松教授は、ビジネス・プロセスに対する拒絶の背景ということで、「有効なモデルの抽出と設計の能力」(がないこと)「目に見えない資産としての認識」(が弱い)「間接費に対する誤解(直接コストの弊害)」「ユーザ視点(設計・マーケティング)」(がない)、「既得権の利害調整」(が大変だ)などを上げていた。ぼくもそう思うし、おそらく問題点の所在はだれも同じような認識であろう。それをどうするかという処方箋が難しいのである。

それよりもおもしろかったのは、末松先生は今会議技術と業績の相関について研究しているとのことで、会議スコア(どうやって出すのかは教えてくれていないが)が高いほど業績指数も高いことを明らかにしていた。そのとき、どういう会議がそのスコアが高くなるかについて、"プロセスの中に会議があること""議論がプロセス的である"ことだそうだ。このことは、ぼくも日頃まずはプロセスがあって、そこでの個人の役割やコミュニケーション、情報参照などが従属すると言っているので大いに共感したのである。
  

2013年3月15日

「kintone」がすごい

サイボウズの「kintone」がバージョンアップした。かなり大きな変更もあってずいぶんと機能が向上した。その主な追加機能を列挙してみる。

・ グループ内での連絡に使用する機能(スペース機能)
・ kintoneのユーザー同士の連絡や、アイデアなどの共有に使用する機能(ピープル機能)
・ Excelブック形式、またはCSV形式のファイルを読み込んでアプリを作成する機能。
・ JavaScriptファイルを読み込んで、アプリの表示や動作をカスタマイズする機能。
・ フィールドをグループ化して、グループ内のフィールドの表示/非表示を切り替えられるようにする機能。
・ フォームに配置できるフィールドの種類に、ほかのフィールドの数値や時刻を基に計算する機能を持つ「計算」フィールドを追加。
・ フォームに配置できるフィールドの種類に、ほかのフィールドの数値や時刻を基に計算する機能を持つ「計算」フィールドを追加。
・ 指定したフィールドの日付を基準にして、レコードの一覧をカレンダー形式で表示する機能。
・ アプリのコメント欄に宛先を指定して書き込む機能。(メンション機能)
・ ファイルから読み込んでレコードを登録/更新する際に必要だった、アプリのフィールドとファイルの列をマッピングする作業を自動化。

といったところでしょうか。元々どんな仕様なのかを説明していないのでバージョンアップした機能がどうのという評価はできないかもしれませんので、個々の機能というよりコンセプト的な変化について見ていきます。追加機能で特徴的なのは、よりSNS的になってきたこと、Excel連携のやりやすさ、JavaScriptでカスタマイズできるようになったこと、そしてフィールドのグループ化あたりですね。

スペースというのは会議室という使い方ができ、ピープルやメンション機能というのは上司や同僚とのコミュニケーションがやりやすくなるわけで、プロセスオペレーションというのは人を中心とした調整行為が大事な位置を占めるので有効な機能となります。これにレコードの一覧をカレンダー形式で表示できるようになったことを加えて、グルーウエアの要素がだいぶ入り込んだ感じです。もう、グループウエアは不要になるかもしれませんね。グループウエアというのは基本的には個人の生産性を上げるためのツールですが、個人の仕事というのはプロセスの一端を占めるものでなくてはいけないわけで、そういう意味で非常に良いことだと思います。

Excel連携とかマッピングの自動化やJSでの記述など外部との連携もやりやすくなりました。kintoneのコンセプトはコア部分にはあまり機能を装備させないであくまでもシンプルに置いておいて、付加機能や連携機能はAPIを用意しておいて外付けにする(それもサードパーティやユーザ自身でやる)という考え方なのでこうなります。SOA的な思想ですよね。非常によいコンセプトです。何でもできるように一つのツールに埋め込むのは却って融通性を損なうことになってしまうのでこうした疎結合は歓迎です。

ぼくが今回のバージョンアップで最もうれしかったのは、「フィールドをグループ化して、グループ内のフィールドの表示/非表示を切り替えられるようにする機能」です。ぼくの方法論ではWebデータベース上にプロセスを表現するわけですから、どうしても縦長になってしまいます。そうなるといちいちスクロールしなくてはいけなくて視認性に難がありました。ですから、その解決に今回のフィールドグループという概念と折りたたみ機能が非常に役に立つわけです。

プロセスにおけるアクティビティをフィールドグループとして記述することによってプロセスが一望でき、各アクティビティのデータ登録、閲覧が指定するフィールドグループを開け閉めすることで個別設定ができるようになるのでとても扱いやすくなります。また、その上部に各アクティビティ(フィールドグループ)のステータスを登録・表示できるようにしておくとさらに管理しやすくなります。

ということで、ぼくが以前から欲しいと思っていた機能がだいぶ実装されてきて、プロセスオペレーションのプラットフォームとしてますます進化してきています。kintoneはすばらしい。(別にサイボウズ社からお金をもらっているわけではありませんが(笑))ぜひ使ってみてください。
 


2013年4月 3日

クソデータを扱って何がビッグデータだ

ちょっと過激で品のない表現で申し訳ありません。最近とみにビックデータという言葉がもてはやされて、またもやバズワードかなとも思うのですが、単純にビックデータというもの自体は別段食ってかかるようなものでもなく大量のデータというだけのことかもしれない。要は、どんな質と量のデータでそれをどうやって活用するのかといったことが問題なわけです。

しかし、どれだけの容量からがビックデータなのか、非構造化データを扱うからそうなのかといた定義もないと思うのだが、Web上で毎日せっせと生成されるデータを個人的なサービスに活用するという意味はあると思うのですが、おそらく普通の会社でビッグデータを扱うようなことは少ないように見受けられるわけで、なぜそんなに熱くなるのかがわからない。ITベンダーが売りものがなくなって、最近はデカ女が売れてますよとか言ってるキャバクラ(そんなところはないか)の呼び込みよろしく叫んでいるようです。

データの活用、すなわち多くのデータを分類・解析して有用な情報を引き出すのは非常に難しくて、重要なのはその有用性に結びつくような意味のあるデータなのかどうかである。クソデータを扱っても何もならない。クソデータからはクソの結果しか生まれないのはまだしも、下手すると害悪となってしまうこともある。誤った判断をもたらす危険をも孕んでいることに注意しなくてはいけないのである。

クソデータには3つの意味がある。「ミソクソ」、「消化したあとのカス」、「どうにも食えない」である。そもそもビックデータというようになったのは、従来のように構造化されてリレーショナルデータベースに収まるようなもの以外のデータがあふれてきたからである。ということは、とりあえずミソもクソもなんでもいいからバケツに放り込んでおけという類である。

クソっていうのは、最初は食物であって、それが吸収されて残ったカスである。企業だって動くのにエネルギーすなわち食料が要るから、それを体内に入れて消費してお金を生み出すわけで、この場合の食料というのは「情報」とも言える。そうした情報を使って産み出された結果が実績データである。ある意味クソというのはビジネス活動の成果とも言える。便秘になったり下痢したりするのは活動の結果がどうであったかを意味するのである。だからあえて言うとクソを分析してもあとの祭りだということである。どんなクソになるのかをもっと早いうちに診断しておかなくてはいけなくて、食欲不振だとか、胃の調子が悪いなんていうのをいち早くチェックする方が大事なのである。

クソは食えませんねえ。要するに食えないようなデータをいくら綿密に解析してもしょうがないわけで、最初に言ったように、食えないようなものも含めてなんでもいいからデータを溜め込めばいいなんてことをしてはいけないのだ。それを何とかミソにまで引き上げるにはどうしたらよいかは、データに生成過程を紐づけておくことが必要ではないかと思うのである。どうやって生成されたかがわかるようにすることである。そうすれば、クソにも意味があることになるからである。

下品なたとえで気分が悪くなったかもしれませんが、データ解析というのは取得・収集段階のフィルタリングとか、分析前のクラスタリングといったことが重要で、そうした前処理をきちんとやることでクソデータ化を防ぐといった取り組みもしてみたらいかがでしょうか。これは、いつも言っているように正規化されたプロセスをきちんと管理することに他ならないのです。
 

 

2013年3月28日

どうやるかの前にどこでやるかが大事である

様々な議論で落ち込む落とし穴がある。議論の対象となっている領域を間違えるあるいは噛み合わないことである。これでは、戦うリングが違うから殴り合いにもならない。5W1HでいうとWhereを取り違えることである。このことはどこの局面にも転がっていて、意外とこのWhereをおろそかにするケースが多くあることに気づく。大きくは、アベノミクスで金融の話と財政の話を混同したり、原発のリスクとエネルギー問題を冷静に議論できないといったことが起きる。

つまり、多くの場合論点が定まっていないところで議論するものだから結局は空中戦になって何だか分からないで終わってしまう。ただの議論で満足するならそれでいいのだが、結果を出さなくてはいけない時には困ってしまうのである。目的(Why)とか構造・機能(What)とか方法(How)、スケジュール(When)といったことは熱心なのだが、意外に見落としがちなのが、今一体どこの話なのか(Where)である。本当はすごく重要であるにもかかわらず忘れられる。

なぜ重要かというと、そこの設定を誤ると結論が逆になったりする弊害があるからである。ここからは、ITの話になる。ITの議論で多くあるのは、システム化する目的の明確化やシステム開発方法論や使用技術といったことが中心になっている。ところがそういった議論はみな一緒くたに語られている。例えば、ビッグデータとかクラウドだとか、アジャイルもそうだし、BPMだってそうかもしれないが、じゃあそれはどこの領域の話なのかが抜けていたりする。

そのWhereというのは、適用領域のことで、それでもいろいろな切り口があるわけで、個人なのか企業なのか、その企業も大企業なのか、中小なのか、それもどういう業種なのか、また企業内でも販売系なのか生産系なのか、さらにリソース系なのかイベント系なのかもっと言えば、多少生煮えでも直ぐにやることに価値があるのか時間をかけても正確さが重要な領域なのかといったように、みな性格が違うのである。大事なことはそういった性格に適したソリューションがあるということである。

それと、ソリューションが決まるとどんなもの(What)をつくるが決まるのだがその作り方も違ってくるのである。要するにこの"どこでどんなものを作る"かによって作り方が変わるということを理解しなければいけない。このやり方が一番だから何でもこれでやるというのは間違いである。

具体的に言おう。トヨタのカンバンシステムを作るのと、銀行のオンラインシステムを作るのと、セブンイレブンのPOSを作るのと、一般企業の経理システムを作るのと、標準品か特注生産システムを作るのとWebサイト作るのとみな違うのである。それをITシステムという括りで一緒にするから混乱する。最初に行ったような仕組みをアジャイルでやれって言っても無理でしょとなる。ぼくは、元ケミカルプラントにいましたからわかりますが、銀行のオンラインなんて工場を作るようなものです。それをとりあえずやってみましょうはないでしょう。

それと、システム開発といっても業務システムなのかソフトウエア開発なのかでも全然違います。これもよく間違えるのですが、モノを作るのとスタイルを作るのとでは作るものも作り方も変わります。さすがに組み込みソフトウエアとは一線を画しているとは思いますが、そこの混同もありますね。今や業務システムはスクラッチからプログラム開発するなんてとこはなくなって、既成のソフトウエアを使って作るという位置関係ですから同じレベルではありません。

結局何が言いたいかというと、ちゃんとどこの領域について議論しているのかということを明確にしてほしいのである。例えば、いまぼくのやっている「プロセス中心アプローチ」というのもどこにでも適用できると言っているわけではなく、文字通りプロセスがあるところが対象です。単なるデータの出し入れはDOAでやればいいわけです。また、企業の決算などのバックヤードシステムはウオーターフォールでやればいいし、生き馬の目を抜くような顧客接点のところはアジャイルでやればいいだけの話である。

ただ、IT化の適用領域が広がってきたので必然的にシステム屋さんの考えなくてはいけない範囲も自ずと広範囲になってきたわけです。だから余計に今どこの位置のことについて議論しているのかを3次元的に把握しておかないといけないのである。つまり、業務領域はどこなのかという水平感、プロセスモデルのことなのかITのことなのかという垂直感、あるいは時間軸としてどうなのかといったことに対するフォーカッシングが必要になってきます。戦う場所をきちんと特定しないといけないのです。そのためには、概念化スキル、構造化できる能力が非常に大切なのではないでしょうか。
 

2013年4月14日

手のひら感

自分が何か行動を起こしたり、指示を出したり、考えをまとめたりといった時にどういう状態が望ましいかと思うことがある。単なる思いつきや行き当たりばったりというのは、運が良ければうまくいくが、それがいつも続くわけではない。そこには、何らかの論理的な裏付けが必要になる。いや、論理が組み立てられなければやることや言っていることに説得力がないことになる。

世の中にはロジカルシンキングだとか、○○思考法とかあるのだが、それほど構えなくても自分なりのロジックを持ちたいと願う。それには、一生懸命勉強して、知識を得てと思われがちであるが、もちろんそれも大事であるのだが、立派な知識を得たとしても、ちゃんと咀嚼して自分の考えに変換できていなければ、すぐに忘れるか、化けの皮がはがれてしまう。

さて今は、知識ということを言ったが、それだけでは不十分で、経験ということも大事である。ただ、経験も知識と同じように経験したということだけを取得してもしょうがなくて、その経験によって得たものから次にいかせる知恵を持つことが大事なのである。つまり、知識と経験は持っただけではなく、それを次の行動や考え方に対する論理的な裏付けに変換させておかないと意味がないことになる。

このことは、仕事でもプライベートでも非常に重要な心構えで、これがあるかどうかで、的確な予想もできるし、あるいは予想外のことが起きたとき、危機に瀕したときなどに適切な対応がとれるかどうかが決まってくる。要するに、これから起こるべき事象について、自分の手のひらで転がすことができるかどうかである。達観するとか極めるとかいった境地までいかなくても、ある程度、自らのコントロール下に置くということである。

ITがここまで進展した現代にあっては、知識にしてもまた経験値にしても膨大な情報が得られるようになっている。その中から自分が手のひらに乗せておきたいもの、すなわちコントロールするために必要なドライバーとしての情報が何なのかきちんと把握しておくことだろう。

そのために重要なことは、責任を自覚することだ。こういう責任があるので、その責任をはたすために何をコントロールしなくてはいけないのか、そのために必要な情報は何かである。責任の範囲、そこの状況や状態、来るべき変化に対応する術を手のひらに乗せておきたい。

残念ながら、日本では、特に日本の企業では、この辺りが比較的あいまいで、そんな堅いこと言わずに何となくみんなでよしなにやろうやとみえる。よしんば手のひらに乗っけていたとしても裏に隠れている。個人生活ではSNSなんかで表に晒されているのに企業では、インフォーマルなものになっているのでもっとオープンな形にしたいものだ。これからのITは、手のひら感を与えてくれる仕組み提供してくれるものになってほしいと強く思うのである。

2013年4月17日

SEって何?(5)

▐ 問題のほんとうの所在はどこか

これまで、辛辣なことを言ってきたが、簡単にいうと時代が変わったのだから、人の意識もスキルも変わっていかないとガラパゴスになってしまうよということである。ではそのためにどうしたらよいのか、馬場さんは「顧客に体制図や人月を出すな」「常駐をやめろ」かと技術偏重の風潮をなくせ」、いまこそSEマネージャーが戦う覚悟を決め、しっかりしろと言っている。 気持ちは分かるがちょっと違うのではないかと言った。

「顧客に体制図や人月を出すな」と言われても意味が分からない人が多いと思う。ぼくはまあまあ大企業と言われる会社の情報システム部長を務めたが理解しがたい。プロジェクトを実行するには「体制図と人月」を出させるのは当たり前で、それをやめると言われてもやめてどうなるの思ってしまう。そういうことではなく、なぜ人月を出さなくてはいけないようなシステムの作り方をしているのかが問われるべきなのである。そっちの方向に解決策をもってかなくてはいけない。

それについて、最近同じITProに連載された「なぜ"ダメなシステム"は無くならないのか?」という記事とともに考えて観ることにします。執筆者の佐藤治夫さんは、「ダメな"システム屋"にだまされるな!」という人気記事を書いてそのあと書籍化までした人で、ぼくの知り合いです。2000年ころにあるプロジェクトの計画で一緒に入っていただきました。当時から既成の枠にとらわれない柔軟な頭の人でした。残念ながらそのプロジェクトは、日の目をみなかったのですが、ある意味業界の常識を覆すことを一緒に提案したことは今でも印象的な思い出の一つになっています。その後も時々お会いしています。

彼は、その記事でシステム屋(ITベンダー、SIer、コンサル、情シ部門の人たち)について経験からこういっています。「良い意味でも悪い意味でも、ウオーターフォール的な思考パターンが、日本の"システム屋"を規定している」。ウオーターフォールが、IT業界の産業構造を規定し、個人の成長の阻害要因や撹乱要因になっているとまで言っています。それが、動かない、使われな"ダメなシステム"がなくならない原因だという。

ぼくも以前から同じようなことを言っているから、同感といった感じなのだが、ウオーターフォールが全くだめというわけではなく、作るものによってはウオーターフォールの方がよい場合もあります。佐藤さんは、情報システム構築プロジェクトはピラミッドを作るのと粘度細工の中間に位置するという表現をしています。ウオーターフォールの弱点は逆流(=手戻り)を阻止するあまり、結局顧客がないがしろになった作りになってしまうのだ。ぼくが顧客志向の欠如と言ったのはこのことでもある。

2013年4月18日

セミナーのはしご

たまたま、一昨日はセミナーに続けて参加する。しかも、テーマは関連あるもので、午後からあったのが、このブログでも紹介したICT経営パートナーズ協会主催の「ユーザ事例に学ぶ超高速開発ツール」というのと、夜に開催されたWebCatStudioとNCデザイン&コンサルティングの共催による「実践的アジャイル開発入門」である。

共通点がアジャイル開発ということになる。いまこのブログで連載している「ビジネスサービスのつくり方」と「SEって何?」のなかでも目下の話題が、ウオーターフォールかアジャイルといったものなのでタイムリーではある。ただ、二つのセミナーでニュアンスが違う。最初の方は、ツールを使って開発スピードあげるという話で、もう一方は、実際のプロジェクトで行ったアジャイル開発の実態を素直に吐露している。

「ユーザ事例に学ぶ超高速開発ツール」は、協会初のセミナー開催であり、有料で定員100人だったので集客できるか心配していたのだがふたを開けると満席だった。認知度がまだないのにここまで集まったのは、運営の方法に工夫があったからだろう。発表がユーザの人だったことと、競合するベンダーが一同に会したことが、ベンダーの宣伝に終始する他の多くのセミナーにはみられない特徴である。だから、面白かった。

ユーザの発表のあとに、ツールベンダー5社の代表がパネルディスカッションを展開するというこれまた大胆な試みで、これからどんなツールを導入しようかと悩んでいる人にとっては参考になったのではないでしょうか。ちなみに登場したツールは、GeneXus、StiLL、Web Performer、ユニケージ開発手法、Wagby、です。ExcelベースのStiLLとUnixのシェルコマンドを使うユニケージ開発手法は特徴的だが、他の3つは似ているので、イマイチ差がわかりづらかった。

「実践的アジャイル開発入門」は、メインフレームにあった基幹システムのリプレースをアジャイルでやった事例と、これも既存のWebサービスの陳腐化に伴い作り変えたという話であるが、やはり現実には教科書的に書いてあるようにはうまくいかないようである。ぼくはアジャイルの方法論であるスクラムを知らないのでどこが違うのかもよくわからなかったのだが、彼らが、結果的に、アジャイルの向き不向きというか適不適ということで4象限で語っていたのがなるほどと思った。

軸を、受託開発か自社開発なのかと要件が固まっているのか途中で変更が多いのかという切り口である。それで、アジャイルに向いているのが、要件が固まっていない場合で、また要件が固まっていても自社開発ではやってもいいケースがあると言っていた。ぼくは、もうひとつ違った切り口を言っていて、受託か自社開発というのは、それほど大きなインパクトはなくてどんな性格のシステムを作るのかというのを軸にしたほうが良いと思っている。ただ、これも要件あらかじめ決まられるのか、そうではないのかというのもシステムの性格とも言えるの、結局要件があらかじめ固定化できるのか否かで決まるように思う。

この二つのセミナーを聞いてみて何かが抜けているように感じた。最初のセミナーでは、設計のところの話がないことで、設計が終わっているという前提でその後の開発のところのスピードのことなのだが、設計のところのスピードと品質がかなり影響するのではないかと思うのである。それと、課題が指摘されていたが、けっこうWeb化とクラウドで解決してしまうような気もした。

次のセミナーについては、お気づきかと思いますが、両方とも既存システムのリプレースなのです。つまり、データモデルにしても機能要件にして、基本的に既存踏襲ですから、真の意味でアジャイルではないのです。それもそうなのだが、リプレース以外で開発案件はないのだろうか。SIerにしても、ITベンダーにしても、情シスにしても、30年前に作ったシステムをリプレースすることがビジネスであり、ミッションだと思っているのだろうか。

ちょっと、脇にそれてしまったが、印象的なものとして、大規模になると全体をアジャイルとはいかないので、分割してやらざるを得ないのだが、そのとき全体管理はウオーターフォール的にやらざるを得ないということと、Webサービスでは、デザインファーストという考えかたが大事だということである。作って見せるのではなくて、見せてから作るというやり方である。

そして何と言っても一番刺さったのが、アジャイルの実践をして感じたこととして「ウオーターフォールだろうがアジャイルであろうが、結局最後は優秀なやつがやればいいシステムを早く作れんですよ」これまた至言である。そうなのです。方法論でもツールでもなく、どうやったら役に立つシステムができるかの本質的なところ押さえることができる優秀なやつがいるかいないかなのだ。
 


2013年4月24日

SEって何?(6)

▐ 解決の方向性

前回、ウオーターフォールモデルの弊害を指摘した。ならば、アジャイルでやればいいのかということでもなさそうだ。ついアジャイルというと、速く作るというHowの話みたいになってしまうことがあって、そのメソッドを知っていればいいSEということになるのだろうか。また、そうでなくて本来的な反復活動で作り上げるということにしてもどういったことができればよいのだろうかと思ってしまう。

どうも開発方法の議論だけで解決に向かうというのは無理があるように思うのである。つまり、いくらいい開発方法を持ってきても悪構造のシステムを作っていてはどうにもならないからである。実際の業務に使えるようなものでないと意味がないわけで、そこの設計が非常に大事になってくる。本当に意味でのビジネスのためのシステムの設計である。

究極のアジャイルは、お客さんのビジネスモデル、業務プロセス、仕事のやり方に基づいたユースケースからさくさくっと実際に動くプロトタイプをつくって、それを動かしながら、変えながら、作り上げるイメージである。動かしている途中で当初のユースケースを変更してもいいし、プロセスも変えてもかまわない。ウオーターフォールの弊害は後戻りできないことだから、全く逆だ。自由に行ったり来たりする。

そうして出来たものは、必ず使うわけです。当たり前の話、使うように作るから使うに決まっています。これまでのやり方だと使われないシステムが半分以上あるというは全くおかしいな話です。確かに、昔のシステム環境やソフトウエアあるいはメソドロジーでは難しかったかもしれませんが、現代では、Web技術の凄まじい向上、クラウドの登場、IT価格の低下によって、さくさく作って、使いものになりそうもなかったらやめてもいいくらいの気軽さが可能になってきています。

こうした時代にSEはどうしたらよいのでしょうか。佐藤治夫さんが指摘するように顧客の顔が見えないような仕事のやり方をしてはいけないわけで、今言ったようなやり方にして絶えず顧客とのコミュニケーションを図りながら作り上げることに立ち向かうべきです。佐藤さんが提起する「日本の"システム屋"の誰もが顧客の顔をみながら仕事をし、それ相応の技術力を求められ、同時に顧客には決断力を要求し、チャレンジする風土と知識・技術力を磨く意識を持つ。これが望ましい姿ではないでしょうか」を実現するにはここで言っていること以外にないと思うのです。

ただ、大事なことは、磨くべき"それ相応の知識・技術力"とは何なのかを確立することである。従来の延長では決してない、ビジネスのための道具の設計、仕事の場のデザインをお客さんと一緒にできるというか、むしろお客さん主体で、自分はファシリテーターとして位置することだろう。仕事のやり方だとか、マネジメントのやり方などはお客さん自身が一番知っているから、彼らが考える背中をちょっと押してやればいい。逆にそれが言えないようなお客さんは相手にしなければよいのだ。"顧客には決断力を要求し"という意味は裏を返せば、決断力のない顧客とは組むなということでもある。

結局、何が言いたかというと、時代が変わり、ビジネス環境も大きく変化し、よりビジネスはスピードや高い質が求められて、それに伴い要求システムの性格も変化している。そうした状況にあって、システムに携わる人々は従来の延長で対処していては対応しきれない。そうであれば、既成概念をとっぱらって考えると同時に、従来と違ったシステム構造や機能そして開発方法論を持ってこないとユーザから見放されてしまう。ですから、当然SEと呼ばれる人たちも変身していかなくてはいけないということなのである。その時、忘れてはいけないのが、"システムは使われてナンボである"ということで、言い換えれば"使われるものを顧客と一緒に動かす"ことなのである。
 


2013年5月22日

つながる経済における実践とは(1)

■ ソーシャルな資本主義 -- つながる経済
今回からは各章について個別にみていきますが、けっこうなことにそれぞれでポイントをまとめてくれていますのでそれにそって考えていきます。切り口はどうしてもITシステムが主になっていきますのでご了承ください。

さて第1章のポイントは次の通りです。
(1) 大量生産品を匿名の大衆に売る「切れた」経済が終わり、継続的なつながりの中から価値を恊創する新しい経済が始まる
(2) 背景は何でもつなぐことのできるネット。ただし、実際に何でもつながるのではなく、信頼してもらって、個人情報を「見せてもらえる特権」を持った企業我競争力を得る
(3) ビジネスモデル、マーケティング、価値戦略、組織など、すべてに大きな変化が来る。

まさに大きなパラダイムシフトですね。これまでの経済社会は大衆の大量消費社会であったわけで、まずはものを作って、それを買ってもらうという作り手側から押し出すプロダクトアウト型の構造だった。ここでは、お客さんの顔が見えない、つまり供給側と需要側が切れていたのである。それでも経済成長期であれば、大量の消費材を飲み込む容量があったのだが、今やものがあふれかえっています。

そうした、大量消費の終わりとインターネットの登場が劇的な変化をもたらしたと思う。インターネットの情報へのアクセススピードとリーチは人々の多様性をもたらし、消費者と生産者の主客の転倒がおきた。個人の叫びが届くようになって、人々は自身の要求を主張するようになる。ロングテール現象である。

ですから、売り方にしても切れていた時代では、匿名の人たちにものを買ってもらわなくてはいけないから、企業のブランド力が非常に重要になって、マスメディアでの広告が顧客からの信頼にとって大事な武器であった。それが、個人の顔が見える世界へと変貌しているわけで、そうなると生産・販売の仕掛けもずいぶんと変わるし、マーケティングでもご存知のように広告が新聞やテレビといったマスメディアからネットへと移行している。

これだけの大きな変化は、とうぜんビジネスモデルだけではなく、企業の従業員の働き方や企業情報システムに影響を及ぼさないわけがない。最初にお断りしたようにITシステムへの言及をしますが、「つながる」ということがシステム上でも非常に大事になってきます。それはシステムそのものもサイロ型になってつながっていなかったのを連携させたり、従業員同士のつながりが電子メールノ普及で格段に向上しています。もはや、自社のWebサイトを持っていない会社もほとんどなくなっているでしょう。

こうした大きなパラダイム変化では、従来の延長での思考態度では取り残されてしまいます。本で強調している「つながる」という意味合いは重要で、ネットは何でもいいからつなげるという精神でもある。20年くらい前に企業にもインターネットが入り込みだしたのだが、やっとここに来て「つながる技術」が多くでてきて何でもできるようになったと思う。これからは、それらをどう使いこなすかが非常に重要なポイントになってきた。
  

2013年5月23日

顧客志向の必要性と限界

幾度となく"顧客志向"の大切さを強調している。お客さんのニーズをよく把握して、その要求に答えるような製品やサービスを提供せよということである。ただ、お客様葉は神様ですとばかりなんでもかんでもお客さんの言うことを聞けばいいのかというとそうではない。どなたが言っていたが、「お客様は王様ではあるが神様ではない」のだ。神様は絶対だが王様は間違えることもあり、時には忠告も聞いてくれる。

だから当たり前だが顧客志向かそうではないのかという二者択一ではなく程度問題に帰する。そのときどんなことでもそうだが、TPOすなわち時と場所と場合によってどっちに軸足をおくのかということなのだろう。で今の企業システムの取り巻く環境をみると顧客志向へ重心を移動させるときなのではないでしょうか。いつやるの?今でしょ!

ところがここで気をつけなくてはいけないのが行き過ぎた顧客志向である。日本人というのは割と極端に走りやすいので、やたら顧客要求を聞きだしてそれに振り回される。その要求が顧客の単なるわがままであっても受け入れてしまう。そうした要求というのはひどいのは個人的な欲求だったり、取りあえず言ってみようという刹那的なものもある。ですから、大事なのは捨てることである。そのためには要求を抽象化・一般化できるかどうかである。

もし抽象化・一般化ができるようになれば、顧客志向からデザイン志向に切り替えていったらいいと思う。顧客要求を聞くのだがそのままではなく、逆にデザイン的な観点から提案する形ですりあわせるのだ。つまり、モノとしてシステムとしてそれがもつ機能やカタチをデザイナーとしてこうあるべきだと提示する。もちろん、骨組みは顧客要求が詰まっているが、道具やシステムにするときは専門家の目も必要なのである。

さらに進んだデザインの考え方では、「椅子をデザインしたい」という考えからはじまるのではなく「人々がストレスを感じない家具を創る」という思考から始まると言われている。これには、行動の観察というフィールドワークが不可欠だろう。人間がどういう振る舞いをしているのか、どんなスタイルで生活しているのかを観察するところからデザインを考えるのである。

これは椅子に限ったことではなく業務システムもしかりで、「人々がストレスを感じない販売システムを創る」ことであり、「人々が楽しくなるような営業システムを創る」のである。ただ、最初からそうはできない。第一歩はあくまで顧客要求の引き出しから始める顧客志向であることは言うまでもない。

2013年5月29日

つながる経済における実践とは(2)

■ つながる時代

第2章は「つながる時代」です。ソーシャルな資本主義の基盤になるクラウドを中心論じていいます。この章のポイントは次の通りです。
(1) クラウドがすべての情報を結合し、ヒトやモノがつながる
(2) ワイヤレスによって、あらゆる現場から情報が発信され、クラウドで結合する
(3) プラットフォーム上で知が結合して、新しい価値が生まれる創発現象が起こる
(4) 切れていたヒトやモノがつながることで、ビジネスモデルも組織も大きく変わる

たしかに、つながる時代の象徴はクラウドかもしれませんね。クラウドが登場した当初は、それほど衝撃を受けたわけではなかった。昔からあったデータセンターとどこが違うのかとか、サーバー運用でのメリットだけじゃないかとか、ただ技術的にはすごくて仮想化技術を使って簡単にスケールアップ、スケーアウトできることにはびっくりした。

というのも、クラウドだからといってすばらしいソフトができるわけでもないし、クラウド用のアプリだってそうなかったわけだからである。ところが、徐々にクラウド上で様々なアプリケーションが動くようになり、プラットフォームも充実してくるとその威力はすごいものがあると思えるようになった。特にSNSの進展はすさまじく、このような共有のメカニズムが、価値を生み出して、新しいビジネスモデルに組み込まれていく。

そこから起こる現象として「創発」という概念を提示している。ネットワーク上で多様なヒトが交流し、多様な情報が結合して、新しい価値が生み出されていくことと定義している。何だかWeb2.0集合知みたいな話ですが、今はやりのエコシステムとか生態系経営といった文脈に近いところでしょう。もはや、ネットワークをつかって"巻き込み"型の関係性がますます重要度を増していくのではないでしょうか。

ここでプラットフォームということを考えてみます。この言葉も解釈がまちまちになる可能性があるのでちゃんと定義しておきましょう。本では少し広義にとって「多様な主体が恊働する際に、恊働を促進する情報交換の基盤となる道具や仕組み」と定義しています。単なる情報のつながりで見るのではなく、情報を介した人間の恊働だと見ているわけです。

これは非常に重要なポイントで、ついついクラウドでのつながりだけに目がいくと情報さえつながっていればよいと考えがちです。情報だけでは創発は起こりません。あくまで情報を介して人間が創発を起こすのです。ITシステムで注意しなくてはいけないのがここのところで、情報の流れを自動化することがシステムであると勘違いしないことです。

このプラットフォームを重要であると考えているのが、多様性と共通性のバランスということです。すなわち同質のものがいくら集まっても相互作用から新しいものは生まれません。一方、多様なものが集まっても、どこかに共通の接点がないとつながりません。このプラットフォームの設計が大事になるわけです。いま、ぼくは社内の恊働プラットフォームはデザインしてあるのですが、これからは先ほどの生態系経営のように社外も含めての恊働を考えて行かなくてはいけないようになってきています。

さて、つながる経済では従来のような切れた経済では成立しなかったようなビジネスモデルが可能になってきます。その典型は、売り切り-所有権移転から貸与-利用権許諾モデルへの転換です。これからは持たないビジネスがどんどん登場します。無償サービスもつながっているから提供できるのです。つまり、匿名の顧客にブランド力をたよりに商品を押し売りする時代は終わったのかもしれません。それだけ、顧客と一体となったビジネスモデルが望まれるのでしょう。

2013年6月21日

ルール適用ということを考えた

昨日のなでしこジャパンの試合で前半に宮間が退場になったことに対してミスジャッジだということを書いた。そのことで少し考えさせられたのでちょっと追記しておこうと思う。これは、サッカーに限らずにビジネスの世界でも、あるいは社会生活においても当てはまるような気がするからである。

昨日のサッカーの審判は、ルールに則って厳格に適用したとも言える。しかし、それが正しいルール適用といえるのだろうか。つまり、ルールというのは、それが適用されるその場の環境とか状況、さらに背景や方針といった様々な要素を勘案したものであるべきではないのかということである。もちろん、そんな以前にやってはいけないこともあって、例えば法律なんては厳密に客観的に適用されるべきであることは当然である。

そうしたもの以外に規範とか、指針のようにある程度の裁量が許されるものがある。それもルールと称されていて、その適用にはケースバイケースという例も多いのである。サッカーのレフリングというのもまさに杓子定規ではないその場に応じた臨機応変の笛が要望されている。プレーの流れを止めないようなアドバンテージという対処もそのことを言っている。

簡単にいえば、KYな笛は吹くなということである。昨日のように、地元日本の企業がスポンサーになって外国チームを招待しての親善試合でホームのチームの選手を退場させますか。それとともに、そもそもルールは何のためにあるかも考えたらいい。サッカーの場合はとてもシンプルでやってはいけないことが書いてあるわけで、GKがペナルティエリア内で使う以外は手を使ってはいけませんとか、ズルしてはいけませんというオフサイドとかとあとは危ないプレーなんですね。

この危険なプレーというのは厳密には決められないので審判の判断に委ねる部分が大きくなります。そして、その危険度に応じて赤と黄色の警告が出されるわけです。これも裁量です。ところで、ぼくは個人的には男子と女子とでは危険の受け止め方も違うように思う。どうしてそう思うかというと、試合中の接触でタンカに載せられる女子選手が少ないということである。

男子だとやたら派手に倒れてタンカで外に出るのだが、女子選手はよほどのことがない限るすくっと立ち上がる。これは、ぼくの持論なのだが、ボクシングと同じで、重量級ではKOが多いのに軽量級では少ないということに通じる話しなのである。つまり、人間というのは、体重とか性別でアタックに対する"耐性力"はあまり差はないのに比べ、"アタック力"には大きな差があることが起因していると思うのである。だから、女子でカードを出すような危険なものは少ないから、やたら出してはいけないのだ。

ちょっと、意地になっていますね。さて、ビジネスとか社会生活にも当てはまると言いました。ぼくは今ジネスプロセスのコンサルティングをしていますが、日頃からプロセスの構成要素で非常に重要なものに業務ルールがあると言っています。つまり、単位意思決定の連鎖であるプロセスにおいて、その意思決定は業務ルールに従って行なっていることがほとんどだからです。

そして、この世界でもルールを厳格に適用すればよいのかという問題があります。おわかりと思いますが、ビジネスの局面、特にお客さんが絡んでいるようなところでは、ルールをそのまま適用できるとは限りません。例えば、お得意さんと一限さんでは、ルールの適用の緩さに固さに差がでます。逆に厳格にルール適用ができるものはITで自動化すればよいのですが、現実の世界はそれだけではないですよね。

結局、ビジネスの世界でも状況に応じたレフリングが重要になってきます。そのためには、この試合はどういう種類の試合(どういう案件)であって、どんな選手たち(顧客や従業員)で、試合状況(収益状況とか)に応じて増えを吹く(指示を出す)ことなのだろう。そのスキルを上げるには、多くの経験を積むことと、他所の試合(同業他社や異業種のビジネス)を観察することである。
 

2013年6月28日

適用域の適正化がものすごく大事なこと

ものごとを整理するときとか、どんなことをしなくてはいけないとかといった時に5W1Hで考えるというのがよくやられる。その時、5W1Hのどれが大事で、また思考の順番はどうしたらいいのだろうか。つまり、なぜやるのか、その目的はといったことが重要でそれを真っ先に考えるのがいいのか、それとも何をするのか、いつやるのか、どこでやるのか、誰がすべきなのか、どんなやり方なのかといったことである。

みんな一緒にやればいいではないかという意見もあろうかと思いますが、結構、重要度と順序は大事だと思うのです。よく、目的と手段を間違えるなとか、今できることは成熟度によって違ったり、外部環境によってもその時期なのかといったことがある。そういう意味で状況に応じて、重要度と順序も変わってくるのだが、あえて、ここでは"Where"の重要性について考えてみたいと思う。

どこのことを言っているのか、どのエリアでやろうとしちるのかといったことである。なぜかというと、いくら高邁な理由があったとして、いくら素晴らしいプロダクトがあったとして、いくら高度な技術があったとしても、それを実施するところ、それを提供するところ、それを使うところを間違ったら何にもならない。逆に言うと理由やプロダクトや技術はどんなところでも通用するというわけには行かないということである。

となると、適用領域をきちんと設定することが非常に重要で、どうもそこが第一歩ではないかと思いだしている。このことは、どんなことにも当てはまるのではないでしょうか。議論が噛みあわない原因はここにあることが多い。例えば、新聞紙面の議論でさえこの間違えをしていて、原発の問題にしても安全性のことなのかエネルギー戦略の話しなのか混同していたり、ついちょっと前にも体育教師の体罰の問題を取り上げているのだが、それが体育授業のことなのか部活のことなのがごちゃごちゃになっていた。(体育授業で体罰ってあるのかなあ、部活の先生がみな体育教師なのかなあ)

これはテレビで知ったのだが、最近話題の「いつやるか、今でしょ」(これはWhenだ)で一躍有名になった東進ハイスクールの林先生が面白いことを言っていた。「努力は裏切らない」とよく言われるがこれは不正確なのだという。「正しい場所で正しい方向で十分な量の努力は裏切らない」というべきだと。"正しい場所"をちゃんと定めないといくら努力してもムダですよと言ってるわけです。

ITの世界でも同様な間違いがあって、何か新しい技術や製品が登場するとどんな領域でも適用できると誤解するケースがけっこうある。例えば、BtoBとBtoCではずいぶんと違うのに同じように語られたりする。どこにITを適用するのかをきちんと設定してから、何をどうやるのかを議論したいものである。次からもう少し堀下げてみようと思う。
  

2013年7月11日

適用領域の適正化がものすごく大事なこと(その2)

前回5W1Hの中のWhereが意外と重要であるという指摘をした。今議論していることとか、問題となっているのはどこの領域のことなのかをはっきりさせないと噛み合わなかったり、あらぬ方向に行ったりする。それで最後は好き嫌いの話になって、とにかく嫌いだからでジエンドである。

前回も体罰に関する話を書いたが、こうした問題にはしょっちゅう出くわす。大体において議論になっていることはこの適用域の共有が曖昧になっていることが多い。特に日本人はどうもはっきりさせることに熱心ではない。最初にどこの話であって、そこでの前提条件や事実認識を共有しておけばほとんど解決してしまうような議論を延々とやる。

ITの世界でもご多分に漏れず同様の咬み合わない議論をみかける。よくあるのは、バズワードであるが、流行り言葉をすぐ鵜呑みにしてしまう。これも往々にして、適用域の問題が潜んでいる。みんながワーワー騒ぐとなんでもいいから受け入れてしまって、使い物にならないなんてはめに陥る。

だから、話題になったものは冷静にどこに適用すべきものかをきちんと判断してから採用しなくてはいけない。提供側はなんでもできます、どこにでも使えますと万能薬的謳い文句をいうので踊らされないようにしたいものだ。

例えば、ITの世界で言えば、今の流行りだとビッグデータというやつである。確かに、情報量の非常に多いデータが大量に入手でき、好きなようにハンドリングできるようになったことはすごいことだと思うのだが、そんなビッグなデータを必要としているのはどこの会社、あるいは機関なのだろうか。

少なくともBtoBのビジネスをやっているところでは必要ないだろう。不特定多数の消費者を抱えているようなところであって、たいしたデータ量でないところにビックデータと言っても意味がない。それと、ビックデータを溜めておくだけでは何もならないので、それを解析すべきニーズがあるのかということである。

ちょっと前では、クラウドというのがあった。今はさすがに落ち着いてきたと思うが、まだ何が何でもクラウドでというケースもある。プライベートクラウドなんていう変なことを標榜する向きもあるが、そんなものは自前のものでやればいいじゃんと突っ込みたくなる。

繰り返すが、向き不向きとか相性とかは必ずあるわけで、それは適用域の適正化をきちんと考えるということにつながる。この見極めが非常に大切であるのだが、そのために必要なことはものごとを概念化、構造化できているのかということに尽きる。構造化できていないものにエリアを特定しようにもできないからである。ビジネスITでもどこの業務領域にどんなITを導入するのかを見ていかなくてはいけない。この話は次回に。
  

2013年7月19日

プロセスとデータ

プロセス中心とか、プロセス先行とか言っているとデータをおろさかにしているとつい誤解される。別に、プロセスだからそれだけを議論しているわけではない。何を中心にあるいは先行して考えるのかという点で軸足が違うだけで、もちろん両方とも必要である。しかも、それだけではなく他にもルールだとかロールだとか必要な要素がある。

そこで、つらつら見ていくと何がいったい中心なのかだが、親子関係というか、どちらがどちらを包含しているかを考えてみる。つまり、プロセスの構成要素としてデータがあるのか、データの構成要素としてプロセスがあるのかになる。これだと明らかにプロセスの中にデータがあるというふうに見て取れる。

プロセスの概念の方が大きいのである。だからプロセス中心、プロセス先行で見たほうがいいと言っている。なぜならば、業務システムをつくるのだから、いかにビジネス要求を実現できるか、その受け皿として機能するのかということが必要だからである。戦略とか方針だとか、ビジネスモデルといった大き枠から落ちて来るものを受けるには、それなりの抽象度の高さがいるというわけである。

プロセスを先行させるということは、アクティビティの並びを書いていくことになるのだが、アクティビティの中身、すなわちその構成要素は何かというと、確定データ、付帯情報、業務ルール、参照情報、ロールといったものです。そうなんです、ここでデータが出てきます。いわばエンティティを表現しているわけです。

これらをまとめて表にしたものを「プロセス要素表」としていますが、ER図に近いのではないかと思っています。昔DOAで佐藤正美さんの「T字形ER」手法というのを使って、製造・品質管理・物流システムを開発したことがあるが、その時教えてもらったER図の書き方は、上にイベント系のエンティティ、下にリソース系のエンティティを置いて、イベント系は時系列に並べろというのであった。

これって、プロセスを書いていることではなかったかと思っています。リソースデータを使って、または参照して、イベントデータを生成して、それを順番に進めるイメージです。さらにデータの正規化をするのですが、プロセスの正規化をすれば自然とできてしまうのではないでしょうか。プロセスの正規化というのも大事なような気がします。似て非なるプロセスを各事業部で使っているなんて非効率的です。

素人的な発想と理解ですから間違っているかもしれませんが、少なくともビジネスサイドの人の理解という意味では、プロセス中心、プロセス先行の方がわかりやすいと思います。データ中心だとどうしてもITシステムをどう作るかという見方になってしまい、業務オペレーションをどうやるか、すなわち、システムをどう使うという視点が薄くなるような気がするのです。そういえば最近はDOAって言葉を聞かないなあ。
  

2013年7月20日

Kintoneバージョンアップ

サイボウズ社が提供する「kintone」がバージョンアップした。今回の主な機能アップは、「スペース・ゲストスペース」と「JavaScriptカスタマイズ」である。この2つの機能は以前から欲しかったもので、これでだいぶ充実してきた。青野社長は「年内には、米Salesforce.comの契約者数に追い付くと予想している」と意気込んでいるが、なかなかいいんじゃないですか。

ぼくは、プロセス志向の業務アプリプラットフォームとしてこれを選定していて、実際にもコンサルとして関係している会社で使っています。当初は、標準的なWebデータベースでしたが、簡単に画面ができるというところと、コミュニケーションを取り入れたチーム業務に狙いを定めてきているのが非常にすばらしいと思う。サイボウズ社自体の働き方も先進的だし、そうした新しい時代の働き方に合った道具になるといい。

前回の3月のバージョンアップでもグループ機能が追加されて、プロセスオペレーションが表現しやすくなったのに続き、今度は「ゲストスペース」で企業間連携が非常にやりやすくなった。昨年、修理サービスのプロセスをkintoneで構築したのだが、そのとき修理するのを製造元ではなくサービス会社にお願いするとかその逆とかがあって、その連絡とかが錯綜するよねみたいな話があった。そんなことはこれで解決してしまう。

また、今や一社でなんでもやる時代ではなくなってきて、設計と製造を分けるとか、それも海外の会社と連携してなんてことがあたりまえになってきつつある。そんなとき、いちいちメールや電話でやり取りなんてしていたら、正確さと速さが失われる。さらに、よくある話として、注文がFAXで飛んできてそれをまた受注受付に再入力しているなんてこともやっている。これもEDIなんてじゃなくて直接注文を打ってもらえばいいのだ。

こうした協業オペレーションを同じシステム上でやれるわけだから相当な業務効率の向上になるように思う。いや効率化だけではなく、質的な向上や創造性といったものも期待できるのではないでしょうか。

もう一つの「JavaScriptカスタマイズ」は、これも会社の業務と同様に一つの業務アプリでなんでもできるわけではない。そうなると、他システムとの連携やデータの取得などが必須になってくる。また、ぼくが言っている「プロセス要素」にある参照情報とか業務ルールを取得するのに今まではリンクするしかなかったのがこれで何でもできるようになりそうだ。

さらに、UIもよくなりそうだ。例えばプロセス進捗一覧にステータス表示をするのだが、「作成中」とか「完了」とか言葉だけで表現していたのが、これの色を変えてよねと言っていたのがやっとできるようになった。完了したら赤になったりすればわかりやすくなる。

「Kintone」が進化したぞ、すごい。ぼくが以前から言っていたパラダイムが変わってきていること、すなわち、データ中心からプロセス中心へ、作ることから使うこと、個人的ワークスペースから協同的ワークスペースという流れに沿ったものになっている。となるとますます、従来のようなデータ登録システムを作っていてはだめで、本当に使うのが楽しくなるようなオペレーション発想の業務アプリを作らないとせっかくの機能が宝の持ち腐れになってしまう。
  

2013年7月27日

つながる経済における実践とは(7)

■ つながりの時代の創発経営

ここまでは主につながる経済とはどんなものであるかについて議論してきたが、ここからは情報を介したヒトやモノのつながりがもたらす創造性についてである。現代は、生産性を追求することより、創造性を追求する時代になってきている。創造性の高い経営が求められている。その際に重要なキーワードがあって、それが「蓋然性の経営」ということだという。この章のポイントをみてみよう。

(1) 情報を介して多様な主体がつながり、相互作用する中で、部分の総和を超えた価値が生まれる創発現象が起こる。創発がイノベーションの源泉となる。
(2) 創発が起こりやすい環境を整える「蓋然性の経営」が重要となる。
(3) 蓋然性を高めるためには、多様性を重視しつつ、多様な主体がつながる共通基盤を作ることが重要

最初に出てくる創発というのは、簡単に言うと異質な主体が巡りあって相互作用する中で生まれるイノベーションである。同質の人間が集まって昨日と同じことをしている中で行われる改善(効率性向上)は創造ではありません。ですから創造性の高い経営を行うにはいかに創発的な価値創造を活性化させるかにかかっているわけです。つながりの場の設計とマネジメントが重要なのである。

蓋然性というのは、何かが起こる可能性が高まっている状態のことで、「偶然性」と「必然性」の中間にある感じである。この「蓋然性」を高めるには、第2章でもでてきたプラットフォームが大事になります。多様な主体間における、共通言語や、動機、主体間の信頼関係の構築支援などを通じて、情報交換による結合を生み出しやすくする環境です。

このあたりは、最近のSNSといったようにコミュニケーションを軸に人々がつながる環境が多く登場してきています。こうしたつながりの中からイノベーションも起きてくるのでしょう。ただ、企業システムの中でこうした動きが活発化しているかというと必ずしもできていないように見受けられる。どうしてもさっき言ったようにまだ多様性より均質性を重んじるから、効率性追求へ軸足が行ってしまう。

ネット系企業とか若い子がはじめたスタートアップ企業などは働き方や人材などでは多様性がみられるようになってきた。しかし、既成の大企業あたりではまだまだ標準化志向でムリ・ムダ・ムラをなくそうなんて言っているうちはイノベ−ティブなダイナミズムは生まれてこないだろう。そんなところを変えるには、大上段に振りかぶってもムリなのでちょっとしたことを取り入れてみたらどうだろうか。例えば業務システムの中に"遊び心"を入れてみたらとか、そんな些細なことからでも始めていってもいいような気がする。
  

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

 
 

2013年7月31日

適用領域の適正化がものすごく大事なこと(その3)

ここからはITの話になるのだが、ITと言っても様々なものがある。スマホみたいなものから、車に搭載されている機器にも入っているし、Suicaの読み取りだってITである。会社の中でもハードもソフトもITと呼んでいたり、現場の制御システムから、会計システムまで幅広い。もはや、ITを意識しなくても多くの場合に何らかの形でITが関係している。

なので、ITの適用というよりITを活用した業務システムという風に絞り込んで議論することにします。すなわち、企業のなかのどこにどういう業務システムが必要で、どんな使い方をするかについて考えていきます。

その議論に入るときに大事な視点は、企業のビジネス活動の構造がどうなっているのかがあります。その構造をきちんと定義し体系立てておかないと本質を見誤ることになります。次の図が企業活動の基本構造を示しています。ここから様々な管理プロセスやサポートプロセスが広がっています。

企業活動の基本構造.png

基本中の基本は、顧客の要求に対して、経営方針や戦略に従って、持っているリソースを使って、製品やサービスを提供して、代金を回収するということになります。ここはきちんと抑えておかないといけません。よく、製品を作ることがメインに置いてしまう場合がありますが、別に生産しなくても購入転売でもビジネスですから、生産機能はマストではありません。あくまで、お客さんのウオンツに対して答えを届けてあげることなのです。

この図を見ながらITの適用領域を考えてみましょう。顧客接点のところは、お客さんを獲得すること、要求を聞くこと、商談すること、オーダーをもらうこと、クレームなどを聞くことなど主に営業部の範疇の活動があってそこにITを適用することになります。従来は、SFAとかCRMと言った言い方でITが導入されてきました。

右側の事業成果というところは簡単には決算を行うところです。貸借対照表や損益計算書、キャッシュフロー計算書など決算報告の時に必要な書類を作成していきます。事業活動の結果を数字で示す部分です。経理部とか経営管理部といったところが活躍します。ここは、最初は会計システムといったものでしたが、いまはERPと呼ばれるような統合ソフトが入っています。

上の部分は組織目標ということになりますが、経営理念から始まって戦略、事業方針、中期計画、予算といった計画系の活動になってきます。ITは上位には適用が難しく、予算編成とかはERPでもできますし、ITが使われます。戦略とか事業方針といったところは、直接ITが使われるというより、経営者や事業責任者が判断するための支援にITは利用されています。

下のリソースは、ヒト、モノ、カネ、情報といった経営資源をビジネス活動に供するために準備しておくという機能です。ビジネスを行うために必要な人材を確保するために人事データが必要になりますし、生産を拡大するために設備の容量を把握しておかなければいけません。

今言ったようにビジネス活動にとっては実体のリソースというより、「情報」になったものを扱います。ですから、ここは「情報」が常にアップデートされて取り出しやすいようするためのデータ管理が重要になってきます。

2013年8月 3日

つながる経済における実践とは(8)

■ ソーシャル時代の知られざるリスク

「創発はコントロールできない」ということを理解する必要がある。従来のような大量生産・販売だと、計画に基づいて調達・製造・出荷という決まったシステムに乗っかっているわけで、そこではある程度コントロールが効くようになっていました。しかしながら、創発の世界はコントロールが難しくなってきます。なぜなら、個々の自由な発想を促し、それらが偶発的に結合されることで新しい価値を生み出すわけだから、コントロールという概念にはなじまないのである。それは、当然リスクを伴なうものなのである。この章のポイントは次の通り。

(1) つながりの中から生まれる創発現象はコントロールが困難で、時に暴走する
(2) コントロールが難しい中で、システムは時に落ちるものだと考えないとリスク管理ができない
(3) リスクは顕在化するものと考えて、事故を防ぐ防災だけでなく、起こった時のダメージを減じる減災の考え方をしなければいけない

コントロールが効かない事態が起こりえるのである。混乱が加速度的にさらなる混乱を起こす現象が出てくる。極端な話、つながりのあるシステムでは、構成要素間の相互作用によって、全体が暴走した挙句崩壊してしまうこともある。株式市場なんてまさにこの様相を想起させられる。

創発とコントロールとは相容れないから、絶対安全な仕組みはないと考えなくてはいけないのだ。東日本大震災における原発事故で絶対安全であるという神話が崩れたことはまさにこのことです。リスクは回避したり完全に封じ込めたりすることはできるものではないということを身をもって知らされました。そうなると、リスクが顕在化した場合の被害を最小限に食い止める「減災」の考え方が重要になってきます。

さて、この問題は業務システム作りにおいても大事なところで、何事も起こらないシステムを作ることは不可能に近いでしょう。銀行のオンラインがダウンしたことも、鉄道の改札システムが止まってしまったこともありましたよね。改札システムなんかだと駅員さんを動員してしのげるかもしれないのですが、銀行の場合は相当大変なことになります。

システムの規模が大きくなり、しかも自動化の程度が上がってくるとアンコントローラブルの部分が増えて被害が大きくなっていきます。効率化、利便性の追求とシステムダウン時の対応の難しさというトレードオフがすごく重要になります。減災の考え方を取り入れていかなければいけないのでしょう。

ぼくがやっていることは小規模で、もし動かなくなっても手作業でやれるからといわれますが、それでも小さな会社だと影響も大きくなります。ですから、システムの適用域の問題もありますが、自動化は極力少なくして、人間の裁量を増やすことを心がけています。
  

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

 
 

2013年8月 6日

適用領域の適正化がものすごく大事なこと(その4)

前回は、企業活動の基本構造を基にITの適用領域を議論しました。組織目標、顧客接点、事業成果、リソースといった領域について、ITはどんな使われ方をしているかをざっと述べておきましたが、ひとつ抜けていましたよね。そうです、真ん中に位置するプロセス活動という領域です。

水平方向の流れが、顧客に製品やサービスという価値を提供する活動で、垂直方向は、組織能力といったものになります。そして、それが直交する部分がプロセス活動というわけです。ですから、非常に重要なポジションにあるわけです。ところが、重要な部分でありながらITという観点からはあまり注目されていなかったような気がします。

IT化されていなかったということはIT化する必要がなったか、それともIT化が難しかったのかですがどちらだったのでしょうか。おそらく、両方の理由があいまってあったのではないかと思います。この部分は決まりきった定型化された手順があるわけではなく、案件ごとに対応がまちまちだったり、人間の裁量部分が多くあります。したがって、属人的対応が主となっているのです。

また、これまでのITは自動化ツールとしてはあったのでが、属人的な領域で効果を発揮するITはなかったと言えます。ワークフローやグループウエアなどがそうだという人もいますが、結局は個人の作業の領域でしかないのです。組織として、チームとして協働的に行うためのITはありませんでした。

例えば、お客さんのサービス要求があったとすると、顧客リストにその要求を登録する、あるいは案件をデータベースにするといった部分ではITで行うのですが、ではその案件をどう処理して、お客さんは満足してくれたのかといったところは隠れてしまっていました。

近年、この領域こそ経営にとって、事業にとって非常に大事なところであうという認識が高まっています。なぜなら、ただいいものを作れば売れるという時代から、顧客のニーズ、さらにウオンツを的確に把握して、それににあった製品・サービスを届けることができなければビジネスから降りなければいけない時代に変わっています。

この顧客ニーズに的確、迅速に対応するというのは、適正なプロセスがあってこそ実現できるわけで、そのプロセスオペレーションの質を高めることが顧客満足度を得る道なのです。しかも、組織・チームとしてのオペレーションになりますので、それに合ったITが望まれる。最近はSNSのようなコラボレーションを意識したツールも登場してきたので、ITが活用できるようになりました。

要するに、気をつけなくてはいけないのは、今まで言ってきたように従来の定型的で自動化できる領域に適用していたITをそのまま非定型的な領域に適用してはいけないということです。これはITそのものもありますが、発想も転換してかからないといけません。"郷に入っては郷に従え"ということなのです。適用領域に合った適正なITを導入すること、利用するITが効果を発揮する領域を見極わめることが非常に重要であることがおわかりになったでしょうか。
 

2013年8月10日

つながる経済における実践とは(9)

■ 価格をデザインする

つながる経済で最も大きく変わるのが価格です。なぜかというとコスト構造が劇的に変化するからです。従来の大量生産・販売を主軸とした大衆消費社会では、大量生産品の価格形態です。すなわち、コストに利益を乗せて一個いくらという売価を設定します。これとは違った価格決定のメカニズムになってきます。第9章のポイントはこうです。

(1) 継続的関係の中で利用権をライセンスするモデルなどが広がる中で、価格戦略が大きく変わる
(2) 情報技術の発達でピーク時割増料金やオフピーク時格安料金などが機動的に実施可能になる
(3) わがまま顧客がコスト負担をし、低所得者向け低優先度サービスが低廉化するなどの現象が起こるだろう

つながる経済における価格決定がちがったものになった要因は何かというと、ひとつはつながり経済のドライバーになっている情報の複製コストがほとんどゼロだからです。つぎに、サービス化です。どういうことかというと、ものの所有権を移転するモデルから、利用権を売るモデルになったことです。一個いくらではなく、時間あたりいくらとか、毎月いくらといった価格体系になるのです。

また、単に価格だけではなく誰が払うのかということも変化しています。例えばの例であげているのが、アマゾンのキンドルです。この電子書籍端末の通信料金は本を読む人ではなくアマゾンが負担しています。ということでビジネスモデルが劇的に変化していて、コピー販売モデル、広告モデルなどの無償サービスなど様々な形態が登場してきています。

この無料のビジネスモデルは、定額制の通信料金によって支えられています。ただ、使い放題は設備を増やさなくてはいけないのに収入が増えないという問題に直面するのですが、それを解決しているのがベストエフォートという考え方です。最大限の努力はするが保証しないということです。

ですから、このサービスだと多くの人が使いたい時間になると混雑してサービスの質が落ちることになることです。そこででてくるのが、有料プレミアムサービスなわけです。これがポイントの3つ目にあげたようにわがままなお金持ち顧客に相応の対価をはらってもらいことでつつましい一般顧客が格安にサービスを受けられる用になったのです。

確かに、企業システムなんかでも、あるユーザ数までとかある容量までは無料なのだが、それを超えると有料になるなんていうソフトウエアがクラウドでは多く見られます。大きな企業が負担してくれているおかげで、小規模零細企業とかわれわれ個人事業主みたいな"つつましい"人々は助かっていますね。

小規模の会社のIT化のハードルがずいぶんと下がってきたわけです。だからといって安いから入れればいいやという安易な導入は慎むべきです。無料でも間違ったものを入れると業務の質を落としたり、保守も含めた余計な手間がかかってしまい結果的に高くついてしまうこともあるからである。
  

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

  


2013年8月13日

適用領域の適正化がものすごく大事なこと(その5)

今回は、ちょっと視点を変えて見てみます。業務の性格から適用領域を考えたらどうなのかです。下の図は、縦軸に業務の定型性、すなわち決まりきったルーティンなのか、ケースバイケースとか、環境とか条件で変えていくとかいったアドホックなものなのかという区分、横軸に時間、短期的な業務なのかそれとも長期にわたって行うものなのかである。

PPRO4象限.png

いくつかの業務形態をプロットしてみると、まずは短期で定型的なものがあります。多くの日常的な事務処理がこれにあたります。コールセンターでの受注受とか、請求書や発注書の発行やらですね。こうした単純なものはITを使ってどんどん自動化されています。

また、定型的で長期にわたるものがあります。現場に近い所ではリソース管理がそれに当たるのではないでしょうか。ヒト・モノ・カネを中心とした管理ですね。例えば、人材管理だと、採用から教育、異動、登用という風に長期にわたって管理しますが、やることはほぼ決まったことです。も少し経営的な部分となると予算なんかがそれですよね。1年で回したりします。

一方、非定型的なもので比較的短期なもの、案件単位でさばいていくようなものはプロセス管理になってきます。ここでさんざん議論してきたものですね。非定型でも長期にわたるものもあります。期間が長くなるとだいたいはプロジェクトという名称も付けて管理していきます。プロジェクトの長いのは研究開発ですよね。薬の開発なんて何十年単位なんてざらにあります。

経営では戦略なんては長期ですし、ビジネス環境が変化すればそれに応じて変えていかなくてはいけません。昔は、ひとつの戦略で長くもったものですが、いまやそのサイクルが非常に短くなってきて、そのうちプロセス管理的な対応になるかもしれません。戦略立案プロセスをしょっちゅう回しているなんてことになったりして。

こうして見ると、左下の短期定型業務にはITは早くから入り込んで貢献していますし、同じ定型で長期に渡るものでもデータベースという形で寄与しています。ERPがEnterprise Resource Planning というようにこの領域のパッケージはけっこうあります。

しかしながら、上の部分ではまだまだITの活用が不十分だといわざるを得ません。プロジェクト管理にしても、ガントチャートをかいてWBSで管理しているだけでいいのでしょうか。基本的にはプロセス管理もプロジェクト管理も時間軸が違うだけでやるべきことは同じだと思うのですがいかがでしょうか。
  

2013年8月23日

IT経営と呼ぶのはやめよう

IT経営という人がいる。IT経営力大賞というのもある。でもちょっとおかしいような気もする。ITを使えばいい経営ができるように聞こえるし、そもそも経営力って一体何なのだろうか。乱暴に言えば、経営とはITなんか関係なくて儲かっていてかつステークホルダーが満足していてそれが持続されていることであるはずだ。

IT経営でイノベーションを起こすのだという人もいる。これもちょっとおかしい。情報システムを機敏に開発・変更できなければ、トップにイノベーションのアイデアがあってもその実現が困難になるというのもなんか変だ。

イノベーションを起こす企業とはスタートアップが多い。イノベーションを起す事業は、まっ更なキャンバスに描かれる。その時点で情報システムを使ってイノベーションを起こしたというのを聞いたことがない。すなわち、インベーションにITは必要ない。イノベーションを起こした後のビジネスモデル維持にITが必要になってくるのだ。

ここで誤解しないでほしいのは、イノベーションを起こすようなプロダクトやサービスがITを使っていないということではない。逆に今やITが関係しないプロダクトやサービスのほうが珍しいだろう。IT経営と呼ぶようなITのことを言っている。企業情報システムあるいは業務システムといったものを指している。

正確に「ITを活用して経営の質と効率性を高める」というくらいの言い回しにしてくれないと困る。当たり前だがITはあくまでツールだから使い方や使う人によっていかようにもなりうるわけで、経営者のリテラシーが問われるのである。経営者自身が自らの頭のなかで「こういうことをしたいのでこんな道具がほしい」と考えないといけない。

決して、本に書いてあるから、コンサルタントの人に言われたから、ITベンダーから勧められたからというだけでITを導入しても何もならない。というようなことを書くと、経営者はITの専門家ではないから、どんな事ができるか分からないから、専門家が気付かせなくてはいけないという人がいる。

これって、経営者に失礼だし、そんなことよりITも活用できない経営者に手を差しのべるのもいいけど、雇用調整助成金のように間違った延命措置となるからやめたほうがいい。現代はITを活用できない会社はいくらまわりでワイワイ言ったところで潰れていくのだから優しくする必要はないと思うのだがいかがでしょうか。
  

2013年8月19日

つながる経済における実践とは(10)

■ 「つながり上手」な企業のアーキテクチャ

これまで経営的な概念を議論してきましたが、本章では企業アーキテクチャに関するものです。アーキテクチャというとわかったようでわからない側面もあるので、定義しておきましょう。本ではこう言っています、「全体システムをどのような部分(下位システム)に分けて機能分担させ、下位システムをどのようなインターフェースで連携させて全体機能を発揮させるかという設計思想がアーキテクチャである」。ぼくがよくいう構造化という概念に近いものです。

つながり上手な企業は、当然のように、つながりやすいような構造になっていなくてはいけません。そのために必要なのが「アーキテクチャ」なのです。現代の企業は内外とも閉ざされたものでは立ち行かなくなってきていて、いかにオープンにして連携をうまく行うかが企業の存続に関わるようになっているのです。例によってこの章のポイントを見ていきましょう。

(1) 21世紀の企業はつながり上手にならなければ競争に負ける
(2) つながり上手になるためには、オープンなインターフェースを持つこと重要
(3) 創発価値を生かすためには、統制型の組織ではなく、自律性を生かす組織が必要
(4) 多様性が生み出す創発メリットを生かすためにも、共通基盤が必要

アーキテクチャというと情報システムの仕組みみたいな取り組みに捉えられがちですが、そうした技術的、表面的なものではなく、文化とか風土といったことが非常に大事なことだと思います。いくら高価で立派なシステムを導入しても、仮にそれがオープンなシステムであったとしても、それを使う人のマインドがオープンでなかったら、つながることはできないのです。

そして、インターフェースの標準化ということも大事な戦略となってきます。いくら外に向かって開いていると言ってもそのインターフェースが固有のものだったりするとつながりにくくなってしまいます。ただ、その時悩ましいのは多様性と共通性のジレンマです。多様性がなかったらつながったとしても新しい価値が生まれない。逆に多様性が行き過ぎてまったく共通性がないとつながらなくなってしまうというものです。おそらく、つながり部分のみに共通のインターフェースを使う考え方で対処するのであろう。

ポイントの最後に出てくる「共通基盤」というのがありますが、この共通基盤はプラットフォームと言われるものです。これもアーキテクチャ同様、わかったようなわからないような言葉ですが、いまは大事な機能だといえます。ただ、範囲が広いので注意する必要があるのですが、ビジネスを行う上でのサービス提供機能といった解釈になろうかと思います。

例えば、SNSサイトやネットショップ、マーケットプレースなどや、アップルストアもそうかもしれないし、各種マッチングサイトもそうです。企業あるいは個人はこうしたプラットフォームを使って様々な外部連携をおこなうことで創発的な価値創造を行うようになってきました。本では、それだけではなく「プラットオームを、単につながりを作り出す存在であることを超えて、資源を機動的に再編集する存在であると認識することができます」と言っている。

このあたりは今ぼくが関与している中小企業間の連携プロセスにも絡んだ話で、大企業との依存関係で生きてきた中小企業は、そうした体質からの脱却を迫られているわけで、そのときプラットフォームを大いに活用して中小企業同士のつながりで新たな商品やサービスを展開していってほしいと思う。
  

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

  

2013年8月27日

つながる経済における実践とは(11)

■ 信頼のプラットフォーム戦略

さてこのシリーズも最後になりました。これまでは、情報のつながりが生み出す創発的価値創造のメカニズムとそれが社会や経営に及ぼす影響などについて議論し、顧客に信じてもらえて、見せてもらえる特権ということにも言及してきました。最後は再びプラットフォームということについて考えていきます。この章のポイントは次のとおりです。

(1) つながりを生かして創発価値を生み出すためにはプラットフォーム構築が重要
(2) プラットフォームの最大の機能は、参加メンバー間で、信頼と協働のインセンティブを形成すること

第2章でもプラットフォームという言葉が出てきましたが、再度この言葉の定義を掲げておきましょう。「多様な主体が恊働する際に、恊働を促進する情報交換の基盤となる道具や仕組み」としています。単なる情報のつながりで見るのではなく、情報を介した人間の恊働だと見ているわけです。

プラットフォームの重要な役割は、コミュニケーションをする上でのインターフェースや、取引をする上でのさまざまなルールを用意することです。これによって、メンバーにプラットフォーム参加のインセンティブや参加して情報を「見せて」も大丈夫だという安心感ができるのです。自由な部分と制約的な部分のバランスをとることが大事になってきます。自由度が高ければ創造的かというとそうではありません。

それでは、どのような情報交換の制約が創発的な価値創造をもたらすかというと、ウイン−ウインの関係、クラブづくり、言葉の共通化、メンバー管理などがあげられます。一方的な受益構造では成り立ちません。全体の利益を適切にメンバーに還元する仕組みが必要になります。メンバーのプラットフォームへの参加は意思をもって参加するという意味で「クラブ」的なものになります。そこには、共通の言葉が必要になってくるわけです。

前回、「全体システムをどのような部分(下位システム)に分けて機能分担させ、下位システムをどのようなインターフェースで連携させて全体機能を発揮させるかという設計思想がアーキテクチャである」という話をしましたが、プラットフォームにも同じような役割が望まれます。

すなわち、大きなシステムを構築する場合には、全体をモジュールに分解して、それぞれのモジュールの役割と、モジュール間の相互作用の方式を決めますが、それと同じ話で、人間の協働の構造を定義して、グループ間のやりとりを定型化するのが本質的に同じであることがわかります。さらに、人間の役割分担構造へも落とし込まれます。

このことは結局、情報システムにも当てはまることで、アーキテクチャ、プラットフォーム、組織(企業内の組織ではなく外と連携されたオープンな組織)、情報システムは同じ概念で構造化されたものだと言えます。言い換えれば、そうしたものを持っていないとこれからのつながる経済、つながる資本主義の世界で生き残ることができないのではないでしょうか。
  

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

  

2013年9月 2日

BPMの動き

本日から日本BPM協会が、一般社団法人になります。名称も日本ビジネスプロセス・マネジメント協会(略称:日本BPM協会)に変わります。何だ変わり映えしないじゃないかと思われるかもしれませんが、BPMという3文字熟語のあいまいさをなくすという意味でもきちんとビジネスプロセス・マネジメントと表現することは意味があると思います。

この一般社団法人化と名称変更はビジネスプロセス・マネジメント(BPM)がだんだん理解されるようになり、注目度も上がってきていうとう背景もあるように感じます。そうしたら、今朝のITmediaの記事に「今こそBPMシステムが求められる理由」という記事が載っていた。SIerである富士通のシニアバイスプレジデントの方がBPMへのIT活用について語っている。

読んでみて、まあ供給側の発言だから多少割り引いて聞いておかなければいけないのだが、導入の機運が高まっているという方向は間違っていないように思います。ただ、若干矛盾した言い回しがあったので指摘しておきたい。大したことではないと思われるかもしれないのだが、実はそこをきちんと整理しておかないと顧客のなぜBPMなのかという問いに対する"ブレ"につながると思う。

どんなことかというと、まずBPMとはという説明で「BPMは、個々のプロセスについて効率化や統廃合といった改善ができる。BPMを実行すれば、作業における人的ミスが低減され、プロセスの迅速化が図れるようになる。」のであり、BPMシステムとは「複数の業務システムを統合・制御・自動化し、BPMの具現化を支援するシステム」のことであると述べている。

ところが、その後で企業のIT活用に対する経営者や情報システム部門の基本的な認識が変化しているとして、「企業におけるIT活用はこれまで業務の効率化が最大の目的だったが、その活用の仕方が大きく変化する中で、経営力やビジネスの競争力を高めていくことに最重点を置く傾向がここにきて強まってきている。」と言っているのだ。

どうでしょうかお気づきになったと思いますが、企業におけるIT活用の目的がこれまでのような業務の効率化ではなくなっているのに、個々のプロセスについて効率化や統廃合といった改善ができ、複数の業務システムを統合・制御・自動化するBPMを導入しようとしています。何か変ですよね。ここはけっこう重要なポイントなのですが。まだまだ普及には道が遠いのだろうか。
  

2013年9月20日

プロセスの分類とアクティビティ定義(1)

何かを分類することに意味があるのは、分類されたクラスターごとに違った理論や方法、解決策といったものが適用される場合である。しかし往々にして分けるだけでそれ以上は知らないとか、分類することが目的化してしまうことがある。4象限の図にきれいにプロットしてうまく分けたでしょうとしたり顔の人がいたりしてだからどうなのよと言いたくなることもある。

さて、プロセスを扱っていると一番問題になるのはアクティビティという箱の中身をどんなものにするのかというのがある。ちょっと前に紹介した「BPMN メソッド &スタイル」という本のプロセスの定義が「プロセス・インスタンスの初期状態からいくつか定義済終了状態に至るまでのアクティビティの実行順序」ということであり、ぼくも前から言っているように、始点と終点とその中間のアクティビティから成っているわけだから、同じことである。

ところが、このアクティビティとはいったい何なのかについて明解に定義し、論理モデルが提示されていたのを見たことがない。さきほどの本でも「対象とする事、ものの名詞+動詞」というように形式的には提示されていますが、動詞といってもいっぱいあるし、動詞ならなんでもいいのかという問題がある。たとえば、「処理する」とか「生産する」も動詞だし、「書く」とか「持つ」だって動詞である。

だから、ぼくはそういった抽象的なものではなく「単位意思決定=(原則一つのデータ確定・判断)であると規定したわけです。ですから、少なくとも先ほどの動詞のようなものは除かれるのである。ところが、プロセスは何でも意思決定プロセスなのかという問題にぶちあたる。そこで、プロセスの性格で分類してみることにする。

例えば、生産ラインで製品を作る場合、これも明らかにプロセスですが、意思決定の連鎖でしょうか。こういうものは、予め段取りや機器の稼働順序とか組み立て順序などは決められていて、それに従ってプロセスは動いていきます。いちいち意思決定をするのではなく、決められたことを忠実に実行するわけです。ですから、意思決定系のプロセスに対して、作業系のプロセスと呼ぶことにします。

つまり、インスタンスごとに状況に応じて意思決定をして進めるプロセスとやるべきことが決まっていて、毎度同じように進めるプロセスの2種類があるということになります。ですから、作業系のプロセスのアクティビティは具体的な形で設定されたタスクとアクションがあるわけです。それに対しして、意思決定系では、メタモデルを設定しておきたくなるのです。つまり、プロセスではどういう項目の構成にすべきか、何を意思決定していくのだろうかというフレームワークがあるといいなあと思うのである。

ところで、前にも言ったことがあるのだが、別の分類で「外部(顧客接点)プロセス」と「内部プロセス」があるという指摘をした。顧客起点か内部起点かでプロセスの見方が変わるという話である。なので、できたら両方のプロセスにも適用できるフレームワークを作ろうとしています。(続く)
  

2013年9月24日

プロセスの分類とアクティビティ定義(2)

前回は、意思決定系と作業系のプロセスに分けられるというお話をしました。なぜ分けられるかというと、こうするんだという決め方ではなく、その性格やら、もっている属性が違うから必然的に違うものになるのです。こうしてこそ意味のある分類にもなるわけです。

違いを表わす切り口として、アクティビティ(タスク)の内容があります。この定義によって、違った性格づけがなされます。意思決定系のアクティビティは、データ確定と判断が主なものになります。一方、作業系は作業なのですがその定義は"モノ、コトのカタチを変換すること"と定義することにしています。製品を作るなんてプロセスはイメージつきますよね。コトでも決まりきった手順で自動的に進めるなんてはこれに当てはまります。

こうした定義によっていろいろな違いがもたらされます。一番の違いは「定型性」です。作業系は定型的で、プロセスフローやタスクが決まっていますが、意思決定系は、依頼内容や顧客の類別で対応が変わったりします。すなわち案件ごとに違った判断がされたりするわけです。

またさらに、定型性からもたらされる性格の違いもいくつか生じてきます。いま言った定型性に似ていますが、順序性があります。作業系は順序が大事ですが意思決定系ではそれほど厳密でなくてもよい場合があります。行ったり来たりすることもあります。プロセスの後ろの方から戻ってまた前の判断を変えることもあるわけです。

それを別のいい方だとブレークダウンがあるかどうかになります。ブレークダウンというのは、なにごともなくそのままプロセスが終わる(ハッピーパス)場合はいいのですが、途中で何らかの破綻がおきることです。作業系では、もちろん機械が故障するなんてことがあるのでないとは言いませんが、意思決定系はこのブレークダウンがあることが前提なのです。

ですから、機械化、自動化というのが作業系ではやりやすいのですが、意思決定系では難しいのです。データ確定や判断を機械に任すのはどうかと思いますよね。従って、ITのことでいうと、作業系はIT化というかパッケージ化しやすいといえます。また、その他にも、個人的なのか組織的なのかとか、オペレーション期間が長期なのか短期なのかといった違いもあるように思います。

ただ、今みてきたような差異を考慮しても、どれもどちらか一方だけというのは少ないかもしれません。意思決定系と作業系が入り混じった形で存在するのが現実かもしれません。意思決定系と作業系の関係を整理すると、ハイレベルなプロセスは意思決定系でその下のレベルに落とす時、予めタスクの内容とか順番が決められる場合には、作業系プロセスとして取り扱い、定型化できないものは意思決定系のプロセスとして扱っていく、あるいは、両方を混在させる、または意思決定系としてオペレーションしていくうちに定型化されたら、作業系にするといった対応になるのでしょう。
  

2013年10月 7日

プロセス志向で大事なこと(1)

プロセス志向ということを標榜している。"志向"というのは意識が一定の方向に向くことだから、まずはプロセスを意識しなさいということである。これは企業の業務をシステム化するにはそのほうが良いですよというアピールである。ではそのシステム化というのはIT化のことですかという問いが湧いてくる。

ここのところは、ついシステム化イコールIT化・自動化というふうに短絡することがある。システムというのは、個々の要素が関係しあって、全体として機能している様のことだから、組織で活動している会社はシステム化した方が良いのである。そもそも組織自体もシステムである。ひとりでは限界があるから人が集まり、人が多くなるとある単位で括らないないとバラバラになるので組織化するわけです。

であるから順番があって、まずシステムになっているのかがある。各要素間の関係が切れているとか、連動して動いていないとかいった場合はそこをシステマチックな考え方で人が動くようにするのが先決だ。その次にIT化すべきところにITを入れ、自動化できるところはコンピュータにまかせるというステップになる。これって、当たり前のように思われるかもしれませんが意外にできていないのではないでしょうか。

プロセス志向の一番重要で最初にやるべきことは「プロセスを記述して組織として共有すること」です。ここで気をつけなくてはいけないことは、プロセスを開発するわけではないということです。企業としてビジネス活動をしているならば必ず"プロセス"は持っています。お客さんがあって、そこに商材を提供して対価を受け取ることはどこの会社でもやっているわけです。

その活動がシステム化されているかどうかの問題なのです。ここができていない、あるいはできているのだがうまく動いていないといったときに、自社のプロセスを記述することによってシステム化の程度を知ることが大事だと思うのです。このシステム化のレベルを測るのに適しているのがプロセス志向なのです。ビジネス活動のメインストリームはプロセスによって成り立っているからです。

IT化を始めるのはそこからです。プロセス記述によって、インフォーマルにプロセスが存在していること、効率的でないこと、質が低いこと、責任の所在が不明確であることなどが顕在化してきます。こうした隠れている部分を見える化する、非効率な振る舞いを効率化するといった改善をすることがIT化の役割になります。ものごとがタバコ部屋で進められていればそれを表に出す、連絡がホワイトボードで書いていたのをITを使うとかをするわけです。

もちろん全部が全部プロセス記述でわかるかというとそうではありません。プロセスという捉え方がなじまない領域もあります。例えば、会計処理とかリソース管理なんてはロジックの問題であったり、データ処理方法だったりしますが、コアの部分はプロセスで捉えることが重要です。

ついついダイレクトにIT化をすることを目的化しがちであり、そうしたメソドロジーも多く見られます。それだと、ひょっとしたらやらなくてもいいことまでIT化したり、かえって見える化したつもりがコンピュータに任せたために見えなくなったりとか起こってきます。さて、「プロセスを記述して組織として共有すること」というプロセス志向の一丁目一番地が大変重要なことであることがおわかりいただけたでしょうか。
  

2013年10月15日

プロセス志向で大事なこと(2)

先の記事でプロセス志向の大事なこととして「プロセスを記述して組織として共有すること」と書いた。ついでに、他の大事なことも記しておこうと思う。どうしてもプロセス志向だから「プロセス命!」みたいな見られ方をしてしまいますが、決してそうではなくて、プロセスを先行してあるいはそこを中心にして考えていこうといったものです。

ものごとに対してどういう切り口というか、攻めどころみたいなものが必ずあります。その突破口をプロセスというものを持ってこようよとしたわけです。実は、この時のプロセスというのは狭い意味で言っています。広い意味でのプロセスとは、いくつかの要素が含まれたものをさしています。プロセスフロー、データ、ルール、ロール、パフォーマンス指標といったものから構成されています。そういった要素の中で、プロセス志向のアプローチで先行させるのはプロセスフローであるということです。

ここであえて業務フローと言わずにプロセスフローと言ったのは、一般的に業務フローというと作業フローとかアクションフローという意味合いが強く、それだと細かくなりすぎるきらいがあるのでもうすこし上位レベルのフローという意味でプロセスフローという表現を使っています。タスクではなくアクティビティの連なりということになります。(それでもわかりにくいかもしれませんが)

ですからまず最初にどんな性格のアクティビティをどういう順番で回していくかを決めることになります。どんな性格という場合の具体的な内容は、どんな意思決定をしたか、すなわち各意思決定でどんなデータを確定したか、どんな判断をくだしたか、どんな書類を作成したかになります。

ここで、フロー以外の要素が登場してきます。まずデータですね。各アクティビティで行われたアクションによってデータが生成されます。データから先ではありません。各種の情報を吟味したり、ルールに従ったり、上司や部下など関係する人々とコミュニケーションを図りながら、意思決定に伴ってデータが生成されます。

ここで注意しなくてはいけないのは、データにはイベントデータとリソースデータというのがあって、いま言ったものはイベントデータです。すなわち、受注するとか発注するといった動詞形のものです。一方のリソースデータは、商品、顧客、従業員といった名詞形のデータで、マスタと呼ばれるものでこのデータは一番最初に持っているものです。ビジネスを行うための原動力だから、これがないとビジネスが始められません。

つまり、プロセス先行と言っていますが、マスタデータは前提条件になっているわけです。そして、その他のルールやロール、パフォーマンス指標などがアクティビティの属性値としてあります。みなさんお気づきかもしれませんが、これって、エンティティということになるのではないでしょうか。ですから、ずっと言っている「プロセス要素表」というのは、何のことはないERD(Entity-Relationship Diagram)みたいなものだとも言えます。

ということは案外、見せ方というか表現方法の違いだけなのかもしれません。言い換えれば、ITシステム、なかんずくシステムサイドの人がデータベースを作るためのものがERDで、業務設計をするためのものが「プロセス要素表」ではないかと思っています。ですから、ユーザの人と議論するには理解が早いプロセス中心、プロセス先行アプローチを推奨しているのです。
 

2013年10月24日

プロセスの分類とアクティビティ定義(3)

前回は、意思決定系と作業系の2つのタイプがあるということを示し、そのタイプの違いは、レベルの違いと定型性であることを指摘しました。従って、作業系・定型のものはIT化・自動化しやすいこと、意思決定系・非定型のものは逆に自動化しにくく、人間とITの合わせ技で対応するということになります。分類することの意味はこうして性格の違いによってやることが異なることを意識することなのです。

ところで、こうした分類の前にも性格分けができます。ただ、それよって対処方法が大きく違うのかというとそうではないので取り上げていませんでしたが、参考のために書いておきます。それは、このシリーズの最初のところで少し触れたことですが、「外部プロセス」と「内部プロセス」があるということです。

外部プロセスというのは顧客接点プロセスと言い換えてもいいのですが、顧客からの要求が起点となるプロセスです。一方の内部プロセスというのは、内部すなわちサービス供給側が起点となるプロセスのことです。両プロセスをもう少しサービスという視点で見てみていくと、「サービス供給型」と「サービス受給型」という言い方になります。

お客さんにサービスを提供するプロセスは顧客起点ですよね。サービス受給というと分かりづらいかもしれませんが、代金を回収するなんていうのは、お客さんがサービスとして代金を入金してくれるという解釈になります。その他にも顧客を獲得するためのプロモーションなんてもそうですよね。顧客が自ら商品をさがしてきてという場合ももちろんありますが、潜在的な顧客をどうやって獲得するのかは供給サイドからの要求になります。

それで先述したように、だからどう違うのかですが、プロセスのレベルとか構造とかには多分違いは見つかりにくいと思います。なぜなら、最近どこでも言われるように顧客の視点でとか、お客様の立場にたってとか言われますが、その時単に立場として目をそこにもっていくだけではなく、サービスという概念を持ち込んでしまえば同じことだからです。

じゃあ、そのサービスって何よとなるが、サービス学会というのがあってそこでの定義が、「提供者と顧客との相互のインターラクションによる価値創造」なのだが、またこれもよくわからないので、もう少し噛み砕いて言い方をすると「提供者が、受給者の望む状態変化を引き起こす行為」ということになる。だから、起点がどこであろうとこの関係性は不変なのである。

プロセスの分類の話をして、分類したけど結局同じじゃんという結論で混乱させたかもしれませんが、言いたいことは、顧客であろうが、商品提供者であろうが"受給者の望む状態変化を引き起こす"ためにどんなことをしたらいいのかということである。これってやはり意思決定系のことにつながってしまいますね。作業系はちょっと違ってきますね。まあ、こんなことでプロセスを考えて見るのも面白いかもしれません。
  

2013年10月27日

情報システムに対する要求の変化

コンピュータを使った情報システムが登場して何十年も経っているが、主に性能アップという面での大きな変化はあったが、ここへ来て大きなパラダイム変化があるように思う。どっぷり浸かっているとわからないが、あと何年かして振り返ったとき、そういえばあの時の変革はすごかったなあと思うのではないでしょうか。その変革とは次の3つだと思うのである。

① 持つことから借りることへ
② 統合することからつなげることへ
③ 作ることから使うことへ

最初の「持つことから借りることへ」はご承知のようにクラウドの登場でまさに所有しないことが注目されています。サーバーのようなインフラから業務アプリまで必要な時に必要なだけ借りることができるようになりました。従来のように投資という固定費的な考えから変動費的な捉え方ができるようになりました。クラウドは大きなインパクトがありました。

2番目の「統合することからつなげることへ」は、典型例が初期には大型汎用機で何もかもやってしまう発想やERPのような統合データベースを目指したものまで基本的には統合化が主でした。ところが、統合化はそれ故のデメリットも内包していました。改修を繰り返していくと保守性が著しく落ちるとか、トラブル時の影響力が大きいとか、得手不得手のものまで混交しているといった問題も顕在化してきました。

もちろんそうした集中システムを分散しようという動きもあったのですが、結局インターフェースの整備に多大なコストがかることでできなかったのです。しかしながら、SOAという考え方やインターフェースの標準化やWebの登場などでシステム間の連携が取りやすくなりました。ソフトウエアやパッケージはある領域に特化してそこで強みを発揮するものが多く現れてきていますから、要は"いいとこどり"をしたいといった希望が叶えられるようになったのです。適切な組み合わせによりより質の高いそして柔軟な情報システムが構築できるようなったのです。

最後の「作ることから使うことへ」というのはあまり意識していないと思いますが、実は大事なことであると考えているのと、これからそうしていかないといけないという願望も含めて言っています。これまでの情報システムはオペレーションから発想されたものだったでしょうか。どういうものを作るかで精一杯でどう使うかは二の次だったように思う。そこの意識を変えたいのだ。

皆さん、iPodやiPhoneがどうやって開発されたかご存知ですか。ぼくは全く知りませんが、DOAで作ったのか、ウオーターフォールなのかアジャイルを使ったのか、オブジェクト指向なのか、BPMなのか、これはさすがにないか(笑)そんなことどうでもいいでしょ。つまり、作り方なんてどうでもいいのです。

こんなことを言うと、iPodやiPhoneはプロダクトだからシステムとは違うという反論があると思いますがそうでしょうか。業務システムって仕事をする上での道具ですよね。それは、個人生活と会社生活の違いはあるかもしれませんが、同じ道具には変わりありません。iPodやiPhoneはどんな使い方になるのか、使われ方をしてほしいのか、その道具を使った新たな生活スタイルを提案しているわけで、オペレーション発想なのです。

従って、同じように業務システムもオペレーション発想でこんなふうに使おうよとか、仕事のスタイルにあった道具を提供するといった考え方が大事になるように思う。そうすれば、役に立たないでほったらかしにするシステムはなくなると思う。こうした考えでシステムを作ってクラウドに置いておけば、もし使い物にならなかったらすぐに代わりがあるという状態になるはずだと思います。
  

2013年11月11日

プロセスの分類とアクティビティ定義(4)

まだ分類するのかよと言われそうだが、ここで時間というファクターを入れて考えてみましょう。つまり、長期的なプロセスなのか、短期的なプロセスなのかということです。次の4象限の図を見てください。縦軸に定型性、横軸に時間をとってどんな業務プロセスが該当するかをマッピングしてみました。

プロセス4分類.bmp

この中には、個人的なものから全社的なものまで含んでいますので広義の意味のプロセスを取り上げています。異論・反論もあろうかと思いますが、あくまで私論ですのでご容赦を。こうしてみるとIT化は定型的なエリアで進んでいて、非定型のところでは人間依存が大きいように思えます。

上部のエリアは顧客を中心とした外部の要求がトリガーになっていて、それが故に流動的で柔軟な対応が求められます。今日では、ここの対応がビジネスを左右するようになって来ていますのでより戦略的でなければいけません。決められた通りに対処するのではなく、それぞれの顧客要求に的確に応える個別対応が求められるのです。

手順化されていなかったり、初めてのケースなんてことに遭遇するわけですから、どう対処したらよいかを考える時に大事なのは、判断の基準というか"拠り所"(あるいは大げさエビデンスと言ってもいいかもしれません)があることです。それに従えば大筋間違えないというものです。その拠り所というのは、現場の個人が勝手に持っているものではありません。起業したばかりとか未成熟な会社では、そういったケースもあるかと思いますが、優良な会社は経営理念や事業方針、戦略から導かれた拠り所があるはずです。それが、業務ルールであったり、行動基準であったりします。

ディズニーランドとか無印良品のマニュアルが有名ですが、あれはおそらく単なる作業手順ではなく、精神を表現しているのでお客様目線の柔軟な対応できるのではないでしょうか。(最近、無印良品でそうではない対応に遭ったのだが)ですから、これからのITは図の上部のエリアでどんな寄与ができるかが問われています。単に自動化・能率化のためではなく、人間の判断をサポートするという活用方法が大切であると思うのである。
  

2013年11月19日

プロセスの分類とアクティビティ定義(5)

これまで4回にわたって、プロセス分類について書いて来ましたが、ちょっと取りとめがないようにも思えるのでまとめ的なエントリーをしておきます。もういちどそれぞれの言わんとすることを簡潔に言うと、大きくは意思決定系プロセスと作業系プロセスに分かれること、そして、意思決定系は非定型的で作業系は定型的であることを指摘しました。「外部(顧客接点)プロセス」と「内部プロセス」という見方も提示しました。

さらに、時間軸を入れてみて、ワークフローのようなものとかプロジェクトのようなものも含めて見ていきました。その議論の中でそれぞれのプロセスの特徴というか性格についても考えたわけですが、もう少しこの点について補足しておこうと思います。現実的には、分類されたプロセスが単独で存在することはまれで組み合わせになっているケースがほとんだと思います。

基本的には、外部プロセスであれ、内部プロセスであれ、意思決定プロセスと作業プロセスの組み合わせになるでしょう。ですからプロセス全体では、依頼受付、意思決定、作業、報告・登録という構造になります。これは、プロセスフローのアクティビティ構成の基本となります。

こうしたプロセス構造でも意思決定プロセスに重点を置くのか、その反対に作業プロセスに重点を置くかの重心の違いが出てきます。前者では、データ確定や判断などを行うことが中心で、作業はその結果をまとめるとか報告書を作成するといった程度のものが対象となります。よく例に出されてるように見積提示のケースなどは、見積書に記載する商品仕様、納期、価格などを決めることが大事でそれさえ決まれば、作業としてはそれをもとに書類の作成するだけになります。

一方、作業プロセスに重点が置かれたものは、意思決定というのは「段取り」のプロセスになります。作業がスムーズに行くように段取りを決定する事になります。その中でも生産プロセスなどは予め手順が決まっているので段取りも日程とか生産ラインの選択といった短く簡潔なプロセスとなります。その代わり、作業プロセスは、長くなりますが、定型であり自動化されることも多いところです。極端なケースでは、スケジュールされたりして全自動ということもあります。

意思決定プロセス重視は外部(顧客接点)プロセスに、作業プロセス重視は内部プロセスに多くなります。従来からくらべて意思決定プロセスの需要度が増してきているように思います。例えば、製造業の中小企業を考えるとわかると思いますが、従来の下請け的なビジネスであれば、作業プロセス中心に回せますが、自力化を図らなくては生き残れない今日では、自分でお客さんを獲って来なくてはいけないために必然的に外部(顧客接点)プロセス、すなわち意思決定プロセスの重みが増しています。

ですから、このエントリーで言いたかったことは、ビジネス環境や自社の立ち位置をよく認識し、そうした環境や利用シーンに適応したプロセスはどういった性格なのかを見極めることで真に役に立つシステムが構築できるというです。(完)
  

2013年11月27日

行動原則としての業務プロセス

外部環境がどんどん変化しているいまは不確実性の時代とも言われている。こうした時代にあって企業の組織構造も変化している、というか変化しないと生き残れないようになってきている。しかしながら、特にわが国の特に大企業における組織が硬直化してなかなか変わっていっていないと感じている人も多いと思う。

どう変化していかなくてはいけないのかというと、これまでのように上からの指示命令によって決められたように動く中央統制型から、従業員それぞれが自律的に動く分散型組織にすべきだという論がある。確かに、変化対応にはスピードや柔軟性が要求されるので自律分散が有効である。しかしながら、何でもかんでも分散型にすればいいというわけにはいかない。

現場で働く人の自主性に任せるということは下手をすると勝手に動いて組織的な行動を逸脱してしまう危険をはらんでいることに注意しなくてはいけない。下手をするとコンプライアンスにひっかかるようなことも気づかないということも起こる。食材偽装とかJR北海道の問題なんかは意識して分散型組織にしているわけではないと思うが、それでも起こってしまう。

分散型組織をちゃんと機能させるためにはどうしたらよいのでしょうか。統制型だと職務分掌とか業務マニュアルとかで縛るという手もあるが、分散型だとそこのところは緩くなってしまう。大事なのは、組織として守るべき規範を共有することだと思う。きっちりと決められたものではなく思想的なものになるが、ビジョンとかミッション、ロール、ルールといったものを共通的な行動原則として持つことではないでしょうか。それは複雑だと共有できないので必然的に簡潔でシンプルなものになる。

では、そういった規範となるものはどういう形で浸透させることができるのでしょうか。紙に書いて渡してもなかなかうまくいきません。常日頃の業務オペレーションをしている中で自然と認識され実行されるべきだと思う。いくら分散型といってもあくまで組織的行動であるわけで、ただし今までのように指示待ちではなく、各人が自分で考えて動き、それが全体として正しい方向になっていることが大切なのである。

業務オペレーションは業務プロセスを進めることで成り立っているから、その中に行動原則が埋め込まれる仕組みにしておくことが求められているのだ。それぞれのアクションが、ビジョンとかミッション、ロール、ルールに則って行われているのかがわかるようにする。それも勝手に解釈してではなく、他の組織構成員とコミュニケーションを取りながら行う。

ですから、リーダも従来とは変わってくる。昔のように伺い箱に書類をためてハンコウを押すのが仕事ではなくなり、たえず部下たちが自律的に動けるように見守り、自分に意思決定を諮られたら素早く判断できるようにコミュニケーションの場に参加することだと思う。

業務システムも組織論と密接につながっているから、これまでのような中央統制型のシステムで作られてきたが、分散型になってきた今日にそれに対応したようなシステムになっているかははなはだ疑問なのである。つまり、行動原則をもって日常業務を行うためにはプロセスという概念を導入していかないと無理なのである。変化対応力をつけるためには、分散型組織にするべきで、その組織を効果的に機能させるには、プロセス志向で業務システムを構築することが重要なのである。
  

2013年12月24日

業務システム構築のトリガー

いまこのブログでシリーズ記事として「イノベーションを支援するITシステム構築の極意」というのをエントリーしている。題名の通りイノベーションを実行に移すためにはビジネスプロセスを設計・実装して、それをオペレーションしなくてはいけないという思いから書いている。だが、業務システムはそれだけで構築するわけではなく、他の理由からの構築するこのとも多い。むしろイノベーションなんてなかなかないからそれ以外のほうが頻繁に検討される。

イノベーションの場合は、プロダクト主導とビジネスモデル主導があるが、新たにできた商品やビジネスモデルに対してプロセスに落としこんで成果を挙げようとするのは同じであるが、フォーカスするプロセスが違ってくるでしょう。このあたりはシリーズ企画のブログを読んでいただくとして、イノベーション以外の理由を考えてみましょう。

それはイノベーションに対してソリューションという言い方を提起したいと思います。つまり、イノベーションの仮説検証タイプに対して、問題解決タイプということです。イノベーションの場合は、こんな商品、こんなビジネスモデルでやったらどうなのだろうかというアプローチになるのだが、一方で既存の商品やビジネスモデルで何か問題があるとか、どうもうまくいかないとか、見えていないとかいった課題に対して、システム的な対応をしたいというきっかけである。

さらに、その問題解決タイプにも2つあって、目的で分けるのだが、「ボトルネック解消」と「業務可視化」になると考えている。前者のボトルネック解消というのは、ビジネスモデルのどこかがボトルネックになっていて、ビジネスの停滞や効率性の悪化、コストアップ、顧客満足度の低下などを引き起こしていて、それを解消したいという動機である。よくありますよね。典型的なのが人手による作業のため非効率だったのをIT化して処理が速度が速くなったといった例です。

ただ、そういった分かりやすいものもありますが、そこはすでにIT化されている分野でもあり、昨今ではもっと違った領域での問題が顕在化されてきているのではないでしょうか。特に顧客とのインタラクションのところの問題をどう解決するかといったことが重要になっていると思う。という意味で古くて新しいIT化領域だろうと思うのです。

後者の業務可視化では、現場作業的なところというより管理者としてのマネジメントに関わるところになります。これまでのように、部下のビジネス活動の結果を帳票として受け取ってそれにハンコを押すのがマネジメントだと思っているミドルも多かったような気がします。さすがに最近はそういうこともなくなったと思いますが、自分の責任あるビジネス活動の進捗や業務品質などを自分の手のひらに乗せて自分が操るというのが大事なことではないでしょうか。そのためにビジネスプロセスを書いてシステム化することが求められるわけです。

こうした、業務システム構築のトリガーによる分類をしてみると次のようになります。
トリガー分類.bmp
 

2014年1月19日

不確実性への対応

ちょっと前に順序からの解放ということで不確実性の問題に触れた。それに関連してちょっと書いておこうと思います。ものごとには陰陽説ではないが、2つの相反する面を併せ持つものが多い。善悪とか黒白といったどちらか一方ではなく、両方から構成されている。そのバランスが時代とともに、あるいは取り巻く環境によって変化していく。逆に言えば、そういった重心の移動が出来なかったことにより消えていってしまうこともある。

当然、ビジネスの世界でもあてはまるわけで、パラダイム変化なんて言われ方もするように機敏に対応していく必要がある。ビジネスの世界、もう少し狭めてビジネスシステムの世界を眺めてみるとやはり時代とともに変わりつつあるように思う。その変化の一つに確実性の世界から不確実性の世界の比重が大きくなっていることがあげられよう。

従来のビジネスシステムでは確実性の高いものを扱うことが主だったように思います。例えば勘定系のもののように厳密性を追求するし、曖昧さは許されないというものです。こういったシステムでは、因果関係がきちんと構成されていないといけません。全部辻褄が合うように、原因と結果がきちんと見えていることが必要になります。このことは実はコンピュータが得意とするところで、確実性のものはアルゴリズムが出来ていることなのでコンピュータでは扱いやすいのです。

ところが、今日のビジネスでは不確実性の高い事案を扱うことが増えてきました。それはなぜかというと顧客との関係が近くて濃くなったからに他なりません。最近では顧客ならぬ個客というくらい、様々なお客さんの要求に応えようとしています。どのお客さんも同じような要求というわけにはいきませんから、どうしても不確実性の世界に入らざるを得なくなっています。

そうなると、従来のように原因と結果の相関がわかっているならそのロジックを通せばよかったのでしょうが、そうはいかなくなります。TPOでどうなるかわからないからです。ではどうしたらよいのでしょうか。ひとつは、顧客の要望を聞かないようにすることです。つまり、供給側が製品やサービスを押し込むビジネスです。しかしこれはアップルのジョブズのような天才がいればいいがだれでもできるというわけにはいきません。

現実的な方法としては、原因と結果の関係を逆転してみたらいかがでしょうか。そうです、ベイズ決定理論のようなアプローチです。そもそも最初のところが不確実なのだから、そこをいくら固めようとしても無理があるわけで、であればそこはあいまいでもいいという前提をおいてしまうことです。つまり、ある事象の結果を絶えずフィードバックして入り口に戻してあげるということです。

この考え方はケースマネジメントにも近い考え方ですが、そのとき大事なことは原因から結果に至る過程がちゃんと把握されていることです。それができていないと、意味づけされてない結果を戻したところで役に立たないからです。もうおわかりだと思いますが、プロセスをきちんと作ってそれをオペレーションすることで初めて不確実性にも対応したシステムになるということです。
  

2014年1月31日

システム開発方法論と健康法

全く関係ないことを2つ並べてどうしようとするのだろうと訝しく思うかもしれないが、今から強引に結びつけてしまおうと思う。このブログでも糖質制限だとか腰痛解消法だとかといった健康法について書いたことがあるが、近頃は健康法のブームという様相を呈している、テレビをつければそんな番組ばかりだし、本屋に行くと極論本を含めてたくさんの健康に関する本が並んでいる。

どれも同じようなことを言っているのかと思いきや、全く反対のこと言っている場合もある。肉を食った方がいいと言っている一方で肉の油はだめだと様々である。往々にして前提があって、年寄りならとか、運動不足の人ならといった条件がある場合が多い。ならば、もう少し整理して言ってくれよと文句も言いたくなるが、センセーショナルな物言いのほうがインパクトがあるからそんな前提ははしょられることとなる。

ぼくが今取り組んでいる腰痛対策にしても、絶対に叩いたり、揉んだり、強く伸ばしたりしてはだめだというだが、他の人はストレッチを薦めてくる。まあ、自分の身体に効くやつをやればいいのだが、そこまで行き着くのが大変なのである。その他にも、糖質は制限したほうがいいというもあるし、制限しないほうがいというのもある。こうなると、信仰みたいなもので信じるものは救われるとなってしまう。そういえば十字式健康普及会にも行ったなあ。

こうしたことは、システム開発の場でも似たようなことがある。つまり、開発のやり方とかアプローチの仕方の領域ではああじゃないこうじゃないという議論が続けられている。やれ、オブジェクト指向がいいとか、ウォーターフォールじゃだめだからアジャイルでいくべきだとか、データよりプロセスだとか喧しい。

健康法にしてもシステム開発にしても、目的とか問題の所在は自明なのだが、その対処法に異なった方法があるということなのである。How toに思いのたけをぶつけてくる。要するに、腰痛だとか、メタボだとか、生活習慣病だとかの解消という目的があって、具合の悪い箇所が腰だとか、血圧だとかわかっていて、それは誰しも否定できない。そこまでは同じでも治し方が様々なのである。

システムだと、業務の見える化だとか、プロセス改革、老朽化更新といったように目的が設定され、問題箇所として、営業プロセスだとかサプライチェーン、レガシーシステムといったようなアプローチは同じなのだが、それをどうやって実現するのかという手段の話となると百花繚乱状態である。こんな時は標準化だとか共通化といった声が上がるのだがうまくいったためしはない。結果が出れば手段は何であるかは問われないからである。

健康法だって、結局痛みが取れればいいし、痩せればいいのだからその人に合ったやり方を見つけて、とりあえず信じて実行するしかない。でもこれだと身も蓋のない話になってしまいそうなので、もう少し体系的で論理的なものを考えてみる。先ほど言った目的と問題の所在は共通だということで、そのあたりのレベルではきちんと定義しておくことが必須である。

ところが案外、このあたりの問題の掴み方、課題の設定が間違っている場合もあるので気をつけなくてはいけない。そのためには、すぐに低いレベルの詳細に行かないことが大事である。つまり、木をみて森をみない愚をおかさない俯瞰力を磨いておくことなのだろう。健康法にしても、どうしても対症療法になるのだが、もっと体質改善的な対応というハイレベル視点も持ったほうがよいと思うのである。
  

2014年2月13日

日本の産業の生きる道(2)

次の「日本企業はピザ型グローバリゼーションで食っていく」というのはどうでしょうか。ピザというメタファは空洞化をイメージさせるドーナッツに対比させて言っている。つまり、海外移転が進行して国内が空洞化してしまうことに対して、あくまで中心部すなわち国内は空洞化させないことが重要であると言っている。ピザ職人がピザを作るとき厚い小さな生地から遠心力を利用してピザを大きくしていくが、真ん中部分の生地の厚さは薄くなり、周辺は大きくなるが真ん中はいつまでもなくならないでいるのである。そして最後には真ん中にトッピングして完成する。

要するに企業内で国際分業をするということにつながる話で、生産工程を細分化してどこの工程を国内に残し、どこの工程を海外のどこの国で立地するのかを志向するということになる。その時のポイントを3つ上げている。
(1) 海外需要を獲得できる製品の国際競争力
(2) 仕事の国内還流の仕組みづくり
(3) ピザのトッピングになり得る国内ベースの準備

こうした検討に対して前提を考えたほうがいいような気がする。どういうことかというと海外展開の目的のことである。何のためにグルーバル化するのかである。それによってピザの作り方やトッピングの施し方も変わってくるように思うからである。簡単に言うと、供給サイド側の要請なのかそれとも需要サイドとしての要請なのかである。安い製造コストを求めてなのか、新たな需要先としての海外なのかで対応も違ってくるように思う。

近頃は、昔のように安価な労働コストの調達先として見ていたのが、当然途上国の労働コストは経済が良くなればどんどん上昇して行くわけだから、徐々にその優位性が失われることになる。それ故、今では多くのケースは新規需要先としての海外マーケットという位置づけになってきているのではないでしょうか。そうなると、製造工程を海外というだけの工程分割ではなくなり、さまざまなパターンがあるように思う。需要先となれば販売拠点をどうするのかといったことの重要性が増すし、むしろ商品の認知の問題でピザの美味しさとかトッピングの良さなんていう前にそういうピザ屋があることを知ってもらうのが先決になる。

となると、商品の性格にも左右されるので一概にこういう分業ですよとは言い切れないだろう。ピザ型ネットワーク分業システムが機能するためには「仕事の国内還流のマネジメント」と「ピザを拡大・代謝させる原動力としてのイノベーション」を留意する必要があると説いている。しかし、確かに分からないでもないのだが、そんな簡単にイノベーションを起こせるわけでもないし、むしろ新興国市場がかつての日本の市場と同じようなものができてくる過程であれば、何もイノベーションではなく国内向けの商品をベースにいかに現地仕様にカスタマイズするといったやり方のほうがいいように思うのである。
  

2014年2月 9日

Jリーグの経営

昨日放送されたテレビ東京の「FOOT✕BRAIN」はおもしろかった。テーマが「横浜F・マリノス社長登場!ゴーンも認めたチーム改革術」である。ゲストとして嘉悦朗社長が出演していた。マリノスは昨シーズン惜しいところでリーグ優勝は逃したが、天皇杯では見事に広島を下して優勝した。これまでそこそこの成績は残してはいたが、最近メキメキと強くなった。その秘訣を探ろうというものである。

嘉悦社長は日産自動車でカルロス・ゴーンの懐刀と言われた逸材で2010年からマリノスの社長を務めている。就任時のマリノスはどん底と言われるくらい成績も悪く、しかも経営的にも収益が悪化していた。それを日産自動車のゴーン改革と同じように日産流のやり方で改革を実施して、成績も収益も改善させたのだ。その手法がおもしろいというか、参考になるので書いておく。

まず方針として、経営とチーム強化のバランスで、収益が悪化したから強化費を削るという単純な方向ではなく、むしろ強化費は削らないで強くすること、そして集客力のアップでお金を得ようとしたのだ。そこでクロスファンクションチームの結成とマーケティングの概念の導入なんですね。さすがビジネスマンですよね。

そのマーケティングでは「パーチェス・ファネル」という考え方を採用した。認知→理解→好意→購入意向→購入→再(リピート)という流れである。これって、ビジネモデルのチャネルというブロックの認知→評価→購入→提供→アフターサービスというのと同じようなことですね。

これを、マリノスに適用したわけである。どうなるかというと、マリノスという名はよく知っているが、どんなクラブかの理解で弱いとスタジアムに来てくれない。なのでよく知ってもらって、好きになってもらい、チケットを買おうかという気にさせ、実際にスタジアムに足を運んでもらう。そしてスタジアムの雰囲気がいいのでまた来ようとなる。このプロセスが大事なのである。ビジネスの要諦ですよね。

こうした流れを維持するためにやった施策の主なものが、「ホームタウン活動」で、地元の港北区にフォーカスしたのだ。ぼくもかつて港北区に住んでいたことがあるが、ここは比較的若い夫婦が多いのでそこにいる子どもたちをターゲットにしてマリノスを売り込んでいる。10年、20年先を観ているのがすごい。

次の「プロモーションで」は、ポイントがコラボレーションで地元の異業種である横浜ベイスターズとか八景島シーパラダイス、ズーラシア或いは劇団四季などと相互協力をしている。3つ目は「ホスピタリティ」でスタジアムをディズニーランドにするというコンセプトでディズニーにも研修に行ったりする。これらを聞いていると一般的な企業の経営改革と一緒だなあと思う。非常に参考になったのである。
  

2014年2月21日

日本の産業の生きる道(3)

3つ目の提言が「日本は複雑性産業で食っていく」です。前回「ピザ型グローバリゼーション」という行き方を議論しましたが、そのピザのトッピングになり得るには次の4つの条件を満たす産業分野だという。
(1) 日本全体の産業蓄積、技術蓄積を活かせる
(2) 日本の組織の得意技に合っている
(3) 電力生産性が高い
(4) ピザ型ネットワーク分業の原点になり得る

そして、この4つの条件が示唆する産業分野のキーワードが「複雑性」だという。製品の機能としてもまた生産工程としても複雑性が高い産業という意味で、多くの人がかなり込み入った仕事をそれぞれにきちんとこなさないと最後はうまくいかない、という意味での複雑性だそうだ。こうした産業の例として、ハイブリッド車の開発・生産の自動車産業、宅配サービスといったものである。さらにイノベーションという意味で東レのヒートテックをあげている。

確かに、複雑性というのは日本のお家芸でもある。ただ、これまででも複雑性を売りにしていた面もあったはずで、そのことで最初は日本の競争優位をもたらしたがイノベーションのジレンマということもあり、韓国や中国。台湾の追い上げられて、今や家電では抜かれてしまったのではないか。ここでは「複雑性」が足を引っ張ったこともあったように思う。複雑な機能を追い求めすぎて、単純な機能で十分な新興国への市場に入れないのだ。

前にも言ったことがあるが、東芝のDVDレコーダーのリモコンを見てびっくりした。まず2つついて来る。全機能がついているものと、簡易リモコンの2つである。何ということだ。いまだに簡易リモコンだけで用が足りて、全機能付きのはホコリがかぶっている。ことほどさようで、テレビにしてもその他の家電やいろいろなものがみな高機能と称しているが、不要な機能が満載なのである。だから、きっと作るのも複雑であるにちがいない。「複雑性」は必ずしもビジネス的には成功していないのだ。複雑だから故に電力生産性も低いし、人手も食うから高コストになる。

ただ、新興国が徐々にキャッチアップしていく中で今より複雑性を要求することはあるかもしれない。しかし、それでも複雑性に持ち込むのはどうかと思う。あくまでシンプルにいくのだがどうしても個別要件に対応せざるを得ない時には複雑性は排除しないという態度が必要なのではないだろうか。そして、複雑になったものを標準化とか共通化してシンプル化に誘導していく方向なのだろう。

複雑性産業を推奨すると、国が言っている例えば経済産業省が発表した産業構造ビジョンにある環境、エネルギー、医療・福祉といった特定産業分野とか、また産業競争力会議で言うところの、健康、エネルギー、インフラ、農林水産業いった重点4分野とはだいぶ違う。ただ複雑性ではないと言ったのだから、国のいうような産業がいいのかというとこれまた違うような気がする。国の言っている分野はどうしても内向きだし、グロバールに戦っていくにはもうちょっと違った産業構造を考えていかないといけないのだが、それが複雑性産業化というとちょっと待ったとなるのである。
  


2014年2月28日

日本の産業の生きる道(4)

次の提言は「日本企業はインフラで食っていく」です。インフラというのは広く使われる場合もあるが、ここでは社会インフラという定義にした方がいいだろう。つまり公共的な社会基盤の施設やシステムと言う意味である。例として、電力供給システム、鉄道網や道路網、上下水道などの水関連システム、情報通信の社会基盤などがそうである。

近頃元気のよい企業に日立とか東芝があるが、彼らはこの社会インフラで業績を上げている。海外にも進出している。日本の社会インフラは海外に行ったとき感じたことや、いろいろな情報からもおそらく世界一だと思う。そのインフラを作り上げたわけだから、日本の産業の生きる道としてはかなり有効なものだと思う。しかも、この産業は関連する産業が多くあることから裾野が広いことも魅力である。

本にも書いてあるのだが、「インフラ産業の日本」といったときに2つの意味があることが気づく。社会インフラを海外展開して売っていくという行き方と、もう一つの側面は日本の産業集積全体を海外の国々の産業活動のために使える基盤として機能させるというものである。この考え方は非常にいいと思う。例えば、海外の企業のために製品開発や試作のプロセスを日本で持つとか、彼らの製品開発や試作に必要な機器・部材を日本が提供するといった形態である。マザー工場的な発想ですよね。

とりわけ、電力インフラ、鉄道、水関連インフラの3分野が強いと言われている。原子力発電所はどうなんか分からないが火力発電所でも日本の技術は優れている。それも単に発電所を作ることだけにとどまらずにそれを運転し運用管理する技術がすばらしいと思う。停電率の低さからわかると思うが、日本人の責任感やきめ細かさはたいしたものである。ぼくは昔プラントの運転のスーパーバイザーだったことがあるが、海外でオペレーションを教えこむのは日本にいる時と比べると大変だった。

つまり、ハードだけではなくソフトも含めたシステムとしての価値をもっと訴求したほうがいい。そこを高いレベルに持って行って維持するには多くの経験とノウハウの蓄積が不可欠であるから、新興国はそう簡単にキャッチアップ出来ないからチャンスなのである。ただし、いくら世界一だと言っても高機能だけど高価なものは望まれていないわけでそこの折り合いをつけられるかがある。

発展途上では、最先端の機能なんかいらないわけだから、いかにシンプルなものに落とし込めるかになる。さらに、モジュール化とかパッケージ化がやりやすいレベルだからそれを推し進めることが肝要なのではないでしょうか。ということで社会インフラで食っていくというのは賢明な選択であると思うのである。
  

2014年3月13日

日本の産業の生きる道(5)

前回は、インフラ産業で食っていくというお話をしました。この考え方は有効だという評価もしました。さてその次が「日本企業は中国とともに食っていく」です。こうした論点の設定は産業構造を決めるポイントは何かという論考にあります。2つのポイントがあって、ひとつは地政学的な面であり、もうひとつは産業全体の科学的基礎として、多くの産業を成立させる共通の基礎科学分野はなにかという問題である。

前者は、世界の中の日本経済という視点から見た時、日本に密接な関係のある国や地域が数多くある中で、その「重心」というべき中心的な存在はどこかである。そこを考えた時、中国が浮かび上がってくるのだという。これまでの中心的存在はアメリカであったことは異存ないと思う。データ的に圧倒的な貿易量からも裏付けられている。しかし、21世紀に入り、その地位はおそらく中国が占めるであろう。

今々は反日感情の高まりで上手くいっていないように見えるかもしれないが、経済的には確実に関係が深くなっている。2008年には日本からの輸出先としてアメリアを抜いている。米中大逆転が起きているのだ。貿易額だけではなく、例えば日系現地法人の従業員数にしてもこの10年間で66万人から160万人へと大幅に増え中国が1位となっているのだ。日本にとって最大の生産基地でもあり市場となったのである。ぼくは、38年前に中国にプラント運転指導という立場で行ったのだが、そのときはもちろんまだ文化大革命の最後の年であり、産業なんてなかった時代だから、その時のことを思うと隔世の感がするし、ほんと驚くべき変化である。

このように経済的には切っても切れない関係いなっているにもかかわらず国民感情的には中国では反日であり、日本人の対中国イメージの悪化というねじれが起きている。このことは一朝一夕には修正できないというか、未来永劫できないのかもしれない。38年間の経験でも一方的に日本側から援助するという関係でありながら、彼らには助けてもらっているという感情よりそれが当たり前、あるいはお前らがいなくても自分たちだけでできるのだとう態度がありありだった。ただそれはそれとして、仲良く出来ないことではないように思う。ある程度割り切った合理的な対応ができればいいのだ。

複雑性産業とかインフラ産業といった提案をしているが、その時には市場という側面もあると同時に国際分業という観点がどうしても必要になるがその時のパートナーとして大きな意味のある国である。しかし、一方でリスクは忘れてはいけない。最近でもバブルが弾ける懸念が憂慮されている。おそらく、経済成長も限界に来るし、どこかでバブルがはじけるのは避けられないと思う。その時、どこまでダメージをうけ、そういう過程で再生できるのかが気になるところである。

従って、伊丹先生も言っているように、中国一辺倒ではなくASEANなどとも連携したバランスのある対応が必要になる。つまり、発展していく東アジアは中国だけで形成されているわけでもない。ASEANもまた今後の成長が期待されるのだから、このASEANとこれまでのようにバランスをとりながら、しかし中国との国際分業の深化を図る。その深化の具体的ありようが良くも悪くも21世紀の最初の四半世紀の日本の産業構造を決めていくのだろう。
  


2014年3月11日

サイボウズが東京駅にいた

先日東京駅で驚いてしまった「kintone」という文字が飛び込んできたからである。写真(1).jpg
けっこうインパクトがある写真とキャッチーな言葉である。まずは「突破する情シスへ。」ときた。企業の情報システム部門を叱咤激励しているようだ。ぼくは以前大手化学会社の情報システム部門にいたのでずしっと来るのだが、いまこそ存在感を見せつける時がきたように思う。ではいったい何を突破するのだろうか。ぼくには旧弊を打破せよと言っているように聞こえる。目の前にある課題ということではなく、情シス部門にいる人々の心の内にある壁を突破せよということである。人々の内面にある壁というのはシステム部門は金ばかり食ってビジネスに貢献できていないという批判に対して逃げていることだ。写真(2).jpg

次が「感動される情シスへ。」である。内なる壁を突破してユーザーである事業部門や管理部門と一体になってビジネスの役に立つシステムが出来れば、よくやってくれたと感動されるだろう。これまでは、叱られこそするがほとんど褒められたことがないのではないだろうか。システムは安定して動くのはあたり前で止まったりしようものなら罵声を浴びせれていた。だから、余計なことはせずに運用に逃げ込んでじっとしていた。そこの意識を変える必要がある。そのためには、守りではなく攻めのシステム化に積極的に参加することである。それには、ビジネスの前線である顧客接点のシステム化に関わることだ。実はそこの領域はリスクをある程度許容できるからチャレンジすべきだと思う。 写真(3).jpg

3番目が「リードする情シスへ。」となる。従来のディフェンシブな姿勢を突破してオフェンシブな情シスへと変貌すると、ビジネスの成功をもたらし、感動され、感謝されるようになるわけで、要求を待ってから動くのではなくむしろ情シス部門からどんどん提案を出しながらひっぱっていく役割も期待されるだろう。今日のビジネスはITなくしては成立しないと言っても過言ではない。そして、技術的な進歩は凄まじく次から次へと新しいデバイス、ソフトウエア、ツールなどが生み出されている。ITはイノベーションを起こすための支援という側面と、すばらしいITが武器となって新規ビジネスを生み出すという面もあるから、ITを駆使したビジネス創出やイノベーションを提案できる情シスはビジネスをリードする存在に成り得るのである。

まだ、この看板が残っているかどうかわからないが、この呼びかけに感じる情シス人が多く生まれることを期待したい。そして、情シス部門の攻めるためのツールとして「kintone」は適している。安価であり導入しやすいこともあるが、IT部門とビジネス部門の両者が会話するのには格好のツールである。なぜなら「kintone」を介在させて同じ言葉で話せると思うからである。 
 


2014年3月30日

日本の産業の生きる道(6)

最後が、「日本企業は化学で食っていく」です。前回、論点の設定において地政学的な面でのポイントとして「重心」というべき中心的な存在が中国にあるという話をしました。今回は、産業全体の科学的基礎として、多くの産業を成立させる共通の基礎科学分野は何かという問題である。すべて産業は技術の優位性で成り立っているわけで、その背後で支えるのが科学である。

その科学の中で重心的地位を占めるものは何か。1970年代から90年代にかけて日本の産業発展を支えた産業科学の重が物理学とくにエレクトロニクスに関わる物理学であったことはみなさん認めるところでしょう。ぼくはちょうど就職したころからだからその伸長ぶりを身をもって知っているのでよく分かる。それもその産業に留まらず、他の産業にでもさまざまな形でエレクトロニクス化現象が起きた。

ところが21世紀に入ると日本の地位の低下が始まり、2011年にはエレクトロニクス産業の総崩れという象徴的な事件が起きる。東アジア企業の大躍進により、日本企業は蹴落とされてしまったのである。それに対して、入れ替わるように存在感を増してきた産業が化学ある。こうした現象が起きるには理由がある。それは、物理と化学の本質的な違いがあるからだという。

物理は基本原理を理解すれば、あとは論理で解決できることが多い。学習のスピードが早い。従って、原理を実行する装置を買えば事業を行える。ということは、新興国が急速にキャッチアップできることを意味しているのだ。それに対して化学は単一の原理を学習すればあとは論理で解決できるという世界ではない。化学は化けるのだから、反応条件をちょっと変えただけ全く違ったものができたりするわけである。

これは、多くの経験やノウハウの蓄積が大事でそれには時間がかかるのである。ぼくは化学産業のまっ只中にいたので実感するのだが、部品表があってそれを組み立てれば製品ができるのとは反対で、レシピがあってその通りにやってもいつも同じものができない料理みたいなもので、ちょっとした温度加減とか調味料の入れ方などが製品のできを左右したりする。難しいのだ。

これだと、新興国はなかなかキャッチアップできない。ただ、化学でもコモディティとファインケミカルとかスペシャリティケミカルといったものとでは違う。コモディティではほぼコストの勝負になるから規模の経済学や立地に左右されるから日本では縮小していくと思われる。最近のニュースでも水島地区のエチレンセンターの2基のうち、旭化成の方を止めて、三菱化学の方に集約するという。

化学産業にあって元気なのが繊維系の会社である。東レ、クラレ、帝人、旭化成などで特殊な用途の化学素材をどんどん生み出している。東レの炭素繊維、ユニクロと組んだ発熱素材とかクラレのポバールとか世界での大きなシェアーを持つものが数多くある。繊維産業というのはご承知の通り日米繊維交渉などでグローバル化の洗礼をいち早く受けた産業で、そうした厳しい環境を克服してきたので強固な体質なのだ。そういった面でもこれから期待できるのである。

ただ、エレクトロニクス産業も消えたわけではなく、化学とともに日本の産業を牽引していくと思うが、化学への重心シフトは止まらないのではないでしょうか。このことの象徴的なものとして歴代の経団連の会長をみていくとよくわかると思う。今井敬(新日本製鐵)、奥田碩(トヨタ自動車)、御手洗冨士夫(キャノン)ときて、現在は米倉弘昌(住友化学)で次期会長が榊原定柾(東レ)である。ものの見事に日本の産業の盛衰をみることができますね。

以上、日本の産業の生きる道は終わりますが、アベノミクスの第三の矢の成長戦略がなかなか見えてこないのだが、政府はもう少し高い位置から鳥瞰して産業構造を見て、歴史的な視点や本質的な分析により有効なものを考えてもらいたいものだ。しかし今のような状態だと、残念ながら民間がどんどん自分の意思でやっていける環境を整えてくれるだけの方がまだましだということになりかねないだろう。
  

続きを読む "日本の産業の生きる道(6)" »

2014年3月29日

デジタルにアナログというアナクロ

イノベーションはまったく新しいものが起こすことは少なく、既存のものを組み合わせたものが多いという話がある。iPodやiPadなどのアップル製品もそんな文脈で語られる。現実的には、ブレークスルーする技術なんてざらにあるものではなくごくまれにしか生まれないと思う。シュンペーターだってイノベーションを技術革新だなんて言っているわけではなく、断トツに市場を専有したらそれがイノベーションだと言っている。

しかしながら、なんでもいいから組み合せればいいのかというとそれはまた違う話であって、商品としての新奇性はもちろんのこと多くの消費者が使ってみたいと思わせる魅力がなければいけない。組み合わせについては、ベースとなる技術やデバイスがあってそこに別の角度から機能を付加するというのが一般的である。

となると今のトレンドは、ベースデバイスはタブレットやスマホということになろう。これに絡む新製品が数多く出ているが、一つの傾向として、タブレットやスマホが登場する前の製品の機能との組み合わせを思いつくというものです。その典型的なものがアナログのもつ機能とか感覚を持ち込んでくることです。デジタルのなかにアナログの良さを加味するという発想なのだがちょっと待ったと言いたくなる。

先日、テレ東のワールドビジネスサテライトのトレたまで登場した2つの製品を見て感じたのである。そこで紹介されたものは、携帯電話用の電話ボックスとタブレットで使う触感タッチパネルである。前者は、周囲の雑音を遮断して通話がしやすいようにした可搬式の電話ボックスで、後者はタブレット上で金庫のダイヤルを回すと、本物の金庫のダイヤルを回したと同じような感覚が得られるというものである。

なんかいいアイデアのように思えますよね。要するにアナログ時代の公衆電話ボックスと物理的な金庫を現代のデジタルデバイスに持ち込んだというわけである。しかし、携帯電話というのはどんな場所でもどんな時でもすぐにその場で通話できることが価値であるし、物理的な空間から空想空間に移行しているのがデジタルでありタブレットなのである。

つまり、コンセプト上の齟齬が生じるのである。変革という経過を経て出現したのにまた元に戻すようなアナクロ的なことことが受け入れられるのだろうか。いや、木目調のスマホの充電器が売れているではないかという反論がきそうだが、それは機能を戻しているわけではなくてデザインを変えているだけなので意味が違う。

触感タッチパネルは富士通が開発しているのだが、こんな発想でいいのだろうか。いや大企業だからこその発想かもしれない。触感パネルがいいと思ったらもっと違った切り口にすべきだと思う。タブレットというのはどういう使われ方をしているのかをちゃんと観察したらいいと思うのだが、タブレットユーザーはそんなものを要求しているのだろうか。全くタブレットとは関係ないガジェットに組み込むとかゲームで使うとかはあり得ると思う。ドメインを変えるのだ。そんなふうに思うのですがいかがでしょうか。
  

2014年4月 9日

これまでどんな業務アプリを作ってきのだろうか

いつも業務アプリケーションにおいてプロセスという概念が欠如しているという指摘をしてきた。ここのところを具体的にこれまで作られた業務アプリの形態をみていくことで明らかにしてみようと思う。まず、ここで主張しているプロセスの基本構成は、意思決定プロセス、作業プロセス、タスク管理というふうに言っている。つまり、何か依頼がきたらその依頼に応えるためにいくつかの意思決定、すなわちデータを確定するとか判断をするとかを行い、作業が必要なら作業を行い、依頼に対する回答を作成し、報告・登録するというものである。

そして、業務の性格によってそれぞれの重さが変わってきます。意思決定プロセスが主要なものもあるし、決まりきった手順で行えばいい業務だったら作業プロセスが中心になる。個人的なアクションだったらタスク管理になる。そこでこれまでのシステム化の対象となっているのは主として作業プロセスとタスク管理、さらにもうひとつは「リソース管理」を加えたものでした。生産・製作システムとかグループウエア、設備管理、人材管理などの仕組みが多かったわけです。

つまり、フローとストックという意味で言うとストック中心のシステムづくりだったことになる。言い換えれば、データベースを作るシステムなのである。作業プロセスはフローですが、手順が固定化されているのでストックに近いフローになる。管理すべきデータを設定して、それを生成・管理するためのシステムである。作業プロセスはこの生成過程でフロー要素が多くあるというふうにも捉えることができる。

ものごとというのは字の構成からも、もの=ストックとこと=フローから成り立っている。飛躍するかもしれないが、事業活動でも財務諸表が「貸借対照表」と「損益計算表」が主であるのもこのことを裏付けている。ところが、従来型のシステム開発では、ストック中心で行われてきたように思うのである。従って、これからのシステム作りは、もうすこしフローのところに焦点をあててバランスよくやることが望まれる。

このフローを考えて上で大事なことは、変動的な要素が強いということである。これまた、勘定科目的な見方をすると固定費と変動費みたいなもので、ストックは固定的であり、フローは変動的である。従来型のシステムすなわち作業プロセスも含めてタスク管理とかリソース管理は固定された型があってそこに当てはめることなのだが、フロー型である意思決定プロセスは大きな枠はあるにしても、個々にはかなり流動的に対応していくことになる。

つまり、システムの作り方が根本的に違うのである。そのことをきちんと理解して、業務の性格に相応したアプローチを採用していかなくてはいけない。それはウォーターフォールからアジャイルといったことではなく、構造的な部分も含めて考えなくてはいけない。まだまだ、どんな対象に対してこれまでと同じようなシステム作りのやり方をしているように思うのだが

2014年4月25日

戦略としてのIT

さて、通常のブログエントリーに戻れそうです。まずはIT関係から。ダイヤモンドオンラインの記事の中にITRの内山悟さんの「経営のためのIT」という連載があって、ちょっと古くなるが2月のテーマが「戦略としてのIT」ということであった。この記事がなかなかよくてぼくが普段うまく言えてなかったことを代弁してくれている。さすが内山さんだ。

このテーマで書いた理由について内山さんが言っているのは、一部の経営者は適正なIT投資判断ができないし、IT部門も的確に説明できていないという現状に対して、いまや企業におけるIT投資は多岐に及んでいるので、ITの果たす役割をきちんと分類して、その目的や種類に合わせてIT投資を捉えなくてはいけないということである。つまり、戦略的に考えよということになる。

いまぼくの周りで困っているのが、BPMを経営にどう説明してその効果を理解してもらうのが難しいということである。そのとき、何でもかんでもBPMがいいのだ、IT投資すべきだというのは間違いで、ちゃんと整理して対処しなくてはいけない。そういった課題に対して下図のようなITの役割を目的層別に見る見方を示してくれているのでこれについて考えてみる。

ITの役割.png

最下層が「参戦する資格としてのIT」で、いまやITは不可欠の要素でインフラになってきている。(中小企業はまだまだのところも多いが)これがなければ戦うことさえできないということである。中間層が「戦う武器としてのIT」で経営や事業からの要請に応じて、効率、スピード、品質、精度などの向上や、業務コストの削減に用いられるものである。

この中には攻めと守りの両方の武器がある。守りというのは主にコスト削減で、攻めはモニタリングにためのITと知識共有や計画精度向上のためのものである。ただ、攻めのところでコスト削減に対して売上増につながるITというのがあるように思う。新規顧客獲得とか。新市場での認知度向上という領域である。ビジネスプロセスが威力発揮する場である。

最上層が「戦略としてのIT」になる。ITが経営・事業・業務に改革や変革を促したり、企業に新たな付加価値をもたらすものである。ビジネスモデルの新規構築あるいは変更といったことをITをてこにしてあるいは保有のITリソースを活用して行うという面がある一方で、ITそのものをシーズとして提案価値になる場合もある。いずれにしろITは今日のビジネスにとっては非常に重要な位置をしめているといえよう。

先進的な企業、強い企業は戦う武器としてのITから戦略としてのITへステップアップできたから今の位置を獲得したのではないでしょうか。これは何も大企業に限ったことではなく中堅・中小問わず言えることであって、経営者は積極的に上位層へ引き上げることをしないと生き残れないことを知るべきである。といって笛を吹いても踊らないのが現実でもある。ああ、何とかしたいなあ。
  

2014年6月19日

業務システムの作り方を考える

いまある中小卸売業のビジネスモデルや業務プロセスを検討しているのだが、こうしたビジネスモデルで業務プロセスはこうなるといったように事前に確定できるのかという問題にぶち当たっている。もちろん、ある前提や仮定を置けば設定できないことはないと思う。しかし、そううまくいくのかと思ってしまう。やってみなければわからないという要素も多い。

これは、卸売業という業態とも関係することだが、はっきりとした商材が確定しているわけではなく、状況によって取り扱う商品が変化することがある。商材が変われば顧客も変わる。逆に顧客の要求に対してさまざまな商品を提供しなくてはいけないのだ。ということは、ビジネスモデルも一様ではなくちょっとした違いを変化と捉えると千変万化するといっても過言ではない。

ということは、きっちりとしたビジネスモデルを描いて、商品や市場・顧客を絞り込んでといったアプローチは難しいのではないかということである。だから、大きな方針とある程度の範囲だけを設定しておいて、まずはその中で実際にビジネスを行ってみて、その結果を解析することで自分たちのビジネスモデルを確定していくというアプローチがいいのではなかろうか。

業務システムにしても仕様を確定して、それに従って業務システムを構築するのがよいことなのだろうかと考えてしまう。同じようにある程度ラフに作っておいて、ビジネスモデルの絞り込みに連動しながら追加・修正していくというやり方である。システムは当初人間がカバーしながらオペレーションを行い徐々にIT化できるものはIT化していくという考え方である。

この考え方は、少し前にエントリーした「セオリー通りにはいかない現実にどう対処するのか?」にも書いた態度である。つまり、"適当"に動かしてみて、その結果をフィードバックして修正動作に反映していくのだ。どうもこうしたTry & Improvementの仕組みをうまく作ることが重要ではないかと思うのである。

それをもっと積極的な意味でやってみたらどうだろうか。よくわからないから、確定できないからしかたないので採用したということではなく、そうやれる仕組みそのものが武器になるという考え方である。この辺りは、コンビニのPOSとか宅急便の追跡システムといったものに似ている。

また卸業における需要予測にしたって直接エンドユーザーと接点を持てないから非常に難しい。従って、システムを使って変化を素早く察知して機敏に対処することでいくしかない。ただ、そのためには今以上に川上、川下との連携というより、寄れるかどうかも大きい。つまり、エンドユーザーへの直需・ネット販売、メーカとの協業・ブランド化といった戦略も必要になってくるだろう。
  

2014年8月 2日

ロボットの時代?

この間のテレビ東京の「カンブリア宮殿」は400回スペシャルということで孫正義が出演していた。「日本を爆発させる"大ボラのススメ"」というタイトルで孫さんのこれまでとこれからの大ボラをテーマにしていた。まあ、ボーダーフォンを買収して携帯ビジネスに参入したり、ちょっと前は太陽光発電といっていたし、最近話題なのはロボット事業であろう。

他のものはあまり興味はないのだがやはりロボットが注目だ。来年198,000円で売り出す「pepper」君が発表されたが、これからどうなるか面白そうだ。この事業に200億円投資したといってたから相当に力を入れているのがわかる。これに対抗?するのがgoogleだ。今盛んにベンチャーを買いあさっているのだという。ということはポストスマホはロボットなのだろうか。

「pepper」(googleもそうかもしれないが)のおもしろいのは、ロボット用のOSがあり、それを開放して世界中の開発者がそれを使ってロボット用のアプリを開発するという考え方である。スマホと同じようなやり方ですね。だから、何とpepper君の開発をよしもとと組んでやっているのだ。びっくりしたのは、よしもとのお笑い作家が、一生懸命pepper君のおもしろい動作を考えてそれをインプリメントしているのだ。

しかもそれを専門のIT技術者ではない彼らが自らPCを使ってやっているのである。画面上のアイコンをドラッグアンドドロップでつなぎ合わせるイメージ作り上げている。ホームページを作るより簡単だという。ちょっと話はそれるが、業務システムもこんなふうに作れればいいなあと思う。業務システムも見方を変えれば、ロボットのやっていることを作り上げているとも言えるからである。だって、例えばヘルプデスクシステムみたいなことって人間がいちいち対応するのではなくていくつものエージェントが命令さえすれば代わりにやってくれる仕組みでもある。

孫さんが、PCはあくまで人間が使う道具だったが、ロボットは意思をもつようになったと言っていた。例えば、自分が病気でできなくてもロボットに教えこんでおけば、そんな状況をみて同じように動いてくれるのだ。ただ、ぼくはロボットが意思を持つというのには異議がある。だって所詮コンピュータの塊でしかないわけで、限界があると思っている。ところが、驚いたのは孫さんと一緒に出演した大阪大学の石黒浩教授のジェミノイドである。

石黒教授はその筋では非常に有名な人で、ジェミノイドというかアンドロイド(分身ロボット)を作っている人で、もうホントびっくりします。全く人間と同じようなロボットなのです。外形はもちろん髪の毛もありますし、体も人間と同じような皮膚、筋肉で、まばたきもしますし口も動かします。ただ、これだけだと動く高級蝋人形になってしまいますが、実はびっくりすることができるのです。

このロボットを見ながらあるヘッドギアをつけると自分がロボットになったように感じることができるというものです。鼻をつままれると痛いと思うとロボットが痛いと声を発するのである。気持ち悪くなるくらい不思議だ。ロボットが意思を持っている感覚になる。石黒教授は言う。「頭と体はもともとつながっていない。だから体と機械を入替たって、機械が自分の思い通りに動くなら自分の体のように感じてしまう」

これを聞いて一瞬思い出したのは池谷裕二さんの「脳には妙なクセがある」である。かれは「意志は脳から生まれのではありません。周囲の環境と身体の状況で決まります」という。だから、意志を持って行動しているように思うが、実際はその場の環境と、経験とかが融合されて形成される「反射」なのだ。

わー、こう言われるとロボットでいけるじゃんと思ってしまう。その場を読み取るセンサーがあって、過去の経験が蓄積されたデータベースがあって、それによってどうアクションをとるかのロジックを組んでおけばいいのだ。でもどうかな、ロボットは泣くのかなあ、笑うのかなあ、怒るのかなあ。
  

2014年9月 7日

BeとDoは分けて考えよう

分類学と定義力と整理術が大事だと言っている。なぜかというとものの捉え方、問題のあり方、対応の仕方などが違ってくるからである。ですから分類をちゃんとしておかないと議論があっちこっちに行ってしまい収束しないことがある。ただ、分類すればいいとってもどういう括り方をするかは案外むずかしい。同じようなものを並べてハイ分けましたといわれてもかえってわからなくなる場合もある。一番簡単なのは、対立的なものにわけることだろう。

例えば、大きい小さいとか高い低いといったような分類なのだが、それではちょっと乱暴な感じもある。ここで、対立軸ではないがわりとわかりやすい2分割を提示したい。それは、BeとDoである。Beというのは「〜である」ということで、Doは「〜する」である。Be動詞で語られるものと一般的な動詞で語られるものに分類することである。

以前指摘したデータの分類にもある。リソースデータとイベントデータである。この場合は名詞形と動詞型と言ったほうがわかりやすいかもしれないが、同じことである。近頃、いわゆる超上流の検討の機会が多くなって来ていて、プロセス設計の前の戦略とかビジョンとかコンセプトとかいった議論をしている。そのとき、BeとDoを切り分けてみていく必要があると感じたのである。

超上流の議論でよく出てくるのが、「戦略」「戦術」「ビジョン」「コンセプト」「シナリオ」「ビジネスモデル」といったものであるが、BeとDoという見方をすると微妙に違いが見えてくる。「〜である」というものを定義するのが、「ビジョン」「コンセプト」で「〜する」という方は「戦略」「戦術」「シナリオ」といったところではないでしょうか。そしてBeからDoへの橋渡しをするのが「ビジネスモデル」であると思う。

つまり、ビジョンやコンセプトにより"私たちの会社は、あるいは事業はこうありたい"という設定をしたら、それを実現するために、戦略を立て、戦術を練り、実行プランをつくるということになります。ビジョンとコンセプトができればビジネスがうまくいくわけではありません。大事なのはどう実行するかです。ダイキン工業の井上会長が言っていたように「一流の戦略と二流の実行力よりも、二流の戦略と一流の実行力」というわけである。

そして、二流の戦略(ビジョン、コンセプトも含め)でも一流の実行力を発揮できるためには1.5流のビジネスモデルが必要になります。二流の戦略からは一流のビジネスモデルはできませんから、せめて一流に近づけたビジネスモデルにしなくてはいけません。ですから、このビジネスモデルが実行へもっていくための要になるのです。

Beでどうなりたいかを描いて、Doでそうなるために日々のオペレーションを行うわけで、最初に言ったように考え方とか定義することも違ってきます。文法が違うのです。良いBe、良いDoにするために、特徴のある、そして差別化できるBeにおける形容詞、Doにおける形容動詞が設定できるかがビジネスの成否を決定するのではないでしょうか。
  

About IT雑感

ブログ「mark-wada blog」のカテゴリ「IT雑感」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

前のカテゴリはIT再考です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type