駆け出しマークアップエンジニアのためのWebサイト制作フロー

Contents

1 はじめに
2 STEP0：制作環境について
3 STEP1：デザインデータの受け取り
4 STEP2：デザインデータの確認
5 STEP3：コーディング
6 STEP4：テスト
- 6.1 ターゲットブラウザ
- 6.2 テスト項目
7 STEP5：納品、修正
8 STEP6：本番公開

はじめに

この記事を書いた背景

TwitterなどのSNSを眺めていると、副業もしくは転職のために、プログラミングを勉強されている方が増えている印象を受けます。
（自身がエンジニアの方を多くフォローしているからかもしれませんが）

そのような方向けに、プログラミングスクールやオンラインスクール、オンラインサロンも充実しており、独学で技術を身に着けるハードルは年々下がってきています。

ただ、もちろんそれらのサイトは技術の習得にフォーカスされているため、実際の案件のイメージがつきにくいのではないかと感じています。

この記事は、

技術は一通り身に着けたけれど、次に何をやればよいのか分からない
フリーランスとして案件を受けたけれど、どのように進めたらいいか分からない

・・・といった方向けに、いちフリーランスが案件を受けた後に、納品・サイト公開までにどのような事をやっており、どのような技術・ツールを使っているかを書いたものです。

なおここでは、案件として「静的なWebサイト作成」を想定しており、動的なWebサイト・Webアプリは除外しています。

そのためマークアップエンジニア向けの記事となっていますが、WEBエンジニアであってもマークアップを同時に担当する事が多いので、将来的にWEBエンジニアになりたい！という方にとっても役立つ記事ではないかなと思います。

今回の記事は、私自身がフリーランスとしてマークアップ案件を100件以上担当し、様々なクライアント様と取引させていただいた中で、最もポピュラーだと思われる制作フローとしてまとめました。

記事内には、いわゆる「モダン」な技術の話はほとんど出てこず、具体的なコードも無く、各技術・ツールについても詳しく解説はしていません。

拍子抜けするかもしれませんが、特に駆け出しエンジニアの方が実際の現場のおおまかなイメージを掴むための、一つの例として参考にしていただければ幸いです。

もちろん、このやり方が正解というわけではありませんので、「今時そんなやり方しないでしょ！」「ウチはこんなフローでやってるよ」と思う方がいましたら、どんどんコメント下さい。

お前は誰だ

青森在住のWEBエンジニア。フリーランスとして活動して5年目。
主に、コーディング・WordPress構築・Webシステム構築等をフルリモートで請け負っています。

ちなみに、30歳過ぎまでプログラミング経験は全くなく、SIerに入社してから初めてプログラミングに触れ、一年後に退職＆フリーランスとして活動開始しました。
今考えれば無謀にもほどがありますが、プログラミングを学び始めるのに年齢は関係無く、誰でも活動していけるチャンスがあると思っています。

今回想定するシチュエーション

具体的な制作フローを書いていく前に、今回想定する案件の概要を記載します。

前に書いた通り、私自身がこれまで受けた案件の中で、最も多かったシチュエーションを想定します。

登場人物	立場
クライアント	個人・法人問わず、WEBサイトを作りたい or リニューアルしたいと思っている。コンテンツは揃っているが、それをWEBサイトに仕上げる技術・知見がないので、どこかの会社に制作を依頼したい。
WEB制作会社・デザイン会社	クライアントからWEBサイト制作の依頼を受ける立場。自社内にデザイナーがいるためデザインは出来るが、コーディング出来る人がいないため、外注に依頼したい。もしくは、デザイン・コーディング両方を内政化しているが、リソースが足りないためさばき切れない案件を外注に依頼したい。
外注（自分）	WEB制作会社・デザイン会社からWEBサイト制作を依頼され、コーディングを担当する立場。

以上のように、クライアント直請けではなく制作会社を挟んだ二次受けになる事が多いです。

デザインスキルもあり、WEBサイト制作を一気通貫で行える人であれば、クライアントさんから直請けしやすいでしょうし、仕事の幅も一気に増えると思います。

自分の場合は、凝ったデザインで無かったり既存サイトの改修であれば、クライアントさんから直請けする事もありますが、デザインセンスが壊滅的にないので、基本デザインは行っていません。。

STEP0：制作環境について

制作フローの話の前に、マークアップエンジニアとして案件をこなすために準備しておきたい環境について触れます。

極端に言えば、パソコン一台とインターネット環境さえあれば何とかなりますが、快適に作業するための環境は以下の通り。

