オイラは突然会社を辞めてしまった。
なんでかというと表題の 「 デスマーチ 」 のせいだ。
この言葉を知らない人はよほど幸運な人か、 わざわざ言葉にする必要がないほど日常的にこの現象に接している人だろう。
デスマーチとは、クライアントの無理な要望を少ない予算と少ない工期で実現するために行われる無謀な行為のこと。
お偉方ってぇのは 0 の数だけ数えて言いなりに 「 はいはい 」 っつって仕事を取ってくるから、 プログラマが死ぬことになるわけだ。
会社が儲かりゃ兵隊は死んでもいいのか!?

プログラマとかけて軍楽隊ととく。
その心は。
真っ先に斬られます。
ってね。

諦めちゃってる人も多いでしょうね。
「 開発プロジェクトにはつきもの 」 ですからね。
でもオイラは 「 正しい交渉と見積りに基づいて設計が行われればありえないものだ 」 …とまではいかないけど、 かなりそれに近い。
交渉において政治色が強くなればなるほどデスマーチが行われる確率は高くなるようだ。 「 こんなに無理を聞いてあげたんだから次の受注は確実だろう 」 って具合で。
でもオイラはそういう交渉のしかたをする方々に聞きたいね。
「 それって自社に決定的な技術的アドバンテージがないからじゃないの? 」
ちゃんと技術なりノウハウを押さえていれば、 無茶をしなくても次の仕事は取れるはずだ。 逆に無茶な仕事は断れるはずだ。
無茶な仕事を受けざるを得ないというのは、 色々言い訳しても結局他社と比べてちっともいいところがないからだ。
それでも稼がなきゃ生きていけないから無茶な仕事をし、 そんなことをしているから技術も蓄積されず、 技術がないから無茶な仕事を受け… ( 以下無限ループ ) 。

オイラは一度デスマーチを経験してから、 職業を聞かれた時に 「 プログラマです 」 と言うのをやめた。
世間ではプログラマというのは得体の知れないすごい技術者だと思われてしまうからだ。
しかし実際にやっているのは泥沼の作業なのだ。
お偉方がもうちょっと考えを改めてくれるかと思って待っていたが、 どうにもならないようなのでパッケージ系のソフトハウスに転職してしまった。
次の会社ではデスマーチが繰り返されないことを祈るぜ。

ちょっと前大はやりしたよね。
うち ( 退職前の会社 ) でもちょっとやってる。
相手は Oracle だから、 Pro*C で CGI でも作ってやれば解決したのだろうけど、 最初に WWW 連携 DB を手がけた時、 時間がなくて簡単なミドルウェアを採用した。
これが案外便利だったし、 そのソフトハウスも熱心にサポートしてくれていたので、 仲良くお付き合いさせてもらっていた。

ところがある日 Digital-UNIX をターゲットとした仕事が舞い込んだ。
その会社に Digital-UNIX 版があるか問い合わせたところ、 存在しないという。
じゃあ DEC 上で make してよと言ったら、 200 万かかるという。
多分 DEC のマシンがないんでレンタル料込みだとそのくらいかかるってんだろうけど、 そりゃいくらなんでも無茶ってもんだ。
なんせウチは 1000 万しか貰ってないんだから。

SE 「 どうしようか 」
オイラ 「 Pro*C で CGI 作るか 」
SE 「 間に合う? 」
オイラ 「 しょうがねぇじゃん 」

で、 客先に転がってた Pro*C を拾ってきて、 ごそごそと CGI を作って、 Apache からキックして Oracle と接続した。

SE 「 もしかして、 あの会社、 もう要らないよな 」
オイラ 「 まあな 」

ベンチャー企業も結構大変である。

オイラは 3 月末日が退職日なのだが、 それまでの間、 仕事がないにもかかわらず引継ぎのために出社しなくちゃならん羽目になった。
やることがないということは、 ここに書きたくなるような事件も起こらないわけだ。
仕方がないから、 話題をよそにそらして時間を稼ごう(笑)。

「 プログラマの三大美徳は、 無精 (laziness) 、 短気 (impatience) 、 傲慢 (hubris) である 」 (Larry Wall)

