スタートページ主張・講演 マーフィーの法則(vol.2)はじめに・目次

Murphyology on Information Technology (vol.2) 2000s

13 妖誤集

(2011/08/17,2011/08/29,42-2011/09/12)

これまで多数の法則を紹介してきたが、法則を正しく理解するには、用語や概念を正しく理解することが前提となる。ここでは、誤解されやすい用語や概念を定義する。


BI(Business Intelligence)
 「BI=ビジネスインテリジェンス」から連想されるのは「事業諜報」、すなわち産業スパイであるが、不正競争防止法に抵触するだろうから、それを喧伝しているとは思えない。ビジネスを組織だとすれば「組織知」、すなわち、ナレッジマネジメントにおける個人知から組織知への変換を意味すると思われる。
 しかし、通常のBIツールは、エンドユーザが売上分析や顧客動向分析などを自ら行うために、Webブラウザのトップページに、帳票メニューを表示するためのツールである。
 用途から見れば、1970年代のDSS、1980年代の情報検索系システム、1990年代のデータウェアハウスと同じであり、しかも、メニュー化により、エンドユーザが得られる情報を限定する傾向がある。
 操作環境から見れば、ブラウザのスタート画面が、Yahoo!→自社サイト→社内ポータルと変化してきた延長として、個人別あるいは部門別のポータルにしたことである。この変化は、社員のインターネット利用の自由度を制限する方向へ進んでおり、社員がポルノサイトを閲覧したり、他部門の情報を参照することを防ぐことができる。
 すなわち、名称とは裏腹に、生のデータウェアハウスやデータマイニングにベールをかぶせることにより、ユーザが得られる情報をお仕着せの情報に限定している。
 なお、「経営者をコックビットへ」として、経営者向けのBIが注目されている。これはBIコンテンツ作成者が、経営者に提供する情報をコントロールすることになり、「裸の王様」育成に役立つと思われる。
COBIT(Control Objectives for Information and related Technology)
 COBITはITガバナンスの成熟度に関するベストプラクティスおよび評価基準である。ITガバナンスを確立する責任は経営者(CIOを含む)である。ところが、COBITのガイドラインを読んだ経営者は稀であり、理解している経営者は皆無に近い。次の改訂版では、「経営者が本書を読んで理解できること」をITガバナンス成熟度の測定基準として付け加えてほしい。
EA(Enterprise Architecture)
 お役人はハコモノ投資から脱却できない。無形の情報システムをなんとか有形のモノにしたい衝動にかられる。それには膨大な文書を作成するのが適切である。行政では、EAを「業務・システムの最適化」としているが、ここでの最適化とは、国民にとっての行政業務の最適化ではないことは明白である。
 適切なシステムが構築され活用されなくても、膨大な文書を作成することにより業務を行っているように見せかけることができる。その手段として最適なのである。
EEPROM、フラッシュメモリ
 「ROMは読めるだけで書き込めない半導体だ」と教える。ところが、EEPROMを用いたUSBやSSDは書き込みができる。生徒から質問されると困る代表例である。
 また、なぜ「フラッシュ」なのかと聞かれ、苦し紛れに「バイト単位でなく、ブロック単位で消去・書込みをするんだ。トランプの51で、すべて取り換えるのをフラッシュというよね」などと逃げている。
 命名するときには、教師の都合も配慮してほしいものだ。
HTML5
 「HTMLは文書構造を記述するものであり、体裁を整えるものではない」ので、体裁重視の傾向が強かったHTMLをHTML4で凍結し、その後はXHTMLへ移行するはずだった。
 ところが、通信回線業者の活性化のためには、利用者の回線速度の向上要求を高めるのが必要であり、それには、Webページを派手な体裁にして、画像、音声、動画などの利用を推進することが効果的だと気付いた。
 また、2000年頃にはIEがブラウザを独占していた。Googleなどの対抗者は、その独占を打破して新しい市場を創造するには、マイクロソフトの公式標準準拠不徹底につけこむのが効果的である。それにはJavascriptを高度活用するのが適切だと考えた。Ajaxでその成果が実証できたので、それを進めて、Javascriptの抜本的な機能拡張を行い、その動作基盤ととしてのHTMLを整備した。それがHTML5である。
