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

Murphyology on Information Technology (vol.2) 2000s

０１　科学法則の適用

自然科学や社会科学には多くの法則が存在する。これらは天才たちが努力して発見し、多くの検証により確認された真実である。独自の法則を唱える以前に、これらの法則の適用を考察する必要がある。

自然科学法則（2011/6/22）

コンピュータは自然科学の産物であるから、ＩＴ活用の分野でも、基本的な振る舞いは自然科学の法則に従うのは当然である。

慣性の法則（その1）
　外部からの力が働かないと、物体は動かない。
　セキュリティ対策やシステムの見直しも、内部意見では実現しない。その実現には、個人情報保護法やIFRSなどの外部作用が必要なのである。また、それらの法規や基準も、海外からの外部作用がないと変わらない。
慣性の法則（その2）
　物体の運動を変えるには、質量に比例した力が必要になる。
　経営環境の激変に対処するには、情報システムを改訂しやすくする必要があるが、巨大な情報システムを改訂するのは大きなコストや時間がかかるため、難しい。それで、昔はシステムを「統合せよ」といったが、現在では「分割せよ」といわれている。
　その典型的な例は、ERPパッケージによる統合化から、SOAやクラウドなど部品の粒度をサービス単位まで小さくする変化である。
作用・反作用の法則
　組織や業務の変化を伴うＩＴ化を行おうとすれば、必ず反発が起こる。
　ニュートンは作用と反作用は同じ大きさだといったが、実際には反作用の方が大きく、「1つの提案への反論は1ダースある」。静止摩擦抵抗が大きく、作用を加えてもなかなか動き出さないのである。
　このとき、静止摩擦抗以上の作用を加えると物体は暴走する。個人情報保護法では、当初は言論の自由が脅かされるなどの理由でなかなか成立しなかったが、いったん成立した途端に、過剰反応による弊害が問題になった。
エネルギー保存則
　ＩＴ化により、ある部門の省力化を達成するには、ＩＴ部門がそれと同等の労力を必要とする。また、ＩＴ投資の費用を捻出するためには、一層の販促やコスト削減の努力が必要になる。すなわち、ＩＴ化は仕事量を他の部門に移転するだけであり、その総量を減少させるものではない。
　さらに、エネルギー変換においては、一部は熱などにより失われるので、有効エネルギーとしては減少する。すなわち、ＩＴ化のための仕事の増加量は、ＩＴ化による省力量よりも大きいのが通常である。
エントロピー増大の法則
　情報システムは、時間とともに複雑になり動かなくなるので、時々再構築をしなければならない。
　長く放置してきたシステムほど、再構築には労力が掛かる。
　「分かってはいるのだが、今は忙しいから」といって放置すると、暇になっても実施できない規模のカオスになってしまう。
　「虫歯と情報システムは放っておくとますます悪くなる。」
ボイル・シャールの法則
　「体積＝k×絶対温度／圧力」の関係は、ＩＴ分野では「体積（規模）＝k×絶対温度×圧力」に修正されている。
　すなわち、開発システムの規模は、外部からの圧力が多く、関係者間の絶対的な対立熱気に比例して大きくなる。対立があると、システムの規模を縮小しようとする動きよりも、対立する事柄をシステムに取り込もうとする動きになるからである。もし、システムの規模を小さくするためには、絶対温度を下げること、すなわち、関係者に興味をもたせず無視させることが効果的である。
ル・シャトリエの法則
　生産性向上を目的にシステム化をすると、そのシステム関連の作業のために生産性が下がる現象は昔から認識されている。
　医療の電子カルテ化は、診療の合理化を図るはずなのに、医師はその入力作業のために診察時間を短くし、患者と会話もしなくなる。営業部員に顧客情報を提供するためにBI（ビジネス・インテリジェンス）を構築すると、社員はパソコンにかかりきりになり顧客訪問をしなくなる。「システムは期待を裏切るように行動する」のである。
不確定性原理
　微細な量子は、運動と位置を同時に確定することはできない。
　ユーザニーズも、ヒアリングすることにより変化し、数回ヒアリングすれば、そのたびに異なったニーズになる。そして、ユーザニーズを詳細に定義しようとすれば、ニーズの目的は不明確になるし、目的を明確にしようとすると、それを実現する具体的なニーズを示すことができなくなる。
　なお、ＩＴ分野ではプランク定数の値が極めて大きく、しかも、時代とともに大きくなる特徴がある。
不完全性定理
　「全てのクレタ人は嘘つきだとクレタ人がいう」のように、自己言及はパラドックスを内蔵する。
　プログラマはプログラムにバグがないことを証明できない。ＩＴ部門はシステムの有効性を証明できない。「システムの内部にいる者はシステムが見えない」のである。
　なお、経営者が「全員一丸になって～」というとき、経営者自身が「全員」に含まれているのかどうかを確認することが重要である。
複雑系のバタフライ効果
　「北京で蝶が羽を動かすとニューヨークで嵐が起こる」ことが知られている。
　システム化提案においても、社長と専務のどちらを先に根回ししたかの違いや、会合での議題の提案順序の違いなど、提案内容とは無関係な初期設定や、会合でちょっと出た本件に関係のないつぶやきなど、ささいなノイズが、提案の評価や採否に大きく影響することが多い。