パソコンのスペック、OS

コーディング中は、ブラウザ・ターミナル・Photoshop・エディタ等、多数のソフトを立ち上げるため、意外とパソコンのスペックは重要です。
それほど高スペックのパソコンは必要ありませんが、最低でもPhotoshopが快適に動作するスペックは必要です。

Photoshop の必要システム構成

また、OSはWIndows / Macどちらでも構いませんが、クロスブラウザチェックのために、余裕があれば両方用意しておくと便利です。

ちなみに、自分はMacを持っていませんが、「MacのSafariでのみ表示が崩れる・スクリプトが動かない」といったケースが稀にあるため、「ちょっと直してみたので、もう一回確認して下さい」と制作会社に毎回伝えるのは申し訳なく感じています。。

ディスプレイの解像度

フルHD（1920x1080px）のディスプレイがお勧めです。

理由は、デザインデータの多くはコンテンツ幅が1000px前後、アートボードが幅1600pxほどで制作されている事が多いからです。

例えば、ノートパソコンの解像度として一般的な幅1366pxのディスプレイであった場合、アートボードの幅に足りないため、デザインデータと見比べての調整がやりづらくなってしまいます。

さらに、ブラウザの開発者ツールを右端に出してCSS等を確認する事になるため、より表示領域が狭くなり、コンテンツ幅の1000px前後にも満たない事になってしまいます。

ブラウザに常時開発者ツールを表示させつつ、デザインと見比べて快適に作業出来る表示領域を確保するために、フルHDのディスプレイをお勧めします。
（開発者ツールでフルHDをエミュレートしたり、開発者ツールをブラウザ下部に固定する方法もありますが）

フルHDに満たない解像度のノートパソコンを使っている方は、外付けディスプレイの導入をお勧めします。

メインのノートパソコンの画面でコーディングし、外付けディスプレイでブラウザ表示といった事が出来るので、作業効率が格段に上がります。
（最近のノートパソコンであれば問題無いと思いますが、フルHDで外部出力可能かは念のため確認下さい。）

エディタ

各自お気に入りのもので良いですが、マークアップだけであれば仰々しいIDEは不要です。

個人的には、起動が爆速で拡張性も高いSublime Textをお勧めします。

Sublime Text VS Atom VS Brackets VS Visual Studio Code スピード対決 | ちんぷいどっとねっと

Adobe Creative Cloud

Sketch、Figmaなど、新しいUIデザインツールが続々と登場していますが、現場レベルでは一度も出くわしたことがなく、Adobe製品がまだまだ標準となっています。

これまで見てきたデザインデータの中で、使用されているAdobe製品の割合は体感で以下の通り。
メジャーなのはいまだPhotoshopですが、XDの利用率も徐々に増えてきているように感じます。

ソフト名	割合
Photoshop	80%
Illustrator	15%
XD	5%

もちろん、データの受け渡し時にはそれらのソフトを持っている事が前提でやりとりが進みます。

また、「ウチのIllustratorはCS6でCCのデータ開けませんから、変換してくれませんか。。」と制作会社に手間をかけないように、古いバージョンの製品を使い続ける事は出来ません。

そうすると、サブスクリプションであるAdobe Creative Cloud一択となり、コンプリートプランだと税別5,680 円/月（2020/1/29時点）と結構なお値段となりますが、必要経費だと思って割り切りましょう。
（IllustratorとPhotoshopの単体プランもありますが、それぞれ税別2,480 円/月となり、個別に買ったとしても劇的に安くなるわけではありません）

レンタルサーバーとドメイン

コーディングに限らず、WordPress開発・WEBアプリ開発をローカルで行える環境は充実しています。
また、静的なサイトであればローカルに作ったhtmlファイルをブラウザで開くだけで表示を確認する事も出来ます。

ですがここでは、あえてレンタルサーバーを借り、一つドメインを取っておく事をお勧めします。

実際の案件では、ローカルで作ったソース一式を納品するだけで終わる事は少なく、クライアントの本番サーバーや制作会社のテストサーバーにアップする所まで求められる事が多いです。

また、今後WordPressやWEBシステム開発案件を受けた場合、レンタルサーバーのコントロールパネル上でWordPressをクイックインストールしたり、データベースを作成したりする事もあります。

そういったケースに備え、自分で自由にいじり倒せる環境を一つ持っておくと良いでしょう。

具体的には、データベース・WordPressが扱え、実案件でも触る事の多い「さくらのレンタルサーバースタンダード」がお勧めです。（月額524円、2020/1/29時点）

