スタートページ主張・講演マーフィーの法則

Murphyology on Information Technology (vol.1) 1990s

昔,このようなものを作って精神安定剤にしていました。汎用コンピュータ全盛時代のものですから,若い人にはチンプンカンプンでしょうが,われわれの年代にとっては,苦しくてもファイトに満ちた時代の記念碑とも思えるのです。それで消さずに保存しておきます。

なお、比較的新しいものは、Vol.2に掲載しております。

次の少なくとも一つに該当するかたはご遠慮ください(^o^)。

  1. レガシー時代の情報システム部門の経験がない人
  2. 経営に携わった経験のない人
  3. お仕事で忙しい人

「マーフィーの法則」がマーフィーの法則の発生を促す原因になる。

トラブル回避のためのいいわけ。このような「法則」は,単に揶揄して楽しむためではありません(ホンネでは楽しんでいる?)。また,自社での状況を他社にも見出して安心するための精神安定剤でもありません(現実には,この効果が多いようです)。このような法則が作用するのを回避するための問題意識を喚起することが目的です(ホント!)


情報システム部門の事大主義


昔,コンピュータが導入された頃には「電算室」などと呼ばれたが,その後,いつのまにか「計数管理部」になり「情報システム部」になった。さらには「経営戦略情報システム管理部」と名乗ろうとしている。ここに情報システム部門の事大主義の片鱗がみられる。この部門が他部門と違和感があるのは,このへんに起因しているのかも知れない。

「情報」「経営」「戦略」「管理」「システム」を情報システム部門の5大慣用句という。どのような言葉にも付けられるが,特別な意味を持たないのは「根岸の里の侘住居」の類である。

では,これらの単語はどのような意味を持つのだろうか。
 「情報」とは,情報システム部門が取り扱う一切のものを指し,それ以外のものは情報であっても「情報」とはいわない。コンピュータに入力する残業時間のデータは立派な情報であるが,競争会社が新製品を発表しそうだなどというニュースはコンピュータに入らない限り情報とはいわない。すなわち,情報とはコンピュータ処理の原料と製品(もし製品といえるものがあれば)のことである。
 「管理システム」について考える。その名称のつく業務の実際の内容は,販売「管理システム」とは請求書発行処理のことであり,人事「管理システム」とは給与計算のことである。すなわち,「管理」や「システム」とは,ある部門の業務を機械処理をする場合に使う接尾語であり,一般用語としての管理やシステムとは関係がないことがわかる。
 「経営情報システム」とは,MIS(Management Information System )の日本語訳である。このコンセプトは60年代に,ともかくすべてのデータをコンピュータに入れておけば,経営に必要な情報は即座に取り出せるので,中間管理層は不要であるといわれたものである。ところが,その後の経過をみるとこの発想はMYTHで終わり,OLの省力化になっただけで,結果としてMISSであったというイワクつきの用語である。すなわち,「経営」とは,「失敗の」とか「幻想の」とまではいわないまでも,単純業務のことであるとしてよい。
 「戦略的情報システム」はSIS(Strategic Information System)である。80年代後半から90年代初にかけて,情報は企業競争の武器であり,企業戦略に情報技術を活用することが,サバイバル競争に生き残る手段であると喧伝された。その事例の多くは,取引先と企業間ネットワークを構築しオンラインでデータを交換することにより,より顧客指向の戦略を実現することである。
 ところがSIS先進企業に聞くと,それらの情報システムは,とくに「戦略」を意識したものではなく,自社や取引先の便宜を図った結果がこうなったのだということになり,「振り返ればSIS」のような言葉も出てきた。現在では,BPR(ビジネス・プロセス・リエンジニアリング)に置き換えられ,SISという用語はキャンペーン後数年で死語になった。すなわち「戦略」とは「短命の」の意味であり,内容は通信回線を利用してデータを交換することである。
 以上から結論すると,「経営戦略情報システム管理部」とは,悪く解釈すれば「短命の幻想のコンピュータ処理を担当する部門」であり,好意的に解釈しても「通信回線を用いて単純業務のコンピュータ処理をする部門」である。
 ところで,経理部門はどうして「経営戦略資産管理部」といわないのだろう?

(昔)カードの穴から経営覗く(針の穴から天井覗く)
 (今)パソコンの窓(Windows)から経営覗く

ともかく,情報システム部門は「経営」が好きである。30年前もそうだったし,現在もそうである。「経営」だから「経営者」ということになり,短絡的に「トップの参画が必要」とか騒いできたが,この場合の「経営」も上と同様に単純業務のことなので,トップはなかなか本気に参画しようとしない。


情報システム職名のインフレーション


大仰なのは部門名だけではない。情報システム部門の職種の変遷をみると,あまりにもインフレ傾向が大きいことに驚かされる。研究部門や技術部門での「技師」は今でもある程度のレベルを保っているが,この部門では「猫も杓子もみなエンジニア」である。

コンピュータ要員名称は業務に関係なく職位があがる。

コンピュ−タがやっとポピュラになった60年代では,まず女子はパンチャ,男子はオペレータに従事し,それがプログラマに昇格して,最高級位のプランナになるコースが標準であった。
 すぐに「パンチャ」が廃語になった。これはエンドユ−ザが端末からデータを入力するようになり,カードパンチ業務を専任として行うことが少なくなったことにもよるが,それ以前にこの職種名はなくなった。腱鞘炎や疲れ眼などの職業病が問題になって採用にも影響が出たり,折りからのウーマンリブ運動で女性差別用語だた指弾されたのであろう。
 オペレ−タも電話交換手と誤解され自動交換により失職するようなイメ−ジが伴うのか,正式?には「ファシリティ・マネジメント(FM)」と呼ばれるようになり,いつのまにか管理者に出世した。最近は「システム・オペレーション(SO)」として,情報産業の花形分野になろうとしている。
 プログラマは往時は花形職種であったが,残業が多いイメージが影響して,いつのまにか3K用語に転落してしまった。なお,94年度から通産省はプログラマを職業蔑視語と認定し,情報処理技術者試験からこの用語を削除した。
 プランナも落ちぶれた。現在では,求人案内にも「新卒求む。職種SE。経験不問」とあるように,情報技術を持たない者でもSE(システムエンジニア)というが,このSEとは往年のプランナの別名である。すなわち,昔の最高職種は現在では単なるコンピュータ部門要員の呼称になったのである。
 一応使えるSEを「上級SE」といい,業務を任せられるSEは「プロジェクトリ−ダ」というように昇格した。最近ではこれも怪しくなってきたので,通産省では「システム・アナリスト」としている。おそらくこれも短命であろう。

2000年に向けて新呼称を作ることが急務である。もはや「システム」は死語である。「ビジネス・インテグレ−タ(BI)」,「プロブレム・ソルバ−(PS)」,「エンタプライズ・コンサルタント(EC)」などはどうだろうか?
 情報システム部門はユーザを大切にする。「エンドユーザ」ではエンド(英語では「目的」の意味であるのに)が失礼にあたるとして,「システム・アドミニストレータ(行政管理者)」とすることによりバランスをとっている。


情報システム部長の特質


情報システム部長とはピーターの法則により,階層社会での終着段階に達した者を配属するのに恰好な職位である。

プログラマあがりはSEになれぬ。SEあがりはCIOになれぬ。情報技術の落ちこぼれが管理職になる。
財務諸表を知らないと経理部長にはなれない。OSを知っているとシステム部長にはなれない。

営業部長が自社商品を知らないとか経理部長が決算状況を知らないと人前でいうにはかなり勇気がいるが,新任の情報システム部長が「いや−。私はコンピュータには素人でして・・・」というのは許される。情報システム部長仲間の会合でも,このような挨拶をするとむしろ尊敬される。それにたいして「私はコンピュータひと筋にやってきました。今でもプログラムくらい組めますよ」などというのは恥であるからひた隠しにする。すなわち,コンピュータを「知らない」ことはステータスシンボルなのである。なぜなのだろうか?
 おそらく経営トップがコンピュータを知らないことでもあるし,コンピュータを「知らなくても」昇進できるからであろう。すなわち,コンピュータは企業にとって「たいしたことではない」のである。そんなくだらないことをやってはいないぞということが,ステータスシンボルになるのであろう。
 CIO(Chief Information Officer:情報担当役員)が必要だといわれる。情報技術は企業戦略の武器であるから,情報システムの専門家に任せるべきではなく,経営者が直接指揮をとるべきであるという論旨である。本来は情報と経営の両方の知識を持つ者がCIOとして活躍すべきだとの論旨であると思うのだが,いつの間にか,情報システム部門に携わった者を情報システム部長にはするなというように解釈されるようになり,コンピュータを「知っている」と情報システム部長になれないことになった。もっとも,ダウンサイジングやオープン化の動向が不明確になった現在では,CIOに求められるのは経営よりも情報技術動向だともいわれるようになってきている。


素人の情報システム部長の言動


とかく情報システム部門の部長は,情報技術を知らないことが重視されるが,これは部下にとっては面倒のタネである。

システム部門の会議では,門外漢の意見が最重要視される。

「みんなの意見はシステム部門の発想だが,ユーザは・・・」といえば,それまでの議論はすべて無価値になり,この意見だけが神託になる。その意見が本当にユーザ的発想かどうかや議題が何かには関係がない。新任部長はこれをいうタイミングさえおさえておけば,部下の小姑的な意見を封じることができる。
 情報システム部門の上司は情報技術を知らない。しかし,決定権は持っているので,部下は上司に説明する必要がある。そこで部下は次のような不平をいう。

自分でやらない者にとって不可能はない。

金は使うな。あれもやれこれもしろ。納期はこれまで・・・。やらされるほうにとってはたまらない。

OSを日常語にするのは難しい。

知識がないので「コンピュータ用語を使うな」という。さて,OSのことを何といえばよいだろう。最近ではミドルウェアの説明が困難になった。
 かなり古い話ですが・・・
 「今度採用計画のメインフレームは100MIPSで・・・」
 「ちょっと待て,そのミップスっていうのはなんだい。」
 「コンピュータの性能を示す尺度で,1秒間に命令を百万回実行するのを1MIPSというんですが」
 「なるほど。ところで,以前に簡易言語のことを聞いた。COBOLでの1000行が,簡易言語では50行で書けるそうだね。すると,簡易言語で書けば20倍の速度になるのか。」
 「いいえ。それは人間が書くプログラムのことで,MIPSはコンピュータが理解する機械語のことです。たとえばCOBOLの1行は機械語で10命令になりますが,簡易言語なら数百命令になるので,結局は簡易言語のほうが命令数はおおくなりますね。」
 「そうか。それはそれとして,今のコンピュータのMIPSが50ミップスだったね。あの請求書印刷は2時間かかっていたが,それが1時間になるのか。だいぶ楽になるな。」
 「いえ,このMIPSはCPUの速度で,請求書印刷はプリンタのことで・・・」
 「そのCPUっていうのはなんだい」
 「・・・!」


