プログラムのレビューがない環境は、伸びないです。
レビューされて初めて、自分の間違いに気づきます。
気づいた瞬間から、伸び方が変わります。
昔、上司に叱られて一番こたえたのは、技術じゃありません。
仕事の出し方でした。
プログラムが正しくても、レビューで止まる。
設計が良くても、通らない。
成果が出ていても、評価が伸びない。
原因はシンプルです。
自分の間違いを指摘してくれる機会が減ったからです。
昔は、雑に出せば雑に返ってきました。
変更点が広すぎて、追うのに時間がかかる。
意図と仕様が文章になっていない。
再現条件が書かれていない。
確認した範囲が見えない。
「これ、確認してないやろ」で終わりです。
きついですが、その場でズレが矯正されました。
今は違います。
叱る側が損をする時代です。
忙しさも重なって、誰も深く見てくれません。
結果、本人は気づかないまま、ズレだけが残ります。
そして評価だけが落ちていきます。
ここで言い切ります。
レビューは任意じゃないです。必須です。
理由は2つです。
1つ目
レビューされて初めて、プログラムがチームの資産になります。
自分だけが分かる状態のプログラムは、実質「共有できない」です。
他人が理解できる形になって初めて、引き継げるし再利用できます。
2つ目
レビューされて初めて、自分の間違いに気づけます。
自分一人だと、見落としが残ります。
残ったまま次の案件に行くので、同じミスを繰り返します。
間違いのパターンはだいたい同じです。
仕様の読み違い
前提の抜け
異常時の処理漏れ
ログ不足
運用の想像不足
本人は「動いたからOK」で出します。
第三者は
「ここで止まる」
「ここで事故る」
「ここが後で詰む」
を見ます。
この差分が、成長の正体です。
レビューとは、人格評価じゃないです。
プログラムの弱点を見つける仕組みです。
ここが重要です。
今、第三者なしでうまく回せている人ほど伸びしろが大きいです。
器用だから回っている。
でも、ズレが修正されていない。
だから第三者視点が入った途端、伸び方が変わります。
努力量が増えるからではありません。
ズレがその場で修正されるからです。
修正が積み上がると、自分の中に「第三者の目」が育ちます。
次からは、出す前に自分で気づけるようになります。
この状態に入ると、成長が止まりにくいです。
レビューで詰まる人は、プログラムが悪い場合もあります。
でも多いのは、出し方で詰まっています。
提出物の形です。
変更点が大きすぎる
何を変えたか説明がない
影響範囲が書かれていない
テストの観点が薄い
異常時の動きが不明
戻し方がない
レビューする側は、プログラムを見る前にここで止まります。
探す時間が増えるからです。
レビューが遅いのではありません。
情報が足りないだけです。
逆に、レビューが速い人は、出す前にこれを揃えています。
何を変えたか。
なぜ変えたか。
何を変えていないか。
影響範囲はどこか。
危ないポイントはどこか。
異常時はどうなるか。
ログで切り分けできるか。
テストは何をやったか。
再現手順はどうか。
戻すならどう戻すか。
これが揃うと、レビューは「粗探し」ではなく「確認作業」になります。
忙しい現場ほど、ここが抜けやすいです。
指摘されない。
矯正されない。
放置される。
そのまま「伸びないまま器用に回る人」が増えます。
評価が伸びないのに、本人は理由が分からない。
そしてある日、難しい案件で詰まります。
もし今、
一人で回せているのに、評価が伸びない。
手戻りが減らない。
同じ指摘を繰り返される。
このどれかに心当たりがあるなら、答えは単純です。
第三者視点が足りていないだけです。
私は、この第三者視点を最短で入れるために、提出物の型と指摘の型を持っています。
レビューで刺さるポイントを、刺される前に潰すための型です。
淡々と見て、淡々と直して、淡々と積み上がる。
結局これが、一番早いです。