「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)

(via 平鍋さんの日記)
正論だと思いました.
もちろん，「保守しやすい」＝「よい設計」ということではなく，
「よい設計」を構成する一要素としてのSupportability(EoM)という位置づけ
だと思っています(それでいいはず，たぶん).

しかしながら，現実のプロジェクト(というか，自分が関わるようなプロジェクト)では，
このような品質は真っ先に切り捨てられるんですよね.
それはやはり，コストがかかるからです.
TDDは1つのプロジェクトチームが継続的にシステムを進化させるのに威力を
発揮するのだと思います。逆にそのようなことが念頭にない場合，
例えば受注範囲が詳細設計〜製造〜テストまでで，サービスのリリースや
その後の保守などお構いなし，なんて場合には「無駄な作業」とみなされます.

そんな状況で，一人一人のプログラマがEoMを実践できるか？
実践すべし，というのが正論なんでしょうけど，難しいかなというのが本音です.
もちろん個人的には大賛成なんですけどね.
ただチームのみんなに布教活動するのは結構しんどいかも.
だって人それぞれ，価値観って違うじゃないですか？
自分の場合は，少しでも良い仕事がしたい，改善したいってのがありますが，
与えられた仕事を確実にこなす，ってことに価値を持つ人がいるかもしれないし.
そういう人に対して，それでいいの？って考えなくもないけど，
別に間違ってるってわけでもないんですよね.
たぶん自分の会社なんかだと，そういう人のほうが扱いやすいし良かったりして？

EoMについては，発注側が受注条件として提示するようにならないと
定着しないのでは，というのが個人的な感想です.
で，それがどれだけ先の話になるかというと
……意外と近い将来に訪れるかもと思っています.
自分はその日のために工具を磨き続けたいと思います.