情報システム部長の悩み


最近は環境変化が激しく,部長が部下よりも業務を知っているとはいえない。とくに情報システム部門の部下の言動はどうも他の部門とは違うようだ。コンピュータと部下は思うように動かない。

指示したことと実行される内容は違う。

指示したことは表面的には実行される。しかし,その本質は全然違う内容になっている。枝葉末節な部分は大々的に展開されるが,本幹な部分は無視される。たとえば,標準化を徹底せよと指示すると,部下は各ベンダのCASEツールの機能比較に没頭し,項目名称の統一などはいつになっても実現しない。

よい報告はトラブルの前兆。
悪い報告は,もっと悪くなる。

プロジェクトがスムーズにいっているとの報告があると,その翌日には致命的なトラブルが発生する。
1週間遅れる報告のあったプロジェクトは,うまくいっても1カ月は遅れる。
 もっとも対人関係が面倒なことは,この部門に限ったことではない。どこにもあることだと思えば諦めもつく。

隣接階層は反目する。

経営者は部長ではなく課長以下の意見を聞きたがる。部長は係長以下の意見を尊重する。逆にいえば,部長の意見は誰も聞きたがらない。

人間関係の逆引力の法則(遠い人ほどよく思われる)

他社のトップは立派にみえる。
 親しい先輩も上司になるとイヤな奴になる。
 持てあました部下が他部門へ転出するとよい仕事をする。

天は自ら扶くる者を扶く。

「一度言ってみたい!」。グータラ部下でも育てねばならぬ。それどころか,ご機嫌までとらねば。


情報システム部門の計画立案


これからの情報化社会では,企業戦略に合わせた情報戦略が必要である。長期的な技術動向を把握し,それを業務にいかに取り入れるかを検討することが重要である。そのための情報投資は,省力化投資や改善投資ではなく,リスクを伴うサバイバルのための戦略投資と考えるべきであり,企業革新のインフラ投資として認識すべきであるといわれている。

「短期」は「長期」を駆逐する。(グレシャムの法則)

情報システム部門は計画作りが好きである。「現状認識」「環境変化」「望ましい状態」「それへのアプローチ」・・・などと,コンサルタントがみたら感激するようなキレイな図表にする。しかし,これはシステム仕様書が現行システムと無関係なものなのと同じく,実際の行動とはほとんど無関係の文書である。
 長期計画は作ってはみるが,現実には日常業務においまくられて,実現されることはない。その逆に,長期計画の実施を理由に日常業務が阻害されることはない。電話応対はすべての業務に優先する。

長期計画不変の法則

5年計画の最終年度に次の5年計画を策定すると,前の5年計画と全く同じであることがわかる。「もう計画ができたのかい。速いねえ。」「前の計画がワープロに入っていましたので,年月だけ変更しておきました。」
 電算室といわれた時代に,ある調査機関が各社にアンケートをした。「現在は省力化対象の単純処理をしているが,5年後には経営の意思決定に役立つ資料を提供する」という回答が多かった。最近のアンケートでも(表現は異なるが)同じような回答になっている。

短期計画はできることしかできないので簡単である。長期計画はどうせ夢物語だし自分はこの部門にいないので簡単だ。困難なのは中期計画である。

部内の硬直化やシステム開発の牛歩的速度,予算の引き締めを考えれば,今年内にできることは決まっている。2000年ビジョンなどは誰にでも作れる。しかも部長のあなたは定年になっている。しかし,データベースやブラウザの標準を何にするか,イントラネットの位置づけをどうするかなどを決定するのは難しい。


情報システム資源の見積


情報システム部門は常に現行の2倍のシステム資源を欲する。

CPUの速度,メモリ容量,ディスクなどの増強案は,業務量増加の多少に関係なく,いつでも現状の2倍になっている。最近ではユーザもパソコンで同じことをいっている。

コンピュータ資源は半年で一杯になる。(パーキンソンの法則)

その案を受け入れてCPUやディスクを増強しても,半年経つと一杯になる。これは業務が増大するしないには関係しない。当初の必要理由であった要件を実施する頃には,実施以前にすでにネックになっている。

資源ネックはスパイラルに増大する。

CPUのネックを解消するとメモリが不足する。メモリを増大するとディスクが不足する。それもカバーするとCPUがネックになる。しかも,これを事前に推定することは困難である。このように,いつでもコンピュータはネック状態である。
 最近はパソコンでも同じような動向にある。使いやすいから業務を拡大する。メモリが要求されるので増強する。使いやすいツールが利用できる。それにメモリが取られる・・・。


情報システム投資計画


コンピュータの費用は価格低下に関係なく毎年一定の割合で増大する。

「昔の大型機は現在のパソコン」などといわれるが,パソコン1台で済ませている企業はない。コンピュータの増強リプレースのために,実際に出す金額は毎年増加する。
 これはパソコンでも同じで,パソコン価格は急速な低下をしているが,カラーにしたい,GUIを載せたいなどと,より高度な機能を求めるために,実際に購入するパソコンの価格は下がらない。しかも台数だけは着実に増大する。古い機種は使用目的には無関係にリプレースしたがる。結果として,全体のコストだけは着実に増大する。

ダウンサイジングはコストダウンに効果的である。

上の費用増大法則は,ダウンサイングの風潮により一時的な変更が起こっている。メインフレームを増強したいといえば,「ダウンサイジングの時代にメインフレームに金をかけるとは何事だ」という。それではダウンサイジングで対処しようといえば,「ダウンサイジングは見えないコストがかかるので危険だ。発展途上のあやふやな技術に金は出せない。現在の環境でなんとかしろ」という。これによりどちらの情報投資も抑えることができる。

OSが大きくなると人も増える。

本来,OSの目的は人の介入を少なくするはずなのに,汎用機の歴史は,OSが大きくなるだびにその管理のための増員を要求し,しかも高度の技術者を必要としてきた。おそらくUNIXやNTも,そのうちに専任オペレータを必要とするようになろう。最近はOSの違いをカバーしようとミドルウェアが大きくなってきた。おそらく「ミドルウェア管理者」が出現するだろう。

予算管理が厳しくなると予算申請額と決定額とは次第に乖離する。

通常の場合,予算申請額合計は投資可能限界を超える。経理部は優先順位を決定する能力がないから,申請を一律10%カットする。各部門はそれを知っているから,まえもって10%上乗して申請する。経理部もそれを知っているから20%カットする。それに対処するため申請額を20%水増しする・・・。その結果,予算は予算にならなくなる。


情報システム部門の社内的地位


経営者は「情報技術の活用が重要だ」という。ところが不況になると,真先にカットされたのがコンピュータ費用である。しかもその投資過剰は情報システム部門の責任だとされている。
 経営者は「これからの経営は情報の活用にあり」という。ところが情報システム部門出身の役員がいる企業は少ない。経理部門や人事部門出身者の役員がいない企業は探すのに一苦労する。

情報システム部門ゴルバチョフ論

情報システム部門は,従来から「ユーザ主導型システム」や「エンドユーザコンピューティング」など,コンピュータ利用の民主化を主張してきた。それなのにトップやユーザは乗ってこなかった。
 それがある日,マスコミのダウンサイジングブームに煽られると,一転して過激派に変貌した。メインフレームをやめてダウンサイジングせよとか,情報システム部門を解体してしまえという意見になった。そして,過激な変化の混乱を危惧する情報システム部門を,旧来思想に安住しているホスト一辺倒の保守反動派であるとして指弾するようになった。
 その結果,情報システムの運営を情報システム部門に任せることはできないとして,経営情報委員会を作ったり,アウトソーシングを検討するようになり,情報システム部門は失脚しつつある。


悪女の深情け


情報システム部門醜女論

(トップへの片想い)
 従来から「システム化にあたってはトップの参画が重要」だとか,「情報を経営に役立てるために,トップとの意思疎通をよくして」などといわれてきた。特に最近は,「情報は第4の資源」とか「情報技術は競争優位の武器」であるから「SIS−戦略的情報システム」や「BPR−ビジネス・プロセス・リエンジニアリング」の確立のために,「情報担当役員−CIO」を置くべきだと主張されている。しかも,これらはトップがいっているのではなく,情報システム部門が一方的にいっているのが特徴である。
 販売部門や人事部門にくらべて,情報システム部門が特にトップの関心や参画が重要であるとは思えない。おそらく他部門は以前からそうなっているのに,情報システム部門だけがそうなっていないからであろう。トップがその重要性を認識していれば,黙っていても関心を持ち参画する。そうなっていないのは,トップが認識していないか認識したが重要ではないと判断したからであろう。
 認識していないとしよう。これだけ世の中で騒がれている(トップの読みそうな雑誌にも書かれている)のに気がつかないのであるから,そのトップは社会情勢に注意していないといえる。そのようなトップはトップとしての資格がない。よしんば参画したところでたいした効果はないと考えてよい。
 トップは情報システム部門を重要ではないと判断しているのではないか。販売や人事は重要であるが,情報は自分がみづから参画するほどの必要はないと判断しているのに,いつになっても一方的にラブコ−ルを送るのは,「片想い」あるいは「醜女の深情け」といわざるをえない。

(ユ−ザへの片想い)
 情報システム部門では,ユ−ザニ−ズに如何に応えるかは重要な問題である。そのために非常な努力をしている。それが実現できないのは自分たちの責任であると信じている。ユ−ザ部門とのコミュニケ−ションを良くするために,「専門用語を使うのはやめよう」とか「利用部門の業務を学習しよう」など,涙ぐましい努力をしている。ところが,相手のユ−ザ部門は,情報システム部門とのコミュニケ−ションのために,その部門のスラングを使わないようにしたり,情報処理業務を勉強しようとは思っていない。
 実は,「提案型SEより下請型SE」でも,ユーザから「お前はでしゃばりだ。オレのいうことを聞け」といわれたのではない。自分がみずから「あなたが主役です。なんなりと仰ってください。それを満足させるのが私どもの任務です」といったのである。なかにはマーケテイングでの顧客志向まで持ち出してこれを主張することすらある。「ユーザ主導型人事部」や「ユーザ主導型経理部」が存在しただろうか。
 現在では情報システム部門は完全に売手市場である。ユ−ザがついてくれなければ仕事がなくなるわけではない。それどころか,殺到する注文がさばけないで困っている。かなり高圧的に構えても仕事はある。コミュニケ−ションが悪くて困るのは,情報システム部門ではなくユ−ザ部門なのである。


奇妙な情報システム部門


情報システム部門は,自部門の合理化には冷淡である。(紺屋の白袴)

