00:09
はい、みなさんこんにちは。kkeethことくわはらです。
本日もやっていきましょう、kkeethのエンジニア雑談チャンネルです。
この番組では、ウェブ業界に関することや、エンジニアリング、
いろんな技術についての雑談などの情報を
発信していきたいと思います。
今日はですね、何のネタにするかちょっと悩んだんですけど、
今日はエンジニアの適性みたいなところをちょっと考えようと思ってます。
僕が自分のキャリアをそういうふうに考えてて、
今後何したいかとか、自分が結局何に能力とか適性があるのか
みたいなところを考えてて、
僕自身がエンジニアにそもそも適性あったのかみたいなところも
何となく振り返りつつ、どういう人がエンジニア適性あるのかっていうのを
僕個人の考えで、喋っていきたいと思っておりますと。
そもそも僕はやっぱり、エンジニアの人生も長かったんですけど、
エンジニアとしての人生は、でも、言うて、
社会人になって今11年目?ですけど、
いや、適性あったかってわからないですね。
エンジニア人生、確か6年か7年ぐらいですね。
マネジメントが4年とか5年とかなので、
実は半分ぐらいは僕、リーダーシップとか
マネジメントをすることの方が結局多かったですね。
プレイングマネージャーとして、行動を書きつつ
マネジメントをするってことは全然してきたんですけど、
そういう意味でいくと、エンジニアの方が多分長いかもしれないですけど、
マネジメント業もやったって意味だと、
社会人人生の半分は占めているのかなってところですね。
今の会社も6年と2ヶ月いますけど、
そのうちの2年半はチャレンジ取締役ということで
取締役をさせていただいたっていうのがあって、
半分近くエンジニアじゃない仕事もしたりしてたので、
結果的には僕はエンジニアじゃない人生の方が多かったんですけど、
適性あったかどうかで言うと、
多分僕適性なかったと思ってます。
コード書くのはすごい好きだし、
どうせ土日もコードを書いてるんですけど、
自分の好きなことだけのコードを書いてるし、
言語も別に複数やったって言っても、
本当にプロとしてやったわけではないですしね。
一応仕事としてやったのはPHPとNode.jsと、
フロントエンド側のほうのJavaScriptと、
TypeScriptも若干やったのと、
全職一瞬Rubyやったんですよね。
仕事というよりも社内プロジェクト、
社内プロダクトとして手を挙げた有志の方たちで
プロダクトを作ってたんですけど、
その時に若干RubyとRailsやりましたね。
なんだっけ?
Webpackerが導入された初めてのバージョンだったような
記憶があります。
ところぐらいですかね。
あと他の言語は、
大学時代にC言語をやって、
Javaも必須であったんですけど、
Javaはそこの今参加してるTelephyさんに
単位を取ってもらったっていうぐらい、
僕はオブジェクト思考苦手だった。
全然分かってない。
社会人になって初めてオブジェクト思考を
多分理解したと思いますけど。
そもそもエンジニア適性あったかというと、
すごく怪しいんですけど、
コードを書いてでも物を作れるっていうのは
好きだったんですね。
そういう意味で、
好きかどうかっていうのは結構エンジニア適性の
僕は一つのポイントだと思いますね。
03:01
好きこそ物の上手なれみたいな
言葉はあるんですけど、
割とあれは真理だと思ってますね。
で、時間はかかるけど、
結構スキルが身について、
自分の楽しい人生をくれるとか、
物になるっていうのは、
多分好きで続くからだと思うし、
手を動かせるモチベーションが
続くからだと思ってるんですよね。
なのでそういう人は結果的には、
なんだかんだトップオブトップみたいに
なるわけじゃないと思いますけど、
自分が満足する、
自分が作りたいものを
自分で生み出すことができる
っていうようなスキルは身につくと思うんで、
そういう意味でエンジニア適性はあると思います。
趣味としてのエンジニアの適性っていうのだったら、
別に好きかどうかっていうのが
まず一つですね。
二つ目は、社会人人生、
社会人として、ちゃんとプロとして
エンジニアになりたいとかの話になってくると、
適性としては学習能力だと思いますね。
もう絶対的に学習能力。
これは伸ばすことができるんですよ。
学習能力っていうのは。
でも問題は、学習能力を伸ばすには
学習が必要っていうのが結構矛盾するんですけど、
学び方を学ぶことをしないと
自分の学習能力とか
自分の学習のペースとか
やり方みたいなのは身につかないので、
結果学びがスタートで
自分の学び方が確立していく
っていうところがあると思うんで、
それを身につけていくと。
あとは、なんで学習能力かっていうと、
エンジニア人生やっていくと、
プロダクト作っていくと、
行動を書くことがメインやることではあるんですよ。
結果的には行動を書くんですけど、
行動を書いていくとどうせバグったり
とか、正常系の機能を作ってるんですけど、
作るまではいろいろエラーが出たり、
それを直していって最終的に形になっていくと。
エラーとかログがいっぱい出てくるんですよね。
そのエラーログを見て、
これってなんだろうってちゃんと読んで、
どうせそれ英語なんですよ。
英語でそれを読んで、理解をして、
別に英語を理解できなかったら、
翻訳ツール今たくさんあるんでそこ投げていいんですけど、
とにかくエラーログを見て、それがなんだって理解して、
それの対策をどうしたらいいかって
考えられるかどうかっていうのが
基礎というか、根本的なとこなんですけど、
僕も経験何度かあったんですけど、
こんなエラーログ出たんですけど、
これどうしたらいいですかって質問してくる
若い子って本当にいたんですよね。
一回ググれよとか思うんですけど、
正直な話。でも、
聞いてくる子は本当にいて、
こういう子は多分適正ないだろうなと正直に思います。
自分でこう解決をするとか、
自分で調べて、
解決策どうなのかっていうのを
探っていくとか。
自分の中に答えがないから結局外に答えを求める。
だからググったりとか人に聞くんでしょうけど、
エラーが出たら
どうしたらいいですかを聞くのは、
そもそもそのワンステップ挟まない時点で、
エンジニア適正は多分ないと思いますので、
そういう人はやらないほうがいいと思います。
それも一つの学習ですよね。
出てきたアウトプットをちゃんと読んで理解するっていうのは
学習の一つだと思うので、
エンジニア適正の二つ目は
学習能力だと思ってます。
で、三つ目は何ですかね。
エンジニアの美徳の中の
堕落でしたっけ。
堕落じゃないな。何かあったりましたよね。
何だっけ、もう一個。三つ目のやつあるじゃないですか。
あれ、あれです。
あれは多分本当にそうやって思います。
で、堕落とか対万化忘れましたけど、
それを満たすために結果何かを
効率化したり自動化したり、
06:01
自分がやらなくていいようにするみたいなところがあると思うんですけど、
あれは結構僕
真実だと思ってて、
それの意味もあって僕はね、
あんまりエンジニアの適正はないと思ってます。
というのは、僕自動化効率化って最近気づいたんですけど、
好きじゃないなと思ったんですよね。
あんま感情が乗らなかったり、
楽をしたいっていう観点の方が皆さん強くて、
なんで楽したいのかっていうと、
自分が苦労したくないから。
楽すること自体は別に僕は
悪いとは思ってないですね。
その楽して、要は時間が生まれるわけですよね。
本来使わなくていい時間を
削るというか、
削減をして、
使うべきところにちゃんと時間を確保する。
そういう意味で自動化とか効率化をするとか、
まずビジネス観点で言うと、
毎日の工数が減れば減るほど、
生産性とか利益率が上がるわけですよね。
お金がはっきり言うと、
減るお金が減るので、結果的には
会社としてはペイするというのもあるので、
いろんな目的があって、
自動化効率化をするのがいいと思ってるんですけど、
ただ自動化とか効率化っていうのは
早い分、捨てやすかったり
抜けやすかったりするのはあると思うんですよね。
特に学びにおいては、
簡単に学べたとか、すごい効率よく
学べましたっていうものは、
すごい効率よく頭から抜けていくんですよね。
やらなくなった瞬間スパーンと抜けていくんで、
あんま身になってないと思うんですよね。
そのワンタイムで、その瞬間に
必要なスキルとか能力とか
知識が欲しくて、
その問題解決のためにそれを
効率よく学んで、使って
解決できました。じゃあもういいやって
言うんだったら、別に捨てていいんですけど、
そうじゃなくて、ちゃんと自分の身にしたいものを
効率よく学ぶのは、僕意外と
物にならないと思ってるんですよね。
それはいろんな、今までオトジックの
講師をやったりとか、今もプログラミングの
講師をしてますけど、
自分で物事を考えて、
ひねくりましたり、頭に汗をかいた
学生さんの方がやっぱ物になるし、
伸びてるなっていう感触があるので、
一定苦労は
ちゃんとした方がいいと思ってるんですよね。
でも本当にしなくていい苦労も
もちろんたくさんありますね。
タイマーは確かにエンジニアの適正な
一つではもちろんあるかなと思ってますね。
で、適正は
まあまあいいとして、でもエンジニアリングを
やってたり、いろんな物事を
作っていったりすると、結果
人と仕事、人と行動を
コードを書くとかあるじゃないですか、チームでコードを
書いたりするときとか、仕事上だと絶対
チームでコードを書くと思うんです。
絶対といってもたまに
本当に一人に全任されるときも
ゼロではないと思いますが、基本的には誰かと
仕事をすると。そうなってくると
エンジニアスキルの
上下とか優劣よりも
結局コミュニケーションスキルの方が高かった
高い方の方が結果バリュー
出すよねっていうことは結構あったりするわけですよ。
そうすると次はそこですよね。
エンジニア、職業エンジニアとか
職プロとしてのエンジニアとしての
適正な話が次に出てきて
それは本人がどこまで気にするかだとは
思うんですけど
結果でもほとんど誰かと何かを
作っていくなど必ずコミュニケーションスキルは
必須になってくると。
それは日常の、例えば朝会とかの
会議とかミーティングでの
話し方とか、伝わり方とか
逆に相手の言ったことをどう理解できるか
みたいなところもありますけど
09:01
あとなんだ、ドキュメンティエーション能力も
ありますし、あとなんだ
行動レビューですね。
とかの書き方もありますよね。
行動レビューは自分を棚に上げて行動レビューする
っていうのが大前提だったりするし
行動レビューするだけであって
人のそのものをレビューとか
指摘をするわけじゃないよっていうところですね。
これは行動レビューされる側のマインドセットも
あるかもしれないですね。
あくまで指摘されてるのは行動であって
あなた自身ではないよってところだったりしますね。
コミュニケーション能力は結構大事だと思いますね。
社会人になったら。
いわゆる出世とかしたい方は
上に行ってる確率は高いよねっていうのは
ちょっとありますけど。
チームでコードを書いていくときに
技術力の優劣っていうのは実はあんまり
寄与しないし、ビジネス観点でも
技術力がバカ高い人が
それはもちろんすごいコードか綺麗なコード
堅牢なコードを書いてくださるかもしれないですけど
ビジネスとしてお金を生むコードを書くのは
果たしてそういう人かどうかっていうと
また別の話ではありますね。
汚いコードを書いてもビジネスとして
お金を稼げるのは真実ではあります。
それがいいか悪いかっていうのは
また別の話だと思いますけど
ただまあエンジニアとしてお金を稼いで
いきたいんだったら一定数そういう
考え方はあると思いますね。
コードの綺麗さは別にユーザーとか
お客さんは別に求めてないんですよね。
プロダクトがちゃんと動くかどうかっていうのが
本当にそこしか見てないので
今後のこの保守性とか
拡張性を考えたらそれは綺麗なコードだったり
セキュリティ的なことを加味した
堅牢なコードを書いた方がいいのは
もちろんそれは正しいです。どっちも正しいんですけど
バランスをとってどっちが大事かっていうのは
あります。プロダクトとか
ビジネスの成功って結局早く出して
フィードバックを得てそれを早く
ブラッシュアップしていくっていう
何を投資するかですね。時間と人と
金の3つがありますけど
その投資をどこに分配をするかっていうのが
主案にかかってくるんで
そこはちょっとエンジニアと違う話ですけど
時間とかを効率化するときに
エンジニアリングはどこまで
エンジニアリングを突き詰めるかっていうのが別の話が出てきて
そういう
言語化しづらい、感覚値に近いとこ
あるんですけど、みたいなエンジニア的
性のスキルがある人の方が
社会人としてのエンジニアとしては
成功するんじゃないかなって思ってらっしゃいますね
はい
これは僕個人の考え方で皆さん一応
いろんな考え方あると思いますし物差しはあると思いますけど
はい、みたいなことをちょっと思ってました
結構学生さんと話す機会が
多くて、そういう系の質問は
結構されるんですよね。やっぱその
サッカーソンとかの審査員させて
いただくことが結構多いんですけど
なんかどういうプロダクト
つけてプロダクトするときに何を気にしたらいいですか
とか、どういうところを
いろんなことを考えて作ったらいいですかとか
どういうものを作ったらバズりますかとか
ユーザーが増えてくれると思いますかみたいな
結構お話があってくるんですけど、そこはもう
エンジニアの考え方じゃないんですよ、さっき言うと
外に目を向けてユーザーが
何を考えているかとか、もっと言うと
自分がそのプロダクトを使うときどう思います
とか、何が欲しいと思いますみたいな
ところからスタートすればいいと思うんで
そうするとエンジニアは関係ないかなと思ってらっしゃいます
とはいえ、エンジニアっていうのは基本的には
技術で物事、問題解決する人
問題解決かもしくは新しい世界観を
作りに行く人だと思っているので
一定数その考え方を
12:01
持ってやるのは本当にいいと思いますけど
何が言いたいか忘れましたけど
最近そういう質問をいっぱいいただくので
適正とかっていうのを今
語ってみたっていう感じですね
あといただく質問は何ですかね
学生のときに何をしたらいいですかとか
エンジニアの指定校
必読書は何ですかとかあるんですけど
最近は色んな方が毎年語っているので
それはもうそっちを読んでくださいに
尽きると思います
何十年も続いている名著と言われる書籍は
しっかりありますし
新しい書籍は新しい書籍で学ぶのは絶対いいと思うので
新旧どちらも読むのは
多分適正だと思いますけど
そういう意味で確かに
本を読めるかどうかって結構大事かもしれないですね
あと英語読めるかですかね
どんなライブラリとかフレームワークも
結局は全世界OSSの観点で
多分作られることが多いので
英語で書かれるんですよね
あとはコミュニティに入ったり
実際コミッターになったら絶対
コミュニケーションは必ず英語になるので
英語がどうしても苦手って人は
エンジニアは本当に向いてないと思うし
幸せになれないと思うので
エンジニアと仕事をするところに
身を置くか全然違う業界に行くのが
本当はいいかもしれないですね
別にそれが悪いわけじゃないですよ
ご自身の幸せのために選択をするだけにつきないと思いますけど
なんで書籍方という話をすると
僕も書籍書いたから
やっぱりつくづく痛感をしたんですけど
正しい情報というか
あの書くたる情報は
書籍から出ていることの方が圧倒的に多いなと思います
もちろんその
いろんなブログとかありまして
ギリュース記事とかあると思います
あちらもちゃんとレビューとか入って
公開されているものもありますけど
聞いたとか全とかあと個人が書いた
自分の中だけで閉じた情報で
記事としてアウトプットされていると思いますが
書籍はしっかり構成とかレビュアがしっかり入った上で
これで間違ってないよね
皆さんがこういう風に誤解されないかというと
かなり適正なレビューが入って
最後出されるので
やっぱ書籍は大事だし本を読める人ってのは
すごくネジには向いていると思います
はいというところで
今日よく喋ったんですけどこの辺で終わっていきたいと思います
じゃあ今日も一日ゆっくり休んでいきたいなと思います
じゃあ終了しますお疲れ様でした
