- バックエンド重視の体制
- html、cssが弱いソースコード
かなと思います。
今回はおこがましいですが、Web制作会社に5年間身を置いた経験から自社開発企業のhtml、cssに対して物言いをさせていただこうと思います。
- 自社開発系企業のソースコードがひどい実態
- 自社開発系企業のソースコードがひどい理由
- 解決策
を書いていきます。
- 自社開発サービスのhtml、cssを書いてるデザイナー
- 自社開発サービスのhtml、cssを書いてるバックエンド
- アクセシブル汎用性のあるコードを書きたいフロントエンド
の方々を対象にしています。
自社開発系企業のソースコードがひどい
ほんとに申し訳ないですが、自社開発系企業のソースコードはひどいです。
これは知人の間でもよく話が上がってましたし、覚悟はしていたのですが想像通りのひどさでした。。
具体的にどうひどいかを何点か挙げてみたいと思います。
モジュールの概念がない
モジュールの概念がないです。
モジュールとはパーツの塊であり、例えば
- 見出し
- リスト
- テーブル
- ボックス
- リンク
などがあります。
モジュールは、それぞれサイト内で使い回すべきです。
つまり同じサイトでページやカテゴリが違うからと言って違うh2見出しやリストのデザインは必要ありません。
違うデザインを用意することでコーダー、デザイナーの作業は肥大化しますし、ソースコードも統制が取れなくなります。
もちろん意味がある使い分けはOKです。
例えば同じサイト内でもコンテンツが違うからという理由でデザインをガラッと変えることはありますが、意味のない使い分けはNGです。
自分が自社開発サービスで改修したサイトでは5つほどあるテーブルがそれぞれ違うデザインでした。
もちろんそこに使い分けの意味は感じられませんでした。
一番の問題は次回テーブルを使用する際、意味づけがされてないため、どのデザインを使えばいいかわからなくなるという問題です。
その問題から免れるために新しいデザインを発生させるという悪循環に陥ります。
Web制作会社では大抵モジュール一覧を作ります。
名称は各企業によっても異なると思いますが、モジュールだけを集めたテストページですね。
モジュール一覧を運用することが破たんしないサイトをつくる近道です。
- 使い回せるモジュール一覧をつくろう
- 同じモジュールでデザインを複数作るときは意味づけをすること
そもそも仕様書がない
仕様書がないサイトも多いですが、引き継ぐ人は困りものです。
例えば、引き継いだ人はわからないため勝手な解釈で命名ルールを作ってしまい、それがまた悪循環となります。
- サイト構築時、セットで仕様書（wiki）を作ること
!importantの乱打
CSSのツッコミ所はかなり多いのですが、!importantの乱打は人ごみでバット振り回してるが如く危険なので辞めていただきたいです。
- そもそも!importantは不要です。今日からやめましょう。
- htmlにstyle属性で書くのもやめましょう。
labelとinput要素が紐づいてない
自社開発サービスはformが多いのでこちらも注意したいところです。
紐づいていればlabelをクリックした時、input要素にフォーカスが合いますが、紐づいてないことが多々あります。
またタブで巡回できないなどアクセシビリティを怠ってるケースが多いです。
- formのアクセシビリティは特に注意しましょう
- アクセシビリティは下記2冊を読めばOKです。
contentに文字入れがち
無意味に疑似要素のcontentに文字を入れがちですが、これもアクセシビリティ的にどうかを考える必要があります。
つまり、contentの文字はスクリーンリーダに読み上げされません。
そのためテキストはhtmlに極力書くことが望ましいです。
横並び
横並びがfloatだったり、flexだったりまちまちです。
flexをかけた子にfloatかけてませんか？
- 今や横並びでfloatは必要ありません。
- flexを使いこなしましょう。
反論：全てがそうではない
たしかに全ての自社開発のサービスが上記の状態ではないですよね。
こうなってしまうのはある条件と理由があると思います。
自社開発系企業のソースコードがひどい理由
自社開発系企業ではhtml、cssは軽んじられている
まずこれは事実かなと思います。
ソースコードレビューなどがされていなければ軽んじられています。
見た目さえ崩れていなければいいという感じでソース自体を第三者が見ていません。
もしくは見る人のレベルが一定のレベルに達していなくても意味がありませんね。
なぜ軽んじられているかというと、サービスはバックエンド命だからです。
なので単価も高いですし、コストもそこにかかります。
人数も1フロントエンド：9バックエンドくらいじゃないでしょうか。
デザイナーやバックエンドが片手間にやっている
フロントエンドが少ないためデザイナーやバックエンドが片手間にやっているという例は多いです。
事実面接を受けた大手飲食口コミサービスは、フロントエンドという職種ができたのは最近という話でした。
それまでどうしていたかというとデザイナーやバックエンドがやっていたということです。
相応の専門性を持ってやってくれていたらいいのですが、専門は別ですから十中八九、先述のようなひどいソースになることは明白です。
余裕がある
古いサービス
以上は、古くからのサービスで起こりがちです。
とはいえ、新しいサービスでもこのような状況であれば、かなり負の遺産を抱えることになるので注意した方が良さそうです。
解決策：しっかり設計のできるフロントエンドが…
解決策としてはしっかり設計のできるフロントエンドがhtml、cssにおいてリニューアルを担当することです。
フロントエンドのリファクタはサイトが大きくなればなるほど難しくなります。
そのためリニューアルの方が無難ですし、いいものが出来上がります。
それにはしっかりしたフロントエンドが必要です。
ここで言うしっかりしたフロントエンドの条件を3つ挙げて記事を締めたいと思います。
- 大規模サイトの構築経験あり
- バックエンドよりというよりコーダーよりのフロントエンド
- Web制作会社経験者
1つ目の条件は異論はないかと思います。
2つ目は、最近自分が思うところでフロントエンドでも2パターンいると思ってます。
それは
- アクセシビリティや保守性の高いコードを書けるフロントエンド
- JSフレームワーク、node.js、typescriptを得意とするフロントエンド
です。
もちろんどちらも必要なのですが、自社開発系企業には前者が欠けているように感じます。
3つ目、Web制作会社経験者は基本がしっかりしているため、2つ目の前者のような人材が多いと思います。
ということで解決策をまとめるとWeb制作会社経験者のフロントエンドを採用し、サービスをリニューアルもしくは新規立ち上げしましょう。
いいソースにすることで得られるもの
良いソースにすることで得られるものが多々あります。
- 保守性が高いため更新の際、崩れや工数がかからない
- アクセシビリティが高まり、ユーザーの満足度向上
- 社員のモチベーションも向上
- サイトパフォーマンス向上（表示スピード）
などなどがあります。
Web業界全体で是非いいhtml、cssを書いていいサービスを作っていきましょう！
コメント