解像度を高め、「自分のやりたいこと」に合わせて伸ばす　佐伯学哉氏が考える“エンジニア力”の高め方

佐伯氏が考える“エンジニア力”の要素

ーーエンジニアというと注目されがちなのは技術力ですが、実際にはそれ以外のさまざまなスキルも必要です。それらを称して“エンジニア力”とした時、佐伯さんの考える“エンジニア力”にはどういった要素が挙げられるでしょうか？

佐伯学哉氏（以下、佐伯）：僕も自分で考えてみたんですが、「“エンジニア力”って何だ？」となって。個人的に、一言で“エンジニア力”と言えるものはないと思うんですよね。

一方で、ざっくり“エンジニア力”が高い、つまりすごいエンジニアだと自分が思っている、尊敬しているエンジニアとか、「この人すごいな」と思っているエンジニアさんの共通点を考えてみたんですね。

そしたら、結局はおもしろいアウトプットとか、すごいアウトプット、関心できるアウトプットを出している方は、やはり個人的にはすごいエンジニアだと思っていて、それがいわゆる“エンジニア力”が高いエンジニアだと自分的には思うんですね。

ただ、アウトプットって種類がいっぱいあるんですよ。例えば、僕が趣味としてやりたいとふだんから思っているような、自分のプロダクトを作ってそれがメチャクチャバズるとか、いろいろな方に使ってもらうとか。

一方で、すごく難しい技術を解説していて、その知識のすごさに圧倒されるようなエンジニアさんもいます。

あとはただ手が早いみたいな（笑）。ただ手が早くて、気がついたら10個ぐらい難しいことをやっているようなエンジニアさんもいるんですね。

いろいろなタイプの方がいますが、こういうエンジニアになることに必要なことは、共通していない気がするんですよ。

1個目の自分のプロダクトを出すエンジニアに必要なのは、もちろん技術力。いわゆる「こういうプロダクトを作りたい」という要件があった時に、それを実現するコードを書きあげる力は技術力としてもちろん必要です。

でもそのプロダクトがなぜすごいのかは、もはやそのプロダクトの趣旨に依存していたり、あとは1人でやるという性質上、実は同じことをできる技術力のあるエンジニアはたくさんいるけど、「それをやったのはこの人しかいない」ということになりがちなんですよ。

それはつまり持久力というか、「どうしてその1つのプロダクトをあなたは2年もやり続けることができたのか」みたいな。こういうタイプは、もはやクリエイティビティみたいなものに比重が強くなってくるところがありますよね。

わかりやすいのは3個目のただ手が早い人（笑）。競プロのランクが高いとか、ただただ頭がいいし、知識がすごいとか、実践力があるとか。

クリエイティビティがあるだけじゃ手が早くなるわけじゃないし、手が早ければ別にそういう自分のプロダクトが出来上がるわけじゃないですよね。人によってすごいアウトプットもいくつか種類があって、それに必要な力も違うと思うんですね。

つまりどういうことかというと、「“エンジニア力”が高い」というのは、いろいろな種類があり得るという話です。アウトプットというと個人開発の結果とかを想像しちゃいますが、単に仕事でも、自分が今やっているプロジェクトのタスクに対してメチャクチャ知見の深い話をしたり、素早くきれいな設計をするとか、そういうアウトプットもあります。そういうのも「すごいエンジニアだ」と思うわけじゃないですか。

あるプロジェクトを早く進めるのって、コーディング力とかだけじゃなくて、むしろプロジェクトマネジメント力みたいなものもメチャクチャ必要になってくる。むしろコミュニケーション力がキーで、なんならクリエイティビティはいらないとか、ぜんぜんあるじゃないですか。

だから“エンジニア力”は人によって違う。「あなたにはあなたの“エンジニア力”」みたいなものがある気がしているんですよね。

僕は趣味としてはどちらかというと「自分のプロダクトで何かをしたい」という比重が強いので、辛抱力、飽きずにやりとおす力とかが欲しいなと思っています。

キャリアステージや環境によって必要なスキルの比重は異なる

ーー「あなたにはあなたの“エンジニア力”」はキャリアに詰まった時の考えのヒントになる気もしますが、なにか活用のアドバイスはありますか？