将来的にWEBシステム開発を見据えている場合は、仮想専用サーバーである「さくらVPS」が良いと思います。（月額585円～、2020/1/29時点）

マークアップエンジニアの最低限のスキルとして、以下のような事が出来ているようになると頼もしいです。
いずれの項目も、レンタルサーバーのコントロールパネルもしくはFTPで行える作業なので、ハードルは全く高くないはずです。

ドメインを契約してサーバーに割り当てる
WordPressのクイックインストール、およびFTPでの手動インストール
FTPユーザーの追加、編集
メールアドレスの作成
PHPバージョンの変更、php.iniに各種設定追加
データベースの作成
.htaccessを使用したBASIC認証
無料SSLの割り当て

STEP1：デザインデータの受け取り

ここからが本題です。

「はじめに – 今回想定するシチュエーション」で触れた通り、制作会社を挟んだ二次受け案件を想定します。

見積りや契約についての話は、今回の趣旨から外れるため詳しくは書きませんが、以下のような状態だとします。

制作会社はクライアントから受注済で、デザインデータは全て完成している。
制作会社から、自身に見積り依頼が来た。
デザインデータをざっと確認して、見積り提出、納期のすり合わせを行った。
制作会社から正式に受注を受けた。

案件受注後は、まずは制作会社からデザインデータ一式を受け取ります。
（納期が短い場合、またクライアント・制作会社間で全てのデザインがFIXしていない場合は、五月雨式にデザインが送られてくる場合もあります。）

前述の通り、デザインデータはPhotoshopあるいはIllustratorで作成されている事が多く、容量も数百MB以上になるため、オンラインのファイル転送サービス（gigafile等）を使ってデータを受け取ります。

安定したインターネット環境であれば問題ありませんが、wimaxを使っている方は注意。直近3日間で10GB以上の通信を利用した場合、翌日18時～翌2時頃に通信制限がかかります。

3日間で10GB以上ご利用の場合の速度制限について | UQコミュニケーションズ

そうそう制限に引っかからないように思いますが、複数案件を抱えていたり、大量のデザインデータを何度も受け取ったりしていると、平気で通信制限に引っかかってしまいます。

そうなると、夕方以降の作業が辛くなるので、固定回線か通信制限のないポケットwifiを使う事をお勧めします。

また、デザインデータ以外に以下のようなものが同梱されている場合があります。

コーディング規約
各ページの注意点（リンクURL、アニメーションの指示）
meta情報（title,description等）
サイトマップ

ただし、こういったドキュメントが用意されている事は少なく、次のSTEPで説明する「用意されたデザインデータから各種情報・意図を読み取る」ことが基本的には求められます。

STEP2：デザインデータの確認

フォルダ構造について

具体的なファイル名としては、例えば以下のような命名規則で、ファイル名だけでどのページ・パーツの事か分かるようになっています。

top_pc_yyyymmdd.psd
top_sp.psd
about.ai
menu.ai
company_ol.ai

Illustratorの場合、「XXX_ol.ai」というように、フォントをアウトライン化したファイルを別途用意してくれている場合もあります。

スマホのデザインについては、全ページ分用意されている事は少なく、「トップページのデザインだけ用意しやので、他のページはお任せします」というケースが多いです。

ファイルに関するトラブルシューティング

Photoshopファイルでよく遭遇するのが、ファイルを開いた時に「コンピュータに無いフォントが使用されています」と警告が出るケースです。
Adobe Creative Cloudであれば、Adobe Fontが付属しているので、Adobe Fontに存在するフォントであれば自動でインストールしてくれるので便利です。
最終的にフォントが見つからなかった場合でも、デザインが崩れる事はなく以降の作業に大きな支障が出るわけではないので、そのまま進めてOKです。
デスクトップアプリケーションで環境にないフォントを解決する
Illustratorで、自身のコンピュータにフォントが存在しない場合は、代替フォントで表示されたり文字化けが発生し、正確なデザインを確認出来ないため注意が必要です。
自身のコンピュータに存在しないフォントが使われているデザインであった場合、かつフォントをアウトライン化したファイルが用意されていない場合は、「アウトライン化されたファイルも送って下さい」と伝えましょう。
フォントのアウトライン化の方法 | WAVE
Photoshop / Illustrator共通で発生するのが、「オブジェクト（レイヤー）が埋め込み配置ではなくリンクで配置されており、リンクファイルが見つからないため正しくファイルを開けない」というケースです。
ファイル一式がきちんと同梱されていれば、手動で紐づけする事で解決出来ますが、そうでない場合は「埋め込み配置にしたファイルを送ってくれませんか」と伝えましょう。

