【雲をつかむ話】クラウドコンピューティングの実際: 2009年10月アーカイブ

さて、私が就職した先は社員300名弱のソフトハウス。ソフトハウスという名のプログラマー派遣会社というのが実態だったのだが、気まぐれではじめたマイコンプログラムの受託開発のために新聞に出した募集広告に私はひっかかったわけだ。面接に行って、Z80のアセンブラがわかると言った瞬間にあっさりと内定を出されて唖然としたのだが、その理由は入社してみてわかった。開発チームの人数は数名いるものの、まともにZ80アセンブラでプログラムを書けるのは、私を含めて3名だけ、完全に仕事がオーバーフローして、危機的状況になっていると知ったのは入社当日、しかも終電車が出たあとだった。つまりは、入社当日に徹夜仕事になったわけだ。信じられないような本当の話である。

なんで、こんな話をするかと言えば、そもそもコンピュータのプログラミングという作業は、個人の技量や経験に依存しやすい。そして、ある程度の規模のプログラムまでは、優秀なプログラマーの職人芸にまかせたほうが、生産性が上がる・・・ように見える。しかし、規模が大きくなると、それだけの「職人」を調達するのが困難になる。また、「職人芸」で作られたプログラムは効率がいい反面、保守性は悪い。まして、作ったプログラマー以外がメンテナンスすることは難しい。よく、古いシステムのバグを直してもらおうとしたら、作ったプログラマーが会社を辞めていたため、誰も直せないといった事態が発生している。だから、当時でも大規模な開発が多かったメインフレームの世界では、システム･エンジニア（ＳＥ)とプログラマーという階層関係や、開発方法の標準化による保守性の向上、設計文書などドキュメンテーションの重視などが一般的に行われていた。設計者とプログラマーを分離することで、優秀な技術者のノウハウを共有し、なおかつその人間がいなくなっても保守ができるように、というわけだ。ＳＥは花形、プログラマーは下働きという悪しき構造が出来上がっていた。やがて、この二つの階層は業界の下請け構造によって分離され、プログラムの基本もわからないＳＥや設計どおりに書くことしか知らない思考停止型プログラマー（コーダーとも言われた）を量産した。この形が日本のソフトウエア業界をダメにした元凶だと私は思うのだが、それは日本固有の話だったのかもしれない。本来、分業化や標準化、文書化は生産性や保守性を向上させるべきものだが、それをあまりに杓子定規に適用しすぎたことで、結果的に業界の階層構造を作ってしまったり、下層にいるプログラマーたちを思考停止に追い込んだというのが当時からの日本の状況ではなかったのかと思う。

そんな雰囲気の中、私がいたチームは異質だった。上司は標準化、ドキュメント重視を念仏のように唱えていたが、我々プログラマーはそれどころではない。徹夜続きで死にかけている人間たちには、それこそ馬の耳に念仏である。どんなことをしてでも、納期までに、しかも何度もお客とかけあって引き伸ばした納期までに仕上げなければならないとなれば綺麗ごとなど言っていられるわけがない。そんなわけで、とにかくフローチャートもまともに描かずに、頭の中で書いた流れに基づいて直接、プログラムをおこしていった。もちろん、そんなプログラムが一発で動くはずがない。しかも、アセンブラとくれば、もう作った本人以外はだれも触ることができないような代物が出来上がってしまう。

私が作っていたのは、工場内の搬送システムを制御するプログラム。ある意味で、信頼性が人命にかかわりかねないプログラムだ。もちろん、ハードウエアはフェイルセーフに出来ているので、万一プログラムが暴走しても大事故になることは、まずないのだが、それでも、テスト中は愉快なことがいっぱい起きた。コーナー手前で減速しなければならない搬送台車が減速せず、ドリフトしながらコーナーを飛び出すといったことだ。床面には誘導無線のワイヤが埋めてあって、これをはずれると台車は停止するようになっているので、大事には至らないのだが、導入後にこんなことが起きると危険極まりない話だ。