IT技術者
 定義が困難な用語の典型例である。ITの供給者だとしても、ベンダ企業の技術者以外にユーザ企業でのIT部員もいるしエンドユーザとしてローカルシステムを担当している者もいる。
 ITを主な業務としている者とすれば、ほとんどのオフィス業務や生産業務が含まれる。日本のIT活用では、戦略的活用が遅れており、それが日本企業の国際競争力が弱い一因だといわれる。これを挽回するには、供給側以上に発注側・利用側の力量が求められる。その観点から、ITの有効利用を実現する者だとすれば、経営者や上級管理者を外すことはできない。猫も杓子もみなIT技術者となる。
 
ITサービス
 昔、情報システムの運用・保守分野は、企画・開発分野よりも重要性が低く見られていた。地位の向上には名称変更が適切である。SaaSやSOAなどが「サービス」という用語の所有権をめぐって争っている間に、英国政府は強引に「サービスとは運用・保守のことである」と定義してしまった。それに応じてSaaSはクラウドと改名して成長したが、SOAは自己の正統性を主張続けたため、かえって話題から消え去ってしまった。
 それにしても、「日本標準産業分類」での「情報サービス業」は、大多数が受託ソフトウェア業である。「情報サービス業」と「ITサービス業」を区別しなければならないのは厄介なことだ。
J-SaaS
 国は、小企業(従業員20名以下)のIT化支援のために、J-SaaSプロジェクトを推進している。
 J-SaaSの目的は、小企業がIT化を進めるにあたって最初の難関である初期投資の壁を低くすることだという。ところが、パソコンが必要なのは同じだし、小企業が独自のカスタムシステムを構築するとは思えない。それならば、パソコンソフトの購入費用を低減すること、すなわち、パソコンソフトのレンタル化とほぼ同様なことになる。それにしては、割高な設定になっている。小企業への支援よりも、小企業向けのソフトウェアベンダを支援することが目的なのだ。
 また、J-SaaSでの「サービス」では、青色申告の自動作成がウリになっている。小企業で青色申告している割合、正確な申告をしている割合を考えると、青色申告をしたいのでJ-SaaSを採用しようとする小企業数は限定的であろう。
 電子政府・電子自治体では「利用度の低い申請システム」が批判にさらされたが、J-SaaSもそうならなければよいのだが。
J-SOX法(金融商品取引法、内部統制)
 監査法人がグルになった粉飾決算が指摘され、財務計算の内部統制を義務化して監査することを目的とした法律である。
 しかし、会計監査と内部統制監査が同一監査法人でもよいとしたので、ウソつきが、「わたしがウソをいっていないというのだからウソではない」ということを認めたことになる。この法律の効果は、監査法人が不正行為で営業不振に陥ったのを救済することにあったととらえるのが適切であろう。
 また、その対応では、内部統制を行って不正や誤りを減らすことよりも、提出書類の形式が重視されることが多い。それに伴い、仕様書のないプログラムは再構築し、文書化のためのツールが必要だとされた。コンサルタントやIT業界への支援に役立ったことはいうまでもない。
OSI(Open Systems Interconnection)
 昔、ISOはネットワークプロトコルの標準化を図ろうとした。ところが、国際会議での机の形でもめている間に、IT業者が談合してTCP/IPを標準にしてしまった。それで「ISOが転倒した」との揶揄をこめて、OSIと命名したのである。
 なお、その反省に基づき、異国間対話接続における問題点を参照しやすく整理したのが「OSI参照モデル」である。
PMBOK(the project management body of knowledge)
 PMBOKは、プロジェクトマネージャがもつべき知識の体系であり、知識そのものを示したものではない。それなのに、このガイドブックを教条的に覚えることが、プロジェクトマネージャの条件だとされた。しかも、必要条件だけでなく十分条件であるとみなされた。その結果、EVMは知っているがPERTやTOCは用語さえ聞いたことがないプロジェクトマネージャが増加した。
 さらに、PMOが設置され、プロジェクトマネージャは、プロジェクトを達成することよりも、提出書類を作成することが主任務になり、プロジェクトチームはそのデータをマネージャに報告する作業に追われることになった。
 なお、PMBOKの商業的成功に触発されて、BABOKやDMBOKなど乱立のきざしがみられる。早急に「共通BOKフレームワーク」の策定が望まれる。
