今回は、プログラマーとして、プログラミングの話です。
プロのプログラマーとして、現場で感じるリアルなことをそのまま書いちゃいます。
最近、フレームワーク病患者が増えすぎなんじゃ！
と、言われても、全然意味分かんないですよね（汗
まず、フレームワークというものについて。
プログラマーの言うフレームワークというのは「開発の土台」というイメージです。
ゼロからプログラムを書くのではなく、フレームワークと言う開発の土台を持ってきて、その上にプログラムを乗っける...という感じ。
ゼロからプログラムを書くことを「スクラッチ」と言ったりします。
で、スクラッチに対して、フレームワークを使うメリットと言えば...
・ゼロからつくる手間がない
・便利な機能が揃っている
・元々ある機能についてはテストの必要がない
・複数人でも開発の方法が強制的に統一される
など、いろいろあって、大変便利なものなのですが
残念ながら、恐ろしいこともあるのです。
まず、フレームワーク病の問題
簡単に言うと、フレームワークおよびその追加機能に頼り過ぎてしまう病気。
この病気にかかると、そのフレームワークで簡単に実現できること以外、開発ができなくなってしまうのです。
もっと乱雑に言うと、スクラッチでの開発ができなくなるということです。
これには、時代背景が強く関係していると感じています。
・システム開発の需要が年々増加している
・素早く開発しなければいけない
・新人さんを素早く戦力にしたい
こんな背景から、若い世代を中心に「フレームワーク ＝ スキル」と言った感じになってきています。
最初から、フレームワークを使うことしか考えていない。
そんなシステム開発企業も増えています。
それと関係して、もう一つ大きな問題があります。
それは、炎上案件の増加問題
ここで言う「炎上案件」とは、システム開発のプロジェクトが暗礁に乗り上げ、どうにも進まなくなった案件のことを指します。
これには、フレームワーク病が大きく関係しています。
フレームワーク病患者がフレームワークを用いてシステム開発をしたとします。
そして、ひとまずシステムを納品する。
ここまでは問題ないのです。
しかし、納品先のお客さんからは、次々と新たな要望が飛び出してきます。
追加開発の依頼です。
これを続けていくと、システムが複雑化していきます。
そして、フレームワークにある機能では、実現が難しくなることがあります。
その瞬間...
これ以上の追加開発は無理です！
という結末になったりするのです。
そして、お客さんはこう思います。
え？そんなことってある？
残念ながら、あるんですよ...。
実際、このような炎上案件に対して、私オーシマの元へ救いを求めて来る企業が後を絶ちません。
この3年くらいで、一気に増えました。
これらの問題は、大工さんの世界に似ています。
例えば、大手住宅メーカーによるガチガチの規格住宅を建てた経験しかない大工さん。
その大工さんに、自由設計の住宅を建てる依頼をしても、おそらく建てられません。
既存の住宅の増築も無理だと思います。
実際、そんな大工さんが増えていると大工さんから聞きます。
勘違いしてはいけないのは、規格住宅やフレームワークがダメだというわけではありません。
私もフレームワークを使うことは多々あります。
しかし、スクラッチの開発ができないというのは、危ないです。
どのフレームワークも「完璧」ではありませんから。
さて。
この問題に対して、どうするべきでしょうか？
答えは、教育にあります。
というか、最後は必ずそこに行き着きます。
例えば、私オーシマが経営するゲームプログラミング道場では、フレームワークを極力使いません。
子供には難しすぎる部分を少しだけ簡単にしてあげる「小さなフレームワーク」を自社で開発しています。
ほぼ、純粋なスクラッチ開発を学ぶことができるようにしています。
有限会社ワンクリックアイティーとして、システム開発の依頼を受けた時もフレームワークの利用には、慎重になります。
初回に依頼された要望のみではなく、その後に発生するだろう未来の要望を想像します。
お客さんの話、夢、野望をよく聞いてから、フレームワークを使うかを決めます。
カッコいい言い方をすると、こういう判断には、過去の経験とそこで培われたセンスが重要なのです。
フレームワーク病には気を付けましょう！
えっ？
お前が言ってもカッコよくないって？
ごめんなさい！
調子に乗りました (-_- #)
