システムのリプレース案件が最も危険な理由

「Joel on Software」を立ち読みして興味深く思えたことを書く。

「あなたが絶対すべきでないこと PART I」という章がある。
Netscapeがブラウザの90%を占めていた頃、何を思ったか、彼らはNetscapeのソースコードを一から書き直すことを決心した。

Netscpapeのアプリをアップデートしていくには、そのソースコードを書き直さねばならない。
文字列を分解してゴニョゴニョした処理をして返すだけの関数が2ページもある！
タコなソースだよ！と。

でも待ってくれ。
このIF文は、IEの古いバージョンのバグに対応するために、ナンシーが書いたものだ。
この処理は、Windows95で動かすために手を入れたもので、ボブが書いたものだ。
つまり、このソースコードは見た目は奇怪でも、きちんと動いているし、過去のバグフィックスも積み重ねられているんだよ。

もし一から書き直したとしよう。
すると、また、これらのバグフィックスを一からやり直す羽目になるんだよ。
何故、IE5.0で動かない？
何故、Windows95で動かない？
何故、MacOS8で動かない？
要らないって？　でもお客から苦情が来てるんだよ。

それから3年余り、Ver4.0のまま止まったまま。
ITの世界で3年は途方もない時間だ。
そしてVer5.0をすっ飛ばして、Ver6.0をようやく出した時、Netscapeはシェアを獲得できなかったばかりか、会社そのものも消えた、と。

この逸話には、工業製品レベルのプログラムの品質について、いくつかの示唆を与えている。
一つは、システムやアプリのリプレース案件は非常にリスキーなことだ。

IT業界の業務システム開発は、システムのリプレース案件が非常に多い。
以前はメインフレームでCobolで作っていたシステムを、オブジェクト指向言語でオープン系のシステムで作り変えたい。
VBやAccessで作っていたクラサバのシステムを、Webベースのシステムに作り変えたい、とか。

これらの案件は非常にリスキー。
確かにそれらの技術は古すぎて、スケーラビリティもユーザビリティも耐えられないだろう。
しかし、数年もかけて運用してきたと言う事実はある。
つまり、色んな業務フローに対するバグフィックスや機能追加を重ねて、安定稼動したシステムになったのだ。

それらを捨ててスクラッチで作り直す時、過去のノウハウも全て捨ててしまうことと同じ。
お客さんから見れば、既に動いているシステムがあるのだから、仕様ははっきりしているでしょう、と思うだろうが、肝心のシステムは中身が全く違う。
運用していくうちに、バグフィックスや機能追加で、恐竜のように馬鹿でかくなった中身は、最新のオブジェクト指向言語で、同じようにたくさんのバグフィックスを重ねて積み上げたものに変わる。
同じソースコードの断片は一つもないはず。

リプレースする最新の技術力をコントロールできるか、そして、仕様を完全に設計しきれるか、が問われる。
普通は、どのプロジェクトもデスマーチになると思う。

もう一つは、プログラムの保守性や移植性、再利用性が、どの時代になっても、言語がいくら発展しても難しいこと。

言語が違えば、そのライブラリを再利用するのは難しい。

とはいえ、最近は、JavaからCのソースをコールしたり、RubyからJavaやC#のソースをコールすることもできるようだが。

特に再利用性は、そのライブラリの粒度に大きく依存する。
再利用できる程度は、フレームワーク程度ぐらいで、昔から夢想するビジネスオブジェクトレベルまでなかなか辿り着けない。

IT業界で仕事してきて、同じような失敗を何度も繰り返しているような気がするのは、上記の現象が解決されないからだろう。
システムのリプレース案件ほどリスキーな仕事はない。

追伸

この本の著者Joelさんは、来週のデブサミに来日されるとのこと。
ちょっと楽しみですヽ(^o^)丿