チーム内連携強化のためのGQMフレームワークに基づいた不具合情報可視化の取り組み

チーム内連携強化のためのGQMフレームワークに 基づいた不具合情報可視化の取り組み 株式会社ZENKIGEN 横田雅和 2025.03.28 © ZENKIGEN Inc.

目次 01 自己紹介 02 本発表の概要 03 発生していた問題とその背景 04 問題点に対する課題と対策 05 対策の有効性確認 06 発表まとめ © ZENKIGEN Inc.

01 自己紹介 02 本発表の概要 03 発生していた問題とその背景 04 問題点に対する課題と対策 05 対策の有効性確認 06 発表まとめ © ZENKIGEN Inc.

自己紹介 横田 雅和 株式会社ZENKIGEN harutaka事業部 兼 新規事業部 QAエンジニア 2024年2月入社 開発チームに所属するインプロセスQAエンジニア （開発体制） ● SaaS系サービス開発 ● PdM/デザイナー/ソフトウェアエンジニア QAエンジニア（私） ● ウォーターフォール開発に近い QAゼミ一期生 1 © ZENKIGEN Inc.

ZENKIGEN提供サービス：harutaka 採用DXサービス 採用工程をデジタル化し、 高効率・高品質の採用を実現する オンライン上での選考を可能にする 「エントリー動画」と「ライブ面接」を基本機能として提供しています。 面接から採用活動をデジタル化することで、 これまでの採用活動と比較し、 企業・応募者双方の時間コストの削減や 採用活動の効率化・高度化を図ることができます。 https://harutaka.jp 2 © ZENKIGEN Inc.

• https://harutaka.jp

ZENKIGEN提供サービス：コレドウ コレドウはAIによって効果的な目標を効率的に作るツールです。 目標達成と個人の成長をサポートします。 目標設定サポート リマインド 進捗管理 本文10px/行間1.0が入ります。本文 10px/行間1.0が入ります。本文 記載した目標について、 10px/行間1.0が入ります。本文 グレードやメンバーのキャリア目標や、チーム内での 10px/行間1.0が入ります。 役割の中で適切かを判定し、かつSMARTな形に書き 本文10px/行間1.0が入ります。本文 10px/行間1.0が入ります。本文 SMARTな目標に対して適切なタイミングで 10px/行間1.0が入ります。本文 進捗確認をPushで通知(Slack,メール等) 10px/行間1.0が入ります。 目標を定期的にリマインドすることで 本文10px/行間1.0が入ります。本文 10px/行間1.0が入ります。本文 通知に対して回答するだけで進捗管理が出来るよう 10px/行間1.0が入ります。本文 になり、マネージャーがマイクロマネジメントをする身 体的・心理的労力を排除します 10px/行間1.0が入ります。 換えます。 達成をサポートします。 注釈8px/行間1.0が入ります。注釈8px/行間 1.0が入ります。 注釈8px/行間1.0が入ります。注釈8px/行間 1.0が入ります。 目標の達成度合いはどうなっているのか？を月次で レポーティングします。 注釈8px/行間1.0が入ります。注釈8px/行間 1.0が入ります。 3 © ZENKIGEN Inc.

01 自己紹介 02 本発表の概要 03 発生していた問題とその背景 04 問題点に対する課題と対策 05 対策の有効性確認 06 発表まとめ © ZENKIGEN Inc.

みなさんへ質問 ● 不具合登録後、その情報は活用出来ていますか？ ● こんな風に活用したい！等の想いはありますか？ 4 © ZENKIGEN Inc.

みなさんへ質問 本発表では、登録された不具合情報を分析・共有することで、 チームコミュニケーションを活性化する具体的な事例を紹介します。 ※ 不具合情報：テスト時に登録を行った不具合チケットから得られる情報 5 © ZENKIGEN Inc.

