ソフトウェア技術者は不精でなければならない。特にプログラミングを主業務とするソフトウェア技術者（プログラマ）は、決して勤勉である必要はない。むしろケチで、不精で、怠惰で、不誠実で、オタク^（注）であることに徹するべきである。たとえば、プログラマたるものは日頃から次のように行動するとよい。

【注】オタクの正確な定義は知らないが、ここでは自分の関心領域に閉じ籠り、他人のやることには無関心な人という意味で用いている。

（１）ステップ数をケチろう
　プログラムの記述はできるだけ簡潔にしてステップ数をケチることが重要である。概して短い簡潔な記述は、実行時間をケチるのにも役立つものである。
　しかし、ステップ数は単に減らせばよいというものでもない。プログラムの生産性を算出する手段として、月当りの記述ステップ数に注目している人々がいるからである。彼等はプログラムの総ステップ数を開発期間で割って値を求めソフトウェアの生産性を測る尺度としている。この値が大きければ大きい程、生産性は高いと評価する訳である。

　ここで“ステップ”と言っているのはソースプログラムの行のことを指すらしい。これはアセンブラ、あるいはＦＯＲＴＲＡＮ、ＣＯＢＯＬなどの旧来のプログラム言語が、行当り１つの機能（文または命令）しか記述できなかった頃からの名残りであろう。今や１行に複数の文を書ける言語が普通である。ＬＩＳＰのように行にとらわれない言語もある。１行の中にはたくさんの機能を記述することが可能である。しかし彼等にとっては行の内容などはどうでもいいのであって、ただ行数のみを問題にする。行数とはつまり文字列の中に含まれる改行コードの数のことであるから「改行コードの数が生産性を左右する」と彼等は主張している訳である。改行コード（\n）の情報ビットのどこに生産性の秘密が隠されているのか、これは面白い研究テーマではある。

　ともあれ、ケチに徹するとしても彼等に生産性の面で心配をかけないようにするため、我々はステップ数を見掛け上増やす配慮は必要であろう。幸い彼等は、プログラム上に書く注釈もステップ数に含めることを許容する程度の寛容さは持ち合わせている。したがって、プログラムの先頭などには努めて注釈を入れるようにして見掛け上のステップ数を稼ぐようにするとよい。ステップをケチり過ぎると、時として分かり難いプログラムになってしまうことがあるからプログラムを理解しやすくするためにも注釈を利用するのは大切なことである（注釈の書き方については「プログラムの美しさ」で触れたのでこれ以上深入りはしない）。

（２）サブルーチン化しよう
　プログラムの中に同じような記述が繰り返し現れる場合、我々の先人は「サブルーチン」というものを考案してその記述を一度で済ますという、この上ない不精な方法を考えついた。「この場所に記述した積もり」という意味で「サブルーチン呼出し」をそこに書くだけで済ますのである。

　この不精な方法は一度使うともうやめられない程便利なものである。最近では、一度しか使わない記述部分でもサブルーチン形式にしたり、あるいは逆に何度も記述する必要がある部分でも（インライン展開という指定付きの）サブルーチンにしたりする人がいる程である。

　プログラマたるものは、先人の知恵に感謝しつつ、この手を使って不精を重ねるべきである。そして、サブルーチンが完成したらその使い方（インタフェース）だけはよく記憶にとどめ、その中身の方はさっさと忘れてしまうことである（あぁ、何たる不誠実！）。特にサブルーチンの中で使われた実装法やデータ類に関しては「後は勝手にせよ」と以後一切関与すべきではない。この種の不誠実で無責任な態度のことを、気取っていうと「抽象化」などと表現する人もいる。要するにサブルーチンをブラックボックス化してしまうことである。

（３）ライブラリを活用しよう
　優秀なプログラマになりたければ、何にでも首を突っ込んで何でも知っていないと気が済まないという、あのいやな性格をまず改めてオタクになることである。

