Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

miisan
November 17, 2021

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

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

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

miisan

November 17, 2021
Tweet

More Decks by miisan

Other Decks in Technology

Transcript

  1. 1
    「最後の砦」にならないQAエンジニア。
    プロダクト開発における新しい品質保証のかたち
    miisan @メルペイ

    View full-size slide

  2. 2
    より良い品質を届けるために
    本日のアジェンダ
    品質・QAエンジニアについて
    身のまわりの変化
    サービス提供に求められること
    02
    03
    04
    01 自己紹介
    05

    View full-size slide

  3. About me

    自己紹介

    View full-size slide

  4. 自己紹介
    miisan @mii________san
    2018年7月よりメルペイに QAエンジニアとして参画。入社直後から iD決
    済領域を主に担当し、信用・与信領域など、メルペイサービスの多くの機
    能に携わる。現在はエンジニアリングマネージャーとしてプロダクト全体の
    品質向上や個人としては女性エンジニアの推進やスタートアップの QA
    チーム立ち上げなどにも関わっている。
    趣味はカメラと旅行。
    以前は週末トラベラーとしていろんな場所にフラッと旅してました ✈
    QA歴:5年
    Merpay歴:3年
    QA Engineer Manager at Merpay, Inc.

    View full-size slide

  5. Today’s goal

    本日のお持ちかえり

    View full-size slide

  6. 本日のお持ちかえり

    1
    2
    3
    チーム全員の役割の大切さ

    「新しい価値」を継続的に届けるために大切なこと

    全員品質


    View full-size slide

  7. What’s Quality?

    品質ってなに?

    View full-size slide

  8. 品質とは

    本来備わっている特性の集まりが、要
    求事項を満たす程度

    品物やサービスの顧客からの要求事項や、
    ニーズに合っているかを決める特性

    信頼性が高い状態

    バグがない状態


    View full-size slide

  9. 品質とは

    ● 致命的な不具合が無い
    ● 使いやすい、分かりやすい(時間を奪わない)
    ● 止まらない(すぐ復旧可能)、間違えない、不正に使われない (安全・安心)
    これが充足されれば当たり前と受け止められるが、不充足であれば顧客の不満を引き起こす品質
    これが充足されなくても顧客が不満にならないが、充足されれば、顧客に満足を与え、喜びをもたらす品質
    ● 他社に無い機能 / 分かり易さ / 直感で操作できる
    ● 初めての体験の提供(素早い変化) / 継続的にお客さまへサービスが提供される体験
    魅力的品質
    当り前品質
    ※品質が良いとは、 仕様通りに動くことやバグが無いサービス だけをさすわけではない。

    View full-size slide

  10. What’s QA Engineer?

    QA Engineerってなに?

    View full-size slide

  11. QA Engineerとは

    Quality Assurance (品質保証)
    品質保証に特化したソフトウェアエンジニア

    View full-size slide

  12. QA Engineerのイメージ


    View full-size slide

  13. QA Engineerのイメージ


    View full-size slide

  14. QA Engineerのイメージ


    View full-size slide

  15. QA Engineerのイメージ

    品質を”守る”「 最後の砦 」

    View full-size slide

  16. 本日のテーマ

    「最後の砦」にならないQAエンジニア...????


    View full-size slide

  17. Any changes around you

    身のまわりの変化

    View full-size slide

  18. 身のまわりの変化

    開発手法の発展

    DXの進化

    1
    2

    View full-size slide

  19. 開発手法の発展

    ウォーターフォール・モデル
 アジャイル開発

    プロトタイプ・モデル
 スパイラル・モデル


    View full-size slide

  20. DXの進化

    DX:Digital Transformation 

    ITの浸透が、人々の生活をあ
    らゆる面でより良い方向に変
    化させる。
    ウメオ大学(スウェーデン)の
    エリック・ストルターマン教授が2004年
    に提唱した概念。
    企業がビジネス環境の激しい変化
    に対応し、データとデジタル技術を
    活用して、顧客や社会のニーズを基
    に、製品やサービス、ビジネスモデ
    ルを変革するとともに、業務そのも
    のや、組織、プロセス、企業文化・風
    土を変革し、競争上の優位性を確立
    すること。
    デジタルトランスフォーメーションを推進するためのガイドライン
    (DX推進ガイドライン) Ver. 1.0 経済産業省

    View full-size slide

  21. 生活スタイルの変化

    これまでなかった日常体験の実現
    買い物/注文 支払い/資産管理
    家電操作 コミュニケーション
    SNS
    医療
    問診
    移動手段

    View full-size slide

  22. 業務スタイルの変化

    これまでなかった仕事・業務体験の実現
    会議 コミュニケーション 情報管理/セキュリティー
    契約書/請求書 問い合わせ
    会計/経費管理
    AI・bot

    View full-size slide

  23. DXの本質

    ”体験価値”を問い直すこと
    一人ひとりの価値を捉え、個別化と包摂を実現する体験
    を提供する

    View full-size slide

  24. DXの本質

    ”体験価値”を問い直すこと
    一人ひとりの価値を捉え、個別化と包摂を実現する体験
    を提供する
    ユーザー体験を「揺らす」
    個々が何を大切にしているかを知り、寄り添いつつ、既存
    サービスを超えた新しい体験の提供をしていく
    ※尾原和啓 宮田裕章 山口周(2021)『ソフトウェア開発の持つべき文化
    DX進化 つながりがリブートされた世界の先』
    MdN

    View full-size slide

  25. Important things for providing services

    サービス提供に求められること

    View full-size slide

  26. お客さまにより早く、より確実に、より良いサービスを継続的に届けること

    サービス提供に求められること

    顧客の要求スピード変化
    不確実性が高いニーズ モノの価値基準の変化

    View full-size slide

  27. How to Build Quality

    より良い品質を届けるために

    View full-size slide

  28. 全てのプロジェクト・サービスで品質の定義は常に変化する。
    条件により常に変化する品質の中でベストプラクティスを追い求める。
    顧客満足度
    変化しない定義:「品質」とは「誰かに対する価値」
    What’s Quality?

    View full-size slide

  29. 「品質」を作り上げるには、プロセス・チーム・プロダクトの相互向上が必須

    3つの視点

    Process
    Product
    Team

    View full-size slide

  30. 「お客さまへの価値」をつくるための取り組み

    Factから目をそらさない
    1
    全員でゴールを握る
    2
    原因分析から振り返る
    3
    習慣化するまで繰り返す
    4

    View full-size slide

  31. さまざまな課題

    リリースサイクルがう
    まくまわらない
    技術的負債の返済
    が追いつかない...
    初期品質が低い
    優先度がわからず着手すべきタ
    スクがわからない

    View full-size slide

  32. 現状を誰が見ても同じ認識で理解できる状態にする
    Factから目をそらさない

    リリースサイクルが
    回らない
    ・どんなフローが標準に
    なっている?
    ・何にどれくらい時間が
    かかっているのか?
    負債の蓄積
    初期品質が低い
    ・不具合発生率は?
    ・開発期間は?
    ・どんな要因で不具合が
    発生したのか?
    作業効率の改善
    ・真のブロッカーになりう
    る負債とは何か?
    ・いつまでに対応すべき
    問題があるのか?
    ・情報が分散していない
    か?
    ・タスクの見える化、タス
    クの一元管理はできてい
    るか?

    View full-size slide

  33. 現状を誰が見ても同じ認識で理解できる状態にする
    Factから目をそらさない

    共通認識としての「課題感」が必要
    曖昧なもの、雰囲気で理解していたことを明確にすることで、立場や役割、個人によって異なって見えてい
    たものが1つに重なり合っていく。
    - 粒度が異なる
    - 温度感が違う
    - 優先度の認識齟齬
    ポイント
    課題の”やばさ”を定量的な指標に落としてみる (チームみんなで把握できる指標 )

    View full-size slide

  34. 新しい文化を作り上げていくためには組織内で連携・協調する姿勢が必要
    全員でゴールを握る

    個人型チーム 協業型チーム
    個人目標 共通目標

    View full-size slide

  35. 新しい文化を作り上げていくためには組織内で連携・協調する姿勢が必要
    全員でゴールを握る

    チームで取り組む意味を理解する
    どんな目的があるのか明確であれば、なぜやらなければいけないのか理解しやすい。
    Factが明確になっていれば、どのような課題があるのか把握できているため課題解消しやすい。
    ポイント
    プロジェクトやサービスは個人のものではない。
    ゴールテープの切り方がわかっていればそれぞれが進むべき道も自ずと決まる。

    View full-size slide

  36. 整理した課題を振り返り、具体的な知見をチーム全員にシェアする
    原因分析から振り返る

    振り返りフローやサイクルの構築
    ・KPT
    プロダクトや案件の定期的な振り返りの実施
    ・Postmortem
    インシデントから学び、再発防止策を決める
    具体的なバグ分析
    ・分析
    問題や事象をカテゴリーに分ける
    ・優先度
    期日や事象の温度感を分ける

    View full-size slide

  37. 整理した課題を振り返り、具体的な知見をチーム全員にシェアする
    原因分析から振り返る

    振り返りフローやサイクルの構築
    ・KPT
    プロダクトや案件の定期的な振り返りの実施
    ・Postmortem
    インシデントから学び、再発防止策を決める
    具体的なバグ分析
    ・分析
    問題や事象をカテゴリーに分ける
    ・優先度
    期日や事象の温度感を分ける

    View full-size slide

  38. 振り返りフローやサイクルの構築について
    原因分析から振り返る

    KPT
    K:keep = 良かったこと(今後も続ける)
    P:problem= 悪かったこと(今後はやめる)
    T:try = 次に挑戦すること
    -> 課題を放置しないように可視化する
    Postmortem
    インシデントを検知したら課題管理ツールに
    問題を報告し周知する
    その後、問題が収束したらチームで振り返り、ポス
    トモーテムを作成する

    View full-size slide

  39. 整理した課題を振り返り、具体的な知見をチーム全員にシェアする
    原因分析から振り返る

    振り返りフローやサイクルの構築
    ・KPT
    プロダクトや案件の定期的な振り返りの実施
    ・Postmortem
    インシデントから学び、再発防止策を決める
    具体的なバグ分析
    ・分析
    問題や事象をカテゴリーに分ける
    ・優先度
    期日や事象の温度感を分ける

    View full-size slide

  40. 具体的なバグ分析について
    原因分析から振り返る

    分析
    ・仕様漏れ/仕様考慮漏れ/仕様不備
    ・表記/デザイン不備
    ・運用/オペレーションミス
    ・機能改善
    ・実装不備
    -> 要素をカテゴリーに分類する
    優先度
    ・対応期限がある場合「期日あり」と明確化、未定
    のものには「期日なし」と明記する
    ・温度感を明確にするための基準/ルールを設け、
    プライオリティーをタスクや問題に定義

    View full-size slide

  41. 整理した課題を振り返り、具体的な知見をチーム全員にシェアする
    原因分析から振り返る

    同じ問題を繰り返さないための背景を知る
    振り返りは誰かを責めるためのものではなく、あくまで ”失敗から学ぶ”活動である。
    新しく発見した知見や再発防止策は別チームにも共有し、同じことが起きないように全員で習慣化してい
    く。ここで重要なことは、人ではなく「仕組み」で解決すること。関係者に閉じず全体に
    対して共有し仕組み化することで、人が変化しても同じことが起こらないようにする。
    ポイント
    Factは常に変わる。
    定期的に変わっていく Factを振り返り、事実にそったソリューションに取り組む必要がある。

    View full-size slide

  42. 長期的な視点を持ち、継続すること
    習慣化するまで繰り返す

    プロジェクト

    案件
    良かった点

    改善点
    新しいトライ
    振り返り

    View full-size slide

  43. 長期的な視点を持ち、継続すること
    習慣化するまで繰り返す

    課題の累積や慣れ親しんだ文化は、簡単にはなくならない
    品質とは「誰かにとっての価値」であり、この価値は常に変化していく。だからこそ条件によって常に変化す
    る中で、実際に手を動かし、いろんな取り組みからフィードバックを得ることや粘り強く継続することで新し
    いプロセスが生まれる。
    ポイント
    長期的な視点をもって作られた新しい文化は、組織の資産となり簡単に失われない。

    View full-size slide

  44. 「お客さまへの価値」をつくるための取り組み

    問題が一つの要因だけで構成されていることは少ない
    問題を多角的に見つめ、定量的に分析する
    良い点も改善点も客観視し、継続して取り組む
    お客さまへの価値はチームでつくる

    View full-size slide

  45. 「お客さまへの価値」をつくるための取り組み -QA ver.-

    要件定義
    1
    設計・実施
    2
    探索的テスト
    3
    不具合分析
    4

    View full-size slide

  46. 不具合を見つけるのではなく、不具合をつくらない取り組み
    要件定義

    ● お客さま視点の要件チェック・レビュー
    ● 他のマイクロサービスや他チームへの影響範囲の考慮
    ● 新しい仕様追加による既存システムへの影響
    ● 過去経験から考慮すべき観点の提案
    ○ 過去にあった類似の障害、不具合に対する考慮がされているか
    ● PMやディレクターの相談役として並走
    上流工程で仕様の考慮漏れなどを検出することで手戻り工数を削減できる
    関係者で細かい認識合わせができることで認識齟齬による不具合を防げる

    View full-size slide

  47. 認識齟齬を減らし、より早く確実にテスト実施できる方法を模索する
    設計・実施

    ● 全体のテスト計画およびテスト自動化計画
    ● テストケースの作成
    ○ テストケースレビュー
    ○ テストコードの実装
    ● リグレッションテスト
    ○ APIテスト・UIテスト
    ○ リグレッションテスト自動化
    テストケースという詳細イメージを共有し、認識齟齬を早期に解消する
    手動テストと自動テストを組み合わせリリースサイクルを早める

    View full-size slide

  48. お客さま体験を知り、仕様を超えた体験を追求する
    探索的テスト

    ● ドッグフーディング(dogfooding)
    ○ 完成されたプロダクトを関係者で動かし、認識齟齬や魅力的品質の 向上
    につながるポイントを探す
    ● おさわり会
    ○ チームの垣根を超え、1ユーザーとしてプロダクトをさわる
    ○ 多角的で異なる意見をフィードバックしあう
    仕様以上の「価値」提供を追求することができる
    デザインや仕様の小さなズレも関係者ですり合わせることができる

    View full-size slide

  49. 網(さまざまな取り組み)をすり抜け発生した問題の深堀りによる改善
    不具合分析

    ● 問題の背景・原因を分析する
    ○ 仕様の認識不足:kick offの重要性・仕様変更時の連携強化
    ○ 人的オペレーション:人員不足・手動オペレーションの改善
    ● 情報は誰でもいつでもアクセスできるようにする
    ○ 不具合分析ボードを管理し、定期的に情報を更新していく
    ○ 問題発生率の変化や分析結果の改善についてはチームに展開する
    データドリブンな品質保証を行うことで、効果的な品質改善につながる
    目には見えない品質を可視化し、定量的にはかることができる

    View full-size slide

  50. 「お客さまへの価値」をつくるための取り組み -QA ver.-


    テストすること以外で品質を向上させる
    ● テスト以外のすべての工程に関わる
    ● 最後にテストするのではなく、ずっとテストし続ける

    View full-size slide

  51. Summary

    まとめ

    View full-size slide

  52. 「不具合」が発生した時の対応


    テストは
    ちゃんとした?
    なんでその問題を
    見つけられなかったの?
    QAチームに問題の原因を尋ねていませんか?
    ・・・。

    View full-size slide

  53. ポイント1

    「最後の砦」としてのQAのポジション

    テストすることがQAの主な役割とすると、関わる領域範囲が狭い。
    また、工程の最後になりリリース直前での「守り」しかできない。
    Design
    Requirements
    Specing
    Coding
    Deploy
    Testing
    QAの役割


    View full-size slide

  54. ポイント2

    どんなに強固な「網」でも完全なものはない

    テストだけを強化しても、ソフトウェア開発は「テスト」と「その他」
    と、2つのプロセスにわけられるほど単純なものではない。
    Design
    Requirements
    Specing
    Coding
    Deploy
    Testing

    View full-size slide

  55. 大事なポイント

    テストという「網」は最終工程にある

    「網」に完全なものはない

    1
    2
    品質保証するには、 1つのステップや個人などですべてを担保できるものではな
    い。”完璧なテスト”は存在しないので、不具合がないことは証明できない。つまり、
    ソフトウェアをリリースする際は、常に何らかのリスクがつきまとうことを念頭にい
    れておく必要がある。

    View full-size slide

  56. まとめ

    品質に対するチーム全体のオーナーシップ「全員品質」

    「網」(= テスト)は完全でない 

    ⇔ 特定の工程(例えばテスト)に依存せず、 「全プロセス(全員)」で信頼性の総和を向
    上させる必要がある



    「不具合を見つける」から「不具合を未然に防ぐ」

    ⇔ 仕様・影響範囲・運用想定すべてを鑑み、不具合をテストフェーズで見つけるのでは
    なく、開発プロセス全体から生まれうる不具合の種をつんでおく


    View full-size slide

  57. 全員品質とは

    役割や立場を越境し、
    One Teamで品質を作り上げること

    View full-size slide

  58. 全員品質の考え方

    テストチームの責任と考えず、品質に対するチーム全体の責任と捉える

    テスト
    ちゃんとした?
    「不具合」が発生した時の対応
    問題を一緒に
    振り返ろう!!!
    Bad case😥 Good case😊

    View full-size slide

  59. 全員で品質と向き合う意味

    プロジェクトを計画通りに進行し、お客さまにサービスを継続的に届ける

    安心安全リリース
    新しい価値提供
    リソース増加
    保守運用コストの低減
    「スピード」と「品質」をトレードオフさせない!


    View full-size slide

  60. Look back

    振り返り

    View full-size slide

  61. 本日のテーマの振り返り

    「最後の砦」にならないQAエンジニア...????


    View full-size slide

  62. 本日のテーマの振り返り

    「最後の砦」にならず、One teamで作り上げる品質保証をリードする


    View full-size slide

  63. 本日のテーマの振り返り

    「最後の砦」にならず、One teamで作り上げる品質保証をリードする


    View full-size slide

  64. Last message

    QAエンジニアの皆さんへ

    View full-size slide

  65. QAエンジニアに必要なこと

    QA活動には終わりがない

    すべてのフェーズに関わるため、QA活動には終わりがない

    開発プロセスすべてでQA活動を行うためのエンジニアスキルが求
    められる!

    だからこそ私たちはあらゆるスキルを身につける必要がある


    役割や立場を越境し、あらゆる境界線を越えていこう✈

    「信頼」の重要性

    QAエンジニアの仕事は”信頼の先”に成り立つ

    お客さまとの信頼関係、プロダクトメンバーとの信頼関係の
    先により良い品質保証活動がある


    最後の「守り」だけでなく、「守り」も「攻め」も できるQAエン
    ジニアになろう!


    View full-size slide

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

    View full-size slide

  67. Thank you

    by @mii________san

    View full-size slide