フレームワークの伝道師

フレームワークは永遠に変化をし続ける…と、どこかの本で読んだことがある。確かに、実際にフレームワークを作っていると次から次へと変更の必要が出て来る。ログインユーザーに持たせる情報とか、ログ出力の形式とか、画面へのエラーの出し方とか、DBの接続先とか、フレームワークを作るときに決めておいた事でも、後から変更が入る部分は多い。そしてその際、通常の業務処理の作成が楽になることを最優先させるため、フレームワークはクラス同士がかなり複雑に絡み合ってしまう場合が多い。少なくとも、俺の周りでは。
そうやってフレームワークの修正、拡張を行っていくと、フレームワークが作った本人にしかわからないクラス構造になってしまう。使うには使いやすいが、フレームワークを変更するのは○×さんじゃないと無理、というソフトウェア開発の世界にありがちな「悪しき習慣」である。「設計書が無いのがおかしい」と言えば確かにそうだ。しかし、サンプルを作りながら徐々にフレームワークを作っていき、動き始めた段階で業務を作り始めるというスケジュールが引かれることが多い為、きちんとした設計概要や詳細なドキュメントなどを残せることは（俺の場合は）無い。
それに、フレームワークは時として、ある画面の一見なんのことは無い機能の為に、開発真っ只中に大幅な変更を余儀無くされる。自分にはすでにカツカツのスケジュールが引かれているにもかかわらず、さらに表に出ないフレームワークの変更作業がとめどなくやって来る。しかもそれが無いと開発出来ないとか言われると、自分の業務よりも優先せざるを得ない。そして業務の間にこなすため、その変更がドキュメントに反映されることはあまり無い。せいぜいプロジェクトのメーリングリストに変更内容が投げられるだけである。
そうやってフレームワークが変更されていくものだから、フレームワークの作成者はずっとそのプロジェクトに残って変更・拡張を行うはめになる。仮に他人に任せようとすると、クラスの構造から設計思想まで伝えなければならない。これは簡単に出来ることではない。時間も手間もかかる。
こうやって1人又は数人がずっとフレームワークを扱っていると、そのプロジェクトでの「フレームワークの伝道師」になる。フレームワークの伝道師はひとつのプロジェクトで数人しか出来ない上に、一旦伝道師になると次のプロジェクトにも伝道師としての役割を期待されるため、なかなか抜け出すことが出来ない。「設計者とプログラマーは役割が違うだけ」と言いつつ懐に入る金額が違う現状では、フレームワークの伝道師は損な役回りなのかもしれない。
あぁ、一般論っぽく書いたけど、もしかしたらこんなのうちだけなのかも。フレームワークを作っている人の、PMや設計者への啓蒙が無さ過ぎるのかな。って、それって俺の力不足やな…ここまで書いて気づくとは。
話は変わってオフショアの話。「オフショアの究極は実装全投げだ」という話を聞いたことがあるが、全投げってことはこのへんも投げるんだろうか。それってものすごく怖いんだけど…。