Web制作のナレッジ / 特設サイト制作の進め方
トイレ我慢サイト設計ノート
トイレ我慢ゲーム特設サイトを作ったときに、事前調査から公開まで、どのような順番で、何を考えて決めたかをまとめた資料です。特設サイトやLPの制作を9つの工程に分け、工程ごとに「考えたこと」「決めたこと」「次回も使えるポイント」を整理しています。
- 内容
- 6作品を紹介する1ページのサイト
- 工程
- 事前調査から公開まで 9工程
- 動作確認
- 画面幅5種類 × 表示状態3種類。不具合7件を修正
実演 / 走る会社員
過去に決めたことや使える素材を先に確認すると、依頼者への質問を減らせます。
渦の演出を「トイレの水の渦」と結びつけることで、派手な演出にも意味が生まれます。
自分の画面で問題がなくても、スマホなど別の画面サイズでは崩れることがあります。
事前調査
過去の決定・素材・注意点を確認する
考えたこと依頼者に改めて聞かなくても、すでに分かっていることは何か。
作業を始める前に、過去の作業記録と、過去の失敗や注意点をまとめたナレッジを確認しました。その結果、同じシリーズでPRサイトを2つ作っていたことが分かりました。
記録には、過去に依頼者が決めた方針が残っていました。「明るく映画のような雰囲気」「アニメーションは多め」「ログインや課金の機能はなし」「動きを減らすボタンを付ける」などです。これらが分かっていれば、同じ質問を繰り返す必要はありません。
決まっていること
明るい雰囲気→ 今回は暗めに変更- アニメーションは多め
- 個人のサイト(ログインなし)
- 「動きを減らす」ボタンを付ける
使える素材
- 既存のPRサイト 2つ
- 作品データ(5作品分)
- プレイ動画 5本
- イラスト・ゲームオーバー画面・オープニング動画
注意点
- 日本語フォントはページの読み込みを重くする
- 公開先で「.html」が省略され、下の階層のページが開けなくなることがある
- 非表示にしたはずの要素が、クリックを邪魔することがある
- 画像の縦横比のずれを見落としやすい
- 過去の方針は「確定」ではなく「回答案」として使う。今回は変わる可能性もある前提で扱う。
- 注意点は作業前に確認しておく。作った後に気づくと、修正の手間が増える。
参考サイトの分析
見た目ではなく、仕組みを言葉にする
考えたこと参考サイトの「どこ」を取り入れるのか。
参考にしたのは、中央の画像が分割され、周囲に大きく変形していく「とろけるような背景」の事例紹介です。記事には、技術的に難しい表現なので制作工数に注意が必要、とも書かれていました。
記事だけで判断せず、元のサイトも開いて実際の動きを確認しました。そのうえで「かっこいい」という印象ではなく、どういう仕組みで動いているかを3つに分けて書き出しました。この3つが、そのまま作るものの仕様になります。
構造中央の円と外側
中央に円形の画像。その外側を、同じ画像を引き伸ばして埋める。
動き輪ごとに回転する
外側を何重かの輪に分け、輪ごとに違う向き・速さで回すと、溶けているように見える。
切り替え割れて、次が現れる
次の画像に移るとき、画像が4つに割れて外へ広がり、中心から次の画像が現れる。
- 参考サイトのプログラムや画像は使わない。仕組みだけを参考にし、プログラムは自分で書く。
- 「処理が重い」という注意点には、動きを止める機能と、画面の外では描画を止める仕組みで対応する(工程07)。
素材の選定
演出に合う素材を選ぶ
考えたこと手元の素材のうち、円形の演出に入れて見栄えがよいのはどれか。
既存の2つのサイトから、画像・動画・作品データを33ファイル(約15MB)集めました。ただし、そのまま全部使ったわけではありません。この演出は、画像の中心を拡大し、外側に引き伸ばします。そのため、選ぶ基準は「きれいかどうか」ではなく、次の3点です。中心に人物などの主役がいるか。奥行きがあるか。字幕やボタンなどの文字が画像に入っていないか。
文字が中心のタイトル画面などは、渦にすると文字がぐるぐる回って読みにくいだけになります(下の×の円を参照)。そこで、プレイ動画やオープニング動画から、演出に合う1場面を切り出して使いました。
走る会社員(オープニング動画の1場面)
- 中心に人物
- 奥行きあり
- 字幕が入っている
採用(字幕の部分を切り取って使用)
まっすぐな通路(マイクラ風のプレイ画面)
- 通路の奥が中心
- 奥行きあり
- 上に操作画面の表示
採用(最も演出に合う)
投手のイラスト(縦長)
- 人物が中央
- 背景が暗め
- 文字なし
採用
告知画面(約束の地へ)
- 文字だけ
- 奥行きなし
- 白い余白が多い
変更 → プレイ中のマップ画面
タイトル画面(マイクラ風)
- 暗く、文字が中心
- 主役がいない
- ボタンが写っている
変更 → 通路のプレイ画面
ポスター(3D)
- 人物はよい
- 奥行きあり
- 操作表示の文字が入っている
変更 → 動画の1場面
事実は実物で確認する。2つのサイトで、掲載している作品が少し違っていました(「2D」と「トイレまで3マイル」)。記憶や推測で判断せず、公開中のゲームを両方開いて比べました。同じ仕組みのゲームの元の版と改良した版だと確認してから、6作品として掲載しています。
- 6作品それぞれに、演出用の画像を1枚ずつ選ぶ。作品紹介用のポスターと、演出用の画像は別に考える。
- 動画から画像を切り出すときは、字幕や操作表示を切り取る(ここを確認しきれなかったことが、工程08の不具合3につながりました)。
ヒアリング
依頼者にしか決められないことだけを質問する
考えたこと最大13問のヒアリング項目のうち、今回本当に質問が必要なのはどれか。
サイト設計の手順には、目的・対象者・構成・デザインなど、最大13問のヒアリング項目があります。工程01で確認した過去の方針を当てはめると、多くの項目にはすでに答えがありました。その回答案は表にまとめて見せ、「違うところだけ教えてください」とお願いしました。
残った質問は4つです。そのうちの1つ、ページ全体の雰囲気は、過去の「明るい」から「暗め」に変わりました。過去の方針はあくまで回答案で、決定ではありません。この質問をしたのは正解でした。
- ① 掲載する作品は?(2つのサイトで違っていた)→「全部」=6作品
- ② 新しいサイトにするか、既存サイトを置き換えるか?→ 新しいサイト
- ③ ページ全体の雰囲気は?→ 暗め(過去の方針と逆)
- ④ 既存サイトの素材をダウンロードして使ってよいか?→ すべて使ってよい
- 質問する前に回答案を表で見せる。依頼者は違うところだけ直せばよいので、確認の負担が小さい。
- 外部に公開される操作や、取り消しにくい操作(素材のダウンロード、公開先のアカウントなど)は、必ず事前に確認する。
コンセプト設計
演出とテーマを結びつける
考えたこと「なぜこの演出なのか」と聞かれたときに、理由を説明できるか。
理由のない派手な演出は、「どこかで見たことがある」「作り物っぽい」という印象を与えがちです。そこで、1つ1つの演出を、サイトのテーマ(トイレを我慢するゲーム)と結びつけました。
たとえば、円の外側が渦を巻く演出は「トイレの水の渦」、作品の切り替えは「水を流す」イメージです。こうすると、同じ派手な演出でも、このサイトで使う理由がはっきりします。
円の外側が渦を巻く参考サイトの表現
トイレの水の渦テーマそのもの
画像が割れて、中心から次の作品が現れる作品の切り替え
水を流す前の作品を流して、次の作品へ
画面の右下に、ページのどこまで読んだかを表示読み進めた量
我慢ゲージ「まだ余裕」から「限界寸前」まで
スクロールすると画面が溶けるページ後半の見せ場
我慢の限界、ゲームオーバー便意 78% → 100%
読み込み中に円が満ちていく最初の数秒
我慢ゲージをためている待ち時間もテーマの演出にする
- ページを読み進めた量を「我慢ゲージ」で表示し、最後まで読むこと自体を小さなゲームにした。
- 目立つ演出をいくつも重ねない。主役の演出を1つ決め、ほかは主役を邪魔しない補助にとどめる。
ページ構成
各セクションの目的を決める
考えたこと各セクションは、見る人に何をしてもらうためにあるか。
ページは上から「第一印象 → 世界観の紹介 → 作品を選ぶ → キャラクター紹介 → オープニング動画 → ゲームオーバーの演出 → ゲームを遊ぶ」の順に並べました。「PLAY(遊ぶ)」ボタンはページの最後だけでなく、最初の画面・各作品の紹介・ゲームオーバーの演出・最後の一覧に置きました。どこで興味を持っても、すぐにゲームを遊びに行けるようにするためです。
スクロールに合わせて画面が動くセクション(最初の画面とゲームオーバー)は長めに、読むためのセクションは標準の長さにしました。下の図の縦の長さは、実際のページ(画面幅1440px)の長さの比率です。
第一印象をつくる円形の演出で6作品を自動で紹介PLAY
WORLD世界観を伝える6作品を路線図のように一覧表示
WORKS作品を比べて選んでもらう作品ごとに動画・数字・舞台・キャラクター・操作方法PLAY ×6
CAST親しみを持ってもらう投手5人・駅や会社の人々
OPENINGストーリーに引き込む音はクリック後に再生
GAME OVER笑ってもらい、印象に残す便意78%→100%で画面が溶け、ゲームオーバー画面へリベンジ
PLAY遊んでもらう6作品のカードPLAY ×6
- 目的が2つあるセクションは分ける。1つのセクションで「説明」と「笑い」を両方やらない。
- 笑いどころ(ゲームオーバー)は、最後の「遊ぶ」セクションの直前に置く。笑った直後が、いちばん遊びたくなるタイミングだから。
実装
データ・部品・代替表示の設計
考えたこと作品が7つに増えたり、演出を別の場所で使ったりしても、壊れない作りになっているか。
実装で意識したのは3点です。作品の情報は1つのファイルにまとめる。演出は部品にして使い回す。動きを止めた表示などの代替表示を最初から用意する。こうしておくと、修正が必要になったときに、直す場所が1か所で済みます。
A円形の演出のしくみ(上の実演と同じもの)
B同じ部品を別の場所で使い回す
最初の画面6作品を自動で切り替え。マウスの位置で円の中心が少し動く
ゲームオーバーの演出溶け具合・渦・円の大きさを、スクロール量に連動させただけ
C作品の情報は1つのファイルにまとめる
最初の画面の作品切り替え
路線図と作品紹介(6作品分)
キャラクター紹介
最後のPLAYカード
D代替表示を最初から用意する
動作確認
画面幅と表示状態ごとに確認する
考えたこと自分の画面できれいに表示されていれば、本当に完成と言えるか。
完成したページは、5種類の画面幅と3種類の表示状態で撮影し、目で確認しました。確認用のブラウザを自動で操作し、スクロール位置を指定して撮影しています。その結果、プログラムを読むだけでは見つからない不具合が7件見つかりました。
円を広げると、動画の字幕が写り込む

