JCO の話じゃないですよ(笑)。

この業界にいると、 ストレスと無縁という方は殆ど皆無でしょう。
もちろん 「 仕事をしていると辛いことは忘れられるんだ!! 」 なんて奇特な方もおられると思いますが、 大多数の方はきついスケジュールを詰め込まれるとだんだんストレスがたまってくると思うんですよね。
きっと皆さんそれなりのストレス解消法を持っておられると思います。

ところが一つ大きな問題があって、 一番ストレスが溜まって辛い時期にはストレス発散のための時間もないんですな。
残業代であほほど儲かるんだが、 前から欲しかったものや目に付いたものを衝動買いするとか、 一発大博打を打ってみるとか、 吐くほど飲むとか、 朝まで歌うとか、 そういうことって出来ないんですよね。

で、 どうしてもささやかな抵抗になってしまうものです。
特に無趣味なオイラなんか、 「 突然部屋の掃除を始める 」 とか 「 漫画を買い込んできて読む 」 「 ただひたすらだらだらする 」 ぐらいなんですよね。
結局大してストレス解消にはならないんですよね。

この辺は何か趣味を持っている人って断然強いですよね。
と、 思っているうちになんとようやく自動車免許が取れました。
さっき近所のホームセンターに 「 はじめてのおつかい 」 に行ってきたんですが、 もうすでにはまっちゃいそうです。
そのうち週末は真夜中のハイウェイをカッ飛ばしてたりして。

なんにせよ、 忙しさとストレスとプレッシャーに負けないためにも、 爆発防止対策はきちんと取っておきましょう。

お前なんか事故って死にやがれって? 死んだらバカも治るかな(爆)。

どっかの会社がクロになったそうですが、 そういうのは他の方がもっと詳しくお伝え下さると思いますのでいつもどおり(笑)。

先週書いた端から土日にドライブと部屋の掃除をしてしまいました。 すげーバカちっくだ(爆)。
車に乗れるようになると突然車に興味がわき始めて、 新聞の折り込み広告を見たり、 ホームページ見たりするんですが、 だからって自分の車を買おうとは思わないですね。
親父の車があってそれで十分走れるんだからそれでいいやって思ってしまう。
いや、 もちろんいい車欲しいですけどね。

パソコンも同じで、 それでメシ食ってるくせにあまりこだわらない。
クロックはいくつ以上だとか、メモリは何 MB とか、 グラフィックカードがどうとかあんまり考えなくて、 カタログに載ってるやつをほいと買いますね。
自作しようなんて面倒臭くて考えたこともないです(笑)。
自分が書いたプログラムが動いてくれれば十分。
あとは普通にワープロとか使えてネットサーフィンできればいいやって… それってもしかして普通のユーザ以下!?

古株のプログラマだと当然アセンブラから入っていて、 マシン依存のコードが当たり前で、 「 このチップじゃないと動かない 」 とか、 「 このチップ独自の、マニュアルにも載ってない機能を使うような 」 トリッキーな技がかっこよかった。
そういう、 ハッカーちっくなのに憧れた時代もあったんですが、 実際仕事にしてみると、 「 んなことやってられっかぁ!! 」 と星一徹顔負けのちゃぶ台返しをしそうになります。
オイラの場合、 初めて触れた言語が C ( しかも ANSI 制定後 ) 。 最初から移植容易性を考えられた言語でした。
それでも OS まわりを担当していると、 やれ Windows だ、 UNIX だ、 Mac だとプラットフォームごとに対応をしなければならないし、 Windows にはあって UNIX にはない機能とかもあって、 マルチプラットフォーム対応した製品では、 無理矢理似たような機能を実装したりしなければならなくなる。

そういう煩わしさを思うと Java が恋しくなるんですね。
どこまでやれるのか見守っていきたいと思いますが、 オイラにとってあれはほぼ理想の世界ですね。
ハードウェアの違いも OS の違いも隠蔽し、 一度書いたコードがどのマシンでも動く…。
夢の世界まで、あともう少しです。