デザインデータを画像に変換

パソコンのスペックやデザインファイルの作りによっては、一つのファイルを開くだけでも重い時があります。

最初にデザインの全体図を確認するため、また最終的にブラウザとデザインを見比べて確認するために、一旦全てのデザインデータを画像に変換しておく事をお勧めします。

Photoshopの場合、アイコンへのドラッグ&ドロップでJPEG保存してくれるドロップレットを作っておくと良いでしょう。

たったワンアクション！　大量のPSDファイルを一気にJPEG保存する方法！ | 株式会社エムハンド

コーディング方針の決定

各種デザインの受領・下処理が終わったら、いよいよコーディング行うための準備に入ります。

制作フローの中で、このフェーズがもっとも重要であると思います。

間違っても、トップページのデザインだけをみてトップページからコーディングを始める、という事はやめて下さい。

前述の通り、デザインデータに関する補足（ドキュメント）が用意されている事は少なく、デザインデータからありとあらゆる情報を読み取り、想像する事が求められます。

まずは、前節で作成した各デザインのJPEGファイルをじっくり確認しましょう。

デザインデータを見てどんな情報を得て、どんな事が想像出来て、どのように方針を決定すべきか。
全ては書き切れませんが、具体的な例をいくつか挙げておきます。

会社概要のページだから、ファイル名は company.html で良いかな。
スライスする画像の数が多くなりそうだから、共通の画像は common フォルダに、ページ個別の画像はページ名のフォルダ（ about 等）にまとめよう。
明朝フォントが使われているが、font-family で明朝を指定するか、それともWebフォントの Noto Serif Japanese を使うべきか。
トップページだけヘッダー部のデザインが若干違うから、下層ページのヘッダーをベースにコーディングしよう。
ハンバーガーメニューの部分は三本線で出来ているから、メニューを開いた時には二本になって×マークに変形させよう。
右下にTOPへ戻るボタンがあるけど、画面をスクロールするまでは非表示にしておいた方がよさそうだ。
指定はされていないけど、画像リンクはマウスオーバーでふわっとさせた方が親切かな。
この英語の部分には有償フォントが使われていて、商用利用不可だから、別のフォントで代替してもよいか相談しよう。
サムネイル付きのスライダーがあるけど、どんなjQueryライブラリが最適だろう。
アートボード上にガイド線が何本か入っているが、コンテンツ幅は1000pxと1200pxの二種類があるようだ。
ページ数が少ないから、用意するCSSファイルは common.css とlayout.css の2つだけで良いかな。
ベースとなるフォントファミリー、フォントカラー、フォントサイズ、行の高さは何だろう。
このスマホのデザインだと、実機では本文の文字が小さくて見えづらいだろうから、少し大きく調整しよう。
この横並びのパーツは、display: flex; 、display: table;、display: inline-block;のどれを使って並べようか。
この矢印の部分は、SVG画像にするか、それともCSSで生成するか。
この画像だけ画質が粗いみたいだけど、元の高解像度の画像を持っていないか先方に確認してみよう。
ボタン類のデザインは同じだから、.btn クラスで共通化しよう。幅は200pxと400pxの2パターンがあるみたいだから、幅広のボタンの方には .btn-wide クラスを付与しよう。
このリンクテキストには下線がついているけど、PCの場合はマウスオーバーで下線を消せばよいのかな？
グローバルメニューに「お問い合わせ」というリンクがあるけど、デザインファイルには見当たらないから確認しよう。
画像がコンテナ幅からはみ出しているけど、ブラウザ幅を狭めた時にどのように表示させようか。

以上の例はごくごく一部であり、実際の案件では何倍もの情報を読み取り、想像する事が求められます。

これは、いわゆるセンスによるものが大きいのかもしれませんが、自身のスキルや経験で十分にカバー出来ますし、確認すべき点は案件・制作会社によっても変わってきます。

制作会社によっては、細かい動きは全部お任せの場合もありますし、デザインデータ上で細かく指示してくれている場合もあります。

また、ある程度経験を積んだり、同じ制作会社から継続して案件を受けるようになると、細かい事を全て丸投げされたとしても、ある程度想像が付けやすくなり、独断で行った作業であったとしても認識のズレによる戻しが発生する事が少なくなります。

