フレームワーク

家をゼロから建てるなら、地面を固めて配管を埋め、柱を立てる基礎工事から始めなければなりません。これを家を建てるたびに更地から始めていたら、時間もかかりますし、うっかりミスで建物が弱くなってしまうこともありますよね。

ソフトウェア開発もまったく同じです。ユーザーがログインしたら本人かどうかを確認する、サーバーと安全にデータをやり取りする、画面を切り替える。こうした基本機能は、ほとんどすべてのプログラムで共通して使われます。フレームワークは、こうした基本の骨組みと共通機能をあらかじめ頑丈に作っておいた、プレハブ住宅の建築キットのようなものです。

開発者は、しっかり組み上がった骨組みの上に、どんな壁紙を貼ってどんな家具を置くか、つまり自分たちのサービスならではの機能だけを組み込めばOKです。おかげで基礎作業にかかる時間を大きく減らし、サービスの本質的なロジック(動作の仕組み)に集中できます。

ライブラリ(Library)とフレームワークを混同する人は多いです。どちらも他の人があらかじめ書いておいた便利なコードのまとまり、という点は同じですが、流れの主導権を誰が握っているかという点で決定的に違います。

ライブラリは、自分の机の横に置いてある「工具箱」です。家を建てている途中で、必要になったらノコギリを取り出して木を切り、金づちを持って釘を打ちます。どの道具をいつ、どう使うかは、すべて開発者が決めます。

一方、フレームワークは、決められたレールの上を自動で進む「大きなアトラクション」や、工場のベルトコンベアのようなものです。全体の運行はフレームワークが管理し、開発者はフレームワークが用意した停車駅に必要な部品(コード)をはめ込むだけです。開発者がプログラムを呼び出すのではなく、フレームワークが必要なときに開発者のコードを呼び出す。この現象を専門用語で「制御の反転(Inversion of Control)」と呼びます。

もう少し正確にいうと、フレームワークは開発スピードだけでなく、チームで協力して作業するときの質も大きく高めてくれる道具です。数十人の開発者が一緒に働いても、フレームワークが定めたファイルの置き場所やコードの書き方のルールに従うので、誰が書いても一貫した形を保てます。

ただし、得るものがあるぶん、決められたルールを厳しく守らなければならない縛りも受け入れる必要があります。フレームワークが推奨する枠から外れ、とても特殊なやり方でプログラムを作ろうとすると、骨組みを作り変えなければならず、かえってゼロから作るより時間も手間もかかることがあります。

結局、フレームワークを導入するというのは、完全な創作の自由を少し手放す代わりに、チーム全体の生産性とプログラムの安定性を手に入れる賢い選択だといえます。