ID:57458さん

# 概要 - AIを活用したE2Eテストとドキュメントの自動作成の改善取り組み ## チームの課題感 ### 結合テスト - 結合テストの多くを手動で実施しており、実施に時間がかかるため、開発サイクルの後半にまとめて確認する形になっていました。また、Playwrightテストを作成・メンテナンスできるメンバーも限られており、テストが属人化している課題もありました。 ### ドキュメント生成 - 事業部/ビジネスサイド向けの説明資料を作成していましたが、時間がかかることが悩みでした。Figmaや実画面などから画面キャプチャを貼り付け、変更点などのコメントを記載するなど単純な作業であるので改善方法を検討していました。 ## 取り組み ### 自然言語からPlaywrightテストの自動作成をする仕組みを構築 - AI活用の一環としてドキュメント整備を進めていて各画面操作が記述されていたので、これを元に各画面の単一操作をするテストを網羅的に作成 - 基本となるテストケースを作成 - 自然言語の操作名とテストケースをマッピングする資料を作成 上記を使うルールをCLAUDE.mdに記載することで、自然言語で依頼するとテストを実行し、同時にPlaywrightのテストファイルも作成する仕組みを実現しました。 この仕組みは画面操作のぶれが少なくなるため、単純にAIに依頼するよりもトークン消費を抑える工夫をしています。 また、別で実施していたアクセスログの調査の仕組みと連携することで、実際のユーザー利用頻度が高い操作パターンを分析して、E2Eテスト(リグレッションテスト)で不足しているケースのテストを自動で作成できるようにしました。 ### ドキュメント作成の仕組みを構築 上記で作成したテストファイルの中に画面スクショを撮る仕組みを入れることで、画面操作マニュアルをMarkdownファイルで作成できるようにしました。 またMarkdownファイルをロゴ・スタイルを適用した会社指定フォーマットのPDFファイルに変換するツールを作成することで、事業部/ビジネスサイドとの説明資料を自動で作成できるようになりました。 ## 結果 テストについては属人化を解消でき、誰でも簡単にテストを実施、作成できるようになりました。またテスト実施についても、見た目の確認など以外のテストは手動実施がほぼ0にまで減らすことができました。 さらにインシデント報告から手順を再現でき、調査時間の短縮につながりました。 ドキュメントについては元々案件により2〜3日やそれ以上かかっていた工数がほぼ0になり、チーム内外から高評価を得ています。(動く環境が必要なのでプロトタイプを作成するなどプロセス改善の検討が進んでいます。)

# 案件概要 - 開発サイクル高速化のプロセス改善 ## 期間：2025年10月 ～ 2026年5月（8ヶ月） ## 体制：開発チーム 9名 ## プロダクトの課題感 プロダクトとしてはPMFを探索している段階であり、顧客価値を検証するための仮説検証を高速に回すことが重要にも関わらず、実際には開発リードタイムが長く、仮説検証サイクルが十分に回せていない状況であった。 原因を分析すると単純なリソース不足ではなく、①技術判断が特定のメンバーに依存する、②開発プロセスが複雑化している、③技術的負債が蓄積しているといった開発基盤の問題が背景にあると考えた。 ## 開発プロセスの改善 まず開発サイクル高速化のための開発フローの単純化に取り組んだ。 当初は、状況・課題感の異なる別チームの独自プロセスを踏襲して デフォルトブランチが流動的。結果CIが不安定 複数バージョン並行開発によるマージ負荷 ブランチ運用の複雑化による属人化 改善活動の反映がなかなかされない といった課題が存在していた。 これらの問題に対してGitHub Flow / GitLab Flow / トランクベース開発といった一般的なブランチ戦略を整理・比較した。結果、運用のシンプルさ、リリース作業工数削減、CIの親和性からトランクベース開発を採用した。 ## モニタリング基盤整備 また開発サイクル高速化のためには障害や性能問題を早期に検知し、迅速に状況把握・対応ができることが重要であると考えた。しかし当初は ログが分散しており追跡が困難 エラーログの確認が手動で気づきが遅い Zabbixでの可視化はしていたがインフラチームが主体で開発チームでは活用できてなかった といった課題があり、開発・運用の両面で調査時間の増加や対応遅延につながりボトルネックになっていると判断した。 前プロジェクトにおいてGrafanaを用いたモニタリング基盤整備に取り組んだ経緯があり、その知見を活かすことで早期に同様以上の基盤を構築した。 Prometheus + Grafanaによる可視化基盤の構築 プロダクト利用状況ダッシュボード リリース確認ダッシュボード 性能負荷試験指標ダッシュボード エラーログのSlack通知によるリアルタイム検知 DBメトリクス及びトレースの可視化 これらを構築することで、システム状態の一元把握、障害の早期検知、調査時間の短縮などを実現でき、さらにチーム全体でデータを活用できる観測基盤を導入できた。 ## 結果 これらの結果により、その後対応した案件を1バージョン前倒しで機能をリリースできるなど開発リードタイムの短縮を実施できた。 またメンバーによる改善活動の活性化や観測結果からスケールアップなどの予測をしやすくなるなどの効果もあった。

# 案件概要 - レガシーシステムのフレームワーク大規模刷新 ## 期間：2023年10月 ～ 2025年9月（2年） ## 体制：開発チーム 5名 ## 担当工程：刷新方針検討、既存仕様調査、新システムアーキテクチャ設計、基本詳細設計、実装、コードレビュー、テスト（結合・性能）、リリース・移行計画策定・実行 ※この案件のうち性能テストについて記載します ## 背景 既存システムは200台以上のサーバによるマルチテナント構成であり、1サーバあたり(当時)最大100テナントを保有している 新システムではDBサーバは既存のまま(200台以上)利用して、アプリサーバのみを統合する構成となっていた この構成の妥当性と必要なサーバ台数の検証のため性能負荷試験を実施した 本番環境のログからいくつかのテナントをサンプリングして、平常時/ピーク時のRPS/スループットを分析して性能指標を計算・算出した 性能テストの結果をもとに本番環境のスペックやサーバ台数などを決める必要があった ## 課題 当初は従来実施していた性能テストと同様にDB1台でテストを実施しましたが、DB負荷が即座に100%に達し、アプリケーション側の性能評価が困難な状況となりました。原因は「本番環境では多数のサーバでDBアクセスが分散される」環境構成の差でしたが、この検証のために本番と同じ台数を用意することはコスト的に現実ではないと判断しました。 ## 検証方法改善と性能課題の是正 開発チーム/インフラチームと協力して、DBサーバを徐々に増やしつつコネクションプーラー(PgBouncer)などのサービスも試しながら性能評価が可能な構成を検証し、DBサーバ10台以上では分散効果が緩やかになることが判明しました。 そのためDBサーバ10台で想定のテストを実施でき、アプリ側の問題を発見することができました。Grafana(Prometheus)やPyroscopeを活用しながらボトルネックの特定し、改善もできました。 ## 結果 結果としてDBサーバ10台の構成で性能負荷試験を実施して、意味のある検証結果を立証でき、刷新前は20台くらい必要と思われていたアプリサーバの台数を6台の稼働で賄えると判断できインフラコストを約70%削減できました。この台数でもリリース後も問題なく動作しています。