制作会社と信頼関係がまだ築けていない場合、判断に自信が持てない場合、認識のズレがあった時の修正が大きくなりそうな場合、こういった時には事前に質問して、自信を持って次のコーディングに入れるようにしておきましょう。

一方、「このデザインをどうやってコーディングに落とし込んでよいか分からない」というケースがあります。

具体的な例を一つ挙げれば、横並びレイアウトを実現する方法を知らなかったり、知っていたとしても display: inine-block; しか使った事がないといったケースです。

これは、単純にスキル不足もしくは経験不足による所が大きいです。

理想は、「このデザインをコーディングに落とし込む方法を複数知っていて、その時その時に適切な方法を選択出来る」事です。

STEP3：コーディング

コーディングにおいて重要な点

いよいよ実作業に入ります。

コーディングで行う作業内容や必要なスキルは、多くのサイトで勉強する事が出来るので、ここでは具体的な内容については触れません。

ここで大事な事は、いかに爆速で正確にコーディングするかです。

前節で書いた通り、制作フローの中で最も重要なフェーズは「デザインデータを基にしたコーディング方針の決定」です。

コーディングの明確な方針・イメージが出来上がっていれば、あとは技術・ツールを駆使して手を動かしていくだけであり、爆速で正確にコーディングするための環境を準備しておく事が重要です。

逆に、コーディング時に大きく詰まったり再コーディングが発生したりする場合は、この方針・イメージが出来上がっていない事が一つの原因です。

今一度前節に立ち戻り、デザインデータをじっくりと確認する事をお勧めします。

コーディング環境について

「STEP：0」でエディタについては触れましたが、爆速コーディングにかかせないツール・手法が多くあります。

キーワードだけ挙げておくと、

Emmet
Pug(Jade)
SASS / SCSS
CSSフレームワーク
Gulp.js

などなど。

個人的に欠かせないのが、Emmet（HTML/CSSを省略して書ける）とGulp.js（タスクランナー）です。

記事冒頭で「具体的なコードは出てこない」と書きましたが、ここではGulp.jsの設定ファイルである gulpfile.js を載せます。

実際の案件で使い回しているものですが、今後変わっていくかもしれません。

var gulp = require('gulp');
//Sassコンパイル
var sass = require('gulp-sass');
//エラー時の強制終了を防止
var plumber = require('gulp-plumber');
//エラー発生時にデスクトップ通知
var notify = require('gulp-notify');
//保存時のブラウザ自動リロード
var browserSync = require('browser-sync');
// ローカルサーバのIPアドレス
var host = 'XXX.XXX.XXX.XXX';
//ベンダープレフィックス付与
var postcss = require('gulp-postcss');
var autoprefixer = require('autoprefixer');
//文字列の挿入
var header = require('gulp-header');
//置換
var replace = require('gulp-replace');
//ソースマップ生成
var sourcemaps = require('gulp-sourcemaps');
//CSS整形
var csscomb = require('gulp-csscomb');
//開発・本番環境切り替え
var mode = require('gulp-mode')({
  modes: ['prd', 'dev'],
  default: 'dev',
  verbose: false
});
//画像圧縮
var tinyping = require('gulp-tinypng-compress');

// scssのコンパイル
gulp.task('sass', done => {
  gulp.src('./common/sass/**/*.scss')
  //エラー発生時にデスクトップ通知
  .pipe(plumber({
    errorHandler: notify.onError('Error: <%= error.message %>')
  }))
  //（開発時のみ）ソースマップ生成
  .pipe(mode.dev(sourcemaps.init()))
  //Sassコンパイル
  .pipe(sass({
    outputStyle: 'expanded',
    indentType: 'tab',
    indentWidth: 1,
    errLogToConsole: false
  }))
  //ベンダープレフィックス付与
  .pipe(postcss([autoprefixer({grid: true})]))
  //CSS整形
  .pipe(mode.prd(replace('\n\n', '\n')))
  .pipe(mode.prd(replace('@media screen and', '\n@media screen and')))
  .pipe(mode.prd(replace('/* -', '\n/* -')))
  //（開発時のみ）ソースマップ生成
  .pipe(mode.dev(sourcemaps.write()))
  //（本番のみ）CSS整形
  .pipe(mode.prd(csscomb()))
  //CSS整形
  .pipe(replace(/@charset "UTF-8";/g, ''))
  .pipe(header('@charset "UTF-8";\n'))
  .pipe(gulp.dest('./common/css/'))
  //ブラウザにCSS反映
  .pipe(browserSync.stream());
  done();
});

