ID:27905さん

## プロジェクト概要 全社プロダクトを横断しAI技術を活用した品質保証体制の強化と品質可視化を推進しております。 ## 役割・体制 ### 自身のポジションと役割 - 会社の強い要望でテックエクセレンスから新設される品質保証ユニットへ異動打診が来た為、メンバーとして参画しました。 - QAエンジニアとして、AIを活用した品質改善施策の企画・実施および品質保証プロセスの整備を担当しました。 - DevinやCursor、Claude Code、n8nを用いてテスト自動化や障害原因抽出の自動化をチーム共同で推進し、品質保証の効率化に寄与しました。 - 品質保証ユニットマネージャーと密に連携し、技術的負債に対する優先度付けと改善計画の策定を行いました。 ### チーム規模と構成 - QAエンジニア3名、SETエンジニア2名の計5名チームで、品質保証分野の横断的な業務を推進しております。 - チームはプロジェクト横断的に連携し、SlackやJIRA、Notionを活用して情報共有とタスク管理を行いました。 ## 背景・課題 - 品質保証ユニットにおいて、全社複数自社プロダクトの品質を横断的に監視・改善する必要がありました。 - 技術的負債が多岐にわたり、品質改善の優先順位設定や効果的な対応策の策定が大きな課題となっていました。 - 従来の手動テスト中心の運用ではカバーしきれない領域が多く、品質の可視化と継続的改善の仕組みが不足していました。 ## 実際の取り組み メンバーと協働したこと - Devinを活用し、コードベースから仕様書の自動生成と自動更新を実現しました。 - Slack連携を通じて、障害原因抽出結果の自動投稿やNewRelicのレスポンス低下検知を実施し、リアルタイムな品質状態の把握を可能にしました。 - CorsorとPlaywrightを用いたe2eテスト自動化を行っております。私の担当箇所は決済を中心にハッピーパスと異常系網羅を行っています。 自身で完結したこと - AIを通してJIRAやNotionで課題管理や改善策のドキュメント化を体系的に行い、n8nで一部タスクの自動化を試みました。 - 障害管理において問題解決が未記載のチケットを定期抽出し、対応漏れを防止するフローを構築しました。 - 障害管理において再発防止策をAIによって作成し、障害起因のチームがレビューを行う方向でフロー改善を行っております。 ### 開発環境 - Devinを活用し、コードベースから仕様書の自動生成と自動更新を実現しました。 - Claude Codeによるコードレビューやテスト設計レビューを導入し、AIによる品質チェック体制を構築しました。 - Slack連携を通じて、障害原因抽出結果の自動投稿やNewRelicのレスポンス低下検知を実施し、リアルタイムな品質状態の把握を可能にしました。 - AIを通してJIRAやNotionで課題管理や改善策のドキュメント化を体系的に行い、n8nで一部タスクの自動化を試みました。 ### 設計・改善内容 - AIを活用したE2Eテスト自動化の構築を模索し、Claude CodeやCorsorによるPlaywrightでのテスト自動化に推進中です。 - 別個でテストスキルに依存しない手動テストの軽量化を推進し、Devinに仕様とコードを読み込ませた状態でAIによるテスト自動化を協働で構築しております。 - 新機能の要件と既存機能の整合性や矛盾をAIによりチェックするプロセスを導入し、品質担保の高度化を提案中です。 - 機能要件や受入基準が未記載、不足しているチケットをAIにより洗い出し、通知するシステムを構築中です。 ### その他アピールポイント - 技術的負債の多い環境下で品質保証ユニットマネージャーと協力し、優先度をつけて改善施策を展開し、成果物をENグループに共有する方針を立てることで継続的な品質改善のループを確立しました。 ## 成果・価値 - AIを活用した品質の可視化に成功し、NewRelicのレスポンス低下検知から速度改善チケットの起票を促進しました。 - 障害管理における未更新や記載不足などが10%減少し、品質管理体制の強化に寄与しました。 - 自動生成される仕様書により、巨大なシステムの仕様把握が効率化され、ドキュメントの鮮度維持が実現しました。

