ソフトウェアのライフサイクルマネジメント - トラブル後は検討のタイミングかも -

物理的な劣化のないソフトウェアには一見必要のなさそうなライフサイクルマネージメントが実際には必要ではないかと思う。ソフトウェアの規模が大きくなり、まったくの新規開発プロジェクトはほとんどなくなった。派生開発であれば母体となるソフトウェア、保守開発であれば前のリリースのソフトウェアに機能拡張の形で開発することがほとんどだ。リプレース案件であれ、既存のものを全て刷新するということはほとんどないだろう。

長期にわたって例外的仕様や例外的処理がたびたび追加されたソフトウェア（の一部）やサブシステムはその役目を終えたと考え、再設計する。システム統合も例外的仕様や例外的処理の追加を含む可能性が高い。たとえば、再設計のコストを20年以上のスパンで吸収できるよう計画する。ソフトウェアの新規開発から破棄までのライフサイクルを定義し破棄の状態に近くなれば、要求仕様の整理や再設計を進める。判断基準としてなんらかのメトリクスをつかってもよい。

「そんなことしてたら、先の開発どころか次の開発の案件もとれない」という状況なのだが、どのみち機能拡張を何度も繰り返せば機能拡張自体が綱渡り状態になる。誰かが貧乏くじをひくことはわかっているが、自分かどうかはわからないのでこのまま進めることが常態化するのは好ましくないと思う。「このバージョンのソフトウェア（の一部）はここまでで役目を終える」というのを早い段階で決めておいてコンセンサスを得ておくべきだと思う。

「この状態でさらに機能追加かよ。。」というソフトウェアが増えてきていることは誰も否定できないと思う。もしもライフサイクルが定義され、「ここまでがんばれば。。」という後ろ盾があれば精神的にもだいぶ違うと思う。ここでも書いたが、旧ルーセント（現アルカテルルーセント）の米国拠点ではレガシーの保守をオフショアし、オンショアでは新製品の設計をしている。これもそのような考え方に基づくものと言えるだろう。

（レアケースの）例外的処理を追加していくと、改変時にその存在の確認が漏れて、適切な処理が抜けてしまったり、例外的処理が期待通り動作するかを試すテストが漏れたりする。その傾向はレアケースになればなるほど、全体に与える影響が小さくなればなるほど強くなるだろう。ここでのレアケースや全体に与える影響は対象ソフトウェア基準の考え方であり、それがどの程度被害を発生するかとか社会的に重要か等とは必ずしも一致しない。

仕様、設計、コードを保守の面からみた「あるべき姿」にできるコスト、時間、後ろ盾があれば問題にならないが、改変にはコストが伴い、テストにも時間がかかる、改変の際に新たな誤りを混入してしまう（デグレード）可能性もある。期待通り動いているものをわざわざ変更して動かなくしてしまうリスクを考えると躊躇するのは当然だ。しかし、これは環境問題と同様で、先のことを考えるならば今手を打っておく必要のあることだと思う。

トラブルが一段落したときは、こういうことを真剣に考えるきっかけになると思う。きっかけは自身のトラブルでも、他者のトラブルでもよいように思うがいかがだろうか。