見出し画像

「HTMLコーディングの仕事なら自分にもできるかも」は考えが甘い、という話

元WEBデザイナーが、デザインの仕事についてつらつらと書いていきます。今回はHTMLコーディングの仕事なら簡単にできそうという考えは甘い、という事ついて語ります。職業訓練・スクールでWEBデザインを学んでいる人、就活中の人に読んでいただければ幸いです。


他人の作ったデザインカンプの再現は難しい

実務経験に乏しい人、職業訓練やスクールを出たばかりの人のうち、最初からHTMLコーダー、フロントエンドエンジニアを目標に勉強してきた人たちはそうでもないかもしれませんが、元々デザイナー志望で諸事情によりコーダーを目指すことになった人は、「実案件に則した実戦形式のコーディング練習」の数をこなしていないため、コーディングの仕事さえも厳しくなる可能性があります。

特に躓きそうなのは「他人の作ったデザインカンプのHTML&CSSでの再現」ではないでしょうか。

デザイナー志望の人の場合、デザインカンプからコーディングまでを自分で行う事が多いと思います。この場合、一連の作業は自分の実力の範囲内、自分が想像できる範囲内で無意識にコントロールしてしまっていたり、難しい、実現不可能だと判断したら実現可能な仕様に変更が簡単にできてしまいます。

実際の案件で他人の作ったデザインカンプのコーディングを請負う場合、自身の実力の範囲内、想像の範囲内を超えてくる事も多々あります。

そのような状況に行き当たった際に、自身の実力不足、知識不足が原因で「実現不可能」と判断しても、クライアントを納得させることは不可能ですし、独断で仕様を変更する事も許されません。

コーディングできないデザイナーのデザインカンプを渡される事も多い

WEBデザインの仕事のうち、HTMLコーディングがメインの案件の場合、デザイナーからデザインカンプを渡されて、それをHTML&CSSで再現していく内容が主になると思います。

デザイナーがコーディングを他人に任せる理由は様々ですが、リソースの問題や作業の分業合理化よりも、デザイナー自身がコーディングできない、または苦手だから他人に委ねる場合の方が多いと考えられます。

そのようなデザイナーはHTML&CSSをよく理解していない事以上に、「コーディング作業とはどのようなものか?」を知らないため、見た目の事しか考えられていないデザインカンプ、HTML&CSSで実現不可能なデザイン、レスポンシブ対応で破綻するor実現不可能なデザインをやりがちです。

そして、「実現不可能」の後始末・尻拭いをコーダー、フロントエンドエンジニアに「何とかしてくれ」の一言で押し付けてくる事が多いです。

この傾向は特に紙媒体の仕事が減ってWEBの領域にスライドしてきたグラフィックデザイナーによく見られます。困った事にグラフィックデザイナーの多くはFigmaやXDといった、開発者向けの補助機能が充実したツールを使わずIllustratorでデザインカンプを作る事が多いため、作業の困難さに拍車がかかります。

書き方に機能性、合理性、公共性を求められる

仕事としてコーディングを担当する場合、内容と作業環境にもよりますが、大抵の場合は機能的で合理的な書き方が必要になります。特にバックエンド側のエンジニアと協業する際は、再利用可能なコードを書くことを求められます。

バックエンドエンジニアに嫌われる記述として、

div.aaa {~} ・・・ divに.aaaを記述したときだけしか適用されない
ul.bbb li.ccc a{~} ・・・ 指定通りのネストにしないと適用されない

.ccc{
display:flex;
justify-content:center;
margin:xx;
padding:xx;
width:xxx;
height:xxx;
font-size:xx;
font-weight:xx;
line-height:xx;
}  ・・・一つのclassにレイアウト関連と文字装飾のプロパティが混在、プロパティを詰め込み過ぎている

上記のような、特定のタグにしか適用されないCSS、ネストの深いCSS、プロパティを盛り込みすぎる書き方が挙げられます。

HTML&CSSのベタ書きで作られるホームページやLP等であればそれほど問題にはならない書き方ですが、バックエンド側のプログラムで動的に生成されるCMSやWEBアプリで使用する場合、コードの再利用や特定条件外でのCSS適用ができないので、効率の良い書き方ではありません。

また、バックエンド側プログラムが絡む案件では、複数人で同じコードを共有する事、コードの使いまわしが可能である事等、機能性、合理性を考慮した書き方や、チーム全体で共有できる命名規則、構造、コードの読みやすさ等の公共性が必要になるということを覚えておきましょう。

「簡単な更新作業」も慣れないうちは簡単ではない

「簡単な更新作業」と言われて請け負ってみたら、実態は全然簡単ではなかった、という事はよくある事です。既存のコードの更新、改修作業が意外と簡単ではない理由としては、以下が挙げられます。

  • 他人の書いたコードの読み書きが大変

  • 既存のコードを破壊しないように修正・追記をしていく必要がある

  • CSSの適用範囲を理解せずに書き換えると危険

  • ガイドラインが設定されている場合、読み込みは必須

  • CMS等のシステムで動的に生成しているサイトは構造が難しい

  • 作業環境、ツールは指定されたものに合わせなければならない

  • Git等のバージョン管理ツールで管理されている場合、ツールの使い方の習得と作業環境の整備、案件ごとの運用ルール熟知が必須になる

一つ一つの作業難易度が高いかというと、そういうことは無いのですが、練度が低いうちは、上記のような「作業に際して注意すべきこと」すら思いつかないでしょう。迂闊にコードを書き替えてしまうとコードの改悪、作業環境・ルールを遵守していなくて環境破壊をしていたりという事があります。最悪の場合、その事に気付かず納品して、多方面・広範囲に迷惑を及ぼす事もあり得ます。

既存サイトの更新作業は簡単手軽なように見えても責任は重いです。経験の浅い人が更新作業だからとたかをくくって請け負うと、痛い目を見る事もあるので注意が必要です。

実務未経験でフリーランスになるのはデザイナー以上に難しい

コーディングの仕事は基礎技術はもちろん、作業工程、作業環境、作業手順に関する経験値が高くないと周囲に迷惑を及ぼす可能性が高く、また、複数人で同一コードを共有する事がとても多いので、自分のやり方しか知らない・できないようでは、参画可能な案件は限られてしまいます。

現場での実戦的な作業経験は制作会社等に所属していれば自動的に積むことができますが、実務未経験からいきなりフリーランスになってしまうと、複数人で共同作業する現場でしか学べない作業工程、作業経験を積むことができず、コーダー、フロントエンドエンジニアとしてのキャリア形成で無駄な遠回りをする事になります。

実務未経験からまっとうに稼げるフリーランスコーダー、フロントエンドエンジニアを目指すのは、実務未経験からフリーランスデザイナーを目指すよりも難しいと言えます。

現状として、コーダー、フロントエンドエンジニアは不足している傾向にあります。最終的にフリーランスを目指すにしても、売り手市場である今のうちに制作会社等に就職して、経験を積んでからの方が目標の実現はよりスムーズかもしません。

ただし、HTMLコーダーは初級職なので、実務未経験・ポテンシャル採用の場合だと30代前半位まででないと年齢的に厳しいと思います。年齢的に難しそうであれば技術職ではなく、ディレクション等の総合職を目指した方が、WEB制作職以外のスキル・経験を活かす事が出来る部分もあるので、就業できる確率は高くなると思います。


この記事が気に入ったらサポートをしてみませんか?