この記事は過去の自分に教えたい、ソフトウェア品質の心得を投稿しよう by QualityForward Advent Calendar 2024 23日目 の記事です。

悩んでいた自分を振り返る

「テストは後、とにかく納期に間に合うように実装が完了すればよい…」

そんな意識が強かった時期があったように思います。もちろん、適当なものを作ればいい、という感覚ではなく「とにかく顧客の要望、会社の期待に応えたい」という価値観が、イコール納期遵守につながっていたと思います。

このような価値観で進めたプロジェクトは大半が赤字プロジェクトでチームを負荷に足らしめた炎上案件を生んだと感じています。

自戒のため、強い表現を使うと「偽善的な価値観」であったなと思います。

例えば、プロジェクトマネージャーとして一通りの開発工程を経験していた頃、念願であった0→1の受託開発を受注しました。"アジャイル"が開発現場に浸透してきた時期、「偽善的な価値観」のもと、アジリティーのある開発を履き違えた私は、要件定義は顧客要望を優先し、納期に合わせる見積もりのため、テスト工程を削りに削って開発を進めました。

削りに削った結果、テスト工程では充分なテスト戦略を練る時間もなく、要件の裏返しとなるようなテスト項目書でテストが進みました。その結果、「どの機能からテストすべき？」「優先度の決め方は？」といった問題に行き当たりばったりに対処する日々。機能Aの結合テストと機能Bの単体テストを同時並行で進めようとして混乱したり、要件が変わるたびにドキュメントを直しては手戻りが続いたり、、、という日々の試行錯誤に追われました。

なんとか初期リリースにはこぎつけ、不具合を改修しつづけながら新たな機能要望を検討する日々が続きました。その結果想像に固くないですが、プロジェクトは疲弊し、最終的にはサービスを維持できる品質を作り込むことができず、プロジェクトは解散となりました。

「もっとスマートに進める方法があったのでは？」と悶々とするばかり。もし、あの頃の自分にアドバイスができたら、こう伝えたいのです。

「テスト戦略は顧客含めたプロジェクト全体の中で考えよう。プロダクトは作ることがゴールではなく、リリース後にユーザーに価値を届け続けることが重要だ。ビジネス課題とテストの価値を紐づけて考えたほうが、未来の自分を救う」と。

転機となった気づき

そんな私の考え方が大きく変わったのは、前述の経験をした企業から、第三者検証機関のITコンサルタントに転職ののち、Saasのスタートアップ企業のQAエンジニアとして働く中で、“品質マネジメント”についての理解が深まったことが大きな要因でした。

ITコンサルタントとしての気づき

体系的な品質マネジメント手法と社内の豊富なナレッジを組み合わせたプロジェクト支援に携わりました。具体的には、事業会社のIT統括部門で品質向上施策を立案・実行したり、エンタープライズ企業の基幹再構築プロジェクトでPMOを担当するなど、多種多様な現場を経験しました。

そこで痛感したのは、品質管理・品質保証は“プロジェクト管理”や“組織体制”と密接に関わっている ということです。過去の私は、テストは開発工程の一部として切り離して考えることが多く、スケジュールや要件変更の影響などを十分に考慮していませんでした。しかし、第三者検証機関で数々の事例を学ぶうちに、品質を支える活動はプロジェクト全体を俯瞰しながら行わなければ、真の効果を発揮しないと気づいたのです。

QAエンジニアとしての気づき

さらに大きな変化をもたらしたのが、現職のQAエンジニアとしての経験です。ここでは、スタートアップならではの変化に柔軟に適応したプロダクト開発が行われており、「事業会社の品質マネジメント」を守りつつも、リリースサイクルを遅延させないテストアプローチ が求められます。

