「評論家気取り」という作る人の行き着く先が怖い

らーめん再遊記 第一巻より引用

らーめん再遊記（１） (ビッグコミックス)

はじめに

技術界隈には、長年続いている不穏な現象があります。コードを書くことに情熱を注いでいた人々が、いつの間にか他人の成果物を論評することに執心するようになってしまうのです。

なぜ私たちは燃え尽きてしまうのか

この現象は、特にベテランと呼ばれるエンジニアたちの間で顕著です。彼らは確かな技術力を持ち、素晴らしい成果を残してきました。しかし、彼らの多くが、創造者から評論家への転身!?を遂げつつあります。

仕事の辞め方 (幻冬舎単行本)

実は私たちエンジニアは皆、いずれ評論家になる運命を背負っているのかもしれません。年を重ね、技術の第一線から遠ざかるにつれ、「作る」ことから「評論する」ことへと、その重心を少しずつシフトさせていきます。それは半ば必然であり、誰もが通る道なのでしょう。

だからこそ、今、この問題について考えたいと思います。これは、いずれ評論家になるかもしれない私自身への警告であり、そして自戒の言葉でもあります。

実装者から評論家へ。エンジニアの変質を、私は憂慮しています。この静かな変化について、正面から向き合ってみましょう。

作る側が評論に逃げるとき

「このコードは素人レベルで時代遅れです。基礎から学び直してください」 「アーキテクチャへの理解が浅く、重要な議論が抜け落ちています」 「技術選定の根拠が説明されておらず、設計思想が古いままです」 「なぜあのライブラリやアーキテクチャに触れていないのですか。初歩的な見落としです」

SNSには辛辣な評論・批評が溢れ、技術ブログには高圧的な論評が並び、カンファレンスの裏チャンネルは批判で充満しています。最も危惧すべきは、これらの評論・批評の多くが、かつては優れたコードを生み出していたはずのエンジニアたちから発せられているということです。

問題なのは、これらの言説が建設的な議論を装いながら、実際には単なる批判に終始している点です。 改善案を示すわけでもなく、プルリクエストを送るわけでもなく、ただ「ダメ出し」だけを繰り返しています。これは技術的な議論ではなく、単なる自己顕示でしかありません。

アイデアのつくり方

自意識が一流評論家になってしまったかつて天才だったエンジニア

Xのタイムラインには、自らを一流評論家だと思い込んだエンジニアたちが目立っています。「この実装は素人レベルです。こんなコードしか書けない人は、基礎から学び直すべきです」—そう断罪するのです。 しかし、彼ら自身は数年前の自分のコードを振り返ってみたことがあるでしょうか。あるいは最近では、実装よりもメンテナンス業務が中心になってはいないでしょうか。

かつての優秀なエンジニアたちは、初学者への指摘だけでは飽き足らず、すでに実績のあるエンジニアたちにまで批判の矛先を向けています。有名OSSのプルリクエストには「この設計は時代遅れです。モダンな設計パターンを学んでから出直してください」と高圧的なコメントを残し、技術ブログに対しても「この技術選定の根拠が説明されていません」「重要な議論が抜け落ちています」と、まるで査読者のような態度で指摘を繰り返します。

さらに気がかりなのは、オープンソースのイシューやプルリクエストへの不建設的な態度です。具体的な改善案を示すことなく、ただ問題点の指摘だけを行うのです。「なぜこの設計を選んだのですか？」「この実装では不十分です」という批判は、具体的な改善案を伴わない限り、何の価値も生み出せません。

評論家気取りのポストで注目を集める快感に魅了されたエンジニアは、徐々に変質していきます。最初は些細な技術的指摘から始まり、「いいね」という承認欲求に駆られ、その評論は次第に厳しさを増していくのです。「なぜこの技術スタックを選んだのですか？」「なぜこの設計パターンを採用しなかったのですか？」—まるで面接官のように、実装者を追い詰める質問を投げかけ始めます。

そして最も懸念すべきは、若手エンジニアの成長機会が損なわれていくという事実です。建設的なフィードバックの代わりに投げかけられる批判は、若手の挑戦する意欲を削ぎ、コミュニティへの貢献を躊躇させています。時には、自身を技術界の権威だと思い込んだエンジニアが、若手たちの真摯な努力までも批判の対象としてしまうのです。

評論は衰退の始まり

エンジニアが評論家めいた物言いを始めるとき、それは衰退の予兆かもしれません。

ただし、適切な評論や建設的な批判は、技術の発展に不可欠な要素でもあります。レビューやフィードバックを通じて、実装の品質は向上し、よりよい設計が生まれていきます。

問題なのは、創造的な貢献を伴わない批判に終始してしまうことです。創造者には創造者としての責務があります。コードに不満があるならば、改善のプルリクエストを送ることができます。ドキュメントが不十分と感じるなら、具体的な改善案を示すことができます。アーキテクチャが気に入らないのであれば、より優れた実装を示す機会が開かれています。発表内容に不満があるというのなら、自らが登壇する選択肢もあります。

これは単なる理想論ではありません。優れたエンジニアたちは、常にこの原則に従って行動してきました。彼らは単なる批判ではなく、コードで語ります。問題点の指摘だけではなく、改善案の実装を示します。時には厳しい指摘も必要ですが、それは常により良い方向への具体的な提案を伴うものでなければなりません。

評論と批判は、建設的な議論の土台となり得ます。しかし、それは実装による貢献があってこそ意味を持つのです。評論家として批判するだけでなく、創造者として具体的な改善を示していく—それこそが、エンジニアの進むべき道筋なのではないでしょうか。

