<   2011年 03月 ( 8 )   > この月の画像一覧

ロジスティクスと兵站の間

SCMのコンサルティングを主にしていたとき、最もよくぶつかった誤解は、『SCMって、ロジスティックスすなわち物流の改善のことでしょ?』というものだ。この誤解は関門のようにSCMの入り口に立ちはだかっていて、まずこれを崩さなければサプライチェーンの中核問題の解決に踏み込むことなどおぼつかない。

この短いが典型的なセンテンスは、じつは少なくとも3種類の誤解が蔓草のようにからみ合って出来ている。それは、

 (1)サプライチェーン = ロジスティクス、という誤解
 (2)ロジスティクス = 物流(輸送)、  という誤解
 (3)マネジメント = 改善、       という誤解

の3種類である。

こうした誤解の生まれる背景には、ロジスティクスという概念のわかりにくさがある。最近でこそ、この言葉は誰もが知るポピュラーなものになったが、'90年代の中頃くらいまでは、「ロジスティクスとはそもそも兵站のことで・・・」と翻訳しなければならなかった。しかし、翻訳してもそれで理解されたわけではない。なぜなら、『兵站』という概念自体が日本では非常に希薄だからである。

では兵站とは何か。
それは、弾薬・食料・衣類・医薬品などの物資を前線の基地に、「必要な場所に、必要な量を、必要なタイミングで」送り届ける活動である(このカッコの中のセリフはみなさんもきっとどこか別の場所で聞いた記憶があるはずだ)。兵站の概念は、資材の調達や輸送、中間地点での蓄積保管なども含んでいる。物資だけでなく、兵隊そのものを移動させることも兵站の重要な一部である。

「必要な場所に、必要な量を、必要なタイミングで」という条件が付いているから、単に物資の場所を右から左へと移動する行為である『輸送』と、ロジスティクスとでは全く別次元の概念であることが分かるだろう。

アメリカの会社と一緒に仕事をすると、彼らがいかにロジスティクスに神経を集中し万全の用意をしたがるか、驚くほどである。彼らにとってはロジスティクスがきちんと準備できたら、もう仕事は半分終わったようなものなのだ。

この行動原理はアメリカの軍隊も全く同じである。彼らほど兵站に厚い軍隊はない。そして、その対極にあるのが、かつての帝国陸海軍だった、と言われている。日本軍は兵隊を広大な中国大陸や南方の各所にばらばらに振りまいて、それで戦争ができると思っていたらしい。しかし鉄砲は弾がなければ撃てないのだ。いや、たとえ武器弾薬がたんまりあっても、食糧がなければ兵隊さんは戦うことができない。衣服や薬がなければ生き延びることができない。

したがって戦略論で攻撃の大きなポイントは、いかに敵の兵站線を切り崩すかであり、防衛とは、いかにそれを守り維持するか、になる。たとえ武器以外の物資の輸送でも、きちんと武装した護衛が必要なのはこのためだ。なぜなら、兵站業務とは前線で戦うことの前提条件であるからだ。

いいかえれば、ロジスティクスを遂行することは、前線に荷担するのとまったく同じ意味を持っている。鉄砲を撃たなければ平和的業務、というのは誤解である。兵站とは「後方業務」かもしれないが、にもかかわらず攻撃なのだ。

ビジネスに話をもどすと、セールスの達人が店でばんばんモノを売れるのも、開店前にちゃんと商品を届けてくれるトラックの運ちゃんがいるからだ、ということになる。そしてそれをさかのぼれば、午前2時に配送場で働く荷役労働者や、ドブ板踏んで仕入先を回る購買担当がいるからだ、ということにもなる。「後方支援」だ、「下積み」だ、などという上下の区別はおかしい。

こうした視野をもたないと、決してロジスティクスを正しく理解することはできない。そしてロジスティクスが分からなければ、その上位の概念であるSCMなど納得できるはずもないのだ。

第3の誤解、すなわち「マネジメント=PDCAサイクルによる改善」という固定観念の問題点については、また別の機会に論じることにしよう。
by Tomoichi_Sato | 2011-03-31 23:40 | サプライチェーン | Comments(1)

サプライチェーンの再生力

Verizonという会社をご存じだろうか? アメリカの通信事業会社である。専門分化し細分化された米国の通信業界において、長距離通信と携帯通話サービスを中心に健闘している。しかし何よりも、NYのウォール・ストリートを中心とした金融街の通信事業者の中核として、Verizon社はその独自の地位を築いている。

9.11の悲劇から1週間後の月曜日、NY証券取引所はその業務を再開した。全員が「ゴッド・セイブ・ジ・アメリカ」を唱和し、続いて会頭の振りおろすハンマーによって業務を再開する映像は、世界中に放映された。フランスのニュース番組は、『アメリカがここまで信心深いとは知らなかった』と皮肉っていたが、アメリカの社会がもつ再生力を象徴するシーンだったことはまちがいない。

ところで、この劇的な再生シーンの背景に、Verizon社の死にもの狂いの努力があったことはあまり知られていない。

取引と言うと机と紙しかいらなかった旧時代はともかく、現代の金融取引の中心手段は通信である。そして、その通信の物理的な基盤はウォール・ストリート中に張りめぐらされた光ケーブル網であることも、考えてみればすぐ分かることだ。

そのケーブル網は、ワールド・トレード・センターのツインタワーの崩壊によって、当然ながらずたずたにされてしまった。Verizon社の中核設備は同センターの7階区にあったが、これも大きな被害を受けた。そして、ウォール・ストリートの機能の復旧とは、すなわちVeirzon社がどれだけ彼らの顧客への接続サービスを再生できるかにかかっていたのだ。

この間のVerizon社の不眠不休の努力は、Fortune誌(2002年10月15日号)の記事が詳しく書いていた。9月11日の朝、同社の社員たちは、本社ビルからツイン・タワーの崩壊場面を呆然と見つめていた。「これを目撃した以上、全力で復旧作業を行わなければ気が済まないという心理でした。」と彼らは同誌に語っている。事実、ウォール・ストリートから世界各地へと送られる声とデータ情報をサービスし、350万以上のハイ・キャパシティ・サーキットと電話回線30万本を処理していていた4個の巨大な交換装置が危機に瀕していた。

これらネットワークを、危険地区を避けてマンハッタンの別の場所に迂回させ、つなぎ直す作業にどれだけ超人的な努力がいるか、通信技術者でなくても想像がつくだろう。彼らはさらに、金融街に戻ってくる何千人もの企業人の便宜を図るため、携帯電話用の仮説アンテナを設置することまで行なった。

米国の通信業界が細分化され競争社会にあることが、この場合は幸運に働いた。大手企業は複数の通信業者を同時に採用しており、一ヶ所に危機が起こった時に別のルートやサービスが選択できる状況にあった。いわばシステムに冗長性があった訳だ。また、ふだんは競争している通信業者が、このような社会的危機の際には団結し協力して動いたことも大きい。ここらへんは開拓者の子孫たちから成り立っているアメリカ社会の良い面だろう。

再生力のポイントをもう一つ上げるなら、それは自己責任による判断があったことだ。Verizon社が、自社の設備の危険性を承知で、あえて事故後しばらく稼働させたまま放置した(人間は避難せざるをえなかった)こともそれだ。こんな状況にどう対応すべきか、当然ながらそこまで社内規定では決まっていなかったにちがいない。現場判断による一種の賭けである。このおかげで多くの電話回線が数時間のあいだ生き続けて、人々の連絡を助けたのだ。

複数の競争があること、しかしそれを超えた協力もできること、自律性すなわちマニュアルに無い状況でも自己判断ができること・・こうしたことが相まって、ウォール・ストリートのネットワークの再生力を強めた。