RAID(Redundant Arrays of Inexpensive Disks)
 日本が優勢になるとルールを変更するのは欧米の常套手段であり、以前からスポーツ界で行われてきた。1980年代までは、日本は高度な品質管理により「絶対に故障しない機器」の生産技術を確立して欧米を圧倒していた。欧米はそれに対抗するために、「少しぐらい不良品があっても、その分だけ多めに提供しておけば顧客は満足する」という技術倫理を作り、それを国際標準とした。
 その代表的な例がRAIDである。安物を組み合わせて高級品に見せるのに役立つが、複数ディスクが同時に故障することが多く、RAIDによる効果は制約される。そもそも、冗長性による安全対策は、原発事故でも証明されたように、「主手段がダウンしたときは、それと同時に代替手段もダウンする」法則に支配される。
SLA(Service Level Agreement)
 「誤を犯すは人の常。それを許すは神の業」。親密な取引関係を維持するためには、少々のトラブルには目をつぶろうという合意文書がSLAである。
 しかし、その「少々」の解釈をめぐって、関係が悪化する懸念がある。それを回避するために「制限値を超える事態が発生したときには、制限値を変更するよう双方努力する」という条項を入れることが推奨されている。
SOA(Service-Oriented Architecture)
 DOA、OOAに続くシステム開発論である。データ→オブジェクト→サービスと変化したが、これは部品の粒度を大きくすることにより、開発者の自由度を制限することが目的である。
 また、DOAやOOAでのAはアプローチであるのに対してSOAのAはアーキテクチャである。これは、方法論ではなく基本設計思想であるとして、開発者の選択の余地をなくすことになる。すなわち、SOAとは、個別システム開発者の自由裁量権を奪うことにより、パッケージベンダの権力支配を確立する手段である。
UML(Unified Modeling Language)
 一般に図法だと思われているが、フルネームからわかるように言語なのである。これで記述すれば、コード(プログラム)が自動生成されると主張されてきたが、実際には自動生成に耐える厳格なUML図を作成するのは、コードを書くより面倒だし、読んで理解するのも、適切に記述したコードのほうがわかりやすい。
 ところが、UMLを用いることが、技術レベルを示す尺度になっている。それで、コードからUMLを作成するリバースツールのほうが広く用いられている。
Web2.0
 新概念を提唱するには新名称を作るのが効果的である。ところが特別な新しいことがないのに、差別したいときには、バージョン番号をアップする方法がとられる。
 ハードウェアやソフトウェアでは、バージョンアップと称して、性能が向上したり新機能がついたりしたような錯覚を持たせることが慣例であった。Web2.0はこの手法を概念に広げたことで画期的な試みであった。今後、SCM2.0、クラウド2.0などが出現するのは必至である。
ウイルス
 とかくIT屋は情報技術に固執して、社会の動きに関心をもたない傾向があるが、業務を安定して遂行するためには、インターネットウイルス対策だけでなく、新種インフルエンザなどのウイルス対策が重要だ。ワクチンの常時更新を怠らず、パソコンを使うときにはマスクをして、使用の前後に手洗いとうがいを励行せよ。なお、画面に直接触るタブレット型PCでは、作業前後に消毒液を噴霧することが望まれる。
エクスペリメント
 エクスペリメントとは実験のこと。パソコンの操作がGUI環境になっても、「削除」と「切り取り」の区別はわからない。アイコンをタグやリボンにしても、どこに何があるのかわからない。あれやこれやを適当にクリックして試してみることが唯一の解決策である。マイクロソフトは、Windowsが使いにくいとの非難を回避するために、エクスペリメントが重要だと唱導している。
仮想化
 封建時代(レガシー時代)では、領主(ベンダ)の領地内での商品の仕様(磁気テープや磁気ディスクのファイルも同等に扱える)や取引方法(ファイルアクセス方法)を仮想化することは当然だった。
 ところが、領地を超えて多くの商人が出入りする(オープン化)ようになった現代では、それぞれの商人の思惑が対立し、この思想を実現するのを妨げてきた。すなわち、オープン化が仮想化動向を後戻りさせたのである。それでも次第に仮想化が普及されつつあるが、どうも雲(クラウド)の上の話になりがちである。
 ところで、貨幣制度は長い歴史をもつ仮想化技術であるが、現実では貨幣が実体化してしまい、その所有権の格差拡大が広がっている。貨幣所有権を仮想化する手段がないものだろうか。原始共産制への復帰?