開発環境も劣悪だ。そもそも、こんなプログラムをシミュレーションもなしに、いきなり実機に入れても動くはずがないのだが、手元には開発用の8ビットマイコンが1台とアセンブラとＲＯＭライター（機械語プログラムを不揮発性メモリに書き込む装置）があるだけ。単純に文法エラーが取れただけのプログラムを実地でデバッグするわけだから、大変だ。おまけに、テスト現場には開発マシンはない。それでどうやってデバッグするかといえば、プログラムリストでバグを見つけ、その部分に手作業でパッチをあてる。ＲＯＭの中身をＲＯＭライターに吸い上げ、ＲＯＭライター上で修正したい部分の機械語命令をいくつかつぶしてそこに１６進コードでジャンプ命令の機械語を入れて、ＲＯＭの後ろ側に残った空き領域に飛ばす。そしてそこに修正プログラムを、これも機械語で打ち込み、またジャンプ命令で元の場所に戻すといった具合だ。ここで、趣味で機械語コードを暗記していたことが役立ったというのは、なんとも皮肉な話である。テストサイトに何日も泊まり込んで、ようやく出来上がったプログラムは、パッチの山。もう、最初のソースコードは跡形もない。リストに書き込んだ修正は何度も上書きされ、もはや、元のソースコードにどんな修正を加えたかもわからなくなってしまっていた。これでは、ソースコードが納品できないので、納品前に逆アセンブラを使って、ソースコードに戻し、それにコメントを入れて納品するといったことが、日常茶飯事のように行われていた。

こういう個人作業を続けていると、そのうちプログラマーの何人かは、以前に作ったプログラムを再利用するようになる。そして、それらは、再利用しやすいように整理されて、その人のノウハウがつまったプライベートなライブラリが出来上がる。こうなるとその人の生産性はどんどん向上する。だが、残念ながらこうしたライブラリが共有されることはあまりなかった。なぜなら、人のライブラリは、その人でなければ使えない代物だったからだ。こうして、プログラマーの生産性はその人の資質によって、さらに大きくばらつくことになる。結果として、出来るプログラマーにどんどん仕事が集中するという現象が発生してしまうわけだ。こうなると、最初は効率よく作業できることに喜びを感じていたプログラマーもマインドがどんどん下がってくる。自分のペースをコントロールして、納期ぎりぎりを目指すようになってしまう。こうなると、その人自身の成長も止まってしまう。優秀なプログラマーをどんどん潰していく環境が出来上がってしまうわけだ。この経験は、自分の中では、開発のありかたを考えていく上で大きな教訓になっている。

（続く）

１章　ＩＴという大河の源流をたどる

これから書くお話は、私自身のＩＴ人生における経験がベースとなっている。私が初めてコンピュータというもののしくみを知ったのが中学時代。某国営放送教育ＴＶのフォートラン講座なるものを見たときだった。コンピュータが、こんな言葉を理解して動いてくれるのだと驚いたことを覚えている。コボルに至っては、まさに英語そのもののように思えて、改めて驚いたものだ。

そんな大昔の話をなぜするのかといえば、クラウドがどうして生まれたかを本当に理解するためには、ＩＴという大河の源流からの流れをある程度知っておいたほうがいいと思うからである。特に、若い人たちには、かえって新鮮かもしれない。ご同輩の方々は適当に読み飛ばしていただけるとうれしい。私の過去の経験を通して、最後に導き出される結論の理由を考えてほしいのだ。

さて、実際に私がプログラミングというものに触れたのは、７０年代前半の高校時代。といっても、コンピュータというよりは、今のプログラミング電卓、しかもコンビニのＰＯＳ端末よりもうひとまわり大きいような代物だ。もちろん性能など論ずるにも値しないようなものだし、プログラミングも高級言語ではなく、数字と記号を組み合わせたコマンドを並べていくようなもので、レジスタが実数演算可能なことや、印刷や磁気カードへの入出力命令を持っている以外は、アセンブラとそんなにたいしてかわらないレベル。当時、ちょうど教育課程が、私たちの年代の少し下からかわって、数学に2進演算やアルゴリズムなどの概念が入ってきたころだったので、文部省（今は文科省）が高校への「電卓」導入をすすめていたころである。数学クラブに顔を出して、プログラムを作って遊んでいたのを覚えている。中でもバイオリズム計算は、文化祭で出したら女子の長い列ができた。今だから言うが、自分だけではなく好きな娘のバイオリズムをひそかに計算したりしていたものだ。