## プロジェクト概要 テックエクセレンスチームリーダーとして品質と非機能要件の改善を推進し、システム性能向上とQAコスト削減を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - QA担当兼チームリーダーとして、Ruby on RailsやGemのアップデート計画立案から実行まで一貫して旗振りを行い、非機能要件定義の作成と速度改善の推進を担当しました。 - 品質改善の根幹となる定義作成と全社浸透を主導し、AIを活用した自然言語によるテスト観点作成やコードレビュー補助の導入を推奨しました。 - スクラムマスターとしてチームのアジャイル開発促進や、エンジニアの業務スコープと改善ポイントの明確化をリードしました。 ### チーム規模と構成 - エンジニア5名で構成される小規模なテックエクセレンスチームで、高い技術志向のメンバーが集まり、密なコミュニケーションを重視する体制でした。 ## 背景・課題 - システムイネーブリングからテックエクセレンスチームの新設に伴い、既存の品質管理や非機能要件の体制強化が急務でした。 - テスト実施におけるボトルネックやバグ発生が頻発し、品質維持とリリース速度の両立に課題がありました。 - AIツール未活用時はテスト観点作成やコードレビューに時間がかかり、QA外部委託費用が高額にのぼっていました。 ## 実際の取り組み ### 開発環境 - JIRAとNotionを中心にプロジェクト管理とドキュメント作成を行い、スクラム開発を推進しました。 - AIツールであるDevinを活用し、自然言語によるテスト観点作成やコードレビューの補助、現仕様の可視化を実現しました。 ### 設計・改善内容 - Ruby on RailsおよびGemのアップデート計画を策定し、チーム全体の合意形成と実行管理を行い、クエリ実行時間を約30%削減しました。 - Devinを用いたAI支援によりテスト時間の短縮を実現し、テスト観点の作成スピードとQAのリードタイムを大幅に改善しました。 - バックログリファイメントで課題の解像度を上げ、デイリースクラムで課題や障害を自由に話せる環境づくりを行い、暗黙知の削減と仕様理解の向上に努めました。 - 品質の根幹となる定義を明確化し、Notion等でドキュメント化してチーム全体に浸透させ、品質改善を組織文化として定着させました。 ### その他アピールポイント - AIツール活用によりQA外部委託費用およびQA用ツール費用を年間約600万円削減し、内製化によるコスト効率化を実現しました。 - AI活用ノウハウをドキュメント化し、属人化を防ぎつつ継続的な運用と改善を推進しています。 ## 成果・価値 - クエリ実行時間を約30%短縮し、非機能性能の大幅な改善に成功しました。 - QA外部委託費用が年間約610万円から12万円程度となり、内製化により大幅なコスト削減を達成しました。 - テスト観点作成のスピード向上とQAリードタイム短縮を実現し、開発全体の品質向上とリリースサイクルの高速化に寄与しました。

