TSKaigi 2026「いつテストを書くか？」より。
ソフトウェアの本質的な特性は変更容易性であり、それはソフトウェアと人間との関係性に左右されるということをここまで見てきた。ではその関係性とはどのように観測されるものか？どのように評価されうるものか？
変更容易性の2層モデル
ここでは変更容易性を2つの層から成るものだと考え、独自の概念を導入する。
- 予期的変更容易性 (“Expected Modifiability”)
- 経験的変更容易性 (“Experienced Modifiability”)
予期的変更容易性
予期的変更容易性とは、変更をおこなう前に抱く「変更のしやすさ」の感覚である。人間が、あるソフトウェアに対して変更をおこなうことを想像したときに、それを容易そうだと思えるかどうかで抱く感情は大きく変わる。具体的には、以下のような予期が考えられる。
- 変更に必要な作業に対する予期
- 変更の影響範囲に対する予期
- 変更が成功する確率に対する予期
- 変更が失敗したときのリスクに対する予期
これらの予期は、大きく分けて2種類の結果をもたらす。安心か、恐怖だ。容易そうだと思えれば、それを引き受けることになっても安心して取り組めるが、困難そうだと思えば、できれば引き受けたくないと思うだろう。
言い換えれば、予期的変更容易性とは開発者がソフトウェアに抱く不安・恐怖の程度である。開発者がそのソフトウェアを変更することに安心できているのであれば、予期的変更容易性が高いといえる。逆に、そのソフトウェアの変更に不安を感じるのであれば、それは予期的変更容易性の低さを表している。
Robert C. Martin は「恐怖」についてこう書いている。
恐怖はコードに腐敗をもたらす。誰もクリーンにしない。誰も改善しない。変更を余儀なくされたら、システムにとって最善の方法ではなく、プログラマーにとって最も安全な方法によって変更される。設計は劣化する。コードは腐敗する。チームの生産性はゼロになるまで低下する。
― Robert C. Martin『Clean Craftsmanship 規律、基準、倫理』角征典訳、KADOKAWA、2022、p.50
経験的変更容易性
一方、経験的変更容易性とは、変更をおこなう中で経験する「変更のしやすさ」の感覚である。変更をおこなう当事者となり、ソースコードと向き合ったときに感じるものだ。具体的には、以下のような経験に関係する。
- 変更にどれくらいの労力がかかったか
- 変更が影響した範囲、影響の大きさ
- 変更が引き起こした副作用
経験的変更容易性が高いというのは、変更に労力がかからず、変更の影響範囲は小さく、想定外の副作用が起きないような状態だ。そういうとき、変更はなめらかに進み、開発者は自信をもって作業ができる。その逆の事態、変更に大きな労力がかかり、影響範囲が広く、予期しない副作用が起きるようなら、経験的変更容易性は低い状態だ。開発者は思うように変更作業が進まないことでストレスを感じるだろう。
つまり、経験的変更容易性とは、開発者がソフトウェアから受け取る「変更への抵抗」の程度である。摩擦と言ってもいいだろう。
2つの変更容易性の両立
変更容易性を2層モデルで考えるということは、ソフトウェアが「ソフト」である状態を、この予期的変更容易性と経験的変更容易性が両立している状態であると考えることだ。これは、ソフトウェアを変更しつづけるための必要条件を意味している。それは、変更の機会があることと、変更が合理的であることだ。
変更が容易そうだと思えることで、変更の機会は増える。予期的変更容易性が低い=変更するのが不安であれば、変更は慎重になる。スピードは落ち、できれば少ない変更回数で済まそうとするだろう。そうすると一回の変更に詰め込まれる内容も大きくなり、影響範囲も読みづらくなる。この関係はソフトウェアをハード化させるものだ。
また、経験的変更容易性が低い=変更に対して抵抗が大きければ、より多くの労力を必要とする。それはそのまま人的コスト、時間的コストに響く。抵抗が大きいほど、その変更は経済合理性を失っていく。その果てにあるのは、いわゆる「作り直したほうが早い」という事態だ。それはソフトウェアの死そのものだろう。
この2つは必ずしも常に両立しない。どれだけ変更しやすくしようと設計を磨いても、変更しやすそうだと思えなければ片手落ちだ。逆に、思い込みや理解不足から変更しやすそうだと思っていたら、想像以上に大変だったということもある。その経験はトラウマのように次の変更を躊躇させる。予期的変更容易性と経験的変更容易性は両輪そろってはじめてソフトウェアをソフトにする。だからこそ、ソフトウェアアーキテクチャとは、この両立を実現する構造を目指すものである。