ひとつの基盤を、データベース指向で

組織とサイト —— マルチテナントと権限

writeWiredは、複数の組織が複数のサイトを運用することを前提に、誰に何が見え、何を変えられるかを、組織・ユーザー・サイトの関係として定義しています。

組織とサイト

writeWiredには複数の組織を登録できます。組織はユーザーを配置する一番大きな単位で、組織とサイトは多対多で対応します。ひとつの組織が複数のサイトを運用することも、ひとつのサイトを複数の組織で使うこともできます。

組織が違えば、コンテンツとメールは完全に分離され、互いに閲覧できません。どの組織がどのサイトを操作できるかの割り当ては、サーバー管理者権限という開発者向けの特別な権限で行います。日常の運用ユーザーがこの層に触れることはありません。

組織は、その組織のユーザーに共通するルールも持ちます。パスワードのポリシー、コンテンツの登録上限、そして次に述べる部署とロールの定義です。

組織の中 —— ユーザー・部署・ロール

ユーザーは管理画面を操作する人です。必ずひとつの組織に属します。ユーザーIDはひとつのwriteWiredの中で一意で、組織が違っても同じIDは作れません。サイトの会員は、この管理ユーザーとは別のモデルで管理します。

部署はユーザーをグループ化する階層です。深さにも数にも制限がなく、設定自体は任意です。部署は、データの閲覧範囲の指定と、承認の担当の指定に使われます。

ロールは、任意の名前を付けてユーザーに割り当てる札です。主に承認の担当の指定に使われます。

権限は2段で掛かる

最初の段は組織です。組織に許可されていない機能は、その組織のユーザーの画面には現れません。

次の段は、ユーザーとサイトの組み合わせです。ユーザーごとに、サイト単位で権限のセットを設定します。同じユーザーでも、サイトAでは編集者、サイトBでは閲覧のみ、という設定ができます。ディレクトリ単位で上書きする設定もあります。

権限は7つの区分で設定します。サイト管理・ディレクトリ管理・コンテンツ管理・テンプレート管理・問い合せ管理・顧客管理・表示フォームです。サイト管理の区分には、素材・アクセスログ・バッチ・オーディエンスフィルター・MAなど、サイト全体に関わる機能の権限がまとまっています。

区分の中の型は揃えてあります。使えるか（許可）、どこまで見えるか（閲覧範囲）、変えられるか（編集）の3つで、コンテンツにはこれに承認が加わります。

閲覧範囲 —— 「誰が作ったデータか」で決まる

閲覧と編集の判定には、データを作成したユーザーの部署と、操作するユーザーの部署の関係を使います。範囲は次から選びます。

閲覧範囲	見えるデータ
自分のみ	自分が登録したデータ
所属部署	自分と同じ部署のユーザーが作成したデータ
所属部署以下	所属部署と、その下の部署のデータ
指定部署	権限に指定した部署のユーザーが作成したデータ
指定部署以下	指定した部署と、その下の部署のデータ
すべて	同じ組織のユーザーのデータすべて

編集にはこの6値に加えて「なし」があり、その場合は閲覧だけができます。

この閲覧範囲の考え方は、コンテンツだけのものではありません。問い合わせや顧客のビュー、メール、バッチのログ、オーディエンスフィルターにも、同じ型で適用されます。

承認について

コンテンツには、制作中・確認依頼・確認中・掲載可の4つの状態があります。状態の変更は、いつ・誰が・どの状態からどの状態へ、の形で履歴に残ります。承認を挟んでから公開する運用はこの状態で組めます。部署やロールで担当を指定する多段階の承認フローも構成できます。

この構造が画面に現れるところ

編集画面に表示されるセクションと編集の可否、トップに表示されるパネル、ステータス変更時の通知先（そのコンテンツの編集権限があるユーザー全員）は、いずれもこのモデルの帰結です。管理画面の見え方が人によって違うのは、権限がこの2段で効いているからです。

サイトとフォーム —— 入れ物をフィールド単位で定義する

writeWiredは、サイトで扱う情報を、フォームという入れ物としてフィールド単位で定義します。

サイトの構造

サイトは、ドメイン別に情報を格納する単位です。ひとつのwriteWiredで複数のサイトを扱えます。