ガラパゴス現象
 日本の携帯電話は、日本国内にしか通用しない多機能・高品質に執着するあまり、世界市場での競争力を失ったと技術戦略の視点で指摘されている。しかし、スマートフォンの人気をみると、この視点での指摘は適切ではない。
 日本人は、携帯電話での電子メールやカメラなど指を用いる機能の過剰使用により、指が細い固有種へと進化した。それに対応してますます繊細な指操作が必要な機能が発展したので、指の太い他の人種には使いづらくなったのが主原因なのである。このことは、日本人でも進化以前の高齢者には、単機能でキーが大きい特殊仕様のものが求められていることからもわかる。ガラパゴス化の本来の意味である環境による生物進化の観点を無視してはならない。
 シャープは、「ガラパゴス」をあえて商品名にした。同社の独自技術を強調する狙いであろう。愛国者としては、日本発を示すために「オガサワラ」としてほしかったのだが。
規格・基準
 ネジや歯車の寸法が統一されていないと都合が悪い。ITに関する用語の統一も必要だろう。ところが近年はITビジネス系の規格や基準(あえて名指しは避ける)が頻発されている。
 どうでもよいようなことをお節介に「国際標準」だ、「ISO規格」だといって権威づけることにより、出版・著作権、審査員資格試験、認定制度、などにより、特定の団体の独占的利益を創出・確保する制度が多くなってきた。
 それらの解説書は、普及が重要ならばパブリックドメインにしてもよいはずである。ところが、一般の出版物に比べて、高価格なばかりか、引用などでの著作権が厳しい傾向がある。市販せず講習会を受講しないと入手できないものもある。
 資格試験では、特定団体の講習会受講(独習できる程度の内容)が受験資格であり、合格後も登録や更新でカネを取られる。
 このように見てくると、普及よりも独占を目的としているようだ。これらの多くは輸入ものであるが、これらの輸出入ギャップは深刻な問題になろう。
キャッシュメモリ
 このキャッシュは cash ではなく cache、すなわち、盗品を隠しておく場所のことである。正規の手続きで遊興費を入手するよりも、埋蔵金から取り出すほうが容易であることから命名された。「事業仕分け」でキャッシュの容量を縮小したが、それにより公務員の活動効率が低下するのは明白である。
共通キャリア・スキルフレームワーク
 3つの標準スキルITSS、UISS、ETSSは、それぞれ関係者間での「共通のものさし」とするために、職種やスキルの定義をするのが目的である。そして、共通キャリア・スキルフレームワークは、これらを共通の体系に統合するのが目的である。
 ところが、共通化の基本である職務名称の統一すら解決されていない。例えば、ITSSではIT、UISSではISなので、ITアーキテクト、ISアーキテクトであり、さらにETSSではシステムアーキテストという。ITSSはプロジェクトマネジメント、UISSとETSSではプロジェクトマネージャという。
 おそらく当初は、あえて異なる用語を設定して、その概念の独自性を主張したかったのであろう。それをどちらかに統一するとなると、組織間の力関係に影響する深刻な対立を生む。
 業務用語は、各企業が長年の慣習によりつちかってきた企業文化の産物である。それを変えることは、自己の歴史を否定されたことになる。そのため、企業合併システム構築において、用語の統一が最大の難関であることはよく知られている。おそらく、共通キャリア・スキルフレームワークの策定作業においても、同様な組織力学が影響したのであろう。
 IT(IS)関連では共通化・標準化が重要だといわれているが、その実現がいかに困難であるかを示した好例である。
