これまで多数の法則を紹介してきたが、法則を正しく理解するには、用語や概念を正しく理解することが前提となる。今回は、誤解されやすい用語や概念を再定義する最終回だ。
情マネ流マーフィー妖誤その23
共通キャリア・スキルフレームワーク
3つの標準スキルITSS、UISS、ETSSは、それぞれ関係者間における「共通のものさし」とするために、職種やスキルの定義をするのが目的である。そして、共通キャリア・スキルフレームワークは、これらを共通の体系に統合するのが目的である。
ところが、共通化の基本である職務名称の統一すら解決されていない。ITアーキテクト(ITSS)、ISアーキテクト(UISS)、システムアーキテスト(ETSS)の名称の違いを説明するのは難しい。また、ITSSはプロジェクトマネジメント、UISSとETSSではプロジェクトマネージャとしているが、どちらかに統一しても困ることはない。
そもそも、ITSSではIT、UISSではISと言ってきた。おそらく当初は、その違いをことさらに重視したのではなかろうが、どちらかに統一するとなると深刻な問題になる。共通キャリア・スキルフレームワークでは、ITは技術、ISはシステムだと定義しているが、あえて区別する必然性があるとは思えない。両者の顔を立てるための苦し紛れの配慮のように感じられる。
業務用語は、各企業が長年の慣習により培ってきた企業文化の産物である。それを変えることは、自己の歴史を否定されたことになる。そのため、企業合併時のシステム構築において、用語の統一が最大の難関であることはよく知られている。おそらく、共通キャリア・スキルフレームワークの策定作業においても、同様な組織力学が影響したのであろう。
IT(IS)関連では共通化・標準化が重要だと言われているが、その実現がいかに困難であるかを示した好例である。
情マネ流マーフィー妖誤その24
超上流
従来の情報システムのライフサイクルは、「開発すべき情報システムが持つべき機能の検討」以降が対象であった。それよりも以前のプロセス、すなわち、事業や業務におけるIT化検討の段階を超上流という。言い換えれば、IT利用を前提としたビジネスプロセス設計のことである。
ここで重要なのは「IT利用を前提にした」である。IPAの「超上流から攻めるIT化の原理原則17ヶ条」で示すように、この段階で既にベンダが参加していることが前提となっている。
この「超上流」は日本発の概念である。本来、超上流プロセスはユーザー企業の聖域である。
それなのにベンダの存在を必要とするのは、あまりにも日本ユーザー企業のITリテラシーが低いことの証ではあるまいか。
なお、超上流以前に、IT利用を前提としない事業や業務の検討や「IT利用が必要か」の検討をするプロセスが必要になる。IT屋は「経営」が好きだから、そのプロセスへも参加したがる。そのうちに、「超々上流」が話題になるのは必須である。
情マネ流マーフィー妖誤その25
電子政府・電子自治体
「IT化における基本的な留意事項を無視すると、どのような問題が発生するか」を周知させるための公開実験のこと。その成果の一部を示す。
・情報システムは利用されて価値を生じる
顧客サーベイが不十分だと、利用1件当たり数千万円になるような申請システムになる危険がある。
・IT化とともに業務改革を行う必要がある
ITだけe?Govにしても、縦割り組織は解消しない。
・IT投資の費用対効果を明確にせよ
IT利用と手作業が併存すると、かえって担当者の業務は増大する。
・個別アプリ構築以前に、全体計画を策定する必要がある
個々のシステムを構築してから、EAなどの方法論やクラウド適用などを示すと二重投資になる。
このような膨大な費用が掛かる実験は、民間企業では決して許してもらえない。国や自治体が引き受けたことは英断だったと言えよう。しかし、実験を恒久的に継続するのは困る。
情マネ流マーフィー妖誤その26
マルチメディア/ユニファイドコミュニケーション
マルチメディアは誤用である。
従来は画像や音声など多様な伝達媒体があったが、それをバイナリデータとして統一するのだから、ユニメディアとするべきである。その観点では、ユニファイドコミュニケーションは正しい用法である。
情マネ流マーフィー妖誤その27
ユビキタス
昔、コンピュータは磁気テープ装置で擬人化された。その後、パソコンのディスプレイになり、現在は雲(クラウド)になっている。
これらは、次第に抽象化され人間の姿から遠ざかる傾向がある。
また、一貫してコンピュータ本体がその対象になっていないのは、偶像化してはならない神聖な存在だからである。この思想は、ITは目には見えないがあまねく存在するというユビキタスの思想へと高められた。
すなわち、ITは信仰の対象であり、それを理解しようというのは罪なのである。
情マネ流マーフィー妖誤その28
要求・要件
昔は「要求分析」や「要求定義」のように、「要求」一本だった。
国語に堪能なIPAは、共通フレーム2007で「要求」と「要件」に区別し、「要件分析」「要件定義」と書き換えた。これにより、ユーザーが「できれば良いな」と言っただけなのか、「実現を取引の条件とする」としたのかが明確になる。
システム調達取引が国際化している現在では、この共通フレームを海外にも浸透させる必要がある。ところが、英語では要求も要件も“Request”である。この分野での文化レベルが低い英語人種には、この機微を伝えることができない。
それで共通フレーム第2版では、せっかくの区分をあいまいにしてしまった。しかも、英語の「nees」を採用するのに「妄想」と訳すのをためらったので、「要求」との境界もあいまいになってしまった。そのため、共通フレームでは、ニーズ、要求、要件が混在している。海外取引先のために英訳するときどうなるのだろう。
ところで、「経営者の想いを実現する」というときの「想い」とは何なのだろう? 「要件」を合理性や形式性があるもの(共通フレーム第2版)だとすれば、ほとんどの「想い」は「要件」ではないし、その変換過程で、当初の想いとは大きく乖離した要件になろう。
情マネ流マーフィー妖誤その29
リッチクライアント/シンクライアント
消費者ニーズが成熟化してくると、ありきたりのパソコンでは見向きもされない。一攫千金を夢見る人向けのリッチクライアント、ダイエットを気にしている人向けのシンクライアントが注目されている。
リッチクライアントでは、株価情報をダウンロードしながら人生ゲームを楽しめる機能を搭載する。動画や音声の品質が良いことが宣伝されているが、それによって、株の選択が容易になるのではないことに留意する必要がある。
シンクライアントでは、余計な機能を一切排除してスリム化を図っているが、ダイエット食品と同じように、排除した分だけ安価にするどころか、通常よりも高い価格に設定することにより、利用者の満足感を高めているのが特徴である。
情マネ流マーフィー妖誤その30
ロングテール現象
ロングテールとは、ウェディングドレスや十二単などの長い裾部分のこと。
歴史的には、女性の社会進出に伴い、次第に裾が短くなってきたのに対して、繊維業界が長い裾の価値を再認識させようと努力した結果、裾の部分が全体の売上高に占める割合を増大させたことが発端である。
それから転じて、通常では売れないガラクタも、インターネット販売ではそれなりの売上高が見込める現象のことを言う。しかし、裾部分だけを売ろうとしたのでは商売にならないことを留意する必要がある。
著者紹介
▼著者名 木暮 仁(こぐれ ひとし)
東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」(日科技連出版社)、「もうかる情報化、会社をつぶす情報化」(リックテレコム)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している
- 情マネ流マーフィーの妖誤集〜その3
- 情マネ流マーフィーの妖誤集〜その2
- 情マネ流マーフィーの妖誤集
- 情報科学の法則を復習しよう
- 社会科学法則の「情マネ流マーフィー」への適用
- 自然科学法則の「情マネ流マーフィー」への適用
- コンピュータが発展すると人間はバカになる
- バグとの長い長い付き合い
- なぜソフトウェアの部品化/再利用は進まないのか?
- “バカ・マジメ”をメンバーに入れるな!
- なぜIT部門は提案できない/しないのか?
- ユーザーニーズを基にシステムを作るな
- 成果の出ないIT戦略
- IT技術者、どう評価する?
- 何かが足りない日本のIT教育政策
- 電子政府の研究はIT推進の教科書として最適だ
- 日本にはびこる素人CIO
- IT部門の戦略部門化は矛盾だらけ
- なぜIT部門アウトソーシングがうまくいかないのか?
- IT部門の社内的地位が低い“本当の原因”は?
- 役に立たないグループウェア
- ユーザーの過度体裁愛好症が問題だ
- ユーザーの過度依存症とIT部門の没我的愛情症
- ああ、上司と部下の悲しいすれ違い
- IT系アンケート結果は信用できない
- “クラウドコンピューティング○×”の寿命
- 羊頭狗肉のIT用語、誇大表示を告発する
- そして、歴史は繰り返す − 2度目は喜劇として
- ITエンジニア今昔物語
- “リスク管理のリスク管理”が必要だ
- 納期とは遅れるものだ
- ITの効果とはプロジェクトの効果だ
- 費用対効果を追求することで出銭が増える愚かさ
- そもそも、IT計画が実現すること自体が奇跡だ
- 経営者にITの費用対効果を説明するのは難しい
- ERPパッケージの不思議あれこれ
- 合併時の代理戦争には気を付けろ!
- ないものねだりのRFP
- 標準化にメリットはあるのか?
- システム開発の可視化で何が見える?
- 「他人のふんどし指向アプローチ」を考える
- マーフィーの法則がIT版になって帰ってきた!
Copyright © ITmedia, Inc. All Rights Reserved.