開発環境を揃える方法や、dbを操作する方法を初めから知っていた場合、最初からそっちを使った方が早いとすら思ってしまいます
おそらくフレームワークの学習コストのことを仰っているのだと推察しますが、
そこは開発期間や納期との兼ね合いもあるかと思います。
ただ、「dbを操作する方法を初めから知っていた」としても、実際はその「dbを操作する仕組み」を作っていかなければなりませんよね。
開発は1人で行うことはほとんどありません。その仕組みを作ったとしても結局のところ他のメンバーがその部分を理解して使わなければなりません。
いわゆる「オレオレフレームワーク」は往々にしてマニュアルが残りません。
例えマニュアルがあったとしてもメンバーが好き勝手に機能追加していく内にマニュアルがメンテナンスされなくなっていきます。
最初に基盤を作った人がいつまでもいればいいですが、いつかはいなくなります。
そうなったときに「最初に作った人すら全て把握しきれていない」現象も起きて、引継ぎも満足にできないまま次のメンバーに引き渡されます。
そうなるとマニュアルも残っていない(最新ではない)ため、結局ソースコードを見て理解するしかなくなりますよね。
その時間は非常に無駄です。例え熟練者であっても他人のコードを完全に理解して、作った人と同様以上に使いこなすのは難しいです。
で、あれば、定期的に正しくバージョンアップが行われ、必要な機能は最初からきちんと揃っている
マニュアルも常に最新化されている著名なフレームワークを利用する方が比べ物にならないくらい後々のメンテナンス性含めて高いパフォーマンスを発揮できることは間違いありません。
もちろん「オレオレフレームワーク」であっても、きちんと役割分担がされていてメンテナンスがされていてマニュアルも過不足無く更新されていれば問題は少ないかと思いますが。
それとこれとはまた別問題なので割愛させていただきます。
モデルとビューと、コントローラーを分けけたところで、そんなに便利でしょうか
先に「開発は1人で行うことはほとんどありません」と書きました。
スポーツに例えると分かりやすいかもしれません。
団体スポーツには殆ど「ポジション」というのが存在します。
野球ではピッチャー・キャッチャー・・・サッカーではキーパー・フォワード・・・
バスケットでは・・・●●では・・・。
サッカーやバスケットでは昔はなかった概念が入ってきたりで内部的には更に細かくなっていることもありますね。
それは「状況にあわせた役割分担」と捉えて差し支えないです。
全て1人で行うのでなければ必ず役割分担をする必要がでてきます。
別の人が同時に同じコードを修正するようなことは基本的にあってはいけません。
モデル・ビュー・コントローラはその大枠であり、わけることにより、それぞれの役割がはっきりします。
オブジェクト指向もそう考えて差し支えないかと思います。
もちろん全て1つのクラスに詰め込むなり、クラスを作らずメソッドだけで乗り切ることも可能です。
でもそれは、「どこに何がどのような意図で存在する」というのを「作った人以外知らない。もしかしたら作った人すら数ヵ月後には覚えてない」ような状態となります。
質問者さんが仰る「フレームワークなしで長年推し進められてきたウェブサービスを一人で抱え込んだとき、その中身に散らかりっぷりに戸惑った経験があります」がまさにそれに近いのではないでしょうか。
きちんと役割分担がされていれば、その戸惑いも少なくなり、抱えたときに自身の役割に集中できるのではないでしょうか。
フレームワークを知っていると、このようなことがなくなり
ではなく「フレームワークでシステムが構築されていると」です。
幾らフレームワークを知っていても熟練者であっても何年もレガシーな状態で更新されてきたシステムを
全てフレームワークに置き換えるのは困難です(まれにそういう案件に出くわして辛い目にあいます)
フレームワークは比較的中規模なプロジェクト、もしくは自分以外のエンジニアが引き続き改修していく予定が初めからあるプロジェクトになって初めて威力を発揮するもので、フレームワークの利便性を感じることができるのは、チームプロジェクトの中のみということになりますか
ちょっとゴチャゴチャしていますね。
「レガシーシステムを全てフレームワークに置き換えるのは困難」と1つ前に書きましたが、
不可能ではありません。
ただそれはとても時間(とお金と人)がかかるものであり、それだけの労力をかけた上で、
それまでのレガシー状態を凌駕するほどのメリットが提案できれば置き換えることもあります。
レガシーでなくても様々な理由で(例えばバグやセキュリティリスク)元々載っていたフレームワークを
全て別のフレームワークに載せかえるようなことも頻繁に行われています。
プログラミングで作られたシステム自体は、「モノ」ではないのでそれ自体は劣化しませんが、
それを作る「ヒト」は日々衰えていくものですし、使う「ヒト」も入れ替わっていき、
技術は日進月歩で進化し、また抱えるリスクや脅威も変化していきます。
何も改修が永遠に行われないシステムなど皆無ですし、同じく自分以外のエンジニアが全く関わらないシステムも皆無です。
「作ったら終わり」のシステムは何1つなくて、むしろ作った後が大事です。
PHPでの提示が多いようなので、PHPで例えると、
PHP自体のバージョンのサポート切れによる対応などは今まさに迫っているものではないでしょうか(PHP 5.6は2018年末まで。参考:PHPのリリース日とサポート期限)
社内で使っているだけの仕組みならいざ知らず、全世界からアクセス可能なところに公開されているものでしたら、
サポート切れによる様々なリスクに対応するため、システムだけでなく言語自体もバージョンアップしなければなりません。
最新のフレームワークであればその辺りの対応もしていっていますし、フレームワークのバージョンアップによる違いのところだけを吸収できれば載せかえも容易です。
そういった「言語のサポート期限」といった面からもフレームワークを選択するメリットは大きいと私は思います。
というのを踏まえておそらく本題と思われる質問へ回答します。
フレームワークの利便性を理解するためにはチーム開発に参加する必要がありますか
利便性の理解自体はどこであろうとなんでろうと関係ないので、チーム開発に参加して初めて得られる・そうしないと得られない という必要性はありません。
むしろ、利便性を理解してからチーム開発に入られた方が良いかと。順序が逆ですね。
チーム開発に参加するということは役割分担された上で成果が求められます。
勉強のために開発を行うわけではありません。顧客に満足していただきその対価をいただくためです。
だからといってチーム開発の経験がないからと恥ずかしいと思う必要もないと思います。
そういう機会に恵まれなかったとか、学生とか、個人でやってるとか 様々事情がありますしね。
質問者さんがどういう境遇の方か知りませんが、やり方は間違わないで欲しいな と思います。
フレームワークをしっかり扱っていくにはそのフレームワークの根本である言語の知識・技術は不可欠です。
その知識・技術をきちんと身につけていけば、フレームワークのメリット(もちろんデメリットも)見えてくるのではないでしょうか。
あとは、自身の言語習得レベルとあわせてフレームワークへの理解を深めていければ良いと思います。