コーダーとマークアップエンジニアの違い|呼び方より大事なこと

※本記事にはプロモーション(広告)が含まれます。

求人を見ていると「コーダー募集」と「マークアップエンジニア募集」が並んでいることがあります。業務内容を読むとほとんど同じに見えるのに、なぜ呼び方が違うのか。

私はWeb制作に14年関わり、数十社の現場を見てきました。派遣・正社員・フリーランスのすべてを経験しています。その立場から、この2つの違いを実務目線で書きます。

目次

結論:明確な定義の違いはない。求人票の意図が違う

先に身も蓋もない結論を書きます。この2つに、業界共通の厳密な定義はありません。

ただし、求人でこの言葉が使われるとき、送り手側の意図には傾向があります。

コーダー マークアップエンジニア
言葉のニュアンス デザインを形にする人 構造を設計する人
期待される範囲 実装が中心 実装+設計の意図
よく併記される要素 HTML/CSS、jQuery アクセシビリティ、SEO、保守性
出てくる現場 制作会社・受託中心 規模の大きい開発現場・事業会社

つまり「同じ作業に対して、どこまでを期待しているか」の差が呼び方に出ている、というのが実態に近いです。

マークアップエンジニアという呼び方に込められるもの

1. 「なぜこのタグなのか」を説明できること

いちばん本質的な違いはここです。見た目が同じでも、意味に合ったタグを選んでいるかが問われます。

見出しに見えるからという理由で見出しタグを使うのではなく、文書構造として見出しだから使う。この考え方ができるかどうかです。

2. アクセシビリティへの配慮

画像の代替テキスト、フォームのラベル、キーボードだけで操作できるか。目で見て確認できない部分まで意識できるかが期待されます。

これは自動生成されたコードで最も問題が出やすい領域でもあり、直せる人の価値が上がっています。

3. 保守性

命名規則、ファイル構成、他の人が触ったときに壊れないか。作った後の運用まで見て書けるかということです。

4. SEOを意識した構造

見出しの階層、パンくず、構造化された記述。検索エンジンに正しく伝わる形を意識する場面が出てきます。

ただし現場では、呼び方はかなり適当に使われている

ここまで整理しましたが、実務での正直な感想を書きます。

同じ作業なのに、会社によって呼び方が違う

私自身、やっている作業がほとんど変わらないのに「WEBデザイナー」から「フロントエンドエンジニア」に肩書きが変わったことがあります。単価はそのとき上がりました。

職種名は、市場での見え方や社内の等級に合わせて付けられることがあります。作業内容の違いを正確に表しているとは限りません。

だから求人票は職種名で判断しない

「マークアップエンジニア募集」でもHTML/CSSの実装が中心だったり、「コーダー募集」でアクセシビリティ対応まで求められたりします。

職種名ではなく、業務内容の記述を読んでください。これが唯一の判断方法です。

他の職種との位置関係

混乱しやすいので、周辺の職種も含めて整理します。

  • Webデザイナー:何をどう見せるかを決める
  • コーダー/マークアップエンジニア:決まったものに正確に合わせる
  • フロントエンドエンジニア:JavaScriptでの機能実装や設計まで担う人
  • プログラマー:処理やロジックを組む人

それぞれの詳しい違いは、コーダーとWebデザイナーの違いコーダーとフロントエンドエンジニアの違いコーダーとプログラマーの違いにまとめました。

境界は連続していて、線を引けない

実際には、この4つは階段のように分かれているわけではありません。対応範囲が広がるにつれて、呼ばれ方が変わっていくだけです。

そもそもマークアップとは何を指すのか

「印をつける」という意味

マークアップは、文章の各部分に「これは見出し」「これは段落」「これは一覧」という印をつける作業のことです。HTMLのタグがその印にあたります。

見た目を作る作業だと思われがちですが、本来は意味を与える作業です。装飾はCSSの担当で、マークアップはその手前にあります。

印が正しいと、後の全部が楽になる

この印が正しくついていると、こういう効果が出ます。

  • 読み上げソフトが正しい順序で読める
  • 検索エンジンが内容を把握しやすい
  • CSSの指定が短くなり、崩れにくくなる
  • あとから他の人が触っても構造がわかる

