はじめに
最近はGitHub CopilotやChatGPT、ClaudeなどのAIツールの進化により、エンジニアの「コーディング」という業務のあり方が劇的に変化しています。
AIが開発の重労働を担うようになっていくこれからの時代、組織のマネジメントやチームビルディングはどう変わっていくのでしょうか？
今回は、「ブリリアントジャーク（Brilliant Jerk）」という概念と織り交ぜて取り上げます。
ブリリアントジャークとは？
ブリリアントジャーク（Brilliant Jerk）とは、直訳すると
「優秀な（Brilliant）」＋「嫌な奴（Jerk）」という意味です。
Netflixの共同創業者であるリード・ヘイスティングスが同社の企業文化の指針において、「No Brilliant Jerks（優秀な嫌な奴はいらない）」として言及したことで広く知られるようになりました。
※ 出典：Netflix Culture Deck（2009年）
ITの開発現場でいうと、
「個人の技術的スキルやプログラミング能力は極めて高い一方で、他者へのリスペクトに欠ける言動をとり、チームの協調性や心理的安全性を破壊してしまう人物」を指します。
組織における彼らの特徴
ITの場合、ブリリアントジャークは以下のような行動をとることが多いです。
コードレビューでの過剰な攻撃
技術的な指摘にとどまらず、人格を否定するような言葉遣いや見下した態度をとる。
他者の意見の拒絶
自分の技術選定やアーキテクチャが絶対であると信じ、代替案や懸念を頭ごなしに否定する。
知識の独占（サイロ化）
自分がチームで一番優秀であるという優位性を保つため、自分の手柄のために情報を抱え込み、意図的に情報共有やドキュメント化を怠る。
権力の誇示
「自分は成果を出しているから」と権力を振りかざし、チームのルールを無視したり、高圧的な態度で他者をコントロールしようとする。
【セルフチェック】あなたは大丈夫？隠れJerk度リスト
「自分は嫌な奴じゃないから大丈夫」と思っていても、プレッシャーがかかる環境や、技術的なこだわりが強すぎるあまり、無意識のうちに「隠れJerk」のような振る舞いをしてしまうことは誰にでも起こり得ます。
以下の項目に当てはまるものがないか、ぜひチェックしてみてください。
※注意
以下のチェックリストは、AIツールを活用して作成したものであり、学術的な裏付けや厳密な正確性を保証するものではありません。
あくまで、ご自身の日々の振る舞いやコミュニケーションを振り返るための「参考」としてご活用ください。
- 相手の技術的なミスを指摘するとき、心の中で「なんでこんな基本的なことも分からないの？」とイライラしてしまうことがある。
- チームのミーティングで、自分の意見が採用されないと明らかに不機嫌になったり、以降の議論に参加しなくなったりする。
- 「ドキュメントを残す暇があるならコードを書きたい」「読めばわかるコードだからコメントは不要」と主張し、他者への引き継ぎを軽視している。
- チームで合意したルール（PRのテンプレート、リンターの設定など）でも、「自分のやり方の方が効率的だから」と独断で無視することがある。
- 「自分より技術力が低い」と判断したメンバーからの指摘や質問に対して、適当に返事をしたり、まともに取り合わなかったりする。
1つでも当てはまった方は注意が必要かもしれません。
そして、これらの振る舞いがもたらす悪影響は、これからの「AI時代」においてさらに深刻なものになります。
AI時代において、なぜ彼らはさらに致命的になるのか？
これまで、ブリリアントジャークは「扱いにくいが、1人で10人分のコードを書くから手放せない」と容認されてしまうケースがありました。
しかし、AI開発が主流になっていく世の中では、この前提が崩れつつあります。
彼らが組織にとって致命的になる理由は、以下の通りです。
※ 末尾の参考資料などを参考に、筆者の考えを図にしたイメージです
「個人のコーディングスピード」の価値が相対的に下がる
AIツールを活用すれば、経験の浅いエンジニアでも、かつての「優秀な個人」に迫るスピードでコードを書けるようになりつつあります。
実際に、ある実装課題ではGitHub Copilotを使った開発者のほうが55%速く完了したという実験結果があります（出典：The Impact of AI on Developer Productivity）。
また、生産性の伸びは経験の浅い開発者ほど大きかったという調査結果も報告されています（出典：The Effects of Generative AI on High-Skilled Work）。
つまり、「1人で素早くコードを書ける」というブリリアントジャークの大きな武器の1つが、AIによって「誰にでも手に入る当たり前のもの」になっていくのです。
人間にしかできない「合意形成」と「共感」を破壊する
AIには要件を汲み取りコードの出力まではできますが、
- 「ステークホルダー間の複雑な利害を調整する」
- 「言葉の裏にある顧客の真の意図を汲み取る」
- 「メンバーが落ち込んでいる時にサポートする」
といった人間らしいコミュニケーションは、これからも人間が担っていく部分です。
ブリリアントジャークは、チームを萎縮させ、活発な議論を奪い、AI時代に人間が担うべき最も重要なプロセス（＝コミュニケーションを通じた価値創造）を根底から破壊してしまいます。
チーム全体の「AI活用力」を低下させる
AIをチーム全体で効果的に活用するには、
- 「こんなプロンプトがうまくいった」
- 「このAIツールをワークフローに組み込もう」
といったオープンな知見の共有が不可欠です。
ブリリアントジャークの存在によってチーム全体の心理的安全性が損なわれると、
こうしたナレッジ共有が生まれづらくなり、結果として組織全体の技術的な進化が停滞してしまいます。
組織としての対策、そして個人としてできること
では、組織として、そして私たち一人ひとりはどのように向き合い、対策すべきなのでしょうか。
組織としての対策
採用段階での見極め（スクリーニング）
一般的に効果的とされるのは、採用段階での見極めです。 「過去に意見が対立した際、どう解決したか？」といった質問で、対話力や他者へのリスペクトを確認する方法があります。
評価基準のアップデート
「個人の技術的なアウトプット」だけでなく、「チームへの知識共有」「他者のパフォーマンス向上への貢献」をより重く評価する仕組みが必要です。
毅然とした対応とフィードバック
問題行動が見られた場合は、「技術力は評価しているが、チームに対するその言動は許容できない」とマネージャーが直接的に明確なフィードバックを行います。
他者を尊重する態度が長期的な影響力の最大化につながることを理解させ、それでも改善が見られない場合はチームから外すなどの毅然とした対応が必要です。
個人としてできること
組織やマネージャーの対応を待つだけでなく、私たち一人ひとりの日々の小さな行動も、チームの空気を変えていきます。
「教えてもらう」側から「共有する」側に回ってみる
自分が得た知見やハマったポイントを、些細なことでもチームに発信してみる。
知識を抱え込まない文化は、誰か一人の行動から広がっていきます。
指摘ではなく、問いかけで伝える
コードレビューなどで違和感があるときも、「なぜこうしたのか」を一度尋ねてみる。
相手の意図を理解してから伝えることで、対話のきっかけになります。
自分と異なる意見を一度受け止めてみる
反射的に否定せず、「なるほど、そういう見方もあるのか」とワンクッション置いてみる。
それだけでチームの心理的安全性は少しずつ変わります。
身近な「隠れJerk」的な言動に気づいたら、さりげなく声をかける
マネージャー任せにせず、同僚として「さっきの言い方、ちょっと気になったよ」と伝えられる関係性を日頃から築いておくことも大切です。
おわりに：AI時代を生き抜くエンジニアのコアスキルとは
過去のエンジニアの評価は、長らく「書いたコードの量」や「技術知識の深さ」に偏りがちでした。
しかし、AIが圧倒的な速度でコードを生成し、バグを見つけ出し、リファクタリングを提案してくれる現在、エンジニアの主戦場は変わりつつあります。
これからのエンジニアにとって最も価値のあるスキルは、プログラミング言語の文法を暗記することではなく、
「ビジネスサイドや顧客と同じ言語で対話し、人と協力し、共感し、対話を通じて不確実な課題を解決していくコミュニケーション能力」です。
技術がどれだけ進化しても、最終的にシステムを使うのは人間であり、システムを作るのもまた人間のチームです。
AI開発が主戦場になっていく世の中だからこそ、「No Brilliant Jerks」を組織のカルチャーとして徹底し、人と人との繋がりや心理的安全性を大切にできるチームを作っていくことが、これからの強い組織の条件になっていくのではないでしょうか？
とはいえ、いきなり会社・自分の振る舞いをすべて変えるのは難しいものです。
まずは、「今日学んだちょっとしたTipsをチームに1つ共有してみる」ことから始めてみませんか？
その小さな一歩が、孤高の『ブリリアントジャーク』ではなく、AI時代に本当に求められる『周囲を輝かせる存在』へとあなたを導き、チームに確かな心理的安全性を育てるはずです。
参考資料