今や一大スクリプト言語として押しも押されもせぬ地位を確固たるものにした、 Perl の生みの親 Larry Wall 氏の言葉である。
オイラはこの言葉に出会って以来、この言葉を座右の銘にしている。

何がそんなにいいかって労働者としておよそ悪だと思われるものを三つも並べて美徳だと言い放つところだ。
これは同時に Wall 氏のプログラマとしてのセンスの良さを物語っている。

無精。
そう、プログラマたるもの無精でなければいけない。
マメな人は意外や意外、プログラミングに向いていないことをご存知だろうか。
例えば 100個のファイルの同じ位置を同じように修正してくれと言われたとき、 「 はいぃっ 」 といい返事をして日がな一日ファイルを vi で開けて変更して閉じて、 を繰り返しちまうような人ってのは、 プログラマには向いてない。
「 あ〜めんどくせぇーっ。 誰か暇そうな奴に押し付けてやろうかなー…後輩も結構忙しそうだなぁ。 うーん、 ( 傍らのマシンに目をやる ) あっ、 コイツひまそうじゃん 」
そして 100個のファイルを開けて、 修正して、 閉じる、 というループをプログラミングし、 そいつを走らせて一発で終わり。 こういう人が、 プログラマに向いているのだ。
最初に命令された時 「 あ〜めんどくせぇーっ 」 と思うか否かで、 最低限プログラマとしての素質を備えているかが分かるだろう。

短気。
仮に無精者でプログラマになれても、 気が長い人は初級プログラマから脱出できない。
こんなことをする人がこのページを読んでいないことを祈るが、 仮に、ソースのいたるところで

char	str[8];

char	str[12];

#define	STR_LEN	8
char	str[STR_LEN];

#define	STR_LEN	12

傲慢。
ここまでくれば上級プログラマの域かもしれない。
プログラマたるもの、自分の書いたソースに自信を持てなくてはならない。
中を見られた時に 「 えーっ、 ナニこれ!? 」 と言われるようなダサいプログラムではいけない。
そのプライドの高さが、彼のプログラムを信頼性の高いものとし、 誰の目にも読みやすく構造化されたものとせしめるのだ。
傲慢という言葉は真の上級プログラマのためにあるのだ。

これで、この逆説的な言葉がちゃんとプログラマの三大美徳を言い表していることがお分かり頂けただろう。

プログラマのセンスがキラリと光る言葉を放ったプログラマが生んだ言語 Perl は、 やはりプログラミング言語のセンスが真珠のごとくキラリと光る言語である。
一言で表すなら、 シェルスクリプト、 sed、 awk、 C を足して 割らなかった 言語、 といったところだろうか。
シェルスクリプトの簡便さ、 sed / awk の強力な文字列処理、 C の構造プログラミング能力の全てを併せ持つ強力さ。
そしてそれぞれの弱点は巧妙に隠蔽されており、 特に C プログラマなら誰でも頭を悩ます文字列処理がここまでさっくり解決するのを見れば驚愕に値するだろう。
Perl5 からは、パッケージモジュールを追加することが可能となり、 さらに強力な言語となった。
Perl の手軽さからパッケージはさまざまなプログラマの手により爆発的な勢いで追加されていっている。
ユーザは目的にあったパッケージを www.perl.com から落としてきて使えばいい。
まさに脅威のスクリプト言語といえるだろう。

ま、こんな風に Perl について語れるのも、 CGI と文字列処理プログラムを鬼のように書かされたからですね。
次の会社に行ったら、当分 Visual C++ をいじくり倒さなきゃいけないんで、 息抜きに Java で遊ぶかな(笑)。

Perl の話が出たので、 プログラマなら一度はやってみたい言語評論を。
少しくらいはかじってなきゃ評論もできないので、 オイラがかじった言語をあげてみよう。

• Perl
• SQL, PL/SQL
• Visual Basic
• C/C++
• Visual C++