佐伯：自分は中堅なので勝手なことは言えないんですが、ステージによって必要な力が違うのは、かなりあると思っています。

例えば、最初の数年とかはわりと小さなタスクを自分1人で完結してやることが多くて、新人だったら実装力というか、情報を自分で調べる力とかが必要です。あとは、きれいなコードを書いてテストをしてとか、細かい話になるけれど、そういう基礎をどんどんやっていく。どちらかといえば1人に完結した細かい技術力がちゃんとあるかが最初は大事です。

どんどん扱っているプロジェクトが大きくなって例えばリーダーになるとか、あとは単純にチームの人数が大きくなると、コミュニケーション能力が大事になってきます。前に進めるためには自分の設計を誰かに説得しないといけないし、時には「止めたほうがいいんじゃない？」という話から始める必要もあって。

そうするとコミュニケーション能力の比重が出てきて、仕事によっては技術力と同じぐらい、もしくはもっとコミュニケーション能力や細かいマネジメント能力が大事になるシーンも出てくると思うんですよ。

これは別にキャリアステージだけではなくて、自分の入ったチームの規模によっても違うんですよ。最初に僕がいたエウレカは、アルバイトだったというのもありますが、わりと自分で完結していました。

一方で、小さい会社とかになるとやることが増えて、コミュニケーションが発生する。とはいえ小さい会社はだいたい知り合い同士なので、そんなにコミュニケーションは大変じゃないですけど（笑）。

大企業だとコミュニケーションがメチャクチャ大事になって。知らないチームと往復してコミュニケーションを取る必要があるとか、タスクによっては自分がプログラミングをするのではなくて、他のチームとの調整がボトルネックになるパターンもたくさんあったかなと。

繰り返しになってしまうかもしれませんが、自分のキャリアステージ、もしくは自分のいるチームの規模で、自分が何を強みと感じたいかによって必要な力がどんどん変わると思うんですよね。

他の人の話になっちゃうんですが、ずっとおもしろいなと思って聞いているのが、moldとかLLDとか、そういうリンカの開発をしているエンジニアのRuiさんという方がいて。その人がよく言っていたのが「昔自分がGoogleにいた時は最初はサーチエンジンチームだったけど、そのあとリンカのチームというかLLDのチームに移って。そっちのほうがぜんぜんうまくやれた」みたいな話があったんですね。

世界的なリンカの開発をしている方でもそう。だから、やはり「どこで何をするか」と「自分が何をしたいか」みたいな、そういう個々の事例によって必要な力はぜんぜん違うと思うんです。だからメタ的にいえば、その分析はかなり重要かもしれないと思っています。

佐伯氏が“エンジニア力”をつけるために意識してきたこと

ーー先ほどのお話で、佐伯さんは「自分のプロダクトで何かをしたい」比重が強いとのことですが、そのタイプに必要な力をつけるために、何か意識してきたことはありますか。

佐伯：その領域は完全に趣味なので意識的ではないので難しいですが、でもふだんから「次に何をやればおもしろいかな」ということは、趣味の一環としてずっと考えている。楽器やっている人が「次に何を弾こうかな」と常に思っているかはわかりませんが、そんな感じで「次に何をすればおもしろいかな」というのはずっと考えていますね。

あとは「何を作りたいか」だけじゃ作れなくて、実際に作りたいと思ったものを実現する細かい技術力ももちろん必要なので。それはけっこう絡めるんですよね。

例えばRustが流行っているからRustを勉強したい。でも「Rustを勉強したい」というモチベーションだけじゃ何もできない。サンプルを作るぐらいしかないから、「Rustを使って何かおもしろいものができないかな」と思って作ったのが、僕の場合はWSLでSystemdを動かすとか、WSLで顔認証をできるようにするとか。

特に2つ目のほうはRustの勉強として始めた側面がかなり大きくて。でも自分がやりたいことを作っているから、次はプロダクト作りが楽しくなっちゃって、作っているうちにRustの勉強にもなるみたいな。

