ウェブシステムをウェブフレームワークと CMS のどちらで作るべきか

ウェブシステム開発の際のプラットフォームの選択肢としてウェブアプリケーションフレームワーク(以下「フレームワーク」)と CMS がある場合、どのように使い分けるのがよいのでしょうか。 今回はこの「 フレームワークと CMS の使い分け問題 」についてかんたんに整理してみたいと思います。

フレームワークにも CMS にもさまざまなタイプのものがあり、 CMS 風の機能を備えたフレームワークやその逆パターンも存在するので、「フレームワーク」「 CMS 」で一括りに語るのは乱暴です。 ただ、一括りでも一定のロジックを持っておくと冷静によりよい選択ができる確率が上がるので、やや乱暴なことを承知のうえで書いてみます。 同様の選択肢を持っている方には「確かに」等と思ってもらえるのではないかと思います。

尚ここでは「ウェブシステム」という言葉を、通常のウェブサイトに加えて SNS サイト・ EC サイト・イントラサイト等も含む広義の意味での「システム」を指すものとして使っています。

前提

話の前提は次のとおりです(前提がたくさんあります)。

  • 自分の立場は技術者である
  • フレームワークと CMS のそれぞれでスムーズに使えるものがある
  • どちらか一方が得意ということは無く知識面での選好度はどちらも同じ
  • 対象のウェブシステムはフレームワークまたは CMS を使うのがよいと考えられるものである

つまり、フレームワークと CMS のどちらでも使うことができて、習熟度という意味ではどっちもどっち、というイメージです。 いずれも「触ってみた」のレベルではなく、たいていの要件にはスムーズに対応ができるぐらいには習熟している想定です。 ですので、どちらを使うかはサイトの要件・仕様次第で決まるというような状況をイメージしています。

尚私はフレームワークと CMS については次の記事で述べたような認識を持っています。

フレームワークと CMS のどちらで作るべきか

もろもろの費用と価値をひっくるめて 費用対効果がよい方を選ぶ というのが基本方針です。 そのためには「 要件が CMS 向きのものを CMS で作って、それ以外は原則フレームワークで作る 」のがよいと思います。

CMS 向きのサイト、 CMS 向きのプロジェクトには具体的には次のようなものがあります。

CMS 向きのサイト:

  • コンテンツが主役
  • 多くのカスタマイズを必要としない

CMS 向きのプロジェクト:

  • プロトタイプが早期に必要

コンテンツが主役: CMS とはその名のとおりコンテンツを効果的・効率的に管理するためのソフトウェアです。ビジネスロジックの「処理」や「データ」よりも「コンテンツ」が主役となるシステムは CMS 向きと言えます。 CMS の典型的な用途は通常のウェブサイトですが、通常のウェブサイトの他にもコンテンツ主体のシステムは実はたくさんあります。 CMS の多くは「モデリング」「編集」「公開」等の基本的なコンテンツ管理機能がデフォルトで備わっているので、特殊な計算や処理はごく一部であくまでもコンテンツが主となるシステムの場合は CMS を選ぶ(少なくとも選択肢に含める)メリットが大きいです。

多くのカスタマイズを必要としない: 多くの CMS は、 CMS 本体をダウンロード・設置していくらかの設定を行うだけで通常のウェブサイトを比較的かんたんに作れるようになっています。その上で、多様なニーズに対応できるよう機能やデザインの拡張ができるようになっています。ただ、利用者に十分な技術知識と経験がある状況では、拡張の際にフレームワークほどの開発効率は CMS では発揮できないことが一般的です。そのため、カスタマイズのボリュームが一定の範囲内に収まるなら CMS を選び、超える場合はフレームワークを選ぶのがよいでしょう。

プロトタイプが早期に必要: 実際に動作するプロトタイプをプロジェクトの早いうちから利用し議論したいような場合は、最初から GUI を提供してくれる CMS を利用すべきです(少なくとも、選択肢に含めるメリットはあります)。いくら開発効率の高いフレームワークでも実物に近い画面が CMS ほど速くは見れないので、早期に実物に近い画面を使った議論や判断を進めたいような場合は CMS が有利です。

逆に、 これらの場合にあてはまらない場合はフレームワークの方がよい場合が多い ように思います。

ただし、現実には、冒頭にあげた前提は成り立たないことの方が多いので、上記の判断基準だけで決められるような場合は稀です。 例えば、現実は次のとおりになります。

  • 理想: フレームワークと CMS のそれぞれでスムーズに使えるものがある
    現実: 特定のフレームワーク、特定の CMS しか使えない
  • 理想: どちらか一方が得意ということは無く知識面での選好度はどちらも同じ
    現実: フレームワークと CMS のどちらか一方の知識が強い

特に、精鋭揃いではない普通のチームの場合はメンバーの意欲や能力の面でさまざまな制約があるため、技術と要件のフィットをニュートラルに比較してよりよい方を選ぶなんてことはできないでしょう。 例えば、英語の技術書が読めない人の比率が高いチームでは、要件へのフィットがどれだけ高いフレームワークでも日本語情報が少ないものは候補から外れやすくなります。 そのため、使える技術の中から消去法的に選択せざるをえないというのがよくある現実でしょう。

また、上の「多くのカスタマイズを必要としない」の判断は言うは易く行うは難しです。 CMS 本体やプラグインに対する知識の度合いによって必要なカスタマイズの量は大きく変わってくるので、どこからが「多くのカスタマイズ」になるかという見極めは属人的な知識・技術レベルに大きく依存するでしょう。

とはいえ、万が一意欲と能力を兼ね備えた力強いチームに恵まれ「どちらでも行ける、どちらにしよう?」という贅沢な悩みを持てた場合には、個人の感覚で選ぶのではなく明確なロジックを使って選ぶことで、適切な技術選択の打率は上がると思います。

フレームワークと CMS のよしあしを改めて実感し、このあたりの判断力を高めていきたいと思う今日この頃です。 同様の興味を持つ方の議論のネタにでもなれば幸いです :)