これからえられる教訓はなんだろうか?

我々の社会においても、サプライチェーンの危機管理が今や真剣に問われている。危機管理を考えるとき、事故や災害や悪意の攻撃を未然に防ぐ方策は何より大切だ。

しかし、もうひとつ大切なことは、サプライチェーン全体の再生力を高めることだろう。供給のネットワークを単線化せず、複数事業部間で協力ができること、そして何よりも、危機的状況が起こったときに、現場での自己責任による判断が許されるような緊急時の権限委譲が保証されていること・・こうしたことを包含してこそ本当の対策となるのである。
by Tomoichi_Sato | 2011-03-29 00:00 | リスク・マネジメント | Comments(0)

危機における技術のマネジメントとは

「どうだ、状況は?」
「かなりヤバイ。温度が上がってきている。液面も落ちてきた。」
「困ったな。一番の問題は容器内の圧力だろう。今どれくらいある?」
「計器のトラブルでよく分からないんだ。表面温度から見てたぶん7~8気圧くらいになってる」
「設計圧力は?」
「4.5だ。5や6くらいまでなら持つ自信はある。でも8となると、正直厳しい。」
「時間との勝負だな。安全弁をふかせるしかないか。ポンプさえきちんと回せれば抑え込めるはずなんだが。」

エンジニアは、こういうしゃべり方をする。ちなみに、上の会話は創作である(念のため)。エンジニアの会話は、数字と見込みと判断と、そして感覚からなっている。これは、科学者や、役人や、政治家や、法律家の話し方とはずいぶん違う。科学者は「ヤバイ」という言葉遣いはしない。科学者は論理的に確実なことしか言わないし、論理的でないことを言えば、科学者でなくなってしまう。政治家は耐圧性能に対して自信を述べず、法律家は「時間との勝負だな」とは言いはすまい(たまには言うかもしれないが、彼らの時間感覚はだいたい月単位である)。


前回
も書いた通り、わたしはエンジニアだ。エンジニアリング業界で働き、周りも技術屋ばかりである。だからエンジニアがどういうしゃべり方をするかよく承知しているし、技術屋同士の話が一番分かりやすい。世間ではよく「科学技術」と一括りにするが、この二種類はかなり違う。科学は真理への探求心が主軸にあるが、技術屋は徹頭徹尾、目的合理性と実用の観点で動く。技術の対象は(たいてい)複雑な系である。必ずしも全ての情報が手に入るとは限らない。そこで、入手可能な数値的データから、系の状態について推測し判断することを求められる。かりに論理的に確実でなくても、経験的に因果関係があれば、なんらかの手を打つ。「一応、念のため」とか「気は心さ」などと口にしつつも。

ここで「技術者」といわずに「技術屋」とわざわざ書いている点に注意してほしい。エンジニアとは生計を得るための商売である。聖職とかではない。そこに自尊も卑下もあるのだし、だから対象から距離をとって正気を保っていられるのだ。技術屋は不確実性の中にいる。そして、一定の制約条件下で判断を下さなければならない。判断のためには、なんらかの価値基準がいる。こうした、不確実性と制約と判断が、エンジニアの直面する日常的問題である。

だからエンジニアを使う時には、それに合った使い方、マネジメントの仕方を理解する必要がなる。とはいえ定常的なオペレーションにおける技術屋のマネジメントについては、ここで詳しく述べるまでもないだろう。『PDCA』という言葉は全国的に流通しているからだ。計画を立て結果を検証し、必要に応じて改善のサイクルを回すことは、普通の企業だったらどこでも行っている。

ここで論じたいのは、技術的な問題発生時、それも重大な危機的問題の発生時のマネジメントでだ。そもそも『問題』とは、“現状が期待と乖離した状況”を指すのだが、それにも軽重がある。普通は三段階、すなわち、プロジェクトやオペレーション全体を止めてしまう可能性のある重篤な問題(英語でいえばShow Stopper)と、当面は迂回可能な問題と、後日修正すれば済む軽微な問題とにレベル分けされる。ABCなどのランクで区別されることも多い。大事なことは、Aランクの危機的問題と、BCランクの問題では、マネジメントの仕方を変える必要がある点である。

Aランクの危機的問題においては、マネジメントは次のことに集中しなくてはならない。
1 リソースを動員する
2 外部影響を遮断する
3 代替案を出させて決定に責任をとる
以下、意味を説明しよう。

1 リソースを動員する
マネジメントは、問題解決に当たる技術者に対して、必要なリソースを可能な限り動員・調達するべく努力してほしい。『リソース』が何を意味するかについては、最近解説したばかりなので、ここで詳しくは繰り返さない。技術者が問題解決に必要としているリソースは人であるかもしれないし、特殊な道具・機械・設備かもしれないし、あるいはユーティリティ(電力・燃料・水等の用役)かもしれない。一口に人と言っても、専門家の場合もあるだろうし力仕事の労力の場合もあるだろう。何であれ、必要と思われるものは、可能な限りすみやかに調達する。そのためのロジスティックスも手当てする。これがマネジメントの第一の仕事である。

リソースは、最初からできるかぎり多めを動員する。足りなくて困るよりは、多すぎて迷う方がましだからだ。戦力の逐次投入が、一番いけない。わたしの知る優秀なプロジェクト・マネージャーやプロジェクト・スポンサーはたいてい、問題発生時のリソース投入の判断が早くて正確である。しかもリソースが多すぎて現場が混乱しないよう、その整理と差配も同時に考えている。

2 外部影響を遮断する
これはエンジニアを問題解決に集中させるためにぜひ必要なことだ。ここで外部影響とは、「外部からの影響(雑音)」と、「外部への影響(波及)」の両面を指す。危機的問題の発生時は、経営トップをはじめ、顧客やら監督官庁やら地域コミュニティからメディアにいたるまで、ありとあらゆるステークホルダが疑問や注文を投げかけてくる。現場の担当技術者がこれらに対していちいち資料を作って答えていたら、肝心の「考える時間」が取れなくなる。そこでマネジメントの第二の仕事は、担当者に代わってコミュニケーションを引き受けることで、担当者を雑音から遮断し、問題に専念させることである。

「外部への影響」の遮断とは、問題事象がなんらかの形で物理化学的に近隣施設やコミュニティに影響を与えている時に必要となる。むろん、物理的遮蔽や化学的中和は技術者の仕事である。マネジメントの仕事とはそうではなくて、遮断による経済面・心理面・法律面での影響について交渉し対処しておくことである。本当に必要なら、行政を説得し近隣住民を予備的に避難させることも案の一つである。かりに現時点で直接の危険性がなくとも、それによって技術者のとれる選択肢の幅が拡がるなら、十分に意味がある。

3 代替案を出させて決定に責任をとる
これがマネジメントの第三の、そして一番重要な仕事である。マネジメントとは、担当者に仕事のやり方を指示命令することではない。技術に関しては、技術者が一番よく知っているのだ。大事なことは、技術者に問題解決のための複数の選択肢を考えさせ、その中の一つをマネジメントの責任の下で選ぶことである。複数の選択肢について、それぞれの技術的可能性、有効性、コスト、時間、影響、リスクなどを簡潔にまとめさせる。そして、総合的判断の下、最善と思われるものを選ぶ。

