16. レビューで感じる「あれ、何か違うぞ」の正体を考える ~違和感をレビュー観点に変えるには~

この記事で考えたいこと

レビューをしていると、成果物の内容に対して、明確に間違っているとは言えないものの、「何か違う」「何か足りない気がする」と感じることがあります。

その違和感は、レビュアの経験や過去のパターン比較から生まれる、大事なサインかもしれません。

一方で、その違和感をそのまま「何となく違う」「足りていない気がする」と伝えても、レビュイーには何を確認すればよいのか、何を直せばよいのかが伝わりにくくなります。

違和感は、レビュー活動において有用な入口になり得ます。
ただし、レビューの場で扱うには、その違和感を言語化し、参加者間で共有できる形にする必要があります。

この記事では、レビューで感じる「あれ、何か違うぞ」という違和感の正体を考えながら、それを成果物の品質改善につながるレビュー観点や問いへ変える方法について考えてみます。

はじめに：違和感でレビューが止まることがある

レビューをしていると、明確な誤りを見つけたわけではないのに、成果物を読んでいて引っかかることがあります。

用語が大きく間違っているわけではない。
記述も一見整っている。
結論もすぐに否定できるものではない。

それでも、

あれ、何か違うぞ。

と感じることがあります。

この違和感は、レビューにおいて無視できないものです。
しかし、そのままレビューの場に出すと、うまく伝わらないことがあります。

たとえば、

何か違う気がします。
もう少し考えてください。
何となく足りていない気がします。

と言われたとき、レビュイーは困ってしまいます。

何が違うのか。
何を確認すればよいのか。
どこを直せばよいのか。
どの観点で考え直せばよいのか。

それが分からないままでは、違和感は品質改善の入口ではなく、レビューを止める言葉になってしまいます。

この記事では、この「違和感」を否定するのではなく、レビューで扱える形にするにはどうすればよいかを考えます。

前回までの整理

12本目の記事では、良い問いとは何かについて考えました。

12. 良い問いとは何か？ 問いの内容・タイミング・関係性・文脈を考える

そこでは、問いは内容だけでなく、タイミング、関係性、文脈によって機能の仕方が変わるものとして整理しました。

前回の記事では、文面レビューで進めてよい時と、同期レビューで合わせた方がよい時について考えました。

15. 文面レビューで進めてよい時、同期レビューで合わせた方がよい時 ~問いが機能するレビュー形式の比重を考える~

文面レビューと同期レビューは、どちらが優れているかで選ぶものではありません。
問いが機能する状態を作るために、文面で進めるのか、同期で認識を合わせるのか、その比重を切り替えるものだと考えました。

今回は、その問いの内容が生まれる前段にある「レビュアが何に引っかかっているのか」に注目します。
良い問いを出す前には、何かしらの気づきや違和感があることが多いからです。

違和感は、思考の流れの差分から生まれるのではないか

レビューで感じる違和感は、単なる気分や好みとは限りません。

レビュアは成果物を見ながら、自分の経験や過去のパターンと照らし合わせています。

この要求仕様なら、もう少し入力値の候補がありそうではないか。
このテスト設計なら、先に入力条件の整理が必要ではないか。
この期待結果に至るなら、状態や条件をいくつか確認しているはずではないか。
この成果物の粒度なら、ここまで詳細に決める前に、まず確認範囲を合わせるべきではないか。

このような比較は、明示的に行われる場合もあれば、無意識に近い形で行われる場合もあります。

私は、レビュアが成果物を見たとき、頭の中で成果物が作られるまでの思考の流れを再現しているのではないかと考えています。

たとえば、テスト設計であれば、次のような流れです。

要求仕様の分析
↓
入力条件の整理
↓
入力値の候補洗い出し
↓
分類・代表値の選択
↓
期待結果の設定
↓
テストケース化

レビュアは成果物だけを見ているようでいて、その背後にある流れも見ています。

このテストケースは、どの要求仕様から作られたのか。
どの入力条件を整理したのか。
どの入力値を候補として洗い出したのか。
なぜこの値を代表値として選んだのか。
どの条件や状態から、この期待結果を導いたのか。
なぜこの粒度でテストケース化しているのか。

レビュアは、こうした流れを頭の中でたどり直しているのだと思います。

そして、自分の中で再現した思考の流れと、成果物から読み取れる思考の流れが合わないときに、

あれ、何か違うぞ。

