読者です 読者をやめる 読者になる 読者になる

フレームワークの押し付けはごめん

システム開発をしている会社には社内標準のフレームワークがあることでしょう。
大体新規案件なんかはそれを元に作成することが想定されます。
まぁ、大体EJBやSpring、Seaserなんかを元に作られるんでしょうけど。

お客さんはフレームワークで作られたシステムが欲しいんです。
作られたシステムで業務効率を上げたり、他社との差別化を図りたいんです。

もっと言えば、品質が良くて機能拡張が容易ならどんな言語使っても
実現さえできれば良いんです。

ただ、コストやスケジュールの問題で
作るあなたが実現するのに効果的なツールを使えば良いじゃない、って話なんです。

何で作られているか、最先端の技術を使っているかなんて二の次なんです。



それなのに、作るシステムの内容を十分に聞かずに、
今回はSpringで行きましょう!とかウチのフレームワークで行きましょう!
とか言ってる訳ですよ。

で、実際の案件に投入してみたら、
あんなことができなくて、こんなところではまって。
で、あのフレームワーク使えねぇ、って評価を頂戴するんです。

プロジェクトメンバーの習熟度もあるでしょうけど
「これしか知らない」選択肢で決められたフレームワークよりも
「要件を鑑みてあれこれ調査してみた」結果決められたフレームワークの方が
よっぽどプロジェクトの為になる気がします。


事前にレールを決めておいて、その上を走るだけなら実作業としては楽ですが、
想定外のケースはつき物です。
お客さんの要望をフレームワークの都合でできない、もしくはコストを余計にかけて
いいんでしょうか?


システムの出来は要件ありきだと思うんです。
どんなフレームワークを使っているかは別。
お客さんとの認識をアーキを決める前に合わせなきゃいけない。


ただ、新しいシステムを構築するたびに違うフレームワークを採用していると
保守が大変なのでその辺は注意が必要。

プロジェクトマネージメントも数千万程度の案件だったら、
お客さんを巻き込んで、動くものをできたそばから見せていくことで
失敗率はかなり下がると思うんですけどね。
(もっと大きいのは意思決定が遅くてフットワークがよくないでしょうね)


フレームワークの出来を比べるのもいいですが、
要件を引き出す腕も養いましょうね、ということです。