はじめに
前回の記事では、「良い問いとは何か？」について考えました。
12. 良い問いとは何か？ 問いの内容・タイミング・関係性・文脈を考える
良い問いとは、良いフレーズではなく、相手が思考を開けるように、問いの内容・タイミング・関係性・文脈を含めて設計されたものだと整理しました。
今回は、そこから一段進めて、
そのような問いを投げる側は、どのように支援されるべきなのか
を考えてみたいと思います。
良い問いを投げることは、単に良い質問文を知っていればできるものではありません。
問う側は、レビューの中でさまざまなことを見ています。
相手が考えられる状態なのか。
防御的になっていないか。
どこで思考が詰まっているのか。
今は待つべきなのか。
それとも、考えるための足場を渡すべきなのか。
この判断を個人のセンスや経験だけに任せてしまうと、良い問いを組織の中で再現することは難しくなります。
本記事では、特に 「待つ」と「足場を渡す」 という2つの判断に注目しながら、問う側を支援するとはどういうことかを考えてみます。
なお、ここでいうレビューは、コードレビューに限らず、要求、設計、テスト仕様などの成果物レビューも含めて考えています。
また、すべての指摘を問いに変える必要はありません。
明らかな誤記や単純な不整合は、素直に指摘した方がよい場合もあります。
ここで扱いたいのは、判断理由や前提、観点のずれを確認したい場面です。
「私があなたにレビューしたようにレビューしてください」では伝わらない
まず、私自身の失敗から書きたいと思います。
私は以前、考え方を問うレビューを自分なりに実践していました。
成果物の誤りを単に指摘するのではなく、
- なぜそう考えたのか
- どの前提で判断したのか
- 他にどの可能性を考えたのか
- 何をリスクと見たのか
を確認しながら、相手の思考を一緒に辿るようなレビューです。
そのようなレビューを、サブリーダーや別のレビュアーにも展開したいと考えたことがありました。
しかし、今振り返ると、その時の私は、問う側をどう育成し、どう支援すればよいのかを十分に分かっていませんでした。
その結果、
私があなたに対して行ってきたレビューの意図や観点を踏まえながら、あなた自身のチームメンバーにも同様の考え方でレビューを行ってみてください
という形で渡してしまったのです。
これは、かなり難しい依頼だったと思います。
なぜなら、問う側は、単に質問文を投げているわけではないからです。
問う側はレビュー中に、相手の状態、成果物の構造、レビューの局面、指摘の影響度、納期や余力を見ながら、問い方を調整しています。
これらを分解しないまま、「同じようにレビューしてください」と言っても、再現するのは難しい。
良い問いを投げるレビューは、見よう見まねだけでは伝わりにくいのだと思います。
なぜなら、問いの裏側で、問う側は多くの判断をしているからです。
問う側が迷うのは、「待つ」か「足場を渡す」か
問う側には、さまざまな判断が求められます。
たとえば、次のような判断です。
| 相手・場の状態 | 問う側がすること | 意図 |
|---|---|---|
| 相手が考え始めている | 待つ | 思考を邪魔しない |
| 考えたいが整理できていない | 足場を渡す | 言語化・モデル化を助ける |
| 正解確認になっている | 戻す | 判断理由を確認する場に戻す |
| 詳細に入りすぎている | スコープに戻す | レビュー目的を守る |
| 疲労や頑なさが見える | 止める | 問いが負荷になりすぎるのを防ぐ |
| 影響が大きい・時間が足りない | 持ち帰る | 無理に結論を出さず、次の行動に変える |
この中でも、特に難しいのは、
今は待つべきなのか、足場を渡すべきなのか
の判断ではないかと思います。
相手が考えようとしているなら、待つ必要があります。
一方で、相手が考えたいのに整理できていないなら、足場を渡す必要があります。
この見極めは、簡単ではありません。
沈黙しているからといって、すぐに助けた方がよいとは限りません。
逆に、黙っているからといって、ただ待てばよいとも限りません。
相手の中で考えが進んでいるのか。
それとも、何を考えればよいか分からなくなっているのか。
ここを見ながら、問う側は関わり方を変える必要があります。
待つことは、放置することではない
問う側に必要なのは、問いを重ねる力だけではありません。
待つ力も必要です。
相手が沈黙している時、それが考えを進めている沈黙であれば、問う側も沈黙することが大事だと思います。
せっかく相手が考えようとしているのに、問う側が先行してしまうと、相手の思考を奪ってしまうことがあります。
良い問いには、問いを投げた後に待つ時間も含まれているのだと思います。
ただし、待つことと放置することは違います。
待つとは、相手の思考が動いていることを見ながら、必要以上に介入しないことです。
放置とは、相手が詰まっているのに、何も支援しないことです。
急かすとは、相手が考えている途中で、次の問いや答えを出してしまうことです。
問う側は、沈黙をすぐに埋める必要はありません。
しかし、その沈黙が「考えている沈黙」なのか、「詰まっている沈黙」なのかは見なければなりません。
考えている沈黙であれば待つ。
詰まっている沈黙であれば、問いを小さくするか、足場を渡す。
この切り替えが必要になります。
足場を渡すことは、答えを教えることではない
一方で、相手が考えたいのに整理できていない場合には、ただ待つだけでは進まないことがあります。
その場合は、問いを重ねるのではなく、考えるための足場を渡す必要があります。
相手が問いに答えられない時、それは意欲がないからとは限りません。
言語化する力。
モデル化する力。
要求から振る舞いを展開する力。
判断理由を説明する力。
こうした土台スキルが、まだ十分に使える状態になっていない場合もあります。
その時に、
なぜそう考えましたか？
と問い続けても、相手は答えにくい。
その場合には、たとえば次のように導くことが考えられます。
- 一旦ツリー図を書いてみましょう
- 要求から考えられる振る舞いを並べてみましょう
- 正常系と異常系に分けてみましょう
- 判断した候補と、除外した候補を分けてみましょう
- まず前提条件だけ書き出してみましょう
これは答えを教えることではありません。
相手が自分で考えるための形を用意することです。
足場は、相手の代わりに考えるためのものではなく、相手が自分の思考を外に出し、扱えるようにするためのものです。
問う側の思考を少し見せる
足場を渡す方法の一つに、問う側の思考を少し見せることがあります。
たとえば、
私はこの要求から、こういう振る舞いも考えました。
と伝える。
これは、答えを示すためではありません。
考え方の一例を見せるためです。
特に、結論を急ぐ傾向がある相手には、いずれ除外する候補に至る考え方を見せることも有効だと思います。
たとえば、
この要求からは、この振る舞いも一度は考えられます。
ただし、今回のテスト目的からすると、この候補は除外してよさそうです。
というように、候補を広げ、絞り、除外する過程を見せる。
これにより、相手は「何を考えるか」だけでなく、「何を捨てるか」の判断基準も学べます。
ただし、問う側の思考を見せることには注意も必要です。
見せすぎると、相手がレビュアの思考を待つようになる可能性があります。
まずレビュアの考え方を聞いてから直せばよい
となってしまうと、問う側が思考を支援しているのではなく、思考を代行している状態に近づいてしまいます。
この加減は、私自身もまだ明確な答えを持っているわけではありません。
ただ、問う側の思考を見せる目的は、正解を示すことではありません。
候補を広げ、絞り、除外する判断の過程を見せることです。
問う側を支援することは、問われる側の安心にもつながる
問う側を支援することは、問う側のためだけではありません。
問う側が何を見ているのか、どのような時に待ち、どのような時に足場を渡し、どのような時に問いを戻すのかを整理できていると、問われる側にとってもレビューの場が分かりやすくなります。
問われる側からすると、考え方を問うレビューは、慣れるまでは少し分かりにくいものです。
成果物の誤りを指摘されるレビューであれば、何を直せばよいのかは比較的分かりやすいかもしれません。
しかし、考え方を問われるレビューでは、
- 何を確認されているのか
- どこまで説明すればよいのか
- 正解を求められているのか
- 判断理由を聞かれているのか
- 今すぐ結論を出すべきなのか
が分かりにくいことがあります。
この状態で問いを受けると、相手は防御的になったり、正解を探したり、「指摘通りに直します」という反応になりやすくなります。
だからこそ、問う側が自分の判断を整理できていることは、問われる側の安心にもつながります。
たとえば、
今は結論ではなく、どの前提で考えたかを確認しています。
あるいは、
今は詳細ではなく、全体構成を見ています。
あるいは、
ここはすぐに答えを出さなくてもよいので、一旦ツリー図で整理してみましょう。
と伝えられると、問われる側は「何を求められているのか」を理解しやすくなります。
問われる側も、完璧に答える必要はありません。
どこまで考えたのか、どこで迷ったのか、何を前提にしたのかを出せれば、レビューの場としては十分に前に進みます。
問う側の判断を支援することは、問う側のレビュー能力を高めるだけではありません。
問われる側が安心して考えを出せる場を作ることにもつながるのだと思います。
まずは振り返るところから始める
では、問う側を支援するには何から始めればよいのでしょうか。
最初から完璧な判断表や教育資料を作る必要はないと思います。
まずは、レビュー後に少し振り返るだけでもよいのではないでしょうか。
たとえば、
- 自分は待つべきところで待てたか
- 問いを重ねる前に、足場を渡すべき場面はなかったか
- 問う側の思考を見せすぎて、思考の代行になっていなかったか
- 相手は考え始めたのか、それとも指摘通りに直すだけになったのか
- 持ち帰るべきところで、無理に結論を出そうとしていなかったか
を振り返る。
問う側の支援は、問いを投げる前だけでなく、問いがどう受け取られたかを振り返るところから始められるのだと思います。
おわりに
本記事では、問う側をどう支援するかについて考えました。
良い問いを投げることは、良い質問文を知っていればできるものではありません。
問う側は、レビュー中に多くのことを見ています。
相手の状態。
成果物の内容。
思考の詰まり。
レビューの局面。
スコープ。
影響度。
納期や余力。
その中でも特に難しいのは、
待つべきか、足場を渡すべきか
を見極めることだと思います。
相手が考え始めているなら、待つ。
考えたいが整理できていないなら、足場を渡す。
正解確認になっているなら、戻す。
疲労や頑なさが見えるなら、止める。
その場で扱いきれないなら、持ち帰る。
これらを切り替えることが、問う側には求められます。
かつて私は、考え方を問うレビューを展開しようとして、
私があなたに対して行ってきたレビューの意図や観点を踏まえながら、あなた自身のチームメンバーにも同様の考え方でレビューを行ってみてください
と渡してしまいました。
しかし、今振り返ると、それでは不十分でした。
必要だったのは、レビューのやり方を見せることだけではなく、問う側が何を見て、どのように判断しているのかを分解し、支援することだったのだと思います。
良い問いを個人技にしないためには、問う側を支援する必要があります。
そして、問う側を支援することは、良い思考を組織に残すための活動でもあるのだと思います。
この連載の全体像はこちら：
車載ソフトウェア品質保証を考える：連載まとめ
補足：もう少し詳しく考えるなら
本記事では、「待つ」と「足場を渡す」を中心に書きました。
実際のレビューでは、それ以外にも、
- 問う側の思考をどこまで見せるか
- 正解確認になった時にどう戻すか
- 疲労や頑なさが見えた時にどう止めるか
- 持ち帰る時に何を決めるか
といった判断があります。
このあたりは、書き始めるとかなり長くなるため、今回は本編には深く入れませんでした。
ただ、良い問いを個人のセンスにしないためには、こうした判断もいずれ整理する必要があると思っています。