メイン

IT再考 アーカイブ

2006年8月29日

ブログデビューはこころワクワク!

ついにブログデビューです。

今年の6月に退職しました。まだ定年前なのですが、思い切って30年以上勤めたサラリーマン生活に終止符です。それで今はIT関連の会社を起業しようと考えています。

会社を辞めると暇でしょうがないでしょうと言う人もいますが、なんのなんの、これからやりたいことが一杯あって時間が足りないくらいです。そんなオヤジがこれまで考えてきたことやこれからの夢そして今の楽しい生活などを発信していきたいと思います。

2009年2月17日

ビジネスプロセスパターン研究~マクロ視点での問題の所在~

前回の主旨で述べたように今の業務システムを変えたいと言っています。ということは、現状に様々は問題があって、その問題を解決していこうということでもあります。その問題あるいは課題とはいったい何なのだろうか。そこをきちっと分析して本質的な課題を抽出しないと方向がずれてしまいます。

個々の領域については細かく見ていくことにしますが、現状の業務システムおよびそれを取り巻く環境を俯瞰してみると、どうも「ビジネスとIT」、「ユーザとベンダー」といった両岸の間に流れる“誤解”の川があるような気がします。そこにかなりの部分の問題が潜んでいるように思えるのです。

何年もの間、「経営とITの融合」、「ビジネスに貢献するIT」、「ビジネスマインドをもったSE」だとか両者をうまくつなぐことの必要性は謳われていながら、現実には乖離があるのは否めないのではないでしょうか。

その誤解について少し見ていくことにします。そして、この誤解を解くことがギャップを埋める第一歩かもしれません。

(1)業務システムは開発するものだ
 ほとんどの人が業務システム開発という。これから販売管理システムを開発するのだという。では一体誰が開発するのですか?システム側の人が業務の仕組みを開発するのですか?

どうも、開発プロジェクトを起こし、そこで業務システムを開発してしまっているのではないのだろうか。だから、プロジェクトは混乱するわけで、そこでは業務(プロセス・機能)を開発してはいけないのです。DevelopmentとConstructionの違いであることを理解すれば、実際のシステム構築の場ではコードを書かないことが大切だとわかると思います。

業務システムというものはユーザがITとは関係なく自分たちのビジネスを強くするためにプロジェクトとは別に開発しておくわけで、それをあらかじめ開発されたソフトウエアを使って組み立てればいいのです。

これって、建築のケースで考えればわかりやすいと思いますが、家を建てるとき“家を開発する”とは言いませんよね。都市とか生活スタイルを開発するとはいいますし、機能的な建材を開発するともいいますよね。そういう感覚で業務システムを作ることを薦めます。

(2)システムを作ることが目的である
さて、業務システムを構築するというが、それだけが目的になってやしないだろうか。もうおわかりでしょうが、作って終わりではなく、それを使ってビジネスや業務を行い、それが役に立ってもらうことが真の目的になります。

そして、この役に立つというのは、皆さんつい忘れがちですが、オペレーションエクセレンスということで、作った瞬間ではなく、それを使っている日々の中で優れた機能やサービスを提供し続けられるかです。

(3)正しいシステムが役に立つ
だれでも、システムを“正しく”作ろうとします。そのための作り方の本もたくさん出ているし、それに異を唱えるひとはいません。しかし、それでいいのでしょうか。少なくとも正しいシステムであれば必ず役に立つとは言い切れないのは確かだと思います。

このことは何を意味しているかというと、見方を逆にすること、すなわち、役に立つシステムであれば正しくないシステムでもいいということになります。

システム屋さんはこういうことを言うとすぐに、正しくないシステムを作るとパフォーマンスが出ないとか、セキュリティが問題だとか言う。そういうことを言っているのではなく、まずは役に立つものを作ってからの話でしょということです。極端なことを言えば、何もシステム化しないほうが役に立つかもしれない、そんなこともあり得るということを頭に入れておくことも必要ではないでしょうか。

(4)業務知識がないとだめだ
よく言われることに、システムエンジニアの人たちに向かって、業務の経験がないからだめだとか、業務知識をもったユーザのいうとおりにすればいいのだとかがあります。これはほんとうでしょうか。そんなに業務経験、業務知識が必要なのでしょうか。

すこし意地悪風に考えてみましょう。まず、その業務経験と業務知識って標準的かつ普遍化されたものでしょうか。違いますよね、もろ属人的なものです。ですから、いつも豊かな経験と豊富な知識がある人がいるとは限りません。わずかな経験と貧弱な知識の人がプロジェクトにアサインされることはいくらでもあって、悲劇の引き金になります。

せっかく、要求定義をしてもプロジェクトの後半やテストの段階になって、”比較的”豊かな経験と知識をもつ、いわゆるキーパーソンが出てきて今までのものを覆してしまうこともよく見かけることです。その人でも本当に客観的に標準にできる要求を出せているかというとおおかたの場合心もとないのではないでしょうか。

ですから、どうしてもユーザがビジネス要求定義をしなくていけないとは思わないのです。前に言ったようにいい加減なユーザが定義したものをシステム化するほうが厄介になることもあるわけで、そうであれば、ユーザ側もシステム側のない、科学的な定義のしかたができれば、こうした誤解は解消されるのです。

ただ、誤解の誤解をしてはいけないのは、だからといってユーザがだめだと言っているのではありません、むしろユーザは意外と賢いということを肝に銘じたほうがいいと思っています。その賢さを引き出すことが大事なのです。

(5)要件定義が大事である
ここでは、「要求定義」と「要件定義」の違いを理解することです。「要求定義」というのは最近やっとその重要性が指摘され出してきていますが、これまでは特にわが国ではあまり語られることが少なかったように思います。

いきなりRFPを書いて(これもユーザではなく、ベンダーが書いてしまうケースもあります)、要件定義に入ります。そうするとどうなるかというと、前に書いたように要件定義に従って、そのとおりにシステムは作ったのだが、いざ動かしてみると使い物にならなかったという事態になります。

それは、要求定義でビジネス上の要件を抽出してそれを仕様化することをしていないからです。ですから、要件定義も大切ですが、それ以上に重要なことはこの要求定義をきちんとやることなのです。

そういうことができていないから、ビジネスの要求がシステムに反映されていないというユーザ側の不満と、ちゃんと言ってくれないからそうなるのだというシステム側の不満がぶつかることになってしまうのです。

(6)経営者はITを使って経営をすべきだ
一見なるほどそうだと思われるでしょうが、そうなのでしょうか。まず、ビジネスと一括りで言っていますが、その中には、経営・事業・業務というようなレベルがあります。

この最上位に経営というものがあって、これは経営者(陣)がこれにあたります。そして経営というのはいったいどういうことなのかであるが、それを考えるとき“社長の関心事は何か”という問いに答えるのがわかりやすいかもしれない。

おそらく多くの経営者の関心は、「事業構造論」と「人事」だと思っています。自社の事業ポートフォリオをどうするのか、そのために企業あるいは事業買収あるいは売却をどうするのかです。そして、それをだれにやらせるのか、おれの後継者をだれにするのかを絶えず考え続けているのです。

そうなると、はたしてそうしたことにITが要るのでしょうか。ある程度の情報は要るかも知れませんが、ITを使って何かをするというふうにはならないでしょう。

ですから、むしろここで言いたいのは、ITは事業に貢献するものであり、業務の効率を上げることに寄与できるもとと位置づけるのがよいでしょう。あまり大上段にふりかぶって「経営とITの融合」なんて言わないほうがいいように思うのです。あくまで、「事業とIT」くらいでいいのではないでしょうか。

これらの“誤解”をよく考え、それを解いていくことが大事であると思うのです。このことは何を意味するかというと、視点を変えてみたら、常識を疑ってみたら、既成概念をこわしてみたらという、今までと違う見方をあえてしてみることでまた新たな発想が生まれてくるような気がするのです。
 


2011年9月 1日

IT再考-WhatがHowに優先する

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

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

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

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

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

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

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

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

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



2011年9月 2日

IT再考-魅力的なWhatを提供できているのか?

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

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

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

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

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

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

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

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

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

2011年9月 3日

IT再考-Whatはオペレーションから発想する

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

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

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

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

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

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

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

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



2011年9月 4日

IT再考-営業のこと

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

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

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

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

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

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

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


2011年9月20日

IT再考-DOAが王道?

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

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

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

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

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

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

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

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


2011年9月26日

IT再考-構造論議ができていない

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

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

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

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

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

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

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


2011年10月 3日

IT再考-業務システムのあり方とその開発とは

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

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

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

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

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

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

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

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

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

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

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

2011年10月11日

IT再考-なぜDOAなのですか

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

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

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

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

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

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

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

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

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

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

2011年10月16日

IT再考-垂直分離から水平分離へ

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

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

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

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

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

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

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

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

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

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

2011年10月24日

IT再考-管理システムって何?

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

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

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

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

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

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

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

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

2011年10月31日

IT再考-Chemical BPMのすすめ

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

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

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

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

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

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

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

2011年11月 8日

IT再考-ビジネスモデルが一丁目一番地

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

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

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

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

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

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

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

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

2011年11月15日

IT再考-情報システムは組織である

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

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

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

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

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

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

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

2011年11月22日

IT再考-遊び心

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

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

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

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

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

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

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

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

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

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

2011年12月 1日

IT再考-遊び心(続き)

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

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

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

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

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

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

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

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

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

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

2011年12月 5日

IT再考-ファストシステム

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

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

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

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

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

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

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

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

2011年12月13日

IT再考-顧客要求

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

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

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

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

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

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

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

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

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

2011年12月20日

IT再考-「生命を捉えなおす」から考える(1)

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

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

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

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

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

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

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

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

2011年12月26日

IT再考-「生命を捉えなおす」から考える(2)

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

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

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

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

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

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

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

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

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

2012年1月11日

IT再考-「生命を捉えなおす」から考える(3)

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

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

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

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

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

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

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

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

2012年1月16日

IT再考-「生命を捉えなおす」から考える(4)

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

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

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

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

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

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

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

2012年1月23日

IT再考-家電化

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

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

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

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

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

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

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

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

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

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

2012年4月 3日

もしSIerのエンジニアがジョブズのスピーチを聞いたら(1)

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

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

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

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

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

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

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

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



2012年4月 4日

もしSIerのエンジニアがジョブズのスピーチを聞いたら(2)

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

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

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

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

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

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

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

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

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



2012年4月 8日

もしSIerのエンジニアがジョブズのスピーチを聞いたら(3)

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

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

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

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

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

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

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

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

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

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

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

2012年5月 7日

クラウド時代の業務システム・・・クラウドとは

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

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

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

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

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

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

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

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

2012年5月14日

クラウド時代の業務システム・・・クラウドは従来とどう違うのか

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

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

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

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

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

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

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

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

2012年5月22日

市販ソフトを使いたおす

「非定型業務のIT化」というテーマで記事を書いてきましたが、“実装を考える“というタイトルを最後に連載を終えました。というのも実装のところまで来ると、元々コードを書かない方法論を主張しているから、どこかから既成のソフトウエアを持って来ることになる。そうなると固有名詞のソフトウエアを特定した話になるので、フェーズを変えたわけである。

そのソフトウエアは昨年サイボウズ社から売り出されたクラウド型Webデータベースソフト「kintone」で、それを用いた実装について、新たなシリーズを起こしていく。題して「「kintone」を使いたおす」である。別にサイボウズ社からお金をもらっているわけではないのだが、「kintone 」が出る前からサイボウズの人と情報交換をしていた関係があって、割といいものができたので使ってみようということである。

それもあったのだが、もっと大きな理由は、「kintone」が出てくる前にオンプレミス型の「デヂエ」という前世代の同じWebデータベースを使ってシステム構築をしていたので、それをクラウド型に変えていきたいという思いがあったからある。

さて、「kintone」というのはいったいどんなソフトウエアなのだろうか。カタログ上の謳い文句は「ファストシステム」である。ファストフードのあのファストである。すなわち、欲しいと思ったときにすぐに手に入るということである。しかもそこそこの品質で安価である。そして、4つのファストを強調している。利用開始、効果の実感、管理者やユーザへの教育、ユーザニーズへの対応のそれぞれがファストであるという。

ちょっとわかりにくいところもあるので説明しておくと、詰まるところ簡単にデータベースが開発できるプラットフォームがクラウドにあるっていうことだ。だから、利用開始や効果の実感がファストというのはクラウドのメリットである。申し込みから利用開始まですぐだし、最初は無料お試し期間もあってすごく敷居が低い。しかも、従量課金で低料金である。

データベースアプリの開発は非常に簡単だ。フォーム設計のところでは、ラベル、文字列、ラジオボタン、日付といった各種のパーツがステンシルのようにおいてあり、それをドラッグ&ドロップでフォーム設定エリアに配置すればそれでOKだ。それが入力フォームとなり、そこから一覧表を作ったり、レポート出力したりできる。だから、案件管理とか日報、顧客リスト、FAQなんていうのはすぐにできてしまう。テンプレートもあるから、ものの数10分でできてしまうものもある。

さて、これから日報だとかFAQを作ろうとしているわけではありません。Excelの代替システムを作るつもりではないのです。「非定型業務のIT化」にこのソフトウエアを活用しようとしているわけです。今までずっと議論してきたように非定型業務のほとんどはプロセスから成り立っています。単にデータベースを作ればよいということではありません。

もちろん、「kintone」はプロセスアプリケーションを作るためにあるツールではありませんから、いろいろな工夫を施す必要があります。場合によっては人力で対応するとか、多少トリッキーなことにもなるかもしれませんが、市販のソフトを使うメリットの方がコードを書くより格段にあります。それは、基本的にはテストが不要ですし、ユーザ管理とかセキュリティとかいったシステム管理がすでにあるのですから、ここも大きいと思います。

ということで、次回から、どうやって実現したらよいのかを議論していくことにします。ただ、スペシフィックでテクニカルな話になりますのでWadit Blog. の方に掲載していきます。


2012年5月28日

クラウド時代の業務システム・・・業務システムにクラウドが与える影響

業務システムにクラウドが与える影響を考える場合、ASP、SaaSというものがどういうもので、その延長としてクラウド化があるのかどうかを議論するのがいいと思う。「インターネットの向こう側にある業務システムを共同で使い、利用料金を払う形態」が有効なのかどうかということである。

ASPは字句通りに解釈すると、「SIerのサービスの一つとして、業務アプリケーションを複数のユーザに提供する」ということになる。しかし、このアプリケーションとはいったい何なのか、全く同じものを使わすのか、どうやってインスタンスを分けるのかとかいった問題を抱えていた。つまり、概念的なレベルの話でこれこそがASPという実体があったわけではなかった。

よくある3文字熟語のバズワードである。ただ、ぼくがその時考えたことは、グループ会社に同じシステムを使わすということである。情報システム部門を分社させて情報子会社を作ったのだが、そのビジネスモデルのキーはグループ会社へ安価なサービスお提供することであった。シェアードサービス化とも言える。何しろ、子会社が100社以上で国内70数社で海外にも30社ぐらいあったので、そこがバラバラのシステムは入っているので共通化、標準化して、運用を一括でやりたかったのである。

そうなると当然同じものを共同利用するという考えが浮かんでくる。汎用機をTSSのように使うわけにもいかないし、世はオープン化、クラサバへ移行した時期でもあったので、どうやってその仕組みを作ったらいいのか思い悩んだものだ。そのとき、誰だかもう忘れたがASPという概念を提示していた。これだと飛び付いたはいいが、統合ネットワーク化から始めなくてはいけなかった。また、業務パッケージを持って来ると、投資がすごいことになるし、子会社はあるゆる業種・業態があるので対応が難しいこともあり、自社でフレームワークを作ってしまった。

そんなことで始めたのだが、非常に難しいプロジェクトになる。結局、親会社で大型パッケージの導入が決まり、そちらの方が忙しくなり止まってしまったのだが、今はどうなっているのかわからない。今日のクラウドの環境があればかなりのことができるようになった。プライベートクラウドという言い方があるが、グループ会社を多く抱える大企業にあっては有効であると思う。

ですから、クラウドはひとつには標準化されたアプリケーションあるいは業務システムを複数ユーザーが共同で利用することでコストを抑える効果があるような形態の企業群が採用してこそメリットが享受できるのではないでしょうか。少なくとも、そうしたことをやりたいと自分たちの頭で考えて人にとってはいい時代がやってきたのではないかと思います。

もうひとつは、個別企業の場合でクラウド上にあるプラットフォームを利用して安価に自分たちの業務システムが組み上げられて、使用できることがある。ここで気をつけなくてはいけないのは、プラットフォーム利用に留めることだということである。そもそもクラウド上にぴったりの業務システムがあるわけないからだ。もしあったとしても、相手が勝手にバージョン変えてきらどうしますか。ですから、やみくもにとびつくのではなく、そうならない領域での利用ということをよく考えておく必要があります。
  
  


2012年6月 2日

大企業と中小企業の違い

いま、ある中小企業でIT化のお手伝いをしている。プロセス設計が終わって実装のためのフォーム定義の最中ですが、いささか中小企業の特徴というか、大企業とだいぶ違うなあという実感がしたのでそのことについて書く。ぼくは、以前は従業員数千人の会社にいたから、いちおう大企業のなんたるかは経験済みである。その100分の一にも満たない小さな会社なので、ずいぶんと驚くことや感心させられることが多くある。

