たとえるなら
カレーを作るときのカレールーです。スパイスの調合（誰が作っても必要な下準備）はルーに任せて、あなたは具材選びや辛さの調整（そのサービスならではの部分）に集中できます。ゼロから調合するより速く、味も安定します。
もう少しくわしく
フレームワーク（framework）は「骨組み」という意味で、アプリ開発でいつも必要になる土台部分を、あらかじめ組み立てておいてくれる開発キットです。ログイン処理、データベースとのやりとり、画面表示の仕組みなど、どんなサービスでも必要になる部分は世界共通です。それを毎回ゼロから書くのは無駄なので、先人たちが土台としてまとめてくれました。多くの開発者に使われ、改良を重ねてきたものが定番として残っています。
土台に何が入っているかを具体的に言うと、画面の住所（URL）と処理の対応づけ、入力内容のチェック、データベースの読み書き、ログイン状態の管理、不正なアクセスへの備えなどです。加えて、どのファイルをどこに置くかという置き場所の決めごとまで用意されています。Webの画面側で有名なReactやVue.js、サーバー側で有名なRuby on RailsやLaravelなどが代表例です。
よく混同されるのがライブラリとの違いです。ライブラリは必要なときに自分から呼び出して使う部品で、主導権は書く側にあります。フレームワークは逆で、用意された枠組みに自分のコードを差し込む形になり、主導権は土台の側にあります。同じ「他人が作ったもの」でも、土台は開発の進め方そのものを決めるのに対し、部品は必要な一か所で使うだけという差があります。
現場では、プロジェクトの立ち上げのときに使うフレームワークを決めます。判断材料になるのは、作るものの性質、チームの経験、そして今後も使われ続けそうかどうかです。いったん決めると途中で乗り換えるのは大工事になるため、この選定には時間をかけます。決まったあとは、その土台のお作法に沿って各自が機能を作っていきます。会社によっては、自社で作った独自の土台を代々使い続けている現場もあります。
落とし穴の代表は、お作法を無視して自己流で書くことです。土台が用意している仕組みを使わず独自に作り込むと、便利さを捨てるうえに、後から入った人が読めないコードになります。もうひとつは、新しい版への更新を後回しにすること。放置するほど更新の手間は増え、見つかったセキュリティ上の弱点も直せないままになります。更新が止まった土台を使い続け、扱える人も情報も見つからなくなる現場もあります。
働きはじめたばかりの人は、まず配属先で使われている土台のお作法を覚えることから始めるのが近道です。公式の解説に沿って小さなものをひとつ作ってみると、全体像がつかめます。エンジニアではない立場の人は、「うちは何を使っているのか」を知っておくと相談がかみ合いやすくなります。名前を聞いても分からないときは、「それは画面側ですか、サーバー側ですか」と尋ねると話が整理できます。
求人票に「React経験者歓迎」と書かれるほど、どのフレームワークを使えるかはスキルの目安として扱われます。ただし土台の考え方には共通点が多く、ひとつを深く使えるようになれば別のものにも応用が利きます。名前をたくさん並べられるより、ひとつを仕組みごと理解しているほうが長く効きます。どんな場面で土台に助けられたかを自分の言葉で話せると、経験として伝わります。
現場での使われ方
「このサイト、フレームワークは何を使ってるんですか？」
開発の土台に何を採用しているかという質問です。答えによって、開発のしやすさ、必要な人材、他の会社に引き継げるかまで変わります。技術選定と呼ばれる大事な判断です。
「フレームワークのお作法に従って書いてください」
土台ごとに推奨される書き方があるので、自己流ではなくそれに合わせてほしいという指示です。自己流のほうが速く見えても、後から読む人が必ず迷います。
「フレームワークのバージョンを上げる作業を入れたいです」
土台を新しい版に更新したいという相談です。新機能が増えるわけではないので後回しにされがちですが、放置するほど手間が増え、弱点も残り続けます。
「そこはフレームワークがやってくれるので、書かなくて大丈夫です」
自分で作り込もうとしていた処理が、すでに土台に用意されていたという指摘です。新人がよく受ける助言で、まずは何が揃っているかを知るのが先です。
よくある質問
フレームワークとライブラリの違いは何ですか？
ライブラリは「必要なときに呼び出して使う部品」、フレームワークは「その上に乗って開発する土台」です。部品は自分が主導して使いますが、土台の上では枠組みのルールに従って書くことになります。「呼び出すのがライブラリ、呼び出されるのがフレームワーク」と言われる主導権の違いです。
フレームワークを使わない開発もありますか？
あります。ごく小さなプログラムや、特別な性能が求められる場合はあえて使わないこともあります。ただし業務でのWeb開発では、何らかのフレームワークを使うのが一般的です。使わない選択をするときは、なぜそうするのかと、誰が保守するのかをチームで決めておく必要があります。
フレームワークはどれから学べばいいですか？
自分が入る現場や志望先で使われているものを選ぶのが、いちばん無駄がありません。決まっていない場合は、作りたいものに近い分野で広く使われているものを選ぶとよいでしょう。焦って何種類も手をつけるより、ひとつを最後まで仕上げるほうが確実に力になります。
フレームワークは途中で別のものに変えられますか？
できますが、作り直しに近い作業になります。フレームワークは書き方そのものを決める土台なので、変えると多くのコードに手を入れることになるためです。どうしても変えるときは、影響する範囲を小さく切って順番に置き換えていくのが現実的な進め方です。乗り換えの費用に見合うかを、先に確かめるのが筋です。
フレームワークを使うと何がどう速くなるのですか？
どのサービスにも必要な共通部分を書く時間が省けます。さらに、書き方が統一されるので他の人のコードを読む時間も短くなります。大勢に使われて鍛えられた仕組みなので、自作より不具合や弱点が生まれにくいという安全面の利点もあります。はじめに覚える時間はかかりますが、そこを越えると差が出ます。