サイトの中は3つの階層でできています。サイトは、ドメイン・SSL・サイト単位のメタ情報・ナビゲーションやフッターなどの共通部品を持ちます。ディレクトリは、コンテンツを置くための入れ物で、階層構造を持ちます。コンテンツは、公開サイトの1ページの本体です。

コンテンツも、問い合わせも、会員情報も、メールも、サイト単位で保管されます。

フォーム —— 項目の束

フォームは、項目（フィールド）の定義の束です。項目は、型と入力形式と属性を持ちます。

型は、文字・英数字・数字・メールアドレス・年月日・画像・ファイル・電話番号・郵便番号などから選びます。入力形式は、テキスト・テキストエリア・選択・チェック・ラジオなどです。属性には、必須・変更不可・入力値のマスク・フォーム内での重複不可などがあります。

選択肢は選択リストとして登録し、複数のフォームで共有します。画像とファイルの項目には、登録できる種類・縦横の大きさ・容量の制限を付けられます。項目は別のフォームを参照することもできます。

フォームは3種類

フォームには、用途の違う3つの種類があります。コンテンツを定型で持つための表示フォーム、訪問者からの問い合わせのための入力フォーム、会員データの器である会員フォームです。

会員フォームには、ログインする会員そのものを保管するWeb会員のほか、ログインしない顧客情報のための名簿、メールアドレスだけを持つメールマガジンの型があります。

フォームグループ —— 束ねて、順序と数を決める

フォームグループは、複数の表示フォームを組み合わせて、サイトに表示するためのデータの集まりを定義します。コンテンツ用のフォームグループであれば、1ページ分のコンテンツを構成する要素——本文のブロックや、定型の入力項目——の集まりがこれにあたります。

束ねる際には、フォームごとに順序と数の範囲（必須か、最小いくつ、最大いくつ）を定義します。この名前は編集画面には現れませんが、「セクションごとに設定できる数が決められている」のは、この定義の現れです。

フォームが取り付く場所は5つ

フォームが取り付き、値を持てる場所は5つあります。

場所	置くものの例
コンテンツ	本文のブロック、定型の項目
ディレクトリ	配下のコンテンツで共通のバナー
サイト	サイト共通のバナー、ヘッダー、フッター
組織	組織ごとの問い合わせ窓口
ユーザー	制作ユーザーの紹介プロフィール

サイト設定にある「サイトフォーム入力」は、サイトに取り付いたフォームそのものです。

コンテンツは項目の集合として保存される

コンテンツは項目の集合として保存され、表示の際にテンプレートが項目を単位に取り出します。同じ情報を、場所や形を変えて見せられるのは、この構造から来ています。

問い合わせも会員も、コンテンツの定型部分も、サイトの共通部品も、同じフォームという単位でできています。だから、フォーム設計（ビュー・クエリー・リスト）やCSVの入出力が、どれにも同じ形で効きます。

テンプレート —— 公開面と編集画面を定義する

サイトの公開部分は、テンプレートの実装がつくります。テンプレートは、コンテンツの器と、編集者が触れる範囲を定義します。

テンプレートは3種類

テンプレートはサイト単位で登録されます。種類は、コンテンツ・組み込み・HTMLの3つです。

コンテンツは、作るときにテンプレートを1つ選びます。テンプレートなしでコンテンツを作ることはできません。選んだテンプレートが、そのコンテンツの編集画面の作りと、公開側での見せ方を決めます。

テンプレートの持ち物

テンプレートが何を決めるかを並べると、次のようになります。

テンプレートの設定	決まること
フォームグループ	入力できる項目の構成
使えるブロックの種類と表示スタイル	本文ブロックで選べる部品と見た目
編集画面のタブ	編集画面に出るタブの種類と並び順
本文ブロックの編集可否	本文のHTMLに触れられるかどうか
既定値	掲載期間や「ニュースとして表示」の初期値
使える承認フロー	このテンプレートのコンテンツが使う承認の経路
表示JSP	公開側でこのコンテンツを表示する実装

編集者がどこまで触れるかを、テンプレートで設計する

同じwriteWiredの上でも、編集画面の姿はテンプレートしだいで変わります。HTMLまで開くこともできれば、定型の項目入力だけに絞ることもできます。絞ったテンプレートでは、更新する人が違っても、コンテンツは同じ構成で作られます。

