この記事で考えたいこと

この記事で考えたいのは、次のことです。

良い問いは、問いそのものだけでは機能しない
レビューでは、何を見るのか、まだ見ないものは何かをそろえる必要がある
問いが機能する場を作ることも、レビュー設計の一部である

前回の記事では、良い問いを個人のセンスにしないために、問う側をどう支援するかを考えました。
13. 問う側をどう支援するか？　良い問いを個人のセンスにしないために

今回は、その続きとして、問いが機能するレビューの場では何をそろえる必要があるのかを考えてみます。

はじめに：現場で起きる違和感

レビューをしていると、問いや指摘そのものは悪くないはずなのに、うまく機能しないことがあります。

たとえば、

判断理由を確認したい
前提を確認したい
対象範囲を確認したい
どこで迷っているのかを知りたい

と思って問いかけているのに、相手が正解を探し始めたり、防御的になったり、「指摘通りに直します」と返ってきたりすることがあります。

この時、問いの言葉だけを見れば、それほど悪い問いではないかもしれません。

この判断は、どの前提に基づいていますか？

この条件を対象外にした理由は何ですか？

今回のレビューでは、全体構成を見ればよいですか？それとも詳細まで見た方がよいですか？

このような問いは、判断理由や前提を確認するためには有効な問いに見えます。

しかし、レビューの場が整っていないと、問いはうまく機能しないことがあります。

作成者がまだ方向性に迷っている。
成果物を完成版として見てほしいのか、相談段階として見てほしいのかがそろっていない。
レビュアは方向性を確認したいのに、作成者は完成度を評価されていると受け取っている。

このような状態では、問いは支援ではなく、追加の指摘や詰問のように受け取られることがあります。

問題は、問いそのものだけではないのかもしれません。

問いが機能するためのレビューの場が、まだ整っていないのです。

前回までの整理

前回の記事では、「問う側をどう支援するか」について考えました。

良い問いを投げることは、良い質問文を知っていればできるものではありません。

問う側は、レビューの中でさまざまな判断をしています。

相手が考えているなら待つ。
考えたいが整理できていないなら、足場を渡す。
正解確認に寄っているなら、判断理由を確認する場に戻す。
疲労や頑なさが見えるなら、いったん止める。

つまり、問う側は単に質問しているのではなく、相手の状態やレビューの局面を見ながら、問いの出し方を調整しています。

今回は、その問いが機能する前提として、レビューの場では何をそろえる必要があるのかを考えます。

結論：この記事で言いたいこと

先に結論を書くと、私は次のように考えています。

レビューの場を設計するとは、良い質問を並べることではなく、問いが機能する前提をそろえることではないか。

もう少し具体的に言うと、

今回のレビューで何を見るのか
まだ見ないものは何か
成果物をどの成熟度として扱うのか
作成者は何を迷っているのか
完成度を見るのか、方向性を合わせるのか
その場で扱うことと、持ち帰ることをどう分けるのか

をそろえることです。

これらが曖昧なままレビューを始めると、問いの目的も曖昧になります。

問いが悪いのではなく、問いを受け取るための前提がそろっていない場合があるのです。

何が問題になるのか

レビューの場で何を見るのかがそろっていないと、問いの受け取り方がずれます。

たとえば、作成者は「まだ方向性を相談したい」と思っている。
しかし、レビュアは「ある程度完成した成果物」として見ている。

この状態でレビューを始めると、レビュアの問いや指摘は、作成者にとって重く感じられるかもしれません。

逆に、レビュアは方向性を確認したいだけなのに、作成者が「正解を出さなければならない」と受け取る場合もあります。

状態	起きやすいこと
レビュー目的が曖昧	問いの意図が伝わりにくい
成果物の成熟度がそろっていない	相談段階なのに完成度を評価されているように見える
何を見るかが決まっていない	細部指摘に流れやすい
見ないものが何かが決まっていない	作成者がすべて直す必要があると感じる
判断理由を確認したいことが共有されていない	問いが詰問のように受け取られる

ここで重要なのは、レビューや問いが悪いということではありません。

問いが機能するための前提が、まだそろっていない場合があるということです。

では、何をそろえるべきか

問いが機能するレビューの場にするには、少なくとも次のようなことをそろえる必要があると思います。