## プロジェクト概要 システムイネーブリングチームでスクラム開発技法を導入し、品質指標の整備と速度改善を推進しました。 ## 役割・体制 ### 自身のポジションと役割 - QA担当として、RailsおよびRubyのアップデート計画策定とテスト設計、テスト実行を主導し、各メンバーでテスト回りを完結するように教育を行いました。 - スクラムマスターとしてスクラムイベントの運営やメンバーへのスクラム教育を実施し、チームの開発手法浸透を支援しました。 - 品質保証の観点から障害分布図の作成と品質指標の策定により、品質改善の基盤構築に貢献しました。 ### チーム規模と構成 - エンジニア5名のみの小規模チームで、スクラム未導入のチームにスクラム開発技法を浸透させる役割を担いました。 - QA担当としてスクラム運営からテスト計画まで一貫して担当する体制でした。 ## 背景・課題 - 従来スクラム開発技法が用いられていないチームへ異動し、開発の基本に立ち返る必要がありました。 - RailsやRubyのバージョンアップに伴うテスト観点の明確化と品質指標の整備が急務でした。 - スクラムの理解不足によりチーム内での開発手法浸透に時間がかかり、生産性向上の阻害要因となっていました。 ## 実際の取り組み ### 開発環境 - アジャイル開発手法を採用し、スクラムマスターとしてイベントの運営とマイルストーン設置を推進しました。 - NotionやJIRAを利用し、テスト計画や品質指標の管理、障害分布図の作成を行い、品質保証活動を体系化しました。 ### 設計・改善内容 - スクラムイベント（デイリースクラム、スプリントプランニング、レビュー、レトロスペクティブ）について具体的な説明資料や共有例を作成し、メンバー教育を実施しました。 - スコープ管理の重要性を強調し、範囲の明確化と調整をチーム内で徹底する仕組みを構築しました。 - バージョンアップに伴うテスト工程を「調査→設計→テストを通しながら実装」にフェーズ変更し、テストと実装の連携を強化しました。 - 障害の発生時期、影響範囲、規模、基点を可視化した障害分布図を作成し、品質強化のための指標を策定しました。 ### その他アピールポイント - チームの自主性を尊重し、スクラム技法の浸透により自発的な改善提案や情報共有が活発化しました。 - 品質保証活動の標準化により、障害低減と開発速度の両立を実現しました。 ## 成果・価値 - スクラム技法の浸透によりチームメンバー間のコミュニケーションが活性化し、些細な事項も共有される文化が醸成されました。 - バージョンアップ作業における開発プロセスが「調査→設計→テストを通しながら実装」へと変化し、品質向上とリリース速度の両方を実現しました。 - 品質指標の整備と障害分布図活用により、障害発生件数の低減と品質改善の効果が表れ、手戻り等が無くなった結果、生産性が向上しました。

## プロジェクト概要 OMO機能開発チームにてECのオフライン/オンライン連携に関わる仕様調査からテストまでを担当し、遅延の解消と品質担保を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - QAエンジニアとして、スマレジ連携や楽天ショップとecforceの連携における仕様調査、要件定義のチェッキング、テスト計画・設計・実行を一貫して担当しました。 - スクラムマスターとして、チームのアジャイル開発推進とプロダクトバックログリファイメントの進行支援を行い、メンバーの機能理解度向上に貢献しました。 ### チーム規模と構成 - エンジニア3名、PdM1名、QAエンジニア2名の合計6名体制で、UIチームは別途1名が参加している環境でした。 - スクラムチームとして、2週間スプリントを繰り返しながら連携機能の開発とテストを進めました。 ## 背景・課題 - ECプラットフォームecforceのオフライン領域/オンライン拡大のため、スマレジや楽天ショップとの連携機能開発が必要でした。 - 仕様調査およびecforceへの繋ぎ込み設計に多大な時間を要し、要件定義と詳細設計の遅延がプロジェクト全体の進行に影響を及ぼしていました。 - 複雑な連携仕様により、要件の不明瞭さが品質リスクを増大させており、効率的な仕様の把握とテスト設計が求められていました。 ## 実際の取り組み ### 開発環境 - アジャイル開発手法を採用し、Notionに調査内容を詳細かつ分かりやすくドキュメント化し、JIRAでタスク管理を実施しました。 - スプレッドシートを活用しテストケース作成や進捗管理を行い、チーム間の情報共有と品質管理を効率化しました。 ### 設計・改善内容 - 仕様調査内容を三行に要約し、簡潔で理解しやすい文章を作成することで、チームメンバーの機能理解度を向上させました。 - プロダクトバックログリファイメントを定期的に実施し、メンバー全員の機能に対する解像度を底上げし、MVPに不要な機能を見極める判断材料および機会を提供しました。 - テスト設計においては連携部分の複雑性を考慮し、多様なケースを網羅したテストケースを作成、品質保証に注力しました。 ### その他アピールポイント - スクラムマスターとしてチームの課題抽出と改善策の共有を推進し、円滑なコミュニケーションと効率的なスプリント運営を実現しました。 ## 成果・価値 - 仕様調査と設計の遅延により予定されていた約2か月の遅延を解消し、プロジェクトをオンスケジュールでリリースに導きました。 - 要件定義の精度向上とテスト設計の充実により、リリース後の品質問題を抑制し、安定したサービス連携を実現しました。 - チームの開発効率と品質意識の向上に寄与し、継続的な改善文化の醸成に貢献しました。

