想像もつかないような頭のおかしな仕様をやる人は天才

司会者:これもよくいただく質問ですが、ひろゆきさんが思う、エンジニアでこの人は天才だなって思う人は、例えばどんな方がいますか?

ひろゆき氏(以下、ひろゆき):ドワンゴっていう会社で一緒にやっていた時に、僕だったら絶対やらない危ないことをやるけど、確かに合理的には正しいなっていう人がいて。

本来であれば、読み込む時にデータを全部テキストファイルから読み込んで、パースして、ってやるんですけど、それをインクルードファイルとして生成して……要は機械でコードを書かせて、そのコードを無理やり読み込むっていう。

本来であれば、テキストで出力して、置いといて、使う時にテキストとして読み込んで、それを変数に入れて、って使うんですけど、コード自体をプログラムが吐き出すようにして、「.inc」という名前で保存して、インクルードファイルとしてそのまま丸々入れてしまうという構造の仕様を書く人がいて。

僕、「この人、本当に頭おかしいな、なんかやべぇんじゃないかな」と思っていろいろ調べたんですけど、確かにその書き方でもエラーもないしセキュリティリスクもないから、ありっちゃありかと。僕もいまだにやらないんですけど、そうやって思いついてやっちゃって、「確かにそのほうがコードは速いよね」と言われたら、「おっしゃるとおりです」という(笑)。

ああいう、想像もつかないような頭のおかしな仕様をやる人がいると、絶対勝てねぇなと思います。

司会者:それに関連して、チャットでいただいている質問です。「ひろゆきさんが仕事をしていて、この人できるなって思うエンジニアはどんな人ですか?」

ひろゆき:自分が考えている「こうだろうな」を超えてくるアイデアを出す人は、できるなと思いますね。

ある程度IT系はわかるけどもエンジニアじゃないおっさんで、「あれ? ここの機能要らないよね」みたいに、気づく人っているんですよね。「それはなくてもいいじゃん」と、結果それをなくしたら、もっとシンプルになって納期も短くなってできるよね、というのがあったりするので。

なので、自分が想定した以上のものを教えてくれる人や気づく人は、頭がいいんじゃないかなと思います。

司会者:そういうのに気づく人は、どういう鍛錬を積んでいるとか、どういう経験をしているんでしょうか?

ひろゆき:ある程度ほかの人がやる常識と、それ以外の常識外のことを思いつくかどうかだと思うんですけど。

昨日の夜まで、ドワンゴの創業者の川上さん(川上量生氏)と飲んでいたんですけど。昔、川上さんがモデムを作る会社でユーザーサポート的なことをしていた時に、バグがあってめちゃめちゃ電話が鳴ったんですけど、対応策として、電話回線を全部引き抜いたらしいんですよ。

要は、どうせずっと電話が鳴り続けて、受け取れないという、かけてもずっと電話鳴りっぱなしという人が大勢いるんだったら、もう誰も電話を取らないほうがいいと。

電話対応しないで、その代わりにバグを直すのと、その当時直すためのCDを送付するというのがあったんですけど、CD-Rに修正ソフトウェアを入れて、それをユーザーに全部送りつけたほうが、最終的には効率いいよねと。

要は、電話でいちいち聞いて、「ごめんなさい、ごめんなさい」ってやるのは、単純に時間の無駄じゃないですか。そうやって謝ったほうがいいよね、カスタマーサポート大事だよねと思う人もいるんですけど、それよりもソフトウェアをバンと送りつけて、「お届けしたソフトウェアをインストールしていただければ直りますよ」と言ったほうが早いよね。

それを実現するんだったら、電話ないほうがいいよねという、そこらへんの考え方の違いっていう、常識をどう……。

司会者:大胆さと合理性の狭間といいますか。なるほどですね。

ひろゆき:でも、そのイズムを受け継いだドワンゴ社員で、酷いことになったやつがいるんですけど。

昔、「iモード」っていうサイトで、毎月チャリンチャリンってお金儲けができる時代があったんですけど、その時は、月末に退会するとその月の分遊べて、次の月にお金がかからないから月末に退会者が増えるという構造だったんですよね。

ある社員が、月末の退会者を減らしてくれというミッションを与えられて、メガネ君という社員が、退会リンクを消したんですよ。

司会者:(笑)。

ひろゆき:そうしたら、退会がゼロになったので、確かに退会数は減ったんだけどドコモにめちゃくちゃ怒られるというのがあって(笑)。

やってもいいことといけないことのラインは大事だよね(笑)。

司会者:メガネ君は、それがちょっとわからなかった。

ひろゆき:わかっていなかった(笑)。