本発表の概要 ● 不具合情報を可視化した取り組み ● チーム内でのコミュニケーション強化を目指した ● 有効性確認のため、アンケートを実施 6 © ZENKIGEN Inc.

01 自己紹介 02 本発表の概要 03 発生していた問題とその背景 04 問題点に対する課題と対策 05 対策の有効性確認 06 発表まとめ © ZENKIGEN Inc.

発生していた問題とその背景 【発生していた問題】 チームで不具合情報に基づくコミュニケーションが 出来ておらず共通の認識を持てていなかった 背景 （例）優先度が高い不具合は何か/原因は何か/スケジュール内で修正完了出来るのか 不具合情報は、起票者および 修正対応者のみが把握 他のチームメンバーには 情報が十分に共有されて いなかった （不具合チケットには修正内容/修 正確認内容をコメントに 記載されているのみ） ７ © ZENKIGEN Inc.

不具合チケットのイメージ ログイン出来ない 手順 ・ログインを実行する 現動作 ・ログインが失敗する 期待値 ・ログインが成功できること 【コメント欄】 エンジニア バリデーションチェックを誤ってい たので修正 各不具合チケットを開かないと 改修箇所や修正確認完了したことが確認出来ない QAエンジニア 修正確認完了しました 8 © ZENKIGEN Inc.

不具合チケット対応の流れ 起票者 ①テスト 実施 修正者 ⑦不具合 修正 内容記載 ⑧不具合修正 内容確認 ⑥不具合 修正内容 ②不具合 事象 ③不具合 起票 ④不具合チケット 一覧 ⑤不具合 内容 確認&修正 9 © ZENKIGEN Inc.

不具合チケット対応の流れ 起票者 ①テスト 実施 ②不具合 事象 ③不具合 起票 修正者 ⑦不具合 修正 内容記載 ⑧不具合修正 内容確認 本来は起票者/修正者以外でも不具合チケットの情報が 確認出来る状態にしておきたい ④不具合チケット 一覧 ⑥不具合 修正内容 ⑤不具合 内容 確認&修正 10 © ZENKIGEN Inc.

発生していた問題を2点に整理 【発生していた問題】 チームで不具合情報に基づくコミュニケーションが 出来ておらず共通の認識を持てていなかった 問題点1 議論の目的が定まっておらず、 不具合チケットから必要な情報が抽出出来ていなかった 問題点2 不具合情報に基づく進捗の共有や改善のアイデア出しが出来ていなかった 11 © ZENKIGEN Inc.

01 自己紹介 02 本発表の概要 03 発生していた問題とその背景 04 問題点に対する課題と対策 05 対策の有効性確認 06 発表まとめ © ZENKIGEN Inc.

問題点から最初に取り組んだこと 【発生していた問題】 チームで不具合情報に基づくコミュニケーションが 出来ておらず共通の認識を持てていなかった 問題点① 議論の目的が定まっておらず、 この問題点が起きている要因は何か 不具合チケットから必要な情報が抽出出来ていなかった 問題点② 不具合情報に基づく進捗の共有や改善のアイデア出しが出来ていなかった 12 © ZENKIGEN Inc.

問題点から最初に取り組んだこと 問題点1 議論の目的が定まっておらず、 不具合チケットから必要な情報が抽出出来ていなかった 問題点1が起きている要因 ● 不具合チケットから収集すべき不具合指標が定まっていない ● 不具合指標を収集する方法が決まっていない ○ 何のデータをいつ誰ががどうやってデータを登録するのか不明 （※）不具合指標：不具合情報から傾向等を分析するために抽出するデータ項目 13 © ZENKIGEN Inc.

問題点から最初に取り組んだこと 問題点2 不具合情報に基づく進捗の共有や 改善のアイデア出しが出来ていなかった 問題点2が起きている要因 ● 不具合情報が可視化出来ていない ○ 全体としてどうなっているのかが見えない ○ コミュニケーションが出来ない 14 © ZENKIGEN Inc.