//ブラウザ起動
gulp.task('browser-sync', done => {
  browserSync.init({
    server: {
      baseDir: './'
    },
    notify: false,
    open: 'external',
    host: host
  });
  done();
});

gulp.task('bs-reload', done => {
  browserSync.reload();
  done();
});

// 監視
gulp.task('watch', () => {
  gulp.watch('./common/sass/**/*.scss', gulp.task('sass'));
  gulp.watch('./**/*.html', gulp.task('bs-reload'));
  gulp.watch('./**/*.js', gulp.task('bs-reload'));
})

//画像圧縮
gulp.task('tinypng', function () {
  return gulp.src('./**/*.{png,jpg,jpeg}')
  .pipe(tinyping({key: 'XXXXXXXXXXXXXXXXXXXXXXXX'}))
  .pipe(gulp.dest('./img_compressed/'));
});

//デフォルトタスク
gulp.task('default', gulp.series(gulp.parallel('browser-sync', 'watch')));

何をやっているのかを箇条書きにすると、

Sassコンパイルエラー発生時にデスクトップ通知
ベンダープレフィックス付与
CSS整形
開発時のみソースマップ生成
ファイル保存時にブラウザにCSS反映or自動リロード
スマホからでも確認出来るようにIPアドレス付与
tinypng apiで画像圧縮（納品前に一度だけ実行）

などなど。

知らないと損な、爆速でWebコーディングしたい時に使えそうなヤツラ(ツールとか) | Qiita
爆速でHTMLコーディングするためのtips | Qiita
CSScomb: Build config（←gulp-csscombの設定ファイルを生成出来るサイト）

デザインデータからの画像スライス

例えばPhotoshopであれば、ガシガシとデザインを制作したり、色んな機能を使いこなせたりする必要はありません。
自分自身も、Photoshopでは簡単なバナーぐらいしか作れませんし、Illustratorであれば、基本であるベジェ曲線すらまともに描けません。

デザインデータを扱う上で、マークアップエンジニアに求められる重要な事は、「適切な形式で、正確なサイズで、綺麗な画像を書き出せる事」です。

そのためのTipsを、Photoshopを例としていくつか挙げます。

背景を透過させる必要のあるロゴ、アイコン、矢印等は、PNGもしくはSVGで書き出します。それ以外は、基本的にはJPGでOKです。
スライスツールを使って領域を描画して、不要な後ろのレイヤーを非表示にする・・といったやり方は、今ではほとんど使いません。
基本的には、画像として切り出したいレイヤーを右クリック→「書き出し形式」を選択肢て書き出します。
複数のレイヤーを一つの画像として書き出したい場合は、右クリック→「レイヤーを結合」を行います。
Photoshop CCの基本第4回：Web用画像を書き出す4つの方法をマスター！
デザイナーさんによっては、画像のサイズが論理的でない場合があります。
例えば、画像のリストがあった場合、一つの画像だけ横幅が数px程度ズレていたり、縦横比がズレていたりする場合があります。
意図的なものであればそのままで良いですが、そうでない場合はサイズを揃えて書き出しておくと親切です。
バナー等で、境界線やドロップシャドウのレイヤー効果が入っている場合、レイヤー効果を外した上で書き出し、代わりにCSSで再現した方が良い場合が多いです。
例えば境界線をborderで再現すれば、画像のサイズが変わっても境界線幅が変わる事がなくなります。
ちょっと難しいレイアウトだからといって、安易に画像として書き出す事は避けましょう。
画像として書き出すべき事が明らかでない限り、HTML / CSSを駆使して再現出来ないか考えてみて下さい。

デザインデータからプロパティを読み解く

マークアップエンジニアに求められるもう一つの重要な事は、「HTML / CSSで再現すべきパーツについて、プロパティを正しく読み解き、HTML / CSSに落とし込める事」です。

今の時代、ピクセルパーフェクトなコーディングを求められる事はほとんどありませんが、目分量でざっくりとコーディングしていく事は厳禁です。

テキストであれば、「フォントの種類」「フォントサイズ」「行の高さ」「フォントカラー」あたりは正確にCSSに反映させておきたい所です。
デザインによっては、トラッキング（letter-spacing）も細かく調整されている場合もあります。
いずれの情報も、「文字」パネルで確認する事が出来ます。

プロなら知っておきたい！Photoshop文字設定とCSSプロパティの相互関係 | それからデザインスタッフブログ

