何年か前だったか、あるいは過去に何度か見た話題なんだけど、ふと思い出したので書いておく。その話題というのが、「純粋な疑問として」という前置きをして「どうしてそう思ったの？」を聞くというものだ。

対面でのソースコードレビューなどで、経験のある開発者が若手の開発者に対して「どうして？」をたずねると、責められている・とがめられていると勘違いするのか「修正します！」みたいな見当違いの返答になる……そこで「純粋な疑問として」を前置きするようにしている……みたいな話だ。

ぼくは当時から「純粋な疑問として」が解決策として成立していないと思っていた。ぼくの想像だと「純粋な疑問として」をつけても、「純粋にわからん≒マジでまったく意味がわからん≒想像もつかない・ありえない状態 (論外) なんだけど」という極端さを表現するための修飾にしかなっていない可能性があると思う。

じゃあ、どうすればいいんだろう。

当時そこまで考えたかは覚えていないけれど、いまのぼくならどうするだろう。

結論を先に書くと、状況によっては適用できないだろうけど、 (1) 自身ならこの状況でどうするかを示し、 (2) 実際のソースコードとの差異を示し、 (3) その差異を生む理由になった相手の意図を問う (考えてないケースに配慮しつつ) ……となりそう。

結局「 3 で問うんかい」とつっこみたいところだろうけど、順番に書く。

もう一度、整理する。

やりたいことはなにか。

• 相手がどういう意図でそのソースコードを書いたのかを知りたい
  • 相手の理解や能力などを試したいわけではない (純粋な疑問なんだよね？)

そのためにどうしたのか。

• 「どうして？」をきいた

「疑問に思った」から「きいた」というだけの話。しかし、うまくいかなかったので、解決策を次のように変更した。

• 「純粋な疑問として」を前置きして「どうして？」をきいた

こんな感じ。

で、前提として押さえたい点が、いきなり「どうして？」が問える相手だったのか？　ということ。相手によってはこの悩みは生じ得ないと思うので、この前提は押さえておきたい。

まず「どうして？」って質問は文法にも意味的にも「はい」か「いいえ」で答えられない「オープンクエスチョン」で、これは「クローズドクエスチョン」よりも答えるのが難しい。ぼくはオープンクエスチョンに対して人は身構えるものだと思っている。

余談だが、弊社代表 (そのときは弊社システムの 1 ユーザーとして) に質問する機会があったのだけど、ぼくの質問に対しての第一声が「(理解を) 試してます？ (笑)」だった。試しているつもりはなかったのだけど、ぼくよりも遥かに能力の高い人間でも「オープンクエスチョンに対して身構えたんだろうな」と思ったので、ここに書いた (余談の余談: こういう冗談を挟んで和やかな空気に持っていけるところも含めて能力が高いとぼくは思う。ぼくにそのコミュ力はないので) 。

話を戻して、その難しいオープンクエスチョンをド頭に持っていける「相手」だったのかということ。聞いたらダメかも知れないから前置きしてるわけだし、問えない相手なんだとぼくは考えている。

いきなり「どうして？」が問えない相手だとして、じゃあ、どうすればいいんだろう。

もっと前提からひとつずつ押さえる形で「確認」から入るか、こちらの認識を示した上で問うほうがいいんじゃないかとぼくは思う。

状況の例があいまいなので難しいが……。

例えば「ここでは最終的に〜という形にしたいんですよね？」のようなゴールの確認はどうだろう。これは「実はいくつかの Issue をまとめて対応している」みたいなケースで起こりそうだ。

例えば「ぼくの認識だと〜と〜あたりを変更すればできそうかなと思ってたんですけど……」のような変更箇所の提示から入るのはどうだろう。これは「実装してみたら、うまくいかないことが分かって、〜の都合で変更箇所が……」みたいなケースで起こりそうだ。

例えば「こう書くと〜のような誤読を避けて書けると思うんですけど……」のような細かい記述の確認はどうだろう。「そういう記法の存在を知らない」「読みづらかったのでやめた」みたいなケースで起こりそうだ。 (余談: 以前の RSpec における自然な文法が云々みたいのは時間の無駄だからやめたほうがいいとぼくは思う。 nits つけてコメントして無視してマージ可にしておけばいいだろ……)

まとめると

(1) 自身ならこの状況でどうするかを示し、 (2) 実際のソースコードとの差異を示し、 (3) その差異を生む理由になった相手の意図を問う (考えてないケースに配慮しつつ)

という感じ。

最後忘れるべきじゃないのは 「(考えてないケースに配慮しつつ)」の点。そもそこまで考えずにコードを書く人も多いので、「別に考えてなかったらそれはそれで大丈夫だよ」というエスケープハッチをきちんと用意してあげたほうがいいと思う。

「純粋な疑問」が生じる理由は、自分の理想の状況と現実の状況に差異があることによるもののはずなので、その点をうまく示せるといいんじゃないかと思う。

さらに余談: 状況設定のバリエーション次第でもっと難しくなると思う。ペア作業でよく分からないコードを書きはじめたとき (ソースコードレビューと違って書き上げられたものがない状況。相手の認識を自分の認識で上書きするようなことを避けたい場合) とか。

おしまい。

病み上がり。さすがに熱は下がった (今度こそ) 。まだ喉がおかしいし、ときどきせきが出る。

怖いのは妻がのどが痛いといいはじめたこと。

今日のコミット。

このブログのコミットのみ。