問題点1に対する課題 問題点1 議論の目的が定まっておらず、 不具合チケットから必要な情報が抽出出来ていなかった 課題① 不具合チケットから収集 すべき不具合指標を定義 課題② 不具合指標を収集 するルールを決める 課題③ 不具合指標に紐づく データを入力する 15 © ZENKIGEN Inc.

問題点1に対する課題における対策 課題① 不具合チケットから収集 すべき不具合指標を定義 課題② 不具合指標を収集する ルールを決める 課題③ 不具合指標に紐づく データを入力する 対策 不具合指標に紐付くデータ 入力するタイミングを 記載した手順書を作成 GQMフレームワークを 活用し、収集する不具合 指標を体系的に定義 不具合チケットの テンプレートに対して、 収集が必要なデータ項目を 入力するフィールドを設置 不具合指標に紐づく データを入力する 16 © ZENKIGEN Inc.

GQMとは？ みなさん、GQMはご存知ですか？ 17 © ZENKIGEN Inc.

GQMの概要 ● GQMの概要 ○ 目標達成度を測定するためのフレームワーク Goal ● GQMの提案者 ○ メリーランド大学 ビクター・バシリ教授 ○ 1984年に提案された ● GQM（Goal/Question/Metric）の構成 ○ Goal ■ 測定目標 ○ Question ■ 目標達成評価のための質問 ○ Metric ■ 質問に回答するために必要な指標 ● Goal/Question/Metricの紐付き ○ Goalは単一or複数のQuestionと紐付く ○ Questionは複数のMetricと紐付く Question ① Metric① © ZENKIGEN Inc. Question ② Metric② Metric③ Metric④ 18

GQMの具体例 身近な事柄に対して、GQMを当てはめます 【健康を維持するための生活を実践する】をGoalに設定 19 © ZENKIGEN Inc.

GQMの具体例（全体図） 健康を維持するための生活を実践する Goal Question 習慣的な運動が行え ているか？ 質の良い睡眠が行え ているか？ 食生活は適切か？ Metric 1時間以上の 運動回数 （回/週） 摂取水分量 （L/日） 摂取カロリー (kcal/日) 食事を摂る 時間 体重増減量 （kg/日） © ZENKIGEN Inc. 睡眠時間 （時間/日） 就寝/起床時間 のばらつき(±30 分以上) 割合 （%/週） 歩数 （歩/日） 20

GQMの具体例（全体図） 健康を維持するための生活を実践する Goal Question 習慣的な運動が行え ているか？ 質の良い睡眠が行え ているか？ 食生活は適切か？ Metric 1時間以上の 運動回数 （回/週） 摂取水分量 （L/日） 摂取カロリー (kcal/日) 食事を摂る 時間 体重増減量 （kg/日） © ZENKIGEN Inc. 睡眠時間 （時間/日） 就寝/起床時間 のばらつき(±30 分以上) 割合 （%/週） 歩数 （歩/日） 21

GQMの具体例 Goal 健康を維持するための生活を実践する 22 © ZENKIGEN Inc.

GQMの具体例 Goal 健康を維持するための生活を実践する Question 食生活は適切か？ 質の良い睡眠が行 えているか？ 23 © ZENKIGEN Inc.

GQMの具体例 健康を維持するための生活を実践する Goal Question Metric 食生活は適切か？ 摂取 カロリー (kcal/日) 体重 増減量 （kg/日） 質の良い睡眠が行 えているか？ 食事を 摂る 時間 睡眠時間 （時間/日） 24 © ZENKIGEN Inc.

GQMの具体例 Metric→Question→Goalの順で目的達成を確認 25 © ZENKIGEN Inc.

GQMの具体例(Metric→Question→Goalの順で繋がりを確認) 健康を維持するための生活を実践する Goal Question 質の良い睡眠が行 えているか？ 食生活は適切か？ 一週間の各食事時間を記録する Metric (例)朝食6時/昼食13時/夕食19時 摂取 カロリー (kcal/日) 体重 増減量 （kg/日） 食事を 摂る 時間 睡眠時間 （時間/日） 26 © ZENKIGEN Inc.