Perl
CGI を記述するのに用いられるようになってから、 一気にその知名度を高めた言語である。
文字列処理においてここまで使いやすい言語をオイラは他に知らない。
それもそのはず、 コイツの父は sed / awk なのだから。 文字列処理のためにこの世に生を受けたようなものだ。
母は C だ。 そのおかげで構造化しやすい文法を持つ。
ただ、 C ゲンガーのオイラとしては、 シェルスクリプトライクなのがちょっと気に入らない。 謎めいた記号が散りばめられているのが何となくヤなんだね。
そのおかげで 「 なんっじゃこりゃ〜!! 」 というコードが書けてしまう。
キーボード最上段の記号を適当に打ったような記号列がプログラムなのですと言われるとちょっとびっくりしてしまう。
たしか、 「 謎の Perl プログラムコンテスト 」 というのがあって、 多分そこには本当に謎めいた記号列が応募されているんだろう。
そうは言っても Perl は本当に便利な言語だ。
特に文字列処理が多いプログラムや、 一回こっきりしか使わないちょこっとしたプログラムなんか作る場合、 下手に C なんかで書くよりよっぽどラクチンだ。
言語仕様もまだまだこれから変貌を遂げる兆しを見せていて、 今後ともお付き合いをしていきたい言語だ。

SQL, PL/SQL
SQL は他の汎用言語とは異なり、 データベースを利用するためだけの言語である。
データベースを定義したり、 データベースからデータを引き出したりすることができる。
一口で言ってしまうと簡単だが、 データベースは奥が深く、 SQL もかなりの規模の言語になっている。
「 枯れた 」 部類に入る言語なのだが、 オイラの正直な感想として、 言語仕様の詰めが甘いようなところがあるように思う。
ま、使えりゃいいんだけど。
で、最初に書いた通り SQL 単体はデータベースとのやり取りしかしないから、 具体的には C や COBOL のソースに SQL 文を 「 埋め込む 」 という形で記述する。
ソースを見ると SQL が C や COBOL に寄生しているようでちょっと面白い。
PL/SQL は Oracle のストアドプロシージャを記述するために、 Oracle が SQL を独自に拡張した言語だ。
こちらはちょっとした関数やプロシージャを記述できる。
ただ、どちらにも言えることだが、 言語仕様が今となっては古すぎる。
COBOL のソースを見たことがないのだが、 書いていくとどうにも構造化しにくくて COBOL ってこんなかなーと思わせる、 ほど書きにくい。
あんまり好きな言語ではないが、 稼がせてもらったから許しておこう。

Visual Basic
オイラが生まれて初めて触ったプログラミング言語は N88BASIC だった。
ただ、それは雑誌に載っていたマンデルブローを描画するプログラムをそのまま打ち込んで実行させただけなので、 N88BASIC については割愛することにする。
その次に BASIC に触れたのが、 Visual Basic だった。
これはカルチャーショックだった。
画面をお絵描きツールのようにエディットして、 ボタンとかにイベントが起きた時の動作を記述する。
オイラはその前に UNIX で Motif を使って GUI を書いたことがあったから、 この差には心底驚いた。
簡単なプログラムなら、 VCなんか持ち出すまでもなくさくさく出来上がってしまう。
一応関数を記述でき、 簡単な構造化も可能だ。
ただ、 「 さくさく開発 」 はあくまでも一人で書ける規模までの話だ。
大規模な開発に耐える代物ではないのだ。
個人的には 「 オモチャ 」 だと思っている。
ちょっとしたものを作るのに使うかもしれないが、 仕事で使うことはないだろう。

C/C++
コイツとは一番付き合いが長く、 実質オイラの飯の種である。
よく言われるように 「 高級言語の皮をかぶったアセンブラ 」 である。
でも逆にその辺がオイラは好きでもあり、 嫌いでもある。
やりたい放題ができる代わりに危険な香りのする言語だ。
ここまであげてきた中で一番構造化プログラミングの容易な言語だ。
C++になってオブジェクト指向、 カプセル化を実現し、 より安全なコーディングが可能となった。
醜い、醜いと言われながらもここまでの言語になった。
オイラはまだもうしばらくコイツで飯を食うだろう。

