現場で伸びるエンジニアの特徴とその育て方

「現場で伸びるエンジニアの特徴とその育て方」というテーマで、エンジニアを育成するプログラミングスクールディープロ代表の野呂と、採用経験を多くお持ちのスナップマート株式会社の取締役CTOの星 直史様がお話します。

現場で伸びるエンジニアとはどのような人を言うのでしょうか？エンジニアが伸びるために必要な環境や条件はあるのでしょうか？エンジニアとして働かれている人にとっても、採用担当者にとっても、興味深いテーマだと思います。
今回は、「現場で伸びるエンジニアの特徴とその育て方」というテーマで、エンジニアを育成するプログラミングスクールディープロ代表の野呂と、採用経験を多くお持ちのスナップマート株式会社の取締役CTOの星 直史様がお話します。

【こんな方におすすめ】
・現場での成長の仕方がわからない方
・どのようなエンジニアが伸びるのか知りたい方
・エンジニアの育て方や伸ばし方を知りたい方

【目次】
1．根底にあるのは「思考持久力」
2．意図的なキャリア形成と偶発的キャリア形成がある中で、どのように仕事に向き合うか
3．環境は必ずしも重要ではない
4．まとめ

■話し手
ディープロ 代表 野呂 浩良
スナップマート株式会社 取締役CTO 星 直史様

根底にあるのは「思考持久力」

今回は「現場で伸びるエンジニアの特徴とその育て方」について、お話します。
まず特徴からいくと、ベーシックな部分では「自分の頭で考える」が1番その根底にあるのかなと思います。あとは、その中で「なぜという問いを続けられる」「問いを立てられる」といった「思考持久力」の話になります。

「思考持久力」ですね。

そうですね。
「なんで？」に対する答えを1回得て満足してしまうよりは、「その答えって本当に合っているの？」と、また「なんで？」というところをどんどん掘り下げていくことができるのが特徴だと思っています。そうすると、自分がやっている物事の意義を自分で見つけたり、そもそもその問題解決の質の精度が高まったりします。あとはキャリアにおいてもそうですね。「自分はどういうキャリアを描けば良いんだろうか」「なんでエンジニアなんだっけ？」というところに関わってくると思います。問いを立て、常に考え続けるところですね。

私はこのディープロを作ってから、授業をずっと担当していたんですね。受講生さんを拝見する中で「この方ってすごく伸びそうだな」とか「この方は少し思考を変えていかないと、伸びが止まってしまうんじゃないかな」と感じることがありました。
今のお話の中でも「思考の持久力」や「なんで？」と考えるといったお話が出ましたが、授業をしていても、その授業を吸収する度合いや、自分から質問をするか、与えられた授業でのワークに対してどれくらいのスピードで取り組むか、全員でワークしたときにそこから学んだことを自分からアウトプットしようとするかなど、その辺はかなり如実に出ます。
ただこれは、スクールに入校した時点でそういった特徴がすでにあったとも言えますし、受講の過程で培うことができれば、とても価値のあることだなと思ってずっと運営をしてきました。

ここで非常に難しいのが、後天的に発達させる能力としては難易度が高いのかなとは思っています。
採用する立場からすると、採用面接の段階で思考持久力があるかを判断しています。とは言え、「思考持久力がないと無理なんだ」という話ではないとも思っています。「思考の持久力」などを後天的に発達させる方法は今もピクスタ株式会社の方では模索しているのですが、若手のメンバーや20代中盤くらいのポテンシャルメンバーを対象に「ロジカルシンキング」を取り入れています。バーバラ・ミントの「考える技術・書く技術」という本が結構有名ですね。

白い表紙の本ですよね。私も買ったことがあります。

理解と実践が大事ですので、読書会のような取り組みをしています。「まずはそのバーバラ・ミントの厚い本を理解しましょう」と、2週間かけて全員でその本を読むという内容です。毎日実施するのですが、その勉強会に来た時点で「もう読んでいる」という前提で「どう思った？」ということをディスカッションしています。それが理解です。実践の方は、そのワークブックというのが別に上下巻ありますので、それを3か月かけてみっちりやっています。

