00:00
はい、こんにちは、Kojimaです。
今回は、バックエンドエンジニアとフロントエンドエンジニアの違い、みたいな話をしようかなと思います。
というのもですね、本当にごく一部の人なんですけど、
フロントエンドの技術が発達してきていて、
どんどん、サーバーサイドの領域であったりも、タイプスクリプトだったりとか、
Node.js、あるいは、JavaScriptランタイムも増えていて、
DenoとかBurnとか、というのも増えてきており、
間違いなく、ウェブアプリケーションの開発という観点で言えば、
JavaScript、タイプスクリプト一本で、フロントエンドもバックエンドももう作れるじゃないかというような時代になっているというのは、間違いないかなと僕も思っています。
一方で、その状況を指して、フロントエンドエンジニアの活躍の幅が広がるというふうに言う人がいてですね、
一見最もらしい気がしますよね。
JavaScript、タイプスクリプトというのは、もともとフロントエンドの技術で、
同じ技術でバックエンドのコードも書けるようになるんだから、
フロントエンドエンジニアがバックエンドエンジニアの領域にも手を伸ばすことができるようになるだろうと。
間違った主張だとは思わないし、非常に理解できる主張なんですが、僕はこの意見には結構怪異的です。
怪異的というのはどういう意味かっていうと、
フロントエンドエンジニアとバックエンドエンジニアという職務の区分けがなくなっていくかどうかっていうふうに考えると、
僕はまだしばらくはというか、かなり長い間なくならないんじゃないかなというふうに思っています。
というのも、僕がバックエンドエンジニアとフロントエンドエンジニアの違いで大きく感じているものは、
技術的な違いそのものよりも、精神性と言いますか、作る時の姿勢と言いますか、
どういう行動が誰に価値を与えるのかっていう観点が全然違うということにものすごい大きな差を感じるんですよね。
なので、バックエンドエンジニアとフロントエンドエンジニアを同じ人がやるっていうのはかなり厳しいんじゃないかなっていうのが個人的な意見です。
03:01
それは技術的な差ではなく、 作る時のメンタルモデルの違いと言いますか、
態度の違いと言いますか、なんかちょっと上手い日本語が思いつかないですけど、なんかそういうもうちょっと精神的なものの違いなような気がしています。
まあこんだけ言っても何を言ってるか意味わからないと思うんですけど、
まずバックエンドエンジニアという生き物が何に気を使って開発をしているのかというと、
これ前も別のエピソードで話したことがあるんですが、バックエンドエンジニアっていうのは基本的にプログラムに対してプログラムを書くっていう仕事なんですよね。
どういう意味かというと、APIと言います。 APIとは何かっていうとアプリケーションプログラミングインターフェースの略なんですが、
つまりプログラムがこのソフトウェアを使うために提供するインターフェースのこと。
おそらく多くの人はWeb APIみたいなのを思い浮かべると思うんですけど、
http リクエストを適切に投げるとJSONでデータが返ってくるみたいなものですね。
例えばツイッターとかも裏側ではAPIが動いていて、
自分がツイートする時っていうのはそのツイートしたい文字列っていうのをリクエストボディに乗せてポストメソッドでリクエストしてツイッターの適当なエンドポイントに送信しているし、
自分のツイートとかフォローしている人のツイートを見たいときは適当なエンドポイントにリクエストをして、
そのエンドポイントから返ってきたJSONを適当にパースしてツイートの表示の形に変えているわけですよ。
というわけで当たり前のように皆さんAPIを使っているんですけど、
このAPIを作る時っていうのはAPIのユーザーっていうのは誰かっていうとプログラムなんですよね。
もちろんデータを見ているのは人間なんですけど、文字列を送信するプログラムが送信します。
それはつまりブラウザだったら人間がボタンを押した時にここにこういう形式のJSONを作って、
ここにhttp のポストメソッドでリクエストを投げるっていうのをブラウザが動くようにJavaScriptを書くわけだし、
スマホアプリだったらSwiftなりコトリーなりで同じようなことを書くわけです。
で、プログラムを相手にプログラムを書くっていうのは人間に対してそのデータを渡すよりも変化しないことに対して非常にシビアなんですよね。
この変化しないことに対してシビアっていうのは極端な話、
昨日まであったデータが今日なくなると突然そのプログラムはクラッシュしたりするわけです。
06:06
もしTwitterがツイートした時にツイートするたびにクラッシュするようなアプリになったら使い物にならないじゃないですか。
あるいはツイートをロードしたタイミングでクラッシュするようになっちゃったらもう全然ツイート見れないし使う気にならないですよね。
で、バックエンドっていうのは極端な話、それを一発で起こせてしまうプログラムなんですよ。
やろうとすれば。ということでそんなことをさせるわけにはいかないので、
バックエンドは基本的に昨日も今日も同じ動きをするように作るんですよね。
どういうことかっていうと、もう多くの場合、最近ではJSONっていうフォーマットを使いますけど、
JSONの形を定義して、そのJSONの形は変えないでバグ修正する時とかも、
そのJSONのインターフェース、JSONのフォーマットは保ったまま直すということを基本的にはやります。
場合によっては気づいてるけど直さないなんてこともあったりはします。
それくらい、昨日と今日同じように動くっていうことにすごい重きを置くのがバックエンドエンジニアだし、
それがある種価値を提供し続けることにつながるので、
そういうふうにトレーニングされるわけですね。 一方でフロントエンドエンジニアはそうではないわけです。
人間にとってこの挙動はおかしいっていうものは、もちろんこの人はおかしいと感じるけどこの人はおかしいと思わないとか、
人によって意見が分かれるようなものはもちろんあります。 だけど明らかにUIの英単語が間違ってますよとか、
ここのロードの来るタイミングがおかしいですよとか、ここ1秒スリープ入れた方がいいんじゃないのとか、
なんかいろんな細かいことがいっぱいあって、その細かいことの積み重ねっていうのがより良い UX になっていく。
ので、人に分かるような変化を細かく積み重ねていくっていうのがフロントエンドエンジニアの姿勢なんじゃないかなというふうに思っています。
これがユーザーがプログラムなのかそれとも人間なのかの大きな違いだと思っていて、
プログラムに対してプログラムを書いている以上、そのプログラムは何かしらの縛りプレイ的な要素があります。
しかしフロントエンドはその縛りプレイ的な要素がないので、自由とは言いませんがその縛りプレイ的な要素がなく、
別のところに力点が行きます。 この力点の差っていうのが
ともエンジニアとしての差をすごい生んでいる気が僕にはしていて、 はっきり言って僕は Python と TypeScript を書くんですけど、
09:01
Python を書くのかTypeScript を書くのかで困ることっていうのはまあほとんどありません。
Python を書いている、書いていた15秒後ぐらいに TypeScript を急に書き始めても、まあ慣れたっていうのはあるかもしれませんけど別にそんなに困りません。
はっきり言って言語の違いっていうのはその程度のものでしかないと僕は思っていて、
もちろん僕は TypeScript のほうが慣れてないので、ちょっと細かいところでこの
文法どうだっけとか、これどういう動きするんだっけみたいな細かい疑問とかはありますし、
まあライブラリー使い慣れてなかったりするとハマるということはあります。 でもそれは正直、使い慣れている Python という言語でもたまにあるようなことだし、
解決する方法っていうのはわかっています。 別に調べる方法がはっきり言って、
Python の公式ドキュメントを見るのか、それともモジュラルデベロッパーネットワークを見るのか、みたいな差でしかなくて、
そんなに解決に困りません。 だけど、
精神性の切り替え、メンタルモデルの切り替えっていうのはすごい時間がかかります。
うまく言えないんですけど、なんか
バックエンド的に考えてしまって、 ああ、今そういう開発をする場面じゃなかったって思うっていうことが本当に多くあって、
この切り替えにすごい時間を僕はかかるし、すごい感じます。 結局誰に対して価値を提供するのかって、誰に対して価値を提供するのが変わると、
どう価値を提供するのかが変わるので、 自分がどういうふうにコードを書くべきなのか、
どういうふうにっていうのはどんなコードを書くべきなのかではなく、 どういうことに気を使ってコードを書くべきなのか、
どういうスタンスでコードを書くべきなのかっていうのが変わってきます。 この違いがものすごく大きいと僕は思っていて、
これは果たして言語をタイプスクリプトにしたからといって解決できる問題なのかというと、 僕はそうは思いません。
たとえ全てのウェブアプリケーションがタイプスクリプトでフロントエンドもバックエンドも書かれるような世界になったとしても、
僕はフロントエンドエンジニアとバックエンドエンジニアは職種は分かれてるんじゃないかなという気がしています。
なぜならばフロントエンドエンジニアが価値を提供する方法とバックエンドエンジニアが価値を提供する方法は違うので、
事業的な要請からそれらを分けた方がある種の分業性につながり、 もし分業を志向するようなソフトウェア開発をするのであれば、
12:03
職種を分けた方が良いという気がしています。 仮に技術スタックがどちらのチームも全く同じであったとしても、
技術スタックが同じなのはありえないですね。
扱う言語が全く同じであったとしても、 フロントエンドチームとバックエンドチームで分けるっていうことに合理性、
事業的な合理性があると思います。 それは置いといて、
皆さん、複数のプログラミング言語を あんまり学ばないんですかね。
わかんないんですけど、 もしプログラミングを経験者である人が聞いているのであれば、
そして自分に1個得意な言語があるのであれば、 2つ目の得意な言語を作るのは非常におすすめです。
なんでかっていうと、やっぱり1つのプログラミング言語しか知らないと、 そのそこでのルールっていうのは当たり前にあって、
自分の価値観みたいなものが、 なんかあまり柔軟じゃなくなります。
日本語と英語どっちも勉強したから日本語を相対的に見れる、 日本語の面白い部分、日本語が変わっている部分みたいなのがわかるのと一緒で、
例えばPythonを一生懸命勉強して、 その後でTypeScriptを学んだりとか、
あるいは全然違うGoとかHaskellみたいな言語を学んだりすると、 Pythonの良いところ悪いところをより強く認識できる、みたいなところはあると思います。
なので複数のプログラミング言語を学ぶっていうのは、 もし自分の技術の幅に広がりを感じないという感触を持っている人がいたら、
ぜひ挑戦してみてほしいなと個人的には思います。 その意味でも、なんか全てをTypeScriptで書けばいいじゃんみたいな言い方っていうのはちょっと乱暴かなという気がしていて、
TypeScriptが今までの言語と比較してかなり出来がいいっていうのは、 僕も感触としては持っています。
この出来がいいっていうのは、 まずJavaScriptのスーパーセットのようなものであるし、
関数プログラミング言語のような柔軟な型の表現力というものも、 もちろん同等ではないですけど、かなり表現力が高いというふうに思います。
15:02
ということからもかなりより良いと言いますか、 出来の良い言語だとは思うんですが、
これが絶対だっていうふうにはやっぱりならないし、 そもそも今までもこれからも未来英語、このプログラミング言語が絶対であるなんてことはないので、
TypeScriptもいつかは廃れるかもしれません。 そういうことも考えて、
TypeScriptを一遍通っていこうと言いますか、
フロントエンド技術が ウェブアプリケーション開発のすべてを席巻するっていうのは、
そういう意味でもそもそも健全な状態ではないよなぁみたいなことも思ったりします。
今日はこんなところで珍しくプログラミングの話をしました。
今回も最後まで聞いていただきありがとうございました。 この番組はですね、最近土曜日の朝に更新するようにしています。
土曜日の朝に、 早く聞きたい方は土曜日の朝にアプリを覗いて見てもらえると嬉しいです。
ではではまたお会いしましょう。