公開側 —— 項目単位で取り出す

コンテンツは項目の集合として保存されています。公開側では、テンプレートの表示JSPが、この項目を単位に取り出して表示します。

取り出せるのは、そのページ自身のコンテンツに限りません。あるページの表示の中で、別のコンテンツの内容を取り出して組み込むこともできます。共通の情報を原本としてひとつのコンテンツに持ち、各ページはそれを参照する——一度直せば載っているすべてのページに反映される、ワンソースマルチユースは、この取り出しの上に成り立っています。

取り出し方は実装しだいなので、同じデータを、詳細ページ・一覧・別ページの部品というように、場所と形を変えて見せられます。条件を指定してコンテンツを絞り込む、検索システムのような公開面も、テンプレートの実装として作れます。

フォーム設計 —— 問い合わせと会員を、データベースとして扱う

入力フォームと会員フォームは、フォームで設計するデータベースです。フォームの設計が、そのままデータベースの設計になります。

定義すれば、画面ができる

フォームに項目を定義すると、データを登録するための管理画面が自動で生成されます。項目を追加すれば入力欄が増え、必須やマスクの属性を付ければ、その通りに動きます。テーブルの設計にあたる作業が、フォームの設計です。

データの見方は、ビューで設計する

登録されたデータをどう見るかは、ビューという単位で設計します。ビューは、クエリーとリストの組み合わせです。

部品	決めること
クエリー	どの条件で絞り込むか。項目を「かつ」「または」「〜でない」で組み合わせ、検索画面の初期値も持てる
リスト	どの列を、どの順序と幅で見せるか。既定の並び順も持てる
ビュー	クエリーとリストの組み合わせ。CSVの入出力の設定と、閲覧権限もここに付く

ビューは任意の名前を付けて複数作れます。クエリーとリストは使い回せるので、同じ絞り込みを違う列の見せ方で使う、といった組み立てができます。

ビューには閲覧権限を設定でき、組織とサイトの節で述べた閲覧範囲の型がそのまま効きます。クエリーの初期条件と組み合わせると、同じフォームでも、利用者の業務ごとに見えるビューと届くデータを変えられます。たとえば地域別の担当者ごとに、担当地域の会員だけが見えるビューを渡す、という運用がこの組み合わせでできます。

検索条件に使えるのは、フォーム自身の項目だけではありません。アクセスログや、送信したメールへの反応も条件に加えられます。

参照型 —— フォームとフォームをつなぐ

項目は、別のフォームを参照できます（サイトとフォームの節で触れた参照型です）。参照でつながっていれば、参照先のフォームの項目を、検索条件にも、一覧の列にも使えます。

入力フォームには、会員フォームとの連携を設定できます。問い合わせの送信時に会員IDを引き継ぐ、メールアドレスを使って会員データへ自動で書き出す、フィールドIDが一致する項目を会員データに上書きする、という動きです。サイトでの問い合わせが、会員という器に集まっていきます。

追加設定 —— 問い合わせと会員の運用を定義する

フォームには、用途ごとの追加設定があります。

入力フォームでは、対応状況を管理するためのステータスを自分で定義できます（コードと名前を複数登録します）。問い合わせがあったときの通知メールの送信先、データの自動削除（保持期間の管理）もここで設定します。

会員フォームでは、会員IDをメールアドレスにするか、パスワードのルール、仮登録を挟むかどうかを定義します。

同じ道具が、どれにも効く

コンテンツの定型部分も、問い合わせも、会員も、同じフォームという単位でできています。だから、ビュー・クエリー・リストの設計も、CSVの入出力も、閲覧権限の型も、どれにも同じ形で効きます。

データベースに対するマーケティング —— 届けて、記録して、数える

問い合わせと会員のデータベースに対して、メールを届け、サイトでの動きを記録し、数えるところまでを、同じ仕組みの中で行います。

メール配信 —— ビューが抽出条件になる

メールの送信対象は、入力フォームと会員フォームのデータです。誰に送るかの抽出には、フォーム設計の節で述べたビューをそのまま使います。データベースの見方として作った絞り込みが、そのまま配信リストの定義になります。

送信のかたちは4つあります。

