はじめに
「品質」と言われたら何を思い浮かべるでしょうか？
コードの品質でしょうか。
または、製品やサービス全体の品質でしょうか。
それらを向上させるために、
フロントエンドエンジニアは何をしたらいいのでしょうか？
目次
- 「品質」とは何か
- 【その１】「品質が良い」コードを納品するために（内部品質）
- Cursor Rulesで品質は向上するか？
- Linterは万能か？
- これで「品質」は良くなる？
- 【その２】「品質が良い」サービスを提供するために（外部品質）
- 「製品品質」の良さと「利用品質」の良さ
- 「品質」評価の移り変わり
- 人間中心設計
- フロントエンドエンジニアができること
「品質」とは何か
「品質」とは「求められた基準をどれだけ満たせているか」の指標、と定義することができます。
たとえば、エンジニアである私たちは設計書にある要件を満たすためにテストコードを書いたり、
相互レビューをしたり、コーディング規約を守るためにLinterを使用したりします。
より広い範囲で見ると、
サービス全体の品質を保つため、QAエンジニアという品質管理のための職種もあったりします。
ソフトウェア品質技術者資格認定試験というものもあるらしいです。
【その１】「品質が良い」コードを納品するために（内部品質）
私の所属するフロントエンドエンジニアチームでも、「品質」はよく話題になります。
この一年も、コードの品質をよくする仕組みづくりにフォーカスして挑戦を行ってきました。
Cursor Rulesで品質は向上するか？
今年の春頃からチームでAIエディタのCursorを活用しています。
その中で「Rules」という機能を利用してコードの品質向上を目指しています。
Rulesとは、
Cursorにコード生成の規則やセルフレビューの観点などを
ドキュメントで定義できる機能です。
例えば以下のようなSCSSファイルのコーディング規則を
mdcファイルで作成しておくと、
### ショートハンド
```scss
// ❌ 冗長なショートハンド
margin: 10px 10px 10px 10px;
// ✅ 適切なショートハンド
margin: 10px;
// ✅ 冗長なロングハンドは許可
margin-top: 10px;
margin-right: 10px;
margin-left: 10px;
Cursorがコード生成やセルフレビューの際に参照して、
ルールに反した記載を洗い出し、修正の提案を行なってくれます。
チームで基本的な書き方を揃えることができるというわけです。
🙆♀️Rulesの良い点
- mdcファイル形式なので、学習コストなく誰でも簡単にルールを追加、修正できる
- git管理しているので、気がついた時にすぐ更新してメンバーに展開することができる
- ある条件の時のみ適用したいルールや、レビュー時にリマインドして欲しい観点などを記載すれば、最終的な判定を人間に任せることもできる
- コーディング規約をRulesに集約することでチーム内資料の管理が楽になる
🙅♀️Rulesの課題
- AIエディタの判断に委ねているため、NG箇所の洗い出しが漏れてしまう可能性もある
AIモデルの進化で課題は今後解決されていくかもしれません。
私たちのチームではAIエディタの導入後も安定した品質の良いコードを納品するために
日々Rulesのブラッシュアップを重ねています。
Linterは万能か？
もちろんチームではLinter（ESLint、stylelint）も導入しています。
レビュー指摘が多い書き方については、
Linterのカスタムルール作成にも取り組んできました。
🙆♀️Linterカスタムルールの良い点
- ルールに反するコードを確実に拾える
- ルールに反する場合はコミットさせないなど厳密な制御ができる
🙅♀️Linterカスタムルールの課題
- 条件によって適用の有無を変えたい場合など、ルール作成に手間がかかる（Linterの処理やテストコードが複雑化する）
- カスタムルールを増やすことでエディタの負荷が上がり、コーディング作業のノイズとなる
チームではこういったLinterの課題についても考えた上で、
以下のような役割分担でRulesとの併用を続けています。
Rules：チームのコーディング規約の属人化を防ぎ、表記揺れなどを無くす役割
Linter：処理のエラーに繋がりかねないコード納品を防ぐ役割
これで「品質」は良くなる？
CursorのRulesとLinterカスタムルールの導入で、
システムの保守性や、コードの可読性を向上させ、
サービスの土台部分の「品質」を良くすることができると考えます。
エンジニアが最初に着手しやすいのはこういった「内部」的な品質の向上です。
しかし、土台部分の「品質」が良ければ、
そのサービス全体の「品質」も良いと言ってよいのでしょうか？
「品質」を評価するために、他にも見るべきところがあるのではないでしょうか？
【その２】「品質が良い」サービス提供のために（外部品質）
より広い視野で、ユーザーの利用時の「品質」にはどういったものがあるかを考えます。
国際基準である「SQuaRE（システム及びソフトウェア製品の品質要求及び評価に関する国際規格 ISO/IEC 25000シリーズ）」には、品質モデルが以下の2つのカテゴリで定義されています。
1. 製品品質モデル（内部の品質に近い）
- 機能的合成
- 要件を満たしているか
- 性能効率性
- 互換性
- 使用性
- アクセシビリティ
- 運用操作性
- ユーザーエラー防止性
- 信頼性
- セキュリティ
- 保守性
- 移植性
2. 利用品質モデル
- 有効性
- ユーザーが正確かつ安全に、指定された目標を達成できるか
- 効率性
- 満足性
- リスク回避性
- 利用状況網羅性
「製品品質」の良さと「利用品質」の良さ
カテゴリとしては「製品品質モデル」と「利用品質モデル」と分けられていますが、
両者は密接に関わっています。
例えば、「製品品質モデル」の「使用性」が満たされた先に
「利用品質モデル」の「満足性」や「効率性」が結果としてついてくると考えられます。
「品質」評価の移り変わり
以前の品質管理の考え方は少し違っていました。
スマートフォンであれば処理速度やカメラの画素数など、
数値で捉えることができる機能的側面の品質が評価されていました。
しかし近年では先ほど「利用品質モデル」の中にあった「満足性」というような
より主観的側面の品質が追い求められるようになってきました。
「品質」が良いかどうかは、実際にユーザーとなる人間が使ってみて初めてわかるのです。
こういった近年の「品質」を良くする考え方を「人間中心設計」と呼びます。
人間中心設計
人間中心設計（HCD、Human Centered Design）とは、
"苦い経験"を少なく、"うれしい経験"をできるだけ豊かにしようとするアプローチのことです。
この考え方はハードウェアやソフトウェアはもちろん、どんなサービスであっても適用できます。
ユーザーの"うれしい経験"を増やすことで、
企業にも以下のようなメリットがあるとされています。
（国際規格ISO9241-210より）
- 理解しやすく使いやすくなることにより、ユーザーに対するサポート費用が削減される
- ブランドイメージを向上させる、競争力がつく
- サステナビリティにも貢献する
フロントエンドエンジニアができること
エンジニアをしていると、まずは目の前のコードについて考えがちですが、
AIエディタで高速にコードを生成できるようになった今、
もっと先のサービス全体の「品質」向上のことも考えるべきなのではないかと感じています。
もちろん「製品品質」を上げた先に
「利用品質」があることは間違い無いと思います。
AIエディタをうまく活用しつつ、コードの品質を保っていく方法は
エンジニアが模索するべき問題です。
特にフロントエンドエンジニアは
「製品品質」から「利用品質」を一貫して考えるのに最適なポジションなのでは無いでしょうか？
じゃあいきなりユーザーインタビューに乗り出してきます！ということが難しくても、
プランナーやデザイナーと「利用品質」を語ることはできると思います。
- その施策、そのデザインは触ってみて違和感がないか？
- ユーザーにとって満足性が高い機能なのか？
- ユーザーが安全に目標を達成するために、その実装でいいのか？
こういった関わり方ができれば、
本当の意味で担当案件を「自分ごと」にできるのだと感じています。
最後に
AIエディタを使いこなした先で、エンジニアはどう動いていけばいいか？
ということを考えることが増えた2025年だったので、
思っていたことを記事にさせていただきました。