この記事で考えたいこと
この記事で考えたいのは、次のことです。
- 良い問いは、問いそのものだけでは機能しない
- レビューでは、何を見るのか、まだ見ないものは何かをそろえる必要がある
- 問いが機能する場を作ることも、レビュー設計の一部である
前回の記事では、良い問いを個人のセンスにしないために、問う側をどう支援するかを考えました。
13. 問う側をどう支援するか？ 良い問いを個人のセンスにしないために
今回は、その続きとして、問いが機能するレビューの場では何をそろえる必要があるのかを考えてみます。
はじめに：現場で起きる違和感
レビューをしていると、問いや指摘そのものは悪くないはずなのに、うまく機能しないことがあります。
たとえば、
- 判断理由を確認したい
- 前提を確認したい
- 対象範囲を確認したい
- どこで迷っているのかを知りたい
と思って問いかけているのに、相手が正解を探し始めたり、防御的になったり、「指摘通りに直します」と返ってきたりすることがあります。
この時、問いの言葉だけを見れば、それほど悪い問いではないかもしれません。
この判断は、どの前提に基づいていますか？
この条件を対象外にした理由は何ですか？
今回のレビューでは、全体構成を見ればよいですか？ それとも詳細まで見た方がよいですか？
このような問いは、判断理由や前提を確認するためには有効な問いに見えます。
しかし、レビューの場が整っていないと、問いはうまく機能しないことがあります。
作成者がまだ方向性に迷っている。
成果物を完成版として見てほしいのか、相談段階として見てほしいのかがそろっていない。
レビュアは方向性を確認したいのに、作成者は完成度を評価されていると受け取っている。
このような状態では、問いは支援ではなく、追加の指摘や詰問のように受け取られることがあります。
問題は、問いそのものだけではないのかもしれません。
問いが機能するためのレビューの場が、まだ整っていないのです。
前回までの整理
前回の記事では、「問う側をどう支援するか」について考えました。
良い問いを投げることは、良い質問文を知っていればできるものではありません。
問う側は、レビューの中でさまざまな判断をしています。
相手が考えているなら待つ。
考えたいが整理できていないなら、足場を渡す。
正解確認に寄っているなら、判断理由を確認する場に戻す。
疲労や頑なさが見えるなら、いったん止める。
つまり、問う側は単に質問しているのではなく、相手の状態やレビューの局面を見ながら、問いの出し方を調整しています。
今回は、その問いが機能する前提として、レビューの場では何をそろえる必要があるのかを考えます。
結論：この記事で言いたいこと
先に結論を書くと、私は次のように考えています。
レビューの場を設計するとは、良い質問を並べることではなく、問いが機能する前提をそろえることではないか。
もう少し具体的に言うと、
- 今回のレビューで何を見るのか
- まだ見ないものは何か
- 成果物をどの成熟度として扱うのか
- 作成者は何を迷っているのか
- 完成度を見るのか、方向性を合わせるのか
- その場で扱うことと、持ち帰ることをどう分けるのか
をそろえることです。
これらが曖昧なままレビューを始めると、問いの目的も曖昧になります。
問いが悪いのではなく、問いを受け取るための前提がそろっていない場合があるのです。
何が問題になるのか
レビューの場で何を見るのかがそろっていないと、問いの受け取り方がずれます。
たとえば、作成者は「まだ方向性を相談したい」と思っている。
しかし、レビュアは「ある程度完成した成果物」として見ている。
この状態でレビューを始めると、レビュアの問いや指摘は、作成者にとって重く感じられるかもしれません。
逆に、レビュアは方向性を確認したいだけなのに、作成者が「正解を出さなければならない」と受け取る場合もあります。
| 状態 | 起きやすいこと |
|---|---|
| レビュー目的が曖昧 | 問いの意図が伝わりにくい |
| 成果物の成熟度がそろっていない | 相談段階なのに完成度を評価されているように見える |
| 何を見るかが決まっていない | 細部指摘に流れやすい |
| 見ないものが何かが決まっていない | 作成者がすべて直す必要があると感じる |
| 判断理由を確認したいことが共有されていない | 問いが詰問のように受け取られる |
ここで重要なのは、レビューや問いが悪いということではありません。
問いが機能するための前提が、まだそろっていない場合があるということです。
では、何をそろえるべきか
問いが機能するレビューの場にするには、少なくとも次のようなことをそろえる必要があると思います。
- 今回、何を見るのか
- 何をまだ見ないのか
- 成果物をどの成熟度として扱うのか
- 何を前提にしているのか
- どこで迷っているのか
- 何を相談したいのか
- どこまでをその場で扱い、どこから持ち帰るのか
特に大事なのは、何をまだ見ないのかを決めることです。
レビューでは、何を見るかを決めることは比較的意識されます。
しかし、何をまだ見ないかは曖昧になりやすいと感じます。
たとえば、方向性を合わせるレビューであれば、細かい文言や表記ゆれはまだ見ない。
全体構成を見るレビューであれば、個別手順の詳細までは見ない。
前提を合わせるレビューであれば、成果物の完成度はまだ評価しない。
これを明確にしておかないと、レビューの焦点が散らばります。
レビュアは気づいたことをすべて指摘したくなるかもしれません。
作成者は、すべてを直さなければならないと感じるかもしれません。
しかし、初期段階では、すべてを同じ重さで見ることが必ずしも良いとは限りません。
今は何を見るのか。
何をまだ見ないのか。
どこまでを今回のレビューで扱うのか。
これらをそろえることで、問いの目的が明確になります。
具体例：テスト仕様書の初回レビュー
たとえば、テスト仕様書の初回レビューを考えます。
この段階で本当に確認したいのは、手順や期待値の細かい書き方ではないかもしれません。
先に見るべきなのは、次のようなことかもしれません。
- どの要求を確認しようとしているのか
- どの振る舞いを対象にしているのか
- 正常系と異常系をどう分けているのか
- どこまでを今回のテスト範囲にするのか
- 何を対象外にするのか
- どこに迷いがあるのか
ここが合っていない段階で細部にコメントしても、修正の方向性がずれたままになることがあります。
この場合、最初に投げる問いは、
この期待値の書き方を直してください。
ではなく、
今回は、どの要求のどの振る舞いを確認する想定ですか？
かもしれません。
あるいは、
ここは詳細に入る前に、まず正常系と異常系の分け方を合わせたいです。
かもしれません。
このように、レビューで何を見るのかがそろっていると、問いの意味も変わります。
単なる指摘ではなく、考え方を整理するための問いになります。
実務で使うなら
実務で使うなら、レビュー開始前またはレビュー開始時に、次のようなことを確認するとよさそうです。
| 確認したいこと | 見るポイント |
|---|---|
| 目的 | 何のための成果物か |
| 前提 | 何を前提にしているか |
| 対象範囲 | どこまでを見るか |
| 成熟度 | 完成版なのか、方針確認なのか |
| 迷い | どこを相談したいのか |
| 今回見るもの | 方向性、構成、詳細、整合性のどれか |
| 今回見ないもの | まだ指摘しない範囲はどこか |
| 次の行動 | 何を直す／整理するのか |
すべてを毎回きれいに決める必要はありません。
ただ、レビューがうまく進まない時には、
今回は何を見るレビューなのか
何をまだ見ないのか
成果物をどの成熟度として扱っているのか
を確認するだけでも、問いの受け取られ方は変わるのではないかと思います。
今回は扱わなかったこと
この記事では、レビュー形式そのものについては詳しく扱いませんでした。
たとえば、
- 文面レビューで進めた方がよい場合
- 同期レビューで合わせた方がよい場合
- 対面レビューの利点と負荷
- 文面レビューと同期レビューの比重をどう切り替えるか
は、今回の主題から外しています。
今回考えたのは、レビュー形式を選ぶ前に、レビューの場として何をそろえる必要があるのか、ということです。
次に考えたいこと
レビューの場を設計する要素はいくつかあります。
何を見るのか。
何をまだ見ないのか。
成果物をどの成熟度として扱うのか。
作成者が何を出せる状態なのか。
そして、もう一つ重要なのが、文面レビューと同期レビューの比重です。
文面で進めた方がよい場合もあります。
一方で、短時間でも同期で合わせた方がよい場合もあります。
次は、文面レビューで進めてよい時、同期で合わせた方がよい時について考えてみたいと思います。
おわりに
良い問いを用意することは大切です。
しかし、問いだけではレビューは機能しません。
その問いが、何を確認するためのものなのか。
今は完成度を見る場なのか、方向性を合わせる場なのか。
作成者は、前提や迷いを出せる状態にあるのか。
何を見て、何をまだ見ないのか。
こうした前提がそろっていて初めて、問いは機能しやすくなります。
レビューの場を設計するとは、良い質問を並べることではありません。
問いが機能する前提をそろえることなのだと思います。
この連載の全体像はこちら：
車載ソフトウェア品質保証を考える：連載まとめ