writeWiredとは

元々、私はフリーの開発エンジニアで、外資系の大手SIerで約10年ほど仕事をしていました。

私自身の立ち位置が一般的なエンジニアと少し違っていて、朝から晩までプログラミングというわけでもなく、 提案書を作って営業と一緒にお客さんのところに伺ったり、お客さんの悩みを聞いて、どんな提案を立てるかを考える仕事をしていました。 一方で、システム開発時に皆が使う共通部品（フレームワーク）を開発するのが得意でプロジェクトが始まるとそれ専用の共通基盤を作って、私の作業は終わりでした。

実際の業務処理の開発は他のエンジニアの方が行いますが、 私は開発のピークになると多くのエンジニアの方々から「これどうしたらいいかな？」などの相談を受ける程度で、 比較的自由な時間が多くありました。

当時、確かまだ2000年を少し超えたくらいの頃、私は求人サイトを運営している企業さまのプロジェクトに参加しました。

要件は法人向けの求人原稿入稿サイト（求人広告を出稿する企業の人が自分でブラウザから求人情報を入力できるサイト）の開発です。 担当する予定の協力会社の方が「実はあまり経験が無くて対応が出来ない」という相談を受け、比較的時間があった私が一人でその求人原稿入稿サイトを開発することになりました。 （最終的には多くの人の助けで成功裏に収めました）

その数年後、同じ求人原稿入稿サイトのリニューアルプロジェクトに参画。

リニューアルに伴い求人原稿の内容も変わるわけですが、その内容に多くの関係者が、 「PRの画像が増えた！」、「企業の紹介文の構成が変わった！」などと大騒ぎをしているのを見ながら、 フレームワーク、共通基盤を開発することが専門だった私は 「結局、どんな項目がいくつ増えて、いくつ減った、という程度なのに、大勢でシステム作り直すってばかばかしいなー。 自分だったら、こういう風に設定できるようにして、都度システムを改修するなんて馬鹿げた事はしないなー」 と考えていました。その時、恐らく2005、6年くらいの事です。これを汎用的な製品に出来ないかな、と。

その後も継続してその人材会社（後に国内大手人材会社になり、TVCMを見かけるのも普通になりました）のリニューアルに参画。 私は一般ユーザー向けの求人サイトではなく、法人向けのビジネスサービスという視点で見ていたので、 法人の契約内容によって使える求人原稿の種類が変わる、原稿審査のチェック工程も変わるなど、業務的な要件が非常に細かく、 「あーこれだと汎用的な製品にするのは無理そうだ」 とこの時は汎用的な製品化の考えを忘れました。

以降も、外資系SIerの中で大規模プロジェクトに参画。 SIer社内の稟議を通すために多くの人が資料を作るのに徹夜したり、稟議のための資料に価値があるのかなどの疑問を感じるようになり、 その業務スタイルは私が思うものとは違ったので、自分で作るには自分で始めるしかないなーと思い、STSD株式会社を作りました。

ただ、STSDを作っても何が変わるわけでもなく、結局、その外資系SIerの受託案件を受けながらも 「弊社はその作業は無駄だと思うから弊社としてその作業はやらない」 と言って、自分の好き勝手できる範囲でささやかにアウトロー気味に過ごしていました。嫌がられていただろう、と振り返って思います。

そのうちに「自分はこの先未来永劫、人様のシステムを開発して、その対価としての費用を頂戴して、また他のシステムを作り続けるのか？」 と考えるようになり、せっかく自分の会社を作ったのだから、自分たちの作ったモノに対価を頂戴できるような、サービスや製品を自社で開発したいなーと思うようになりました。

とは言っても、新しいサービスや製品などが簡単に思いつくはずもありません。 日々の生活のために、これまで通りシステム開発をしながら 「随分昔に考えたWebでサイトを更新するツールって汎用的にして売り出せないかな？」 と思い、調べてみると、世の中にはCMSという分野の製品があり、まさにWebサイトを簡単に更新できるようにするものらしい、ということを知りました。

これが後のwriteWiredです。

