はじめに
現代のソフトウェア開発において、スピードと品質を両立させるための鍵は、皮肉なことに「完璧でないことを受け入れること」にあるのではないかと考えています。より正確に言えば、「失敗することを前提とし、その許容の程度を柔軟に組織やプロセスの設計にあらかじめ組み込んでおくこと」 です。
なぜ「失敗を許容する設計」こそが、結果として品質への近道となるのか。今回はその理由についてお話していきます。
「作る脳」と「直す脳」を切り離す
人間は、新しいものを生み出す「発想・創造」のようなアクセルと、論理的な不整合をチェックする「批判・検証」のようなブレーキを同時に行うようにはできていません。これらを無理に並行させようとすると、認知的負荷が上がり、脳のエネルギーを消耗します。
その結果生まれるのは、品質が低く、創造性も欠いた凡庸な成果物になってしまうかもしれません。
この構造的なジレンマを考慮した設計の第一歩は、フェーズを分けることです。「今は粗くてもいいから出し切る時間」と割り切ることで制約を外し、スピードを上げる。その後に、改めて実際に手を動かしながら検証のフェーズに入る。このプロセスを組み込むことが、創造的な活動を支える仕組みになると思います。これは組織にQAエンジニアが必要と言われる一つの理由であり、同様にQAエンジニアの設計や分析の成果物にも検証のプロセスを用意することが必要なことは明らかです。
「品質」とは、作業ではなく「結果」である
現場において「品質の作り込み」という言葉が、「一度もミスをしてはいけない」という過度なプレッシャーに変換されているケースをよく見かけます。しかし、最初から100点を目指して手が止まるくらいなら、30分で60点のものを出し、次の30分で検証して80点に直す方が、最終的な品質到達スピードは圧倒的に早くなります。
ここで必要なのは、「品質とはプロセスの最後に出力される『結果』であり、作業そのものではない」 という視座の転換です。
失敗をゼロにすることに心血を注ぐのではなく、失敗が起きた際の「検知」と「修正」のコストを下げる。これこそが「失敗の許容度を組み込んだ設計」の本質です。
「すべてのモデルは間違っている」という前提
統計学者のジョージ・ボックスは、「すべてのモデルは間違っている（が、いくつかのものは役に立つ）」という至言を残しました。ソフトウェア開発において、私たちが事前に定義する仕様書、設計、そしてテスト基準もまた、現実を切り取った一つの「モデル」に過ぎません。
テストの品質を「正解を当てること（網羅性や正確性）」だと定義してしまうと、不確実な事象に直面した際に手が止まります。しかし、テスト（モデル）そのものが間違っている可能性をあらかじめ許容できていれば、「まずは動かして、現実との乖離から学ぼう」という動的なアプローチが可能になります。
追求すべきテストの品質とは、テストの内容そのものではなく、「モデルの間違いを素早く暴き、修正できるプロセスの堅牢さ（復元力）」 にあるのです。
前述の文章に「QAエンジニアの設計や分析の成果物にも検証のプロセスを用意することが必要なことは明らかです」と述べていたのですが、この視点でテストプロセス全体を俯瞰すると、「テスト実施」とは「テスト設計という名の仮説」を検証する一面を持ったアクティビティであると捉え直すことができます。もちろん、プロダクトの品質を測定し、評価するための役割を持っていると思います。ここで話したいのは、QAエンジニアが生み出す成果物（テスト設計）もまた不完全なモデルであり、それ自体に検証プロセスが必要であるという考え方です。成果物をレビューするだけではなく、分析や設計時点の仮説の正しさを検証するという観点です。
このパラダイムシフトは、昨今のAI（LLM）によるテスト設計の自動化に対しても、「逆転の発想」をもたらすかもしれません。
現在、AIを用いた品質保証の多くの取り組みは「いかにAIに人間と同等の『完璧なテスト設計』をさせるか」に注力しています。しかし、AIに完璧さを求めるのではなく、あえてAIが提示したテスト設計を「不完全な仮説」として扱い、それを検証するためにテストを実行するというアプローチが考えられます。
AIの仮説（テスト設計）と現実の挙動との間に生じる「ギャップ」を意図的に明らかにすることで、仕様書には記述されていない隠れたエッジケースや、人間側の考慮漏れを能動的にあぶり出すことができるかもしれないのです。LLMの特性を考えると、オラクルを厳密に定義することは苦難の道です。このような考え方をしてみるのも面白いのではないか？と最近は考えています。
「AIの出力が間違っているかもしれない」ことをリスクとするのではなく、むしろ 「AIという不完全なモデルを活用して、自分たちの認識の穴（間違い）を素早く明らかにする」 。これこそが、失敗の許容度をプロセスに組み込むという発想ならではの考え方ではないでしょうか。
弱さを補完する「外在化」と「ガードレール」
人間は不完全で、忘れっぽく、自分に甘い生き物です。この「弱さ」を気合でカバーしようとするのは非現実的です。人間が創造的な作業に集中させるためには、頭の中にある基準や手順を「外」に置くこと、すなわち 「外在化」 が不可欠です。
ただし、すべてを厳密にルール化して外在化すればよいわけではないと考えています。
- 厳密な外在化： 機械的な判断が可能なものは詳細に定義し、誰でも（あるいは機械でも）客観的に実行可能にする。
- 抽象的な外在化： 人の創造性や気付きが必要な領域には、「テストチャーター（指針）」のような方針を与える。
難しく書いてしまいましたが、要は 「ガードレールを敷く」 ということです。逸脱してはいけない方向性だけを担保し、その内側では自由な探索を許容する。このバランスが、失敗を恐れずに挑戦できる環境を作れるのではないかと考えています。
少し変えるだけで改善できる
失敗の許容度を設計に組み込む具体的な例として、例えば探索的テストの記録のあり方を変えることが挙げられます。
単に「バグ」の結果だけを記録するのではなく、QAエンジニアが感じた 「懸念」「問い」 そして 「学び」、さらには 「テストチャーター（モデル）そのものへの改善案」 をログの項目に設ける。これだけでも、テストケースの失敗は「単なるミス」から「貴重なフィードバック」へ変化すると考えています。
結びに：弱さを抱擁する組織へ
「高い品質で作れなかったこと」を責めるのではなく、「早く作って検証（失敗）できなかったこと」を課題にする。このパラダイムシフトが達成されたとき、チームは犯人探しをやめ、仕組みの改善へと向かうことができます。
人間の不完全さを認め、あらかじめ「失敗」をその内側に含ませた設計を行うこと。にし先生が説くような、「弱さを抱擁する」 ような組織の姿は、まさにこの考え方の先にあるような気がしています。
不完全なモデルと共に歩み、失敗を繰り返しながら最速で正解へと近づいていく。それこそが、現代のソフトウェア開発や創造的活動における最も誠実な品質への向き合い方ではないでしょうか。
Discussion