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

Murphyology on Information Technology (vol.2) 2000s

０２　歴史認識

現在の行動、将来への対策を検討するには、正しい歴史認識が求められる。
・万物は流れる。時間の矢は一方方向
・歴史は繰り返す。温故知新
・天の下、新しきことなし。
不易流行を考察することが大切だ。

今昔物語－進化は進歩とは異なる（2009/1/19)

情報システムが登場してから半世紀近くになった。レガシー時代と現在では、ＩＴエンジニアの役割も大きく変わっている。今回はＩＴエンジニアの昔といまを比較した法則を紹介する。
　「成功は失敗の父」といわれる。時代の変化を的確に理解することが重要だ。ベテランＩＴ技術者は心せよ。

昔、改革の先兵。今、改革のお荷物
　コンピュータが企業に導入されたころは、ＩＴ部門（電算室とかＩＢＭ課といわれた）は、経営者をだまし、利用部門を脅してＩＴ化を進めてきた。部門名称にもかかわらず、チェンジエージェンシーだったのである。
　経営情報企画部となった現在では、情報システムが改革のネックだといわれるようになった。情報システム統合の遅れが原因で、企業合併が遅れることすらある。
　これが事実なこともあるが、実は情報システム以外にも多くの遅れがあり、たまたま情報システムが見えただけなのかもしれない。その情報システムが遅れたのは、ほかの要因が原因だったのかもしれない。
　いずれにせよ、ＩＴを悪者にしておけば周りも納得するし、特定個人の責任を追及する悲劇を回避できる。このようなＩＴの効用は昔もいまも変わらない。
昔、ユーザ志向。今、経営志向
　以前は「ユーザはお客さま」であり「ユーザの声は神の声」なのだから、情報システムはユーザニーズに応えるべきだとされた。
　それが、ＥＲＰパッケージの出現により、ＩＴガバナンスが重視され、「靴に足を合わせる」ことになった。いずれの時代でも「ＩＴ部門志向」がいわれたことはない。
昔、外科医。今、内科医
昔、西洋医学。いま、漢方医学
　レガシー時代にはJCLとCOBOLだけを駆使して、複雑な脳手術や心臓手術ができるのが優秀なプログラマであった。現在ではOOAやSOAのように、膨大な薬箱から適切な薬を組み合わせて調合できるのが優秀なプログラマである。
　対象が基幹系システムのときは、病状も治癒した状況も明確であった。グループウェアやナレッジマネジメントでは病状も分かりにくく、治癒したかどうかも不明確である。
昔、病理学。今、臨床学
　レガシー時代には、システムダウンが起こると原因追及が行われ、同じ原因によるトラブルの再発を防ぐことが重視された。
　現在では原因が不明なままに、ともかくメモリを増設しようとか、ルータを取り換えようという対策でお茶を濁す。そのような対処でも一応動くようになるが、次の瞬間に再発するかどうかは分からない。そのような理由で優秀なＳＥになるのには、理論を学ぶよりも場数を踏む方が重要になる。
昔、情報の共有化。今、セキュリティ
　昔は、「資材の仕入れ先に自社製品をどれだけ売っているか？」のような横串的分析が重要だといわれた。現在ではセキュリティの観点から、仕入れ先ファイルも得意先ファイルもパスワードが設定されており、ほかの部門の者には利用させないようにしている。人事異動時には、ファイルのアクセス制限変更が最大のネックである。
　個人情報保護の理由で顧客データベースが廃棄された。同じ会社からお歳暮をいくつももらうのはうれしいものだ。
昔、品質。今、納期
　バグのあるプログラムはプログラマの恥とされ、バグを生まないための「プログラミング作法」が重視されたのは昔の話だ。
　現在は、ともかく短期間に稼働させることが重視される。バグがあるにせよ、それが発見される以前にビジネスモデルが変更になってシステム再構築が必要になるので、大した問題ではなくなったのだ。
　テストが不十分なままに本番稼働してトラブルが発生することが指摘されるが、おそらく関係者はテスト期間よりも、システムの寿命の方が短いと予測しているのであろう。
昔、プログラマを疑え。今、コンピュータを疑え
　COBOL時代では「コンピュータにエラーがありました」と初心者がいうと、「コンピュータは思ったようには動かない。命令した通りに動くのだ」「コンピュータはエラーを起こさない。オマエのプログラムにバグがあるのだ」とベテランにたしなめられた。
　コンピュータ工学が発展して人間に近くなった現在では、「コンピュータはマニュアル通りには動かない。自律的な行動をする」ことをベテランも承知するべきである。
昔、大文字。今、小文字
（プログラム言語は、シフトキーを多用するように発展する）
　レガシー時代の言語、COBOLやFORTRANなどでは、予約語を大文字で書くのが通常であった。当時は大文字にロックしておけば、シフトキーの操作はほとんど不要であった。
　オープン時代になり、CやJavaでは小文字で書くようになった。HTMLも当初はタグを大文字で書いていたが、次第に小文字になり、XHTMLでは小文字が強制されるようになった。それにより、英字と"="や"+"などでシフトキーを使う必要が出てきた。
　しかも、昔は大文字・小文字の区別はなかったのが、次第にそれを区別するようになってきた。また、単語と単語をつなぐ変数名も、COBOLでは"-"でよかったのが、"_"でつなぐようになり、現在では、単語の先頭を大文字にして判別するようになった。
　これらの変化は、タイピングを面倒にすることにより、安易なプログラミングを防止するのに役立っている。
昔、１から。今、０から
　FORTRANの配列の添え字は１からであった。BASICは０から、PL/Iは任意の範囲が設定できたが、１から用いることが推奨されていた。人間の慣習と一致させるためである。ところが、CやJavaでは添え字を０から用いることが推奨されている。
　ポインタはPL/Iではプログラム解読が困難になるとの理由で、使わないように社内ルールを定めるのが通常であった。逆に、Cではこれが広く用いられている。Cだから解読が容易になったというわけではないのだが。
　昔はプログラミングを楽しむ風潮があったが、現在では規格にはめられた単調な作業になり、ストレスがたまっている。少しでも遊び心を持たせるために、プログラミングにクイズの要素を取り入れたのだろう。

