HTMLコーダーの未来 〜AIやノーコードとどう向き合うべきか〜
2022年下半期以降、ChatGPTやGitHub Copilotなどの多様なAIツールが登場し、Web業界でもAIの活用が広がっています。コーディングに関連する便利な技術やサービスも絶えず進化している状況です。
AIによって多くの職種が置き換えられる可能性が話題になっていますが、果たして「HTMLコーダー」の存在意義はどうなるのでしょうか。
私のこれまでの経験を基に「HTMLコーダーの未来」について深く考えてみました。
私について
私がこれまでどのようなWeb制作業務に携わってきたかを完結にまとめました。
略歴
- デザイン系専門学校でWebデザインからコーディングを2年間学ぶ
- 新卒で3年間（現）株式会社メンバーズに入社（Web系事業会社）
- デザインからコーディング、ほんの少しのWeb開発（Vue.js）や広告運用など幅広いクリエイティブ業務に携わる
- その後フリーランスに転身して、様々な契約形態やクライアントとWeb制作を中心とした業務に携わる
- エージェント経由で制作会社に常駐
- 制作会社やエンドクライアントから単発案件を受注
- 大手事業会社の自社サービスの保守運用を準委任契約で行う
- 現在、Web業界7年目の26歳
- 今のスキル
- HTMLやCSSなどのベースコーディング
- VueやReactを用いたWeb開発（しっかりと関わり始めたのは直近1, 2年）
- WordPressを用いたテーマ開発
- PHPのLaravelを用いたバックエンド開発（多少理解できる程度）
- 今のスキル
前提
本題の前に、まずは様々な情報を整理しておきます。
言葉の定義
この記事で使う言葉の定義は以下の通りです。
| 単語 | 定義 |
|---|---|
| コーダー | HTMLとCSSでコーディングを行う人。JavaScript（jQuery）を使った簡単な動的な処理の実装もできる。WordPressもコーディング業務の一部に含める。 |
| フロントエンドエンジニア | JavaScriptでWebアプリの開発を行う人。モダンな技術（VueやReact）を使うことが多い。 |
| 静的サイト | HTMLとCSSのみで実装されている機能を"持たない"サイト。 |
| 動的サイト | JavaScriptやPHPなどを使って実装されている機能を"持つ"サイト。 |
コーダーの主な業務
この記事でのコーダーの業務は以下2つに分けています。
- サイトの新規構築
- 既存のサイトやサービスの保守運用
「サイトの新規構築」は言葉の通りで、0ベースでサイトをコーディングすることです。デザインデータを再現する力やCSS設計などのスキルが必要です。
「既存のサイトやサービスの保守運用」は、既にリリースされたサイトやサービスに対して新たな機能を追加したり、不具合を修正したりする業務になります。基本的なコーディングスキルも重要ですが、複雑な仕様書や既存のコードを読み解く「読解力」が特に求められます。
▽ 参考：他社の記事で書かれているコーダーの業務内容
将来性
この記事でのコーダーの将来性は以下3つに分けています。
- 5年後10年後もコーダー業務があるか
- キャリアアップの選択肢
- 単価
▽ 参考：他社の記事で書かれているコーダーの将来性
前提条件は以上で、ここからは「コーダーの将来性」について書いていきます。
5年後10年後もコーダー業務があるか
まずは結論からです。私は以下のようになると考えています。
- 新規構築のコーディングは無くなる可能性が高いが完全には無くならない
- 保守運用系の業務は無くならない
新規構築のコーディングは無くなる可能性が高いが完全には無くならない
2023年現在、デザインデータをHTMLに変換するツールはすでに存在します。これらのツールの精度が今より高くなれば、新規のコーディング作業はほぼ不要になる可能性があります。
しかし、現存のツールはレスポンシブデザインに対応したコードを生成できなかったり、要素をすべてpositionプロパティで配置していたりなど、課題はまだまだたくさんあります。
それでも、Figmaではレスポンシブデザインのデータを作成すること自体は今でも可能です。Figmaのプレビューにおけるレスポンシブデザインの再現性も高く、将来的にはプレビュー通りのHTMLを自動生成できるようになると思います。
ただ、この機能を活用できるデザイナーは「現時点では」ごく少数です。
この先、レスポンシブデザインでデザインデータを作成する手法が今よりも一般化して、HTMLの生成精度も向上すれば、新規のコーディング作業は事実上不要になると思います。
このように、デザインデータからのHTML自動生成が普及する日は遠くないと思いますが、すべてのプロジェクトで使えるわけではありません。その理由をいくつか挙げてみました。
- 動的なサイト開発では手作業での調整が避けられない
- 新しいツールの導入には稟議とコストがかかる
- 社風的に意見が通らない
動的なサイト開発では手作業での調整が避けられない
シンプルな静的サイトなら、自動生成されたHTMLコードをそのまま使うことが可能です。
しかし、動的サイトの場合、VueやReactなどのフレームワークを用いることが多く、これらには独自のルールや仕様があります。そのため、生成されたHTMLをそのままでは使えず、フレームワークに従ってHTMLを調整する必要があります。
新しいツールの導入には稟議とコストがかかる
HTMLの自動生成などの新しいツールを導入するには、通常、会社や上長への稟議が必要です。特に大企業では承認フローが厳しく、稟議が通りにくい場合があります。
また、ツールの導入には費用もかかります。一度の購入で済む「買い切り型」なら稟議は通りやすいですが、定額制の「サブスクリプション型」のような定期的に費用が発生する場合は、稟議が通りにくい（嫌がられる）傾向にあります。
社風的に意見が通らない
昔ながらの企業や、新しいツールに抵抗感を持つ上司がいる場合、「新しいツールを導入したい」と提案しても受け入れられないことがあります。
特にレガシーな技術に依存している企業では、新しいツールや技術の導入が消極的になるケースが多いです。
このように、様々な要因からHTMLの自動生成を採用できないケースは、現在も、そして将来も存在すると思います。
保守運用系の業務は無くならない
ここで取り上げる保守運用の対象は「Webサービス」に限定します。
多くのWebサービスでは、VueやReactといったフロントエンド技術、さらにはバックエンドにおいてもPHPのLaravelやPythonのDjangoといったWebフレームワークが使われています。
一見、「コーディング」とはほど遠い技術が使わているように感じますが、これらの技術の根幹はあくまでHTMLです。以下のように、ベースとなるHTMLに対して独自の記法で様々な処理を追加していく形になります。
<template>
<p>{{ message }}</p>
<button @click="clickHandler">Click Me</button>
</template>
<script>
export default {
data() {
return { message: "Hello, Vue!" };
},
methods: {
clickHandler() { this.message = "Clicked!"; }
}
};
</script>
import React, { useState } from "react";
function App() {
const [message, setMessage] = useState("Hello, React!");
const clickHandler = () => { setMessage("Clicked!"); };
return (
<>
<p>{message}</p>
<button onClick={clickHandler}>Click Me</button>
</>
);
}
export default App;
// Controller
public function show()
{
$message = 'Hello, Laravel!';
return view('sample')->with('message', $message);
}
// View
<p>{{ $message }}</p>
採用する言語やフレームワークによって細かい記法は変わりますが、HTMLに近い記述は共通して存在しています。
そして、Webサービスの保守運用においては、以下のように職種ごとに作業を分けることがあります。
- コーダー：見た目（HTMLやCSS）の実装
- エンジニア：動的な処理や機能の実装
エンジニアは高度な言語を使っているのでHTMLやCSSも簡単に扱えると思われがちですが、むしろ苦手なエンジニアのほうが多いです。そのため、お互いに得意な領域を補いながら保守運用を行うケースもあります。
このように、Webサービスの保守運用においては、将来もコーダーの需要は無くならないと思います。
専門分野が分かれていても基本的な技術理解は必要
先程紹介したように役割を分けて保守運用を行う場合でも、コーダーは採用されている技術について最低限の理解が必要です。
例えば、Reactが採用されている場合、ディレクトリ構造や自分が触るファイル、さらにはReact自体の基本的な概念についても、しっかりと理解しておく必要があります。これらの理解が無いと円滑に作業ができません。
VueやReact、バックエンドのWebフレームワークについての技術を理解するには、Web全般に関する知識やJavaScriptの基礎スキルが必要不可欠です。コーダーであっても、これらの基礎知識はしっかりと理解しておきましょう。
これらの基本技術を理解しない、または理解しようとしないコーダーは将来徐々に需要が無くなり、最終的には淘汰されると思います。
古い技術を用いたサービスではコーダーのスキルが重宝される
今でも普通に運用されているサービスでも、実は裏側は何年も前のレガシーな技術を泥臭く使っている場合があります。このようなサービスは、コードが肥大化して中々最新の技術にリプレイスできないものです。
そして、上記のようなサービスの保守運用は、バックエンドエンジニアが仕方なくHTMLやCSSを対応しているケースが多いです。そのような現場ではHTMLコーダーが特に重宝されます。
キャリアアップの選択肢
ここで指す「キャリアアップ」は、コーダーが他の職種や役割へとステップアップできるかどうかを指しています。
フロントエンドエンジニア
フロントエンドエンジニアへのキャリアアップが一番一般的だと思います。使う技術は主にJavaScriptになるので、基礎理解がある状態でスタートできます。実際に私はこのパターンでした。
バックエンドエンジニア
フロントエンドエンジニアより難易度は高いですが、この道も十分実現できると思います。バックエンドエンジニアには、データベース管理、サーバー管理、API設計など、コーディング以外のスキルも求められます。
私がバックエンドのプロジェクトにアサインした時は、サーバーやデータベースの概念、テーブル構造の理解、よく使うSQLコマンドから学びました。Web制作とは考え方が全く違うので、最初はかなり苦労した記憶があります。
ディレクターやPMなど管理する側
クリエイター側から管理する側になるケースも少なくありません。
管理する側の立場には様々な役割があり、プロジェクトによっては役割が変わったりもします。
- プロジェクトの予算やリソースを管理する
- プロジェクトの全体的な品質や進行状況を管理する
- クライアントとコミュニケーションをとり、要件定義を行う
- デザインの品質を担保する（アートディレクション）
- エンジニアリングチームの進行管理を行う
- システムの設計書や仕様書の作成、テストの実施など
管理する側を目指す方は、どの領域を担当したいかを明確にすることが重要です。
単価
ここでは「コーダー」と「フロントエンドエンジニア」の単価について考えてみます。まずは働き方を比較してみます。
| 比較項目 | コーダー | フロントエンドエンジニア |
|---|---|---|
| プロジェクトの規模 | 小・中規模が多い | 中・大規模が多い |
| プロジェクトの種類 | 単発が多い | 中長期が多い |
| 契約形態 | 請負が多い（成果物に対して請求を行う） | 準委任が多い（稼働時間に対して請求を行う） |
もちろんコーダーでも大規模なプロジェクトはありますが、数ページ規模の単発系のほうが多いと思います。
対してフロントエンドエンジニアの場合、規模が大きいプロジェクトにアサインすることが多いので、契約形態は請負より準委任になることが多いです。
コーダーの1つのプロジェクトの単価（請負）は20万円以下が多く、10万円以下のケースもよく目にします。時給換算すると良くても2,000円くらいだと思います。
フロントエンドエンジニアの単価（準委任）は、どんなに安くても時給4,000円くらいです。
このように、コーダーとフロントエンドエンジニアを比べてみると、フロントエンドエンジニアのほうが単価が高くなる傾向です。
単価の決まり方
Web制作の「報酬」の決まり方の図
予算を上げる3つの方法の図
結局「スキル」が必要の図
フロントエンドエンジニアのほうがコーダーより単価が高い理由
先程の図の「予算」の部分に注目します。プロジェクトの予算が多いほど、働く側の単価も高くなりやすいです。
当然ですが、大企業のほうが予算が多く、中小企業のほうが予算は少ない傾向です（外部から資金調達をしているベンチャーなどは小さくても予算がたくさんある場合があります）。
そして、コーダーに関する仕事は「中小企業」から依頼されることが多く、フロントエンドエンジニアに関する仕事は「大企業」から依頼されることが多いです。
さらに、請負契約ならではの仕様追加や修正が終わらない地獄も、準委任契約にはありません（稼働した分の報酬は約束されているので）。
このような理由から、コーダーよりフロントエンドエンジニアのほうが高単価になりやすいということです。
WordPressを扱うコーダーの未来
今のWordPressに対する私の考えは主に3つです。
- 常にWordPressのトレンドを追える自信があれば、今後も仕事には困らない
- とはいえ、なんだかんだクラシックテーマでのWordPress案件は無くならないと思う
- でも、WordPress一本でやっていくのはリスクが高い
常にWordPressのトレンドを追える自信があれば、今後も仕事には困らない
WordPressは日々進化し続けています。
ブロックエディタがリリースされた当初は評価がかなり低かったです。しかし、昨今ではブロック前提の新機能がどんどんリリースされたり、ブロックテーマやハイブリッドテーマという開発手法も生まれました。
このように、最新の情報を常にキャッチアップできて、新しい技術を理解・取り入れられる自信がある方ならWordPressメインで仕事を請けられるはずです。
とはいえ、なんだかんだクラシックテーマでのWordPress案件は無くならないと思う
あくまで私の周りでの話ですが、正直なところ、クラシックテーマで開発する案件のほうが圧倒的に多いです。ブロックテーマやブロックエディタで開発を指定されたのは1, 2回程度しかありません。
ブロックテーマやブロックエディタで開発をする一番のメリットは、サイト全体を管理画面から編集できる点です。
しかし、この機能を使いこなすにはコーダーのスキルというより、フロントエンドエンジニア寄りのスキルや知識が必要になります。開発工数も「クラシックテーマのファイル内にコンテンツを直接書く手法」より工数が必要になります。
そもそも、WordPressで開発を依頼する制作会社は、サイト全体を管理画面からの編集したり、ブロックを使いこなす高度なスキルなどはあまり求めていません。何故なら、小規模のプロジェクトにそこまでの予算や工数を避けないからです。
また、初期構築は外注をしても、保守運用は自社で行うケースも結構あります。その際にブロックで開発をしていると、社内の技術的に扱えない場合もあります。なので、あえてクラシックテーマ（これまで通りのファイル内にコンテンツを直接書く手法）で開発を指定することもあります。
SNSではブロックエディタやブロックテーマの話題がたくさん溢れていますが、正直実際の現場ではこれまで通りクラシックエディタでの開発のほうが溢れています。
この投稿の引用リツイートで様々な方の意見を見れます。
でも、WordPress一本でやっていくのはリスクが高い
どのような開発手法をメインにしても、WordPress一本で仕事をするのは高度なスキルを持っている人以外はリスクが高いです。
X（旧Twitter）がいい例です。
フォロワーの管理や予約投稿などの機能を提供するSocialDogは、Twitter APIというTwitterの機能を用いてサービスを運営していました。
しかし、Twitter APIの利用規約の変更によってこの機能が有料になり、一時は半分以上の機能が使えなくなりました。
これまでは無料プランでもフォロワーの管理や予約投稿など機能は使えたのですが、今では無料プラン自体が無くなりました。
このように、ひとつのプラットフォームに依存をすると、プラットフォーム側の方針によっては多大な影響を受けることがあります。なので、WordPress以外にも自分の武器は持っておくようにするのが大切かなと思います。
ノーコードの将来
STUDIOやWixなど、ノーコードツールは日々進化しています。ここでは、ノーコードの「現状」と「将来」について話していきます。
ノーコードの現状と将来性
- 現状は一部の現場で使われている（普及率はまだまだ低い）
- 将来はノーコードツールでの制作が一般化する可能性が十分ある
現状は一部の現場で使われている（普及率はまだまだ低い）
ノーコードは工数を抑えてサイトを手軽に作れる便利なツールですが、全てのプロジェクトに簡単に導入できるわけではありません。
現状の課題をいくつか挙げてみました。
- 実現したいことができない可能性がある
- 理由：様々な制約がノーコードツールにはあるため
- 新しいツールを使うことに制作会社は特にネガティブ
- 理由：保守運用をしっかりとできる自信がないため
- 理由：そもそもツールを扱える人材が少ない
- クライアントに受け入れられない
- 理由：実績のない手法は怖がられてしまう
コーディングの依頼が来るときには既に仕様が固まっていることが多いので、ノーコードの提案をする機会がそもそも少ないのが現状です。また、ノーコードツールを導入する選択肢がそもそも存在しない制作会社もたくさんあります。
なので、少なくともこの数年はノーコードツールにコーディング業務が奪われることは無いと思っています。
将来はノーコードでの制作が一般化する可能性が高い
過去の傾向を考慮すると、この可能性は非常に高いと考えられます。
かつては、インフラエンジニアが自社のインフラ環境を手作業で構築していましたが、今日ではAWSやGCPなどのクラウドサービスによる構築が主流となっています。
バックエンド開発におけるデータベース設計も、ローコードプラットフォームを使用してクラウド環境で一元化される傾向があります。
5年後程度であればローコードがすべてのバックエンド開発を担う可能性は限りなく低いと思いますが、それより先の10年後くらいには開発手法が劇的に変化する可能性が高いと思っています。
このように、表面的な部分（デザインやフロントエンド）より根幹部分（バックエンドやインフラ）の開発が様々なツールによって代替されつつあります。
そして、次に代替される可能性がある部分はフロントエンド分野だと思います。バックエンドと同様にここ数年は大きな変化はないと思いますが、いずれはフロントエンド開発やコーディングもノーコードやローコードに置き換わる可能性が高いです。
しかし、開発業務がツールによって代替されたとしても、そのツールを操作する役割は必要です。したがって、コーダーが完全に淘汰されるわけではなく、業務内容が変化する（コードを書かずにツールでコーディングをするみたいな）可能性が高いと私は考えています。
おわりに
HTMLコーダーの業務内容は、10年単位で見るとほぼ確実に変化すると思います。これまではフルスクラッチで実装していたものを、AIやノーコードで実装するのが当たり前になるかもしれません。
とはいえ、それらのツールを実際に扱う人材は必ず必要ですし、プロジェクトによってはそれらのツールを採用できない場合もあります。その時は、スキルのあるコーダーが重宝されるので、私たちは日々学習し続けなければいけません。
最後に宣伝ですが、Web制作全般の実務的な内容を学べる本を書いたので興味がある方はぜひ読んでみてください。
Discussion