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