EUCを省力的に運営するために公開ファイルを作ろうとか,既存システムが長年のパッチ当てで複雑になり保守が大変だから改訂しようなどという内部合理化はなかなか実施できない。そのために,必要以上に忙しく,それがために勉強もできず,付加価値の高い業務に手がまわらない。この悪循環が部門の評価を低下させている。
 なぜ自部門のニーズに応えないのか? ユーザのニーズがないからである。情報システム部門はユーザの声にだけ反応するように訓練されているので,上司がいかにわめいても部下は動かない。
 もっとも,外科医は自分を手術しないし,床屋は自分の髪を刈れない。社内で情報システム部門が最も情報化が遅れているのは当たり前だという意見もある。

情報システム部門は,自社問題を他社同業者と相談する奇妙な部門である。

情報システム部門ではメーカーやユーザ団体の主催する講習会が盛んである。「情報システム部門のありかた」として,「トップの関心を得るにはどうするか」とか「ユーザとどう付き合うか」などを話題にしている。これは昔も今も人気のあるテーマであり,「ハードウェアの安い買いかた」や「システムを簡単に作成する方法」などははやらない。すなわち,情報システム部門は自社固有の問題解決を,社内ではなく社外に求める傾向がある。これは,販売部門や経理部門など他部門ではあまりないことである。


情報システム部門の分社化


情報産業が高度成長していた頃は,それに参入すべく分社化が盛んであった。ところが最近では,本業中心だとか技術空洞化が問題になり,またEUCやダウンサイジングでのユーザ部門への技術者転出のために,本体への復帰もいわれている。

分社すべきか復帰すべきかはマスコミが決める。

マスコミが80年代には情報システム部門の分社化を煽った。そのとき情報システム部門がEUCへの対処や技術の空洞化を懸念しても無視された。90年代になりマスコミがそれを指摘すると,分社したものを本体に戻そうとする。最近のマスコミはアウトソーシングを喧伝しているがどうなるか。

分社理由には二重帳簿がある。

公式の分社提案書には,情報産業への進出や情報技術者の確保と育成などがいわれているが,ポスト不足の解消や余剰人員の受皿などがホンネであることが多い。そのため,バブル崩壊で外部収入が減って経営困難になったり,本体のEUCの推進のために,本体に戻そうと思っても戻せない。

分社後の文化は分社前の文化を増大する。

分離前の情報システム部であったときから積極的な組織は,分社すると外部進出に手を広げ過ぎて,本体のいうことを聞かなくなる。ユーザのいいなりだった組織は,分社すると本体の下請になる。

親会社の情報システム部門および情報子会社の管理職業務の半分は,親子関係のあつれきの調整に費やされる。

分社した当初は,親子の仕事の分担がどうの予算がこうのでもめる。時間がたつと外部仕事と親仕事との調整でもめる。BPRの主旨とは反対の結果になる。


リエンジニアリングとダウンサイジング


悪くなる可能性のあるものはかならず悪くなる。(マーフィーの法則)

情報技術はリエンジニアリングのインフラだといわれる。そのために,情報システム部門は他部門のリエンジニアリングを推進する立場になる。また,情報システム部門自体もリエンジニアリングの対象部門になる。紺屋の白袴では困る状態になる危険がある。
 これは事態が深刻なので,ご本家の法則を引用する。
 リエンジニアリングは,人員整理や労働強化につながる臭いがする。他部門のリエンジニアリングを行うために情報システムを構築するとき,その部門は「ユーザ主導」により,喜んで積極的に参画するだろうか。情報システム部門はすでにユーザの反対を押し切って事を進める文化を失っている。
 ユーザ部門はリエンジニアリングそのものに反対することはできない。それを「システムが使いにくい」とか「業務プロセスと合致していない」などと,情報システムへの批判として表現する。情報システム部門は,それをカバーするためにあれこれ対策をとる。結果としてコストもかかり納期も遅くなる。
 逆に,トップはこれの成否に大きな関心を持っている。進捗状況やコストについて従来とは格段の関心を持つ。この板挟みの結果,情報システム部門が無能だということになる。
 当然ながら情報システム部門もリエンジニアリングの対象になる。紺屋の白袴で情報システム部門の生産性は悪い。最近の方法論も採用していないし,ツールも用意されていない。これを外部のコンサルタントに指摘されたとき,トップは「自分のことすらできない連中に,全社のことを任しておいたのか」と愕然とするだろう。その結果は,情報システム部門にとって愉快なものではない。

外注ではマンネリだが,アウトソーシングなら先進的に聞こえる。

経営資源配分の観点から,リストラやリエンジニアリングの一環として,自社では十分ではない機能を他社が提供できるならばアウトソーシングすべきだという動向も出てきた。
 外国のアウトソーシングでは,情報システム部門を解体してその要員も出してしまう例が多いが,日本ではそれは困難であり,ハードウェアをベンダ所有にするとか,部分的な業務を外部に依頼する程度のことになろう。オペレーションやプログラミング業務のアウトソーシングなら昔からやっている。その前にはコンピュータも計算センタのものを利用していた。
 また,悪くなる可能性のあるものはかならず悪くなる。このようなアウトソーシングなら安心だが,リエンジニアリング対象で紺屋の白袴を指摘されたときは,深刻なアウトソーシングになる。


ユーザの独善(1)


情報システム部門は奇妙な特性を持っているが,そのなかでも対ユーザ思想は特殊なものである。情報システム部門のベテランよりも,新入社員のユーザのほうが情報システムについての発言力が強いのである。年功序列が根強い日本的組織において,これは特記すべき現象かもしれない。

人事部が人材をよこさなくても非難しない。経理部門が予算を認めなくても非難しない。情報システム部がシステム要求を満足しないと非難する。

人事部門も経理部門も情報システム部門と同様なサービス部門であるのに,社内での地位はかなり異なる。「ユーザ主導」の人事配置とか,各部門代表による「経営予算委員会」での予算優先順位決定はあまり聞かない。
 また,自己申告や評価などの用紙の形式は各部門に相談せずに人事部が一方的に決めており,自分の名前を何度も記入させられるが,みなそれに従っている。ところがコンピュータへのデータ入力になると,ちょっとした重複入力も拒否される。予算申請ではあの手この手をつくして経理部を説得するのに,その査定結果は理由書もなく一方的に通達される。ところがシステム化でユーザ部門の要望の一部をカットするには,情報システム部門はかなりの説得をする必要がある。
 どういうわけか情報システム部門だけが,ユーザの意向を全面的に受入れるように強制されている。

昔,ユーザは音声応答,AI付のコンピュータを持っていた。
「コンピュータは難しい」というのは,「コンピュータを使いたくない」という婉曲な表現である。

コンピュータ利用の講習会を開いても歩留りが悪い。EUCをやっても利用度が少ない。それでアンケートをとると「コンピュータは難しい」という。その理由を聞きいろいろ改良しても使わない。あいかわらず難しいという。
 なまじっか「知っている」といえば,仕事を押しつけられる。「わからない,できない」といええいれば,他人がやってくれる。
 最近のようなビジネス環境にあっては,「オレはコンピュータなんか使いたくない」とあからさまに表明するのは勇気がいる。一応はやろうという態度を見せる必要がある。しかし,日本の社会ではコンピュータ技術の習得能力に劣ることは仕事の能力とは無関係(ある場合には逆の関係)であると認識されている。だから,「コンピュータは難しい」といっておけば,自分の責任ではないことになる。それを評価する上司も同じなのだから。


ユーザの独善(2)


私の1日,あなたの1月。
ユーザは虫がよい。システム部門は人がよい。

ユーザは,自分の1か月に1時間の事務作業を改善するために,情報システムを開発したり改訂することを要求する。そのために情報システム部門は1カ月の作業をさせられる。ところが,情報システム部門がユーザのために1日のEUCの講習を受けさせようとすると,ユーザは面倒だとして受講しない。
 システム開発の基準として,情報システム部門よりも残業時間が多い部門だけの要望を受け付けるというのはどうか?

他へのサービスは俺への反逆。
提案SEよりすぐやるSE。

ユーザは情報システム部門が自分のことだけを優先に行うことを望んでいる。他部門の仕事をしているのは仕事とは思わない。販売部門の要求にたいして,流通部門と調整して統合的なシステムにしようなどと提案するのは,販売部門としては,頼んだことがすぐに実施できなくなるので面白くない。


ユーザの要求事項


ユーザからの要求は,最初の要求の半分は取り下げられる。それにない2倍が付け加えられる。当然ながら,戦略的に見えてトップの了承を得た機能は,取り下げられた半分に含まれる。

すべてのプロジェクトは,そのうちに第1次がつくようになる。

最初の要求書では簡単なことをいってくるので,情報システム部門も安易に引受けてしまうが,ヒアリングを進めていくうちに,大きなことが欠けていたり,人により多様な要望がでてくる。結果として最初の目的とは全然異なるシステムを構築することになる。当然,予算が足りなくなるので,要望書に基づいて算出した予算範囲を「第1次」とし,それを超過した分を「第2次」とする。

エンドユーザの世界では論理法則が成立しない。

(因果律は成立しない)
 データがそろうのが5日なのに3日に結果がほしいという。
 (3段論法は成立しない)
 「この情報を得るには手順を明確にする必要がある。その手順はその情報をみないとわからない。ゆえに,この情報を得るためのプログラムを事前に作ることは不可能である」という論理を納得させるのは困難である。
 (1つの事象には3つの名称があり,1つの名称には3つの事象がある)
 事象Aを名称aとも名称bとも名称cとも表現する。また,名称aは事象Aを指すことも事象Bや事象Cを指すこともある。すなわち,命題は存在しない。

ユーザは自部門システムさえもわからない。

システム開発時に参画したユーザは,人事異動などによりいなくなる。ユーザ部門ではシステム関係の引き継ぎはいいかげんである。逆にシステム部門はローテーションが少ないので,その担当者はその情報システムどころか業務システムについても強くなる。表面的なことはともかく,本質的な事項についてはユーザ部門より詳しくなってしまう。


メーカー/ベンダの特性


メーカーは,40年前に汎用コンピュータという未完成品を発売して顧客を混乱させた。現在ではミドルウァアでそうしている。

コンピュータメーカーは,コンピュータという「高価で遊ばせるにはもったいなく」「かなりの変り者でないと使えない」試作品を製品として世に出した。そのために,情報システム部門を設置して,販売システムとか経理システムなどの中央集権型の基幹システムを作り運用しなければならなくなり,その後の混乱を招いてしまった。最近では,「廉価」で「ユーザフレンドリ」だといってパソコンを売り出したが,それもクライアント・サーバ系などに拡張しようとして,また「高価」で「わかりにくい」ものにしようとしている。

マシン性能はOSのためにある。(歴史は繰り返す。懲りない人々)