もちろん、そうした従業員数とか売上だとかといったありきたりの比較をしてもしょうがない。業務プロセスの扱いについてである。会社にある業務プロセスは業種さえ変わらなければ会社の規模には関係なく同じではないだろうか。製造業なら営業があり、調達、設計、生産、出荷などのプロセスがある。そのプロセスでやっていることには規模から来る違いはないといえる。

しかしながら、会社の規模が違えばいろいろなところが違いますよと主張する人がいる。だいたいが大企業の人たちである。会社が大きいとなにしろ大変なんだからという。いったい何が大変なのだろうか。例えばオーダーの数がぜんぜん違うじゃんという。だけどひとり当たりのオーダー数がどうなのだろう。いやそんなことよりやっていること自体は同じでしょうと言いたいのだ。

ただ、その違いが表れるところがある。それは、そのプロセスを誰がどうやってコントロールし、監視・管理しているかというオペレーションのところで、そこに差が出てくるように思う。そこでも一番違うのがひとりひとりが見ている管理範囲ではないだろうか。更に言うと管理単位同士の連携の濃さとか円滑さみたいなところだろう。

つまり、中小企業だとひとりが管理する範囲が必然的に広くなり、また、人と人の関係がすごく近いので、ツーといえばカー的な連携ができる。一方、大企業では、縦割りの組織が基本でかつその中でもかなり細分化されてくるから、そこの人は狭く深くなっていく、そして組織的にも分かれるから壁ができて連携がうまくいかないようなケースもでてくる。よいか悪いかとか、できるできないかということではなくそういった性格があるということである。

ですから、業務プロセスを書いていく時にもそうした特徴が出てくるのである。具体的に見ていこう。今対象となっているプロセスは顧客サービス要求に対する処理プロセスである。お客さんが会社の窓口にサービスを要求して来るのを受付けるところから始まって、その要求に答えてやるといったことをする。顧客サービスといってもいろいろあって、苦情とかクレーム、修理要求、返品、単なる問合せといったものがある。

それぞれの要求でどうやって対処するかはけっこう違っている。となると、それぞれ別々に個別プロセスを書くのが普通であろう。例えば、クレームだったらその内容を吟味して、不良品を返してもらい、それを検査して修理個所を直して送り返す。一方、通常の修理品だと、返してもらうのは同じだが、検査して修理内容が決まるとどれくらい費用がかかるか算出して、その見積を出して、修理するかどうか決めてもらうというような動作をする。

これだけみると別個のプロセスで管理した方がよさそうに思うでしょうが、全部一緒のプロセスに合体してしまいました。その理由は、クレームでもひょっとすると通常修理対象だったとか、その逆に修理してくれと言われたのだが検査をしたら欠陥があったなんてこともあること、クレーム品でも修理費用もちゃんと出しておく必要があるねとか、どれも欠陥情報は一元的に管理するよねといったことがでてくる。

結局、統合したような形のプロセスを設計することになった。だから、オペレーション上は、要求サービスによっては、使わないアクティビティが出てくるがそれはブランクにしておけばいいという風にした。(分岐という考え方は基本的にはしない)それでいいのだという。ひとつには前述したように、クレーム品であろうが修理品であろうが同じ人間が見るからというのがある。

いまこのプロセスを見ていて、中小企業の強さみたいなものを感じたのと、これまでの業務システムの考え方あるいはツールだとこうした強みを生かせる仕組みができないだろうなあと思った。つまり、きっちりとしたインターフェースがかえって効率性を損なうようなとき、それを緩めることができないといったことである。システムはある意味組織であるからそうなるのだが、大企業の硬直した組織とそれを写像した既成の業務システムの硬直性は通底しているわけでここが大きな問題なのである。

2012年6月 3日

クラウド時代の業務システム・・・クラウドならではの業務システムはあるのか

これまで、クラウド型のシステム形態がもたらすメリットを要求側できちんとみておかないでやみくもにいれればいいという話はないということを書いてきた。ずっと以前にセブンイレブンの情報化のことに及んだことがあって、彼らは、今の技術がどうのこうのという前に自分たちがやりたいことが先にあって、その時はまだ技術やパフォーマンスが追いついてなかったら待っていて、実現できるようになった途端にそれを導入するということなのだ。

だから、今のクラウドをめぐる議論で、クラウドが出てきたからこれをどうやって使おうかというスタンスで騒いでやしないだろうか。今言ったセブンイレブンもそうだし、前回ぼくがASPをやりたかったがまだその環境が不十分だったのがやっとできるようになったと書いたことにつながるのだが、繰り返すがまずは何をしたいのか、それを実現するための技術やインフラ、他のリソースがあるのかないのか、なかったらとりあえずここまでにしておこうということではないだろうか。そうではない本末転倒のアプローチはやめたほうがよい。

それで、業務システムのことですが、間違ってはいけないのは、クラウドならでは、あるいはクラウドにしかない業務システムというのはあるのだろうかということである。業務システムというのはビジネスパーソンが営業とか販売・購買などの業務を行うためのものだから、クラウド以前からずっとやってきたことで、クラウドだからとといって新しく生まれたものではない。

「クラウドは従来とどう違うのか」のところでも書いたように、利用形態が新しくなって、それにより運用のコストやパフォーマンス、拡張性などが改善されたのであって、業務システムそのものが新規性を持ったわけではない。ということは、いままでも、必要に迫られたものはクラウドに近い形態もある。たとえば、地方銀行の勘定系のシステムは約8割が共同利用されている。これなどは、クラウドの出現を待つまでもなく共同利用という形態が多くのメリットを生むからそうしているのである。

だから、業務システム側からの要請としてクラウド化ということはなかった。ただ、ASPについて書いたようにグループ内共同利用化という要求は芽生えていたのは確かだ。さて、要請はしなかったが、現実としては、クラウドが目の前に姿をあらわすようになった。これを無視するわけにはいかないだろう。なぜかといえば、コストを大幅に下げることができる可能性があるからである。

繰り返すが、仕事に使う業務システムそのものをクラウドから手に入れ、それを使うというのはそれほど多く出てくるとは思えない。クラウドの特徴は同じものを共同利用するということだから、そうなると業務システムを競争相手の会社と共同で使うということなのだろうか。あれえ、差別化とか競争優位性とかはどうなっちゃうのかという話になる。

2012年6月 8日

クラウド時代の業務システム・・・業務システム構築のためのクラウド利用

前回、差別化とか競争優位性とクラウドの矛盾の話をした。クラウドの特徴である共同利用性がそうした企業の個別性を損なうのではないかという指摘である。つまり、差別化とか競争優位性はクラウドの中にはないわけで、それがあるのはビジネスモデルやビジネスプロセスの中である。

もうおわかりだと思いますが、どこの会社でも同じことをやっているようなものだったらクラウド利用はありだと思うが、そうではない、ここは自分たちだけのオリジナルであるとか、こだわりがあるところだというようなところはクラウドではできないのである。ここの話は実は、ITがこれまでたどった誤解と同じなのである。

どういうことかというと、ITは自動化のためのツールであるから、自動化に耐えられるように定型化しようとする。それは当たり前の話でロジックがないとプログラムが書けないからである。定型化されたものは最初に言ったように差別化とか競争優位性を持つことはできない。ですから、人間の代替機能としてのITと位置づけている限りは、ITで差をつけることはできないのだ。

このことは自分自身に対する反省も含めて言いたいのだが、高価で高機能の業務パッケージを入れると何だか競争他社よりも勝ったような錯覚に陥る。同業の会社があるパッケージを入れると、離されていけないと思い何でもいいから同じものを導入するといったバカな競争をした。差別化とか競争優位性を持つことができないシステムを入れる競争をしていたという愚かなことをしてきたのである。これからはそれを繰り返してはいけない。

しかしだからといって、クラウドを使う必要がないといっているわけではない。ここまでの話は業務システムそのものの話であるが、業務システムそのものではなくてそれを構築するためのプラットフォームをクラウドにあるものを利用することは有効である。そういうとSaaSではなくPaaSですねと言われるのだが、必ずしもそうではなくて実際的には両者の組み合わせである。

標準的、共通的なサービスとプラットフォームをうまく使いこなして、差別化された、競争優位の業務システムを組み上げるというのがより良い選択肢ではないでしょうか。そこにある考え方は何かというと、人間の代替機能としてのITではなく、ビジネス戦略を実現するための道具としてもITという捉え方である。

ですから、自分たちの業務システムはクラウドとは関係なく設計し、構築すべきで、そのときたまたまクラウドにちょうど合うコンポーネントがあった、あるいは基盤があったのでそれを使おうというのがとるべき態度ではないでしょうか。つまり、クラウドには世の中で喧伝されているような業務システムそのものに与えるインパクトはあまりないが、その開発および運用コスト、パフォーマンスにおいては大きく改善されるであろう。
  

2012年6月15日

クラウド時代の業務システム・・・どうやってシステム構築を行うのか

前回、業務システムそのものをクラウドから利用するのではなく、そのコンポーネントや基盤を利用するのがよろしいのではないかと指摘した。今回は、そうした構築のし方について考えてみましょう。これまで議論で、差別化や競争優位性を発揮するのは当たり前の話として、共同利用できるような部分ではなく独自性をもったものでなくてはいけないという話をした。

また、差別化や競争優位性をもった独自性のあるところというのは定型的な業務ではなく非定型業務にそれがあるという議論もあったかと思う。ということはこれからの業務システム構築の要諦は、非定型業務システムをクラウドにある要素を有効に活用してどうやって構築していくかになる。ところが、非定型業務にフィットするようなものがあるかどうかというと残念ながらほとんどないというのが現状である。

これは、別にクラウドだからというわけでもなく、クライド以外のところにも少ない、というかないに等しい。BPMSもあるのだが、基本的には定型化されたものが対象である。分岐や差し戻しをプロセスエンジンを使って回すのだが、そこが非定型だったらどうするのか問題になる。あらゆるケースを考えて分岐を作っておくのだろうか。

このあたりは「非定型業務のIT化」というエントリーでさんざん議論してきたことだが、非定型業務というのはある種の“調整的行為”による選択活動だから、決まりきった理路があるわけではなく大いに揺らぐのである。でも、それはいかげんでも、あいまいでもなく合意形成がちゃんとなされているのである。これがおおかたの会社の業務である。

こうした特徴をもった動きを何を使って表現するのかが大事で、そのための基盤要素をクラウドから探してくることになる。調整的なことだから、データを登録するとか検索するとかいった機能より抽象度が高いものが必要になる。つまり、調整することと調整する流れを表現できるものになる。

調整すること、すなわち意思決定は個性的である。結果そのものではなく、結果を導くための調整のし方が固有のもので、特色がでるところである。大胆にいくのか慎重なのかとか、短期的に考えるのか、長期を見据えるのかといった方針が反映されるのである。方針は、手順でではないからロジック化できない。

ですから、今のクラウド上にある業務アプリの基本はデータベースだから、それだけでは難しいので、一段抽象度を上げた作り方にする必要がある。調整だから、データ登録フィールドがあるだけの“点“ではなく”場“が大事になってくるのです。このことはクラウドであろうがなかろうが言えることで、つまりクラウドだから業務システムの構築のし方が変わる事はない。クラウドがもてはやされるけど根本的な考え方は不変であり、ここをしっかり抑えておかないとただ踊らされてしまうだけで何もメリットを生まない。

このシリーズはこれで終わりますが、具体的な構築技法や実装については、「「kintone」を使いたおす」に詳しく書いていきますのでそちらをご覧になってください。何度も言いますが、クラウドのインパクトは大きいのですが、それは運用とかインフラ、ITコストとかいうところでのことであって、クラウドだから業務システム、業務アプリケーションの中味が変わることはないので、地に足がついた対応をすることを強くお薦めいたします。

2012年6月27日

IT再考-ERPはプロセスに出られるか

業務システムが作られる領域を企業のビジネス活動のチェーンでみると、大きく顧客との接点のところと、それを受けてプロセス活動を行うところ、そしてプロセス活動の結果を登録し、集計するところの3つがあります。ERPはこの最後の領域をカバーするものとして登場してきました。

ですから、ERPの主たるキーワードは「統合データベース」です。企業では最終的にはプロセス活動記録、事業成果を集約して記録するので、販売、購買、生産といったシステムやデータベースがバラバラだと大変困るわけです。そこをマスタなどのリソースも含めて統合的に管理できるようになったことが最大のメリットだと思います。

しかしながら、重要な問題として、ではERPに登録するデータはどうやって作っているのでしょうか。このデータを作るというのはフロント側のプロセス活動によって生成されるから、どうしてもERPはこの領域に出たがるのです。最近そうした動きもあります。しかし、やたら出てきてもらっても困るというか、出てきていいプロセスとそうでないところがある。

では、その理由を考えてみましょう。プロセスには大きく2つに分けられると思っています。顧客接点のプロセスと内部プロセスです。このとき、違いが出てくるのはどこだと思いますか。プロセスの構造をみていくとざっくりいうと始点と終点とその間に中間点があります。さて、皆さん始点を考えてみください。文字通りプロセスが始まる点は何なのかです。この始点はどうして決まるかという点に違いがあります。

顧客接点プロセス、すなわちお客さんと直接やりとりするようなプロセスの始点は必ず「顧客要求」ですよね。実際には、このお客さんの要求が、はっきりとした形になった「顧客依頼」になってメインプロセスは起動しますが、要するにお客さんのこうして欲しい、ああしてくれというのが始まりです。

一方の内部プロセスですが、これは企業側としてこれが欲しい、こうしたいといった内部的な要求が出されるようなものです。例えば、代金の回収なんては企業側から取りに行くわけだから内部プロセスになります。つまり、こうしたプロセスでは終点が先に決まって、その終点に合うように始点がきまるという性格になります。ですから、ものの考え方というかアプローチが反対だということになります。

さて、ERPが出てきていいプロセスとそうでないところがあると言ったのはこのことで、内部プロセスならまだしも、顧客接点プロセスに出てこないでくれと思っているのである。つまり、プロセスを終点から考えるようなアプローチでやられては困るという話である。顧客接点プロセスはお客さんの要求をよく吟味してそれに的確に答えられるようにプロセスを動かすことが求められるから、自分たちの都合のいいように顧客要求を曲げてはいけないのである。発想が違うのである。

2012年7月24日

プロセス管理とプロジェクト管理

プロセス管理とプロジェクト管理の違いはあるのでしょうか?このブログではプロセスのことばかり言及しているので、プロジェクト管理についても少しみていきましょう。プロジェクト管理の知識体系として認知度が高くなったPMBOK(Project Management Body of Knowledge)にもちゃんとプロセス体系というのがあって、(1)立ち上げのプロセス (2) 計画のプロセス (3) 実行のプロセス (4) 終結のプロセス (5) 監視コントロールのプロセスが定義されています。

ですから、プロジェクトの実行もプロセスなのです。ただ、PMBOKを読みこんだわけではないので間違っているかもしれませんが、5つのプロセスに分けていますが、計画のプロセス以外は全部一連の動きの中にあるように思えます。全体を一つのプロセスと考えてもよさそうです。つまり、(1)の立ち上げのプロセスはプロセスの始点で(3)の実行プロセスが中間アクティビティで(4)はプロセスの終点というわけです。

(5)の監視というのはプロセスでいうパフォーマンス管理になります。また、(2)の計画プロセスは制約情報やパフォーマンスドライバーを作成するサブプロセスと考えられます。すなわち、計画値はプロセス実行の時の目標メトリクスになります。ですから、(5)とも関係してくるのです。

こうして見て行くとプロジェクト管理というのは実行フェーズではプロセス管理そのものであるとも言えます。普通のプロセスに較べると時間軸が違う、息の長いプロセスであるというくらいの差にみえます。あとはパフォーマンス管理のポイントが大きく期日に偏っていることかもしれません。

では実際にはプロジェクト管理はどんな風にやられているのでしょうか。おそらく、まずは目標があって、いつまでにこれこれの成果をあげることという風に設定され、そこからスコープと必要なリソースを調達して、計画スケジュールを立て、マイルストンとWBSを作成するのではないでしょうか。これが立ち上げプロセスです。ここらはプロセスというより、リソースマネジメントやプランニングですね。

次は実行プロセスになりますが、計画でできたスケジュールとWBSを持って進捗を管理することになります。使うツールは、MS-Projectあたりがよく使われているのではないでしょうか。基本的にはガントチャートタイプの表を見ながら実績を登録し、マイルストーンからの乖離などをビジュアルに表示されたものでチェックすると思います。

しかし、それでうまくプロジェクト管理ができるのかという疑問があります。今プロセス中心アプローチでプロセスを設計し、できたプロセスをオペレーションすることの重要性を強調しているが、この観点から同じようにプロジェクト監視オペレーションを眺めてみると、WBSで規定されたタスクをどうやって進捗させているのかが気になるのである。

つまり、作業が終わったという結果だけをガントチャートに登録して、それが期日通りなのかそうでないのかだけを管理しているように見える。もちろん計画スケジュール通りに進行させることは大事であることは言うまでもないのだが、その作業そのもの“質”は見えているのでしょうか。

プロセス中心アプローチで言っている単位意思決定をどうやっているのかということである。必要な情報を得てそれを参照して、メンバーとコミュニケーションしながらやっているのかということである。WBSを細分化すればするほど個人レベルのタスクに落ちてしまうのでコラボレーションという意味合いが薄れてしまうし、ガントチャートでプロセス管理と同じようにできるとも思えない。ガントチャートは計画値を作るためのシミュレーターでしかないのだ。