GQMの具体例(Metric→Question→Goalの順で繋がりを確認) 健康を維持するための生活を実践する Goal ● ● ● Question 摂取カロリーは高くないか 食事間隔が適切か 体重増減量は問題ないか ・睡眠時間直前に食事を摂っていないか ・睡眠時間は十分か 質の良い睡眠が行 えているか？ 食生活は適切か？ 一週間の各食事時間を記録する (例)朝食6時/昼食13時/夕食19時 Metric 摂取 カロリー (kcal/日) 体重 増減量 （kg/日） 食事を 摂る 時間 睡眠時間 （時間/日） 27 © ZENKIGEN Inc.

GQMの具体例 例を用いてMetric→Question→Goalでの 目的達成が確認できました！ ここから本題に戻ります！ 28 © ZENKIGEN Inc.

問題点1に対する課題における対策（課題①とその対策のみ） 課題① 不具合チケットから収集 すべき不具合指標を定義 課題② 不具合指標を収集する ルールを決める 課題③ 不具合指標に紐づく データを入力する 対策 GQMフレームワークを 活用し、収集する不具合 指標を体系的に定義 不具合指標に紐付くデー タ入力するタイミングを 記載した手順書を作成 不具合チケットの テンプレートに対して、 収集が必要なデータ項目 を入力するフィールドを 設置 不具合指標に紐づく データを入力する 29 © ZENKIGEN Inc.

課題①とその対策の具体内容 ● GQMに基づき不具合指標を検討/定義 ○ 全体として8ケースのGQMを作成し指標を定義 ■ 例として3ケースのGQMをこの後説明します ● GQMの各Metricを収集するために不具合指標と 入力データ項目を定義 30 © ZENKIGEN Inc.

課題①とその対策の具体内容：GQM例1 不具合指標「クローズ理由種別」 Goal テスト実施内容に認識誤りが少ない状態であるか Question 修正対応せずにクローズしている不具合はあるか？ 「対応しない」不具合割合が 高ければ、テスト実施のミスや テスト項目書に誤りが多い可能性 があると考えられる。 テスト設計やテスト実装の工程が 改善可能となる。 Metric 不具合総数の内 クローズ不具合割合 クローズ不具合数の内 対応しなかった不具合 割合 31 © ZENKIGEN Inc.

課題①とその対策の具体内容：GQM例2 不具合指標「機能毎の不具合割合」 テスト実施している機能に対してどの程度 不具合が発生しているのか Goal Question テスト実施している機能は どの程度不具合が発生しているか？ テスト終盤において、局所的に不具合が 多い/少ない機能はどれか？ テスト終盤にテスト自体のフィード バックが行えるようになる。 Metric 不具合密度 各機能毎における 不具合検出割合 例として、リグレッションテストを厚 めに行うやバグが多い機能に対して よりテストする/バグが少ない機能に 対しては、テストケースの精査を実施 するなどのフィードバックが行える。 32 © ZENKIGEN Inc.

課題①とその対策の具体内容：GQM例3 不具合指標「不具合発生要因」 Goal 不具合が作り込まれている要因を把握し、 プロセス改善して品質向上施策につなげる Question どのプロセスで不具合が多く作り込まれて いるのか？ 振り返り会にて、不具合要因数が多 いプロセスに対して改善の アイデア出しが行いやすくなる。 ※ 不具合発生要因： どのタイミングで不具合が作り込まれて いたのかを把握する Metric 不具合総数の内 改修完了済みの 不具合割合 各プロセスでの 不具合発生割合 33 © ZENKIGEN Inc.

