吉田 卓弘（よしだ たかひろ） エクスレイヤ社マネージング・ダイレクター。1961年10月2日生まれ、1990年4月に渡英。ダブルフォルト4連続でゲーム終了するほどの超初心者テニスを趣味とする。夢は、キャサリン・ゼタ・ジョーンズと一緒にテニス。

随分昔に入手した本を、たまに本棚から取り出して読み直すことがある。それらの本の中でも、特に「プログラム書法・第2版」、「ソフトウェア作法」の2冊から受けてきた恩恵は計り知れない。両者ともコンピューターのプログラムをどのようにデザインし、作りこんで、テストし、リリースすべきか、大量のサンプル・プログラムや悪い例を挙げ、概念から実装まで、丁寧に指導してくれる書籍である。

作法① 保守性

当時、既にソフトウェアの生産性や保守性が問題となっており、構造化言語と呼ばれるコンピューター言語がいくつか開発されていた。20代前半の私は、C言語というプログラミング言語に魅せられ、これをマスターした。そして「プログラム書法・第2版」、「ソフトウェア作法」の2冊が勧めるように、プログラムの保守性を高く保持し、他人様が後で私のプログラムを読む際に理解しやすいであろうプログラム作りやデータ構造を心がけた。

例え話になるが、変数Aにゼロを代入するプログラムを作るとしよう。普通に考えれば、「A = 0」というプログラムを作るだろう。しかし当時のマシン語プログラマーたちは例外なく、「A = A XOR（排他的論理和）A」といったパズルのような書き方をした。その方が処理スピードが速く、メモリーの消費量も少なかったからである。このように、当時のハードウェアはプログラマーたちにとって大変制限のあるものだった。

しかしながら保守性を考えれば、「A = 0」という読みやすいプログラムの方が断然優れている。ハードウェアの能力（コストに直結する）と、要求される処理速度のバランスを考慮し、できるだけ保守性の高いプログラムを作るべきだ、というのが前述した2冊の本から私が教えてもらった数々の素晴らしい概念のうちの一つだった。保守性ということに関しては、プログラムであろうが、事務処理であろうが、高いほど良いに越したことはない。多少の一時的なコストを考慮しても、長い目で見れば保守性を優先した方が大体安くつくのである。この原則はプログラムのみならず、一般論として捉えてまず間違いはないだろうと思った。

作法② 要素化

コンピューター自身は処理を間違わない。コンピューターは、機械的に一つ一つの処理をプログラムに基づいて実行する。間違いがあるとすればプログラムにある。そしてプログラムというものは、気の遠くなるような膨大な量の論理の塊である。そのほんの一部にバグ（間違い）があると、システムは止まってしまうかもしれないし、誤った答えを出してしまうかもしれない。このため、プログラマーたちはある一定の役目を果たす小さめのプログラムを作り、徹底的にテストを行う。テストでは、境界条件と呼ばれるプログラムにとってなるべく意地悪な入力を与えて、出力を観察するのである。こうして小さなプログラム（モジュール・関数）の完成度やブラックボックス度を高め、これらモジュール群を組み合わせて、より大きなプログラムを作る。これは、論理の誤り（バグ）を少なくするために大変有用なアプローチである。こういった方法論も、また一般的な概念になりうるだろう。

作法③ 直観力

後に、直感力がある。プログラムを書きながら同時に境界条件を常に意識し、もっと時間をかけてテストすべきなのか、十分頑健なモジュールが出来上がったのかを判断する必要がある。過去に作ったプログラムを捨て、最初から作成し直した方が良いという状況もしばしば発生する。そのような場合に備えて、どのプログラムが技巧的過ぎるのか、保守性を高めるためのコストは将来を見越しても見合うのかを見極めるために、仕事を進めながら常に直感力を鋭く働かせ、さらに磨くことが重要となってくる。今回紹介した2冊の技術本はこれらの点を最初から最後に至るまで訴えているように思うし、さらにこの原則はプログラムという範疇を超えて、一般論になりうる。

最後に、これら名著から2、3の抜粋を:
「うますぎるプログラムはいけない」
「いいたいことを単純率直にいおう」
「わかりやすさを犠牲にしてはいけない」
「第一版ができたところでやめてしまってはいけない」

▲