従来のように「すべての機能を大量のテストケースで網羅する」アプローチだと、スピードを求める開発の足を引っ張りかねません。そこで、 テスト技法を上手に取捨選択し、重要な機能を効率よくカバーする 方法を模索してきました。最近では、リスクベースの考え方で、発生頻度や影響度の大きいバグが潜在する可能性の高い箇所に優先度を置くことで、短いリリースサイクルにも対応できるように日々取り組んでいます。

このプロセスを通じて学んだのは、 QAの目的は単に不具合を探すだけではなく、チーム全体の生産性やビジネスの成長速度を保ちつつ、品質を高めること なのだということ。以前は「テストでバグを見つけるのがQAの役目」という認識が強かったのですが、いまでは「次のリリースにつなぐための最適な“品質保証プロセス”を設計・実践することこそがQAの役割だ」と考えています。そして、この役割を全うするのに強い権限は不要（例えば管理職であるとか）で、日々の現場で実践できるということを学びました。

過去の自分に教えたい4つのポイント

1. プロジェクトマネジメントと同じようにテストマネジメントする

一見別物に思えがちな「テストマネジメント」と「プロジェクトマネジメント」ですが、どちらも 期間・コスト・品質をいかにバランスよくコントロールするか、という点では共通 しています。工数管理やスコープ管理、ステークホルダーとのコミュニケーションなど、実は多くの部分が共通です。この共通の観点をテストに対しても考えてみよう。

2. テスト技法の大半は“経験則”である

境界値分析や同値分割、ペアワイズテストなど、テスト技法には理論的な裏付けだけではなく“過去の不具合事例”や“現場の知見”が強く反映されています。この経験則を知り、自分のプロダクトや組織に合う形にカスタマイズ しよう。そして、このプロセスを繰り返し、プロダクトや組織にあった"型"を言語化しよう。

3. リスクにはプロジェクトリスクとプロダクトリスクがある

品質を高めたいなら、不具合（プロダクトリスク）を見つけるだけでなく、要件変更やスケジュール圧縮（プロジェクトリスク）にどう対応するかも重要です。どちらか一方ばかりに目を向けていると、最終的な品質を落とす原因になりかねません。 相互に影響し合うリスクを見分けて対処 しよう。そして、このプロセスを繰り返し、再現性のあるリスクを見つけよう。

4. テストレベルを無視したテスト戦略は後の自分を苦しめる

単体テスト・結合テスト・システムテスト・受け入れテストといったレベルを意識せずに、テスト項目を無造作に積み上げると、抜け漏れや重複が発生しやすくなります。開発プロセスの原則を無視せず、 どのレベルで何を検証し、どのレベルで何を完了とするのか を明確にしよう。その労力はリリース後の自分を助けてくれます。

これから

最後までお読みいただきありがとうございます。

あのころの自分に戻れるなら、「QCとQAはプロジェクト全体の成功を左右する重要な軸であり、ビジネス価値を高めるための頼もしい味方だ。世の中の経験則を余すことなく活用してみよう。納期を守ることが重要ではない。」だと伝えたいと思います。もやもやっとしていた「アジリティーの高い品質を作るための品質マネジメントとは？」が、ITコンサルタントとQAエンジニアとしての経験を通して、その考えが確信へと変わりつつあります。

テスト技法や品質マネジメントを正しく理解し、リスクを俯瞰しながら開発チームと協働することで、よりスムーズかつ高品質なリリースサイクルを回すことができます。

もし、この記事を読んでいる方の中に、過去の私のように「テスト計画って難しい」「納期遵守のためにテストを省略したくない」「品質を守りながら、スピードも損ないたくない」と悩んでいる方がいたら、ぜひ今回挙げた4つのポイントを意識してみてください。未来のプロジェクトが、きっとより良い方向に進むはずです。

そして何より、品質はただの“合否チェック”ではなく、 価値ある製品やサービスを生み出し続けるための“仕組みづくり” だと私は思います。これからも学びを深めながら、より良い品質とプロジェクト成功を両立させる取り組みを続けていきたいと思います。