gotohayato.com

月(ダークモード)
太陽(ライトモード)

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

CMSウェブよもやま話

ウェブシステム開発の際のプラットフォームの選択肢としてウェブアプリケーションフレームワーク(以下「フレームワーク」)と 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 を選び、超える場合はフレームワークを選ぶのがよいでしょう。

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

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

ただし、現実には、以下のような制約がある場合が多いでしょう。

  • 理想: フレームワークと CMS のどちらもほどほどに使える 現実: 特定のフレームワーク、特定の CMS しか使えない
  • 理想: チームの技術者は学ぶ意欲があり、たとえそれが自分の知らない技術でもよりよい方を選ぶことに賛成してくれる 現実: 学習意欲がそう高くなく、自分がすでに知っている知識・技術にこだわる

現実には、標準的なスキルレベルのメンバーからなるチームの場合は、メンバーの意欲や能力の面でさまざまな制約があるため、技術と要件のフィットだけを比較してよりよい方を選ぶなんてことはなかなかできないと思います。 例えば、英語の技術文書が読めない人の多いチームでは、日本語情報が少ないものは候補から外れやすくなるでしょう。

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

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


後藤隼人
ウェブサイト制作・ウェブアプリ開発やマーケティングをしています。
GitHub

お知らせ

大阪大学医学部附属病院さんで現在クラウドファンディングのプロジェクトをされています(後藤も少しだけ寄附させていただきました)。
© 2020 gotohayato.com
サイトについてタグアーカイブメッセージを送る