メインフレームでは「わからなくなったらOSを大きくせよ」といわれた。それが巨大なOSになり,主記憶装置の容量を大きく占有してユーザが利用できる資源は一向に豊富にならず,CPUも同様にMIPSの増加はOSのオーバヘッドで帳消しになってしまう状態であった。
 それを打開しようとしたパソコンでも,最近のOSは高速のCPUと大容量メモリを要求するようになってきた。そして「でも価格が安くなったのだからいいじゃないか」といっている。これもメインフレームのときと同じ論旨である。

メーカーのカレンダは半年遅れている。

新製品を4月に出すと発表するのは,10月には出荷するということであり,初期には多くのトラブルがあるので,実際に使えるのは翌年の4月になる。


メーカーとオープン化


すべてのメーカーがオープン化を宣伝している。しかし,すべてのメーカーは自社製品しか提案しない。

最近は,オープン化と称して,特定のメーカー特定の機種でしか使えない機能ではなく,どの機種にでも共通な規格や業界標準に合わせるようになってきた。そして,サービス商品化(有料化)のために,自社製品だけでなく,他社の商品も含めた最適な構成をサポートするといっている。ところが現実には,当然のことではあるが,実際に提案するのは自社製品だけである。
 他社製品と「接続できます。互換性があります。・・・」というが,実際に接続したり交換しようとすると,メーカーも他社製品の知識がほとんどないので,非常に面倒なことになる。

清一色のほうが混一色より良いのに決まっている。
オープン化対応は守れ。ただしマルチベンダ化は防げ。
オープン化とは独裁者がIBMからマイクロソフトに代わったことをいう。

UNIX,Windows,OS2など多くのOSが自己主張をしている。統一できないのでミドルウェアなる通訳を設けた。ところがバベルの塔以来の多言語状態で,通訳に通訳を付けるような状態になり,十二単衣的ミドルウェア構造が出現した。コンピュータ資源はそのオーバーヘッドに費やされる。
 とくにCSS環境では,クライアント,サーバ,NOSなどとの関連が機種により微妙に異なる。トラブルの切りわけが大変だ。文句の持っていく相手を特定するには,単一メーカーに揃えておくのが安全である。


コンピュータ利用の発展


一般企業にコンピュータが設置されるようになってから30年が経過した。その間にコンピュータの利用も変化するのは当然であろう。なかには180度変わったものもあれば,360度変わって元へ戻ったものもある。

時代が変わればコンピュータの意義も変わる。

(昔革新派,今保守派)
 昔,コンピュータが導入された頃の情報システム部門は変革の尖兵であった。今,システムの都合で変化を抑えている。昔は組織に変革をもたらすためにコンピュータを導入した。今はコンピュータがネックで組織変革ができないでいる。
 (昔標準化,今個別化)
 昔は業務標準化のためにコンピュータを導入したが,今はダウンサイジングなど,業務の個別化を推進している。
 (昔省力化,今増力化)
 昔は事務処理の省力化をコンピュータ導入の理由にしたが,それが行き詰まってくると,今度は情報のより高度な活用をというようになり,そのための人員の増強を主張している。
 (昔支援,今阻害)
 昔は,事務の生産性向上のために「システム化しよう」といった。今は「システムが使いにくい」ので,生産性が阻害されているという。

なかには,変化がかさなり元に戻るものもある。メインフレームによる集中からダウンサイジングへと分散したのに,イントラネットでまた集中にしようとしている。

時代が変わっても人間の行動は変わらない。

昔はFAXを送ると「FAXしたよ」と電話をかけた。今も電子メールを送ると電話をかける。なかには電子メールの文面を印刷してFAXで送る人もいる。
 昔は「オープンプログラマ」という呼称でエンドユーザがコンピュータを利用していた。今もEUCの呼称でエンドユーザに利用させようとしている。その違いはオープンプログラマは自主的に行動したが,EUCでは情報システム部門がオンブにダッコをしないと利用したがらないことである。
 昔は3点を求めてグラフを手描した。今は膨大なコンピュータ処理をしてグラフを画面表示する。それに要する時間も結果のグラフもほぼ同じである。


コンピュータ利用の輪廻


情報システム分野では5年周期で新コンセプトがブームになる。
新コンセプトは信じず布教に使え。

60年代後半 MIS
 70年代前半 TSS
 70年代後半 DSS
 80年代前半 EUC
 80年代後半 SIS
 90年代前半 BPR
 情報技術に関するコンセプトは頻繁に生じ短期間に消滅する。MISからDSSになりSISへと続いたが,もはやSISはBPRへと移行した。ダウンサイジングはいつのまにかライトサイジングになった。情報システム部門の分社化もユーザ部門への復帰となりアウトソーシングがいわれている。
 最近の風潮は,「日本的SIS」「日本的BPR」「日本的アウトソーシング」のように,「日本的」が付くのが特徴である。
 これらは以前は情報システム部門内部の話題であったのが,最近はトップやユーザまでもがマスコミに踊らされている。BPR,ダウンサイジング,アウトソーシングなどに反対の意見を述べてはならない。保守反動派のレッテルを貼られる。賛成のような顔をしよう。しかし自分で信じてはいけない。短期で消滅するから信じて行動するとマスコミにハシゴを外される。
  SISは企業生き残りの切り札   − SIS投資はバブルの申し子
  ダウンサイジングはコストダウンに − 見えないコストで高くなる
  メインフレームよさようなら    − ライトサイジング
  分社化せよ            − 空洞化するので本体へ戻せ
 このような用語を自説の説得に利用することが秘訣である。このとき,用語と内容の一致はとくに気にする必要はない。「○○の推進のためには,情報システムの活用が必要だから,△△をしよう」において,○○はBPRでもダウンサイジングでもよいし,△△はRDBMSの購入でも標準化の推進でもよい。ともかく流行の用語が使ってあればよいのである。


エネルギ保存則

(物質不滅の法則,運動量一定の法則)


エネルギ保存則(物質不滅の法則,運動量一定の法則)
システム化は労力の移転をするだけである。

システム化により,ある部門の業務の省力化を達成するには,情報システム部門はそれと同等の労力を必要とする。あるいは,ある部門の業務を省力化するためにシステム化すると,その維持のために他の部門の作業が増大する。システム化することにより,その対象業務は合理化するかもしれないが,そのために発生したコンピュータ費用を稼ぐための営業努力が必要になる。このように,システム化は,仕事量を他の部門や他の分野に変換するだけであり,その総量を減少させるものではない。
 エネルギ保存則は理想状態において成立する。通常の場合は摩擦などの抵抗により,無効エネルギが熱となって発生する。すなわち,実世界においては,システム化をすると,全体の仕事量はむしろ増大するのである。
 最近のコンピュータでは,OSやミドルウェアなどのヒューマンインタフェイスが向上した。人間が楽をするだけ,コンピュータの処理速度や記憶容量は浪費される。当然ながら人間のほうが効率がよいので,全体としてのエネルギは増大する。しかし,これを理由にシステム化が不要だというのではない。社会環境や技術進歩により,人間のエネルギ単価は高くなり,コンピュータのそれは低下してきた。エネルギ総量は不変であっても,それを実現するコストは変化するので,その最適なポートフォリオを常に変化させることが必要である。


力学の法則


慣性の法則
現在最も困っているシステムは,以前では最も評価の高かったシステムである(現在評判のよいシステムは,将来のお荷物になる)。

恐竜のように,ある環境に最も適応したものは,その環境が変化したときに内部からの対処は最も困難になる。ある部門の業務を変えるのをその部門に期待しても無駄であり,外から変えてやる必要がある。その部門が巨大で権力が大きければ,それだけ大きな外力を与える必要がある。
 情報システムも,それが巨大になると環境が変化しても改訂することが困難になる。エンドユーザが構築するような小規模システムは,改訂も容易だし最新の技術をすぐに採用できるが,全社的な基幹システムは,それが精緻に構築され各分野に関連しているほど困難である。昔は「個別システムを統合せよ」といわれたが,今後は「システムを分割して統治せよ」といわれるようになろう。

作用反作用の法則(運動の第3法則,ル・シャトトリエの法則)
組織は変化を望まない。

ある業務についてある提案をすると,かならず反対の意見がある。強く主張すれば反対も強くなる。情報システムにより変化を与えようとすると,それを阻止するように組織は動く。逆に,業務の改革をしようとすれば,情報システムがそれを困難にするように働く。早急な変化を求めると,それを抑える環境勢力は急速に強くなる。
 組織力学においては,この法則は非線型の関係がある。業務改革をするにはそれに対応した「閾値」があり,その値以下の力では動かない(静止摩擦ともいえる)が,この値を越えると一挙に動きだす。すると今度は逆向きの力が働く。その結果,振動が発生する。往々にしてその振動は発散する。
 EUCも情報システム部門が主張した程度では誰も動かないが,マスコミなどが騒ぐと何でもEUCにしようということになり,メインフレーム不要論や情報システム部門解体論に発展する。それが実施されそうになると矛盾に気付き,今度は集中だと騒ぐ。結果としてポリシーのないシステムだけが乱立して情報システムの無政府状態になる。


熱力学・量子力学の法則


エントロピ増大の法則(熱力学第二法則)
虫歯と情報システムは放っておくとますます悪くなる。

情報システムは時間とともに複雑になり動かなくなる。それを作動させておくためには,ときどき再構築をしなければならなくなる。長く放置してきたシステムほど,再構築には労力がかかる。それを「わかってはいるのだが,今は忙しいから」といって放置すると,ヒマになっても実施できない規模のカオスになってしまう。

不確定性原理

情報システムがどのような動作をするかは,人為的要因というプランク定数により,決定論的に予測することは不可能である。その挙動は確率的で千差万別であり,人知の及ぶところではない。一応それらしい動きをしているにせよ,それは統計的正確性であり,次の瞬間にはどうなるかわからない。とくにCSS環境では,プランク定数の値が大きい。
 システム開発におけるユ−ザニ−ズにも不確定性原理が働く。運用時点でのニ−ズを測定しようとすれば,そのニーズは特定できなくなるし,あるニーズを特定すると,運用の方法がわからなくなる。


情報システムはそれがなかったときの企業の文化を極度に増幅する。


良くも悪くも情報システムは人間が運用しているのであり,その人間は組織の内で企業文化に支配されている。コンピュータは物事を明確にする傾向がある。在庫管理のうまい会社のPOSは成功する。顧客動向に敏感な企業は顧客情報分析に力を入れる。意思決定を逡巡する組織のシステム開発は時間がかかる。形式主義の企業のシステムは巨大化複雑化して役に立たないか,あるいは現状の問題点を隠蔽したり維持強化するのに利用されている。
 要するに,情報システムを評価をするよりも,情報を活用する文化があるかどうかを調べ,それが低いようならば,情報システムを極力軽くすればよい。
 なお,エンドユーザコンピューティングの導入は,その企業の情報システムの性格をさらに増大するし,これはクライアント・サーバ・システムにより,極度な状況にまで発展させる。


