00:08
ネトラボの記事がよく経緯をまとめているんですけど、
有名な野球のダルビッシュ選手が、グローブか何かの新品を買ったので、
プレゼントしますというツイートをしたら、それに対して、
グローブよりもRTX2080Tiが欲しいというリプが返ってきたらしくて。
ダルビッシュ選手がそれを調べて、そもそもそれ何だと。
調べたところ、PCウォッチの、要はグラフィックの記事にたどり着いて、
全然わからないところで、要はわからないという話で、
PCウォッチはそれに対して、ダルビッシュ選手でも分かるように説明した記事をあえて書くという事態に発展しまして、
そこからさらにダルビッシュ選手が分かったと。
何となく分かったと。ちょっと分かりやすかったと、みたいな話で、
私的にダルビッシュ選手は、ゲーミングのPCを買いに行くという。
謎すぎですね。
経緯まで至っているという感じですね。
結局買ったんですね。
結局買ったらしいですね。
買って、今頑張ってPCを起動させている最中みたいな。
ゲームやるんかな?
ゲームやるんじゃないですかね、やっぱり。
Eスポーツ?
Eスポーツ。
野球から?
そうそうそう。
という経緯の話ですね。
なるほど。
すげえな。
これでも最初、何でグラフィックボード欲しいって言い出した人がいるの?
分からない。分からない。
もしかしたら何か策略が動いているのかもしれないですね。
すげえな。
そういう話ですね。
これはこの話で終わります。
以上、ダルビッシュの話です。
いいですね。何にでも興味を持つ感じで。
でも何かあれですよね、ケイン小杉とかも。
ケイン小杉はね、有名ですね。
めちゃめちゃガチの方なんで。
あれ、笑えるよね。
何だっけ、チャンネル登録みたいなのをするとさ、パーフェクトボディ、
あれめっちゃウケるね。
そうなんですか?知らない?
自分のスタジオとかすごいですからね、マジで。
なんか椅子のゲーミングチェアのCMしてるのは知ってるんですけど。
知ってる知ってる。
そうなんですね。
ダルビッシュのその椅子そうなるかもしれないですね。
もしかしたらいきなり、Eスポーツ業界に参入してくるかもしれない。
恐ろしいですね。反射神経良さそうだもんね。
やっぱ資金はあるんで。
本気でやったらそこそこのとこ行きそうだから。
そこそこのとこ行きそうですからね。
そうですね。
面白いですね、ダルビッシュのセットアップしてる感じ。
03:03
超PCに多分、割とそんなに初心者ぐらいの方だと思うんで、
割と色々ツノつけながらセットアップしながら、
画面ちっちゃいよとか言って、
表示がちっちゃいのこれどうすればいいんだとか言って、
ずっとやっているという。
フォローしたくなりましたね。
なるほど、こんな事件が起きてたんですね。
はい、なのでこの展開見守りたいと思います。
はい。
じゃあ次行きますね。
なんかこの本の紹介なんですけど、
キャリアスキルっていう、
これ前にちょっと多分読んだ方は、
菅谷さんとか読んでたと思うんですけど、
ソフトウェアスキルを書いた方の、
次キャリアの話を書いた本があって、
これが結構思った以上に面白くて、
結構リアルなことを書いてるというか、
ソフトスキルも結構リアルなことを書いてあったと思うんですけど、
それがいいのかどうかはちょっと別として、
ただこのキャリアスキルに関しても、
結構リアルなことを書いてあって、
今後ソフトウェアエンジニアのキャリアを目指す人にもいいし、
今ソフトウェアエンジニアで、
さらに次のキャリアを目指してる人っていうのにも、
割と参考になるんじゃないかなみたいな話を、
結構いろいろ書いてあるところではありますね。
ただ結構言ってることは偏ってるところもあれば、
正しいところもあるんで、
全て真に受ける大変なことになりそうなっていうのはありますね。
なんかソフトスキルって最終的に不動産投資するって話だと思うんですけど。
そうそうブログ書いて不動産投資するみたいな。
で、エグジットするみたいな。
これ何書いてるんですか?
これは結構まだ最初の方読んでるんですけど、
割とソフトウェアエンジニアになるためのルートがいくつかあるよねみたいな話をして、
プログラミングスクールに入るとか、
ブートキャンプに入るとか。
そっからってことですね。
そうそうそういうところからちゃんと綺麗に書いてあって。
なるほどね。
ただこれ作者の方がいるのは海外の環境なんで、
日本に全てマッチするかっていうと、
例えばブートキャンプとかあんまりないし。
ないですね。
ないんで。
プログラミングスクールは今乱立してますけど。
今乱立してますから。
まあそういうところはありつつも、
基本ベースとする考え方とかは結構共通とか多いんで、
そこはかなり参考になるかなという話ですね。
SESに入るとか。
それは書いてなかった。
上級先のSESで揉まれるとか。
でもソフトウェアエンジニアになるんだったらこういうことを考えながら、
06:01
そもそも始めるのがいいよねとか、
最初のプログラミング言語をどうするのかみたいな話とか。
そんなのどうでもいいみたいな。
そもそも何が作りたいんじゃみたいな話から、
そのプログラミング言語を選んだ方が今の時代とマッチしてるよとかいう話とか。
確かにね。
まあそういうなんか結構いいことはいろいろ書いてあるんで、
ただこれ結構分厚いんですよ多分。
これKindleで読んでてもかなりページ数あるなっていう感じで。
紙の本で832って書いてある。
日本版で668ページあるで、
かなりそこ分厚いんですよ。
やばいね。
章もかなり細かいので、
気になるところだけ読んでみてもいいんじゃないかなと思いますね。
これ評価めっちゃすごいですね。
みんな5か4。
エンジニアなら買って損なし。
読んでいて元気が出てくる。
そんな感じがしますね。
元気が出そうだなっていう。
やる気になる。
ただ分厚すぎるんで最初に手に取んでたのがこれっていう感じがしますね。
ただこれはなんか、
例えばソフトウェアエンジニアをやりたいっていう感じの人が、
ソフトウェアエンジニアの方とかに紹介されたら、
最初の方の章とか読んでみると、
ソフトウェアエンジニアってこういうことをやってるんだろうなとか、
っていうのは分かりますかね。
コーディングブートキャンプの話とか、
インターン話とか、
それこそ履歴書を書く話とか、
どういう履歴書を書けばいいのかとか、
そういうすげえ細かいところからいろいろ書いてあるような感じですね。
そうそうそうそう。
なんかこの本を振り返って読んでみて、
さっき話したプログラミングスクール話もありつつ、
いろいろ振り返ってみて、
ジーモン・ピョパモのアンチポさんが、
プログラミングスクールへの期待と提案についてっていう記事をここ最近出したんで、
それも読んでて、
プログラミングスクールっていい面もあるわ、
あまりに問題になっている面もあるといえばあるんで、
そういう意味でアンチポさんが書いたと思うんですけど、
確かにいろいろプログラミングというかソフトウェアエンジニアみたいなところへの希望と、
それに対するギャップというか、
環境の問題もあると思っていて、
自分がソフトウェアエンジニアになったときって、
どういう経緯とかどういう体験だったかなっていうのを思い返して、
いろいろこういう本を今また読んでるっていう感じなんですよね。
あとは単純にキャリアとして、
例えば自分がそれなりにやってくると、
シニアソフトウェアエンジニアとかいう枠組みに入ってきたときに、
09:02
それなりに自分では自立してはいると思うんですけど、
ジュニアの方とかこれから入ってくる方を成長させるっていうところにも、
個人的には貢献したいなと思ってるんで、
そういうところも考えると、
やっぱりこういうものとか読んで、
どういう道を100%正しくないかもしれないけど、
示せるかっていうのは、
それなりに自分なりの答えを持っておきたいなと思ってるんで、
こういうのを割と読んでるっていう感じですね。
偉いっすね。
その一言。
ジュニアのエンジニアとかも頑張れってしか思わない。
結論頑張りなんですけどね。
結論頑張りなんですけど、
それに対して手助けできればいいかなとかは考えてはいますね。
結局業界全体が盛り上がらないと、
その後死んでしまうので、産業自体が。
個人的に技術的に得意としているアンドロイドの業界とかって、
新規参入で若い人が入ってくるような波が最近少ないかなとか、
そういうことも感じているんで、
そうなるともうちょっと新しい人を入れたいんだけど、
どうすればいいのかなとか、
そうなると採用するときにも、
今までだったら結構経験のある方が普通に採用できたと思うんですけど、
そうじゃなくて普通にこれからまだジュニアと呼ばれるような、
過ぎる説と思った人も、
採用しなくちゃいけないことがあるかもなって考えたときに、
どう成長させればいいのかなとか、
そういうことを考えることはあるんで、
なので一応色々見ているっていうのもありますね。
あと単純に自分も、
アプリケーションという領域、
いわばアンドロイドアプリケーションという領域では普通にできますけど、
ウェブの領域に行ったりとか、
例えば極端な話、組み込みに行ったりすれば、
もうジュニアレベルだと思うんで、
そうなったときにもう一回自分がそういう立場になったときに、
どう勉強すればいいかっていうのは、
常にアップデートしなくちゃいけないなと思ってるんで、
そういう観点でも常にどう学べばいいかというか、
そこら辺の感覚値っていうのは色々アップデートしてるっていうのがありますね。
どうですか、お二人は。
そうですね。
なんか自分も今インフラやってるんですけど、
インフラに入ると全く全然分かんないから、
最初から学び直してるって感じなんですけど、
それに対して明確な、
キャリアパス的にどうなのかっていうのを考えたことはないですけど、
やりたいものをやってるって感じなんですよね。
なるほどね。
やりたいものっていうか、
必要だからこれやった方がいいよねとか、
12:01
これ今来てるけど、
これ勉強しといた方がいいよなっていうのをやっていこうかなみたいな、
それがエンジニアとしての生存するにもなればいいかなみたいな感じですね。
僕がやりたいことはもう、
ここ10年ぐらいずっと変わってなくて、
自分でサービス作って自分でこう飯を食うっていうのはやりたいんですけど、
何もしてないっていう。
何もしてない。
そういう意味だとキャリアスキルに書いてあったんですけど、
締め切りを決めろと。
ちゃんとスケジュール決めろみたいなのが書いてあるんですよね。
そういう意味ではもうスケジュール的には締め切り全然過ぎてますね。
スケジュール引き直したらいいですね。
そういう結局キャリアスキルに書いてあるのは結局、
自分が踏んできたアンチパターンみたいなところもあると思うんですよね、きっと。
自分がやってきて、結果的にスケジュールとか目的を決めなかったからこそ、
ずっと1年間ぐらい謎の勉強をしていたとか。
たぶん著者自体の経験っていうのもかなり入っていると思っていて、
そういうのも結構見えるんで、やっぱり面白い本ではありますね。
最終的には不動産として。
そう、不動産として。
最近YouTubeやってるらしいですからね。
マジで?
YouTuberになったの?
手広いね。
でもある意味いいんじゃないですかね、生存戦略的には。
僕らもポッドキャストやってるからね。
だいごも言ってたしね。
副業しろって。
知らない?
だいごに影響されてる?
メンタリストだいご。
あ、そうなの?
そんなこと言ってんの?
言ってる言ってる。
だいご知らないですか?
知ってますよ。
だいごのYouTube見た方がいいですよ。
それ勝馬和夫と同じ流れじゃん。
勝馬和夫の次はだいごです。
ドルコスト平均?
だいごはもっと自己啓発的な感じなんですけど。
前ツバで聞けばいいんだけど、
1000万プレイヤーになりたいんだったら副業しろって書いてあったんで。
副業はない。
だいご的には。
副業は副業ですね。
セブンイレブンとか。
YouTubeとか?
UberEatsとか。
UberEatsの下請け流すとか。
UberEats、それちょっと後で話しますわ。
何か言いたいことある。
プログラミングどう学んだかなって考えたときに、
僕は経歴的には都がやっているプログラミング、
要は俗に言う職業訓練校みたいなところに1年間通ってプログラミング学んだんですけど、
そこは結構国とか都がやってるから、
15:00
割とカルキュラムとか古いんですよね。
初期はC言語から始まって邪魔に入るんですけど、
手でフローチャート書いたりとか、
手でC言語書いたりとか普通にやってたんですよ。
これが当たり前なのかなと思ってやってたんですけど。
脳内コンパイル?
そうそう。脳内で書いて、
社員に打って、
あ、エラーになったわみたいな。
ここダメだったみたいな。
普通にやってたんで。
計算機資源が貴重な時代の。
そうそう。
それが完璧に良いか悪いかっていうのは人によると思っていて、
僕は結構それが肌に合ってたんで、
全然良かったなと思うんですけど。
そういうとこに行った時に、
コンピューターシステムの基礎っていう本とか、
リンク貼ってるんですけど、
こういうの抜かされたりして、
超分厚いんですよ。
辞書みたいな。
多分コンピューターサイエンスの本でもなくて、
コンピューターの歴史みたいなのとか。
ある程度コンピューターサイエンスの内容も入ってるんですけど、
それこそ昔のメインフレームの話とか、
とかも書いてあるようなものを渡されて、
それを暇あったんで、
ちまちま読んだりして、
そんな感じで学んできたんで、
そういうところが良かったかなと思いますね。
今の、やっぱその頃ってまだプログラミングがそんなに、
僕が学び始めたのって、
ちょうど7、8年前だったんで、
まだプログラミングスクールとかってあったかもしれないですけど、
今ほどにはやっぱり追い明けになっていなかったというか、
そうっすね。
とは思うんで。
なので、
ある程度結構場所、
学ぶ場所としても厳選されていて、
選択肢が少なかったんで、
こんなもんかと思ってたんですけど、
これからプログラミングスクールとかいっぱい出てくると、
選ぶほうが大変だろうなっていう。
どこで学んだらいいのかなとか、
どういう教材が。
教材がいっぱいあることっていうのは、
いい面もあれば悪い面もあると思うんですよね。
どれ選んでいいかわかんねえとか、
そういうのもあると思うんで、
そういうところに対して、
いいベストプラクティスみたいなのが提示されれば、
産業的にはいいだろうなとは思ってますね。
プログラミングのスクールって、
ここ2、3年とか、
1、2年とかで、
一気にめちゃくちゃ増えてきた印象があるし、
あとはTwitterとかいろいろ見てると、
プログラミング学んで年収1000万みたいな。
ありますね。
広告とかひどいですよね。
副業の広告とか、
転職すると運100万円上がるとか、
お金貸してみてよみたいな。
広告が多いですよね。
入り口がそういうふうになってきてるんですかね。
僕別に、金がめっちゃ稼げるから、
エンジニアになろうと思ったわけじゃなくて。
そういう感じだった?
いや、俺はなんかもう、
世の中パソコンだろうみたいな。
世の中パソコンだろう。
18:01
俺中学生ぐらいの時に思って、
じゃあパソコンやるなら、
もう無くならないから、
絶対ソフトウェア的な話になるから、
プログラマーだなみたいな。
なるほどね。
マーク&リーセンのソフトウェアが世界を食ってるみたいなのを、
中学生的に悟って、
その道に済んだっていう。
わかんないけど、
ファミコンやりながら思ってた。
ファミコンやりながら思ってた。
僕もプログラミングを学んでる最中に、
色々考えた時に、
お金のことっていうよりも、
何を作りたいかとか、
どういう世界観を持ってるかっていうところを、
メインとして結構考えてたんで、
僕、正直最初は計算エンジン作りたかったんですよ。
プログラミングを学び始めて、
C言語とか色々やってる最中に、
何かの表紙で検索エンジンの話を聞いた時に、
単純に作ってみたいなと思った経緯もあったりして、
今でも学んでいるから別として、
自然言語の話とか、
割と興味あったりとか、
検索の話とか興味あるんで、
そうなってくると、
そもそもお金というよりも、
初期に何を作りたかったかなっていうところが、
結構ベースになっていて、
そこから結構色々学んだりしているかなという感じはしますね。
なので学校で学んだのはシート邪魔なんですけど、
その頃から検索エンジンやるには何がいいかなと思って、
周りの言語を調べたりとか、
あとなぜかその時多分Rubyと出会ったんですよね。
何かの表紙でRubyと出会って、
Rubyっていうのがあるらしいんだみたいなので、
ちょっとやってみたりとか、
それこそアセンブラやってた時期もあったんで、
謎だったんですよね。
多分同翼だったんで、
すごい色んな言語を触ってみたりとか、
自分のWindows PCにOpen COBOLっていうのを入れて、
COBOLを動かしてみたりとか、
謎だったんですけど、
そういうことをずっとやってたんで、
でも結局そのベースにあるのは、
何か作りたかったかなっていうところが大きかったんじゃないかなみたいな。
何も作りたいものがないまま、
やっぱソフトウェアエンジニアとかプログラミングって
結構学びづらいのかなみたいな。
やっぱ物を作る仕事だと思うんで、
そこはやっぱベースとしてあるのかなと思いますね。
何か入り口は別に結構稼げそうだって入ってくる。
まあ言っちゃいいんですけど、
多分長く続けようとすると、
そこだけだと何かしんどいんじゃないかなって思う時ありますけどね。
なるほどね。
そうそうそう。
これは結局プログラミングっていうスキルよりも、
ソフトウェアエンジニアとして必要なスキルセットとかって
いろいろあるじゃないですか。
プログラミングだけじゃなくて、
例えば仕様を書くとか、
21:02
思考性とか、
それこそ例えば仕様を考える人とか、
例えば外部とのコミュニケーションする人であれば、
そういう交渉スキルであったりとか、
まとめ役とか、
いわゆるプロジェクトマネージとか、
プロジェクトマネージみたいな観点のスキルが必要だなと思った時の、
どう学べばいいかなって考えた時には、
僕は基本的に本を学んできたんで、
じゃあどういう本を読めばいいかっていうので、
一個一個紹介したりすると時間かかるんで、
一個いい本があってですね、
コンピューターの名著と古典100冊っていう本がありまして、
これちょっと古いんですけど、
ここに紹介されているような本は、
かなりソフトウェアエンジニアを学ぶ上で、
いい本がいっぱい紹介されていますね。
例えば多分、
やっぱり古いところになっちゃうんで、
いろいろあると思うんですけど、
多分ユニックスの哲学とかも入っているだろうし、
あとはいいか悪かとして人間造神話とか、
いろいろ入ったりして、
あと多分、
ピープルウェアとか、
トムデマルコみたいなソフトウェアスキルみたいなところの話とかの本が
いろいろ書いてあったりするんで、
ここに紹介されている本は、
ちょっと試しに10冊ぐらい読んでみると、
プログラミングじゃなくて、
単純にソフトウェアエンジニアとして
物を作っていく上での考え方とか、
趣向性というのがいろいろ身につくんじゃないかなという本で、
これは結構僕は初期の時代に読んで、
ここから本を漁って、
さらに紹介されている本を漁って、
ひたすら読んでいたという経緯があるんで、
これはいいかなと思いますね。
あと結構ソフトウェアエンジニアのプログラミング以外のスキルって、
プログラミングもそうですけど、
まだそんなにベース変わってないかなという感じはするんですよね。
結構過去に書かれたものでも、
今結構通用する考え方とかいくらでもあるんで、
通用しない本もあるんですけど、
通用するものは普通に使えるんで、
古い本だからって嫌いして読まないっていうのは、
機械損失になっちゃうかなと思いますね。
ペーパーバッグめっちゃ安いです。
ペーパーバッグめっちゃ安いと思うんですよ。
Kindleバンドというよりも195円。
そうですね。
買わなくても多分図書館に行ったりすれば、
もしかしたらあるかもしれないんで。
僕は図書館で読んで、
図書館で読んでも、図書館の中から、
この本がいいんだなとか見て書いてましたね。
なるほど。
ちょっと見てみよう。
100冊もあれば自分に合いそうなやつが見つかるし。
100冊もあれば、さすがに1個ぐらいあるんじゃないかなと思うんですよね。
確かに。
そんなこんなでプログラミングを学んで、
これから学ぶ人たちとか、
24:02
自分を踏まえて、
これから新しいものを学んでいく姿勢っていうのは、
大事にしていきたいなみたいなことを、
わりと日々考えている派の人間ではありますね。
確かにこのプログラムってソフトウェアエンジニアって、
常に新しいものを学ばないと生きていけない業種だから、
常に新しいものを読めるとか、
そういう学ぶ意欲がない人じゃないと、
ちょっときついのかなっていうのは思いますね。
常に新しいものを学び続けなくちゃいけない。
仕事の中で学べばいいと思うんですよね。
個人で結構やらなくちゃいけないのかなみたいな、
思っている方も多分いると思うんですけど、中にはね。
でもそうでもないかなっていう感じはしますね。
なるほど。
なんか僕なんかも残された時間が短いんで。
嘘つけない。
なるべく学ぶにしても、
あんまり変わらないものを学ぼうとしようとするところがあって。
あるじゃん、やっぱ変わってないこと。
そうですね。
夫婦的なもの。
変わるタイミングっていうのを掴むっていうのが大事かもしれないですね。
これもう常識変わるぞっていうタイミングで、
変わった後にそのまま変わる前の状態をずっと維持しても仕方ないんで。
例えばプログラミングっていうところで言うと
パラダイムがすごい変わるところって、
例えばネットワークとかレイテンシーだと思うんですよね。
例えばハードウェアからSSDに変わったとか、
そこって実際プログラミングとしてはかなり速くなるし、
速度が速くなる。
あと単純に今メモリって全部乗っかって消える場合もありますけど、
吹き出すとか飛ばすってありますけど、
そもそも全部電源を落としても消えなくなったときって、
だいぶプログラミングのパラダイムとか変わるかもしれないし、
とか考えたときには、
ここがこうなったらこう変わるだろうなとか、
そういうのは結構意識的には考えるといいのかなと思いますね。
なるほどね。
ハードが変わったときに何かが変わるみたいな。
クラウドもそうですし、
全部クラウドになるわけじゃなくて、
やっぱり大半の人が触るインフラっていうのはクラウドになってきたし。
僕が思うのは仮想化の技術が出てきたときは、
これはちょっとゲームチェンジャーの可能性があるって考えるようになって、
例えばDockerとか仮想ドムとか。
そうですね。
ちょっと変わるぞみたいな。
仮想化のレイヤーが増えたときはちょっと注意してます。
注意してる。
確かに。
だからそういう感じの常に見てなくてもいいけど、
これが変わったらちょっとやべえなっていうところの裸を持っている必要はあるかもしれないですね。
その人の立ち位置によると思いますけど、
いる環境とかによりますけど、
でも普通にウェブ技術マンネリとかアプリケーションを作っている人たちであれば、
27:04
そういうのは常に気にしなくちゃいけないかなっていう感じはありますね。
難しいですね。
難しいですね。
答えがない話だと思うんで。
勉強の話とキャリアの話を絡めちゃうと、
なんかすごい自分次第みたいな。
結局はその人個人の問題なんで。
どっちに進めたいのかっていう。
その人個人がどれくらい。
そっちを決めてから勉強した方がいいのか。
勉強してから。
まあでもとりあえず勉強してみればいいと思いますけどね。
やりたかったら。
肌に穴があったらやればいいんで。
不動産の本にも書いてありました。
不動産を買うときどうしたらいいですか。
とりあえず買ってみろって。
まず貯金しろって。
正論すぎる。
正論すぎるな。
正論すぎるな。
確かにね。
とりあえず貯金しろって言われました。
確かにね。
それは貯金がないと買えないですからね。
そうそう。
まず勉強みたいな。
まあでも頭品なしでも買えるぐらい。
それはいいかどうかわかんないですけど。
そこが変わってくる。
そういうことを考えるんだったら
まず貯金しろみたいなことが書いてあった。
確かに。
次の話に行くと
やっぱりプログラミングのパラダイムが
なんとなく変わっているだろうなっていう話で言うと
やっぱりマイクロサービスとか
それに付随するBFFっていう話を書いているんですけど
僕がそもそもBFFをちゃんと理解しているかっていうと
それはちょっと怪しいところなんですけど
そもそもBFFって何中かっていうと
バックエンド
フロントエンドですね。
っていう話で
これ記事をリンク貼ってあるんで
そちらを読むとすごいわかりやすいんですけど
なぜこうBFFが必要になったのかっていう話なんですけど
そもそもBFFって何かっていうと
今までって
例えばアプリ
Androidアプリでもいいんですけど
AndroidアプリがAPIと通信したいときって
普通にAPIサーバーにそのまま直接つなげて
レスポンスをもらって
表示するっていう形になってたと思うんですけど
そもそもバックエンドのAPIっていうのが
ここ最近大きい組織で言うと
マイクロサービス化してしまっているんで
ウェブとかアプリケーションって言われるクライアントから
APIをつなぎたいときに
しかも別にクライアントとかアプリケーションって
あんまり後ろがマイクロサービスになっているかどうかって
意識する必要ないので本来であれば
情報を取ってきて出すっていうところが
メインではあるんで
後ろがマイクロサービスになっているかどうでもいいんですけど
ただマイクロサービスになってしまっていると
クライアント側がマイクロサービスを気にして
じゃあこの情報を取りたい方はこっちのAPI
こっちの情報を取りたい方はこっちのAPI
ひたするとURLが変わるかもしれないですよね
ひたすると
っていう状況をクライアントが選定してるのって
30:01
結構やばいよねっていう課題が
普通に出てくるんですよね
そんな感じの課題が出てきたときに
クライアントのAPI
バックエンドのAPIの間を持つような
レイヤーっていうのを作りましょうって話で
BFFっていう話が出てきているっていう感じの話題ではあるって話なんですよね
抽象化レイヤーですね
そうそうだから抽象化レイヤーですよね
なんでこういう要は抽象化
抽象化1個出てくるとやっぱパラダイムが変わるというか
やっぱ考えることが変わるんで
なのでこのBFFっていうのは
いかんせん面白いなというか
自分が普通やってた環境とはちょっと違うけども
例えばマイクロサービスになっている世の中を考えたときに
確かにこれは必要だなみたいな
納得感があるような内容があったんで
ちょっと面白いなと思った次第でありますね
特にネイティブアプリとかの人たちがよくBFF入れてるっていうか
使ってるイメージがあるんですけど
要はクライアントってiOSかもしれないし
アンドロイドかもしれないし
ウェブのSPAみたいなやつかもしれないし
それぞれで似たようなAPIの書き方みたいなのをするじゃないですか
それをまとめることもできるわけでしょ
BFFがいつの間にあると
そうですね
なんでどっちかというと
BFFがないとやりたいことに対して
APIコールを複数回しなくちゃいけないし
コネクション回して
どれが返ってきたら全部失敗するしみたいな
結構大変な状態なんですけど
BFFがいることによって
それを全部BFF層がまとめてくれて
よしなりにガッチャンこうして返してくれる
っていう形の体験も取れるんで
やっぱバックエンドのAPIがマイクロサービスであればあるほど
絶対的に必要になってくるというか
絶対なく
絶対必要というか
ないと多分めっちゃ辛いよねっていう話になってくるかなと思いますね
じゃないとやっぱ原理APIサーバーの方が
何でも返すAPIみたいなのがどんどん生えていって
逆にこう辛いみたいなことになるんで
紙API
そうそうそうそう
しかもマイクロサービスにしたらもうそれは絶対できないんで
紙APIを作ることっていうのはできないんで
ある意味紙APIみたいなのがBFFの役割を果たすみたいなのはありますね
これBFFって誰の責務になるんですか開発的には
クライアント側の人がやるんですかね
そういう話をよく聞くんですけど
確かにそこの責務の切り分けはすごい難しいような気がしますね
誰の持ち物なのかなみたいな
確かに
クライアントのエンジニアができるんだったらやってもいいと思いますけど
なんかそれをBFFとか聞くとよくクライアント側の人がノードでやってますみたいな
33:00
JSだからそんな変わんないじゃないですか
みたいな話をよく聞くんですけど
そのBFF層に使う技術っていう選定は難しいとは思っていて
大体ノードか
ノードっていうか要は非同期でいっぱいAPIを走らせて束ねる
手返すっていうところの技術がいけてるようなフレームワークとか
プログラミング言語じゃないとダメなんで
要はノンブロッキングと言われるようなノードだったりとか
Javaであれば似たような仕組みがいろいろあったりもするんで
っていうところの技術選定っていうのは難しいところもありますねBFF層って
ノードってどうなってるんですか
あとはWebのほうが
これなんか僕社内では一応BFFって言っているんですけど
要はナクストのサーバーを立ててBFFって言ってるんですけど
いかにこれがBFFなのかどうかっていうのは
僕ちょっともうちょっと詳しく見てみないと厳密には分からないなっていう感じはしますね
サーバーサイドレンダリングしてるんで
それがBFFなのかっていうとそれはそうじゃないだろうしみたいな感じもあるんで
ノードのアプリに関しては特にBFFみたいなのなくて
普通にAPIサーバーがRailsのモノリシックなAPIがあるんで
それと直接通信をしているって感じですね
そもそもマイクロサービスじゃないんで
そういう必要性は感じていないっていう
メルカリみたいな感じになると
なると必要になってくるでしょうね
きっと今僕がいた頃のメルカリに関してはそういうのなかったですけど
多分今はそうなってるはずです
マイクロサービスやってるんで
きっとアプリとバックエンドのAPIの間には
BFFみたいな層がきっとあるんだと思います
想定としては
じゃないとやっぱ厳しいかな
なるほど
マークさんとか
あれですね
普通にフロントがNUXTでバックエンドがRailsみたいな感じなんで
モノリシックなRailsのAPIがあって
なんで
これBFFがあったら
今っていろんなAPI叩きまくってるんですよねバックエンドが
いろんな別々のサービスを叩いて
じゃあまさに必要なやつじゃないですか
そうですね
これめっちゃいいなと思って
バックエンドの中でもパフォーマンス出るんですかね
BFFの中間の中小レイヤーの
サーバーのパフォーマンスが遅いと
フロントまでのレスポンスがめっちゃ遅くなりそうな
そうですね
イメージなんで
だから非同期のやつでやんなきゃダメなんですよねきっと
そうですね
同期処理だとめっちゃ遅くなると思う
めっちゃ遅いですよね
めっちゃ遅いと思いますね
BFFを作る設計っていうのもまた
別で考えなくちゃいけない
36:01
とは思いますね
うちもレポートのAPIとか
いろんなマスターを作るAPIとかいろいろあるんで
こういうのがあったらめっちゃ便利そう
そういう話ではありますね
なのでもうちょっと詳しく学ぼうかな
結局どこで頑張るかって話じゃないですか
そうですね
クライアントで頑張るのかサーバー側で頑張るのか
クライアントで頑張るのはかなり厳しいと思うんですけど
それでこういう形になってるんですねきっと
完全に仲介するだけですもんね
ビジネスロジック的にはもうAPIが責務を持って
返してあげるっていうことですよね
これでもやばい作り方もできるじゃないですか
BFFがデータベースを持つみたいな
そういうのもやばいです
それBFFなんかみたいな
アンチパターンとかもすげえあるけど
ありそう
今後できるようになるきっと
BFF層がさらにDBを使って保存とか持ってるみたいな
やばいなみたいな
とかはあるかもしれないですね
恐怖ですね
恐怖ですね
なんかインフラがすごい複雑に
でもそっかエンドポイント
BFFの記事で言うと
Cookpadが似たようにやってる記事が
すごいわかりやすかったんで
多分それをリンクに貼っておくといいかなと思いますね
要はAPIの入口に
リバースプロクシーみたいなの置いてとか
ロードバランサー置いてとか
いろいろやってるらしいんで
その記事を見ると多分いいんじゃないかなと
思いますね
あとは話題としてはちょっと飛ばして
ここからはもうゆるい感じで
ゆるい感じのネタをいくつか置いてあるんですけど
RPA化が人権意識で吹っ飛びましたっていう
これ面白かったんですけど
RPA化ってそもそもわかります?
知らないです
聞いたことない
これ僕もなんとなくなんですけど
要は手動でやってる仕事っていっぱいいるじゃないですか
でもソフトウェアの自動化みたいなので
なんとかできるよねみたいな
なんて言ったらいいんだ
それこそ変な言い方にすると
働き方書くみたいな
自動化してなんとかしようぜみたいな
バックオフィス系をテックで解決しようみたいな
だからRPAってロボテクスプロセス
オートメーションの役なんですよね
役で超雑に言うと要は自動化しろよって話
ソフトウェアで自動化しろよって話なんですけど
岡野さんが好きなザピアとかも
まさにRPAと言われる
39:02
RPAなのかなって思いますけど
RPAの一部とよく言われる
何ならExcelのマクロとかもRPA
そういうことね
っていうのが要は人権意識で吹っ飛びましたっていうのは
要はそういうことすると
要は雇用がなくなる人がいるだろうみたいなとか
こういう手作業一個一個にも
人の温かみみたいな話をしたりする
分からんでもないけども
この記事でもまさしく正論書いてあるように
そういう面倒くさい仕事がなくなることによって
もうちょっとクリエイティブな仕事ができるようになるでしょ
別の仕事ができるようになるから
そっちが本質的じゃないって話はしてるんですよね
僕も例えば社内でザピアとか使うときにも
同じようなことを言うんですよね
要はあなたの時間はすごい大事なんで
できるようになることにもっと時間を使いましょうと
定期的にやってるつまんねえなみたいなとか
これ今日もやるのかみたいな作業は
やっぱり自動化しましょうって話はしていて
多分それに対して人権を
人権ってすごい大きいワードを持ってきて
RPAの案件自体が沸騰になってる話が
この記事になってます
めちゃくちゃ面白くて
でもこういうのあるんだなっていうまさにきっと
アクションであったとしても
多分本当にこういうことが起きてる現場っていうのは
あるんだろうなと思って大変だなと思って
なんか日本的な感じもシムアックもないけど
人権出されたら止めざるを得ない
でも本来大事な仕事に時間を費やす方が
すごい大事だと思うんで
そこに対しての意識はないのかなみたいな
論点が違う気がする
人権意識とRPAかで
かといってみんなそうすればいいかっていうと
そうでもない気がしていて
いろんな人がいるんで世界って
だから次新しい仕事したくないっていう人もいると思うんですよ
新しいことは学びたくないし
この作業やっていればずっとお給料がもらえるし
これで満足してみたいな人もいると思っていて
そういう人をどうするのがいいのかなというか
その人はそのままでいいのかなみたいな
難易度ポイントがあると
それを大きく膨らませると人権になるのかなみたいな
俺はダメだと思う
だって世の中AIで駆逐されるんじゃないかっていう
まずは手前の段階でそういうことになっちゃうと
結構あれなんじゃないかなと思いますけどね
なんか残された時間が結構ある人だったらまだ
ちょっと変わろうかなって思うけど
50過ぎぐらいから
お前の仕事いらないわとか言われたら結構きついかなって
思う時はあるけどね
42:01
銀行だって窓口来ないでほしいから
窓口の人たちを結構レイオフするみたいな
らしいですね
だから窓口よりもインターネットしかやらないから
オン・ザ・カウンターもいらないんじゃないみたいな流れじゃないですか
貿易のやつだって
仕分けとか完全にAIとかで自動化で仕分けしてくれるから
結構こう言ってる人たちもいいけど
背後には結構もっとドラスティックな改革が進んじゃうんじゃないかみたいな
一気にみたいな
恐怖はないのかな
確かに銀行とか行くと窓口まで行けないもんね
ウェブでやらせますもん
リバースプロキシみたいなおばちゃんがいて
まずATMでできるからみたいな感じでそっちに流される
一旦流してからみたいな
たどり着けないです
多分そうなってるんでしょうね
オペレーション的に
だから何でも自動化すればいいやって感じではない
自分の働いてる範囲内であれば
できるだけ自動化した方がいいですよって話はするんですけど
人類全体で考えた時には色んな課題があるなと思って
人類全体で考えた時には女子号でかくなりますから
なんかありそうですよね
いやーマークさん大きい話つけようと思う
僕結構子供のこと考えるんですけど
じゃあ20年後15年後とか20年後とかに
子供が社会に出るってなった時に
どうなのかなみたいな
何やらす時がいいのかなみたいな
プログラムだって怪しいもんですよね
こんなIFとROOPで
IFと4と変数みたいな
できる世界が
イントとストリングみたいな
パズルできるやつができる
銀行の窓口になりたいとか言い出したらさ
全力で止める
だったらYouTuberの方が
YouTuberとかでそっちの方がいいと思うよって言っちゃうもんね
そうね
僕からの場合はそんな感じですね
いやー難しいですね
マークさん何でも難しいですねって雑にまとめ
まとめ難しいですね
ちょっと思考停止の合言葉
難しいですね
