「“課題を見つけて分解する力”と“コードを書いて解決する力”は全然違う」　増井雄一郎氏が明かす“エンジニア力”の本質と鍛え方

自分の強みは「新しいことをおもしろがって勉強できる」こと

ーー増井さんご自身が考える、自身のエンジニアとしての強みはどこでしょうか？

増井雄一郎氏（以下、増井）：新しいことを覚えられるというのは、やはり強みとしてあるなと思います。

1つの技術の初めから終わりまでは、だいたい20年でワンサイクルだと思っているんですよ。要するに、本当に初期から関わればその技術はだいたい20年ぐらい使える。逆に半分ぐらいから入ると10年ぐらいしか技術のライフタイムがもたないんですよね。

一昔前の35歳定年説みたいな話があったのもそうで、社会人の2年目、3年目ぐらいはたくさん覚えることがあるからたくさん勉強するじゃないですか。だけど、だいたい技術は10年ぐらいで陳腐化するので、35歳になった時に25歳で覚えたことはおおむね陳腐化しているんですよ。

その間に新しいことを覚えていないと、35歳の時に25歳で学んだことを使いきっておしまい、というふうになっちゃうと思うんですよね。

僕はそういうふうになるのは嫌だなと思っていて、別にITにかかわらず新しいことを覚えるのが好きです。

例えば、僕が今いる会社はスキンケア事業もやっているので、化粧品検定を受けるために勉強をしたんですよ。だけど、女性なら当然のようにわかることがまったくわからなかったんですよ。僕には初め、化粧水とファンデーションすら、顔に塗るもの以上の違いがわからなかったわけです。

女性の多くは自分の肌のことや化粧品や成分のことにすごく詳しいじゃないですか？　ビタミンCとか日焼けの話とか当然のように知っている。まったくわからない化粧品のことを新しく勉強するのがすごくおもしろかったんですよ。

だからといって僕は化粧をしないので、それを自分に使うことはないんですけど、やはり「新しいことを覚える」そのものは楽しいし、その仕事に関わることで新しく覚えることはたくさんあると思います。

例えば食品加工の分野に行けばそれはそれでおもしろいことがあると思うし、新しいことをおもしろがって勉強できるということは、僕の強みなんだろうなって思います。

大きく2種類に分かれている“エンジニア力”

ーーIT業界は、変化のスピードが速いと言われていますが、需要がなくならないエンジニアであり続けるために必要な「エンジニア力」とはなんでしょうか？

増井：僕は、エンジニア力は大きく2種類のパートに分かれると思っています。

課題を見つけて課題を処理可能な単位に分解するという、企画に近い部分。もう1つはその単位をコードに書き起こしてユーザが触れるようにすること。この2つです。つまり、「こういう困ったことがあるんだよね」という時に、それが解決可能かどうかを調べて、こういうふうにすれば解決できるんじゃないかと考えることと、それを実際にコードを書いて、プログラムにしてお客さんに届けることは、大きく違うなと思っています。

前者は企画職のようにも見えますが、「プロトタイプを作って動くものを見せながらお客さんと対話する」ことはエンジニアにしかできない企画の手法だと思います

この2つ、どちらかに絞ってもいいと思いますし、僕は両方ともやりたいと思っています。もともと後者のプログラムを書くほうが好きで、問題を分解して「こんなことをしたい」と言う人たちのものをどう形にするかという、エンジニア力は僕はもともと強かったんですが、そうじゃなくて、もう1つ手前の、課題を認識して解決可能な形に分解するというところをがんばっている感じです。

ーー「課題を見つけて分解する力」と「実際にコードを書いて解決する力」、エンジニア力が2つあると思った経緯を教えてください。

増井：「プロダクトを作る」という視点をエンジニアから見た時、「製品のためのコードを書くこと」が主になりがちですが、「広い視野」を作るためにもエンジニアの能力が大事だと思い、この2つを分けて考えるようになりました。

先ほど、補聴器を作り始めたとお話ししましたが、これはうちの婆ちゃんに使ってもらうために作り始めたもので現時点で市販しようとは思ってはいません。

なので、このプロダクトは、婆ちゃんの問題を一定解決ができるかもしれませんが、これが仕事だとして、スケールして売上を作っていって会社を大きくしていくということが目標になってくると、状況は変わってきます。今回、補聴器や老人性難聴についてはけっこう調べたので、ある程度理解しているつもりですが、僕が知っていることは世界のうちのごくわずかなんですよ。

例えば、日本語話者の難聴と英語話者の難聴は少し違うんですよ。英語話者については調べたから知っているけど、「フランス語、中国語はどうなの？　人口が多いインドと中国の難聴はどうなの？」というと、僕はまったく知らないわけです。

最初の段階では、実は自分が思っているより狭い世界のことしか見えていないことが多いんですよ。僕の場合でいうと、婆ちゃんのことしか見えていないわけですよね。