逆に印が適当だと、見た目だけ合っていて中身がぐちゃぐちゃという状態になります。納品直後は誰も気づきませんが、運用が始まると効いてきます。

実務で「違い」が表面化する場面

ふだんは呼び方の差など意識しません。ただ、はっきり差が出る場面があります。

1. 既存サイトの改修を頼まれたとき

他人が書いたコードを触るとき、構造が読めるかどうかで作業時間が何倍も変わります。私は運用案件をいくつも受けてきましたが、直しづらいコードには共通点があります。

  • タグの意味が見た目に引きずられている
  • クラス名が装飾の名前になっている
  • 1か所直すと別の場所が崩れる

この3つが揃っていると、改修より作り直したほうが早い状態になります。そうならないコードを書ける人が、マークアップエンジニアと呼ばれる側です。

2. アクセシビリティ対応を求められたとき

公共性の高いサイトや大きな企業のサイトでは、対応が要件に入ることがあります。ここで後から足せる部分と、構造を直さないと足せない部分が分かれます。

代替テキストは後から入れられます。しかし見出しの階層がおかしい、リストがリストになっていないといった問題は、書き直すしかありません。最初の段階で決まってしまう部分です。

3. CMSに組み込むとき

WordPressなどに組み込む段階では、どこが可変でどこが固定かを分けて考える必要があります。1ページだけを見て作ると、記事が増えたときに破綻します。

この「増えても壊れない形にする」という発想も、構造を設計する側の仕事です。

求人票の読み方

職種名で判断しないと書きました。では何を見るか、具体的に挙げます。

チェックするのは5点

  1. デザインは誰が作るのか(支給か、自分で作るのか)
  2. JavaScriptはどこまでか(既存の組み込みか、実装か)
  3. CMSに触るのか(テーマ改修まで含むか)
  4. 公開作業は誰がやるのか(サーバー作業を含むか)
  5. 誰と会話するのか(社内だけか、クライアントと直接か)

この5つが分かれば、職種名が何であっても実際の仕事の重さが判断できます。

書いていないときは面談で聞く

求人票に書かれていない場合、面談で聞くのが最も確実です。私はエージェント経由で複数社と面談しましたが、この種の質問を嫌がられたことはありません。

むしろ範囲を確認してくる人は、入った後に揉めないと判断されて印象が良くなります。

未経験から入るならどう考えるか

最初はどちらでもいい

未経験の段階で職種名を選ぶ意味はほとんどありません。まずHTML/CSSで手を動かせる状態を作るのが先です。

案件の受け方は実績なしで案件を取る方法に、必要な学習順はコーダーになる方法にまとめました。

ただし早い段階で構造を意識しておくと得

あとから直すのは大変ですが、最初から意識しておけば追加の労力はほぼゼロです。学習中に「なぜこのタグか」を1回ずつ考えるだけで、数か月後の自分が楽になります。

模写で練習している人は、模写の題材の選び方も合わせて読んでください。

実際にあった、呼び方が問題にならなかった話

面談で職種名を聞かれたことはない

私は7社のエージェントに登録し、面談を受けました。そのなかで「あなたはコーダーですか、マークアップエンジニアですか」と聞かれたことは一度もありません。

聞かれたのは毎回この3つでした。

  • これまで何をどこまで担当したか
  • 得意な領域はどこか
  • 週にどれくらい稼働できるか

職種名は案件票に載せるときの見出しでしかないというのが、面談を重ねた実感です。

案件票の職種名と、実際の作業が違うこともある

紹介された案件でも、記載された職種名と実際の担当範囲がずれていることはあります。だからこそ面談で範囲を確認する手順が要ります。

確認せずに入って「話が違う」となるより、先に聞いて調整したほうが早い。エージェント経由の場合、この確認は担当者が代わりにやってくれます。

単価は呼び方では変わらない

変わるのは対応範囲

「マークアップエンジニアと名乗れば単価が上がる」ということはありません。上がるのは、対応できる範囲が広がったときです。

