現代的なというか、近代的なウェブ開発において、ノンフレームワークという選択肢はまず存在しない。
これは集団開発において、フレームワークなしだと書き方にばらつきが出るという理由も大きいが、汎用的な言語がもともと持っている語彙（ライブラリや機能群）では貧弱すぎるという問題もある。
良くも悪くもウェブが一般化した90年代後半から20年ほどを経て、ウェブ開発はかなり習熟を見せてきたように思う。
これは多くのベストプラクティスが出揃ってきた、と言い換えてもいいかもしれない。
ミドルウェアの構成などもだいぶ洗練されてきたので、フレームワークに求められる機能は大体固定的になってきた（特にサーバサイドは）。
とはいえフレームワーク自体もソフトウェア製品である以上、ライフサイクルがあり、開発が終わることもあれば、終わらないまでも「ちょっと大丈夫か？」と思うレベルで開発が停滞することもある。
そんなときに利用するフレームワークの乗り換えという、正直開発者的にはあまり乗らない仕事が発生してしまう。
何故気が乗らないかというと、乗り換え自体は生産的な活動ではないにもかかわらず、学習負荷は大抵の場合それなりに重く、やっている間はありとあらゆる機能の開発が低速化してしまうからだ。
フレームワークマニアみたいな人種もいて、次から次へと様々なフレームワークを物色しているが、特別な例だと思う。
さてそんな面倒くさいフレームワーク乗り換えだが、以前の私は学習期間を設けて実戦投入していた。
ザーッとチュートリアルをこなし、ドキュメントを端から読んで、内部実装をちょろっと読みつつ小さなアプリを作る、みたいなやり方だ。
でも最近の私の結論は表題の通り「いきなり実戦投入」である。
もちろん世の中にそれなりに実績があるフレームワークであり、目的達成は間違いなく可能だ、という場合に限る。PoC(Proof of Concept)とは意味が違うのでそこはまず理解しておいてほしい。
結局チュートリアルはフレームワークにとって都合の良い仕様なので、本当に一日程度でさっと流すレベルであればいいが、本番で「ここはこう動かしたい」という細かいカスタムのときに結局かなり時間を使ってしまう。
であれば最初から実戦に放り込んでしまったほうがマシだ。
納期がゆるゆるな案件を適当に取ってきて、実験台にしてしまうのが個人的にベスト。
どうせディスカウントを全く求められないということはあまりないので、品質は守るという約束はした上で（当たり前すぎるが）、実験台にすることを口実にしてしまえばいい。
多少なりとも予算が付けばなんとかなることもある（試験環境を構築したり必要な資料を買ったりとか）。
振り返って見るに、結局フリーになってからは案件ベース学習がほとんどだ。なにかと腰が重い自分にはこれがいいのかもしれない。
勉強したい分野なら、自分がド素人であってもとりあえず受けてから考えればいい・・ように思う。
ここまで書いてふと思い出したのだが、そういえば学生のときに初めて個人で取った仕事もとりあえずできると言って契約してから帰りに本屋で資料を買って帰ったのだった。
何が言いたいのか最終的にまとめておくと、
「あ～〇〇勉強しないとな～。てか仕事で使いたいんだよな～。でも勉強する時間ないわ～」みたいな人はとりあえず先に実戦投入してから泥縄式で勉強するのが早いぞ！ってこと。
頑張れ。
コメント