「何でこう書いたの？」問題とその対策を考える

## はじめに

コードレビューにおける最頻出ワード、「なんでこう書いたの？」

今日は我々エンジニアがつい口にしてしまうこの言葉について、なぜ「ナンデコウカイタノ」と言ってしまうのか、この言葉が受け手にどのような心情をもたらすか考えてみようと思う。

## 言う側の視点

これに関しては、**シンプルに疑問だから訊いている**という意見がTwitter上で多く見られた。

ではこの「シンプルに疑問」とは何なのか。

細分化にあたり、私なりの経験から想像してみると
- 要件に沿っていない、よって相手と自分との**認識に齟齬**を感じる
- 要件には沿っているものの、**もっと良い書き方がありそう**だ
- 要件以前に、そもそも**不要なロジック、無意味そうなコード**がある

の3点が思い浮かんだ。

言葉には必ず意図がある。
ここで、上記の事象を **レビューする人間が本当は何を望んでいるのか？** に置き換えてみる。

- 要件に沿っていない、よって相手と自分との認識に齟齬を感じる -> `認識を一致させたい！`
- 要件には沿っているものの、もっと良い書き方がありそうだ -> `良い書き方を教えたい！`
- 要件以前に、そもそも不要なロジック、参照されていないなど無意味そうなコードがある -> `お掃除してほしい！`

なるほど、多くの人の思う「シンプルに疑問」とは、「なぜこう書いたのか皆目検討がつかない」というわけではなく、
- 認識の違いを明確にし、訂正したい
- アーキテクチャやコーディングルール面でより良いコードを提案したい
- 不要なコードを削除して可読性を高めたい

などの狙いが潜んでいることが分かった。
あるいは、上記に気付ける人間であってほしい、などもあるだろうか。
つまり、「なんでこう書いたの？」という短文の裏で、書き手は読み手に**自分の疑問に対し、解決に向かって行動してほしいと期待している**のではないだろうか。

## 言われる側の視点

次に言われた側の視点で見てみる。

「なんでこう書いたの？」と言われて萎縮する者の多くは、先輩後輩、上司と部下などの上下関係にあることだろう。
これは **「正しい答えを提供できる者」と「そうでない者」の構造**になっており、萎縮をする要因の大前提になっていると思う。

そこで言われた側の心情を調べてみると

- 詰め寄られている感じがして怖い、自分の至らなさを責められているように感じる
- （そうじゃないのは分かっているけれど）人格を否定された気持ちになる

などが出てきた。

ここをもう少し細分化するならば、実際に言われているように感じる言葉は
「おい、もっと良い書き方があるだろう」
「（手の内は明かさずに）こんなことも思いつかないのか？」
「お前はレベルが低いな」
「俺は完璧で正しい人間、お前は愚かで間違った人間だ」
といったところだろうか。

「何でこう書いたの？」という言葉から、このような思い込みに至る原因としては

- 過去に周囲にひどく責め立てられた、過剰な指導をされたなどの経験
- 失敗してはならない、上達しなければならないという自己への強いプレッシャー
- 新人とベテラン、階級や肩書きなど明確な上下関係にあること
- 自分の能力に対する自信のなさ

等があるのかもしれない。


## 解決に向けて

これら２つの視点を総合すると、「何でこう書いたの」問題には
- レビューする側が期待を伝えきれず、ローコンテクストなまま相手に次の行動を求めていること。レビューする人間の言語化能力の問題
- 上下関係など意思決定の構造の問題
- コードが完璧であってほしい/あらねばならないという、相手や自己に対する期待の問題

が潜んでいるように思える。
これらを1つずつ解消していくことで、コードレビューしんどいな...と思う人が減っていくのではなかろうか。

### レビュー時にはハイコンテクストな表現を心がける

まずはレビューする側として、コメントを送信する前に
「自分はなぜこれを聞こうとしているのか、相手をどうしたいのか」というところを考えてみてほしい。
直して欲しいのか、それともディスカッションしたいのか、教育したいのか。
それが出来たら、今度はなぜ直して欲しいのか、なぜディスカッションしたいのか、なぜ教育したいのか。
発言の意図を綿密に盛り込めば、多少冗長でも角の取れたコメントになるだろう。

