モジュールアンケート

モジュールアンケートは、BOSHU の募集の追加の質問、4S の参加登録（チケット）の設問、イベントの団体の登録フォームを、同じ仕組みで組む機能である。設問はページの並びで、ページにモジュールを並べ、モジュールは主体ごとの一連の質問である。

どこでも同じモジュールを使うので、プロフィールや団体の基本情報は答えておけばほかの募集やチケットで引用でき、登録済みの人は欠けている欄だけを答える。運営は質問を毎回書き起こさず、棚のモジュールを置いて組む。

設問はページ、モジュール、質問の入れ子でできている。ページは答える人が見る画面の単位、モジュールは「本人の基本情報」「発表の内容」のような意味のまとまり、質問は回答の欄そのものである。

モジュールには共通モジュールと固有のモジュールがある。共通モジュールは棚に置き、いくつもの設問から参照する。固有のモジュールはその募集・チケットだけの質問で、コンセプト固有の質問や連絡用の QR などはここに入れる。

棚はイベントごとの棚と、全イベント共通の棚に分かれる。共通モジュールを置いた設問どうしは質問の鍵が同じになるので、CSV の列も、複数の募集にまたがる共通の質問もそろう。共通モジュールを「この設問だけ」の写しにすると鍵を作り直し、CSV では別の列になる。

上の「モジュール」の一覧は、層ごとのまとまりで並ぶ。層は「主体」「企画」「チケット」である。主体は本人の基本情報と団体の基本情報で、値の正本はプロフィールと団体の登録にある。企画は結んだ企画の表示・発表の内容・当日の準備・同意・スタッフのシフトや連絡先・知ったきっかけで、回答は応募ごとに残る。チケットはイベントごとのマッチングの設問と、募集への応募である。

各行は、モジュールの名前、鍵、置ける行き先の札でできている。鍵は棚と回答の鍵の頭になり、版をまたいで変わらない。イベントごとのモジュールは鍵の後ろにイベントが付くので、頭だけを省略の印付きで出している。

行き先の札の「BOSHU」は募集の応募のページ、「チケット・」で始まる札はチケットの設問の各ページ（4S / GEEK 共通・プロフィール・このイベントの設問）を指す。札の無い行き先には、そのモジュールを置けない。

企画の表示は質問ではない。募集に結んだ企画の題・説明・日時・会場・登壇者・画像を応募の上に見せるだけで、版にも回答にも入らない。ログインが要るモジュールを置いた募集は、応募のログインを「不要」にできず、組み立ての画面がその理由を出す。

設問の持ち主は、募集では募集そのもの、チケットではイベントである。募集の設問は送信の前に置く単独のページで、チケットの設問は行き先ごとにページを持つ。棚・組み立ての部品・検査は共通で、画面とサーバが同じ検査を使うので、画面で通ったものがサーバで落ちることはない。

違うのは保存の意味だけである。チケットの設問は下書きを直してから公開する。募集の設問は保存がそのまま新しい版になる。

回答の置き場も出どころごとに決まる。募集の回答は応募ごとに残る。チケットの回答は行き先ごとで、4S / GEEK 共通は 4S へ、プロフィールのページは本人へ残して次のイベントでも使い、このイベントの設問はそのイベントに残す。プロフィールのページに共通モジュールしか置けないのは、本人に残す回答の鍵をイベントをまたいでそろえるためである。

募集の質問を直して保存すると新しい版を足し、応募はどの版に答えたかを持つ。公開済みの版は書き換えないので、古い応募は答えたときの文言のまま読める。答える人に見える質問が変わらない保存（並びや置き方だけの変更）では、版を足さない。

CSV の列はすべての版の質問の鍵を合わせて作る。質問を作り直したときは、古い鍵の回答を新しい質問の回答として読む付け替えを版に持たせる。回答の行そのものは書き換えない。

募集に置いた共通モジュールは、置いた時点の中身で固定する。棚の側が直されると要約に「棚に新しい版」と出て、運営が「棚の新しい版にする」を押したときだけ新しい中身へ移る。ほかの募集のための編集で、公開中の質問が知らないうちに変わらないようにするためである。

質問の審査が有効な募集では、応募者に見えるのは承認済みのいちばん新しい版のままで、保存した版は審査の後に出る。

質問の種類は記述・長文・単一選択・複数選択・チェック・URL・日付・画像で、チケットのページでは資料のファイルも使える。質問ごとに必須とヘルプを付けられ、連絡先のように個人情報に近い回答には個人情報の印を付ける。

分岐は、同じモジュールの前にある選択式の質問の選択肢を引き金にして、後ろの質問を出し分ける。どこまで深く重ねられるかは行き先ごとに決まっており、チケットの 4S / GEEK 共通のページは 4S の形に合わせて浅い。

本人の基本情報の質問はプロフィールの欄に結んでいる。値があれば「プロフィールの内容です」と引用して読むだけにし、「直す」も選べる。値が無ければその場で聞き、送信のときにプロフィールの編集と同じ検証を通して書き戻す。名前と所属団体は書き戻さず、値が無ければその応募でだけ答える。結んだ質問の答えは回答の表に複製せず、提出時の写しとして応募に残す。

団体の基本情報も同じ考え方で、登録済みの値は固定して見せ、欠けている欄だけを聞いて団体へ書き足す。このモジュールは団体を新しく作らない。