担当技術者に選ばせない理由は二つある。担当者は問題事象に集中しているため、より大きな観点からの得失が見えにくくなっているおそれがある。たとえば、技術屋というのは、自分が面倒を見てきた装置やら製品やらシステムが可愛い。だから、できるかぎりは破壊から守ろうと無意識に考える。しかし、「それはもう捨てろ」と命じるのが、マネジメントの役割なのだ。「過去つぎ込んだ金や時間への執着は忘れろ、それはSunk Costだ」と言わなくてはならない。もう一つの理由は、当然のことだが、結果に対する責任を引き受けるためである。かりに技術者のリコメンド案をそのまま受け入れる場合であっても、責任はマネジメントに残る。うまくいかなかった時の非難は、マネジメントが受け取る。うまくいったら担当者を賞賛する。これがアカウンタビリティーの原則というものである。

以上の三つの仕事を煎じ詰めれば、マネジメントの仕事とは技術者を「支援する」ことだ、と分かるだろう。現場に乗り込んで陣頭指揮、とか、一刀両断に問題を解決、といったかっこいい「リーダーシップ」を世間では求めたがる。マネージャーも現場感覚は必要だから、現場には行くべきだと思う。だが、あいにく、技術的問題に関しては、技術者が解決するしかないのだ。技術のマネジメントとは、脚光を浴びず、非難ばかり浴びる仕事である。それは当然なのだ。なぜなら、危機における技術のマネジメントとは、『支援』の別名だからである。
by Tomoichi_Sato | 2011-03-24 22:45 | リスク・マネジメント | Comments(0)

計画技術者の目から見た「計画停電」

わたしはエンジニアだ。調査票やアンケートにもそう記入する(選択肢があれば、だが。無い場合はしかたなく「会社員」を選ぶ)。工学部の大学教育を受け、エンジニアリング業界で働き続けている。職場で周囲を見渡しても技術屋ばかりだ。

何の専門のエンジニアか? と聞かれたら、わたしの場合は相手の立場を見て答えを決める。まったくの素人さん相手なら、「プラント関係の仕事です」と答えるだろう。これで相手は分かった気になる(らしい)。理工系相手なら「大学の専門は化学工学です」と答えたいところだが、8割以上の人は『カカクコウガク』というものが分からないので、白衣を着てビーカーを振っているように思うらしい。自慢じゃないが白衣なんて中学以来着たことがない。でも、これが英語での質問なら、"I'm a chemical engineer."でピタッと理解される。英米では、mechanical engineerと並んでメジャーな職種の一つだからである。

でも、もしも同じ業界の人に聞かれたら、"I'm a schedule engineer."だと答えるだろう。「スケジュール・エンジニア」という専門職種が、わたしの業界には確立しているからである。ああ、それじゃあPlanningとかProgress controlとかを毎日やっているんだ、と理解してもらえる。Time Managementが専門の技術者、と言いかえても良い。

そのスケジュール・エンジニアの目から見て、今回の「計画停電」というのは、率直にいって、きわめて筋のわるいスケジューリングのやり方である。ちなみに、電力会社はわたしの勤務先の顧客筋の一つに当たる。そして、わたしは一応このサイトを実名で書いている訳だから、あまり批判めいたことをするべきではないのだが、家庭用電力の単なる一ユーザーとして、一言述べさせていただこう。

計画とかスケジュールというのは、何のために立てるのか。それは、あらかじめ「準備するため」である。準備して、事態に備える、あるいは、仕事をスムーズに立ち上げる。それを見越して材料や要員を頼んでおく。

逆に言うなら、スケジュールで一番大事なことは、準備できるだけの時間を前もってとって公表することである。準備に1時間かかる作業を、5分前になって指示されても、誰もついて行けない。もう一つ大事なことは、「やる」と計画したら、多少遅れてもよいからきちんと「やる」ことである。「やるかやらないか、その場にならないと分からない」では、やった準備作業が無駄になってしまう。だから、今回のやり方は失礼ながら「無計画停電」というに等しい。

電力を落とすということは、鉄道・交通信号から工場・商店の操業そして医療・保育まで、ありとあらゆるところに大きな影響が出る。それは電力事業者ならば誰でも分かっていることだ。でも消費電力のたぐいは気象にも左右されて、気まぐれで予測が難しい。そして、供給能力は限られていて、万が一にも消費が上回ったら、(家庭内で電気消費が大きすぎるとブレーカーが突然落ちるように)それこそ大規模停電がいきなり起きてしまう。--こういう、電力会社や監督官庁の不安は、もちろん分かる。

需給がバランスを欠きそうな時に、手立ては二種類ある。需要側に、自主的な節減努力を期待するか、供給側でコントロールするかである。そして、この国は後者のやり方をいつも好んでとってきたように思う。かつて米の不作の時もそうだった。

だが、わたしは需用者側のふるまいに期待するのが近代社会のサプライチェーンの姿ではないかと思う。そのためには、たとえば供給エリア毎に「使用量」と「供給可能上限」とを、リアルタイムに「見える化」すればよい。それこそ、メーターの形にしてネットで見せるだけでも効果があろう(どうせ制御監視室ではこの数値を見ているのだから)。今日の技術ならきわめて簡単に実現できる。携帯でちらとメーターを見て、やばい、この地域は上限に近づいてる、節電しなきゃ、と消費者が考える--これが実現されれば、「さすがは日本人だ」と世界中が感心するはずではないか。

あるいは、もう少し大がかりな手法で、電力需要ピークを下げるために、工場や職種を選んで2~3時間程度の時差勤務を要請する、というアイデアを提案している人もいる。前倒しと後ろ倒しのグループ間で最大4時間程度の差をつければ、ピークはかなり減ると考えられる。一種の大規模なサマータイム制である(これは電力会社だけではできないので、その監督官庁のガイドラインによる指示の形になろう)。

それでも、無責任で気まぐれな国民なんか信用できない、計画停電しか方法はない、というのなら、せめて以下の二点を提案したい。

・地域を18グループくらいに分けて、停電時間は1時間以内とする
・計画された停電は、必ず実行する。スケジュールは週単位で固定し、3日前に予告する

1時間以内とする理由は、各種の自家発電装置や無停止電源装置の容量を考えてのことである。3時間分もの容量をもつ事業所は多くあるまい(たしか、例の福島原発の緊急ディーゼル発電機が背負っていた補助バッテリも1時間分じゃなかったか?)。また毎日3時間分の燃料油を確保するのも困難だ。さらに人間の心理としても、1時間程度ならまだしも我慢しやすいだろう。

停電時間帯が毎日変わるというのも、困難さの大きな一因だ。これはせめて週単位で固定すべきだろう。そして、スケジュールは、先に述べたように、準備期間を考えて3日前には予告する。予告したら、もう計画は変更しない。これをスケジューリング用語で「タイムフェンス」と呼ぶのだが、ここが守られないから皆が困惑しているのだ。

むろん、たとえ1時間でも停電してもらっては困る、という事情も、あり得るだろう(とくに工場や食品関係では)。たとえばわたしの勤務先は大型コンプレッサーを多数、関東に工場を持つ企業に発注しているのだが、もう製造は出来上がってこれから出荷前検査という段階に来ている。ところが、24時間連続運転試験ができないから、出荷の見込みが立たないのだ。こうした事業所には、一週間連続給電するかわりに一日停電する、といった代替の選択肢が与えられるべきだと思う。

現在の「計画停電」のやり方では、停電する区域は事前に分からないし、どういう基準で決められているかも不明だ。ある企業は交渉して停電を免除してもらっている、などというまことしやかな話(根も葉もない噂だと信じたいが)も通用し始めている。このままでは、電力という公共財としての商品が、『利権』の対象になりかねない。そのような状況は、ぜひ避けるべきだと思うのである。
by Tomoichi_Sato | 2011-03-20 23:30 | リスク・マネジメント | Comments(5)

