CMS（Portal System）とWiki。コンテンツの作り方の違い

公開日時：: 2006/07/27 02:56
著者：: 今駒哲子

コメント(9)

ブックマーク(-)

CMS（Portal System）とWikiでコンテンツをつくっていますが、それぞれのしくみによって記事の投稿の性格がかわります。

CMS（Portal System）は、最新情報をまず記事として掲載。あるいは掲示板にUP。
それでコメントやトラックバックで反応をみながらさらにコンテンツを追加していきます。
ただ、Wikiのように、履歴がのこりません。まちがって記事を削除したり変更したときには、もうお手上げです。（もちろん、CMS（Portal System）にWikiプラグインが追加されている場合にはそのようなことはありませんが。）グーグルのキャッシュをあわてて見に行き、そこからはめ込むこともあります。もしなければ12時間ごとにデータベースのバックアップを行っているので、そのバックアップファイルからその記事の部分を探して復帰させるか、最悪データベースのリストアで復帰する方法も残されていますが。

ですから、CMS（Portal System）は速報性は高く優れているものの、じっくり編集したり、追加していくという目的ではすこし弱いようです。

その点、Wikiは、じっくりおちついて文章を練って、体系立てて文書を作成していけます。だれがいつどういうふうに編集・修正したか差分もわかり、いつでもどの時点のコンテンツへでも復帰させることができるので、安心して大胆に修正を行うことができます。

コンテンツ自体が文字を主体にしているので文字の大きさも大きくよみやすい。
タグが共通化されているので統一感もあり、キーワードへのタグリンクもしやすく、ページもつくりやすい・・・。自然に、おちついた文体になって、よみやすい文章になります。

CMS（Portal System）で作成していた文章をWikiで構成しなおすと、気がつかなかった構成の不備、まちがいに気づかされます。

さらに、このコンテンツを書籍化する場合には、こんどは全体のページ数と個々のコンテンツの主張ごとにどういうページ配分にするかを割り当てることになるので、削除してよいところを削除していって、全体的にバランスをとって、言いたいことをわかりやすく簡潔にしていきます。また、印刷になることで、校正を十分にかけるのでさらに文章が洗練されていくことになり、画面のキャプチャーも、Webのときには気にならなかった細部のミスも気になり、作り直すことにさえなります。

速報性、コミュニティ、連携をCMS（Portal System）サイトで求め、ドキュメントの充実をWikiで求め、最後に書籍として信頼度の高い情報化をおこなって、Webに反映させていく・・・。

この循環がさらに良い効果をもたらすように思います。

追伸）
当初CMSとして紹介していましたが、WikiもブログもCMSであるということから、CMSから、CMSのなかでもPortal Systemのことを限定してこのブログを書いていたため、後から(Portal System)を追加させていただきました。（2006.7.31）

※このエントリは CNET Japan ブロガーにより投稿されたものです。シーネットネットワークスジャパンおよび CNET Japan 編集部の見解・意向を示すものではありません。

ログインしてコメントするこのエントリを評価する

運営事務局に問題を報告この記事についてブログを書く（ブロガー専用）

このエントリーへのコメント

tacaさん、コメントありがとうございます。
CMSという表現がいろいろと問題を複雑化しているので、ポータルシステムと、Wiki というふうに言い方を変えますね。

今駒哲子 on 2006/07/31

横から失礼します。

> geeklogもwikiプラグインを追加すればできるし、
元々のStoryとかもバージョンの管理とかできるようになるのでしょうか??

> 履歴がのこるだけでは不十分で、Wiki独特の　=== や　[[]]といった
> タグが思った以上の効果を生むと思うんです。
Wiki記法が有効・便利な場面というのはあると思います。ただ、運用の形態によっては、バージョンの管理ができて、変更点を簡単に比較できることが必要な場合もあります。
こういった機能を備えている"CMS"も少なくないですから、CMSとWikiを並列にすると違和感があるのではないでしょうか?

taca on 2006/07/31