## プロジェクト概要 スクラム導入支援のためスクラムマスターチームを立ち上げ、5チームの自己組織化を推進しました。 ## 役割・体制 ### 自身のポジションと役割 - スクラムマスターリーダーとして、外部スクラムマスターコーチの指導を受け、得た知識を5チームへ還元し、スクラム導入の啓蒙とサポート活動を主導しました。 - 直接1チームのスクラムマスターを担当し、スクラムの実践とチームの自己組織化を促進しました。 - 品質保証担当として、受け入れテスト基準のフロー変更やQAとエンジニアの連携強化に取り組み、バグや障害分析ルールの策定を推進しました。 ### チーム規模と構成 - スクラムマスターチームは5名で構成され、対象となる5つの開発チームに対してスクラム導入支援を展開しました。 - 各開発チームは約5〜8名で、エンジニア、QA、プロダクトオーナーなど複数職種で構成されていました。 - QAがスクラムマスターの役目を担う方向で調整しました。 ## 背景・課題 - スクラム導入初期であり、組織全体のスクラムに対する理解が乏しく、従来のウォーターフォール開発との違いが明確でなかったため、自己組織化推進に大きな障壁がありました。 - スクラムの価値や役割の認識不足により、チームメンバーの主体的な行動が促されず、スクラム体制の定着が困難な状況でした。 - 品質保証に関するプロセスも成熟しておらず、受け入れテスト基準の不明確さやバグ・障害の分析体制の未整備が課題となっていました。 ## 実際の取り組み ### 開発環境 - プロジェクト管理ツールとしてJIRAを活用し、バグ・障害のトラッキングや分析データの蓄積に加え、スプレッドシートと連携する形で傾向分析を実施しました。 - ドキュメント管理はConfluenceと後年はNotionへ移行活用し、スクラムに関する知識共有や啓蒙資料の整備を行いました。 ### 設計・改善内容 - スクラムを自己組織化を促進するサポート活動と位置づけ、5チームに対し継続的にスクラム知識やアジャイルプラクティスを教育・還元しました。 - 受け入れテスト基準をプロダクトオーナー側で選定するフローに改め、要件定義から基本仕様への落とし込みにはエンジニアとQAを巻き込む体制を徹底しました。 - QA実施中のバグやリリース後の障害発生に対し、チーム内での分析ルールを策定し、JIRAとスプレッドシートの連携によるデータ蓄積と傾向の可視化を推進しました。 ### その他アピールポイント - スクラムマスターリーダーとして、チーム間の知見共有や課題解決のためのコミュニケーション促進に注力し、組織全体のスクラム成熟度向上に貢献しました。 ## 成果・価値 - スクラム導入により小さく作って継続的にリリースする文化が醸成され、チームの自己組織化が進んだことで開発の柔軟性とスピードが向上しました。 - 品質保証プロセスの整備とデータ分析基盤の構築により、バグや障害の早期発見・対処が可能となり、リリース品質の安定化に寄与しました。 - スクラム導入後、チーム間の連携強化による効率的な問題解決が実現しました。