私が大学に進んだころには、いわゆる「マイコン」が一般でも手に入るようになる。Ｎ社が出した基盤丸出しのマイコン検証キットＴＫ８０は人気で、卒研のお隣の研究室で遊んでいるのを見に行った。１６進で機械語を直接打ち込んでプログラミングするのだが、オプションの基盤を１枚加えるとＢＡＳＩＣが使えるようになる。高級言語でプログラムできる環境が個人で手に入るのかと驚いたと同時にわくわくしたものだ。

当時、卒研の実験データは、同期のお金持ちなオーナー社長の息子が持ち込んだテキサス・インスツルメンツ（ＴＩ）社製の３０万円ほどするプログラム電卓を使って処理していた。なぜかと言えば、私が通っていた大学は（当時は・・の話だが）貧乏大学で、理工学部にはパナファコム製のミニコン（死語）が１台あるだけ、ややこしい計算はご近所の某国立大学の計算センターを使わせてもらっていた。当然、そんな貧弱なミニコンでも学部の学生は直接使えない。当時は、紙のパンチカードに１枚１行ずつプログラムを打ち込み、束にして事務室に持っていくと、空いた時間で処理して結果を返してくれる。しかし、ＦＯＲＴＲＡＮで、しかも複雑な数値計算をするプログラムをそんなに簡単に書けるはずがない。まず、文法エラーの山が帰ってくるので、それを修正してカードを入れ替えて再度提出する。そんなことを数回繰り返してやっと何がしかの結果が返ってくるのだが、まだ単に文法が正しいというだけで、アルゴリズムは別物。間違っていても結果が出ればまだいいのだが、不正処理で落ちてしまうことも多く、これじゃ、電卓でやったほうがマシ・・と半ばあきらめていた。ところが、それを見ていた院生が、自分のＪＯＢカードを貸してくれた。ちなみに、ＪＯＢカードは、プログラムやデータのカードの先頭に置くカードで、これがないとコンピュータを使えない、いわばＩＤカードのようなもの。当時は、セキュリティのセの字もない管理状況。これを借りて、堂々と計算機室に行って、院生面をして使っていたのだが、ある日、悲惨な事件が発生した。

ようやく文法エラーが取れたプログラムを走らせたところが、結果を数行打ち出したあと、わけのわからない数字列をがんがん打ち出し始めた。あっという間にラインプリンターの用紙がひと箱なくなってしまった。いわゆる「ダンプ」である。プログラムが暴走して強制終了させられたときに出るアレだ。今のＯＳなら、ＨＤＤ上に吐き出されるのだが、こいつはプリンタに吐き出してしまう。いくらメモリが少ないとはいえ、全部ダンプされたらたまったもんじゃない。とりあえずアボートして、紙の束を研究室に持ち帰ったのだが・・・、使った紙の枚数をノートに書いてくるのを忘れた。シングルタスクのミニコンなので、自動でカウントなどできないから、ノートで課金管理していたのだけど、消費枚数と記載枚数が大幅に狂ったため、さすがの事務室も気がついたようだ。コンソール（タイプライターだが・・）の記録でＪＯＢカードから、うちの院生を割り出した。悪いことに、その院生氏、その年度の利用更新をしていなかったため、使ったカードは前年度のもの・・・。orz である。年度のチェックすらシステムには入っていなかったわけだ。その院生氏、事務室からの呼び出しに悪びれる様子もなく、私に「君が使ったのだから、君が言ってきてくれ」とのたもうた。しかたがないので、恐る恐る事務室に行き、たっぷり油をしぼられて帰ってきたというわけだ。これは、なかなか忘れることができない思い出である。

大学を出てから、しばらくの間、いわゆるプータロー状態で、学生時代からのバイト先である舞台音響・照明の会社で音響（ＰＡ）の仕事のバイトをしながら食いつないでいたのだが、そのころに、まだ高価だったＳ社のマイコン（当時はまだＰＣと呼ばれる前だったのだが）を購入、よなよなプログラミングにはまり、ＢＡＳＩＣでは飽き足らず、ＰＡＳＣＡＬ、そして最後には、当時主流だったザイログ社の８ビットＣＰＵ、Ｚ８０のアセンブラを使って、モニタプログラムの改造などをはじめ、機械語コードもほとんど暗記してしまった。Ｚ８０は、たかだか２００個あまりの命令しか持たず、しかも同種の命令はパターンがあって、覚えやすかった。

