フレームワークの採用は何のため?
先日、フレームワークは採用すべきか?という問い合わせに、「それは、何のためですか?」と質問したら、「開発工数が短縮するためコストは安く抑えられるから」と言われたらしく、見積もり金額は、フレームワークを採用した方が安かったという。

設計仕様が決まらないうちにフレームワークが先に決まる謎

では、設計は完了しているんですね?と尋ねると「いや、設計はこれからです」と言う。
そもそも、フレームワークとは何か判っていますか?と質問すると、「開発工数を短縮させるための作り方や進め方じゃないの?」と言う。まんざら間違いでは無いが、フレームワークは、大工で言ったら、ノコギリやカンナのような道具と思って貰えばよく、どんな家を建てるか決まらないうちに、「この、ノコギリとカンナ、ノミなどが一式揃った大工道具セットで建てますから」と言われたようなもの、もし、設計が進み、鉄筋の三階建てになったら、大工道具セットで鉄筋が建てられるのか?という問題が発生する。しかも、大工道具セットだけで建てるため、それ以外の道具は使えないという制約がある。恐らく、設計が進みフレームワークを逸脱してしまうと、「開発はフレームワークで行う。という契約ですので、こちらは、追加作業、追加金額となりますがよろしいですか?」となる。
そもそも、設計が決まらないうちにフレームワークが決まるのが不思議であり、先に決めてしまうと、フレームワークに合わせて仕様を決めて行くしかない。もし、フレームワークに逸脱した仕様で作成を依頼すると、普通以上に見積もり金額は跳ね上がる覚悟が必要だ。にしても、何も事情を知らないお客さんに、それを押し付けるのはどうかと思う。

開発品質が向上し、将来性がある?

ホントかよ?確かに設計上はね。しかし、運用が始まると、システムは生き物になる。生き物とは、想定外なことが起きてしまいそれに対応していかなければならない。「それは想定外で設計仕様にありませんでした。」とよく聞く言い訳だ。
フレームワークは開発品質を重視しているのであり、運用で発生する想定外は対応しない。なぜなら、想定外は開発品質を落すからで、これは、フレームワークの基本思想では無い。と何処か矛盾が生じている。