稼働中のアプリケーションがメンテナンスできない，または，メンテナンスにかかるコストが非常に大きい場合，メンテナンスするよりも再構築した方が得策と判断され，アプリケーションは寿命を迎える。これまでアプリケーションの寿命と言えば，アプリケーションが古く設計書が残っていない場合や，開発/運用環境が古く製品をそろえられない場合などに起きていた。しかしここにきて，比較的新しいアプリケーションであっても短命化しやすくなってきた。
その背景には，情報システムに対する短期開発のニーズがある。開発期間が短いと，カットオーバー後に頻繁に機能の見直しや追加を行うことになる。動いているプログラムに後から手を加えなければならないため，プログラムが汚くなりやすく，アプリケーションの短命化につながる。
「既存のプログラムに手を加えるとプログラムが汚くなる」という問題は今に始まったことではないが，最近の短期開発のニーズによって問題が表面化してきた。“プログラムが荒れる”という問題を避けて通れなくなってきた。
ではどうすれば，この問題を乗り越られるのか。解決策を探るために，まずプログラムがなぜ荒れるのか，その要因を分析してみた。
プログラムが荒れる3つの理由
プログラムが荒れる第1の理由は，設計者の意図がメンテナンス担当者に伝わらないことである。設計者はアプリケーションの全体をデザインし，設計方針を立て，細部のルールを決めていく。このような「デザイン・ポリシー」は設計者の頭の中にあることが多く，明確に記載したドキュメントが存在することは稀（まれ）だ。
アプリケーション開発時は，仕様書や対話でのコミュニケーションを通して何とかデザイン・ポリシーを伝えることができるものの，メンテナンス時にこれらの情報を文書などから正確に読み取ることはまずできない。設計者の意図が伝わらなければ，プログラムは荒れやすい。
第2の理由は，避けるべきだと分かってはいても例外的な処理を加えなければならない場合があることである。適切な修正個所が分かっていたとしても，メンテナンスにかけられる時間や予算が限られる場合，本来修正すべき個所では無いところで修正せざるを得ないことがある。そのようなことが重なると，プログラムが荒れる。
第3の理由は，プログラム構造を変えなければならない機能追加が避けられないことである。設計者が想定していない機能追加が必要になった場合，そもそもそのような機能を想定していないため，既存のプログラム構造を保ったまま機能を加えることは難しい。自ずとプログラムは荒れる。
問題解決のために発想を転換してみる
これらの課題の解決策を探った。すると，従来の常識だけではうまくいかないことが分かってきた。
設計者の意図をメンテナンス担当者に伝えるには，できるだけ詳細な設計書を作成することが基本である。この基本は間違ってはいないものの，それだけでは解決できない。デザイン・ポリシーのようなものは文章だけで伝えることは難しいし，たとえ伝わったとしても確実に守られるとは限らない。
解決するには発想の転換が必要だ。デザイン・ポリシーを伝えるのが難しいならば，デザイン・ポリシーに従ったアプリケーションしか作成できないようにする。
この発想をある程度具現化したものが，「フレームワーク」である。フレームワーク製品はアプリケーションの共通機能を提供するだけでなく，アプリケーションの構造まで決めてしまう製品が多い。個々のプログラマが好き勝手にプログラムの構造を決められないため，デザイン・ポリシーは暗黙のうちに守られる。
例外処理が増えてプログラムが荒れるという問題を解決するには，どこかのタイミングで，最初に作られたプログラムの周りに付け加えられた例外処理を排除し，もう一度きれいなプログラムに作り直すことが解決策として考えられる。しかしこれまでは，動いているプログラムはできるだけ触らない方がいいとされてきた。下手に触ると新たなバグを埋め込んでしまうからだ。このようなこれまでの常識にとらわれていると，プログラムは荒れる一方で，荒れたプログラムを良好な状態に戻すことはできない。
この問題を解決するには，動いているプログラムであっても積極的に手を加えることが必要だ。プログラムをオーバーホールすることで過去の膿（うみ）を吐き出し，プログラムの荒れを元に戻す。ソフトウエア開発手法のXP（Extreme Programming，[用語解説] ）では，プログラムのオーバーホールを「リファクタリング」と呼んで実践項目に入れている。積極的に既存のプログラムに手を加え，プログラムを常に健全な状態にしておく。
従来の設計の常識は，「将来の機能追加を予測して柔軟性の高い設計にしておく」ことである。柔軟性の高い設計は複雑になりやすいが，将来の機能追加がやりやすければプログラムは荒れにくい。この常識はその通りなのだが，行き過ぎるとかえってやっかいな問題を引き起こす。もし予測が外れた場合，採用した設計は，不必要に複雑な設計といえるだろう。時間が経つとなぜそのような設計になっているかが不明瞭になり，プログラムは荒れやすくなる。予測し過ぎるのはリスクが高い。
また，プログラムが荒れる第3の理由にあったように，プログラムの構造を変えなければならない機能追加は避けられない。その場合，複雑な設計である方が，改修が難しくプログラムが荒れやすい。将来必要になる機能の予測が難しいアプリケーションでは，できるだけシンプルな設計を採用する方が得策だ。
確実に必要な機能だけを考え，それらを実現するのに一番シンプルで分かりやすい設計を採用する。そうすれば機能を追加しなければならなくなっても，分かりやすい設計であるため改修しやすい。この“シンプル設計”もXPでは実践項目に入れている。
XPやフレームワークの中には新常識のヒントがある
もちろん，ここで説明した方法がすべてのアプリケーションに最適とは思わない。また，フレームワークの採用やリファクタリングの実施，シンプルな設計には，注意すべき点も多い。
例えば，フレームワークを利用すればアプリケーションの均質化が図れる半面，フレームワークによって実現できることが制限される。リファクタリングは稼働中のプログラムに手を加えるため，品質を確実に維持させることが不可欠だが，それは簡単ではない。シンプル設計を採用すると，小さな機能追加でもプログラム構造の変更を起こしやすく，改修を繰り返すと広い範囲の設計を変えざるを得なくなる。
しかし，ECサイトのように必要な機能が読みにくいアプリケーションでは，従来の常識だけにとらわれているとアプリケーションの短命化を進めることになりかねない。アプリケーション開発に求められるニーズが変わってきているのだから，開発の常識も変えなければならない。フレームワークやXPの中に新常識のヒントが隠されているように思う。
（松山 貴之＝日経オープンシステム）
