|
| |
※「セキュリティ保護のため...」というメッセージが出る方・日本語が入力できない方へ
ソフト革命と構造革命
【スパゲッティ】 1980年代半ば頃まではしばしば「スパゲッティ・プログラム」と呼ばれる ものを見かけました。要するに流れがグチャグチャになっててどこがどう なってんだか、訳のわからないプログラム。 だいたいそういうのを書いてた人は1990年代に生き残ってないと思うので それ以降は消えてしまったでしょう。 まぁ訳が分からないからスパゲティというのであって、例示するのは難し いのですが、スパゲティの素くらいなら簡単に呈示できます。 IF (A<B) GOTO 20 IF (A<C) GOTO 30 M=A GOTO 90 20 IF (B<C) GOTO 40 M=B GOTO 90 30 IF (C<B) GOTO 50 M=C GOTO 90 40 M=C GOTO 90 50 M=B 90 CONTINUE 有名な例なのでニヤニヤされた方もあるかと思いますが、これ何やってん だと思いますか？訳が分からない。そう、訳が分からないことが問題。 これはA,B,C の内、最大のものを M に格納しようとしてるんですね。でも それをやるのなら、下記の方がずっとシンプルで分かりやすい。 M=A IF (B>M) M=B IF (C>M) M=C 約5分の1の量で済んでしまいました。だいたい発想が貧困だとスパゲティ になりやすいのです。しかし考え過ぎもいけません。それを次回に。 (2000-07-07)
【超トリツキー】 これも有名な例です。なにをしようとしているのか見てみて下さい。 FOR I=1 TO 5 FOR J=1 TO 5 M(I,J) = (I/J) * (J/I) NEXT J NEXT I 私も最初見たときは頭をひねりました(^^; このプログラムの「ミソ」は整数のわり算をしていることで、3/5とかは 0 になりますので、この計算式は I>J ならJ/Iがゼロになり、I<JならI/J がゼロになります。 つまり、この計算式はIとJが異なる限りゼロになり、I=Jなら1になるの です。要するにこれは対角線が1でほかは0の5次行列を作っているのです。 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 しかし、どうしてこれを作るためにこんな分かりにくいことをする必要が あるのでしょう。これなら、こう書いたほうがよほど簡明です。 FOR I=1 TO 5 FOR J=1 TO 5 M(I,J) = 0 NEXT J NEXT I FOR I=1 TO 5 M(I,I) = 1 NEXT I 多くの言語では領域をゼロクリアする命令を持っていますので例えばCなら memset( m[0], 0, 25); for (i=0; i<5; i++) m[i][i] = 1; となってもっと簡単に済みます。 (2000-07-08)
【なぜ悪いのか】 昨日・一昨日の例ですが、これを書いた本人はそんなにいけないことと 思っていなかったかも知れない。では何が悪かったかというと次の一点 に尽きます。 データの格納を無理に一度で片づけようとした 私が直して「こちらがいい」と書いたやり方では同じ格納場所に複数回 アクセスしています。しかしコンピュータでは一般に「格納」にはそん なに時間はかかりません。それよりも 一昨日の例では「判断」が多すぎる。 昨日の例ではわり算をしている。 IFによる分岐はたいへん時間の掛かる処理です。またわり算は人間でも 面倒ですが、機械でもやはりたいへん。それをたくさんやっていますから これらのプログラムは「遅い」プログラムです。遅い上に分かりにくい コーディングなのですから、これは許されないのです。 プログラムを作っているとき「ややこしいコーディング」を避けられない こともあります。しかしそれはたいてい「スピードを上げるため」とか 「改造しやすくするため」であったりします。そして一昨日のプログラム はあれを４個の数字から最大値を取り出すプログラムに改造しようとした ら絶望的。こういうソフトはよくないソフトです。 (2000-07-09)
【部品化・構造化】 スバゲティ・プログラムというのは、たとえていえば、鉄鉱石の固まりか ら、いきなり自動車を作ろうとしているようなものです。 普通は鉄鉱石から鉄板や鋼管などを作り、それからエンジンだのギアだの 車軸だのを作り、そういった部品を組み立てて自動車に仕上げていく。 大きなプログラムを作る時は、やはりそういう過程を経る必要があります。 1968年にこういう問題について注目すべきふたつの提言がありました。 ひとつはEdsger Dijkstraの「構造化プログラミング」、もうひとつは Alan C. Kay の「ダイナブック構想」です。 ダイクストラの提言はプログラムの構造の明確化を要求していました。 プログラムは多くのモジュール(部品)から成って、それらは独立性を持ち どれかを修正したからといって他が影響を受けるようではいけない、とい ったことがこの「構造化プログラミング」では言われました。そして何よ りも大きなショックを与えたのは「GOTO を使わないようにしよう」という ものでした。 現在でもこの提言の影響を受けてGOTOを持たない言語というのもあります。 そしてそれに代わる仕組みとしてもっと構造の明確な、DO(FOR),WHILE(UNTIL), SWITCH(CASE) などといった命令群が整備されてきているため、「普通の」 ソフトを作る限りにおいては実際、現在GOTOはまず必要ありません。 (2000-07-10)
【構造化チャート】 そういう構造化プログラミングのためのチャートというのも幾つか考案 されています。NSチャート、PAD、SPD、HCPチャート、etc.etc. それぞれ「偉い人」たちにはなかなかアピールする部分があるのですが ソフト開発の現場で実用に耐えるかというと、なかなか難しいところが あり、上記の4つの中では私見ですが、SPDが最も実用性が高いと思います。 NSチャートなどは、それで10万ステップのソフトのフローを記述してみ ろよ、という感じ。要するにフローチャートを書くまでもないような処理 しか記述できませんし、フローを修正する時の手間は絶望的です。 PADはSPDをもっときれいにした感じ。ですから見やすいと思いますが、 書く手間は大変そう。SPDはPADより見た目は劣りますが、高速に書ける ので、常に厳しい納期で作業をしているソフト開発の現場に合っています。 HCPについてはフローチャート的な考え方が強すぎて、構造化自体がいま ひとつのように思います。 しかしこういうのはだいたい各メーカーともメンツを掛けて、各メーカー の頭のいい人たちが集まって開発しているので、関連ソフトハウスなどに かなり使用を強制した例もあるのではないかと思います。 しかし実用的なところでこの手の「新チャート」が使われているのを見た 例としては、私はSPD,PAD,HIPOのみ(HIPOは構造化チャートとは違うのだが)。 そのHIPOも単にその用紙を使用しているだけで、実際はダラダラと文章で 書かれているというしろものでした。PADは、とある巨大なシステムの記述 で見ました。2000ページほどの仕様書のソフトのロジックの大半がPADで 書いてありました。たぶんチャートの清書をする専用スタッフを雇えるほど の予算と時間の余裕のあるプロジェクトだったのでしょう。 (2000-07-11)
【オブジェクト指向】 さて、ダイクストラの構造化プログラミングの提言があったのと同じ年、 アラン・ケイが「ダイナブック構想」を出しているのですが、こちらは 当時先進的すぎて、注目した人は少なかったようです。 このダイナブック構想の中にはいろいろなものが含まれていた訳ですが それを支える概念のひとつが「オブジェクト指向」でした。 だいたい私見では「構造化プログラミング」で組めるソフトのステップ数 は2〜3万ステップ程度で、それを越えた大規模プログラミングでは、この 「オブジェクト指向」の指導原理がなければ、まともに動くソフトを組む のは不可能であると思います。 構造化プログラミングはソフトの部品化を要求したのですが、オブジェク ト指向では、その部品の意味や相互関係まで突っ込んだ要求をしています。 例えば「ドアのノブ」という部品はそれを手にとってドアを開けるために あります。オブジェクト指向以前のソフトでは、それを「硬いから、人を 殴るのにも使えるな」とか「表面が平らだから、うどんをのばすのにも 使えるな」といった感じの部品利用というのも許容されていましたしそれ を「うまいプログラム」だと自画自賛して積極的にやる職人的プログラマ ーというのも結構いました。 しかしそういう「目的外使用」はやめよう、というのがオブジェクト指向 のひとつの考え方。 もうひとつはこれらの部品に「親子関係」を導入したことです。それまで は直径30mmの歯車、直径22mmの歯車、直径5mmのネジ、直径4mmのネジ、と いったものが全て同格の「部品」として横一列であったのに対して、歯車 は歯車、ネジはネジとして、ひとつのグループに属するとみなし、ネジに 対して何か記述をしておいて、その記述がそのまま適用できるのなら、 わざわざ直径5mmのネジに関するその部分の記述は省略しようといったもの です。親子関係は多重になる場合もあります。 経理課の社員←総務部の社員←この支店の社員←この会社の社員 などといった多層構造で記述できるケースもあります。この親子関係の導入 により、多数の部品がきれいに組織化され、記述もかなり省略することが できて、プログラムのソースコードがものすごく見やすくなるのです。 (2000-07-12)
【イベント駆動】 ダイナブック思想の中でもうひとつ重要な概念の転換がありました。それが 「イベント駆動」という考え方です。 初期のコンピュータのソフトというのは、完全にプログラムの設計者の意図 通りに操作する必要があり、それ以外の操作方法というのは一切許されない ものでした。しかしダイナブックにおいては『操作方法は操作する人が決め る』というパラダイムの転換が起きています。 実際にマシンを操作する人が「こうしたい」と思った通りにソフトが反応す べきである、というのがイベント駆動の考え方です。ですから利用者がマウ スを動かせばカーソルもそれに合わせて動くべきだし、利用者が先頭の項目 から入力するのが嫌で、最後の項目から順に入れたいと思ったら、それでも ちゃんと動くようにしておくべきである。 基本的にMacintosh, Windows のプログラミングにおいては、このイベント 駆動の考え方を理解し、納得していないと、まともなソフトは組めません。 しかしときどき、旧来の考え方で「操作方法を強制する」Windowsのソフトと いうのも見かけます。だいたいにおいて「これならWindows用ではなくMSDOS 用で作ってもらった方が操作性がいい」と思うようなソフトばかりです。 この考え方に納得できないプログラマはWindowsやMacintoshのソフトを作る べきでないのです。はっきり言って迷惑です。 (2000-07-13)
【国民総プログラマ論】 これも1990年前後まで言われていた話なのですが、1980年代はオフィスの場 へのコンピュータの導入がひじょうに進んだ時代で、そのためのソフトも 多数作成されました。その中で「ソフト技術者が足りない！」という声があ がります。そして専門学校の情報処理コースなどもすごい人気になり、それ でも全然足りなくて「今のままソフトの需要が増えれば日本国民全員がプロ グラマーになっても追いつかないかも知れない」などとまで言われました。 この国民総プログラマ論を打ち砕いたのはご存じ「ダウンサイジング」です。 結局汎用機の需要がガタっと減って、それまで大型機でしかできなかったよ うなことがパソコンでできるようになる。すると専門の技術者にシステムの 設計をしてもらい、専門のプログラマにソフトを作ってもらわなくても結構 OFFICEとかFileMakerとかファラオとか、そんなソフトを使って現場の人が ちょちょいとマクロを組めば、十分実用に耐える。そんな時代になってしま いました。 そしてこれが重要なことなのですが、5000万円掛けて専門家に作ってもらっ た専用ソフトより、どう考えても2〜3万円で買ってこれるOFFICEなどの方が ずっと使いやすいしバグも少なくて、安心して使えたのです。 このダウンサイジングによって恐らく日本のソフトハウスの１／３が倒産し たと思います。ソフト技術者は巷にあふれ、生き残ったソフトハウスでも、 かなりの会社で厳しい賃金カットや残業手当の停止などが行われ、そもそも 劣悪な労働条件を、ある程度高水準の賃金ゆえに我慢してきた技術者たちの 堪忍袋の緒が切れます。かくして倒産しなかったソフトハウスでも、一般に 優秀な技術者から先に独立して「ＳＯＨＯ」の世界へと転じて行きました。 かくして現在は日本のソフトハウスは大きな資金力を持っていて優秀な技術 者をまだつなぎとめているごく一部の大手の会社と、技術力が貧弱で特殊な 用途のソフトのメンテや、大企業のアウトソーシングなどによるオペレーシ ョン・センター的な活動で生き延びている数多くの弱小ソフトハウスとに、 ほぼ色分けされてしまいました。 ではどうすれば。。。。それは次回に。 (2000-07-14)
【なるかソフト再生】 1990年代後半に富士通は「メディアシャトル」というシステムを運用してい ました。 これは健全なソフト作者育成・支援のため、多くの有料ソフトをまとめて ＣＤに収録し、いろんな雑誌におまけで付けて配ってもらって、体験版や デモ版を見て興味を持った人はセンターにアクセスして料金を払って「鍵」 をもらえばそのＣＤに収録されたソフトが利用できるようになるというもの でした。 このシステムは結局は挫折したようです。ひとつにはこのＣＤを付けてくれ る雑誌をあまり多数確保できなかったこと。ひとつにはフリーウェアを多数 収録したＣＤを添付した雑誌が多数販売されている中、有料ソフトばかりで 鍵が無いと実際には使えないソフトしか入っていないＣＤにあまり消費者が 興味を持ってくれなかったため、そのＣＤ自体を開封してくれなかったこと 多くの消費者は年間せいぜい２〜３本しかソフトを購入しない）。そして、 ソフトのサイズが年々巨大になってきて何百本ものソフトを収録しようとす ると１枚のＣＤでは済まなくなってしまったことなどがあるようです。 今電子取引が盛んになってきて、多くの企業が BTOC に興味を持っているの ですが、幾つかの企業は本格的に CTOC に乗りだそうとしています。ニフティ などはその先駆者でシェアウェア送金代行や、電子書籍のダウンロードサー ビスなどを早くから展開していますが、若干審査が厳しすぎるきらいもある ようです。結果的には皮肉にも現在 CTOC のメイン舞台になっているのは Yahoo! や ONSALE などのオークション。ここで自作のソフトを販売してい る人たちがけっこういるようです。 『恐らく』突然Netscapeが出てきたように、突然Linuxが出てきたように、 思いもしないところに全く新しいソフトが生まれる余地はまだまだあります。 そしてたったひとつのソフトで、現在全てがアメリカ中心で動いているソフト の世界が一夜にして覆される可能性もあります。 それが起きるのは日本かも知れないし、韓国かも知れないし、台湾かも知れ ないし、インドかも知れない。 しかしどこにも、誰にも、そう「あなたにも」それを起こせる可能性はある のです。 (2000-07-15)
【痛みを伴うＩＴ】 さて、ＩＴですが、これを本気で推進していった場合、かなりの「痛み」が 伴うことをあまり政治家は言っていません。そもそもその前に認識している のかも怪しいのですが。 ＩＴ革命は1960〜1970年代に進行したオートメーション導入による社会構造 改革に匹敵する大規模な地殻変動をもたらします。 ＩＴ導入によって間違いなく大量の失業者が出ますし、逆に人手不足の業種 も大量に出るでしょう。相当の労働争議が起きることは覚悟しなければなり ません。アメリカは既にそのような痛みを乗り越えて現在の情報産業の基盤 を作り上げつつあります。 そして重要なポイントは「ＩＴに国境は無い」ということです。 現に私は日本にいながらアメリカのシリコンバレーに物理的に置かれている サーバーマシンを毎日操作しています。インドが今世界のソフトセンターと して成長しつつありますが、恐らくインドのソフトハウスも世界中のマシン の操作を日々やっていることでしょう。 ですから日本のＩＴ化が遅れた場合、日本の全産業が消滅してしまう危険性 さえあります。（残るのは運送業と神社くらいか） 日本になくても、日本の消費者は一向に困らないのですから。 ここが国外で生産して日本に持ってくると運賃がかかるといった「物」の 経済との違いです。 そして逆に今から必死になって走り出したらまさに「パックス・ジャポニカ」 が到来する可能性もあります。それは韓国も台湾もインドも持っている 可能性ですが。 (2000-07-16)
【精神崩壊者続出のイベント駆動】 数日前ダイナブックがもたらしたプログラミング革命の中に「イベント駆動」 があるということを書いたのですが、実はこの思想革命はこれに挑んだプロ グラマたちの精神にかなりのダメージを与えました。 だいたいこの一番苦労した世代というのは1987〜1989年頃にWindowsやMacin toshのソフト作成に取り組んでいた人たちだと思うのですが、実際精神が 崩壊してしまって、プログラマやめてしまった人や、ひょっとしたら病院 行きになってしまった人たちもいたのではないかと思います。 私もまさに1988年に最初 Macintoshでプログラムを5〜6本書き、それから Windowsで100本くらい書いたように思うのですが、ほんとに発狂寸前の状態 でした。私もそれまで15年間プログラムをやってきて、自分のプログラムの 能力に相当の自信を持っていたわけですが、この時は今まで自分がやってき た全てのことを完全否定されたような気がしたのでした。 私の場合先にMacintoshをやったのが良かったように思います。Inside Mac intoshを読んだことにより、頭の中にひとつのロードマップが描かれました。 これ無しでいきなりWindowsに取り組んだ人たちはマジでやばかったようです。 このころ苦労した人たちと当時は全然交流がなかったのですが4〜5年ほど たった時に偶然にも別々のチャンネルで体験者に３人ほど遭遇しまして、 あれは本当やばかったという感想をもらされました。 逆に言うと当時プログラムのプの字も知らない人にこのイベント駆動のプロ グラミングを教えるとかえって障害はなかったようです。すんなりと覚えて くれました。しかしこれから入った人は逆に従来型のソフトは組めないかも 知れません。 (2000-07-17)
Dropped down from digital episode.