「レビューするくらいなら自分でやった方が早い」問題について
BASE株式会社で執行役員をしている柳川です。金融事業の事業責任者をしています。エンジニア→PdM→事業責任者というキャリアを歩んできました。
今日はレビューの話をします。レビューといってもいろいろありますが、成果物全般のレビューを念頭に置いています。ユーザーに送付するメールの文面の確認もそうだし、企画書の確認もそうだし、コードレビューも、デザインレビューも今回の話の守備範囲です。
あなたはレビューしたことありますか？レビューされたことありますか？会社で働いていると両方とも経験あるんじゃないでしょうか。
レビューって人の作ったものを見て、直すべきところを探して、伝える。それだけ聞くと、作るより楽そうに見えます。
でも、やったことある人なら分かると思うんですよ。レビューって、自分で作るよりもよっぽど大変です。
長いので気になった見出しの文章だけ読んでください。
レビューは楽じゃない
レビューして指摘するのって、自分でやるより大変なんです。何が大変なのか、分解してみます。
指摘場所を探すコスト：作る側は自分が通った道だけ見ればいい。レビューする側は、通らなかった道も含めて穴を探しにいく。別の集中力を食う
翻訳するコスト：頭の中の「ここが違う」を、相手に伝わる言葉に変換する。なんでダメか、どう直すか、なぜそう思うか。ここで一番時間が溶ける。正しく伝えればいいわけじゃない。トーンを間違えると刺さらない、あるいは刺さりすぎる。「嫌われたくないな」が頭をよぎる。
嫌われるコスト：断言しますがレビュアーは嫌われます。正面か嫌いとは意はないと思いますが、レビューされるのは気分がいいものではありません。特にレビューをしたことのない人には間違いなく嫌われます。レビューしたことある人には「ありがたいな」と思ってもらえるケースも。ただ中長期でありがたいなと理性的に思っても、レビューされている瞬間に関しては嫌いでしょうね。
最後のやつ、レビュアーなら身に覚えがあると思うんですよ。指摘を書いては消し、書いては消し、言い方を何度も調整する、あの感じ。
探す。翻訳する。嫌われない言い方を選ぶ。レビューは、この三重のコストを毎回払っている。作るより楽、なんてとんでもない。
それでもレビューするのは、品質のためだけじゃない
じゃあなんで、そんな面倒なことをするのか。
まずは、品質の担保のためですね。これは分かりやすいです。基準を守るためでもありますし、より良いものを作るために多様な視点を入れるという要素もあります。
でも、それだけじゃないんです。丁寧にレビューするとき、僕らはたぶん相手の成長に投資しています。今ここで一個指摘しておけば、次は自分で気づけるようになるかもしれない。その期待が、面倒なコストを払う動機になっている。
ここを分けて考えたい。レビューの目的って、ざっくり三つに分かれます。
① 品質の担保：出すものの水準を守る
② 育成：相手が次から自分でできるようにする
③ 責任の所在：「これで出していい」と誰かが引き受ける
この三つ、ふだんは混ざって見えるけど、別のものです。あとで効いてくるので、覚えておいてください。①②③、これがこの記事の補助線です。
役割分担が綺麗に働く範囲は案外せまい
「作る人とレビューする人を分けれるのは、品質の担保というよりも品質を上げるための役割分担では」と思う人もいるでしょう。理屈ではその通りだと思います。視点が複数に増えて品質が上がる。そうなれば合理的な分業です。
でも、それが綺麗に成立する条件って、案外せまいんですよ。以下の条件ががそろってないと成立しない。
スキルが拮抗している
お互いの視点が補い合える
時間軸が噛み合っている
この三つがそろったときだけ、分業はうまく回る。条件がずれると、途端に「自分でやった方が早い」側に倒れる。
正直に言うと、レビュアーの本音は「できればレビューなんてしたくない」だったりする。サボりたいって話じゃなくて、それくらいコストが高い、という話です。
みんな、できれば作りたい。できればレビューは最小にしたい。でも品質と育成と責任のために、しぶしぶ対価を払っている。これがレビューの実態だと思うんですよ。
レビューのROIは、固定じゃなくて動いている
ここで身も蓋もない話をします。
「他人に任せてレビューだけする」のと「そもそも自分で作る」の、どっちが得か。これ、固定じゃないんですよ。状況でぐるぐる変わる。何で変わるのか、変数を並べてみます。
スキルの補完関係：レビュアーとレビュイーの強みが噛み合うなら、分けた方がいい
スキルレベルの差：離れすぎていると、指摘が伝わらず往復が増え、結局自分で手を入れる。これなら最初から自分で作る方が早い
時間軸：短期なら自分でやる方が早い。でも育成目線では中長期でペイする。今日の30分が、半年後の自分の30時間を浮かせる
つまり「自分でやった方が早い」は、半分正しくて半分間違っている。
短期で見れば：正しい
中長期で見れば：必ずしもそうじゃない
どっちを取るかは、あなたがどの時間軸で勝負しているかの話なんですよね。ちょっと前までは。
AIは、この分岐点を動かす
さて、お待たせしました。ここからが本題です。ちょっと前までは。の話をします。
ずっと「自分でやるか、任せてレビューするか」のROIの話をしてきました。この分岐点を、AIが動かしにきています。流れを整理すると、こうです。
今までは、自分で全部作るのは時間がかかった
だから多少コストが高くても、人に任せてる必要があった
レビューするのはコストだが仕方がなかった、人材教育でもあるし
でもAIを使えば、自分で作れる範囲は増えた
ふと気がつく、「レビューの指摘事項を書く作業はAIにお願いするのと似ている行為なのでは、むしろAI相手の方が楽で正確なのでは」
「少なくともこの指摘事項は自分で直した方が早いのでは？」
すると計算が変わる →「人に任せてレビューするくらいなら、そもそもAIで自分で作った方が早いのでは」
「あれ、人にお願いして往復するより、AIに投げた方が抜け漏れなく直るな」と気づいてしまう。この誘惑は、けっこう強いですよね。だってレビュー大変だもの。
しかもタチが悪いことに、レビュイーは指摘事項そのままAIに渡して修正させますよ。これは批判でもないし性悪説でもないのです。そりゃそうです。そこにAIがあったらそうするでしょう。人として普通です。レビュアーのコメントをしっかり解釈して、AIに指示するなんてそんなこと普通の精神の人間はできませんよ。
レビューしたら、レビューで書いた内容をAIに読み込ませたであろう返答が返ってくる。これはかなり落ち込みます。落ち込むし、そんなことされるくらいなら、「自分でAIに指示した方がいいな」ってなります。そりゃそうでしょ。失礼だよ普通に。
「代替されてしかるべき」を、一回ちゃんと認める
綺麗事を言ってもしょうがないので、事実を書きます。
レビューが必要な仕事は基本的にAIに代替されて行きます。
これが今回書きたかった肝です。AIに代替される仕事の基準をずっと考えていてこの答えに辿り着きました。
「レビューできる」ってことは、何が正しくて何がダメか、チェックの基準があるってことです。基準があるなら、AIに作らせて、出てきたものを自分でチェックすればいい。わざわざ人に作ってもらって往復する必要がない。
AIにお願いする方が楽で速くて漏れがない場面が増えていく。だとしたら、役割として代替されていくのは、自然なことなんですよね。
これは「人間 vs AI」みたいな勇ましい話じゃない。もっと地味で、ROIの計算の話です。同じアウトプットがより速く安く出るなら、そっちが選ばれる。それだけ。
ここで「いや人間にしかできないことがある」とすぐ慰めに走りたくなるんだけど、一回こらえます。慰めの前に、じゃあ何が残るのかを、ちゃんと見たい。残る場所は、二つの方向から見えてきます。
でも、これはゼロイチじゃない ROIのグラデーション
一つ目の方向。「レビューできる仕事はぜんぶAIに、ハイ終わり」みたいなゼロイチの話でもないんですよ。ここにはグラデーションがある。
カギは、指示の抽象度です。
AIは、具体的に指示を切り出すほど強い。逆に、指示が抽象的なままだと、まだ取りこぼす。「いい感じにして」とだけ渡すと、いい感じにズレたものが返ってくる。
ここで人間が勝てる場所が見えてくる。抽象的なままの指示を受け取って、「だとしたら、ここは確認した方がいいですよね」「あるべき論点はこれとこれですよね」と、自分で論点を立てて、確認しながら進められる人。これは、まだAIより強いです。ROI的に、人に頼む意味が残る場所です。
AIが強い：論点が出そろっていて、具体的に切り出せる仕事
人が強い：論点があいまいなまま渡されて、何を確認すべきかを自分で考える仕事
ただし残酷なお知らせです。この境界線は止まってないです。グイグイ進行されています。
AIが賢くなるほど、抽象的な指示も拾えるようになる。人が勝てるグラデーションの基準はは、上へ上へと押し上げられていく。2026年の夏に勝てている抽象度でも、来年には怪しい。
だから「今は勝ててる」に安心しない方がいい。もう一段抽象的なところへ、自分を引き上げ続けるしかない。
どこが置き換わって、どこが残るのか
二つ目の方向は、さっきの①②③です。レビューの目的、①品質・②育成・③責任。これをAIに当ててみます。
① 品質の担保 → 置き換わる：探して、直す。これは作業。AIがどんどん食い込む。たぶん人より速くなる
② 育成 → 一部置き換わる：AIが丁寧にフィードバックを返せるなら、人はそれで学べる
③ 責任の所在 → 残る：「これで出していい」と引き受けること。ここはAIに渡せない
三つ目だけ、性質が違うんですよ。
AIは「ここが間違ってます」「こう直すといいです」とは言える。でも「これで世に出して大丈夫です、責任は私が取ります」とは言わない。言えないというより、引き受ける主体がいない。最後に旗を立てて、決めて、引き受ける。ここは人に残る。
整理するとシンプルです。
AIが置き換えるのは → 作業（探す・翻訳する・改善する）
AIが置き換えないのは → 引き受け（これで出していい、と決める）
なんで引き受けられるのか 文脈を持っているから
じゃあ、なんで人は引き受けられるのか。ここが一番大事なところです。
責任を引き受けられるのは、長い文脈を持っているからなんです。引き受けを支えている文脈って、たとえばこういうの。
この事業が何を狙っているのか
過去にどんな失敗をして、何を学んだのか
今このメンバーがどういう状態で、何に悩んでいるのか
この判断が半年後にどう効くのか
ドキュメントに全部は書ききれない、長くて生っぽい文脈。これを抱え続けているから、「これで出していい」と腹をくくれる。
逆に言うと、文脈を持っていない人の「OK」は、ただのハンコです。それなら、たしかにAIで十分かもしれない。
だから、引き受けと文脈の保持は表裏なんですよ。
長い文脈を持っている → だから責任を引き受けられる
文脈を持っていない → 引き受けは形だけ(ハンコ)になる
ここまで来ると、レビューの話が、レビューだけの話じゃなくなる。これはそもそも「作業を頼むか、頼まないか」の話だったんです。誰かに何かを委ねるとき、僕らは作業を渡しているようで、本当は文脈と責任のレイヤーで仕事をしている。
AIと作るなら、あなたはもうレビュアー
ここまでで、残っていくのは「レビューする側」、文脈を持って、論点を立てて、引き受ける側だ、という話をしてきました。ここで面白い皮肉があるんですよ。
その「レビューする側」、もう特別な誰かの役割じゃないんです。AIを使って何か作るとき、あなたがやっていることって、ほぼレビューなんですから。AIが出してくる。それを見て、ここは違う、こうしてほしい、と返す。
どこが目的とずれてるかを「探す」
直してほしいことを伝わる言葉に「翻訳する」
何度も往復して「形にする」
気づきましたか。さっきの三重苦、まるごと自分に返ってくる。作る人とレビューする人が別々にいた時代から、一人の中に両方が同居する時代になった。
だから皮肉なんだけど、AIが広まるほど、レビュアーのスキルは捨てるどころか効いてくる。AIと組む人は、ほぼ自動的にレビュアーになるんですよ。「レビューなんてやりたくない」と思っていた人も、AIと作り始めた瞬間、一日中レビューしている。
ただし、誤字脱字を指摘するだけのレビュアーは要らない
ここで急いで付け足したいことがある。「みんなレビュアーになる」と言ったけど、どんなレビューでもいいわけじゃないんですよ。
誤字脱字を指摘するだけのレビュー。表記ゆれを揃えるだけのレビュー。あれ、正直に言うと、AIの方が速いし漏れもない。人がやる意味がどんどん薄くなる。
というか、誤字脱字だけ指摘してくるレビュアーって、ちょっとムカつきません？（言い方の問題はある）。一番大事な「で、これ何のためにやってるんだっけ」には触れず、表面だけなでて、指摘した気になっている。あれは脳死レビューなんですよ。
脳死でレビューするな、と自分にも言いたい。チェックリストを上から舐めるだけなら、それこそAIに任せればいい。人がやるなら、もう一段深いところを見る。残るレビュアーと、消えるレビュアーの差は、たぶんここなんです。
消えるレビュー：表面のチェック(誤字・体裁・規約)。基準が決まっていて、AIの方が速い
残るレビュー：何のために・どこが詰まっているかを問い直す。基準そのものを持ち込む
基本的にレビューなんてない方がいいんです。レビューされる側にとってもそれは何かを萎縮させて損なう行為なんです。本来。
なくていいならない方がいい。
良いレビューは、ナラティブを語ること
じゃあ、AI相手のレビューで何が効くのか。指摘の細かさ？ 違うんですよ。一番効くのは、ナラティブを語れるかどうかです。
AIは、ちゃんと指示すれば直してくれる。でも「何のためにこれをやってるのか」を渡せていないと、的確な指示そのものが出せない。細かい修正をいくら投げても、向かう先がズレていたら、綺麗にズレた成果物が出てくるだけ。
ナラティブって、つまりこういうことです。
何のためにこれをやるのか（目的）
実現したいことは何か（たどり着きたい状態）
ボトルネックは何か（今、どこを動かすのが一番効くのか）
これを理解して、言葉にして、形にする力。これがレビュアーの本体なんですよ。指摘を探すことじゃない。何を目指していて、どこが詰まっているかを掴んで、渡せること。
そしてこれ、さっきの「文脈を持つ」と同じ話なんです。
ナラティブを語れる = 文脈を抱えている
文脈を抱えている = 引き受けられる
探す・翻訳する・直すという作業はAIに渡せる。でも「何のために・何を実現したくて・どこが詰まっているか」を掴んで語る部分は、渡した瞬間に仕事が崩れる。ここがレビュアーの、そして人の、残る仕事です。
上から指摘する関係から、助言を求め合う関係へ
もう一個、トーンの話をさせてください。
こういうレビューって、上から「ここ直して」と指摘する関係だと、たぶんうまくいかないんですよ。指摘する側／される側が固定されると、される側は身構えるし、する側は粗探しに寄っていく。さっきの脳死レビューが生まれるのも、だいたいこの構図からです。
目指したいのは、もっと自然なやつ。助言を求めて、求められる関係。
「これどう思う？」と気軽に聞ける
「ここ、こう見えたよ」と返してもらえる
レビューが、一方通行のチェックじゃなく、文脈を渡し合う往復になる
これ、相手がAIでも人でも同じなんですよね。AIに対しても、ただ命令するんじゃなくて、狙いを共有して「どう思う？」と壁打ちできる人の方が、いい成果物にたどり着く。人に対してなら、なおさらです。
レビューって本来、品定めじゃない。一緒に良くするための、助言の往復だったはず。AIが表面のチェックを巻き取ってくれるなら、人はその本来のところに戻れる気がするんですよ。
じゃあ、何を育てるのか
そろそろ着地します。
「AIで仕事がなくなる」って、よく聞きます。あれ、解像度が荒いと思うんですよ。なくなるのは仕事まるごとじゃない。仕事を分解すると、こう分かれる。
作業の層（探す・翻訳する・直す） → AIに移っていく
引き受けの層（文脈を抱え、決める） → むしろ価値が上がる
だとしたら、僕らが育てるべきは「作業の速さ」じゃないんですよね。そこはもう勝負にならない。育てるべきはこっちです。
長い文脈を抱え続ける力
何のために・何を実現したくて・どこが詰まっているかを語るナラティブの力
それを足場にして引き受ける覚悟
これ、レビューする側だけの話じゃない。任される側も同じです。
指摘をただ直すだけの人 → AIと同じ土俵に立たされる
指摘の背景を取りにいって、文脈ごと自分のものにできる人 → 置き換わらない側に回る
[番外編]どんどんレビューが重くなる問題
AIを使いこなして、思考を深めた質の高いアウトプットを出せるようになる。上手く活用するとそうなると思います。これはいいことです。いいことなんですが、その結果、「アウトプットが重く長くなりすぎてレビュー出来ねぇよ！」ってなる問題があります。もはや全てを読んで返答するのは不可能です。
この問題を解決するにはレビュアー、レビュイーの双方が工夫する必要があると考えています。簡単にいうと、どこまで見てどこまで見ないかのコンセンサスを揃えることが肝要です。簡単にいうと、レビュアーは何をレビューするかの宣言をし、レビュイーは何を見て欲しいかしっかり伝えることが肝要です
そのためにどのような工夫ができるか。書き始めるとただでさえ長い文章がさらに長くなるので簡単に。おそらくエンジニアのレビュー文化が参考になると思います。コードレビューにおいては、AI以前からコードを全行読むことはないです。そしてAIが出てきてますます全てを読むなんて不可能になっています。ゆえにさまざまな現場でコードレビューのお約束の試行錯誤が行われています。おそらくその営みはエンジニア以外にも参考になると思います。調べてみてください。
編集後記みたいなやつ
「レビューするくらいなら自分でやった方が早い問題」は昔からありました。個人の体験談プラス人に聞いた話ですが、プルリク出したらレビューさえしてもらえずにcloseされてたりとか、レビューさえしてもらえずに内容全部書き直されてマージされたりとか、そんな夜もありましたよね。乗り越えてきましたよね。みんな経験するよね。
正直に言うと、僕も「自分でやった方が早い」を飲み込んだ回数なんて、数えきれません。レビューが面倒で、いっそ全部巻き取りたくなる日もある。
でも、たぶんそれをやり続けると、自分も相手も「作業の人」のままになる。短期では早いけど、文脈を渡す機会を捨てている。
AIが作業を巻き取ってくれる時代だからこそ、人と人の間に残るのは、文脈を渡し合うことなんだと思います。面倒で、時間がかかって、嫌われるかもしれない、あのレビューの往復。あれは作業の押し付けじゃなくて、本当は文脈の受け渡しだった。そう思うと、ちょっとだけ、あの面倒くささを引き受ける気になりませんか。
僕はなりました。今日はそういう話でした。
今の環境普通に考えると「レビューするくらいなら自分でやった方が早い」です。この構造転換は多分不可逆です。
この構造転換を見てみぬふりをするのはよくないなと思い、今回しつこいくらいに丁寧に書きました。その結果長くなりましたが、ここまで読んでいただきありがとうございます。
コメント