そもそも、どのようにプランニングするとプロダクトサービス品質が良くなるか。考えてみました。
当然、サービスによって異なりますが何を持って品質向上と言えるのか。
品質向上担保がQAチームだけではなく 「プロジェクト品質」、「スケジュール品質」、「作業品質」、「コミュケーション品質」、「ドキュメント品質」、「開発品質」、「リリース品質」、「運用品質」、「エンジニア採用品質」、全てが品質だということを心得。事業全体が一つの品質活動ということになる。
| 品質 | 内容 |
|---|---|
| プロジェクト品質 | PMもしくはPMOがサービス、開発、インフラ、QAスキルを持ち合わせている、承認する立場、責任の所在が明確 |
| スケジュール品質 | 企画、開発、インフラ、QA、運用がきちんと作業できる、リスクに備えたバッファ、各工程の作業理解 、差し込み案件の対応 |
| 作業品質 | 集中力、モチベーション、休息 、脱長時間勤務、キャリアパス |
| コミュケーション品質 | きちんと伝わっている、相手に応じた説明である、対象者全員、フルリモート下では1on1の定期実施 |
| ドキュメント品質 | 記載している内容が正しい、アサインすべきレビューア |
| 開発品質 | 利用フレームワーク、サーバ設計、サーバーパフォーマンス、DB設計、DBパフォーマンス、ログ精査、単体テスト基準、単体テストケース、検証環境の構築 |
| リリース品質 | 使用ブランチ、リリース手順、時間、担当者が明確 |
| 運用品質 | 運用手順、障害対応手順、利用ツール、担当者が明確 |
| エンジニア採用品質 | 担当案件もしくは作業を遂行できる能力がある人材である、メンタル面、体調面に問題がないかを見極める |
これが前提にあって、初めてQAが品質活動をすることができる。
この品質も担保されず、QAをしたところで何を示すことができるでしょうか。
QAチームだけが品質活動をしたところで、良い結果にはなりません。
なぜか？
QA側で考えてみると！！！
全体の品質を高めることが、まずは必要であると言えます。
| 項目 | 内容 |
|---|---|
| プロジェクト品質 | PMもしくはPMOがQAの作業や役割をきちんと認識していない |
| スケジュール品質 | 何も考えずに線だけが引かれている。QAの見積が考慮されない |
| 作業品質 | 作業精度が落ち、本来確認できる不具合も見落としてしまう |
| コミュケーション品質 | 作業領域や優先度がわからず、工数だけ使ってしまう |
| ドキュメント品質 | 設計、仕様書に落とし込んでいる内容と異なる。メンテナンス工数だけ膨れる |
| 開発品質 | 単体レベルの不具合が、たくさん見つかりQA実施ができない。使用している環境も正しいのか不安になる |
| リリース品質 | QAが完了し、リリースに取り掛かっても、ブランチを間違ったり、リリースの手順をミスすると、不具合となる |
| 運用品質 | 障害ばかりで、一向に収束しない |
| エンジニア採用品質 | 作業進捗や、工数の変更、稼働コスト |
この状況下で、品質活動をしてはいけない。まずは、改善しましょう
全体の品質を高めることが、まずは必要であると言えます。