せっかく作ったものを広い世界に届けたいのであれば、やはり広い視野が必要で、その必要性を感じることが仕事上けっこうあったんですね。最初に気づいた課題や解決方法って、大きな問題を解決できるように思えるけれど、案外自分の見えている狭い世界だけの解決方法だったりするんですよね。自分の初期の視点を過大評価しちゃうことってよくあるので。

スタートアップで、一番初めにプロダクトを出して一定まで伸びるんだけど踊り場に行って、そこから成長に悩む会社が多いのも、たぶん同じような感じで。初めに想定したユーザーには届いたけれど、意外に狭い世界しか見えてなかったということだと思います。プロダクトが日本中、世界中で使われるようになるには広い視野が必要で、それを知るための手法がマーケティングだと思っています。そしてそれをエンジニアバックグラウンドがある人間がやることには意味があるんじゃないかと感じています。

顕在化していない課題を見つけるのは本当に難しい

ーーちなみに、今までエンジニアとしてエンジニア力の不足が原因で失敗したことはありますか？

増井：コードを書いてプロダクトを作るということ自体は、正直、僕1人でもけっこうできるんですよ。でも、それを多くの人に使ってもらって、多くの人の課題を解決するということは僕1人では難しいんです。

モノを作ることはできるけど、課題の大きさを考えたり、プロダクトをお客さんに届けてその価値を理解してもらったり、もしくはお客さんが理解ができるようなプロダクトを作ったり、というところから僕はけっこう逃げて他の人に任せていたんです。だけど、「わかる人が使ってくれればいい」「プロダクトオーナーと呼ばれる別の人が考えてくれればいい」となっていたところから、もう少し視野を広げたプロダクトを作りたいと、どんどん思うようになっていったんですね。

ーー今お話しいただいた、不足していたエンジニア力は「課題を見つけて分解する力」のほうだと思いますが、このエンジニア力を高めるのは、難しいですか？

増井：そうですね。「課題を見つける」というところでいうと、課題には顕在的なものと潜在的なものがあって、顕在化していない課題を見つけるのは、本当に難しいなと思います。本人たちに直接「今、生活の中でなにか困っていることはありますか？」とか「今、仕事上で一番困っていることはなんですか？」と聞いても、あまり出てこない、もしくは無理なことしか出てこない。

なので、本人から聞くだけじゃなくて、アイデアを出して、「例えば、これとこれとこれがあるとしたらどれが欲しいですか？」と聞くことで「あっ、これが欲しかったんだよね」みたいな話を聞き出したり。それこそ統計を取って、ユーザーの滞在時間がやたら長い、やたら短いところになにか課題があるんじゃないかと仮説を持って考えたり……仮説をきちんと立てるというのは、よく言われることなんですが、解決方法が検討もつかないと仮説が立たないんですよ。

ここはエンジニアがすごく活きるところで、まったく解決不可能なことの仮説を立てても仕方がないわけですよね。「四次元ポケットがあったら」という仮説を立てたところであまり意味がないんです。

AI絡みでいうと、「ChatGPT」とか、言語処理とか画像の自動生成とかがここ半年ぐらいですごく伸びたわけですよ。あれができるかできないかで、アイデアの幅はすごく変わるんですね。

例えば、「ChatGPT」が、本当に人間が話すのと区別がつかないレベルで一般的な質問と答えができるようになったら、それをアイデアの1つとして、こういう方法で解決できるんじゃないかとか、アイデアが出せるようになるかもしれません。画像も、テキストから絵で表示できるようになって、言葉での説明をやめて絵で表示するというアイデアが出せたりするかもしれません。

お客さんの課題をただ聞いてもダメで、アイデアを出して、それに対して評価してもらう。そして、そのアイデアを出すためには、エンジニア力がないといけない。荒唐無稽なアイデアを評価してもらって、四次元ポケットを作るためにそこからがんばるという方法もありますが、それではあまりにも遠いので、僕はエンジニア力をうまく活かしながら課題を認識するということに自分を使えたらなと思っています。

ーー「課題を見つけて分解する力」と「実際にコードを書いて解決する力」、2つのエンジニア力を高めるために、増井さんが今までやってきたことを教えてください。

増井：コードを書いて解決する力は、狭い意味でのエンジニア力なので、それこそコードを書くとか、いろいろな方法論や開発の回し方を本から学ぶとか、勉強していく方法はたくさんあると思います。

ただ、課題を見つけて課題を処理可能なかたちに分解する力は、これといって決まった手法はいまだにないんですよね。

いろいろな手法があって、僕は人と話す、人から話を聞くことはすごく大事だと思っています。僕は話すことがそもそもすごく好きなので、今日もこうやって話をしているんですが、ただ、言い方を悪くすると、僕は今までどちらかというと自分の意見を押しつけるために話すことが多かったんですよ。

