IT分野の先達は、珠玉の法則を遺している。それに対して、原著の文脈を無視した蛇足(曲解)を加えるのは不謹慎だが、お許し願いたい。
情マネ流マーフィーの法則その220
グロシュの法則
「コンピュータの性能は価格の二乗に比例する」
レガシー時代には、この法則により、汎用コンピュータの大型化が進んだ。ダウンサイジングには都合の悪い法則なので、政策的に葬られてしまった。さらに現在では、デスクトップPC、ノートPC、タブレットPC、携帯電話、スマートフォンなど、似たような機能の多数の機器を所有することが推奨されている。「情報機器の費用は、必要な機能の二乗に比例する」と表現すれば、グロシュの法則は現在でも通用する。
この法則は人間系にも適用ができる。安い料金のSEを2人使うよりも、その料金で優秀なSEを1人使う方が役に立つ。ただし、高い料金をとるSEが常に優秀だとは限らない。
情マネ流マーフィーの法則その221
ムーアの法則
「半導体の集積密度は18カ月で2倍に向上する」
「しかも価格は変わらない」。と続くのだが、新しいチップが発売されるたびに不要な買い替えをさせられているような気がする。
情マネ流マーフィーの法則その222
メトカーフの法則
「ネットワークの価値はユーザー数の2乗に比例して増大する」
「優れたものが普及するのではない。普及しているものが価値があるのだ」ということは、レガシー時代のIBM、パソコン時代のマイクロソフトで証明済みである。
そのうち、グーグルも同様な評価に?
情マネ流マーフィーの法則その223
ブルックスの法則(その1)
「狼人間を撃つ銀の弾はない」
新しい概念やツールの唱道者は「これこそ待望の特効薬」だと宣伝するが、しばらくすると、いつも鉛の弾だと判明する。新しいように見えるのは、以前の鉛の弾に銀メッキをしたからである。
情マネ流マーフィーの法則その224
ブルックスの法則(その2)
「一つは放棄するつもりでいよ」
ウォーターフォール型開発技法では、要求分析→外部設計→内部設計→プログラミング→テスト→移行のライフサイクルを、逆戻りせずに行うことだと信じられている。ところが、この技法の提唱者であるブルックスは、最初のサイクルはプロトタイプとしてどうせ放棄するのだから、2回繰り返すことが必要だと言っている。
電子政府では、「個別に膨大な申請システムを構築した後で、EAの普及を図る」とか、「利用率向上のためにシステムの見直しをする」と言っている。この法則を正しく適用している数少ない理解者である。
情マネ流マーフィーの法則その225
ブルックスの法則(その3)
「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」
関係者が増えれば物事が複雑になる。
新人に状況説明をする必要がある。古巣で役立たないお荷物が押し付けられてくることもある。この法則を発展させれば、「プロジェクトの遅れを挽回するには、関係者を減らすのが効果的である」となる。
情マネ流マーフィーの法則その226
ベームの法則
「システム開発工数は規模の指数乗に比例して増大する」
ERPパッケージでは、ユーザーニーズを無視することにより、システム規模の増大を抑えることに成功した。また、ERPパッケージを全業務に適用するのは、従来の個別システム構築の合計よりも費用や時間がかかることも証明した。
そこで、提供機能を分割してSaaSとするのが良いと言われたのだが、その各機能間の連携が複雑なことが判明し、SaaSの発展形であるクラウドでは、また丸抱えにしようとしている。
情マネ流マーフィーの法則その227
コンサルタント業務に関するシャービーの法則
第1法則:依頼主がどう言おうとも、問題は必ずある
第2法則:一見どう見えようとも、それは常に人の問題である
第3法則:料金は時間に対して支払われるものであって、解答に対して支払われるものではない、ということを忘れてはならない
第1法則の活用:初心者コンサルタントは、製造業では「手待ち時間」、小売業では「顧客情報」、全産業では「在庫」を話題にすればよい。
第2法則の活用:ITに不得手なコンサルタントは、本来はITによる解決が適切な問題でも「組織や業務の見直しをすることが大切だ」とすり替える。
第3法則の活用:ITコンサルタントは、「あえてITを導入しなくても?」と答えたのでは、たいした報酬は得られない。IT導入を説得することにより長期的な契約がもらえるのだ。しかも「小さく生んで?」と言って当初のIT導入バリアを除き、エンドレスな拡大を提案して時間を延長する。
情マネ流マーフィーの法則その228
ワインバークの最高度困難法則
「自分の手助けをすることは、他人の手助けをするよりもっと難しい」
これが「紺屋の白袴」の理由である。
経営者は経営課題の解決はできない。IT部門はIT活用の実現はできない。経営者がIT部門に経営の提案を求めたり、IT部門が経営者の参画を求めたりするのは当然か。
情マネ流マーフィーの法則その229
デマルコ/リスターのリスク法則(その1)
「リスクのないプロジェクトには手をつけるな」
ハイリスク・ハイリターンが経営戦略の特徴だ。
ところが、IT部門は「トラブルがあると叱られる」という脅迫観念が染みついており、リスク回避をしたがる。プロジェクトチームに参加しても慎重派になる。戦略部門になるには不適切な部門なのだ。
情マネ流マーフィーの法則その230
デマルコ/リスターのリスク法則(その2)
「リスク管理は大人のプロジェクト管理だ」
無防備で飛び込むのは子どものやることだ。事故が起こらないように、事前に目配りをするのが大人の役目だ。
「いけいけドンドン」の無邪気なプロジェクトにIT部門が危惧の感を持つと、「保守反動派のIT部門が足を引っ張る」と非難するが、IT部門は社内(経営者を含めて)唯一の大人の部門なのである。
著者紹介
▼著者名 木暮 仁(こぐれ ひとし)
東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、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.