🔍

ベーシックなweb制作における非機能要件について考えてみた

2021/11/26に公開

私はweb制作の世界に入って8年くらいが過ぎました。
その中で色々な案件を経験しており、毎回どう「更によいアウトプットをするにはどうしたらいいのか」と自問自答、試行錯誤しながらやってきました。

前職は納期優先で安いサイトを作るタイプの制作会社でした。
その中では、LPをアップロードするのにデザインを作ってそれを画像一枚で貼り付けたhtmlをアップロードして完結、というような案件もありました。
クライアントの目的を達成するには、それでも機能要件は満たせることがあるというのが悲しいながらweb制作のごく一部では真実ではあります。

現在の会社に入ってからは、コードレビューが導入されていることもあり、非機能要件についても考える機会が増えました。
その中で色々と見えてきたものがあるので、ideaとしてまとめてみます。
マサカリ大歓迎なので、何かありましたらコメントください!

まずは機能要件・非機能要件という単語を整理していきたい

システム開発全般における機能要件・非機能要件について、まず下記のように書かれています。

システム開発や構築において、一番最初に行われる工程が『要件定義』です。この要件定義では、製作するシステムに対し、その製作の主目的となる、実装搭載すべき機能や満た>すべき性能などを明らかにしていく作業を行います。
この要件定義のうち、特に『実装、搭載すべき機能』に関する要件のことを『機能要件』と言います。
例えば、『何がしたいのか』、また『何ができないと困るのか』など、そのシステムが必ず満たすべき要件のことを指します。車で例えるなら『前後に進むこと』、『右折、左折ができること』などが機能要件といえます。

また、そのシステムがどれだけの性能を持っているかなど、主目的(機能要件)以外での要件は『非機能要件』と言います。車で例えるなら、『どれだけ燃費が良いか』『故障はしないか?』『スピードを出しても安定して走るか?』『故障してもメンテナンスはしてくれるか?』などが非機能要件と言えます。

http://cloudeo.jp/word/glossary/function_nonfunction.html

これを踏まえると、web制作の機能要件はクライアントのサイトを作る目的を達成することであり、それは【サイトをバズらせる】【サイトから顧客を得る】【商品の認知度を上げる】等々の解決だと私は考えます。(あくまで私の考えであり、この記事における定義です)
ここに関しては、かなりディレクターさん、デザイナーさん手動で導かれていく要素が多いように思えます。

一方、webサイトの非機能要件はどうでしょうか。サイトのレスポンス速度、セマンティックなマークアップ、アクセシビリティの配慮…
かなりエンジニア(コーダー)の腕によるものになってきます。

直近で「非機能要件を高いクオリティで達成する!」という気持ちで案件をやっていて、エンジニアがどう非機能要件を満たしていけるか少し見えてきたので、下記に記してみたいと思います。

私の考える制作における非機能要件を満たしていくためのステップ

CSS設計を適切に行う

CSSがどのように設計されているかは、サイトの機能にはまったく影響がありません。
ですが、CSS設計が適切に行われているかどうかはサイトの持続可能性にクリティカルに関わってきます。
CSS設計がずさんだと意図しない箇所が崩れたりすることもあります。
制作をやっている方ならCSS設計完全ガイドは一読の価値があります。(FLOCSSについても書いて欲しい…確かなかったような)
https://www.amazon.co.jp/CSS設計完全ガイド-詳細解説-実践的モジュール集-半田-惇志/dp/429711173X

画像の解像度に決めを持つ

画像はサイトのパフォーマンスを低下させやすい要素です。
サイトのパフォーマンスをよくするために、どの解像度を使用すべきか、サイトのデザインのクオリティを保つためにはどの解像度が最低ラインかというところまで考えてやるべきであると考えます。
最終的に2xにしても、1xにしても、1.x倍にしてもいいのですが、なんとなくその解像度で書き出しているというのはちょっと待ってほしい気がします。
srcsetを用いて、2xと1xなど複数の解像度の画像を用意し出し分ける、もしくは<picture>要素で別の画像を出す…というのも、選択肢としては視野には入れておいて欲しい部分だと私は思いました。
自分への戒めですが、display: noneでの画像のレスポンシブ出し分けもやめていきたいと思っています。
(※srcset, pictureタグはIE11ではポリフィル必須)

パフォーマンス解析を行う

Lighthouseでの解析だけでも構いません。まずは見るべきだと思っています。
Lighthouseにおいては、Performanceに関してはどうしても修正できないものもあると思いますが、Accessibility、Best practices、SEOに関しては満点に近いところを目指さなくてはならないと思っています。
ベーシック認証がかかっていてもLighthouseは検証ツールから実行が出来ますので、クライアントに見せる・納品する、の前にフローとして組み込んでしまうのが良さそうです。
アクセシビリティに関しても、ここで見るべきだと思っていますし、axeなどのツールをつかってもいいでしょう。

セマンティックなマークアップ

ここは賛否ある箇所だと思います。
htmlタグが適切に使われているかは検索エンジンがそこまで重要視していないという情報もあります。
ですが、最適解のあるものを積極的に行わないというのは私は出来ないと思います。
headingタグなどがきちんと構造通りに使われているか、リストで<ul>が使われているかなどは、人間が見てのコードの理解しやすさにつながる箇所でもあります。
altの効果も議論されることがありますが、私はGoogleに否定でもされない限り書いていくべきだと思っています。
閉じタグ忘れは、検索エンジンが勝手に補正してくれるようですが、サイトのソースを覗いてくるタイプの人って意外といるので恥ずかしい思いをしないようにツールでチェックしましょう。
クリックイベントはbuttonタグに。

画像には属性でwidthとheightを

これは細かな話ですが、レイアウトシフトを防ぐためにwidthとheightは入れていきましょう。
下記記事読み応えあって面白かったです。
https://www.mizdra.net/entry/2020/05/31/192613

自分が思いついた非機能要件を満たすためのステップはこれだけです。
jsのパフォーマンスはこの記事で最適解を示せるものではないので省いています。

非機能要件を満たしていくにはどのようにプロジェクトにあたればいいのか?

大事なことは知識納期だと思っています。
上記で述べたようなことは、知識なくては出来ません。webの仕様を理解していくキャッチアップ力は常に持ち続けていく必要があると思っています。
納期は大事なファクターです。残業フルフルでやらなければ終わらないプロジェクトでは、エンジニアはきちんと設計にあたっていくことは難しいです。(少なくても私は、時間に追われているプロジェクトできちんと設計できたー、ってなったことがありません。)
エンジニア自身が納期をコントロール出来るのであれば余裕を持って工数を設定し、これを見ているディレクターさんがいらしたらクオリティの高いコードを求めるなら必ず余裕を持った納期を設定してあげて下さい。

最後に

web制作は、webの基本であるhtml, css, JavaScriptに真っ向から向き合っていく仕事です。
真剣に取り組めば、webの基本知識を深めていくことが出来ます。
みなさんも楽しいweb制作ライフを!

(ここから2021/11/26 15:00加筆)
デザイン再現について言及してませんでした。
私はデザイン再現は、クライアントの目的を達成するためにあり、それは機能要件だと思っています。
会社により様々だと思いますが、私はピクセルパーフェクトよりで実装すべきだと思ってますし、それがないと機能要件は満たしていないように思えます。

Discussion