システム開発における留意点


諸悪の根源はプログラムを作ることにある。

プログラムがあるから保守しなければならない。プログラム作成が,人員不足をもたらし,ベテランの仕事を固定化し,情報システム部門を硬直化させる元凶である。無能なSEは,ユーザの要求に応じたシステムを開発するが,優秀なSEは,ユーザの仕事を見直すことにより,システム要求そのものを不要にする。プログラムを作成することは,赤字国債の発行と同じで,自分の無能のツケを後輩に押しつけているのである。

個別アプリケーションシステムを開発するな。

そもそもの問題点の発端は,販売システムや経理システムなどの個別のアプリケーションシステムを構築することに原因がある。そのような個別システム以前に得意先や商品があり販売行為があり,その情報は存在する。だから,情報システムでも,まずそのようなデータを販売とか経理に関係なく無目的のデータベースとして構築し,それから情報を検索加工する仕組みを作るべきなのである。そして,その上に立って,そのデータベースの品質保証をしたり,その維持を容易にするために,販売システムや経理システムなどの個別アプリケーションを構築すべきなのである。これがDOA(データ中心アプローチ)の基本である。

ボルトやナットを特注するな。

工業では標準化した部品を整備することで生産性が向上する。自動車ディーラも色や内装はユーザ希望に応えるが,ボルトやナットまでは聞かない。これらは世界中どこでも同じ仕様で統一されている。多品種個別受注生産であっても,グループテクノロジという手法により,乗用車でもトラックでもできるだけ同じ部品を使うようにして,大量生産方式を採用できるように努力している。それが品質管理にも役立っているのである。
 情報システム開発では,ボルトやナットの類までユーザのニーズにより個別に作成するし,タイヤの個数やハンドルの位置までユーザの好みで個別設計している。1台ごとに新規に設計して生産しているのでは生産性はあがらない。
 ところがユーザは,自社開発のシステムについては細かい要求をするが,パソコン通信による外部データベースの検索など他社のシステムでは,ヒューマンインタフェイスが悪くてもいっこうに文句をいわない。その理由をよく検討することが重要である。


システム開発


システムは,自分を理解させないように振る舞う。
新人は育たないのではない。システムが育てないのだ。

情報技術を習得しユーザ部門の業務を知れば一人前のSEになるはずである。前者は半年も訓練すればどうにかなるし,後者も半年位その部門にいれば理解できよう。すなわち,理論的には1年間でSEに育成できるはずである。それなのに,実際には3年以上かかるのはどうしてなのか?
 それは,情報システムが複雑になっているからである。長年のパッチ当てで複雑怪奇になったアプリケーションを理解するには,それなりの失敗を繰り返す必要がある(その失敗によりシステムは更に複雑になる)。

ユーザニーズの80%は,ユーザの趣味である。
システムの論理とユーザ趣味とを区分せよ。

では,なぜ複雑になるのだろうか? 改訂要求があるからであり,それにパッチ当て的に対処しているからである。
 改訂要求は経営環境の変化に伴うこともあるが,原則的に対象業務自体がそんなに複雑なはずがない。複雑だったらその業務が成立していないはずであるし,それこそリエンジニアリングの対象になる。複雑にしている大部分はユーザの個人的趣味によるのである。それも一人の趣味ならばよいのだが,大勢の趣味を取り入れるために,わけのわからないものになってしまうのである。

システム開発の複雑さは M×N2 に比例する。Mは画面と帳票の個数,Nは関係者の人数である。

ヒューマンインタフェイスがからむと,システムは複雑になる。それを防ぐには,入出力部分と中核部分を分離して,前者をなるべくエンドユーザコンピューティングに移行することが必要である。
 関係者が増大すると,「船頭多くして船山に登る」ためにNに応じて複雑になるが,各人の組み合わせなのでN2 に比例することになる。プロジェクトの関係者を絞ることが生産性と品質の向上の鍵である。


システム開発では最初が肝心


情報システムも工業製品と同様に,高品質の製品を低価格で短納期に製作するべきなのに,実際には工業製品というよりも,芸術的作品を個別に制作している状況である。これはプログラマの創造性の発露だともいえるが,あまりありがたいことではない。

事前に検討する時間はないが,事後でやりなおす時間はいくらでもある。
テストをする時間はないが,リランをする時間はいくらでもある。

標準化が重要であるが,それを行おうという案は,ユーザのニーズがない,忙しく時間がないなどの理由で,いっこうに実施されない。標準化規則を作っても納期を理由に守られない。
 それができていないために個別開発を行っているので,品質もよくないし保守に時間がかかる。その時間のほうがはるかに大きい。納期がないことを理由にテストもしないで本番に入る。その結果トラブルが頻発するが,どういうわけか,それを直してリランすることはできる。担当者の納期云々を重視するな。

最初の1時間の無配慮を改訂するには数年間かかる。

「商品コードの改訂が必要だ。なんでこんな体系にしたのだろう。」「何も考えちゃいなかったさ」。この変更をするには,短くて3年〜5年,おそらく企業が倒産したり合併するまでは不可能である。
 どうしてもそれまでに改訂する必要があるときは「新商品コード」を作るが,旧のものも捨てられないので新旧併存になる。そのうちにまた新しいコードが必要になる。そのため「商品Aコード」「商品Bコード」・・・「商品Zコード」などが出現する。
 同様なものがファイル段階でも起こる。商品マスタに項目追加したいのだが,それをすると既存プログラムの修正が多く,到底「納期に間に合わない」。それで既存マスタはそのままとして,新規に「商品マスタ2」を作る。これもすぐに「商品マスタ10」にまで発展する。
 これを事前に考えることは不可能である。ファイルデザインを変更しても既存プログラムに影響させないこと,すなわちファイルデザインとプログラムを分離することが必要である。正規化やRDBをすることである。


プログラミング言語の分析


小文字言語はカッコよい。

昔,COBOLやFORTRANが華やかなりし頃は,プログラム大文字で記述されていたが,最近の言語はすべて小文字である。この風潮は奇妙なことに,メインフレームからパソコンへの移行と時期が一致している。そのうちにコンピュータからは大文字がなくなるものと思われる。ところが未だキーボードの表示は大文字が多い。


情報システムの寿命


通常の情報システムは,開発後1年で仕様書が無意味になり,3年後には当初の目的とは異なる目的に使われ,5年後には何のためにやっているのかわからなくなる。(エントロピ増大の法則)
システム改訂の負荷はそのシステムの年齢に比例する。
 システムは年月が経つにつれて,何をやっているのかわからなくなる。それを防ごうとして,手を加えるとさらにわからなくなる。
 10年も使っているシステムは,その間のパッチあて改訂で例外の固まりになっている。それを理解できる人はいない。1年しか経たないシステムなら,どこをどう直せばよいか全員が知っている。上の命題のように比例するのであれば,どの頻度で改訂してもコストは一定なのであるが,どうも完全な比例ではなく非線型らしい。しかもその最適期間はちょうど関係者が忙しい時期に一致するようだ。

システムの寿命は関係者の平均職場滞留期間と一致する。

平均5年でローテーションされる職場では,システムは5年に一度の大改造が行われる。エンドユーザ部門は新担当者が自分のニーズを入れたがる。情報システム部門はシステムがブラックボックス化したので改訂したいと考える。


デバッグ


情報システムは寿命により改訂することもあるが,品質管理が不十分でエラーがあり,それを直すために部分的に修正することが多い。このエラーを探して直すことを「デバッグ(虫潰し)」というが,これが難儀な仕事である。(デバッグの語源は次のように伝えられている。その当時はプログラムリストを連続用紙に出力していた。長く延ばしてその上にはいつくばりエラーを探す姿が,褌を広げてノミやシラミを探すのと似ているからだとのこと。その頃は欧米人も褌をしていたとみえる。)

虫は死なず。ただ隠れるのみ。
虫を潰すとシステムが複雑になる。

マッカーサーは「○○(老兵)は死なず。ただ消え去るのみ」といった。長島茂雄は選手引退時に「○○(巨人軍)は永久に不滅です」といった。彼らがプログラマだったら,この○○は「虫」だったろう。ある箇所を修正すると,それが原因で違うところにエラーが発生する。あちこちいじくっているうちに正しいところまで直してしまう。
 トラブルがあったときに,その根本から原因を追求するのは時間がかかる。ともかくこのへんが原因だろうと決めて,対症療法で逃げるので迂回路を設ける。それでも直らなければ違う個所を探す。こんなことをやっているうちに,GOTOは増加し,せっかく最初は構造化したのに,結果としてスパゲッティ化したプログラムになる。

デバッグの影響は期末になるまでわからない。

こんな手順で直すのだから,10個のエラーで5個見つかれば成功である。しかも,テストする時間がないので本番でやってみてOKなら事終われりとなる。したがって,日次処理でのデバッグの影響は,月末処理や期末処理の忙しいときになって発見される。忙しいのだから,また対症療法で逃げることになる。
 このようなことを述べると,初心者は「虫のわかないプログラムを作ろう」などと考える。しかし,昔のCOBOLで鍛えたベテランにとっては,デバッグは知的ゲームであり「デバッグはど面白い商売はない」のである。老兵の生き甲斐を奪ってはならない。しかも,「虫のわかないツール」そのものが虫の巣窟なのだから,結果はもっとひどくなるだけである。


文書化


昔から文書化が重要だといわれてきた。COBOLは文書的表現ができる言語だといわれていたが,それなのに文書が必要だとすれば,いったいCOBOLとは何だったのだろう。一時はCASEが華やかに喧伝されたが,その後はどうなっているのだろう。

すべての文書化は本番移行後に作成される。

プログラマはプログラムを作るのが好きである。ともかくプログラムを書くのが第1と心得ている。外部仕様書,内部仕様書,操作仕様書などの文書化は本来は各ステップで作成し,それぞれの確認を得てから次のステップに進むことになっているが,実際には本番移行完了時点で作られる。しかも,その順序は逆で,操作仕様書,内部仕様書,外部仕様書の順に作成される。それでも作成されればよいほうで通常は次のようになる。

すべての文書化は,担当者の引継ぎのときに作られる。

開発のときですらそうなのだから,対症療法的改訂時に仕様書も改訂するなどということは幻想にしか過ぎない。

ソースプログラムこそ真実を示す唯一の文書。

「ドキュメントはありますがねえ。ただし5年前のものですよ」
 なかには,ロードプログラムは存在するがソースプログラムはどこにあるかわからないとか,同じ名称のものが5つもあったなどというのは,そう稀なことではない。


CASEツール


最近は,CASEツールが発展してきた。仕様書を作るとプログラムが自動作成されるようにもなってきた。ところが,これも標準化や利用基準を厳重に管理しないとややこしい問題が発生する。

