スマホで自分の会社のサイトを開いてみて、「あれ、なんかおかしい」と思ったことがある人は多いと思う。でも、何がおかしいのかうまく言葉にできない。デザイナーに伝えようにも「なんか詰まってる感じがする」とか「画像の位置がしっくりこない」としか言えない。
今日の作業は、まさにそういう「なんか違う」を一つずつ言語化して直していく一日だった。
スマホとPC、同じページなのに「読む順番」が違う
あるクライアントの指名検索用LP（ランディングページ＝検索して最初にたどり着くページ）は、PCで見ると左側にキャッチコピー、右側にサービス風景の写真という2カラム構成になっている。横に並んでいるから、文字と画像が同時に目に入る。これはこれで悪くない。
問題はスマホだった。
スマホは画面が縦長だから、当然1カラム（縦並び）になる。そのとき、キャッチコピー→本文→CTAボタン→画像、という順番で表示されていた。つまり一番伝えたいメッセージのあとに、ずらーっと文字が続いて、ずっと下までスクロールしてようやく画像が出てくる。
これだと、せっかくの写真が埋もれてしまう。
やりたかったのは、メインのキャッチコピーのすぐ下にサービス風景の写真を持ってくること。キャッチコピーで興味を引いて、すぐに画像で「あ、こういうところなんだ」とイメージさせる。そのあとに詳しい説明やボタンが来る、という流れ。
雑誌で考えるとわかりやすい。見開きのレイアウトと、文庫本の縦書きでは、同じ内容でも読者の目線の動きがまったく違う。だからプロの編集者は媒体ごとにレイアウトを変える。ウェブも同じで、PCとスマホで要素の「並び順」を変えるCSSの機能がある。今回はそれを使って、スマホだけ画像の位置を繰り上げた。
たった数行の変更。でも第一印象への影響は大きい。
「詰まってる感じ」をどう直すか
もう一つ気になっていたのが、キービジュアルのセクション（ページ上部の大きな画像とキャッチコピーのエリア）と、その下のサービス紹介セクションの間が窮屈だったこと。
「なんか詰まってる」——これを技術的に言い換えると「セクション間の余白（マージン）が足りない」になる。
で、余白を足すにも2つのやり方がある。上のセクションの下側に余白をつけるか、下のセクションの上側に余白をつけるか。結果は同じに見えるけれど、他のレイアウトへの影響が違う。
スーパーの棚に例えるなら、下の棚を少し下げたいとき、上の棚の底板をいじるか、下の棚の天板をいじるか。どっちでもいけそうだけど、他の商品のレイアウトに響きにくいのはどちらか、という判断になる。
最初はヒーローエリア側のパディング（内側の余白）を広げてみた。でも「それだとヒーロー側のバランスが崩れるから、サービス紹介セクション側の上マージン（外側の余白）で調整してほしい」という指摘をもらって修正した。
こういう試行錯誤の過程は、完成品だけ見ると伝わらない。でも「どこをいじるか」の判断ひとつで、あとから別の箇所がズレるリスクが変わる。必要なところだけ、ピンポイントで手を入れる。プラモデルの塗装で、マスキングテープを貼って「ここだけ」に色を乗せる感覚に近いかもしれない。
一番地味で、一番大事だった仕事
今日やった作業のうち、エンドユーザーの目に直接見えるのはスマホの画像配置と余白の調整だけだ。でも実は、今日一番時間をかけたのは別のことだった。
「ステージング環境の構築」と「バージョン管理の導入」。
これだけ聞くと何のことかわからないと思うので、順番に話す。
バージョン管理（Git）って何？
Googleドキュメントの「変更履歴」機能を使ったことがあるだろうか。誰がいつ何を書き換えたか、全部記録されていて、過去の状態にワンクリックで戻せるあの機能。
Git（ギット）は、ウェブサイトのコードに同じことをやる仕組みだ。「3日前の状態に戻したい」「この変更で何が壊れたか調べたい」ができるようになる。
で、GitHub（ギットハブ）はその変更履歴をクラウド上に保存しておく場所。Googleドキュメントの本体がGoogleドライブに入っているのと同じイメージで、コードの本体と履歴がGitHubに入る。今回はプライベートリポジトリ（非公開の保管庫）として作ったので、関係者以外には見えない。
実はこのLP、ここまでの開発でバージョン管理なしで走っていた。変更したらそのまま本番に反映。巻き戻しの手段がない状態。
「試食してから出す」仕組み
ここからが今日のメインテーマ。
飲食店には、料理をお客さんに出す前にシェフが味を確認する工程がある。当たり前の話だけど、ウェブサイトの更新ではこれをやっていないケースが意外と多い。修正したら、そのまま本番サイトに直行。お客さんの目に触れてから「あ、ここ崩れてる」と気づく。
今回導入したのは、こんな流れだ。
① staging（ステージング）ブランチで修正する
ブランチというのは、本番とは別の「作業用コピー」のようなもの。本番のサイトには一切影響しない場所で、自由にいじれる。
② 自動でプレビューURLが発行される
Vercel（バーセル）というホスティングサービスがGitHubと連携していて、stagingブランチに変更をアップロードすると、確認用のURLを自動で作ってくれる。このURLは本番とは別物なので、エンドユーザーには見えない。
③ プレビューで確認して、OKならmain（本番）に合流させる
問題なければ「マージ」という操作で本番ブランチに反映。するとVercelが検知して、数分以内に本番サイトが更新される。
これまでは修正→即・本番だったのが、修正→確認→本番になった。たったワンステップ増えただけ。でもこのワンステップが、「エンドユーザーに崩れた画面を見せてしまう」事故を防いでくれる。
仕組みは地味だけど、ずっと効く
正直に言うと、今日の作業で一番「見た目が変わった」のは、スマホでの画像の位置だと思う。余白の調整もパッと見は些細な違いだ。
でも、Git導入とステージング環境の構築は、これから先ずっと効いてくる。
担当者が変わっても、過去の変更履歴が残っている。修正ミスがあっても、前の状態に戻せる。新しい機能を試すとき、本番を壊さずにテストできる。
事業の運営と同じだ。マニュアルや仕組みが整っていれば、人が変わっても品質は落ちにくい。逆に「あの人の頭の中にだけある」状態で回していると、どこかで必ず綻びが出る。
今日は地味な一日だった。でも、これから先の改善を全部安全にやっていくための土台ができた日でもある。
今日の変更まとめ
- スマホKV配置の最適化：タグラインの直後に画像が来るように並び順を変更
- セクション間の余白調整：サービス紹介セクション上部にマージンを追加
- バージョン管理の導入：Git初期化、GitHubプライベートリポジトリ作成・push
- ステージング環境の構築：Vercel × GitHub連携、ブランチベースのデプロイフローを確立
