パソコンの試作機を開いてみると、プリント基盤の上をジャンパー線が這っていることがある。ハードウェアの試作段階で設計変更を施した跡である。これは試作機だから許されることであって、ジャンパー線付きで製品として出荷されることはない。しかし米国の某パソコンメーカの製品を開いてみたら、ジャンパー線が這っていたという有名な話もある。我々の作る製品がジャンパー線付きで出荷されたとすれば、それは我々技術者にとっては最大の恥であると思わなければいけない。

　ところで、ソフトウェアの世界にもジャンパー線がある。そしてソフトウェア製品は“ジャンパー線”付きで堂々と出荷されている。ソフトウェアのジャンパー線とは、パッチのことである。パッチとは周知の通りソフトウェアの設計ミスを修正するためにあらかじめ確保しておいたメモリ領域にプログラム制御を移し（つまりコブを作って）抜けていたロジックを補うなどの応急処置をしてまた何食わぬ顔をして元の場所に制御を戻す手法である。これを“手法”と言うのもおこがましいが。
　ソフトウェウのジャンパー線は、どんなにみにくい配線をしても、どんなに長く線を引き回しても外からは決して見えないので、それが問題になることはない。

　こういう方法を最初に考え出したのは誰であるかは知らないが、システムソフトの開発者でこの手法のお世話にならなかった人がいるとしたら、それは余程（？）の人であろう。パッチ領域内のプログラム記述では、通常の記述言語を用いるのではなく８進や１６進表現での機械語命令を用いる。したがって、ソフトウェア技術者はいやでも機械語命令のビットパターンを覚え、絶対番地の表現法に精通し、８進や１６進の加減算が巧みになり、それはそれは高い“技術力”を身に付けることになる。

　パッチのお陰で仕事量も十分に確保される。たとえば、パッチ領域の管理、パッチ領域の重複使用によるトラブル対策、パッチクリーンナップに伴うトラブル対策などが必要となる。パッチクリーンナップとは、パッチがある程度以上の分量になったので、誤り修正をソースプログラムに反映させてパッチと入れ替える作業のことである。これをやると、あ〜ら不思議！　パッチではうまく動作していたのに、クリーンアップすると期待通りに動かなくなったりする。そしてトラブルの再発となりお客の信用を確実に失う結果となる。その他、パッチ領域不足への対策、パッチ領域捻出のためのサイズリダクション、パッチが原因の新たなバグの発生（これが難しい。ソースプログラム上で追ったのでは絶対原因は分からない）、客先ごとに異なるパッチの適用管理・適用ミス対策‥‥。あげくの果てにパッチエディタ、更には高水準言語でパッチをあてるには、‥‥等という各種のツール開発が必要になる。そのための予算獲得の仕事も増える。ソフトウェア技術者の学ばねばならぬ分野はどんどん広がっていく。うれしくって、うれしくって、震えがくるというものである。

　プログラムの記述言語が高水準になるにつれ、この有り難い「パッチ」を利用する頻度は残念ながら減ってくる。高水準というよりもスタック構造を持つ言語といった方がよいかもしれない。スタック構造を持つ言語ではデータアクセスの手順が複雑になるので、それを知らずにパッチを当てるのは困難になるからである。特にＣ/Ｃ＋＋言語を用いる開発環境では、パッチを当てるよりソースレベルで修正し速やかにロードモジュールを再構成した方が結果として速いという考え方（流儀）で今までやって来た。その前提としてはＣ/Ｃ＋＋の世界では、make というツールが使えるからである。make を利用すると再コンパイルが必要なモジュールだけを自動的に判定し、最短時間でシステムを作り直すことができる。ところが、他の言語による開発環境から新たにＣ/Ｃ＋＋言語の世界に移行してきた場合には、移行を容易にするためもあるのか、旧来の開発手法にこだわり勝ちである。Ｃ/Ｃ＋＋でパッチをあてようとする剛の者も出てきたりする（元々Ｃをやっていた人の中にもいるが）。郷に入りては郷に従えで、できるだけ早くＣ/Ｃ＋＋流の開発環境に慣れることが大切である。Ｃ/Ｃ＋＋の世界では「プログラムを美しく書く」ことも大切であるが、Ｃ/Ｃ＋＋を取り巻く開発環境に早く慣れることも重要である。プログラム移植もこの開発環境ごと移植するのが普通である。

　しかしパッチを使うのを止めようと言っても、ことはそれ程簡単ではない。パッチを使う目的は、単にできるだけ早くシステムを作り直すことにあるのではなく、それまで積み上げてきた品質テストの実績を生かして予定通りにシステムを完成させることにある。ソースレベルで修正をしてしまうとプログラム全体の相対的位置関係が変わってしまうので、それまでやってきたテストがすべて御破算になり、テストを最初からやり直さなければならなくなるからである。そこで、出荷時期が近づくとある時点でソースを凍結し、それ以後の変更は（それも致命的なものに限り）パッチで行うようになるのである。こうすると再テストの対象をその変更部分に限定することができる（と信じられている）。大きなシステムになればなる程この効果は大きい。この議論がどこまで厳密に通用するのかは不明だが、これまでのところそれで大過なく乗り切ってきたことだけは確かである。
　しかし、いずれの日にかソフトウェアの“ジャンパー線”はなくしたいものである。■

［］