3ヶ月ですか…。

そうです。2週間に1回、勉強会をします。その2週間で1章から2章ずつ取り上げて、自分の中でロジックを組み立てるんです。それを皆で持ち寄って批評会を行い、実践と理解をより深め、全部で3ヶ月半ほどかけて若手メンバーに実施しています。
業務でやり取りをしながら、「能力の開発が必要だな」というふうになったら、そこで「ちょっとやってみない？」と取り入れている感じですね。

そうなんですね。
先程の、「なかなか後天的に…」というところに、私は1番興味があります。
2019年の夏頃に「教育格差」という単行本が出たんです。教育の効果を統計的に見たという内容で、すごく平たく言うと、「0歳から3歳までにいろいろな言葉のインプットがあったかどうか、そこの思考を巡らせたかどうかで、すべてが決まる」といった統計結果になっているそうです。比較だけするとそういう主張なのですが、私は「家庭環境やその時の環境ですべてが決まる」となると、「人生おもしろくないな」と思うんですね。私は「人の可能性は無限大だ」と信じたいタイプなので。

だから、そうではないという領域やチャンスをつかめるような機会をつくりたいなと思ってこのスクールを作ったんです。やはり星さんの仰るとおり、論理的思考力や「思考の持久力」といったものはすごく重要だと思っています。一方で、エンジニアを目指したいという局面では、なかなか思考力の方から入るのには「わかりにくさ」があります。皆、興味があるのは、モノを作ることやプログラミングの方なんですよね。かつ、それを知っていないと、そもそもその世界自体がわからなくなってしまいます。そのため、私たちはまずはプログラミングに触れていくところから始めています。

そういった順番について、星さんの中では「まずプログラミングをしてから思考力」とか「思考力を磨いてからプログラミングを本来やるべきではないか」とか、何かご意見はありますか？今のお立場としては、思考力かもしれませんが…。

実際のところメンバーを育成するときに、「次の成長課題はこれ」という点について知っているメンターから見ると、「あ、これを先にした方が良い」ということはよく感じます。実際の現場では、当の本人が問題だという認識をしていないと、そもそも学習する意欲がわかずに吸収力も低くなってしまいます。途中で止めてしまうこともあります。

今のお話に照らし合わせると、やはり汎用的でビジネスにおけるロジックの部分を学習するということは、知っている身からすると、そっちの方が良いのではと思います。他に適用できますしね。どちらが正解というのはないのですが、基本的には必要です。意義を見いだせるものから行った方が良いんじゃないかなと思います。

意図的なキャリア形成と偶発的キャリア形成がある中で、どのように仕事に向き合うか

エンジニアを目指されている方には、エンジニアに興味を持ったり、「今の仕事ではなく、より自己決定権のある人生を」というような言葉の中から「こういう道を歩みたい」と思っていらっしゃる方が多いです。そこで、「じゃあそれって一体、何で解決できるんだっけ？」とか「そもそもなんでエンジニアなんだっけ？」といった「なぜ」の部分をしっかりとご自分で定義して、「それを解決するためにこれを学ぼう」とか「こっちを鍛えよう」といった繋がりの強化が重要になりますね。

これまた難しいテーマですが…最初から定義できるかどうかというと、決してそうではないと思っています。とは言え、「問題を解決するためにはエンジニアだ」という何かしらの仮説については、それはそれで飛び込んで良いと思うんです。実行が伴っていないと何も成功しません。「できるかどうか」より「やるかどうか」だと思いますね。

仮説で飛び込んだ先にまず私がいて、そこから卒業して星さんのところに…という時系列のつながりが今起きていますね。もともと今回のテーマが「現場で伸びるエンジニアの特徴とその育て方」ですので、キャリア形成とか仕事のスタンスについても触れたいです。
まず、エンジニアになるために仮説でプログラミングスクールに飛び込んでみたとします。その中で問題を定義したり、問題解決のために自分自身に知識を入れるということが、ある程度わかってきました。それでもまだ十分じゃない状態というのがあって、おそらくそれで「思考の持久力」というところを鍛えられると私は思っています。そのイメージで合っていますか？

