typo 死ぬほど多いので突っ込みまってます

考え方はコロコロ変わるタイプなのですが、最近はレビューが実はとても大事でとにもかくにもレビューなのでは？と思い始めてきています。

レビューといってまず出てくるのはコードレビューですよね、実はそれ以外にも設計レビュー、仕様レビュー、ドキュメントレビュー、テストレビュー、とりあえず作業名＋レビューって付ければなんでもあるのではないかなと思っています。

自分のレビュー全般に対する考えを整理してみました。

教育目的でのレビューやスキル差が大きくある前提でのレビューは含みません。教育目的でレビューするのであればスキルが高い人がレビューすると効果的です。

一定の能力以上の集団が出来た時を前提として考えてみています。

レビューの目的って何だろうって考えてみました。継続開発におけるレビューの立ち位置はメンテナンス出来るかどうかが一番先に来る気がします。

つまりレビュー時に意味不明な点 を削除するという事です。

たとえば、コーディング規約を守っているかはレビューというより、ツールでかなりの部分を解決出来ます。レビューは単純に今後残る成果物に対する意味不明点 を削除するという目的が大半を占めています。

意味不明点は仕様ミスも含まれます。誰かが違和感を感じなければそもそも仕様ミスすら気付くことが出来ません。その辺りはレビュー以前の問題です。

レビューはとてもコストが高いです。沢山の人数で作業する場合その分だけコストがかかります。これを減らすのはまずレビューツールの存在です。

それ以外にもレビューが気軽に行える という意味でもレビューツールは必須だと感じています。

GitHub の Pull-Request に対するコメント機能はとても優秀です。レビューがかなりしやすいです。コミットに対して簡単にコメントを付けてフィードバックができるのも優秀です。

これが、普通にリポジトリがあるだけでツールが無い場合はコストが膨れあがる上に、気軽にレビューすることが出来ません。作業者のコストがふくれます。

レビューされる側もする側も余り嬉しくありません。

レビューの文化を入れるときは、とにもかくにもレビューツールの選定から入るべきな気がします。ツールが無い状態からレビューを持ち込んだ場合は、時間と共にレビューされなくなっていく可能性が高いです。

レビューはそもそもコストが高いので、ツールで減らすくらいしか出来る事が無いのでは無いかと思います。

レビュースキルって多分あるのだと思います。レビューが上手い人っていますよね。なんだか良くわからないけどさくさくレビューして、上手いこと矛盾点だったり意味不明点を見つけてくれる人。

レビューのコツをレビューが上手いと自分が感じている人に聞いたのですが、よくわからないという回答が返ってきました。本人は自然とやっていることなので、コツなんかないと。

で、色々話をして気付いたことが一つだけあって、実はこれが真意なんじゃないかなと。

とにかくわからない ことにコメントする。それが自分の知識不足だろうが、仕様読み込み不足だろうがなんでもいいんです。自分がレビューしてわからない があったら「ここがわかりません」というコメントで十分です。

レビューは相手からの反論を恐れた時点で意味が無くなります。そうじゃなくて、単にわからないから質問するでいいのです。なぜなら作者なのでわからないわけ無いわけですから。

レビュー担当者はとにかく読んでわからないことを質問すればいいのです。コードレビューする人は正直にわからないとコメントしていけばいいだけです。

このわからない はレビューされる側を成長させます。理解して貰うまで説明する必要があるからです。

レビュースキルというのは、一方通行のスキルでは無くレビューされるスキルとレビューするスキルの二つがあって、二つのレビュースキルを伸ばしていくのが効率の良いレビュー環境を作るためには必須なのでは無いでしょうか。

人が二人以上いる事が最低条件です。ただ、なんとなくレビューする 状態になってしまうと、面倒で効果的では無い事が経験上わかってきました。

レビューってかなりめんどくさい作業なので、とにかく手を抜きがちです。仕事といえども自分で別の作業を持っている場合は、集中力をレビューに向けるのは難しいですよね。

理想論から言えば、レビューにかなり重心を方向けた人を置くのがベストです。