V字モデルを「時間軸」として読んでいないか？
仕様どおりなのに、なぜ「これでは使えない」と言われるのか。V字モデルの読み方から考えてみます。
※執筆にあたり生成AIとの対話を活用しています。
システム開発の終盤で、こんな言葉が出ることがあります。
「仕様どおりに動いているのはわかる。けれど、これでは使えない」
この言葉は、かなり重いものです。
単なるバグであれば、まだよいのです。原因を探し、修正し、再試験できます。しかし「これでは使えない」は、システムとしては動いているのに、仕事の流れの中では効いていない、という意味を持っています。要件レベルの不適合は、画面の誤りや処理のバグとは違い、業務・運用・利用者の判断、場合によってはシステムの構造そのものに関わります。そして、開発プロジェクトがこじれるのは、しばしばこの種類の問題です。
それほど危ない確認が、なぜ最後の方で初めて顔を出すのか。
「こと」に変えればテスト仕様書になる
昔、古い先輩からこんなことを言われました。
「仕様書の語尾を『こと』に変えれば、それがテスト仕様書だ」
たとえば「異常発生時に警報を表示する」は、「異常発生時に警報が表示されること」になる。なるほど、と思いました。けれど同時に、どこかに決して小さくはない違和感も覚えていました。当時は、それをうまく説明できませんでした。
いま思うと、抜け落ちているのは仕様の文面ではなく、仕様が本来持っていた意味だったのだと思います。
警報が出ることと、異常に気づけること
「異常発生時に警報を出力する」という仕様を下流で具体化すると、こうなります。
警報一覧にメッセージが追加されること。画面上に警報アイコンが表示されること。ブザーが鳴ること。ログに記録されること。確認操作をすると状態が変わること。
どれも必要です。そして確認されるべきものです。
しかし、その要件が本当に実現したかったことは、単に画面のどこかに警報が表示されることだったのでしょうか。おそらく、そうではありません。本当は、
「異常発生時に、担当者が見落とさず、優先度を判断し、次の行動に移れること」
だったのではないでしょうか。
警報が出ることと、担当者が気づけることは、似ています。けれど、同じではありません。
具体的な表示や音やログがなければ、業務上の判断は成立しません。しかし、それらを一つずつ確認したからといって、上流の価値が確認されたことにはなりません。ブレークダウンは必要です。しかし、分けることと、もとの意味をそのまま保存することは違います。具体化の過程で、意味が痩せることがある。ここに、私たちは意外と無自覚なのではないかと思います。
上流の仕様は、まだ少し湿っています。業務の温度があり、現場の迷い方があり、このシステムによって何が守られてほしいのかという感覚があります。それが下流で機能に分解され、画面に落ち、処理条件になり、試験項目になっていくとき、言葉は乾いていきます。間違ってはいない。しかし、十分ではないことがある。この状態が、プロジェクト終盤で扱いにくくなります。開発側は「仕様どおりです」と言える。利用者側は「これでは使えない」と感じている。どちらも嘘ではないから、問題がこじれるのです。
V字モデルを時間軸として読んでいないか
V字モデルでは、要件定義に対応するのがシステム総合テストや受入テスト、基本設計に対応するのが結合テスト、詳細設計に対応するのが単体テストとされています。
多くの現場では、この図を自然に時間軸として見ています。左から右へ時間が進み、上流から降りていき、実装を底にして、テストで上がってくる。工程管理としては自然です。
けれど、V字モデルを時間軸としてだけ読むと、右側のテストが「後でやる作業」に見えてしまいます。受入テストは最後にやるもの。要件定義の妥当性は、そこで確認するもの。その結果、一番危ない確認がプロジェクト終盤に初めて行われる構図になります。
受入テストで「これでは使えない」と言われる問題は、受入テストの段階で突然生まれたわけではありません。
V字モデルの右側は、単なる未来の作業ではないはずです。それは、左側で書いた言葉が後にどのように検証されるかを示す対応関係でもある。要件定義を書いている時点で、受入テストの影はすでにそこにある。V字モデルは、時間軸である前に、対応関係の図なのではないでしょうか。
では、なぜその対応関係に気づいていながら、上流で十分に扱えないのでしょうか。そこには、もうひとつ別の思い込みがあるように思います。
差分は、語られない
具体化には、暗黙の前提があります。
「正しく具体化すれば、上流の意味はすべて保存される」
だから、具体化の他に差分を確認するという発想が生まれない。ここでいう差分とは、仕様が具体化されたあとに残る、上流の意図とのずれのことです。
それどころか、そういう確認を求めることは、具体化が不完全だったという意味になってしまう。語ることが、それ自体として問題の告白になる。だから、差分は語られません。
しかし、具体化と意味の保存は、本当に同じことなのでしょうか。
分けることと、もとの意味をそのまま保存することは違う、と先に書きました。であれば、具体化とは別に「価値が保存されているか」を確認するプロセスが、本来は必要なはずです。それは具体化を否定することではなく、具体化を補完することです。
その補完が、現在のプロジェクト工程の中で、十分に明示的な作業として扱われていないことが多い。だから差分は積み上がり、終盤になって初めて問いが現れます。
「これは、本当に業務で使えるのか」と。
「何を価値として確認するか」
テスト設計には二つの層があります。
ひとつは「何を具体的に確認するか」。警報が表示されること、帳票が出力されること、性能値が基準内に収まること。これは必要で、下流では必ずここに落としていかなければなりません。
もうひとつは「何を価値として確認するか」。その機能によって業務上何が成立していなければならないのか。利用者は何を判断できなければならないのか。異常時にどのような状態へ導けなければならないのか。
この二つはつながっています。しかし、同じではありません。具体的な確認項目を積み上げれば、自動的に価値の確認に到達するわけではない。
ここで「物が動いてからでないと確認できない」という声があります。画面を見ないと分からない、想像できない——それは半分正しい。しかし、具体的な確認方法を今すべて決められないことと、何を価値として確認すべきかも今は決められないことは、同じではありません。警報をどの位置に出すか、色をどうするかは後工程で明らかになる。しかし「担当者が見落とさないこと」「重要度を判断できること」「次の行動へ移れること」は、上流でも言葉にできるはずです。むしろ、上流で言葉にしておかないと危ない。
右側は、左側の影である
上流工程で必要なのは、最後の試験項目を細かく決め切ることではありません。
「この要件は、何が成立すれば価値を満たしたと言えるのか」
を合意することです。この合意があると、下流で仕様を具体化するときに何を痩せさせてはいけないかが見えます。テスト項目を作るときにも、仕様文を「こと」に変えるだけでなく、その仕様が守ろうとしていた価値に立ち戻ることができます。
V字モデルは、単なる工程表ではありません。それは、上流で書いた言葉に対して「それは、どうやって確かめるのか」と静かに問い続ける図です。
仕様を具体化するたびに、何が明確になり、何が痩せたのかを見に行くこと。その問いを、工程の終盤まで先送りしないこと。
たぶん、それがV字モデルを本当に使うということなのだと思います。
※似た問いを、別の記事でも考えています。
「仕様どおりなのに、これでは使えない」と言われるのは、本当にテスト不足なのか。今回の記事と近い問題を、少し別の角度から眺めています。
