「品質を追求する」と言えば聞こえはいい。
不具合のない完璧なシステム、美しいUI/UX、誰もが迷わない新規登録フロー。
けれど、もしあなたが開発の現場にいて、本気でプロダクトを良くしようともがいたことがあるなら、薄々気づいているはずだ。「完璧な品質」なんてものは、この世のどこにもない。
開発スタイルがウォーターフォールであれアジャイルであれ、プロダクトのリリースは新たな始まりに過ぎず、新機能の追加や不具合との戦いは終わりなく続いていく。
世の中には、変えられない納期がある。どれだけ欲しくても足りない開発リソースがある。完璧だと思われた仕様も、OSやプラットフォームの突然の変化、あるいは強力な後発プロダクトの出現によって、一瞬で「過去、古臭いもの」に変わる。
私たちはいつだって、理想を追いかけながら、不確実でリソースの足りないカオスの中を駆け抜けなければならない。すべてをすくい上げようとする網羅主義は、ただの無理難題だ。
その呪縛に囚われたままでいると、いつの間にかテストを消化するためだけの「チェッカー」になり、誰のためになぜ作っているのかもわからない機能のテストを、短いスケジュールの中で泥泥になりながら回すことになる。リリースは遅れ、市場の変化に置いていかれ、チームの誰もハッピーになれない。
だからこそ、私たちは一歩進んで、自分たちの仕事の範囲を広げ、変化させていく必要がある。
品質とは、「何を諦めるか」をあらかじめ決める、極めてクリエイティブな意思決定のプロセスなのだ
「諦める」のは、より多くを救うため
医療の世界には「トリアージ」という概念がある。
災害時などの極限状態において、限られた医療資源で一人でも多くの命を救うため、患者の治療優先度を選別する手法だ。
ここで絶対に勘違いしてはならないのは、トリアージは「患者を切り捨てる（諦める）ため」ではなく、「より多くの命を救うため」に行われるという事実である。
これは、開発現場における品質保証（QA）も全く同じではないだろうか。
スケジュールが崩壊し、バグが噴出した炎上プロジェクトの終盤、私たちは否応なしにこのトリアージを迫られてきた。「このバグは直さず、制限事項としてリリースしよう」「この機能はフェーズ2に後ろ倒しにしよう」と。
しかし、なぜ私たちはいつも、現場が血を流し、カオスに陥ってからようやくトリアージを始めるのだろうか？
本来、トリアージの基準は、まだ誰も傷ついていない平時──つまりプロジェクトのキックオフ時点で定義されているべきだ。
「どんな状況になったら、どの機能を後ろに送るのか」
「このプロダクトにおいて、何が発生したら『失敗』と定義するのか」
「この時期までに、何が満たされなければリリースできないのか」
これら、目指すべき品質の目標と「諦める基準」を初期に言語化・合意しないまま見積もり、走り出すから、終盤になって想定外の出来事に対応できず、現場がただ疲弊していくのだ。
何を諦めるかを決めることは、プロダクトの「コア」を決めて抉り出す作業
何を諦めるかを定義する作業は、実はこのプロダクトが届ける、絶対に譲れない価値（コア）は何かを決める作業と完全に表裏一体である。
すべてを欲張って100%完璧なプロダクトを目指そうとすれば、尖っている魅力は削ぎ落とされ、焦点がぼやけ、結局誰の心にも刺さらない凡庸なものが出来上がる。
「ここは諦める。ただし、この体験だけは、絶対に譲らない」
「できる範囲の最善は、ここにすべて尽くした」
その境界線を引く知恵と勇気を持つことこそが、結果としてプロダクトを健やかに成長させ、持続可能な開発スピードを生み出す。
なぜいつも手遅れなのか？──「シフトレフト」を阻む席の壁
多くのQAエンジニアやテストエンジニアは、日夜、歯がゆい思いを抱えているはずと思っているがどうだろう？
「このスケジュールじゃ絶対に間に合わない」
「もっと前の段階で気が付けたはずなのに」
「どうして自分の手元にプロダクトがくるころには、いつも手遅れなのだろう」
もっと前に、自分たちの意見を聞いてほしい。誰もがそう願っている。しかし、開発の最上流、つまり「何を諦め、何を守るか」を決定する最初の席に、QAが招待されることはまだ驚くほど少ない。
世間はまだ気づいていないのだ。「テスト設計」という技能が、単なる不具合探しの準備ではなく、「不確実な確認の中に、プロダクトの基準を作る行為そのもの」であるということに。
仕様書が固まり、コードが書き上がった後に、ただ「仕様通りか」をテストするだけでは、歪んだ構造を根本から直すことはできない。それでは、自分たちですら勧めたくない、使いたくないようなプロダクトがそのまま世に出ていってしまう。
だからこそ、私たちはさらに前へ、開発の左側へと踏み込む「シフトレフト」をすすめなければならない。開発が始まるよりも、もっと前の席に参画していこう。
大きな話ではなく、ただ「問いかけていく」ことから始めよう
AIがテスト項目を自動出力し、定型的なチェックを肩代わりしてくれる時代はもう来ている。しかし、AIがどれだけ賢くなろうとも、この上流の課題はおそらく解決できない。なぜならAIは、プロジェクト上流の「意思決定の席」に自ら座ることはできないからだ。
こう書くと、何か特殊な技能が必要で、自分にはできないと思うかもしれない。
けれど、そんな大きな話ではないのだ。まずは、目の前のドキュメントやチームの会話に向き合い、プロジェクトを進める上で足りない記載を探すことから始めればいい。
「誰のためになぜこれをやるのか」を問いかけること
理想と現実のギャップを見つめ、限られたリソースの中で「今回はここを諦めよう、その代わりここを絶対に守ろう」と、PdMと一緒に、あるいは先導するつもりでチームを導くこと。
私たちは、テストに優先度をつけるのと同じように、チームの対話と合意を進めていけるはずだ。
QAの本質は、仕様書を完璧にトレースすることではない。
変えられない納期や技術的制約を受け入れる賢さと、事前に発見できるリスクを仕組みやコミュニケーションによって変えていく勇気を持つことだ。
すべてを救おうとする完璧主義の呪縛から逃れ、プロジェクトの初期から「美しく諦める技術」をチームに共有する。ただの「チェッカー」や「不具合の責任を負う係」から、プロダクトに寄り添うオーダーメイドな品質の管理者・アーキテクトへ。
最上流の席で意思決定を支え続けたとき、私たちの追求する品質は、お客様も、関わるすべての人たちも、本当の意味でハッピーにする。
──けれど、これはきっと、いつまでも終わりのない話なのだと思う。
品質にマニュアルはなく、ゴールもないのだから。
私たちは今までよりもいい未来へ向けて、それでも走り続けるしかない。