課題①とその対策の具体内容：最終的に定義した不具合指標及び入力データ項目 不具合指標 入力データ項目 クローズ理由 修正完了 / 仕様通り / 重複 / 対応しない Priority Urgent / High / Normal Status 未着手 / 着手中 / QA確認中 / クローズ 機能名 各機能名を入力 不具合起因箇所 BE / FE / Infra / Design 不具合発生要因 要件定義誤り / 機能設計誤り / 実装誤り / 外部要因 特定環境のみ発生 / その他（原因不明含む） Productionでの検出不具合 Production検出 / Productionでない デグレ デグレである / デグレでない 34 © ZENKIGEN Inc.

問題点1に対する課題における対策（課題②③とその対策のみ） 課題① 不具合チケットから収集 すべき不具合指標を定義 課題② 不具合指標を収集する ルールを決める 課題③ 不具合指標に紐づく データを入力する 対策 不具合指標に紐付くデータ を入力するタイミングを 記載した手順書を作成 GQMフレームワークを 活用し、収集する不具合 指標を体系的に定義 不具合チケットの テンプレートに対して、 収集が必要なデータ項目を 入力するフィールドを設置 不具合指標に紐づく データを入力する 35 © ZENKIGEN Inc.

課題②③とその対策の具体内容 ● 課題①に対する対策で定めた不具合指標/データ項目に紐付く データ入力タイミング等を記載した手順書を作成 ○ 作成後、チーム全体に共有を実施 ○ 手順書はNotionを使用して作成 ● 既存の不具合チケットのテンプレートを修正 ○ 収集が必要なデータ項目を入力するフィールドを設置 ○ 既存の不具合に対しても、データ項目を入力 ● 不具合チケット起票時/更新時に手順に沿ってデータを入力 36 © ZENKIGEN Inc.

課題②とその対策の具体内容：手順書の一部（課題①のその対策の表に入力する人・入力タイミングを記載） 不具合指標 入力データ項目 入力する人 入力タイミング クローズ理由 修正完了 / 仕様通り / 重複 / 対応しない 不具合起票者 不具合クローズ時 Priority Urgent / High / Normal 不具合起票者 不具合起票時 Status 未着手 / 着手中 / QA確認中 / クローズ 不具合更新者 不具合更新時 機能名 各機能名を入力 不具合起票者 不具合起票時 不具合起因箇所 BE / FE / Infra / Design 不具合起票者 不具合クローズ時 不具合発生要因 要件定義誤り / 機能設計誤り / 実装誤り 外 部要因 / 特定環境のみ発生 その他（原因不明含む） チーム全体 プロジェクト振り返り会前 Productionでの検 出不具合 Production検出 / Productionでない 不具合起票者 不具合起票時 デグレ デグレである / デグレでない 不具合起票者 不具合起票時 37 © ZENKIGEN Inc.

問題点２に対する課題 問題点2 不具合情報に基づく進捗の共有や改善のアイデア出しが 出来ていなかった 課題④ GQMの各Goalを達成するために ダッシュボードを作成し、不具合情報を可視化する 38 © ZENKIGEN Inc.

問題点２に対する課題における対策 課題④ GQMの各Goalを達成するために ダッシュボードを作成し、不具合情報を可視化する 対策 不具合チケットに入力された データを基にして、不具合指標や 傾向を視覚化するためグラフ等を作成 グラフやチャートを纏めた ダッシュボードを作成し、チーム全体で 閲覧可能な状態にする 39 © ZENKIGEN Inc.

課題④とその対策の具体内容：グラフデータイメージ「クローズ理由種別」 クローズ理由毎の不具合割合 ● 70%以上の不具合が 修正完了しクローズしている ● 5%未満が、対応しないで クローズしている 40 © ZENKIGEN Inc.

課題④とその対策の具体内容：ダッシュボードイメージ 41 © ZENKIGEN Inc.

