デブサミ2025で品質に関するパネルディスカッションに参加してきました。アジャイル開発において「価値提供のスピードを落とさずに品質を維持するためにどうするか」というテーマにおいて、僕はアーキテクトという立場から「構造」の側面、ブロッコリーさんはQAエンジニアという立場から「プロセス」の側面から話をしました。
アジャイル開発で品質とスピードを両立するには、構造とプロセスの両面からのアプローチが必須です。
はじめに
参加したのはデブサミ2025での「開発スピードは上がっている…品質はどうする？ ～スピードと品質を両立させるためのプロダクト開発の進め方とは～」です。もう1人の登壇者である風間さん（ブロッコリー）からお誘いを受けてお話しさせていただきました。パネルは安達さんにまとめてもらい、良い形になったと思います。
ブロッコリーさんのブログ「Developers Summit 2025で企画作成＆登壇してきました #DevSumi」
ソフトウェア品質モデル
まずは「ソフトウェアには4つの品質がありますよ」というソフトウェア品質モデルの話から。
一般的に言われる「品質」は外部品質（ソフトウェアの挙動が仕様通りか）のことです。「ソフトウェアの挙動」と「想定される仕様」に齟齬があれば「バグがある」と表現されます。
そこに2つの品質が影響を与えています。１つ目はプロセス品質（手順通りに作業できているか）です。計画に対してその通りに実行されているかが重要です。プロセスそのものは後に残らないため、プロセス品質の検証は検証結果などの成果物でしか測れません。
2つ目は内部品質（コードや文書の構造が適切か）です。内部品質の対象となるモノは後に残るため、品質の検証はコード解析などによっても行うことができます。
ソフトウェアの価値は、最終的には利用時の品質（利用者が感じる価値）が重要です。複数の円があるのは、利用者の状況や立場によって価値が変わってしまうことを意味します。どんなに「仕様通り」の挙動をしても、価値が低いと感じる人もいえば、高いと感じる人もいます。
従来はリリースに向けて品質を確保する
従来型のウォーターフォールでは「リリースする時点で外部品質を確保する」ことが目標。そのためにはプロセス品質を高めて「テストプロセス」をしっかり回すことが有効です。
機能スコープを確定させた上で、テスト計画を立てて、単体テスト、結合テスト、システムテストと積み上げていく。内部品質は標準化できれば尚良し。
アジャイルは変化しても品質を維持する
一方で、アジャイル開発では「利用時の品質（提供価値）を上げ続ける」ことが求められるので、機能をどんどん変更していきたい。そのためアジャイル開発では「挙動がどんどん変更されていく中で外部品質を維持する」ことが目標になります。
こういう状況では、内部品質を高めて、構造的に外部品質を維持する取り組みが有効です。DevOpsやSRE、マイクロサービス、クラウドネイティブといった取り組みは、変化のスピードを落とさないで品質を維持するための構造だと捉えることができます。
たとえば、 DevOpsのFour KeysやSREのエラーバジェットは、内部品質への取り組みを定量化することで、品質とスピードの適切なバランスを維持するための指標として機能します。
構造的なアプローチにおいて注意が必要なのは、構造を変化に強くしていくと必ず副作用があり、やりすぎると品質もスピードも落ちるということです。過度な自動テスト、過度な疎結合、過度な先端技術は、すべて変化を阻害する要因となります。何事も、身の丈にあったほどほどが大切。
アジャイルにおけるテストプロセス
そんなわけでアジャイルにおいても、構造的な副作用がないプロセス品質を高める取り組みも重要となるわけです。
ブロッコリーさんの発表は、アジャイル開発を前提としたうえで、どのようにテストプロセスをアジャイルのサイクルに組み込んでいくのか、を提案しています。
たとえば、実装が開始される前のリファイメントやスプリントプランニングからQAエンジニアが関わり、テストの観点から意見を言うことによって、品質を高めることができる、というような話です。
結局、品質とスピードがトレードオフになるのは事実で、だからこそ、様々な工夫をすることで両立を目指す必要があります。その際には構造からもプロセスからもアプローチが必要になります。
（当然、ブロッコリーさんも僕も「どっちも大事だ」とわかった上で、あえて役割分担して話してますので）
品質はQAエンジニアのものか？
パネルでも感じましたが、品質を高める役割はQAエンジニアのものだ、というわけではありません。
ただ、アプリケーションエンジニアは、問題が出ると、すぐに解決モードになってしまい、問題の背景にある目的や、その目的に向かう場合に内在する課題を見落としがちです。
一歩立ち止まり「そもそも、何のためにやるんだっけ。なにが価値なんだっけ」を俯瞰して考え、そこからテスタビリティや、シンプルさについて検討するべきです。
パネルで話された「物事を外側から見る」みたいなのが視点を養うのは、あらゆるエンジニアにとって大事なことでしょう。
とはいえ、現代においては、品質を確保するための様々な手法や技術が存在します。それらを正しく理解し、適切に実践するのは専門性が高いスキルになっています。テストプロセスやDevOpsなどの「直接的に機能開発をしない作業」は、ややもすると軽視されがちです。
なので、QAエンジニアという専門職種が求められることも納得です。ただ、丸投げはダメ絶対！！