Visual C++
C/C++ と分けたのは、 コイツには膨大なクラスライブラリがくっついてくるからだ。
MFC を使わずに、 Win32 API ベースで書いてもいいのだけれど、 ある程度の規模になるとやっぱり MFC を使ってラクチンしようということになる。
ただこのライブラリが結構面倒というかクセがあるというか。
オイラも結構苦しめられた。
で、 MFC のソースを反面教師にしてクラス設計を勉強するわけだね(笑)。
M$ はあんまり好きじゃないけど、 今のところ仕方なくすっかり飯の種。 仕事の道具と化している。

オイラは今後も言語の海で泳ぎ(溺れ?)続けるだろう。
言語とアルゴリズムとデータ構造を紡いでプログラムを編み続けるだろう。
今後どんな言語と出会えるか、 楽しみだ。

とはいえ、あんまり出会いたくない言語がある。 COBOL だ。
コイツとだけはあんまりお友達になりたくない。
聞くところによると変数はグローバルしかなく、 構造化しようったってできないらしいじゃないか。
触っただけで下手がうつりそうだ。 もとい、 ただでさえ下手なのに更に下手になりそうだ。
…とまで言うと世の中にいっぱいいるコボラーを敵に回してしまいそうだ。 今日は早く帰ろう(笑)。

世の中には驚くようなプログラムを書くプログラマがいると聞く。
いや、オイラもその中に入っているのだが…。

うちの会社が入っているビルのエレベーターの制御プログラムが傑作だ。
うちの部署が12階に入っている。
昼飯時に12階から乗ると、下の階のどこかで満員になる。
満員だったら他の階で呼ばれていても通過すればいいのに、 律義に止まりやがる。
止まった階で一人ぐらい乗れるだろう、 と思って誰か乗ると 「 満員です。 降りてください 」 とほざく。 仕方なくその人は降りる。
それを呼ばれた階で必ずやるんだから1階に着くころにはみんな爆発寸前だ。
あまりにもひどいので切れて笑い出す人までいる始末だ。

オイラは制御系プログラミングを体験したことがないから、 どうこう言える立場にないんだが、 仮に C でエレベーター制御プログラムが書けたとしたら、

if(満員だったら){
    通過する;
}else{
    呼ばれた階で止まる;
}

みたいに書きゃいーんでねぇかと思うのだが…。
あれを書いたヤツに聞いてみたいよ。
「 あんた、大脳新皮質ついてんの? 」

そもそもエレベーターの制御プログラムなんて、 まさかエレベーターごとに違ったりするまいし、 一回作ったらそれを使いまわしているはずだ。
つまりこれは2重の犯罪だ。
まず、最初にこんなバカなプログラムを書いたヤツが悪い。
そして、このバカプログラムを継承しつづけてる連中が悪い。

プログラムは最初に上手く設計されていれば、 多少の変更には耐えられる。
継承していくうちに具合の悪いところが出てきても、 一から作り直すという最悪の事態には至らない。
問題は最初の設計がヘタクソだった場合だ。
改造しようにもどうにも手の入れようがなく、 全部書き直しになってしまうこともある。
書き直すだけの予算や時間が無ければ、 まずい設計のまま継承されていく。
エレベーターのプログラムは多分最初の設計がまずかったんだろう。

ソフトハウスでよくやるのが、 一から起こす時はベテランプログラマに設計とコーディングをしてもらって、 その後の拡張や変更は新人にやらせるパターンだ。
こうすると上手く設計でき、 新人の教育もできる。
後々まで使われるプログラムの設計というのは本当に難しい。

とりあえず昼飯にありつくのが遅れるから何とかしてくれ。

オイラは、前に書いたWWW連携データベースのCGIのテストをしていた。
と、 ブラウザの画面に 「 Submit 」 ボタンが鬼のように表示されるようになっちまった。
やべ! バグだ! しかも納期直前!! うへーぃ、 なんてこったい…。
ピンポーン。 ピンポーン。
がばっ。 なんだ夢かよ…うわーパジャマびしょびしょ。 「 どちらさんですかー 」 「 速達でーす 」
届いたものは、 次の会社からの採用通知だった。
3月4日の朝のことである。