STSD株式会社設立後の私の実質の業務はコンサル的な要素のものが多く、実際の開発作業は当時のスタッフに任せ、自社製品の開発をしていました。 スタッフの空いた時間も使い、総勢4名で数か月かけて開発。この時に「writeWired CMS Platform」という名前も決まり、発表・リリースに至りました。 writeWired CMS Platform の初期開発費用はその大手人材会社によるもの、と言って過言ではありません。（胸を張って言えることでもありませんが・・・）

しかし、writeWired CMS Platform の基本的な考え方は2005、6年くらいに漠然と考えていた 「こんな項目の設定を増やしたらシステムの改修の必要なく、その項目の登録が出来るようになる」 というものから変わっていません。

writeWiredは「CMSを作りたい」という気持ちから生まれたわけではありません。

writeWired が生まれた理由は「自分がこういうツールがあればいいな、と思ったのがたまたまCMSでした」というものです。

※2018 年に書いた記事を再構成したものです。当時の用語や事情が含まれます。

「自分がこういうツールがあればいいな、と思ったのがたまたまCMSでした」と書きましたが、もちろんそのまま製品に出来るはずもありません。

実際には「パッケージ製品とするのであれば、何が出来ればCMSって呼んでいいのだろうか？」と考え、色々な製品を調べることになりました。 当然ですね。かなりの時間を費やしました。当時、ブログが一斉に流行りだした頃だったと思います。

Webサイトは今ほど身近、当たり前のものではなく、作るにも更新するにしても、 プロフェッショナルな制作会社に頼むものという考え方が一般的でしたが、 ブログの出現によって「Webサイト簡単に更新出来るもの」というイメージが浸透し始めました。

ブログはどちらかと言うと個人向けの情報発信ツールでしたが、 企業サイトも同様に、自分たちで簡単に更新出来るようにしたい。これがCMSという製品カテゴリの始まりでした。

今もそうなんですが、当時から「CMSとはこういうもの」という決まりがない曖昧な分野の製品なのですよね。 今でも「CMSとは？」とGoogleで調べてみると 「CMSとは、コンテンツ・マネジメント・システムの略で、専門知識の必要なく、Webサイトを管理・更新できるシステムのことをいいます。」 程度の定義しかありません。

顧客管理システムや会計システムなどは 「これが出来ればその製品として考えて良い」 というものがあったりしますが、CMSが取り扱うのは決まった形のない「Webサイト」というもので 「こういうWebサイトをこうやって更新できる」 という定義が無かったのです。（今も決まった定義はないと言っていいと思います。）

しかし、ブログはWebサイトとしての構成や出来ることが分かり易かったので、 多くの人にとって最大公約数的な要素になり、企業サイトでも同じように考えられるようになったのではないかと思います。

要素としてまとめると以下のように考えられます。

• トップページがある。
• カテゴリーごとのトップページがある。
• カテゴリーのトップページには、そのカテゴリーに含まれるページの一覧がある。
• 各ページがある。

あとは、付随要素として、ヘッダー、フッター、ナビゲーション、バナー、それに当時の流行りとしてRSSやトラックバックがあると思います。 つまり、逆を言うとこれだけ出来ればCMSと呼んでよいのです。（多分）

そこで当時、自社CMSの機能・在り方を下のように考えていました。

1については、元々のCMS開発の動機が 「フォーマットされたコンテンツ登録画面を都度システムの改修無しに出来るようにしたい」ということだったので十分な柔軟性を持たせました。 2～5に関してはある程度の柔軟性は持ちつつ、汎用的な機能をもったものを用意しました。HTMLタグの構造は変更でき、その他cssなども各サイトで設定できるようにしました。

しかし、製品自体が中規模以上のサイトをターゲットにしていたので、導入事例が増えていくにつれ、以下のような事態になりました。