みんなのフィードバック大全

なぜ評論に逃げるのか

実のところ、その理由は複雑に絡み合っています。一見すると創造する意欲が失われていくように見えますが、その背景にはさまざまな要因が存在します。

まず、技術の進化スピードが年々加速していることが挙げられます。かつて最先端だった技術スタックは、わずか数年で「レガシー」と呼ばれるようになります。新しい技術への追従に疲れ、自信を失っていく—そんなベテランエンジニアの姿を、私たちは目にしてきました。

また、組織の中での役割の変化も大きな要因となります。マネジメントやアーキテクトの立場になると、直接コードを書く機会が減っていきます。それは自然なキャリアパスかもしれませんが、同時に「作る」喜びから遠ざかることも意味します。

さらに、以前の自分を超えられないという焦りもあるでしょう。若かりし頃に作り上げた素晴らしいプロダクトやライブラリ。その成功体験が重荷となり、新しいチャレンジを躊躇させることもあります。過去の栄光に縛られ、新たな失敗を恐れる—そんな心理が、評論という安全な場所への逃避を促します。

そして、評論には誘惑があります。技術ブログへの評論記事は数時間で書け、発表資料への批判は数分で完結し、SNSなら数行のポストで事足ります。実装を伴う苦労も、メンテナンスの責任も、失敗のリスクも必要ありません。

最も注意すべきは、その行為が「いいね」という即時の報酬と、表面的な自己肯定感をもたらすことです。賢明な分析家として認められ、技術の識者として扱われる。この心地よさが、さらなる評論への逃避を促していきます。他者への批判で得られる一時的な優越感は、しかし、本当の自己肯定感とは異なります。 建設的な創造による達成感こそが、エンジニアの誇りとなるべきものです。

時には、組織の文化や環境も影響します。過度な品質要求や、失敗を許容しない雰囲気は、エンジニアを萎縮させ、批評家的な立場に追いやってしまうことがあります。新しいことへの挑戦よりも、既存のものを批評する方が「安全」だと感じてしまうのです。

この悪循環は、技術コミュニティ全体に影響を及ぼします。建設的な議論が減少し、若手の挑戦する意欲が失われ、コミュニティの分断が進んでいきます。評論は容易でも、実際の改善は誰も行わない—そんな状況に陥っているのです。

しかし、これは決して避けられない運命ではありません。技術の変化を恐れず、小さな一歩から始める勇気を持つこと。過去の成功や失敗にとらわれすぎず、新しい挑戦を続けること。そして何より、評論家としての安易な満足に甘んじないこと。それが、創造者としての道を歩み続けるための鍵となるのではないでしょうか。

批評の教室　──チョウのように読み、ハチのように書く (ちくま新書)

作る側の矜持

エンジニアの本質的価値は、創造する能力にあります。 しかし、それは建設的な評論の価値を否定するものではありません。むしろ、創造と評論のバランスを保つことこそが、真のエンジニアとしての成熟を示すのかもしれません。

不満な実装を見つけたのなら、より良いコードで示していきましょう。しかし、それは時として現実的ではないこともあります。そんなとき、具体的で建設的で受け入れやすいフィードバックは、それ自体が価値ある貢献となり得ます。

資料に物足りなさを感じたのなら、自らより良い資料を書いていきましょう。ただし、すべての領域で自ら書き直すことは不可能です。そこでは、経験に基づいた示唆に富む指摘が、コミュニティの発展を支えることになります。

エンジニアの成長は、実装による具体的な貢献を通じて実現されます。しかし、それは単独の作業ではありません。建設的なフィードバックの交換、経験の共有、そして時には適切な批評—これらの相互作用が、より良い実装を生み出す土台となります。

重要なのは、創造と評論の適切なバランスです。他者のコードを批判するだけでなく、具体的な改善案を示すことができます。時には成果を否定したくなることもあるでしょうが、それを建設的なフィードバックへと昇華させることが大切です。また、自身の実装経験に基づいた説得力のある指摘は、コミュニティの発展に大きく寄与します。特に若手エンジニアに対しては、その成長を支援する温かい指摘を心がけたいものです。

SNSでの浅薄な承認に価値を見出すのではなく、実装と建設的な評論の両輪で、技術コミュニティの発展に貢献していきましょう。それこそが、経験を積んだエンジニアとしての責務なのではないでしょうか。

創造の喜びを忘れず、同時に適切な評論の価値も理解する—その両方を備えることで、私たちは真のエンジニアとしての成長を続けることができるのです。そして、それこそが技術コミュニティ全体の発展につながっていくはずです。

批評理論を学ぶ人のために

おわりに

「この文章自体も、評論ではないでしょうか」—そんな声が聞こえてきそうです。その通りです。

私たちは、いずれ評論家になる運命から完全に逃れることはできないのかもしれません。年を重ねていったり、第一線を離れていく中で、評論的な視点は自然と身についていきます。それは、ある意味で技術者としての成熟の一面なのかもしれません。

しかし、それでも私たちには選択の余地があります。評論に溺れるのか、それとも最後まで創造を続けるのか。私は後者を選びたいと思います。

だからこそ、この文章を書き終えたら、すぐにコードを書きます。 プルリクエストを送り、ドキュメントを改善します。たとえ疲れてしまって楽な評論的な視点を持ったとしても、それを建設的な創造へと昇華させる努力を続けていきます。

エンジニアは、創造することで価値を示せます。評論だけでは、成長は望めません。

私たちは、作ることで命をつなぎます。 評論家という名の死に屈することなく。

ついでにGitHubでもフォローしてくれ⋯

github.com