アジャイル開発やスクラムを実践する場において、関わりの強い品質・メトリクスを整理してみようとおもいます。考えながら書いているので、これでばっちりになる気がしませんが、Google Geminiの力を借りてまとめてみます。
きっかけ
品質の話をするときに、必ずといっていいほど、人によって考え方が異なるからです。
また、こういうときによく登場する品質特性は便利なんですが、開発未経験の人に説明しにくく、サイトを比べると書いていることが違っていたりするので(訳が異なるのかしら)、いいかんじにシンプルにまとめられないかと思っています。
ざっくり
アジャイル開発やスクラムに取り組んでいると、だいたい3つの視点が目立ちます。これにあわせて品質を考えるなら
- プロダクト品質
- 開発品質
- プロセス品質
にわけられそうです。これは一般的なスクラムチームの役割にも当てはまります。
- プロダクト品質を高めるPO
- 開発品質を高める開発者
- プロセスの品質を高めるスクラムマスター
スクラムはとても一般的なので、これらをベースにブレークダウンしてみましょう。Geminiには「ISO 25010 で定義されている利用時の品質特性と副特性について、箇条書きで、ITのことがわからない人でも理解できる言葉で簡潔に説明してください」のようにお願いしています。
また、どの品質も現場によっては境界があいまいだと思います。よって、「プロダクト品質だからPO」というより、プロダクトバックログのように「責任はPOが持つけど、チームで協力して達成する」感覚で望むと良いと思います。
プロダクト品質
「プロダクト品質」という言葉を使うと、ビジネスやユーザに向けられた品質になりそうです。専門用語だと利用時の品質特性でしょうか。では、プロダクト品質を箇条書きに洗い出してみます。カッコには備忘録も兼ねて該当しそうな品質特性を残しておきます。
- ユーザニーズを満たす、ビジネスとして期待する結果が出る(有効性)
- 直感的に利用できる使いやすさ、繰り返し作業が簡潔になる(効率性)
- 快適な操作、見やすい画面デザイン(満足性)
- 安心安全のセキュリティ、データバックアップ、サポート体制(リスク回避性)
- 幅広いユーザや特定業務に関わるユーザ全体が利用できる、決済手段など幅広い選択ができる、マルチデバイス・マルチOS対応(利用状況網羅性)
開発品質
開発品質は、製品品質モデルが対象になりそうです。内部品質と外部品質に分けられた図が見つからなかったので割愛。
- 機能が揃っていること、仕様通りであること(機能適合性)
- サクサク動作する、効率的にコンピュータリソースを使っている(性能効率性)
- データを引き継げる、複数バージョンの環境で動作する(互換性)
- 簡単に操作できる、わかりやすい画面表示(使用性)
- 長時間利用できる、フリーズやクラッシュしない、データが消えない(信頼性)
- 認証認可、暗号化、脆弱性対応(セキュリティ)
- 素早い新規リリースや修正リリース、最新アップデート可能(保守性)
- 疎結合なコード(モジュール性)、再利用できるコード(再利用性)、読みやすいコード(解析性)、変更しやすいコード(変更性)、テストしやすいコード(試験性)など
- マルチデバイス・マルチOS対応(移植性)
プロセス品質
ISO 25010には該当するものがみあたらないので、スクラムガイドにあるスクラムマスターの責務がそのまま使えそうです。そこから品質面に関連する部分を抜き出してみます。
- スクラムの実践と原則の理解を促進(スクラム品質)
- スクラムチームの支援(自律品質、コミュニケーション・コラボレーション品質、学習と改善品質)
- プロダクトオーナーの支援(バックログ品質)
- 開発チームの支援(インクリメントへのコミットメント品質)
- 組織へのスクラムの導入と展開(アジャイルな組織品質)
プロセス品質は「利用時の品質特性や製品品質モデルのための品質」のように見えます。
メトリクス
品質の洗い出しが終わったので、メトリクスとの紐づけを行ってみます。メトリクスはこの場合、「じゃ、その品質をどうやって計測して、どれぐらいのレベルを目指すのか?」を決める指針になります。
種類 | 詳細 | メトリクスや測定方法 |
プロダクト品質 | ユーザニーズを満たす、ビジネスとして期待する結果が出る(有効性) | KGI、KPI、LTV、ARR、MRRなど |
プロダクト品質 | 直感的に利用できる使いやすさ、繰り返し作業が簡潔になる(効率性) | ユーザテスト、アンケートなど |
プロダクト品質 | 快適な操作、見やすい画面デザイン(満足性) | ヒューリスティック評価、アイトラッキングなど |
プロダクト品質 | 安心安全のセキュリティ、データバックアップ、サポート体制(リスク回避性) | プライバシーマーク、ISMSなど |
プロダクト品質 | 幅広いユーザや特定業務に関わるユーザ全体が利用できる、決済手段など幅広い選択ができる、マルチデバイス・マルチOS対応(利用状況網羅性) | アクティブユーザ数、滞在時間、満足度など |
開発品質 | 機能が揃っていること、仕様通りであること(機能適合性) | DONEの定義、バグ数 |
開発品質 | サクサク動作する、効率的にコンピュータリソースを使っている(性能効率性) | 応答時間、処理時間、CPU利用率、メモリ利用率など |
開発品質 | データを引き継げる、複数バージョンの環境で動作する(互換性) | 機能テスト |
開発品質 | 簡単に操作できる、わかりやすい画面表示(使用性) | プロダクト品質でもカバー。ここでは開発者目線の感覚でよさそう。 |
開発品質 | 長時間利用できる、フリーズやクラッシュしない、データが消えない(信頼性) | パフォーマンステスト |
開発品質 | 認証認可、暗号化、脆弱性対応(セキュリティ) | セキュリティテスト |
開発品質 | 素早い新規リリースや修正リリース、最新アップデート可能(保守性) | デプロイ回数、リードタイム、変更障害率、サービス復元時間。 コードレベルの確認なら静的解析等のメトリクスも利用できる。 |
開発品質 | マルチデバイス・マルチOS対応(移植性) | 機能テスト |
プロセス品質 | スクラムの実践と原則の理解を促進(スクラム品質) | 計測が難しいので成熟度モデルなど活用できる。 |
プロセス品質 | スクラムチームの支援(自律品質、コミュニケーション・コラボレーション品質、学習と改善品質) | 計測が難しいので成熟度モデルなど活用できる。 |
プロセス品質 | プロダクトオーナーの支援(バックログ品質) | RICE、加重スコアリングなど |
プロセス品質 | 開発チームの支援(インクリメントへのコミットメント品質) | ベロシティ、タスクボード、バーンダウンチャートなど |
プロセス品質 | 組織へのスクラムの導入と展開(アジャイルな組織品質) | 計測が難しいので成熟度モデルなど活用できる。 |
プロセス品質の「測定が難しい」部分は、アジャイル開発やスクラム導入の大きな壁になりうる部分のように思います。