品質マネジメントで抑えておきたい2つのリスクを見分けて未来に備えよう #yapcjapan

YAPC函館の登壇資料です。

イベントサイト
https://yapcjapan.org/2024hakodate/

プロポーザル
https://fortee.jp/yapc-hakodate-2024/proposal/da4c92fe-0a90-4fd1-9eec-946ce046c1e2

Transcript

1. 品質マネジメントで抑えておきたい 2つのリスクを見分けて未来に備えよう テックタッチ株式会社 巻　宙弥（まき　みちや） YAPC::Hakodate 2024　〜 Open the future 〜 2024/10/5 Sat.
2. 目次 自己紹介 1. 本トークの概要 2. リスクとはなにか？ 3. ２つのリスクを見分ける 4. 事例紹介 5. まとめ 6.
3. システムエンジニア 道内独立系IT企業・札幌市内ベンチャー企業 東証プライム 第三者検証企業 ITコンサルタント 10年 4年 自己紹介 焼き鳥が焼ける QAエンジニア 巻　宙弥（まき　みちや） 主な担当業務 Saasベンダー企業、テックタッチ(株)のQAエンジニア 札幌でフルリモート勤務中 マイブームは #おうちやきとり 経歴 QAプロセス改善、標準化 QAチームメンバー育成 テストプロセス実践・推進 マネージャー 4年
4. 本トークの概要 品質マネジメント 品質保証 品質コントロール 「品質コントロール」と「品質保証」を包括 ※一般に使われている品質管理と概ね同義と考えています ※
5. 本トークの概要 品質マネジメント リスクマネジメント ? ? 「リスクマネジメント」における2つのリスクの見分け方を紹介します。
6. ? ? なぜ、リスクを見分けることが大事なのか？ 品質マネジメント リスクマネジメント
7. ? ? なぜ、リスクを見分けることが大事なのか？ 品質マネジメント リスクマネジメント プロジェクトの成功 製品の品質 影響 影響
8. 3.リスクとはなにか？ 私は、マネジメントと名のつく活動には、根本に必ず「リスク」があると考えています。 普段から何気なく使っている言葉ですが、改めてリスクの意味を整理してみましょう。
9. リスクとはなにか？ 顕在化すると悪影響をもたらす潜在的な事象、 ハザード、または脅威のこと 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf ※JSTQB（Japan Software Testing Qualifications Board）とは？ 日本国内におけるソフトウェアテストに関する資格認定を行う組織です。 国際的なソフトウェアテストの資格認定団体であるISTQB（International Software Testing Qualifications Board）の日本支部として、ソフトウェアテストの知識体系を普及させています。
10. リスクとはなにか？ 目的に対する不確かさの影響 引用）ソフトウェア品質知識体系ガイド （第3版） －SQuBOK Guide V3－ 不確実なイベントや状態で、発生すると プロジェクトの目標にプラスまたはマイナスの影響を 与える可能性があるもの 引用）プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版
11. リスクとはなにか？ 目的を達成する上での不確かさがもたらす影響 ふ たし
12. リスクの例
13. 予期せぬ問題 解決までの時間 リリース日が守れない リスクの例 新しい機能をリリースする際、開発途中 で予期せぬ技術的な問題が発生 計画外のバグ修正や追加のテストが必要になる 開発のスケジュールが遅れ、 リリース日が守れない可能性が出てくる
14. 予期せぬ問題 解決までの時間 リリース日が守れない リスクの例 新しい機能をリリースする際、開発途中 で予期せぬ技術的な問題が発生 計画外のバグ修正や追加のテストが必要になる 開発のスケジュールが遅れ、 リリース日が守れない可能性が出てくる プロジェクトの進行に 悪影響を与える潜在的なリスク
15. 4. 2つのリスクを見分ける 2つのリスクについて、JSTQBの定義を引用しながら、説明します。
16. プロジェクトリスク プロダクトリスク リスクには2つの側面がある 2つのリスクを見分けることがリスクマネジメントの第一歩
17. プロジェクトリスクとは プロジェクトの目的を達成する能力に影響を与える可能性がある。 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 要件の増加 スケジュール遅延 コスト増加 要因 影響
18. プロダクトリスクとは 以下のようなさまざまな負の結果をもたらす可能性がある。 ⚫ ユーザーの不満足 ⚫ 収益、信頼、評判の損失 ⚫ 第三者への損害賠償 ⚫ メンテナンスコストが高い、ヘルプデスクに負荷がかかる ⚫ 刑事罰 ⚫ 極端な場合、身体的な損傷、重傷、または死に至ることもある 引用）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf 機能不足 不十分な応答時間 使いづらさ 脆弱性
19. プロジェクトリスク プロダクトリスク 2つのリスクは相互に影響し合う 相互影響 重要なのは、この2つのリスクが相互に影響し合うという点
20. プロジェクトリスク プロダクトリスク 2つのリスクは相互に影響し合う 相互影響 片方のリスクにだけ対処すると もう片方のリスクが顕在化する可能性がある 重要なのは、この2つのリスクが相互に影響し合うという点
21. 2つのリスクを見分けるプロセスが重要 プロジェクトリスク プロダクトリスク どっちに対処？ このような状態を防ぐには、リスクを見分けるプロセスが重要
22. 5.事例紹介 実際に私が経験したプロジェクトを紹介します。 この事例では、プロジェクトリスクとプロダクトリスクがどのように影響し合ったか紹介します。 注意）現職ではなく過去経歴の中での実例です
23. プロジェクトの状況 事例紹介 遠隔地の開発会社と協業 スクラムガイドに則った開発 頻繁にコミュニケーション スクラム未経験のリーダーで開始 中盤でリーダーが交代
24. 不具合が多発 段階的なリリースが停滞 コミュニケーションエラー 楽観的な報告 リーダーの交代 発生した問題 事例紹介 開発会社のリーダーとのコミュニケーションに問題があり、中盤でリーダーが交代 初回リリースまでなんとか進行したものの、不具合が多発、予定していた段階的な機能リリースが滞る ※アジャイルの観点で、早く市場に投入して利用者のフィードバックを得てから機能をアップデートしていく計画があった ※
25. コミュニケーションのギャップが発生する可能性　　　 リーダー交代によりプロジェクトが不安定になる可能性 　　　　　　　　　　　　　　　　　　　　　　　　 顕在化したリスク プロジェクトリスク 事例紹介 リモートでのコミュニケーションを行っていたものの、リーダーの報告が実態と合ってい ませんでした。 この事実に気づくことがなく、プロジェクト全体の進行状況が適切に把握できず、問題の 早期発見と対処ができませんでした。 中盤でのリーダー交代時のフォローアップが不十分で、プロジェクト全体が不安定とな り、進捗管理やリスクマネジメントの継続性が途切れ、スケジュールの遅延に繋がりまし た。
26. 顕在化したリスク プロダクトリスク 不十分なテスト計画により品質が低下する可能性 機能リリース停滞により製品価値が低下する可能性 事例紹介 初回リリース後に多発した不具合は、リリース前に十分なテストが行われなかったためで した。不十分なテスト計画により、低レベルの不具合が顕在化し、プロダクトの品質を低 下させました。 リリース後の不具合対応に追われた結果、新機能の開発が後回しになり、段階的な機能リ リースが滞りました。これが、製品の価値提供に影響しました。
27. 片方のリスクだけに対処する（アンチパターン） プロジェクトリスク プロダクトリスク 片方だけに対処 ※本スライドでは「特定の問題に対して、一見有効に見えるが実際には問題をより悪化させるか、新たな問題を生み出す可能性が高 い解決方法」を指します ※
28. 不具合が多発 段階的なリリースが停滞 コミュニケーションエラー 楽観的な報告 リーダーの交代 片方のリスクだけに対処していた 事例紹介
29. コミュニケーションエラー 楽観的な報告 リーダーの交代 リリース後に品質問題が発生 事例紹介 不具合が多発 段階的なリリースが停滞 プロジェクトリスクが要因となるその後の影響まで考慮できず、不十分なテスト計画を見過ごしてしまった
30. コミュニケーションのギャップが発生する可能性 リーダー交代によりプロジェクトが不安定になる可能性 不十分なテスト計画により品質が低下する可能性 機能リリース停滞により製品価値が低下する可能性　　 顕在化したリスク プロジェクトリスク プロダクトリスク 事例紹介 注意）実際のプロジェクトはもっと複雑でしたが、今回はわかりやすくシンプルに表現しています。 リスクが特定できなかった
31. コミュニケーションのギャップが発生する可能性 リーダー交代によりプロジェクトが不安定になる可能性 不十分なテスト計画により品質が低下する可能性 機能リリース停滞により製品価値が低下する可能性　　 顕在化したリスク プロジェクトリスク プロダクトリスク 事例紹介 注意）実際のプロジェクトはもっと複雑でしたが、今回はわかりやすくシンプルに表現しています。 最終的にはプロダクトの価値に悪影響を及ぼした
32. プロジェクトリスク プロダクトリスク どちらか見分け もう一方のリスクを特定するプロセスが重要
33. プロジェクトリスク プロダクトリスク 一方のリスクを特定 もう一方のリスクを特定するプロセスが重要
34. リスクの相互作用に注意して交代すべきだった プロジェクトリスク プロダクトリスク リーダー交代によりプロジェクトが不安定になる可能性 コミュニケーションのギャップが発生する可能性 不十分なテスト計画により品質が低下する可能性 機能リリース停滞により製品価値が低下する可能性 相互作用に注意
35. 現在の取組
36. テックタッチの開発プロセス プランニングから参加
37. テックタッチのリリースサイクル テックタッチのリリースサイクルは3ヶ月に一度
38. プランニ ング QA 情報共有会 スプリン トレビュ ー QAがリスクを見分けるプロセス 昨年
39. QA プランニング プランニ ング QA 情報共有会 スプリン トレビュ ー QAがリスクを見分けるプロセス 現在 開発プロセスや体制変更のタイミングでQAプランニングを追加
40. QA プランニング プロジェクトリスクを見分ける テストに必要なドメイン知識が不足する テストに必要なスキルが不足する スケジュールに対しQAのリソースが不足する 要件定義や設計に時間がかかりそう 3ヶ月に一度のリリースに影響を与える可能性はあるか？ リスク要因
41. QA 情報共有会 機能性・使用性・テストプロセスに影響を与える可能性はあるか？ リスク要因 「〜」という表現は顧客が誤解しそうだ 「〜」の手順は使用性を損なう可能性がある 「〜」のようなケースは検討されているか？ この機能はテスト設計が難しそうだ プロダクトリスクを見分ける
42. 最近の事例 開発スケジュール延伸 コードフリーズ延伸
43. 不具合分析によるリスクの特定
44. プロジェクトリスクの最小化を図る 潜在している不具合を検出 テスト戦略 既存機能の不具合や修正機能のデグレードを発見。 リリース直前のプロジェクトリスク顕在化を低減
45. 5.まとめ
46. プロジェクト リスク プロダクト リスク まとめ 品質マネジメント リスクマネジメント 2つのリスクを適切に見分け、相互に影響するリスクも考慮して対処する ことが、リスクマネジメントのベストプラクティスです。
47. 過去から学び　未来に生かす 一般論や先人達の経験、そして私自身の経験 ユーザーにとっての価値、品質を追求していこう
48. 品質マネジメントで抑えておきたい 2つのリスクを見分けて未来に備えよう テックタッチ株式会社 QAエンジニア 巻　宙弥 YAPC::Hakodate 2024 2024/10/5 Sat. ご清聴ありがとうございました