はじめに

QAエンジニアとして10年以上やってきました。
障害の根本原因を追いかけると、結局「仕様の書き方が悪かった」と「要件や受入基準が曖昧だった」に帰結するケースが多いです。~~書く時間が無かったて。~~

実装のバグでもテストの漏れは想像力の欠如でもありますが、そもそも仕様の段階で条件や振る舞いが書き切れていない事が当然のようにありました。あります。
なので実装者は想像で補い、テスト設計者はどこをテストするか確証が持てず、結果として障害が出るケースが多かったなぁとしみじみ思っているわけです。

なので私なりに「上流工程の仕様品質が下流をどう詰ませるのか」を整理し、実務的な対策を提案できたらいいなぁと思ってます。

「筋が悪い仕様」とは何か

私から見た「筋が悪い仕様」とは、条件と振る舞いの対応関係が書き切れていない仕様のことです。

たとえば「金額に応じて割引を適用する」という仕様があったとします。あったとします。
突っ込み処が出ていると思いますが、一旦パッと私が思いついたのが下記なのでそれでいきたいと思います。

その金額の境界はどこか（5,000円単位等決まっている倍数なのか、自由に設定できるのか）
境界ごとに割引率は変更できるのか、一律なのか
端数は四捨五入なのか、切り捨てなのか、切り上げなのか
他の割引（クーポン等）との併用は可能なのか、不可能なのか
他の割引との優先度はどちらが上なのか
税率を含むのか、含まないのか
本体以外、つまり送料・手数料は含むのか

実装者はこの曖昧さを「多分こうだろう」で埋めます。
QAは「多分こう読めるだろう」でテストケースを作ります。
この2つの「多分」がずれたとき、障害になります。
よしんば障害にならなくともPdM（プロダクトマネージャー）や要望者が違うといったらおしまいです。
~~そうなる前にスプリント計画に入れる前に確認するか、リファイメントちゃんとやろう~~

一方、「5,000円未満は割引なし、5,000〜10,000円は5%、10,001円以上は10%で固定、クーポンとの併用時は割引率の高い方を適用、端数は切り捨て」と書かれていれば、実装もテスト設計も一意に決まります。
想像で補う余地がないからです。
~~ここでビジネス要件と比較しながらリファイメントで唸るのが醍醐味。拡張性も考えてると良し。~~

仕様には2つの層がある

ここで注意したいのは、仕様は1枚岩ではないということです。多くの開発現場では、仕様は以下の2層に分かれています。

機能仕様（基礎仕様） — PdMやPO（プロダクトオーナー）が書く「何を作るか」。ビジネスロジック、ユーザーから見た振る舞い、受入基準。「5,000円以上で送料無料」のような話がここに該当します。

技術設計（実装仕様） — EN（エンジニア）が書く「どう作るか」。DB設計、API設計、既存テーブルとの関係、パフォーマンス要件、エラーハンドリング方針。

「筋が悪くなる」パターンは2つあります。

1つ目は、機能仕様の段階で曖昧なケース。先ほどの割引の例がこれに当たります。
条件と振る舞いが書き切れていないため、エンジニアもテストエンジニアも想像で補うことになります。

2つ目は、機能仕様は明確なのに、技術設計に落とすときにズレるケース。
たとえば機能仕様で「5,000円以上で送料無料」と書いてあっても、技術設計で「税込か税抜か」「ポイント利用後の金額か利用前か」が定義されていなければ、実装者の解釈で決まってしまいます。

どちらの層で曖昧さが紛れ込んでも、結果は同じです。ここよりも下流が詰む可能性が増えます。

なぜ上流で詰むと下流が全部詰むのか

開発フローを整理すると、仕様の曖昧さがどこで顕在化するかが見えてきます。

市場調査 / 要望受理
        ↓
    要件定義
        ↓
    受入基準作成
        ↓
    機能仕様作成　　　　　      ← 1層目：何を作るか
        ↓
   ┌────┴────┐
   ↓         ↓
 技術設計　　　 テスト設計　　   ← 2層目：どう作るか / どうテストするか
   ↓         ↓
 設計レビュー ⇔ 観点レビュー    ← ★ 要・相互レビュー
   ↓         ↓
 実装・PR作成   TC作成
   ↓         ↓
 PRレビュー   ⇔ TCレビュー     ← ★ ほぼ最後の気付きチャンス
   └────┬────┘
        ↓
  マージ＆テスト実施　　　　　  ← ★ 要・バグバッシュ

