なぜフレームワークを使うのか？
Web アプリケーションの開発においてフレームワークはもはや必須となりました。
しかし、フレームワークは Web アプリケーションだけのものではありません。そもそもフレームワークって何なんでしょう？
今回は「フレームワーク」全般について考えてみたいと思います。
そもそもフレームワークとは？
プログラミングの勉強や仕事をしていると、フレームワークといえば、「ああ、(Spring | Laravel | Rails | Django | React | Vue.js) のことでしょう？」という感じだと思います。
みなさんひとつやふたつはフレームワークが思い浮かぶのではないでしょうか。
しかし、フレームワークはプログラミングの世界のものだけではありません。
ビジネスとソフトウェアのフレームワーク
「フレームワークとは」でググってみると、ソフトウェア以外にもビジネスにおけるフレームワークの話も出てきます。
ビジネスにおけるフレームワークは課題解決や意思決定、分析などを論理的に思考するためのツールを指します。
一方、ソフトウェアにおけるフレームワークはある課題に対して定型的な処理やデータ構造をまとめたものです。
概要だけでは共通点はなさそうに思えますが、ちゃんとあります。
それは「枠組みにはめて思考 (開発) する」という点です。
例を挙げてみましょう。
ビジネスフレームワークのひとつとして PDCA というのがあります。
PDCA は PLAN (計画), DO (実行), CHECK (評価), ACTION (改善) のサイクルを繰り返し行うことで目標に達成しようというフレームワークです。
「計画して実行する」ところまでよく行われますが、その後の「評価」と「改善」まで手が回らず、やるだけやって終わり！、になってしまうのはよくあるパターンです
しかし、これでは継続的な改善を行うことができません。
そこで PDCA というフレームワークを用い、枠にはめることによって、半強制的にやったことに対する評価・改善を行います。
ソフトウェアのフレームワークとして Web アプリケーションフレームワークを考えてみましょう。
ここでいう Web アプリケーションフレームワークとは Web アプリケーションのバックエンドのフレームワークを指すことにします。
PHP の Laravel や Ruby の Ruby on Rails などですね。
バックエンドは、
- ブラウザーからリクエストを受け取る。
- 受け取ったリクエストを元にいろいろやる。
- いろいろやった結果をレスポンスとして返す。
というのが一般的な処理の流れです。
リクエストやレスポンスを扱うには定型的な処理を行う必要があるのですが、それを Web アプリケーションフレームワークがうまく隠蔽し、必要な処理を書いておけば、適切なタイミングでそれを呼び出してくれます。
このように枠にはめて考えたり、開発したりするのが「フレームワークを使う」ということになります。
フレームワークとライブラリの違い
フレームワークはかなり規模の大きなソフトウェアなのでライブラリとしての側面も兼ねます。なので、一概に説明するのは難しいのですが、フレームワークとライブラリの違いをあえてざっくり説明するなら、
と言うことができます。
これはコードを書くときの違いですが、それぞれの性質をよく表した結果でもあります。
フレームワークは特定の処理に対する全体のフローを管理します。
Web アプリケーションであれば、ブラウザーからリクエストを受け取って、何かやって、レスポンスを返す、というフローですね。
フレームワークを使っていない場合はこれらのフローをすべて自分で制御しなければなりません。
しかし、フレームワークを使うと「何かをやって」の部分だけを書いておけば、それが適切なタイミングで呼び出されます。
つまり、こちらから何かアクションを起こさなくてもフレームワークが勝手に動いてくれるわけです。
これに対し、ライブラリはこちらが呼び出さない限り、何かをしてくれることはありません。
これは良し悪しの問題ではなく、フレームワークとライブラリは役割が違うということを意味しています。
自ら枠にハマる
ビジネスであれ、ソフトウェアであれ、フレームワークを使う上で重要なのは「自ら枠にハマっている」ことを意識する ことです。
この視点がないと、「フレームワークはルールばかり押し付ける窮屈なもの」になってしまいます。
言いかえると、フレームワークを使うということはルールを決めてもらう、ということにほかなりません。
なぜフレームワークを使うのか？
近年の Web アプリケーションの開発において、「どのフレームワークを使うか」という選択はあっても、「フレームワークを使わない」という選択はまずありません。
フレームワークを使わないのはおそらく初期の学習段階ぐらいです。
フレームワークを使うデメリットとしてよく挙げられるのが、学習コストの高さですが、それは大したことではありません。
フレームワークを使うとどんなメリットがあるのでしょうか？
巨人の肩に立つ
「巨人の肩に立つ」というのは、先人の積み重ねた業績をもとに何かを成し遂げることを言います。
現代のフレームワークは過去と現在の多くの優秀のプログラマーが知見を積み重ね、作り上げたソフトウェアです。
それは十中八九、僕を含めた多くのエンジニアが個人で作ったものよりも優秀です。
もちろん間違いがないとは言えませんが、その場合でも多くのフレームワーク(の開発者)に意見し、改善していくことができます。
車輪の再発明を避ける
「車輪の再発明」とは、すでに公開されている機能を一から開発することを言います。
ライブラリも同じですが、公開されたフレームワークはたくさんの人の目に触れ、継続して改善されます。
おそらく自分で一から作っても、時間がかかるばかりで、すでにあるものよりも良いものができる可能性はほぼありません。
それでも一から開発するのは、より深く理解するための学習目的か、ライセンスの問題で使用できないか、既存のものを超える意義とアイデアあるか、ぐらいしか思いつきません。
セキュリティ
初心者の方にはいろんなアプリケーションを作ってみてほしいと思う一方、すべてがインターネットに繋がる今の時代、セキュリティを考慮せずに公開することはできません
これが仕事のアプリケーションであればなおさらです。
僕がフレームワークを使う理由のひとつはセキュリティがある程度担保されるからです。
Web アプリケーションにおいてセキュリティは重要事項ですが、(僕にとっては)関心事ではありません。
その部分をある程度フレームワークが担ってくれるのは大きいです。
作りたいものに集中する
あなたが作りたいものはなんでしょうか？Web アプリケーションですか？
違いますよね。
EC サイトやブログサイト、TODO 管理などのプロダクトのはずです。
僕がフレームワークを使う最大の理由がこれです。
僕が作りたいのは特定の機能を持ったシステム・アプリケーションであって、セッション管理やセキュリティ、バリデーション、データベースアクセスを行うプログラムでありません。
「重要だけど関心がないこと」はフレームワークに任せて、自分は自分のやりたいことに集中する、そのためにフレームワークはあるのだと思います。
ミニフレームワークを作る
フレームワークというと「人が用意したものを使う」と思いがちですが、もちろん自分で作ることもできます。
なにも Laravel や Ruby on Rails のような大規模なフレームワークを作ろうということではありません。
小さな課題に着目し、それを解決するためのフレームワークを自分で作るということです。
公開できれば素晴らしいですが、必ずしも公開する必要もありません。
たとえば CSV を出力するフレームワークなどです。
僕は Symfony の ExpressionLanguage を使ってフレームワークを作ってみました。
与えられたものだけで組み上げるのではなく、自分でフレームワーク (枠組み、ルール) を作る。これはプログラマーの楽しみのひとつだと僕は思っています。
まとめ
フレームワークを使うということは「自ら枠にハマる」ということです。
枠にハマることによって、自分の関心事に集中することができます。
そして自分の関心事のミニフレームワークを考える・実装することによって、普通のエンジニアとは一線を画すスキルを身につけることができます。
Discussion