そうですね。

そのときに、キャリア形成という観点と仕事のスタンスという意味で、スクールに通われる方の中には「1年生にとりあえずなる、まずはなれば後はなんとかなる」という方がすごく多いです。「まずはなっちゃえばなんとかなるんじゃないか」「後のことはその後に考えよう」といって、例えば1年後に、まだあまり実力が高まっていないのにフリーランスに憧れて、すぐパッとなってしまうケースや、または、「まだ未熟なのになぜ？」という時期に育成してくれた企業さんに決別するというケースも少なからず見聞きします。そういうことを見ると、キャリア形成という観点を、私たち自身もかなり把握した上で伝える必要があると思っています。

星さんの中では、まずそのキャリア形成の観点では、どのようなイメージなのでしょうか？

私が実践している方法をお話しますね。
やはりキャリア形成って、若手のときとか、すごく悩むじゃないですか。「どうすればいいんだろう」と考えたときに、考え方が2つあります。ひとつは意図的なキャリア形成の戦略、もうひとつは偶発的なキャリア形成です。

意図的なものに関しては、「エンジニアになりたい。そのためにはどうすればいいのか？」というのをブレイクダウンして、それを習得していけば、単純に線形に伸びていくわけですよね。その中でキャリアが形成されるというのが、まずひとつの考え方です。そのメリットは、理想の状態に最短距離で到達できること。デメリットに関しては、その到達点に固執してしまうあまりに、他のことが見れなくなることです。要は、チャンスをチャンスと思わなくなってしまうという点で、ひとつデメリットとしてあるのかなとは思っています。

「チャンスをチャンスとして見れなくなる」ってことですね。

そうです。なので他の人から見たら「チャンスじゃん！」って見えているのかもしれないけど、自分からしたら「俺の道あるから」みたいな感じで、プイッと捨ててしまう可能性があります。

たとえば、「こんなスキルも付くし、こういう分野でも役に立つから、こっちの仕事もやってみない？」というときがあっても「いや、それは俺は今は必要じゃないから」「違うものをやりたいから」と切り捨ててしまうイメージですかね。

機会損失と言ったら良いのかわからないですけど、遠回りすることで得られるモノってありますよね。それが得られなくなってしまうという観点から、デメリットのひとつではあります。

イメージつきます。ありがとうございます。で、もうひとつが偶発的な…ですかね。

そうですね。
これは意図的な戦略とは別のお話なのですが、「やってみない？」と言われたことに対して、「実際どこに結びつくかはわからないけど、とりあえずやってみよう。そこで得られるモノもあるんじゃないか」という判断を試験的に実行することで、もし得られるモノがあったのなら、そこから方向修正することもできますし、単純にスキルやキャリアの幅が広がることもあります。基本的には意図的戦略があった上で、その補助として偶発的な戦略を持ってくるというのが、ちょっと抽象的なのですが、キャリア形成の戦略かなと思います。

キャリアの大枠をまずは意図的に作って、そこからの道のりで、偶発性もあった上でやっていくと、何かしら深みがある人になりそうですね。いろいろなことを知っている状態でだんだん育っていって、さまざまなことを任せられる人になりそうだなって、今思いました。

一方でエンジニアの職業は、今は非常に開発案件が多かったり、声がかかるケースが多いのですが、他の職種よりも割とスキルベースで判断されやすいです。お金にも、換金価値というか、しやすさがあるなと思っています。いろいろな誘惑や、「そこまで偶発性を求めなくても」というご意見もあるかもしれません。働き方自体もリモートワーク・副業・フリーランスなどいろいろあります。そういう、ある意味での誘惑や選択肢が多い場合に、つい「年収」とかわかりやすい方にいってしまう人も多いんじゃないかなと、ちょっと感じています。

そういう場合、ご本人にとってその都度は良くても、後々、何かにハマってしまったり、いわゆるデッドロック状態になってしまうことってあるものなのでしょうか？

