ITエンジニア今昔物語：情マネ流マーフィーの法則（14）

情報システムが登場してから数十年がたった。レガシー時代と現在では、ITエンジニアの役割も大きく変わっている。今回はITエンジニアの昔といまを比較した法則を紹介する。

» 2009年01月19日 12時00分 公開
[木暮 仁，＠IT]

　「成功は失敗の父」といわれる。時代の変化を的確に理解することが重要だ。ベテランIT技術者は心せよ。

情マネ流マーフィーの法則その81

昔、改革の先兵。いま、改革のお荷物


　コンピュータが企業に導入されたころは、IT部門（電算室とかIBM課といわれた）は、経営者をだまし、利用部門を脅してIT化を進めてきた。部門名称にもかかわらず、チェンジエージェンシーだったのである。

　経営情報企画部となった現在では、情報システムが改革のネックだといわれるようになった。情報システム統合の遅れが原因で、企業合併が遅れることすらある。

　これが事実なこともあるが、実は情報システム以外にも多くの遅れがあり、たまたま情報システムが見えただけなのかもしれない。その情報システムが遅れたのは、ほかの要因が原因だったのかもしれない。

　いずれにせよ、ITを悪者にしておけば周りも納得するし、特定個人の責任を追及する悲劇を回避できる。このようなITの効用は昔もいまも変わらない。

情マネ流マーフィーの法則その82

昔、ユーザー志向。いま、経営志向


　以前は「ユーザーはお客さま」であり「ユーザーの声は神の声」なのだから、情報システムはユーザーニーズに応えるべきだとされた。

　それが、ERPパッケージの出現により、ITガバナンスが重視され、「靴に足を合わせる」ことになった。いずれの時代でも「IT部門志向」がいわれたことはない。

情マネ流マーフィーの法則その83

昔、外科医。いま、内科医


情マネ流マーフィーの法則その84

昔、西洋医学。いま、漢方医学


　レガシー時代にはJCLとCOBOLだけを駆使して、複雑な脳手術や心臓手術ができるのが優秀なプログラマであった。現在ではOOAやSOAのように、膨大な薬箱から適切な薬を組み合わせて調合できるのが優秀なプログラマである。

　対象が基幹系システムのときは、病状も治癒した状況も明確であった。グループウェアやナレッジマネジメントでは病状も分かりにくく、治癒したかどうかも不明確である。

情マネ流マーフィーの法則その85

昔、病理学。いま、臨床学


　レガシー時代には、システムダウンが起こると原因追及が行われ、同じ原因によるトラブルの再発を防ぐことが重視された。

　現在では原因が不明なままに、ともかくメモリを増設しようとか、ルータを取り換えようという対策でお茶を濁す。そのような対処でも一応動くようになるが、次の瞬間に再発するかどうかは分からない。そのような理由で優秀なSEになるのには、理論を学ぶよりも場数を踏む方が重要になる。

情マネ流マーフィーの法則その86

昔、情報の共有化。いま、セキュリティ


　昔は、「資材の仕入れ先に自社製品をどれだけ売っているか？」のような横串的分析が重要だといわれた。現在ではセキュリティの観点から、仕入れ先ファイルも得意先ファイルもパスワードが設定されており、ほかの部門の者には利用させないようにしている。人事異動時には、ファイルのアクセス制限変更が最大のネックである。

　個人情報保護の理由で顧客データベースが廃棄された。同じ会社からお歳暮をいくつももらうのはうれしいものだ。

情マネ流マーフィーの法則その87

昔、品質。いま、納期


　バグのあるプログラムはプログラマの恥とされ、バグを生まないための「プログラミング作法」が重視されたのは昔の話だ。

　現在は、ともかく短期間に稼働させることが重視される。バグがあるにせよ、それが発見される以前にビジネスモデルが変更になってシステム再構築が必要になるので、大した問題ではなくなったのだ。

　テストが不十分なままに本番稼働してトラブルが発生することが指摘されるが、おそらく関係者はテスト期間よりも、システムの寿命の方が短いと予測したのであろう。

情マネ流マーフィーの法則その88

昔、プログラマを疑え。いま、コンピュータを疑え


　COBOL時代では「コンピュータにエラーがありました」と初心者がいうと、「コンピュータは思ったようには動かない。命令した通りに動くのだ」「コンピュータはエラーを起こさない。オマエのプログラムにバグがあるのだ」とベテランにたしなめられた。

　コンピュータ工学が発展して人間に近くなった現在では、「コンピュータはマニュアル通りには動かない。自律的な行動をする」ことをベテランも承知するべきである。

情マネ流マーフィーの法則その89

昔、大文字。いま、小文字（プログラム言語は、シフトキーを多用するように発展する）


　レガシー時代の言語、COBOLやFORTRANなどでは、予約語を大文字で書くのが通常であった。当時は大文字にロックしておけば、シフトキーの操作はほとんど不要であった。

　オープン時代になり、CやJavaでは小文字で書くようになった。HTMLも当初はタグを大文字で書いていたが、次第に小文字になり、XHTMLでは小文字が強制されるようになった。それにより、英字と"="や"+"などでシフトキーを使う必要が出てきた。

　しかも、昔は大文字・小文字の区別はなかったのが、次第にそれを区別するようになってきた。また、単語と単語をつなぐ変数名も、COBOLでは"-"でよかったのが、"_"でつなぐようになり、現在では、単語の先頭を大文字にして判別するようになった。

　これらの変化は、タイピングを面倒にするだけでなく、大文字小文字の区別をプログラマに強いることにより、安易なプログラミングを防止するのに役立っている。

情マネ流マーフィーの法則その90

昔、1から。いま、0から


　FORTRANの添え字は1からであった。BASICは0から、PL/Iは任意の範囲が設定できたが、1から用いることが推奨されていた。人間の慣習と一致させるためである。

　ところが、CやJavaでは添え字を0から用いることが推奨されている。それで、配列のオーバーフローや添え字に±1することのエラーが増大した。

　ポインタはPL/Iではプログラム解読が困難になるとの理由で、使わないように社内ルールを定めるのが通常であった。逆に、Cではこれが広く用いられている。Cだから解読が容易になったというわけではない。

　昔はプログラミングを楽しむ風潮があったが、現在では規格にはめられた単調な作業になり、ストレスがたまっている。少しでも遊び心を持たせるために、プログラミングにクイズの要素を取り入れたのだろう。

著者紹介

▼著者名　木暮 仁（こぐれ ひとし）

東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士（情報工学）、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」（日科技連出版社）、「もうかる情報化、会社をつぶす情報化」（リックテレコム）など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している


「情マネ流マーフィーの法則」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