華やかな世界の裏側で

スクリプト言語の代表格であるPerlで作られたWebアプリケーションがITベンチャ企業を中心に増えています。特に近年では開発スピードを高めるために、CPANモジュールを大いに活用して、CatalystやSledgeなどのフレームワークを使った構築事例が多くみられます。

その一方で、1990年代末期にCGIで構築されたWebアプリケーションが連綿と保守され続けている現状もあります。

近頃の雑誌やWebメディアなどで取り上げられるのは、前者の華やかな世界が中心です。そこで本記事では、現在でも必要とされている後者の保守開発している現場にフォーカスを当ててみたいと思います。

1990年代末期のプログラミング言語

1990年代末期は「B to B」や「B to C」のWebアプリケーションが多く作られた時代で、現在と違いJavaアプリケーションサーバはいまだ重厚で高価なものでした。したがって、従来のビジネスをいち早くWeb化するという目的では、スクリプト言語を開発言語として選ぶことが自然な流れだったといえます。

現在の状況と異なるのは「従来のビジネスをWebに載せるのか」と「インターネットだからこそ実現できるWebに特化したサービスを作るのか」という点といえるでしょう。

当時はスクリプト言語の中でも日本語対応（jperlパッチ）が有志によって進められていた「Perl」が無難な選択肢でした（PHPは実績の面でまだ乏しかったですし、Ruby、Pythonはエンタープライズ用途ではまだまだマイナーでした）。

分かれ道は保守開発フェーズ

ということで、開発段階において言語選択に分かれ道はそれほど無かったのです。では、どこに選択の分かれ道があったのかというと、初期構築の後の「保守開発フェーズ」においてです。

筆者の経験では、Webアプリケーション開発はコンシューマ向けのものがほとんどです。その中でビジネスとして成功したものほど、システムの寿命は長くなり、思い切った再構築の決断はし難くなっているようです。

これは売り上げをあげているWebサイトにおいても、開発スピード勝負に勝つためには再構築した方が有利ではありますが、ハッキリと目に見えるリターンもなしに投資（再構築）をするのか、というイノベーションのジレンマに陥るためです。

こうしたケースでは、経年劣化していく生産性と品質を極力下げないようにドライブしながら、来るべき再構築へ向けて次のアーキテクチャを考えるとともに、現行のソースコードをその時に再利用できる形に変えていくという難しい判断が求められることになります。

そのような理由から長年使っていくプログラムにおいては「1. ソースコードを書かないようにする」「2. 不要になったソースコードを捨てる」「3. 修正の途中で別の問題を見つける（修正する）」の3つが特に必要だと考えています。これらは言い換えると、エントロピー増大の法則に全力で逆らい続け、ソースコードをシンプルに保つための行動原理といえるでしょう。

では、Perlは保守開発フェーズにどれほど効果を発揮するのでしょうか？ 次のページ