私はあるかなと思っています。要は動機付け要因と衛生要因だと思っています。基本、年収は衛生要因に入ると思いますが、もし年収が1番の目的だとするのであれば、それは近視眼的な視点だなと思っています。どちらが良い悪いというお話ではありませんが。

そうですよね。それは価値観によってまた変わりますからね。

どちらかというと、なりたい姿をイメージして、そのためにスキルを習得していくと、年収はついてきます。私自身は「年収にフォーカスするのはどうかな？」と思っています。なので「どうあるべきか」とか「どうなりたいのか」っていうところをベースに考えて、行動や意思決定をするのが良いかなと思います。

そういうときに仕事のスタンスについては、「意図的にキャリアを描く」と「偶発的なものを持つ」の双方を持っていれば、割と目の前のことに対してしっかりと自分事に捉えられそうな気がします。偶発性が強すぎても良くないでしょうし、きっと意図が強すぎても、技術が身に付くからという観点で語られがちな気がしますが、そこがすごく難しいと思っています。

例えばスクールですと、「今はRubyを学習しているし、このRubyが使えなきゃいやだ！」といったスタンスもある気がするんですよね。意図的に「Rubyのエンジニアとしてやっていくぞ！」とか、「そうじゃないインフラ系からだったら、ちょっといやだな」とか。一理あるかもしれませんが、「でも偶発性とは、どの程度までが許容範囲なのか」というのも、なかなか未経験からするとわからなかったりしますよね。星さんの中では、せめて「こういう範囲であれば汎用的だ」とか「もしRubyとして、Rubyの世界でどっぷりだったらこういうの！」など何かありますか？「型」みたいなものとでも言いましょうか。

一般的な話ではありますが、毎年「Developer Roadmaps」というものが公開されます。「まず、フロントとバックエンドのどちらから入りましょうか」とか「バックエンドだったらこういうのも学んでいって、次はフロントやインフラに行こう」という具合に、1番基本的なところで一般的ではあるのが、そこを外さないようにする。やはり、局所的にお金になっても汎用的ではないところに向かうのではなく、市場のトレンドなどに合わせていくのは大事です。あとは自分の今の立ち位置ですかね。「そのロードマップ上のどこにいるのか？」ということを認識して、「今はここにいる」、何か違うものがきたときには「ロードマップ上で言うとここだから、次の役に立ちそう、だったら先にやっておこう」と意識するのは、ひとつの方法としてあるのかなと思いますね。

あとは、仕事のスタンスの軸でいうと、ガッツリ本気になって取り組まないとわからないこともあると思っています。例えば、「クラウドソーシングのサービスを使って、とある特定のサービスを作ってください」という依頼があり、それを作ったとします。そして「はい、納品して終了」となります。一方、「自社のサービスを作ってね」と言われて作ったときには、運用が絡んできたり、不具合などがあったときに自分で対応しないといけなくなります。そのコミットの仕方は、考えた方が良いですね。そこも自分のスキル習得に影響がある範囲なのかなとは思いますね。

今思い浮かんだのは、私が昔、業務システムのパッケージの開発会社にいたときに、運用保守の部分のシステムエンジニアの仕事をしていた頃のことです。仕事で得られる計画的なモノももちろんあったのですが、偶発的に「これをしないとお客様の業務が回らない」とか「止まっちゃう」など、それを解消するために人力で何とかするという対応をしょっちゅうしていました。そうなると、極限に追い込まれた状況で、ものすごくキャッチアップするんですよね。必死になって「よしできた！」というあの時の快感を、ずっと覚えています。困難があっても興奮するようになるんですよね。当時は「だいぶ染まったな」と思ったものですが、でもやはりそのブレイクスルーする感じが、自己成長というか「もっと学びたい」という自信につながる気がします。

そうですね。全能感はひとつあるかなと思います。あとは達成感とかですかね。
「自分だったらできる！」という感覚は、必要とまでは言いませんが、あったらなお良いのかなと思っています。今、野呂さんのお話を聞いていて、自分もそういう経験があることを思い出しました。「いつまでにしなきゃいけない」という期限付きのモノが「締切まであと6時間です！」という状況で、全然できていないときには、よくエンジニアのプライドを捨てていました…。