今でも、退会のリンクがめちゃめちゃ探しにくい、わかりにくいところにある会社ってあるじゃないですか。FAQに飛んで、質問のところに行って、退会しますか、「はい」「いいえ」で、「退会しますか?」の次に、「いいえ」「はい」に順番が変わっているみたいな、ああいうことをちょこちょこやって退会率を下げるのも、一応テクニックとしてはアリなのかなとは思いますけど。

司会者:ありがとうございます。

随時チャットからも拾っていきたいと思います。ちなみにみなさん、チャットに(質問が)めちゃくちゃ来ているので、随時拾っていますが、全部に答えられるわけじゃないので、これだけよろしくお願いしますね。

エンジニアは要領の良さがけっこう重要

司会者:では、直近のところから1個拾いましょうかね。「Fラン文系大学生が大手企業に就職するために、プログラミングを勉強してアプリ開発で実績を残そうと思っているんですが、賢明な判断でしょうか?」

ひろゆき:Fランク大学でそんなに頭が良くないのであれば、むしろプログラムに懸けるほうが、ワンチャンありますけどね。

要は、勉強してなにかを学んで、試験的なものに受かる能力が低いというのは証明されていると思うので。

プログラムって知識をいっぱい入れて、それをアウトプットするものでもなくて、わからない関数があったら全部ググればいいし。要領の良さがけっこう重要だったりするので、コツコツと努力をするより要領がいいよね、勉強しないで大学に行ったほうがいいよねと思うタイプのほうが、むしろプログラマーに向いている場合があるんじゃないかなと思いますけど。

司会者:これに関連して、同じくチャットでいただいた質問です。「エンジニアは地頭が必要と言われますが、Fラン学生にエンジニアはきついんでしょうか?」というところで、地頭とエンジニアリングってどうなんですか?

ひろゆき:トップレベルになろうとか、エンジニアを束ねるレベルの管理職に出世したいとかであれば、たぶん地頭はけっこう必要になるんですけど。別に普通にワーカーとして働く分であれば、四大を卒業できるぐらいの頭があればぜんぜん問題ないと思いますけどね。ただ、「英語が読めません」とかまでいくと、ちょっときついんじゃないかなと思いますけど。

エンジニアの英語力に関する、ひろゆき氏の見解

司会者:逆にエンジニアとして英語力って、ひろゆきさん的に、どれぐらいあったほうがいいってありますか?

ひろゆき:「いい」というのをちゃんともらうんだったら、必須になるんじゃないですかね。やはりドキュメントって基本的に英語で発表されるので、誰かが日本語にするのを待っているとか、翻訳を待っているとかになっちゃうと、ドキュメントを読むのが億劫になってしまうんですよね。一応翻訳サイトにぶち込めば日本語になるんですけど、「それは面倒くさいよね」と、英語のサイトだからと言って見ないと、情報を得るのを遠回しにしちゃうんですよね。

情報は多ければ多いほど判断しやすいんですよね。「こういうプログラムを書きたいよね」とか「エラーコード入れました」といって出てくるのって、英語のサイトが多いんですよ。 要は、もともと使っているミドルウェアが英語圏で作られているものだと、そのエラーコードで困っている人は英語圏に多いので。

そこのコミュニティとかで、「こんな感じのコードを書いたら直ったよ」とか「これってこのバグだからバージョンをこっちに下げたほうがいいよ」とか書いてあるのを、英語でバッと見て、あぁ、これなんだってわかるかどうかというのは、けっこう大事なんじゃないかなと思いますけど。

司会者:それに関連して質問が来ています。「お金がなくて今は留学ができません。留学以外で英語がしゃべられるようになるお勧めの手段はありますか?」

ひろゆき:読めればいいだけなので、別にしゃべれなくていいと思いますよ。

司会者:留学以外でありますか?

ひろゆき:英語のサイトを見て、難しいと思っていると思うんですけど、まずは翻訳サイトを通さないでバッと内容を見て、その後翻訳サイトを通して、「あっ、この部分は合っていた」とか「あれ、この部分ぜんぜん違った」とか、わからなかった部分や自分が違っていた部分を見つける中でちょっとずつ学習すればいいんじゃないかなと思いますけど。

司会者:とのことです。ありがとうございます。

ひろゆき:英会話は別にやらなくてもいいと思うんですよね。英語でコミュニケーションできるかできないのかであれば、できたほうがいいんですけど。

外資系も、今はけっこうリモートでメールベースでやり取りしているし、別にそんなのコミットしてくれればいい、コメントをちゃんと英文で書いてくれればいいという会社もあって、英語を耳で聞いて英語を口で返すという能力がなくても、普通に仕事ができる時代になっちゃったので。

なので英会話は、やりたい人がやればいいけど、後回しでいいんじゃないかなと思うんですけど。

司会者:ありがとうございます。