「ITって、何?」 第17問 IT業界で成功する秘訣はあるの?(その2)

<< パラダイム・シフト=IT産業は対話劇のシナリオのように発展する >>

「世の中ってなんだか不公平にできているのねえ。それじゃ、中小企業は永久に大企業に勝てない、ってことじゃない。」

--ところが、いつでもそうとは限らないところが面白いのさ。さっきもあげたように、一度は市場の5割以上を席捲した製品が没落してしまうことがある。

「ああ、そうだったわね! ねえ、どうして?」

--それはね、パラダイム・シフトのせいなのさ。

「あら、妙なことを言うわね。パラダイムってのは本来、科学哲学の用語よ。パソコンの投げ売りにどうして世界観が関係あるの?」

--ここでパラダイムとよんでいるのは、皆が物事を考えるときの暗黙の基盤のことだ。ITの場合は技術的な基盤かな。
 ITの世界は階層的な構造になっていて、お互いにある程度独立分業になっている。パッケージ・ソフトの下には(たとえば)データベース・ソフトがあり、その下にはOS(基本ソフト)、PCハード、CPU・・という風になる。そして、それぞれの層は独自に進化していくんだ。

「だるま落としみたいに、つみ重なっているけれど、上に乗ってるだるまはそのままで、下の方の木だけを入れかえられる、ってこと?」

--そう、ふつうはね。
 ところがね、すぐ下の基盤におおきな革新が起こってパラダイムが変わってしまうと、それまで立脚していたメリットが足元から崩れてしまう。

「それでだるまが落ちてしまうという話なの? なんだかよく分からないわ。例で説明してくれない?」

--たとえばね、昔々、1-2-3という表計算ソフトがあった。これはMS-DOSというOSの上でメジャーだった。キーボードからすべてを操作できて、画面には基本的に文字だけでできた表が並んでいく。早いし、そこそこ多機能だし、結構人気だった。
 しかし、OSのパラダイムがグラフィックとマウス中心のWindowsに移ってしまうと、1-2-3のキーボードを最大限活用した強みがひっくりかえってしまった。そして後発のExcelに席を奪われたんだ。
 ExcelはもともとApple社のMacintoshという、グラフィックスとマウス中心のOS用に開発されたものだった。よってたつパラダイムが違うんだ。

「パラダイム、ねえ・・」

--もともと、類似の機能を持った製品では、いったん優劣が決まった市場をひっくり返すのは至難のわざだ。だから別種の機能を発明して差別化をねらうんだね。これが進化の原動力で、新機能がソフトの使われ方・考えかた自体を変えてしまうほどのインパクトをもつ場合、新しいパラダイムの発明といっていい。

「あなたのいうパラダイムって、そうすると戦うときの土俵のようなものなのね」

--そう、土俵だね。
 じつは1-2-3だって、最初はそうやって登場した。もともと「表計算」というジャンルはApple II用のVisiCalcが発明したものだった。1-2-3はその中核機能をまねしながら、さらにグラフ機能やデータベース機能などを加えた「統合型表計算ソフト」として、新しくIBMが導入したPCの上で登場して、あっという間に市場を席捲してしまった。そして、その命運はMS-DOSというOSとともにつきることになったという訳だ。

「つまり、同じ土俵の上で逆転負けしたのじゃないのね。」

--そう。土俵自体がとりかわってしまう。これがIT産業の特徴だ。
 IT産業の市場争奪劇は、なんだか対話劇のシナリオに似ているとおもう。一人がある主張をする。別の人間が出てきて対抗する主張で圧倒する。それでけりがつくかと思うと、三人目が出てきて二つの対立点を乗り越えるような新たなテーゼを提出する。決して野球の試合のように同じラウンドのくり返しにはならないんだ。
 とくに、新しいパラダイムの発明とともに新しいジャンルの市場が生まれることで全体のパイが膨らんで行く。だから分岐独立の法則がなりたつのさ。

スケール・アップの法則

「そんなに簡単にパラダイムって発明できるの? ようするに世界観でしょ、普通そんなにすぐ乗り超えられないものだと思うけど。」

--そりゃ、この世界には伝説的な天才が何人も出てるからなあ。現在のユーザ・インタフェースの原形を考えたアラン・ケイ、Wordの産みの親チャールズ・シモニイ、unixをつくったトンプソンとリッチー・・あのビル・ゲイツだって、本当の天才は商売の抜け目なさにあったのかもしれないけれど、でもBASICを当時の小さなPCに実装したときはやっぱり一つの発明だったといえるだろうな。

「そうやって、天才が現れては新しいパラダイムを創造して、世界を変えていったと信じている訳ね。」

--やはり、そうとしかいえないもの。

「馬鹿みたい! いっちゃ悪いけど。」

--おいおい、なんだって?

「怒ったのなら、ごめん。でもね、そんな、天才が世界を動かして行くなんて、19世紀ロマン主義みたいなことを、いまだにIT屋さんが信じているんだとしたら、ずいぶんおめでたい幼稚な状態だと思うわ。」

--幼稚! 言ってくれるじゃないか。じゃ、君には何かい、パラダイムの進化のしかたについて、別にきちんとした説明でもあるんだろうな。え?

「別に無いわよ。でもね。さっきの数式をいじり回してへんてこなモデルを引き出していたあなたはどこにいったのよ? 天才がいるのならいてもいいわ。でも、その天才が登場できる必然というのがどこかにあるべきよ。」

--何をいいたいのかぼくにはわからないね。

「私はね、ただ、天才が偶然現れて歴史を動かして行く、というような『天才史観』には賛成できないだけ。一緒に検討して見ましょうよ。さっきのだるま落しだっけ? あれって、ほんとに最初から横に切れ目が入っていたの?」

--??

「土台、つまり構造の下の部分が変わったから、上に乗っている上部構造もひっくり返った、って説明だったでしょ。ITってそんなにきれいに階層の分かれた仕組みだったの、最初から?」

--・・うーん。歴史を最初からたどってみると、そうともいえないかもな。本当に最初に弾道計算の計算機が発明されたときは、ハード・ワイヤードだった。

「ハード・ワイヤード。・・ハード・ボイルドとはちがうものよね。」

--すべての計算ロジックが直接ワイヤー(電線)で電気回路に組み込まれているものを、ハード・ワイヤードと呼ぶ。そこには、ハードウェアとプログラムの区別はなかった。その区別ができたのは、天才フォン・ノイマンが現れて、命令を機械語としてデータと同様に保存しようと考えたときからだった。

「ふんふん。つづけて。」

--続けて、って、何を。パラダイムの歴史をかい?

「うん。ただし天才はいいから」

--やれやれ。プログラムは当時一度限りだった。しかし、計算機の状態を同時にモニタするプログラムが現れて、それが進化してOS=基本ソフトになった。さっき名前を出したブルックスは、IBMではじめて汎用的なOS/360をつくった責任者だ。
 このころまではね、プログラムは計算機メーカーがつくるもんだった。しかし次第に複雑化するに従い、第三者にも技術を公開して作らせるようになった。このときはじめて、ソフトウェア産業というものが生まれた。計算機それ自体は、ソフトウェアと区別するためにハードウェアと呼ばれるようになった--何笑ってるんだい?

「だってへんてこな説明するんですもん。Hardwareって金物のことで、古くからある英語よ。Hardware shopといえば金物屋。コンピュータ屋さんがそれを勝手に転用したんでしょ。HardをもじってSoftwareという言葉を作ったのよ。」

--あ、そ。まあ、それはともかく、プログラム自体も生産性を上げるために、高級言語と呼ばれるものが登場してきた。それから、データ量が巨大化すると、高度なファイル・システムが必要になって・・。

