プロダクト開発に取り組む中で本番インシデントに向き合うとき、改めて「品質ってやっぱりテストの瞬間ではなく、もっと前の工程から作り込んでいくものだよな」と考えていました。
トラブルが発生した際に、起きている現象へ迅速に対処したり、事前チェックの項目を増やしたりして次を防ごうとする姿勢はもちろん大切です。ただ、テストで検知する網を広げることに留まらず、「そもそもそのバグはどの工程で作り込まれたのか？」を特定し、根本から防ぐ仕組みを作っていくことが大事だと、感じています。
発生した個別の不具合をテストで捕まえるだけでなく、それが「どの工程で生まれたのか」に目を向けることで、同じような構造の課題（同型の再発パターン）をまとめて防ぐ仕組みへ昇華させていく。そんなアプローチについて、頭の整理も兼ねて書いてみます。
テストは品質を「確認する」もの。ただし、早い段階のテストは設計を良くする手段でもある
インシデントを防ぐ方法を考えると、「出荷前やリリース直前の検査（QA）をより手厚くしよう」という発想になりやすいです。リリース直前のテストは、あくまで「今の状態（品質）を可視化・確認する作業」である、という側面は確かにあります。
一方で、設計や実装の早い段階で書くテスト（TDD や契約テストなど）は、単なる「後追いの検査」ではなく、設計の穴を早く見つけ、品質を作り込む手段にもなります。つまり大事なのは「テストをするか否か」ではなく、品質を後工程に押し付けないこと。検査も、設計も、実装も、それぞれの工程の中で品質を育てていく、という見方のほうが自然かなと思います。
製造業の「トヨタ生産方式」でもよく知られる「品質は工程で作り込む（Built-in Quality）」という考え方があります。検査の段階で不良品を弾くだけでなく、製造の各ステップの中で最初から不良を出さない仕組みを作ろう、という思想です。ソフトウェア開発でも、比喩として同じことが言えると感じています。
仕様の考慮漏れや設計上のボトルネックといった課題は、実際のコードを書く前の段階ですでに生まれていることが多いです。テストで不具合を検知して直すアプローチも大切ですが、「そもそも仕様検討や設計の段階で、どうすればその不具合を作り込まずに済んだか？」と発生工程まで遡って振り返るほうが、より根本的な解決に近づけそうです。
インシデント対応のあとも、ポストモーテムで「いつ・どの判断で・どの工程にバグが入り込んだか」を言語化しておくと、この振り返りが次の改善につながりやすくなります。そのためには、個人を責めるのではなく仕組みを直す、非難しない（blameless）ポストモーテムが前提になる、とも思います。
個人の「注意深さ」だけに頼らず「安全なガードレール」をつくる
トラブルが起きたとき、「次から気をつけよう」とルールを増やすことも、経験上よくある話です。ただ、確認作業やルールをどんどん増やしていくと、どうしても開発時の負担が増えて、スムーズな開発がしにくくなってしまいます。
テストでの検知に留まらず、バグが生まれた工程にアプローチして同型の課題を根本から解決するには、「気をつける」という人間の注意力だけに頼るのではなく、「意識しなくても自然と安全に作れる状態（ガードレール）」を整備することがポイントなのかなと思います。
たとえば、「各自がレビュー時に気をつける」と注意喚起するよりも、設計の標準パターンを揃えたり、コードの静的解析や CI で危険な記述を自動検知したりするアプローチです。ポカヨケ（ヒューマンエラー防止策）の考え方を取り入れて、ミスが起きにくい枠組みを整えていく。
もちろんガードレール自体の設計・運用にもコストはかかります。それでも、属人的な注意力に依存し続けるより、チーム全体で再現性のある安全を作れるほうが、長期的には楽になることが多いと感じています。
開発者が変に身構えることなく、安心してのびのび開発できる環境を目指すほうが、結果としてチーム全体が幸せになれる気がします。
AIのおかげで、上流での品質づくりがやりやすくなってきた
「上流工程でしっかり品質を作り込もう」と言うと、人間が検討したりレビューしたりするコストが増えて、デリバリー全体が遅くなるんじゃないか、と心配になるかもしれません。
最近は、この課題を AI がかなり助けてくれるようになってきた、とも感じています。
設計書や仕様案の段階で、AI にセキュリティ、非機能要件、コーナーケースなどの観点から下書きレビューやチェックリスト生成をしてもらう。人間が手作業で漏れを探す負担を減らしつつ、AI と対話しながら仕様の穴を埋めていく、という使い方です。
現時点では、上流検討の質を上げる最初の一手として AI を使うのが現実的だと感じています。出力をそのまま採用するのではなく、人間が確認しながら仕様を磨いていく——そこまでを、まずはチームの目標にしてみる、くらいのイメージです。
過去のインシデントから学んだパターンを、AI のチェック観点やレビューボットに組み込んでおくのも有効です。ただ、そこも陳腐化しうるので、定期的な見直しがセットになると、より信頼できるガードレールになるはずです。
品質に向き合うことが、結果として開発のスピード感にもつながる
ソフトウェア工学では、後工程ほど修正コストが跳ね上がりやすい、という知見（いわゆる cost of change）は長く語られてきました。バリー・ボームの研究などでは、本番リリース後に見つかった課題の修正コストが、要件定義や設計段階より大幅に高くなる、という傾向が示されています。倍数はプロジェクトや文脈によって大きく変わるので、数字そのものより「手戻りを早く防ぐほどトータルコストを抑えやすい」という方向性のほうが、実務では参考になりやすいかなと思います。
また、DevOps の研究で有名な DORA（DevOps Research and Assessment）のレポートでは、デリバリー速度が高いハイパフォーマーなチームほど、変更失敗率が低く、トラブルからの復旧も速い、という結果が示されています。これは「上流だけ頑張れば速くなる」と直接証明しているわけではありませんが、速度と安定性は両立しうることは示唆しています。ハイパフォーマーは、小さな変更、自動テスト、CI/CD、観測可能性などもセットでやっている、というのが DORA 的な読み方です。
上流で品質を作り込むだけでなく、本番環境での観測・モニタリングや段階的リリースも、品質を後から確認・影響を限定する仕組みとして重要です。作り込みと検知・限定の両方を揃えることで、品質全体のバランスが取りやすくなります。
「スピードか、品質か」という二者択一ではなく、各工程で品質を作り込み、手戻りやインシデント対応を減らすことこそが、一因として、結果としてプロダクトを届けるスピードを最大化してくれる、という理解のほうがしっくりきます。
今後インシデントに向き合うときは、「どう検出するか」だけでなく「どの工程でバグが作り込まれ、どこで防ぐチャンスがあったか」という視点も大切にしていきたいです。
「品質は前工程で作る」という原点を意識しつつ、AI のような現代のツールも補助として賢く頼りながら、みんなが楽に安全に開発できる仕組み（ガードレール）へと還元していく。品質保証は特定の担当者や最終テストだけで完結するものではなく、仕様を考えて設計し、コードを書くプロセス全体の中でチームみんなで育てていくものなんだよね、という共通認識を深めていけたら素敵だなと思っています。
