「最後の砦」にならないQAエンジニア。プロダクト開発における新しい品質保証のかたち / QA engineer who doesn't become the "last fort"

2021年11月17日に開催されたWomen Developers Summit に登壇した際に使用した資料となります。

様々な開発手法や技術の発展、DXの推進による顧客のサービス要求スピードの変化によってプロダクト開発における品質作りのかたちは変わりつつあります。これからのプロダクト開発では、QAチームだけでなくプロダクトチーム全体で品質作りに関わっていく必要があります。私が考えるこれからの時代に求められる品質保証のあり方、「お客さまへの価値」をつくる活動を継続的に推進するための取り組みや文化の作り方などを紹介します。品質保証はもはやQAエンジニアだけのものではありません。お客さまに選ばれるサービスを提供することについて一緒に考えてみましょう。

Transcript

1. 1 「最後の砦」にならないQAエンジニア。 プロダクト開発における新しい品質保証のかたち miisan @メルペイ
2. 2 より良い品質を届けるために 本日のアジェンダ 品質・QAエンジニアについて 身のまわりの変化 サービス提供に求められること 02 03 04 01 自己紹介 05
3. About me
 自己紹介
4. 自己紹介 miisan @mii________san 2018年7月よりメルペイに QAエンジニアとして参画。入社直後から iD決 済領域を主に担当し、信用・与信領域など、メルペイサービスの多くの機 能に携わる。現在はエンジニアリングマネージャーとしてプロダクト全体の 品質向上や個人としては女性エンジニアの推進やスタートアップの QA チーム立ち上げなどにも関わっている。 趣味はカメラと旅行。 以前は週末トラベラーとしていろんな場所にフラッと旅してました ✈ QA歴：5年 Merpay歴：3年 QA Engineer Manager at Merpay, Inc.
5. Today’s goal
 本日のお持ちかえり
6. 本日のお持ちかえり
 1 2 3 チーム全員の役割の大切さ
 「新しい価値」を継続的に届けるために大切なこと
 全員品質

7. What’s Quality?
 品質ってなに？
8. 品質とは
 本来備わっている特性の集まりが、要 求事項を満たす程度
 品物やサービスの顧客からの要求事項や、 ニーズに合っているかを決める特性
 信頼性が高い状態
 バグがない状態

9. 品質とは
 • 致命的な不具合が無い • 使いやすい、分かりやすい（時間を奪わない） • 止まらない(すぐ復旧可能)、間違えない、不正に使われない (安全・安心) これが充足されれば当たり前と受け止められるが、不充足であれば顧客の不満を引き起こす品質 これが充足されなくても顧客が不満にならないが、充足されれば、顧客に満足を与え、喜びをもたらす品質 • 他社に無い機能 / 分かり易さ / 直感で操作できる • 初めての体験の提供（素早い変化） / 継続的にお客さまへサービスが提供される体験 魅力的品質 当り前品質 ※品質が良いとは、 仕様通りに動くことやバグが無いサービス だけをさすわけではない。
10. What’s QA Engineer?
 QA Engineerってなに？
11. QA Engineerとは
 Quality Assurance (品質保証) 品質保証に特化したソフトウェアエンジニア
12. QA Engineerのイメージ

13. QA Engineerのイメージ

14. QA Engineerのイメージ

15. QA Engineerのイメージ
 品質を”守る”「 最後の砦 」
16. 本日のテーマ
 「最後の砦」にならないQAエンジニア...????

17. Any changes around you
 身のまわりの変化
18. 身のまわりの変化
 開発手法の発展
 DXの進化
 1 2
19. 開発手法の発展
 ウォーターフォール・モデル
 アジャイル開発
 プロトタイプ・モデル
 スパイラル・モデル

20. DXの進化
 DX：Digital Transformation 
 ITの浸透が、人々の生活をあ らゆる面でより良い方向に変 化させる。 ウメオ大学（スウェーデン）の エリック・ストルターマン教授が2004年 に提唱した概念。 企業がビジネス環境の激しい変化 に対応し、データとデジタル技術を 活用して、顧客や社会のニーズを基 に、製品やサービス、ビジネスモデ ルを変革するとともに、業務そのも のや、組織、プロセス、企業文化・風 土を変革し、競争上の優位性を確立 すること。 デジタルトランスフォーメーションを推進するためのガイドライン （DX推進ガイドライン） Ver. 1.0　経済産業省
21. 生活スタイルの変化
 これまでなかった日常体験の実現 買い物/注文 支払い/資産管理 家電操作 コミュニケーション SNS 医療 問診 移動手段
