グッドビーのフロントエンドクリエイション部が、社内のフロントエンドに対する取り組みをシリーズでお届けしています。第4弾となる今回のテーマは「開発環境とプロセスで品質をどう担保するか」です。
前回は技術選定の考え方と、AI支援との親和性についてお伝えしました。どんなフレームワークやレンダリング方式を選んでも、日々の開発の積み重ねがなければ、ユーザーに届く品質は安定しません。本記事では、グッドビーがプロセスと開発環境（ツールチェーン）の両面から品質に向き合っていることをご紹介します。

はじめに―フロントエンドの責務が増えたいま、「品質」がより重要になっている

第1弾でも触れたとおり、フロントエンドはもはや「ページを表示する」だけの領域ではありません。状態管理、非同期処理、フォームや認証、パフォーマンス最適化、アクセシビリティまで、かつてバックエンドやインフラに寄っていた関心事の一部が、ブラウザ側に移ってきています。
責務が増え、実装の複雑さが上がるほど、バグや仕様の食い違いがユーザー体験や事業指標に与える影響も大きくなります。表示の遅延や操作性の悪さが離脱やコンバージョン低下につながることは、各種調査でも繰り返し示されてきました。
だからこそグッドビーでは、「リリース後に慌てない」「チームで同じ基準を保つ」ために、開発プロセスと開発環境の整備に継続的に投資しています。

プロセス面―振り返りとKPTでProblemに向き合う

ツールだけ入れても、運用されなければ形骸化します。グッドビーでは振り返りを通じて、現場で起きている課題を可視化し、対策に落とし込んでいます。
具体的にはKPT（Keep/Problem/Try）の表を用い、うまくいっていること（Keep）、困っていること（Problem）、次に試すこと（Try）を整理します。表を常に最新の状態に近づけておくことで、「誰が感じている不満か」に閉じず、「チームやプロジェクト全体のProblem」として共有し、Tryに繋げやすくしています。
品質の話だけに限りませんが、たとえば「レビューで見落としが多い」「本番と開発環境で挙動が違う」「テストが後回しになる」といったProblemが挙がれば、Lintのルール見直し、E2Eの対象範囲、CIでのチェックタイミングなど、開発環境側の改善タスクに具体化できます。プロセスと環境を切り離さず、同じテーブルで扱うことが、継続的改善につながると考えています。

開発環境面―ツールで「早い段階で」「チーム全体で」品質を揃える

グッドビーでは、次のようなツールを組み合わせ、コンパイル時・コミット前・CI・手動実行など複数のレイヤーで品質を担保しています。採用の考え方は、「業界で実績があり、チームで再現しやすいこと」「お客様のプロダクトを長く保守できること」を重視しています。

①TypeScript―静的型付けでバグを「実行する前」に検知する
TypeScriptはJavaScriptに静的型を足した言語で、Microsoftが開発しオープンソースとして保守されています。型情報により、未定義プロパティへのアクセス、引数の取り違え、nullまわりの漏れなどを、エディタやビルドの段階で検出できます。実行して初めて分かる不具合を減らすことは、フロントエンドの複雑化が進むほど効果が大きくなります。
第3弾で述べたとおり、型のあるコードはAIによる補完や生成とも相性が良く、人とツールの両方で読みやすいコードベースを維持しやすい点も、採用理由の一つです。

②ESLint―コードの質と安全なパターンをルールで共有する
ESLintはJavaScript/TypeScript向けの代表的なリンターです。構文エラーに近い問題から、チームで決めたスタイル、セキュリティやアクセシビリティに関するベストプラクティスまで、ルールとしてコードベース全体に適用できます。
「暗黙の了解」に頼らず、レビュー前に機械が同じ基準でチェックすることで、指摘のばらつきを減らし、レビュアーは設計や仕様の議論により時間を使えるようになります。

③Prettier―フォーマットを自動化し、議論のノイズを減らす
Prettierはコードフォーマッタで、インデントや改行、クォートの統一などを自動で整えます。フォーマットの好みでPRが細切れになったり、レビューが表層的な指摘で埋まったりするのを防ぎます。
ESLinzが「何をしてはいけないか・どう書くべきか」の一部を担うのに対し、Prettierは見た目の一貫性を担当する、という役割分担が一般的です。グッドビーでも、この組み合わせで読みやすく、差分が追いやすいコードを目指しています。

④Jest/Vitest―単体テストでロジックと部品の振る舞いを検証する
JestはMeta（旧Facebook）が公開しているテストランナー兼アサーションライブラリで、フロントエンドの単体テストで広く使われています。VitestはViteエコシステムに馴染む高速なテストランナーで、API互換を意識しており、プロジェクトのビルド構成に応じて使い分ける選択肢もあります。
コンポーネントやユーティリティ、カスタムフックなど、小さな単位で期待どおり動くかを自動検証することで、リファクタリングや機能追加時の回帰バグを早く発見できます。第3弾で触れたテストコードの自動生成とも組み合わせやすく、継続的にカバレッジと信頼性を高めていく土台になります。

⑤Playwright―E2Eテストで「ユーザー操作に近い」経路を検証する
PlaywrightはMicrosoftが支援するブラウザ自動化・E2Eテスト向けのフレームワークで、Chromium・Firefox・WebKitなど複数エンジンでの検証がしやすいことが特徴です。
単体テストが部品の正しさを保証するのに対し、E2Eは画面遷移、API連携、認証まわりなど、実際の利用に近い経路で動作を確認します。リリース前の安心感だけでなく、「重要なユーザージャーニーを誰でも再実行できる」という生きた仕様書としての価値も大きいと考えています。

品質担保へのAIの活用

開発の効率化だけでなく、品質担保のプロセスにもAIを積極的に活用しています。コードレビュー支援、Lintエラーの修正案の提案、テストケースの洗い出し、ドキュメント整備など、人の注意力を設計判断や難しいバグの深掘りに集中させるための補助として位置づけています。
AIは万能ではありませんが、TypeScriptやLint、テストと組み合わせることで、「機械が拾えるものは機械に」「人は人にしかできない判断に」という分担がしやすくなります。第3弾でお伝えした「コンポーネント設計との親和性」とあわせ、お客様に届く品質の安定に寄与していると感じています。

おわりに―プロセスと環境の両輪で、持続可能な品質を

フロントエンドの高度化に伴い、品質担保は単発のヒーロー頼みではなく、チームで再現できる仕組みとして設計することが重要です。グッドビーでは、KPTを用いた振り返りでProblemに向き合い、TypeScript・ESLint・Prettier・Jest/Vitest・Playwrightといったツールで開発環境を整え、AIも活用しながら、早い段階での検知と、チーム全体での基準の統一を進めています。
技術選定（第3弾）と開発環境・プロセスは表裏一体です。お客様のプロダクトが長く価値を生み続けるよう、引き続き現場から改善を重ねていきます。