「だいたいわかったわ。あなたも、もう、わかったでしょ?」

--何が? ・・ははあ、階層構造は最初からあったのじゃなくて、次第に生まれてきたということかい?」

「そうみたいね。出てくる言葉はよく分からないけれど、でも聞いてると、ITの歴史って分化の歴史だわ。」

--言われてみればそのとおりだな。

「じゃあ、何がその分化を促したか考えて見ましょうよ。」

--まいったな、先生と生徒が逆転だ。天才の発明が、じゃ納得しないんだな?」

「納得しない。」

--やれやれ。ちょっと考えさせてくれ。基本テーマは計算機の進歩だ・・進歩すると分化する・・・・だから分岐増殖なんじゃないか。

「計算機の進歩って何よ?」

--進歩は進歩さ・・・・でも、そもそも進歩ってなんなんだ・・・・・? 量的拡大かな? ・・・・・量的に拡大すると・・・・・・・・・・拡大すると効率化が必要で・・・・・・・・・・・・・・・・・・・まてよ、そうか・・。
 わかりました、先生!

「わかったの? じゃ、答えを言ってください。」

--ITってのはシステム、つまり目的と機能を持った組織なんだ。ところがね、システムの取り扱う量が大きくなると、そこに分化の必要性が出て来るんだ。その方が効率的だから。

「もうちょっと説明して。」

--えーとね、会社組織でたとえると分かりやすい。会社が小さいときはみんな何でも屋だ。あまり組織はいらない。君んとこの事務所なんかそうだろ? でも売り上げが増加して人が増えて来ると、たとえば人事課と総務課と営業と制作と、という風に専門職を立てた方が良くなる。
 みんながちょっとずつ分担していた仕事を集めると、専門職一人分の量になる。そういうときがたぶん別れ目なんだ。そうしてしだいに企業組織は分化をはじめる。総務課ができて、それが人事課と経理課に分かれて、経理は会計と財務に分かれて・・
 ITの世界でも、じつは同じ事がなりたつ。計算が複雑になれば、データとプログラムは独立化した方がいい。プログラムが多くなれば、モニタが必要になる。データが増えれば高度なファイルシステムが欲しくなる・・。

「そうやって自分自身の中から子供を産みだして、その子どもが独立していくのよね、きっと。どう? 天才が気まぐれで歴史を動かしているんじゃないでしょう?」

--分化を実現するためのアイデアは、やはり天才の発明さ。

「別に天才はいてもいいのよ。でも分化を促す背景が別にあるんだわ」

--そうだね、ITでは『量的な変化が質的転換をもたらす』という法則が働きやすいんだ。
 いや、分化の必要性だけじゃない。逆にスケールの量的拡大が新しい事を可能にする、ってこともあるんだ。基本的に計算機性能てのは倍々ゲームで増えて行く競争にかりたてられて動いている。しかし性能が10倍になると、これまで不可能に近かった機能が実用に近づく事が多い。たとえば日本語ワープロはパソコンがかな漢字変換に耐えられる性能になってはじめて商品になり得た。こんな例はいくらでもある。

「じゃあ、その、量的変化が質的転換を、ってのを”スケール・アップの法則”と名付けて上げましょう」

--はい、先生。
 そうだね、これはいい視点かもしれない。会社も、構成員の数が増えると組織が分化したり、あるいは管理階層が増えて硬直化した、組織が質的に変わってしまう傾向があるよね。情報システムも、あつかうデータ量の桁がふえると設計の基本から考え直さなくちゃならなくなる。そもそも目的と内部構造を持つようなシステムにはみんなあてはまる法則なんだと思う。

「中小企業も社員が200人を越えると安定性が出て来るから、かっちりした会社組織をととのえる必要があるんですって。会計士の先生がいってたわ。」

--200人ていうのは業種によるんじゃないかな。製造業とはそうかもしれないけれど、ソフトウェア産業ではもっと小さいような気がする。でも、さっきもいったとおり、どんな組織であれ、安定して存続し成長することのできる臨界点があるようにおもう。
 市場の小さな業界や、競争が全国区になるサービスなんかは、小さい企業が生まれても大手にすぐ弱肉強食でつぶされてしまう。そうなると、かくれた天才によって新しいアイデアやパラダイムが生まれても、育つチャンスが少ない。

「買い手の側の価値観が金太郎飴でみんな同じ場合だってそうよ。」

--ほんとだね。日本なんかそうなりやすい。だから、日本ではITの創造性が乏しい、なんていわれちゃうのかもしれないね。

             (この話の登場人物はすべて架空のものです)
by Tomoichi_Sato | 2011-03-16 22:08 | ITって、何? | Comments(0)

休めない人々

あれほど多くの人を路上で見たのは初めてだった。職場から家まで歩いて帰る途上、横浜の海沿いの国道は歩道を歩く人たちで一杯だ。車列も満杯だが、こちらは渋滞がひどくて青信号でもぴくりとも動かない。津波警報が出ている時に、こんな海抜0メートルの道を歩くのは愚の骨頂だ。それは承知しているが、ウォーターフロントのオフィス街から逃げ出す道はこういう道しかないのだった。

それでもわたしは帰ることができただけラッキーだった。職場にはまだ多くの同僚が不安な気持ちを抱えたまま、夜明かしを覚悟で残っていた。交通機関がバスをのぞいて一切ストップしていたからだ。男達はそれでもまだいい。女性、とくに小さな子どもを家や保育園にあずけて働きに来ている女性たちの心配は尋常ではない。携帯電話が機能マヒし、固定電話もろくにつながらない状況で、どうやって子どもの安全を確保するのか。

わたしが帰れたのも偶然の結果にすぎない。たまたま職場にいて出張にも外出にも出ていなかった、たまたまエレベーターにも閉じ込められなかった、たまたま家も近くだった、たまたま面倒を見るべき直属の部下もほとんどいなかった、そして、たまたま国道を歩いている時に津波が襲ってこなかった・・それだけのことで、自分の意志や才覚とは一切関係がない。自分は自然災害には全く無力なのだった。

たまたま偶然のことで帰る人、帰れない人が分かれてしまう。しかし、帰らずに留まらなくてはならない人もいるのだという、当たり前のことに気がついたのは、帰路を歩き出してしばらくたってからだった。

帰らずに留まる人とはどんな職種の人たちか。たとえば、保育園の保母さんがそうだ。母親達が迎えに戻れぬうちは、幼児を施設に預かったまま留まり続けなければならないだろう。彼女たちだって自分の住居や家族がひどく心配なはずだ。だが、職業的な責任上、持ち場を離れられないのだ。

それに消防署の職員だってそうだ。横浜は、ビルから見えた範囲では火事の煙は見えなかったが、かりに火の手が上がったとしても、こんな渋滞した道でどうやって駆けつけるべきか。それから、発電所・ガス会社・電話局・鉄道会社の人たちもそうだ。こうした「ユーティリティ」事業の運転・保全の人達は、たとえ機能が停止しているように見えても、中では必死に回復に努めているにちがいない。わたしが高層ビルの階段を帰るために歩いて下りる最中も、ビル保全の人は階段を逆に駆け上っていった。彼らは帰りたくても帰れず、休みたくとも休めないのだ。

それからもう一種類、休めない人たちがいる。会社や組織の「責任者」の人たちだ。部下や設備の安全に責任を持つ人たち--全体の状況を把握し、全員の無事を確保するまでは仕事から降りて休めない。ちょうど船長が総員の退去を確認できるまで船を下りられないように。