送信タイプ	動き
自動返信	サイト上のイベントと同時に送る。問い合わせへの返信、会員登録・変更・パスワード関連などの通知
予約配信	ビューで対象を抽出し、指定した日時に送る
予約配信（対象選択）	一覧からデータを選んで、指定した日時に送る
繰返配信	フォームの日付項目を基準に「n日前・n日後」の条件で、データの状態が続くかぎり送り続ける

送ったメールは、送信済み・エラーの数に加えて、開封数と開封率、本文中のURLごとのクリック数・クリック人数・クリック率が記録されます。この反応は記録で終わりません。先に触れたとおり、「このメールを開いた人」「このURLをクリックした人」を、ビューの検索条件として次の抽出に使えます。

登録済みのコンテンツは、HTMLメールに流用できます（詳しくはメール配信の機能ページで）。

アクセスログ —— 会員IDまで届く記録

writeWiredは、公開サイトでのアクセスをすべて記録します。日時・URL・リファラー・検索ワードといった一般的な項目に加えて、クッキー、流入元のメールとキャンペーン、フォームの送信イベント、そして会員がアクセスした場合はその会員IDが、常に記録されます。

匿名の訪問がクッキーで、ログイン後の訪問が会員IDでつながるため、「誰が・どこから来て・何を見て・何を送信したか」が、問い合わせと会員のデータベースと同じ土台の上に揃います。

オーディエンスフィルター —— ログからの抽出

アクセスログに条件を指定して、対象を抽出するのがオーディエンスフィルターです。条件は、来訪回数・閲覧数・URL・キャンペーン・リファラー・IPアドレス・クッキーの組み合わせで指定し、任意の名前を付けて複数作れます。

抽出されるのは、クッキー・問い合わせデータ・会員IDの3つです。抽出結果はビューの検索条件として使えるので、「特定のページ群を繰り返し見ている会員」を絞り込んで、そのままメールの配信対象にする、という流れが仕組みの上でつながります。集計はバッチで定期的に行われ、再構築の間隔を設定して最新の状態を保ちます。

分析 —— 数えて、見せる

記録したログと配信の結果は、分析ダッシュボードに自動で集計されます。記事やページの閲覧の傾向、フォーム・会員・メールのそれぞれの動きが、管理画面の中で数字として確認できます。

他システム連携 —— 拡張ポイントで、個別につなぐ

外部システムとの連携は、固定の連携機能としてではなく、環境に合わせた個別の開発としてwriteWiredに組み込みます。連携方式・データ形式・更新頻度は、つなぐ相手ごとに設計します。

作り方は2つ

作り方	どこに、何を作るか
プラグイン	パッケージに用意されたデータ処理の拡張ポイントに、独自の処理を埋め込む。本体をカスタマイズしないため、バージョンアップ後も互換性を保つ
アドオン	外部システムと連動する独自のプログラムを、要件に合わせて作る。管理画面や、集計・取り込みのバッチ処理など

writeWiredは自社開発のパッケージです。拡張ポイントの仕様も、連携の検討に必要な技術情報も、開発元として提示できます。

データの入口

受け取るデータは、コンテンツよりも業務のデータが中心です。基幹システムが持つ会員の情報や、セミナーの受講履歴のようなデータを、会員や問い合わせのデータベースへ取り込みます。外部システムやデータベースからコンテンツを自動で取得してサイトへ反映する取り込みや、媒体ごとのフォーマットを正規化するCSVの一括取込も作れます。

取り込みの際には、項目のマッピングと、桁・型・必須の検証を挟んで、データの整合性を保ちます。コンテンツは項目の集合として、問い合わせと会員はフォームの定義として持たれているので、取り込みはどれも項目単位の対応付けになります。

データの出口

送る側も同じです。会員や問い合わせのデータを、所定のスケジュールでCSVなどにエクスポートして、他システムへ渡す定期出力を作れます。

コンテンツの出口はAPIです。APIでコンテンツを配信する構成に対応し、Webサイト・アプリ・デバイスへ同じコンテンツを配信できます。テンプレートの節で述べた「項目単位で取り出す」の取り出し先が、自サイトの外まで広がる形です。

外部のデータを、公開面で使う

既存の基幹システムのデータと連携して、検索や照会の結果をWebに表示する公開面を作れます（テンプレートの節で述べた検索システムの、連携版です）。外部のレコメンドの結果を受け取って、サイト上の表示に使うこともできます。