22. 業務スタイルの変化
 これまでなかった仕事・業務体験の実現 会議 コミュニケーション 情報管理/セキュリティー 契約書/請求書 問い合わせ 会計/経費管理 AI・bot
23. DXの本質
 ”体験価値”を問い直すこと 一人ひとりの価値を捉え、個別化と包摂を実現する体験 を提供する
24. DXの本質
 ”体験価値”を問い直すこと 一人ひとりの価値を捉え、個別化と包摂を実現する体験 を提供する ユーザー体験を「揺らす」 個々が何を大切にしているかを知り、寄り添いつつ、既存 サービスを超えた新しい体験の提供をしていく ※尾原和啓 宮田裕章 山口周（2021）『ソフトウェア開発の持つべき文化 DX進化　つながりがリブートされた世界の先』 MdN
25. Important things for providing services
 サービス提供に求められること
26. お客さまにより早く、より確実に、より良いサービスを継続的に届けること
 サービス提供に求められること
 顧客の要求スピード変化 不確実性が高いニーズ モノの価値基準の変化
27. How to Build Quality
 より良い品質を届けるために
28. 全てのプロジェクト・サービスで品質の定義は常に変化する。 条件により常に変化する品質の中でベストプラクティスを追い求める。 顧客満足度 変化しない定義：「品質」とは「誰かに対する価値」 What’s Quality?
29. 「品質」を作り上げるには、プロセス・チーム・プロダクトの相互向上が必須
 3つの視点
 Process Product Team
30. 「お客さまへの価値」をつくるための取り組み
 Factから目をそらさない 1 全員でゴールを握る 2 原因分析から振り返る 3 習慣化するまで繰り返す 4
31. さまざまな課題
 リリースサイクルがう まくまわらない 技術的負債の返済 が追いつかない... 初期品質が低い 優先度がわからず着手すべきタ スクがわからない
32. 現状を誰が見ても同じ認識で理解できる状態にする Factから目をそらさない
 リリースサイクルが 回らない ・どんなフローが標準に なっている？ ・何にどれくらい時間が かかっているのか？ 負債の蓄積 初期品質が低い ・不具合発生率は？ ・開発期間は？ ・どんな要因で不具合が 発生したのか？ 作業効率の改善 ・真のブロッカーになりう る負債とは何か？ ・いつまでに対応すべき 問題があるのか？ ・情報が分散していない か？ ・タスクの見える化、タス クの一元管理はできてい るか？
33. 現状を誰が見ても同じ認識で理解できる状態にする Factから目をそらさない
 共通認識としての「課題感」が必要 曖昧なもの、雰囲気で理解していたことを明確にすることで、立場や役割、個人によって異なって見えてい たものが1つに重なり合っていく。 - 粒度が異なる - 温度感が違う - 優先度の認識齟齬 ポイント 課題の”やばさ”を定量的な指標に落としてみる (チームみんなで把握できる指標 )
34. 新しい文化を作り上げていくためには組織内で連携・協調する姿勢が必要 全員でゴールを握る
 個人型チーム 協業型チーム 個人目標 共通目標
35. 新しい文化を作り上げていくためには組織内で連携・協調する姿勢が必要 全員でゴールを握る
 チームで取り組む意味を理解する どんな目的があるのか明確であれば、なぜやらなければいけないのか理解しやすい。 Factが明確になっていれば、どのような課題があるのか把握できているため課題解消しやすい。 ポイント プロジェクトやサービスは個人のものではない。 ゴールテープの切り方がわかっていればそれぞれが進むべき道も自ずと決まる。
36. 整理した課題を振り返り、具体的な知見をチーム全員にシェアする 原因分析から振り返る
 振り返りフローやサイクルの構築 ・KPT プロダクトや案件の定期的な振り返りの実施 ・Postmortem インシデントから学び、再発防止策を決める 具体的なバグ分析 ・分析 問題や事象をカテゴリーに分ける ・優先度 期日や事象の温度感を分ける
37. 整理した課題を振り返り、具体的な知見をチーム全員にシェアする 原因分析から振り返る
 振り返りフローやサイクルの構築 ・KPT プロダクトや案件の定期的な振り返りの実施 ・Postmortem インシデントから学び、再発防止策を決める 具体的なバグ分析 ・分析 問題や事象をカテゴリーに分ける ・優先度 期日や事象の温度感を分ける
