TL;DR
- 変更が容易であること（保守性が高いこと）を、本書では「保守容易性」と呼ぶ。保守容易性は非機能要件の 1 つだが、機能要件やほかの非機能要件よりも重要である。
- 保守容易性は開発者満足度を高め、開発者満足度と生産性は互いに高め合う。問題の解決策が複数あるときは、一般に保守容易性が最も高まる手段を選べばよい。
- 保守容易性を保つには、アーキテクチャを作り、それを維持することが重要である。
内容
保守容易性とは
保守容易性とは、コードの変更のしやすさのことである。非機能要件の 1 つであり、その中でも最も重要である。変更が容易なソフトウェアは、柔軟性が高く、モジュール化もしやすくなっている可能性が高い。そのため、セキュリティの強化、信頼性の向上、スケールアップ、パフォーマンスの向上といった、ほかの非機能要件にもつながる。
保守容易性によって実装できる機能
ソフトウェア開発で一番重要なのは、ユーザに価値（機能）を提供することである。しかし、保守容易性が低いと、機能を追加するのに多くのコストと時間がかかる。開発者とそれ以外のメンバの間に軋轢も生まれやすく、コミュニケーションコストも膨らむ。そのため、機能要件を満たすことよりも保守容易性のほうが重要であり、保守容易性には投資する価値が十分にある。
「保守性が低いのに成功しているソフトウェアもある」という反論もある。こうしたソフトウェアは、次のどちらかの条件を満たしている。
- ソフトウェアとしての寿命が尽きかけており、変更がほとんど発生しない
- 金銭的に余裕のある組織が所有しており、問題の解決にお金を払うことに抵抗がない
これはBDUFをすべきだという話ではないが、事前にある程度の設計は必要である。アーキテクチャを選び、ソフトウェアの構築が間違った方向に進まないようにする。本書ではヘキサゴナルアーキテクチャを使ってクリーンアーキテクチャを実現する。もちろん銀の弾丸ではないので、すべてのソフトウェアに適しているわけではない。
保守容易性によって高まる開発者満足度
保守容易性が高いと、開発者満足度（developer joy）が高まる。開発者満足度とは、開発者が今の環境に満足しているか、本来の能力を発揮できる環境かを指す。SPACE フレームワークの S（Satisfaction and well-being）にあたり、開発者体験（developer experience）や開発者有効性（developer enablement）とも呼ばれる。
開発者満足度と生産性は互いに作用する。開発者が幸福であれば、より良い仕事をする。逆に、開発者が自分の仕事に誇りを持てれば、満足度も高まる。また、開発者満足度が高まると離職率も下がる。
保守容易性によって変わる意思決定
ある問題を解決する選択肢が複数あるとき、開発者は過去に使ったパターンや原則（DRY、依存性の注入、Builder パターンなど）を慣習的に当てはめて選びがちである。これらのほとんどは保守性を高める効果がある。つまり、開発者が毎日行っている判断には、意識しなくても保守容易性が関わっている。
経験したことのない問題でも、同じように保守容易性が最も高まる手段を選べばよい。もちろん、ほかの一般的な原則と同じく、保守容易性が高まらない手段が最善になる場合もある。
保守容易性の維持
改善したコードが本当に保守性を高めているのか、保守容易性をどう維持するのか。その答えは、アーキテクチャを作り、それを維持することである。優れたアーキテクチャでは、どのようにコードを書けばよいかを簡単に把握できる。そのようなコードは、各コンポーネント間の依存関係が明確で複雑にならないので、機能の追加や修正がしやすい。優れたアーキテクチャは、開発者満足度や生産性の向上、離職率の低下、意思決定に間接的に影響を与える。
キーワード
自分の理解
保守容易性は、要するに保守性が高いかどうかの話である（参考: arc42 Quality Model の Maintainability）。変更しやすければ機能追加もしやすいので、ほかの非機能要件だけでなく機能要件にもつながる。
保守容易性に投資する、というマインドセットをチームメンバ全員で持つことが大事だと思う。これは戦略的プログラミングを採用するということでもある（A Philosophy of Software Design 第3章 Working Code Isn't Enough）。「保守性が低くても成功しているソフトウェアがある」という反論は戦術的プログラミングによるアプローチであり、これも同じ章で書かれていることとほとんど同じである。