すべての生産性向上手段は項目名の標準化を前提とする。

上流だ,下流だ,いや統合だなどと騒ぐ前に項目名を1内容1名称にすることが肝要である。それができればツール導入の効果の大半は完成したことになる。

 ところが,項目数は数千個にも及ぶ。それをすべて異なる名称にしようとするので,命名された項目名は,誰もが理解できないような名称になる。

CASEツールの主機能はワープロ機能である。

ベテランほどこのようなツールを使いたがらない。強制すると,プログラムを作成してから,CASEツールで仕様書を作成する。ファイルデザインも後になってから登録する。項目名も自作するので,同義語が多くなる。
 このような人にCASEツールをみせると,決まっていうのは「プログラムを与えたら自動的に仕様書を作成する機能はないのか」である。
 一般にCASEツールを導入すると,関連文書が数倍に増大する。「紙への信仰は捨てられない」ので,キャビネットが必要になる。CASE導入にあたっては,キャビネットのスペースを考慮することが肝要である。
 実際にCASEツールをプログラムの自動生成にも使われることもある。そのときは無駄なプログラムの粗製濫造用ツールとなっている。しかし,よほどのことがないかぎり,リポジトリ的に利用されることはない。

ERモデルとDFDモデルのどちらを重視するかで育ちがわかる。

最近の方法論で育った人はERモデルを重視する。EUCに関係している人もそうである。従来のシステム開発に従事していた人はDFDモデルを重視する。


ニーズとシーズ


技術はニーズを規制する。
まかぬ種は生えぬ。

マーケティング理論では,「消費者ニーズにマッチした商品を作る」ことが商売の基本であるかのようにいわれるが,いまでかって消費者ニーズにより革新的な商品が生まれたことはない。提供者が消費者ニーズであろうと想像した商品を市場に出したので,それによってニーズが喚起されたのである。
 電気が発見され電球が発明されるまでは,消費者はもっと明るいランプがほしいと思っただけであり,ユーザニーズを調査したならば,ランプの芯やフレームの改善で終始したであろう。情報を速く伝えたいニーズはあっても,郵便馬車制度の改良がいわれただけであろう。電球や電話を発明したのは,マーケティングの研究をしたからではない。マーケティング調査をしたら,このような発明はされなかったし,商品化できなかったであろう。
 パソコンやGUIをみせるから,それを利用したニーズがでるのであって,何もないところにこれらがほしいというニーズはでてこない。ユーザに何を欲しいか聞いても単なる改善要求しか得られない。本当に革新をしたいのであれば,実物を作って示すことが重要である。
 新製品開発では当然なことであっても,情報システムになるとこの考えは受入れられない。「技術先行のアプローチはいけない。ユーザ主導で考えるべきだ」といわれる。しかも,ユーザにPRしようにも,そのプロトタイプを作ることさえ認めないのだから,ユーザがそれを希望するはずがない。すなわち,情報システムの分野では革新を行おうとするならば,ユーザニーズ主導から脱却することが必要である。


念には念を入れよ


調査をすれば必要がなくなる。

(新技術)
 新しい利用方法はユーザからは出てこない。他社を調査してもやっていない。すなわち,提案者の一人よがりとされる。
 (既技術の選択)
 CSS系のDBを導入することを例にする。担当者は評価項目と商品評価の一覧表を作りたがる。ORACLEだのSybaseだの多くの(本当に多い!)商品カタログを集め,ベンダの説明を聞き,それでも安心できないので仮導入してテストをする。
 一人では不安だからとして数人を任命すると,かならずその間で商品シンパができる。評価項目で商品を評価するのではなく,商品から評価項目を作ろうとする。
 さらには,使うのはユーザだからといって,多くのユーザに見せてアンケートをとる。そうすると,ユーザは全然違う観点(ベンダの説明者が美人だとか,アイコンがきれいだというようなDBには関係のない事項がほとんどである!)で指摘する。それも評価項目に入れる必要がある。
 ともかくA>Bになりかけたときに,Bのバージョンアップが行われる。すると評価の点数が変わりA<Bになることが多い。一般に「比較評価とはどれが最近にバージョンアップされたか」と同じになる。
 このようなことを繰り返していれば,永久に導入をしないで済ませることができる。


決断は勇気を必要とする


飛びつくのは危険。飛びつかないのはもっと危険。

サーバのRDBやミドルウェアを何にするかを決めるのは難しい。何を決めてもすぐによりよいものが出現する。すなわち,どの決定もかならず失敗する。しかし安定するのを待っていたのでは,その間の機会損失が莫大になる。最も時間がかかるのは人間系なのである。早く新しい環境に慣らすことが,結局は効果を早く得ることにつながる。

新しい提案には,1つの賛成理由を考えるよりも1ダースの反対理由を考えるほうが簡単である。

もっとも1ダース列挙しなくても,通常は次の3つで結論に達する。
   「ユーザがついてこられるかね」
   「現行の方法でも運用でカバーできるだろう」
   「ところで誰がやるんだね」


新技術の評価基準


新しいアプローチは新しいトラブルを生む。

EUCを例にしよう。ユーザが使いやすいようにというので,「1を押せば○○集計表,2なら△△分析表,・・・」のような個別処理メニューを提供する。すると,ユーザはさらに多様なメニューを要求するので,情報システム部門は多忙になる。それに応えないとユーザの不満が高まる。
 公開データベースを整備し,簡易言語でアクセスできるようにすると,処理を簡単にするために,公開データベースを帳票直前の形式にしろという。そうすると,多種多様な公開データベースになり,その管理や同期合わせのために,システムが複雑になる。
 その対処のために,正規化したデータベースで提供しようとすると,今度は教育が必要になる。歩留りも悪いしQ&A対応が大変になる。それでまた個別処理メニューの提供に戻る。それならいっそのこと,情報システム部門が作表して配布するほうが簡単だということになる。・・・

最初に覚えた言語が簡易言語

どんなに便利な4GLが出現しても,最初に覚えたCOBOLのほうがわかりやすい。ベテランは新技術を使わない。とくにユーザにある言語(COBOLでもExcelでも)を普及したら,更によい言語が出現したのでそれに切り換えようとしても,旧言語を廃棄するには少なくとも5年はかかる。その間には新言語も旧言語になっている。これは言語だけにとどまらない。メインコンピュータで育った人はパソコンに関心を持たない。


新技術とマスコミ


成功例は発表されるが失敗例は報告されない。
事例発表の50%は報告者の希望である。

情報システムの分野では,各種の事例報告が活発である。どこどこの企業ではSISの構築に成功したとかBPRを達成したなどが,講習会や雑誌で多く喧伝される。当然ながら失敗例は公表しない。そのため,それらをやればかならず成功するような錯覚を受ける。
 異機種間接続の失敗例は聞いたことがない。しかし,個人的に聞くとだれもが2度とやりたくないという。ところがユーザはそのような裏話を聞いていない。すべて簡単にできると信じている。自社で情報システム部門がそれを困難だというと,情報システム部門が無能なのだと結論する。
 他社の立派な事例報告も,後で非公式に聞いてみると,実際にできているのは半分で,半分はこれからの計画であったり,実現できなかったものである。

マスコミが取り上げなくなったときが役に立ったときである。

犬が人を噛んでもニュースにはならない。この30年間,汎用機でCOBOLを用いて給与計算システムを開発した事例は一度も記事になっていない。ところが,すべての企業がこれを行い,しかも成功している。マスコミから消えたら取りかかれ。


エンドユーザコンピューティング


EUCについて2人が議論するとき,2人のEUCの定義は違っている。

AはスタンドアロンでのOA的利用をいっている。Bはホストデータの検索加工のこといっている。さらにCは電子メールのことをいっている。

エンドユーザの定義では組織上の所属がすべてに優先する。

ユーザ部門に所属しさえすれば,その人がコンピュータのプロでもエンドユーザである。先月まで情報システム部門にいた者がユーザ部門に転出し,そこでシステムを構築すると「先端的なエンドユーザによるシステム開発(EUD)」となる。ところがユーザ部門にいた者が情報システム部門にきてシステムを開発しても「旧態依然とした情報システム部門主導のシステム」となる。
 「当社はEUCで○○システムを構築した」という話をよく聞くが,実際の状況を調べると,そのユーザはその部門で10年間もコンピュータを担当していたベテランで,その構築には情報システム部門から数人が応援をし,実際の構築作業はメーカーに依頼したなどという例はざらにある。
 最近はEUCをしているのはカッコよい。もしEUCと称したいならば,システム化案件がでるたびに,情報システム部門からその部門にベテランを人事異動させて,終わったら戻せばよい。もっとよいのは,「情報システム部」という名前を営業部とか経理部としておくことである。「当社ではすでに情報システム部は廃止しました。すべてEUCでやっています」「すごいですね。では情報システム部にいらした人たちはユーザ部門に移ったのですか」「ええ。全員が営業部になり,そこで全社の情報システムの開発やコンピュータのオペレーションをしています。たまたま取締役の某が情報システム部と営業部を兼務したものですから」。

EUCとは,情報システム部門はエンドユーザが自ら行うものと考え,エンドユーザは情報システム部門がエンドユーザに使いやすい環境を開発してくれると信じている,同床異夢のコンピュータ利用形態である。

従来,ユーザはAIつき音声応答つきのコンピュータを持っていた。

EUCの目的は「必要なときに必要な人が必要な情報を容易に得られるようにすること」である。その趣旨には情報システム部門もユーザ部門も一致する。ところがその実現手段では,情報システム部門はユーザがコンピュータ知識を習得して自分でやることだと考えるし,ユーザ部門では情報システム部門が全部お膳立てをしてくれて,自分たちはせいぜいテンキーを押す程度でよいと思う。「いままでは情報システム部門に電話で頼めば詳細説明しなくてもやってくれた。なぜ,いまになっておれたちがやらなければならないのか」


エンドユーザコンピューティング


パソコンの稼働率は昼休みにピークになる。

ユーザは,EUCの技術はなかなか覚えない。講習会にも参加しないしマニュアルも読まない。HELP機能を容易しても参照しない。しかし,コンピュータゲームはマニュアルもHELPもなくてもすぐに覚える。
 ワープロや表計算ソフトのバージョンアップは情報システム部門でないとできないが新作ゲームは自分でインストールできる。

使わせたくない機能はすぐ伝播する。

ファイルの登録手順はすぐに覚えるが,削除手順は覚えない。ジョブのプライオリティや空いているクラスは,教えないのに全員が知っている。ゲームソフトはプロテクトの外しかたまで普及している。


EUCのコスト


ホワイトカラーの生産性は情報機器の整備の如何によらず一定である。