プロジェクトでも普通のプロセス業務でも同じだと思う。今まではITツールにアクションやタスクの結果を入力して、それを表示してレポートを出すことが業務だと思っている節がある。それだと、それぞれのアクションやタスクが隠れてしまい、可視化できないままです。ですから、プロセス管理で新たなコンセプトを提案したのと同じようにプロジェクト管理にも新しいコンセプトを入れたらいいと思うのである。
  

2012年8月 3日

プロセス中心アプローチとオープン化

プロセス中心アプローチでのシステム構築を標榜しているが、こうしたアプローチのメリットは何なのだろうか。システム開発作業の効率化、開発コストの低減なのだろうか、業務改善なのだろうか、業務の可視化なのだろうか。どれも当たっているのでそれを目的化してもかまわないのだが、少し角度を変えて見てみようと思う。

その観点は「オープン化」ということである。この場合の「オープン化」というのはITの世界なんかでいうオープンシステムとかオープンソースのオープンという意味とはちょっと違う、隠れていたものを表にだすというような意味合いである。開示、公開といったニュアンスになります。インフォーマルな世界をフォーマルな世界に引き上げるとも言えるかもしれない。

プロセス中心アプローチというのは、まずはプロセスを書いておいて、そのプロセスの要素であるアクティビティが円滑に進むのに必要な機能を付帯させることをします。そして、プロセスを書きだす時には人や組織を意識することなしに、ビジネス活動にとって必要不可欠なものは何かという切り込み方で書いていきます。ですから、そのアクションがどこでやられているのかとか、フォーマルかインフォーマルかは関係なしに抽出していくわけです。

そうして浮かび上がったプロセスはどういったものになるでしょうか。いままで隠れていたもの、裏で調整されていたものなどが表に出てくることになります。これが「オープン化」です。従来からもプロセスを書いているとおっしゃる方もいます。しかし、それはコンピュータの画面をつないだ業務フローでしかなかったのではないでしょうか。これでは画面と画面の間にあるインフォーマルな動きを拾うことはできません。

では、「オープン化」によってどんないいことが待っているのでしょうか。意思決定の質や量が上がります。オープンになることで、多くの人の知恵が集まる、すなわち集合知が形成されること、経験・ノウハウが蓄積され後に活かせるといったことが寄与します。

また、もうひとつ大事なことは意外と見過ごされがちですが、人材育成につながるということです。皆さんも経験があると思いますが、よくわかっていない若手の時代に上司や先輩からおまえにまかせたからなと言われ、どうしていいか困ったなんてことがあったでしょう。誰もやり方を教えてくれないし、もう何年もおれのやっていることを見てきたんだからできるだろうなんて勝手に思われていたりする。

しかし、インフォーマルの世界で何年もかかって習得したことなんてわからないですよね。当たってくだけろと言われたって失敗したら怒られるんだから始末が悪い。そんな職場は楽しくないとなる。それを全部表に出すのだ。プロセス中心アプローチではまず設計の時に、できるだけ若手に書かせることにします。そのとき、ベテランの人も参加させて暗黙知を形式知に変換して埋め込むようにするわけです。この作業の過程で若手はノウハウを表面的ですが知ることができます。

また、プロセス中心アプローチは設計して実装して終わりではなく、オペレーションしてこそ成果を出すわけで、そのオペレーションはコミュニケーションをしながらアクションを起こします。そういう仕掛けにすることが重要です。そこにベテランの人をアドバイザーとして参加させれば、日々の実務の局面で知恵を借りることができます。不機嫌な職場の現象の一つに冷ややかな傍観者がいることがあると思うのだが、それがなくなるということである。いい意味で「赤信号みんなで渡れば怖くない」というところかもしれない。

問題は、暗黙知を持っていることがその人の価値と勘違いして抱え込まれてしまうことです。しかし、組織としてのプロセス活動のメンバーに指定して、もしあなたが言わなかったらOKであるとみなすルールにするといったこともしたらよいと思う。これは、同時に不正防止にもつながるので、是非オープン化ということを意識してプロセス設計を行ってほしいと願っている。

2012年8月15日

AsIs記述不要論

以前にエントリーした「CIO不要論」ではないが、「AsIs記述不要論」を書いてみようと思う。システム構築のコンセプトを変えて見ると、それまで常識とされていたものがはたして今まで通り常識なのだろうかという疑問がわいてくる。時代が変わると考え方も変わるのと同じで、環境の変化で常識も変わっていく。

現在の情報システム構築の進め方は、現状分析という形で今のあるがままの姿、すなわちAsIsを書きましょうから始まる。AsIsでもプロセスを書くならまだいいのだが、今のシステムを使った業務フローなんて書く場合もよくあるのだがあまり意味がないように思える。このAsIsから、問題点を探したり、共通化、標準化といったチェックによりToBe化していく。

いかにも正しいように思えるでしょうが、何か変だと思いませんか。おそらく多くの人はそうは思っていないのではないでしょう。なぜなら、従前のようなシステム構築を行う場合は、そうしたやり方が業務改善、プロセス改革につながると当たり前のように信じられているからです。しかしながら、プロセス中心アプローチでは違ってきます。とういうかできないのです。つまり、「AsIsは書かないのではなく書けない」のです。

プロセス中心アプローチでは、組織とか人とかは関係なく、その事業、ビジネスにとって必要なプロセスは何かという攻め方をします。もうこれだけでおわかりだと思いますが、その時点でAsIsではなくなります。AsIsは組織と人が必ず絡んできますので、この組織だから、この人がいるからということで業務フローが規定されてしまいます。ですから、例えば、AsIsを見て、業務が重複しているからそこを改善してToBe化しようなんてやらなくても最初から重複のない業務プロセスが書けわけです。

言ってみれば、最初から今までと違ったコンセプトで業務プロセスを記述するからToBeプロセスの原型を直接記述してしまうことになります。ここでToBeプロセスの原型と言ったのは、そんなにすぐにToBeへは持っていけませんので、まずは基本的なところだけを構築しておけばよいということです。

プロセス中心アプローチの特徴の一つは成長できる仕組みができるということでもあります。骨格をきちんと作っておけば、そこから筋肉をつければよいのです。これまでのやり方だと、使ってもいないのに、紙の上でToBe化しようとしますが難しい話だと思います。しかしながら、今のシステムは、スクラッチで作ろうが、パッケージを持ってこようが一生懸命ToBe化しようとします。ところが使ってみるとギャップだらけということもあります。

これからのシステム作りは、早めにプロセスを書いてそれを使ってみて練り上げるのが一番のような気がします。例えば、業務ルールにしても、最初からあるべき姿のルールを作ろうとしても絶対できません。往々にしてそんなできもしないことをやりだします。そして挫折するわけです。これはムダですよね。

だから、最初は生半可なルールでいいのです。そのかわり、自動化とかコンピュータにロジックを持たせたらいけませんよ。当初は人間が介在して調整します。そうしたことが重なってくるとルールらしきものが自然とできあがってきます。それをルールとして固めて行くのです。このようにして、成長していく、自己学習して進化していくような仕組みを作れば、いわゆるAsIsプロセス記述は必要なくなるのです。
  

2012年9月11日

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

前回、ビジネス活動を簡単に5つの領域、すなわちPlan、Requirement、Process、Resources、Resultというふうに分けてみて、それぞれにプロセスがどのように入り込んでいるのかという議論を始めた。そして、まずはRequirementのところにフォーカスしましたが、考えてみると、ビジネス活動のところをちゃんと定義なり、論理化しておかないと枝葉になりかねないので、少し回りくどいかもしれませんが、基本線に立ち戻りつつ議論していこうと思います。

前回示した模式図は構造を表しています。大きな括りとしての業務機能を配したものです。ではそれぞれの機能はどうなっているのかをみていきましょう。下図が各エリアのもつ機能を表したものです。すべてを網羅したものではなく代表的なものをあげてあります。
BZfunction1.bmp
Planというのは、単なる計画ということではなく、計画を立てるためのポリシー、経営戦略、事業コンセプトといったものや、計画を実際のお金の裏付けをもったものに落とした予算といったものも含んでいます。Planというのは、もちろんここだけのものではなく、どこの領域、レベルでも多かれ少なけれ持っている機能ですが、ここでは大きく企業全体のものを指しています。

Requirementというのは、顧客接点のところで、基本的にはお客さんの要求をどうさばいていくかということです。お客さんというのはある意味わがままですから、様々な要求がやってきます。それらを最終的にビジネスに結びつけることが求められる機能です。要求には単なる問い合わせから、オーダーにつながる要求、さらに苦情やクレームの類まであります。

以前は、クレームを受け付けることを嫌がる企業が多くありました。いちいちお客さんの言い分を聞いていたらたまらないといった感覚だったと思います。ところが最近では、クレームこそ新商品のアイデアの源泉だとか、適切なクレーム処理がリーピーターを増やすといった言われ方もされ、アフターサービスの質がビジネスにつながるという意識になっています。

Processについては、本稿の主題なので後でたっぷり議論するとして、次はResourcesです。これは経営資源のことで、いわゆるヒト、モノ、カネ、情報というのがよく言われるものです。最近ではそれ以外に、技術・ノウハウ、ブランド力、ネットワークといった無形資産の価値の重要性が増しています。ビジネスはこうしたResourcesを使ってビジネス活動を行うわけですが、競争相手に勝つとか、市場を寡占するなんてことは競争力のあるResourcesがあってこそ実現できるものなのです。

最後のResultは事業成果をチェックして、その成績を報告・開示することです。煎じつめると決算書を作ることです。貸借対照表、損益計算書、キャシュフロー計算書、事業報告書を書くことに他なりません。そのために必要な、売上だったり、変動費や固定費のコストだったり、またResourcesの状況だったりを(勘定科目といってもいいかもしれません)集計して加工するわけです。

ということで、Processを除く4つのエリアについてみていきましたが、それぞれの業務機能の性格が違うのがお分かりになったかと思います。その特徴に応じたプロセスがあると同時にマネジメントのやり方が違うことになります。次回エリア間の関係について考えたあとにこの話に行きます。
  

2012年9月17日

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

前回にビジネス活動のところをちゃんと定義なり、論理化しましょうとなったのでシリーズ化していきます。今まで言ってきたことと重複することも多々あるかと思いますが、年寄りの繰り言と思って聞いてつかーさい。

これまでの2回でビジネスの構造と機能についてPlan、Requirement、Process、Resources、Resultの5つのエリアで見ていきました。図の恰好が花びら風になっているので接しているところの関係は分かるのですが離れているところとの関係はどうなっているのだろうか。それをBridgeと称して考えてみた。それが下図です。
businesuFrennkei.bmp
最初は、PlanとRequirementの関係です。戦略とか事業方針、計画といったものとお客さんの要求との関係になります。Plan側から見ると、これはマーケティング戦略になると思うのですが、SegmentationとかTargetingですね。つまりどういった市場と顧客に狙いを定めるかになります。

一方、要求側つまり顧客から見るとPlanというのはどのように映るのでしょうか。近頃はCSR(Corporate Social Responsibility)とかメセナ活動とか、今回のような災害支援といったようなこととか、ずばり企業成績もそうかもしれませんが、その会社のイメージをわかせるための姿勢といったものが大変重要になってきています。

RequirementとResourcesの関係はどうでしょうか。Resourcesというのはヒト、モノ、カネといった経営資源のことですが。そこで重要なのはお客さんとの関係性です。そこで継続性のあるよい関係ができネットワーク化されるとそれは大きな経営資源となります。また、製品やサービスといったリソースは、お客さんによいブランドイメージを持ってもらうことも大事です。こうした、ネットワーク力とブランド力は現代のビジネスではとても重要な要素となっています。

さて、そのResourcesとResultです。Resultは事業成績のことで最終的には決算書といったフォームに落とされるわけです。わかりやすいのは、ビジネス活動で消費された、あるいは生み出されたリソースをバランスシートに反映することです。資金調達をどれだけしたかとか、従業員の採用を増やしたとか、給与をあげたとか、設備投資をしたとか言ったことです。また、あまりないのですが事業の結果をリソースに戻すといったことがあります。

最後のResultとPlanとの間になりますが、Plan側からの要請はあまりなく、多少利益の配分だとかといった経営方針が関係しますが、一番大事なのは事業成果から戦略なり次の事業方針といったようなところを見直すことがあります。ここが非常に重要なところで、BI(Business Intelligence)などを使って分析して新たな計画を作っていくことになります。

ということで各エリア間の関係をみてきましたが、このことは実は大企業では組織間の連携を必要とします。縦割りの組織になっているとこのインターフェースがうまくいっていない例をみかけます。これまで見てきたような構造化をちゃんとして、何を受け渡していくのか、どうやったらスムーズの受け渡せるのかをお互いに理解しあうことが大事になってくるのではないでしょうか。


2012年9月21日

ビジネス活動にプロセスはどのように入り込んでいるのか - PDCAとビジネスモデル

さて、企業活動モデルの構造と機能をみていくと、会社ってPDCAを回しているということに気がつくと思います。計画を立ててそれを実行して、実行した結果をチェックして、次のアクションにつなげるというわけである。それをあの模式図にかぶせると下のようになります。
PDCA.bmp
Planは一緒ですからそのままですが、DoはProcessのところに当たります。つまりプロセスをオペレーションすることで計画を実行することになります。その結果はResultですから、そこでチェックが入ることになります。チェックの最たるものは会計監査ですね。それ以外でも管理会計と称して様々な角度から評価をしていきます。そうした分析データを次の計画に生かすことになります。そうした意味ではAはActionというより、Analyzeの方が適当だと思います。

ここで言っているPDCAは企業全体の大きな範囲でのものです。PDCAはもちろんそれだけではなく、様々な領域で存在します。ただ、覚えておいてほしいのは大方の場合、Doはプロセスオペレーションからなりたっていることです。ちょっとしたアクションもあると思いますが、PDCAサイクルという場合はアクションレベルではなくオペレーションレベルの話だからです。

一方で、ビジネスモデルというものがあります。ビジネスモデルというのは、どこの誰に、どんな商材をどの経営資源を使って、どのように提供して、どうやって儲けるかであるから、それをかぶせると次のようになります。
bijinesmoderu.bmp
ある市場のあるお客さんからの要求、Requirementに対して、手持ちのResourcesを使って、サプライチェーンプロセスや収益プロセスを経て応えてあげることになります。要求に対する答えを用意して回答するのがProcessです。こうした機能のそれぞれに価値、すなわち自分たちの強み、他社との差別化要素などを配してビジネスの競争に勝っていくのです。

ところで、PDCAとビジネスモデルでカバー領域が違うのはなぜでしょう。PDCAサイクルではRequirementとかResourcesが、ビジネスモデルでは、PlanやResultがあまり入り込んでいません。これはどういうことなのか考えてみるのもおもしろいと思います。次回にここらあたりの議論をしますのでみなさんも考えてみてください。

2012年9月24日

ビジネス活動にプロセスはどのように入り込んでいるのか - PDCAとビジネスモデル(続き)

前回、PDCAとビジネスモデルのカバー領域が違うという話をしました。つまり、PDCAサイクルではPlan-Process-Resultが、ビジネスモデルでは、Requirement-Resources-Processが主な主なカバー領域でした。まずここで気がつくのは、違うと言いながら共通のところがあります。それはProcessです。だから、プロセスが重要なのだという前にまずはこのProcessのところを考えてみましょう。

PDCAサイクルでいうProcessとビジネスモデルでいうProcessは同じでしょうか。どうも全く同じではなさそうだと思いませんか。ここで、PDCAサイクルのProcessを見てみましょう。DoはPlanに基づいて実行するためのプロセスというイメージになりますよね。計画を実行するという見方です。一方でビジネスモデルではお客さんの要求に応えるためのプロセスになります。

どうもプロセスの起点が違うようです。すなわち、PDCAでは計画ありきというか自分たちの計画を達成するというところから出発しています。ビジネスモデルではお客さんが出発点です。ですから、内部起点プロセスと顧客起点プロセスという違いが出てくるのです。従って、同じProcess でも性格がちょっと違うのです。別に同じプロセスだから分けて考える必要がないという人もいるかもしれませんが、実はプロセスの設計の仕方だとか、案件の扱いだとか相違があるのです。これはまた別の機会に。

こうしてみて気がつくと思うのですが、これまでの業務システムがいかにPDCAサイクルを基本にして作られているかです。少し乱暴な言い方かもしれませんが、Resultをちゃんとマネジできるための仕組みを作ってきたともいえるのではないでしょうか。ERPはまさにPDCAサイクルを回すためのITシステムであったわけです。

だからダメだと言っているわけではぜんぜんなくて、根幹としてはなくてはならないものであるのは言うまでもありません。言いたいのは、逆にビジネスモデルのところのITシステムがちょっとおろそかになっていやしないかということです。いやあ、SFAだとかCRMだとかやっているじゃないかと言われるのだが、プロセスという概念を含めたものになっているでしょうか。まだまだ、リソースマネジメントの域を脱していないような気がします。

それと、PDCAサイクルにおいても従来のようなPlan-Do-Check-Actionという機能的な定義は再検討した方がいいと思う。どういうことかというと、先にどういう意味合いにしたらいいのかを言います。Design-Operation-Control-Analyzeという風な考え方が必要ではないかと言いたいのである。

なぜこんなことを言うのかの一番大きな理由はPlanのことである。長年の実感として「計画」を立てる有効性について疑問があるのだ。計画を立てたのに守られないということもあるのだが、それは守れない計画しか作れないからだと言ったらそれでおしまいである。一生懸命、販売計画や生産計画を作ったとしても、そのとおりにできないことがしばしばで計画の変更を余儀なくさせられる。