という違和感が生まれるのではないでしょうか。

この違和感は、成果物の結論そのものが間違っているという判断ではありません。
むしろ、成果物の内容や作成者の思考の流れと、レビュアが頭の中で再現した思考の流れとの間に差分があると感じた状態です。

ただし、違和感を感じること自体が目的ではありません。

レビューでは違和感の有無にかかわらず、必要な観点に沿って確認する必要があります。
入力値、入力条件、期待結果、状態遷移、境界条件、例外条件、前提、根拠などは、違和感を感じたかどうかに関係なく確認すべきものです。

違和感はレビューの代替ではありません。
あくまで、確認すべきことに気づくための入口の一つです。

具体例：テスト入力値が決め打ちに見えるとき

たとえば、ある要求仕様に対してテスト設計をレビューしている場面を考えます。

要求仕様を読むと、入力値としてはA以外にも、BやCのような値があり得そうに見えるとします。

しかし、テスト設計書では、入力値としてAだけが選ばれている。

このとき、Aを選んでいること自体が間違っているとは限りません。

実際には、複数の入力値を分析したうえで、代表値としてAを選んだのかもしれません。
BやCは別のテストで確認済みなのかもしれません。
方針や制約により、今回はAだけを対象にしているのかもしれません。
あるいは、同値分割や境界値分析の結果として、Aだけで十分だと判断したのかもしれません。

しかし、その検討過程が成果物から見えない場合、レビュアは次のように感じます。

要求仕様からすると、A以外の入力値もあり得そうに見える。
なぜ今回のテスト入力値はAだけなのだろうか。
他の入力値は検討したうえで除外したのだろうか。

この時点では、まだ「Aだけでは誤り」と言えるわけではありません。

レビュアが感じているのは、Aという選択への否定ではなく、Aに絞った理由や、他の入力値をどう扱ったのかが見えないことへの違和感です。

つまり、この場合の違和感は、

選ばれた入力値が間違っていること

ではなく、

入力値を選ぶまでの比較検討の流れが見えないこと

から生まれていると考えられます。

このようなとき、レビュアがいきなり、

Aだけでは足りないのではないですか。

と言うと、レビュイーは「Aではだめなのか」と受け取るかもしれません。

しかし、本当に確認したいのはAがだめかどうかではなく、A以外の入力値をどう扱ったのかです。

他の入力値を検討したうえで代表値としてAを選んだのか。
BやCは別の観点で確認済みなのか。
要求上はあり得るが、今回のテスト対象外として除外したのか。
それとも、そもそも入力値の洗い出しが不足していたのか。

ここを確認しないと、違和感の正体は分かりません。

違和感を、レビュー観点と問いに分ける

ここで、本記事での「レビュー観点」と「問い」の関係を整理しておきます。

この記事では、違和感を分解して得られた「確認すべき論点」をレビュー観点と呼びます。
そして、そのレビュー観点をレビュイーと確認するための表現を問いと呼びます。

たとえば、「入力値がAに決め打ちされているように見える」という違和感があったとします。

この違和感を分解すると、確認すべき論点としては、

代表値の選択理由

が出てきます。

これがレビュー観点です。

そのレビュー観点をレビュイーと確認するためには、

A以外の入力値は検討しましたか？
代表値としてAを選んだ理由はありますか？

という問いに変える必要があります。

つまり、この記事では次の流れで考えます。

違和感
↓
確認すべきレビュー観点
↓
レビュイーに返す問い

違和感をそのまま言葉にするのではなく、まずレビュー観点に分解する。
そのうえで、レビュイーが答えられる問いに変える。

これが、違和感をレビューで扱える形にするということだと思います。

こんな違和感を感じたら、何を問いにするか

違和感をレビューで扱うには、まず「何に引っかかったのか」をたどり直す必要があります。

ここでは、テスト設計のレビュー中に起きやすい違和感をいくつか挙げ、それをレビュー観点と問いに分けて考えてみます。

