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の各コンポーネントが最後の瞬間に柔軟に結び付けられて動くのと同じように、ソフトウェアコンポーネントもお互いに疎結合である必要があるのです。