特に最近のように目まぐるしく変わる環境変化に追随するのは大変である。ということは、計画がどう実行されたかをチェックして次のアクションに生かすという言い方は似つかわしくないように思うからである。さらにCheckというのは遅いのである。“後の祭り“的なのである。また、Actionという前にちゃんと分析、解析をしないといけない。

ということで、フィードバックループを効かせたような制御系を持った方がよいのではという意味でDesign-Operation-Control-AnalyzeというDOCAを提案したいのである。実はこれはビジネスモデルオペレーションの考え方なのだが、PDCAサイクルの領域においてもこうしたダイナミックでスパイラルアップ的な動作が求められているのが現代の企業なのではないだろうか。ドーカ(DOCA)なな?
  

2012年9月28日

ビジネス活動にプロセスはどのように入り込んでいるのか - PlanとResourcesのプロセス

プロセスというものを考えていくと大きな意味でのPDCAよりもビジネスモデルのほうに入り込んでいるのがわかると思います。それに進んで行く前にPlanとResourcesという二つの領域について考えていきましょう。なぜこうして取り上げるのかというとどうもプロセスになじまないような気がするからである。ただ、ここでいうプロセスというのは日常的な企業活動、ビジネスモデルの実行するためのプロセスという意味です。

要するに「位相」が違うのである。もちろん計画を立てるという意味ではプロセスがあり、リソースを管理するという意味でもプロセスはあります。ただ、計画を作るプロセスは前回にも議論したように日常のビジネス活動の前にあらかじめ立てておくということで時間的なずれがあります。ただ生産計画などは、連続性があると言えばありますが、直接的なビジネス活動でもないのです。こういうと反論されそうですが、つまりお客さんとの関係では希薄だという意味です。

ですから別の時限で計画を立てるプロセスが動いているわけです。それと同じようにリソース管理についても言えて、日常的なビジネス活動ではリソースを使うことであって、その管理プロセスはまた違った「位相」で動くことになります。例えば、新規のビジネスが始まるときにその専門家を雇うといった人材採用プロセスは前もって動いていることになります。逆に、ビジネスのスループットが増えたので設備の増強をしたとなると、そのあとの設備管理は後で発生するといった具合である。

そして、大事なことは計画にしてもリソースにしてもビジネスモデルから導かれたプロセス(後で議論していきます)を円滑にかつ効率的にオペレーションするために存在するのです。つまり、そうしたメインストリームありきなのです。いつも言っている「プロセス先行アプローチ」は厳密に言うとこのプロセスを中心に据え、先行させて考えるということになります。

時々、みかけるのはメインストリームのプロセスがちゃんとしていないのに、やれ販売計画システムだ、需要予測だ、CRMだ、物流システムだといったようにサブプロセスに力を入れることがあります。これらは本末転倒で、ビジネス活動の要諦である顧客の要求獲得から商品提案、オーダー受領、商品ピッキング、輸配送、納品、代金回収といったプロセスをきちんと確立しておくことが先決なのである。

PlanとResourcesという領域はメインストリームのプロセスと位相がずれているという指摘をしましたが、それとともにフロー的な機能よりもストック的な機能が重視される点でも違ってきます。別な言い方をすると「情報(データ)管理」的な色彩が強いとも言えます。ちょっとわかりにくいかもしれませんが、計画もリソースも最終的には情報(データ)という形になります。例えば、予算値、販売計画数とか、人材プロファイルとか設備能力といった情報(データ)を活用することです。

ですから、これらはほぼマスタ管理と同義ということになります。すなわち、データを生成、読み取り、更新、削除するいわゆるCRUDの世界である。ただ、単純なデータベース管理ではなく、プロセス要素が入ったマネジメントが必要であることは言うまでもありません。ということで次回からは、ビジネスモデルからプロセス展開をどうやって行くのかを見ていきます。
 

2012年10月 5日

ビジネス活動にプロセスはどのように入り込んでいるのか - ビジネスモデルもプロセスである

さて、今回からはビジネスプロセスをプロセスに展開していきます。PDCAサイクルよりもビジネスモデルの方にプロセスが入り込んでいるという指摘をしました。それは、ビジネスモデルの構成要素を見ていくと自ずと分かってくると思います。何回も出てきますが、どこの誰に、どんな商材を、どの経営資源を使い、どのように提供して、どうやって儲けるかがビジネスモデルでした。

これらを並べて眺めるとこれもプロセスだと気が付きます。ではビジネスモデルの構成要素が求める機能は何でしょう。まずは、どこの誰にというのは、顧客を獲得して、そのお客さんから注文を受けることが要求機能です。狙った市場と顧客に対して売り込んで、見込み顧客から潜在顧客に持っていって最終的には注文をもらうというものです。

次のどんな商材をというのは、顧客が手に入れたいと思う魅力をもった製品やサービスをどうやって企画・開発するのか、あるいはよそから調達して商品リストとして揃えておくかである。どの経営資源は、プロセスというよりも全体の構成要素、機能に対して供給するリソースを保有しておくということなのでここでは外して考えます。

どのように提供してというのは、サプライチェーンプロセスそのものです。つまり計画・調達・製造・出荷のチェーンである。昨今は、一社で完結するのではなく、よその会社との間で行われる場合も多くなり、さらにグローバルに広がってします。こんな場合はサプライチェーンというよりはビジネスチェーンといった方がよいかもしれません。会社間をまたがったバリューチェーンとなります。

最後のどうやって儲けるかは、お金の流れを中心とした商流ですが、プロセスというよりどういったスキームにするかといったモデル化の方が重要になります。例えば、直販にするのか、代理店をかますのか、本体は安い価格にしておいて保守部品で稼ぐのか、広告収入を主体にするのかといったことである。

時々、これをビジネスモデルという人がいたり、ビジネスモデル特許はこれだみたいなことがあるのですが、ここでの議論では商流モデルとか収益モデルという言い方にします。ですから、ここでのビジネスモデルは最初に言ったような広い範囲を指しています。商流モデルであえてプロセスを持ち出すとすると代金回収、代金支払プロセスがそうですね。また価格決定プロセスも入れたらよいかもしれません。

ということで、ビジネスモデルからの要求機能を記述してそれを簡潔な言葉で表現すると、営業、マーケティング、リソース管理、サプライチェーン、商流モデルとなります。さらにそこからその機能を実現するためのプロセスのイメージがわくと思います。それをこの時点のレベルと粒度で表現すると営業プロセス-商品企画・設計プロセス-調達-製造-出荷-代金回収・支払プロセスとなります。これを「事業プロセス」と呼ぶことにします。呼び方はこだわりませんが、要するに業務機能の関連といったところです。これらを図示したのが下の絵になります。

bijinesumoderutopuroses.bmp

2012年10月12日

ビジネス活動にプロセスはどのように入り込んでいるのか - プロセスの階層

前回は、ビジネスモデルからそれを実行するためのプロセスとそれぞれの関連を見てきました。今回からはさらに個別のプロセスについて議論していくことにします。ただその前にプロセスの階層ということを見ていきましょう。

具体的な例でみた方がわかりやすいので営業プロセスを取り上げてプロセスを分解しながら階層化をみていきましょう。営業プロセスというのは、お客さんに商品を認知させて興味を持ってもらい、買ってもらいように仕向け、注文をもらい契約するまでのプロセスとなります。

起点は顧客の興味それを最終的に売買契約まで持っていて終わることになります。ということでこの営業プロセスをもう少し分解すると、プロモーション、商談、見積、契約といったふうに分解されるでしょう。この段階をどのくらいの粒度で括るかは議論があるかもしれませんが、これでなくてはいけないといった決まりがあるわけではなく、分かりやすいとか、自分の感覚に合っているかといった評価でかまわないと思っています。本当はこれらの他に計画とリソース管理とリターンプロセスがあります。ただ、主たるプロセスではないことと共通的なものですので後で一緒に議論します。

さて、分解されたプロセスに名前をつけなくてはいけません。そこでプロモーション、商談、見積、契約といった流れをハイレベルプロセスと呼ぶことにします。この呼び方はいろいろあって、レベル2とか3とかといった表現をする場合もあります。もちろんどれでなくてはいけないということはありません。

ただ注意しなくてはいけないのが、プロセスという表現の括りがフロー全体を指しているのか、それとも中の要素として入っているプロセスを指しているのかが紛らわしいことです。つまり、ここで言っているハイレベルプロセス(あるいはレベル2とか3プロセスでもかまいません)は、営業プロセス全体のことなのか、それともその中のプロモーションとか商談のプロセスを言っているのかが混乱してしまうということです。

ここでいうところのハイレベルプロセスの場合は、プロモーション-商談-見積-契約という流れを指していて、後で出てきますが、その中のプロモーションや商談のプロセス、すなわちハイレベルプロセスを構成している要素プロセスはローレベルプロセスと呼ぶことにしています。ちなみにローレベルプロセスを構成しているのは「アクティビティ」という呼び方で、さらに、そのアクティビティを動かす「アクション」があるという風に見立てています。

そこをレベル2とか3とかという表現をとるとフロー全体のことだったのか要素のことだったのかが分かりづらいところがあるように思います。ちゃんと理解してしまえば混乱はないのでしょうが、結構どうだったかなあという場面によく出くわすので固有の名前をつけてしまおうということです。

結局、ビジネスモデルがあってそれを実行するものとして事業プロセスがあり、その中にハイレベル、ローレベルのプロセスが階層的に存在し、このローレベルプロセスが実務的な意味の業務プロセスといった言い回しになってきます。実務的な意味というのは日常のオペレーション単位といった感じでしょうか。このようにプロセスの階層を考えていくわけです。階層化の例は下記のようになります。

kaisouka.bmp
  

 



2012年10月23日

ビジネス活動にプロセスはどのように入り込んでいるのか - 営業プロセス

前回はプロセスの階層化と呼び方を議論しました。例として営業プロセスを取り上げたので幾分か営業プロセスの中味が出てきたのでお分かりかもしれませんが、もう一度営業プロセスというものを見ていきます。営業プロセスを分解すると、プロモーション、商談、見積、契約といったものに分解されると考えました。

要するに、お客さんに商品を認知させて興味を持ってもらうというプロモーションプロセス、興味をもったお客さんとコンタクトしながら買ってもらいように仕向ける商談プロセス、買う意思がある、あるいは検討の余地を持ったお客さんに見積を提示する見積プロセス、注文をもらい契約する契約プロセスとなります。

呼び方とか、粒度感で多少の違いがあると思いますがだいたいこんなところになるのではないでしょうか。さらにこれを分解してローレベルプロセスに落としていきます。ここまで来るとかなりの数のプロセスになっていくるので詳述はしません。前回の見積プロセスの例のような感じになります。あまり突っ込まない別の理由は、実際の現場では様々なバリエーションがあるからです。ハイレベルぐらいだとどこの会社でもあるいはどんな業種でも変わりありませんが、ローレベルでは実態にあったプロセスになっていきます。

ですから、モデルは参考にはなりますが現実にはかなり違ったものになります。もう少し正確に言うと、アクティビティそのものの内容が変わるというのではなく、組み合わせとか取捨選択とかいったところが変わってきます。それは、必ずプロセス間の関係があってそこの連動性によっても違ってくることも影響します。

例えば、営業プロセスでいえば、単純には営業プロセスで成約したら、受注・出荷プロセスへ受け渡しますが、そこはどんな場合でも連動していく関係にあります。ところが、それ以前の段階でいうと、プロモーションといっても何もないところから始めるのではなく、商品企画のマーケティング戦略から狙いを定めた顧客を標的にします。ですから、商品企画プロセスから情報を取得することになります。

また、商談あるいは見積の段階にもあると思いますが、見込み顧客に対して商品提案をする場合、商品企画でラインアップされたものを選んだり、設計プロセスで試作された未製品を見せたりすることがあります。単にカタログ品の中から抽出して見積するというケースばかりではありません。むしろ、最近では少なって来ているのではないでしょうか。

プロダクトにサービスを付加した売り方などは、そのサービスの価値を別のプロセスを経て獲得することが行われます。お客さんの要求ごとに応える特注品などや開発サービスのような商材はこうした横断的なプロセスが必要になってくるわけです。ですから、プロセス設計では、実際の営業活動を業務シナリオという形で書き出していくことになります。ボトムアップ的な分析、再設計を行います。

ちょっと、営業プロセスそのものからずれてしまいましたが、下図のようにまずは大きな絵で連携する流れを抑えておくことが大事になります。
  
jigyoupurosesukannrennzu.bmp
 

2012年10月28日

システム開発の失敗

先日あるシステム構築プロジェクトのキックオフでこんな質問をされた。「おっしゃっていることはわかりましたし、成功事例も聞きましたが、もし失敗例があったら教えてください」。さて困った。「まだ失敗例といえるようなものはないのですが、かなり議論になったことはあります」てな言い方でごまかしたのだが、ふと考え込んでしまった。

というのも、失敗とか成功とはいったいどこで線引きするのか、何をもって失敗というのかのことである。特許庁のシステム開発は明らかに失敗というのは分かります。システムができ上がらなかったらそれは失敗でしょうが、できたはいいが使われなかったら失敗なのか、使われなかったのが大部分だったら、あるいは一部だったらどうなのだろうか。システムはまずは損害を与えるということはほとんどないので、役に立ったのがどの程度あったのかが問われる。

しかし、ここのところをよく考えてみるとおかしなことに気づく。役に立たないものをなぜ作るのだろうかということである。役に立つものだけを作り、役に立つことだけすれば失敗することはないからである。だけど、いろいろなところで失敗したという話を聞く。毎度の話かもしれませんが、これだけ役に立たないものを作っても平気でいられるところはシステム開発とハコモノ行政くらいなものかもしれない。

これからの業務システムは失敗のない構築をみながやれるようにならなくてはけない。その処方箋は一番簡単なのは「使う人が作ること」です。使う人が考えるわけですから、当たり前ですが、必ずできてから使えるものにします。使えないようなら作りません。このことになかなか気づかないので、使う人と作る人がいて、使う人が作る人にこんなものがほしいと言い、それを作る人が適当に作るというやり方がずっと続いています。

いや、エンドユーザコンピューティングをやっているところがあるではないかという指摘をする人もいるが、所詮個人の作業効率向上といった範囲ではないでしょうか。組織プレーの場としての業務システムでは上述したような使う人と作る人の乖離がある気がします。ですから、失敗のないシステムづくりと言うのなら、できるだけ使う人が直接作り上げてしまうようなやり方にしないと問題は解決しないと思う。

という意味で、以前から業務システムに“システム開発“という言い方をしているのをやめることを提案したい。システム開発というとどうしてもITの専門家に頼んで新たに開発してもらうというイメージになるが、そんなことをしてもらっても困るというのが心ある業務側の見方なのではないだろうか。ただ、ここのところもユーザサイドではまだ理解が不足しているというのが正直なところで、ITのことだから自分たちには難しいのでお願いしますという考えが残っている。

業務システムは開発するものではありません。業務を任されているユーザの人が、自分が円滑に業務を遂行できるように、また使いやすいように自分自身でシステムを組み上げるというやり方にしていかないといけないと思うのである。それと、継続的に容易に変更ができるようにしておくことも重要である。そうすれば、失敗もないし、たえず業務オペレーションのお役立ちツールとしてITが活用されることになる。

人とITの関係でいうと、クラウドにしてもデバイスにしてもどんどん今言ってきたような方向へと進んでいるように思える。しかしながら、業務システム以外の領域ではこうしたメリットを取り込んでいるのに、業務システムでは表面上はクラウドだとかビッグデータだとか、BYODだとか言っているのだが、肝心の基本的なコンセプトが旧態以前のままでは豚に真珠なのである。
 

2012年11月 2日

ビジネス活動にプロセスはどのように入り込んでいるのか - その他のプロセス

前回営業プロセスを見ていきましたが、その他のプロセスについて考えてみましょう。その他には何があるのかというと、主なところで「商品企画」「設計」「調達」「製造」「受注出荷」があります。他には代金回収・支払とか計画、リターン、リソース管理といったプロセスありますが、ベースとなる重要なものは前者の方になります。

また、「営業」「商品企画」「設計」「調達」「製造」「受注出荷」というコアのプロセスは直列につながっているわけではなく、階層とまではいかないのですが横と縦の関係になります。それが前回示したハイレベルプロセス関連図です。

ところで、その中でメインストリームは何でしょうか。要するにほんとうのコアとなる部分、ビジネス活動の根幹は何だと思いますか。言いかえるとかどんなビジネスでも必ずあるものです。それは、「営業」と「受注・出荷」です。「商品企画」「設計」「調達」「製造」がないビジネスってありますよね。

単に仕入販売だけで製造しない会社もあれば、商品企画がなくて製造だけの下請けみたいな会社もある。ところが、お客さんを見つけてそこに商品を売って、それを届けてお金をもらうというのはどんな会社でも必ずある。ですから、ここがメインストリームなのである。つまり、まずはここをしっかりと築くことが肝要なのである。

日本の会社、特に製造業は、モノづくりということに拘泥しているから、製造というプロセスに思い入れがある。そういった意識は、いいものを作れば売れるという誤解を生じ、高度経済成長時代にはよかったのが減速経済やグローバル化では弊害と化している可能性がある。自ら商品を企画・開発し、顧客や用途の拡大をしていかないと生き残れなくなっている。従って、お客さんを見つけてそこに商品を売って、それを届けてお金をもらうというプロセスに力を入れなくてはいけない。

そうすることで見方も変わってくることもある。例えば、顧客のニーズに合わせるために、何でもかんでも自前で作る必要がないかもしれないし、あるいはサービスという付加価値をつけることによって満足度をさらに上げることができるかもしれないことに気づくはずだ。あるいは、お客さんの要求や場合によってはクレームのようなものも商品企画に生かせるではないかといった気付きもある。