## プロジェクト概要 品質基準の策定と障害対応戦略の構築により、テストプロセスの可視化と改善を推進したQAチーム主導の品質向上プロジェクト。 ## 役割・体制 ### 自身のポジションと役割 - QAエンジニアとして、機能に対する品質レベルの定義やリリース可否判断基準の作成を担当した。 - 障害の予測・可視化と障害対応リードタイム短縮の施策立案を行い、スクラム開発におけるドキュメント作成基準の設定とスタートアップ運用を推進した。 - ノーコードQAに対するサイエンス基礎学習やコード学習の年単位教育制度を確立し、社内の品質向上意識の醸成に寄与した。 ### チーム規模と構成 - QAエンジニア6名で構成されたチームにて、スクラム手法の取り入れと品質改善施策の実施に注力した。 ## 背景・課題 - 機能リリースの品質基準が不明確であったため、リリース可否の判断が属人的になり、品質担保にムラがあった。 - 開発プロセス中の障害発生箇所が把握されておらず、障害対応にかかる時間が長期化していた。 - チーム間でテストの責任範囲に対する認識差があり、QAチームへの依存が強く、他部門の品質意識が低かった。 - QAエンジニア側もサイエンス基礎学習が不十分であり、技術的な品質向上に向けた教育体制が未整備だった。 ## 実際の取り組み ### 開発環境 - スプレッドシート、JIRA、Confluenceを活用し、品質基準や障害対応に関するドキュメント管理とタスク管理を行った。 - スクラム開発のフレームワークを参考に、ドキュメント作成基準やQA業務の標準化を推進した。 ### 設計・改善内容 - 品質レベルの明確化とリリース判断基準の作成により、品質保証の透明性を高めた。 - 開発における障害となりうる要素を洗い出し、テストフェーズも含めた障害分析を行い、対応リードタイム短縮のための具体的な施策を策定した。 - 障害対応に関係する各部署の対応時間を計測し、技術的負債の返却タイミングと理由を戦略的に設定。 - ノーコードQAに対するサイエンス基礎学習やコード学習を促進する年単位の教育制度を会社予算と業務時間を活用して確立し、教育体制の強化を実現した。 - テストの責任をチーム全体で共有する文化を浸透させ、QAへの依存を減らすための意識改革を行った。 ### その他アピールポイント - 障害対応戦略の策定により、プロジェクト全体の品質管理体制が強化され、安定したサービス運用に寄与した。 - 教育制度の確立により、QAエンジニアのスキルアップと社内の品質文化醸成に大きく貢献した。 ## 成果・価値 - エンジニア全体でテスト作成と実施が当たり前となり、品質に対する意識が全社的に向上した。 - QAエンジニアは会社負担でサイエンス基礎やコード基礎を学べる環境が整備され、専門性の高い品質管理を実現した。 - 障害対応リードタイムの短縮と品質基準の明確化により、サービスの安定稼働と顧客満足度向上に寄与した。

## プロジェクト概要 品質保証チームの立ち上げとRedmineからJIRAへの移行、QAプロセス整備を主導し、組織のテスト品質向上を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - QAリードとして、RedmineからJIRAへの完全移行を単独で完遂し、バグトラッキングおよびドキュメント管理の運用ルールを策定しました。 - テスト設計から実施、障害分析までのQAプロセス整備とテストエンジニアの教育・マネジメント（1on1、目標設定、指導）を担当しました。 - JIRAとスプレッドシートの連携による障害分析基盤の構築により、品質状態の可視化を推進しました。 ### チーム規模と構成 - QAエンジニア2名（リーダーレベル2名含む）とテストエンジニア3名の計5名体制で、テスト品質向上を目指しました。 - QAチーム発足初期からの継続的な体制強化を図り、段階的にメンバーのスキルアップを促進しました。 ## 背景・課題 - 入社直後に2人でQAチームを立ち上げたものの、テストエンジニアはテストの体系的な知識が不足しており、スプレッドシートの使用方法も統一されていませんでした。 - RedmineとJIRAが並行稼働しており、情報が分散していたため、バグ起票はチャット連絡のみで管理が不十分でした。 - 障害分析が未実施で、品質の状態把握が困難だったため、QA体制の強化とプロセス整備が急務でした。 ## 実際の取り組み ### 開発環境 - バグトラッキングにはRedmineからJIRAへ移行し、Confluenceを用いたドキュメント管理および運用ルール策定を進めました。 - スプレッドシートとの連携機能を活用し、障害分析や品質管理の可視化を実現しました。 - 運用ツールの統合により、QAチームの情報共有とコミュニケーション基盤を強化しました。 ### 設計・改善内容 - RedmineからJIRAへの完全移行を単独で遂行し、移行に伴う委託費用750万円～1200万円の削減に貢献しました。 - JIRAにおけるバグトラッキング運用ルールを策定し、ストーリーチケットやバグチケットの適切なタイミングでの発行を全社に指導しました。 - Confluenceの運用ルールを整備し、仕様書やルールの透明化を図りました。 - テストフェイズからリリース後の障害分析をJIRAとスプレッドシート連携で実施し、品質状態を目視で把握可能にしました。 - テスト技法とスプレッドシートのテンプレートを作成し、テストエンジニアの教育・自立支援を推進しました。 ### その他アピールポイント - マネジメント業務として1on1面談や目標設定を行い、チームメンバーの成長とモチベーション維持に努めました。 - 要件定義のチェッキングも担当し、品質の上流工程からの確保に貢献しました。 ## 成果・価値 - テストエンジニアのスキル向上により、テスト設計から実施までを一気通貫で自立して遂行できる体制を構築しました。 - チーム内の1名がPdMへ転籍するなど、キャリアパスの多様化と人材育成に成功しました。 - テスト報告の明確化により修正漏れを防止し、品質向上とリリースの安定化に寄与しました。 - RedmineからJIRAへの移行に伴う運用効率化と移行委託費用削減により、最大1200万円のコスト削減を実現しました。