38. 振り返りフローやサイクルの構築について 原因分析から振り返る
 KPT K：keep ＝ 良かったこと(今後も続ける) P：problem＝ 悪かったこと(今後はやめる) T：try ＝ 次に挑戦すること -> 課題を放置しないように可視化する Postmortem インシデントを検知したら課題管理ツールに 問題を報告し周知する その後、問題が収束したらチームで振り返り、ポス トモーテムを作成する
39. 整理した課題を振り返り、具体的な知見をチーム全員にシェアする 原因分析から振り返る
 振り返りフローやサイクルの構築 ・KPT プロダクトや案件の定期的な振り返りの実施 ・Postmortem インシデントから学び、再発防止策を決める 具体的なバグ分析 ・分析 問題や事象をカテゴリーに分ける ・優先度 期日や事象の温度感を分ける
40. 具体的なバグ分析について 原因分析から振り返る
 分析 ・仕様漏れ/仕様考慮漏れ/仕様不備 ・表記/デザイン不備 ・運用/オペレーションミス ・機能改善 ・実装不備 -> 要素をカテゴリーに分類する 優先度 ・対応期限がある場合「期日あり」と明確化、未定 のものには「期日なし」と明記する ・温度感を明確にするための基準/ルールを設け、 プライオリティーをタスクや問題に定義
41. 整理した課題を振り返り、具体的な知見をチーム全員にシェアする 原因分析から振り返る
 同じ問題を繰り返さないための背景を知る 振り返りは誰かを責めるためのものではなく、あくまで ”失敗から学ぶ”活動である。 新しく発見した知見や再発防止策は別チームにも共有し、同じことが起きないように全員で習慣化してい く。ここで重要なことは、人ではなく「仕組み」で解決すること。関係者に閉じず全体に 対して共有し仕組み化することで、人が変化しても同じことが起こらないようにする。 ポイント Factは常に変わる。 定期的に変わっていく Factを振り返り、事実にそったソリューションに取り組む必要がある。
42. 長期的な視点を持ち、継続すること 習慣化するまで繰り返す
 プロジェクト ・ 案件 良かった点 ・ 改善点 新しいトライ 振り返り
43. 長期的な視点を持ち、継続すること 習慣化するまで繰り返す
 課題の累積や慣れ親しんだ文化は、簡単にはなくならない 品質とは「誰かにとっての価値」であり、この価値は常に変化していく。だからこそ条件によって常に変化す る中で、実際に手を動かし、いろんな取り組みからフィードバックを得ることや粘り強く継続することで新し いプロセスが生まれる。 ポイント 長期的な視点をもって作られた新しい文化は、組織の資産となり簡単に失われない。
44. 「お客さまへの価値」をつくるための取り組み
 問題が一つの要因だけで構成されていることは少ない 問題を多角的に見つめ、定量的に分析する 良い点も改善点も客観視し、継続して取り組む お客さまへの価値はチームでつくる
45. 「お客さまへの価値」をつくるための取り組み -QA ver.-
 要件定義 1 設計・実施 2 探索的テスト 3 不具合分析 4
46. 不具合を見つけるのではなく、不具合をつくらない取り組み 要件定義
 • お客さま視点の要件チェック・レビュー • 他のマイクロサービスや他チームへの影響範囲の考慮 • 新しい仕様追加による既存システムへの影響 • 過去経験から考慮すべき観点の提案 ◦ 過去にあった類似の障害、不具合に対する考慮がされているか • PMやディレクターの相談役として並走 上流工程で仕様の考慮漏れなどを検出することで手戻り工数を削減できる 関係者で細かい認識合わせができることで認識齟齬による不具合を防げる
47. 認識齟齬を減らし、より早く確実にテスト実施できる方法を模索する 設計・実施
 • 全体のテスト計画およびテスト自動化計画 • テストケースの作成 ◦ テストケースレビュー ◦ テストコードの実装 • リグレッションテスト ◦ APIテスト・UIテスト ◦ リグレッションテスト自動化 テストケースという詳細イメージを共有し、認識齟齬を早期に解消する 手動テストと自動テストを組み合わせリリースサイクルを早める
48. お客さま体験を知り、仕様を超えた体験を追求する 探索的テスト
 • ドッグフーディング（dogfooding） ◦ 完成されたプロダクトを関係者で動かし、認識齟齬や魅力的品質の　向上 につながるポイントを探す • おさわり会 ◦ チームの垣根を超え、1ユーザーとしてプロダクトをさわる ◦ 多角的で異なる意見をフィードバックしあう 仕様以上の「価値」提供を追求することができる デザインや仕様の小さなズレも関係者ですり合わせることができる
