技術を採用するときの重要な観点の一つなのだが、軽視されている場面をみかけたので整理しておく。

ライブラリとフレームワークの違い

あなたが呼び出すのか、それとも呼び出されるのか？

ライブラリとフレームワークの違いを一言で表現するなら「あなたが書いたコードは呼び出すのか？それとも呼び出されるのか？」に集約される。 自分のコードが呼び出すのであればそれはライブラリだが、自分のコードが呼び出されるのであればそれはフレームワークだ。 これはフレームワークが持つ大きな特徴の一つで、制御の反転(Inversion of Control; IoC)と呼ばれる。

自由に書けるのか、それとも制約をもたらすのか？

もう一つの違いは「あなたが書くコードに制約をもたらすのか？」だ。フレームワークは構造を規定し、制約をもたらすことで、統一感を生み出す。 例えば「Webアプリケーションの開発において、APIを実装する場合はこういう書き方をすればよい。そのコードはこのディレクトリに配置する」といった形だ。 フレームワークは便利なように見えるが「自由度を下げ、適度な制約をもたらす」という一面がある。

逆に言えば、お作法を知っておき、適切な箇所に記述する必要があるということ。 その作法を守らなければ不具合やセキュリティ上の問題を引き起こしたり、バージョンアップによって動かなくなることも多く発生するだろう。

例：CMSをフレームワークとして採用するか？

WordPressやDrupalのようなCMSは、コンフィグレーションだけに留めるケースもあれば、カスタマイズも行うケースがある。 この2つは強く意識しなければならない。 なぜならコンフィギュレーションだけであればライブラリに類似した使い方だが、CMSのカスタマイズはフレームワークに類似した使い方だからだ。

ここでいうコンフィギュレーションは、CMSの設定項目を変更したり、プラグインを入れたりすることで、コード自体は変更しない。 バージョンアップでプラグインが動かなくなったとしても、代替プラグインを探したり、そのプラグインを外したりすれば対応できる。¹

一方、カスタマイズではCMSのコード自体に変更を入れる。たとえ変更がたった1行でも、どんなにシンプルに見えても、その変更は非常に大きな違いだ。 カスタマイズをする以上はそのCMSのアーキテクチャを理解し、適切な箇所に変更を入れる必要がある 。誤った箇所に修正を入れれば、不具合の原因となったり、CMSのバージョンアップ時に壊れたりする。²

世の中にはCMSをフレームワークのように使い、いろんなサイトやアプリをCMSで開発するベンダーが存在する。 そのスタイルを否定するつもりはないが、CMSをフレームワークとして使う学習コストは低くないし、参考になるドキュメントも多くない。 開発組織の主要技術にするつもりがなければ、CMSをフレームワークとして使用するのは避けるのが懸命だろう。

フレームワークを使うときに大事なこと

超えてはいけない一線

フレームワークは「構造」を規定し、そこには極めて強い力が働く。人類は構造に逆らうことができない。³ 構造とは「仕組み」や「システム」に近いものであり、構造を敵に回すことは開発リスクを大きく高めることになる。

フレームワークには前提や設計思想があり、それと同時にやってはいけないことも存在する。 例えば「フレームワークが管理している内部状態を公開・更新する」や「フレームワークの内部仕様を前提としたコードを実装する」といったことが挙げられる。 「やってはいけないこと」の境界は曖昧なこともあるが、この一線を超えると構造を敵に回すことになるので、これを見極めることが重要。 もしこの一線を超えたくなった場合・超えてしまった場合には、脱出戦略の実行を検討することになるだろう。

フレームワークをうまく採用すれば、開発工数は抑制でき、高品質になり、ソフトウェアはコントロールしやすい状態を保つことができる。 しかし組織やプロダクトの戦略方針に合致しないフレームワークを採用すれば、開発工数を浪費し、無理な実装や不具合に繋がる。

脱出戦略

フレームワークは、ライブラリほど簡単に切り替えることができない。⁴ しかしフレームワークがプロダクトの方針や戦略と合わなくなってきた場合や、フレームワークがEOLになる可能性は存在する。 そのためにはどのようなフレームワークの機能を使っていて、どこへ移行するかなどを考えておく必要がある。

ここでいうフレームワークは、前述のCMSをカスタマイズするケースも当てはまるし、KintoneやSalesforceといったSaaSを採用するときも当てはまる。 例えばKintoneの脱出戦略ならば「CSV出力したものをOneDriveに配置し、Excelで運用できるようなデータ構造にする」ことが考えられるだろう。

脱出戦略を考えておかないと、ふとした拍子にソフトウェアのコントロールを失う可能性がある。 例えばフレームワークがEOLになった場合や、SaaSの料金が大きく増加した場合だ。 ソフトウェアのコントロールを失うということは、変化に適応できないということ。 別の言葉でいえばアジャイルでないということだし、内製開発をする意味がなくなるということでもある。

まとめ

フレームワーク、ひいては「構造」の力はとても強力。便利であると同時に、人類に逆らうことは不可能である。
まず採用しようとしている技術は「ライブラリなのか、それともフレームワークなのか」を意識すること。
そしてフレームワークを使うときには、超えてはいけない一線を見極めつつ、脱出戦略を考えておくことが重要になる。