それまでにプログラマ辞めやがれって? 賢明かも(笑)。

オライリーの 「 Open Source T シャツ 」 が当たりました。
すごく嬉しかったりして。

なんのこっちゃと思われるので説明しておくと、 このページを見に来られる方ならおそらくご存知のオライリーという出版社 ( 表紙に動物の絵が描いてある主に UNIX 関連の本を出している出版社、 といえば分かるでしょうか? ) が、 オープンソース関連の本を出版した記念にプレゼントとして作ったもので、 表には大きく " Open Source " と書いてあって、 " O " の字からはオライリーのマスコット、 メガネザルが覗いている。
" O " の下にはオープンソースによって名を馳せたソフトウェアの名前、 LINUX、 PERL、 TCL/TK、 PYTHON、 APACHE、 SENDMAIL、 DNS & BIND、 がプリントされている。

表のデザインはホームページで見ることが出来たので、 現物を見て改めてカッコイイなぁと思ったのですが、 ちょっと意外だったのが裏のデザインでした。
こちらはごくシンプルにメッセージがプリントしてあるだけなんですが、 それがこんなフレーズなんです。

" It isn't who has the most
money or the most clout
who wins; it's who has
the best code. "

誰かの有名なセリフなんですかね? 勉強不足なもので知りませんが…。
オープンソース陣営にしてみれば、 Linux をはじめとするオープンソースソフトウェアの躍進を 「 アイツに勝った! 」 と捉えて息巻いているのかも知れないのですが、 ちょっとこれは意外でした。

英語の " win " という単語の正確な意味を知らないので頓珍漢なことを言っているのかも知れないのですが、 そもそもオープンソースソフトウェアを書いた人たちって、 「 誰かに勝とう 」 と思って書いてたんでしょうか。
確かに、 「 素晴らしいソフトを作ってプログラマとしての栄誉を勝ち得たい 」 という気持ちはどんなプログラマにもあるんだと思うのですが、 それは " win " とはちょっと違うような気がしたのです。

それをきっかけにふと自分を省みてみると、 自分は何のためにプログラミングをしているんだろうと考えこんでしまいました。

「 TV チャンピオン 」 という娯楽番組があります。
何かに長けた人を何人か呼んできてチャンピオンを決める番組なのですが、 最後に司会者がチャンピオンにこんな質問をします。
「 あなたにとって○○とは? 」

自分がチャンピオンになることは万が一にもないけれど、 もしこの質問が自分に投げかけられたらどう答えたものだろう。
「 あなたにとってプログラミングとは? 」

サンデープログラマでない以上は成果物を金に替えている。
だからといって金を貰うのが第一の目的でないことは確かだ。
いや、 もちろん稼がなきゃ生きていけないけど、 金が欲しいだけならもっと割のいい仕事を選べばいいわけでしょ。

売り物のソフトを書くのだから、 ユーザに満足してもらわなければ金は貰えない。
もちろんユーザから 「 これは素晴らしいよ! 」 と言われればとても嬉しい。
プログラミングをしている非常に大きな原動力である。
でもそれだけではない。

新しい技術に挑戦できるというのも大きな魅力だ。
小学生の頃からいろんな学問に手をつけては飽きて別の分野に引っ越すということを繰り返してきたオイラとしては、 研究対象がどんどん提供されていつまでも飽きない、 というのは大きな魅力だ。
マンネリになって飽きてしまって、 ただ金を貰うためだけにコードを書くようになったらプログラマを辞めよう、 といつも思っているのだけれど、 全く飽きないほど次々と新技術が登場して夢中にさせてくれるのだ。
それも、 でもすべてではない。

モノを作るわけだから、 それなりに苦労して、 ない知恵を絞って工夫して作り上げるわけです。
だから出来上がった時は舞い上がらんばかりに嬉しい。
まぁ、 でもこれはどんな仕事でもそうですよね。

