投稿する
マガジン
著者：アソバース編集部公開：更新：約11分で読めます

スマホ対応を最後に回すと、何か所直すことになるか：変更箇所を数える実験の設計書

遊びをつくる

執筆にClaudeを使用しています。

小さな迷路の壁を一か所取り外し、通り道を確かめる模型。
記事のテーマをもとに制作したAI生成イメージ。実際のゲーム画面ではありません。

PCのブラウザだけで試作を作り、動きが固まってからスマホで開く場面を考えてみます。キーボードで動かす前提で組んだゲームを手に持った画面に出したとき、直す箇所は数か所で済むのか、設計の根っこまで触ることになるのか。感覚では「意外と面倒だった」「案外すぐ済んだ」とどちらも言えてしまい、次の試作でどう備えるかが決まりません。 そこで、この記事は「直す量」を数える実験の設計書として書きます。結果は載せていません。同じ手順を自分の試作で行えば、変更箇所の数、種類、かかった時間が手元に残ります。それを自分の予想と並べると、スマホ対応を最初に考えるべきか最後でよいかを、自分の制作スタイルで判断できます。

この記事の目次
  1. 問いを「数えられる形」にする
  2. 準備するもの
  3. 手順
  4. 記録の取り方
  5. 結果の読み方
  6. 起こりやすい誤り
  7. 次の行動

問いを「数えられる形」にする

「スマホ対応」は広い言葉です。そのまま測ろうとすると、何を数えたのかが後でぶれます。次の3つに分けて問いを立てます。

  • 変更箇所は何個か（修正の意図を1個として数えます）
  • 変更の種類は何に偏るか（入力、表示サイズ、レイアウト、文字、その他）
  • 変更は1か所に集まるか、ファイル全体に散るか

「直す量」は行数だけでは測りません。同じ「マウスをタッチに変える」修正でも、入力処理が1関数にまとまっていれば数行で済みます。クリック処理が各所に散っていれば十数行になります。行数が少なくても修正の意図が多ければ、設計に画面の前提が染み込んでいたと読めます。そのため、行数と意図の数の両方を記録します。

準備するもの

  • PCのブラウザとエディタ
  • 実機のスマホ（できれば縦持ちと横持ちの両方で試せるもの）
  • 差分を見る手段（gitが使えるなら git diff --shortstat。使えなければ、対応前のファイルをコピーして保管し、比較ツールで差を見ます）
  • 記録用の表（スプレッドシートでもメモ帳でも構いません）
  • 題材を2〜3本。規模の違うもの（例：1画面で終わる反射神経ゲーム、盤面のあるパズル、スクロールするアクション）が望ましいです

試作の題材がまだなければ、次の最小構成を土台にできます。キーボードの矢印で四角を動かし、マウスで押した位置に印を出すだけの、PC専用の作りです。

html
<!doctype html>
<meta charset="utf-8">
<title>PC専用の試作</title>
<canvas id="c" width="800" height="600" style="border:1px solid #888"></canvas>
<script>
const c = document.getElementById('c'), g = c.getContext('2d');
let x = 400, y = 300, tx = null, ty = null;
const keys = {};
addEventListener('keydown', e => keys[e.key] = true);
addEventListener('keyup', e => keys[e.key] = false);
c.addEventListener('mousedown', e => { tx = e.offsetX; ty = e.offsetY; });
function tick() {
  if (keys.ArrowLeft) x -= 4;
  if (keys.ArrowRight) x += 4;
  if (keys.ArrowUp) y -= 4;
  if (keys.ArrowDown) y += 4;
  g.clearRect(0, 0, 800, 600);
  g.fillRect(x - 10, y - 10, 20, 20);
  if (tx !== null) g.strokeRect(tx - 5, ty - 5, 10, 10);
  requestAnimationFrame(tick);
}
tick();
</script>

これは「題材の例」です。実験の本体は、読者が実際に作る試作のほうです。ここで作った例は小さすぎて散らばり方が見えにくいので、自分の試作で行うことをおすすめします。

手順

1. 事前に予想を書く

スマホ対応を始める前に、次の3つを書き留めます。実測と並べるための基準です。

  • 変更箇所は何個になりそうか
  • いちばん多い種類は何か
  • 何分で終わりそうか

予想を書かないと、結果を見たあとに「だいたい思っていた通り」と記憶が書き換わります。

2. PC専用で仕上げ、その時点を固定する

スマホのことは考えず、PCで遊べる状態まで作ります。完成したらその時点のファイルを保存します。gitならコミットし、使わないなら別名でコピーします。以降の変更はすべてこの時点との差として数えます。

3. 実機で開き、気づいた順に直す

スマホで開き、動かない、見えない、押せない、と気づいた順に直します。直すたびに記録表へ1行足します。ブラウザの開発者ツールのスマホ表示だけで済ませず、最後は実機で確認します。タッチの感触や、画面の端の切れ方は、実機で初めて気づくことが多いためです。

対応後の姿を想像しやすいよう、先ほどの最小構成で出やすい修正を示します。これは「この題材で起こりうる例」であり、実際に何個になるかは試作次第です。