当初の想定	実際に起きたこと
1. 設定で入稿画面が出来て、簡単にページの登録が出来て、	サイトごとに更新する情報の構造が全く違い、一般的な業務系システムと比較すると情報の粒度がとても細かいと再認識できました。しかし、writeWiredのコンセプトが、小さな粒度でデータを管理出来るものだったのですべての要件に対応出来ました。 ※小さな粒度で管理することで、コンテンツの再利用を無理なく実現できました。
2. トップページやディレクトリのトップはパッケージとしてのテンプレートが用意されていて、	すべてのケースでお客さまからデザインが提示されたので、1からそれに合うように作り直しました。
3. バナーも画像サイズ、期限を設定できて、	バナー画像を管理する機能を用意していたのですが、テキスト、入り組んだHTMLバナーの場合もあり、表示する条件の要件もサイトにより違ったので、結局使いませんでした。
4. RSSが自動で出力できて、	RSSに含めていい記事がサイトごとに違うため要件に合わせて開発しました。
5. 一覧は自動生成するモジュールで簡単に表示できて	一覧に含めるページ（コンテンツ）の種類、表示する内容、表示する条件、順番、出力するHTMLのすべてサイトにより要件が全く異なったので、これもサイトごとに開発しました。

最初に導入されたサイトは大規模の消費者向けのサービスサイトで、要件が明確でサイトのデザイン、各出力仕様もすべて決まっていました。 そういったサイトに対して汎用的に使えるパッケージの標準機能として用意するのには無理があったのだと思います。

全くの無名の自社製品を導入していただくのに「仕様なので出来ません。我慢するかサイトの方を変えてください」なんて製品側の勝手な主張をするわけにもいきません。

「製品が対応できない＝システム屋としてやっている我々の能力が低いから」と思われてしまう気がしたので、パッケージの方にサイトごとに違う方式を取り入れられるよう関数のようなものを追加して対応していきました。 なぜ、関数のようなものを追加したかというと、なんとなくですが「パッケージの標準機能」的なものがあった方が良いのではないかと思ったからです。 「これは標準機能で出来ますか？」とか聞かれたり、「標準機能はこちらです」とか言ってみたくなりますし、何かの基準としてあるべきだと考えたんですよね。

他のCMSであれば、これらの関数のような集りが製品の標準機能となり、「対応できる・できない」を決定づけていくものになったのかも知れません。 しかし、導入サイトごとに全く違う要件が重なり、難易度も高くなりました。 その中で「いえ、これは製品の機能に無いので出来ません」とは、 やはり言いたくなく、標準機能としての関数のようなものですら無くなっていきました。

例えば、記事一覧を表示するものだけでも、サイトによって違ってきます。すべてのバリエーションを予め準備するのは現実的に不可能ですし、役に立たない機能を持っていても仕方がありません。

どうしても「お客さまがしたいことを実現する＝パッケージベンダーという立場より前のシステム屋としての使命」と考えてしまうので、 それが出来るCMS、ということで開発をしていくと、サイトで利用できる標準的な機能は無くなってしまいました。 （結構な期間をかけて作ったものだったのですが、今となっては跡形もありません・・・）

今のパッケージの機能としては「CMS内に登録するコンテンツのフォーマットを自由に設定できて、保管されたコンテンツを自由に持ってこれる」これしかありません。これらを組み合わせていかようにでも開発出来るようにしました。

しかし一方で、公開するWebサイトでは標準機能と言えるものは無くなってしまったので、「これは標準の機能で出来ますか？」と質問されると回答に詰まってしまいます。 「標準機能というものはありませんが、出来ますよ」と聞く方は少し不安になるような受け答えしかできないので・・・。

ただ、「標準機能」という言葉自体、CMSという製品分野では受け取る人によって意味が千差万別になってしまうので、あまり使わない方がいいと思っています。 パンクズ、サイドナビゲーション、バナー、コンテンツの一覧などをよく見かけますが、標準って無いと思うのですよね。 そのベンダーが言っている標準があなたの標準とは限らないですし。

しかし、開発するベンダー側からすると、機能一覧を作った時に確実に行を増やせて、カバー範囲を広く見せたがるので、ついつい書いてしまうんでしょうね。よく「CMSは機能比較表で選んではいけない」と言われる所以だと思います。ベンダーが書く標準機能はあまり気にせず、自分がしたい事が出来るか確認した方がいいと思います。

writeWired CMS Platform には公開するWebサイト側の標準機能はありません。