こんなコラムをだらだら書いているぐらいだから子供の頃から文章を書くことが大好きで、 モノ書きになるのが夢だったりするのですが、 プログラミングというのは案外文章を書くことにも似ているんですね。
他人に 「 こうしてちょうだい 」 という手順書のようなものを理路整然と書ける人、 論理的・美的センスのある人というのは美しいコードを書いてくれます。
モノを書く人間の一人として、 美しいコードを書きたいといつも思っているし、 それなりに勉強もしているつもり。
ソースに Author を記述しておいたりしますよね、 例えば自分が書いたソースに " Coded by Ada72 " とか書いておくわけです。
それを何年かして、 オイラがいなくなった後とかに誰かが見て、 「 なんてエレガントなコードなんだ! 誰が書いたのかなぁ… Ada72? 」
「 あっこれも! これも! … Ada72 さんって凄い人だったんだ!! 」 なんてことになったらプログラマとして最高の栄誉ですね。 多分そんなことにはならないけど。
とある学者の言葉に、 こういうのがあるそうです。 うろ覚えですが大体こんな感じだったと思います。
「 私の名は歴史の中に埋もれても、 私の生み出したものは人々の記憶の中に残るだろう 」

さてそろそろ司会者がマイクをオイラに向けようとしているので、 結論を出さなければいけません。
「 あなたにとってプログラミングとは? 」
もがいて、 苦しんで、 ふと見上げると吸い込まれそうな秋の空。 空の上にはどんな世界が広がっているのだろう? それを見にいくための旅。
「 私はかもめ 」 ( テレシコワ ; 女性初の宇宙飛行士 ) と言えたら本懐でしょう。 そんな凄いプログラマにはなれないけれど。

ロケット爆発して死ねって? バグが減るかもね。

ロケットが爆発する話を書いたら本当に H2 ロケットが爆発してしまいました。
ありゃ〜。 これから宇宙ビジネスに参入しようと準備を進めていた会社とかはどうなるんでしょうかね。

おそらく 21 世紀の花形産業は宇宙と遺伝子でしょう。
もう情報科学は産業として定着して、 これまでのような画期的な発展はなくなる、 というか生活の中に埋め込まれていくでしょうね。

先日から、 Denis Shasha / Cathy Lazare の 「 コンピュータの時代を開いた天才たち ( 原題は " Out of Their Minds " ) 」 を読んでいるのですが、 いやぁ、 本当に情報科学という分野は凄い。
工学というのは純粋科学であることは少なく、 数学と物理とか、 物理と化学とか、 複数のジャンルにまたがっていることが多いのですが、 情報科学はもうネタが尽きたというか、 逆に尽きないというか。
もし神様がいるのなら、 数学と言語学を引き合わせたのは彼でしょう。

この本の巻末には情報科学に関する年表があるのですが、 この年表の始まりはなんと 1673 年です。
あんまり書くと著作権に抵触するのでやめますが、 1821 年にはおそらく初のコンピュータと呼べるものが チャールズ・バベイジによって開発されています。
さらに凄いのはバベイジを助けた エイダ・オーギュスタ・ラブレイスが、 まだ存在もしない計算機のプログラムを書き、 ループ、サブルーチンなど、 今日のプログラミングには当たり前の概念を発明したこと。
動く機械があって発明したのならなるほどと思うんですけど、 頭で考えてループやサブルーチンが必要だと考えたというのは驚きの一語に尽きます。
彼女はこの功績により人類初のプログラマとして歴史にその名を刻み、 さらに言語の名前にまで採用されています。
余談ですがオイラのハンドルネーム " Ada72 " は彼女の名前から頂いたものです。 いやぁ、 我ながら畏れ多い名前を…。

この後情報科学史上に燦然と輝く研究が続くのですが、 そういった研究って、 ダイクストラなどによって編み出された基本的なアルゴリズムや、 チューリングマシンなんかにしても実際にまともに動くものがあってなされた研究ではないんですよね。
そこらへんは、 逆に動くものがなかったがゆえに自由なアイデアを盛り込めたとも取れるし、 微妙なのですが、 どちらにしても動くものがなかった時代にこれだけのものを考え出せるなんて、 天才的な頭脳だけがなしうる偉業であることに間違いはありません。