このようにだらだらとプロセスを並べるのではなく、上下、縦横、濃淡といった関係性があることをよく知って、どういった構成にするのかを吟味することが大事なのである。これを構造化という。ただし、ここは業種・業態や社風の違いといった要素でつがってくるので、必ずしも決まった構造があるわけではない。つまり、プロセスの分解・詳細化されればされるほどその会社特有のプロセス構造になる。ということで、このシリーズもこれ以上深く突っ込まないでこのへんで終わりたいと思います。


2012年11月12日

ビジネスモデル・ジェネレーション

ちょっと前に、東京の大きな書店に寄ったら「ビジネスモデルYOU」という本が置いてあった。著者がティム・クラーク、アレックス・オスターワルダー、イヴ・ピニュールとなっていて、「あなた自身をモデル化する」とある。前作「ビジネスモデル・ジェネレーション」を個人に応用したものである。今から、そのビジネスモデル・ジェネレーションについて考えてみたい。

そもそも、ビジネスモデルという言葉もあいまいなところがある。多くは収益モデルを表すことが多い。古くはプリンターのトナーモデルとか、最近では携帯ゲーム、アフィリエイト、はたまたAKB48といったイメージである。それよりももう少しビジネス活動全体を表現したほうがよいと思っている。その点では、このビジネスモデル・ジェネレーションはよくできている。

かいつまんでどんなものかを紹介すると、肝はビジネスモデル・キャンバスという下図のようなテンプレートに従って記述するとモデルができてしまうということのようです。

BIJINESUMODRU.bmp
 

顧客セグメントCustomer Segment)、提供する価値(Value Proposition)、チャネル(Channels)、顧客との関係(Customer Relation)、収入の流れ( Revenues)、主なリソース(Key Resource)、主な活動(Key Activity)、パートナー(Key Partner)、コスト(Costs)9つの構成要素から成立っている。

ぼくもずっと前からビジネスモデルを定義しているからすごくよくわかるし、最初に言ったようによくできていると思う。しかし、少なからず違和感というか不十分さを感じるのだ。その問題点を下記に示す。

① 構成要素の過不足
9つの要素のうちで同じようなことを言っているものとして、パートナーというのはリソースのひとつであるし、収入の流れとコストは収益モデルとしてくくれるような気がする。一方、抜けているのが商材である。コンテンツだけなのか、サービスも含めているのかといったことである。どういうコンセプトなのかも重要であると思う。

② 価値の同列化
図の真ん中に提供する価値を置いているが、ほかの要素と一緒にすべきなのだろうか。この図を書く意味はなんなのだろうかと考えたときに、ビジネスモデルの各要素を記述・分析していくうちに、そのモデルの持つ価値が浮かび上がってくることだと思う。つまり、他社と差別化できる、競争優位を保てるための価値を規定したいからこそキャンバスに書いて眺めたいのです。ですから、まずは価値を除いたところで記述して、その分析と評価結果から提供価値を定義するのではないでしょうか。つまり位相を変える必要がある。

③ ビジネスモデルをどうやって実行するのか
最後に、非常に重要なこととして、ビジネスモデルを書いたあとそれをどう実行するかにつなげていかなくてはいけない。ビジネスモデルが書けましたで終わりではないのです。コンサルタントはそれでもよいかもしれませんが、生でビジネスをやっている人にとっては、それが終点でもなんでもないのです。いくら立派なモデルが書けてもそれが実行できなくては何もならないのです。そういう意味で、このモデルでは実行系に落とし込めないという問題があります。

これまで数多くの戦略論やモデルが提示されていて、それをコンサルティングと称して分析してみるのですが、どうもそれが目的化してしまい、立派な戦略やモデルを作ったはいいが、実際に生かされているかという点では不十分であると思うのです。ということで3点の問題を提起しました。ではその問題を解決するにはどうしたらよいかはまた次回に書いてみようと思います。
  

2013年1月19日

システム開発の海外比較(1)

よくこのシステム開発のやり方はおかしいとかいう意見を聞くことがあるが、それでは海外ではどんなやり方でやっているのだろうかという疑問が湧いてくる。日本がダメでアメリカがいいということではなく、どんな違いがあるのかは興味があるところではある。そんな折、ITProに「ここがヘンだよ日本のシステム開発」と題して日経SYSTEMSの記者が連載しているのでそれに関して一緒に考えてみたい。

日本のシステム開発の現場で働く外国人エンジニアの目を通してそうした違いについて取材した結果をもとに解説している。その切り口を「ベンダーとユーザーの関係」「開発手法」「ITエンジニア像(姿勢)」という面で捉えている。要するに、この三つが代表的な違和が生じていることなのだろう。確かにそうかもしれないなと思う。

「ベンダーとユーザーの関係」ではITエンジニアがユーザーから一方的に文句を言われる立場にあると映っているようだ。ユーザーの声に耳を傾けるのはいいがそれが過度に聞きすぎてはいないということだが、これは3ツ目の「ITエンジニア像(姿勢)」にも関係するかもしれないが、自分たちは業務を知らないから文句言えないので聞くしかないとか、偏屈な"お客様は神様"的根性があるのだろう。

「開発方法」については、一律にウォーターフォールで作ることが上がっている。外国人エンジニアは「ウォーターフォールはハードウエアのように、一度作ったら終わりの場合に向く開発手法だ。ソフトウエアは改良して使い続けることが多いので、システム開発に安易にその手法を採用するのは違和感がある」と話している。ここは重要な視点ですが、ぼくがちょっと驚いたのはまだまだウォーターフォールが主流なんですね。

ただ、それが故に品質の高さを担保しているのわけなのだが、現代のシステム開発では、そうした品質よりも早く開発して、それをどんどん改善していくというやり方で品質を上げていくほうがかなっているように思う。ぼくはいまBPMのアプローチを推奨しているが、その特徴も実は継続的な改善を指向している。この記事にもこんなことが書いてあった。

かつて、システム化といえばきっちりとプロセスが決まっている業務を自動化することだった。しかし現在では、より良いと思われる業務プロセスを新たに作り出し、それがスムーズに流れるように支援するシステムを作るケースの方が圧倒的に多い。後者の場合は初期段階で要件を確定できず、稼働後も改善を繰り返すことが多いので、ウォーターフォールで取り組むと無理が生じやすいのは明らかだろう。

最後の「ITエンジニア像(姿勢)」では、日本のITエンジニアは実績最優先で製品や技術を選ぶ傾向にあるという指摘だ。確かに新しい製品や技術を選ぶにはそれなりの勉強もしなくてはいけないし、リスクもあることから避ける傾向は見て取れるのだが、おそらくそれは業務系というか基幹システム系の領域だろうと思う。Web系では日本の技術者もどんどん進取の精神でやっていると思う。だから、機能とリスクのトレードオフみたいなものだから。そこをどう折り合うかの工夫をもっとすべきだと思う。

ここはまではまだ概観だが、刻々と世界は変化しているのに日本の業務系システムのエンジニアたちの変化への追随性はいいか悪いかの前に遅れていると言わざるを得ないようだ。次回からは、個別にもう少し詳しく見ているのでそれについて考えてみます。

2013年1月24日

システム開発の海外比較(2)

前回は日本のシステム開発のヘンなところということで、「ベンダーとユーザーの関係」「開発手法」「ITエンジニア像(姿勢)」の断面から考えようということから概観したが今回からは個別のところに焦点をあてて検討してみる。

最初は、「ベンダーとユーザーの関係」についてである。外国人エンジニアに聞くと多くのひとが「日本のITエンジニアは"がんじがらめ"になっている」と指摘するそうだ。

どういうことかというとまずは日本ではシステム部門がベンダーと利用部門の間に入って、プロジェクトを主導したり、調整したりすることが多いのだが、海外ではベンダーとシステム部門が1対1の関係で進める。日本のように、プロジェクトに利用部門が入って、トライアングルの体制になるのは珍しいのだという。

要するに利用部門が入り込まないようにするのである。ちょっと驚くかもしれない。日本ではユーザーの要求をよく聞いてやるのが当たり前というか、そうしなくてはいけないと思われているからである。

また、こんな指摘もある。販売管理システム構築を担当した際、仕様通りに作ったにもかかわらず、利用部門から「欲しいのはこんなものではない」と言われ、大幅な作り直しを求められたと打ち明ける。「一方的な非難に納得がいかず、工数に見合うコスト負担と納期のリセットが必要と主張しようとしたが、争いを避けるために日本人の上司から止められた」という。

つまり、利用部門の言うことをどの程度聞くのか聞かないのかに差があるようだ。これを単純に比較してもいけなくて、仕事のやりかたとシステム部門の役割とステータスという前提が違うことに留意しなくてはいけない。日本と海外の会社での仕事のやり方というか、働いている人たちの"マニュアル度"の違いがある。つまり、海外ではJob Descriptionがしっかりあって、ワーカーはそれに従って職務遂行を行うわけで、CIOとシステム部門がこうしろと言って作り上げることができるのだ。

それに比して日本のワーカーは必ずしも職務分掌通りというより工夫をいっぱいする。だから、システムに対する要求も当然多くなる。これがいいのか悪いのか難しく、ユーザ要求に忠実に答えるというメリットもあるが、属人的になる弊害もある。そんなことでシステム部門は業務を知らないからという理由でベンダーとの橋渡し役につけないのだ。利用部門からの「欲しいのはこんなものではない」と言われるのも仕様を決めた人と現場のオペレーション責任者は違ったりするからで、しかも属人的要素があるので真のキーマンを見つけられないとそんなことが起こるのである。

また、日本の多重下請け構造の開発体制も、日本のITエンジニアはがんじがらめになっていると見られている。下位層のベンダーは、元請けから決められた開発手法や開発標準、開発ツールを用いて作業を強いられるから、エンジニアの優れたアイデアが押さえ込まれたりするのからである。さらに米国などでは、「CIOやシステム部門が仕様をすべて決め、基本的に内製する。ただし、合理性を高めるためにプロジジェクトマネジメントの専門家や専門エン ジニアを一時的に雇うこともある」体制なので、ITエンジニアのアイデアが押さえられることはないのだという。

ここらあたりは構造的な問題が大きい。CIOやシステム部門が仕様をすべて決め、基本的に内製するやり方に対して、この部分をSIerに丸投げしている日本の姿との差が浮かぶだろう。やはり、日本のSIerの存在は日本特有のようだ。これは、これまではよかったかもしれないが、今日のように変化が激しく、新たな技術や製品が次々と生まれているITの領域ではデメリットの方が大きいといえる。しかし、マニュアル通りに働く文化にはない場合は、ユーザの役割や意識を変えるのも難しいので、「利用部門が仕様をすべて決め、基本的に内製するやり方」ができると一番よいのだ。
 

2013年2月 1日

システム開発の海外比較(3)

さて、今回は開発手法の違いについてである。単純化していうとアジャイル開発がどの程度進んでいるのかということである。調査結果がある。情報処理推進機構(IPA)が2012年6月に公開した「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」によると、米国や英国では非ウォーターフォール型開発の普及度が高く、逆に日本や中国では低いことが判明した。非ウォーターフォール型開発とはアジャイル開発など、短いサイクルで反復的に開発を進める手法のことである。

ただ、非ウォーターフォール型開発がよくてウォーターフォール型開発はもう時代遅れであるとは一概には言えない。それは適用するシステムの性格によって適不適があるからである。日本で働く外国人エンジニアの意見として「ウォーターフォールモデルが合うかどうかは、ものによると思うよ。ウォーターフォールモデルは、ドキュメントと計画を重視して、 1回仕様を決めたら、それを変化させずに最後まで突き進むスタイル。だから、きっちりとプロセスが決まっている業務を自動化する場合にはうまくいく。1回 作ったら、それを数年にわたりそのまま使い続けるハードウエアの開発にも最適だと思う。逆に、開発期間中や開発後に次々に変化が生じるシステムの開発には 向かない面がある。」というのがあってその通りだと思う。

だから、バックヤードの定型的な業務システムとか、開発側で仕様を決めて作るソフトウエアといったものに対してはウォーターフォールモデルでやればよいのだが、なかなか仕様が決まらないものに対しては、途中の変更を前提としたアジャイル型の方が合っている。ドキュメントにしても、ウォーターフォール型だと仕様書をたくさん書いてその通りに作ろうとするが、アジャイルではほとんど書かないのだ。

最近日本でも開発対象のプロセスは顧客要求ベースのところが多くなってきて、そうした領域ではきっちりと仕様が固まることがないから、アジャイル的なアプローチが有効なのに普及が遅れている。米国でアジャイル開発が普及しているのに、日本では普及していない理由は次の三つを上げている。

①ソフトウエアを内製せず、ベンダーに依頼する外注比率が高いこと。
②ITエンジニアの流動性が低いこと
③産学連携による実践教育が盛んではないこと

ちょっとつながりがわかりにくい面があるかもしれないが、日本のようにシステム開発を外注すると利用側と開発側の距離が離れるのでやりにくということである。ITエンジニアの流動性では、離職率が日本10.7%、米国32.1%と大きく違うのだが、人が動かないと新しい技術の伝播がしにくいのだという。最後の産学連携は、これに限ったことではなく、大学教育で開発手法などを学ばずにIT会社に就職してエンジニアになるケースが多く、従って従来のやり方を踏襲するので新しい技術に向かわないのである。

こうして見ると、何もIT業界だけの問題ではなく、日本の産業界全体の問題であることがわかる。製造業のものづくりにしてももはや決まりきった汎用品を仕様書通りに作っていれば売れた時代から、顧客ニーズに的確・迅速に対応していかなくてはいけない時代へと変わっている。そうした環境変化に対して、開発・製造のやり方も適応させていかなくてはいけない。

何でも米国がよいと言っているわけではなく、アジャイル開発とか、リーンスタートアップといった手法を日本の良さ、例えばチームワークや真面目さといったものを取り込んで日本らしいものにカスタマイズすればよいと思うのだが、いかがなものだろうか。


2013年2月15日

新しい生産管理システムを

先日ある協議会の勉強会で生産管理システムの紹介をしたいので聞いてくれませんかというので出かけていった。中堅・中小企業向けのパッケージとExcelを利用したテンプレートの説明があり、そのあと議論した。中小企業向けの生産管理のパッケージとかソフトウエは意外と少ないのである。その理由は高額なものはダメだし、とはいっても中小といっても生産管理は簡単ではなくほどほどに複雑だからである。

ということで、大手SIerは手を出さないし、他のITベンダーにしても売上・利益が少ないからあまりやりたがらない。しかし、これからの日本の製造業は中小企業に頑張ってもらわなければいけなくなってきている。その時にIT化は欠かせない。だからこの手のユーザに生産管理システムを安価に提供するというのは、非常に大事なことなのであるが、従来型のシステムをコンパクトにして、あるいは同じようなものを汎用ソフトを利用して安上がりにといったアプローチはいかがなものだろうか。

視点を変える必要があるように思う。その理由は大きく2つあって、まずは中小製造業のビジネスモデルが変わってきているということである。いま、こうした中小の製造業は生き残りに向かってすごいことになっている。従来の延長では座して死を待つことになる。これまで多くの企業がやってきたことを中国やタイ、ベトナムでやりだしているわけで、安価な労働力の前では太刀打ちできないのはご承知のとおりである。

大企業の下請けとして言われたものを質を保ち確実に製造、提供していれば安穏としていられたのが、元請自体も海外へ出ていくし、下請け業務は中国や東南アジアの企業に取って代わられているなかで、どうやってサバイバルしていくかという大きな課題を突きつけられている。そうなると、見込み生産・受注生産から受注設計生産・受注開発生産というようなシフトが起きるのは当然の流れである。

だから重要になるのは、顧客の要求をいかに的確に把握して、その要求に応えてあげるかである。そこでは営業と設計・開発部門の密な連携が必須となる。ところが、営業部門を持たない中小製造業というのも珍しくはない。元請けからの注文さえ聞いておればよかったから営業機能は要らなかったのである。従って、当然IT化なんてできているはずもなく、技術者が直接足を運んで注文をもらってくるというやり方になる。

このことは、システムが追求すべき目的が変化したことを意味する。つまり、見込み生産や受注生産型の場合は早く安くという効率性が大事であるが、受注設計・受注開発型になると顧客満足度が勝負となる。ですから、明らかに焦点が変わってきているのである。こうした変化に生産管理システムは対応できていないように思える。

もう1点は、システムの形態のようなことに関してである。いったいどんなものを中小製造業ユーザに提供したらよいのかということである。おそらくこの時代ではスクラッチでコーディングして開発しますというのはありえないから、パッケージ、フレームワーク、テンプレートといったものなのか、開発ツール、システム構築用ソフトウエアなのかといったものが考えられる。

意外とこのあたりははっきりしていなくて、上の組み合わせみたいなものもある。Excelを使ってテンプレートみたいなものがあって、それをVBAを使ってカスタマイズするなんて例もある。生産管理は、千差万別でパッケージを持ってきてそのまま使えるかというと難しいので、フレームワークを持ってきてカスタマイズ前提でやったほうがいいなんて言う製品もある。ただ中小企業というターゲットを持ってきたときには、システム要員がいない、使う人のリレラシーもそう高くはない、属人的な動きが多いなどのため、簡単に作れて自由度もかなりあるといったシステム構築用ソフトウエアがよいと思う。

