필사 모드: 摩擦が消えると目利きが残るのではなく、目利きを育てる道が消えます

• レビュー待ちのPR十二本が全部まともです
• 摩擦は濾過装置であり、濾過装置は消えたあとにしか見えません
• 目利きが作られていた経路のかたち
• いま新人に起きていること
• 「目利きがすべて」という結論が危うくなる地点
• 判定を観測可能にする
• 摩擦を意図的に復元する三つの習慣
• チームで変えられるのはレビューの問いです
• 参考資料

レビュー待ちのPR十二本が全部まともです

月曜の朝、レビュー待ちの列にPRが十二本あります。全部にテストが付いていて、名前が端正で、コメントが誠実です。一本ずつ見れば差し戻す理由がありません。

ところが全部並べて見ると、この十二本のうち五本はそもそも作るべきではなかった機能です。オプションがひとつ増え、設定キーが三つ増え、これから維持する人が増えました。差し戻しの理由を書こうとすると「コードはまともなのに、これをなぜ作るのか分からない」という文しか出てこず、その文はレビューのコメントとして書くには無礼に見えます。

摩擦は濾過装置であり、濾過装置は消えたあとにしか見えません

2026年8月6日に公開されたTaste Is All That Is Leftは、この状況を正面から扱います。記事の核心は、努力が濾過装置だったという観察です。そしてあらゆる濾過装置がそうであるように、それは取り除かれるまで見えませんでした。

以前はある機能を作るのに三日かかりました。三日という費用はそれ自体が審査でした。三日を使う価値のある仕事かと自分に問わせ、曖昧なアイデアの半分はその問いで死にました。いまは同じ機能が40分で出てきます。40分は審査を通すには安すぎる値段です。

そのため作るべきではなかったものが作られます。そしてそれらは悪く作られていないので、反論するのがいっそう難しいのです。

目利きが作られていた経路のかたち

同じ記事がより重要に指摘するのは次のくだりです。目利きは遅く、間抜けで、恥ずかしいやり方で作られるということです。悪いものを作り、それと一緒に暮らさなければならず、人前で失敗する過程です。

この順序を分解すると、各段階がなぜ必要なのかが見えます。悪いものを作る段階で「こうすればこうなる」という因果が体に刻まれます。それと一緒に暮らす段階で、維持費用が感覚に変わります。失敗する段階で、自分の判断と現実の差が測られます。

三つとも時間がかかり、三つとも不快です。そして三つとも成果物が悪いときにだけ発生します。

いま新人に起きていること

ここで問題が生じます。原文の観察どおり、いま始める人たちは悪い版を出して、そのなかに座ってみる機会を持てません。道具が無難な版をただでくれるからです。

これは能力の問題ではありません。むしろ逆です。いまの新人は三年前の新人よりはるかに速く動くものを作ります。ただ、その過程で「この選択が半年後にどんな対価を要求するのか」を学ぶ出来事が発生しません。流暢さは得て、見習い期間は飛ばされます。

そしてこの隙間は指標に映りません。処理量にもリードタイムにもPR数にも現れないまま、二年ほど経って、誰も構造を決められないチームとして現れます。会議で二案のどちらを選ぶか誰も強く言えず、結局は両方作るか、いちばん最近しゃべった人の案になります。

ひとつ付け加えると、これは世代についての話ではありません。経験十年の人も同じように経験します。慣れていない領域で道具がくれる無難な結果を受け入れはじめると、その領域についての判断力はそこで成長を止めます。ただ、すでに他の領域で積んだ感覚があるので、自分では気づきにくいだけです。

「目利きがすべて」という結論が危うくなる地点

原文の最後の主張は強いものです。何を作る価値があるのかを教えてくれる人はほとんどおらず、それは常により難しい技術であり、いまはそれだけが残った、というものです。

診断としては説得力がありますが、この文を処方に変えるときには注意が必要です。「これからは目利きさえあればよい」と読むと困ります。目利きは作る経験の副産物であって代替物ではないからです。作ったことのない人の判断は目利きではなく好みであり、二つの差は間違ったときに露わになります。

より正確な整理はこちらです。目利きの価値が上がったのと同時に、目利きの供給経路がふさがった。 二つが一緒に起きたので、これはよい知らせではなく問題です。

判定を観測可能にする

そこで個人にできる最初のことは、判定を外へ出すことです。目利きはもともと言葉なしに働く能力であり、言葉なしに働くものは検証も伝授もされません。

具体的にはこうです。何かを作る前に二、三行を書きます。何を作るのか、なぜ今なのか、作らなければどんなことが起きるのか。そして作ったあとにそのメモを読み返します。半年ほど溜まると、自分の予測がどちらの方向へ外れるのかが見えます。ほとんどの人は「作らなければ起きること」を過大評価する方向へ一貫して外します。

このメモが設計文書である必要はありません。むしろ長いと書きません。コミットメッセージの本文でもイシューの最初のコメントでも、あとで探し出せる場所に三行あれば十分です。重要なのは分量ではなく、判定が下された時点で記録されたという事実です。結果を知ってから書いた振り返りは自分の判断を再構成してしまうので、学習の材料には使えません。

摩擦を意図的に復元する三つの習慣

二つ目は、消えた摩擦を人為的によみがえらせることです。全部よみがえらせる必要はなく、学習が起きていた地点だけを選べば足ります。

三つ目の項目がもっとも効果が大きく、もっとも頻繁に省かれます。作る人と維持する人が分離していると、目利きはどちらにも積まれません。作った側は対価を払わず、維持する側は選択の文脈を知りません。組織図がそう描かれているなら個人には変えられない場合も多いのですが、そのときはせめて自分が作ったものの障害通知だけは受け取り続けるほうがよいでしょう。

二つ目の項目にもひとつ落とし穴があります。代案を三つ一度に作ってくれと道具に頼むと、たいてい互いに似た三つが出てきます。同じ既定値の周りを回るからです。ですから少なくともひとつは手で、そして可能なら正反対の制約を掛けて作ってはじめて比較が成り立ちます。たとえば「設定をひとつも追加せずに解く」という制約を掛けてみる、といった具合です。

チームで変えられるのはレビューの問いです

最後は組織の水準です。いまのコードレビューは「このコードは正しいか」を問うように設計されていて、その問いには道具がすでにかなりよく答えます。レビューがその問いだけを続けるなら、レビューから学ぶものは残りません。

問いをひとつ手前へ移せばよいのです。PRのテンプレートに「検討したうえで捨てた代案とその理由」の欄を入れ、その欄が空ならレビューを始めないという規則を置く、という具合です。この一欄がすることは二つです。書いた人に選択を言語化させ、レビューする人にコードではなく判断を見る場所を与えます。

冒頭のPR十二本に戻ると、そのうち五本はこの欄で引っかかります。捨てた代案がないというのはたいてい代案を考えなかったという意味であり、代案を考えなかったというのは作らないという選択肢も検討されなかったという意味だからです。

参考資料

• Taste Is All That Is Left — notashelf.dev, 2026-08-06 — 濾過装置としての努力、目利きが作られる過程、無難な既定値が見習い期間を飛ばさせるという観察が、この記事の論旨です。
• Hacker Newsの議論 — 反論側の意見も併せて読んでみる価値があります。
• このブログの関連記事: コードは難しい部分ではなかったという言葉が、なぜあれほど腹立たしいのか
• 本文の習慣の表とPRテンプレートの提案は原文に出てくるものではなく、私が整理したものです。