いそいそと封を切って目を通す。
ありきたりの文面の後、 出社日 4月1日、 出社場所 神戸開発センター、 携行品 保険とかの書類。
そして給与。 粘った甲斐あって希望年収ぎりぎりパス。
「 配属 開発本部 開発一部 」 の文字が光っている。
ああ、 ごりごり書かせてもらえるんだー!!

話を元に戻す。
オイラが見たような夢って、 プログラマならきっと一度は見ているだろう。
コーディングする夢を見た人も多いだろう。
こういう夢って、 バグに苦しめられている時によく見るんだよね。
オイラの場合、 あまりにもひどいバグに出くわすと寝ている間に笑うらしい。 自分でも怖い。

バグというのは言語や開発環境やバグそのものの性質によって対処法が違う。

まず、一番簡単なのは自分のミスによるバグ。
単純なものは printf デバッグやデバッガを使ったデバッグで簡単に原因を突き止められる。
メモリリークなど、 メモリまわりのバグはちょっと厄介だが、 自分で書いたんだから、 どこで malloc してどこで free すべきかは自分が一番よく知っている。
だから free 忘れとか、 二重に free してるとかは簡単に突き止められるはずだ。

当然だが厄介なのが他人のミスによるバグ。
単純なものでも、 他人のコードを読んで、 何をしてるのか理解してからだから手間がかかる。
メモリまわりのバグは最悪だ。 「 free してないように見受けられるが、 本当にここで free していいのか? 」 などと悩みながら手を入れていかなければならない。

ただ、ここで一言言っておきたいのは、 最初に設計した時にきっちりモジュール分割し、 モジュールごとにきちんとテストしておけば致命的なバグは格段に減るということだ。
これをやっていないプログラマが意外と多いのに驚く。
適当にわーっと書いていって、 後から分割しようとするのだが、 オイラ自身の経験から言うと、 このやり方で上手くモジュール分割できた試しがない。
結果、 malloc と free の対応が予測しにくいところに現れたりして、 メンテナンスしづらいコードになってしまう。

先輩で上手い人のやり方を見ていると、 ある機能を実現するために必要と思われる小さいルーチンを、 紙に向かって随分時間をかけて設計してから大枠の設計に移り、 ようやくコーディングにかかっているようだった。
一見時間の無駄遣いに見えるが、 バグだらけのモジュールを作ってデバッグに追われるのと、 時間をかけても最初から完璧なものを作ってデバッグ時間ゼロとでは、 後者の方が圧倒的に効率的だ。
オイラも先輩を見習ってようやく真似っこができるようになってきたところだ。

それにしても一口にプログラマと言ってもいろんな人がいるようで、 オイラが出会った中で一番すごかったのは、
全部自分が書いたプログラムのデバッグが自分で出来なくて、 派遣先のSEにデバッグしてもらっていたヤツ だった。
二度と同じプロジェクトでやりたくないね。

読者の皆様もプログラマという仕事を選んだからには、 それぞれこだわりをもって仕事にあたっておられることだろう。
それなりの 「 スタイル 」 を持っておられると思う。

設計してる時とか、 ロジックをひねり出してる時に顕著に顕れやすいね。
うろうろと歩き回る人、寝る人、 ゲームをする人、ネットサーフィンをする人。
で、遊んでるのかなーと思ってると突然キーボードをがしがし叩き始めるわけだ。

オイラの場合、ロジックを考える時にはトイレに行く。
尾篭な話で恐縮なのだが、 個室に篭ってスッキリすると大抵いいアイデアが浮かんでいる。
思い付いたが吉日、 自席に戻って詳細設計を起こすことになる。
特別なツールとかは使ってなくて、 紙にラフな絵を描いて、 うまく描けたらコーディングに入る。
絵といってもフローチャートとかではなくて、 我流だ。
実はこの 「 紙 」 のサイズにこだわりがある。
オイラが設計に使っているのは A4 の裏紙を 4 枚に割いた、 つまり A6 の紙に穴をあけて綴じたものだ。
A6 と言われてもピンとこない方にはハガキの大きさと言えばお分かり頂けるだろうか。
ラフスケッチを描くにはあまりにも小さな紙きれなのだ。