面白いのは、 情報科学が数学から出発して途中で言語学と合流したことです。
ノーム・チョムスキーが文脈自由文法を考え出さなかったら、 そしてそこからバッカス=ナウア記法が生まれなかったら、 ここまでの発展は望めなかったでしょう。

ちゃんとまともに動くコンピュータと、 プログラミング言語とコンパイラ・リンカが登場してからの情報科学の進歩はここでは語り尽くせないほどの躍進ぶりでした。
そして、 工学の宿命として、 科学はビジネスへとシフトしていくことになるのです。

オイラが生まれて初めてパソコンに触ったころ、 まだパソコンは ( もちろんビジネスに使われていたものの ) ビジネスの道具というよりオタクのオモチャという側面の強いものでした。
そして、 オブジェクト指向など、 今日のプログラミングパラダイムを支える概念がようやく実用に達してきた頃でもあり、 情報科学は科学とビジネスの間を行き来しているような観を呈していました。
当時すでに商用ソフトも多く出ていましたが、 フリーソフトも多く、 それらはコードも公開されており、 みんなでよってたかってアルゴリズムを磨き上げていった時代でした。

やがて情報科学が本当にビジネスになることが分かると、 後はここで書く必要のないくらい様々な出来事が起こりました。

別に情報科学が純粋に研究だった頃や、 コンピュータがオタクのオモチャだった頃を懐かしむわけではありません。
情報科学は工学として、 健全な道をたどっているのですから。

ただ、 ビジネスには市場原理が働きます。
どんなに技術的に優れているものでも、 販売戦略に失敗すれば歴史の影に埋もれてしまう。
それが悲しい。
カネと政治にまみれたその姿を見るのが辛い。
キラキラと輝いていた少年のような面影は、 確かに失われつつあるだろう。

これからの情報科学に一番期待していることは、 オブジェクト指向を超えた新しいプログラミングパラダイムですね。
それはもうすでに 「 言語 」 ではないかもしれない。
そして、 ユーザが好きなようにタスクを定義できて、 オイラのような糞プログラマは全員クビになるかもしれない。
そんな時代が来ることを夢見つつ、 情報科学の発展を祈ります。

元文学部出身のためか、 言語に対しひときわ思い入れが強いので、 このコラムの最後を、 この言葉で締めくくりたいと思います。

言語は考え方を形造り、 考えられるものを決定する。 - Benjamin Whorf ( 言語学者 )

情報科学の歴史は、 一面をたどれば言語の歴史でもあったのです。
新しい言語が出てきて、 それによってこれまで作れなかったプログラムが作れるようになった、 そんな挑戦の歴史。
我々は今まさに、 歴史の誕生に立ち会っているのです。
データ構造とアルゴリズムについては、 またの機会に委ねましょう。

糞プログラマのくせに Ada72 とは生意気なって? それは認める(核爆)。

最近のソフトウェアの傾向として、 とにかく多機能を盛り込もうとして肥大化するという現象を指摘することができます。
でも、 DOSとUNIXからこの世界に入ったオイラはどうにもこれが馴染まない。
まぁ、 DOSでも最後の方はメモリの制約も一見なくなったかのように見えたため、 お化けソフトもいっぱいあったし、 UNIXだってMotifやXのインターフェイスのあるやつはなんでもかんでもやってくれるものが結構多かったですけれどね。

でも、 シンプルなユーティリティコマンドがたくさんあって、 それをパイプやリダイレクションで繋いだり、 スクリプトをちょこっと書いて複雑なことが出来ることを知った時はかなり感動したものです。
しかし、 ユーザはその手間さえも厭うものです。
ソフトウェアは、 結果として肥大化という道を辿らざるを得なかったわけですが、 やがて我々ははたと気づくわけです。
隣の人と共有できるものがたくさんあるということに。

