昔，このようなものを作って精神安定剤にしていました。汎用コンピュータ全盛時代のものですから，若い人にはチンプンカンプンでしょうが，われわれの年代にとっては，苦しくてもファイトに満ちた時代の記念碑とも思えるのです。それで消さずに保存しておきます。
なお、比較的新しいものは、Vol.2に掲載しております。
次の少なくとも一つに該当するかたはご遠慮ください(^o^)。
トラブル回避のためのいいわけ。このような「法則」は，単に揶揄して楽しむためではありません（ホンネでは楽しんでいる？）。また，自社での状況を他社にも見出して安心するための精神安定剤でもありません（現実には，この効果が多いようです）。このような法則が作用するのを回避するための問題意識を喚起することが目的です（ホント！）
昔，コンピュータが導入された頃には「電算室」などと呼ばれたが，その後，いつのまにか「計数管理部」になり「情報システム部」になった。さらには「経営戦略情報システム管理部」と名乗ろうとしている。ここに情報システム部門の事大主義の片鱗がみられる。この部門が他部門と違和感があるのは，このへんに起因しているのかも知れない。
「情報」「経営」「戦略」「管理」「システム」を情報システム部門の５大慣用句という。どのような言葉にも付けられるが，特別な意味を持たないのは「根岸の里の侘住居」の類である。
では，これらの単語はどのような意味を持つのだろうか。
「情報」とは，情報システム部門が取り扱う一切のものを指し，それ以外のものは情報であっても「情報」とはいわない。コンピュータに入力する残業時間のデータは立派な情報であるが，競争会社が新製品を発表しそうだなどというニュースはコンピュータに入らない限り情報とはいわない。すなわち，情報とはコンピュータ処理の原料と製品（もし製品といえるものがあれば）のことである。
「管理システム」について考える。その名称のつく業務の実際の内容は，販売「管理システム」とは請求書発行処理のことであり，人事「管理システム」とは給与計算のことである。すなわち，「管理」や「システム」とは，ある部門の業務を機械処理をする場合に使う接尾語であり，一般用語としての管理やシステムとは関係がないことがわかる。
「経営情報システム」とは，ＭＩＳ（Management Information System ）の日本語訳である。このコンセプトは６０年代に，ともかくすべてのデータをコンピュータに入れておけば，経営に必要な情報は即座に取り出せるので，中間管理層は不要であるといわれたものである。ところが，その後の経過をみるとこの発想はＭＹＴＨで終わり，ＯＬの省力化になっただけで，結果としてＭＩＳＳであったというイワクつきの用語である。すなわち，「経営」とは，「失敗の」とか「幻想の」とまではいわないまでも，単純業務のことであるとしてよい。
「戦略的情報システム」はＳＩＳ（Strategic Information System）である。８０年代後半から９０年代初にかけて，情報は企業競争の武器であり，企業戦略に情報技術を活用することが，サバイバル競争に生き残る手段であると喧伝された。その事例の多くは，取引先と企業間ネットワークを構築しオンラインでデータを交換することにより，より顧客指向の戦略を実現することである。
ところがＳＩＳ先進企業に聞くと，それらの情報システムは，とくに「戦略」を意識したものではなく，自社や取引先の便宜を図った結果がこうなったのだということになり，「振り返ればＳＩＳ」のような言葉も出てきた。現在では，ＢＰＲ（ビジネス・プロセス・リエンジニアリング）に置き換えられ，ＳＩＳという用語はキャンペーン後数年で死語になった。すなわち「戦略」とは「短命の」の意味であり，内容は通信回線を利用してデータを交換することである。
以上から結論すると，「経営戦略情報システム管理部」とは，悪く解釈すれば「短命の幻想のコンピュータ処理を担当する部門」であり，好意的に解釈しても「通信回線を用いて単純業務のコンピュータ処理をする部門」である。
ところで，経理部門はどうして「経営戦略資産管理部」といわないのだろう？
ともかく，情報システム部門は「経営」が好きである。３０年前もそうだったし，現在もそうである。「経営」だから「経営者」ということになり，短絡的に「トップの参画が必要」とか騒いできたが，この場合の「経営」も上と同様に単純業務のことなので，トップはなかなか本気に参画しようとしない。
大仰なのは部門名だけではない。情報システム部門の職種の変遷をみると，あまりにもインフレ傾向が大きいことに驚かされる。研究部門や技術部門での「技師」は今でもある程度のレベルを保っているが，この部門では「猫も杓子もみなエンジニア」である。
コンピュ−タがやっとポピュラになった６０年代では，まず女子はパンチャ，男子はオペレータに従事し，それがプログラマに昇格して，最高級位のプランナになるコースが標準であった。
すぐに「パンチャ」が廃語になった。これはエンドユ−ザが端末からデータを入力するようになり，カードパンチ業務を専任として行うことが少なくなったことにもよるが，それ以前にこの職種名はなくなった。腱鞘炎や疲れ眼などの職業病が問題になって採用にも影響が出たり，折りからのウーマンリブ運動で女性差別用語だた指弾されたのであろう。
オペレ−タも電話交換手と誤解され自動交換により失職するようなイメ−ジが伴うのか，正式？には「ファシリティ・マネジメント（ＦＭ）」と呼ばれるようになり，いつのまにか管理者に出世した。最近は「システム・オペレーション（ＳＯ）」として，情報産業の花形分野になろうとしている。
プログラマは往時は花形職種であったが，残業が多いイメージが影響して，いつのまにか３Ｋ用語に転落してしまった。なお，９４年度から通産省はプログラマを職業蔑視語と認定し，情報処理技術者試験からこの用語を削除した。
プランナも落ちぶれた。現在では，求人案内にも「新卒求む。職種ＳＥ。経験不問」とあるように，情報技術を持たない者でもＳＥ（システムエンジニア）というが，このＳＥとは往年のプランナの別名である。すなわち，昔の最高職種は現在では単なるコンピュータ部門要員の呼称になったのである。
一応使えるＳＥを「上級ＳＥ」といい，業務を任せられるＳＥは「プロジェクトリ−ダ」というように昇格した。最近ではこれも怪しくなってきたので，通産省では「システム・アナリスト」としている。おそらくこれも短命であろう。
２０００年に向けて新呼称を作ることが急務である。もはや「システム」は死語である。「ビジネス・インテグレ−タ（ＢＩ）」，「プロブレム・ソルバ−（ＰＳ）」，「エンタプライズ・コンサルタント（ＥＣ）」などはどうだろうか？
情報システム部門はユーザを大切にする。「エンドユーザ」ではエンド（英語では「目的」の意味であるのに）が失礼にあたるとして，「システム・アドミニストレータ（行政管理者）」とすることによりバランスをとっている。
情報システム部長とはピーターの法則により，階層社会での終着段階に達した者を配属するのに恰好な職位である。
営業部長が自社商品を知らないとか経理部長が決算状況を知らないと人前でいうにはかなり勇気がいるが，新任の情報システム部長が「いや−。私はコンピュータには素人でして・・・」というのは許される。情報システム部長仲間の会合でも，このような挨拶をするとむしろ尊敬される。それにたいして「私はコンピュータひと筋にやってきました。今でもプログラムくらい組めますよ」などというのは恥であるからひた隠しにする。すなわち，コンピュータを「知らない」ことはステータスシンボルなのである。なぜなのだろうか？
おそらく経営トップがコンピュータを知らないことでもあるし，コンピュータを「知らなくても」昇進できるからであろう。すなわち，コンピュータは企業にとって「たいしたことではない」のである。そんなくだらないことをやってはいないぞということが，ステータスシンボルになるのであろう。
ＣＩＯ（Chief Information Officer:情報担当役員）が必要だといわれる。情報技術は企業戦略の武器であるから，情報システムの専門家に任せるべきではなく，経営者が直接指揮をとるべきであるという論旨である。本来は情報と経営の両方の知識を持つ者がＣＩＯとして活躍すべきだとの論旨であると思うのだが，いつの間にか，情報システム部門に携わった者を情報システム部長にはするなというように解釈されるようになり，コンピュータを「知っている」と情報システム部長になれないことになった。もっとも，ダウンサイジングやオープン化の動向が不明確になった現在では，ＣＩＯに求められるのは経営よりも情報技術動向だともいわれるようになってきている。
とかく情報システム部門の部長は，情報技術を知らないことが重視されるが，これは部下にとっては面倒のタネである。
「みんなの意見はシステム部門の発想だが，ユーザは・・・」といえば，それまでの議論はすべて無価値になり，この意見だけが神託になる。その意見が本当にユーザ的発想かどうかや議題が何かには関係がない。新任部長はこれをいうタイミングさえおさえておけば，部下の小姑的な意見を封じることができる。
情報システム部門の上司は情報技術を知らない。しかし，決定権は持っているので，部下は上司に説明する必要がある。そこで部下は次のような不平をいう。
金は使うな。あれもやれこれもしろ。納期はこれまで・・・。やらされるほうにとってはたまらない。
知識がないので「コンピュータ用語を使うな」という。さて，ＯＳのことを何といえばよいだろう。最近ではミドルウェアの説明が困難になった。
かなり古い話ですが・・・
「今度採用計画のメインフレームは１００ＭＩＰＳで・・・」
「ちょっと待て，そのミップスっていうのはなんだい。」
「コンピュータの性能を示す尺度で，１秒間に命令を百万回実行するのを１ＭＩＰＳというんですが」
「なるほど。ところで，以前に簡易言語のことを聞いた。ＣＯＢＯＬでの１０００行が，簡易言語では５０行で書けるそうだね。すると，簡易言語で書けば２０倍の速度になるのか。」
「いいえ。それは人間が書くプログラムのことで，ＭＩＰＳはコンピュータが理解する機械語のことです。たとえばＣＯＢＯＬの１行は機械語で１０命令になりますが，簡易言語なら数百命令になるので，結局は簡易言語のほうが命令数はおおくなりますね。」
「そうか。それはそれとして，今のコンピュータのＭＩＰＳが５０ミップスだったね。あの請求書印刷は２時間かかっていたが，それが１時間になるのか。だいぶ楽になるな。」
「いえ，このＭＩＰＳはＣＰＵの速度で，請求書印刷はプリンタのことで・・・」
「そのＣＰＵっていうのはなんだい」
「・・・！」
最近は環境変化が激しく，部長が部下よりも業務を知っているとはいえない。とくに情報システム部門の部下の言動はどうも他の部門とは違うようだ。コンピュータと部下は思うように動かない。
指示したことは表面的には実行される。しかし，その本質は全然違う内容になっている。枝葉末節な部分は大々的に展開されるが，本幹な部分は無視される。たとえば，標準化を徹底せよと指示すると，部下は各ベンダのＣＡＳＥツールの機能比較に没頭し，項目名称の統一などはいつになっても実現しない。
プロジェクトがスムーズにいっているとの報告があると，その翌日には致命的なトラブルが発生する。
１週間遅れる報告のあったプロジェクトは，うまくいっても１カ月は遅れる。
もっとも対人関係が面倒なことは，この部門に限ったことではない。どこにもあることだと思えば諦めもつく。
経営者は部長ではなく課長以下の意見を聞きたがる。部長は係長以下の意見を尊重する。逆にいえば，部長の意見は誰も聞きたがらない。
他社のトップは立派にみえる。
親しい先輩も上司になるとイヤな奴になる。
持てあました部下が他部門へ転出するとよい仕事をする。
「一度言ってみたい！」。グータラ部下でも育てねばならぬ。それどころか，ご機嫌までとらねば。
これからの情報化社会では，企業戦略に合わせた情報戦略が必要である。長期的な技術動向を把握し，それを業務にいかに取り入れるかを検討することが重要である。そのための情報投資は，省力化投資や改善投資ではなく，リスクを伴うサバイバルのための戦略投資と考えるべきであり，企業革新のインフラ投資として認識すべきであるといわれている。
情報システム部門は計画作りが好きである。「現状認識」「環境変化」「望ましい状態」「それへのアプローチ」・・・などと，コンサルタントがみたら感激するようなキレイな図表にする。しかし，これはシステム仕様書が現行システムと無関係なものなのと同じく，実際の行動とはほとんど無関係の文書である。
長期計画は作ってはみるが，現実には日常業務においまくられて，実現されることはない。その逆に，長期計画の実施を理由に日常業務が阻害されることはない。電話応対はすべての業務に優先する。
５年計画の最終年度に次の５年計画を策定すると，前の５年計画と全く同じであることがわかる。「もう計画ができたのかい。速いねえ。」「前の計画がワープロに入っていましたので，年月だけ変更しておきました。」
電算室といわれた時代に，ある調査機関が各社にアンケートをした。「現在は省力化対象の単純処理をしているが，５年後には経営の意思決定に役立つ資料を提供する」という回答が多かった。最近のアンケートでも（表現は異なるが）同じような回答になっている。
部内の硬直化やシステム開発の牛歩的速度，予算の引き締めを考えれば，今年内にできることは決まっている。２０００年ビジョンなどは誰にでも作れる。しかも部長のあなたは定年になっている。しかし，データベースやブラウザの標準を何にするか，イントラネットの位置づけをどうするかなどを決定するのは難しい。
ＣＰＵの速度，メモリ容量，ディスクなどの増強案は，業務量増加の多少に関係なく，いつでも現状の２倍になっている。最近ではユーザもパソコンで同じことをいっている。
その案を受け入れてＣＰＵやディスクを増強しても，半年経つと一杯になる。これは業務が増大するしないには関係しない。当初の必要理由であった要件を実施する頃には，実施以前にすでにネックになっている。
ＣＰＵのネックを解消するとメモリが不足する。メモリを増大するとディスクが不足する。それもカバーするとＣＰＵがネックになる。しかも，これを事前に推定することは困難である。このように，いつでもコンピュータはネック状態である。
最近はパソコンでも同じような動向にある。使いやすいから業務を拡大する。メモリが要求されるので増強する。使いやすいツールが利用できる。それにメモリが取られる・・・。
「昔の大型機は現在のパソコン」などといわれるが，パソコン１台で済ませている企業はない。コンピュータの増強リプレースのために，実際に出す金額は毎年増加する。
これはパソコンでも同じで，パソコン価格は急速な低下をしているが，カラーにしたい，ＧＵＩを載せたいなどと，より高度な機能を求めるために，実際に購入するパソコンの価格は下がらない。しかも台数だけは着実に増大する。古い機種は使用目的には無関係にリプレースしたがる。結果として，全体のコストだけは着実に増大する。
上の費用増大法則は，ダウンサイングの風潮により一時的な変更が起こっている。メインフレームを増強したいといえば，「ダウンサイジングの時代にメインフレームに金をかけるとは何事だ」という。それではダウンサイジングで対処しようといえば，「ダウンサイジングは見えないコストがかかるので危険だ。発展途上のあやふやな技術に金は出せない。現在の環境でなんとかしろ」という。これによりどちらの情報投資も抑えることができる。
本来，ＯＳの目的は人の介入を少なくするはずなのに，汎用機の歴史は，ＯＳが大きくなるだびにその管理のための増員を要求し，しかも高度の技術者を必要としてきた。おそらくＵＮＩＸやＮＴも，そのうちに専任オペレータを必要とするようになろう。最近はＯＳの違いをカバーしようとミドルウェアが大きくなってきた。おそらく「ミドルウェア管理者」が出現するだろう。
通常の場合，予算申請額合計は投資可能限界を超える。経理部は優先順位を決定する能力がないから，申請を一律１０％カットする。各部門はそれを知っているから，まえもって１０％上乗して申請する。経理部もそれを知っているから２０％カットする。それに対処するため申請額を２０％水増しする・・・。その結果，予算は予算にならなくなる。
経営者は「情報技術の活用が重要だ」という。ところが不況になると，真先にカットされたのがコンピュータ費用である。しかもその投資過剰は情報システム部門の責任だとされている。
経営者は「これからの経営は情報の活用にあり」という。ところが情報システム部門出身の役員がいる企業は少ない。経理部門や人事部門出身者の役員がいない企業は探すのに一苦労する。
情報システム部門は，従来から「ユーザ主導型システム」や「エンドユーザコンピューティング」など，コンピュータ利用の民主化を主張してきた。それなのにトップやユーザは乗ってこなかった。
それがある日，マスコミのダウンサイジングブームに煽られると，一転して過激派に変貌した。メインフレームをやめてダウンサイジングせよとか，情報システム部門を解体してしまえという意見になった。そして，過激な変化の混乱を危惧する情報システム部門を，旧来思想に安住しているホスト一辺倒の保守反動派であるとして指弾するようになった。
その結果，情報システムの運営を情報システム部門に任せることはできないとして，経営情報委員会を作ったり，アウトソーシングを検討するようになり，情報システム部門は失脚しつつある。
（トップへの片想い）
従来から「システム化にあたってはトップの参画が重要」だとか，「情報を経営に役立てるために，トップとの意思疎通をよくして」などといわれてきた。特に最近は，「情報は第４の資源」とか「情報技術は競争優位の武器」であるから「ＳＩＳ−戦略的情報システム」や「ＢＰＲ−ビジネス・プロセス・リエンジニアリング」の確立のために，「情報担当役員−ＣＩＯ」を置くべきだと主張されている。しかも，これらはトップがいっているのではなく，情報システム部門が一方的にいっているのが特徴である。
販売部門や人事部門にくらべて，情報システム部門が特にトップの関心や参画が重要であるとは思えない。おそらく他部門は以前からそうなっているのに，情報システム部門だけがそうなっていないからであろう。トップがその重要性を認識していれば，黙っていても関心を持ち参画する。そうなっていないのは，トップが認識していないか認識したが重要ではないと判断したからであろう。
認識していないとしよう。これだけ世の中で騒がれている（トップの読みそうな雑誌にも書かれている）のに気がつかないのであるから，そのトップは社会情勢に注意していないといえる。そのようなトップはトップとしての資格がない。よしんば参画したところでたいした効果はないと考えてよい。
トップは情報システム部門を重要ではないと判断しているのではないか。販売や人事は重要であるが，情報は自分がみづから参画するほどの必要はないと判断しているのに，いつになっても一方的にラブコ−ルを送るのは，「片想い」あるいは「醜女の深情け」といわざるをえない。
（ユ−ザへの片想い）
情報システム部門では，ユ−ザニ−ズに如何に応えるかは重要な問題である。そのために非常な努力をしている。それが実現できないのは自分たちの責任であると信じている。ユ−ザ部門とのコミュニケ−ションを良くするために，「専門用語を使うのはやめよう」とか「利用部門の業務を学習しよう」など，涙ぐましい努力をしている。ところが，相手のユ−ザ部門は，情報システム部門とのコミュニケ−ションのために，その部門のスラングを使わないようにしたり，情報処理業務を勉強しようとは思っていない。
実は，「提案型ＳＥより下請型ＳＥ」でも，ユーザから「お前はでしゃばりだ。オレのいうことを聞け」といわれたのではない。自分がみずから「あなたが主役です。なんなりと仰ってください。それを満足させるのが私どもの任務です」といったのである。なかにはマーケテイングでの顧客志向まで持ち出してこれを主張することすらある。「ユーザ主導型人事部」や「ユーザ主導型経理部」が存在しただろうか。
現在では情報システム部門は完全に売手市場である。ユ−ザがついてくれなければ仕事がなくなるわけではない。それどころか，殺到する注文がさばけないで困っている。かなり高圧的に構えても仕事はある。コミュニケ−ションが悪くて困るのは，情報システム部門ではなくユ−ザ部門なのである。
ＥＵＣを省力的に運営するために公開ファイルを作ろうとか，既存システムが長年のパッチ当てで複雑になり保守が大変だから改訂しようなどという内部合理化はなかなか実施できない。そのために，必要以上に忙しく，それがために勉強もできず，付加価値の高い業務に手がまわらない。この悪循環が部門の評価を低下させている。
なぜ自部門のニーズに応えないのか？ ユーザのニーズがないからである。情報システム部門はユーザの声にだけ反応するように訓練されているので，上司がいかにわめいても部下は動かない。
もっとも，外科医は自分を手術しないし，床屋は自分の髪を刈れない。社内で情報システム部門が最も情報化が遅れているのは当たり前だという意見もある。
情報システム部門ではメーカーやユーザ団体の主催する講習会が盛んである。「情報システム部門のありかた」として，「トップの関心を得るにはどうするか」とか「ユーザとどう付き合うか」などを話題にしている。これは昔も今も人気のあるテーマであり，「ハードウェアの安い買いかた」や「システムを簡単に作成する方法」などははやらない。すなわち，情報システム部門は自社固有の問題解決を，社内ではなく社外に求める傾向がある。これは，販売部門や経理部門など他部門ではあまりないことである。
情報産業が高度成長していた頃は，それに参入すべく分社化が盛んであった。ところが最近では，本業中心だとか技術空洞化が問題になり，またＥＵＣやダウンサイジングでのユーザ部門への技術者転出のために，本体への復帰もいわれている。
マスコミが８０年代には情報システム部門の分社化を煽った。そのとき情報システム部門がＥＵＣへの対処や技術の空洞化を懸念しても無視された。９０年代になりマスコミがそれを指摘すると，分社したものを本体に戻そうとする。最近のマスコミはアウトソーシングを喧伝しているがどうなるか。
公式の分社提案書には，情報産業への進出や情報技術者の確保と育成などがいわれているが，ポスト不足の解消や余剰人員の受皿などがホンネであることが多い。そのため，バブル崩壊で外部収入が減って経営困難になったり，本体のＥＵＣの推進のために，本体に戻そうと思っても戻せない。
分離前の情報システム部であったときから積極的な組織は，分社すると外部進出に手を広げ過ぎて，本体のいうことを聞かなくなる。ユーザのいいなりだった組織は，分社すると本体の下請になる。
分社した当初は，親子の仕事の分担がどうの予算がこうのでもめる。時間がたつと外部仕事と親仕事との調整でもめる。ＢＰＲの主旨とは反対の結果になる。
情報技術はリエンジニアリングのインフラだといわれる。そのために，情報システム部門は他部門のリエンジニアリングを推進する立場になる。また，情報システム部門自体もリエンジニアリングの対象部門になる。紺屋の白袴では困る状態になる危険がある。
これは事態が深刻なので，ご本家の法則を引用する。
リエンジニアリングは，人員整理や労働強化につながる臭いがする。他部門のリエンジニアリングを行うために情報システムを構築するとき，その部門は「ユーザ主導」により，喜んで積極的に参画するだろうか。情報システム部門はすでにユーザの反対を押し切って事を進める文化を失っている。
ユーザ部門はリエンジニアリングそのものに反対することはできない。それを「システムが使いにくい」とか「業務プロセスと合致していない」などと，情報システムへの批判として表現する。情報システム部門は，それをカバーするためにあれこれ対策をとる。結果としてコストもかかり納期も遅くなる。
逆に，トップはこれの成否に大きな関心を持っている。進捗状況やコストについて従来とは格段の関心を持つ。この板挟みの結果，情報システム部門が無能だということになる。
当然ながら情報システム部門もリエンジニアリングの対象になる。紺屋の白袴で情報システム部門の生産性は悪い。最近の方法論も採用していないし，ツールも用意されていない。これを外部のコンサルタントに指摘されたとき，トップは「自分のことすらできない連中に，全社のことを任しておいたのか」と愕然とするだろう。その結果は，情報システム部門にとって愉快なものではない。
経営資源配分の観点から，リストラやリエンジニアリングの一環として，自社では十分ではない機能を他社が提供できるならばアウトソーシングすべきだという動向も出てきた。
外国のアウトソーシングでは，情報システム部門を解体してその要員も出してしまう例が多いが，日本ではそれは困難であり，ハードウェアをベンダ所有にするとか，部分的な業務を外部に依頼する程度のことになろう。オペレーションやプログラミング業務のアウトソーシングなら昔からやっている。その前にはコンピュータも計算センタのものを利用していた。
また，悪くなる可能性のあるものはかならず悪くなる。このようなアウトソーシングなら安心だが，リエンジニアリング対象で紺屋の白袴を指摘されたときは，深刻なアウトソーシングになる。
情報システム部門は奇妙な特性を持っているが，そのなかでも対ユーザ思想は特殊なものである。情報システム部門のベテランよりも，新入社員のユーザのほうが情報システムについての発言力が強いのである。年功序列が根強い日本的組織において，これは特記すべき現象かもしれない。
人事部門も経理部門も情報システム部門と同様なサービス部門であるのに，社内での地位はかなり異なる。「ユーザ主導」の人事配置とか，各部門代表による「経営予算委員会」での予算優先順位決定はあまり聞かない。
また，自己申告や評価などの用紙の形式は各部門に相談せずに人事部が一方的に決めており，自分の名前を何度も記入させられるが，みなそれに従っている。ところがコンピュータへのデータ入力になると，ちょっとした重複入力も拒否される。予算申請ではあの手この手をつくして経理部を説得するのに，その査定結果は理由書もなく一方的に通達される。ところがシステム化でユーザ部門の要望の一部をカットするには，情報システム部門はかなりの説得をする必要がある。
どういうわけか情報システム部門だけが，ユーザの意向を全面的に受入れるように強制されている。
コンピュータ利用の講習会を開いても歩留りが悪い。ＥＵＣをやっても利用度が少ない。それでアンケートをとると「コンピュータは難しい」という。その理由を聞きいろいろ改良しても使わない。あいかわらず難しいという。
なまじっか「知っている」といえば，仕事を押しつけられる。「わからない，できない」といええいれば，他人がやってくれる。
最近のようなビジネス環境にあっては，「オレはコンピュータなんか使いたくない」とあからさまに表明するのは勇気がいる。一応はやろうという態度を見せる必要がある。しかし，日本の社会ではコンピュータ技術の習得能力に劣ることは仕事の能力とは無関係（ある場合には逆の関係）であると認識されている。だから，「コンピュータは難しい」といっておけば，自分の責任ではないことになる。それを評価する上司も同じなのだから。
ユーザは，自分の１か月に１時間の事務作業を改善するために，情報システムを開発したり改訂することを要求する。そのために情報システム部門は１カ月の作業をさせられる。ところが，情報システム部門がユーザのために１日のＥＵＣの講習を受けさせようとすると，ユーザは面倒だとして受講しない。
システム開発の基準として，情報システム部門よりも残業時間が多い部門だけの要望を受け付けるというのはどうか？
ユーザは情報システム部門が自分のことだけを優先に行うことを望んでいる。他部門の仕事をしているのは仕事とは思わない。販売部門の要求にたいして，流通部門と調整して統合的なシステムにしようなどと提案するのは，販売部門としては，頼んだことがすぐに実施できなくなるので面白くない。
ユーザからの要求は，最初の要求の半分は取り下げられる。それにない２倍が付け加えられる。当然ながら，戦略的に見えてトップの了承を得た機能は，取り下げられた半分に含まれる。
最初の要求書では簡単なことをいってくるので，情報システム部門も安易に引受けてしまうが，ヒアリングを進めていくうちに，大きなことが欠けていたり，人により多様な要望がでてくる。結果として最初の目的とは全然異なるシステムを構築することになる。当然，予算が足りなくなるので，要望書に基づいて算出した予算範囲を「第１次」とし，それを超過した分を「第２次」とする。
（因果律は成立しない）
データがそろうのが５日なのに３日に結果がほしいという。
（３段論法は成立しない）
「この情報を得るには手順を明確にする必要がある。その手順はその情報をみないとわからない。ゆえに，この情報を得るためのプログラムを事前に作ることは不可能である」という論理を納得させるのは困難である。
（１つの事象には３つの名称があり，１つの名称には３つの事象がある）
事象Ａを名称ａとも名称ｂとも名称ｃとも表現する。また，名称ａは事象Ａを指すことも事象Ｂや事象Ｃを指すこともある。すなわち，命題は存在しない。
システム開発時に参画したユーザは，人事異動などによりいなくなる。ユーザ部門ではシステム関係の引き継ぎはいいかげんである。逆にシステム部門はローテーションが少ないので，その担当者はその情報システムどころか業務システムについても強くなる。表面的なことはともかく，本質的な事項についてはユーザ部門より詳しくなってしまう。
コンピュータメーカーは，コンピュータという「高価で遊ばせるにはもったいなく」「かなりの変り者でないと使えない」試作品を製品として世に出した。そのために，情報システム部門を設置して，販売システムとか経理システムなどの中央集権型の基幹システムを作り運用しなければならなくなり，その後の混乱を招いてしまった。最近では，「廉価」で「ユーザフレンドリ」だといってパソコンを売り出したが，それもクライアント・サーバ系などに拡張しようとして，また「高価」で「わかりにくい」ものにしようとしている。
メインフレームでは「わからなくなったらＯＳを大きくせよ」といわれた。それが巨大なＯＳになり，主記憶装置の容量を大きく占有してユーザが利用できる資源は一向に豊富にならず，ＣＰＵも同様にＭＩＰＳの増加はＯＳのオーバヘッドで帳消しになってしまう状態であった。
それを打開しようとしたパソコンでも，最近のＯＳは高速のＣＰＵと大容量メモリを要求するようになってきた。そして「でも価格が安くなったのだからいいじゃないか」といっている。これもメインフレームのときと同じ論旨である。
新製品を４月に出すと発表するのは，１０月には出荷するということであり，初期には多くのトラブルがあるので，実際に使えるのは翌年の４月になる。
最近は，オープン化と称して，特定のメーカー特定の機種でしか使えない機能ではなく，どの機種にでも共通な規格や業界標準に合わせるようになってきた。そして，サービス商品化（有料化）のために，自社製品だけでなく，他社の商品も含めた最適な構成をサポートするといっている。ところが現実には，当然のことではあるが，実際に提案するのは自社製品だけである。
他社製品と「接続できます。互換性があります。・・・」というが，実際に接続したり交換しようとすると，メーカーも他社製品の知識がほとんどないので，非常に面倒なことになる。
ＵＮＩＸ，Ｗｉｎｄｏｗｓ，ＯＳ２など多くのＯＳが自己主張をしている。統一できないのでミドルウェアなる通訳を設けた。ところがバベルの塔以来の多言語状態で，通訳に通訳を付けるような状態になり，十二単衣的ミドルウェア構造が出現した。コンピュータ資源はそのオーバーヘッドに費やされる。
とくにＣＳＳ環境では，クライアント，サーバ，ＮＯＳなどとの関連が機種により微妙に異なる。トラブルの切りわけが大変だ。文句の持っていく相手を特定するには，単一メーカーに揃えておくのが安全である。
一般企業にコンピュータが設置されるようになってから３０年が経過した。その間にコンピュータの利用も変化するのは当然であろう。なかには１８０度変わったものもあれば，３６０度変わって元へ戻ったものもある。
（昔革新派，今保守派）
昔，コンピュータが導入された頃の情報システム部門は変革の尖兵であった。今，システムの都合で変化を抑えている。昔は組織に変革をもたらすためにコンピュータを導入した。今はコンピュータがネックで組織変革ができないでいる。
（昔標準化，今個別化）
昔は業務標準化のためにコンピュータを導入したが，今はダウンサイジングなど，業務の個別化を推進している。
（昔省力化，今増力化）
昔は事務処理の省力化をコンピュータ導入の理由にしたが，それが行き詰まってくると，今度は情報のより高度な活用をというようになり，そのための人員の増強を主張している。
（昔支援，今阻害）
昔は，事務の生産性向上のために「システム化しよう」といった。今は「システムが使いにくい」ので，生産性が阻害されているという。
なかには，変化がかさなり元に戻るものもある。メインフレームによる集中からダウンサイジングへと分散したのに，イントラネットでまた集中にしようとしている。
昔はＦＡＸを送ると「ＦＡＸしたよ」と電話をかけた。今も電子メールを送ると電話をかける。なかには電子メールの文面を印刷してＦＡＸで送る人もいる。
昔は「オープンプログラマ」という呼称でエンドユーザがコンピュータを利用していた。今もＥＵＣの呼称でエンドユーザに利用させようとしている。その違いはオープンプログラマは自主的に行動したが，ＥＵＣでは情報システム部門がオンブにダッコをしないと利用したがらないことである。
昔は３点を求めてグラフを手描した。今は膨大なコンピュータ処理をしてグラフを画面表示する。それに要する時間も結果のグラフもほぼ同じである。
６０年代後半 ＭＩＳ
７０年代前半 ＴＳＳ
７０年代後半 ＤＳＳ
８０年代前半 ＥＵＣ
８０年代後半 ＳＩＳ
９０年代前半 ＢＰＲ
情報技術に関するコンセプトは頻繁に生じ短期間に消滅する。ＭＩＳからＤＳＳになりＳＩＳへと続いたが，もはやＳＩＳはＢＰＲへと移行した。ダウンサイジングはいつのまにかライトサイジングになった。情報システム部門の分社化もユーザ部門への復帰となりアウトソーシングがいわれている。
最近の風潮は，「日本的ＳＩＳ」「日本的ＢＰＲ」「日本的アウトソーシング」のように，「日本的」が付くのが特徴である。
これらは以前は情報システム部門内部の話題であったのが，最近はトップやユーザまでもがマスコミに踊らされている。ＢＰＲ，ダウンサイジング，アウトソーシングなどに反対の意見を述べてはならない。保守反動派のレッテルを貼られる。賛成のような顔をしよう。しかし自分で信じてはいけない。短期で消滅するから信じて行動するとマスコミにハシゴを外される。
ＳＩＳは企業生き残りの切り札 − ＳＩＳ投資はバブルの申し子
ダウンサイジングはコストダウンに − 見えないコストで高くなる
メインフレームよさようなら − ライトサイジング
分社化せよ − 空洞化するので本体へ戻せ
このような用語を自説の説得に利用することが秘訣である。このとき，用語と内容の一致はとくに気にする必要はない。「○○の推進のためには，情報システムの活用が必要だから，△△をしよう」において，○○はＢＰＲでもダウンサイジングでもよいし，△△はＲＤＢＭＳの購入でも標準化の推進でもよい。ともかく流行の用語が使ってあればよいのである。
システム化により，ある部門の業務の省力化を達成するには，情報システム部門はそれと同等の労力を必要とする。あるいは，ある部門の業務を省力化するためにシステム化すると，その維持のために他の部門の作業が増大する。システム化することにより，その対象業務は合理化するかもしれないが，そのために発生したコンピュータ費用を稼ぐための営業努力が必要になる。このように，システム化は，仕事量を他の部門や他の分野に変換するだけであり，その総量を減少させるものではない。
エネルギ保存則は理想状態において成立する。通常の場合は摩擦などの抵抗により，無効エネルギが熱となって発生する。すなわち，実世界においては，システム化をすると，全体の仕事量はむしろ増大するのである。
最近のコンピュータでは，ＯＳやミドルウェアなどのヒューマンインタフェイスが向上した。人間が楽をするだけ，コンピュータの処理速度や記憶容量は浪費される。当然ながら人間のほうが効率がよいので，全体としてのエネルギは増大する。しかし，これを理由にシステム化が不要だというのではない。社会環境や技術進歩により，人間のエネルギ単価は高くなり，コンピュータのそれは低下してきた。エネルギ総量は不変であっても，それを実現するコストは変化するので，その最適なポートフォリオを常に変化させることが必要である。
恐竜のように，ある環境に最も適応したものは，その環境が変化したときに内部からの対処は最も困難になる。ある部門の業務を変えるのをその部門に期待しても無駄であり，外から変えてやる必要がある。その部門が巨大で権力が大きければ，それだけ大きな外力を与える必要がある。
情報システムも，それが巨大になると環境が変化しても改訂することが困難になる。エンドユーザが構築するような小規模システムは，改訂も容易だし最新の技術をすぐに採用できるが，全社的な基幹システムは，それが精緻に構築され各分野に関連しているほど困難である。昔は「個別システムを統合せよ」といわれたが，今後は「システムを分割して統治せよ」といわれるようになろう。
ある業務についてある提案をすると，かならず反対の意見がある。強く主張すれば反対も強くなる。情報システムにより変化を与えようとすると，それを阻止するように組織は動く。逆に，業務の改革をしようとすれば，情報システムがそれを困難にするように働く。早急な変化を求めると，それを抑える環境勢力は急速に強くなる。
組織力学においては，この法則は非線型の関係がある。業務改革をするにはそれに対応した「閾値」があり，その値以下の力では動かない（静止摩擦ともいえる）が，この値を越えると一挙に動きだす。すると今度は逆向きの力が働く。その結果，振動が発生する。往々にしてその振動は発散する。
ＥＵＣも情報システム部門が主張した程度では誰も動かないが，マスコミなどが騒ぐと何でもＥＵＣにしようということになり，メインフレーム不要論や情報システム部門解体論に発展する。それが実施されそうになると矛盾に気付き，今度は集中だと騒ぐ。結果としてポリシーのないシステムだけが乱立して情報システムの無政府状態になる。
情報システムは時間とともに複雑になり動かなくなる。それを作動させておくためには，ときどき再構築をしなければならなくなる。長く放置してきたシステムほど，再構築には労力がかかる。それを「わかってはいるのだが，今は忙しいから」といって放置すると，ヒマになっても実施できない規模のカオスになってしまう。
情報システムがどのような動作をするかは，人為的要因というプランク定数により，決定論的に予測することは不可能である。その挙動は確率的で千差万別であり，人知の及ぶところではない。一応それらしい動きをしているにせよ，それは統計的正確性であり，次の瞬間にはどうなるかわからない。とくにＣＳＳ環境では，プランク定数の値が大きい。
システム開発におけるユ−ザニ−ズにも不確定性原理が働く。運用時点でのニ−ズを測定しようとすれば，そのニーズは特定できなくなるし，あるニーズを特定すると，運用の方法がわからなくなる。
良くも悪くも情報システムは人間が運用しているのであり，その人間は組織の内で企業文化に支配されている。コンピュータは物事を明確にする傾向がある。在庫管理のうまい会社のＰＯＳは成功する。顧客動向に敏感な企業は顧客情報分析に力を入れる。意思決定を逡巡する組織のシステム開発は時間がかかる。形式主義の企業のシステムは巨大化複雑化して役に立たないか，あるいは現状の問題点を隠蔽したり維持強化するのに利用されている。
要するに，情報システムを評価をするよりも，情報を活用する文化があるかどうかを調べ，それが低いようならば，情報システムを極力軽くすればよい。
なお，エンドユーザコンピューティングの導入は，その企業の情報システムの性格をさらに増大するし，これはクライアント・サーバ・システムにより，極度な状況にまで発展させる。
プログラムがあるから保守しなければならない。プログラム作成が，人員不足をもたらし，ベテランの仕事を固定化し，情報システム部門を硬直化させる元凶である。無能なＳＥは，ユーザの要求に応じたシステムを開発するが，優秀なＳＥは，ユーザの仕事を見直すことにより，システム要求そのものを不要にする。プログラムを作成することは，赤字国債の発行と同じで，自分の無能のツケを後輩に押しつけているのである。
そもそもの問題点の発端は，販売システムや経理システムなどの個別のアプリケーションシステムを構築することに原因がある。そのような個別システム以前に得意先や商品があり販売行為があり，その情報は存在する。だから，情報システムでも，まずそのようなデータを販売とか経理に関係なく無目的のデータベースとして構築し，それから情報を検索加工する仕組みを作るべきなのである。そして，その上に立って，そのデータベースの品質保証をしたり，その維持を容易にするために，販売システムや経理システムなどの個別アプリケーションを構築すべきなのである。これがＤＯＡ（データ中心アプローチ）の基本である。
工業では標準化した部品を整備することで生産性が向上する。自動車ディーラも色や内装はユーザ希望に応えるが，ボルトやナットまでは聞かない。これらは世界中どこでも同じ仕様で統一されている。多品種個別受注生産であっても，グループテクノロジという手法により，乗用車でもトラックでもできるだけ同じ部品を使うようにして，大量生産方式を採用できるように努力している。それが品質管理にも役立っているのである。
情報システム開発では，ボルトやナットの類までユーザのニーズにより個別に作成するし，タイヤの個数やハンドルの位置までユーザの好みで個別設計している。１台ごとに新規に設計して生産しているのでは生産性はあがらない。
ところがユーザは，自社開発のシステムについては細かい要求をするが，パソコン通信による外部データベースの検索など他社のシステムでは，ヒューマンインタフェイスが悪くてもいっこうに文句をいわない。その理由をよく検討することが重要である。
情報技術を習得しユーザ部門の業務を知れば一人前のＳＥになるはずである。前者は半年も訓練すればどうにかなるし，後者も半年位その部門にいれば理解できよう。すなわち，理論的には１年間でＳＥに育成できるはずである。それなのに，実際には３年以上かかるのはどうしてなのか？
それは，情報システムが複雑になっているからである。長年のパッチ当てで複雑怪奇になったアプリケーションを理解するには，それなりの失敗を繰り返す必要がある（その失敗によりシステムは更に複雑になる）。
では，なぜ複雑になるのだろうか？ 改訂要求があるからであり，それにパッチ当て的に対処しているからである。
改訂要求は経営環境の変化に伴うこともあるが，原則的に対象業務自体がそんなに複雑なはずがない。複雑だったらその業務が成立していないはずであるし，それこそリエンジニアリングの対象になる。複雑にしている大部分はユーザの個人的趣味によるのである。それも一人の趣味ならばよいのだが，大勢の趣味を取り入れるために，わけのわからないものになってしまうのである。
ヒューマンインタフェイスがからむと，システムは複雑になる。それを防ぐには，入出力部分と中核部分を分離して，前者をなるべくエンドユーザコンピューティングに移行することが必要である。
関係者が増大すると，「船頭多くして船山に登る」ためにＮに応じて複雑になるが，各人の組み合わせなのでＮ2 に比例することになる。プロジェクトの関係者を絞ることが生産性と品質の向上の鍵である。
情報システムも工業製品と同様に，高品質の製品を低価格で短納期に製作するべきなのに，実際には工業製品というよりも，芸術的作品を個別に制作している状況である。これはプログラマの創造性の発露だともいえるが，あまりありがたいことではない。
標準化が重要であるが，それを行おうという案は，ユーザのニーズがない，忙しく時間がないなどの理由で，いっこうに実施されない。標準化規則を作っても納期を理由に守られない。
それができていないために個別開発を行っているので，品質もよくないし保守に時間がかかる。その時間のほうがはるかに大きい。納期がないことを理由にテストもしないで本番に入る。その結果トラブルが頻発するが，どういうわけか，それを直してリランすることはできる。担当者の納期云々を重視するな。
「商品コードの改訂が必要だ。なんでこんな体系にしたのだろう。」「何も考えちゃいなかったさ」。この変更をするには，短くて３年〜５年，おそらく企業が倒産したり合併するまでは不可能である。
どうしてもそれまでに改訂する必要があるときは「新商品コード」を作るが，旧のものも捨てられないので新旧併存になる。そのうちにまた新しいコードが必要になる。そのため「商品Ａコード」「商品Ｂコード」・・・「商品Ｚコード」などが出現する。
同様なものがファイル段階でも起こる。商品マスタに項目追加したいのだが，それをすると既存プログラムの修正が多く，到底「納期に間に合わない」。それで既存マスタはそのままとして，新規に「商品マスタ２」を作る。これもすぐに「商品マスタ１０」にまで発展する。
これを事前に考えることは不可能である。ファイルデザインを変更しても既存プログラムに影響させないこと，すなわちファイルデザインとプログラムを分離することが必要である。正規化やＲＤＢをすることである。
昔，ＣＯＢＯＬやＦＯＲＴＲＡＮが華やかなりし頃は，プログラム大文字で記述されていたが，最近の言語はすべて小文字である。この風潮は奇妙なことに，メインフレームからパソコンへの移行と時期が一致している。そのうちにコンピュータからは大文字がなくなるものと思われる。ところが未だキーボードの表示は大文字が多い。
通常の情報システムは，開発後１年で仕様書が無意味になり，３年後には当初の目的とは異なる目的に使われ，５年後には何のためにやっているのかわからなくなる。（エントロピ増大の法則）
システム改訂の負荷はそのシステムの年齢に比例する。
システムは年月が経つにつれて，何をやっているのかわからなくなる。それを防ごうとして，手を加えるとさらにわからなくなる。
１０年も使っているシステムは，その間のパッチあて改訂で例外の固まりになっている。それを理解できる人はいない。１年しか経たないシステムなら，どこをどう直せばよいか全員が知っている。上の命題のように比例するのであれば，どの頻度で改訂してもコストは一定なのであるが，どうも完全な比例ではなく非線型らしい。しかもその最適期間はちょうど関係者が忙しい時期に一致するようだ。
平均５年でローテーションされる職場では，システムは５年に一度の大改造が行われる。エンドユーザ部門は新担当者が自分のニーズを入れたがる。情報システム部門はシステムがブラックボックス化したので改訂したいと考える。
情報システムは寿命により改訂することもあるが，品質管理が不十分でエラーがあり，それを直すために部分的に修正することが多い。このエラーを探して直すことを「デバッグ（虫潰し）」というが，これが難儀な仕事である。（デバッグの語源は次のように伝えられている。その当時はプログラムリストを連続用紙に出力していた。長く延ばしてその上にはいつくばりエラーを探す姿が，褌を広げてノミやシラミを探すのと似ているからだとのこと。その頃は欧米人も褌をしていたとみえる。）
マッカーサーは「○○（老兵）は死なず。ただ消え去るのみ」といった。長島茂雄は選手引退時に「○○（巨人軍）は永久に不滅です」といった。彼らがプログラマだったら，この○○は「虫」だったろう。ある箇所を修正すると，それが原因で違うところにエラーが発生する。あちこちいじくっているうちに正しいところまで直してしまう。
トラブルがあったときに，その根本から原因を追求するのは時間がかかる。ともかくこのへんが原因だろうと決めて，対症療法で逃げるので迂回路を設ける。それでも直らなければ違う個所を探す。こんなことをやっているうちに，ＧＯＴＯは増加し，せっかく最初は構造化したのに，結果としてスパゲッティ化したプログラムになる。
こんな手順で直すのだから，１０個のエラーで５個見つかれば成功である。しかも，テストする時間がないので本番でやってみてＯＫなら事終われりとなる。したがって，日次処理でのデバッグの影響は，月末処理や期末処理の忙しいときになって発見される。忙しいのだから，また対症療法で逃げることになる。
このようなことを述べると，初心者は「虫のわかないプログラムを作ろう」などと考える。しかし，昔のＣＯＢＯＬで鍛えたベテランにとっては，デバッグは知的ゲームであり「デバッグはど面白い商売はない」のである。老兵の生き甲斐を奪ってはならない。しかも，「虫のわかないツール」そのものが虫の巣窟なのだから，結果はもっとひどくなるだけである。
昔から文書化が重要だといわれてきた。ＣＯＢＯＬは文書的表現ができる言語だといわれていたが，それなのに文書が必要だとすれば，いったいＣＯＢＯＬとは何だったのだろう。一時はＣＡＳＥが華やかに喧伝されたが，その後はどうなっているのだろう。
プログラマはプログラムを作るのが好きである。ともかくプログラムを書くのが第１と心得ている。外部仕様書，内部仕様書，操作仕様書などの文書化は本来は各ステップで作成し，それぞれの確認を得てから次のステップに進むことになっているが，実際には本番移行完了時点で作られる。しかも，その順序は逆で，操作仕様書，内部仕様書，外部仕様書の順に作成される。それでも作成されればよいほうで通常は次のようになる。
開発のときですらそうなのだから，対症療法的改訂時に仕様書も改訂するなどということは幻想にしか過ぎない。
「ドキュメントはありますがねえ。ただし５年前のものですよ」
なかには，ロードプログラムは存在するがソースプログラムはどこにあるかわからないとか，同じ名称のものが５つもあったなどというのは，そう稀なことではない。
最近は，ＣＡＳＥツールが発展してきた。仕様書を作るとプログラムが自動作成されるようにもなってきた。ところが，これも標準化や利用基準を厳重に管理しないとややこしい問題が発生する。
上流だ，下流だ，いや統合だなどと騒ぐ前に項目名を１内容１名称にすることが肝要である。それができればツール導入の効果の大半は完成したことになる。
ところが，項目数は数千個にも及ぶ。それをすべて異なる名称にしようとするので，命名された項目名は，誰もが理解できないような名称になる。
ベテランほどこのようなツールを使いたがらない。強制すると，プログラムを作成してから，ＣＡＳＥツールで仕様書を作成する。ファイルデザインも後になってから登録する。項目名も自作するので，同義語が多くなる。
このような人にＣＡＳＥツールをみせると，決まっていうのは「プログラムを与えたら自動的に仕様書を作成する機能はないのか」である。
一般にＣＡＳＥツールを導入すると，関連文書が数倍に増大する。「紙への信仰は捨てられない」ので，キャビネットが必要になる。ＣＡＳＥ導入にあたっては，キャビネットのスペースを考慮することが肝要である。
実際にＣＡＳＥツールをプログラムの自動生成にも使われることもある。そのときは無駄なプログラムの粗製濫造用ツールとなっている。しかし，よほどのことがないかぎり，リポジトリ的に利用されることはない。
最近の方法論で育った人はＥＲモデルを重視する。ＥＵＣに関係している人もそうである。従来のシステム開発に従事していた人はＤＦＤモデルを重視する。
マーケティング理論では，「消費者ニーズにマッチした商品を作る」ことが商売の基本であるかのようにいわれるが，いまでかって消費者ニーズにより革新的な商品が生まれたことはない。提供者が消費者ニーズであろうと想像した商品を市場に出したので，それによってニーズが喚起されたのである。
電気が発見され電球が発明されるまでは，消費者はもっと明るいランプがほしいと思っただけであり，ユーザニーズを調査したならば，ランプの芯やフレームの改善で終始したであろう。情報を速く伝えたいニーズはあっても，郵便馬車制度の改良がいわれただけであろう。電球や電話を発明したのは，マーケティングの研究をしたからではない。マーケティング調査をしたら，このような発明はされなかったし，商品化できなかったであろう。
パソコンやＧＵＩをみせるから，それを利用したニーズがでるのであって，何もないところにこれらがほしいというニーズはでてこない。ユーザに何を欲しいか聞いても単なる改善要求しか得られない。本当に革新をしたいのであれば，実物を作って示すことが重要である。
新製品開発では当然なことであっても，情報システムになるとこの考えは受入れられない。「技術先行のアプローチはいけない。ユーザ主導で考えるべきだ」といわれる。しかも，ユーザにＰＲしようにも，そのプロトタイプを作ることさえ認めないのだから，ユーザがそれを希望するはずがない。すなわち，情報システムの分野では革新を行おうとするならば，ユーザニーズ主導から脱却することが必要である。
（新技術）
新しい利用方法はユーザからは出てこない。他社を調査してもやっていない。すなわち，提案者の一人よがりとされる。
（既技術の選択）
ＣＳＳ系のＤＢを導入することを例にする。担当者は評価項目と商品評価の一覧表を作りたがる。ＯＲＡＣＬＥだのＳｙｂａｓｅだの多くの（本当に多い！）商品カタログを集め，ベンダの説明を聞き，それでも安心できないので仮導入してテストをする。
一人では不安だからとして数人を任命すると，かならずその間で商品シンパができる。評価項目で商品を評価するのではなく，商品から評価項目を作ろうとする。
さらには，使うのはユーザだからといって，多くのユーザに見せてアンケートをとる。そうすると，ユーザは全然違う観点（ベンダの説明者が美人だとか，アイコンがきれいだというようなＤＢには関係のない事項がほとんどである！）で指摘する。それも評価項目に入れる必要がある。
ともかくＡ＞Ｂになりかけたときに，Ｂのバージョンアップが行われる。すると評価の点数が変わりＡ＜Ｂになることが多い。一般に「比較評価とはどれが最近にバージョンアップされたか」と同じになる。
このようなことを繰り返していれば，永久に導入をしないで済ませることができる。
サーバのＲＤＢやミドルウェアを何にするかを決めるのは難しい。何を決めてもすぐによりよいものが出現する。すなわち，どの決定もかならず失敗する。しかし安定するのを待っていたのでは，その間の機会損失が莫大になる。最も時間がかかるのは人間系なのである。早く新しい環境に慣らすことが，結局は効果を早く得ることにつながる。
もっとも１ダース列挙しなくても，通常は次の３つで結論に達する。
「ユーザがついてこられるかね」
「現行の方法でも運用でカバーできるだろう」
「ところで誰がやるんだね」
ＥＵＣを例にしよう。ユーザが使いやすいようにというので，「１を押せば○○集計表，２なら△△分析表，・・・」のような個別処理メニューを提供する。すると，ユーザはさらに多様なメニューを要求するので，情報システム部門は多忙になる。それに応えないとユーザの不満が高まる。
公開データベースを整備し，簡易言語でアクセスできるようにすると，処理を簡単にするために，公開データベースを帳票直前の形式にしろという。そうすると，多種多様な公開データベースになり，その管理や同期合わせのために，システムが複雑になる。
その対処のために，正規化したデータベースで提供しようとすると，今度は教育が必要になる。歩留りも悪いしＱ＆Ａ対応が大変になる。それでまた個別処理メニューの提供に戻る。それならいっそのこと，情報システム部門が作表して配布するほうが簡単だということになる。・・・
どんなに便利な４ＧＬが出現しても，最初に覚えたＣＯＢＯＬのほうがわかりやすい。ベテランは新技術を使わない。とくにユーザにある言語（ＣＯＢＯＬでもＥｘｃｅｌでも）を普及したら，更によい言語が出現したのでそれに切り換えようとしても，旧言語を廃棄するには少なくとも５年はかかる。その間には新言語も旧言語になっている。これは言語だけにとどまらない。メインコンピュータで育った人はパソコンに関心を持たない。
情報システムの分野では，各種の事例報告が活発である。どこどこの企業ではＳＩＳの構築に成功したとかＢＰＲを達成したなどが，講習会や雑誌で多く喧伝される。当然ながら失敗例は公表しない。そのため，それらをやればかならず成功するような錯覚を受ける。
異機種間接続の失敗例は聞いたことがない。しかし，個人的に聞くとだれもが２度とやりたくないという。ところがユーザはそのような裏話を聞いていない。すべて簡単にできると信じている。自社で情報システム部門がそれを困難だというと，情報システム部門が無能なのだと結論する。
他社の立派な事例報告も，後で非公式に聞いてみると，実際にできているのは半分で，半分はこれからの計画であったり，実現できなかったものである。
犬が人を噛んでもニュースにはならない。この３０年間，汎用機でＣＯＢＯＬを用いて給与計算システムを開発した事例は一度も記事になっていない。ところが，すべての企業がこれを行い，しかも成功している。マスコミから消えたら取りかかれ。
ＡはスタンドアロンでのＯＡ的利用をいっている。Ｂはホストデータの検索加工のこといっている。さらにＣは電子メールのことをいっている。
ユーザ部門に所属しさえすれば，その人がコンピュータのプロでもエンドユーザである。先月まで情報システム部門にいた者がユーザ部門に転出し，そこでシステムを構築すると「先端的なエンドユーザによるシステム開発（ＥＵＤ）」となる。ところがユーザ部門にいた者が情報システム部門にきてシステムを開発しても「旧態依然とした情報システム部門主導のシステム」となる。
「当社はＥＵＣで○○システムを構築した」という話をよく聞くが，実際の状況を調べると，そのユーザはその部門で１０年間もコンピュータを担当していたベテランで，その構築には情報システム部門から数人が応援をし，実際の構築作業はメーカーに依頼したなどという例はざらにある。
最近はＥＵＣをしているのはカッコよい。もしＥＵＣと称したいならば，システム化案件がでるたびに，情報システム部門からその部門にベテランを人事異動させて，終わったら戻せばよい。もっとよいのは，「情報システム部」という名前を営業部とか経理部としておくことである。「当社ではすでに情報システム部は廃止しました。すべてＥＵＣでやっています」「すごいですね。では情報システム部にいらした人たちはユーザ部門に移ったのですか」「ええ。全員が営業部になり，そこで全社の情報システムの開発やコンピュータのオペレーションをしています。たまたま取締役の某が情報システム部と営業部を兼務したものですから」。
ＥＵＣとは，情報システム部門はエンドユーザが自ら行うものと考え，エンドユーザは情報システム部門がエンドユーザに使いやすい環境を開発してくれると信じている，同床異夢のコンピュータ利用形態である。
ＥＵＣの目的は「必要なときに必要な人が必要な情報を容易に得られるようにすること」である。その趣旨には情報システム部門もユーザ部門も一致する。ところがその実現手段では，情報システム部門はユーザがコンピュータ知識を習得して自分でやることだと考えるし，ユーザ部門では情報システム部門が全部お膳立てをしてくれて，自分たちはせいぜいテンキーを押す程度でよいと思う。「いままでは情報システム部門に電話で頼めば詳細説明しなくてもやってくれた。なぜ，いまになっておれたちがやらなければならないのか」
ユーザは，ＥＵＣの技術はなかなか覚えない。講習会にも参加しないしマニュアルも読まない。ＨＥＬＰ機能を容易しても参照しない。しかし，コンピュータゲームはマニュアルもＨＥＬＰもなくてもすぐに覚える。
ワープロや表計算ソフトのバージョンアップは情報システム部門でないとできないが新作ゲームは自分でインストールできる。
ファイルの登録手順はすぐに覚えるが，削除手順は覚えない。ジョブのプライオリティや空いているクラスは，教えないのに全員が知っている。ゲームソフトはプロテクトの外しかたまで普及している。
ＥＵＣを行うとコストがかかるといわれる。それには端末やホストのコスト増加がよく指摘される。しかし，最大のコスト増加は，ユ−ザが端末を利用している機会費用である。
案外ユ−ザはコンピュ−タが好きである。販売部門にいながら，客先を訪問するよりも端末の前に座るほうが好きな者が出てくる。その数は次第に増加する。そのうちに全社員総コンピュ−タ係になってしまう。
それが業務改善に役立つ情報を得るために，端末を駆使しているのならばよいのであるが，そうとばかりはいえない。ユ−ザは情報の中身よりも出力帳票の体裁を重視する。必要な情報は短時間に得られたのに，表示方法を変えたりグラフ化するなどの体裁をよくするために，その数（十）倍の時間をかけていることは珍しくない。問題点を明確にするために，このような改善をするのはよいことであり，非難する気はない。問題なのは度が過ぎる傾向があることである。
この現象は，自分が意思決定をするのでなく，上司に見せる資料を作成するときに顕著である。上司は内容よりも体裁をほめることが多い。数表の羅列では不満を示すようになる。すると，次第に体裁改善競争が始まる。そのために端末に座る時間はますます長くなる。
パソコンはますます上位機種になる。プリンタもカラ−の高価なものが要求される。一つの部門がそうすると，他の部門はそれに負けないものをほしがる。パソコンは価格が下がり性能がよくなった。しかし，その大部分はヒュ−マン・インタフェイスの改善に費やされ，本来の目的である情報の入手にかかわる部分はそれほど改善されていない。
そのうちにホストからの出力にも同様な体裁を要求するようになる。システムは出力系だけが異常に大きくなる。ホストの資源も大きくなり，システム開発改訂の規模も大きくなる。情報システム部門は出力に凝るための負荷が増大する。
すなわち，情報処理は急速にプレゼンテ−ションツ−ルと変貌している。それは非難すべきことではない。しかし，情報コストにはかなり厳しい企業でも，このような観点からのコスト論議はあまりなされていないのは奇妙である。
サーバーのお守り，ファイルのバックアップ，ソフトのバージョンアップなど多くの作業が必要だが，ユーザはそんなことをしたがらない。結局システム部門から転出させることになる。しかも，パソコンやＵＮＩＸの技術を持った数少ない要員を張りつける。その結果，常にシステム部門はこの分野を知らない状態になり，周囲からホスト一辺倒だと非難される。すなわち，ダウンサイジング環境が整備されるに従い，情報システム部門のダウンサイジングの分野での知識経験は相対的に低くなる。
従来のように，ヒューマンインタフェイスに自由度が少なかったときは，端末の操作性や画面のデザインに関するユーザの趣味も限定されていた。ところが，ＧＵＩを提供すると，この線は赤くしようとか，枠の角を丸くしようなどと，ユーザの趣味が急速に多様化する。「ユーザ趣味主導型」の極致になる。それに振り回されて，システムが完成するのは極度に遅くなる。ＧＵＩは自分で開発するには役に立つ機能であるが，他人のためのシステムを作るにはかえって邪魔なものである。
また，情報システム部門の担当者も面白い機能があるので，あれこれやってみたくなる。それとユーザ趣味が重なると，共鳴が起こり無限大にまで発散する。情報量は増えないのに，コストだけは着実に増加する。
プルダウンメニューで「切り取り」と「削除」の違いもわからないし，なぜ「コピー」では「貼り付け」が必要なのかわからない。アイコンを見て内容をしるには，かなりの想像力が必要で，そうでない者にはチンプンカンプンである。理解している者にとっては，マウスクリックでもコマンド入力でも同じである。
一般に，旧い文化が新しい概念に遭遇すると葛藤が生じる。ＥＵＣもダウンサイジングも，企業での業務のしかたに影響を与えるものである。従来の業務方法や職場の雰囲気がそれに合致していれば，円滑に発展することができるが，一致していないと，なかなかうまくいかないだけでなく，そこにコンフリクトが生じる。その場合，単に新技術の否定としてではなく，情報システム全体への反発となる危険すらある。また，業務や雰囲気を変えるために，これらの情報技術を適用しようとする場合には，そのコンフリクトは深刻なものとなる。
クライアント・サーバ系の利用形態では，オープン化により多くの機種がＬＡＮに接続できるようになり，情報の共有化が進むと考えられるが，実際には，自部門の情報は他部門には見せたくないので，電子メールや掲示板は部内専用にするようになり，従来ホストを利用していたときには，公開ファイルとして全社で共有していた情報も，ＬＡＮ内部から外部に出てこないようになる。
物言えば唇寒しの環境では，電子メールや電子掲示板を作っても，公式に決定されたものしか入力されず興味のあるインフォーマルな情報は入らない。当然見てもつまらない。部外者が関心を持つと，すぐに見せないようにセキュリティが重要だという。
ダウンサイジングなど情報システムを分散せよというが，実務の権限は委譲しないし意思決定の分散化もしない。企業文化と違うシステムができてしまう。
本社営業部が情報を共有したり伝達したいのは，支店販売部門であり，本社の経理部門や総務部門ではない。支店の状況は逐一知りたいが，その情報は他部門には知らせたくない。本社営業部がほしいのは，構内回線としてのＬＡＮではなく，自部門独占のホストコンピュータからスター型にむすんだ，営業部門だけの全社的ネットワークである。
ＬＡＮやＷＡＮを全社的に張り巡らすのは費用がかかり，その完成までには時間がかかる。情報システム部門は，本社−大支店−小支店のように，場所単位で逐次ＬＡＮ化し，その後でＷＡＮでむすびたいと考えるが，営業部門は，まず本社と全支店の営業部門間のネットワークを作れと主張する。経理部門や総務部門も同じである。
インターネットやパソコン通信での接続時間は，１２分１５秒とか３３分４秒というように，分の単位はかならず３の倍数になる。すなわち接続を切った途端に料金が上がる仕組みになっている。これは，タクシーで「ここでいいよ」といった瞬間にメータがあがるのと同一の法則に基づく。どなたか，１４分台や３５分台になった経験のある人はご連絡ください。
時間を気にしながら使うのは精神的に悪い。それでテレホーダイにする。すると１１時まではかけるのがもったいない。１１時になった瞬間にかけると，つながったためしがない。朝８時以前に使えるほどには，まだ年とってはいない。（最近，昼間の時間を割引にしたプロバイダもあるようですね）
欧米での開発によるＥＲＰが日本でも普及してきた。それを成功させる秘訣は，アドオンを厳禁することだそうである。社内で従来から開発してきてきたシステムは，ユーザの趣味を唯々諾々と取り入れてきたので，複雑怪奇非効率的になったのだ。ＥＲＰはよくできているというが，ユーザの要求を無視してよいなら，よいシステムになるに決まっている。
日本の業務慣習は欧米のそれとは異なる。当然ながら「製番管理」や「価格事後調整」などの機能は持っていない。通常の製品ならばユーザニーズに合わせて製品を変える。それで多品種少量生産になったのだが，ＥＲＰでは，自社製品に合わないのはユーザがけしからんという。これに従う自動車メーカは，おそらくそのうちにＴ型フォードを生産するだろう。
歴史は繰り返す。そのうちまた日本経済が米国を凌ぐ時が来る。そのときＥＲＰは，ＥＲＰはよくできているというが，「根回し機能」を売り物にするのだろうか。
それにしてもＳＡＰのＲ／３は高いですねぇ。会計システムだけでも数億円して，その開発に１０人以上かかり，その上，維持保守のために人がいるんですって。当社などは，数十年会計システムをやっていますが，開闢以来の累積費用は，まだその半分にもなっていないのですが・・・。ところでＥＲＰにはどんな節税システムがあるのでしょうか。
機能説明を聞いて驚きました。Ｒ／３には全部で数十万個のパラメタがあるんですって。それをどうやって覚えるのでしょう。ＣＯＢＯＬでは数十個のメソッドと，ユーザフレンドリィな名称の組合せだけで，ほとんどのシステムができたのですが。
ダム端では仕事にならない。インテリジェントターミナルだ。パソコンだ。Ｗｉｎ９５だ。２００ＭＨｚ，２ＧＢだ。ブラウザだ。ＮＣだ。・・・あれ？ ダム端に戻っちゃた。ＩＢＭはＤＯＳ／Ｖ機にブラウザをのっけてイントラネットに使えるようにしました。そのうち，富士通はＦＭＲを？ やはり物は大事にしましょう。
メインフレームよさようなら。ＬＡＮです。クライアント・サーバです。管理費が高くつきますね。ではイントラネットにしましょう。回線もやすくなったことだから，サーバを利用部門に置くよりも，集中したほうが管理が容易です。情報システム部門はサーバだらけになりましたね。これでは場所ふさぎですから，１台の機械にまとめましょう。・・・あれ？ これはいつかやってた方式ですね。
それにしてもブラウザとデータベースの連携は大変です。いや，そんなことはありませんよ。当社のブラウザ，当社のデータベース，当社のサーバソフトを使えば連携は容易です。あ，当然ハードも当社のものを使っていただかないと，責任のあるサポートができません。
（ここでの法則は，このホームページには適用されません。
そのため，誤解を招くおそれのある解説は省略しました。）
見せたい情報と見たい情報の間には大きなギャップがある。
[new!]により，３ヶ月以内手を加えていないことがわかる。
[Sorry Japanese only]とあるページは，本来日本人しか見ないページである。
テキストオンリーにすると，画像が気になる。画像も表示させるとがっかりする。
長時間かかってローディングしたＪａｖａアプレットに，面白いものがあったためしがない。
ニュースサービスで紹介されたＵＲＬを見に行くと，すでに消されている。
紹介記事のほうが長い場合もある。
検索エンジンを使うことにより，言葉の多義性を認識する。
目的のＵＲＬは，いつも「次の２０件」にある。
電子メールの本質は，情報伝達の秘密性の追求である。どこかで会えば会ったことがばれる。電話をすれば近くの者に聞かれる。手紙やＦＡＸだと持ってくる人に見られる。電子メールこそ，伝達したことすら第三者に秘密にできる手段なのである。電子掲示板（会議室）があるのに，それの利用が少なく，電子メールが愛用される組織では，第三者に秘密にしようとする尺度だといえる。
クローズな文化の組織では，「あの人には見てほしいがあの人には見られたくない」が複雑に入り組んでいる。そのために，電子掲示板のアクセス制限が複雑になっている。人事異動の時にそのアクセスルールを修正するのが大騒ぎになる。
商談報告を例にする。口頭で報告していた頃は雑談で多くの情報が伝達できた。それが報告書で報告することになり，フォーマット以外の情報は伝達されなくなった。電子掲示板になると，誰が見るか気になるので，「○○日に○○の件で○○に会いました。結果は○○でした」の２６文字以外は記述しなくなる。上司はそれではわからないので，呼びつけて口頭で報告させる。
グループウェアの管理が初心者のときは，一般社員よりも課長は広くアクセスでき，部長はもっと広く，役員はさらに広くというように，▽型にしがちである。ところが，情報提供側では上位者に見られるのはイヤなものである。それで当たらずさわらずのことしか入力しなくなる。なかには励ましのつもりで，社長が一般社員の発言を見て，掲示板に発言したりすると，この傾向は加速される。むしろ「上位者見るべからず」として△型にしたほうが，有意義な発言が活発になるのである。ところが上位者は，グループウェアは下位の者を監視するツールだと思っているので都合が悪い。
ＳＱＬを第１政党とする第４統治体制。ＨＯＷではなくＷＨＡＴだけを重視する。その理論は結果さえよければ手段は問うべきではないという思想に基づく。そのために，実現のためには組織の全資源を費やすなど無鉄砲な行為もあり，長老たちを震撼させているが，世の風潮はこれを支持している。
他人の作った機械語プログラムを人間の読めるプログラムに戻すことをリバースエンジニアリングといい，アイデアを盗むのに有効な技術である。これを略してリエンジニアリングというが，この思想をビジネスプロセスにも適用するものである。すなわち，他社が業務改革で成功したアイデアを盗用して自社に適用すること。
ｃａｓｅを「格のある患者の立場で事件の真相を訴訟する箱」と覚えたように，この単語にはいろいろな意味がある。「上流だ下流だいや統合だ。ＥＲモデルだ。リポジトリだ」といろいろいわれるが，結局は特殊用途のワープロとして利用されているのが一般的であり，高度に利用されているときは不要なプログラムの粗製乱造ツールになっている。
「これからの仕事は勘と度胸ではダメだ，データを重視したアプローチをする必要がある」として，やたらデータを集めたが整理に困ってしまった。その対策として正規化などの標準化がいわれているが，集めべきデータは何か，どう集めるか，データそのものの信頼性はどうかなどには全然役立っていない。
コンピュータ利用機会均等運動の所産。識字率の低い発展途上国でもコンピュータが利用する必要がある。指をつめたヤクザ社会でも情報化は必須になった。その対応として，画面表示は文字を使わず絵文字にし，タイプライタをやめてマウスにする。なお，タイプに毒された者にはペンコンピュータが用意される。
文字通り言語である。本来は文書の一部にタグをつけて，ブラウザで読みやすいようにしたものであるが，Ｊａｖａなどの機能追加により，本来の文章はプログラムの隙間に記述する程度となり，プログラム言語になってしまった。
ジャバコーヒーの湯気が揺らぐのをブラウザで表示させるために開発されたプログラムである。当然この場合はホットコーヒーである。ところがＪａｖａを多用した画面はクールだといわれる。送信側ではホットなものにしようとしても，受信側ではクールと見ることが多い。ここにコミュニケーションの苦悩がある。
限られた地域での付き合いのこと。地方分権の企業版。支店や工場では，なるべく本社の影響を受けずに，自分たちだけでうまくやろうという文化がある。情報システムでもそのニーズに応えて，自分たちの内部だけで利用して余所者を締め出そうとする閉鎖的な仕組みが必要である。だからＬＡＮを設置すると，そこから外部への情報発信は少なくなる。
インターネットでアクセスされるサイトは，成人向けのサイトが多いのは当然である。ところが初期のブラウザは，画面の解像度が悪く，肝心のところがモザイクになってしまうことが多かった。
ＩＳＯはＩＳＯ９０００で有名な国際機構であるが，オープン化対応として異機種間の接続の基準を作成した。ところが，多数の国から外交官が集まり，会議は踊る状況になってしまい，ＴＣＰ／ＩＰの侵略を招いた。これでは，本末転倒だといわれ，ＩＳＯではなくＯＳＩではないかと揶揄された命名である。
米国からみると日本の品質管理はマニアックに見えるらしい。ともかく数打ちゃ当たると第２次世界大戦やベトナムでは絨毯爆撃をやった国である。一方が故障したら他方を使うという構成を並列というが，ディスクでも安物をずらり並べれば，効率のよいものが安くできると考えた。しかし，組織でもそうだが，あまり大勢がいるとそれを管理するのが大変になる。
人間の行動は予知できず勝手な動きをするという認識に基づくデータベースである。すべての行動に適合させることは，すべての行動にとって最適ではない。そのスラックは当然コンピュータにしわよせされる。すなわち，人が楽をすればコンピュータ資源を浪費することになるが，それは相対的関係（レラティブ・リレーション）にあることから名付けられた。
オープン教の最大宗派の教典。当初は変人の間で，個人救済を目的とした密教的小乗宗教（ユニ）であったが，最近は一般人が集団帰依をするようになり，大衆大乗宗教へと変化してきた。キリスト教にならい二つの宗派が対立していたが，窓教という異教が強くなってきたので宗教和解が行われた。しかし，次第にその勢力が弱まってきている。
従来は窓の側で仕事がないのに仕事をしているふりをしている高年齢層を窓際族といったが，最近では若者までがそうなってきた。しかも若いので，複数の窓を開けたり閉めたり，ネズミと格闘したりして音まで出すので，はた迷惑なのは窓際族より始末が悪い。注意をするとＮＴ（ノン・トラブル）など受け流すのが憎らしい。
せっかく従来のメインフレームＴＳＳでの集中管理からＣＳＳでの分散管理に変えたばっかりなのに，また集中管理にするんですかねえ。そうなると情報システム部門がＨＴＭＬを書かされることになるんでしょうか。
「オーブン禍」の訛り。昔はＩＢＭという専制者の圧制に苦しんだ人民が，プロトコルは神の前に平等であるとして革命を起こしたが，革命委員会のマイクロソフトがまた独裁者になってしまった。その独裁政策は基礎（ＢＡＳＩＣ）的なことから窓の開閉にまで及び，人民はまるでオーブンで焼かれているようだと阿鼻叫喚したことによる。
日本では信者も多かったが，ＵＮＩＸ教などの伝道普及により異端とされて，公式には世の中には存在しないとされているコンピュータのこと。この言葉を口にすると品位を疑われるので，隠れ信者は「オ○コン」と書いたり「ビジネスサーバ」と婉曲な表現をする必要がある。
目的を重視すること。あまりにも当然であるが従来のシステム構築理論や開発手段ではそれがあいまいであった。それを明確にしようとする概念である。また当然のことであるが，その目的とはコンピュータ資源をいかに浪費させるかにある。
従来はホスト（主人）コンピュータに多くのパソコンを結び，主人の資産を寄食していたが，主人の資産が底をついたので，クライアント（客）とサーバ（給仕人）とでやっていこうとすること。主人がいないので気は楽であるが，責任を持つ者がいないのが困る。
日本はソフトウェア輸入に際してこの機能を義務付けているが，国際社会にあわない特殊機能であり貿易障壁であると批判されている。国内でもこれがソフトウェアの生産性やプリンタ能力を阻害しているとの指摘もあるが，コメ以上の日本文化の基本だから絶対に譲れないというのが多数意見である。
最近の情報分野の低迷により情報処理技術者試験受験者数低下で財政収入に苦慮した通産省が，コンピュータの素人を対象にして創設した認定資格。直訳すれば「組織管理者」であるが，コンピュータ技術習得で脱落した専門学校生などがそれにあたる。すなわち，「組織に管理される人」とか「コンピュータに使われる人」であり，能動形と受身形を誤った例である。
未来の国家管理社会において，国民の現実直視を防止するために，仮想的現実感を与えることが必要である。そのために特殊メガネ等を着用する方式が研究されていたが，ほぼ実用見通しがたった。次の段階ではこれの着用を法的に強制して，究極的には脳の一部に移植することが計画されている。
英語ではパーソナル・コンピュータで個人用であるが，日本企業ではまだ数人に１台なのでプール・コンピュータと称すべきである。また，その購入や管理および運用方法まで規制されているので，パブリック・コンピュータというほうが適切だとの説もある。
人間的境界，すなわち人付き合いのこと。ビジネスではＣＳ（顧客満足）といわれているが，情報用語ではヒューマン・インタフェイスという（以前はＭＭＩ−マン・マシン・インタフェイス−といったが女性差別語として廃止）。相手の気持は千差万別なので，各人に気に入られるには，かなりの苦労が必要である。
日本では伝統的に系列取引の商慣習があり，一社からのコンピュータ購入が行われていたが，日米貿易協議により，一定以上のコンピュータを購入するときは複数のベンダから購入すべきことを業界自主規制として定めたもの。違反の罰則規定はないが，環境破壊につながるとして道義的非難を浴びる。
情報伝達方法には，口頭，電話，文書など多くの手段（マルチメディア）があるが，それを規制して，画像や音声もいったんコンピュータを通さないと伝達させないようにすること。本来はマルチメディア「規制」というべきであるが，規制緩和の風潮により，「規制」の文字を削除した表現が一般に流布している。
バベルの塔以来，多くのアプリケーションやＯＳが出現した。これらをそれぞれの用途特徴によって使い分けるのは，コンピュータリテラシの低い中高年者や中間管理職にとって困難である。彼らミドルのために，一つでも使えるようになれば，他のものも使えるようにしたものである。
大艦巨砲時代の戦艦大和的コンピュータのことを指す。すでに戦闘機やミサイルの時代であり，これを擁護するのは大時代的感覚とされる。ところでこれを「汎用機」ともいうが，それならば，パソコンやワークステーションは「単用機」であるから，それらだけで全社的なシステムを構築するのは無理であると言外に匂わしている。
文字通り作業机のこと。ＩＢＭは大机願望者が多かったのか，個人用机（パソコン）のこともワークステーションといったが，一般的に個人用とするには大き過ぎるし，共同用とするには小さいものをいう。以前は技術屋が図面台として使うのが通常であったが，最近は事務屋の打合せにも利用されている。