フレームワークは「流行っているから」で選ばない|小さく始めて移行する判断基準

「流行っているから」で選んで、遅くなった

技術を選ぶ時、「今、一番流行っているから」という理由で、フレームワークを選んだことがあります。人気があるものなら間違いないだろう、情報も多いだろう、という期待でした。

ところが、実際に使い始めると、次の問題が出てきました。

• 学習コストが大きすぎた:覚えることが多く、本来の目的(作りたいもの)に取りかかるまでに時間がかかった
• 規模に対して、過剰だった:小さなものを作りたいだけなのに、大がかりな仕組みが必要だった
• カスタマイズしにくかった:フレームワークが決めた作法から外れる、細かい要望に対応しづらかった

結果として、開発のスピードは、むしろ落ちました。

うまくいった進め方:小さく始めて、必要になったら移行する

反対に、うまくいったのが、次の進め方です。

1. まずは、小さく、ライブラリで組む
2. 規模が大きくなり、フレームワークの助けが必要だと実感してから、移行を考える

必要性を実感してから移行すると、「なぜこのフレームワークが必要なのか」が、体で分かります。そのため、選ぶ基準もはっきりします。

ライブラリとフレームワークの違いは、「自分から呼び出して使う部品」か、「決められた枠組みの中で書く」かです。詳しくは、フレームワークとライブラリの違いをご覧ください。

選ぶ前に確認したい5つの観点

「流行っているか」ではなく、次の5つの観点で、自分の状況に合うかを確認します。

特に重視しているのが、②の運用です。技術選定では、「最新かどうか」より、「5年後も運用できるか」を見るようにしています。

状況別:こう考える

小さく始めて移行する3つの段階

「小さく始めて、必要になったら移行する」を、具体的な段階で示します。

②の「何に困っているかを書き出す」ことが、一番大事です。困りごとが具体的であるほど、必要な機能が絞られ、選ぶべきフレームワークも、自然に絞り込まれます。

選ぶ前に、チームで話し合う5つの質問

導入を決める前に、次の質問に、全員で答えてみてください。答えが曖昧なままなら、まだ決めるのは早いサインです。

1. このフレームワークで、解決したい問題は何か(「流行っているから」以外で答えられるか)
2. 使わなかった場合に、どんな困りごとが起きるか
3. 学習に必要な時間を、誰が、いつまでに確保するのか
4. 半年後・5年後に、誰が運用・改修するのか
5. 合わなかった時に、やめる方法はあるか

この5つの質問は、フレームワークに限らず、どんな技術を導入する場面にも使えます。**「新しいから」ではなく、「自分たちの問題を解決するから」**選ぶ。この姿勢が、後悔の少ない技術選定につながります。

同じ考え方は、他の技術選定にも使える

同じ失敗は、フレームワークだけではありません。たとえば、**コンテナとVM(仮想マシン)**の選択でも、「新しいからコンテナにする」という判断は危険です。

• 既存のシステムが、VMを前提に安定している
• 運用する担当者が、コンテナの経験がない
• 移行によるメリットが小さい

こうした場合は、VMを使い続けるほうが、現実的な選択になることもあります。違いについては、コンテナとVMの違いで解説しています。「新しいかどうか」ではなく、自分たちが責任を持って運用し続けられるかが、判断の軸です。

移行しやすく作っておく工夫

小さく始める場合でも、将来の移行に備えて、次の点を意識しておくと、後が楽になります。

• 画面の部分・処理の中身・データの扱いを、混ぜずに分けて書く
• 特定のフレームワークにしかない機能に、深く依存しすぎない
• ドキュメントを残す(なぜその技術を選んだのか、という判断の記録も含めて)

「なぜこれを選んだか」の記録は、後任の人にとって、非常に価値があります。選んだ理由が分からないシステムは、変更するのが怖くなり、技術的負債になりやすいからです。

AI時代の技術選定

AIにコードを書いてもらう場面が増え、技術選定の観点も少し変わっています。

• 情報や利用者が多い技術ほど、AIの提案が安定しやすい傾向があります(ただし、AIの提案には、間違いも含まれます)
• AIが出した提案を自分で説明できる範囲で、技術を選ぶことが、ますます重要になります
• AIで作るスピードが上がるほど、「選んだ理由」と「運用の見通し」が、後で効いてきます

AIが書いたコードの確認方法は、AIが書いたコードをそのまま使ってはいけない理由で整理しています。

迷った時に立ち返る一言

迷った時は、「この選択を、半年後の自分や後任の人に、納得のいく言葉で説明できるか」を考えてみてください。「みんな使っているから」ではなく、「この問題を解決するために、この条件で選んだ」と説明できる選択は、後から見直す時にも、判断の拠り所になります。

まとめ

• 「流行っているから」で選ぶと、学習コスト・過剰な機能・カスタマイズのしにくさで、かえって遅くなることがある
• 規模・運用できる人・学習コスト・自由度・やめやすさの5観点で判断する
• 小さくライブラリで始め、必要になってからフレームワークへ移行する
• 技術選定は、**「最新か」ではなく「5年後も運用できるか」**で見る
• 選んだ理由を、記録として残しておく

関連記事:ストラングラーパターンとは