ただし、これだけでは「私はあなたのためを思って言ってるんだよ？（圧）」のような論調になりかねないので、客観的に不快や不安感を与えないためにも、言葉遣いには気を配りたいものである。

### 傷つける意図がないことを相手に伝える

レビューする、される側の関係性として「ズバズバ言ってくるが良いヤツだと思う」「悪気がないのを分かっている」というのは、ある意味理想である。
なぜなら、言い回しに多少のアラがあっても、それを受容することができる関係でいられれば、ちょっとした言葉遣いのノイズに心をかき乱されずに済むからだ。
だが、これはレビューされる側の価値観に左右されるところであり、外部から「キミの上司は根は良いヤツだからさ」などと言われても到底納得できないだろう。

「ついきついことを言って(書いて)しまう」側に出来ることとしては、
- 萎縮される前に日常的にコミュニケーションを取って心理的安全性を高める
- 悪い感情を抱かれる前に、先出しで丁寧に断りを入れる
  - 「本当に申し訳ないんだけど、忙しいとつい短文になってしまうことがあって、もし私のレビューコメントで分かりづらい部分があったらいつでもコールしてください」など
- きつい言い方になったあとに気付いて訂正したり、補足を入れる

ことだと思う。
信用は貯金のようなもので、日々積み上げるのが正攻法だ。

### 周りが失敗し、謝罪し、訂正する姿を見せる

これはチームビルディングにおいても取り上げられるTipsである。
誰もが間違いを犯す、人間とは不完全であるということを示すためにも、特に上司やエキスパートの立場が積極的に失敗を開示する。
大きな失敗でなくとも、ちょっとした勘違いに「あ、そうか！ごめんなさい私勘違いしてた！」となる程度で良いと思う。
そして、それらの失敗を（もちろん手放しではないが）誰も責めない、ということも同時に意識していきたい。
失敗しても大丈夫なんだ、という意欲は時にイノベーションを生む。

### 個人的に意識している取り組み

最後に、自分が「気難しいレビュアー」にならないように意識していることを記しておく。

- 相手に関心がある、好意的であることを日々の会話の中で表現する
  - 雑談OKタイム（作業しながら雑談する時間枠）を設けて積極的に会話する
  - しっかり話を聞いて、相手の話を深堀りしていく
  - 5W1H的な質問を投げかける
    - ifの話は誰も傷つけないので結構良い
    - 「家の隣に飲食店ができるなら何屋がいいか」とか
  - 時間が取りづらいなら雑談1on1する
  - 万が一自分の言葉遣いがBADだったとしても、**あの人が詰問してくるはずがない**、と思ってもらう下地作り
- 相手の考えや感情にはなるべく共感する
  - 自分の考えと真逆なことを言われても受け止める
  - **何をアウトプットしても大丈夫なんだ**という安心感を持ってもらう
- 失敗や勘違い、自分の至らなさを若干大げさに伝える
  - **こっちが先にアホになりきる方が、相手も失敗を開示しやすい**
  - 卑屈にならない程度に
  - [生チョコ大福を作ろうとしてスライムの死骸が量産された話は結構ウケた](https://twitter.com/kotlin_obasan/status/1625420918444167170)
- レビューする時は「私は頭が良くないし完璧な人間ではない、私が間違っている可能性は十分にある」と脳内で念じてから読む
  - 実際に自分はコードから意図を読み取ることに長けた人間ではない
  - コメントは相手に教えを乞うつもりで書く
  - 卑屈にならない程度に

## おすすめの本

- ハーバード　あなたを成長させるフィードバックの授業
    - https://amzn.asia/d/cglpF5T
- Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス
    - https://amzn.asia/d/1DsOBmk 
- LEADER'S LANGUAGE 言葉遣いこそ最強の武器
    - https://amzn.asia/d/12nnYLZ