┣[ContentsManagementSystem]
┃┣[Portal System]…Geeklog,XOOPS,MODx,plone,Drupal,Joomla他
┃┣[Blog]…Nucleus,MT,WordPress,HyperNikkiSystem 他
┃┣[Wiki]…MediaWiki,PukiWiki,yukiwiki
┃┣[Commerce]…OsCommerce,ZenCart他

Geeklogはブログ機能も持っているし、Wiki機能もプラグインによって可能になる、など、それぞれのシステムごとにすっきりとわけられるものではありませんが、根幹のシステム設計、構想を重視して系統立てると上図のようになりそうです。
Geeklogも、CommerceのZenCartとドッキングしてシステムを提供できるようになります。

今駒哲子 on 2006/07/31

なるほど。PortalSystemですか。
これならかなり判りやすいですね。

＃どっかにカテゴライズとか進化（分化・影響）系統樹とか書いてみるかなｗ。

masamic on 2006/07/31

masamicさん、系統立てた説明、どうもありがとうございます！
┣[ContentsManagementSystem]
┃┣[Portal System]…Geeklog,XOOPS,MODx,plone,Drupal,Joomla他
┃┃┣[Blog]…Nucleus,MT,WordPress,HyperNikkiSystem他
┃┣[Wiki]…MediaWiki,PukiWiki,yukiwiki,(Geeklogプラグインを追加すれば可能)他

Weblog=blog　BBSは　CMSとはすこしニュアンスがちがうかなということで分けてみました。
Geeklogは、ブログポータルシステムですから、コアシステムにブログ機能を持っています。
WikiプラグインでさらにWikiにもなります。
Portal Systemは、個々のブログ機能は、ブログ専門のシステムに劣る場合があっても、開発の方向性や立場として、ブログの上位にあるのかな、という感触です。

今駒哲子 on 2006/07/30

あ、一応念のため補足しておきますが、Geeklogには個人的には注目していますよ。1ヶ月くらい？前にオフィシャルサイトを覗いてみて、いい感じの印象だったので、大変期待しています。

masamic on 2006/07/30

客観的に考えるとWikiもCMS(Contents Management System)ですね。さらに突っ込んでソースコード管理システム(SCMS)もCMSと親戚関係だと思います。

そういう点で用語的にWikiとCMSを分けるのには少々抵抗があります。WikiとBlogとBBS(SNS)というように分けるのであればいくらか個人的には納得いくんですけどねぇ。

つまり、（プラグインでの機能追加は考慮せず）ベーシックな機能で分類すると、

[DataManegementSystem]
┣[SourceCodeManagementSystem]
┃┣[SCCS]
┃┣[RCS]
┃┃┣[CVS]
┃┃┃┣[Subversion]
┃┣[Arch]
┃
┣[ContentsManagementSystem]
┃┣[Wiki]
┃┣[WebLog]
┃┃┣[HyperNikkiSystem]
┃┃┣[Blog]<=今駒さんの言われるところのCMS？
┃┃┃┣[Vlog]
┃┃
┃┣[BBS]
┃┃┣[SNS]

私の頭の中では上記のような系統樹が描かれているわけです。もちろん、時間が経過していくごとにお互いに影響を及ぼしあってそれぞれ変化（進化？）していきますが。

まあ、あんまり深く突っ込んでもなんか神学論争的状況になりそうな予感がするので、結局のところ、その辺が判るように書いていただければ良いのではないかと思います。

masamic on 2006/07/30

@randomさん

> うーん、世の中には履歴が残ってバージョン管理ができるCMSもゴロゴロしてると思うのですが。

そうですね、あるでしょうね。
geeklogもwikiプラグインを追加すればできるし、MediaWikiのプラグインも開発中のようですから。

履歴がのこるだけでは不十分で、Wiki独特の　=== や　[[]]といった
タグが思った以上の効果を生むと思うんです。
こういったルールは覚えやすいのでたくさんの人が関わって
コンテンツをつくるには、この方法しかないとおもいます。

WikiもCMSだといってしまえないことはないのですが、でも、基本的には、WikiとCMSとは、そのあたりでわけないと混乱しそうです。

今駒哲子 on 2006/07/28

うーん、世の中には履歴が残ってバージョン管理ができるCMSもゴロゴロしてると思うのですが。

@random on 2006/07/28