00:00
♪
はい、今日はノーモライズFのFMの第5回になります
本日はですね、私からすると結構最初は雲の上の人だったんですけども
そんな方が今日はゲストに来てくださっています
今日のゲストはですね、ICSの池田さんに来ていただいています
池田さん本日はよろしくお願いします
はい、よろしくお願いします ICSの池田と申します
はい、えっとま、えっとウェブのフロントエンドのリスナーさんであればね
まあまず間違いなくご存知だと思うんですけれども
今日は色々なそのウェブのフロントエンドに関するトピックなどなどね
聞いていけたらいいかなと思っておりますので
早速始めていきたいと思います
♪
はい、でまず最初になんですけど
一応簡単に、まあ池田さん絶対あのみんな知ってると思うんですけどね
一応簡単にその自己紹介などしていただいてもよろしいでしょうか
はい、わかりました
では改めまして池田と言います
私自身は株式会社ICSという
東京の港区にあるウェブ製作会社の代表をやってます
ウェブ製作はそうですね、16、7年ぐらい
社会人になってから続けていまして
今はあの主にフロントエンドの開発を見る
テクニカルディレクターという形で
色んな案件に携わってます
主に業務系のシステムみたいなところであるとか
その3Dを使うようなもの
一部はゲームであったりだとか
あとちょっとクリエイティブ向けなウェブサイトを作ったりだとか
なんかそういったところを基本的に
ウェブの技術を主体的に使いつつ
その中で基本的に受託制作にはなるんですけれども
幅広くコンテンツを作っているというような仕事を普段やっています
あとICSメディアというオウンドメディアもやっていて
ウェブに関するHTMLとかJavaScriptとかの
新しい技術のこういうものが出てきたよっていう紹介したりだとか
こういう設計手法があって
こうやると問題解決につながるんじゃないかとか
そういうことを会社で
情報を取りまとめて発信するということをやっていて
その編集上もやっています
これが自己紹介になります
ICSメディアは本当に
いまだに私もよくお世話になっていて
ありがとうございます
03:01
非常に1回出した記事を定期的にメンテされているというイメージがありますね
ICSメディアは
そうなんです
昔アクセス数が増える記事って
年月が経っても
意外とGoogle検索結果から落ちなかったりするんですけれども
その時に昔の記事が
たどり着いたユーザーさんが
手順通りだったけど動かないみたいなので
自分自身も困ったこともありますし
多くの人も困っているだろうから
ICSメディアでは古い記事もちゃんとメンテナンスしようという方針を取っていて
新しいバージョンアップであるとかそういうのを推進していって
いつでも役に立つ記事をいつも心がけてやってますね
それが本当にすごいな
私も小さいながらもメディア的なものを自分で運営している立場からすると
過去の情報を定期的にメンテするのってすごい大変なんじゃないかなっていうふうに
自分としては思っちゃうので
それを続けられているっていうのが本当にすごいなって
普段見てて思ってますね
Webpackの最新版の設定だとこれがいいですよみたいなのとかも
結構しっかり書かれてるじゃないですか
多分あれに救われてる開発者の人たち相当いるんじゃないかなって
見ながらいつも思ってましたね
そうですね 特に開発環境周りの話
Webpackも 例えばGulpとかもそうなんですけれども
ちょこちょこバージョンアップで破壊的変更が入ってくるので
そういった時に
だいたいGoogleも意地悪くて
検索したら結構古い方がウインキ期待するんですね
これはどちらかというと編集長としてのモチベーションの話になりますけれども
そういう古い記事で困る読者の方がいたら悪いだろう
だから我々はGoogleにも認められるように
上の記事になるようにちゃんとメンテナンスを
少なくともアクションとしてはやっていこうというふうに思っていて
そういうところもモチベーションとしてあったりするんですけれども
ユーザーが困らないようにというのが一番のモチベーションですかね
あれは元の記事を書いた人たちが定期的に見ているという感じなんですか?
基本的なスタンスはそうですね
ただどうしても仕事の都合上できなくなったりだとか
会社なので退職する社員とかもいたりするので
そういったところは他のメンバーが引き継いでやるというような形でやってます
すごいな
本当にすごいです
最近タイプスクリプトで環境を作りたいなと思って検索したら
まさに一番上にボンと出てきてすごい助かりました
ちょうどリーチできたのかなというので嬉しいですね
この収録するお約束はさせていただいてたタイミングで
そういうことがあったので改めてすごいなというふうにね
偶然だったんですけど思いました
06:01
前にチラッと聞いた話
たぶんたしか池田さんから直接聞いたんだったと思うんですけど
3JSの記事とかも新しいリビジョンが出たらそのリビジョンに合わせて
ちゃんとビルドをもう一回通してみてみたいなこともされてるっていうのを
昔上がったことがあったような気がしていて
そういうの本当にすごいなって思いますね
今もそういう感じでやられてるんですか?
そうですね3JSは特に思い入れのあるライブラリみたいなところはあったりするんですけれども
新しいリビジョンは毎回じゃないです
さすがに毎回はちょっとできてないんですけれども
少なくとも1ヶ月2回ぐらいのペースで
新しいリビジョンにとりあえず上げて
全部スクリプトでピッてやればバージョンは勝手に上がるように作っていて
チェックするときもこれはどうしても目視で
WebGLなので目視で確認しないとわからないこともあったりするので
それで目視で見てチェックするみたいなことをやってるんですけれども
割と反自動的にできるような仕組みにはしてますね
いやーすごいですね
なんか最近だとジオメトリークラスがなくなって
バッファージオメトリーだけになったりとかしたんで
そういう時に結構ああいう記事ってすごい影響受けるのかなって思ったりもしたんですけど
全部直しましたよ
プレインジオメトリーとか中身はバッファージオメトリーに全部変わっちゃいましたから
私ジオメトリーいじいじするの大好き派だったので
3JSとかのラッパーしたライブラリ上だと大体
ジオメトリーって簡単にいじれるように作られている設計
これ多分PIXYJSもそうだったと思うんですけど
3JSがそれをやめちゃったので
もう動かなくなるサンプルたくさんあってこれは困りましたけどね
やりましたよと思って
そこまではもう地道に手で直していく感じだったんですか?
そうですね一個一個やっぱりもうクラスのライブラリ名
クラス名自体は同じで中身がごそっと変わった系のやつだったので
これは手で直すしかなかったかなって感じですかね
すごいな本当にすごいですね
ICSメディアの部分はお仕事の範疇でもありつつだと思うんですけども
純粋な組織として住宅で開発している部分で言うと
なんかあんまり完全に私の個人的なイメージになっちゃうんですけど
あんまりその代々的にこれやりましたっていうのは
あまりICSさんの場合は外に出てこないようなイメージがあるんですけど
なんか言える範囲でもちろん構わないんですけど
最近こんな仕事でこんなことがあったよみたいななんかあったりしますかね
そうですね
Webサイトコーポレートサイトとかを最近
今年になってからよく作ってまして
TYOさんのコーポレートサイトなんかが特に新しい事例になりますね
ICSのWebサイトでもちょっと最近事例紹介って形で載せましてですね
09:00
URLはICSweb.jpに載っているんですけれども
事例といっても確かに我々の会社ってあんまり出しにくい案件をやっているみたいなところ
これも山田さんの会議の時もあったと思うんですけど
やっぱりなかなか日本の企業は出しづらい
いろいろなものがあったりとかしてですね
その影響を我々も受けてたりするんですけれども
その中で最近今年になって
スタジオディテールさんとよく一緒に仕事するようになってですね
そこでやった仕事なんかをこちらの実績として紹介載せてます
先ほど紹介したTYOさんのサイト
というのはこれもWebGL 2Dの範囲なんですけど
WebGLを使ったりとかして
動画とマスク表現と組み合わせで動かすみたいな感じで作ったサイトでした
結構じゃああれですか
普通のいわゆる受託もやりながら
例えばゲームとかってなってくるとちょっとまた経路が違うというか
同じフロントエンドとは言っても
ちょっと普通のコーポレートサイトの受託開発とはやっぱりちょっと違うじゃないですか
やってる内容が
違いますね
その辺は別にこういうのじゃなきゃやらないみたいなのは
堅苦しくは考えずにニーズに合わせてやっていくみたいな感じなんですか
そうですね
正確に言うと私は一応会社の代表という形でやっているので
案件のバランスみたいなところは考えていて
それは一つは社員のモチベーション
こういうこともやってみたいということであるとか
会社としてどっちの方向に成長させたいのかみたいなところを考えて
案件受注
そのコーポレートサイトもやるし
もう少し固いシステム側の案件をやったりだとか
ゲームのやつとかちょっとバランス見ながら
研究開発的なものとか
それもちょっとバランス見ながらやったりするんですけれども
でもなんか一個に固まってしまうと
ちょっとやっぱりウェブ制作のなんか標準というか
日本の制作市場の空気を知らないままになってしまうというのは
一番恐れていることで
ここはまんべんなくみんなの経験値が上がり
バランスよく上がるような仕事を受け持つという形で
よくやってますね
なるほど
なんかそういうの
私の場合は結構一人だけの会社の代表という感じなんで
その辺の悩みがあんまりちょっと
自分自身では体験したことないんですけど
なんかすごいその
従業員のモチベーションとかも考えて
事業を選択していくっていうのが
なんかすごいですね
なんかそういうことまで考えてお仕事できるっていうのは
池田さん自身にとってもいいことだと思うし
その組織に所属されているスタッフさんたちにとっても
すごくいいことですよね
そういうふうに自分の要望が
気軽に声に出して言えるっていう
ちゃんとした会社の雰囲気作りとか
そういったところもちゃんと下地にあってのことなんでしょうけどね
12:04
やっぱり社員もやっぱり
うちの会社で10名ほどいてですね
全員エンジニアなんですけれども
エンジニアってやっぱりどうしても新しいものに注目するというか
そこにやる気を持ったりとかしたりするわけで
ちょっとやっぱり古い案件をずっと
保守的なこともやったりするんですけれども
何かこの新しいこともチャレンジできるっていうのが
根底のモチベーションやる気につながっているところは
結構あるなと思っていて
そうですよね
そのあたりのバランスにいて
引き受けるかどうかっていうのをよく考えてますね
なんかいいな
私なんかは結構一人でやってるから
なんでも自由になるでしょって結構
自分では思ってたんですけど
いざやってみると意外とやっぱり
そんなに選んでる余裕がないっていうか
逆に自分一人でしかやれないので
自分がサボればそのまんま売上が立たないっていう
現実がただ襲ってくるだけだから
自分のやりたいものだけやってるわけにもいかない
みたいなところがちょっとあったりもするのかなと思うんですけど
でもすごくいいですね
なんか組織としてもすごくいい状態なのかなっていうのが
お話を聞いている中でなんとなく感じましたね
いやーすごいな
ありがとうございます
あとはちょっと私の方から何個か聞きたいなと思っていたことがありまして
ちょっとサクサクとそのあたりを聞かせて
質問させていただこうかなと思うんですけども
最近結構大きめなところで
Safariが割と大きな変更があったと思うんですけど
なんか私なんかはあんまりこうなんて言うんですかね
ちょっと言い方悪いんですけど
Safariはあんまり信用してないというか
意外とバギーな動きをする厄介なブラウザっていうイメージがあって
あんまり細かいところまで追っかけたりはしてないんですけど
池田さんの普段の活動を拝見していると
結構そのアップル関係とかあとはアドビとかですかね
なんかその辺もしっかり追われてるなっていうイメージがあったんで
なんか最近のそのSafariの変更点とかで
なんかこう気になってるトピックとかあったら聞きたいなと思うんですけど
どうでしょう
そうですねSafariがiOS15に搭載に合わせてSafari15が出てきたというところで
iOSも今ここに画面新しいiPhoneと新しいiOSが入ってるんですけれども
下側にアドレスバーが出てくる上側に変更することもできるんですけど
この辺の新しい変化であるとか
あとだいたい世の中Chromeの方が新しい機能で先行していることが多いんですけど
Safariもそれに大半年に1回大きなリリースSafari挟んできますけど
ようやく結構追いついてきたなみたいなところがあったりとかしていますと
15:03
その中でSafari面白いなと思って
常々Safariの進化の時にチェックする項目があって
それがPWAですね
このSafariのPWA毎回チェックするんですけれども
何かというとChromeであるとかFirefoxもそうだと思うんですけど
特にChromeがご利用してるというのもあるんですけれども
PWAがパソコンだけじゃなくスマートフォンでできるようになると
もっと未来が広がるんじゃないかみたいなところで
これがiOS Safariがどのくらい対応しているのかっていうのが
PWAの界隈だと2,3年前くらいからずっとこういう話が出てきてるんですが
これがSafariがちょっとずつ対応を始めていると
すごいゆっくりでは入ってきてますと
今回のSafari 15で面白いなと思ったのが
アドレスバーのところ?じゃないヘッダーのところが
テーマカラーによって変わるという挙動が入ってきて
これがちょっと面白いなというふうに思いました
テーマカラーっていうのはCSS的なもので指定するんですか?
はい これはMetaタグにありまして
Metaのネームカラーというプロパティがあって
それを指定すると今例えばこの画面の中で共有されている
アドレスバーの部分とかヘッダーのウィンドウ閉じるとか
最大化するとかあるここのバーのところ
これが色が変わるという機能が入ったんですね
PWA特有のプロパティというわけじゃなくて
普通の単なるMetaタグなんですか?
そうです これが入ってきた経緯みたいなところは
私はちょっと知らないんですけれども
よく実用的な使い方 Lighthouseとかの採点とかの基準とかにしては
PWAの分類に入っているもので
PWAのmanifest.jsonというのを作るんですけど
それとは関係なくテーマカラーというのをMetaタグで指定することができましたと
これがSafariにも入ってきて
Android Chromeだとテーマカラーというのが結構ドキドキ出てきたんですけど
Safariでも見た目がガラッと変わっちゃうので
これが入ってきたことで
Safariのコンテンツの見方が変わってきたなというのが
今回特徴的な出来事かなと思いました
もちろんPWAというのの最終的な着地点としては
Webアプリがネイティブアプリのような振る舞いをするというところに
一つポイントがあると思うんですけど
その傾向がより強くなったってことなのかもしれないですね
そうですね 体験として一体コンテンツと
UIの透明感といいますか
18:02
アプリケーションに近づくというところもそうなんですけれども
そのコンテンツ自体によりユーザーが集中できるように
みたいなところの流れが強くなったのかなと思いました
デザイントレンドみたいなところには
なってくるのかなと思うんですけれども
ヘッダーがこう見えるようになるから
ウェブサイトのヘッダーの色もそれに合わせておこうとか
そういうデザイン的な工夫が多分今後出てくる
手法として出てくるのかなと思ったりしてですね
そういった意味ではちょっと気になる変化だったかなと思いました
なるほど PWAは結構一時私もちゃんと勉強までいかないですけど
一回自分のウェブサイトに組み込んでみたりとかして
使ったことはあるんですけれども
確かiOSではプッシュ通知が出せないとか
ちょっと縛りがあったような記憶がありましたね
確か前はストレージ的に使える容量が限定されていたり
あとはプッシュ通知のAPIがChromeとかだと出せるんだけど
iOS上だとちょっとそれができないとかっていうのが
なんかあったような気がしたんですけど
その辺は正直多分私も全然覚えてないんで分かんないんですけど
まだ変わってないんですかね
結論から言うと変わってなくて
まだ変わる見込みも出てきてないというのが正直ですね
そこが結構解決すると
やっぱりウェブアプリなんだけど
最終的なエンドユーザーへの提供の仕方を考えた時に
PWAにできたらいいよねみたいなケースって結構あったりするんですけど
その中でやっぱりプッシュ通知が出せないんですよね
とかってなっちゃった時にそこで
じゃあ残念ですけどみたいになっちゃうことが
結構私の体験としてはあって
iOSがそこを対応してくれるといいんだけどなーっていうのが
ずっとあったりはするんですけど
そうですねどうもSafariは広告の対処みたいなところには結構シビアで
おそらく電力とプライバシーみたいなところは結構シビアで
プッシュ通知もサービスワーカー使って通知エリア使うってところもあるんですけれども
電力も後ろ側でどのぐらい使うかわかんないですけれども
後ろ側にずっと待機するって状態になるので
そういったところから政治的というか
iOS全体としての体験からおそらくSafariに制限化してるのかなというふうには思ったりはしますね
なのでなかなか来ないんじゃないかなという気はします
残念ちょっと残念だけどまあでも仕方ないですね
そうですね
まああとちょっと違う観点で面白いなと思ったのが
iPhoneで120Hzのスマートフォンが出てきたってことですね
画面のリフレッシュレートが
21:00
Androidではもうすでにいくつかあったと思うんですけれども
これがiOSでも
iPad Proとかだと少し前から120Hzのディスプレイがあったんですが
iPhoneでも入ってきたということで
おそらく今後のiPhone、次の来年の14とか15とか
もう少しエントリーモデルでも120Hzっていうのが入ってくるのかなという期待もありまして
これがちょっと面白い出来事かなと思いました
実際今池田さんのお手元にあるのは120Hzで動いてるんですか?
そうです
結構違います?
結構違いが出ますねやっぱりぬるっと感が違いますね
普段のスクロールであるとかアプリケーション切り替え
OSのユーザーインターフェースの挙動に関するところは
やっぱりちょっと心地いいなって思いますね
なんかTwitter上でスロー再生で2つ並べて
同じアクションを撮った時にどういう風になるかっていうのを
スロー再生でやってる動画がTwitter上に流れてたんですよ
それは見たんですけど
それ見た感じはかなり違うなって思ったんですけどね
そうですね
単純に違和感になってるっていうところで
おそらくスローモーションで撮られた動画のやつだと
多分スローモーションしてるからすごく分かりやすかったのかなと思うんですけれども
体験上はやっぱり違うかなと思いますが
ただこれ慣れの問題もあるかなと思っていて
iPad Proも私も出た当時120Hzすごいと思って触っていたんですけど
普段毎日使ってると気にならなくなってくるんですよね
iPhoneの方も同様に120Hzであるってことが
あんまり気にならなくなってくると思うんですけれども
ちょっとこれ特にドクザさんのいるタイミングで
やっぱり気になるところはWebGLとの関係性なのかな
そうですね
Request Animation Frameこれやっぱり60Hzなんですよね
120Hzのディスプレイなのに60回で動くみたいな形で
省電力モードにすると30fpsに下がるみたいな形で
だけどAndroidって120でちゃんとRequest Animation Frameは回ったりするんですよね
そうするとじゃあOSレベルっていうよりはブラウザレベルで制御してるんですかね
Request Animation Frameに関しては
それっぽい感じがしますよね
単純にレンダリングするだけだったらそんなにかまわないんですけど
Request Animation Frameで前の計算結果を引き継いで値を変えるみたいなことをよくやるじゃないですか
そこに支障が出てくるのでちょっとこれは難しい問題ですよね
そうですね
なんか結構Webのフロントエンドだとちょっと分かんないですけど
多分ゲームとかああいうまた違ったグラフィックスの世界だと
おそらくフレーム数ではなくて経過時間とかでうまく処理するように組まないとダメだったりとかするのかもしれないですよね
24:03
そうですね
120回でも60回でもちゃんと同じようにしようと思ったら
時間に依存する実装にするしかないですもんね多分
そうなんですよね
絶対時間というかタイムコードというか持っていて
そこに依存して座標位置をそれだけ進ませるとかそういう実装ですよね
なので結構そっちをやるのも面白かったりするんですけど
どうもビジュアルアートとかそっちの範囲だと
前に描いたものをもう一回当たりずらしながらやるみたいなことが手法としては多いですから
そうですね
確かにちょっともともとiPad Proでそれがあったんで
実際必要なところでは皆さん対策すでにされているところはあるのかもしれないですけどね
でもなかなかそこまでやるってやっぱりちょっと大変ですよね
普通のウェブのフロントエンドの一般的なウェブのフロントエンドでそこまで面倒見るの結構大変ですよね
ちょっとさすがに自宅案件とかだと割に合わないと思いますよね
ちょっと割に合わないよな
でもエンドユーザーの目線で考えると悪いことではない
バッテリーが持ちが悪くなっちゃうとかそういうわかりやすいデメリットみたいなのは特にないんですかね
やっぱりあるんじゃないですかね
フレームレートが高くなっている分それを真面目に対応してようとしたりだとか
特にこのiPhoneの上位モデルだと
DPIが3倍だったりして普通の2倍よりも高いものだったりするので
そこでバッテリー食いやすいとか私もiPhone新しいの買って
こういう端末電機で何をはじめにやるかというと
ウェブの技術を使ったベンチマークをまず試すんですけれども
もう熱くなること熱くなること
結構池田さんのベンチのやつは結構みんな見てると思いますよ
いやーそれであればありがたいですね結構初期にスマートフォンが
普及し始めた頃2014年15年ぐらいに作ったベンチマークがあってですね
WebGLとかCanvas APIとか使うそれで当時のスマートフォンだと300ぐらいしか出なかったんですよスコアが
でこれが時間とともにスコアが上がっていく形でベンチマークを取るようにしてたんですけど
この新しいiPhone使うとそれベンチマーク取るのにですね15分ほどかかって
もともと300だったスコアが7万ぐらいまで伸びたんですよ
昔のスマートフォンだと一瞬でベンチマーク終わったのに今のやつは全然終わらなくて10分15分やって
そしたらもうあっつあっつの状態になってしまう
いやーまあでもそうですよねなんかそのハードウェアの進化もすごいですよね
27:01
モバイル端末ももちろんそうですけどデスクトップ用のGPUとかもそうだし
5年ぐらい前っていうと全然なんか世界線がもう全く違うというか
今だったらWebGLで1万2万ぐらいのオブジェクト出すのは全然ヘッチャラですけど
最初の頃はやっぱり万までいくと結構きついなっていうのはありましたもんねやっぱり当時は
ありましたよね確かに
ちょっと不幸な話ではありますけど2000年の前半の頃はブラウザゲームであるとか
HTML5が特に注目されていた時期だと思うんですね
でこの時にWebGゲームコンテンツであるとか
本来この時期にこれだけパフォーマンス出ればもっと市場が拡大していたにもかかわらず
その時不幸にもそんなにスマートフォンの性能が高くなかったから
成功したところもありますけれどもすごく爆発的に入らなくなったのかなと思っていて
ブラウザゲームは今もありますけれどもそんな大きなメジャーではないかなと思っていて
だからそのハードウェアの進化というのもちょっとなかなか
求めている時にはちょっとなかなかまだ来ないんだなっていうのは思いましたね
そうですね 今は結構無茶しても
でもiPhoneはやっぱり何だろう いつも解像度がとにかくめちゃくちゃ高いから
WebGLを走らせるってなるとそれが結構大変だったりもしますけど
そこにさらに120Hzの世界が来たってなると大変だなやっぱり
WebGLを普段触る人間からすると新しいiPhoneだからといって
安心できないみたいなところはありますね
そうですね
一昔前の一昔といっても3年ぐらいとか前の
MacBook Proはレティナディスプレイだったけど
MacBook Airがまだレティナじゃなかった頃とかって
結構そのMacBook Airはレティナディスプレイじゃないから
WebGLが軽いみたいなのがあったんですよ昔
一昔の話だね 市売だからレンダリングの範囲が狭いから
そうですね レティナディスプレイを搭載したProの方が遅くて
ちょっと古いMacBook Airの方が軽いみたいなのが昔はあったりしたんですよね
今後そういうのがモバイルでもちょっと起こるのかもしれないな
あり得るそうですね
なんか220Hzでしかも高解像度だと
多分結構グラフィックス的にはきついってなっちゃうと思うんで
そうすると体感的にちょっと昔のiPhoneの方が軽く感じますみたいなのがあるかもしれないなって
ちょっと思いました今話聞いて
ディスプレイが良くなってもそっちの先生の方が遅くなって
体感としてはちょっと下がってしまうみたいなことも確かあり得ますね
あり得ますよね
30:00
でもそこは何かしらやっぱり日々日々解決はされていくんでしょうけどね
うん 確かに
だって想像できなかったですよね
多分5年後にここまで進化してるってなかなか
やっぱりイメージ湧かなかったし当時は
これからの5年ってまた全然違う5年間でいろんな進化があるんだろうなと思うんで
特にアップルに関してはもう
チップを自分らで独自に作ってっていうのがもっともっと先駆化していくんだと思うんで
より効率的にこういろんなことが高速に処理できるみたいなところが
もっともっと変わっていくのかなっていう感じは何となくしてますね
そうですね iPhoneのAチップであるとか
MacBookのApple M1系のシリコン系のものであるとか
それに感化されて AMDもちょっと勢いありましたけれども
Intelもちょっと遅れを取ってき始めてたのが
おそらくちょっとモチベーションというか追い上げもこれからも期待あるでしょうし
これからどれだけ変わっていくのか進化していくのかっていうのは気になりますよね
ラフデブリア的に
絶対競争力が高まっていくと思うんで
そうすると各社しのぎを削って
エンドユーザー的には美味しい思いができるっていう感じになっていくのかなっていうのはちょっとありますよね
いやーなんか楽しみですね
楽しみですねこれは
[音楽]
はいそうしましたら続いてはちょっとまた話題を少し変えてですね
最近そのWebのフロントエンドの開発っていうとやっぱりリアクトとかビューみたいな
フレームワークが結構主流になってきているのかなっていうのがあると思うんですけど
その辺をですねちょっとまた池田さんの普段のお仕事と関係する部分も含めて
なんかいろいろ知見を共有していただけたらなと思ってるんですけど
なんかその結構お仕事で使われるのってやっぱり
リアクト+タイプスクリプトみたいな感じが多かったりするんですか最近の傾向だと
そうですねタイプスクリプトとかJavaScriptとかに関してはタイプスクリプトを使うのがほぼ100%です
でリアクトとビューが合わせて8割ぐらいでアンギュラーが一部であるみたいな形でやってますね
じゃあもうフレームワークなしもほとんどないって感じですか
フレームワークなしは全くなしではなくて使うことがフレームワークを使わずに作ることもありますと
その生JSで作るだとかこともよくあります
そのポイントとしてはフレームワークを使うとどうしてもやっぱりフレームワークの容量分を重ねてしまうとか
33:01
そういうところもあるので結構うちの会社パフォーマンスにシビアな案件とかもたまにあってですね
リアクトの容量でもダメだみたいなこともあるんですけど
生JSの方がすごいいい時もあるのでそういう作り方もします
基本的にはリアクトビューで土台を用意してそこでタイプスクリプトで作っていくみたいなことが多いですね
なるほどなるほど
結構やっぱりこれは私の勝手なイメージですけど
世の中一般的にはもちろんいろんな製作会社さんとか開発組織とかいろいろあると思うんですけど
結構表に見える流行っていう意味でいうとリアクトとタイプスクリプトでみたいなことがやっぱり多いのかなっていうのがある中で
私自身は結構WebGLだからっていうのもあるんですけど
あんまりビューのフレームワークとか使わない場合が多かったりはするんですけど
やっぱりでもタイプスクリプトは使っていきたいかなみたいなところもあって
これ本当に唐突にちょっと私の普段思っていることをいきなりぶつけちゃうんですけど
結構私がちょっとどっちに含まれるかわかんないんですけど
ちゃんと流行の技術をキャッチアップもしていて
組織的にもしっかり柔軟に取り入れる風土があってっていうところはリアクトとビュー一択っていうところは結構あるんじゃないかなと思うんですけど
街のホームページ屋さんみたいな感じのところから始まっている中小の小さな組織とかだったりすると
なかなかその技術のキャッチアップするようなスタッフもそんなにいなくて
昔ながらのHTMLとCSSとJavaScriptみたいなことをしくしくとやっている組織もあると思うんですよね
そういう中で我々今後一体どこを目指していったらいいのかなっていうのが
人によって見えているものが違うとは思うんですよね
なんとなく私のイメージなんですけど
ただあくまでもスタートラインが一緒だったらっていうこと
例えばこれからWebのフロントエンドに入っていこうみたいな人がいたときに
これから先まず学ぶべきはどこなのかっていうのを考えると
その辺ってやっぱりTypeScriptとかリアクトをちゃんと覚えてもらうってことを前提にした方がいいのか
それともそういうことじゃなくてまずはJavaScriptの基本からしくしくとやってった方がいいのかとかっていうのが
何が正解なのかなっていうのはちょっと私個人の中ではまだ正解がないというか
ちょっと難しい話題かなと思ってたりもするんですけど
池田さんの中でその辺り
例えば今からWebのフロントエンドを始めて勉強していきたいんですみたいな人がいたときに
どういったコンテンツというか教材を提供してあげるのがいいのかなみたいなところって
36:02
なんか肌感としてこういうのがいいと思うみたいなところってありますかね
難しい問題ですよねこれは
基本の考え方で言うとやっぱり基礎からつけるべきというのがある
HTML、CSS、JavaScriptとして基本を抑えるっていうのは
これは変わらないのかなとはちょっと思ってます
その上である程度抑えたところでどこに行くのか
JQueryとかWordpress派の方に行くのか
ReactとかTypeScriptのガチガチ系に行くのか
ここは判断の迷いどころ
多分所属する組織にかなり依存されたりする
受け持つ案件に依存するみたいな話になるのかなと思います
ただ単純に世の中で多分その総数で言えば
日本の中でそのWordpressとかJQueryとかで作ってるウェブサイトの方が
多分まだ需要は大きくて
仕事を長い目でというか今時点で食いそびれない
すぐに案件もらえるかみたいな話で言えば
そっちの方が手っ取り早く
小銭を稼ぐ案件みたいなやつは多分手に入りやすいんだろうなと思いますが
本質的なウェブのことをより深く知って
いろんなことに応用できる人材になろう
と考えた時にReactであるとかTypeScriptであるとか
HTMLやJavaScriptができなかったことを
フレームワークの力で解決に導いていっている
新しいアーキテクチャであるとか
そこを学んだ方が多分長い目で見た時に強い人材になれると思うので
単に学ばせるだけなら基礎を教えた上で
ある程度新しい方の技術選択をお勧めするというのが
私の算数になるかなと思っています
なるほどな
結局いろいろ考えると似たような結論になりそうな気はしますね
確かに私がお仕事で関わりのあるクライアントで
そこまで組織的に開発というものが主体ではない業界の
ちょっと今最近開発もやり始めましたみたいなところの組織があって
そこはやっぱりあんまり技術に明るい人がそもそもいない中で
私が入っていっていろいろ変えたりGitを導入しましょうとか
そういうレベルの話から始めて
ソースコードは履歴で管理するようにしましょうねとか
Gitでコミットしてプッシュしたらちゃんとデプロイされるようにしましょうねとか
そういうことをやったりしたことが最近あったんですけど
39:03
そういう組織でリアクトやるぞタイプスクリプトやるぞってなかなか言えないというか
いきなり言ってもできないでしょなっていうのがあって
でもそのクライアントのことを本当に真身に考えるのであれば
おそらくその所属されているスタッフさんたちにリアクトだったりタイプスクリプトだったりは
なぜそもそもなぜこういうものが世の中で今もてはやされているかという背景がまずあるわけじゃないですか
必要とされている需要の部分がまずあって
いろいろある問題を解決するために今こういうアプローチを業界の最先端では取っているんだよみたいなところも
本当はそのクライアントのことを考えたら教えてあげるというか
私なりに説明してあげた方がいいのかなとも思うんですけど
ただやっぱりそれって下地がないとできないというか
解決しようとしている問題に実際にぶち当たった経験がないとありがたみがちょっと分からないというか
押し付けられてもそんなこと言われてもこんなめんどくさいことをなんでしなきゃいけないんですかみたいになっちゃうというか
なんかその辺のすごい悩みがあって
それでちょっと今池田さんはどういうお考えかなというのを聞かせてつい質問してしまったんですけども
なるほどなるほど
なんか難しくて多分今の話だとリアクトとかタイプスクリプトまでは多分いかない方が多分いいのかなという思ったりするんですけれども
なんか今ちょっと話がちょっとそれるところではあるんですけれども
かけだしエンジニアとつながりたいっていう層がホットな
で8月とかの時にすごくよく燃えてたのかなと思っていて
そっちの界隈結構私ツイッター最近はあまり知ってないんですけど結構深く追っていてですね
なかなか興味深いなと思ってるんですけれども
やたら教えるロードマップを紹介してるんですよね
なんか私はこうやって成功したみたいなので
それでJQueryとWord of Letters
JQueryはもうちょっと触ればもうokみたいな感じで紹介していたりとかして
なんか教えるその学び方みたいなものがなんかそういうインフルエンサーと言うんですかね
なんか結構人気が2万フォロワーとかいって自分より上だもんみたいな悔しい思いをするんですけど
なんかやっぱりそのウェブの学び方っていうのがすごく幅広く広がってしまったがために
よりハイエンドな方を目指すにしてもカジュアルにちょっとしたウェブサイトがそれっぽいものができるみたいな技術の話もあって
すごく選択肢が広がってしまったから
どこから学ばせるべきなのかとかそれが本来組織に根付くものなのかみたいなことを考えないととても難しくなったんだなと思っていて
そうですね難しいだからなんか我々と言うとちょっと語弊があって私は一人社長だからあれなんですけど
例えば池田さんみたいな立場だともちろんその経営者としての判断として組織にどういうカルチャーを根付かせたいかみたいなところを判断を自分でできるというか
42:09
そういうポジションだと思うんですけどやっぱり一従業員のレベルになっちゃうとなかなかそこの判断って難しいというか
自分自身がその組織内でのインフルエンサー的な立場に自分自身がならないと結構難しかったりもすると思うんですよね
多分リアクト全然知らない使ったことないという組織の中でじゃあこれをみんなで使っていこうっていうのは多分結構勇気がいると思うんですよね
だから正解一つじゃないというかその組織なりでもちろんいいんでしょうけど
ただ先ほど池田さんがおっしゃったみたくやっぱりより成長していくためにはやるべきなのかなっていうのはやっぱ私も同じ意見ですね
そうですよね新しい人がちょっとその中でたまたまできる人上に立っている人だったらたぶんパッと鍵切りやすいでしょうけれども
なんかの一社員特に例えば新入社員の方が逆に詳しいみたいなことがたまにあったりとかして
その時に上司に向かってちょっとやり方古いんでこんなのありますよっていうと
だいたい組織でそういうの嫌がりますから失敗するでしょうからね
我々のICS…私の会社でやってるICSメディアのコンセプトというのが業界の水準を上げようというところが
ウェブ教科の水準を上げようというところがあって今の話聞いていて
そういう新しいことにチャレンジしたいしそもそもどういうふうなことが今解決手段とあって
それをどのぐらいの負荷で取り入れられてそれが実際に自分たちに実務に役に立つんだみたいなことって
なかなかちょっとアウトプット我々から発信できなかったりするというか
難しいですよねやっぱり正解がその組織ごとにバラバラだから一概に言えないですもんね
我々はこういうふうにやってますよというところまでしか言えないというか
こうすれば絶対成功するというのはなかなかないんで
その辺って啓蒙とか啓発したくてもなかなかやっぱ難しい領域かもしれないですね
でもやっぱりICSメディアみたいなウェブサイトがあることによってかなり貢献されてるとは思いますけどね
それであればいいですが祝々と新しいコンテンツを発信することでというのはちょっと続けていきたいですね
絶対役に立っていると思うけどなんか上司とか同じ組織のスタッフたちを説得させる材料として
結構ICSメディアが引用されるっていうこともあるんじゃないかなとは思いますけどね
めっちゃ個人的な話を言うとWebGLスクールっていうのを私やっていまして
45:04
池田さんも前に出ていただいたことあるんですけどその中で3JSも教えたりしてるんですけど
基本的に教えるときに3JSのわからないことが出てきたときに検索して
日本語で出てくる記事で信用していいのはICSさんのところだけですよって言ってるんですよスクールで普段
ありがとうございます
やっぱり古い池田の記事とかが出てきちゃったときに
いやそれ今の3JSじゃ使えないんですよってなっちゃうことがやっぱ多いんですよね
これ3JSに限らずWebpackとかももちろんそうだと思うんですけど
なかなかそのまるで生き物のように姿が変わっていくじゃないですかWebの世界って
だから
おっしゃる通り生き物ですよね
生き物みたいにどんどん姿が変わっていくんでその日本語で検索しちゃうのも悪いとは言わないし
英語で書かれているもの追いかけるの大変っていうのもすごくわかるけど
できるだけその公式をまず見なさいっていうふうに最初は言って
公式のドキュメントも結局3JSもドキュメントが追いついてないときとかもあるんで
絶対ではないっていう前提でまずはドキュメントを見てもらって
それでも解決しないときは日本語で検索するのもいいけど
その場合はICSメディア以外のところはあんまり信用しないほうがいいぞっていうふうに言ってますね
それはありがたいですねなかなかこの辺り難しいですよね
その公式のサイト3JSもミニマムのサンプルがいきなりESモジュールを使って対するんですね
ESモジュールって私も気になって日本のツイッターのアンケートとかでやってみると
ESモジュールを普段のアンケートで使っているかというと
バンドルしてはもちろん使っていると思うんですけど
バンドルせずに使っているかというとあんまり実は普及していなくて
なので3JSの公式サイトのサンプルそのままやると
多分そこでやっているときはいいんですけれども
他のところで使い回しづらくなるだろうとか
なんかそういうちょっと先行き過ぎているみたいな逆の現象だったり
先ほどおっしゃっていたのはちょっと古い原稿があったりとか
多分それってリアクトとかでもあって
リアクトって今関数コンポーネント押し出しているけど
公式のサンプルは全部クラスコンポーネントで作られていて
参照すると初心者殺しだったりするんですけれども
結局誰かが安心して使える情報にしていかないといけなくて
それか本当は公式ができればいいんですけれども
どうしてもやっぱり人力なところがあったりするので
ウェブのいいところでもありますけど
いろんな人がいろんな手段で新しい情報をアウトプットして
更新していけるっていうのはいいことなので
うちは会社としてそれを組織として業界に貢献したいなという思いから
やってはいるんですけれども
こういう動きでもっと広がるといいかなと思います
48:01
本当そうですね
私はどっちかっていうとちゃんとメンテができていない側だから
ちょっとあんまり大きな声では言えないんですけど
でも本当にそうですよね
ウェブジェルはそもそもAPIが全然変わってないんで
昔書いたものでもそんなに放置しておいても影響はないんですけど
でもとはいえやっぱり新しいものがどんどん出てくる中で
メンテナンスして正しい情報を正しく発信するっていうのを
誰かがやっぱりやらないと
業界全体として信用を受けないサイトばっかりになってきちゃうと
やっぱりそれは多分成長を阻害しちゃうことになるんで
すごい大事なことですよね
ちょっと急にガラッと話題変えちゃうんですけど
メンテナンスっていう意味で言うと
ウェブサイトとか発信されてる情報のメンテナンスももちろんそうだとは思うんですけど
自分たちで開発したもののメンテナンス性とかって結構考慮されたり
住宅で納品して終わりっていうものと
継続して開発していくものでまたちょっと捉え方違うかもしれないですけど
ICSさんの場合って結構
長期メンテナンスすることも踏まえた場合とかって
やっぱりしっかりテストをどれくらい書くのかとか
あるいはリントとかをどこまで厳しくリントで制限するのかとか
その辺も結構ポリシーがあったりするんですかね
そうですねありますね
これはまだ結論出てないというか
いつも試行錯誤の段階で皆さんの危険も聞いてみたいところではあるんですけれども
うちの基本的な開発スタンスとしては
新しく案件を始めるときは
その当時の一番可能な限り新しいものを選択して
リリースするまでは結構頻繁に
新しいモジュールであるとかを最新化していってリリースしますと
リントとかプリティアとかタイプスクリプトも
先ほどから何度もお話出てると思うんですけれども
そういう設定を可能な限り最大限厳しくして
開発するようにしてますね
リリースした後って結構ややこしくて
多分うちも長期保守みたいな案件もあったりするんですけれども
そこの時になると
使ってるものを例えばWebpack 4から5にするって
リスクもかなりあるので
予算取れるかみたいなところもありますし
だからそこは思いっきり一気に
今回の次のリリースに向けて全部上げるかみたいなことを
やれるものもあればちょっとやると
自己利走な気もするしなぁやめとこうかなみたいな
あってこの辺り皆さんどうやってるのかな
っていうのがすごく気になりますね
気になりますよね
私なんかは本当にいつも一人で
作業してるから余計に普段他の人たちって
51:02
みんなどういう風にしてんだろうっていうのが
全く想像がつかなくて
でも本当にWebpackのバージョン変えるとか
対応するノードのバージョンを変えるとかって
結構経験的には痛い目を見るというか
それをやってしまったことによって
全てが動かなくなってしまいましたみたいなことって
よくあるようなイメージがあるから結構みんな
なんかその辺のタイプスクリプトもバージョン
結構頻繁に変わったりするし
みんなどういう風にやってんだろうなーって
ちょっと気にはなってたんですよね
Lintとかもそうですよね
どこまで厳しくするか
あとはコーディングスタイル的なところもあるじゃないですか
例えば括弧の間にスペースを入れるのか
入れないのかみたいなこととかも
細かい話はいろいろあると思うんですけど
一応あれですかね
多分ICSさんの場合は
社内ではとりあえず共通のルールにしておこう
みたいな感じなんですかね
そうですね
基本Googleの出してるスタイルガイドラインというのがあって
なるべくそういう風にしてるんですけど
ただリアクトにはリアクトの文化があったり
ビューにはビューの文化があったりとか
あったりするので
なるべくフレームワークとかが推奨している書き方を
第一優先にして
そこに足りないものはGoogleの基準を適用して
あと自分たちでより細かくチューニングしていく
みたいなことをやりますね
結構厳しくて
変数名パスカルケースとか
XML HTTPリクエストみたいなAPIがあったときに
XMLを全部大文字で書くか
MLを小文字にするかみたいなところ
悩ましいですけど
そういうところまでリントで制限できるので
そういうところも全部ガチガチに
可能な現時点の技術で最大限ガチガチにできるところは
固めてやるようにはして
あとCI回すみたいなことは
たすらやっているんですけれども
これがまだどのくらいできるか
あと更新したとき
モジュールアップデートするのは結構怖い
難しいかったりするんですけれども
初機能を運用の中で追加したりだとかしたときに
壊れてないかって
人力でチェックはするんですけれども
どうもこのCIとかでチェックできることがないのか
っていうのは常々思っていて
いわゆる案件では単体テストで
完璧に単体テスト作り上げたりだとか
E2Eテストとして
パペティア、クロニウムを後ろ側で動かして
CI走るときに全画面とりあえず
フォームとかにバーって値入れて
ちゃんとそれ通りAPI叩いてるかとか
掴みつけたり
あとビジュアルリクレッションテストみたいな形で
作ったテストを全部
サイトを全部スクリーンショット自動的に走らせて
前の結果と差分がないかみたいなこともチェックしたりだとか
54:00
いろんな仕組みを作ったりするんですけど
そこの作るとコストが高すぎて
こんな毎回やってられないしなみたいな思ったりするんですよね
本当予算取れないですよね
多分普通にお客さんの中で作ってくださいって言って出てくる予算って
そういうことまでなかなか考慮されてないじゃないですか普通は
だからすごい難しい問題ですよね
理想的にはもちろん全部のテストを書いて
ちゃんとCI回してっていうのが理想だと思うんですけど
自社でサービス作ってるならできるのかもしれないですけどね
なかなか受託でそれどこまでやるかって
やっぱICS3レベルでもそこはやっぱ悩ましい問題なんですねやっぱり
他の会社の
特にちょっと最近はオンラインになったので
ちょっと私もあまり勉強会にそんなに参加できてるわけじゃないんですけれども
コロナが始まる前って結構勉強会
東京だとほぼ毎日どこかで開催されてたみたいなことがあって
その時にテストに関する勉強会とかもやったりしたので
聞いてたりしたんですけれども
ちょっとイケてるところってやっぱりそういうシステムを組んでたりとかして
うちらもちょっとマルテみたいなみたいなことやるんですけれども
そうですよね
受託だとなかなか難しいところがありますよね
難しいところがありますね
この辺はちょっとこのポッドキャスト今もし聞いてる方で
その辺のどこまで厳しくルール決めしてやってるかみたいなところは
もしこういう知見もあるテストこれぐらい書くよとか
リントはこれぐらいの厳しさでやってますよとかね
そういうのがあったらぜひハッシュタグつきでつぶやいてもらえると嬉しいですね
ちょっと聞いてみたいですね
世の中一般でどんな感じなのか
はい じゃあいろいろ楽しいお話をたくさん聞かせていただいているところなんですけれども
ちょっと気になっているところで
結構池田さんの普段のツイートとか拝見してると
もちろんウェブのフロントエンドのJavaScriptだったりTypeScriptだったりっていう話題はありながらも
その中で結構FigmaとかあとはAdobeのXDとか
そういった結構デザイン系の話題とかもよく拝見するなっていうイメージがあるんですけど
なんかその辺追いかけてる理由というとちょっと大げさなんですけど
どういうふうに使われてるかとかなんかその辺ちょっと聞きたいなと思うんですけど
そうですね デザインツール自体は昔から興味があって
今は違いますけれども私10年ぐらい前とかPhotoshopを起動しない日はないというか
常にPhotoshop起動しながら何か作業してるみたいな感じで
57:02
大好きなんですね そのデザインツールというのが
それが何かというとなんか思いついた時になんかイメージを伝える
ちょっと落書き状みたいなぐらいのイメージで使ってたりだとかもするし
ちゃんとウェブサイトのデザインを作るために使うみたいなところもあるんですけれども
今このXDとかFigmaとかちょっと最近はスケッチも少し需要が落ちてきたのかなと思うんですけれども
その辺りのツールの新しいイノベーションというかは
デザインを構造的に作れることだと思っていて
Photoshopだと細かくいられもそうですけど細かく作れるようなことに特化しているものの
XDとかFigmaとかってコンポーネント化して
それの余白関係とかを論理的に持たせて構造できる
組み立てることができるので変更に強いであるとか
同時編集ができるとかそういったワークフロー上の改善点とかもあったりして
面白いなと思って追いかけてたりするんですね
うちの会社だとXDとかFigmaとか
Figma最近かなり一気に増えてきたなという感じもするんですけれども
だいたいその辺りのスケッチも一部の案件であったりするんですけれども
使っていたりだとかしてですね
この軍有格局のデザインツールはどういう風にみんな使っていて
伸びていくのかなというのは常々気になっているトピックでしたと
最近ちょっと思っているところがあってですね
何かというとFigmaが増えてきたんですけれども
XDもそうなんですけれども
結構このツールって便利なところがあってコンポーネント化して
その中でステートを切り替えたりとか
バリアンツかなとかで状態切り替えたりとかできるって便利な機能があるんですけれども
どうもとりあえずツールだけ導入するんだけれども
何かその辺りの便利機能あまり使われてないFigmaとかファイルとか多いなと思っていて
何かその辺り杉本さんのところでどうなのかなというのは聞いてみたいなと思ってました
めちゃめちゃ個人的な話になっちゃうんですけど
Figmaを使ったプロジェクトって今んとこ私は経験がなくて
XDはもちろんあるんですけど
今池田さんがおっしゃったみたいにただ単に
PhotoshopとかIllustratorって要はどこまでも細分化して情報を表せるけど
要はその二次元的な
要はグラフィックスの延長線上にあるというかそういうものだと思うんですけど
XDとかってやっぱりその構造的にコンポーネントベースで構造的に表現できるっていうところが
Webとの親和性がすごい高いのかなっていうふうには思う一方で
何かでもすごい雑な言い方をするとそれって結構PowerPointと近いというか
1:00:04
シェイプをうまく並べて大きさを調整してみたいな
PowerPoint的な見え方は見え方って言うとちょっとおかしいな
なんか操作感がPowerPointに近いというかそういう感じの印象があって
自分でやっぱりXDとかFigmaみたいなツールを使うっていうのがあんまり私の場合はないんですよね
WebGLで何かをやるっていうことがほとんどなんで
あんまりああいうのを使うってことはないんですけど
デザインを提供してもらう側の視点に立つと
例えばフォトショーで静止画を書き出したんで
PingとかJPEGがボーンって渡されるよりは
XDとかで渡された方が分かりやすいなと思うんですよね
じゃあ何が分かりやすいのかなっていうのを考えると
やっぱりマウスホバーさせたらマージンが出るとか
そういうインタラクティブ性にあるのかなって俺は個人的には思ってるんですよね
多分そのインタラクティブ性のさらにもう一歩踏み込んだところにあるのが
おそらく今池田さんがおっしゃったようなバリアブルな部分というか
バリアブルは違うな表現が間違ってるな
変数的な部分っていうんですかね
なんかそのステートを与えると状態を変えられるとかっていう
そういうところなのかなと思うんですけど
実際その逆に私なんかはFigmaとかを普段バリバリ使ってますよみたいな組織で
どういう感じの出来事が日々繰り広げられているのかっていうのを
逆に気になっちゃいますね全然使ったことがないんで
今の私の使い方だとデザイナーさんが使いやすいツールとしてまずXDがあって
そのXDで作られたデータを私はもらって見てるっていうだけの使い方しかできてないんで
その先のもっとチームとして神話性の高い状態っていうのは逆に私はイメージできないから
聞いてみたいですねいろんな人に
すごく興味深い話でした
Figmaとかコミュニケーションオンラインでコメント取り合ったりだとか
多分Teamsとかスラックとかでやり取りするのと
違うフィールドでコメントをやって
Figma使ってる人たちってコロナ禍じゃなかったら会議室でパーンってハイタッチしてるようなイメージがあってですね
なるほどなるほど
ちょっとどういう使い方してるかみたいなところは興味あるんですけど
多分デザインシステムを組み立ててそれに基づいてコンポーネントとして各画面で展開していく
アトミックデザインみたいな話もあるかと思うんですけれども
デザインの作り方の作法みたいなところっていうのは
1:03:01
今までPhotoshopとかの段階だとあまり言語化されてなかったり
ワークフロー存在しなかったのが新しいツールになって出てきたので
今の聞いてみたいっていうのが
より受け止め、調べたら勉強会とかで聞ける話になってきたのかなってちょっと思ってまして
多分ちょっと前、コロナの始まる前の
割と勉強会ありましたよっていう時の空気感だったら
ぜひ聞いてみたいし多分たくさん催されてるというか
多分デザイナーさんたちのイベントとしてたくさんこういうのやってたんじゃないかなってちょっと思いますよね
今度デザイナー寄りなゲストが来た時にぜひ聞いてみたいですね
どんな感じでやってるんですかっていうのを
結構WebGLソフトさんでWebGL使ってるというところは基本テーマとしてあると思うんですけど
クリエイティブなサイトをよく取り上げられてるじゃないですか
それとところでそういったプロダクションの方とか個人制作者の方とか
もし話聞くことがあったらぜひ
聞いていただけると嬉しいですね
すいません、せっかく池田さんから質問していただいたのに私自身があんまり使ったことがなくて
面白い答えもできなかったんですけど
私自身もすごい気になってますね
これから先のWebの制作の中で欠かせないと思うんですよね
こういうツールの存在が
だからといってフォトショップもイラストレーターもなくならないし
Webではないデザインの世界では引き続きやっぱり必要なものだと思うんですよ絶対に
ただ今後、例えばWebのプロダクトデザインみたいなところになってくると
特にGUIをどう組み立てていくかみたいなそういう意味でのデザインっていうことになってくると
やっぱりFigmaとかXDみたいなツールの方が向いてるのかなっていうか
メリットが大きいのかなっていうなんかふんわりした感覚はあるんですよね
やっぱりなんか、例えば普通のデザイン
Web以外のデザインとやっぱり違うところで言うと
インタラクティブ性があると思うんですよねWebの中って
ユーザーがどういうふうに操作したかとかっていうそのUXの部分まで考えなきゃいけないっていうところで
なんか多分XDとかFigmaみたいなツールはそういうところにマッチしてるのかなっていう気はするんですよね
ただまあ自分自身がそのデザインの素養がないんで
どういう肌感でみんな使ってるのかなっていうのはちょっとイメージが湧かないんですけど
プロトタイプモードとかで大体そういうツールのインタラクションとか確認できますからね
そういったところでコーディングして初めて体験がわかるよりも
1:06:05
もうちょっと前の段階でユーザー操作とかの体験がわかるようになってるっていうのがすごくいいところなので
そうですよね、なんかこうドロップダウンリストがこう出てくるんだなとかっていうのが見てわかりますもんね
確かにそうですよね、そういうのは確かにPhotoshopとかIllustratorだとちょっと難しいというかやりにくいことではあると思うんで
確かにな、そういうところが受けてるのかもしれないですね
あとはちょっと池田さんが来たらちょっと聞いてみたかったのが
デザインどこまで揃えるか論っていうのが俺の中であって
これ結構池田さんに限らずWebではよく議論に上がる内容だと思うんですよ
デザイナーさんからすればピクセルレベルで合わせろっていう主張と
フロントエンドのエンジニア側からするといやいや1ピクセルずれててもわかんないでしょっていう
ずる乱暴な論調もあると思うんですけど、なんか池田さん個人はどっち派閥なんですか
これあれなんですよね、どんばちする話なので、へちゃいで言うと怒られそうなところがあるんですよ
あくまでもその1個人の気持ちで構わないんで
この考え方としてはなるべく揃えるべきで
仕事上でやるときはかなり正確に揃えます
これはデザイナーの方がデザインを作り終えるまでのプロセスって
単純にスタイルを作るだけじゃなくて色々交渉してその子に行き着いたみたいなところがあったりするので
簡単なフロントエンドのエンジニア側の解釈で都合のいいようにそのルールを崩してしまうみたいなことが
あまりある、互いの仕事を尊重する意味ではない、守るべきなところなのかなと思っていて
それによっては整えるの方に自分の意見はありますね
やっぱそうですよね、なんか俺も同じですね
結局例えばWebGLのことを語ろうとしても相手がWebGLのことをわからないっていうのが
よくある、私は自身の体験としてよくある中で
じゃあデザイナーさんの立場に立ったときに
俺みたいにデザインのことがわからない人間に対して全部を説明はできないだろうな
で、説明してくれたとしても俺も読み取れないというかわからないだろうなっていうのが
逆の立場になったらなっていうのを想像するとやっぱ思うんですよね
だからなるべく本当は揃えるべきだなって私も思いますね
例えばグラフィックス系のプログラマーあるあるで
FPSが60を切った瞬間にすごい残念な気持ちになるみたいなこだわりがあったりして
60FPSでヌルヌル動いていることにすごい価値を見出す傾向とかあったりすると思うんですけど
多分それと似てると思うんですよね
59FPSと58FPSの違いなんか見ててもわかんないでしょって思うかもしれないけど
1:09:04
グラフィックスプログラマーからすればその1FPSの違いは非常に大きいんだっていう
なんかそういうのがあって多分デザインも同じだと思うんですよね
その1ピクセルとかの違いが
あなたにはわかんないかもしれないし重要じゃないかもしれないけど
デザイナーさんとしては意味をちゃんと持たせた上でそういうことになってるんだよっていうのがあるんだろうなっていう想像だけはできるんですよね
なんとなく
すごく面白い話ですね
それは結構思うところがあって
その通り私もその意見かなり賛成というか同意なんですけれども
自分自が気づけない感じられない価値がわからないことでも
ウェブっていいところではあるのはどんな人が見てもそのコンテンツを体験できるということで
いろんな多様性があっていろんな人がコンテンツを授業しますと
自分じゃない誰かが見てそこに価値を感じることがあるわけですよね
それが先ほどの1FPSのたどり着けないところとか
ピクセルレベルでずれている法則が混沌としているようなところであるとか
もう少し言えばアクセシビリティもその話に入ってきて
普段我々気にしてないかもしれないけど
DIVタグとかでボタン作っててフォーカス合わないみたいな残念がある人だとか
多分根底としては同じで
自分がそこに対して品質やクオリティや便利さを感じているところが
感じたり感じなかったりするんだけど
他の人はそこに実は価値を感じているみたいなことがあったりするので
その各パートで専門分野にもって作ってくれている人の
考えとかこだわりっていうのは
なるべく尊重して最終的なアウトプットに生かすようにするのが
我々のWebの制作の仕事の大事なところなのかなとは思ったりしますね
そうですよねやっぱそうだよな
でも本当にその通りだと思います
私なんかはそうは言うても揃えるのはちょっと最後でいいですかって言って
パッと作ってちゃうんですけど
まあでもそうですよね
やっぱ議論するには同じ土俵に立てないといけないですもんね
そもそも同じ土俵に立てない者同士が
それぞれの専門領域の中で仕事を一緒にしているわけで
なんかもう本当にね両方のどっちの気持ちも分かる
その揃えるべきだっていうデザイナーさんの気持ちも分かるし
一開発者的な考えだといやそこ揃えるのはちょっと
あの大変だなっていうのも分かるから難しいんですけどね
そうですねそのこだわりみたいなところがやっぱり
お互いやっぱりそこのこだわってるところのポイントっていうのが
コミュニケーションで成立しないとただしんどいだけだと思うので
1:12:03
なんかそこのところやっぱり気を遣いますね
私も実装すべてやってるわけじゃなくて
デザイナーとエンジニアの橋渡しみたいなところでやってたりとかして
なんでこここんなこだわりでデザイン揃えてるのかみたいなところが
分からなかったりすることも多々あるので
そういう時は逆に質問したりだとか
ちょっとクライアントデザイナーが遠い時は
エンジニアがただデザインを受け持って
ルールが分からないってモチベーションが下がっちゃうってこともあるだろうから
ここのデザインはなんとかうまく解消して解釈して
ここは実はこういうこだわりがここに隠れていて
こういうことをやろうとしてるのでここを守った方がいいとか
実はこれデザイナーがちょっとテーマというか認識が外れていて
ただ単に本当にずれてしまっただけだとか
というところをちゃんとモチベーションを保つようにエンジニアに伝えるようにはしていて
なので難しいですが
結構橋渡し役の辛いところではありますよね
特になんか今チラッと一瞬池田さんおっしゃいましたけど
要は決策材件を持っている人が遠い場所にいる場合が結構やっぱ難しいですよね
このデザインを下りてきました
基本的にデザイン変えるってことはあんまりできる空気感ではないよ
みたいな時もあったりはするわけじゃないですか
言われた通りに作らざるを得ないよみたいな時もあって
そこら辺はやっぱり難しいし
どうしてもそういうところにバチバチしちゃう要因があるんでしょうね
わかるんだよな
エンジニアがそこにこだわれないっていうのはもうしょうがないというか
やっぱりこだわるポイントが違いますもんね
エンジニアがこだわりたい部分とデザイナーがこだわりたい部分が
基本的には一致してないことの方が多いからどうしても
営業と開発者がバチバチするっていうのと同じだと思うんですよね
なんとなく
営業さんたちって営業さんたちの基準で動いてて
エンジニアからしたらそんな無茶な脳キリで
なんでお前仕事取ってきちゃうんだみたいな感じの
よく耳にするそういう話があると思うんですけど
それと近いというか同じなのかなと思うんですよね
価値観が違うというか
そうです難しいですね
どうしてもやっぱり自分の職に応じたスキルとか技とか
スキルでいいでしょうスキルとか
どうしてもエンジニアとかデザイナーとか営業とか
縦の方向で割っちゃうんだけれども
プロダクトとして
縦で割るんじゃなくて横のラインで
こういう機能サービスを提供したいっていう
そこのモチベーション価値が一致して
その中でコミュニケーション
そこを出すからそれぞれのデザイナーでエンジニアとかの
こだわりポイントとかが理解できるとか
1:15:02
そういう組織的な問題みたいな方もあったりするのかなって
思ったりしました
だからやっぱりフロントエンドはフロントエンドで日々日々進化していくし
変わっていくしトレンドも移り変わっていくしっていうのと同じで
プロダクトをどう運用運営していくかみたいなところもやっぱり
最近で言えばそのアジャイルだったりとかデブオープスみたいな
新しいトピックが出てきてやっぱり日々日々変わっていかなきゃいけないんでしょうね
アップデートし続けなきゃいけないというか
やっぱり結局最終的にはどこまで自分自身にそういう前向きな
変わっていこうという力というか
そういう気持ちがどれだけ自分自身の中にあるかっていうのを
やっぱり重視すべきなのかな
成長する意識がなくなった時点でやっぱり
ダメなんだろうなってちょっと思いますよね
そうですねやっぱりこの業界って結構
ウェブって出てきて30年くらいなのかな
その中でどんどん変わっていってたりするので
やっぱり変わっていくことを楽しむような人じゃないと
多分ウェブに限らずデジタルって多分そういうもんだと思うので
そうですねそうだよな
本当だってもう5年10年で全く別世界になっちゃいますもんね
そうですねこの前のスマートフォンの話もそうですけれども
全然違いましたからね
だってなんか今結構その今も
普通に名前を聞くような大きな企業でも
創業期にはいわゆるフューチャーフォンのアプリを作ってた
会社でしたとかっていうのもいまだにやっぱり
そういう歴史をたどっていくと昔はフューチャーフォンの
iモードとかで使うやつですよね
iモードとかで使うアプリを作ってたけど
今はいろいろあってその時代に合わせてアップデートしてきたからこそ
今も経営が前向きに継続しているみたいな組織っていっぱいあると思うんで
やっぱり時代に応じてアップデートしていかないとダメなんでしょうね
いや面白いですね
面白いですね
なんかそういう意味で言うとウェブの新しいAPIで言うと
最近あのウェブGPUがそろそろ来そうだなっていうところがあるんですけど
なんか池田さん的にウェブGPUとかその辺は追っかけてたりするんですか
そうですねICSでウェブGPUに対するサワリが先行で搭載してたと思うので
実験的に入れてたやつあの時代からちょっと基準したりとかして追っかけていましたと
で今ChromeにウェブGPUが
そうですねかなりでフラグを立てると動くっていう感じですね
フラグを立てるとか
で誰かなんかChromeの96とか
1:18:00
97までをオリジントライアルして99で確か載せるって話じゃなかったかな
確かですけど
詳しいありがとうございます
でChromeの周期が確か何か3週間か4週間に1回みたいなことになったから
そこから逆算するといつリリースしたいのかっていうのが見えてきた段階かなと思ってまして
で他の各種ブラウザが揃うかどうかみたいなところとか
特にウェブGPUになるとどこで動くのか
オープンGL上ではないくて
メタルとかバルカンとかそっち系の上で動くみたいなところがあったりするので
なかなか普及まではまだまだ時間かかるのかなと思ってはいるんですけれども
私ですねつい最近ウェブGL
サファリが初めの話に戻りますけど
サファリがウェブGL2に対応したということで
昔のデモを焼き直してみたんです
すると今見れるかな
ちょっと見れないかもしれないんですけれども
たくさんのパーティクルがいくつ同時に動きますかみたいなやつで
ウェブGL1の頃のフレームワークとしてはCreate.jsだったんですけれども
そこで動かしたやつがだいたい当時2万3万ぐらいが上限で
でウェブGL2というかPixie.jsで
多分これウェブGL2はあまり関係ないと思うんですけれども
Pixie.jsで最近焼き直して作ったら5万パーティクルぐらいまで余裕で動いて
でこれうちの会社の中でこういう作ったよみたいなことを共有してたりするんですけれども
あるスタッフがそれ貸してくださいって言って
翌週になったらウェブGPU貸してて帰ってきたんですね
そしたら私が5万で満足してたところが26万ぐらいまで動くようになって
やべえって感じで帰ってきたんですけど
ウェブGPUがようやく日の見を見にしそうになってきているというところで
だいたいパフォーマンスが上がって上がる手段が出てきたというところで
興味深いなと思ってるんですけど
ウェブGPUってあれなんですよね
コンピュートシェーダーも使えるようになるんですよね
使えるようになりますね
なんかそのウェブのコンテンツの最適化の手段として
並列の後ろ側のワーカー側に仕事を任せるのか
もしくはCPU上で高速で動くWebアセンブリとかASM.JSとか
そっち側で計算させるのかとか
あとWebGLのGPU上で計算させるみたいな
GPGPUでしたっけ
とか新しく出てくるのが
1:21:00
ウェブGPU側のコンピュートシェーダー側に計算させるとか
その辺りのどれが高速で
多分こういう計算にはこっちが向いてるみたいなのがあるんでしょうけれども
単純にベンチマーク好きなので
なるほど
そういう辺りですごく注目していますね
でもなんかすごいですね
何倍というか5倍ぐらいですか
だいたい5倍ぐらいになったっていう話はすごいですね
それがポンと出てくるというのがまずすごいけど
WebGL GPUに好きなスタッフがいて
分かります
なんならゲストに来てほしいなってちょっとこっそり企んでたんです
ありがとうございます
そのメンバーがスタッフがポンと上げてきて
でもそれはまだWebGPUの描画だけをそっちに移して
それだけ計算が早くなったで
ロジック上の座標計算とかはJavaScript上でまだやってるので
そっちの速度はまだ上がってないですね
それをWebAssemblyにするか
Compute Shaderに任せるかっていったらまだ上がりそうな気配はあって
それ多分その用途であれば
Compute Shaderにしたらもっと早くなるとは思いますね
なるほど
WebAssemblyは十分高速で早いと思うんですけど
とはいえ並列で一気にガッて計算するんだったら
多分Compute Shaderの方が早いと思うんで
なるほど
多分今の文脈の比較であれば
Compute Shaderが勝ちそうな気はしますね
それはアドバイスありがとうございます
そしたらでも本当に100万オブジェクトとか
ブワーって動かしても全然減っちゃらとか
そういう未来が来るかもしれないですもんね
単純にこれは実際の案件でそんなやることがあるかというとないと思うんですけど
単純にこの辺り技術的にはチャレンジしたいですね
分かります
本当にすごいタイムリーな話なんですけど
私もWebGPUは会議的とまでは言わないんですけど
いつ来るか分からんっていうのが基本的な立場だったんですけど
でもとはいえChromeのかなりに乗ったっていうタイミングで
そろそろ1回やっとくかなっていう気持ちになったとこだったんですよね
すごいタイムリーなとこで
今後まだまだAPIが変わるかもしれないし
なんならどっちかというと変わっていくことを運命づけられてるAPIだと思うんですよ
WebGPUって
WebGLの場合はもう彼に借りたOpenGLの実装を
Webに持ってきたっていうものだと思うんですけど
WebGPUの場合は新しくてモダンなグラフィックスAPIの
いいとこ取りをWebでもしたいよねっていうのが
WebGPUの存在価値だと思うんで
そうなると大元になっているグラフィックスAPIの
1:24:00
DirectXなりVulkanなりMetalなりが進化すれば
それに応じてWebGPUも変わっていかなきゃいけないというか
それを運命づけられてるAPIだと思うんで
そうすると一度形が決まったからといって
それで終わりではなくて日々新しいものがどんどん出てきそうな
出てきたらいいなっていうちょっと希望も含めてなんですけど
そういう気持ちがあるんで
しかもそこに5Gとかがさらに追い打ちをかけるように普及していくとすると
リソースは落としたい放題高速に落ちてくる
GPU使いたい放題ってなってくると
本当に100万200万のボリュームを
余裕でスイスイ動かせるみたいな未来が
下手したら本当5年後とかにはもう余裕できてるかもしれないじゃないですか
そうなるとすごい楽しみだな
だからそろそろちょっとWebGPUやっとこうかなって私も思ってました
いや本当技術的な進化あるでしょうからね
なんかもう5年後10年も経ったらすごいことになってそうだね
10年は相当変わってそうですよね
なんか別に技術に追いつけなくなっちゃってるとまでは思ってない
自分はちゃんとキャッチアップしていこうとは思ってますけど
10年後って言ったら多分全く違うことやってる可能性ありますからね
なんか今はWebGLとかの人っていう感じに
自分自身でも思ってるし周りもみんな思ってるかなと私は思うんですけど
でも本当に10年後って言ったらもうWebGLの人じゃないことは間違いないから
絶対何か別のものになってると思うんで
なんかそう考えると本当に10年後とか
今は想像つかないですけどね
でもポリゴン数とか頂点数を気にしていたのは過去の話でみたいになってるかもしれないですもんね
なんかWebも本当に今だと必死でみんなこう
ツリーシェイキングがどうのこうのとか色々考えて
頑張って何キロバイトでも減らせ減らせ減らせつって頑張ってるけど
そんなの全然なくなっちゃってるかもしれないですもんね概念として
そうですねツリーシェイキングもね1個ちょっとモーメントの容量削るかとか
なんかちょこちょこやってたりしますけれども
全くどうせ容量削っても画像1個追加したらその分ペイになっちゃう
みたいなとこもありますけど
なんか単純に回線が速くなれば気にしなくなるでしょうしね
なんか作り方もワークフローも変わりそうで面白い
そうですね
恐ろしい部分もありつつ
いや恐ろしい部分もありつつ楽しみな部分もありつつ
なんか本当5Gだって5G本当に5G普及したら
なんかギガっていう単位がそこまで怖くなくなるというか
まあ言うてギガでもちゃんと回線の状況さえ良ければ数秒で
1:27:03
余裕でいっちゃうと思うんで本当に5Gがちゃんと普及すれば
なんかそうなると画像の数メガバイトとか数キロバイトみたいなのを省略する
省略するというかその節約することのコストよりも
もう見栄えだ見栄えだって言って4K、8Kのテクスチャー画像とか
いっぱい使って綺麗にとかっていう感じになってるかもしれないなって思いますもんね
そうですね
なんかネットワークスマホの携帯の料金も安くなって去年から
そういうプランが出て使える容量もだいぶ増えたかなと思うんですけれども
早くなる容量の緩和も進んだ未来の頃で
なんかもう遠慮なくぶん回してアップロードプログラミングが受けられていくのかもしれないですね
エンジニアとしては楽でいいですけどね
楽でいいですけどね
でもそういう風になったらなったで多分もっと容量があればなみたいな別の何かが出てくるんでしょうね多分
そうですねそれが品質に関わるさっきの4K、8Kテクスチャーとか
そういうところもなってくるかもしれないですね
ディスプレイも3倍もいったい3倍のDPIだったりするのがもしかしたら5倍とかになってくるかもしれないし
180Hzとかのディスプレイが普通になるかもしれないし
普通になるかもしれないし
そしたらなんか色々恩恵は受けたけど恩恵は受けた世界線でまた問題が色々出てきてっていうことの繰り返しなのかもしれないですけどね
でも本当今後もその池田さんのやってくれてるベンチマークとか
いや本当にあの多分池田さんご自身は自分が発信している側だと思うんで
あの第三者的目線って想像を難しいかもしれないですけど
私なんかからすると本当にあの色んなこと発信してくれるのめちゃくちゃありがたいなって思って普段拝見してるんで
なんかあの古くは実はあの池田さんがまだFlashをバリバリ書いてらっしゃった頃に
池田さんが作ってくれた蝶々が羽ばたくみたいなFlashの3Dのやつがあったと思うんですけど
あの私はあれを見てWebで3Dができるっていうふうに思ってWebGLを勉強したという
あの勘違いから始まってるんですけど私の実はWebGL人生って
その池田さんのあの3Dデモを見てWebで3Dができるって思って
でも実はそれ今思うとFlashなんですけど
あの当時は私それ知らなかったので
それでWebGLを勉強し始めたという実はあの経歴がございまして
実はあの私がWebGLでここまでのし上がってきた時のスタート地点は実は池田さんだったんですよね
そんなことがあったんですか
そうなんですよ実はそうなんですよ
3Dはまあ確かにFlashの時代から私も大好きで
1:30:03
あのWebで3Dの体験ができるということで
当時はFlashの方が早かったですからまあそれにやってたんですけれども
そこからがきっかけだったっていうのは嬉しい話でありますね
これ初めて言うかもしれないですけど本当そうなんですよ
あの当時まだ私がその頃はあんまりこうJavaScriptとかもそんなにできなくって
プログラマーとしても当然全然成熟してない頃で
でもインターネットがもてはやされ始めた頃っていうか
もうこれからはインターネットの時代だみんなブログを書けみたいなそういう時代で
で池田さんのその作ってくれるJS Do Itでしたっけ
JS Do It
あったと思うんですけど当時は
あれとかで池田さんが作ったり公開したりしてくれてるものとか
あとFlashの作品とか見て
ウェブっていうのはこんなこともできるのかって目を輝かせながら
いろいろこうワクワクしながら
WebGLというものが存在するらしい
じゃあこれを勉強しようってなったんですよ当時
だからその池田さんがもしいなかったら私はWebGLをやってなかったかもしれないっていうね
そこからWebGLに結びついたのもすごい面白いですけどね今考えると
そう間違えてただけなんですけどね
FlashとWebGLの違いもわかんないような本当に
まだまだ開発者でもなんでもなかった素人だったんで
いやでもすごい先見の面があったといいますか
いやでもねなんかFlashもねやっぱり
まさかなくなっちゃうとまでは思わなかったというか
こういう流れはやっぱり当時は予測できなかった
だからさっきの話にちょっと戻りますけど
本当にその時代の変化にいかに対応していくかってことが大事なんでしょうね
そうですよねやっぱ政治的なところ
Webって政治的なところがあまり受けにくいところにあると思ってはいるんですけれども
今ちょっとChrome、Googleの一興みたいなところの背景とかあったりだとか
そういったところを考えるとまだWebも完全に安泰な
政治的土台にあるという変な表現ですけれども
変わりゆく要素は十分にあるのかなと思っているので
今後の変わりゆく時代にどう我々自身が対応していくかって話に行き着くんですよ
そうですね間違いない
だからやっぱり変化を恐れず柔軟に成長する気持ちを忘れずにっていうことなんでしょうね
ね確かに
うまくまとめた感じが
うまくまとめた
♪~
はいえーとでは
えーと
いろいろと話がつきない感じで
もうこのまま続けていくとどんどん無限に喋っちゃいそうなので
1:33:00
ちょっとね今日はこの辺で一旦ね空気を切ろうかなと思います
最後に池田さんの方から告知などあればということでね
お話があるということなんで池田さんよろしくお願いします
はいえーと私のやっている会社株式会社ICSではですね
フロントエンドエンジニア募集してまして
あのもし今日は話聞いたところで新しい技術もある程度できるし
WebGLとかを中心にクリエイティブなところのコンテンツも作ってみたい
チャレンジしてみたい学んでみたいみたいな方がいらっしゃったらですね
是非ともあの応募のチャレンジお待ちしてますので
あの公式の私の会社のサイト上に採用情報載ってますので
そこに細かいこといろいろ書いてるんで
もし見ていただいてもし合いそうだチャレンジしてみたい方がいらっしゃったら
是非とも応募いただければと思います
はいありがとうございます
いやもうぜひもし私駆け出しだったらもう今すぐ突撃したいぐらいの感じですけど
はいあのぜひね今日のポッドキャストの中で
池田さんの人柄というか組織としての取り組み方とかも含めて
いろいろ話題があったと思いますのでね
興味がある方がいらっしゃいましたら
是非応募していただければなと思います
はいえーとではねちょっと長くなりましたけども
今日はこの辺りで終わりにしたいと思います
池田さん本当に今日はありがとうございました
ありがとうございました
はいあのまた声が違うな
また機会がありましたら声がけすることもあるかもしれないですけども
はいその時はまたよろしくお願いします
はいよろしくお願いします
はいでは今日はこれで終わりにしたいと思います
最後までご視聴いただきましてありがとうございました
ありがとうございました
♪