社会科学法則（2011/7/11）

経営やＩＴは複雑系なので、多くの科学領域を超えた研究が必要である。自然科学分野の法則に続き、社会科学法則のＩＴ業務への適用について研究する。

グレシャムの法則「悪貨は良貨を駆逐する」
　「パスワードを定期的に変更する」という良癖は、なかなか浸透しない。システムから強制的に変更する手段を採ると、いったんは変更するものの、次の瞬間に元のパスワードに戻すという手段がすぐにまん延する。「悪癖は良癖を駆逐する」のである。
　ＩＴ部門が、システム運用などの日常的業務とＩＴ戦略策定などの長期的業務を持っていると、日常的なトラブル対応に追われて、長期的な業務が行われなくなる。「短期は長期を駆逐する」。これがアウトソーシングを行うことの指導原理である。ところが、ＩＴ部門の短期業務をなくしても、戦略部門になるとは限らない。
マルサスの法則「人口は等比級数的に増え、食糧は等差級数的に増える」
　イッサウィ／ウィルコックスは「問題は等比級数的に増え、解決法は等差級数的に増える」と展開した。常にＩＴ部門が多忙なのは、これらの法則が支配しているからだ。
パーキンソンの法則（その1）
「公務員の人数は、仕事量に関係なく、毎年一定の割合で増加する」
　経営環境に大きな変化はなくても、システムに対する要求は頻発するので、「システム対象業務は、必要性に関係なく毎年拡大する」。この現象を「システムは生物のように自然成長する」といった人もいるが、生物のように自然淘汰しないところに大きな問題がある。
パーキンソンの法則（その2）
「仕事の量は、完成のために与えられた時間を全て満たすまで膨張する」
　ユーザは１０分間で得られた情報を、凝ったグラフに加工するために１週間にわたって作業する。スパイラル型の開発では、ユーザの趣味により、エンドレスのスパイラルに陥る。
　WindowsやOfficeが求めるハードウェア資源は、その時点で得られるハードウェアの限度まで膨張する。そのため、パソコンの性能が向上しても、利用者が使える資源は常に不足している。
サイモンの満足原理「経済人は最適原理に従うが、経営人は満足原理に従う」
　利用部門は、不明確なニーズの下で、システム開発を要求する。経営者は不完全な説明の下で開発の意思決定をする。ＩＴ部門は、不十分な要求仕様の下でシステム開発を行う。
　その結果、常に“不”満足なシステムになる。
ピーターの法則「階層社会においては、昇進により無能レベルに到達する」
　この法則は「多くの業務は無能者によって管理されるので、円滑に動かない」と展開される。東日本大震災に伴う原発事故では、大政党も大企業も典型的な階層社会であることが証明された。
　ピーターの指摘を待つまでもなく、このようなことはサラリーマンは誰でも知っている。「ウチのＣＩＯやＩＴ部長はバカだ。それでも何とか動いているのは、オレたちがいるからだ」と。しかし、不満をいうべきではない。有能なキミが昇進しないでいることこそ、会社の英知であり成長の源なのだから。
ジョン・ゴールのシステマンテックス
「システムは一般に不完全にしか働かないか、あるいはまったく動かないかのいずれかである」
「複雑なシステムは、思いもかけない結果を生む」
　情報の共有化のために構築したシステムは、秘密の漏えいが大きな問題になる。そして、セキュリティ対策のためのシステム規模が、情報共有のためのデータベースの規模よりも大きくなる。
　全業務にＥＲＰパッケージを適用すると、複雑になり動かなくなる。そのため、賢明で誠実なベンダは、会計システムへの適用を勧めるだけで、他の分野への適用にはお茶を濁す。賢明なユーザ企業は、ＥＲＰパッケージ導入と業務改革の両方を行うと複雑になるのを回避するために、ＥＲＰパッケージでのシステム構築だけを目的にして業務改革を無視する。
　レガシー時代には「コンピュータは期待したようには動かない。指示したとおりに動くのだ」といわれた。オープン系になってからは「コンピュータは指示どおりには動かない」ようになり、Web時代、クラウド時代になると「コンピュータの動きは人知では分からない」にまで発展した。それほどシステムが複雑に巨大になったのだ。

情報科学法則（2011/7/27）

ＩＴ分野の先達は、珠玉の法則を遺している。それに原著の文脈を無視した蛇足（曲解）を加えるのは不謹慎だが、お許し願いたい。

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

次へ進む