君は評論家か？
# 雑談前言
「なんで Y を使わないの？」
「これって基本じゃない？」
「俺は最初からこうなるって言ってた」
批判はとても簡単な行為であり、自分が賢いことを際立たせて、鶴の群れの中で一羽だけ高く立つような感覚を味わえる。やらない手はない。
上層部を説得するのも、プロジェクトを前に進めるのも、他部署と調整するのも、どれも面倒だ。でも、批判に比べれば何百倍も大変だ。
誰かが新しいフレームワークを嬉々として共有すれば、下には「また無駄に車輪を再発明してる」などと書かれる。誰かが技術記事を書けば、「これで一篇書けるの？」と評される。誰かが辞めて起業すれば、友人は「どうせ失敗する」と言う。
認めるが、僕もかつてはそんな人間だった。
経験が増えるほど、世界の複雑さもよく分かるようになる。知識の呪いによって、何事も表面で見えているほど単純ではないと無意識に考えてしまう。そんなとき、いちばん楽な姿勢は一歩引いて、「傍観者」の視点であらゆる物事を見ることだ。
こうした言葉は口にすると気持ちいい。コストゼロ、リスクゼロ、それでいて少し知的優越感まで得られる。だが、自分が気分よくなる以外には何の役にも立たない。
ある大規模プロジェクトで、金融関連のフローが絡んでいたこともあり、僕もあの煩雑で長ったらしい手順を鼻で笑っていたことがある。批判するのは簡単だし、問題点を指摘するのも簡単だが、口だけではプロジェクトの進捗は進まないし、フローも翌日には変わらない。
上司に指摘されてはっとした。理想論だけを抱え、手を汚すことを嫌がるような人間を、組織は最も恐れるのだ。
プロジェクトを前に進めるという観点では、僕は Amazon の創業者 Bezos の意思決定方法——Disagree but Commit（Lex Fridman の Podcast でも触れていた）——もかなり好きだ。つまり、同意はしなくても全力でやり切るということだ。
最近のプロジェクトでは、これを強く実感した。僕が納得できない点に遭遇しても、プロジェクトへの影響が大きくないなら、まずは推進を最優先にするべきだ。逆にボトルネックにぶつかったなら、あらゆる手を尽くして上層部に報告し、数字を示してステークホルダーを説得しなければならない。なぜそれが重要なのか、放置したらどんな結果になるのかを示すのだ。
物事をもっと良くする
（画像は哲学哲学雞蛋糕より）
これは哲学哲学雞蛋糕が Paul Graham の How to disagree を翻訳した記事だ。そこでは「不同意」のレベルについて触れられている。ネット上の批評の大半は一級から四級にとどまる。
あの記事は人を論破する方法について書かれたものだが、その中のいくつかの核心的な概念は応用できると思う。
僕は、よい批判には次のような要素が必要だと思う。
- 相手を理解する：よい批判は、相手の文脈や思考を整理するところから始まる
- 方法を提示する：よい批判は、相手の悪い点を指摘するだけでなく、別の方法も示せる
逆に、何の役にも立たない批判とは、動機を疑うことだ。
批判中毒
口でまくしたてるのは気持ちいい。
- コストゼロ：ネットにコメントするのに責任は要らない。文字が挑発的であるほど注目を集めやすい
- 優越感：情熱いっぱいで始めて失敗した人を嘲笑し、「ほら見ろ、僕は最初から言ってた」と一言書き込む。自分のほうが相手より先を見通していると証明し、たった一言で他人の努力を空振りに見せられる
- 即時のフィードバック：誰かが丹念に書いた技術記事は、数日かけて構想し、検証したものかもしれない。でも、こちらは一言でひっくり返せる。あまりにも費用対効果が高すぎる
こういう心持ちが一度身につくと、自分ですら自分をだまし始めることに気づく。ほかの人がやることはすべて愚かなことで、他人の努力はみな滑稽だと感じるようになり、やがて安全地帯にとどまって他人の粗探しをするしかなくなる。
僕もこれでたくさん痛い目を見た。昔の Code Review では、よく自分の主観を相手の実装に押しつけていた。ただ自分の知識をひけらかしたかっただけだ。
だが、どうすればプロジェクトをもっと良くできるのか、自分が良いと思う書き方をどうやってチームに伝えるのか、そういうことはほとんど考えていなかった。
専門家の荷物
簡単なことなんて何一つない。どんな論点にも賛否があり、どんな行動にも副作用があり、どんな理想にも矛盾がある。
だが、まさにその心持ちのせいで、自分は軽々しく最初の一歩を踏み出せなくなる。
製品をリリースするには気をつけるべき点が山ほどあると知っているから、やらないことを選ぶ。そして完成品を SNS に載せている人たちを笑う。
こういう心持ちは自分を押しつぶす。長い目で見れば、他人を批判することしかできなくなる。
エンジニアが評論家になる
これは僕が技術界隈で観察してきた現象だ。
一部のベテランエンジニアは、いつの間にかコードを書かなくなる。彼らの主なアウトプットは、他人のコードを評論し、他人の記事を批判し、コミュニティでさまざまな技術的意思決定を講評することに変わっていく。
誰かが AI で文章を書き始めたのを見ると、「あいつはゴミばかり書いている」と言う。
「このアーキテクチャはあまりにも素朴だ」
「あの記事は浅すぎる」
「この技術選定は問題がある」
言っていること自体は、たぶん間違っていないのだろう。だが、彼ら自身はもうずいぶん長いこと何も生み出していない。
評論は楽だ。保守の責任を負う必要も、失敗のリスクに向き合う必要も、文章を練る時間もデバッグする時間も要らない。数分で鋭いコメントを一つ書くだけで、技術的権威のオーラを手に入れられる。
僕はまだ創造者なのか。それとも、気づかないうちにもう評論家になってしまったのか。
建設的な批判を見分ける
すべての意見を批判だと受け取って、会話を避ける人がいる。こちらが問題を指摘すると、相手はその批判を「粗探し」と解釈し、ある決定に疑問を投げかけると、こちらが自分に敵意を向けているのだと言う。
ある事柄に疑問を投げ、説明を求めることは、職場ではごく普通のことだ。相手がこちらのアウトプットを重視しているからこその反応でもある。
では、どう見分ければいいのか。相手が何を疑っているのかを見ることだ。具体的な案を出しているか、方向性の提案があるかを確認すればいい。
僕が誰かに提案するときは、できるだけ自分の理由も添えるようにしている。いくつか例を挙げる。
- 相手の報告に重要なデータが欠けていたら、僕は「この数字は重要だと思う。顧客の予算に関わるから、補うべきだ」と尋ねる。（より上級なのは、すでに自分で計算しておくことだ）
- この実装だとトラフィックがすべてバックエンドサーバーに流れてしまう。画像を CDN にアップロードすることを考えてみてはどうか？
もちろん、「え、そんなことも考えてなかったの？ 仕事してるの？」と言うこともできる。だが、その一言が目標達成にどれだけ役立つだろうか。
ひとつ注意すべきなのは、ソーシャルメディアだ。
SNS には、根拠のない主張、感情的な罵り合い、誰も誰も説得できない無限ループといった低品質な争いがあふれている。こうしたものとは距離を置くのが正しい。すべての対話に参加する価値があるわけではないし、ネット上のコメントは有害だ。
今あきらめたら試合終了だ
他人を批判するより怖いのは、自分を批判することだ。
「こんなの僕にはできないだろう」
「書いても誰も読まない」
「この年齢から始めるのは遅すぎるんじゃないか」
こうした自己批判は現実的だ。だが、その批判は行動しないことを正当化する口実にもなる。どうせやっても無駄だ、と。
結語
評論家になるのは気持ちいい。だが、同時にとても空虚でもある。そこには何も残らない。
僕がかっこいいと思うのは、世界の荒唐無稽さや矛盾を見抜きながらも、毎日不安を抱え、それでも自分の理想と純真さを手放さず、一歩ずつ行動し続ける人だ。