はじめまして。
株式会社PRUMでエンジニアをしている人見です。
日々、プログラミング学習や実務の中で
つまずきやすいポイントを整理して発信しています。
PRUMについて気になった方は、
コーポレートサイトもご覧ください。
▶ コーポレートサイト
【後編】「また指摘されてしまった…」と思った新人エンジニアへ
― レビューはなぜすれ違うのか ―
はじめに
前編では、レビューで起きていることを次の5段階のプロセスとして整理しました。
- まず 内容が正しいか を確認する
- 内容が整理されると 不足情報 が見える
- 情報が整理されると 表現の問題 が見える
- 表現が整理されると 構造の問題 が見える
- 最後に 他の資料との整合 が見える
レビューが何度か往復するのは、単にミスが多いからではありません。
見る視点が段階的に増えていくからです。
レビューとは、解像度が少しずつ上がっていくプロセスでもありました。
では実際の現場では、
レビューはどのように行われているのでしょうか。
後編では、レビューの構造を分解しながら
レビューに対する視点を整理していきます。
現場のレビューは3種類ある
レビューというと「 良いレビュー 」「 悪いレビュー 」と語られることがあります。
しかし実際の現場では、レビューはもっと混ざり合っています。
多くの場合、レビューは次の3つのどれか、あるいはそれらが混ざった形で行われています。
- 雰囲気レビュー
- 作業レビュー
- 教育レビュー
① 雰囲気レビュー
一番よくあるレビューです。
・「なんか違う」
・「分かりにくい」
・「ここ直してください」
レビュワーは違和感を持っています。
多くの場合レビュワー自身も
「感覚では分かるが、説明は難しい」
という段階だからです。
この状態で行われるレビューが
雰囲気レビューです。
教育学者 Donald Schön は、熟練者の思考を
Reflection in Action（行為の中の省察） と呼びました。
熟練者は作業しながら状況を判断し、
直感的に問題を見つけることがあります。
そのため
「なんとなく違う」
という感覚はあるものの、
それをすぐ言語化できないことがあります。
② 作業レビュー
次に多いのが「こう修正してください」というレビューです。
例えば
・ここは箇条書きにしてください
・この順番に直してください
これは
・締め切りを守る
・成果物を完成させる
という目的では、とても合理的なレビューです。
実際の現場では
教育よりも
まず完成させること
が優先されることも少なくありません。
③ 教育レビュー
最後が教育レビューです。
これは「なぜ問題なのか」を説明するレビューです。
ポイントは次の3つです。
- 指摘
- 理由
- 思考のヒント
例えば次のようなレビューです。
「この説明だと登録条件が読み取りづらいです。
仕様ではメール認証が必須で、電話番号は任意になっています。
条件を箇条書きにすると読みやすくなると思います。」
このレビューでは、修正だけでなく
判断基準そのものが共有されます。
レビューで共有される「暗黙知」
レビューで共有されるものは、修正方法だけではありません。
多くの場合
- 説明の順序
- 情報整理の仕方
- チームの設計思想
といった
仕様書には書かれていない判断基準です。
レビューとは、こうした
言葉になっていない判断基準を共有するプロセスでもあります。
哲学者 Michael Polanyi は、このような知識を
Tacit Knowledge（暗黙知） と呼びました。
彼は次の有名な言葉を残しています。
We know more than we can tell.
人は「説明できる以上のことを知っている」という意味です。
レビューの本当の目的
レビューの目的はミスを見つけることではありません。
本当の目的は
思考を共有すること
レビュー前は「 新人の思考 」だけですが
レビュー後は「 新人の思考 + レビュワーの視点 」になります。
こうして少しずつ判断基準が増えていきます。
つまりレビューとは
経験者の思考をインストールする仕組み
とも言えます。
最後に
もしレビューで修正が続いたときは
「また直しだ」
ではなく
「まだ共有されていない視点がある」
のかもしれません。
レビューとは
経験者の視点を少しずつ受け取るプロセスでもあります。
その視点が増えていくと、
ある日ふと気づくかもしれません。
自分がレビューを書く側になっている
ということに。
PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。