僕は、プレゼンテーション的に話すのはそこそこうまくできるので、人の心を変えるために話すことが多かったんですが、人の話を聞くために話すのが大事だなと、ここ5年ぐらいはけっこう思っていますね。

就労年数に合った能力を身につけていることが求められている

ーー年代によって必要となるエンジニア力は変わっていくものですか？

増井：年齢によってやることはそんなに変わるわけではないですが、一緒に仕事をする人として、プラスマイナス10歳ぐらいを選ぶ人が多い気がするんですよ。

例えば、フリーランスで50歳過ぎてくると仕事が減ってくるという話を前に聞いたことがあるんですよ。それはどうしてかというと、だいたいプロジェクトのリーダーや決裁権を持っている人は、30歳後半から40歳ぐらいの人が多くて、プラマイ10歳ぐらいの人を選ぶことが多い気がするんですね。となると、40歳のプロジェクトリーダーが選ぶのは、50歳から30歳の幅になるんですよ。

なので、年を取ると仕事が取りにくくなるというのはたぶん一定あって、技術というよりは、選ばれる年齢によるのが多いんだろうなと僕は勝手に思っています。

ただ、エンジニアとして20歳でも40歳でも求められることは違うけれど、やはり経験年数が多くなっていく中で、40歳のジュニアというのはなかなか受け入れられにくいでしょうし、就労年数に合わせてそれなりに成長していることは求められると思います。

10年やった人と3年やった人の能力が同じぐらいだったら、たぶん3年の人を採ると思います。なので、年齢というよりは、その人の学習能力を見るという意味で、就労の長さによって、それなりに能力を身につけているかを求められるとは思いますね。

セカンドキャリアとしてエンジニアを目指す人が意識しておきたいこと

ーー今は、プログラミング教室とかノーコードとかがけっこう賑わってきていて、セカンドキャリアとして例えば、30代半ばでエンジニアを目指す、という人も一定数増えていると思いますが、学習能力というところを考えると、なかなか厳しいのでしょうか？

増井：いや、その場合にはたぶん求められるものが違うんだと思います。例えば新卒でエンジニアとして入った人は、最初は経理のことをまったく知らないわけですよね。

でも、経理畑の人がプログラムの能力を身につけると、少なくとも経理全般を理解しているので、逆にそちらを強く求められて、コードとしてきれいに書けるということよりも、経理の人が本当に使いやすいアプリケーションをどう作るかとか、そういった部分が強く評価されるんだと思います。

ーーなるほど。今まで自分が培ってきたドメイン理解、プラス技術力で評価されるんですね。

増井：そうですね。「Excel」のマクロとか「Google Apps Script」とか、自動化のためのプログラミング言語ってあるじゃないですか。

例えば経理の人がそれを学べば、プログラムも書けるけど、今やっている経理の仕事が楽になる。両方できるとなった時に、プログラムを書くために経理の知識を使うのか、経理のことを便利にするためにプログラムの知識を使うのか、どちらに主軸を置くのかという問題が出てくると思います。

僕は、ドメインナレッジに強い人が、プログラムを書けたり、理解できたりすることで、技術者に対して、課題を分解して仕事をお願いができたりするのですごく有用なんじゃないかなと思います。

エンジニア力を高めるために増井氏が大事だと思っている2つのこと

ーーエンジニア力を高めたいと思っている人にアドバイスをお願いします。

増井：僕は、「勉強をすることを億劫にしない」と「遡ってきちんと基礎から勉強する」ということが大事だなと思っています。メトロノームみたいなものですよね。

メトロノームって、当たり前ですが、目立つのは見えている振り子の部分なんですよね。支点より上のほうは大きく振れるから派手に見えます。だけど、支点から下は上の部分よりは大きく振れないから目立たない。

例えば、機械学習であれば、支点に近い部分というのは数学になるんですよね。化粧品でいうと、肌に関する科学や薬剤に対する科学。もちろん新しい発見はあるにしろ、基礎はあまり変わらないわけですよ。そういう基礎の部分をきちんと押さえるのは、大事だなと思います。

例えばプログラムをやっているのであれば、プログラム言語についてきちんと仕様や教科書的な本を読む。プログラムの変数とかオブジェクトとか、基本的な言語仕様とかフレームワークの内容とかは、仕事ではなかなか学ぶ機会がないんですよね。なので、別の時間を確保してやはり基礎的なこと、俗にいうコンピューターサイエンスに近いことを勉強する必要があると思います。

さっきお話ししたメトロノームの根のほうを押さえるのは大事で、アプリケーションとかフレームワークとかライブラリの使い方とかをやっている限り、その都度新しいことを覚える必要があるけれど、普遍的なことについてはある程度勉強しておく必要は、一貫してあるなと僕は思っています。