例えばあるソフトハウスAが作ったアプリケーションaは画像を読み込んで表示する機能があるとします。
別のソフトハウスBが作ったアプリケーションbは画像を読み込んで表示し、 イフェクトをかける機能があるとします。
こういう場合、 AもBも画像をファイルから読み込むルーチンなどのAPIを自前で用意する必要があるわけで、 ホントはお互い共通ルーチンにできたらなぁなんて思っていたんじゃないでしょうか。

やがて、 ライブラリが公開されたり、 dllやシェアドオブジェクトが配布されたりして、 共有することそのものは容易になってきました。
最近ではCOMだのActiveXだのなんだか訳が分からなくなりつつありますけれど。
結局それもアプリケーションを肥大化させてしまうことに変わりはないんですよね。

ちょこっとした絵が描ければいいだけなのに、 というときにPowerPointを立ち上げた経験のある方ってどのぐらいいらっしゃいます?
本当はあの程度の描画機能だったらもっと軽いソフトでいいはずなんですよね。

例えば軽い描画ソフトがあって、 そのソフトが吐いたデータを読み込んで別の処理をするソフトとか、 その画像を取り込んだ文書を作成するソフトがあればそれで事足りるのでは、 と思うのはオイラだけなんでしょうか?
Wordで絵を描けるようにするぐらいなら、 Wordそのものにお絵描き機能を実装するより、 軽いお絵描きツールを別に用意して、 Word文書に貼り付けられるようにするだけの方がエレガントだと思うのはオイラだけなんでしょうか?
Wordから直に編集をかけられるのって、 便利かもしれませんが元データ勝手にいじられちゃ困る場合はかえって不便な気がするんですが。
昔から 「 大は小を兼ねる 」 と言いますが、 この場合にそれは成り立たないと思いますね。
確かにPowerPointでも絵は描けるけれど、 不必要な機能のために遅くて重いのはユーザの要望を満たしているとは言えない。
我々の使命は 「 必要な機能をシンプルに提供すること 」 だと思うのです。

その意味ではオイラはLaTEX、HTML、XMLといった一連のSGML系のアプローチの方が好きですね。
ただ、 「 メジャーなデータからサポートされていく 」 という意味でオープンなものが標準データとして採用されやすいですから、 どこかの会社の目論見とは外れます。
どちらのアイデアが最終的に市場を席巻するのかは、 終わってみなければ分からないのですが。

歴史は時として残酷である。
正しいものが勝つのではなく、 勝ったものが正しいのだ。
何が勝ち、 正となるのか。 歴史の誕生に、 立ち会うのも一興だ。

お前なんか立ち会う資格ないって? どうせ糞プログラマだしね。

最近アクセスカウンタの伸びが著しいと思っていたら、 社内からのアクセスが案外多いそうです。
そこのアナタ! 時間中にくだらないホームページを見ないように!!
会社の人から 「 Ada72さんってもしかしてプログラミング以外に趣味ないの? 」 「 休みの日は何してるの? まさかプログラミングとかじゃないでしょうね 」 とか聞かれてしまいました(笑)。
こういうくだらない文章を書くのが趣味で、 たまたまプログラミングをテーマに選んだだけで、 休みの日までプログラミングしてたりはしませんよ。
あっ、 でもこの前年賀状の宛名ラベル作るヤツ作ったな… ( 墓穴 ) 。

高校時代の数学の先生が、 とびきり変わった人でした。
オイラが勉強した頃の高校の数学というのは、 「 ある公式を証明せよ 」 みたいな問題の連続で、 古典数学をなぞっていく形式でした。
普通の先生だと型通りに証明を進めてハイおしまい、 って感じだと思うんですが、 この先生は証明が終わると導出された公式を示し、 心の底から嬉しそうな顔をしてこう言うのです。
「 美の鑑賞の時間です 」
オイラに数学の美しさを教えてくれたのはこの先生だった。
数学は本当に美しい。
文学部に行かなければ理学部数学科に行ってしまっていただろうと思うくらいだ。

それから何年かが過ぎて、 再びオイラの心を躍らせたものがある。
アルゴリズムだ。
「 アルゴリズムとデータ構造 」 の授業中に、 ヒープソートのロジックが理解できた瞬間、 雷に打たれたような衝撃を覚えた。
その時の感動は、 例の 「 美の鑑賞 」 の時間に味わったものと同じだった。