ビジネスモデルの変化、中小企業特有のシステム対応能力を勘案した新しい生産管理システムが望まれると思うのだが、具体的にはまだなく正直難しいのであるが挑戦しがいがあるように思える。なぜなら、確実に中国や東南アジアでそのうち必要となるシステムだからである。
  

2013年3月20日

SEって何?(1)

年明けからITProに馬場史郎さんが「SEマネージャーよ逞しくなれ!」というタイトルで毎月記事を書いている。最初のサブタイトルが「日本のSEはこれで良いのか」で次が「なぜ、体制図や人月の提示と技術偏重の風潮が変わらないのか」、3回目の今月が「SEが変わればIT企業のビジネスが伸びる」というものである。馬場史郎さんといえば泣く子も黙るSEのカリスマですが、かなりの違和感を抱いたのでそのことについて少し書いてみようと思う。

▐ SEが抱える問題とは?
ご存知のようにSE(システムエンジニア)というのは和製英語で海外では使われていません。ということは、日本特有の職種でもあるわけです。おそらく、ハードウエア主体の時にそのマシンを使いこなすために技術者を張り付かせたところからではないかと思う。ですから、お客さんがどんなことをしたいかを聞きだし(実態はこんなことができますからやりましょうよと言ったのではないでしょうか)、それをプログラム開発のための仕様を書くことが主な仕事だったようだ。

その後、多重下請け構造化していく中で、そうした外注を管理することまでやるようになった。また、ネットワーク化とかそれに伴うセキュリティ管理といったインフラ系もカバーすることにもなってきて、ずいぶんと範囲も広がってきた。それと急速にIT技術の進化があり、それを取り込むことに汲々となる場面も増えてきたのである。ただ、基本的には、顧客のシステム化の要求に対してどういうソリューションがよいのかを選定し、プロジェクトを起こし、実際に動かすまでをサポートするのが仕事になっている。

そんなSEたちの現在の状況を馬場さんは次のように言っている。

日本の多くのSEは、IT技術に偏重気味でビジネス意識に乏しく視野が狭い。また、仕事に対して受身で営業や顧客などと壁を作りがちだ。そして、往々にし「営業は無理ばかり言う。IT技術も知らない。だからSEは困っている。会社はSEを分かっていない」などと言ってフラストレーションをためている。程度の差はあってもどこのIT企業のSEも大体こんな状況であろう。

そして、このことはずっと以前から変わらない問題でいっこうに解決できてないという。むしろ昔より悪くなっているとも指摘する。SEがいろいろな問題を抱えているうちは、情報化の進化やIT企業の発展・成長はないのではとも言っている。確かに状況としてはそうなのかもしれないのだが、これを嘆いているだけでよいのだろうかというのがそもそもの疑問なのである。

なぜか。まずは何十年も同じ問題を抱えていても解決できていないということは状況認識とか問題設定が間違っているのではないでしょうか。ITの世界は時間軸、空間軸からみてもものすごい勢いで変化しています。また同様にビジネスの世界も激しく動いています。つまり、取り巻く環境が以前とは全くと言っていいほど違うわけです。何を言いたいかというと環境が変化しているのに問題認識が変わらないということ自体がおかしいと思うのです。環境が変わるということは価値観も変わるわけで悪かったものが良くなったり、その逆もあるからである。
 

2013年3月26日

SEって何?(2)

▐ 問題の背景?
前回、SEの現況について議論したが、SEの多くが技術偏重や受身の仕事のやり方、ビジネス意識が薄く視野も狭いといった状況に陥っている背景にある問題について、馬場史郎さんは3つあげている。

(1) SEの世界の「技術をよく知っている、IT技術に強いSEは優秀だ」という風潮
(2) IT業界の「顧客へのSE体制図の提示や人月の提示、常駐」など人売り的とも言えるビジネスのやり方
(3) IT企業の「売るのは営業、システム開発や保守などを行うのがSE」という風潮

なのだそうだ。そして、こうしたSEの問題の背景にある因習的な風潮やIT企業のビジネスのやり方にメスを入れる必要があると論じている。これが根っこの問題だとも言う。これって本当だろうか。みなさんどう思われますか。

ぼくが感じた大きな違和感は2つあって、ひとつが「顧客視点の欠如」で、もうひとつがきつい言い方になるが「時代錯誤」ということである。あとの方は「SEのシーズと顧客ニーズのミスマッチ」という言い方にもなるが、その意味はどういうことかというと、企業システムとしてのコンピュータやITの役割は当然変化しているわけで、30年前は経理計算が主役だったかもしれないが、現代ではそんなことがほぼどこの企業もやられていて、主戦場は違うところになっている。そうであったら、当たり前だがSEの使命も当然変わらなくてはいけない。なのに、30年前からずっと同じ物差しでいいの悪いのと論じることがおかしいと思うのである。

では、まずは「顧客視点の欠如」について考えてみましょう。上にあげた3つの問題についてですが、異論はないだろうとおっしゃるのだが、お客さんから見たら"どうでもいいこと"なのではないでしょうか。顧客にとっては、誰がどうやろうとも必要なものを適切に提供してもらえばいいだけの話でしょう。こうした「サービス」を提供できていないことが根っこだと思う。日本人だからかどうか知らないが、内部に問題を設定することが多いように感じる。

ちょっと飛躍するのだが、柔道のパワハラ問題やかつても大相撲もそうだが内向き志向の問題設定と解決策選定をしがちである。このような傾向がSEの問題についても言えるのではないでしょうか。つまり、自分たちが何とかすればいいという視点になっていて、外部の人がどういう目でみているのかまでいかない。その自分たちの問題が顧客にとってどういう問題を引き起こしているのか、そうではないのかといった検討が必要であろう。

さらに飛躍するかもしれないが、日本のものづくりにも通じる話で、すなわち、いいものを作れば売れるはずだ、お客さんも喜ぶはずだというやつである。ビジネスの基本は、顧客の要求ありきであり、そのお客さんに満足してもらえるサービスを提供することなのである。ものを作ることがビジネスではない。

前述したようにめまぐるしく変化するビジネス環境に対応したITや情報システムを提供することが求められているわけで、もはや避けられないグローバル化も含めて日々刻々とユーザ要求、ビジネス要求も変化していっている。従って、それに応えられるSEが要望されているが、そのSE像も当然変わってきているのである。昔のようにコンピュータに慣れていないリテラシーの低いユーザに対する場合と今のように個人の生活でもITを駆使するようなユーザがいるような時代では自ずと求められるSEも違うはずである。
 

2013年4月 2日

SEって何?(3)

▐ ユーザはとっくに気がついている

前回「顧客志向の欠如」ということについて書いた。SEの抱える問題にお客さん側から見た視点というものがないのにちょっと驚いたのである。自分の好きなものを作っているわけではなく、ビジネスとして顧客に対しているのだから、一方的に自分たち側だけの内部問題をどうのこうのといっても始まらない。

そのユーザというか顧客が30年前とは全然変化してしまっている。変わったのは顧客を取り巻くビジネス環境であり、ビジネスのスピードとリーチ(グローバル化といったようなバリューチェンの拡がりなど)だし、IT技術やITインフラ、そして企業員のリテラシーといったところである。そうした変化は何をもたらすかというと「業務システム」に対するビジネスとして欲する要求が変わってきているということを意味している。

企業は勝つか負けるか、生き残りをかけて日々戦いをしているのだ。それも現代では、ちょっと間違った判断をしてしまったりとか、ちょっと遅かったりしたらたちまち競争から脱落してしまう。おそらく、生き残っている優れた会社はITをうまく活用しているはずである。ただ間違っては困るのは、IT活用をうまくすれば生き残るのではないですよ。よく、ITを導入すると生き残れますよみたいなセールストークをする人がいますが、そう簡単にいくものではありません。

それと、IT活用といっても立派な高額システムを導入しているとは限りません。効果的な一部のところとか、身の丈にあったものといったように、あくまでビジネスモデル、ビジネスプロセスが主体でそこで有効に機能する範囲とレベルのITを入れるという考え方であるはずです。これが普通の企業活動の姿です。

高度経済成長期では、ファッションのようにITシステムを導入して、それが半分は使われないものであっても平気でした。ところが、バブル崩壊を経てもはや大きな成長を望めない成熟期に入った日本企業は、そんな無駄な投資は許されなくなっています。ですから、心ある経営者は必死に自分たちのビジネスモデル、ビジネスプロセスに最も効果的なITシステムは何かを考えています。

何を言いたいかというと、ユーザー企業側はSIerがこういうビジネスをしなくていけないだとか、SEがこう変わらなくてはいけないなんてどうでもよくて、生き残れるためのITシステム導入ができればSEであろうが、学生だろうが、クラウドであろうが、フィットしたソリューションを提供してくれさえすればよいのだ。

それと、ITの有効性とその適用範囲・レベルを理解できないような企業にIT化を促してもしょうがないのです。昔は、コンピュータの使い方そのものがなかなか浸透していなかったのである程度の啓蒙的なセールスは必要だったかもしれない。(これがSEの仕事だった)ところが、現代ではそんな悠長なことは言ってられなくてITをうまく活用できないような会社は早晩潰れるだけなのである。つまり、真にビジネスに貢献できるITしか目がいかないようになっているのである。あたり前の市場原理である。

つまり、SEの多くが技術偏重や受身の仕事のやり方、ビジネス意識が薄く視野も狭いといった問題をクリアーしても顧客が満足するものを提供できなかったら何の意味もない。だから、ユーザー要求から考えてSEはどうあるべきかという議論に落とし込めないと見離されるだけである。企業は賢いですよ。今のIT業界なんて頼りになんてしていません。IT業界を頼りにしているような企業は潰れてしまうからです。
 


2013年4月10日

SEって何?(4)

▐ システム化のねらいどころが変わった

前回、前々回と、違和感ということで「顧客志向の欠如」という指摘をして、お客さんを意識した見方をする必要があるという話をした。今回は、もうひとつの「時代錯誤」という点について考えてましょう。「顧客志向の欠如」というころでも顧客ニーズが時代とともに変化しているといった似たような話が出てきたかと思います。ここでは、システム化のねらいどころが変わってきていることについて論じることにします。

「時代錯誤」を別の言い方をすると「SEのシーズと顧客ニーズのミスマッチ」ということになります。すなわち、お客さんの望むものが昔と変わってきているのに相変わらず昔のSE像を引っ張り出しているということである。いや、SE自らが変われと言っていると反論がきそうですが、どうも表面的なところであって本質的にはSEという枠からは出ていないのである。

ユーザがシステム化したいことに対して、今のSEが持っているスキルにギャップがあるのではないかという指摘である。そこの議論に入る前にちょっと考えていただきたいことがある。ユーザはいったい何をしたいのだろうか。IT化なのだろうか、システム化なのだろうか、それともITシステム化なのだろうか。それぞれ微妙に違いそうですね。ここでは、企業内にある業務プロセスあるいは作業に対してITおよびITシステムを必要な部分に適用してシステムを作ることとします。つまり、人手もあるしITでの自動化もあるしという組み合わせシステムである。

この定義を頭に入れて、企業システムの変化を見ていきましょう。2回目にもちょっと触れましたが、初期の目的は文字通り電子計算機でした。学術的な使い方を別にすれば、経理計算が主体でした。昔は、経理部電算課なんて組織もあったように会計処理のための計算機でした。それまでのそろばんでの計算からコンピュータに移行したわけです。これは、むちゃくちゃ効率化に寄与しています。

おそらく今日の企業でそろばんでやっているところはないでしょう。このように人間が行っていた定型的な処理はどんどん置き換わっていきました。それらを統合的に管理しようということでERPも登場してきたわけです。こうした過程ではSEという職種はそれなりに機能してIT化に貢献したのではないでしょうか。

ところが、その領域、すなわち計算処理を中心とした定型業務のIT化は徐々に減ってきています。パッケージも多く登場して、起業してもクラウドのパッケージをすぐ使える環境になっています。SEなんて要らないわけです。では、今日のユーザは何がしたいのでしょうか。IT活用を検討したい領域は、ERPと顧客(広義の意味で、サプライヤーとかも含めて)を結ぶ業務プロセスのところではないでしょうか。顧客の要求に応えてサービスを提供して、対価をもらってそれが売上になってERPに登録するまでのこのサービス供給のところです。単にデータを登録して集計処理するようなERPにビジネス要求は入らないし、Webサイトをきれいに作るだけでは顧客を満足させることができないからです。

実はここのところは非定型のアドホックな業務でプロセスから成り立っています。ユーザはそこに他社との差別化要素を盛り込んだりしたいのです。競合より早く回答するとか、顧客満足度を高めようとかいった工夫を入れるのです。そこでは単に計算機的に自動化してやるわけにはいきません。ですから、もしそこにSEが入り込むとすると従来と違ったスキルが必要になるわけです。

違うスキルを持つことになるとそれはもはやSEとは呼べないものになるでしょう。それよりもそういった転換が可能なのでしょうか。そもそも「顧客志向の欠如」という指摘をしたわけですから、顧客志向を持たないSEが顧客志向の業務プロセスのシステム化ができるわけがありません。
 


2013年5月12日

エンタープライズSNSは成功するか?

企業にソーシャルネットワークシステム(SNS)を入れる動きが急だ。あのIBMもエンタープライズソーシャルウエアなるものを出している。はたして、個人の生活に入り込んだように会社の中にも浸透するのであろうか。

その成功のキモというのがあって
① 社員自身による情報発信の促進
② 社員・ナレッジの自然な可視化
③ ナレッジの流通スピードの加速化

ということだそうだ。どうもいつか来た道のような気がする。もう10年以上前にもナレッジマネジメントというものがあった。しかし、あれから各企業に浸透したかというとあまりそういった話は聞かない。ぼくも、その当時あるNTT系のシステム開発会社が盛んにやっていておもしろいから見に行ったらと言われて、教えてもらったことがあった。

その会社は開発会社だから、システムエンジニアに対して、自分のもつ知識やノウハウを開示する仕組みを作った。しかし、そこでただあなたの知識を出してよといっても出てこないのでそこの工夫がいるということで確かポイントを付けるようにしていたと思う。つまり、誰かに利用してもらうとポイントがたまる仕掛けだ。そのポントをどうしたかは失念したが、何らかのインセンティブを与えないと機能しない。

さて、社員自身による情報発信の促進という場合、みんなつぶやいてくれと言うのだそうだが、それらの情報を集めてみんなで共有するという。どうも、TwitterやFacebookを想定しているようで、ただああいったタイムライン的にばんばん流すのではなく、ストック情報も対象にするというところが違うのだそうだ。

これで、みなさんつぶやくのだろうか。"いいね"をもらえるのがモチベーションになるのだろうか。あのひとはよく知っていると言われるのがうれしくて知識やノウハウを出すのだろうか。もし、そんなことでうまくいくようならとっくに浸透して使いこなしているはずだ。まずは、日本の会社で普通は自分のノウハウを出すわけがないでしょう。だって、みんなに教えたとたんに自分の地位があぶなくなるんですよ。そことの戦いなのです。

今の社会は、特にネットの出現でオープンになったといっても既成の会社の中でそれだけそれが実現できているのだろうか。ですから、何らかの工夫をしなくては浸透しない。ひとつは、人事評価と結びつけることがある。会社人間なんて所詮自分の給料に跳ね返ることに一生懸命になるのだ。しかし、これも人事評価となると、どれだけ業績に貢献したかをつぶやきで判断できるだろうか。難しいところである。

もう一つは、以前から何回も言っているように、日常の業務オペレーションの中で自然と知識やノウハウが引き出されて、それが業務というか案件の成果に結びついた時に正当に評価することではないでしょうか。「社員・ナレッジの自然な可視化」と言っていますが、単に各人のナレッジを見えるようにするのではなく、自然に引き出せる場を提供してあげないと意味がないということである。ナレッジは、あれば価値があるのではなくどこでどう使われたかが大事なのである。

まだ、ここでも目的と手段の混同が起きていて、情報を発信することが目的でもなんでもない。エンタープライズにSNSを入れる目的は何かをよく考える必要がある。それは、より円滑なコラボレーションによるチーム力の向上ということもあるが、もっと突っ込んで組織の構成員一人ひとりが小さくてもいいから日々成長していけるということだと思うのである。今のソーシャルSNSはそうした使い方を目指しているのだろうか。
  

2013年6月17日

つながる経済における実践とは(3)

■ デジタル情報革命

つながる経済の背景にはデジタル情報革命があったからというのがあります。この章では、そうしたデジタル情報革命とはいったいどういうことなのかを解説しています。ですから、実践というよりかは、革命の本質とか企業システムに与える影響とかを見ていくことにします。第3章のポイントは次のとおりです。

(1) デジタル技術は情報を媒体のしばりから解放することで、モノの経済原理からも解放する。結果として複製費用が小さくなり、結合することで、価値が増大するネットワーク外部性の特徴が表面に現れる
(2) 多くの知が結合すると、単なる総和を超えた新しい価値が生まれる創発現象が起こる

アナログとの対比で言えば、アナログは媒体(紙とレコード、CDとか)の形状として記録されてきたため、媒体の形が変化すると変わってしまいます。つまり媒体に依存するから媒体が劣化したら情報も劣化してしまいます。ところがデジタルは媒体とは関係なしに同じ品質を保ちます。このことは、情報の複製や転送にコストがかからないことを意味します。

そこでさまざまな主体が膨大な情報を発信し出したのです。そしてそれらがクラウド上にどんどん蓄積されたてきました。ここではそうした量の増大もさることながら、情報がつながることに注目しています。今流行のビッグデータというのも単なる大量のデータという意味ではなく、情報が組み合わさることによって意味が深まるのです。