勉強と趣味を絡めるのはかなり効率が良いというか、一石二鳥だからよくやっています。他の人もけっこうそうなんじゃないかな。ちょうど勉強したいと思っていたことで、それに絡めて楽しいことがないかを探すみたいな。

アウトプットのためにインプットする

ーー今のお話はインプット・アウトプットの話と絡むところがあると思うのですが、インプット・アウトプットのバランスで気をつけていることはありますか。

佐伯：意識しているともしていないとも言えないんですが、基本的にはアウトプットを重視しています。もしかしたらよくある話かもしれませんが、インプットだけをしようと思っても頭に残らないし……。すみません、これは見栄を張りました。そもそも続かないんですよ。

（一同笑）

そもそも本を買っても読み通せない。厚いし、途中からよくわからないしみたいな。それよりは「それを使って何か作ろう」と思ったほうが、作っている過程でわからなかったことが、なぜわからなかったかがわかってくるし、「手で動かしてみれば簡単なことだった」みたいなことがあったり。

何かを作るために必要になった知識ベースで飛び飛びに学んでいくと、気づいたら本の最初から最後までを読んでいたみたいな。人によると思いますが、僕は何だかんだでそっちのほうが効率が良いと思っているんですね。

それに、アウトプットといっても、別にインターネットに公開する必要はない。僕にも日の目を見なかった趣味プロダクトがたくさんあって。単純に途中で飽きちゃったというのが一番多いんですけど、でもたとえ途中で飽きたとしても、それを作る上で入れた知識は身についています。

見方を変えれば、インプットのためにやった習作の話にもなるので、やはり何かを作るというのが、実はインプットするのに一番良いやり方かなと思っていますね。

しかもこのやり方って、もし完成したらインターネットに公開できて。これはよく言われることではありますが、アウトプットをする、例えば「○○を作りました」というと、その情報に関する情報がなぜか不思議と集まってくるんですよね。なんでかはわからないですが。

僕はARM入門勉強会を1回主催したことがあります。理由はシンプルで、僕がARMのことを何も知らなかったから。ARMのことを知っている人は1人知り合いでいるし、「みんなで分担して調べて発表しようぜ」と言って発表したんです。僕は文字どおり、何も知らなかったんですよ。なのに、ARM入門勉強会をしたあとは、ARMの話がよく来るようになって。

外から見たら、「あ、こいつは何か自分で調べて発表してるし、出来上がったものを見るとちゃんと学んでいそうだから、とりあえず聞いてみるか」みたいな。そういう気軽な話が発生して、聞かれたら知っているものは答えてそこから話が進むし、知らなくてもそこから「知らないな、何だ？」と思って調べるから、結局どんどんインプットできる。

「とりあえずアウトプットをやる」というのは、そういう瞬間があって良いことずくめな気がしますね。ただ僕はそういうタイプですが、得意なことは人によって違うので、ずっと本を通読できるようなすごい人もいると思うんですよ。ただただ何冊も本を読めるみたいな。知り合いにも1人います。ただただ本を何冊も読むことができる人。そういうことが得意な人もきっといるはずだと思います。

趣味はタイムマネジメントしない、やりたくないことはタイムマネジメントする

ーーインプットとアウトプットのバランスでいうと、タイムマネジメントも重要なポイントだと思います。「好きだからこそやり続けることができてしまう」というところもあると思いますが、時間に追われ過ぎないために意識されていることは何かありますか？

佐伯：それに関していうと（僕は）あまり良い例ではなくて。どうしてかというと、僕は区切りがつけられないんですよね。趣味で何かを作っていた時は、仕事がなければ作り始めたら午前4時ぐらいまでやって、寝て起きてまたやるみたいなこともよくやっていたし、今も次の日が土日だったらやっちゃいます。これはもちろん熱が入っている時ですけどね。趣味で何かを学ぶということに関しては、タイムマネジメントはしていません（笑）。

これはもちろん良い面もあって、一気にやるし、いろいろながんばって調べるから単純に知識はつくし、経験にもなるし、細かい技術力みたいなものも上がっていきます。おすすめできるわけじゃないですけどね（笑）。