アルゴリズムと数学は少し似ている。
シンプルなものほど美しい。

数学の美しさに打たれた時と同じように、 教科書より美しく実装することに燃えた時期もありました。
数学ではさすがに教科書より美しく証明できることは少なかったですが、 「 アルゴリズム入門 」 みたいな本だと結構 「 勝った! 」 と思える瞬間があって楽しいものでした。

開発現場にいると高度なアルゴリズムを駆使することは意外と少なく、 だんだんフラストレーションが溜まってきたりするんですよね。
で、 うちで実装して遊んでみたりして… ( 墓穴2号 ) 。

最近はいろんなライブラリやコンポーネントが公開されていて、 複雑なロジックを自分で実装する必要は殆どないし、 仕事であれば下手に実装する方が高くつくので、 既存のものを使う方が賢明です。
でも、 若葉マークの方は一度でもおうちでこっそり遊んでみて下さい。
本当に楽しいから。

お前は墓穴に埋まってろって? はぁい。

しばらく真面目な話題が続いたので、 ちょっと軽い話でもしましょう。

昔からモテる男性って傾向が決まってますよね。
ハンサム、 スポーツが得意、 話術巧み…。
スキーやテニスを教えるとか、 ギター片手に 「 キミのために歌うよ 」 とかいうのはナンパ成功率が高いようです。
しかし、 大概の場合、 プログラマって女性にはモテないんですよね。
それでは悔しいので、 我々プログラマがモテる方法を脚本仕立てで模索してみましょう。

まずは数学から。

男 「 ねぇ、 FFT (高速フーリエ変換) って知ってる? 」
女 「 知らなぁい 」
男 「 教えてあげるよ 」
女 「 べつにいいよ 」
男 「 ( 勝手にどんどん説明を始める ) …これが畳み込み積分で… 」
女 「 … 」

どうも応用数学には興味がなさそうですね。
では基礎数学で攻めてみましょう。

男 「 じゃあ、 1+1がどうして2になるか証明してあげるよ 」
女 「 は? 」
男 「 こういう根源的なヤツの方が証明は難しいんだよ ( やっぱりどんどん証明を始める ) … 」
女 「 えーでも1+1が2だって証明できて何が嬉しいわけ? 」
男 「 えっ感動しない? 」
女 「 別に… 」
男 「 … 」

現実に何か役に立つものの方が興味をひかれるようですね。
アルゴリズムなんてどうですかね。

男 「 よし、 深さ優先探索のアルゴリズムを教えてあげるよ。 まずデータ構造はツリーで持ってね… 」
女 「 ( 半分呆れている ) で…何ができるわけ? 」

じゃあもっとストレートに言語を教えてあげるとかすればいいんじゃないかな。

男 「 プログラマに憧れたりしない? 」
女 「 別に… 」
男 「 やっぱ自分が作ったプログラムが実際に動くのを見るのは楽しいよ 」
女 「 ふーん 」
男 「 ( 鞄の中から 『 はじめての C 』 を取り出す ) これが教科書でね… 」
女 「 ( 顔が引きつっている ) あ、 私用事思い出したから帰るわ… 」

結論 : やっぱりプログラマはモテない

単にお前がモテてないだけだろって? そのとおりです。

夏目漱石の " 夢十夜 " という作品をご存知だろうか。
本が手元にないので詳しくは読者に委ねるが、 彼が実際に見た夢をもとにした小品集である。

その中に彼が鎌倉時代にタイムスリップする話があった。
確かこんな話だったと記憶している。

タイムスリップした彼は仏師が仏を彫る場面に遭遇する。
仏師はみるみるうちに一本の木から仏を掘り出してゆく。
あまりの見事さに彼は仏師に質問した。
「 なぜそんなにうまく彫れるのですか 」
すると仏師はこう言うのだった。
「 私が木から仏を彫っているのではない。 仏が木に埋まっていて、 私はそれを彫り出すだけなのだ 」

