102
48

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

天才プログラマーに依存するリスク

Last updated at Posted at 2022-01-21

(原題は「天才プログラマーは有害」でしたが、釣りでは?との指摘があったので、改題しました)

テレビや映画で、思考が異常に速く、知識も深く、我々凡人では太刀打ちできないような天才ハッカーがよく登場します。本当に常軌を逸した能力があったり、ダークな生活をしているかはさておき、実世界でも確かに思考・分析能力が並外れに高いエンジニアは少数いますけど、仮に見つけたとしても会社・チームに置いておいても大して利益がないばかりかリスクが多いのでなないでしょうか、という話をします。

ここで私が天才というのはソフトウェア開発技術に必要な思考・分析能力がトップレベルのプログラマーのことで、単に総合的に仕事のできる人のことではありません。

##天才が必要とされる業界は少ない
そもそも、天才がチームにいなくても適当なスキルと経験があるエンジニアが揃っていればプロジェクトはちゃんと進みます。実際に開発をされてる方なら分かるともいますが、本当に新しいモノを作り出す必要があることって普段の業務では稀です。ウェブ・モバイル・デスクトップに限らず、3DやAI機械学習だって結局既存のフレームワークやアルゴリズムをつなぎ合わせることがほとんどです。もちろん、ちゃんとつなぎ合わせて実装・管理するためにはそれなりの知識や経験が必要なわけですが、それは他の人がすでに開発したものを流用する訳なので、稀有のヒラメキや独創性はあまり必要ありませんし、内部の仕組みまを隅々まで細かく理解する必要もありません。

「弊社の革新的なAI技術を駆使して・・・」なんて謳ってても、実は他の会社もみんな使ってる機械学習ライブラリを使っていることが多いです。既存の技術をうまい具合に組み合わせて、革新的な製品やサービスを開発しているおもしろいチーム沢山ありますが、それは技術面以外のところで革新ではないでしょうか(プロダクトデザイン・市場調査・デザイン・マーケティング等)。

本当に真の天才が必要とされているのは、高度な機密を扱う情報機関や一部の研究機関くらいだと思っています。必要とされていない場所で天才が活躍しようとすると、次のような弊害が起きることがあります。

##弊害1:天才の書いたコードが理解できない
天才であるが故に独創的なコードを書いてしまったり、特殊な知識がないと理解できないプログラムを作った、というのはよくある話です。ちゃんと実装が済んで機能すればいいじゃないか、と思われる方もいるかもしれませんが、ソフトウェア開発では実装したシステムを長年運営・管理・アップデートしていかなければいけません。結局プロジェクトが我々凡人の手に渡って「はい、メインテナンスよろしく」ということになり、そこでコードが理解できないほど難しければ言うまでもなく支障がでます。

例えば、自分でTCP/IPに改良を加えて自社システムに実装してしまった天才プログラマーの話を聞いたことがあります。だいたいTCP/IPの内部構造までしっかり理解しているエンジニアなんてそういません。少なくとも私は知らないし、私の同僚の殆ども知らないでしょう。どんなに改良版が素晴らしくても、管理・運営できる人が他にいなければ、事故があった時やそのエンジニアが離職した後は、会社にとってリスクの方がずっと高くなってしまいます。

プログラムはヒトのために書くものだと、私は思っています。才能の有無に関わらず、一人でできる仕事なんか限られてるんですから、結局チームで協力しないといけない。言語やフレームワークの規格・習慣に沿って書かれたプログラムは、誰でもすぐに理解できて、開発が速い。新しいエンジニアも即戦力になる。既存のパターンから逸脱したプログラム(アンチパターン)は開発が滞る。

##弊害2:天才は成長の機会を奪う
技術レベルが高い人がいつもプロジェクトの指揮を取っていて他のエンジニアが育ちにくい環境を作っていた、という状況を何度も目にしました。新しいプロジェクトがある度、「頭の良くて経験豊富のあの人に指揮を取ってもらおう」と天才エンジニアがいつも計画・設計を行う。他のエンジニアは計画書を読むだけ。「分からないことがあったら聞いて」「どっかおかしいところはある?」と言われても、「あの人よりも自分の方がいいアイディアを持っているなんてありえない」「この方法に反対してもあの人には敵わない」と萎縮してしまうから、結局天才エンジニアの計画がそのまま通る。

これでは他のエンジニアの成長に機会が奪われてしまいます。ある程度技術的なことをその人から学ぶことはできるでしょうが、実際にプロジェクトの計画を自分で練ってみないと本当の成長の機会は来ないと私は思います。個人的なところでは、こういうチームは自分の貢献度が低くて、やり甲斐もなく、働いていて面白くありません。

エンジニア自身やチームリーダーが積極的に責任分担を行い、誰でも安心して発言できる環境を作ることでこの問題はある程度回避できるはずですが、突出してレベルの高い人がいるとこういう状況に陥りやすいです。

