Submit Search
Upload
エムスリーのQAチームが目指すもの
•
3 likes
•
6,555 views
Yuki Shiromoto
Follow
11/03のDevLove「あなたの知らないQAチーム、QAエンジニアの世界」で発表した内容になります
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 36
Download now
Download to read offline
Recommended
しばしばQAと一括りにされる、テストエンジニアとSETとQAを整理してバランスをよくするための「QMファンネル(3D版)」について紹介しています。Scrum Fest Osaka 2021のプレゼンテーション資料です。
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
This slides explain what you should "shift left" in agile development and you should make patterns of traps in software development.
What should you shift left
What should you shift left
Yasuharu Nishi
This slides show how to design "Quality Culture" and ingrain it with software/digital organizations in Japanese.
What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?
Yasuharu Nishi
年単位でトラブルを起こさないための考え方についてまとめました。システムがトラブル続きだとビジネス速度がどんどん落ちていくので、気をつけましょう。
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
テスト観点を基盤としたテスト開発のための記法(NGT: Notation for Generic Testing)とテスト開発プロセス(VSTeP: Viewpoint-based Software Test Engineering Process)の説明スライド。2013/5/10版。
テスト観点に基づくテスト開発方法論VSTePの概要
テスト観点に基づくテスト開発方法論VSTePの概要
Yasuharu Nishi
鷲崎弘宜, "アジャイル品質パターン (Agile Quality, QA2AQ), アジャイル時代の組織ケーパビリティ向上 CMMI V2.0 / APH(アジャイルパフォーマンスモデル) / アジャイル品質パターンセミナー, 早稲田大学, 2019年6月6日
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎にて、メトリクスの基礎の講義ならびにゴール指向の測定手法 Goal-Question-Metric(GQM)パラダイムを演習いただきました。 短時間ですが2チームにおいて実践的なGQMグラフができあがりました。仮説、解釈を明示しておくことが重要であり、それが書けている点もgoodです。来年も実施しますのでご興味があればぜひご参加ください。 http://www.juse-sqip.jp/workshop/bunka/index.html#soft1
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
Hironori Washizaki
CodeZine連載中のアジャイル品質パターン QA to AQ の概要を紹介します。アジャイル開発における品質活動は、特定段階で取り組むというよりも、ロードマップから日々のモニタリングに至るあらゆる段階でチーム全体で取り組むものとなります。QA to AQ はそのエッセンスをまとめたものです。
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
Hironori Washizaki
Recommended
しばしばQAと一括りにされる、テストエンジニアとSETとQAを整理してバランスをよくするための「QMファンネル(3D版)」について紹介しています。Scrum Fest Osaka 2021のプレゼンテーション資料です。
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
This slides explain what you should "shift left" in agile development and you should make patterns of traps in software development.
What should you shift left
What should you shift left
Yasuharu Nishi
This slides show how to design "Quality Culture" and ingrain it with software/digital organizations in Japanese.
What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?
Yasuharu Nishi
年単位でトラブルを起こさないための考え方についてまとめました。システムがトラブル続きだとビジネス速度がどんどん落ちていくので、気をつけましょう。
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
テスト観点を基盤としたテスト開発のための記法(NGT: Notation for Generic Testing)とテスト開発プロセス(VSTeP: Viewpoint-based Software Test Engineering Process)の説明スライド。2013/5/10版。
テスト観点に基づくテスト開発方法論VSTePの概要
テスト観点に基づくテスト開発方法論VSTePの概要
Yasuharu Nishi
鷲崎弘宜, "アジャイル品質パターン (Agile Quality, QA2AQ), アジャイル時代の組織ケーパビリティ向上 CMMI V2.0 / APH(アジャイルパフォーマンスモデル) / アジャイル品質パターンセミナー, 早稲田大学, 2019年6月6日
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎にて、メトリクスの基礎の講義ならびにゴール指向の測定手法 Goal-Question-Metric(GQM)パラダイムを演習いただきました。 短時間ですが2チームにおいて実践的なGQMグラフができあがりました。仮説、解釈を明示しておくことが重要であり、それが書けている点もgoodです。来年も実施しますのでご興味があればぜひご参加ください。 http://www.juse-sqip.jp/workshop/bunka/index.html#soft1
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
Hironori Washizaki
CodeZine連載中のアジャイル品質パターン QA to AQ の概要を紹介します。アジャイル開発における品質活動は、特定段階で取り組むというよりも、ロードマップから日々のモニタリングに至るあらゆる段階でチーム全体で取り組むものとなります。QA to AQ はそのエッセンスをまとめたものです。
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
Hironori Washizaki
Classification Tree Method/CTM, WACATE2014Winter
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
H Iseri
社内資料です。LayerXのQAチームで目指したい動き方です。
LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)
mosa siru
例外設計における大罪 Jun 27, 2012 @ java-ja
例外設計における大罪
例外設計における大罪
Takuto Wada
近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps開発では,今まで主流であったウォーターフォール開発と異なり,短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返しながら開発する特徴がある.そのため,品質保証や信頼性でのメトリクス活用においても,メトリクスにもとづいたQAテストを実施することは依然重要であるが,それに加え開発から運用までの一連のプロセスの中でプロダクトとプロセスの品質を見える化し継続的な改善活動を促進するフィードバックを提供することがアジャイル開発では求められる.また、DevOps開発では本番稼働中のシステムについてもレジリエンスの枠組みで障害やバグに関するフィード バックを獲得し継続的に学習する.本講演ではアジャイル /DevOps の品質保証と信頼性におけるメトリクス活用の方法について事例も交えながら紹介する.
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
イマドキのソフトウェアのQAのマインドセットと戦略立案についてまとめたドラフトの第1稿です。QAは開発の弱さに寄り添い支える存在で、納得感の共感を高めていくのがミッションです。サーバントシップ、カイゼンサイクル、ミッションシェア、アップストリーミング、見える化という5つの大事なマインドセットを持ち、QA戦略としてスコープ、レジリエンス、スキーム、ストーリーをデザインしていきます。
modern software qa - draft 1
modern software qa - draft 1
Yasuharu Nishi
A presentation for LINE Developer Meetup in Tokyo #39 on paradigm shift to and testing methodology for modern software development.
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
Yasuharu Nishi
テストやQA (品質保証) には説明責任が求められます。しかし、仕様書のコピペにすぎないテスト設計、自己目的化した自動化、規格に準拠しただけの開発 / 機能安全プロセス、おざなりな保証ケース、属人化したレビュー、ハードウェア主導のQA組織によるピントを外した品質保証など、説明責任とはほど遠い組織が多く見られます。そこで本講演ではQAアーキテクチャというコンセプトを紹介し、テストやQAの全体像を俯瞰し説明責任を高めるための方策を概説します。これにより、テスト自動化をベースとしたパイプライン化によるテストのリズムの高速化や、フロントローディングによる上流での品質作り込みサイクルの構築も目指すことができるようになります。
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Yasuharu Nishi
テスト分析設計についてのワークショップの資料です。 http://swquality.jp/
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
Akira Ikeda
2022/03/10 JaSST Tokyo22 http://www.jasst.jp/symposium/jasst22tokyo/timetable.html
「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」
大貴 蜂須賀
WACATE2019 夏
テストの組み立て方
テストの組み立て方
kauji0522
リリースサイクルが早い開発の中で、我々はどのようにテストを行っていけば良いのでしょうか? 今回は私が前職行っていた、探索的テストをメインとした戦略をご紹介します
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
Mineo Matsuya
A modified presentation for LINE Developer Meetup in Tokyo #39 on paradigm shift to and testing methodology for modern software development.
LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)
Yasuharu Nishi
WACATE2023Summer
テスト分析.pptx
テスト分析.pptx
kauji0522
組織にテストを書く文化を根付かせる戦略と戦術 Feb 16, 2016 @ 日本OSS推進フォーラム
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
This slides show various definitions of "Quality Engineer" and compare it with tester and QA in Japanese.
What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?
Yasuharu Nishi
2017年1月12日(木)に、「Regional Scrum Gathering Tokyo 2017」で発表させていただいた資料です。 http://2017.scrumgatheringtokyo.org/ メトリクスに関する知見を、学術的視点(Agile2016・SQiP2016)および現場での活用事例から整理し、具体的な取得・活用方法を含めて説明しています。 みなさんのメトリクスの習得・活用のプラスになれば幸いです。
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
当資料は、2012/1/14に開催された、以下の勉強会で発表した資料です。 わんくま同盟 名古屋勉強会 #20 & 第39回 名古屋アジャイル勉強会 & TEF東海 勉強会 http://www.wankuma.com/seminar/20120114nagoya20/ 1/19 ・当日のワークの結果を追加した ・TEFの紹介部分を微修正 ・P1タイトル誤字を修正 1/23 ・WACATEのリンクを追加 ・テスト設計関連の参考リンクを追加 ・P18の図にライフサイクルの補足を追加 ・P16の表示が変だったのを直したよ
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
CASEやMaaSの時代になって、車載ソフトウェアの品質保証は左利きと右利きの両利きでなくてはなりません。右利きとは、CASEやMaaSの時代よりも以前から必要になっている車載ソフトウェアの品質保証の技術です。左利きとは、CASEやMaaSの時代になって身につけなくてはならなくなった技術です。この講演では両利きの技術のそれぞれについて概説し、左利きの技術についてはQualiTraxというフレームワークで説明しています。この資料は2020/8/28に講演したスライドですが、ベリサーブさんのご厚意で公開できました。
車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから
Yasuharu Nishi
デブサミ関西2012のA-5自分戦略で話した内容です
デブサミ関西2012_自分戦略_yohhatu
デブサミ関西2012_自分戦略_yohhatu
Yoh Nakamura
Regional SCRUM GATHERING Tokyo 2016 での発表です
あなたのチームの「いい人」は機能していますか?
あなたのチームの「いい人」は機能していますか?
Minoru Yokomichi
More Related Content
What's hot
Classification Tree Method/CTM, WACATE2014Winter
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
H Iseri
社内資料です。LayerXのQAチームで目指したい動き方です。
LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)
mosa siru
例外設計における大罪 Jun 27, 2012 @ java-ja
例外設計における大罪
例外設計における大罪
Takuto Wada
近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps開発では,今まで主流であったウォーターフォール開発と異なり,短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返しながら開発する特徴がある.そのため,品質保証や信頼性でのメトリクス活用においても,メトリクスにもとづいたQAテストを実施することは依然重要であるが,それに加え開発から運用までの一連のプロセスの中でプロダクトとプロセスの品質を見える化し継続的な改善活動を促進するフィードバックを提供することがアジャイル開発では求められる.また、DevOps開発では本番稼働中のシステムについてもレジリエンスの枠組みで障害やバグに関するフィード バックを獲得し継続的に学習する.本講演ではアジャイル /DevOps の品質保証と信頼性におけるメトリクス活用の方法について事例も交えながら紹介する.
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
イマドキのソフトウェアのQAのマインドセットと戦略立案についてまとめたドラフトの第1稿です。QAは開発の弱さに寄り添い支える存在で、納得感の共感を高めていくのがミッションです。サーバントシップ、カイゼンサイクル、ミッションシェア、アップストリーミング、見える化という5つの大事なマインドセットを持ち、QA戦略としてスコープ、レジリエンス、スキーム、ストーリーをデザインしていきます。
modern software qa - draft 1
modern software qa - draft 1
Yasuharu Nishi
A presentation for LINE Developer Meetup in Tokyo #39 on paradigm shift to and testing methodology for modern software development.
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
Yasuharu Nishi
テストやQA (品質保証) には説明責任が求められます。しかし、仕様書のコピペにすぎないテスト設計、自己目的化した自動化、規格に準拠しただけの開発 / 機能安全プロセス、おざなりな保証ケース、属人化したレビュー、ハードウェア主導のQA組織によるピントを外した品質保証など、説明責任とはほど遠い組織が多く見られます。そこで本講演ではQAアーキテクチャというコンセプトを紹介し、テストやQAの全体像を俯瞰し説明責任を高めるための方策を概説します。これにより、テスト自動化をベースとしたパイプライン化によるテストのリズムの高速化や、フロントローディングによる上流での品質作り込みサイクルの構築も目指すことができるようになります。
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Yasuharu Nishi
テスト分析設計についてのワークショップの資料です。 http://swquality.jp/
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
Akira Ikeda
2022/03/10 JaSST Tokyo22 http://www.jasst.jp/symposium/jasst22tokyo/timetable.html
「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」
大貴 蜂須賀
WACATE2019 夏
テストの組み立て方
テストの組み立て方
kauji0522
リリースサイクルが早い開発の中で、我々はどのようにテストを行っていけば良いのでしょうか? 今回は私が前職行っていた、探索的テストをメインとした戦略をご紹介します
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
Mineo Matsuya
A modified presentation for LINE Developer Meetup in Tokyo #39 on paradigm shift to and testing methodology for modern software development.
LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)
Yasuharu Nishi
WACATE2023Summer
テスト分析.pptx
テスト分析.pptx
kauji0522
組織にテストを書く文化を根付かせる戦略と戦術 Feb 16, 2016 @ 日本OSS推進フォーラム
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
This slides show various definitions of "Quality Engineer" and compare it with tester and QA in Japanese.
What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?
Yasuharu Nishi
2017年1月12日(木)に、「Regional Scrum Gathering Tokyo 2017」で発表させていただいた資料です。 http://2017.scrumgatheringtokyo.org/ メトリクスに関する知見を、学術的視点(Agile2016・SQiP2016)および現場での活用事例から整理し、具体的な取得・活用方法を含めて説明しています。 みなさんのメトリクスの習得・活用のプラスになれば幸いです。
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
当資料は、2012/1/14に開催された、以下の勉強会で発表した資料です。 わんくま同盟 名古屋勉強会 #20 & 第39回 名古屋アジャイル勉強会 & TEF東海 勉強会 http://www.wankuma.com/seminar/20120114nagoya20/ 1/19 ・当日のワークの結果を追加した ・TEFの紹介部分を微修正 ・P1タイトル誤字を修正 1/23 ・WACATEのリンクを追加 ・テスト設計関連の参考リンクを追加 ・P18の図にライフサイクルの補足を追加 ・P16の表示が変だったのを直したよ
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
CASEやMaaSの時代になって、車載ソフトウェアの品質保証は左利きと右利きの両利きでなくてはなりません。右利きとは、CASEやMaaSの時代よりも以前から必要になっている車載ソフトウェアの品質保証の技術です。左利きとは、CASEやMaaSの時代になって身につけなくてはならなくなった技術です。この講演では両利きの技術のそれぞれについて概説し、左利きの技術についてはQualiTraxというフレームワークで説明しています。この資料は2020/8/28に講演したスライドですが、ベリサーブさんのご厚意で公開できました。
車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから
Yasuharu Nishi
What's hot
(20)
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)
例外設計における大罪
例外設計における大罪
アジャイル開発とメトリクス
アジャイル開発とメトリクス
modern software qa - draft 1
modern software qa - draft 1
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
「PdMと考えるQAとプロダクトマネジメント」
「PdMと考えるQAとプロダクトマネジメント」
テストの組み立て方
テストの組み立て方
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)
テスト分析.pptx
テスト分析.pptx
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
テストを分類してみよう!
テストを分類してみよう!
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから
Similar to エムスリーのQAチームが目指すもの
デブサミ関西2012のA-5自分戦略で話した内容です
デブサミ関西2012_自分戦略_yohhatu
デブサミ関西2012_自分戦略_yohhatu
Yoh Nakamura
Regional SCRUM GATHERING Tokyo 2016 での発表です
あなたのチームの「いい人」は機能していますか?
あなたのチームの「いい人」は機能していますか?
Minoru Yokomichi
社内でスクラムについて説明するときに使用した資料です。 スクラムの本質に触れることで、なぜスクラムをやるのか?を理解することを目標にしています。
Scrumの根っこ
Scrumの根っこ
Koji Sudo
FindyLT会
2023-03-23_SpiralAI
2023-03-23_SpiralAI
SasakiYuichi1
DevOpsDaysTokyo 2021 Day2
How to use testing viewpoint
How to use testing viewpoint
Noriyuki Nemoto
Front night vol1
Front night vol1
Daisuke Shigyou
Spiral.AIでは、LLMが社会実装されていくお手伝いをします。 精度改善のためのツールや、カスタマイズ機能を提供することで、「遊んでみた」から「本流のサービスに組み込んでみた」ところまでの移行を支援します。
2023-03-22_Spiral.AI_FindyLT会
2023-03-22_Spiral.AI_FindyLT会
SasakiYuichi1
LT会
2023-03-23_Spiral.AI
2023-03-23_Spiral.AI
SasakiYuichi1
DevLOVE #290 チームビルディングへの招待
20190926_島耕作に学ぶ、ひとたらしチームビルディング
20190926_島耕作に学ぶ、ひとたらしチームビルディング
大貴 蜂須賀
社内勉強会でプレゼンの経験があまり無い方向けに話した資料
社内プレゼン勉強会発表資料
社内プレゼン勉強会発表資料
Yoh Nakamura
Similar to エムスリーのQAチームが目指すもの
(10)
デブサミ関西2012_自分戦略_yohhatu
デブサミ関西2012_自分戦略_yohhatu
あなたのチームの「いい人」は機能していますか?
あなたのチームの「いい人」は機能していますか?
Scrumの根っこ
Scrumの根っこ
2023-03-23_SpiralAI
2023-03-23_SpiralAI
How to use testing viewpoint
How to use testing viewpoint
Front night vol1
Front night vol1
2023-03-22_Spiral.AI_FindyLT会
2023-03-22_Spiral.AI_FindyLT会
2023-03-23_Spiral.AI
2023-03-23_Spiral.AI
20190926_島耕作に学ぶ、ひとたらしチームビルディング
20190926_島耕作に学ぶ、ひとたらしチームビルディング
社内プレゼン勉強会発表資料
社内プレゼン勉強会発表資料
エムスリーのQAチームが目指すもの
1.
エムスリーのQAチームが 目指すもの あなたの知らないQAチーム、QAエンジニアの世界 2020/11/03 エムスリー株式会社 城本 由希
2.
本日お話したいこと 「あなたの知らないQAチーム、QAエンジニアの世界」 ということで、エムスリーのQAチームの雰囲気や普段のしごとを知っ ていただけたらと思います 2
3.
本日お話したいこと 1. エムスリーのQAチームが何を目指しているか 2. どうやっているのか a.
会社の文化 b. チームの体制/人 c. 開発の仕方/具体例 3. これから伸ばしていきたいところ 3
4.
自己紹介 ● 名前:城本 由希 @yuki_shiro_823 ●
仕事:エムスリーのQAエンジニア ● 出身:広島(カープファン) 大学時代の専攻は歴史でした ● 趣味:神社仏閣や城や古墳を訪れること QA関係の勉強会によく出没してます 4
5.
前提:エムスリーとは何をやっている会社か? ● ミッション ○ インターネットを活用し、健康で楽しく長生きする人を一人で も増やし、不必要な医療コストを一円でも減らすこと 5
6.
前提:エムスリーとは何をやっている会社か? ● 医師の9割が登録する医療従事者向けサイト「m3.com」を中心 に以下のようなサービスを提供 ○ 製薬企業 :マーケティング支援や新薬開発支援など ○
病院 :採用支援、電子カルテ、医療機器など ○ 医療従事者 :医療に関する情報の提供、開業・転職支援など ○ 一般消費者 :医療相談、医療系情報の提供など 6
7.
エムスリーのQAチームが何を目指しているか 低コストで高品質の製品を創り、 高速リリースが可能な開発チームを創る 7
8.
「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? ● 盲目的にバグの削減を目指すのではなく、顧客利益の最大化を目指す ● 開発プロセスに上流から関わり、顧客が真に必要とする製品を提供する ●
テストでバグを検出するだけではなく、バグを埋め込まない仕組みを作る ● 個人の作業の最適化を目指すのではなく、開発チーム全体の最適化を目 指す ● QAエンジニアとしての役割を越えて、開発チームの課題解決に全力を尽く す 8
9.
「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? 盲目的にバグの削減を目指すのではなく、顧客利益の最大化を目指 す ● 過去のNG例 以前はバグの検出数をKPIにしていた →テスト量が多く重箱の隅を突くような指摘が多い ● 是正結果 顧客にとって価値のあるテストを考える 9
10.
「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? 開発プロセスに上流から関わり、顧客が真に必要とする製品を提供 する ● NG例 最終ゲートキーパーとしてのQAを行い、出来上がったシステム に対する評価しかできない ● OK例 上流から仕様策定への意見を出し、すべての工程で顧客価値を 評価する 10
11.
「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? テストでバグを検出するだけではなく、バグを埋め込まない仕組みを 作る ● 過去のNG例 以前はバグ検出数をKPIにしていた →バグがないと評価が悪くなる ● 是正結果 バグを埋め込まない仕組みを作った方が品質も業務効率も上が るので、それを目指すべき 例:仕様レビューなどでなるべく事前にバグを取り除く
11
12.
「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? 個人の作業の最適化を目指すのではなく、開発チーム全体の最適化 を目指す ● 過去のNG例 テストケース作成数、実施数(作業量)をKPIとしていた時期が あったが、不要なテストを誘発してしまった ● 是正結果 本当は少ないテストで品質を保てる方が生産性が高いはず →作業量ではなく、チームのアウトプットの数(ひいては顧客の利 益)にフォーカスすべき
12
13.
「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? QAエンジニアとしての役割を越えて、開発チームの課題解決に全力 を尽くす ● 過去のNG例 テストだけに注力して他の開発フェーズには手を出さない ● 是正結果 チームの課題解決に向けて積極的に動く 例:必要に応じて、ドキュメント整備や問い合わせ回答をQAエン ジニアが行う 13
14.
どうやっているのか? ~前提:会社の文化~ ● フラットな組織 ○ 現場に裁量 ○
誰でも施策の起案OK(雇用形態や職種の壁なし) 14
15.
どうやっているのか? ~前提:会社の文化~ ● クライアント(仕事)に対する執着心 ○ 顧客の期待を絶えず上回る ●
社長意識 ○ 一人ひとりが経営者視点に立って主体的に行動 ○ 大きく考え、何でもありで課題を解決 ● 皆をプロフェッショナルとして尊重 ○ 相手を尊重しつつも率直に意見を言う ○ チームで協力して良い成果を出す 15
16.
どうやっているのか ~チームの体制~ 16
17.
どうやっているのか ~チームの体制~ ● QAチームは組織横断チーム ○ QAエンジニアは所属はQAチームで、普段の仕事は各事業チーム と一緒にやっている ●
各事業チームはプロダクトマネージャー、デザイナー、開発者、 QAエンジニア含めて10~20名程度 ○ 開発者とQAエンジニアの比率は10:3程度 17
18.
どうやっているのか ~チームの体制~ ● 各事業チームごとに事業のフェーズが異なるため、求められる品 質の内容が変わる ○ 歴史が長く顧客がついていて、既存影響がないことを厳密に求めら れる事業 ○
新規に立ち上げて、素早くリリースして市場からのフィードバックを もらいたい事業 ● 開発スタイルは各事業チームの裁量に委ねられる ○ スクラム、カンバン、WBSでの進捗管理 ○ 技術選定 18
19.
19 技術スタック
20.
どうやっているのか ~QAチームのメンバーとアウトプット~ チームリーダー:窪田純士 ● Docpediaでの品質計画とQA活動 ● エムスリーのテスト自動化の
歴史とこれから 中塚由美子 ● エムスリーのQAメンバーが JaSST Review'20 に登壇しま す!! 20
21.
どうやっているのか ~開発の仕方とQAエンジニアの役割~ 基本的な開発の流れ 21 フェーズ 開発者 QAエンジニア 1
施策の起案 工数見積、企画書レビュー、企画の狙い確認 2 仕様のレビュー 仕様、設計のレビュー 3 実装 実装、ユニットテスト実装 テスト計画/設計/実装 4 コードレビュー コードレビュー 5 システムテスト 非機能テスト テスト実施、テストマネジメント 6 リリース リリース作業 リリース手順、残タスクの確認 7 リリース後の作業 本番環境の動作確認/監視、ふりかえり
22.
どうやっているのか ~一例:開発チームの一員として~ 「施策の起案」フェーズ ● 企画書を見て、ROI算出のためのテスト工数の見積もり ● 起案時点で仕様の考慮漏れなど言えることがあればコメント ○
影響範囲が分かれば確認 ● 起案の狙いの確認(何のためのシステムか把握してテストしたい ので) 22
23.
どうやっているのか ~一例:開発チームの一員として~ 「仕様のレビュー」フェーズ ● 仕様レビューに参加 ● プロダクトマネージャーや開発者に説明してもらい、不明点を質 問する ○
システム構成図やシーケンス図を描いてもらったり、その場で図を 描いたりする 23
24.
どうやっているのか ~一例:開発チームの一員として~ 「実装」フェーズ ● ここは主に開発者が担当 ○ ユニットテストやAPIテストは開発者が担当 ●
QAエンジニアは実装・コードレビューと並行してテスト計画・設計 を実施 ○ 計画中に出てきた不明点は都度開発者に質問 ○ 非機能系試験をどこまで実施するか相談 ○ 計画が出来上がった段階で関係者にレビューしてもらい認識をあわ せる 24
25.
どうやっているのか ~一例:開発チームの一員として~ 「コードレビュー」フェーズ ● ここは主に開発者が担当 ● QAエンジニアは実装・コードレビューと並行してテスト計画・設計 を実施 ○
特性に合わせてテスト技法を選択 ○ 条件の洗い出し等で不安がある箇所は開発者と打ち合わせて確認 ○ 設計を同じ事業チームのQAエンジニアに任せる場合は導入とレ ビューを実施 25
26.
どうやっているのか ~一例:開発チームの一員として~ 「システムテスト」フェーズ ● 前のフェーズで作成したテスト設計を元に、テストケースを実装、 実施 ○ 自分でやることもテスターさんにやってもらうこともある ○
非機能系のテストは開発者やセキュリティエンジニアに助けてもらう ことが多い ○ 探索的テストを取り入れることもある 26
27.
どうやっているのか ~一例:開発チームの一員として~ 「リリース」フェーズ ● リリース申請の承認 ○ Gitlabでソースコードが見られるので疑問点があれば確認 ■
リリース対象と関係なさそうなファイルが対象に入ってないか ○ 今回のリリース対象外とするバグがあれば事前に合意を取る 27
28.
どうやっているのか ~一例:開発チームの一員として~ 「リリース後の作業」フェーズ ● 一部の顧客問い合わせについて調査、仕様の回答など対応 ● リリースのふりかえりを実施 ●
本番障害発生時は再発防止策を関係者全員で考える 28
29.
どうやっているのか ~一例:QAチームの一員として~ <課題感> 組織横断チームとはいえ、実際には担当事業のチームメンバと話し ている方が多い →QAエンジニアの間で、事例やグッドプラクティスの共有や、困り事 の相談をする場が少ない 29
30.
どうやっているのか ~一例:QAチームの一員として~ <対応> 1. QAチーム勉強会を隔週で実施 a. お互いのスキルや相談しやすさがアップ b.
勉強会は「業務時間内に業務としてやってよし」とVPoEから許可を もらう (業務委託やアルバイトの方も参加しやすく!) ※VPoEの口癖は「やっちゃいましょう!」 c. 最近は「ソフトウェアテスト技法練習帳」を解いている 30
31.
どうやっているのか ~一例:QAチームの一員として~ <対応> 2. 隔週で座談会実施 a. 課題ややりたいことの共有 b.
お悩み相談 「XXで困ってるけどどうしてる?」 3. QAチーム定例、TechTalk(LT大会) a. 全体方針や影響の大きいバグの共有 b. グッドプラクティスの紹介 31
32.
これから伸ばしていきたいところ 各事業チームによって事情が異なるので各チームに最適化されたプ ロセスを目指す ● 優れたテストの実施 ○ システム構成の理解、ドメイン知識、テスト技法やプラクティス等を 利用したテスト設計 ●
スピードを落とさずに品質確保する ○ テスト内容(プロダクトごとの手厚さ)や作成するドキュメントなどの 最適化 ○ 自動テストの積極的検討 32
33.
これから伸ばしていきたいところ ● QA(システムテスト以降)実施前の品質を上げる ○ 上流への積極関与:仕様書のレビュー、認識齟齬の防止、各テスト レベルでのテスト ○
チーム全員で品質を作り込む体制 ● 優れたユーザ体験の提供 ○ 上流・企画への積極関与:UI / UX を開発者、プロダクトマネー ジャー、デザイナーとともに良いプロセスで作り上げる 33
34.
どんな人を新たに迎えたいか スキルがあるだけでなく、 より良い品質保証を目指し続ける情熱のある方 ● カルチャーフィット ● エムスリーで案件を自走して対応できる ●
品質保証の何かしらのスペシャリストである ● (将来的に)組織レベルでの品質保証体制の構築・改善ができる 参考:QAエンジニア採用のために、ペルソナを作成してみたお話 34
35.
We're Hiring! QAエンジニア・SET募集中! https://jobs.m3.com/engineer/ 35
36.
ご清聴ありがとうございました 36
Download now