感じる違和感	背後にありそうなこと	確認するレビュー観点	レビュイーに返す問い
要求仕様から見ると、複数の入力値がありそうに見える	入力値の洗い出しや分類が見えない	入力値の洗い出し・分類	要求仕様から想定できる入力値を、どのように洗い出しましたか？
入力値がAに決め打ちされているように見える	他の入力値を検討した痕跡が見えない	代表値の選択理由	A以外の入力値は検討しましたか？ 代表値としてAを選んだ理由はありますか？
入力値と期待結果の対応理由が見えない	条件や状態から期待結果を導く過程が見えない	入力条件と期待結果の対応	この入力値に対して、この期待結果になることを、どの条件や状態から確認しましたか？
単機能確認と組み合わせ確認の切り分けが見えない	テストの目的や確認対象が曖昧になっている	テスト目的と確認対象の切り分け	このテストは単機能の振る舞いを確認するものですか？ それとも複数機能の組み合わせを確認するものですか？
結論はあるが根拠が見えない	判断理由や比較結果が残っていない	判断理由・比較結果	この判断に至った理由や、比較した観点を確認できますか？
粒度が合っていない	成果物の成熟度と記述レベルがずれている	成果物の成熟度と記述粒度	今回は方針確認の段階ですか？ 詳細確認の段階ですか？

ここで重要なのは、違和感の種類に正しい名前をつけることではありません。

大事なのは、違和感を確認すべきレビュー観点に分解し、相手が答えられる問いに変えることです。

たとえば、「入力値と期待結果の対応理由が見えない」という違和感がある場合、レビュアが確認したいのは、期待結果が間違っているかどうかだけではありません。

その入力値を、どの条件で使うのか。
どの状態を想定しているのか。
なぜその条件や状態では、その期待結果になるのか。
他の状態では期待結果が変わらないのか。
その期待結果は要求仕様のどこから導いたのか。

そうした思考の流れを確認したいのだと思います。

この場合のレビュー観点は、

入力条件と期待結果の対応

です。

そのため、問いとしては、

この入力値に対して、この期待結果になる理由を、どの条件や状態から確認しましたか？

のように聞く方が、レビュイーは答えやすくなります。

違和感をそのまま言葉にするのではなく、どの思考の流れを確認したいのかをレビュー観点にする。
そして、そのレビュー観点をレビュイーに伝わる問いにする。

これが、違和感をレビュー観点に変えるということだと思います。

違和感をレビュー観点と問いに変えるときの考え方

違和感を問いに変えるには、次の順番で考えるとよさそうです。

1. 何に引っかかったのかを言葉にする
2. その違和感が、どの思考の流れに関係しているかを見る
3. 確認すべきレビュー観点を整理する
4. レビュイーが答えられる問いに変える

たとえば、「入力値がAに決め打ちされているように見える」と感じた場合を考えます。

このとき、レビュアが本当に確認したいことは、

なぜAだけにしたのか。

だけではないはずです。

むしろ、

• 他の入力値を検討したのか

• 検討したうえで除外したのか

• 代表値としてAを選んだのか

• 方針や制約によりAだけに絞ったのか

• 成果物に書いていないだけなのか

• そもそも未検討なのか

を確認したいのだと思います。

この場合、確認すべきレビュー観点は、

代表値の選択理由

です。

そうであれば、問いは次のようにできます。

要求仕様からすると、A以外の入力値もあり得そうに見えました。
今回はAだけが選ばれていますが、他の入力値は検討したうえで除外したものなのか、代表値としてAを選んだものなのかを確認したいです。

この問いであれば、レビュイーは何を答えればよいか分かります。

• 他の入力値は検討済みで、代表値としてAを選んだ

• BやCは別のテストで確認している

• BやCは要求上は見えるが、仕様上は発生しない

• 今回のテスト範囲ではAのみを対象としている

• 実は入力値の洗い出しが不足していた

• 成果物に記載すべき判断理由が抜けていた

といった回答が可能になります。

つまり、問いにすることで、レビュアの違和感はレビュイーと共有可能な論点になります。

レビュイーには、違和感ではなく問いとして伝える

レビュイーに伝えるべきなのは、違和感そのものではありません。

何か違う気がします。

ではなく、

何を確認したいのか。

を伝える必要があります。

違和感をそのまま伝えると、レビュイーは何を直せばよいか分かりません。
しかし、問いに変えれば、レビュイーは自分の思考の流れを説明できます。

その説明を通じて、成果物の不足が見つかるかもしれません。
あるいは、レビュア側の前提違いが分かるかもしれません。
どちらであっても、レビューとしては前に進みます。

ここで大事なのは、問いを相手を追い詰めるために使わないことです。

問いは、レビュアの違和感が正しいことを証明するためのものではありません。
レビュアとレビュイーが、成果物に至る思考の流れを一緒に確認するためのものです。

そのためには、次のように伝えるとよさそうです。