今回、何を見るのか
何をまだ見ないのか
成果物をどの成熟度として扱うのか
何を前提にしているのか
どこで迷っているのか
何を相談したいのか
どこまでをその場で扱い、どこから持ち帰るのか

特に大事なのは、何をまだ見ないのかを決めることです。

レビューでは、何を見るかを決めることは比較的意識されます。
しかし、何をまだ見ないかは曖昧になりやすいと感じます。

たとえば、方向性を合わせるレビューであれば、細かい文言や表記ゆれはまだ見ない。
全体構成を見るレビューであれば、個別手順の詳細までは見ない。
前提を合わせるレビューであれば、成果物の完成度はまだ評価しない。

これを明確にしておかないと、レビューの焦点が散らばります。

レビュアは気づいたことをすべて指摘したくなるかもしれません。
作成者は、すべてを直さなければならないと感じるかもしれません。

しかし、初期段階では、すべてを同じ重さで見ることが必ずしも良いとは限りません。

今は何を見るのか。
何をまだ見ないのか。
どこまでを今回のレビューで扱うのか。

これらをそろえることで、問いの目的が明確になります。

具体例：テスト仕様書の初回レビュー

たとえば、テスト仕様書の初回レビューを考えます。

この段階で本当に確認したいのは、手順や期待値の細かい書き方ではないかもしれません。

先に見るべきなのは、次のようなことかもしれません。

どの要求を確認しようとしているのか
どの振る舞いを対象にしているのか
正常系と異常系をどう分けているのか
どこまでを今回のテスト範囲にするのか
何を対象外にするのか
どこに迷いがあるのか

ここが合っていない段階で細部にコメントしても、修正の方向性がずれたままになることがあります。

この場合、最初に投げる問いは、

この期待値の書き方を直してください。

ではなく、

今回は、どの要求のどの振る舞いを確認する想定ですか？

かもしれません。

あるいは、

ここは詳細に入る前に、まず正常系と異常系の分け方を合わせたいです。

かもしれません。

このように、レビューで何を見るのかがそろっていると、問いの意味も変わります。

単なる指摘ではなく、考え方を整理するための問いになります。

実務で使うなら

実務で使うなら、レビュー開始前またはレビュー開始時に、次のようなことを確認するとよさそうです。

確認したいこと	見るポイント
目的	何のための成果物か
前提	何を前提にしているか
対象範囲	どこまでを見るか
成熟度	完成版なのか、方針確認なのか
迷い	どこを相談したいのか
今回見るもの	方向性、構成、詳細、整合性のどれか
今回見ないもの	まだ指摘しない範囲はどこか
次の行動	何を直す／整理するのか

すべてを毎回きれいに決める必要はありません。

ただ、レビューがうまく進まない時には、

今回は何を見るレビューなのか

何をまだ見ないのか

成果物をどの成熟度として扱っているのか

を確認するだけでも、問いの受け取られ方は変わるのではないかと思います。

今回は扱わなかったこと

この記事では、レビュー形式そのものについては詳しく扱いませんでした。

たとえば、

文面レビューで進めた方がよい場合
同期レビューで合わせた方がよい場合
対面レビューの利点と負荷
文面レビューと同期レビューの比重をどう切り替えるか

は、今回の主題から外しています。

今回考えたのは、レビュー形式を選ぶ前に、レビューの場として何をそろえる必要があるのか、ということです。

次に考えたいこと

レビューの場を設計する要素はいくつかあります。

何を見るのか。
何をまだ見ないのか。
成果物をどの成熟度として扱うのか。
作成者が何を出せる状態なのか。

そして、もう一つ重要なのが、文面レビューと同期レビューの比重です。

文面で進めた方がよい場合もあります。
一方で、短時間でも同期で合わせた方がよい場合もあります。

次は、文面レビューで進めてよい時、同期で合わせた方がよい時について考えてみたいと思います。

おわりに

良い問いを用意することは大切です。

しかし、問いだけではレビューは機能しません。

その問いが、何を確認するためのものなのか。
今は完成度を見る場なのか、方向性を合わせる場なのか。
作成者は、前提や迷いを出せる状態にあるのか。
何を見て、何をまだ見ないのか。

こうした前提がそろっていて初めて、問いは機能しやすくなります。

レビューの場を設計するとは、良い質問を並べることではありません。
問いが機能する前提をそろえることなのだと思います。

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