DataBase（DB）の問題

WordPress等のオープンソースCMSが案件で採用されない一番の理由がDBの問題です。ブログからCMSエンジンとしても使われるようになったためか、汎用性を意識した作りをしており、DB構造が複雑です。

その上、HTML吐き出し型では無く、アクセスの度にDBにクエリを投げる形を取っています。これによりサーバへの負荷が増え、多量のアクセスを捌くことが困難になります。

DBのチューニングである程度負荷を下げることが出来ますが、根本的な解決にはなりません。商用製品はこの部分を綿密にチューニングし開発を行っています。例えば、HeartCore CMSであれば、チューニングなしの状態でも、1日あたり100万PV（１CPUあたり）の負荷に十分に耐えられます。

プラグインの問題

ここまでオープンソースCMSが広く普及した理由は、プラグインの存在無しには語れないでしょう。「手軽に導入出来るプラグインによるカスタマイズ」こそがWordPress等のオープンソースCMSの魅力と言っても過言では無いと思います。

しかし、それこそが致命的な欠点を作り出しているとも言えます。まず、その手軽さ。

ほとんどのプラグインがボタン一つで簡単に導入できるわけですが、みなさんはその中身や動作を知っていますか？
どういう処理が行われていて、どのような脆弱性を持っているのか。

導入したが有効化していないプラグインの脆弱性を突かれて、Webサイトのコンテンツを改ざんされたという記事をよく目にします。

何故こんな事件が発生してしまったのか。
オープンソースCMSの管理画面やプラグインのURLは設定を変更しない限り、デフォルトのものが使用されます。

つまり、そのWebサイトがオープンソースCMSを使っていて、かつ、そのプラグインをインストールしていれば、有効化しているかどうかに関わらず、そのプラグインの脆弱性を突くことが可能になってくるのです。

こうした被害も個人のブログであればたいして問題無いかもしれませんが、企業のホームページに導入していた場合、どうなるでしょうか？
誰が責任をとってくれますか？

オープンソースCMSはオープンソースのプログラムですから、作った人が何かを担保してくれるわけではありません。導入を決定した人が、あくまで責任を負う必要が出てくるわけです。そこまでのリスクを理解した上で導入を決定しているのでしょうか。

直接のカスタマイズの問題

オープンソースCMSはJavaやPHPで作られているケースが多く、JavaやPHPの読み書きが出来ればある程度のカスタマイズが可能になっています。テンプレートを作りたければ、最小限の JavaやPHPの知識と、オープンソースCMS独自関数の知識があれば良いのです。

しかし、中途半端な知識は脆弱性の温床です。言うまでもありませんが、「知らなかった」なんて言い訳は出来ません。

また、オープンソースCMS本体の問題も多くあります。歴史的な背景もあり、オープンソースCMS独自関数は整備状況が甘く、命名ルールや挙動すらも統一されていないという現状です。当然そこで出来上がるコードは、非常に可読性が低く、今後の再利用に適さないものになります。

あとから機能を追加したくとも、まずは解読から、という状況も珍しくありません。しっかりしたドキュメントを作れば解決…たしかにそうですが、それってスクラッチ開発とどう違うのでしょう？

オープンソースCMS自体は、オープンソースそのものの発展に大きく寄与した面もあり、高く評価しています。しかし、だからといって盲目的にそれを信頼していいのか、というとそれは別の問題です。

この他にも、パフォーマンスの問題もあります。オープンソースCMSは自分でチューニングをする必要があったり、大規模サイトの場合は、非常に大規模なサーバを準備する必要があります。SEOにも影響しますし、セキュリティ、パフォーマンス共に、企業ユーザは考慮しないといけない問題です。