1. 雨宿りとWEBの小噺.fm
  2. Season -No.188 朝活「You Wil..
2023-03-08 19:33

Season -No.188 朝活「You Will Never Be A Full Stack Developer」をダラダラ読む回

はい.第188回は


You Will Never Be A Full Stack Developer
https://seldo.com/posts/you-will-never-be-a-full-stack-developer


を読みました💁

海外の方は日本とは全然バックグラウンドが違うため,キャリアに関する記事は特に興味深い物が多いですね!今回もまさにそういった記事でした.是非読んでみてくださいー!


ではでは(=゚ω゚)ノ

  • Full Stack Developer
  • Career Advice
  • evolving
    • visualized
    • web app
    • Simplification
    • Standardization

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:06
はい、3月1日です。よく朝9時13分になりました。
本日9月に3月というところで、会社さんによってはラストですね。
本日がラストで、締め日とか締め気になるんじゃないかなというところですね。
はい、おはようございます。memeのkkeethことくわはらです。
では本日も朝活を始めていきたいと思います。
今日はですね、またキャリア的なお話の今回の記事になるんですけど、
You Will Never Be A Full Stack Developer or Career Advice For The Working Web Dev
あなたはこのままだとフルスタックデベロッパーになることはないよと。
または働くウェブ開発者のためのキャリアアドバイスというところのタイトルですね。
を読んでいこうと思いますが、海外の方の記事でこういうキャリア的な記事を読むって、
僕確かにそんなに読んだことなかったなというので、気になっていた記事ではあるので、
これをちょっと読んでいこうかなと思っております。
フルスタックデベロッパーになりたいかどうかはちょっとまた別の話ではあったりしますけど、
でも多分エンジニアの最終目標はそこにたどり着くことだろうなというなんとなく気はしてますね。
技術をどこまで身につけていくかということですけど、
身につけていった先には多分フルスタックになっていくんだろうなというなんとか思ったりしてましたが、
まあまあ踏まえつつ読んでいこうかなと思います。
いきましょう。
私はウェブ開発者が自分自身を説明するときに使う多くの曖昧な概念の一つである
スタックですね、と呼ばれるものについてずっと考えてきました。
人々は自らをフロントエンド、バックエンド、フルスタックとかで呼びますけど、
どれが何を意味するのか、本当の意味でのコンセンサスは得られていないよということですね。
これはおっしゃる通りで、ぶっちゃけたみんな雰囲気で使っているという感じがしますし、
周りの人が使っているからじゃあうちもそうやって使うかみたいな、
多少の曖昧さを残しつつ使っていることは結構あると思います。
弊社でもそれぞれのデベロッパーの名前だったり定義だったりは一応してはいますけど、
どこまで厳密かというと別に厳密ではないし、
厳密さがどこまで重要かというとそれはそれで違う気はしてますけどね。
幅があるからこその解釈の仕様もあるし、
適用の仕方もあると思うし、取り入れることもできると思うので、
一概に厳密な定義をしていることが大事というわけではないと思いますけど、
それぐらいみんなフワッと使っているよということだと思います。
ではでは、What is a stackということで、
スタックというのはそもそも何ですかというところですよね。
問題の一つはそのスタックが膨大であることだからだというふうに言っています。
最低でもHTML、CSS、JavaScriptは含まれます。
しかしどこまで深く折り下げれば良いんでしょう。
サーバーさえのゲームもたくさんありますし、
ネットワークも考慮しなければならないし、
アプリケーションサーバーやHTTPサーバー、システムレベルの関心事とかもあります。
あとはビルドツールだったり、パフォーマンスの最適化であったり、
URL体験だったり、APIのサーフェイスとかインターフェイスだったりとか、
データベースだったりとか、オブジェクトストアもあったりします。
このようなことは全部学んでいこうとすると一生かかっても終わらないかもしれません。
03:03
だからあなたもきっとそうでしょう。
では続いて、一生かかって終わらないとも、
全部というのはどこまで全部かによりますよね。
本当に世の中の技術全部について学ぶというのもありますし、
その分野一つにおいて横方向の広がりとかもありますよね。
僕フロントエンドなのでフロントの話をすると、
JavaScriptフレームワークを勉強しなきゃいけないとなったときに、
Reactやるか、Vueやるか、Svelteやるか、Solidやるかみたいなので、
結局横方向にフレームワークがたくさんあるので、
それらも全部というのを含めてやるとそれはたぶん一生に時間は終わらないですけど、
とりあえず一個JSフレームワークというのを選んで学ぶという意味で、
いわゆるフルスタック的に、
インフラ周りだったりバックエンドだったりというところまでを全部学ぶというのだったら、
別に一生かかって終わらないということはないと思います。
それは学びきれると思いますけど。
続いてのセクション。
The stack is always evolvingですね。
エボルビングか。
スタックは常に進化しているよという話ですね。
問題のもう一つというのは、スタックが進化し続けることです。
私がウェブ開発を学んだ1995年後半には、
JavaScriptとCSSは存在していませんでしたが、
自分でHTTPサーバーをハンドロールすることはまだ合理的なことだと考えられていました。
HTTPヘッダーを解析してくれるPHPを書くことは、
怠惰・非効率・基本を理解していないというのが見なされていたんですよと。
これらは現在でも新しい開発者に向けられた非難にはなりますけど、
JavaScriptの世界では基本を擁護する人々というのは、
私が1995年にいた頃から8レベルも上のスタックにいますと。
8レベルがどういう基準とか通知なのかはちょっとあれですけどね。
私は変化し続けるスタックに基本なんてものは存在しないというように結論に達しました。
ああ、はいはいはい。変化し続けるからね。
ベースみたいなものはないよということですね。
仕事を成し遂げるために役立つことを学べば良いのです。
新しいことをするためにはおそらく自分が始めた頃から
スタックの上や下にあるものを学ぶ必要があるでしょうし、それで良いのです。
自分のペースで続けてくださいというふうにおっしゃってますけど、
一応全部においての基本は存在しないと思いますけど、
なんだかんだここ何十年変わっていない技術スタックというのもあると思っていて、
それは僕はいわゆるRDBですね。
データベース。いわゆるマイエスケルトポスグレというところですね。
RDBはもうこの二大巨頭から何十年変わっていないはずですね。
僕少なくともこの業界来て10年ですけど、
昔の先輩とか方にお話を聞くと、やっぱりそのようなのを使っていたよという話。
途中から使い始めたとはいえ、
そういう方々が現役で書かなくなったという話を聞いた上で、
でもその長い年月僕らを使っていたよという話を聞きますので、
データベースは早々でかく変化することは多分ないと思いますね。
もちろんAWSにいろんな形のデータベースがありますよね。
タイムマネージのものもあったりするという、結構特殊なものもあったりするけど、
基本のノーエスケールかRDBMSかみたいな二つだと思っていて、
RDBの主要なデータベースはその二つ。
06:02
所要なものということで、オラクルを使う方もいらっしゃると思います。
ここの辺はそんな変わらないので、
ここはベースだと僕は言っていいんじゃないかなと思ったりしています。
あとあれですね、サーバーサイドの話とかちょっとインフラの話になると、
Webサーバーですね。
WebサーバーはやっぱりApacheかNginxですね。
けど現代だと結構Nginxを使うケースの方が圧倒的に多いんじゃないかなと思いますね。
スラッグは確かApacheを使ってたはずですけど、
いろんな多量アクセスだったりとかをさばききるって意味で、
やっぱりNginxの方が一律の長があるんだろうなっていうところで、
現代はNginxの方が多いんじゃないかと思いますけど、
こういうレイヤー下がれば下がるほど、
技術の進化ってそんな多く変化し続けてるとは思えないので、
そういう意味でWebサーバーとかデータベースとかっていうところは、
今のものを学んどいて、それをベースと思っていただいてもいいと思っています。
新しいの出たところで、おそらくそんなドラスティックに変わることはないんじゃないかと思うので、
全然知識とか技術をそのまま流用できると思っています。
いわゆる横方向の変化しかないんだろうなと思っているので、
横方向、水平ですね、的な視点での変化しかないと思うので、
ベースとしてその辺は学んでてもいいんじゃないかなと思いますね。
変化が激しいのはやっぱり人が触れるところ、目につくところとかになってくると思います。
API周りになってくると思うので、
いわゆる言語であったり、その言語に付随したフレームワークとか、
アプリケーション開発の方に寄ったものは確かに変化が大きいので、
そういうのはベースなんてものは存在しないっていう風に言ってもいいかなと思いますが、
フロントエンドで言うと基本は今のJavaScriptもしくはTypeScriptがベースと言ってもいいんじゃないかと、
もう数年、下手したら10年ぐらいはそんなドラスティックに変化することは多分ないと思っていますね。
Jaceフレームワークもベースはやっぱり React なんじゃないかなと思います。
2022年のいろんな新しいフレームワークだったり、
フレームワークとかはライブラリをラッパーしたさらにフレームワークみたいなやつもあったりしますよね。
いわゆる React における Next.js みたいなラッパー的なフレームワークもありますけど、
ベースは多分今後もいわゆる React Hooks ですね。
Hooks 的な概念のものが入ってますかというのと、JaceX で表現をするものかというところですね。
昨今ですね、流行り始めたものとか話題になったフレームワークは大体 JaceX で書くんですよ。
Vue みたいな独特なテンプレート構文を書くかというとそういうわけではなくて、
いわゆる React の JaceX ベースのような表現の仕方、書き方というフレームワークが結構増えてきたなという印象です。
さっきの名前ありましたが、Svelte はちょっと特殊ではありますけど、
Solid Jace はまさに JaceX。 React っぽいですね。
React ライクな書き方をしたりしますし、それ以外のいろんなものが今出てますけど、
リミックスはどっちというか、フレームワークと言っていいから、
ライブラリというかちょっと悩ましいところですけど。
そうですし、あと僕の好きなクイックとかも JaceX ですし、
09:02
いろんなフレームワークが出ましたけどやっぱり JaceX なので、
フロントエンドの Jace フレームワークという意味では、
React がベースと言ってもいいんじゃないかなと思ったりします。
はい、ちょっと待って。この話、どんどん余談が過ぎるんで、次行きますが。
要は基本なんてものを全部に一貫して、基本なんてものは存在しないし、
変化し続けるものはもちろんあるんですけど、
でもちゃんと見ていくと、基本って言っていいだろうなというものは、
僕はいくつかあるんじゃないかなと思いました。
でも、仕事を成し遂げるために役立つこと、
自分がやりたいことのために、実現のためになる技術を学ぶっていうのは、
本当その通りおっしゃる通りだと思うので、そこは完全に同意ですね。
というところで、じゃあ次のセクションに行きましょうか。
次は The Stack Visualized っていうところですね。
その技術の可視化というところをしていきましょうと。
このようにスタックについて考えていると、
スタックがどのように変化していくかを視覚化したくなりました。
Twitter でいくつかのドラフトを公開したところ、
たくさんのいいフィードバックをいただき、最終的にこのようになりましたと。
一応今画像でパッと貼られていますね。
デバイスだったり、ステータだったり、プレゼンテーションだったり、
パーシステンスだったり、フィジカルだったりみたいなところで、
いろいろ技術の名前だったり、対象の名前が変わってあがっていて、
それのグラフが変わっていますね。
横軸に年数が10年単位で横軸が貼られていて、
縦軸は、What does the average web developer spends time thinking about?
時間をどれだけ使っていますか?というのが縦方向ですね。
上に行けばいくほどパーセントが高い。
100%を考えているというものと、0%の方が下になります。
という感じですね。
これ結構面白いですね。
全データをバーッと見ていますけど、
傾向がはっきり流れていく感じがすごく面白いですね。
今はやっぱり、2020年ではデバイスですね。
モバイルパーツだったり、レスポンシブUIだったり、
これをほぼ100%皆さん考えているというのが2020年だそうです。
1990年、グラフで見ると一番下なんですけど、
一番古い1990年はそんなワードすら出てきていないですね。かけらも。
その時に考えていたものは、100%考えていたのはHTMLだそうですね。
とかCSSだったり、コンポーネンツというものがだいたい考えられていたよというものが
1990年ですと。
そこからずっと変わっていっているものですね。
あと、1990年でほぼほぼ考えられていなかった、
0%だったり25%以下だったものに、フィジカルですね。
ロケーションだったりストレージだったりネットワークだったりしますけど、
物理的なものですね。
ちゃんとクラウドじゃない時代のお話なので、そりゃそうだよねという感じですけど。
それがずっと2020年だったら、そもそもグラフの中から消え去りましたね。
全く考えていませんという人がかなり増えたということですね。
本当にクラウドの進化が著しいんだろうなと思いましたけど。
そんな話がずっと続いています。
これ結構グラフ面白いし興味深いので、後ほどこの記事ツイートしますので、
12:00
皆さんの方でもこの記事の中からグラフの画像を見てもらうと面白いと思います。
続けますね。
これは客観的なデータには基づいていないことを明確にするというのが重要ですよと。
ソースを求めてこないでください。
私はそれをすべて作りましたけど、
あくまでこれ多分有志の方たちのアンケートなので、
ちゃんとソースがあるわけではないんじゃないかなと思いますね。
これは完全に主観的な視覚化にもなります。
いわゆる平均的な開発者を特定するのは難しいですし、
彼らが何を考えて時間を費やしているのかというのはさらに曖昧な考えです。
確かにそもそも軸自体が曖昧さをかなり含んでいますね。
しかし多くの開発者がこれを見て、
自分の経験とほぼ一致すると言ってくれたので、
私はこれを使って仕事をし、これが示しているものについて考えたいと思っています。
これは僕もおおむね同意ですね。
大体こんな感じなんじゃないかと思ったりします。
僕は10年間しか仕事をしていないので、
大体2010年くらいからのグラフの結果を見て、
ああそうだなという感覚にいますけどね。
結構これ面白いですね。なるほどでした。
先輩方とか古くから開発をされている方の意見も聞いてみたいですけど、
多分ほぼほぼ一致するんじゃないかなという気がします。
続いていきましょう。
続いては、Demands for software are outpacing supply of developersですね。
ソフトウェアの需要は開発者の供給を上回っているというものです。
まず重要なのは、私たちの脳はこれ以上大きくならないが、
スタックは常に大きくなっているということですね。
脳みそのシナプスをどこまでつなげるかという意味で大きくなるという話はできなくはないですけど。
では、ウェブアプリケーションに対する消費者の期待というのは絶え間なく高まっており、
私たちは常に新しいことを考えなければなりません。
1995年のクオリティのウェブアプリケーションを
今日の午後には作ることができますが、誰もそれを満足しないでしょう。
次に重要なのは、ウェブが全ての新しいソフトウェアの主要なプラットフォームになるにつれ、
開発者の需要が供給をはるかに上回り続けていることです。
そりゃそうだよね。
これはまず2020年におけるウェブ開発者の給料の高さに現れています。
またチームの規模に対する制約にもなっています。
本当にそうなんですよね。
消費者、消費者というか、ユーザー側の需要がかなり加速的に高まっているのは本当にその通りだと思います。
現代はウェブなしで生きていけないという時代になってきたなという感じがしますね。
それを支える技術者が足りないと。
なので、チャットGPリーダーもそうですけど、オープンアイドルが、
AI周りのところの進化が待たれる感じはあります。
これはロボットの話とかにもつながるので、AIはいつでも求められていると思うんですけどね。
とはいえ、とにかく行動がかく人が少ないので、
どれだけ効率化してもスピードが結構頭打ちになるので、
そのスピードをさらに超えてくれるという意味で、
AIの進化というのは結構待たれるなと僕は思っています。
ではでは、続いていきましょうか。
そのまま話は続くんですけど、
シンプリスケーションイズエッセンシャルだと。
15:01
まあ確かにシンプルっていうのはとても重要ではありますよね。
本質的と言いますが。
ではお話ですね。
高まり続ける機体とほぼ横並びのチームサイズという2つのプレッシャーの結果、
スタックを縮小するという容赦ないプレッシャーが生まれました。
一度に全てを考えることはできませんし、ゼロから全てを構築することもできません。
物事を成し遂げるためには、スタックを簡素化する必要がありますよと。
はいはいはい。
シンプリスケーションを簡素化と。
これはちょっと僕の感覚かもしれないですけど。
とりあえずシンプルにする必要があるというのがこの弊社で言いたいことだと思いますね。
そのスタックをシンプルにする仕組みは3つありますと言ってますね。
1つはスタンダラリゼーションですね。
標準化をするところだと言ってます。
物事を単純化する本当に素晴らしい方法っていうのは、
ほとんどの人が使うデフォルトを選択することになります。
みんなが同じプラットフォームで作業していれば、規模の経済が働いてみんなにメリットがありますと。
バグの修正が早くなったり、チュートリアルやドキュメントが充実し、
新しいツールがそのプラットフォームの上に構築されることになるでしょう。
デフォルトは、たとえ勝利したデフォルトが採用選択肢でなかったとしても、
誰にとっても結局は有益なものになりますと。
1980年代から1990年代にかけて、
デスクトップOSのWindowsでこのようなことが起こりました。
一般市民が座ってWindowsを採用するための会議を開いたわけではなく、ただただそうなったんですよと。
結果的にそうですよね、世界は。
Windows OSでわーっと1回石鹸したって感じですね。
いろんなアカデミック学校教育の機関もそうですし、会社でもそうですけど、
支給されるPCは一旦Windows OSでわーっと1回固まったんじゃないかと思いますね。
一部もちろんMac OSもあったと思いますけど、
Macがデフォルトで支給とか標準装備されている機関ってそんなに多くなかった気がします。
僕は日本にしかいなかったので、他の国とか海外の企業とか全然見てないからわからないですけど、
多分Windowsだったんじゃないかなと思いますけどね。
2010年代初頭ですね。
最近Ubuntuでも同じことが起こりました。
Ubuntuでウェブサーバーを走らせようという会議を開いた人はいませんでしたが、
今でも圧倒的に人気のある選択肢になっていますし、
これと同じことがリアクトのコンポーネントレベルでも起こっていると言えるでしょう。
Ubuntuもそうですよね、いわゆるLinuxのディストリビューションですけど、
何を使いますかというところですけど、
確かに大体みんなUbuntuを使っていたという時期があったと思いますね。
僕の周りでも困ったらとりあえずUbuntuを入れるっていう。
3つの周りから市民権を得たというか、
デファクトになったと言ってもいいんじゃないかと思いますけどね。
これらの例では、デフォルトが客観的にベストかどうか、
全てのユースケースに最適な単一のデフォルトを選択することが可能かどうかということはあまり自由ではありません。
事実上の標準があることで、そのプラットフォームを前提にしたイノベーションを起こせるんですよと。
選択そのものよりもシンプルになることの方が価値があるんですと。
選択肢が多いというのはすごく大事なのがあるんですけど、
ビジネス観点とかで考えると意外と制約があるからこそ、
18:04
みんなそこに対してこれを使う前提で工夫をしていったりとか、
どうしていくかっていうのを考えたりするクリエイティブになるので、
一概に選択肢が狭まった、それは辛いっていう、
辛みはもちろんあるんですけど、とはいえ、
だからといって全部がネガティブな話というわけでは結構なかったりしますよね。
ここ面白い観点だなと思っているので、ここは見直していきたいというか、
改めてみんなで議論したいなと思う面もあったりしますね。
もうちょっと続けましょうか。
時間的にですね、僕が朝遅れたのは申し訳ないんですけど、
残りの分量からして今ちょうど折り返しにきたぐらいのところなんですよね。
なので今日はここで区切りまして、中途半端で申し訳ないですね。
シンプルにする3つですけど、
1つ目のスタンダラリゼーション、標準化で今日は一旦止めようと思います。
明日はパッケージングが2つ目で、3つ目がアブストラクションですね。
というのが3つ目になります。
この辺を明日読んでいこうかなと思っていますので、よろしくお願いします。
ということで今日は一旦ここで区切りたいと思います。
水曜日中日ですね。
1週間の中日とはいえ、今日から3月なのでまた1ヶ月頑張っていけたらと思います。
会社さんによってはもう最後第4四半期、ラストだと思ったりしますし、
復業されている方々もそうですけど、確定申告今月以内なので、
皆さん頑張って確定申告も書いていきましょう。
というわけで今日の朝方はこれで以上にしたいと思います。
では今日も頑張っていきたいと思います。お疲れ様でした。
19:33

コメント

スクロール