わたし達の社会は、こうした保母さんや駅員や運転員や保全マンや事業所長・店長などの無名の人たちの努力によって、かろうじて支えられているのだった。それに比べれば、大企業の中間管理職でござい、と偉そうにしている自分自身など、いたって居なくたって何の変わりもないではないか。

いや、あの人たちだって仕事で給料をもらっているじゃないか。一瞬、そう思った。だが、制服にヘルメットをかぶり、交差点に立ってあたりを警戒している若い消防署員の、不安そうな顔を見て、思い直した。彼らは給料のためだけに働いているのではない。誰だって人は「パンのみに生きるにあらず」ではないか。それに、わたし達の社会は、彼らの危険と不安と責任感に見合うだけの給料の差額を払っているだろうか? ほんの一瞬でも、危険をお金で差し引きしようと考えた自分が、ひどく恥ずかしく思えた。

サービスという仕事は、ある意味で精神的に引き合わない仕事である。サービス業の中核は、「リソース」の提供と保守だ。「仕事の最小単位--アクティビティの構造を学ぶ」でも書いたように、リソースとは、何らかのプロセスの中にあって必要とされるが、アウトプットに組み込まれずに、作業が終わるとリリースされるような存在である。それは「人」Human Resourceの場合もあるし、場所や設備機械の場合もあるし、水道光熱を供給する仕組みの場合もあるし、交通や通信などシステムの場合もある。またバックアップとして、緊急時や異常時のみに必要とされる種類のリソースもある。保育、鉄道、電気、ガス、電話などはみなリソース提供のサービスだ。消防や医療もまた、異常時のためのサービスである。

そしてサービス業が精神的に報われないのは、こうしたリソース提供の仕事は、「100%動いていて当たり前、機能しなかったらガンガン責められる」扱いを受けやすいからだ。その昔、初めて電力で灯がともされた頃は、電気は貴重だったろう。あれば嬉しかっただろう。だが世の中が発展し、いつの間にか電気は通じて当たり前に感じるようになった。どんなものもそうなのだ。初めてWWWとMosaicが登場した頃、ユーザは皆、その希少性に熱狂した。今は Webサーバが落ちればとたんに文句を言われる。ネットの維持は「当然の仕事」になったのだ。

この天災を目の当たりにして、Twitterをはじめ多くのチャネルを通じて善意ある情報や申し出がなされている。そのことはわたし達の社会にも健全性が残されている証拠であり、うれしい。しかし、溢れるほどの沢山の『善意』と、『当然の仕事』観のギャップに時折驚くこともある。

海沿いの国道から離れて自宅の方に向かう道を曲がった時、その前から頭の中で生まれては消えていたメロディの断片が、急に全体像をとって鳴り響いた。

 凍れる 月影 空に冴えて~ 
 真冬の 荒波 寄する小島

それはなぜか、『灯台守の歌』だった。海の孤塁で、文明の小さな光を守る、古い時代のロマンチックな歌を、なぜ思い出したのかわからない。だがそれは、揺れ動くわたし達の社会に、確かに必要なもののシンボルなのだった。

* * *

今回の地震・津波で被災された方々が一日も早く安心した生活に戻れますことを、また不幸にも亡くなられた方々のご冥福を、心からお祈りいたします

  佐藤 知一
by Tomoichi_Sato | 2011-03-12 18:32 | ビジネス | Comments(2)

「ITって、何?」 第17問 IT業界で成功する秘訣はあるの?(その1)

<< ITビジネスを支配する諸法則 >>

「なんだか数式まじりのややこしい話だったけれど、私の質問とかみ合っていなかったことだけはたしかね。私は会社の大きさの話なんかじゃなくて、IT産業がどういうパターンで発展してきたかっていうことを聴きたかったのよ。それが分かれば、世の中がITってものをどう理解して、どういう価値を認めてきたのかが分かるかもしれないと思ったのよね。」

--ごめん。数式なんかはどうでもいいのさ。今の議論のポイントは、IT企業のサイズ分析をしてみると、この産業が決して直線的な発展ではなくて、分岐増殖型の道をたどってきたことが分かる、ということなんだ。一つの進化の直線上で自然淘汰と生存闘争を行うんじゃなくて、分岐して新しい生存圏を開拓しながら広がっていく。これがIT産業の発展の姿なんだ。そして、幸いまだ弱肉強食の成熟市場にも至っていないことが教訓だ。

「うーん・・。ねえ、じゃあもし世の中がまだそれだけの勢いで、ITにお金を使い続けるのなら、今からでもITビジネスの会社を作って独立すればもうかるんじゃない? 分岐増殖の法則なのならば。あなたも、やりなさいよ。」

--あのね。簡単に言ってくれるけれど、やれば誰でももうかるようなビジネスがこの世にあってたまるかよ。バブル時代の不動産業者じゃあるまいし、それなりの売り物がなければ、商売になりはしないさ。

「あら、ないの? IT業界で成功する秘訣なんてないのかしら? あなただって会社でずいぶんシステムを作っているんだから、売り物にするべきよ」

--そりゃ作っているけれど、ほとんどは自社向けのシステムさ。うちの会社のやり方に従ったシステムを隣の会社に持っていっても、そのまま売れるわけじゃない。
 よそに売るためには、きちんとしたパッケージにしなければならないんだ。機能に多少は汎用性を持たせて、マニュアルもきれいにそろえて、サポートや教育の体制も作らなければいけない。

「だったら、すればいいじゃない。」

--あのね、Brooksというひとが、自著「人月の神話」の中で、こんなことを言っている(図)。
 ┏━━━━━┳━━━━━┓  
 ┃     ┃     ┃  
 ┃プログラム┃プロダクト┃ │
 ┃     ┃     ┃ │
 ┣━━━━━╋━━━━━┫ │(3倍)
 ┃システム ┃システム ┃ │
 ┃部品   ┃プロダクト┃ ↓
 ┃     ┃     ┃  
 ┗━━━━━┻━━━━━┛  

    ──────→
     (3倍)

 この図で左上にある「プログラム」は、普通のコンピュータのプログラムで、自社で使うために作った、単体の機能を持つものを指している。
 これををよそに売るために製品としたものが、右上にある「プロダクト」だ。基本的な機能は同じだけれど、信頼性を高めるためのテストや、分かりやすいマニュアル、経常的なメンテナンス体制などのために、必要とされるマンパワーは、実に三倍にものぼる。

「3倍とは、またずいぶんふっかけたわね。」

--オーバーに聞こえるかもしれないけれど、お金を取って売る以上は責任が生じてくる。社内のだれかが作ったものなら、どこかにバグがあって計算が違っても、“いや、ごめんごめん”ですむかもしれない。でも商品だったらそうはいかないだろ?

「まあ、お金を取る以上は、たしかにアマチュアの作品なみじゃあ困るわね。」

--ところで一方、左下にある「システム部品」は、同じプログラムではあるけれども、それをもっと大きなシステムの中で組み合わせて使えるような部品にしたてたものだ。目的は社内用だが。

「なあにそれ。言ってることがわかんない。」

--そうだな、どういえばわかるかな。
 たとえば、君が自分用に英日の自動翻訳ソフトを作ったとする。

「ちょっと待ってよ! わたしはね、機械翻訳なんて基本的に不可能だし無意味だと、つねづね思っているの。少なくとも印欧諸語と日本語との間なんて使い物にならないし、まったくナンセンスだわ。そもそもね、IT屋さんって・・」

--タ、タンマ。ご高説はいいけど、これは単なるたとえ話なんだからちょっと置いといてくれないかな? まずい例だったかもしれないけれど我慢してもらって、君がとっても素晴らしい英日翻訳ソフトを作ったとする。英文をタイプ入力すると、画面にすかさず日本語の翻訳が表示される、と。

