質とスピード、納品と顧客
和田卓人さんの「質とスピード」が大好きで、何度も読み返す。
この資料では、"雑に速く！"は将来的に逆に遅くなる、と説明しています。
私も開発経験の中で同じ経験は何度かしてきました。
つまるところ、"後先考えないと後で痛い目を見る"、という話です。
「質とスピード」は、
"内部品質を犠牲に開発速度を上げた(ように見せかけた)としても、保守・改修の速度が遅くなるからリリース後に変化に対応できず市場での価値を失いやすいから辞めた方が良い"
ということを説いています。
これを少し視点を変えて考えてみます。
保守性が低いということは、機能を増やしにくい、バグを直しにくい、バグを作り込みやすい、ということです。
変化させるのが難しい状態になるわけですね。
この状態は、変化させることで価値を増やすことができるソフトウェアの特性を損なっている状態とも言えます。
ソフトウェアをLEGOで例えると、
保守性の高いソフトウェアはパーツを組み換えやすいように組んだLEGOのようであり、
保守性が低いソフトウエアはパーツを組み換えにくい、あるいはLEGO同士を接着剤でくっつけたLEGOのようなものと言えます。
保守性の低いソフトウェアは、発注者の要求に応えられないというだけではなく、そもそも発注者の期待していた特性を備えていないということになるわけです。
ソフトウェアを保守・改修することを契約に盛り込んでも、
変化させられるソフトウェアを開発することなんて当然すぎて契約書にも書かれないのではないでしょうか(よく知らないけど)
保守性の低いソフトウェアは、開発のコストを高め自分たちの首を締めるだけではなく、提供先の顧客に対しても"ソフトウェアというものの特性を損なったもの"を提供するということで不誠実な形になります。
どこからが保守性の高いソフトウェアかは現場によると思いますが、"変化させられること"がソフトウェアとして依頼する最大の意味だと思いますので、そこを忘れないように開発をする必要があると考えています。