## プロジェクト概要 大手モバイルゲーム開発にてQA・テストリーダーとして、ガチャやキャラクター、レイドの検証設計から障害防止までの品質管理を推進しました。 ## 役割・体制 ### 自身のポジションと役割 - QAエンジニアとして機能テストや他端末検証を担当し、テスト設計やバグ分析、仕様書のフレームワーク策定を行いました。 - テストメンバーの教育やテスト人員計画に参画し、ガチャや季節限定キャラの仕様整理をリードしました。 - 再発防止のための障害分析と仕組み作りに注力し、障害発生リスクの低減に貢献しました。 ### チーム規模と構成 - 約4名規模のテストチームに出向し、開発チームと密接に連携しながらQA業務を遂行しました。 ## 背景・課題 - ガチャの仕様書が再利用されておらず、季節限定キャラクターの管理が不明瞭であったため、仕様の把握と共有が困難でした。 - キャラクターのスキル強度が開発内で明確に把握されておらず、バランス調整に支障がありました。 - レイドのマルチプレイ仕様が不透明であり、テスト計画やスケジュールに遅延リスクが存在しました。 ## 実際の取り組み ### 開発環境 - AndroidおよびiOSプラットフォーム向けのモバイルゲームに対し、ウォーターフォール開発手法でテスト設計を実施しました。 - ガチャ検証やスキル整合性確認、レイドテストの要件整理を中心にテストフェーズを支援しました。 ### 設計・改善内容 - ガチャ仕様書のテンプレートを作成し、ガチャキャラクターに属性を付与することでプランナーのリードタイムを大幅に削減しました。 - キャラクタースキルに点数を付与し、強さの可視化を実現して「ぶっ壊れ」キャラクターの特定を容易にしました。 - 他社のレイド仕様を参考にし、プランナーと協力してマルチプレイ仕様書を作成し、仕様と検証の明確化を図りました。 ### その他アピールポイント - 障害発生の損失が開発・QA間のコミュニケーションコストよりも大きいという判断のもと、障害防止に注力し、コミュニケーションを重視しながら品質向上を実現しました。 - テストフェイズからリリース後にかけての障害分析を継続的に行い、再発防止策の提案と仕組み化を推進しました。 ## 成果・価値 - ガチャ作成やキャラクター作成、テストにかかる時間をそれぞれ約30%削減しました。 - レイドのスケジュールをオンスケジュールに戻し、遅延リスクを大幅に低減しました。 - 品質向上によりユーザーからの不具合報告が減少し、開発チームとの信頼関係強化に寄与しました。