「わかったわよ。それで?」

--これを君は自分用のツールとして使っていた。ところが、まわりの人間が、これはよくできているから、電子メール・サーバのソフトに組み込めないかと提案する。英文で電子メールが外から来ると、自動的に翻訳して、日本語のメールとして宛先にくばってくれる仕組みだ。ね? これは、電子メール・システムという大きなソフトの一部として、部分品として動いてくれる。こういうものをシステム部品と呼ぶんだ。
 システム部品は、基本的な機能は元のプログラムと変わらないけれど、他のサブシステムとのインターフェースの整合性とテスト、共通のデータベース構造の利用、設計文書の整備などのために、手間はやっぱり単体プログラムの開発のおよそ三倍かかる。

「また3倍なの?」

--それが図の下向きの矢印の意味していることだ。
 右下はその二つが複合したもので、「システム製品の中で使う部品」を意味している。これを作るには3倍×3倍で、結局10倍近くのマンパワーがかかることになるわけだ。言っておくけれど、基本的には同じ機能のプログラムなんだぜ?
 この効果を念頭におかないために、たくさんのプロジェクトがスケジュール遅れの泥沼に陥る羽目になった、とBrooksは主張している。自社向けにプログラムを作ったことがあるからといって、世の中に売れる製品が簡単に作れると思ったらとんでもない間違いなのさ。

ネットワーク外部性の法則

「でも、それって自社用のソフトをパッケージ化して売る場合の話でしょう? たんなる受託開発のビジネスの場合はもっと簡単に競争できるんじゃないの?」

--単なる受託開発の請負業で成長するのは、じつはかなり難しいんだ。というのは、この業種は能力の差が見えにくいからさ。能力やアイデアよりも、どうしても業務知識や経験の幅が売り物になる。すると、建設業と同じで、発注側はどうしても過去に実績のある方を選びがちだ。ネットワーク事業ほどではないけれど、やはり大きい企業ほど「信用できそう」な気がする。

「大きい方が能力があるの?」

--実際のプロジェクトになれば、じつはあまり大差はないね。とくに、初期のシステム分析のフェーズは属人性の方が強いから。大企業だといっても、過去に類似の業務を経験した人間がかならず担当者にアサインされるとは限らないし。
 それに、大企業はプロジェクト・マネジメント能力を売り物にしているけれど、その内実はけっこう個人任せで、まだまだ技術というよりスキルのレベルにとどまっていたりする。
 しかし、こういう「信用」というやつはなにせお布施みたいなもんだから、どうしても大小の企業が争うと大の方が勝つ、弱肉強食になりがちなんだ。

「持てる者はますます富み、持たざる者はますます奪われるであろう・・福音書のマタイ伝にでてくる言葉みたいだわ、まるで。
じゃあ、受託開発の業種に小さい企業が参入しても勝ち目はないのかしら」

--かなり特殊な業界のノウハウでも持っているか、あるいは革新的なパッケージでも抱えていれば別だけれどね。この業種で安定して存続し成長するためには、ある程度の大きさが必要になる。つまり、「臨界点」=原子力でいうクリティカル・マスがあるようにおもうね。

「でも、あなたがいっているのはソフトの開発でしょう? 通信ネットワークのサービス企業とかにはあてはまらないはずだわ。」

--ところが、ここにも「ネットワーク外部性」という、大きい方が有利だという法則がある。

「なにそれ。」

--ネットワーク外部性というのはね、ネットワークの価値は、その利用者数の2乗に比例する、という法則だ。いや、2乗以上だ、という説もある。つまり利用者数が2倍になると、価値は4倍以上になり、利用者数が10倍になると、価値は100倍以上になるというんだ。だから、買い手はどうしても大きい方を選びたくなる、ということさ。

「ここでも、持てる者はますます富み・・って具合ね。でも、どうしてそうなるの? たしか経済学じゃ、収益逓減の法則だかなんだかで、売上が増えても利益は比例しては上がらないはずじゃなかったの?」

--収益逓減の法則ってのは、利用者一人あたりの利益に関して言っているわけで、その点ではあたっているのかもしれない。けれども問題なのは、利用者の数がどれだけのスピードで増えて行くかの方にある。
 ネットワークというのは、2点間をむすぶサービスだ。結ばれる線というか、組み合せの数が多ければ多いほど利用者にとってメリットが多い。2点を結ぶ線の数は、数学では点の数の2乗に比例する。
 たとえばもし、携帯電話がそれぞれの事業会社内でしか通じないとしたら、誰だって一番大きい方に参加するだろ?

「でも、現実には他の会社の電話機とも通じるじゃない。」

--だから携帯はある程度、価格競争になってしまった。これを避けるため、各社とも独自のサービス開発に必死だ。その成功例がi-Modeだったわけだ。
 ネットワーク事業は外部接続性が命になる。この場合は図体の大きい、接続「させる」側の発言力が大きくなってしまう。結局大きい方が有利なのさ。

ロック・イン現象

「なんだかあなたの解説って夢がなくてつまらないわね。」

--悪うござんしたね。この業界に十年以上も身をおいていると、いろんな栄枯盛衰を見て、すれっからしになるんだ。飛ぶ鳥を落とす勢いだった企業が、あっという間に失速して、イカロスよろしく墜落していくのも何回か見たし。

「たとえば?」

--そうだね、パソコン・ソフトの世界でいえば、太古の時代のVisiCalc、MultiPlan、CP/M、それからdBASE、WordPerfect、Lotus 1-2-3、Netscape・・もう、枚挙にいとまがない。どれも一世を風靡して、事実上の業界標準とまでいわれたものばかりさ。

「どうしてだめになっちゃったの?」

--どうしてだと思う?

「知らないからきいているんじゃない、いじわるね。・・えーと、競争相手に負けたからじゃないの? コストとか、品質とか、サービスとかで。」

--ライバル製品に負けるといったって、一度は市場の5割以上を席捲したものばかりだよ。簡単にはひっくり返らない。プロ野球で今年は巨人が勝つか阪神が勝つか、みたいなものじゃない。なにより、パッケージ・ソフトの市場には「ロック・イン」の性質がある。

「何それ?」

--いったんある方向に動きはじめると、逆方向にはロック=すなわち歯止めがかかって、後戻りしにくい現象。自転車のチェーンなんて前方向にしか回らないようになっているだろ? あれさ。
 だからね、最初に甲乙ふたつの製品があって、商品力がほぼ互角でも、どちらかの製品が優勢になると、強い方がますます加速度的に強くなるんだ。カウンターバランスが働きにくいからね。

「またなの、ここでも。」

--どうしてそうなるかというと、パッケージ・ソフトの製品は買手側にいろいろな付随的投資を要求するんだね。たとえばユーザ教育・トレーニングの投資。いったんあるソフトの使い方を習得すると、別の製品の使い方を勉強し直すのは無駄に感じられて抵抗が大きい。他のシステムと組み合せて使う時にも、インタフェースの構築に投資する事になる。こうした資産は簡単にきりすてられない。
 それから、データ資産の問題もある。データの保存形式はソフトごとに異なる事が多い。そうなると、ソフトをのりかえるためには、いったん蓄積されはじめたデータを全部コンバートするか、捨てるかしなきゃならない。

「そういえば、個人で使うソフトだって、友達同志でファイルを交換できる方が便利ね。」

--だからどうしても人と一緒のソフトを買おうか、となってしまうだろ? マニュアル本とかも、どうしてもたくさん売れているソフトから先に出版される。アドオン・ソフトも同様さ。雑誌メディアの情報も多くなる・・という訳で、市場のシェアが大きい方がどんどん強くなってしまう。

