内製フレームワーク

私は今、お客さんの懐の内で仕事しているんですが、「内製フレームワーク」で作る開発会社は推しません。


オープンソースで、且つ、充分に普及しているフレームワークを使用して、開発会社にロックインされずに簡単に「すげ替える」事ができるようにしておくことを薦めています。このためにはユーザー側でビジネスロジックをガッチリ握っておく事も必要ですね。


オープンソース」というのはソースが滅多になくならないですし、ほぼ全てが CSV CVS 等のバージョン管理システムで管理されているので特定のバージョンを引き出したり、パッチを当てるのも簡単です。
「充分に普及している」というのは、「情報が流通している」と言い換えられます。シェアは問題ではありません(Seasar2 は既にクリアしていると思います、RailsCatalyst はこれから)。そのスキルを既に備えている人を確保しやすいというのもありますし、知らなくてもウェブで情報がすぐ拾えると引継ぎ要員の学習が容易です。


理由は、開発会社が潰れたり、潰れなくても事業撤退があったり、コスト削減で他の保守・運用を行う会社に切り替えたりする時に引継ぎコストを減らすためです。あと、内製フレームワークの品質が良いか悪いかはユーザー側では判断できません(フレームワークと言わず全てのコードに対して、第3者を入れて監査してもらうと良いと思うのですが、一般的でないし、お金もかかりますし、その監査会社を選ぶ手間等もありますから難しいですね)。より多くの技術者の視線をくぐったフレームワークの方を使いたいです。


ドキュメントがしっかりしてればいいのですが、有用な(書いてある内容がわかる、重要な部分の SYNOPSIS がある・漏れがない)ドキュメント書ける会社は少ないです(あるのか?)。それどころか、ドキュメントがソースだったり、譲られた開発環境でビルドできなかったり、あまつさえソースがなかったりする! なんじゃそら! ……っと、最後は内製フレームワークに限らずあってはならない話ですな。あるけど。


はぶさんの言

あと、エンジニアの育成プランはセットで提案します。当然です。で、それが面倒ならうちが保守サービスしますよ、ってことです。商売だもの(w

これ素晴らしい。これがあれば内製フレームワークでも学習の面では担保できますね。ユーザー企業はこの育成プランもセットで頼むべきです。人から人の情報は長期運用では必ず失われます。配置換えは常だし、いつまでも「卒業」できないのは技術者にとっても不幸です。なにより、ユーザー企業はこの育成プランの過程で作りあげられるドキュメントに着目してもらいたい。


開発のみんな! 保守・運用を考えようぜ!(半泣き)