超上流プロセス
 従来の情報システムのライフサイクルは、開発すべき情報システムがもつべき機能の検討以降が対象であった。それよりも以前のプロセス、すなわち、事業や業務でのIT化検討の段階を超上流という。いいかえれば、IT利用を前提としたビジネスプロセス設計のことである。
 ここで重要なのは「IT利用を前提」である。IPAの「超上流から攻めるIT化の原理原則17ヶ条」で示すように、この段階で既にベンダが参加していることが前提となっている。
 この「超上流」は日本発の概念である。本来、超上流プロセスはユーザ企業の聖域である。それなのにベンダの存在を必要とするのは、あまりにも日本ユーザ企業のITリテラシーが低いことの証ではあるまいか。
 なお、超上流以前に、IT利用を前提としない事業や業務の検討や「IT利用が必要か」の検討をするプロセスが必要になる。IT屋は「経営」が好きだから、そのプロセスへも参加したがる。そのうちに、「超々上流」が話題になるのは必須である。
電子政府・電子自治体
 「IT化における基本的な留意事項を無視すると、どのような問題が発生するか」を周知させるための公開実験のこと。その成果の一部を示す。  このような膨大な費用がかかる検証実験は、民間企業では決して許してもらえない。国や自治体が引き受けたことは英断だったといえよう。しかし、実験を恒久的に継続するのは困る。
マルチメディア/ユニファイドコミュニケーション
 マルチメディアは誤用である。従来は画像や音声など多様な伝達媒体があったが、それをバイナリデータとして統一するのだから、ユニメディアとするべきである。その観点では、ユニファイドコミュニケーションは正しい用法である。
ユビキタス
 昔、コンピュータは磁気テープ装置で擬人化された。その後、パソコンのディスプレイになり、現在は雲(クラウド)になっている。次第に抽象化され人間の姿から遠ざかる傾向がある。
 また、一貫してコンピュータ本体はその対象になっていないのは、偶像化してはならない神聖な存在だからである。この思想は、ITは目には見えないがあまねく存在するというユビキタスの思想へと高められた。すなわち、ITは信仰の対象であり、それを理解しようというのは罪なのである。
要求・要件
 昔は「要求分析」や「要求定義」のように、「要求」一本だった。国語に堪能なIPAは、共通フレーム2007で、「要求」と「要件」に区別し、「要件分析」「要件定義」と書き換えた。これにより、ユーザが「できればいいな」といっただけなのか、「実現を取引の条件とする」としたのかが明確になった。
 世の流れに従い、この共通フレームも「国際標準」に合わせることになった。ところが、英語では要求も要件もrequestである。この分野での文化レベルが低い英語人種に、この機微を伝えることができない。
 それで共通フレーム第2版では、せっかくの区分をあいまいにしてしまった。しかも、英語の「nees」を採用するのに「妄想」と訳すのをためらったので、「要求」との境界もあいまいになってしまった。それで、共通フレームでは、ニーズ、要求、要件が混在している。海外取引先のために英訳するときどうなるのだろう?
 ところで「経営者の想いを実現する」というときの「想い」とは何なのだろう? 「要件」を合理性や形式性があるもの(共通フレーム第2版)だとすれば、ほとんどの「想い」は「要件」ではないし、その変換過程で、当初の想いとは大きく乖離した要件になろう。
リッチクライアント/シンクライアント
 消費者ニーズが成熟化してくると、ありきたりのパソコンでは見向きもされない。一攫千金を夢見る人向けのリッチクライアント、ダイエットを気にしている人向けのシンクライアントが注目されている。
 リッチクライアントでは、株価情報をダウンロードしながら人生ゲームを楽しめる機能を搭載する。動画や音声の品質がよいことが宣伝されているが、それによって、株の選択が容易になるのではないことに留意する必要がある。
 シンクライアントでは、余計な機能を一切排除してスリム化を図っているが、ダイエット食品と同じように、排除した分だけ安価にするどころか、通常よりも高い価格に設定することにより、利用者の優越感を高めているのが特徴である。
ロングテール現象
 ロングテールとは、ウェディングドレスや十二単などの長い裾部分のこと。歴史的には、女性の社会進出に伴い、次第に裾が短くなってきたのに対して、繊維業界が長い裾の価値を再認識させようと努力した結果、裾の部分が全体の売上に占める割合を増大させたことが発端である。
 それから転じて、通常では売れないガラクタも、インターネット販売ではそれなりの売上が見込める現象のことをいう。しかし、裾部分だけを売ろうとしたのでは商売にならないことを留意する必要がある。