塑像 ( 粘土像 ) が " + ( プラス ) の芸術 " 、 つまり素材を足していくことにより作品を完成させる芸術であるとすれば、 彫刻は " - ( マイナス ) の芸術 " 、 つまり素材を削っていくことにより作品を完成させる芸術である。
だからこそ仏師はあのような表現をしたわけである。

プログラミングという " 芸術 " は、 一般的には " + ( プラス ) の芸術 " に分類されるであろう。
ただ、 個人的にはどんな芸術にも " + の側面 " と " - の側面 " があると思っている。

うまい人のコードを見ると、 " なるべくしてこうなった " という部分が随所に見られる。
自分で書いていても、 コードレビューを繰り返すうちに、 徐々に無駄な部分が削ぎ落とされ、 美しいソースへと収束してゆく。
そんな時、 あの仏師の言葉を思い出すのだ。

ソースを書き上げた後、 必ず " 掃除 " をすることにしている。
無駄なことを繰り返していないか、 もっと効率的なやり方がないか、 メンテナンスが容易か、 後で変なコードを埋め込まれる可能性がないか、 などなどをチェックし、 よりエレガントなコードへと昇華させてゆく。
そして美しくなったソースを見て、 " 仏を掘り出した! " とほくそえむわけだが、 同時に、 " もっと美しい仏様が埋まってはいまいか " とも思う。

芸術に終わりはない。
美しい仏様を掘り出せることを願いつつ、 ない知恵を絞る毎日である。

お前こそ木に埋まってろって? 彫った人は不幸だねぇ。

年の瀬が迫ってまいりましたが、 今年も機械仕掛けのあの方は歌われるのでしょうか。
いやぁもうあそこまでエスカレートすると " 行事 " ですね。
今年はどんな仕掛けだろうとか、 水が出るのだろうか、 はたまたドライアイスかとか、 彼女の出番まで 様々な思いが駆け巡ります。

で、 時計仕掛けの林檎の話題に無理矢理持って行くのですが(笑)、 今年のアップルは凄いというかひどいというか、 なんだか変でしたね。

技術的には何も変わっていないものをデザインで売る。

パソコンは、 既に一般ユーザにとってはスペックなんてどうでもよくて、 部屋に置いて似合うかどうかという、 家電的な位置づけに移行している。
そこをすかさず行動に移したのがアップルでした。
それは、 パソコンビジネスが技術戦略から販売戦略へと軸足を移した瞬間だったのです。

これはソフトウェアに関しても言えることで、 技術的には他と遜色のないソフトハウスが、 販売戦略で負けてしまうという現象が以前より多くなってきたように思います。
販売戦略で勝ったソフトハウス、 それはずばりM$のことなのですが、 あの会社はソフトハウスやめて商社にでも転向したらいいんじゃないか、 と冗談で言っていたことがあります。
社名はマイクロ商事なのか? なんか小商いしてそうだな〜(笑)。

1999年を振り返ってみると、 ビジネスのパラダイムが大きくシフトした年であったように思います。
インフラ企業、 家電メーカなどがコンテンツ提供サービスをビジネスの基幹に据えることを公表しました。
インターネットが普及し始めた頃は、 日本人は情報に金を払いたがらない、 コンテンツ提供サービスなんてせいぜい広告料で稼げる程度でビジネスにはならないんだ、 などという声が圧倒的でした。
" 情報に金を払う " という思想はパソコンユーザよりむしろ携帯端末ユーザの方が一歩進んでいました。
今後組み込み系プログラミングは大きく様相を変えるでしょう。
しばらくは Embedded Java の成り行きを見守りたいところです。
エンタープライズ系も、 これまで実験段階であったECなどが実用に移行し、 無名だった会社やドットコム・カンパニーが売り上げを伸ばす例が増えてきました。
ITは経営の中枢へと向かっています。

