アーキテクチャの基本的な要素
もし世界がいつも単純で具体的なら、プログラマの居場所はないだろう。まずは、具体的な個人や団体やサービスのかわりに、抽象的な要素を定義する。
- 提供サービス
リクエスト センターという代物は、「誰かが Web 上でサービスを提供しており、その利用者が質問や疑問を抱く」という想定から始まる。 そのサービス（ネットショップ、Web アプリ、パッケージソフトの広報など）のことを、「提供サービス」とする。
- 訪問者
提供サービスに質問・疑問を抱いて、リクエスト センターにやってきた人のことを、「訪問者」とする。
- リクエスト センター
訪問者の目には Web アプリとして映る。
- リクエスト、コメント、記事、スレッド、親子関係
訪問者が疑問・質問を記して投稿した記事のことを「リクエスト」とする。リクエストで提起された疑問・質問を解くための記事を「コメント」とする。 なお訪問者もコメントを投稿することができる。そして、リクエストとコメントはどちらも「記事」である。なお記事にはリクエストとコメント以外のものもある（後述）。
ひとつのリクエストに対して、1個以上のコメントがつく。この、リクエストとそれに対応するコメントの集合のことを「スレッド」とする。 また、リクエストとコメントの対応関係を「親子関係」とする。リクエストは複数の子（コメント）を持つことができるが、コメントは単一の親（リクエスト）しか持たない。 なおリクエストに対応するのはコメントとは限らない（後述）。
- オペレータ
訪問者から寄せられた記事に一番最初に対応する人である。
- 回答者
もし提供サービスの運営者が団体であれば、オペレータが回答できないリクエストが寄せられることがある。 このときオペレータは、リクエストの内容に応じて適切な「回答者」を割り当てる。
基本的な成功シナリオ
検索・発見シナリオ
- 訪問者 A は提供サービスについて知りたいことを見つける
- 訪問者 A は質問する先を探して、リクエスト センターへとたどりつく
- 訪問者 A はリクエスト センターで検索し、自分の知りたいことを見つける。シナリオ終わり
質問・回答シナリオ
- 検索・発見シナリオの2までと同じ
- 訪問者 A はリクエスト センターで検索したが、自分の知りたいことを見つけられない
- 訪問者 A はリクエストを投稿する。投稿後の画面で、「回答状況を知るにはこのページをブックマークしておき、後で開いてください」と書いてあったので、ブックマークする
- オペレータはリクエストに回答するコメントを投稿する
- 翌日、訪問者 A が例のブックマークを開くと、オペレータの回答が出ていた。それを読んで A は疑問を解決する。シナリオ終わり
回答者シナリオ
- 質問・回答シナリオの4までと同じ
- オペレータはリクエストを読んで、回答者 X を割り当てる
- 回答者 X はリクエストに回答するコメントを投稿する
- 質問・回答シナリオの5と同じ
対話シナリオ
- 質問・回答シナリオの3までと同じ
- オペレータは訪問者 A の状況を詳しく知るために、訪問者 A に対して質問するコメントを投稿する
- 翌日、訪問者 A が例のブックマークを開くと、オペレータのコメントが出ていた。それを読んで A はオペレータの質問に回答するコメントを投稿する
- 質問・回答シナリオの4からと同じ
詳細な要素
基本的な成功シナリオだけを想定することはできない。
- リクエストが解決していないスレッドをどう扱うのか
- 訪問者が見つけられなかった既存のスレッドがあった場合はどうするのか
- オペレータによる回答者の割り当てが適切でなかった場合はどうするのか
- 運営側は記録しておきたいが訪問者には見せられない内部情報はどうするのか
基本的な成功シナリオにしても、
- オペレータが回答者を割り当てるというのは、具体的には何がどうなるのか
- 対話シナリオにおいて、オペレータの質問に答える訪問者が訪問者 A であると保証するにはどうするのか
こうした詳細を処理するために、詳細な要素が必要になる。
- 著者
記事はかならず1個の「著者」という要素を持つ。著者は名前とパスワードを持つ。パスワードが一致しなければ投稿することはできない。 これにより対話シナリオの問題は解決する。
- 記事の状態
記事は状態を持つ。
- 新着
- コメント
- 内部閲覧用
- 概要
- 重複
- 対応中
- 対応しない
- 対応済み
「対応中」「対応しない」「対応済み」はリクエストである。「重複」は、その記事が親リクエストと重複していることを示す。「概要」はスレッドの概要を示す。
- タスク、タスク置き場
オペレータは「タスク」という要素を作成し、これを「タスク置き場」に配置することができる。タスクは1個の記事を持つ。 回答者はタスク置き場からタスクを取り出して、タスクの記事に回答し、タスクを削除する。
オペレータによる回答者の割り当てが適切でなかった場合、回答者は、タスクの記事に回答するかわりに、内部閲覧用の記事を書いて、 この記事をオペレータに割り当てることができる。このアクションを「差し戻す」とする。
- 添付ファイル
記事にはファイルを添付することができる。
- 設定
運営側とまぎらわしい名前での投稿を未然に防ぎ、オペレータや回答者の名前に特別な表示を行って目立たせることができる。
詳細または瑣末な成功シナリオ
詳細な対話シナリオ
- 質問・回答シナリオの2までと同じ
- 訪問者 A はリクエストを投稿する
- 訪問者 A がリクエストセンターに投稿するのはこれが初めてである
- 名前欄、パスワード欄、本文欄をそれぞれ記入し、投稿する
まだ登録されていない名前での投稿があった場合、その名前とパスワードは、新規の著者として記録される。
- 投稿後の画面で、「回答状況を知るにはこのページをブックマークしておき、後で開いてください」と書いてあったので、ブックマークする
- オペレータは訪問者 A の状況を詳しく知るために、訪問者 A に対して質問するコメントを投稿する
- オペレータは親記事の状態を「対応中」に変更する
- 翌日、訪問者 A が例のブックマークを開くと、オペレータのコメントが出ていた。それを読んで A はオペレータの質問に回答するコメントを投稿する
- 名前欄、パスワード欄、本文欄をそれぞれ記入し、投稿する。なお名前欄とパスワード欄には、先日と同じものを記入する
なお実際には cookie によって名前欄とパスワード欄は記入するまでもなく埋まっている。
- オペレータはリクエストに回答するコメントを投稿する
- オペレータは親記事の状態を「対応済み」に変更する
- 質問・回答シナリオの5と同じ
重複シナリオ
- 質問・回答シナリオの3までと同じ
- オペレータは、訪問者 A の投稿した記事と同じ内容の過去のリクエスト P を発見する
- 訪問者 A の投稿した記事を、リクエスト P の子にする
- 訪問者 A の投稿した記事の状態を「重複」にする
- 翌日、訪問者 A が例のブックマークを開くと、「このリクエストは重複しています」と書いてあったので、重複元のスレッドを読んで A は疑問を解決する。シナリオ終わり
タスクの優先順位
パッケージソフトのリリース直後のように、回答に労力を要するリクエストが重なる場合、タスクに優先順位をつける必要が生じる。 これはタスク置き場のなかの記事セルの上下関係として表現される。一番上の記事セルが最優先のタスクとなり、 回答者には最優先のタスクだけが渡される。
タスク置き場のなかの記事セルの上下関係はドラッグ アンド ドロップによって操作できる。
ソフトウェア コンポーネントの配置
Yamibou は以下のコンポーネントから成る。
- 訪問者の Web ブラウザ
- リクエスト センターをサービスする Web アプリケーション
- yamibou-2ch: 2chスタイルのインターフェイス
- yamibou-riu: りうスタイルのインターフェイス
- オペレータ用クライアント yamibou-operation
- 回答者用クライアント YamibouRespondent
- 回答者の Web ブラウザ
なお全ユーザ（訪問者、オペレータ、回答者）は補助的に RSS フィードを利用できる。
リクエスト センターをサービスする Web アプリケーション
動作環境：
RDBMSは用いない。
オペレータ用クライアント yamibou-operation
SOAP によりリクエスト センターと接続する。
動作環境：
回答者用クライアント YamibouRespondent
SOAP によりリクエスト センターと接続する。タスクの到着を常時監視するためにデスクトップに常駐することを意図して作られている。
動作環境：
配置方法
オペレータ用クライアント yamibou-operation と回答者用クライアント YamibouRespondent は、 リクエスト センターからダウンロードして実行またはインストールすることができる。