応募の画面の頭には「本人確認 → 基本情報 → 応募の質問」の工程の帯を出す。チケットでは最後の段が「イベントの質問」になる。段の中身はモジュールの並びから作り、欠けている項目が無い段は「飛ばす」として理由を添える。

確認の段は置かない。最後の段のボタンがそのまま送信になる。残りの問数や所要時間も出さない。答える人の手を止める表示を減らすためである。

ログインが要らない募集でも、本人確認は 4S のメールのコードで行い、その場でアカウントを作って本人の応募として送る。送った後は「受け付けました」と、結果の連絡の時期と手段を同じ画面とメールで知らせる。

イベントの団体の登録フォームは、団体・登録者・イベントとの連携・応募内容の各モジュールでできている。団体は団体の登録の欄で、承認は SPIKES PLATFORM の運営が行う。登録者は BOUNTY のアカウントと同じフォームの中の 4S のログインで、承認は無く同意を書く。

イベントとの連携はイベントのパートナー募集の質問で、パートナー登録としてイベントが承認する。応募内容は GUILD ROYALE などの企画募集の質問で、イベントの選考にかかる。

団体と登録者は直せないシステムのページで、組み立ての画面では鍵付きの「固定」のカードとして聞くことだけを並べる。イベントとの連携と応募内容は募集の設問のページなので、モジュールを置いて直せる。

組み合わせ（パターン）は platform・partner・royale である。platform は団体と登録者で、SPIKES PLATFORM への団体の登録だけを行う。partner はそこにイベントとの連携を足したパートナー登録、royale はさらに応募内容を足した企画募集への応募である。

並び順はどの組み合わせでも、登録者 → 団体 → イベントとの連携 → 応募内容で同じである。本人を先に置くのは、ログインした本人の所属から団体を選べるようにするためである。新しい学生団体は団体の欄を入れてから進める。

送信は最後の段のボタンで行い、サーバは組み合わせの順に各モジュールを回し、単一の transaction で書く。どこかで断られれば全部が戻る。

パートナー募集のフォームは、同じイベントの受付中の企画募集があれば「イベントとの連携」の段でその企画に参加するかを聞く。「はい」で応募内容の段が出て企画募集にも応募し、「いいえ」ならパートナー登録だけになる。切り替えても先に答えた回答は消えない。審査の画面は、登録者・申込時の団体・イベントとの連携・企画の見出しで同じ順に並ぶ。

運営が募集に「チケットで案内する」の印を付けると、チケットの設問に置いた「募集への応募」のモジュールの位置で「〇〇に応募しますか」と はい / いいえ を聞く。印を付けられるのはイベントと運営の個人向けの募集で、団体で応募する募集は入口へのリンクだけを出す。出す募集は表示のときにサーバが読むので、チケットの設問の版を上げずに出し入れできる。

「はい」は本人だけの下書きを作るだけで、応募にはならない。「いいえ」も記録して、ホームで聞き直さない。参加登録（チケッティング）が先で、送り終えた画面が「次は〇〇の応募」と案内する。

「はい」の募集が複数あり、同じ鍵で聞く質問があれば、共通の質問としてまとめて答える。募集ごとに違う値が入っている鍵は共通にせず、募集ごとに聞く。送るのは募集ごとで、途中でやめても答えは下書きに残る。

後から印を付けた募集は、既に参加登録した人へ知らせ、ホームの「新しい募集」に出す。運営に見えるのは、はい・書き始めた・提出の件数だけで、名前は出さない。

イベントの管理の「フォーム」が、そのイベントの設問を組む画面である。「登録フォーム」と「チケットの設問」を切り替えて使い、切り替えても直しかけの内容は消えない。段はカードで並び、閉じた要約から開いて直す。運営の募集の編集の画面も同じ部品と同じ棚を使う。

棚は横のパネル（スマホでは下のシート）に出る。「追加」でページの最後へ置き、つまみを掴めば好きな位置へ動かせる。キーボードでも並びを変えられる。固有のモジュールは「…」の「棚に入れる」で共通モジュールにでき、質問の鍵は変えないので CSV の列もそのまま残る。プレビューで答える人の見え方を確かめられる。

タイムテーブルや企画の一覧の「公募を作る」は、企画に合うテンプレートで下書きの募集を作り、この画面を開く。テンプレートはモジュールの組み合わせで、差し替えると消える質問を先に知らせる。応募のある募集はテンプレートを変えられない。

公開は、応募と結果のメールの文面を確認してから行う。非公開に戻しても届いた回答は残る。承認済みの団体の募集の質問を運営の管理者でない人が直すと承認のやり直しになるので、保存の前に確認を出す。

MCP の道具は、棚を読む・募集の設問をモジュールの形で読む・操作を試す・操作を当てる・モジュールから新しい下書きの募集を作る、の各道具である。操作は棚のモジュールを置く・固有のモジュールを足して直す・写しにする・棚の新しい版にする・外す・棚に入れる・分けるで、人の組み立ての画面の保存と同じ関数を通る。

試す道具は保存と同じ処理を走らせて必ず巻き戻し、版が増えるか、承認のやり直しが起きるか、書きかけの下書きから消える回答の数を返す。当てる道具は同じ操作の一覧を単一の transaction で書き、読んだ時点の値と違えば断るので、人の編集を上書きしない。

公開済み・締切後の募集には、版を増やさない操作だけを当てられる。公開・承認・共通モジュールそのものの編集は人が画面で行う。応募者・回答・連絡先は返さず、件数だけを返す。入口の一覧はこの頁の下の関連から辿れる。