俺にはさっぱりわからねぇ
もし、プログラム開発者は コンピュータシステムを開発してしばらくしていなくなり、別のプログラマーが 5年から10年 あるいはもっと長い年月の間、他人の開発したコンピュータシステムをプログラム保守運用し続けるという条件があるのであれば、プログラム開発者は好みのソフトウェア構造を設計して製造してはなりません。ソフトウェア構造は プログラム保守運用を担当する人間が考える、あるいは 想定される平均的なプログラム保守運用担当者に適したものを作らなくてはなりません。
この文章が暗黙的に言っている部分をまとめると
- プログラム開発者と保守担当者が存在し、それぞれ別種の人種らしい(会社も違うかも)
- プログラム開発者は先進的で生産性の高いアーキテクチャがお好み
- (ここは明確ではないが)平均的の保守担当者は、プログラム分野に限ってはあまりスキルが高くない*1
- プログラム開発者好みの生産性の高いアーキテクチャは、何らかの理由で平均的な保守担当者に適していない
- したがって、保守を考えた場合は、平均的な保守運用担当者にあわせた、(妥協した)アーキテクチャを採用しなければなりません
あー確かに今の日本の業務システムの現状ではそうかもしれない。開発と保守で完全に人が入れ替わってることなんてよくあることだし、しょうがない。でも「俺にはさっぱりわからねぇ」*2
アーキテクチャを妥協するより、長期間の保守に耐えうる開発文化(組織やプロセス)を作り上げるほうがいい*3。例えば、繰り返し型開発のようなソフトウェアを小さく作って育ていく漸進的な開発では、開発と保守の垣根は低いし、人員を少しずつ入れ替えたり教育することができると思う。
業務システムのアーキテクチャは開発の組織構造に依存する(Conway's Law)。クソみたいな組織からはクソみたいなアーキテクチャというわけで、その逆もしかり。組織を変えることによってプロダクトのアーキテクチャを変えるという発想は「組織パターン」「プロセスパターン」という形でXPよりも前から考えられていた。
非常に中二病的発言なのは自分で分かってます。でも妥協を続けてジリ貧にならないで、どこかで天井を突き破る必要があると思うんだけどなぁ。なかなか実現できてないですが。
追記: そもそも生産性の高いアーキテクチャは保守性が低いという前提自体に疑問を感じるのだけど、それは置いておきます。