プライドを捨てる…？

そうです。プログラミングで解決するよりも、手作業でやった方が速いんだけど、システムの調査が必要といった場合に、小さいせめぎあいがありました。すごく若いときなんですけど、「エンジニアだからプログラムで解決したい！」でも「時間が迫ってるじゃん！」となったときに「プライドを捨てよう」と手作業で一生懸命作業した…という経験がありますね。請求書のシステムなどで、プログラムで請求書を一括で出力することもできるけど、例えば、Wordで印刷した請求書に手書きで請求金額を書いてハンコを押しまくることで、まあまあ解決できることもあるじゃないですか。そういう「追い込まれたときにどうやって解決するのか？」といった論点はありますね。ちょっと話がずれてしまいましたが。

いえ、ありがとうございます。
でもそういった「意図的に常に安定して常に予定調和で何かスキルを得る」というよりも、むしろ偶発的にした時に、今まで使っていなかったような優先順位付けの判断や、「そもそも何を目的に？」というところに立ち返ることができるのかなと、今思いました。

そうですね。

そこから、ステップ・バイ・ステップでシステム化していく。そして、そういったことを知っているがゆえに、システム化する優先順位が決まったり、運用との整合性を取ったりしていく…といったこともありそうですね！

そうですね。「なんで作るんだ？」という問いは、そうしてできるようになりました。「作る必要がないのではないか？」と疑問を持つんです。

環境は必ずしも重要ではない

最後に少し触れたいのが、環境のお話です。
キャリア形成や仕事のスタンスといったときに、就職する会社によって環境が全然違うと感じています。例えば、弊社ディープロもそうだったのですが、初めてエンジニアが入社したとき、弊社には最初からCTOがいたわけではありません。最初は新人のエンジニアがひとりの状態から始まったんですよ。そうなると「誰から学ぶの？」といった問題が生じます。私たちはプログラミングスクールだからまだ良いですが、それでもやはり、スクールで教えられる範囲と、その後現場で学んでいくスタンスは、少し違うと感じています。そのため、最初の頃はそこのギャップの部分を業務委託の方にお願いして、週1回必ずみっちりとマンツーマンでQ＆Aをしていただき、そこから個別の問題解決をしていただくところからスタートしたんです。会社さんによっては本当にエンジニアがひとりだったり、周りにエンジニアがいたりと、全然、環境が違います。

そんなときに、それぞれの場合にわけて、「こんなスタンスで臨むといいよ」といったアドバイスはありますか？あるいは、何かそういったエピソードを聞かれたり、聞いた時に思われたことなどはありますか？

正直なところ、私は環境はどこでもいいのかなと思っています。仕事って実践の場じゃないですか。というか本番じゃないですか。自己研鑽は自分の時間を使って学べばいいので、そこは環境じゃないかなと思っているんですよ。
よく、「マネージャーになると技術力とかは少なくなってしまうんじゃないか」などと話す人もいますが、そんな訳はないです。私はピクスタ株式会社で部長をしていて、「仕事で直接手を動かすことは今後はあまりない」という状況でしたが、技術力という観点では、若手のエンジニアやリーダー層にも負けていないと自負しています。それは自己研鑽で補っているからです。だから環境は別に関係ないんじゃないかとは思います。これは個人的に考えていることです。

ただ、一般的に話すのであれば、やはりエンジニア業界は大きくわけて受託の会社と自社サービスを運営している事業会社がありますが、受託の会社だとやはり知識を広げやすいです。手持ちのカードはすごく増えるとは思います。自社サービスの会社になると、運用とかも絡んできますので、深みが増すのかなと思いますね。自社サービスの会社でコロコロと開発言語を変えるようなことは、大規模な会社では本当にないことなので。例えば、特定のRubyだったら、「バージョンを4系から5系に上げます」とか「そこからRubyを使って新しい機能を作ります」といった流れになるので、技術の範囲は受託の方と比べると狭まりますが、深くは追求できると思います。