修正前修正後円の中では見えなかった字幕が、スクロールで円を広げたときだけ見えていました。動画から画像を切り出す範囲を、上下とも狭くしました。
「GAME OVER」の文字が、笑いどころの絵を隠している

修正前修正後一番見せたい部分(ユニフォームのお尻)と一番大きい文字が、同じ左下に重なっていました。文字を右上に移し、縦長の画面では縦長のイラストに切り替えました。
スマホで本文が右端で切れる

前後画面幅390pxのときだけ発生しました。1列のレイアウトが、中身の幅に合わせて横に広がっていました。
高さの低い画面で、番号と縦書きの文字が重なる

前後公開後に見つけた不具合です。390×844では起きず、503×699のような高さの低い画面でだけ発生しました。
実演1文字ずつ動かすと、句読点が行の先頭に来る
満員電車を降りた瞬間から、戦いは始まっている。
満員電車を降りた瞬間から、戦いは始まっている。
実演回転する要素は、外枠が大きくなる
元の大きさ:96px
回転中の外枠:96px
句読点が行の先頭に来る
- 原因
- 文字を1つずつ動かすために別々の要素に分けると、「句読点を行の先頭に置かない」というルール(禁則処理)が効かなくなる
- 修正
- 句読点や閉じかっこを、前の文字と同じ要素にまとめる
- ポイント
- 文字を1つずつ動かすときは、禁則処理を自分で行う
ページが横にはみ出す
- 原因
- 回転する輪の外枠は、回転すると大きくなる(上の実演)
- 修正
- はみ出した部分を切り取る設定にする(画面上部に固定する表示が壊れない方法を選ぶ)
- ポイント
- 回転や拡大をする要素は、外枠の大きさで確認する
円の中に字幕が写る
- 原因
- 動画から切り出した画像に、字幕と操作表示が入っていた
- 修正
- 上下を切り取って、画像を作り直す
- ポイント
- 動画から画像を切り出すときは、画像に入っている文字を確認する
スマホで本文が切れる
- 原因
- 1列のレイアウトが、中にある一番幅の広い要素に合わせて広がった
- 修正
- レイアウトの最小幅を0に指定して、画面幅に合わせて縮むようにする
- ポイント
- 1列のレイアウトでは、最小幅を0に指定する
文字が笑いどころの絵を隠す
- 原因
- 画像の見せたい部分と、大きな文字の位置が同じだった
- 修正
- 文字を右上に移動し、縦長の画面では縦長のイラストを使う
- ポイント
- 先に画像の見せたい部分を決め、文字はそこを避けて配置する
読み込み中にスクロールするとエラーになる
- 原因
- 画像の読み込みが終わる前に、動きの計算が始まった
- 修正
- 読み込みが終わるまで計算しないようにする
- ポイント
- 読み込みを待つ処理には、「まだ準備できていない場合」の分岐を必ず入れる
高さの低い画面で番号と縦書きが重なる
- 原因
- 縦書きの文字は、画面の高さによって長さが変わる
- 修正
- 番号を左下に横一列で並べる
- ポイント
- 縦書きを使うときは、高さの低い画面でも確認する
公開
アップロード後に、ファイルと表示を確認する
考えたことアップロードが終わったら、公開は完了と言えるか。
公開用のフォルダを別に作り、設計書などの内部資料は含めないようにしました。さらに、セキュリティの設定(読み込めるプログラムを自分のサイトのものだけに制限するなど)と、SNSでリンクを共有したときに表示される画像を追加してから、アップロードしました。
アップロード後は、公開された47ファイルがすべて手元のファイルと同じかを確認し、実際のブラウザでエラーが0件であることも確認しました。この確認の途中で、工程08の7件目の不具合(番号と縦書きの重なり)が見つかり、修正して再度公開しています。
- 公開用フォルダを作成内部資料を除く
- セキュリティ設定読み込み元を制限
- 共有用の画像1200×630px
- アップロード47ファイル
- ファイルの確認手元と一致
- ブラウザで確認エラー0件
- 修正して再公開重なりの修正
つまずいた点:Cloudflare(サイトの公開サービス)の新しい公開ツールが、別の仕組みで公開しようとして失敗しました。ツールの案内に従い、最初の作成時だけ強制オプションを付けて作成し、以降は通常の手順で公開しています。公開先のアカウントも、公開前に依頼者に確認しています。
次のサイト制作で使うチェックリスト
よくある質問
- 特設サイトは、どんな順番で作ればよいですか?
- この資料では「事前調査 → 参考サイトの分析 → 素材の選定 → ヒアリング → コンセプト設計 → ページ構成 → 実装 → 動作確認 → 公開」の9工程で進めました。ヒアリングの前に事前調査を置くことで、依頼者への質問を減らせます。
- ヒアリングの質問を減らすには、どうすればよいですか?
- 過去の記録から回答案を作り、表で見せて「違うところだけ教えてください」とお願いします。質問するのは、過去に決まっていないこと、外部に公開される・取り消しにくいこと、人によって好みが分かれることだけです。実例では13問のうち9問が回答済みで、質問は4問でした(工程04)。
- 参考サイトは、どこを見て分析すればよいですか?
- 見た目の印象ではなく、「構造」「動き」「切り替え」の3点を言葉で説明できるまで観察します。その説明がそのまま制作の仕様になります。参考サイトのプログラムや画像は使わず、仕組みだけを参考にします(工程02)。
- 派手な演出を使うときに、気をつけることは何ですか?
- すべての演出について、サイトのテーマとのつながりを1行で説明できるかを確認します。説明できない演出は使いません。目立つ主役の演出は1つに絞り、補助の演出は3種類までにします(工程05)。
- 動作確認は、どこまでやればよいですか?
- 確認する画面幅と表示状態を先に決め、すべての組み合わせを撮影して目で確認します。実例では画面幅5種類(390・503・768・1024・1440px)と表示状態3種類(通常・動きを減らす・WebGLなし)の15通りを確認し、プログラムを読むだけでは見つからない不具合を7件見つけました(工程08)。
- 公開した後に、何を確認すればよいですか?
- 公開されたファイルがすべて手元のファイルと同じかを確認し、実際のブラウザでエラーが0件であることを確認します。実例では47ファイルすべての一致を確認し、その途中で見つかった表示の不具合を修正して再公開しました(工程09)。