EUCを行うとコストがかかるといわれる。それには端末やホストのコスト増加がよく指摘される。しかし,最大のコスト増加は,ユ−ザが端末を利用している機会費用である。
 案外ユ−ザはコンピュ−タが好きである。販売部門にいながら,客先を訪問するよりも端末の前に座るほうが好きな者が出てくる。その数は次第に増加する。そのうちに全社員総コンピュ−タ係になってしまう。
 それが業務改善に役立つ情報を得るために,端末を駆使しているのならばよいのであるが,そうとばかりはいえない。ユ−ザは情報の中身よりも出力帳票の体裁を重視する。必要な情報は短時間に得られたのに,表示方法を変えたりグラフ化するなどの体裁をよくするために,その数(十)倍の時間をかけていることは珍しくない。問題点を明確にするために,このような改善をするのはよいことであり,非難する気はない。問題なのは度が過ぎる傾向があることである。
 この現象は,自分が意思決定をするのでなく,上司に見せる資料を作成するときに顕著である。上司は内容よりも体裁をほめることが多い。数表の羅列では不満を示すようになる。すると,次第に体裁改善競争が始まる。そのために端末に座る時間はますます長くなる。
 パソコンはますます上位機種になる。プリンタもカラ−の高価なものが要求される。一つの部門がそうすると,他の部門はそれに負けないものをほしがる。パソコンは価格が下がり性能がよくなった。しかし,その大部分はヒュ−マン・インタフェイスの改善に費やされ,本来の目的である情報の入手にかかわる部分はそれほど改善されていない。
 そのうちにホストからの出力にも同様な体裁を要求するようになる。システムは出力系だけが異常に大きくなる。ホストの資源も大きくなり,システム開発改訂の規模も大きくなる。情報システム部門は出力に凝るための負荷が増大する。
 すなわち,情報処理は急速にプレゼンテ−ションツ−ルと変貌している。それは非難すべきことではない。しかし,情報コストにはかなり厳しい企業でも,このような観点からのコスト論議はあまりなされていないのは奇妙である。


ダウンサイジングの問題点


サーバーを1台設置するとシステム部門から人身御供が1人必要となる。

サーバーのお守り,ファイルのバックアップ,ソフトのバージョンアップなど多くの作業が必要だが,ユーザはそんなことをしたがらない。結局システム部門から転出させることになる。しかも,パソコンやUNIXの技術を持った数少ない要員を張りつける。その結果,常にシステム部門はこの分野を知らない状態になり,周囲からホスト一辺倒だと非難される。すなわち,ダウンサイジング環境が整備されるに従い,情報システム部門のダウンサイジングの分野での知識経験は相対的に低くなる。

GUIはシステム開発労力を増大する。

従来のように,ヒューマンインタフェイスに自由度が少なかったときは,端末の操作性や画面のデザインに関するユーザの趣味も限定されていた。ところが,GUIを提供すると,この線は赤くしようとか,枠の角を丸くしようなどと,ユーザの趣味が急速に多様化する。「ユーザ趣味主導型」の極致になる。それに振り回されて,システムが完成するのは極度に遅くなる。GUIは自分で開発するには役に立つ機能であるが,他人のためのシステムを作るにはかえって邪魔なものである。
 また,情報システム部門の担当者も面白い機能があるので,あれこれやってみたくなる。それとユーザ趣味が重なると,共鳴が起こり無限大にまで発散する。情報量は増えないのに,コストだけは着実に増加する。

わからないことは英語をカタカナにしてもわからない。
絵にしてもわからない。

プルダウンメニューで「切り取り」と「削除」の違いもわからないし,なぜ「コピー」では「貼り付け」が必要なのかわからない。アイコンを見て内容をしるには,かなりの想像力が必要で,そうでない者にはチンプンカンプンである。理解している者にとっては,マウスクリックでもコマンド入力でも同じである。


企業文化とのコンフリクト


一般に,旧い文化が新しい概念に遭遇すると葛藤が生じる。EUCもダウンサイジングも,企業での業務のしかたに影響を与えるものである。従来の業務方法や職場の雰囲気がそれに合致していれば,円滑に発展することができるが,一致していないと,なかなかうまくいかないだけでなく,そこにコンフリクトが生じる。その場合,単に新技術の否定としてではなく,情報システム全体への反発となる危険すらある。また,業務や雰囲気を変えるために,これらの情報技術を適用しようとする場合には,そのコンフリクトは深刻なものとなる。

技術はオープン,情報はクローズ。(LANのブラックホール現象)

クライアント・サーバ系の利用形態では,オープン化により多くの機種がLANに接続できるようになり,情報の共有化が進むと考えられるが,実際には,自部門の情報は他部門には見せたくないので,電子メールや掲示板は部内専用にするようになり,従来ホストを利用していたときには,公開ファイルとして全社で共有していた情報も,LAN内部から外部に出てこないようになる。

入っていないものは出ない。

物言えば唇寒しの環境では,電子メールや電子掲示板を作っても,公式に決定されたものしか入力されず興味のあるインフォーマルな情報は入らない。当然見てもつまらない。部外者が関心を持つと,すぐに見せないようにセキュリティが重要だという。

システムは分散,組織は集中。

ダウンサイジングなど情報システムを分散せよというが,実務の権限は委譲しないし意思決定の分散化もしない。企業文化と違うシステムができてしまう。
 本社営業部が情報を共有したり伝達したいのは,支店販売部門であり,本社の経理部門や総務部門ではない。支店の状況は逐一知りたいが,その情報は他部門には知らせたくない。本社営業部がほしいのは,構内回線としてのLANではなく,自部門独占のホストコンピュータからスター型にむすんだ,営業部門だけの全社的ネットワークである。
 LANやWANを全社的に張り巡らすのは費用がかかり,その完成までには時間がかかる。情報システム部門は,本社−大支店−小支店のように,場所単位で逐次LAN化し,その後でWANでむすびたいと考えるが,営業部門は,まず本社と全支店の営業部門間のネットワークを作れと主張する。経理部門や総務部門も同じである。


接続時間の法則


接続時間はかならず3分の倍数である

インターネットやパソコン通信での接続時間は,12分15秒とか33分4秒というように,分の単位はかならず3の倍数になる。すなわち接続を切った途端に料金が上がる仕組みになっている。これは,タクシーで「ここでいいよ」といった瞬間にメータがあがるのと同一の法則に基づく。どなたか,14分台や35分台になった経験のある人はご連絡ください。

11時になるとつながらない

時間を気にしながら使うのは精神的に悪い。それでテレホーダイにする。すると11時まではかけるのがもったいない。11時になった瞬間にかけると,つながったためしがない。朝8時以前に使えるほどには,まだ年とってはいない。(最近,昼間の時間を割引にしたプロバイダもあるようですね)


ERPの法則


昔,ユーザニーズに応えるのが情報システムの使命であった。
今,ユーザニーズを無視するのが情報システムの使命である。

欧米での開発によるERPが日本でも普及してきた。それを成功させる秘訣は,アドオンを厳禁することだそうである。社内で従来から開発してきてきたシステムは,ユーザの趣味を唯々諾々と取り入れてきたので,複雑怪奇非効率的になったのだ。ERPはよくできているというが,ユーザの要求を無視してよいなら,よいシステムになるに決まっている。

機能の不備は業務が悪い

日本の業務慣習は欧米のそれとは異なる。当然ながら「製番管理」や「価格事後調整」などの機能は持っていない。通常の製品ならばユーザニーズに合わせて製品を変える。それで多品種少量生産になったのだが,ERPでは,自社製品に合わないのはユーザがけしからんという。これに従う自動車メーカは,おそらくそのうちにT型フォードを生産するだろう。
 歴史は繰り返す。そのうちまた日本経済が米国を凌ぐ時が来る。そのときERPは,ERPはよくできているというが,「根回し機能」を売り物にするのだろうか。

ERPと化粧品は高いほど売れる
ERPとゲームは複雑なほど好まれる

それにしてもSAPのR/3は高いですねぇ。会計システムだけでも数億円して,その開発に10人以上かかり,その上,維持保守のために人がいるんですって。当社などは,数十年会計システムをやっていますが,開闢以来の累積費用は,まだその半分にもなっていないのですが・・・。ところでERPにはどんな節税システムがあるのでしょうか。
 機能説明を聞いて驚きました。R/3には全部で数十万個のパラメタがあるんですって。それをどうやって覚えるのでしょう。COBOLでは数十個のメソッドと,ユーザフレンドリィな名称の組合せだけで,ほとんどのシステムができたのですが。


イントラネットの教訓


注意:よく走るハツカネズミは,もっと速く走らされる

ダム端では仕事にならない。インテリジェントターミナルだ。パソコンだ。Win95だ。200MHz,2GBだ。ブラウザだ。NCだ。・・・あれ? ダム端に戻っちゃた。IBMはDOS/V機にブラウザをのっけてイントラネットに使えるようにしました。そのうち,富士通はFMRを? やはり物は大事にしましょう。
 メインフレームよさようなら。LANです。クライアント・サーバです。管理費が高くつきますね。ではイントラネットにしましょう。回線もやすくなったことだから,サーバを利用部門に置くよりも,集中したほうが管理が容易です。情報システム部門はサーバだらけになりましたね。これでは場所ふさぎですから,1台の機械にまとめましょう。・・・あれ? これはいつかやってた方式ですね。
 それにしてもブラウザとデータベースの連携は大変です。いや,そんなことはありませんよ。当社のブラウザ,当社のデータベース,当社のサーバソフトを使えば連携は容易です。あ,当然ハードも当社のものを使っていただかないと,責任のあるサポートができません。

対策:1周遅れのランナーは,トップを走っているように見える
補則:途中でゴールが引かれれば,実際にトップになることもある


ホームページ考

(ここでの法則は,このホームページには適用されません。
そのため,誤解を招くおそれのある解説は省略しました。)


見せたい情報と見たい情報の間には大きなギャップがある。
 [new!]により,3ヶ月以内手を加えていないことがわかる。
 [Sorry Japanese only]とあるページは,本来日本人しか見ないページである。

テキストオンリーにすると,画像が気になる。画像も表示させるとがっかりする。
 長時間かかってローディングしたJavaアプレットに,面白いものがあったためしがない。

ニュースサービスで紹介されたURLを見に行くと,すでに消されている。
 紹介記事のほうが長い場合もある。

検索エンジンを使うことにより,言葉の多義性を認識する。
 目的のURLは,いつも「次の20件」にある。


グループウェア考


電子メールの受発信数は情報共有化の逆尺度である

電子メールの本質は,情報伝達の秘密性の追求である。どこかで会えば会ったことがばれる。電話をすれば近くの者に聞かれる。手紙やFAXだと持ってくる人に見られる。電子メールこそ,伝達したことすら第三者に秘密にできる手段なのである。電子掲示板(会議室)があるのに,それの利用が少なく,電子メールが愛用される組織では,第三者に秘密にしようとする尺度だといえる。