来年はどんな年になるのでしょうか。
我々を取り巻く状況は予想を超えるスピードで変化しています。
TECH B-ing ( おいおいまた転職する気かよ ) などを見ていると、 技術営業やプロジェクトマネージャ、 コンサルタントを募集する企業が圧倒的に多くなりました。
今までも受託系ソフトハウスではそうでしたが、 今後一層 " プログラマはOJTの一環、 いずれは営業かマネージャへ " という傾向は強くなるでしょう。
プログラマで居続けるというのは、 " 研究開発職として生涯研究を続ける " もしくは " 下請けの派遣社員で言われた通りにコードを書く " のどちらかの選択を迫られることになるように思います。
どの道をどう歩いてどこへ行くのか、 信念を持って歩まなければ崖から転落しかねない状況になってきました。

21世紀まであと1年。
2000年という節目の年は、 自分の心が未来を決める、 そんな年になりそうです。
あなたはどんな年になりそうですか?

お前なんかとっとと崖から落ちて死にやがれって? 言われなくてもそのうち落ちるでしょう(爆)。

さ〜て、 来週のこのコーナーは ( もちろんサザエさん調で読んでね ) 、 年末年始のトラフィック ( それにしても年賀状メールはなんとかならんのか ) およびY2Kを考慮して 、 お休みさせて頂きます。
次回は2000年1月11日頃になります。
それでは皆様、 よいお年を!

1999年12月29日、 父が天に召されました。
どんな偉大な人にも残せぬ大きな足跡を私たちに残して。

自動車整備会社で修行を積んで29歳で独立。
額に汗して手にした財産をすべて二人の子供の教育に充て、 私たちに最高の教育をつけてくれました。
二人の子供も立派に社会人となり、 これからはのんびりとやっていこうとしていた矢先のことでした。
子供たちに自分の人生の全てを捧げ、 燃え尽きるように逝ってしまった父。
もっと余生を楽しみたかったろうに、 そして親孝行してあげたかったのに。
厳しくも優しい、 立派な父でした。

お父さん、 ありがとう。
私はあなたの子としてこの世に生を受けたことを誇りに思います。

父は小柄な人だったが、 背中は大きかった。
いつかあの背中を超えられるだろうか。
死によって永遠の存在となったあなたを。

で、 また例によって無理矢理業界の話題に結び付けますが(笑)、 最近のプログラミング関連の本って扉に、 「 妻ナンシーに捧ぐ 」 などと書いてあったりしますよね。
でもあれっていつも思うんですけど、 本を捧げてもらったナンシーさんは嬉しいんでしょうかねぇ。
正常なナンシーさんの反応はきっと 「 えー私お料理のレシピの本とか、 フラワーアレンジメントの本がいいわぁ 」 とかいうものだと思うのですよね。

これは立場を逆転してみれば気持ちが分かるのではないでしょうか。
例えばあなたの奥様が料理研究家だったとして、 「 300円で作る今夜のおかず 」 なんて本の扉に、 「 夫○○ ( あなたの名前を入れて下さい ) に捧ぐ 」 なんて書いたサイン入りの本を貰ってもねぇ…。

1. 夫が書き上げた本はチンプンカンプン。 漬物石、 枕、 ヘソクリ隠しとして活用している。
2. 実は夫とは職場で知り合った同業者。 貰った本には速攻チェックが入り、 「 あら、 このガーベージコレクションの仕組みには欠点があるわ。 だってガーベージコレクタのプロセスの優先度をこんなに下げちゃったら、 最もガーベージコレクションを必要とする、 優先度が高くて空間的にも時間的にも浪費の多いプロセスが、 いつまでたってもガーベージコレクションの対象にならないじゃない! 」 などという鋭いツッコミが入る。

もっと気をつけるべきこととして、 本を書いている間は奥さんほったらかしになっちゃうことでしょうね。
本業がプログラマで、 副業として本を書くわけだから休日の家族サービスはきっと惨澹たるものでしょう。
それに対する奥様の報復が恐ろしいであろうことは容易に想像が…。

ま、 私は永遠に本を書く立場にはならないから安心です。

お前なんかの書いた本なんて誰が買うかって? 売れないだろうなぁ(爆)。