先日、IT 関係に詳しい出版関係の方とお話していたとき、私が「ああ、あのプロジェクトは、奇跡のソフトで…」と発言したとき、その方から「奇跡とはどういう意味なんですか？」とより詳しい説明を求められた。
その方は、IT に詳しいとはいえ、実際にプログラマや SE として働いたことはなく、その点に関しては一般の人と変わらない。そのとき「一般の人の感覚ってこんなもんなんだ」と認識を新たにしたので、そのことに関して書く。
あるソフトが「動くには動いているのだが、度重なるソースの改変で、もはや常人にはロジックを追うことすら難しく、たとえプロジェクトマネージャーであっても、なんで正常に動いているのかよくわからない」とき、半ば揶揄の意味を込めて「奇跡のソフト」とか「奇跡のコード」とかという言い方をする。
「でも、そういうのはアマチュアや日曜プログラマが作ったソフトで、メーカーが作るソフトにそういうのはないでしょう」という声が聞こえてきそうだが、これもちょっと違う。最近は諸々の事情もあって、かなり有名なメーカーがリリースしたソフトでも、「奇跡のコード」が含まれている可能性はあると思う。
これに関しては、あまり一般的なことを言ってもしょうがないような気がするので、昔、関わったプロジェクトを例に語りたい。
分類：創薬支援ソフト
特徴：薬剤候補化合物を Web 画面から投入、官能基を変化させた類似化合物などを自動的に表示、また、その物理化学的性質をシミュレーションした上で表示
経緯：某大学計算化学研究室で開発→某化学系業界団体が支援→大手N社が Web アプリに改変して販売→某大手製薬企業が購入→バグ発覚→支払いでトラブル→両者膠着状態
もう１０年以上も前の話なので、より詳しく書いても問題ないと思うが、念のため、かなりぼかして書いた。
たぶん、業界に通じている方なら、「某大学計算化学研究室で開発」あたりで危険な香りを感じていると思う。大学研究室は、一般の人が考えるほど研究の継続性はそれほど高くなく、担当院生が卒業してしまうとその部分に精通した人間が一人もいなくなってしまうということはザラだ。実際、このケースでも（後でわかったことだが）原因はそれであった。
上のように経緯をはっきり書いてしまうとわかると思うのだが、N社はこのソフトに関して Web アプリ化したのみで基本的な部分にはいっさい関わっていない。というか、製品全体に渡って一貫して関わっている技術者は一人もいない。大手リリースの製品であっても「奇跡のソフト」が生まれる余地があると書いたのはこういった事情による。
また、上記案件では、Web アプリといっても企業内 LAN 使用が前提のため、tom…ナントカ あたりでことがすんでいたのだが、N 社の経営陣が気まぐれで「これからはネット社会。どうせ Web アプリ化するなら、外部公開も前提に REST も実装しておいてくれ。VPN もお忘れなく（にっこり）」などと言った場合、もっと悲惨なことになっていたことは想像に難くない。（まあ、この時点では REST はなかったわけだが）このとき N 社プロダクトマネージャー（PM）が、例えば、その仕事を外注に出したとしても、また、それが原因で、その後、REST 周りが奇跡のコード化しようとも、私には、この PM を単純に責める気になれない。現代にあって、有償のソフトを限られた時間内でリリースするのは、相当、プレッシャーがかかることなのだ。
なお、上記プロジェクトは、その後、デバッグ作業が外注に出され
- 大学教養〜学部レベルの化学の知識のあるもの
- 医学・薬学に関して実務経験かそれに相当する知識のあるもの
- 一般的なプログラミングのスキルがあるもの
- 計算化学特有のロジック・アルゴリズムを追える能力のあるもの
- 主要開発言語である Fortran の経験があるか短期間で習得可能なもの
といった選抜条件の下、東欧系やインド系の会社とのバトルを勝ち抜いた国内某ソフトハウスが受注。紆余曲折を経て、当時、フリーであった私がデバッグ作業を担当することになった、という次第だ。
なお、デバッグ自体は、まあまあ上手くいき、ごまかしごまかし動くといった程度までには回復した。が、完全に狙った動作を実現する実装ができたかというと、そこまでは至らなかった。奇跡のコードはどこまでいっても奇跡のコードなのだ。
開発元がバグを認識していても、なかなか改善されない、とか、自称「開発者」がバグを直したつもりになっても、全然直っていない、とかといった現象を目の当たりすると、一般の人は、不思議に思うかもしれない。が、背景にある国際分業化とか業務の外注化といった状況を考慮すると、しごく真っ当な事情があったりするのだ。
以上、デバッグだとかバグフィックスだとかに関する IT 業界の昔話でした。