仕様の曖昧さは、概ね受入基準作成の段階から紛れ込み始めます。
そして曖昧さは、下流工程に伝播していきます。

開発側は曖昧な仕様を 「自分の解釈」 で実装します。
QA側は曖昧な仕様を 「自分の解釈」 でテスト設計します。
この2つの解釈がたまたま一致すれば障害は出ませんが、まぁ無いです。
一致しなければ、レビューの段階で初めて「仕様の意図はどっちだったのか」という議論が始まります。
つまりレビューが、上流工程で防げたはずの曖昧さに気づける最初のチャンスです。

そして次の気づきのチャンスはテスト実施の段階ですが、ここを過ぎれば障害や意図しない損失に直結します。
仮にテスト実施あるいはリリース前で気づけたとします。

この段階での手戻りは障害を除けば最もコストが高いです。

実装は完了している。
テストは開始している。
場合によってはリリース日が迫っている。
そこから仕様の認識合わせをやり直すことに……さぁ残業のお時間です！！
~~大人しくリリースをずらしましょう。他にも出てくるはずです。私ならそうします。~~

仕様レビューで何を聞くべきか

最低でも設計レビューと観点レビューの段階で相互レビューを行うことが重要です。
開発とQAがそれぞれ別々にレビューするのではなく、QAが仕様を読んでテスト設計の観点からフィードバックする。

ただし「この仕様でテストできますか？」という聞き方は当然ながら相手が「え、喧嘩？」となります。
レビューに帯同していたらまぁまぁな土下座案件です。酒を奢りましょう。ました。８年前位に。
なので以下の観点で確認します。

条件の網羅性： この機能の入力に対する条件分岐は全部書かれているか。
振る舞いの明確性： 各条件に当てはまったあとの処理は、入力値によって結果が変わるか。変わるならその境界はどこか。
既存機能との整合性： 新機能の条件が既存の割引・ポイント・キャンペーン等と組み合わさったとき、優先順位や計算順序は明記されているか。（多分一番漏れやすい箇所）
異常系の定義： 条件に当てはまらないケース（境界外、null、想定外の型）の振る舞いは定義されているか。

これらの問いに仕様書を見てわかるなら、その仕様は「筋が良い」事になります。
回答できないなら、仕様が足りていません。
経験上、怖い点はサボっているわけではない事もままあります、自覚が無いのが一番怖い。

仕様品質を組織的に担保する仕組み

レビューで「何を聞くか」がわかっても、それを毎回人の意識だけで回すのは限界があります。
仕様の品質を組織的に担保するために、以下の3つの仕組みを組み込むと概ね良い結果になります。
特に今ならAIを活用しない手はないでしょう、ということで私なりのモダン的解釈を出しときます。

大前提：解った事は書き残す

チケットなりリファイメント資料に書き残しましょう。
今なら議事録AIもあるので各イベント後で書くのも簡単だと思います。

記録する、私の好きな言葉です。

1. 要件と受入基準のAI品質ゲート

※品質ゲートとは、次の工程に進む前に「この基準を満たしているか」を確認する関所のようなイベントです。
基準を満たさなければ先に進めない、というルールにすることで、曖昧な仕様が下流に流れるのを防ぎます。

リファインメント完了時に、仕様書をAIに通して条件の抜け漏れを機械的にチェックします。
リファイメントでのチケットの完了条件にこのチェックの通過を含めることで、属人性を排除できます。

※DevinなどでGitリポジトリから自然言語の仕様書を自動生成し、それをベースに条件の網羅性を検証する方法も有効です。
※※或いは最初はすり抜けるものとしてskills等で補ってください。小さく作って完成に向けて長期で頑張る方向にしましょう。

2. 既存仕様との整合性チェック

新機能の仕様と既存機能の仕様をAIに読み込ませ、矛盾や条件の漏れを検出します。
機能が積み重なったプロダクトは人間のレビューだけでは既存仕様との不整合を見落としやすい為、AIによる補完が効きます。

※このチェックは受入基準～仕様が固まった直後の間に配置すると結構効きます。

3. リファインメント議論の十分性の事後検証

障害発生時の根本原因分析で「リファインメント等の各フェーズで拾えたはずの仕様漏れだったか」を確認し、プロセス改善につなげます。

