【34】60/60 ルール

　私たちはソフトウェア開発がソフトウェアのライフサイクルで一番重要だというふりをよくします。世の中には開発のための方法論があふれています。書籍、雑誌記事、ブログなど、いずれも開発に焦点を当てています。しかし、お金がかかるのは開発だけではありません。

　ソフトウェアシステムにおけるライフサイクルコストの 60% はメンテナンスによるものです。開発にかかるコストは、相対的に 40% にすぎません。もちろん、これは平均での話です。実際のメンテナンスコストは、システムの種類やデプロイ環境によって 40% から 80% まで変動します。メンテナンスコストのうち、平均して 60% がユーザーによる機能強化（要件変更）に、23% が移行アクティビティに、17% がバグ修正に関係しています。

　ライフサイクルコストの 60% がメンテナンスに関係していること、そしてそのメンテナンスの 60% が機能強化に関係しているという事実から、ソフトウェアメンテナンスについてよく言われている「法律」のひとつ、いわゆる 60/60 ルールが生まれました。

　移行アクティビティには、システムを新しいハードウェアやソフトウェア環境に移すことも含まれます。こうした移行もまた、要件変更の 1 つです。そう考えると、興味深い事実に気づきます。メンテナンスアクティビティの 80% は何らかの要件変更に関係しているのです。

　当然ながら、コードを変更するためには、まずコードを理解しなくてはなりません。やるべき変更を理解すること、それがメンテナンスの主たるアクティビティとなります。全メンテナンス時間のだいたい 30% が、既存のソフトウェア製品を理解することに費やされます。これは、要件変更、移行、バグ修正といったメンテナンスすべてに当てはまります。

　他人が書いたコードや自分たちがずっと以前に書いてよく覚えていないコードをメンテナンスするためには、「理解すること」が支払わなければならないコストになります。メンテナンス中は、コードを理解することが、開発中に見られる新たな設計作業の代わりになるのです。

　60/60 ルールはソフトウェア開発だけでなくメンテナンスにも注力しなければならないことを思い出させてくれます。開発アクティビティに注力しすぎると、最高の利益を生み出せないかもしれません。1980 年代初めのベームによる「適切なソフトウェアエンジニアリング規律は欠陥を 75% まで削減できる」という主張は正しいのかもしれません（本当のところ私は疑わしいと思っていますが）。この主張は開発方法論がさかんに議論され、作られた土台となっていました。しかし、それでどうなったでしょうか？

　すぐれた方法論を使うことでバグ（全メンテナンスコストの 17%）は削減できるかもしれませんが、移行、機能強化に要する時間やコストにはまったく対処できていません。メンテナンスコストを削減するためには、コードの理解、新しい要求へのコードの適合、新しい環境へのコード移行などにまつわるコストにも対処する必要があるのです。

　60/60 ルールは、メンテナンス可能なシステムを作ることに全力を注ぐべきだということを示唆しています。私たちのソフトウェアは、変更可能なように設計されなくてはなりません。これによってシステムは新しい要求に直面しても柔軟に対処できるようになります。こうしたシステムを設計することは、ソフトウェアエンジニアリングにおける次の大きな課題の 1 つです。

　私たちは少なくとも、その答えの一部を知っています。Web の各コンポーネントが最後の瞬間に柔軟に結び付けられて動くのと同じように、ソフトウェアコンポーネントもお互いに疎結合である必要があるのです。