T - 12006年11月09日 11時28分03秒

新規大型プロジェクトへの移行が始まり、二十年以上稼働していたシステムが終焉を告げようとしている。

旧システムは二十年来の柵<しがらみ>が複雑に絡み合って、かなり悲惨な状況になっていたので、新規システムの導入には私はとても肯定的だった。元々、大がかりな変更を嫌う経営陣からの新規システムに対する肯定的な姿勢も大変な援護射撃だった。

旧システムは、時代的に CPU やディスクもとても遅いものであった時に設計されたので、今日の速い CPU と速いディスクには到底合わなくなっていた。加えて、当時の技術力も未熟だったため、やっつけ仕事だったり、とりあえず動くようにしたところが継ぎ接ぎになり、どうにか動いていたような物だった。いわゆる、奇妙な仕様が出来上がり、なぜだかわからないがシステムが動いているような状態だった。流石に、中核は何度も書き直されていたので、少々ましではあったが、大胆な変更が出来ないので、保守の手間の半端ではなかったのである。

新しいシステムを開発する場合は、何もないところから書き起こした方がよい。経験的には、ほとんどのコードは、再利用には値しない。車輪の再発明とか言われるが、書き直した方が読みやすく、バグもなく、高速に動作し、最終的に保守の手間の少ない事の方が多い。

再利用可能な部分もある。それは string.h や stdlib.h などで見られる関数の変種や、とても文字列の基本的な操作を行なう関数がほとんどだ。少し大型な API などだと、書き手による。開発の面子にもよるが、経験上だとどのシステムでも使い回せるようなコードを書けるのは、あまり見たことがない。元々、大昔に書かれたものだと、なおさら大型関数の大作が乱立するので、元々コードの使い回しも出来ないことが多いのだ。新規に書かれたものでも、必要のない動作を繰り返す無駄な作業が多いのも、頻繁に目にするのも事実だが。

しかし、時間的な制約のため、一部を旧システムから引き継いだので、一部では旧来の癌を引き継いでしまった部分もある。徹底的に反対したが、最終的には時間的な制約な為と決断が下された。皮肉にも、試験を重ねて問題が表面化されてくる部分は、旧システムからの部分も多かった。旧システムからの遺物だと、変更を行なったときの期待しない副作用が多く、変更を加えるのも新しく書き起こされた部分よりも大変な事がほとんどだ。

新しい部分にも、もちろんそれと同等か、もしかしたらそれ以上の問題はあった。決定的な違いは、コードに対する理解の度合だろう。そのため、新しいコードは修正がやりやすい。それに引き替え、古いコードだと何を理解するのに時間が掛かる。意図的に奇妙な動作をしているのか、バグで奇妙な動作をしているのかの、判断が出来ないようなコードが交じっていると、あっと言う間に時間が過ぎてしまう。そういう部分に限って、書いた人は、もういないものだ。

今のままで動いていると言う理由で、古いコードが再利用される場合もある。しかし、新しいシステムに同じような理由で再利用することが間違いだ。新しいシステムの仕様は、古い仕様とは違うし、開始時点では同じつもりでも、最終的には変わってしまう事も多い。

そんなわけで少々不満が残る部分もあったが、様々な部分での革新が大量に行なわれた事も事実だ。そして、開発方針の一部として、旧来の部分を書き直していく作業も容認されている。残念ながら、初版には間に合わなかった変更も、次期に向けて改善していくことが出来る。

色々と開発陣内での衝突もあったりするが、何だかんだ言っても後一日の所まできた。そんな新規システムも本稼働が始まる前日なのだ。

次回