けっこうな数の運用を経て型が出来てきたのでメモ。
何がうれしいの？
品質保証の活動(主にテストとプロセスQA)について
- なぜそれで充分と言えるのか？
- なぜその活動が大事なのか？
が自分の意見で説明できるようになります。字面で見ると響かないかもですが、現場の品質保証活動の最上流から自律的にブレイクダウンできると手を動かす場面へのトレーサビリティが確保できて、結果として周りを動かす大きな力になります。
成果物は品質特性をコンテキストにあわせて狭めたもの
品質特性は非常に数が多くその全てを適用した品質保証体制を敷くことは出来ず、ステークホルダー全員がわかる何らかの基準なり思想にそって削ぎ落とす必要があります。戦略とは戦いを略すと書くとおり、品質特性全てに向かって戦うのは上策ではありません。略すのはいいけどその課程には筋を通したい、そのためのメソッドがこのそぎ落とし方のモデルです。
そぎ落とし方のモデル
このそぎ落とし方のパターンを適用して、そのプロジェクト、ビジネスにとって最適な量のモデルに作り変えたものをプラクティカルクオリティモデル、とよびます。造語です。クオリティモデルのままだと、公的に定義されているものと見分けが付かないからです。Practical は 「(理論上ではなく)実際の, 実践的な, 現実的な」とかいう意味です。なぜメソッドではなくモデルなのかというと、このフィルタ自体も構造を持つことが多かったからです。
具体的にはどんなモデルがあるの？
ビジネスリスクベースド
いま一番熱いそぎ落とし方。ステークホルダーの納得度が違う。
これはサービス開発向けのモデルが確立できてきたところ。
向かうビジネスにとって何ができなければヤバいか？を優先付けする。
サービス開発の現場では変更性＝CIをかなり高くおいてみている。
ドメインベースド
これが出来ると仕事がかなり楽になるので頑張りたい。
多業種多ドメイン垂涎。
モバイル、ウェブ、組み込み、などドメインにとって
当たり前に期待される部分と自分たちが表現したい品質を
モデル化する。
ゲーミフィケーション
DevQUTで紹介した方法。機能を含めた品質をボスに見立て、
プロセスをマップに見立て、各種特性のHPをゼロにしたらDONE!ってやつで、
とっても楽しいです。
