この連載について
品質保証プロセスの改善やQAの役割について考える中で、
いくつかの疑問を持つようになりました。
本連載では、それらの疑問について整理しながら考えていきます。
記事一覧
第１章 品質保証を問い直す
1. QAは品質を保証しているのか？ ← 今回の記事
2. レビューは品質を保証しているのか？
3. AI時代にQAが保証するものは何か？
第２章 品質はどこから生まれるのか
4. レビューの価値は学習ではないか？
5. プロセスは思考を設計しているのか？（予定）
前書き
私のこれまで経験と思っていることについて記載しております。
最終的に答えに到達しきれていないところもありますので、ご了承ください。
また、二番煎じかもしれません。
はじめに
車載ソフトウェア開発の現場では、品質保証プロセスの改善活動が繰り返し行われています。
レビュー手順の整備、成果物テンプレートの標準化、トレーサビリティ管理、メトリクス収集など、多くの組織が品質向上のための取り組みを進めています。
しかし、その一方で次のような悩みもよく聞きます。
- プロセスを整備しても現場に定着しない
- レビューは実施されているが形骸化している
- ASPICE対応は進んだが品質向上を実感できない
- QA部門と開発部門の距離が縮まらない
私自身も品質保証プロセスの改善に関わる中で、「品質保証プロセスが根付かない」という問題について考える機会がありました。
しかし最近は、そもそも問いそのものが違うのではないかと感じています。
品質保証プロセスは開発プロセスの一部ではないか
品質保証プロセスという言葉があります。
しかし実際には、品質保証プロセスは独立した活動ではなく、開発プロセスの一断面を切り出して見ているだけではないでしょうか。
例えば、
- 要求レビュー
- 設計レビュー
- コードレビュー
- テスト設計レビュー
は品質保証活動として扱われます。
しかし開発者から見れば、それらは本来開発活動そのものです。
品質保証プロセスが根付かない理由を考えるとき、「品質保証プロセスの問題」として考えがちですが、実際には「開発プロセスそのものが定着していない」という問題が隠れている場合もあります。
開発の進め方が担当者依存になっている状態では、品質保証活動はどうしても追加作業として認識されるのではないでしょうか。
テスト設計、QAの経験が長いので開発者の方とお話ししてきた経験からの想像です。
人に品質を求めるアプローチの限界
品質向上活動ではよく次のような施策が行われます。
- 品質教育
- 品質意識向上
- 品質文化醸成
- レビュー強化
もちろん重要な活動です。
しかしこれらには共通点があります。
それは、
「人が頑張ること」
を前提としていることです。
品質保証活動がうまくいくかどうかが、個人の意識や経験に依存してしまうのです。
しかし現実には、
- スケジュールが厳しい
- 人員が不足している
- 要求変更が頻繁に発生する
といった状況があります。
その中で品質活動だけを強化しても、長続きしないことがあります。
レビューは本当に品質を保証しているのか
品質保証活動の代表例としてレビューがあります。
しかしレビューには根本的な課題があります。
レビュー完了という状態は存在します。
しかし、
「レビュー品質保証済み」
という状態は存在しません。
レビュー記録には
- 問題なし
- 指摘なし
- レビュー完了
と書かれている。
それでも後から重大な不具合が発生することがあります。
つまり、レビューという行為そのものにも品質のばらつきが存在しているのです。
レビューを実施した事実は確認できても、レビューが機能したかどうかは分かりません。
ここに多くの品質保証活動が抱える難しさがあるように思います。
QAは成果物を監査しているのか、それとも仕組みを作っているのか
ここで一つの疑問が生まれます。
QAエンジニアの仕事は何なのでしょうか。
成果物を確認することなのでしょうか。
レビュー記録を確認することなのでしょうか。
それとも別の役割があるのでしょうか。
私は最近、QAの本質は監査そのものではなく、
「品質が自然に作り込まれる仕組みを設計すること」
ではないかと考えるようになりました。
製造業では、検査で品質を保証するのではなく、工程で品質を作り込みます。
ソフトウェア開発でも同じことが言えるのではないでしょうか。
品質保証活動を減らすことがQAの仕事かもしれない
少し極端な言い方になりますが、
QAの究極の目標は品質保証活動を増やすことではなく、
品質保証活動が不要になる仕組みを作ることかもしれません。
例えば、
- 要求作成時に曖昧さを自動検出する
- トレーサビリティを自動生成する
- 静的解析を自動実行する
- コミット時に自動テストを実行する
- AIがレビュー観点を提示する
こうした仕組みが整えば、人による確認作業は減っていきます。
重要なのは、人が品質を作るのではなく、品質が自然に作られる流れを設計することです。
QAの役割を再定義する
もしこの考え方が正しいのであれば、QAエンジニアの役割も変わるかもしれません。
従来は、
- 監査する
- 指摘する
- 確認する
ことが中心でした。
しかし今後は、
- 品質が作り込まれるプロセスを設計する
- 自動化を推進する
- 品質活動の再現性を高める
- 開発システム全体を改善する
- 必要な観点を整備する
ことが中心になるのかもしれません。
QAは品質の専門家というより、品質が自然発生する開発システムの設計者になる。
そんな姿も考えられるのではないでしょうか。
おわりに
品質保証プロセスが根付かない原因は、品質保証プロセスそのものにあるのでしょうか。
あるいは、開発プロセスや組織の仕組みにあるのでしょうか。
そしてQAの役割は、品質を保証することなのでしょうか。
それとも、品質保証という活動そのものを不要にする仕組みを作ることなのでしょうか。
まだ私自身も答えは持っていません。
ただ、品質保証プロセスの改善を考える中で、最近はそんな問いを持つようになりました。
皆さんの現場では、QAはどのような役割を担っていますか。
また、品質保証活動を減らしながら品質を高める取り組みがあれば、ぜひ教えてください。
次回は、
について考えてみたいと思います。