対策実行後の結果 ● ダッシュボードの活用 ○ デイリーミーティング ■ リリースまでに修正すべき不具合チケットの数が把握 ● 開発リソースの調整判断をよりスムーズに実施可能に ○ 振り返り会 ■ 不具合が多く発生した機能を特定 ● 改修の際は、要件定義やデザインレビューの強化など提案可能に 42 © ZENKIGEN Inc.

01 自己紹介 02 本発表の概要 03 発生していた問題とその背景 04 問題点に対する課題と対策 05 対策の有効性確認 06 発表まとめ © ZENKIGEN Inc.

対策の有効性確認 ● 有効性確認のためアンケートを実施 ○ 対象者 ■ 本取り組み実施チーム ■ 未実施チーム ● 不具合情報を可視化する必要性について未議論 ● アンケート項目観点 ○ 本取り組み実施チーム ■ ダッシュボードがチームに対して貢献出来ているか ○ 未実施チーム ■ ダッシュボードを共有し、現状から発展できるか 43 © ZENKIGEN Inc.

対策の有効性確認：アンケート項目（本取り組み実施チーム） 本取り組み実施チーム 質問内容 評価方法 ダッシュボードを、デイリーミーティング等で使用するこ とで、知りたい不具合の情報を取得できましたか？ 5段階評価 (全く取得できていなかった：1/非常に取得できた：5) ダッシュボードを、デイリーミーティング等で使用するこ 5段階評価 とで、チーム内のコミュニケーションは円滑になりました (全く円滑になっていない：1/非常に円滑になった：5) か？ 不具合情報を可視化することは、 本取り組み前と比較すると有効でしたか？ 5段階評価 (全く有効でなかった：1/非常に有効だった：5) 不具合情報を可視化することは、プロジェクト全体を通 5段階評価 して貢献していると感じますか？ (全く貢献していない：1/非常に貢献している：5) 今回の取り組みは、今後、他のチームやプロジェクトで 5段階評価 も使用すべきだと思いますか？ (使用すべきではない：1/使用すべきだ：5) 44 © ZENKIGEN Inc.

対策の有効性確認：アンケート項目結果（本取り組み実施チーム） 本取り組み実施チーム結果 アンケート収集数（2名） 質問内容 評価方法 結果の 平均値 ダッシュボードを、デイリーミーティング等で使用す ることで、知りたい不具合の情報を取得できました か？ 5段階評価 (全く取得できていなかった：1/非常に取得できた：5) 4.5 ダッシュボードを、デイリーミーティング等で使用す ることで、チーム内のコミュニケーションは円滑にな りましたか？ 5段階評価 (全く円滑になっていない：1/非常に円滑になった：5) 4.5 不具合情報を可視化することは、 本取り組み前と比較すると有効でしたか？ 5段階評価 (全く有効でなかった：1/非常に有効だった：5) 4.5 不具合情報を可視化することは、プロジェクト全体 を通して貢献していると感じますか？ 5段階評価 (全く貢献していない：1/非常に貢献している：5) 5 今回の取り組みは、今後、他のチームやプロジェク トでも使用すべきだと思いますか？ 5段階評価 (使用すべきではない：1/使用すべきだ：5) 5 © ZENKIGEN Inc. 45

対策の有効性確認：アンケート項目（本取り組み未実施チーム） 本取り組み未実施チーム 質問内容 評価方法 現在、不具合チケットの情報を分析する 取り組みをどの程度行っていますか？ 5段階評価 (全然行えていない： 1/非常に行えている： 5) 不具合状況を可視化することで、チーム内で 有効なコミュニケーションが行えるように なると思いますか？ 5段階評価 (行えるとは思えない： 1/行えると思う： 5) この取り組みが導入された場合、 業務の効率や品質向上に貢献すると 考えますか？ 5段階評価 (全く貢献しない： 1/非常に貢献する： 5) 46 © ZENKIGEN Inc.