「でも・・なんだかその説明っておかしくない? ワープロだって何だって、二つどころか何種類も世の中には売っているわよ。」

--そう。ところがね、マーケティングの世界では、いつも結局トップの2者の対決に収束していくんだ。ある程度成長した市場には二人分の席しかないんだね。

「それで、機能がいい方が勝つのね。」

--そうでもない。機能・価格・タイミングの中で一番大切なのはタイミングさ。
 さっきもいったように、市場にはロック・インの性質がある。だから、タイミングが一番大事になる。適度に優れた機能を持つ製品を、早いタイミングで市場に出し、しっかり宣伝する。マーケティングが大事なんだ。市場を征服するのは、プロの目からみれば機能はおとっているが、タイミングがうまかったので勝った製品がほとんどさ。

(この項つづく)
by Tomoichi_Sato | 2011-03-09 00:21 | ITって、何? | Comments(0)

試験は誰の責任か - 人材のサプライチェーンマネジメント再考

もう何年も前のことだが、東京大学教養学部の男子学生が、同じ学年の女子を包丁で何度も刺して重傷を負わせ、殺人未遂で逮捕されるという事件があった。理由は恋愛感情のもつれによる逆恨みだったらしい。若者にありがちと言えば言えるが、まことに幼稚かつ愚かな犯罪である。

「その学生はすぐに退学処分にすべきだ」とわたしは思った。人間には、やっていいこととやってはいけないことの区別がある。お勉強の上手下手より以前に、まずその事を理解しておく必要があるのだ。たぶん東大生の多くは、入試をパスすることに、それまでの青春のほとんどを賭けてきたであろう。だとすれば『退学処分』は最も戦慄すべき事態にちがいない。人を刺したら「自分の人生を失う」という、ショックに近い感情によって、その教訓は全学生の心に残るだろう。「人を刺したら犯罪」くらいのことは、東大生でなくたって誰でも知っている。だが、頭で“知っている”だけでは足りないのだ。感情を込めた体験があって初めて、教訓が“分かる”のである。

ところが当時、ニュースや新聞を見ていても、この事件の後で東京大学は当学生に対する処分を何ら発表しなかった。一罰百戒のせっかくの機会を、この大学は逃してしまった。もしかしたら、「裁判で有罪が確定するまでは処分保留」という判断でもあったのかもしれぬ。しかし学生運動のデモかなんかで逮捕されたのならともかく、この刑事事件では犯意は明らかであった(結局、この学生は有罪判決を受けている)。それでももし万が一、その学生が無罪になったら復学してやれば良いだけである。『復学』というフレキシブルな制度はそのためにあるのだ。

世の中には東大に合格するよりも、もっと大事なことがある。これは落ち着いて考えてみれば当たり前だが、その「当たり前」の条理の灯を、目先の損得や感情のつむじ風で吹き消そうとするのが世間である。東大があの時もっと倫理において毅然と対応していたら、世間のモラルも一瞬はしゃんとしたかもしれぬ。

教育のシステムとは社会における人材のサプライチェーンである。ところが、このサプライチェーンがあちこちで歪みを生じ、きしんでいる。京大の入試でカンニング事件があったと言って世間はむやみに騒いでいるが、「たかが入試じゃないか」という感想はあまり聞かれぬようだ。試験というのは、教育ではない。入荷検査が『製造』ではないように。心配するなら、教育の方を心配すべきだ。日本の教育システムをサプライチェーン・マネジメントの観点から見ると、すべての工程(教育段階)に共通する、おかしな矛盾がある事に気がつく。それは、製造工程と検査工程の逆転である。

ふつうの工場だったら、製造した製品は、自分が検査する。検査のポイント(品質項目)は自分で決める。検査ではねられたら、修正に戻すかおシャカにして、出荷しない。出ていくものの品質については、自分のブランドの名前にかけて保つ。これが製造業における普通の感覚であろう。なお、部品材料を入荷したら、その時点で検査を行う場合もある。その場合も通常は員数と外観チェックか、せいぜい寸法確認程度で、鋳物にスが入っていないかいちいちX線で検査したりはしない。入荷品の品質に問題が多い場合は、自ら仕入れ先に出向いて品質指導をする。

サプライヤーの側で出荷検査をして、それを受け入れる側でまた入荷検査をする、というのは、明らかに二重の手間である(よほど輸送工程にリスクがあれば別だが)。では、どちらか一方を省くとしたら、どちら側を省くべきだろうか? 答えは明らかだろう。入荷側である。検査データというのは製造工程の質を向上するために使われなかったら、意味がないからだ。検査と製造工程は一つの思想の元にマネジメントされなければいけない。製造者は検査と出荷品の品質にオーナーシップを持つ。だから先進的な企業では「検品レス」といって、入荷検品を全く省くケースも出てきている。サプライヤーをそれだけ信頼し、また信頼できるようにマネージしているのである。

こう考えてみると、日本の教育システムのおかしな点がわかるだろう。この人材のサプライチェーンでは、自分が製造したものを自分がきちんと検査していないのである。“そんなことはない、各学期に期末試験をしているじゃないか”と先生方はおっしゃるだろうか? じゃあ、東大でも京大でもいい、目立つ「一流校」に合格した生徒を、自分の権限と責任で落第させる勇気がおありだろうか。父母の猛然たる抗議にもゆるがず対応できる、明確な教育スタンスを持つ高校など、おそらく殆どありはすまい。

だが、これは高校の先生方のせいではない。サプライチェーンの下流に位置する購入側、すなわち大学がいけないのだ。大学が出荷検査に信を置かず、自分でいちいち詳細に検査すると言っている。じゃあ、その大学の製造工程はどうなっているのか。わたしは大学3年生を相手に後期授業を行っているから知っているが、大学3年後期というのは就活のおかげで、学生はたいてい気もそぞろである。授業になんか集中できる訳はない。そして、その理由は、企業が製造も終わっていない人材を、はやくも入荷検査のふるいにかけようとするからである。

おわかりだろうか。このサプライチェーンでは、検査工程と製造工程の間にあるべきポジティブな改善のフィードバックループが失われているのである。製造者が検査の所有権を失っているからだ。そして、この事態をなんとかしたいなら、まずチェーンの最下流から直していかなければいけない。その責任は企業の側にある。企業が、「卒論を書いてちゃんと大学を卒業した者だけを採用の対象にする」と宣言すれば済むだけだ。就活は、卒業式の前後に始める。そうすると就業開始は夏頃になるかもしれないが、それでひどく不都合な会社などないはずである。大学は落ち着いて教育に専念できる。そして入試も、高校に信を置いて推薦入学が中心になる(現に、今ではAO入学が全体の50%を超えている)。そのかわり高校の側も自分の検査と製造に責任を持つようになり・・

むろん、この仕組みが働くようになるためには、一つの条件がある。それは、検査ではねられた学生も、妙な烙印を押されずに再履修したり大学をやめて働いたりする道が確保されるということだ。いわばサプライチェーンのフレキシビリティー(セーフティーネット)があって初めて機能するのだ。そしてこの場合も最終責任は企業の側にある。企業は大学未了の、つまり「高卒」の人間を消耗品としてではなく評価し、使う道を用意しているだろうか? わたし達は有用な人材を海に捨てていないだろうか。

春は希望の季節である。あらゆる生命が再び芽吹く時期だ。わたし達は検査と選別ではなく、「育てる」ことにもう少し熱意を込めるべきだと信じている。


(関連エントリ) 「人材のサプライチェーンを正すには
by Tomoichi_Sato | 2011-03-05 09:14 | 考えるヒント | Comments(1)