こんなに小さい紙切れにラフスケッチを描くのには訳がある。
以前 A4 の紙に絵を描いていたことがあったのだが、 それだと描ける範囲が大きすぎるため、 モジュールが肥大化するのだ。
一つの関数に何十行も詰め込むモジュールが出来上がってしまう。
単機能しか実現しない小さなモジュールにするためにはもっと小さな紙にお絵描きしなきゃいけないことに気づいた。
それでこのサイズに落ち着いた。
愛用のオリジナルスケッチブックに描ききれないようなら、 設計はやりなおし。
もっと細分化しなくてはいけない。
で、この紙に収まるようにお絵描きができたら、 いよいよ関数の作り込みに入る。
実際にはそうして作った単機能関数を複数組み合わせて一つの機能を実現することになる。

それにしてもオソマツだなぁと普段から思っている。
ちゃんとした設計手法を勉強しないとねぇ。
おいおい勉強していって、 ここで紹介していきたいと思ってます、 ハイ。

実はもう一つ、 会社ではやったことがないのだが、 こだわりがある。
帽子だ。
オイラ髪が長いんだよね。
それもポリシーがあって伸ばしてるとかじゃなくて、 単に床屋へ行くのを無精してぼさーっと長いだけ。
普段はぼさーっでいいんだけど、 コーディング中にばさっと落ちてくるのがヤだから、 家では野球帽を反対向きにかぶってる。
次の会社は募集要項に 「 服装、 髪型、 仕事の進め方、 全て自由 」 と書いてあったから、 帽子かぶってコーディングさせてもらおうかな(笑)。

引継ぎの間ひじょーに暇だから、 さまざまに工夫を凝らして時間を潰している。
その中には当然ネットサーフィンも含まれる。
プログラミング関連のサイトを渡り歩いているうちに、 プログラミング講座のホームページを見つけた。
まあ、 上級プログラマが初心者向けのお勉強サイトを解説している例はゴマンとあるから、 別段珍しい訳でもないのだが、 掲示板があったのでふと覗いてみた。

そういうホームページを訪れる人が書き込むページだから当然なのだが、
「 プログラマに憧れています。 どうやったらなれるのか教えてください 」
という書き込みの多いこと多いこと。

オイラも何年か前はこっちの組だったんだなぁと思うとちょっと懐かしくなった。
しかし、ゲームプログラマは憧れる人が多くてゲームだけの専門学校とかコースがあったりするってのは聞いてたけど、 こんなにもプログラマ志望者が多いとは。
不況のせいなんでしょうかねぇ。 「 不況の今こそ手に職を! 」 ってとこか?
憧れは大切だ。 あらゆる情熱の原動力だ。
でも、 どんな職業でもそうだけど、 憧れだけでなれるほど世の中甘くはない。

まず、 適性というヤツがある。
ぶきっちょなヤツが寿司屋になれないのと同じように、 世の中にはプログラマに向いてるヤツと向いてないヤツが存在する。
当然、 向いてるヤツしかプログラマにはなれない。 いや、 向いてないヤツがプログラマになっても苦労するだけだ。
それを人は 「 下手の横好き 」 と言う。
プログラマに求められる最低限の適性は語学力と論理的思考力と好奇心 だと、 オイラは考えている。
いまどき機械語でプログラミングするでなし、 何がしかのプログラミング言語を最低限一つはしっかりマスターしないといけない。 最初にあげた語学力がそれ。 なにも英語ペラペーラでなくていい(笑)。
プログラムにはアルゴリズムが必要だ。 そいつを考え出すのには頭がいる。 論理的思考力だ。 プログラミングには、 覚えることよりも考え出す能力の方が大切だ。
あとは、 流れの激しい、 新しいものがどんどん出てくるこの業界に対応できる好奇心があればばっちりだ。
これがプログラマの最低限の適性。
上級プログラマを目指したければ、 " 美徳 " の項で書いたものを備えればいい。