##弊害3:天才依存のリスク
以上の2点が悪化すると、天才に依存したチームが出来上がります。あの人にしか触れないソースコード。あの人にOKをもらわないと先に進めない。

###開発のボトルネック
天才エンジニアが介入しないと進まない案件が山積みになると、その人は忙しいのに、他のメンバーは手持ち無沙汰に待っているだけ、という状況になります。時間も人件費も無駄遣いで、天才エンジニアの過労にもつながります。

###天才も間違える
依存が進んだ状況では、あの人にOKもらったから絶対大丈夫、という心理が働きます。メンバーが自身で欠陥をチェックせず、天才が何かを見落とすと(特に過労が続いていると)事故につながったりします。

###離職
過労があってもなくても、転職の機会が多い業界です。依存が進んだチームから天才が抜けたあと、埋め合わせに何ヶ月も掛かったり、ソースコードが理解できないので見落としが多くなり、リリースの度に障害が発生するチームを見たことがあります。

##必要なのは、適当な技術レベルと高度の協調性
一番チームに有益なのは、適当な技術レベルと高度の協調性を兼ね備えたエンジニアだと思います。

###適当な技術レベル・経験
これまでの内容で誤解がなかったといいのですが、技術面である程度適性があって、年数相応の実績があって、しっかり勉強していることはエンジニアとして非常に大事です。誰でもいつでも始められる仕事ではありません。チーム内で5年や10年以上の実装経験がある人がしっかりリーダーシップを取っていることも大事です。ただ、突出した天才レベルの思考・分析能力は普通必要ないと言いたかったのです。

例えば、技術面接で満点を取る人と合格点をギリギリ取る人がいたとします。反対する方もいると思いますが、私は両者を区別しません。合格点に達しない人を切るのは仕方がないとして、かといって満点を取る人を特別扱いしません。もともと面接のプロセス自体が不完全なので、満点取って採用したら技術レベルは人並みだったなんてよくある事です。仮に、満点取る人と合格点取る人とに本当に点数差分の能力の差があったとしても、その差分が実務に与える影響は少ないと思っているので「両者とも技術面はクリア」と判断して、非技術面を重視します。技術満点で協調性のない人よりも、合格点で協調性がある人の方が、チームにずっと有益だと思うからです。

###高度の協調性
経験の浅いエンジニアの育成が上手。
非技術者とも気持ちよく働ける。
技術以外の業務の大切さがわかる。
チームの雰囲気を明るくできる。
コミュニケーションの達人。
ハラスメントをしない・許さない。
こういった所謂ソフトスキルを効果的に実践できるエンジニアは天才の技術屋を探すくらい大変かもしれませんが、チームに与える効果は絶大です。こういうメンバーが揃っているチームではモチベーションも高いので事業もはかどり、新人が育ち、離職率も低いでしょう。

##才能は悪くない
今更ですが、才能があること自体が悪いわけではありません。むしろ良いことです。ただ、ずば抜けた才能があって意識が高くて向上心のある人は、いい仕事をしよう、チームに貢献しようと思って、上記のような弊害の原因を作ってしまうかもしれないので気をつけましょう、というのが本意です。突出した能力を持っていても協調性やリーダーシップで弊害は防げます。例えば、チーム内でスタイルガイドやデザインパターンを統一し、プログラムの理解性の高さをPRレビュー等で重視すれば、弊害1は防げるでしょう。少し経験を積んだ若いエンジニアに設計・計画をやらせてみたり、会議中にあまり発言しないメンバーにも意見を促し、無知や未経験を蔑まず発言の積極性を評価すれば、弊害2も防げるでしょう。

(ただ、本物の天才なら普通の職場は張り合いがなくて飽きてしまうのではないかと、凡人の私は思ってしまいます。)

ここまで書いていて気づいたのが、別に天才ではなくとも、同じことが起きることもあるのではないか、ということです。天才気取りで独りよがりのコードを書いたりすれば弊害1は起きるし、経験値が高い人が意気込んでいると弊害2も起きるし、誰か一人に依存したチーム(弊害3)も出来上がるわけですね。そう考えれば、結局才能うんぬんの話でなはく、特定のメンバーの能力に依存しないチーム作りの話だったのかもしれません。

##追記
少し挑発的ではありますが、私の考えを正直に書きました。LGTMを下さった方もあり、批判的なコメントも頂きました。的確な反論をされている方もいますし、返答に私が記事を書くに至った経緯なども触れておいたので、コメント欄も読んでみてください。ただ、マトを得た批判も出尽くした感がありますし、私もこれ以上特に追加することはないので、コメントにはもう返答していません。

初めて試しに記事を書いみて、閲覧百件も行けば良いほうかなんて思っていたら1万件を越えてしまいました。あまり叩かれたら消そうかとも思っていたんですが、共感された方も少なからずいるし、時間を割いて丁寧にコメントしてくださった方もいるので、このままにしておきます。

102
48
24

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
102
48

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?