フロントエンドエンジニアの紹介
ken
はい、リスナーのみなさん、こんにちは。London Tech TalkのKen Wakatomoです。じゃあ、Kaz、今日もよろしくお願いします。
はい、よろしくお願いします。
いやー、今日スペシャルだね、なんかね、すごい盛り上がってる。すでにオフレコトークですごい、もう場が温まってる感じがあるんですけど、今日はゲストの方を2人お呼びしてます。
じゃあ、紹介しますね。じゃあ、NaoさんとArisaさん、今日はよろしくお願いします。
Arisa
よろしくお願いします。
Kazunari Okuda
お願いします。
ken
お願いします。
Arisa
今日は、何の話しようかなっていうと、そのフロントエンドの技術という言い訳をしつつ、ちょっとArisaさんとNaoさんを呼んで、4人で話したいという回ですね、今日は。
ありがとうございます。
ken
いやいや、どうしようかな、じゃあ、簡単に2人から自己紹介してもらいましょうかね。
Arisa
どっちからいきますか、じゃあNaoさんから。
譲り合い。
譲り合い、譲り合い。
Nao
じゃあ、いきますか。はい、皆さん、Naoです。初めまして、こんにちは。
えっと、そうですね、私はずっとエンジニアになってからフロントエンドがメインっていう感じ。
で、今の会社はOctopus Energyっていう会社で働いてるんですけど、ちょこっとバックエンド、グラフQLとかのところ、ちょっとインターフェースのところ、ちょっと触りにいくぐらいのことはしたり、あとコード自体はバックエンドのコードも読むっていう感じ、みたいな感じですかね。
ken
でもずっとフロントエンドです。よろしくお願いします。
じゃあ、Arisaさんお願いします。
Arisa
はい、そうですね、Arisaと言います。ドイツ在住で、最近までデブレルエンジニアをしてました。
そして、もしかするとじゃないかもなんですが、春からフロントエンドに戻って、フロントエンドエンジニアとして働く予定が立ちそうなので、
復刻ができるかもしれません。確定じゃないので、まだちょっと契約化はしてないので、なりましたとは言えないんですけれども、はい。
ken
それは嬉しいニュースですね。
Arisa
ありがとうございます。なので、そうですね、ローシュテック界の皆様に本当助けていただいたおかげもあるので、ロンドンテックトークでもうちょっと、
めっちゃ嬉しい。
少しだけ報告できて嬉しいです。
嬉しい、ありがとうございます。
なので、フロントエンドを主にやってきて、そういったスキルだとか、知識だとかっていうのを活かして活動してきています。
主に私はリアクト系のテクノロジーにこう、何て言うんですかね、長く携わっているので、
まあ、ネクストジェスターとか、あとリミックスとか、ちょっとリアクトじゃありませんけど、アストロとか、そんな辺に関しては、
ここ3年ぐらいですかね、の間で割とよく使っているので、経験があります。
あと、もともとGatsbyから入ったので、グラフQLとかその辺りも馴染みがあるかなという感じです。
ken
はい、よろしくお願いします。
そこら辺の技術すごい聞きたくて、今回の収録をやろうと思ったきっかけは、僕ずっとフロントエンドからやりたかったんですよ。
ああ、そうなんですね。
SREだけどフロントエンド技術好きでずっとやってたんだけど、なんか業務で使っている人を呼んで話したいなと思ってて、
で、この前アリサさんと別の、アリサさん2回目に来てくれたときのCAキャリア深掘り会の前後とかで、
フロントエンドをやりましょうって盛り上がって、じゃあちょっともう1人呼びましょうかってなったときに、
ロンドテックトークのコミュニティでもフロントエンド好きな人が何人かいるんだけど、
なおさん呼んでみようかってことになったんですよね。
ありがとうございます。嬉しい。
技術へのアプローチ
Nao
ずっとアリサさんは憧れだったので。
Arisa
それ多いです。
Nao
まさかの。
Arisa
いや本当嬉しかったです。
ken
どういうお気持ちなんですか?ずっと会いたかった有名人に会えたみたいな。
Nao
なんかそういう、ずっとか、めっちゃ、何て言うんですかね。
でもやっぱそのベンチマークっていうとちょっと言い方違う気がするんですけど、なんかずっと気になってる人とかっているじゃないですか。
なのでそういう感じかなって。
でやっぱりこう日本で女性でみたいな、デベロッパーでみたいな、あんまりそんなに発信しててっていう方ってそんなにたくさんいるわけではなかったりするし、
でそのエンジニアの仕事っていうのもそうですけど、ヨーロッパで暮らしてたりそういった暮らしぶりのことだったり、その考えとか、なんかそういうところを聞いててなんかすごい面白いなと思ってたっていうか。
ken
そういう感じでしたね。
興味持っていただけて嬉しいですし、なんか私ものすごい昔にやってたポッドキャストとかあって、それ聞いてくださってたっていうのが恥ずかしながらすごい嬉しいです。
なんかなおさんがアナニマスFM昔聞いてましたっていうのを、ローンテイクトークディスコで言ってくれて、僕も有栖さんのゲストに呼ぶときに、なんかこうやっぱ発信してることとかちゃんと聞いとこうと思って予習しようと思ったときに、なおさんが言ってたから聞いてみたんですよ。
Arisa
そうなんですか。めっちゃ駆け出しの何言いたいんだっていう感じですけど。
ken
いやでもなんかすごい、その一つのエピソードで印象に残ってるのが、そのカンファレンスに当時出られたんですよね。ギャッツビーカンファレンス2019かな。
Arisa
初めて出たときですね。
ken
初めて出たときにあたっての心情とか、カンファレンスのCFPトークを出すのはみんな出した方がいいよみたいな、前向きなマインドセットの発信とか、あと実際出てみてどうだったかみたいなのを出たときに、なんかすごい、なんだろう、そのカンファレンストーク絡みの話も今日はしても面白いかなと思ったんですけど。
そうですね。じゃあ2人がフロントエンドに入ったきっかけっていうのをちょっと聞いてみようかなと思います。
最初に使った技術が何で、なぜその技術を使ったか。それはたまたま最初に契約したり仕事で使ってるっていう偶然かもしれないし、自分で選んだのかもしれないし、トレーニング、例えばブートキャンプのコンテンツだったっていうのもあると思うんですけど。
で、それをやった後でじゃあなぜ引き続きフロントエンドに自分の、なんだろうね、やり続けてるのかみたいなところもちょっと合わせて聞いてみたいんですけど、ちょっと今回はじゃあアリッサさんから聞いてみようかなと思います。
Arisa
はい、そうですね。導入の部分としては専門スキルを何か身につけたくって、その前してたCAの職業は結構割とトレーニングをすればそれなりに割といろんな人が参入できるような分野だったんですけど、その入れ替わりも激しかったので、もうちょっと技術スキル的に重宝される役職に就きたいなと思って、
見つけたのがエンジニアで、その中でバックエンド、フロントエンドどっちにしようってなった時に、導入部分としてフロントエンドを進めてるところが多かったので、それで私はまずHTML、CSSから入って、すごく楽しかったので、実装したものが目に見えてできていくのが、それでJavaScriptに進んだ感じですね。
当時は2017年だったので、リアクトがもうそうですね、少しずつ日本のテイク界でも実用され始めたぐらいな感じ、でもまだまだJQueryとか主流で使ってる感じのところが割とあって、ワードプレスとかもまだまだ勢いがあったように私は思いますね、その時は。
やってたお仕事とかもフリーランスでやってたんですけど、割と私はフリーランスで仕事しながら実務経験を積んでっていう感じでやってて、お仕事もその時はワードプレスとかが多かったですね。それでPHPとかもワードプレスを触るレベルですけどやってて、
もうちょっとこうそうですね、モダンなアーキテクチャで開発したいなと思って調べてたところ、当時Gatsbyが割とまだ勢いがあって、ドキュメンテーションとかも割と充実してたので、それでそこから入り、
サーバーレースのファンクションだとか、そういうサーバーサイド系に少し関わるようになって、グラフQLもビルトインで入ってますから、Gatsbyの場合。
そこから少しずつAPIたたいて、データを設置してきて、クライアントサイドの方に反映させてということをするようになってから、ヘッドレスCMSあたりに興味を持ったりとか、クライアントに進めたりとかっていう風にするようになりましたね。
そこからリアクト系のフレームワークにどんどん移っていった感じですね。
そういう流れがあって、前にいた会社に入って、業務上SDKのメンテとかしないといけなかったので、Next.jsやったりとか、他のフレームワークとかもやるようになったり、
あと最後の方とかはリアクトの枠から外れますけど、Next.jsとかも使って、デモアプリケーションの開発をするようになってましたね、という感じです。
ken
なるほど。じゃあ結構Gatsbyと出会って、自分の幅というか、バックエンド売りのものも変えてみたり、サーバーレスのものも変えてみたりとか、そのフレームワークを深掘りしたという経験は結構アリサさんにとっては大きかった点だったのかなと聞いてて思います。
Arisa
そうですね、私もそう思います。だから割とそのバックグラウンドがあったので、Linuxの方に移行するのもそんなに苦じゃないというか、むしろ共通点を多く感じてたので、バックエンドのマインドも50%ぐらい念頭に置きながら開発をしていくというか、むしろスターターに入ってますよね、既にも。
業務経験と転職
Arisa
入ってるんで、そのデータベースを念頭に入れたスターターの構造っていうのが。だからもうそのマインドセットで開発するっていうのが割と普通。
ken
なるほどね。じゃあJQueryとかも経験してきたんだ。naoさんはどうですか?
Nao
私は4年半ぐらいなんですよね、エンジニアになってから。だからそんなに長い経験があるわけでもないんで、そんなにアリサさんみたいにたくさん経験ないんですけど、フロントエンドに行った理由ってものすごい強い理由があったわけではないんですけど、とりあえず私はブートキャンプに行ってエンジニアになったっていうタイプの人間なので、
要はエンジニアとして就職したかったので、ブートキャンプを卒業したらその後職に就きたいっていうのがあったから、あってそうですね、募集してた、どっちにしろ未経験なので、ブートキャンプ出たばっかりのホヤホヤのあれなんで、一応ブートキャンプではバックエンドもフロントエンドもどっちも同じ分量ずつぐらいっていうかやったんですけれども、
どれが嫌いとかどれがめっちゃ好きとかそういうのがあったわけでもないんですけど、
良かったのがフロントエンドだったっていう感じっていうか、私そうですね、自分がユーザーとして使ってたところに、使ってたアプリケーション、アプリのところにウェブアプリなんですけど、そこに
がたまたま募集してたんで受けて入れてもらったっていうので、フロントエンドのエンジニアになって、私はもともと動的コンテンツをやりたいっていうのがもともとあって、そのスタティックなページっていうよりかは、だからマーケティングサイトとかっていうよりかは、どっちかっていうとプロダクトっぽいものとか、
そうですね、動的コンテンツをやりたいっていうのがなんとなくそういうのの方が楽しいっていうのは自分が感じてたので、もともと最初にいたところでは一応リアクトだったんですけれども、割と静的コンテンツっぽいサイトっぽいところが多かったんで、もうちょっとウェブアプリケーションをやりたいなっていうので、今の会社に転職したっていうような感じで、どちらもリアクトベースで、今は今のところはNext.jsで、
今のところはNext.jsなんですけど、経験としてはだからそんな感じですね。そんなにいろいろあるわけじゃないかなって感じですね。
ken
動的コンテンツというか、バックエンドを叩いたりとかの方が楽しそうっていうのは、例えばステティックのサイトだと結構デザイナーとのやり取りとかがありつつも、完成果物を作ったら終わりみたいな一方で、動的なものはプロダクト開発というかイテレーションを回して継続的に関わっていくみたいな、どういう部分に惹かれたのかなって覚えてます?
Nao
単純にやってて楽しかったっていうのと、あとCSSってものすごく難しいですよね。ちゃんとデザインというのは、いわゆるフィグマとかのデザインという意味じゃなくて、フィグマもそうですけど、システムデザインと言われるようなことであったりとか、ちゃんとやろうと思うとものすごく難しいと思うんですけれども、
あんまりそういったところに面白さっていうのもあるだろうなと思ったんですが、あんまり好きじゃなかったっていうのがあったりとか、あとはデザインとかクリエイティブみたいなところ、そういうものを見て心が全然わかないわけじゃないんですけど、もちろんそういうものを見てかっこいいなとかそういう気持ちもあるんですけど、
自分のこだわりポイントみたいなところが、そこまでこうめちゃめちゃヌルヌルしたUI作りたいみたいなとかあるじゃないですか、そういう細かいところまでの追求が、いやもうできてたらいいんじゃんみたいな、どっちかっていうと、
そういうところが、爪が、私はそこの部分の爪を爪切ることはできないなっていうのをやりながら感じてたのがあって、それよりはどういう設計にしようかとかそういう話をしたりとかしてる方が全然楽しいみたいな、とかバックエンドの人とかと実際どういう風な設計になっているのかとかいう話を聞いたり、
ビジネスロジックを落とし込んでいく、そういうところがすごい面白い。今もそういうところが面白いと思って仕事やってるんですけど、そこが好きなんですよね。だから物事の抽象化みたいな話かもしれないんですけど、実現していく、そこに面白みがあるなと思ってて。
ken
プロダクト開発の醍醐味ですよね。自分たちがどんな機能を作ってて、それがユーザーにどういう課題の解決につながるのかみたいなのをシステムレベルに落とし込むみたいな、ヌルヌルしたアニメーションじゃないよねっていうところ。
ハリシャさんもカズもすごいうなずきながら聞いてたけど。
Nao
そこにこだわれる人はいいと思うんですけど、ただそれが私のネイチャーじゃなかったっていう。
フロントエンドのキャリア
Arisa
私も同感というか、あんまりスタイルに一生注ぎたいみたいなそれほどのパッションはないんですよ。
むしろここまでできてたら良くないっていうところがあったりするので、それよりかはやっぱり機能、動的にやり取りをする機能の方がもうちょっと詰め込んで、
精度上げてっていう、そこができてないと結構ユーザーからの例えば満足度が低いようなフィードバックが返ってきたりしやすいなって思ってるんで、
私結構喜びを感じるのがユーザーからの声なんですよ。
使いやすいとか、すごいこの機能好きとか、リクエストしたフルリクエストの内容をちゃんと反映してくれてありがとうとか、そういうことを言葉でもらったりとかすると嬉しいって感じるタイプなんで、
スタイルってあんまりそう言ってもらえなかった記憶があるんですよ、私の中では。確かにまあいいけど、でもそれよりこっちの機能が機能的に動いてないからそっち直してみたいな風に言われるようなことがちょっと私の場合は多かったので、それもあって。
ken
そうですよね、なんかスタイルめちゃくちゃこだわってもなかなか気づきづらいところでもあったり、それが本当のユーザーに届けたい価値でなかったりするところもあったりするので、
僕もすごいわかります、なんかアンドロイドエンジニアだった頃に、なんかそのハートをお気に入りのハートをした時のハートが消えていくアニメーションみたいなところに、なんか2週間ぐらいコースかけて作ってる人がいて、
楽しいけど、具体的にどういうユーザーに価値を与えてるんだろうって悩んだことあるんだけど。
数はさ、なんかCSSの辛さとか通ってきたの?もう最初からバックエンドなんだっけ?
Kazunari Okuda
いやー、それで言うと、そうですね、私がフロントエンド触った時は、最初にRuby on Railsが流行ってた14年ぐらい前かな、
なんかそんな時にRuby on Railsって、Alternative JavaScript、Coffee Scriptっていうのが入ってたりとかして、
で、ちょっともう化石みたいな話になるんですけど、その時はIE5とか6とか、そのJavaScript自体がもう今みたいになんかその、
トランスコンパイルしてくれるとか、なんかそんなブラウザーごとに勝手にやってくれるとかじゃなくて、
自分たちでなんかこうIE6用のJavaScriptのハックしてみたいな、HTMLもCSSもそんなことしてみたいな、
そんな時にフルスタックとして働いてたんで、時々HTML、CSS、JavaScriptっていうのを触ってたって感じで、
なんて言うんでしょうね、私はJavaScriptあんまり良い思い出が正直ないんですよね、
こうIE6対応とかで頭悩ませたとか、その時のJavaScriptってなんて言うんでしょうね、
なんでもできちゃうというか、今でもそうなのかもしれないんですけど、制限があんまりないっていうか、
ken
いくらでも壊しようがあるみたいな感じだったんで、
扱いづらいなっていう印象は今でもトラウマのように持ってるところがある、正直言うと。
すごい良いね、対照的な観点から話してるけど。
フロントエンドのめっちゃ好きなところと嫌いなところっていうのを問い置き、投げかけてみたくて、
僕のようなフロントエンド好きだけど業務で触ってないみたいな人からすると、結構フロントエンドの難しいところは、
すごい色んなフレームワークが本当に出てきて、開発速度も速いしリリースも速いから、
どのフレームワークにベッドしようかなとか、あとどういう風に学習キャッチアップしていこうかなみたいな、
そういうのが結構難しくて、例えば僕もGatsbyを結構触ってた時期が長かったんですけど、
業務外で勉強する意味としてはGatsby触るだけで精一杯なんですよね。
だからNextとか、あとVue.jsとか、AmberとかBackboneとか全然知らなくて触ったこともないみたいな感じで、
たまたまそれがリアクトだったから、なんとなくリアクトが結構盛り上がったから、
色んなところのコードを読めるようになったけど、っていうのがあって、学習効率の難しさ。
でも一方でやっぱりアリサさんとかも言ってたけど、ユーザーに直接見せられるところだから、
使ってくれた人からのフィードバックとかはもうダイレクトに来る。
僕のようなSREというかインフラで働いている人からすると結構ユーザー遠いので、
それはもう面白い醍醐味だったりするんですけど、
嫌いなとこと好きなとこって何か一つあげるとしたら何ですかね、お二人にとっての。
Arisa
いい質問なんですけど、難しい質問ですね。
Nao
好きですね、難しいですね。
Arisa
私は好きなところが多いので、嫌いなところ、欠点みたいなところをちょっと思い浮かべるのが難しいんですけど、
強いて言うなら、キャッチアップするスピード性を求められるので、
そこが例えばブランカいて戻ってきたりすることを考えると少し怖いところではありますね。
リアクトとビュー両方できる二刀流の方っているんですけど、
その方にはちょっと私はまだかなわないので、リアクトでずっと生きてきたような感じなんで、
そのあたりも結構手広くできる人にはちょっとかなわないかなっていうのは感じますね。
やっぱり手広くできた方がいいに越したことはないですけど、
あとそれだけ基本、JavaScriptの基本っていうのがものすごく強いっていう意味でもあるので、
そこの域にまで達するのに私はもう少し修行がいるかなっていう、そこは少し欠点かなと思います。
でもだからといってめちゃくちゃ嫌いになるっていうわけではないですね。
ken
なんかキャリアの築き方で二刀流とかフレームワークどっちも使えるようになるっていうのはやっぱり一つ強みになり得るんですかね、フロントエンドとかでも。
Arisa
キャリア仕事の面で言うと、携わっている分野とかポジションによるんじゃないですかね。
例えばそのプロダクト開発してたら全然二刀流できたとしても、プロダクトが2種類の違うライブラリとかフレームワークからできてるってそんなにないと思うので、
というかまずないと思うので、それならプロダクトで使われている技術に特化している人の方がいいと思いますし、
どっちかっていうと二刀流で得をするケースっていうのは転職活動している時じゃないですかね。
自分の普段やっている業務外の技術だけでもできますってなると、その分リクルーターから声かかる率っていうのは上がると思いますし、
可能性が広がるので早く仕事が見つかるんじゃないかなとは思いますけど、業務上ではそんなにかもしれないですね。
ただDXエンジニアとかっていう役職の人とかだったら、デモだとかエクステンションの開発だとかっていうのでコロコロ変わったりするので、使う技術が。
なんで両方できたに越したことはないみたいなケースもありますけど、数としてはDXエンジニアとかそういうエクステンション開発に特化したエンジニア職って少ないと思うので、
あんまり大きなメリットっていうのはそんなにないように私は思います。
ビジネスとの連携
ken
仕事の取りやすさとかね、それはデータベースでも一緒なんで、ビュートリアクト、うちのフロントはビュートリアクトどっちも使ってますなんて言われるとむしろ避けたい現場ですよね。
Arisa
そうですね。
ken
技術的不採が溜まってるのかなみたいな。
Nao
なんでっていう。
あとは業務委託とかそういうフリーランスでやってる人とかは、両方使えたらパイが広がるっていうのはあるでしょうね。
ken
確かに。
なおさんどうですか?
Nao
私ですか。あれですよ、好きなとこと嫌いなとこです。
そうそう。
私バックエンドエンジニアとしてがっつり働いたことないんで、あんまり正確に比較することはできないんですけど、
でもやっぱりビジネス側が求めてることとどういうふうにアプリケーションが動いてるのかっていうののまさにインターフェイスの立場にいるっていうところで、
結構包括的にバックエンドの知識をバックエンドデベロッパーほどもちろん深くしっかり理解しているわけではないんですけれども、
全体像とかが見えてどういうふうにどういう仕組みになってるのかっていうのがすごく見えるんで、それが楽しいっていうのはありますね。
なるほどね、そうやって動いてるんだって。
それを理解してるからビジネスのリクエストが来たときに、なんとかするっていうのが仕事なわけじゃないですか、リクエストが来たときに。
なんとかしよう。
いや、これはこういうふうな構造になってるんで、もう無理ですっていうことをこっちから言われて、
でもこっちからは、これをしたらこれだけビジネスグロースが見込めるんですよってなって、それをなんとかしていくっていう、アダプトしていくっていうところなんで、
そこを解決、まさに解決していく位置にいるのかなっていう気が、そういうバリーを感じることが結構あるので、そこが楽しいかなって思います。
これがフロントエンドに特化してることなのかどうかはちょっと分かんないんですけども、今自分がフロントエンドエンジニアとして働いててすごい楽しいのはそういう部分って感じですね。
で、嫌いなとこはちょっとあんま分かんないですね。
ken
もうお二人泣いてた。
Nao
いや、キャッチアップ。
ken
好きさが伝わってくる。
Nao
キャッチアップがとかって、でも確かその先アリサさんがおっしゃられたみたいに、業務で使うやつが決まってたら、それをしっかり特化していけばいいっていう話にもなるから、
フロントエンドの課題
Nao
要はもう自分が使ってるテクスチャーが決まってるんで、その次のバージョンとか、あとは社内のライブラリーとかも出てきたりとかするので、そういったところとの互換性みたいなところとかもあるから、
そんなに先々のことを全部理解しておかなきゃいけないっていうより、今自分たちが使ってるもののところに入っていけるのかっていうところをしっかり、
要は壊れてしまわないかどうかっていうところをしっかり確認できるとかっていうことの方が大事だったりもするし、
最新の情報を常に知ってるかどうかとかよりも、もちろん知ってるに越したことはないんじゃないんですけど、
それを1週間後にすぐやろうぜみたいな話にはならないんで、
だけどそこに自分たちの課題を解決してくれるフィーチャーが新しくあるのであれば、できるだけ早くそっちに行けるようにしようかとかってなっていくんですけど、
キャッチアップとかの速さで大変っていうところもどうなんかな、私があんまりちゃんとしたデベロッパーじゃないかもしれないですけど、
そこはそれなりにみたいな感じっていうか、そういう感じで、嫌いだとかあんま分かんないっすね、特にないっす。
ken
ちょっと分かったかもしれないというか、お二人の話で共通してあるのが、やっぱり現場で求められているものとか、リアクトとビューどっちも使うようなキメラ構造じゃない限りですけど、
現場で求められているものをプッシュしたリミットじゃないですけど、ちゃんと理解してビジネス価値に貢献していくっていうところなのかなと思ってて、
僕は逆に業務で求められてないからこそ、何でも輝いて見えるんですね、新しいものとか出てくると。
だから多分そう見えちゃうだけで、例えば仕事でリアクトとリミックス使うからそれをキャッチアップしようってなると、スコープを閉じたとこで深掘りできるのかなというところもあって、
僕もちょっと形は違うけど、データベースという領域ではお二人と似たようなマインドで確かにデータベース深掘ってるなっていうのを聞きながら思ったんで、
そこはすごい同意するところでしたね。
ありがとうございます。
Arisa
目移りしやすいのは確かにデメリットにないかもしれませんね。
Nao
確かにそうですね。
だけど大事なのは自分というか、プロダクトなりチームなりが解決したいものを解決してくれるのであればそれは採用、もちろん使ったらいいですけど、
そうじゃなければ別にそれが世間で騒がれてるからといって、私たちに必要かどうかっていうのはまた別の話になってくるから、
確かにその目移りっていうのはあるかもですけど。
Arisa
いやでも確かにそれは一理あると思っていて、
特に私の場合、最初はフロントエンドとフロントエンド寄りのフルスタックやってて、デブレルエンジニアに移行したので、業務内容で扱うテクノロジーっていうのが全く変わるなっていう風にちょっと思う節があるんですよ。
理由としてはデブレルエンジニアってやっぱりエンジニア目線でエンジニアユーザーに向けて、今こういうことがあるとかっていう、
要するに最新のエンジニアユーザーがまだ知らない技術だとか、アーキテクチャだとか、技法だとかっていうのを発信していく人なんで、
まだ実用化されてない、これから実用化されるであろう技術っていうのを先に習得したりするんで、実用性があるかどうかっていうとそこに欠けてたりするので、
結構その表舞台で話す内容と、実際こう例えばユーザーとかクライアントとか、
エージェンシーのパートナーとかとのそのソリューションの方では、あんまり使われてない、
私デブレルエンジニアからすれば、もうちょっと少し時間を戻した技術の理解っていうのが求められたりとかソリューションを提供しないといけなかったりするんで、
時差っていうのをすごい感じてましたね。なんかこう、こっちが知っているソリューションを提供しても、でもそれうちで使ってないし、
マイグレーションするコストの方が大きいからできないって言われたりとかすることも多くて、
デブレルエンジニアの役割
Arisa
そうなんで、実務性があるかもう実用されているのかっていうことと、その今最新でトレンドになっている技術っていうのが足並み揃ってないんで、そこはちょっとあれですね、ずれを感じるとこはあります。
ken
なるほどね、そのずれの認識すごい、めっちゃしっくりきました。面白い。
Arisa
本当ですか。
ken
僕もデータベース限ると、コクローチDBが出た、ロックスDBが盛り上がってるとか、ユーガバイトDBがとか周りが言ってるけど、
いやでもうちマイシークエルでこのショッピファイスケールで捌けないしなとかっていう、なんか似たような感じなのかなと思っていて、
その現実、自分たちが求められる要求とのギャップと、そして自分が知っているツールの何ができるかっていう、なんかすごいしっくりした、なんか勝手にメタ的に解釈して盛り上がってますけど、僕の中では。
なんかその中で、フロントエンドのエンジニアとしてファンダメンタルに求められるスキルって何だと思いますかっていうのを聞いてみたくて、
僕フロントエンドってすっごい深い技術だと思うんですよ。
データベース並みに難しいと思っていて、例えばフレームワークを触るってなると、フレームワークをフレキシブルに書いていけるように、データモデリングとかアーキテクチャーの観点がすごい必要で、
例えば機能を追加していけるようにプラガブルなアーキテクチャーにしてみようとか、SDKの設計一つ取っても機能開発のスピードを落とさずについていけるような、
ディレクトリストラクチャーとか中身の構造をしていこうっていう行動各観点でもすごい求められるし、
例えばデバッグってなったときに、結構デバッグ、エンドユーザーで起こっているデバッグって結構難しいじゃないですか。
再現方法を手元で分かったりとか、数少ない情報で仮説を立てて、デバッグログのスクショ送ってくださいとかだけでなるべく少ない情報で解決しようとしたりとか、
あとパフォーマンスもサーバーサイドから自分のブラウザーまでに帰ってくる、HTMLが帰ってくるまでにすっごいいろんなプロセスが起こっていて、
例えばどこがボトルネックになってて遅くなっているのか、それはバックエンド側で単純にデータベースが遅いっていうわけでも限らなくて、
例えばHTMLの配信の仕方、CDNとかのもありますし、ブラウザー側でちょっと遅いみたいなのもありますし、
パフォーマンスのフロントエンドに限ったパフォーマンスでもすごい深掘りできる技術じゃないですか。
本当にパフォーマンスエンジニアリングもソフトウェアアーキテクチャーも普通にコーディングスキル求められるフルスタックなものだと思っていて、
その中でご自身が今注力しているでもいいし、自分が大事に言語化できるファンダメンタルなスキルとか、
もしくは自分が今注力しているでもいいですし、
そういうのってフレームワークから一歩離れたときにフロントエンジニアにとって大切なスキル、もしくはクリティカルな要素はこれですって、
言語化できたりしますかね。
Arisa
一言で言うのは難しいですね。
ken
そうですよね。さっきは難しい質問を出した。
Arisa
いやいやいや、だからこそ答えがあるって感じで。
そうですね、私は7年ちょっとフロントエンドの技術に携わって思うことなんですけど、
今例えばフロントエンドエンジニアにゼロから参入してなろうって思うと、すごく長い道のりになったなって思うんですよ。
それが多分ちょっと今聞いていただいたフロントエンドエンジニアに必要なファンダメンタルになる知識、必須の知識って何ですかってところにもつながると思ってて、
7、8年くらい前までで言うと、
HTML、CSSできてJavaScriptができたら、
もうほぼワードプレスとかそういったコンテンツマネジメント系の開発できるようになりますよねっていうところがちょっと無理ありますけど、
正確にはもうちょっとSQLあたりだとかっていうのもできないといけませんし、
あとMolewareとかも対応できないといけませんから、
結構プラグインとかの脆弱性を狙って、
そういうHTMLの中に埋め込まれたりとかする被害とかも実際見たり対応したりとかしたことあるので、
そのあたりのセキュリティとかもできないといけませんけど、
でも昔ってそんなに長くなかったと思うんです、
フロントエンドエンジニアとしてJITSMに触り始めるまでが。
今はJavaScriptまでたどり着いたらJAMA JITSM触っていいよって感じじゃなくて、
そこから次ライブラリリアクト行きますか、Vue行きますかから始まって、
そこも割と複雑化もしてると思ってて、
割とライブラリだけで結構できてしまうことも増えてるんですけど、
でもそれってイコールビルトインで入ってるAPIだとか、
そういったことに関しても既に知ってないと対応できませんし、
で、JavaScriptの基礎がしっかりできてないと、
そういったライブラリっていうのも理解が難しいですし、
で、さらにそのライブラリの先があるじゃないですか、フレームワーク。
で、そこのフレームワークで、
じゃあ例えば私はコンテンツマネジメントの方に特化してたので、
どうやって例えばページだとかコンテンツのロード時間っていうのを素早く、
必要な量だけ最小限の、
例えばデータコミュニケーション量でサーブできるか、
とかっていうところにも入ってきたりしますし、
フレームワークごとにビルトインで入ってるAPIとか性能とか、
特化してる優れてる点とかっていうのも違うわけじゃないですか。
で、どれがまたよく使われてるかとかっていうのも違うので、
身につけないといけない知識の量が増えて長くなった、
プラスその先見の目も持ってないと、
マイナーなフレームワーク、その一瞬だけバズったフレームワーク、
を習得してしまうと後がしんどくなってしまったりとかするんですよ、
それこそギャツビーとか。
今かなりもうNext.jsを最初から選んだ人は割と、
一つのフレームワークに長く携わることができてていいかなって思うんですけど、
そうじゃない人たちもいますから、
なんかこう、もう一度戻って新しくフレームワークを学習し直したりしないといけなかったり、
だから先見の目と長くなった学習スパンに耐えられる忍耐力みたいなものが結構求められてると思ってて、
でもその全部の根源っていうか、
一番基盤になってるのはJavaScriptの理解ですかね、
プラス今はTypeScriptもできて当たり前ですから、
結構そのあたりっていうのが広く浅くじゃなくて広く深く長くやっていかないといけないのが結構あれですかね、
必要なんですけど時間のかかる工程かなと思います。
ファンダメンタルなスキル
ken
なるほど、先見の目とあと広く深く学んでいく忍耐力と、
あとベースとなるJavaScriptっていうところで、
おっしゃる通りセキュリティも求められてくるって本当に幅広いですよね。
JavaScriptの理解っていうのもちょっと深掘っては見たいんですが、
一旦同じ質問をNaoさんにも投げてみたくて、
ファンダメンタルに求められるスキルってNaoさんの目線でいうとどんなものだったりするのかなっていうのを聞いてみていいですか。
Nao
はい、ありがとうございます。
そうですね、どのレベルのエンジニアに求めることかとか、
そういうフリーランスなのかとかいうのでも変わってきちゃうと思うんですけど、
一応自分がずっと会社員でやっててっていう感じなので、その前提で答えるみたいな感じになるんですけど、
言われたリクエストをそのままやるっていう仕事とそれ以外だと、
実はそれ以外の方が結構多いような気がしていて、
パフォーマンス向上の重要性
Nao
もちろんリクエストはめちゃめちゃ来るので、それ自体はシップしていかないといけないんですけど、
そういったものをどれだけ早くシップできるかっていう、
要はインフラ整えるとか、
あとはアラートのいらないノイズを日々省いていったり、
さっきケンさんが言ってたみたいにパフォーマンス上げるとか、
そういういろんなテックデッドまでいかないですけど、
日々の少しずつの改善っていうのがものすごく大きなインパクトにつながっていくって考えてるんで、
そういうのがすごい大事だなと思ってて、
それはあらゆるエリアにおいてって感じになると思うんですけど、
そこでファンダメンタルな力っていうので言うと、
エラーメッセージが出てくるわけじゃないんですけど、
そういうノイズを自分で感知できるかどうかっていうところがあるかなと思ってて、
もしかするとこれあんまフロントエンドに限らずって感じになっちゃうかもなんですけど、
フロントエンドの場合は探せば解決方法ってもう絶対とは言い切れないかもですけど、
ほぼほぼの確率であると思うんですよ、
もうすごいいろんなフレームワークも出てたり、
あとはそもそも会社自体がモダンなテック採用している場合だったら、
それに付随しているエクステンションだったり、
そういうような形で何かしらあるんですよねとか、
あとは違うフレームワークに乗り換えるだったりとかしても、
モダンからモダンに行く場合だと、
もうマイグレーションガイドみたいなのがそもそもDocsに書いてあったり、
マイグレーションコマンドがあったりとかするわけなので、
だから探せば解決方法あるっていうのが、
もうほぼほぼ8割9割じゃないかなっていうふうに私は考えてるんですけど、
ってなってきたら、AIとかもありますし、
ってなってきたら自分がそれに気づけるかどうか、
それを見過ごさないかどうかっていうのがやっぱり人間が、
人間がっていうかフロントエンドエンジニアができることなんじゃないかなっていうふうには思いますね。
だいぶちょっと、すみませんあんまり具体的な話じゃないんですけど、
気づかない限りそれって見過ごされてしまうし、
でもそういうところのちょっとした、
0.1秒のパフォーマンス向上であったりとか、
もうセンチュリーのアラート来まくっているところをきれいにするとか、
それを読みやすくするとか、
そういったことだけで、
それがすべて早いデプロイにつながっていくので、
やっぱりフロントエンドってその実際に、
もう表にパブリックに何かを出荷していくっていう立場にあるんで、
そこのスピード感だったりっていうのはすごい大事で、
スピードは早く出すだけじゃなくて、
何かあった時にすぐ戻せるとか、
そういうピンできるとか、
そういったことにもつながってくるんで、
インシデント対応じゃないですけど、
そういうラバストっていう、
要は堅牢な状態を保つこともできるわけなので、
とにかくそこのスピードを落とさないように、
日々メンテナンスが必要なんですけど、
好奇心と小さな改善
Nao
それってリクエストされて上がってくるわけじゃないんで、
そういうのを自分でキャッチしていけるかどうかっていうのはすごい大事かなと思います。
ken
なるほど。
今のナオさんの話、
エッセンスが個人的に2つ詰まってきたかなと思ってて、
1つが怪しいものを嗅ぎ分ける、
何ですかね、
ガンではないかもしれないけど、
Something smells みたいな感じですよね。
Nao
これはスメリーだな。
ken
スメリーだなみたいな、
スモーキングガンだなみたいな。
2つ目はでもやっぱり小さなことを積み重ねっていうか、
それを積み重ねていくことで、
ロバストな、堅強なものが作られていくんだなっていうのを、
すごい僕は今腑に落ちたの。
なぜかというと、
先週うちのチームでめちゃくちゃ優秀なシニアスタッフのSREの人がいて、
彼に君の成果が出る秘訣は何だいって聞いたら、
この2つを教えてきたんですよ。
小さなスロークエリとかを積み重ねを、
ちゃんとちゃんと泥臭い仕事だけでやっていくと。
そうすると、
You're gonna fail somethingって言われて、
それは多分ソースコードに対する深い理解とかなのかもしれないけど、
彼レベルの人が、
そういう小さなことを積み重ねると何か感じるよって言ってくれてるのと、
今ナオさんは基本的に同じことを言ってて、
僕はすごい今ドキドキしてるというか、
なるほど、そういうことなのかと思ったんですよね。
でもそう思いますね。
カズどうですかちょっと、
僕個人的に一人で盛り上がってるんだけど。
ずっと聞きたかったことを2人に聞きまくってるみたいな感じになっちゃってるんだけど。
どうですか?
カズからフォローアップクエスチョンとかある?
Kazunari Okuda
そうですね。
どうぞどうぞ。
Nao
こんなフロントエンドエンジニアと働きやすいとか、
こんなフロントエンドエンジニア好きとかありますか?
Arisa
それ気になりますね。
ken
めっちゃいい質問だ。
僕ね、今日の想定質問でそれを逆を聞こうと思ってたんだけど、
Nao
先に僕らから答える。
ken
カズ考えてる?
Kazunari Okuda
それはめっちゃいい質問ですね。
ken
考えたことなかったな。
今日いい質問飛びまくってるよ。
グッドクエスチョン。
Kazunari Okuda
ケン答えられる?
考えてる間に。
ケンが答えてる間に考えようかなと思って。
ken
ひどいなもう。
いくよじゃあ。
でも、やっぱり、何だろうね。
二人みたいなのはあれですけど、
例えばデータベースとかSREの領域で、
詰まったこととか難しいことたくさんあるんですよね。
フロントエンドはフロントエンドで、
僕が見えてる限りさっき言ったパフォーマンスの話とかフレームワークの
どこまで深掘りしていくかとか難しいこともあるんだけど、
でもソフトエンジニアリングのもうちょっと中序的なレイヤーで考えると、
基本的には構造的に同じことで悩んでると思うんですよ。
フロントエンジニアもバックエンジニアもデータベースエンジニアも。
オープンソースで開発されてるものを
アップストリームに入ってしまったソフトウェアバグであったり、
どこまで自分たちで深掘りしていくかであったり、
メタ的には同じこと悩んでるんで、
答えに戻るとすごい、自分の領域じゃない技術にも
クリオシティというか好奇心を持っていろいろ
アスクしてくれる人、質問。
例えば今回データベースでこういうこと起こったけど、
なんで起こったのみたいな、
もともとフロントエンジニアで、
SQLクエリとか書いたことない人でも、
いろいろ質問してくれて、
すごい分かろうとしてくれる人がいると、
楽しいんですよ、話で。
単純に。
し、僕らもパフォーマンスエンジニアの領域で、
FTPがファーストコンテンツなんちゃらいろいろあるけど、
そういうの教えてよって言ったら、
僕らの目線で教えてくれるようなフロントエンジニアとかがいると、
すごい話で楽しいんですよね。
だから何だろう、
単純にフロントエンドに誇りを持ってて、
好奇心があって楽しそうに話してる人と話すと、
なんか楽しいですし、
僕は本当にフロントエンドは、
データベースと同じくらい難しい楽しい領域だと思ってるから、
僕もサイドギグでキャッチアップしてたりするから、
なんかちょっとふわっとなっちゃったけど、
すごいフロントエンドを好きで、
誇りを持って働いてる人だったら、
フロントエンドだろうがバックエンドだろうが、
モバイルエンジニアだろうが楽しいなと思いますね。
Nao
ありがとう。
Arisa
お互いの垣根を越えて繋がれるっていうことですよね。
ken
そうそう。
お互いの好きなカードを見せ合うみたいな感じ?
見てよ見てよ、
これ俺の最近当たったカードなんだけどさ。
Arisa
それが楽しいです。
Nao
カジュアルにそういう話できるのもいいですよね。
仕事で要件があるから話すというより、
ちょっとした興味があって好奇心があって、
っていうところでどうなってんの?みたいな話。
デバッグ能力の重要性
Nao
すごい楽しいですよね。
ken
楽しいですね。
基本的にはポジティブインテントを想定して、
まず話すっていうのがうちのカルチャーとしてもあるし、
僕もすごい好きなので、
フロントエンドとバックエンドの断絶とか、
インフラプラットフォームエンジニアリングと
アプリケーションエンジニアのコミュニケーションギャップとか、
もちろん話題になったり、
それが実際に問題になる開発現場ってたくさんありますけど、
基本的にはお互いソフトエンジニアとソフトエンジニアとしての対話というか、
そういうのが僕は好きなので、
単純に自分のやってるものが好きな人には好きなものを表現してほしいし、
表現者というか。
そこでお互いの、
お前はそんなことができるのかしら、
ちょっと俺の話も聞いてくれよみたいな、
キャッチボールができると楽しいなと。
答えになってるかなって感じなんだけど。
Nao
でも、けんさんの人柄があふれ出てる感じがする。
Arisa
でもそうですよね、ソフトウェア開発自体、
どれか一つの分野だけでできてないですもんね。
複数の分野が複雑に一緒に構成しあって、
そのソフトウェア自体ができてるものだと思うので、
その違う分野だから、垣根は越えないじゃなくって、
そこを柔軟に、例えば橋渡しできる人がいたりだとか、
どっちでも行けますよとかっていう人もいたり、
別の分野だけれども理解を深めたいとかっていう、
そういう柔軟性っていうのがやっぱり求められるものだから、
理解してもらえる、理解したいっていう、そこが結構大事ですよね。
多分それがあると開発自体もチーム自体の中でもスムーズなんじゃないかなって思いますね。
ken
レスペクトを持つみたいな感じなのかな、相手の専門性に対して。
もういいでしょ、かず。
Kazunari Okuda
もういいでしょ。
Nao
かずは考えてました?考えてました?
ken
考えてました。めっちゃ真剣に考えてました。
Kazunari Okuda
それで言うと、私的に働きやすいフロントエンジニアの人、
フロントエンジニアに結構限らないような気がするんですけど、
デバッグとかが上手な人って働きやすいなと個人的には思ってて、
もちろんコードをパパッと変えて試行錯誤で問題を見つける方法もあるんですけど、
まずはブラウザで開いてみて、問題のある箇所で、
例えばフロントエンドであればブラウザのデバッグ画面を開いて、
これでちょっとココココってやってみて、
こういう原因なんだみたいなのとか、なんて言うんでしょうね。
Arisa
確かに。
Kazunari Okuda
そうしてくれると、トライアンドエラーで何かなったよっていう、
フロントエンドってちょっとそういうところがありそうなのか、
CSSとか見た目のバグって結構やっぱり見ないと分かんなかった。
実際やってみないと分かんないっていうことはあるじゃないですか。
でもそんな中でも、コード変えてブラウザで表示してとかよりも、
例えばブラウザのデバッグでレスポンスをレコードして、
デバッグの重要性
Kazunari Okuda
その結果こういうレスポンスをAPIに送ってますと、
そのログからこういうバグが考えられるよね、
こういう挙動をしてるんだよねっていうのを考えられて、
それでブラウザで実際HTMLとかCSS変えてみて、
値を変えてみてこうなったよねみたいなのっていうのが、
私はどっちかっていうとバックエンドエンジニアよりのロジックで考えがちなんで、
そういうデバッグの仕方とか一緒に働いて、
そういうふうにやってくれると、私としては結構理解しやすい。
こういうふうに動いてるんだな、フロントエンドが動いてるんだな、
デバッグもこういうふうにしてるんだなっていうので働きやすい。
これはもう全然フロントエンドによらずだと思うんですよね。
フロントエンドも適当にコードの問題ある箇所探すよりも、
まずはログ見て、プロダクションとかステージングのログ見て、
そこからこういうエラーメッセージがあるよね、
だからこういうここじゃないかなみたいなっていうのを探していく人っていうのは、
ジェネラリーなんか働きやすいような気がするし、
問題解決も早いのかもしれないなとかって思いました。
リモートワークでのコミュニケーション
Nao
そうですね、確かに。
ブラウザーにすぐにホットリロードできちゃうから、
見た目のところだけだと、UXの部分は無理ですけど、
だから手当たり次第コンソール.ログをやりまくって、
これかなみたいなのとかってできなくもないんだけれども、
モニタリングとかデバッギングとかそういうエラーメッセージとかをちゃんと読んで、
まず最初に自分の中で仮説を立てられるっていう。
それに沿って、それを検証するっていう段階にきて初めて画面で確認するっていうか、
そういうのだとすごい早いですよね。
いいところですね。
Arisa
確かに、あとリモートの環境とかだと特にそういうスキル求められてるかなっていう風に個人的に思いますね。
私の場合常にフルリモートでやってるので、
全然みんなレベルも違うエンジニア同士でそれやってると、
特にジュニアであればあるほどつまずいたときに聞く頻度ってどうしても増えると思うんですけど、
そこのコミュニケーションのやりとりがどれだけ早く進められて、
どれだけ早く解決に持っていけるかっていうのがすごい大きな差を生むかなって思います。
だからそれを多分するための努力の一つとして、
自分でできる範囲でできるだけデバッグして仮説を立てて、
何をどこまで検証することができたかっていうそこの報告がしっかりできる人とだったら、
多分シニアの人だとか他の多分一緒に働いてる別の分野のエンジニアの人とかも
コミュニケーションがスムーズになるんじゃないかなと思います。
やっぱりこう、開発にかかる時間って差が出てしまうそうですね。
リモートとオフィスで実際やってるのと、
いろいろ企業とかの話聞いてると、
なんでオフィスに出社してもらうことにこだわってるかとかっていう理由を聞くと、
結構そこが多かったりしたりするので、
リモートは自発的に自分でかなりデバッグ力が高いスキルがあるかどうかっていうところにかかってる部分もあるので、
そこにちょっとリスクをかけたくないっていう企業とかの通勤してくださいって言ってたりしますね。
2025年の目標と展望
Arisa
個人的な感想ですけど。
ken
確かにデバッグですね。
デバッグって一人でやると孤独じゃないですか。
なかなか成果見えづらくて。
リモートだとデバッグ頑張ってるんだけど、
マネージャーからすると成果が見えないみたいなところでもあったりするから。
Arisa
本当それですよ。
私それでクビになったようなもんですからね。
ken
お前はエラーコード読んだのかっていうの見せてやりたい。
Arisa
本当に本当にとかなんかびっくりするようなコメントとか来てたんであれなんですけど、
なんかもう一日おきに監視されてましたからね、デバッグしてるんですけど。
それで最速の連絡が来るたびにどこまでデバッグしてどこまで成果進んでて、
仮説立ててこのアプローチの方がいいっていう、
私自身の働いてる内容の証明をする方に時間かかってたので、
それはちょっとそれあれですよね。
ken
本質的じゃないですよね。
Arisa
だから信頼っていうのも必要ですよね。
ken
デバッグをさせる側とする方とっていうのも思います。
デバッグに本当は集中できるような環境をね、
マネージャーとかが作ってあげるべきなところを逆に説明責任を求めちゃうと、
それはちょっと違いますよね。
Arisa
そうなんですよね。
話がちょっとそれちゃいますが、
マネージャー自身のそのスキル力っていうのが衰えてたりする場合もあるじゃないですか。
ちょっとわかりませんけど、私が言える立場じゃないかもしれないんですけど、
それでこう判断を誤ったりだとか、納得のユーザーが多分満足しないだろう、
実装で進めないといけなかったり、それに切り替えないといけないがために、
また一から実装し直しとかっていうのもあったりするので、
結構あれですよね。
なんかコミュニケーション良くなんですかね。
コンテニューアルの働きやすそうな。
ken
なのかな。
そこについちゃうのかな、コミュニケーションスキル。
でも知識足りてないマネージャーに教えるのはちょっと違いますからね。
マネージャーアップの範囲を超えてるとも言えるしね。
Arisa
難しいですね。
ごめんなさい、難しい方向に引っ張っていっちゃいました。
ken
僕はこの4人がドリームチームじゃないかなと思ってるぐらいですけど。
僕がインフラして、カズがバックエンドして、
アリスさんフロントして、ビジネスのつなぎ、
ナオさんやれば最高じゃない。
ないですよ。
Arisa
確かに。
改めてしちゃいましょうか。
ken
本当に。
今日聞きたかったことの20%ぐらいしか聞いてないんだけど、
もうこれ第2、パート2やりたいぐらい。
本当は具体的なツール名とか開発ツールとかワークフルを愛用してるツールで
デバッグ方法であったり、
いろいろキーワードあるじゃないですか、マイクロフロントエンドとかテストとか。
デザインシステムの話もありましたけれども、
それは次回にとっときつつ、
今日は最後に締めなんですけど、
年初の収録ということもあるので、
2025年の個人的な展望、野望、目標みたいなのを聞いてしまおうかなと思ってます。
大沢さんは冒頭にもおっしゃってました4月のコントラクトの話もあるかもしれないですけど、
全然フロントエンドの絡みでもいいし、仕事の話でもいいし、
カズみたいにプルアップを10回するみたいなそういうのでもいいんですけど、
2025の自分についてデコルジングしようかなと思ったけど、
そんな締め方でカズよろしいでしょうか。
Kazunari Okuda
もちろんもちろん。
ken
ぜひしたいです。
ぜひ思いついた方から言ってもらおうということで。
Arisa
野望さんどうですか。
Nao
いろいろありますけどね。
いろいろありますけど、
そうですね、私は、
仕事の面で言ったら、
一応2025年はレッスン・イズ・モアっていうのを、
一応今年のタイトルにしてるんですけど、
なので、やっぱりAIとかも普通にコードを書くときにみんな使いますし、
正しい情報みたいなのとかっていうのは、
間違ってる時もありますけど、ほぼほぼだいたい合ってるみたいなやつっていうのは、
どんどんいっぱい来る、その辺にあるわけなんで、
それはもう自分が一生懸命何かを学習して得るスピードは追いつかないと思うんですよ。
なので、やっぱり考えるっていうところをしっかりやりたいなっていうふうに思ってて、
レバレッジっていうところになると思うんですけど、
しっかり考えて、考えることで価値を出していくっていうのって、
すごいプロミスされてないので結構難しいと思うんですけど、
でも、だからこそ頑張りたいかなっていうところもあって、
去年とかは割と私、デベロッパーもやりつつ、
デリバリーっぽいプロジェクトマネージャーみたいなこともやったり、
いろいろあんまり整ってなくてガチャガチャ忙しかったんですけど、
プロジェクトマネージャーがついに来たりとか、
ちょっと若干そういうところの手離れが来たので、
もっとフォーカスできることっていうのが増えてきて、
だいぶ、やっぱまだ2週間とかですけど、
年始まって、だいぶ去年よりはスッキリしてる感覚があるので、
なんでこのままチームのことであったり、
自分たちのアプリケーションのこととか、
しっかり考えて高いインパクトを出せるようにしたいな、
みたいなのがばっくり思ってる感じで、
あとは健康にっていう感じで、
朝のジムを、ちょっと変な時間帯に生きてるんですけど、
やたら朝早くからジムに行く人みたいな感じで、
ken
6時くらいですか?
Nao
6時前にはもうジムに着くんですよ。
だから何してる?みたいな感じなんですけど、
何を目指してはないんですけど、
そのルーティーンが今すごい自分にがっちりはまってて、
すごい、わかんないですけど、ハイになっちゃってるんで、
できるだけ続けられたらいいなっていうふうに、
持続可能なルーティーンを築いていきたいと思ってます。
何を目指してるかわかんないですけど、
そこにもサステラビリティを持ち込んでいきたいと思ってます。
ken
大事じゃないですか。
Nao
はい、そんな感じです。
ken
いいですね、レッスンもありがとうございます。
はい、ありがとうございます。
アリサさんどうですか?
Arisa
いやぁ、尚更みたいにこう、もっとみたいな、
こう、文芸みたいな、なんかこう、
ないんですけど、私の中では。
でもやりたいことは、すごいしっかり、
割とはっきりしてるかなと思ってて、
ちょっと冒頭でも言いましたけど、
確定じゃないんですけど、オファーいただいたので、
取るか取らないかにはよりますが、
多分、何も問題がなければ、
私は一番そこに行きたかったので、
春からフロントエンドエンジニアとして、
また開発、200%携われるので、
そこで、気持ち新たに、
デブレルからフロントエンドエンジニアに戻るのって、
こんなに大変だったのかって、
本当に苦労したので、
まず面接までこぎつけないところを、
そこは割とポテンシャル見込みで、
面接っていうよりも、
一緒に何がしたいっていう相談を聞いてくれて、
決めたって感じなんですよ。
ほとんどの企業が、
うちが出してる、
開いてるポジションは、
レベル別に、シニアだから、ミドルだから、
エントリーレベルだからっていう、
そこの枠にはまらなかったら、
さよならっていうところが、
多分ほぼ全てだったんですけど、
そこだけは話してみて、
一緒に見ていた中で、
あなたはこれぐらいのレベルだから、
このぐらいで、
私たちは一緒に仕事したいなと思ってるんだけれども、
どう?っていうふうに聞いてくれるところだったので、
そうなんですよ。
だから、一緒に考えてくれる企業であったことと、
プラス、結構ポテンシャルに投資をしてくれる企業だったので、
そこの期待に応えたいですね。
だから、まず最初の使用期間半年、
要するに今年の9月までに、
首にならないことが、
キャリアと学習の志
Arisa
ちょっと低レベルかもしれませんけれども、
そこが一番、
まず先にあって、
すでにフィードバックいただいているので、
何が足りないかとかっていうのも分かっていますし、
そこを埋めていって、
そうですね、
正式に使用期間を終えて、
長くフロントエンジニアとして続けていければなと思っています。
もしダメだったとしたら、
私いつもプランBとかプランC、プランD考えるタイプなんですけど、
ダメだったとしても、
一応その転職活動、今回してきた中で思ったのが、
経歴の中で自分がやりたい役職名を持ってないといけないんですよ。
だからレベルエンジニアとしてやってきてしまってたら、
そこから別のフィールド、別の役職に行くってものすごいしんどいので、
特にシニアなんてついてちゃってたもんですから、レベルエンジニアの時には。
逆に働いたと。
そうなんですよ。
うまく一致しなくて、
私のレベルエンジニアとしてはミドルなので、
シニアじゃないので、
すごく苦労したので、
そこが少し足枷が取れる状態になるので、
もしクビになったとしても、
次に行くための橋渡しが自分の力でできたかなっていうところが大きいので、
それを解雇されたとしても、
次につなげていければいいかなと思います。
あとその会社がデジタルエージェンシーなので、
ドイツ語も、ドイツ語力も求められるんですよ。
なので、7年8年サボっていたドイツ語の学習をしなければいけなくなったので、
長い目で見ると絶対私にはプラスになるんですよね、
ドイツで暮らしていくには。
なので避けていたことを今年はちょっと頑張って実力をつけていこうかなと、
技術面でもドイツで生きていくサバイバル面でも向上していこうかなと思ってます。
なので今年は趣味だとかそういうものに割く時間は少しお預けかなと思ってます。
全くお預けにするわけではないんですけど、
そうするとやる気そぼれちゃうので。
という感じですね。
技術面でもドイツでの基盤の面でもちょっと200%出せるなら出していきたいというのが今年の目標ですかね。
ken
素敵ですね。
キャリアに対する考え方とかマインドセットとかいつも聞いてて本当に刺激になるんですけど、
なんかお二人ともいい年にチャレンジングかついい年になりそうですね。
Arisa
ありがとうございます。
Nao
ありがとうございます。
ken
年になってほしい。
また引き続きオフレコでも収録でも、
2025年どんなチャレンジをするかまたキャッチアップさせていただきたいなと思ってます。
今日はフロントエンドエンジニア編ということでなおさんと有沙さんに来てもらいました。
今日は本当にありがとうございました。
Nao
ありがとうございました。
ありがとうございました。