ここで聞き慣れない「ネットワークの外部性」という言葉が出てきますが、これは「顧客が増えるほど、つながり数が指数的に増大する現象」のことで、このことは友達の友達は友達だといったSNSの広がりを見れば明らかだと思います。この辺りはソーシャルな感じですよね。それと、これも単純な拡大ではなくて、異質なものがつながることによる拡大も大きな特徴です。

このことが、新しい価値を生み出す創発という現象が起きてくるわけです。単な総和以上の特性をもつものである。著者は「多様な個が相互作用しているうちに、共鳴現象が起こって、予期しない大きな結果が生まれること」という見方をしています。何やらサッカー日本代表みたい(違うかスペイン代表か)ですね。

さて、こうしたデジタル情報革命は企業システムにどういうインパクトを与えるのでしょうか。いつもITについては2つの側面から考える必要があります。ITを使う側への影響とITを提供する側への影響です。使う側すなわちユーザ企業にとって、ビジネスの性格が変わってきています。産業構造そのものが変化しています。先述のように情報と媒体が一体だった時代から、それらが切り離されてしまった現代では様変わりしています。音楽はレコードやCDではなくダウンロードして聞く時代になったわけです。

また、広告のモデルも随分と変わってきています。いまやつながりを意識した、あるいは活用して、商品を認知するようになっています。ビジネスモデルが特に顧客接点のところで大きく変革されたのです。このことに気がつかないで相変わらず閉じた自社の内部プロセスをIT化しても効果が薄いのです。

一方、供給する側すなわちITベンダーやSIerはデジタル情報革命をどううまく取り入れてシステムづくりをしているのでしょうか。もやは、ハードウエアを売ることが重要だと考えているところはないと思いますが、今現れてきているクラウドとかビックデータを表層的な捉え方ではなく、本質的な変化をきちんと理解して対応していかなくてはいけません。そして、システムを作るにしても、これまた自社だけの閉じた世界でやるのではなく、多くの外部の知を利用する、あるいはコラボレーションすることも大事になってきているのです。

要するに、ITシステムを使う側も作る側もこうした変化を捉えて対処しないと真にビジネスに貢献できるものは生まれてこないという不幸を引きずることになってしまうのではないでしょうか。
  

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

  

2013年6月29日

つながる経済における実践とは(4)

■ つながる経済に従来の常識は通用しない

パラダイムが変わるということは、これまでの延長線上でものごとを考えていてはついていけないことになる。不連続の連続が世の中の進化を促しているのではないでしょうか。「つながっていない経済」から「つながる経済」への変化はどういうことなのか、それがもたらすものは何なのかを考えていきます。例によってこの章のポイントを掲げます。

(1) つながる経済では、従来の生産者から顧客への直線的、一方向的な情報の流れが変わる
(2) 顧客価値創造参加、ライバル企業との協創など、これまでのビジネス常識とは異なる現象が起こる
(3) 顧客との継続的関係が維持しやすくなることで、所有権を移転させる販売モデルから、利用権をライセンスするモデルへの転換など、資産を社会的に共有(シェア)するモデルが発達する

現代のビジネス状況をみていると実感しますよね。従来型の経済だと、生産者が大量に消費財を供給し、それを顧客が購入するという構図でした。ですから、供給側はお客さんの顔が見えなくても、買ってくれそうなものを作り、この会社が作ったものだからだいじょうぶだという信頼で売っていました。そのためにブランド力が大きな力になっていたわけです。

ところが、成熟された経済では、もはや規格化された商品をやみくもに買うというわけには行かなくなります。多様化した個別顧客ニーズに的確に答えていく時代なのです。そして、ただ聞くだけでなく、顧客も生産に関与していくようになっています。それが、顧客価値創造参加であり、協創ということになります。日本の製造業はもろにこの変化の波に洗われました。

大量消費財を一方的に供給するモデルは国内ではこうしてなくなり、発展途上国に移っていきました。そして、そのモデルで一番重要なのはコストですから、生産機能は低コストで生産できる国へとシフトしていきます。いま、まさに日本の製造業が生き残るためには、つながる経済に対応した新たなモデルが必要なのです。

さらに、もうひとつ販売モデルの変化です。「持たない」ビジネスです。商品の所有権を顧客に移転させる売り切りモデルから、所有権を提供者の側に留めて貸すモデルが登場してきました。このことは顧客から見ると専有する時代から共有する時代への転換を意味します。ソーシャルネットワークサービスと呼応していることがわかります。

さて、ずいぶんとITシステムとの関わりがでてきましたね。ITシステム(業務システム)は当たり前ですがビジネス形態やパラダイムに影響されます。ですから、従来の業務システムは、プロダクトアウト型のモデルに沿ったものです。つまり、低コストを目指した効率化を追求した生産システムで安価で大量な製品を作り、決まった規格の商品の注文を受けて販売するという仕組みが中心でした。

しかし、その時代は終わり、顧客ニーズに的確かつ迅速に答える受注設計・開発生産型の形態へと変わってきています。しかも、設計や開発に顧客が参画する、あるいは他社、場合によっては、競合会社も巻き込んで行く必要も出て来ました。特に中小企業は1社では顧客ニーズに応えられないので複数の会社と連携するということが求められています。(つい先日も中小企業庁から「中小企業連携ナビ」という指針も出ています)では、そうした形態に合った業務システムになっているでしょうか。

ビジネスの分野はすごい勢いで変化しているのですが、業務システムという意味でのITは付いていっているでしょうか。新しいビジネスモデルで始めたような会社は、どんどんとITを武器に展開しています。クラウドを活用して、売り切りではなく、レンタルとかサービスは無料にして広告で儲けるといった仕組みにしています。ところが、レガシーの会社(ITベンダーも含めて)はどうなっているでしょうか。従来の資産を維持するために新たな挑戦をしていないような気がします。既成概念を打ち破るような動きを期待したいものです。
  

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

  

2013年7月 8日

つながる経済における実践とは(5)

■ POU(利用時点情報)で見える顧客の素顔

つながる経済の中で現在進行している大きなテーマのひとつがPOU(Point of use)なのだそうだ。情報によるサプライチェーンとデマンドチェーンの統合であるといわれる。この章のポイントは次のようになっています。

(1) モバイルデバイスの発達によって、企業と顧客の接点が、従来の店頭(POS)ではなく、消費の現場(POU)となる
(2) 顧客に密着したデバイスから、個人の履歴、嗜好など、きわめて価値が高く、かつデリケートな情報が収集され、プラットフォーム上に蓄積される
(3) 情報が蓄積されることで、情報の価値が増大する
(4) 情報を収益化するモデルが進化している

まずはPOS(Point of sales)であるが、これは1980年代にスパーやコンビニを中心に普及して、レジでバーコードを読み取る仕組みはおなじみのものですよね。店頭での販売時点での情報により、どの時間にどのくらい売れているかを知ることができるようになり、小売業にとってなくてはならないものになっています。

ところが、大きな成果を上げたこのシステムもサプライチェーンが高度化するにつれて浮かび上がった問題点が、「販売時点」は顧客の「利用時点」ではないということなのです。結局サプライチェ−ンは供給側の最適化ですから、顧客ニーズやウオンツには応えられないというわけである。このブログでも何度も言っているようにプロダクトアウト的な論理なのです。

従来ですと、顧客の利用時点の情報を取るのは大変難しかったのですが、スマートフォンのようなモバイルデバイスの登場で可能になったわけです。スマホは情報を得ると同時に情報を発信する道具でもある。もちろん、個人情報保護の問題はあるにしても、情報の質と量がものすごく変わったのだ。ビックデータの昨今のもてはやされかたはこのことなのである。こうして、情報が文脈的な意味を付与されてますます価値が出てきたのである。

こうした流れ、つまり利用者の発信情報を得ること、その情報に多くの意味が込められるようになることはコンシュマー向けのビジネスへのインパクトが大きいが、そうではないB to Bのビジネスにも少なからず変化をもたらせている。また、社内システムにおいてもこうした考え方を取り入れることを考えたらいかがでしょうか。

利用者情報というのはあまりないかもしれませんが、生成された情報に様々な意味を付随させたものにしたり、組み合わされたりして価値が増すことである。例えば、売り上げデータでも従来だとただいくらで売ったという情報しかないが、どういう売り方だったのか、定価で売ったのか、値引きしたのか、キャンペーン価格だったのかといったことである。

最後のポイントの情報を収益化するモデルについては、ターゲットマーケティングですね。あの手この手でつながりを通じて売り込みや宣伝がきます。手当たり次第にDMをおくりつけるなんていうよりは効率的ですよね。今後はますます多くの有用な情報を携えたつながりをめがけたビジネスモデルが盛んになるのでしょう。
  

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

  


2013年7月16日

つながる経済における実践とは(6)

■ 見せてもらえる特権

つながる経済の進展は、否応なしにプライバシーという問題が浮かび上がってきます。前回出てきたPOSからPOUへの流れも、個人がいつどこで買ったかだけではなく、自分の行動様式のようなものまで記録されてしまう状況を生んでいます。普段見ているWebサイトの広告にぼくのことを知っているに違いないと思えるものが表示されていて気持ち悪くなったこともあります。第6章はこんなまとめになっています。

(1) つながりの中で、個人に密着した情報を活用したサービスサービスを提供しようとすると、プライバシー問題の解決が課題となる
(2) データの匿名化、自己コントロール権を尊重したシステム設計などの対応を進めることになる
(3) 最終的には、企業と顧客の間の信頼関係が重要となる。顧客に信じてもらえて、見せてもらえる特権をもらった企業が強い。特権をもらうためには顧客の側にたって行動した実績が重要となる

ここに出てくる「データの匿名化」というのは、個々のデータについてそれが誰のものであるか分からないようにしながら蓄積する手法です。ただ仮名にしたところで、元は固有名詞に紐付いたデータもあるのでそこを本当に引き剥がせてくれたのかがわからないということはあると思う。

そこで、自己コントロール権という概念が重要になってきます。個人がさまざまなデータベースに登録された自分についての情報に対して、少なくとも知る権利を有し、どういう目的に使われるかをコントロールする権利があるという考え方です。いま話題のマイナンバー制などもこの権利が大事になってくるのではないでしょうか。

これからのビジネスを考えると最後の「信頼が資産」であるというのが重要なポイントです。これまで、あまり意識せずに銀行やクレジットカード会社、携帯電話会社に個人情報を預けてきましたが、それは彼らが信頼できると思ったからです。ところが、近頃ではさらに様々な領域で個人データの提示をもとめられるようになってきました。また、個人情報がネットにさらされるようになり、プライバシーの侵害やなりすましなどの被害が出ています。

先日実際に経験したのですが、クレジット会社を信頼していたところで、クレジットの不正使用は防げないということがありました。怖い時代です。こうした、危険な世界を泳いでいくには、結局は信頼関係の絆をどう構築できるかであろう。それも、顧客が企業を選択する時代になったのである。いかに「信頼されて見せてもらえる」事業者になれるかが競争上のポイントになってきている。

ということは、顧客要求をただ一方的に聞いて、内部で仕様を決めたり、設計するような仕掛けではなく、顧客と一緒になって仕様決めや設計を行なっていくような業務システムが望まれている時代なのである。製品開発にしても、アイデア出しからコンセプトまでコラボレーションを主体にした創造プロセスの構築が重要になってくるのではないでしょうか。
 

ソーシャルな資本主義
國領 二郎
日本経済新聞出版社
売り上げランキング: 41,496

  
 

2013年7月24日

もし、見積システムを作ってと言われたらどうしますか?

システム開発のための要求工学とか要件定義技法とか、実装方法とかあるわけですが、それがどうであれ、単純に「見積システム」を作ってくれといわれたいったいどうしますか? どこかからパッケージかテンプレートを持ってくればいいじゃんというのは抜きにして考えてください。

さて、最初にどういうことを思いつくのでしょうか。見積書の帳票イメージが浮かぶかもしれません。そのための登録画面を思いつくかもしれません。でもWebサイトで見積してしまえば帳票要らないなあとか、登録画面からボタンを押すと見積書を自動作成したらいいかもとかも頭のなかを駆け巡るかもしれません。

おそらく大方の人はこうした取り組みを始めると思います。世の中にあるほとんどの見積システムがこうだから発想もそうなってしまうような気がします。すなわち、「見積書作成システム」を作り出そうとします。見積書に何を記載して、どんなレイアウトにするか、そのデータをどういう画面で登録させるのかという視点です。

これは、見積書に限ったことではなく、商談報告書や修理報告書もそうである。つまり、それぞれの活動の結果のみを登録するシステムをつくろうとします。見積書では、基本的に必要な情報としては、提供商品、納期、価格ですが、そのデータを打ち込むためのフィールドを用意することになるわけです。

それがユーザの望むシステムでしょうか。そこで、少し視点を変えてみていきましょう。このようなシステムで作られた案件データの集合ははたしてビジネスの役に立つのかということです。どこの誰の見積依頼に対して、提案した商品はこれで、納期はいつで、いくらの価格を提示したのかが並べられています。これだけでは、なぜ受注できたのかあるいは失注してしまったのかの解析もできないと思いませんか。

つまり、これはちょっと前に「つながる経済における実践とは」の記事にも書いたように、データが持っている文脈的な意味合いを包含していない、空疎な情報でしかないことなのだ。ということは、いかに意味をもった情報として残すはかが重要なことなのである。提案した納期はどういう事情があったから、コストから単純に割り出した売価なのか、顧客のランクを考慮したものなのか、戦略的な価格だったのかといった付帯情報が必要なのである。

もうおわかりだと思いますが、見積書をつくるまでにストーリーがあるのです、そのストーリーは案件ごとにみな違うはずです。その記録はどうするのですか。電話やメール、打ち合わせといったようなコミュニケーションや営業が工場に納期を確認したといった情報の収集、あるいは戦略や方針の共有といったことを残さなければ意味がないと思いませんか。

こうした表に出ないインフォーマルな動きをシステム上で行うようにすることで記録に残るのです。案件ごとに行ったアクションの意味などを付帯した履歴を残せば、同じような案件の処理に役立つはずです。これが、プロセス志向の重要な考え方です。ですから、システムを作るときの発想を結果をどうやって登録し検索するかではなく、どうやって結果を出したかがわかるようにする発想に転換しなくてはいけないのです。
  

2014年3月 5日

もうシステム開発というのはやめよう

システム開発と言うとどうしてもプログラミングをするというイメージが強くなる。それはものによってはコードを書くこともあるので全面的に否定することでもない。しかし、業務システムの世界でいつまでもコードを書くのは極力なくしたいものだ。なぜコードを書くかというと処理ロジックをプログラム言語を用いて書くというのが合っているからかもしれない。ぼくはプログラムを書くことは出来ないが(昔はちょっと書いたことがるが)、データ処理ロジックをプログラミングするというのはわりと自然の流れでもあると思う。

しかしながら、ここで少し立ち止まっていったいぼくらは何を作ろうとしているのかを考えてみたらどうだろうか。コンピューターに処理させるためのシステムを作っているのだろうか。もうそんな時代はとっくに去っていっただろう。もちろんコンピューターが登場した初期の頃は人間がやることの肩代わりという側面が強く、高級計算機であった。だからデータ処理システムが必要とされたのである。

ところが、インターネットの登場というインパクトもあって、単なる計算機から人間の行動をサポートする道具という側面が強くなったように思う。スティーブ・ジョブズがいみじくも言ったように"自転車"という道具なのだ。自分が行きたいところに自由に行き、速くも遅くも動け、途中で止まることもできる人間が操るものである。そして何よりも乗っていて楽しいのである。

それと大きな変化は人と人の間に介在するコミュニケーションツールとしての役割である。つまり孤立したものではなく周囲と調和した自転車の乗り方が求められている。従って、企業内でもこうしたITを使い、あるいはITに助けられて、迅速で的確な行動や円滑なコミュニケーション図られなければならない。

ところが、こうしたことをプログラミングという手段で実現しようというと無理があるように思うわけです。だって、個人的でもあったり、恣意的でもあり、状況でしょっちゅう変わってしまったりすることを扱うわけで、これを決まりきった手順で書ききれないからです。

そこで、いったいどんなものを作ろうとしているのかという最初の設問に戻って考えてみるに、結局「インターフェース」を作ろうとしているのではないかと思えてくる。それも、「マン・マシン・インターフェース」というより「マン・マン・インターフェース」を作りたいのではないでしょうか。つまり、いかに組織能力を上げることができる、あるいは働きやすい場とするにはどんなインターフェースが必要なのかという観点が大事なような気がする。

もちろん、インターフェースそのものはプログラミングされたものですが、それをユーザと一緒につくるのではなくて、あらかじめ作られた部品を利用してインターフェースを設計・組み上げるというアプローチにすべきなのである。こうしてできたものは、必ずユーザが使いやすいようになっている(設計とはそのために行うもの)のだからすぐに使うことができるし役に立つものになるのである。
  

2014年4月28日

プロセス中心アプローチのフレームワーク(1)

今このブログで「イノベーションを支援するITシステム構築の極意」というタイトルで連載をしている。タイトルにもあるようにITシステムの構築方法がテーマである。従って、手順とか記述方法などが中心になっている。そのとき、何もかもごりごりと書くわけではなく、モデルを参照したり、共通フォームを利用したり、ソフトウエアパーツを組み合わせたりすることが望ましい。