私が7社のエージェント面談で提示されたのは、どこも月50万円台でした。このとき職種名を何と名乗るかは聞かれていません。聞かれたのは経歴・得意分野・週何日働けるかの3点だけです。

面談で見られているのは説明できるかどうか

指示どおりに実装するだけだと、代わりが見つけやすいため評価が上がりません。「なぜこの実装なのか」を説明できると、実装者ではなく相談相手として扱われます。

これはまさに、マークアップエンジニアという呼び方に期待されている能力そのものです。名乗り方ではなく、この説明ができるかどうかが単価を決めます。

マークアップ寄りに強くなるには

呼び方に近づくというより、対応範囲を広げる話として書きます。

1. タグの意味を確認する癖をつける

今書いているコードで、「なぜこのタグなのか」を1つずつ言えるか試してください。言えないものがあれば、そこが伸びしろです。

2. アクセシビリティの基本を押さえる

代替テキスト、ラベル、フォーカスの順序、コントラスト。フレームワークほど学習コストは高くありません。費用対効果の良い領域です。

3. 表示速度を意識する

画像の扱い、読み込みの順序。これも自動生成コードで問題が出やすい部分なので、直せると重宝されます。

4. 現場のルールに合わせる

私が入った30名規模の現場では、最優先されていたのは技術の高さではありませんでした。レギュレーションを守ることと、事故を出さないことです。

命名規則もファイル構成も、その現場の決まりに従う。自己流の「正しい書き方」を持ち込むより、そちらのほうが評価されます。

どちらを名乗るべきか

職務経歴書では「やったこと」で書く

職種名を悩む必要はありません。担当範囲を具体的に書くほうが伝わります。

  • 支給されたデザインの実装(PC・スマホ)
  • 既存サイトの改修・運用
  • WordPressテーマのカスタマイズ
  • アクセシビリティ対応

この形なら、相手が自社の呼び方に置き換えて理解してくれます。

迷ったら相手の言葉に合わせる

求人が「マークアップエンジニア」と書いているなら、応募時はその言葉を使う。合わせるだけで、話が通りやすくなります。

よくある質問

Q. マークアップエンジニアのほうが単価は高いですか

職種名では決まりません。対応範囲と、説明できるかどうかで決まります。実際の水準はコーダーの単価相場にまとめました。

Q. どちらを目指すべきですか

目指すのは職種名ではなく範囲です。まずHTML/CSSで案件を受けながら、JavaScriptかCMS構築を1つ足してください。

Q. 未経験の求人ではどちらが多いですか

「コーダー」表記のほうが目にする機会は多い印象です。ただし件数の比較にあまり意味はありません。業務内容で選んでください。

Q. HTML/CSSだけの案件は減っていますか

減っています。1つ足すだけで提案される案件の帯が変わります。この点はコーダーの将来性で詳しく書きました。

Q. 名乗り方を変えるだけで案件は変わりますか

変わりません。ただし自分がどこまで対応できるかを整理する機会にはなります。整理した結果を面談で聞いてもらうのが、いちばん早い確認方法です。

迷う時間より、外の基準を1つ持つ

職種名で悩むのは、比較する基準を持っていないからです。案件を紹介する側に聞けば、その場で答えが出ます。

私は7社に登録しましたが、門前払いはゼロで、技術テストもありませんでした。面談で「この経歴だと、あと何ができると案件の幅が広がりますか」と聞けば、担当者は具体的に答えてくれます。

今すぐ案件を変える気がなくても構いません。Midworksのような会社は登録も相談も無料です。9社の比較はフリーランスコーダーにおすすめのエージェントにまとめています。

まとめ

  1. 2つの呼び方に業界共通の厳密な定義はない
  2. マークアップエンジニアという言葉には構造・アクセシビリティ・保守性への期待が込められやすい
  3. ただし現場では呼び方はかなり適当に使われている
  4. 求人は職種名ではなく業務内容で判断する
  5. 単価を決めるのは名乗り方ではなく対応範囲と説明力

私自身、同じ作業のまま肩書きが変わった経験があります。呼ばれ方は後からついてくるので、先に範囲を広げてください。

何を足すべきかはコーダーに必要なスキル、単価の上げ方はコーダーの単価の上げ方にまとめました。

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次