「変更容易性の2層モデル」というアイデアについて少し前にブログに書いたが、あれから考え続けたところ違う景色が見えてきた。そのアップデートを反映した「変更容易性の二元モデル」について書いておきたい。
レイヤーモデルの課題
2層モデルは、変更容易性が2つの層で構成されていると説明する。この見方が完全に間違っていたとは思わないが、2つの変更容易性の関係をうまく言い表せていないことは課題だった。
レイヤーモデルは依存関係の一方向性を含意する。フロントエンドとバックエンドのように、上位のレイヤーは下位のレイヤーに依存するが、逆はない。変更容易性の2層モデルでは、予期的変更容易性が下層であり、経験的変更容易性が上層という説明になるが、これは実態に即していない。
2つの変更容易性は相互に影響を与える。変更に対する恐怖・不安が少なくなることで、変更の頻度が増えることが考えられる。しかし、構造が変わらないまま変更の頻度が上がれば、メンテナンスのコストは高くなる。新しい変動性に適応するように構造が調整されていないからだ。また、変更のコストが低くなると、変更に対する不安も小さくなる。予期的変更容易性と経験的変更容易性の関係は双方向的だ。
本質的には、変更容易性の阻害要因を恐怖・不安と、変更にかかる労力・コストのふたつの観点に分解するというコンセプトは的を射たものだと考えているため、上記の課題はあくまでもモデルの命名・表現レベルである。そこでたどり着いたのが、変更容易性の二元モデルである。
変更容易性の二元モデル
新しいモデルでは、変更容易性を阻害する要因によって二分化するものとした。それが、心理的変更容易性と、物理的変更容易性である。
心理的変更容易性 / Psychological Modifiability
心理的変更容易性は、変更を加えることに対する心理的な抵抗の少なさである。不安が小さいほど心理的変更容易性は高い。だが、心理的な抵抗を与えるのは不安だけでない。典型的には、次のよう状況は心理的な抵抗を大きくするだろう。
- 複雑性が高く、変更の影響範囲が予測できない
- 知識・経験の不足により、変更の手順の見通しが立たない
- 変更が失敗したときのリスクが大きい
- 作業が煩雑で認知負荷が高く、ストレスが大きい
予期的変更容易性とほとんど同じ定義だが、心理的変更容易性には時間的な含意はない。現実には、不安は変更をおこなう前だけでなく着手してからも続く。開発者はデグレに怯えながらおそるおそる変更をおこなっている。また、不安だけでなく認知負荷という心理的な抵抗についても捉える必要があった。そこで、この観点を心理的変更容易性として定義しなおした。
物理的変更容易性 / Physical Modifiability
物理的変更容易性は、変更にかかる労力の度合いだ。単純に変更コストと読みかえてもいいだろう。変更コストが低いほど物理的変更容易性は高い。労力は開発者がソフトウェアから受け取る変更への抵抗である。典型的には、次のような要因が変更のコストを大きくする。
- 変更されるコードの量が大きい
- 変更の影響範囲が大きい（検証コストの増加）
- 安全でない変更により引き起こされるバグの修正（追加コスト）
こちらも経験的変更容易性と似た定義だが、抵抗の結果として発生する物理的なコスト、人的・金銭的・時間的コストに重心を寄せている。変更コストの高いレガシーシステムでも、長く保守を続ける人間はその状況にある程度慣れてしまう。こちらの次元においては主観的な抵抗感よりも客観的な経済性に着目するため、物理的変更容易性として定義しなおした。
変更容易性の四象限
レイヤーモデルではなく二元モデルになったことで、変更容易性の状態を四象限で捉えることができるようになった。
心理的変更容易性と物理的変更容易性がともに高い状態は、言うまでもなく理想的なソフトウェアの状態である。変更を加えることを開発者は歓迎し、その労力も少ない。ソフトウェアとしての存在意義をもっとも体現している状態だ。
逆に、どちらも低い状態はもはや変更できないソフトウェアであり、Peter Naurのいうところの「プログラムの死」だ。誰もこのソフトウェアを変更したいと思えず、やむを得ず変更するとなれば地獄が待っている。
心理的変更容易性だけが低い状態は何を意味するか。変更自体は簡単だが、それに携わる開発者は不安やストレスを感じている。例えば、テストが少なかったり、複雑な結合により影響範囲が広がりやすいことを知っている状態だ。できなくはないがなるべく触りたくない、そんな関係を表すのがこの象限である。
物理的変更容易性だけが低い状態は何を意味するか。変更を恐れてはいないが、スムーズに変更が進むわけではない。テストは十分にあり簡単に壊れはしないが、変更にかかるコストは大きい。柔軟性に欠けた状態だ。だが、開発者はそんなものだろうとそのソフトウェアの設計上の問題を諦めている。この象限が表すのはリファクタリングの停滞、設計の固定化である。
どのようにモデルを使うか
この二元モデルと四象限図を使えば、チームが変更容易性に課題を感じたときの分析に役立つだろう。心理的変更容易性が低いと感じているなら、その不安・忌避感の出どころを特定しなければならない。物理的変更容易性が低いと感じているなら、変更コストを高めている設計上の歪みを特定しなければならない。ボトルネックに集中して対処することを助けてくれる。
もちろん、二つの変更容易性は相互に影響し合うし、同じ原因に行き着くこともあるだろう。不安によって必要以上に防御的になることが変更コストを高めることもあるし、複雑に絡み合ったコードを整理する中で理解が進み、変更する不安が軽くなることもある。どちらかだけが課題となることは稀で、どちらのほうがより強く感じられるかというグラデーションになる。
変更容易性はある・なしの二値でないし、構造だけが決めるのではない。開発者とソフトウェアの関係であり、チェックリストを満たせば100点になるようなものではない。重要なのは、このソフトウェアは十分にソフトか？と問い続ける姿勢であり、実践する習慣だろう。そのための型のひとつが、テスト駆動開発である。