レビューに骨が折れることは、レビューが機能している証拠ではない

gingerBill氏は、Vimを例に挙げる。複雑な操作を乗りこなすことが「ハッカーっぽくて楽しい」ともてはやされる風潮があるが、それは達成感であって効率ではない。テキスト編集に1時間かけて凝ったマクロを組むより、別のツールで数分で終わらせるほうが、本来の意味で生産的だと氏は言う(出典)。

氏はこれを「feeling productive」と「being productive」の違いと呼ぶ。難しい問題を解いた達成感と、実際にかかった時間や誤りの少なさは、別の軸だという指摘だ。

良いツールは背景に消える

氏の主張の核は、良いツールは背景に消えるべきだ、というものである。良い初期設定はユーザーの時間への敬意の一形態であり、過度な設定可能性は、設計者が決断を避けた逃げ場に過ぎない。良い初期設定が一つあれば、千人のユーザーが個別に試行錯誤する手間を省ける。

道具そのものを乗りこなす技術を磨くことと、道具を使って本来やりたかった仕事を進めることは、別々に評価しなければならない。前者に時間を溶かしていることに、当人が気づけないのが厄介な点だ。

丁寧なレビューが、伝わるレビューとは限らない

コードレビューの世界にも、同じ罠がある。長い時間をかけて丁寧にコメントを書き込むレビューは、レビューをした側に確かな達成感を残す。だが、その達成感は、レビューが機能したことの証拠にはならない。時間をかけて指摘した内容が、実際に次の変更で参照されるかどうかは、また別の話だ。

PRの説明欄を毎回、著者が一から書式を考えて書くことにも、同じ構図がある。丁寧に書けば書くほど、書いた本人には「ちゃんと説明した」という達成感が残る。だが、書式が毎回違えば、レビュアー側はそのたびに、何を読み取ればいいかを推測しなければならない。丁寧さが、伝わりやすさに変換されているとは限らない。

四軸という良い初期設定

PRレビューツールParryが、Why・Risk・Confidence・Contextという4項目を毎回同じ形式で求めるのは、氏の言う良い初期設定と同じ発想だ。著者が毎回、説明の書式を一から考える手間を、あらかじめ決められた4つの欄が肩代わりする。設定可能性を上げるのではなく、選択肢を絞ることで、著者にもレビュアーにも、書式を考える負担そのものを消す。

もっとも、氏はもう一つ、厄介な指摘もしている。一度ツールが「自分らしさ」と結びつくと、その欠点を認めることが自己否定に感じられ、人は欠点を守り始めるという。四軸というフォーマットも、使い続けるうちに同じことが起こりうる。フォーマットに慣れることと、フォーマットの欠点を指摘できなくなることは、紙一重だ。

Vimのマクロと同じように、四軸を埋めることそのものに達成感を覚え始めたら、それは氏の言う「feeling productive」の兆候かもしれない。四軸が本当に機能しているかどうかは、埋めた本人の手応えではなく、半年後にそれを読んだ別の誰かが判断を再構成できるかどうかでしか測れない。