無事プログラミングがなんとかできるようになったら、 会社に入って実務をこなしたい。 はずだ。
会社選びは自分の人生を左右する。 特にこの業界。
人を人とも思わぬ会社が、 あまりにも多いのだ。
その最たる例が派遣会社。
フェアやパンフレットで 「 未経験でも大丈夫! 」 「 あなたのスキルを活かせます! 」 などと派手に誘っておいて、 プログラマやSEを派遣してその上前をはねるという、 水商売のおかみさんも真っ青の商売をしているのだ。
確かに 「 未経験でも大丈夫! 」 と言われると 「 ボクでも大丈夫かな 」 と思ってつられてしまう気持ちは分かる。
実際、 転職フェアで一番人が集まっていたのはこぞって派遣会社だった。
オイラは派遣会社に籍を置いたことがない。 だからここでどうこう言う立場にはないのだが、 どう考えてもあまりいい労働条件とは思えない。
もしあなたが今就職 / 転職活動中で派遣会社を考えているとしたら、 一度冷静になって考え直して欲しい。
現在の自分のスキルがどうしても普通のソフトハウスで採用してもらえる基準になければ、 いっそベンチャーというのはどうだろう。
ベンチャーを起こすようなプログラマなら、 相当のパワープログラマだ。
もしそういった会社で 「 未経験可 」 の募集を出していたらすごいチャンスだ。
パワープログラマの骨の髄までしゃぶりつくして自分もスーパープログラマーになればいい。

さて無事いい会社も見つかったとしよう。
ところがこの業界、 実に残業が多いのである。
しかもその残業に見合うほど給料は高くないときた。
プログラマは、 「 三度のメシよりプログラミングが好き 」 とキッパリ言い切れるようでなければ、 あほらしくてやってられない職業なのだ。
知力だけでなく、 体力と精神力も求められる職業なのだ。

体力にも精神力にも恵まれているあなたにも、 いつか試練の時が訪れる。
パッケージ系のソフトハウスと、 システム系のソフトハウスでは事情が若干異なるが、 何年かすると SE にステップアップ、 その後はマネージャーやコンサルタントなどへと変容していく。
ずっと現場でプログラミングしていたいのか、 それともステップアップの道を選ぶのか、 それはあなた次第だ。
ただ、 残念なことだが、 ずっと第一線でプログラミングできる人というのはほんの一握りだろう。

ここまでちょっと厳しいことを書いてしまったが、 でも、 プログラマに憧れる人は多い。 オイラだって憧れのプログラマがいっぱいいる。
何がそんなに魅力的なんだろう?
変な例えだが、 愛とか恋とかいった感情に結構近いんじゃなかろうか。
なぜオイラがプログラミングがそんなに好きなのかと聞かれたとき、 論理的に説明するのがどっかで出来なくなっちゃうからだ。
人を愛するのに理由がいらないように、 プログラミングという行為を愛するのにも、 理由はいらない。
オイラがプログラミングを好きだから好きなんだ。 オイラもプログラミングに愛されているんだ。
それでいいじゃんか。
ともかく掲示板に書き込んでいたプログラマの卵さんたちの健闘を祈ってるよ。

4月から行くことになっている会社の面接で、 開口一番 「 プログラミングは、 好きですか? 」 と聞かれた。
それが殺し文句だったことは、 言うまでもない。

暇だ、 ネタがないとかなんとか言いながら殆ど日記状態のこのページ。 最初は一週間に一度ぐらい更新していくつもりだったんだけど…(笑)。 ま、そのうち落ち着くでしょ。

オイラのいる部署で今日月例ミーティングがあり、 その席でオイラは正式に退職を公表した。
これで大手を振って有給消化できるぜぇっ!!…とは問屋が卸さない。
これまでに書いたプログラムを " WWW 連携データベース " で登場した SE くんに引き継がなければいけないのだ。
今日はプリコンパイラと格闘する彼を背にして、 やっぱりネットサーフィンしたり、 要らなくなった書類をシュレッダーにかけたり、 ぶらぶらしていて、 時折 SE くんからの質問に答えたりしていた。

トイレで 「 この不況によく就職を決めましたね 」 と言われた。
そう、 オイラにはあんまり実感がないけど、 世の中は不況の嵐が吹きまくっているのだ。
先輩が茶飲み場で新聞を見ていたのでふと後ろから覗き込むと 「 リストラ 」 の字が躍っている。