趣味の話はそうですが、一方で僕は転職を何回かしていて、その時に転職対策みたいなこともしているんですよね。転職の対策は楽しいものではないので「寝ずにやる」みたいなことはなくて、ちゃんとタイムマネジメントはしていました。

エンジニアあるあるかもしれませんが、エピック、ユーザーストーリー、タスクみたいな感じで、1人カンバンみたいなものを作って。

エピックは個人的な部分もありますが、一番大事なものは「転職先を探す」とか、「入社に必要な手続きを整える」とか。エピックからユーザーストーリーにいって、「じゃあまずはレジュメを書かなきゃね」とか。「面接の内容も考えなきゃ」「想定質問を考えなきゃ」という感じでユーザーストーリーを書いて、タスクとして「今週はこれを読むか」みたいな。

そうやって、やりたくないけどやらなきゃなと思っていることは、「今週はこれとこれのタスクをします」みたいなことをやって、スプリントを回して、「カレントスプリントはここです」といってin progressにして、みたいにやっていました。

ただ、転職はしなくてもいいじゃないですか。だから「気が向いたらやる」みたいな感じで、このスプリントのタスクも3回ぐらい、なんなら1ヶ月ぐらい持ち越されていくんですけど。

でもあれがあったから、好きじゃないこともちゃんとやれた面もあったので、そういう管理も、人によってはハマるかもしれないですね。

“エンジニア力”を高めたいなら、解像度を高める

ーー最後にまとめとして、「“エンジニア力”を高めたい」と自分が思った時に、どういうステップを踏むのがいいでしょうか。

佐伯：解像度を高めるのが大事ですね。基礎的な技術力は絶対に必要なので、Udemyでも自分でプロダクトを作るでも何でもいいので、とりあえずまずは基礎的な技術力をつける。何かサンプルプロダクトを作ってみる。まずは前提として技術力は必要で、そのスキルを高めることは絶対にやったほうが良い。

その上で、先ほどの話にあった「自分が思うエンジニア力は何か」みたいな話が大事で、自分が何に憧れているのか、自分は何をやりたいのか。

あとは、自分の得意なものが何かを見て、どこを伸ばしていくかを考えるのも大事な気がしますね。「こういうものを作るのはおもしろそう」と思っているものがあるんだったら、作ってみたほうがいい。何ならそこから始めるのでもよくて、「作れないな」と気づいたら基礎力をつける必要が出てきて、先ほどのアウトプットの話になりますが、アウトプットベースでどんどん必要なインプットを身につけていけると思う。

僕も「DirectXってなんだ」というところから始まって、最終的にプログラミング言語を作るみたいなことをやっていたので、そんな感じでどんどん進めていけます。「やりたいことはないけど、成績というかポイントを稼ぐのは得意だよ」という方なら、競技プログラミングでKaggleとかを始めるのもいい。人によって違うと思うんですよね。

あとは、「ソフトウェアエンジニアになりたいし、ソフトウェアエンジニアの力をつけたいけれど、どちらかというと自分は人と話すのが好きです」みたいな人は、英語ができる前提ではありますが、最近だったら有名なOSSプロダクトのissueに行って、Good First Issueとか、初心者でもできるissueを始めて、それだけを見て何をやればいいのかわかるならやってもいいし、「これをやりたいんだけど、これはどうすればいい？」とリプライで聞いてしまうとか。

僕はそういうのは苦手なのでできませんが、これができる人は知り合いに何人もいるんですよ。だからコミュニケーションが得意とか、飛び込むのが得意という強みがあるんだったら、いきなりどこかのOSSの応募に入って、経験を積む道もあります。あとはいきなりどこかのインターンに申し込むとか。

そういった、やれることとかやりたいことによって、最初の“エンジニア力”がつくというか。

人に「おもしろい」とか「すごい」と思ってもらえるアウトプットはいろいろな種類があって、種類によってさまざまなやり方があるから、「自分ならこれが一番できるな」と思う道筋があると思うんですよ。

パターンに応じてやれることがあると思うので、基礎力をつけたら次にそれをやるのが、人によって「“エンジニア力”が高いとはなにか」は別だけど、なんだかんだいって誰かから“エンジニア力”が高いと思ってもらえる近道な気がします。