これが高じて、やがてソフトウエア開発会社に就職することになる。さすがに、プータロー生活に不安を感じ始めたからだが、そこから地獄の日々がはじまる。

（続く）

雲、それは不思議な存在だ。その形も色もさまざま、一面空を覆うかとおもえば、青空にポツンとひとつだけ漂ったりもする。ちょっと科学をかじっていれば、それが水や氷の粒であることくらい知っているはずだ。もうひとつ言えば、雲ができるためには、水蒸気が水滴になるための核がいる。しかし、核があっても、空気の流れがなければ雲はできないだろう。雲は空気の流れのよどみや、境目、空気のかわり目に生まれる。それは、その場所で空気が変化していることを示している。

飛行機に乗って、雲をかすめると飛行機が揺れるのは、雲のせいではなく気流が乱れているからで、雲はその副産物なのだ。いい方を変えれば、雲はそこで何か変化が起きていることを示す空の標識でもある。

話は飛ぶのだが、私は飛行機が大好きだ。飛行機に乗って窓からの景色を見ていると、飽きることがない。だから、必ず窓側席に座る。それがたとえ、国際線の長時間フライトであってもである。飽きない理由のひとつが雲だ。雲はひとつとして同じ形がない。人間の顔と同じで分類はできても、まったく同じものができる確率は極めて低い、というかゼロに限りなく近い。

雨の日に飛行機に乗るのもまた面白い。一面黒雲に覆われて、大粒の雨が降っている飛行場を離陸すると、意外なほどすぐに雲の上に出てしまうことも多い。雨を降らせる雲の多くは、積乱雲を除けば低層の雲だ。だから、飛行機がエンジン推力を少し絞ってフラップをたたむころには、雲の上に出てしまう。

でも、前線が通過しているような時は、そう簡単には雲から抜けられない。雲は何層にも重なっていて、ひとつ抜けても、まだ上に厚い雲が覆いかぶさっている。青空を見るには、３層くらいの雲を抜けなければいけないこともある。ときには巡航高度近くまで雲がたちこめることもある。国内線では７０００ｍくらいの高度を飛ぶ路線もあるが、結局、最後まで青空を見られないことだってあるのだ。国際線でも時々、４００００フィート以上を飛びながら、雲すれすれの飛行・・・ということもある。

飛行機から見て一番壮観なのは、雲の谷間を飛行している時だ。特に、夕陽や朝日の中では、思わず見とれてしまう。多少揺れようが、かまわない。落ちさえしなければ・・・。

さて、季節は秋。秋の雲も面白い。秋晴れの空にぽつんと浮かんだ雲。しばらくの間にどんどん形をかえ、やがて消えていく。ふと、昔、マイコンで流行ったライフゲームを思い出した。周囲に雲がなければ、やがて雲は消える。雲が多すぎれば、やがて雨となり、やはり消える。雲が雲であるためには、３次元的に見て適度な広がりが必要だ。もちろん雲は、大気の変化の仮の姿だから、これは見かけの現象であり、本質ではないだろう。しかし類似性はあるし、それはその本質を知る手掛かりにもなる。だが、雲の本質を知るには、その様々な姿に騙されないようにしなければいけない。それは、雲の中にある何かの、ひとつの切り口に過ぎないのだから。

こんなことを考えていると、なんとなく雲という物体は、様々な意味で示唆に富んでいるように思えてくる。そんな様々な切り口を重ね合わせてみると、なにか本質らしきものが見えてきそうな気がするのだ。

さて、これからの話は大気現象としての雲の話ではない。「雲」という名のついた、やはりつかみどころのない仮想空間における現象の話である。しかし、奇妙なことに、それはここで書いた雲とよく似た性質を持っているように思える。この仮想世界の雲をこれから、いろんな切り口で見ていこうと思っているのだが、本物の雲が暗示するものとの類似性を考えてみるのも、ちょっと哲学的で面白いかもしれない。

さておき、そろそろ本題に入ろう。なお、これから書くことは、私の個人的な思い込みだ。でも、なにかしらの本質に近づいていくものだと自分では思っている。そして、これは使い手の目線から見たものでもある。なぜ、「雲」は生まれたのか。それはどこから来て、どこへ行くのか。それは、地上に何をもたらすのか・・・。敢えて独断と偏見をもって書くつもりだ。

（続く）