電子掲示板の公開度は人事異動の時に明らかになる

クローズな文化の組織では,「あの人には見てほしいがあの人には見られたくない」が複雑に入り組んでいる。そのために,電子掲示板のアクセス制限が複雑になっている。人事異動の時にそのアクセスルールを修正するのが大騒ぎになる。

グループウェアは情報伝達を阻害する

商談報告を例にする。口頭で報告していた頃は雑談で多くの情報が伝達できた。それが報告書で報告することになり,フォーマット以外の情報は伝達されなくなった。電子掲示板になると,誰が見るか気になるので,「○○日に○○の件で○○に会いました。結果は○○でした」の26文字以外は記述しなくなる。上司はそれではわからないので,呼びつけて口頭で報告させる。

アクセス権限をピラミッド形式にすればうまくいく

グループウェアの管理が初心者のときは,一般社員よりも課長は広くアクセスでき,部長はもっと広く,役員はさらに広くというように,▽型にしがちである。ところが,情報提供側では上位者に見られるのはイヤなものである。それで当たらずさわらずのことしか入力しなくなる。なかには励ましのつもりで,社長が一般社員の発言を見て,掲示板に発言したりすると,この傾向は加速される。むしろ「上位者見るべからず」として△型にしたほうが,有意義な発言が活発になるのである。ところが上位者は,グループウェアは下位の者を監視するツールだと思っているので都合が悪い。


マーフィー妖誤集


4GL

SQLを第1政党とする第4統治体制。HOWではなくWHATだけを重視する。その理論は結果さえよければ手段は問うべきではないという思想に基づく。そのために,実現のためには組織の全資源を費やすなど無鉄砲な行為もあり,長老たちを震撼させているが,世の風潮はこれを支持している。

BPR

他人の作った機械語プログラムを人間の読めるプログラムに戻すことをリバースエンジニアリングといい,アイデアを盗むのに有効な技術である。これを略してリエンジニアリングというが,この思想をビジネスプロセスにも適用するものである。すなわち,他社が業務改革で成功したアイデアを盗用して自社に適用すること。

CASE

caseを「格のある患者の立場で事件の真相を訴訟する箱」と覚えたように,この単語にはいろいろな意味がある。「上流だ下流だいや統合だ。ERモデルだ。リポジトリだ」といろいろいわれるが,結局は特殊用途のワープロとして利用されているのが一般的であり,高度に利用されているときは不要なプログラムの粗製乱造ツールになっている。

DOA

「これからの仕事は勘と度胸ではダメだ,データを重視したアプローチをする必要がある」として,やたらデータを集めたが整理に困ってしまった。その対策として正規化などの標準化がいわれているが,集めべきデータは何か,どう集めるか,データそのものの信頼性はどうかなどには全然役立っていない。

GUI

コンピュータ利用機会均等運動の所産。識字率の低い発展途上国でもコンピュータが利用する必要がある。指をつめたヤクザ社会でも情報化は必須になった。その対応として,画面表示は文字を使わず絵文字にし,タイプライタをやめてマウスにする。なお,タイプに毒された者にはペンコンピュータが用意される。

HTML

文字通り言語である。本来は文書の一部にタグをつけて,ブラウザで読みやすいようにしたものであるが,Javaなどの機能追加により,本来の文章はプログラムの隙間に記述する程度となり,プログラム言語になってしまった。

Java

ジャバコーヒーの湯気が揺らぐのをブラウザで表示させるために開発されたプログラムである。当然この場合はホットコーヒーである。ところがJavaを多用した画面はクールだといわれる。送信側ではホットなものにしようとしても,受信側ではクールと見ることが多い。ここにコミュニケーションの苦悩がある。

LAN

限られた地域での付き合いのこと。地方分権の企業版。支店や工場では,なるべく本社の影響を受けずに,自分たちだけでうまくやろうという文化がある。情報システムでもそのニーズに応えて,自分たちの内部だけで利用して余所者を締め出そうとする閉鎖的な仕組みが必要である。だからLANを設置すると,そこから外部への情報発信は少なくなる。

Mosaic

インターネットでアクセスされるサイトは,成人向けのサイトが多いのは当然である。ところが初期のブラウザは,画面の解像度が悪く,肝心のところがモザイクになってしまうことが多かった。

OSI

ISOはISO9000で有名な国際機構であるが,オープン化対応として異機種間の接続の基準を作成した。ところが,多数の国から外交官が集まり,会議は踊る状況になってしまい,TCP/IPの侵略を招いた。これでは,本末転倒だといわれ,ISOではなくOSIではないかと揶揄された命名である。

RAID

米国からみると日本の品質管理はマニアックに見えるらしい。ともかく数打ちゃ当たると第2次世界大戦やベトナムでは絨毯爆撃をやった国である。一方が故障したら他方を使うという構成を並列というが,ディスクでも安物をずらり並べれば,効率のよいものが安くできると考えた。しかし,組織でもそうだが,あまり大勢がいるとそれを管理するのが大変になる。

RDB

人間の行動は予知できず勝手な動きをするという認識に基づくデータベースである。すべての行動に適合させることは,すべての行動にとって最適ではない。そのスラックは当然コンピュータにしわよせされる。すなわち,人が楽をすればコンピュータ資源を浪費することになるが,それは相対的関係(レラティブ・リレーション)にあることから名付けられた。

UNIX

オープン教の最大宗派の教典。当初は変人の間で,個人救済を目的とした密教的小乗宗教(ユニ)であったが,最近は一般人が集団帰依をするようになり,大衆大乗宗教へと変化してきた。キリスト教にならい二つの宗派が対立していたが,窓教という異教が強くなってきたので宗教和解が行われた。しかし,次第にその勢力が弱まってきている。

Windows

従来は窓の側で仕事がないのに仕事をしているふりをしている高年齢層を窓際族といったが,最近では若者までがそうなってきた。しかも若いので,複数の窓を開けたり閉めたり,ネズミと格闘したりして音まで出すので,はた迷惑なのは窓際族より始末が悪い。注意をするとNT(ノン・トラブル)など受け流すのが憎らしい。

イントラネット

せっかく従来のメインフレームTSSでの集中管理からCSSでの分散管理に変えたばっかりなのに,また集中管理にするんですかねえ。そうなると情報システム部門がHTMLを書かされることになるんでしょうか。

オープン化

「オーブン禍」の訛り。昔はIBMという専制者の圧制に苦しんだ人民が,プロトコルは神の前に平等であるとして革命を起こしたが,革命委員会のマイクロソフトがまた独裁者になってしまった。その独裁政策は基礎(BASIC)的なことから窓の開閉にまで及び,人民はまるでオーブンで焼かれているようだと阿鼻叫喚したことによる。

オフコン

日本では信者も多かったが,UNIX教などの伝道普及により異端とされて,公式には世の中には存在しないとされているコンピュータのこと。この言葉を口にすると品位を疑われるので,隠れ信者は「オ○コン」と書いたり「ビジネスサーバ」と婉曲な表現をする必要がある。

オブジェクト指向

目的を重視すること。あまりにも当然であるが従来のシステム構築理論や開発手段ではそれがあいまいであった。それを明確にしようとする概念である。また当然のことであるが,その目的とはコンピュータ資源をいかに浪費させるかにある。

クライアントサーバシステム

従来はホスト(主人)コンピュータに多くのパソコンを結び,主人の資産を寄食していたが,主人の資産が底をついたので,クライアント(客)とサーバ(給仕人)とでやっていこうとすること。主人がいないので気は楽であるが,責任を持つ者がいないのが困る。

罫線

日本はソフトウェア輸入に際してこの機能を義務付けているが,国際社会にあわない特殊機能であり貿易障壁であると批判されている。国内でもこれがソフトウェアの生産性やプリンタ能力を阻害しているとの指摘もあるが,コメ以上の日本文化の基本だから絶対に譲れないというのが多数意見である。

システム・アドミニストレータ

最近の情報分野の低迷により情報処理技術者試験受験者数低下で財政収入に苦慮した通産省が,コンピュータの素人を対象にして創設した認定資格。直訳すれば「組織管理者」であるが,コンピュータ技術習得で脱落した専門学校生などがそれにあたる。すなわち,「組織に管理される人」とか「コンピュータに使われる人」であり,能動形と受身形を誤った例である。

バーチャル・リアリティ

未来の国家管理社会において,国民の現実直視を防止するために,仮想的現実感を与えることが必要である。そのために特殊メガネ等を着用する方式が研究されていたが,ほぼ実用見通しがたった。次の段階ではこれの着用を法的に強制して,究極的には脳の一部に移植することが計画されている。

パソコン

英語ではパーソナル・コンピュータで個人用であるが,日本企業ではまだ数人に1台なのでプール・コンピュータと称すべきである。また,その購入や管理および運用方法まで規制されているので,パブリック・コンピュータというほうが適切だとの説もある。

ヒューマン・インタフェース

人間的境界,すなわち人付き合いのこと。ビジネスではCS(顧客満足)といわれているが,情報用語ではヒューマン・インタフェイスという(以前はMMI−マン・マシン・インタフェイス−といったが女性差別語として廃止)。相手の気持は千差万別なので,各人に気に入られるには,かなりの苦労が必要である。

マルチベンダ

日本では伝統的に系列取引の商慣習があり,一社からのコンピュータ購入が行われていたが,日米貿易協議により,一定以上のコンピュータを購入するときは複数のベンダから購入すべきことを業界自主規制として定めたもの。違反の罰則規定はないが,環境破壊につながるとして道義的非難を浴びる。

マルチメディア

情報伝達方法には,口頭,電話,文書など多くの手段(マルチメディア)があるが,それを規制して,画像や音声もいったんコンピュータを通さないと伝達させないようにすること。本来はマルチメディア「規制」というべきであるが,規制緩和の風潮により,「規制」の文字を削除した表現が一般に流布している。

ミドルウェア

バベルの塔以来,多くのアプリケーションやOSが出現した。これらをそれぞれの用途特徴によって使い分けるのは,コンピュータリテラシの低い中高年者や中間管理職にとって困難である。彼らミドルのために,一つでも使えるようになれば,他のものも使えるようにしたものである。

メインフレーム

大艦巨砲時代の戦艦大和的コンピュータのことを指す。すでに戦闘機やミサイルの時代であり,これを擁護するのは大時代的感覚とされる。ところでこれを「汎用機」ともいうが,それならば,パソコンやワークステーションは「単用機」であるから,それらだけで全社的なシステムを構築するのは無理であると言外に匂わしている。

ワークステーション

文字通り作業机のこと。IBMは大机願望者が多かったのか,個人用机(パソコン)のこともワークステーションといったが,一般的に個人用とするには大き過ぎるし,共同用とするには小さいものをいう。以前は技術屋が図面台として使うのが通常であったが,最近は事務屋の打合せにも利用されている。