ＳＷ品質まとめ⑥ＱＡプロセス

「品質保証」は絶対に必要です。

なぜなら、品質が保証されていることを証明しない製品には、ユーザーが安心して利用できるだけの信頼性が欠如するためだからです。しかし、品質保証部門あるいは品質保証チームという形式が必ずしも必要なわけではありません。

あくまでも必要なのは「品質を保証・証明する仕組み」であって、これを開発チーム内で責任と覚悟をもって実行できるのであれば、開発チームの中で閉じていても良いからです。

ただし、一般的な製造業の品質保証と、ソフトウェア開発の品質保証は、その性質がまったく異なることは覚えておかなくてはなりません。

一般製造業とソフトウェア開発業の違い

一般的な製造業では、プロジェクトと言う概念で製造しません。そこでは「試作→ライン構築→量産」と言う流れになります。そのため、量産の時点では”全く同一製品、同一品質”であるための流れを保証するために、出荷検査と言う形で介入することが多くなります。そして自社製品の開発の場合、出荷検査の段階で不良が発生すれば、ラインを止めて再点検し、是正することができるわけです。

しかし、ソフトウェア開発の場合は大別して、「パッケージ開発」と「オーダーメイド開発」の２つに区分されます。前者のパッケージ開発であれば、製造業の品質保証と同じような流れで検査することも決して無理ではないでしょう。

けれども、オーダーメイドで作成するＢ２Ｂ向けのシステム開発の場合、一つひとつのプロジェクトが世に２つとない一品モノの作成となってしまいます。にもかかわらず、試作を作って確認する間もなく、いきなりぶっつけ本番を要求されるわけです。

すべてが一発勝負となってしまううえに、その契約的な性質から開発のために設けられた『期限』が定義されており、その中では殆ど手戻りすることが許容されていません。

大きなスケジュール破綻を起こすことが一切許されないのです。

そのような開発モデルの中で、最後の最後に出荷検査するだけでは、品質上の保証ができても、プロジェクトの成功は望めるはずもありません。修正のために手戻りを行う規模の大きさ次第では、損害賠償請求に発展する可能性すらありえます。

ゆえに、ソフトウェア開発における品質保証では、水際で不良を発見する「出荷検査」ではなく、開発の進め方自体が常に妥当であることを保証する「プロセス検証」と、プロセスごとのアウトプットに対して計画通りであることの「成果物検証」の両方が必要になってくるのです。

しかし最近では、ＱＡの主戦場は「テスト」のみとなっており、参加タイミング自体はテスト計画を行う頃からであっても、テストばかり考え、テスト設計を行い、テストツールの環境を整え、テストの実施まで行っている現場も増えていますが、逆に言えば『ソフトウェアテスト』以外がとんと無関心になっているように見受けられます。

アジャイル開発モデルの場合は、

　「テストの実施はQAチーム」
　「エンジニアは修正に集中させる」

と明確に役割分担を行い、効率性を上げているところも多いようで、そのうえでテストツール、自動化ツールなどを駆使して、さらに効率をあげようとしているようにも見えます。

このような状態では

　本当に「品質の保証」がしっかりとできているのか？

という点に懸念が付きまといます。「テストを実施した」かどうかだけでは保証にはならないからです。テスト内容が正しいことを保証するのは当然必要ですが、そもそもテスト内容の適切性や抜け漏れがないことを証明することはテストの結果からだけでは判断できません。

ゆえに、本来の開発方法であれば「仕様書」や「設計書」をベースラインとするのですが、こうした記録類を残さない開発現場も増えてきたため、本来の意味における『保証』は昨今の方法では困難と言わざるを得ません。答え合わせの答えが存在しないようになってきたからです。

本来、ＱＡ（Quality Assurance：品質保証）に必要なのはテストを実施したり、テストツールに精通することではなく品質を保証することであるため、保証できない方法論はあまり推奨できません。

この点については各社様々な方法で対応しているみたいですが、各社それぞれが自由に対応しているため、業界全体で包括的に「これが適切である」と呼べるものができるまでにはまだまだ時間がかかると思われます。

品質保証担当者に求められるスキル

品質保証（ＱＡ：Quality Assurance）を実施する担当者には、次のスキルが必要となります。

・論理的思考力（具体的に、ユーザーに説明できるレベル）*
・ソフトウェア品質 *
・ソフトウェア工学（開発手法とその本質的な必要性 / ISO 15504）
・対象システムに特化したソフトウェア技術に対する知見
・プロジェクトマネジメント（ISO 21500 / PMBOK）*
・保証できる根拠を言語化できる程度のコミュニケーション能力*
・データサイエンス　　　　　　　　　　　　　　　　　　　　　*…必須

ＱＡ担当者は、作業一つひとつ、結果一つひとつに対して、その内容が妥当であることを証明できなければなりません。ゆえに、論理的な表現は必須となります。また、具体的な作業経験の有無はともかく、インプットとアウトプット、そしてそれらをコントロールするプロセスの関係を知るためには、どのような開発アーキテクチャがあるのは理解しておくべきでしょう。

ここから先、全８項はファイルにて。

6. ＱＡ（品質保証）プロセス
　6.1 品質保証の必要性
　6.2 一般製造業とソフトウェア開発業の違い
　6.3 品質保証担当者に求められるスキル
　6.4 品質保証担当者が絶対にやってはいけないこと
　　6.4.1. 独断でスコープに無いことを実施する、または要求する
　　6.4.2. 各作業の対効果を度外視する
　6.5 品質保証体制
　6.6 品質保証の流れ
　　6.6.1. 「様式」や「ルール」を定めていない場合（不足している場合）
　　6.6.2. 「様式」や「ルール」をプロジェクト特性を無視して定めた場合
　　6.6.3. 事前に品質計画を見定め、確認方法および内容を特定しない場合
　6.7 まず、すべてに明確なゴール（目標）を決定する
　6.8 ＱＡ確認方法
　　6.8.1. 体裁が整っていること
　　6.8.2. 識別できること
　　6.8.3. 追跡可能性が確保されていること（ドキュメント品質）
　　6.8.4. 成果物内容の一つひとつに対して、インプット情報がトレースできていること
　　6.8.5. 認識齟齬が起きやすい表現が存在していないこと
　　6.8.6. 注意点