対策の有効性確認：アンケート結果（本取り組み未実施チーム） 本取り組み未実施チーム結果 アンケート収集数（8名） 質問内容 評価方法 結果の 平均値 現在、不具合チケットの情報を分析する 取り組みをどの程度行っていますか？ 5段階評価 (全然行えていない： 1/非常に行えている： 5) 3.25 不具合状況を可視化することで、チーム内で 有効なコミュニケーションが行えるように なると思いますか？ 5段階評価 (行えるとは思えない： 1/行えると思う： 5) 4.13 この取り組みが導入された場合、 業務の効率や品質向上に貢献すると 考えますか？ 5段階評価 (全く貢献しない： 1/非常に貢献する： 5) 3.5 47 © ZENKIGEN Inc.

対策の有効性確認：アンケート結果（コメント） ● 一覧で見るよりも全員が同じ課題感を持って仕事できそうなので 今後も続けられると良い ● 開発にフィードバックでき、改善が回せるようになると好ましい ● 可視化の手法によって認知しやすさが変わると思うので、 適切な手法を考えたい ● 継続性の観点から導入したことによる効果を定量的に見たい ● 最終的な目標があるとより協力的になるのではないか ● 可視化した不具合状況をどういった基準でプロダクトやチーム改善に 活かしていくかのようなプロセスが課題になりそう ● メンバーの習慣化が課題 48 © ZENKIGEN Inc.

まとめ ● アンケート結果からの考察 ○ 本取り組み実施チーム ■ 取り組み内容自体は概ね有効 ■ チーム全体のコミュニケーションなどに貢献 ■ 他チームや他プロジェクトでの活用にも有効 ○ 本取り組み未実施チーム ■ 導入により、更に効果的なコミュニケーションや品質向上への期待 ● 新たな課題 ○ 複数の指標を組み合わせたデータの可視化 ■ (例)機能名と不具合発生要因を組みわせて 機能毎に不具合が作り込まれている要因を知る ○ 本取り組み未実施チームで同様の取り組みを実施し、導入前後の比較 49 © ZENKIGEN Inc.

01 自己紹介 02 本発表の概要 03 発生していた問題とその背景 04 問題点に対する課題と対策 05 対策の有効性確認 06 発表まとめ © ZENKIGEN Inc.

発表まとめ ● GQMを活用し、不具合指標やそれに基づくデータ項目を整理 ● 不具合指標や傾向を把握するために、ダッシュボードを作成 ● チームに共有し、チーム内MTGで活用 ● 有効性確認のため、2チームにアンケート調査を実施し、有効性が確認出来た ● 複数の指標を組み合わせたデータの可視化など今後の課題はある 50 © ZENKIGEN Inc.

参考文献 © ZENKIGEN Inc.

参考文献 ● 鷲崎, メトリクスによるソフトウェア品質評価と改善品質測定評価の落と し穴とコツ,Embedded Techology2017 ○ https://www.jasa.or.jp/expo/2017/conference2017/doc/ET_IoT_Technolo gy2017_TSE_3.pdf ● 芹沢, ほか, Web／モバイル・アプリケーション開発における定量的なテ ストマネージメントに向けた取り組み , ソフトウェア品質シンポジウム 2019 ○ ● https://www.juse.jp/sqip/library/shousai/?id=459 ソフトウェア品質知識体系ガイド(第3版): SQuBOK Guide V3 51 © ZENKIGEN Inc.

• https://www.jasa.or.jp/expo/2017/conference2017/doc/ET_IoT_Technology2017_TSE_3.pdf
• https://www.juse.jp/sqip/library/shousai/?id=459

お知らせ 二人目のQAエンジニア募集しています！！ プロダクトが大きくなっており 二人目のQAエンジニアを求めています。 アドバイザーとして河野哲也さん（tettan）に サポート頂いています。 今回の発表や日々の業務にて、ご支援頂いています。 QAエンジニア 採用ページ 52 © ZENKIGEN Inc.

ご清聴ありがとうございました！ © ZENKIGEN Inc.

© ZENKIGEN Inc.