結論が間違っていると言いたいわけではありません。
ただ、このテスト入力値を選ぶまでに、どの入力値を候補として見たのかを確認したいです。

このように言えば、違和感は詰問ではなく、確認可能な問いになります。

作成者にとっても、違和感は見直しの入口になる

違和感は、レビュアだけのものではありません。

成果物を作成している本人も、作成中に、

何か足りない気がする。
このまま出すのは少し不安だ。
どこが足りないのかは分からないが、何か抜けていそうだ。

と感じることがあります。

このときも、違和感をそのままにせず、思考の流れをたどり直すことができます。

テスト設計であれば、たとえば次のような観点です。

• 要求仕様は十分に読めているか

• 入力条件は整理できているか

• 入力値の候補は洗い出せているか

• 同値分割や境界値など、値を選ぶ理由は説明できるか

• 代表値として選んだ理由はあるか

• 除外した入力値の理由は説明できるか

• 期待結果は要求仕様や状態から導けているか

• テスト対象の範囲は明確になっているか

• 成果物の粒度は今の段階に合っているか

作成者にとっての違和感は、セルフレビューの入口になります。

何か足りない気がする。
その感覚があるなら、要求仕様、入力条件、入力値、期待結果、判断理由のどこに引っかかっているのかを確認してみる。

そうすることで、レビューを受ける前に、自分で成果物の弱い部分に気づけるかもしれません。

違和感を扱うときに気をつけたいこと

違和感は大事なサインになり得ます。
しかし、扱い方を間違えると、レビューを難しくします。

特に気をつけたいのは、違和感をレビューの結論にしないことです。

何か違う。
だから直してください。

では、レビュイーにとっては困ります。

違和感は、まだ仮説の入口です。
その違和感が正しいかどうかも、まだ分かりません。

レビュアが感じた違和感は、検討漏れを示しているかもしれない。
成果物への説明不足を示しているかもしれない。
レビュアの前提違いかもしれない。
レビュー対象の成熟度と期待値が合っていないだけかもしれない。

だから、違和感を感じたときほど、いったん問いに戻す必要があります。

私はここに引っかかりました。
ただ、結論が間違っていると言いたいわけではありません。
この入力値を選ぶまでに、どの候補を見たのかを確認したいです。

このように伝えられれば、違和感は詰問ではなく、思考の流れを確認するための入口になります。

今回は扱わなかったこと

今回は、レビューで感じる違和感を、レビュー観点や問いに変えることに絞って考えました。

そのため、次のことは深く扱っていません。

• 違和感を感じる力をどう育てるか

• 熟練レビュアの暗黙知をどう教育するか

• 違和感をレビュー観点表として標準化する方法

• レビューで得られた違和感や問いを組織知としてどう残すか

• AIが違和感を検出できるか

これらも重要なテーマですが、今回の記事では、まず「違和感をそのまま止めず、問いに変える」ことに焦点を当てました。

おわりに

レビューで感じる「あれ、何か違うぞ」は、単なる感覚や好みではないかもしれません。

それは、成果物の内容や作成者の思考の流れと、レビュアが頭の中で再現した思考の流れとの間に生まれる差分なのかもしれません。

その差分は、入力値が決め打ちに見えることとして現れるかもしれません。
なぜその入力値に対して、その期待結果になるのかが見えないこととして現れるかもしれません。
単機能で確認したいことと、複数機能の組み合わせで確認したいことの切り分けが見えないこととして現れるかもしれません。
判断理由や検討結果が残っていないこととして現れるかもしれません。

ただし、その違和感は、そのままではレビュイーに伝わりません。

違和感を感じること自体が重要なのではなく、違和感を感じたときに、そこで止まらず、何に引っかかったのかをたどり直すことが大切なのだと思います。

要求仕様を見たのか。
入力条件を見たのか。
入力値の候補を見たのか。
期待結果を見たのか。
判断理由を見たのか。
成果物の粒度を見たのか。

そこをたどることで、違和感はレビュー観点になります。
そして、レビュー観点にできれば、レビュイーに伝わる問いに変えられます。

違和感は、相手を止めるための言葉ではなく、一緒に思考の流れをたどり直すための入口として扱いたいものです。

次は、レビューで得られた問いや判断を、組織にどう残していくかについて考えてみたいと思います。

この連載の全体像はこちら：
車載ソフトウェア品質保証を考える：連載まとめ