　一般にプログラマは、何でも知っていないと不安で不安で仕方がないものである。他人の作ったプログラムをそのまま使うなどという恐ろしいことは考えもしない。特にシステムプログラマと呼ばれる人たちにこの傾向が強い。すべて自分でゼロからコーディングしないと気が済まない。あるいはソースプログラムが手元にないと不安で使えない。その結果同じようなプログラムを、繰り返し繰り返し作ることに仕事の大部分の時間を費やすことになる。

　先輩が作ったプログラムの集積（いわゆるライブラリと呼ばれるもの）を信頼し、それをもっと活用することが大切である。日頃からそのような対応をしておけば、何かのときにはトラブルの原因を先輩のせいだと責任転嫁することだってできるではないか（あぁ、何と破廉恥な！）。それだけではない。コーディング時間を節約した分だけ楽ができるというものである。間違ってもライブラリプログラムの中身に関心を持ったりせず、努めてオタク族であることに徹しなければならない。

　ライブラリがそんなに信頼できるのかと異議を差し挟む人がいるかもしれない。ライブラリプログラムは「皆んなで渡れば怖くない」という主義で多くの人が使えば使う程、信頼度が高まり高品質なソフトウェア部品として再利用できる道が開かれるものである。その結果、相対的な保守費もケチれるというものである。

（４）キー入力は下手になろう
　プログラマがキーボードに向かってせっせとキー入力している姿をよく見掛ける。実に熱心である。その熱心さが仕事の成果に結び付けばよいのだが、大抵は空回りしていることが多い。単にキーの入力操作ばかりが巧みになっているのではないか。プログラマはキー操作など下手な方がよい。下手なら下手なりに工夫するからである。変にキー操作に自信があると無駄な入力を繰り返しても一向に無駄と思わないようになってしまう。

　キー入力の中身は同じことの繰り返しであることが多い。勤勉なプログラマであればあるほど、飽きることなく同じキーシーケンスを入力し続けている。もっと手を抜くことを考えないといけない。長ったらしい変数名やディレクトリパス名を真っ正直にそのまま入力したり、同じようなコマンド系列を繰り返し入力するなどは愚の骨頂である。こんなものはエディタの機能を利用したりコマンドスクリプト（いわゆるバッチファイル）にして一発で終りにするなどして、手を抜くことを考えるべきである。

　Ｃのプログラム作りにしても同様である。Ｃのプログラムなど最初の書き始めはすべて同じである。プログラムの雛形をあらかじめ用意しておいて、そこから不要な部分を削ることによって個々のプログラムの骨格を作るくらいの知恵を働かせて欲しいものである。

　最近では、ウィンドウシステムの普及にともないキー操作ではなくマウスによる窓の開閉に没頭している姿を見掛けるようになってきた。明けても暮れても窓を開いたり閉じたりの作業に追われている。そんなことばかりしていると、突然発作的に変わったことをしたくなり、窓の中に飛び込んだりしたくなるのだ。窓を開け放したまま終了するのはいけません。いくら不精者でも窓を開いたら「必ず自分で閉じる」という最低限のマナーは忘れないようにしたいものである。

（５）再帰的呼出しによる仕事の進め方
　性格的にこういった行動指針に素直に従える人は、再帰的呼出しというプログラミング技法を理解する上でも有利である。プログラミング教育で初めて再帰的呼出し（recursive-call）の手法に出くわすと、大抵の若い技術者は理解できなくて苦労するものである。これを理解するには、今までの逐次的な考え方をやめて根本的に発想を変える必要がある。それには無責任で直ぐに人に頼ろうとする性格に変身するとよい。たとえば次のようにすると簡単に再帰的プログラムが作れる。

(1) 与えられた仕事をよく分析し、難しい部分とやさしい部分に分ける
(2) 難しい部分は残らず人に依頼する
(3)ただし、依頼するに当っては誰に依頼するか、依頼条件は何か、納入物件は何か、などを最低限明確にしておく
(4) 残った一番やさしい部分だけを自分で行う

　この方針で仕事にのぞめば大抵の仕事は成功する。しかも仕事の成果はすべて独り占めすることができる（もっとも、再帰的にやるのが望ましい仕事であるかどうかの判断は別に必要であるが）。■

［］