保守性が大事！

システムがリリースされるとその後は運用保守フェーズに移行します。その後、何の問題もなく運用していければよいのですが、時が経つにつれ必ず「プログラムのバグによるトラブル」や「仕様変更に伴う修正」が定期的に求められます。（もし、全く求められないとすればそのシステムは使われていないのかも？）
どちらのケースであってもプログラムを変更する必要があるのですが、変更にあたってプログラムコードを把握する必要があります。もし、コードを把握せずに修正すると、他の部分に副作用が出てしまい新たなトラブルを起こしてしまう可能性があるからです。

コードを把握するには

教科書通りの手順ですと「設計書を見る」->「コードを見て把握する」->「修正箇所を特定する」という流れになるのですが、長く運用されているシステムであれば「設計書がない」や「あっても実際のプログラムと差異がある」といった状況になっており、設計書がアテにならないこともよくあります。（むしろこっちの方が多いかも）

そうなると、頼りになるのはコードのみでありコードを読み解くことができなければ、不具合対応も仕様変更も対応できないことになってしまいます。こうなるともうそのシステムは「安心して使うことのできない」ものとなり、もはやシステムとは呼べない代物となってしまします。
「そんなことあるの？」と思うかもしれませんが、ほんの数十年前はよくある話でした。このようなことを考慮すると、リリース時にはユーザー要件を満たしていたとしても、「保守しやすいかどうか？」という要素が如何にシステムとして重要な物であるかはご認識いただけることと思います。

保守性向上の為に！

上記のような保守しずらい/できないシステムを「保守性が悪い」といいますが、高度な開発言語、データ中心、オブジェクト指向、構造化、各種設計手法など、システム開発のために生み出された各種理論やツール、手法はそのほとんどが「より保守性の高いシステムを開発する」ために考えられたものです。

プロなら保守性の高いシステムを！

逆に言えば、システム屋にとって「如何に保守性にも配慮してシステムを構築できるか？」ということが重要である認識してください。もちろんユーザー要件に応じた適切なシステムを構築できることも重要ですが、与えられた環境/時間/人員の中で、如何に保守性に関する配慮ができるかが「優秀なシステム屋かどうか？」の分かれ目にもなります。