そこで、システム構築に際して使うモデル、フォーム、パーツなどの集まりを広義の意味でフレームワークと呼んでみようと思う。対象となる領域は、「イノベーションを支援するITシステム構築の極意」で議論しているところと同じ、すなわちビジネスモデル起点でプロセスへ展開して、そのプロセスを市販のツールを活用して実装してオペレーションするというものである。

個別のものに入る前に全体観をもつために概念的な話から始めたいと思います。まず、プロセス中心アプローチについて、しつこいようですが繰り返して説明すると、業務システムを作る時に文字通りプロセスを中心に据えて考えましょうというスタンスのことです。

従来はデータや機能を中心に作られていましたが、競争や変化が激しい現代のビジネス環境では様々な局面での俊敏な意思決定が重要になってきていて、ビジネス活動の結果を登録するデータベースシステムでは対応しきれなくなっています。これまでは登録するデータを生成する過程が属人的な世界に閉じ込められてしまっているように思います。

すばやい変化対応やビジネスモデルの継続的な変革などを実現するには、プロセス中心で考えざるを得ないのではないでしょうか。いまや、リアルタイムのコントロールとマネジメントが必須になってきているわけです。リアルタイムでコントロールするにはプロセスが確立していなくてはできません。コントロールできるのはデータではなくプロセスだからです。なぜなら、データはプロセスを経て生成されるか、プロセスに使われて初めて意味のあるものになるからです。

というわけで、大事なことはプロセスを中心として考えるということですが、中心ということは上下左右に何かがあるということでもあります。それは何でしょうか。プロセスの上にはビジネスモデルがあり、下にはアプリケーションがあります。横の関係としては、ルールとデータだと思っています。ここでは縦の関係について議論していくことにします。

ですから、ビジネスモデル、ビジネスプロセス、アプリケーションの3ステージでのフレームワークを考えていきます。そのとき大事なポイントを忘れないことです。それは次のようなことになります。まずはこの特徴をしっかりと理解してください。

(1) ビジネスモデル起点のプロセス展開
(2) オペレーション発想のプロセス定義
(3) プロトタイピング型IT実装

この意味は、プロセスはビジネスモデルから課題や要求が来てそれを表現するものであること、オペレーションしてこそ初めて成果がでるということ、システムは作った時が終わりではなく始まりであることということです。
  

2014年5月 8日

プロセス中心アプローチのフレームワーク(2)

前回、プロセス中心アプローチのポイントを説明しましたが、プロセスの重要性を理解してもらえたでしょうか。さて、前回に最後に示した要請に応えるようなビジネスモデル、ビジネスプロセス、アプリケーションはどんなものなのかの議論に入って行きます。

そして、留意しておくべきことは、それぞれが独立しているわけではなく連動していること、すなわち上から下、さらに下から上への継承関係が維持されていることで、ビジネスモデルで導出されたビジネス要求をプロセスがちゃんと受けとめて、そのプロセスが成果を上げるように動くことを担保されていなくてはいけないし、結果を戻して修正するループが確立していることである。

話は戻って恐縮ですが、ビジネス活動というのは、こうしたフィードフォワードとフィードバックの制御機能が働くことが必須で、というか必ずあることなのであって、それがどういう形態でやられていたかが問題なのである。それを人間系でやるのかITを活用してやるのかで違いが出てきて、繰り返すが、変化が激しい今日ではITを使わないと対応できないということだと思う。

さて、前置きが長くなったが、ここからフレームワークはどんなものから成り立っているかを考えていきましょう。プロセス中心といってもいきなりプロセスを描くことはどうでしょうか。何のために、何をしたいからプロセスがあるのかという視点が必要であると思うと思います。そこをしっかりと抑えておかないと、ぶれたり後戻りしたりします。

こういうことを言うとやっぱり大事なことはビジネスモデルだという人がいるかもしれませんが、残念ながらビジネスモデルというのは静的で、実際に適用するときの動的手段をもっていません。だからプロセスなのです。ですから、プロセスにどういうふうに受け渡すことができるビジネスモデルを描けるかが重要なのです。

このことは、重要な視点でつまり継承という担保を確保しようとするとボトムアップ指向が必要だということである。つまり、こんなふうに規定してくれないと受けられないというふうに下から突き上げるべきなのである。またまた話がそれるのだが、受託開発の様態の問題はここにあって、言われたままにやるという上下関係は連動性を損なっているのだ。受託側が委託側に言えないということが問題かもしれない。

話しを戻そう。フレームワークを構成する要素は何かである。まずは、きちんとその目的とかなぜ必要なのかがあって、そして、具体的なモデルとかフォームがあり、それがどんな要素から成り立って、どういうふうに記述したらいいのか規定されたものであろう。次回はビジネスモデルについて具体的に見ていきましょう。

2014年5月22日

プロセス中心アプローチのフレームワーク(3)

前回までの議論でプロセス中心アプローチといってもいきなりプロセスを書けばいいというわけではなく、なぜプロセスが必要なのかという意味でビジネスモデルを起点として考えましょうというのがあります。そして、そこから課題を解決するために対象となるプロセスが特定され、そのプロセスを設計します。

プロセスの設計は最終的には日々のオペレーションで生かされますから、オペレーションをいかにうまくやれるように設計するかが大事になります。そして、オペレーションを実行するためのITシステムを作ることになりますが、それはいちいちプログラミングするのではなく既成のソフトウエアやツールを活用して、反復的に試作を繰り返しながら素早く組み上げようというのがこのアプローチの肝の考え方になります。

従って、大きくは、どんなビジネスモデルにするのか、どのようにデザインされてプロセスにするのか、すぐにオペレーションに供されるアプリケーションを作りあげるのかという3つのステージに分けることができます。そのそれぞれのステージで大きな括りのフレームワークがあります。そのフレームワークの中身は、主に目的、モデル・設定フォーム、構成要素から成り立っています。それと、それらをどういう手順で記述し、定義していくかとセットで考えていきます。つまり、モノとコトの組み合わせになるわけです。

だいぶ前置きが長くなりましたが、ここをよく理解しておくことが大切なのであえて繰り返して言っています。さて、最初はビジネスモデルになります。ビジネスモデルを記述することになりますが、なぜ記述するのでしょうか、記述する目的は何なのでしょうか。

どんな形態でビジネスを行うのかを戦略やビジョン・コンセプトから描いていきますが、結局それを記述する目的は「顧客の望む価値提案」ということになるのではないでしょうか。単に商品を用意してそれを販売するというだけでは、そのビジネスはいつかは消えてしまいます。顧客が買う価値があると思ってくれなくてはいけません。そうした価値を提案するのがビジネスモデルを描く目的になります。

次のモデル・設定フォームには型があります。「モデル構成」「要素モデル」「要素表」です。ビジネスモデルについては次の図のようになります。
  
ビジネスモデル構成.pngのサムネイル画像
 
ビジネス要素モデル.png
 
ビジネス要素表.png
 

2014年6月 2日

ITに求められるものが変わった

いま、「イノベーションを支援するITシステムの構築の極意」といういささか長ったらしいタイトルで連載記事を書いているが、どちらかというとテクニカルな面が強いので、なぜこうした主張をしているのかといった背景面での考察をしてみる。もちろん情報技術そのものの変化というのは大きな影響があることは否定しませんが、それだけの理由ではなく、ITとは関係ないところの変化があって、そこからITに求めるものもかわってきているのではないかという視点である。

例えば、いま3つのパラダイム変化を提示している。すなわち、「データ・機能中心からプロセス中心へ」「作って終わりから動かしてナンボへ」「個人作業からチームワークへ」である。こうした動きの背景には、経済環境、産業構造、ビジネスモデル、働き方、組織といったものが大いに関係していると思う。

非常に大雑把な言い方ですが、コンピュータが登場して企業の中に入ってきた頃は、経済成長期だったのだが、いまは完全に成熟期に入っています。ですから、成長期におけるITと成熟期におけるITではやるべきことが違ってくるはずです。ところが、ITそのものの技術進歩が急だから"ITシステム"そのものも進歩していると錯覚してしまい、成長期に求められていたシステムと同じものにただ新しい技術を入れただけで満足してしまっているように思える。

「イノベーションを支援するITシステムの構築の極意」で指摘したように、ITを高級計算機、帳票出力マシンとして、個人が端末の前に座ってデータの入出力のための仕事に使われているのである。これは、成長期のコンピュータ導入初期の使われ方である。それが、基本的には同じようなシステムとして続いているのだ。ダム端末からPCになりモバイルになったとしてもやっていることは変わりない。そして、相変わらずタバコ部屋はもうなくなったかもしれませんが、クローズした世界でITを使わず仕事を進めています。

ただ、成長期ではある程度仕方がなかったのかもしれません。会計処理とか決算といったバックヤードの整備が大事だったからです。しかも、ビジネス形態的には、プロダクトアウト思想が強かったことが大きいと思います。つまり、作れば売れる時代だったということです。この傾向が強いと、売るためのプロセスなどというより、極端な話どれだけ売ったのかどれだけ儲かったのかを知るだけでよかったのです。

お客さんの声を聞くよりもこれはどうか、こんなものができたから買ってというのが営業で、そして引きが多いのでコラボレーションなんて言葉もなかったように個人プレーでどんどんやったのである。当時の営業部長は、営業日報に登録する暇があったらさっさと外に出て売ってこいと言っていた。

ところが、バブルもはじけ、リーマンショックにもみまわれ成長が鈍化し、いまや完全に低成長の成熟期に入ってしまった。こうなると、成長期のプロダクトアウト思想ではものが売れなくなってしまった。顧客の声を聞いてその要求に合ったものを提供していかないと立ち行かなくなったのだ。そこには、単にデータの入出力だけではなく、どのようにしてそのデータが生成されたのか、なぜそのデータを見る必要があるかといったプロセス的な観点が必須になってきたのだ。

こうした変化に対応するには従来型のITシステムでは無理だということは歴然としている。だから、ITシステムにもパラダイム変化が必要なのである。ところがこのことに気がついている人が少ないようで、従来の延長での技術進歩を盛り込んだ製品や技法はあるのだが、新しいパラダイムに依拠した機能を装備したツールやソフトウエアはまだまだ少ないように思う。これができれば、企業向けIT産業でイノベーションが起こせるかもしれない。
  

2014年6月 5日

セオリー通りにはいかない現実にどう対処するのか?

いつも思うのだが、何か行動を起こしたり実行するとき事前に設定したとおりに行くことはほとんどないだろう。何事もなくすんなりいくというHappy Pathは期待しないほうがよい。そうなると、最初に一生懸命シナリオを考えておくというのは無駄なことのように思えてくる。

だから、現実的にはある程度の道筋を想定しておいて、その都度調整してゴールするというのがとるべき態度ではないと思う。この筋書き通りにいかないというのは、いろいろな局面でやってくる。すなわち、その瞬間のアクションの時であったり、相手の要求に対する提供サービスであったり、戦略とか方針といった場合だったりする。

"調整"において一番大事なことはなんでしょうか。それは「察知」ということではないでしょうか。絶えず事象を観察して変化の兆候を感じ取る「察知」である。これは能動的なもなので、こちらから仕掛けることもありだということでもある。つまり、なんでもいいからまずやってみてどうなるかを素早く察知してだめならすぐ切り替えていくというのも必要なことではないでしょうか。この切替ができる代替案を持っていなくてはいけないのは言うまでもない。

そこで、階層的な切り口でみていくと大きくつの3つのパターンがあるように思うのである。

① Change & Evolution (変化と進化)
② Try & Improvement (試行と改善)
③ Sense & Response  (検知と応答)

最初の変化と進化というのはより高次で広い範囲を対象にしている。例えば社会情勢だとかビジネス環境が変化したのを察知して戦略やビジネスモデルを変えたりすることである。この場合忘れてはいけないのが、ただ変化に対処するだけではなく、変化したことを進化に繋げないといけないということである。

試行と改善は主にプロセス管理の領域に対して言えることである。よく業務改善とかプロセス改革とか言うのだが、最初から立派な理想的なプロセスを描いてそれを実行することが是とするスタンスから、ある程度プロセスが描けたらまずそれを動かしてみて、不足するところとか変えるべきところが出たらすぐに追加・修正するというやり方を言っている。

最後の、検知と応答というのは、実オペレーションの断面でのパフォーマンス管理の領域である。例えば、このままほっておくと納期に間に合いそうもないというときに、増員して対処するといったことである。それも、応答時間も短く、リアルタイムで繰り返しやることも多くなる。

様々な局面で変化の予兆に気づき、適切な対応をとり、それを次に活かすという動作が継続的にやられている姿が望ましい。さて、これをITシステムに持って行くにはどうしたらよいのでしょうか。ある意味で制御システムに近いものになる。こうしたシステムを使って変化対応力に優れた断トツオペレーションができたら差別化できるんだけどなあ。挑戦してみるかな。
  

2014年6月10日

プロセス中心アプローチのフレームワーク(4)

前回は、ビジネスモデルのフレームワークについて議論しました。次はビジネスプロセスについてになります。このフレームワークはビジネスプロセスをデザインするステージのものです。このフレームワークを使う目的は何かというと、ビジネス要求を実現するプロセスをきちんとデザインすることにあります。

単にプロセスをデザインするというのではなく目的に合致したものであるかという見方が大事になります。ビジネスモデル上で浮かび上がった課題を解決する、あるいは戦略やビジョンが実現できるプロセスをデザインすることなのです。これも、前回と同様に構成要素としては「ビジネスモデル構成」「プロセス要素モデル」「プロセス要素表」になります。

ビジネスプロセス構成.png

プロセス要素モデル.png

プロセス要素表.pngのサムネイル画像
  

それぞれのフレームワークについて簡単に説明を加えておきます。ビジネスプロセス構成では、大きく「意思決定プロセス」「作業プロセス」「タスク管理」という構成になっています。プロセスの基本構造は依頼を受けてその依頼に応えるための意思決定を行い報告するというもので、その報告するために何らかの作業が発生し、その作業は個別のタスクによって遂行されるという考え方です。

この構成でどこにウエイトが置かれたプロセスであるかはその性格によります。例えば、見積提示というようなものであれば、作業が見積書作成ぐらいで、ほとんどが商品仕様、納期、価格などを決めるプロセスが主体になります。一方、生産プロセスといったあらかじめ手順が決められたものであれば、作業プロセスが重要になってきます。また、それぞれのプロセス間でデータがきちんと継承されていることと重複がないことに注意しなくてはいけません。

次が、プロセス要素モデルですが、これは6W2H3Rとおぼえてください。依頼が来て、その要求を確認して、誰が、誰に、何を、どこで、いつ、どうやって、どのくらいなのかを決め、それを提供するための作業をして報告するということを表しています。作業プロセスは作業指示と作業と報告から成り立っていますので、1W2Rということになります。

プロセス要素表に着いては、何度も説明していますので表を見ていただければよいと思います。
  

2014年6月23日

プロセス中心アプローチのフレームワーク(5)

前回のプロセスに続く3つ目のフレームワークは、アプリケーションです。実際のITシステムに実装していくステージになります。目的は成果をあげるオペレーションを行うためということです。なんだかんだといっても日常のオペレーションでビジネス成果をあげないといくらいいビジネスモデルを描いても、いくらすごいプロセスをデザインしても意味がないわけです。

ここは非常に重要なことで上流からの分断がおきているシステムを数多く見てきたので軸足を移動させたほうがいいと思う。こうしたオペレーション発想のIT実装をぜひ心がけてもらいたいものだ。これも同じようにアプリ構成、アプリ要素モデル、アプリ要素表というものがありますが、最後のアプリ要素表は書くまでもなく、ツールの持つ設定フォームでよいと思います。例示はサイボウズ社のkintoneを用いたもので示しています。


アプリ構成.pngアプリ要素モデル.png   



      

アプリ要素モデル2.png


アプリ要素モデル3.png


アプリ設定フォーム.png

   

これについても少し説明をしておきます。サイボウズ社の「kintone」のステマをしているわけではありませんが、中小企業あるいは大企業の部門システムなどでDIYのような使い方は推奨できます。もちろん、ぼくが思っているとおりというわけにはいきませんが、だいぶ機能もアップしていて十分に使いものになります。個人的に作ったりしても運用をどうするのかといった問題がすぐに上がってきますので、クラウドで組織的に対応してくれるメリットは大きいと思います。

アプリケーション構成は、データとプロセスとコミュニケーションからなっています。この考え方はすばらしいと思います。これまでのシステムのほとんどはデータベースアプリケーションだったからです。ただ、ここで言っているプロセスはワークフローですから工夫が要ります。

要素モデルとしては、データベースがあります。なんだかんだといっても最終的にはデータベースにデータを格納しますから主要素になります。続いてプロセスですが、先に述べたように申請フローなどが対象ですので、本来のプロセスというと一覧表で進捗管理したり、アクティビティごとの登録画面を作ったりして対応します。3つ目のコミュニケーションは、データ登録画面にコメント欄が付帯していて、そこで関係者が会話しながら仕事ができるようになります。

最後のアプリ要素表は設定フォームがその役割になります。そこにはいくつかのパーツを配置してあって、それらをドラッグアンドドロップしてキャンバスに貼り付けることで画面を作成することができます。それはすぐに動くものとなります。ノンプログラミングですからユーザ自身で作ることが可能です。

以上でこのシリーズは終わりますが、できるだけシンプルな構造にすることを心がけたつもりです。フレームワークの役割は詳細な手順ではなく、おおよその枠組みを提供するもので、大事なのはその思想とか視点なのでそこをよく理解していただけたらと思います。
  

About IT再考

ブログ「mark-wada blog」のカテゴリ「IT再考」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

次のカテゴリはIT雑感です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type