歴史は繰り返す－２度目は喜劇として(2009/4/13)

最近、よく耳にする仮想化技術は、レガシー時代から用いられていた技術だ。また、サーバを統合したり、分散処理したり……といったことも、これまで何度も繰り返されている。

１周遅れのランナーは、トップを走っているように見える< （途中でゴールが引かれれば、実際にトップになることもある）
　メインフレームよ、さようなら。これからは、オープン系で分散処理です。管理費が高くつきますね。回線も安く高速になったことだから、利用部門にサーバを分散配置するよりも、集中した方が管理が容易です。サーバだらけになりましたね。これでは場所をとりますから、１台の装置にまとめましょう……。　あれ？ これはいつかやっていた方式ですね。
　セキュリティが心配です。クライアントに記憶装置があったり、アプリケーションを載せたりするからいけないのです。それらを全部はがして、サーバで処理するようにしましょう。……昔の端末を捨てなければよかった。
　サーバがネックになっています。一時的に余裕のあるサーバを利用できないでしょうか？ それこそ当社が誇る仮想化技術です。当社のサーバで統一すれば、そのような無駄がなくなりますよ。……なんだ。レガシー時代では当然のことだったのに。
　エクストリーム・プログラミング（XP）は素晴らしいですよ。数人のプログラマとユーザが短期間で開発する範囲や仕様を決めて、テストしながら逐次開発していくんです。ソフトウェア工場のような没人間的なやり方ではないので、プログラミングが楽しいですよ。……古希を過ぎたＯＢ、「オレがプログラムをやっていたときもそうだったよ。当時から進歩がないなぁ」。
混一色よりも清一色の方が良いに決まっている
　レガシー時代はメインフレームメーカー、一辺倒であった。
　オープン時代ではマルチベンダ化が礼賛され、多様なＯＳやミドルウェアが乱立した。個々のシステムを異なるベンダに発注したので、社内標準が崩壊した。その後、インテグレータとかアウトソーシングにより、ユニベンダ化が進んだ。
　情報システムでは、ＥＲＰパッケージの限界がいわれ、SaaSで各サービスの「いいとこどり」ができると期待された。ところが実際には、他サービスとの連携が困難で、結果として一つのSaaSベンダに丸抱えされている。
用語を変えればニーズが生じる
　1960年代～1970年代には、意思決定支援のために線形計画法（リニア・プログラミング）、PERT（Program Evaluation and Review Technique）、シミュレーションなどのＯＲ（Operations Research）技法が花盛りであった。1980年代になるとコンピュータによる省脳化により消え去ってしまったが、1990年代になるとデータマイニングとして息を吹き返した。
　もっとも、ＯＲとデータマイニングの間には大きな違いがある。前者ではコンピュータ負荷を低減するためにサンプリングが重視されたのに対して、後者では全データを対象にする。そのため、パソコンでもできることに並列プロセッサを用いるようになった。データクリーニングをせずに玉石混交のデータを用いるので、ノイズが混入し、グラフ化しないと全体傾向がつかめなくなった。それで、マイニングツールは分析技法ではなく、グラフの３Ｄ技術を売り物にしている。

永遠の課題

紀元前3000年のエジプトで「近頃の若い者は・・」と象形文字で刻まれた粘土版があるそうだ。そもそも変化していない「古くて新しい問題」もある。

ＩＴ投資はもうかるのか？
　これは、現在でも経営者の最大の関心事の一つである。
　そして、「ＩＴに投資したらもうかるのではない。業務や組織の見直しが必要である」ことは当然だが、そのようなことは1960年代にもいわれていた。当時、「コンピュータを入れる。そのために業務の見直しをせよ」といって、業務の標準化や改革を行い、それが済んだら「コンピュータは高いのでやめた」というのが、最も効果的な方法だといわれたものである。これは、現在でも有効な方法ではないだろうか？
　評価基準がなければ、もうかっているか損をしているかは分からない。半世紀もたっているのに、その基準を確立している企業が少ないのも、古くて新しい問題である。
ウチの経営者はＩＴが分かっていない
　ほとんどのＩＴ部門はこのような愚痴をこぼす。
　一方、ＩＴの教科書では「経営者の思いを成就することが、ＩＴの目的である」と一貫して書かれている。教科書の著者が現場を知らないことは、昔もいまも変わらない。
　経営者に変化があるとすれば、「パソコンが使える」や「SaaSという用語を知っている（間違った理解だが）」ことで、ＩＴを理解していると自任する経営者が増えた程度である。
ＩＴ部門はいかにあるべきか？
　昔から、ＩＴ部門は企業戦略に密着した戦略部門である（あるべきだ）といわれてきた。それならば、自社の最高機密を持っているので、その組織の存在、部門要員の氏名すら秘密にすべきであろう。
　ところが、自部門の在り方について、部外者の講演を聞いたり、他社の同業者と話し合う研修会に参加したりするのに熱心である（営業部門や生産部門が、このような行動をすることはまれである）。

次へ進む