49. 網（さまざまな取り組み）をすり抜け発生した問題の深堀りによる改善 不具合分析
 • 問題の背景・原因を分析する ◦ 仕様の認識不足：kick offの重要性・仕様変更時の連携強化 ◦ 人的オペレーション：人員不足・手動オペレーションの改善 • 情報は誰でもいつでもアクセスできるようにする ◦ 不具合分析ボードを管理し、定期的に情報を更新していく ◦ 問題発生率の変化や分析結果の改善についてはチームに展開する データドリブンな品質保証を行うことで、効果的な品質改善につながる 目には見えない品質を可視化し、定量的にはかることができる
50. 「お客さまへの価値」をつくるための取り組み -QA ver.-
 
 テストすること以外で品質を向上させる • テスト以外のすべての工程に関わる • 最後にテストするのではなく、ずっとテストし続ける
51. Summary
 まとめ
52. 「不具合」が発生した時の対応
 
 テストは ちゃんとした？ なんでその問題を 見つけられなかったの？ QAチームに問題の原因を尋ねていませんか？ ・・・。
53. ポイント1
 「最後の砦」としてのQAのポジション
 テストすることがQAの主な役割とすると、関わる領域範囲が狭い。 また、工程の最後になりリリース直前での「守り」しかできない。 Design Requirements Specing Coding Deploy Testing QAの役割

54. ポイント2
 どんなに強固な「網」でも完全なものはない
 テストだけを強化しても、ソフトウェア開発は「テスト」と「その他」 と、2つのプロセスにわけられるほど単純なものではない。 Design Requirements Specing Coding Deploy Testing
55. 大事なポイント
 テストという「網」は最終工程にある
 「網」に完全なものはない
 1 2 品質保証するには、 1つのステップや個人などですべてを担保できるものではな い。”完璧なテスト”は存在しないので、不具合がないことは証明できない。つまり、 ソフトウェアをリリースする際は、常に何らかのリスクがつきまとうことを念頭にい れておく必要がある。
56. まとめ
 品質に対するチーム全体のオーナーシップ「全員品質」
 「網」（= テスト）は完全でない 
 ⇔ 特定の工程（例えばテスト）に依存せず、 「全プロセス（全員）」で信頼性の総和を向 上させる必要がある
 
 
 「不具合を見つける」から「不具合を未然に防ぐ」
 ⇔ 仕様・影響範囲・運用想定すべてを鑑み、不具合をテストフェーズで見つけるのでは なく、開発プロセス全体から生まれうる不具合の種をつんでおく

57. 全員品質とは
 役割や立場を越境し、 One Teamで品質を作り上げること
58. 全員品質の考え方
 テストチームの責任と考えず、品質に対するチーム全体の責任と捉える
 テスト ちゃんとした？ 「不具合」が発生した時の対応 問題を一緒に 振り返ろう！！！ Bad case😥 Good case😊
59. 全員で品質と向き合う意味
 プロジェクトを計画通りに進行し、お客さまにサービスを継続的に届ける
 安心安全リリース 新しい価値提供 リソース増加 保守運用コストの低減 「スピード」と「品質」をトレードオフさせない！

60. Look back
 振り返り
61. 本日のテーマの振り返り
 「最後の砦」にならないQAエンジニア...????

62. 本日のテーマの振り返り
 「最後の砦」にならず、One teamで作り上げる品質保証をリードする

63. 本日のテーマの振り返り
 「最後の砦」にならず、One teamで作り上げる品質保証をリードする

64. Last message
 QAエンジニアの皆さんへ
65. QAエンジニアに必要なこと
 QA活動には終わりがない
 すべてのフェーズに関わるため、QA活動には終わりがない
 開発プロセスすべてでQA活動を行うためのエンジニアスキルが求 められる！
 だからこそ私たちはあらゆるスキルを身につける必要がある
 
 役割や立場を越境し、あらゆる境界線を越えていこう✈
 「信頼」の重要性
 QAエンジニアの仕事は”信頼の先”に成り立つ
 お客さまとの信頼関係、プロダクトメンバーとの信頼関係の 先により良い品質保証活動がある
 
 最後の「守り」だけでなく、「守り」も「攻め」も　できるQAエン ジニアになろう！

66. QAエンジニアに必要なこと QAエンジニアは、お客さまに選ばれる品質のサービスを 継続的に提供するために関係者と協力しあらゆることをする！ 誰かにとっての価値を作る活動を行う！
67. Thank you
 by @mii________san