具体的には、障害チケット（或いはテスト中バグチケットにも）に「要件起因」「受入基準起因」「仕様起因」「実装起因」「テスト漏れ」等、開発フローごとのラベルをつけて比率を可視化します。
この数字があると、レトロスペクティブでの議論が「気をつけましょう」で終わらず、「仕様起因が全体の○%を占めているから上流のチェックを強化しよう」という具体的なアクションにつながります。
特にチームが多くなり、単独スクラムからLSMへ移行するあたりや 各プロダクト連携が必須 になってきたフェーズから刺さります。

品質ゲートが定着しないケースとその対策

品質ゲートの導入を提案しても、採用されない・定着しないケースがあります。よくあるパターンと対策を整理します。

「スピード優先」で足枷に見える

スタートアップや新規事業フェーズで「まず出してから直す」が文化になっていると、品質ゲートはリリース速度を落とす足枷に見えます。

対策としては、品質ゲート自体を軽くすることです。AIによる自動チェックなら数分で完了します。「人間のレビュー会議を増やす」ではなく「AIに仕様を通すだけ」という見せ方にすれば、スピードとの両立が可能であることを示せます。

通過基準が曖昧で形骸化する

「AIに通してチェック」と言っても、何をもって通過とするかが定義されていないと毎回判断が属人化します。
結局「通過したことにしよう」が常態化して廃止されるパターンです。

対策は、通過基準を具体的に定義することです。
例えば大枠として「すべての条件分岐に対して、入力と出力の組み合わせが明記されていること」「異常系の振る舞いが定義されていること」のように、Yes/Noで判定できる基準にします。

コスト対効果が証明できない

品質ゲートの工数は目に見えますが、品質ゲートがなかったことで発生したはずの手戻りの工数は見えにくいです。
「毎スプリント2時間かかっている」は言えても、「なければ手戻りで10時間かかっていた」は証明しにくく、予算やリソースの承認が下りません。

対策は、先に述べた障害チケットの「要件起因/受入基準起因/仕様起因/実装起因/テスト漏れ」ラベルです。
品質ゲート導入前後で仕様起因の障害件数と手戻り工数を比較できれば、コスト対効果を数字で示せます。
テストブロッキング時間も含めて良いでしょう。

仕様の責任範囲が不明確

PdMは「機能仕様は書いた、あとはエンジニアの責任」、エンジニアは「仕様が曖昧なのはPdMの責任」と互いに考えていると、品質ゲートを誰が主導するかで揉めて導入が止まります。

対策は、品質ゲートの運用をQAが担うことです。
QAは機能仕様も技術設計もテスト設計の観点で読む立場にあるため、どちらの層に曖昧さがあるかを中立的に指摘できます。
責任の押し付け合いにならず、「仕様の品質をチーム全体で上げる」という方向に持っていけます。
QAが居ないチームの場合は他所のチームのPdMやENに依頼できるような組織的フットワークの軽さを持つようにしましょう。

導入は小さく始める

3つの仕組みをいきなり全チームに導入するとハードルが高いため、1つのチームから展開するのが現実的です。

仕様起因の障害が多いチームよりも、チームの受容性が高いところから始めるのがおすすめです。
なるべく早く適切なFBが手に入ることが目的なので。
なのでAIに抵抗がなく、リファインメント等も回っているチームが結果を良きにせよ悪しきにせよ出してくれます。
~~仕込みとして他チームの飲み会に出入りしとくと楽なのは令和でも変わらず。~~

「AI品質ゲートを入れたら仕様起因の障害がこれだけ減った」という実績があれば、他チームへの展開はスムーズにいきます。
数字なしで一斉導入しようとすると「工数が増えるだけ」という抵抗が出る為、絶対に避けてください。
まず1チームで証明するのが近道です。

まとめ

障害の多くは、仕様が条件と振る舞いを書き切れていないことに起因する。
仕様の曖昧さは開発とQAに伝播し、テスト実施段階で最もコストの高い手戻りを生み、最悪障害と仕様変更コストも嵩む。
レビューでは「条件分岐は全部書かれているか」「各条件の振る舞いは入力値で変わるか」を具体的に問いかけてリファイメント資料に記録する。
AI品質ゲート、既存仕様との整合性チェック、障害起因の事後分析の3つをルール化する。
導入は受容性の高い1チームから始める。

上流工程の仕様品質は、テスト技法やテスト自動化では補えません。
テストは仕様が書き切れていて初めて信頼できるものになります。
品質を下流で担保するのではなく、上流で作り込む。
そのための仕組みを、まず1つのチームから始めてみてください。
小さく作り、小さく伝播させ、小さな結果を求めてください。

千里の道も一歩から、私の好きな言葉です。