テキストと画像スライスとして書き出すもの以外のパーツとしては、背景色やテキスト周りのborder、ボタン類に使われている長方形レイヤーがほぼ該当するのではないかと思います。
このレイヤーについても、「属性」パネルで細かい情報を確認する事が出来ます。
確認すべき情報は、幅、高さ、背景色、境界線の色と太さ、角丸の半径値です。

Photoshopのデザインカンプからコーディングに必要な画像や値を取得する方法 | HPcode

画像スライスとコーディングはどちらから行うべき？

画像スライスは、コーディング前に行う、コーディングと同時に行う、コーディング後に行うという風にいくつかやり方がありますが、自分の場合は以下のような流れで作業しています。

共通パーツであるヘッダー・フッター部で使われている画像（サイトロゴ等）や、ページ共通で使われる画像（アイコンや矢印等）については、コーディング前に一通り書き出しておく。
下層ページについては、各ページのコーディングを行う前にページ単位で都度画像を書き出す。

STEP4：テスト

コーディング規約がキッチリと決まっているような制作会社であれば、ターゲットブラウザやテスト項目も提示される事が多いため、それに沿ってテストを行います。

ですが、ほとんどの場合は明示的に指示される事は無いため、自身でターゲットブラウザやテスト項目を判断し、クライアント・制作会社と取り決める必要があります。

ターゲットブラウザ

自身の経験ですが、以下の環境全てで確認しておけばまず問題になる事はありません。

Windows：Chrome、Firefox、Edge、IE11
Mac：Safari、Chrome
iOS端末（iPhone）：Safari、Chrome
Android端末：Chrome

数が多く大変に思えるかもしれませんが、各ブラウザの仕様を念頭においた上でコーディングを行い、CSSにもきっちりベンダープレフィックスを入れておけば、それほどブラウザ独自の解釈に苦しむ事はないはずです。

キモはIE対応ですが、さすがにIE10以下は切り捨ててもよいでしょう。
IE11については、2019年12月時点で約12％のシェアがあるようなので、自分の場合は標準でターゲットブラウザとしています。

WebブラウザシェアランキングTOP10(日本国内・世界) | ウェブレッジ

テスト項目

「STEP3：コーディング – デザインデータからプロパティを読み解く」で記載した通り、デザインデータから読み解いたプロパティを正確にコーディングに落とし込めているのであれば、目に見える細かい部分（フォントカラー、フォントサイズ、パディング、マージン等）で修正が起きる事は多くないはずです。

その上で、チェックすべき項目をいくつか記載します。

見出し階層が正しいか：
文書の構造としてhタグが正しい箇所に使われており、階層に沿っているかを確認します。
といっても、開発者ツールでタグを一つ一つ確認する必要はなく、hタグをハイライトもしくは抽出してくれるサービスを使うと便利です。
ソース開く必要ナシ。Hタグをハイライトするブックマークレット「html-highlighter」を公開しました | 株式会社ZINE
TDKが正しく設定されているか：
meta情報であるタイトル、ディスクリプション、キーワードの事です。キーワードについては、Googleが公式に、「meta keywordsを検索順位を決める要因として利用していない」と明言しているようなので、現時点では不要でしょう。
タイトル、ディスクリプションについては必須ですが、クライアント・制作会社から指定される事は稀です。
自分の場合は、デザインデータ上のテキストをいくつかピックアップし、タイトル・ディスクリプションそれぞれちょうどよい文字数に収めた上で設定してしまいます。
クライアント・制作会社にお願いする場合は、「こんな感じで書いて下さいね」と例文を添えた上で、入力欄と文字数カウント欄を設けたExcelシートを送って書いてもらっています。
画像のalt属性が正しく設定されているか：
基本中の基本ですが、これも指定される事はまずないので、文脈に従って正しい文字を設定するようにしましょう。
ブラウザのコンソールにエラーを吐いていないか：
例えばWEBサイトリニューアル案件で、リニューアル前のサイトを確認した時に、jQueryのエラーや画像リソースが見つからないといったエラーが、ブラウザコンソールに大量に吐かれている場合があります。
こういったエラーは、サイトでレイアウト崩れが発生している事も無く、ただ閲覧する分には問題にならない事も多いです。
ですが、「動いてれば良い」の考えではなく、技術者として自分が書いたコードには責任を持ち、エラーを発生させないようにする事は最低限のマナーだと思います。
ブレークポイントの前後で表示が崩れていないか：
ターゲット端末・ブラウザで確認する事はもちろんですが、ブレークポイントが切り替わる前後での確認も重要です。パーツが左右どちらかに寄っている、意図しないカラム落ちが発生している等を発見出来る場合があります。
画像を圧縮する：
これも最低限の対策だと思います。
自分の場合は、「TinyPNG API」を使って、納品前に一括で圧縮しています。
無料で圧縮できるのは月間500枚までなので、複数案件をかかえていて制限を超えてしまった場合は、ブラウザ版でチマチマと圧縮しています。
W3Cに準拠しているか：
「HTMLやCSSの文法が正しいか」をチェックします。
HTML5 / CSS3に沿ったコーディングが出来ない初心者の頃は、大量のエラーに辟易してしまうかもしれませんが、必ず一つ一つチェックしていくようにしましょう。
ある程度経験を積めば、エラーの出ないコードを一発で書けるようになります。
The W3C Markup Validation Service
W3C CSS 検証サービス