先輩 「 万単位のリストラって、すごいよなぁ 」
オイラ 「 こわいよねぇ…最近電車の中とかで、 VB とか Access の本読んでるオジさん いるじゃん、 ああいうの見ると背筋が凍るよな 」 ( 先輩にタメ口、 おそるべし生意気野郎 )
先輩 「 それが趣味だとかわいいんだけど、 そんなの一割にも満たないよな、 きっと崖っぷちなんだよな 」

それは命がけのプログラミングだ。
Visual Basic で、 Access で、 プログラミングが出来なければ首を切られるのだ。

じゃオイラたちがのうのうとお気楽極楽プログラマで生きているのかと言うとそうでもない。
…いや、 気楽ですけどね。
オイラだって命がけだぜ。
コンピュータを動かす謎の言語で記された、 怪しい文書を書いて金をもらうのだ。
その文書はどこかで誰かの手助けをするはずだ。
場合によっては誰かの大切な何かの運命さえ左右するかもしれないのだ。
医療システムや原子力発電所プラントシステムだったりすると人命にかかわるのだ。
そんなプログラムを書くのに命がけでなくてどうする。
…いや、 オイラそんなすごいシステム手がけてませんけどね。
でも、 命がけですよ。 もしオイラが書いたソースがぐっちゃぐちゃだったら、 オイラが書いたプログラムにバグがあったら、 その場で首くくって死んでやってもいいぜ。
…とか大口たたいても、 汚いソース書いて、 バグ出して 「 あちゃー 」 とか言ってますけどね。

ここで一句。
腐っても プロでやるなら 命がけ。
…腐ってますけどね(笑)。

約一週間の引き継ぎ期間を経て、 オイラは有給消化に入った。
ほんとに暇になったわけだ。
暇だから、川崎まで遊びに行った。前から欲しかったものを買うことにしたのだ。
まずハードディスク。 4GB くらいでいいと思っていたんだけど、 Quantum のが思ったより安かったんで 6GB のを買った。
これで安心していろんな OS やアプリを入れて遊べる。

次に買ったのがなぜか G パン。
オイラの会社は一応スーツ着用が基本ってことになってる。
そんな会社に 3 年も勤めてたら、 タンスの中がスーツだらけになってしまった。
次の会社は服装自由。 開発チームは殆どみんな G パンだ。
オイラだって好きでスーツ着てた訳じゃない。 出来ることなら開発中は楽な格好がいい。
てなわけで G パンを買ったのだ。

昔からなぜかプログラマって G パンと T シャツなんだよね。
プログラマの制服なのかと思うくらい。
で、 上級プログラマほどきったねぇ格好してたりする。 格好なんか気にしないんだね。
だいたいものを考える時に格好なんて気にしてたら出るもんも出ないわな。
ネクタイなんぞ締めようもんなら、 首が絞まって苦しくて仕方ねぇ。

システム系っつうか、 ビジネス系のシステムとかやってるとこだと、 いかにも 「 私はビジネスしてるんです 」 っつう格好したプログラマが 「 私は技術者なんです 」 と言いたげにプログラミングしてる。
今までそういうところにいたから言えるけど、 その人たちが技術者の真似するの、 やめて欲しいよ。
世の人たちが 「 プログラマ 」 という職業について誤解をするとすれば、 「 得体の知れないすごい技術者 」 と勝手に決め付けるか、 「 大したことも出来ないくせに給料だけは高いヤツ 」 と思うかどっちかだもんね。
後者の誤解を生む原因になった人たちには業界から消えて欲しいね。
ソフトウェア業界を育ててくれた上級プログラマに失礼だ。

「 プログラマが不足している 」 という噂を聞きつけてか、 プログラマになりたがっている人が多いと聞く。
でも、 誤解してもらっては困るのは、 「 業界が求めているのはできるプログラマであって糞プログラマではない 」 ということだ。
糞プログラマには消えて頂いた方が日本のソフトウェア業界に貢献するだろう。

で、 ここまできついこと書いた張本人が 「 真っ先に業界から消えて欲しい糞プログラマ 」 だったりするんだよな(爆)。