エンジニアのコミュニケーション力において大事なことは?

司会者:では、コミュニケーションに関連して、「けっこうなコミュ障なのですが、エンジニアにとってコミュニケーションは必要ですか?」というコメントもいただいています。

ひろゆき:まったくなくても暮らせるという職業の中のランキングでは、(エンジニアは)かなり高いと思うんですよね。もちろん組織で、会社で働く場合であればコミュニケーション能力は必要になるんですけど、完全なコミュ障でも、いいコードさえ書いて納品さえしていればけっこう許してくれるくらい、エンジニアにとって社会は優しいので、(エンジニアは)コミュ力がぜんぜんない人でも大丈夫という、稀有な職業の1つじゃないですかね。

司会者:その中でも、「エンジニアとしてのコミュニケーション能力を鍛えるためにはどうすればいいですか?」という質問が来ているんですが、こういう場合はどうでしょう?

ひろゆき:エンジニア同士のコミュニケーション能力っていう、「エンジニアにこういう言い方をしたほうがいいよね」とか「こういう言い方をしないほうがいいよね」というコミュニケーション能力と、発注元であるクライアントだったり上司だったり、エンジニアリングがわからない上司と話す時にどういう言葉を使えばいいかって、ぜんぜん別の話になるので。

エンジニアリングがわからない人だったら、「こういう概念は言ってもしょうがないから、喩え話にしよう」とか切り替えたり、こだわりがあってコードを書いている人だったら、「こだわりを外してしまうとすごく機嫌を損ねるから、そのこだわりはそのまま残しておいて、最後の最後でちょっとだけ削って納品しよう。そのためにどうやって説得しようかな」みたいな、考え方を変えるとか。

人それぞれに対してどう対応するかというバリエーションと、多くの人と話をするということになってくるんじゃないかなと思いますけど。

司会者:ありがとうございます。

ひろゆき:今のは、エンジニアリングと関係なく、すごく一般的な話ですね。コミュニケーションの能力、いろんな人がいるから、いろんな人と話そう(笑)。

コメントで、「専門用語はあまり使わないのがベストかもしれませんね」とあったんですけど、エンジニアリングがわからない人になるべく専門用語を使わないというのは、僕は正しいんじゃないかなと思いますけど。

司会者:ありがとうございます。

新卒カードが使えるうちは、大きめの会社に行くのが安全

司会者:続いて、「今ひろゆきさんが就活生だったら、どんな企業を選びますか? 判断基準をお教えください」。

ひろゆき:独立する気でいるのであれば……でも、結局一緒か。大企業にまず入りますね。大企業に入って、大企業の肩書があったほうが転職が容易なんですよね。

「一部上場のIT系の企業(出身)です」となると、逆にIT系じゃない企業も入りやすくなるんですよね。要は、「この人、ITわかってそう。うちの会社もITにそろそろ本腰入れなきゃいけないから、こういう人が欲しいよね」となったりするので。

独立するのであれば、中小でオーナーがけっこう優秀なところに入って、会社組織の運営をちゃんと学んで、「あぁ、こうすればいいんだ」というのをわかって独立するのはあるかもしれないんですけど、最初から中小に行って独立には向いてないとなると、そこからキャリアを作って転職して大企業に入るのはけっこう遠くなるので、新卒カードが使えるうちは、大きめの会社に行くのが安全なんじゃないかなと思いますけども。

司会者:今、質問が来ています。「その大企業にはメガベンチャーは含まれますか?」

ひろゆき:含まれています。楽天とかヤフーとかサイバーエージェントに新卒カードで入れる人は入ったほうがいいんじゃないかなと思いますね。

司会者:ひろゆきさんは、新卒カードとよくおっしゃいますが、どういうメリットがあるんですかね?

ひろゆき:たぶん日本特有だと思うんですけど、あんまり社会を知らない新卒を洗脳して、うまく安くこき使いたいというのが、わりと日本の会社というか文化としてあって。

「本来であれば、この人って即戦力で年収1,000万レベルだよね」という人に対しても、「とりあえず新卒でみんな横並びだから年収500万でよろしく」と言って、会社としては500万浮いたわ、というのはわりとやりがちなので。

なので優秀な人にとっては、新卒みんな横並びは損なんですけど、逆に言うと、優秀かどうかわからないという人たちが人を採用していたりするので、ぜんぜん優秀じゃない子も、「新卒だからきっとこれから学んだら優秀になるのかな」って誤解されて、その人たちの能力だったらなかなか入れないところも入れてしまうというのがあります。

なので、無能な人は新卒カードをうまく使ったほうがいいんじゃないかと思いますけど。

司会者:忖度なしで(笑)、そういうことですね。ありがとうございます。

(次回へつづく)