最初の頃ってなかなかそういったことをうまく解釈できないんですよね。どうしても隣の芝は青く見えるというか、「あそこの会社にはこんな環境があって…」とか、自社の中で「そうはいっても…」とわからないものだらけだったりすると、特に起こりがちな気がします。本人というよりは、周りの上司やビジネスサイドの企画をする側の方たち、CEOとかに対して、「どんなふうに接してあげるとより伸びそうか」といったご意見や思いはありますか？あるいは開発部長のときに、「こんなふうに心がけていた」となどのアドバイスはありますでしょうか？

そうですね…。そこはずっと問いかけです。さっきの話でロジカルシンキングの話が出ましたけど、内省習慣も意図的に取り組んでいました。

内省習慣…？

そうですね。1on1をやっています。内容は、コルブの「経験学習モデル」というのがあり、それを基にして行なっています。「学習におけるパターンは、経験から学習、他人から学ぶ、自分で学ぶ」ことです。また、「経験から学ぶ」というのは、大人の学習パターンとして大部分を占めます。そして、この経験学習のモデルを使った1on1では、「経験学習のサイクルを回していきましょう。でも上司は答えを言わない」といった感じで、メンバーが、具体的な経験や思っていることを自分の中で問いかけ、内省して、「その結果どうだったのか？」をどんどん回していくんです。基本的には上司としては「傾聴」と「促し」のスタンスに徹します。

意図的に”How”を言うのではなく、経験の中から「そういうシーンではこう考えた」といった経験のシェアに近いのでしょうか？

そうですね…どちらかと言うと、「なぜそう思ったの？」などずっと問いかけをする感じです。
例えば、プロジェクトが成功したら、「なぜ成功したと思うの？」とかずっと問いかける感じですね。すると「ハッ！」となる瞬間がやはり多いですね。

そうですか…。ではきっと、問いかけだけではなく、問いかける背景とか、自分の経験を時々交えながら伝えると、気付きが生まれたりするのかもしれませんね。

自分が知っていることを直接言うのではなく、自分が知っている成功パターンに寄せるために、思考を促進させるというイメージです。

そうしますと、やはり、「その方自身がすべてを自分で判断し、自分の範囲内で、自分の殻に閉じて判断する・学ぶ」のではなく、「周りを通して一緒に、時には引き出してもらう」といった心持ちなどが大事なのかもしれませんね。いわゆるエンジニアの人数とか体制とかは抜きにして、「ビジネスに対してどう向き合うか？」というところなのかなと今思いました。
今回お伺いしたのが、「現場で伸びるエンジニアの特徴とその育て方」、そしてキャリア形成や仕事のスタンスに関するお話でしたが、いろいろなお話が出てきて、とても刺激的でした。ありがとうございました。

ありがとうございました。

まとめ

・根底にあるのは「思考持久力」。ビジネスにおけるロジックの部分を学習するのはおすすめ。
・基本的には意図的戦略があった上で、その補助として偶発的な戦略を積み重ねていくのが戦略として良いと考えられる。
・環境によって得られるものやできることは異なる。周りを通して一緒に、時には引き出してもらいながら、成功パターンに寄せるために、思考を促進させていく。

いかがでしたでしょうか？
「現場で伸びるエンジニアの特徴とその育て方」では、本人や周りにとって必要になりそうな思考やスタンスのお話がいろいろと出ました。ぜひ、日頃のお仕事の中で、考察されてみてください。

職場での成長関連記事 一覧

現場での成長に関しては、下記の記事もぜひご参照ください。

■「仕事ができる人とできない人の違いとは何か？」の記事はこちら

■「徹底討論！つまるところ『自走力』って何なの？」の記事はこちら

■「3年後、ありたい姿に到達するためのPDCAサイクル：①『ありたい姿』とPDCAサイクルとの関係」の記事はこちら

■「20代は成長を取るべきか、安定を取るべきか？」の記事はこちら