トレードオフスライダーにおける品質について考えてみた

Transcript

1. 2025.01.30 初心者歓迎！クラフトビールを楽しむLT会！登壇資料 トレードオフスライダーにおける 品質について考えてみた
2. Agenda
 
 1. 自己紹介
 2. 会社紹介
 3. 本題
 4. まとめ
 
 
 
 3
 4
 9
 24
 
 
 2
3. 3 Profile 鈴木 Suzuki 自己紹介 2009年よりSIerにて要件定義から運用保守まで幅広く従事。2018年からは某SIer上場企業にてプロジェク トマネージャーとして複数案件をこなした。その後、自社サービスの開発マネージャー兼テックリード として開発に携わった。並行して社内のスクラム開発導入推進に携わり、自らも認定スクラムマスター (CSM)を取得し、いくつかのプロジェクトにてスクラムマスターやプロダクトオーナー、スクラム開発 における開発者として従事。 現在はEM, プロジェクトマネージャー, プリセールス と幅広い領域で業務を遂行しています。
4. 4 所属会社の紹介 ⇒割愛
5. 5 本　題
6. 6 トレードオフスライダー 知ってますか？
7. 7 引用元｜https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck プロジェクトの成功は QCDSのバランスが鍵
8. 8 引用元｜https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck プロジェクトの成功は QCDSのバランスが鍵
9. 9 品質とは？ 少ない欠陥、、、あっバグの数ね！ では、当然優先度は最大ですね。 バグとか当然ゼロですよね いやでもテスト量かも、、 決済周り以外はある程度は許容とかそういうのかな？ いやいや品質というより全部そもそも MAXじゃね？ 優先度とかいいから全部やるんだよ！ ひえっ
10. 10 • 優先度を決めるときに品質とは何かが定義されていない • 優先度を上げるとどうなって、下げるとどうなるか説明できない 課題
11. 11 品質は多面的である
12. 12 ISO/IEC 25010における 8つの品質特性 • 機能適合性（Functional Suitability）・・・・機能が意図した通りに動くか • 性能効率性（Performance Efficiency）・・・要求されたパフォーマンスを発揮できるか • 互換性（Compatibility） ・・・・・・・・・他のシステムやプラットフォームと適切に連携できるか • 使用性（Usability） ・・・・・・・・・・・ユーザーが簡単に理解・操作できるか • 信頼性（Reliability）・・・・・・・・・・・システムが安定して動作し続けるか • セキュリティ（Security） ・・・・・・・・ 適切に保護され、攻撃や不正アクセスを防げるか • 保守性（Maintainability）・・・・・・・・・ システムの修正・変更が容易か • 移植性（Portability）・・・・・・・・・・・異なる環境に適応しやすいか 「品質にはいろんな特性があり、それを すべて満たすのはコスト的に厳しい」 「だからこそ、トレードオフが必要」
13. 13 品質保証(QA)のプロセス
14. 14 品質保証 (Quality Assurance)の実施内容 • ユニットテスト・結合テスト（ JUnit, PyTest, Jest など） • 仕様書・要件定義の厳格なレビュー • エンドユーザーテスト（ UAT） • 負荷テスト（Load Testing）（JMeter, Gatling） • パフォーマンス監視（ APM導入）（New Relic, Datadog） • キャッシュ・DB最適化のガイドライン策定 • クロスブラウザ・クロスデバイステスト • APIテスト（Postman, Newman, RestAssured） • 異なるOS/環境での互換性テスト • ヒューリスティック評価（ UXデザイン原則に基づくチェック） • ユーザビリティテスト（ A/Bテスト, ユーザーテスト） • アクセシビリティチェック（ WCAG基準に準拠） • 耐障害性テスト（Chaos Engineering, フェイルオーバー検証） • SLA/SLOに基づく監視とアラート • セキュリティログ監視（ SIEM導入） • コードレビュー（PRチェック, SonarQube静的解析） • リファクタリングのルール策定 • CI/CD導入でリリース負担を軽減 • コンテナ化（Docker, Kubernetes）で環境依存を削減 • Infrastructure as Code（Terraform, Ansible） • 環境別設定の標準化（ Feature Toggle, 環境変数管理） • 障害復旧訓練（Disaster Recovery Test） • 脆弱性診断（Penetration Testing, OWASP ZAP） • 認証・認可のテスト（ OAuth, JWT, SAML）
15. 15 Kano モデル
16. 16 Kano モデル Kanoモデルは、製品やサービスの品質を「顧客満足度」と「品質特性」の関係で分類する手法です。品質を5つ（当たりまえ品質、一元的品質、魅力的品質、無関 心品質、逆品質）に分け、特性ごとの満足度への影響を分析します。顧客の期待に応じた品質向上や優先順位の判断に役立ちます。 当たりまえ品質（ Must-be Quality） • ユーザーが「当然満たされているべき」と期待している基本的な品質。 • 例: 家電製品が動作すること、システムがエラーなく動くこと。 • 満たさないと不満が発生するが、満たしても特に満足度が上がるわけではない。 一元的品質（ One-dimensional Quality） • あればあるほど満足度が高まり、不足すると不満が発生する品質。 • 例: スマートフォンのバッテリー寿命や処理速度。 • 品質の向上が顧客満足度の向上に直結する。 魅力的品質（ Attractive Quality） • あれば顧客を驚かせ満足度が上がるが、なくても不満にはならない品質。 • 例: サービスの予想外の便利機能やデザインの美しさ。 • ユーザーの期待を超える品質要素。 無関心品質（ Indifferent Quality） • あってもなくても顧客満足度にほとんど影響を与えない品質。 • 例: あまり使われない機能や目立たない仕様。 • 労力をかける優先度が低い品質要素。 逆品質（ Reverse Quality） • あればかえって不満が発生し、ない方が満足度が高まる品質。 • 例: 過剰な通知機能や使いにくい自動操作機能。 • 顧客のニーズや期待に反している要素。
17. 17 当たりまえ品質（ Must-be Quality） • ユーザーが「当然満たされているべき」と期待している基本的な品質。 • 例: 家電製品が動作すること、システムがエラーなく動くこと。 • 満たさないと不満が発生するが、満たしても特に満足度が上がるわけではない。 守りたい・・・ なんかバグと か品質を阻害 する何か
18. 18 品質の優先度を下げるということ 彼らに犠牲になってもらうということ 魅力的品 質 一元的品質
19. 19 当たりまえ品質を 犠牲にしないということが前提条件
20. 20 Kanoモデルと品質保証の関係性（例） • 「当たり前品質」 = 必ずQAを保証（最低限のテスト・動作保証が必須） • 「一元的品質」 = QAを強化すると満足度が向上（負荷テスト、 CI/CD、UX最適化など） • 「魅力的品質」 = 高度なQAは投資対象（AIテスト、UX最適化、自動化テストの強化） 「品質はすべてが同じ重要度ではなく、 Kanoモデル で分類」 「例えば、当たり前品質 は『なければならないもの』、一元的品質 は『あると満足度が上がる』もの。」 「これをQAと結びつけると、 品質の優先度を決める＝ QAのレベル を決める ということになる。」
21. 21 品質特性ごとにどこまで品質保証するかの例 品質特性 (ISO 25010) 当たりまえ品質 (Must-be) 一元的品質 (One-dimensional) 魅力的品質 (Attractive) 機能適合性 (Functional Suitability) 100%の機能正確性保証（全ユニットテスト、主 要機能の結合テスト実施） 高品質保証（結合テスト、E2Eテスト、自動テス トカバレッジ 80%以上） 最適化の追求（AIを活用したテスト自動生 成、高度なテスト分析） 性能効率性 (Performance Efficiency) 最低限のパフォーマンス確保（基本的な負荷テ ストのみ実施） パフォーマンス最適化（詳細な負荷テスト、 キャッシュ最適化） 超高パフォーマンス保証（スケーリングの自 動最適化、負荷分散の最適化） 互換性 (Compatibility) 主要環境での動作保証（特定のOS、ブラウザ のみサポート） 幅広い環境対応（複数OS・ブラウザでの互換 性テスト実施） 完全なプラットフォーム互換（すべてのデバ イスで動作保証） 使用性 (Usability) 最低限のUI/UX基準（基本操作の一貫性を保 つ） UI/UXの強化（ユーザビリティテスト、デザイン ガイドライン準拠） ユーザーエクスペリエンス最適化（A/Bテス ト、自動UIパーソナライズ） 信頼性 (Reliability) 99.9%の可用性保証（基本的なフェイルオー バー対応） 99.99%の可用性保証（マルチリージョン冗長 化） 完全障害耐性（自動復旧、障害予測、ゼロ ダウンタイム設計） セキュリティ (Security) 基本的なセキュリティ基準準拠（認証・暗号化 実装、簡単な脆弱性診断） 高度なセキュリティ対策（定期的な脆弱性診 断、権限管理の強化） AIによるリアルタイム脆弱性監視（ゼロトラス トアーキテクチャ） 保守性 (Maintainability) 基本的なコードレビュー実施（リグレッションテ スト最低限） 継続的デリバリー（CI/CD強化、テスト自動化、 コード品質指標を管理） 自動コード修正、AIリファクタリング（コード品 質保証を完全自動化） 移植性 (Portability) 特定環境向け最適化（オンプレ/クラウドのどち らかを前提） マルチプラットフォーム対応（複数クラウド環境 に適応できる設計） 完全な環境ポータビリティ（どのクラウド環境 でも動作可能なシステム設計） ※プロダクトフェーズが PoCなのか MVPなのか PMFなのかで当たりまえ品質は変わる
22. 22 引用元｜https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck トレードオフスライダーで決めるのはの QAレベル 　⇒品質の優先度を上げる＝ QAプロセスの強化 　⇒品質の優先度を下げる＝ QAの最適化（優先度を決めて実施） 当たりまえ品質を守ったうえで、 一元的品質や魅力的品質のバランスを予算や時間 (納期)と調整
23. 23 引用元｜https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck そもそも品質を品質特 性にブレイクダウンする のもあり
24. 24 まとめ
25. 25 まとめ トレードオフスライダーで決めるのは、品質保証（ QA）レベル • 品質の優先度を決める = どこまで QAを徹底するか？ • 100%の品質保証は不可能、だからこそ「何をどこまで担保するか？」を考える。 Kanoモデルを活用し、品質を分類して QAレベルを決定する • 当たり前品質 → QAの最低保証ライン • 一元的品質 → QAを強化すれば満足度 UP • 魅力的品質 → 高度なQAを導入すると価値 UPだが必須ではない
26. 26 締め • 正直、まだ 「実際に100％適用できていない」 ので、これから試していきたい • でも、この整理をすることで 品質のトレードオフを議論しやすくなる と思っている • 「すべての品質を100%保証するのは不可能」 → だからこそ どう最適化するか？ を考え続ける必要が ある
27. 27 俺たちの戦いはこれからだ
28. 28 Thanks
29. 29 Appendix
30. 30 品質特性＋ Kanoモデルの表（一例） 品質特性 (ISO 25010) 当たりまえ品質 (Must-be) 一元的品質 (One-dimensional) 魅力的品質 (Attractive) 機能適合性 (Functional Suitability) 最低限の正確な機能を提供する 機能が正確で便利になる ユーザーの予測を先読みした動作 性能効率性 (Performance Efficiency) 過度な遅延がない（最低限動作する） 高速レスポンスを保証する 0.1秒以内の超高速処理 互換性 (Compatibility) 主要なプラットフォームで動く 他のシステムとの連携が容易 すべての環境で完全互換 使用性 (Usability) 基本的なUI/UXが使いやすい 直感的な操作性 ゲーミフィケーションを活用したUX 信頼性 (Reliability) ダウンしない（最低限の安定性） システム障害に強い 自動復旧機能付き セキュリティ (Security) データ保護が最低限確保されている 厳格なアクセス制御 AIによるリアルタイム脅威検知 保守性 (Maintainability) ソースコードが最低限変更できる リファクタリングしやすい設計 自動コード最適化ツール導入 移植性 (Portability) OS・ブラウザの基本的な対応 クロスプラットフォーム完全対応 どんな環境でもシームレス動作 ※プロダクトフェーズが PoCなのかMVPなのかPMFなのかで当たりまえ品質は変わる