html
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>canvas{width:100%;max-width:800px;height:auto;touch-action:none}</style>
<script>
c.addEventListener('pointerdown', e => {
  const r = c.getBoundingClientRect();
  tx = (e.clientX - r.left) * c.width / r.width;
  ty = (e.clientY - r.top) * c.height / r.height;
});
</script>

ここには少なくとも3種類の修正が含まれています。画面幅の宣言（viewport）、表示サイズの可変化、マウスからポインター入力への置き換えと座標の換算です。さらにキーボード操作しかなければ、画面上のボタンなどの入力手段も別に足すことになります。こうした修正が1か所にまとまるか、散らばるかを数えるのが、この実験の中心です。

4. 終わりの基準を決めて止める

「PCと同じ遊びが、実機の縦持ちで最後まで通せる」を終了の条件にします。遊び方の改良や見た目の磨き込みは数えません。途中で混ぜると、スマホ対応の量が測れなくなります。

5. 題材を変えて繰り返す

別の題材でも同じ手順で行い、少なくとも2本分の記録を揃えます。1本だけでは、その試作の癖か一般的な傾向か区別できません。

記録の取り方

修正の「意図」を1行にします。同じ意図で3か所を機械的に書き換えた場合は、1行に「3か所」と書きます。意図ごとに数えると、行数の多さと設計の問題を分けて見られます。

  • 番号、書き方の例：通し番号
  • ファイル、書き方の例：変更したファイル名
  • 種類、書き方の例：入力／表示サイズ／レイアウト／文字／性能／その他
  • きっかけ、書き方の例：予想していた／実機で初めて気づいた
  • 行数、書き方の例：追加＋削除の合計
  • 所要時間、書き方の例：分単位
  • 波及、書き方の例：直した結果、別の修正が必要になったか

あわせて、全体の指標を1本ごとに残します。

  • 変更の意図の総数
  • 差分の追加行数と削除行数（全体の行数に対する割合も出します）
  • 種類ごとの内訳
  • 「実機で初めて気づいた」の数
  • 実機を開いて確認した回数
  • 合計の所要時間

結果の読み方

数字が揃ったら、事前の予想と並べます。判断の目安は次のとおりです。

  • 入力の種類に集中している場合： 操作の受け口が散らばっていたと読めます。次の試作では、キーボード、マウス、タッチを1か所で受けて「移動」「決定」のような共通の命令に変換する層を、最初に置くのが有効です。
  • 表示サイズの種類が多い場合： 座標やサイズに固定のピクセル値が散らばっていたと読めます。ゲーム内の論理座標と、画面に出す大きさを分けておくと、直す箇所が減りやすくなります。
  • 種類が散らばり、波及も多い場合： 画面の広さを前提にした判断が設計の随所に入っていたと読めます。この場合は「最後に直す」より、最初に小さな画面で動かすほうが総量は減る可能性があります。
  • 「実機で初めて気づいた」が多い場合： 修正量より確認の遅れが問題です。PCで作る途中でも、数回に一度は実機で開く習慣を足せます。
  • 意図の数が少なく、時間も予想内の場合： その題材では最後に回しても負担は小さいと読めます。ただし題材が1本だけなら結論は保留にします。

公式作品の設計も、読み方の参考になります。「紙ひこうき郵便」は左右キー、ドラッグ、矢印ボタンの3通りで操縦できます。「WAVE / WAVE」は狭い画面でステップが横スクロールになります。どちらも、入力と表示の幅を複数用意する作りです。実際にどのような作りで実現しているかは、作品を開いて確かめてください。

起こりやすい誤り

  • 数え方がぶれる： 同じ修正を行数で数えたり意図で数えたりすると、比較できなくなります。最初に単位を決めたら変えません。
  • 改良を混ぜる： スマホ対応のついでに演出を足すと、差分が膨らみます。別の作業として後日行います。
  • 整形ツールの差分： インデントの自動整形で全行が変わると、差分行数が無意味になります。実験中は整形設定を変えません。
  • エミュレーションだけで判断： PC上のスマホ表示は便利ですが、タッチ操作や端の切れ方は実機と差が出ることがあります。必ず最後に実機で確認します。
  • 2本目の学習効果： 1本目の経験で2本目の修正が減ることがあります。減った分は「慣れ」として別に注記します。
  • 縦持ちだけで終える： 横持ちで崩れる場合があります。終了条件に両方を入れるかどうかは、題材ごとに事前に決めておきます。

次の行動

まず、いま手元にある小さな試作を1本選び、スマホ対応を始める前に3つの予想を書き留めてください。そのうえでPC専用の状態を保存し、実機で開いて記録表に1行目を書きます。

投稿を考えている作品なら、実機で開く作業は公開前の確認にもなります。HTMLの入口は直下の index.html、素材は相対パスで指定します。記録が2本分揃ったら、予想との差がもっとも大きかった種類を選び、次の試作の最初に作る部品として決めておくと、この実験の結果が次の制作に使えます。

マガジン一覧に戻る