STEP5：納品、修正

コーディングとテストが終わったら、いよいよ納品となります。

実案件の場合は、「これで納品しても問題ないですか？修正点はないですか」という意味合いで、納品前に一度確認してもらう作業が発生します。

確認してもらう方法は様々ですが、一般的にはいずれかの公開サーバーにFTPでアップロードし、クライアント・制作会社双方に確認してもらう事になります。

どのサーバーへアップするかについては、経験上多かった順で以下のようなものがあります。

制作会社のテストサーバーへアップする：
制作会社がテストサーバーを用意してくれているパターンです。
「FTP接続情報はこれこれだから、出来上がったらこのディレクトリにアップロードしておいてね」という流れになります。
自身の開発サーバーへアップする：
クライアント・制作会社がテストサーバーを用意していない、というパターンです。
特にクライアント直請けの場合は、テストサーバーが用意されている事はまずありません。
そういった時のために、「STEP0：制作環境について」で記載した通り、レンタルサーバーを1つ持っていると便利です。
BASIC認証をかけておく事も忘れずに！
クライアントの本番サーバーへアップする：
新規構築案件で、「ドメインを取得してレンタルサーバーも契約したので、あとの作業はお願いします」といったパターンです。
この場合は本番サーバーに何かデータがあるわけではないので、そのまま本番サーバーにアップします。
公開前は、BASIC認証をかける事を忘れずに。
また、サーバーに関する詳しい情報を把握されているクライアントは少なく、コントロールパネル情報しか分からないといった時があり、ドメインとサーバーの紐づけやメールアドレスの発行、FTP接続情報の確認等、コーディング外の作業も発生するかもしれません。
そのようなサーバー側の作業について、誰がどこまで担当するかを、あらかじめ取り決めておいた方が良いでしょう。
また、今後改修案件等で取引が続きそうな場合は、前項同様に自身のレンタルサーバーにテスト環境を用意しておくと対応しやすいです。

サーバーへアップした後は、クライアント・制作会社から修正指示があれば、それに従って対応します。

デザインデータから読み取れる情報を忠実に再現しており、デザインにはない追加要求でなければ、ここで大きな修正が発生する事はありません。

逆に大きな修正が発生するという事は、「認識のズレがあったまま独断でコーディングを進めてしまった」とう事が考えられます。

事前に質問する事はもちろん、例えば下層ページ1ページが完成した時点でサーバーにアップして、作業方針に問題が無いかを確認してもらう事も一つの方法です。

STEP6：本番公開

本番公開（クライアントの本番サーバーへのアップ）については、「STEP5：納品、修正」での各パターンに従うと、次のようになります。

制作会社のテストサーバーへアップしていた場合：
制作会社のテストサーバーのデータを基に、制作会社側が対応する事が多いため、ここで自身としての対応は完了です。
自身の開発サーバーへアップしていた場合：
制作会社側が対応する場合は、自身の開発サーバーのソース一式をzipファイルとして納品して終了、となります。一方、本番サーバーへのアップを依頼されるケースもあります。
クライアントの本番サーバーへアップしていた場合：
この場合は、基本的に前もってかけておいたBASIC認証を外すだけで作業完了です。

以上で、一案件の中でのマークアップエンジニアとしての仕事は終了です。お疲れ様でした！

引き続き案件をこなしてマークアップを極めるもよし、WordPressサイト構築にステップアップするもよし、フロントエンド周りを勉強してWEBエンジニアに挑戦するもよし。

マークアップエンジニアというと、「ただのコーダーでしょ」とdisられてしまう事もあるかもしれませんが、いずれの方向に進むにしろ、WEBに関わるのであれば基本中の基本となる技術だと思っています。

それでは、良きマークアップライフを！