00:07
9月27日、月曜日。
嘘つけ、火曜日です。
時刻は昨日もありました。
ちょっと突然、今日も朝寝坊してしまったので、
だいぶ後ろ立ちになってしまっています。
はい、おはようございます。
miminokeethこと、くわはらです。
では、本日も朝活を始めていきたいかなと思います。
はい、今日は、
えー、まあ、今日も今日でいろいろ悩んだんですけど、
まあ、ちょっと抽象的な話ばっかりまたちょっとなってしまいがちですけども、
まあ、そんなような議事を読んでいこうと思います。
はい、一つ目は、「Webis a harsh manager」ってやつですね。
はい、ざっくり言うと、
なんかフロントエンドエンジニアの役割の拡大みたいなところですね。
の記事をちょっと読んでいこうと思っています。
はい。
なんかいろいろ役割を拡大してて、
アナリティクスだって、セキュリティ、アニメーション、キャッシュ、戦略、パフォーマンス、
ほげほげみたいなのが、
まあ、フロントエンドの領域がかなり拡大したという感じですね。
はい。
で、なんか、この記事自体実は朝活読んだような、
読んでないような気もしなかないんですけど、
すいません、僕がちょっと確認しなかったし、
まあ、改めて読みたいのは読みたいので、
ちょっと、もし重複しちゃうとしたらすいませんが、
でも、今日また改めて勉強したいなと思ってました。
はい。で、もし、あともう一個時間が余ればですね、
もう一個の記事、
ハンドリングクロスチームフィードバックループスオンデザインワークってところで、
まあ、またデザイナーのほうのチームビルディングとか組織的なお話なんですけど、
でも、このクロスチームっていうところですね、
ハンドリングクロスチームフィードバックループっていうところです。
他のチームとかの連携するところの、
ループをいかに早くできるかっていうところの記事ですね。
まあ、チームビルディングですけど、
やっぱりちょっと気にはなるので、ここを読んでいこうかなと思います。
で、この記事自体はなんか、
リッスンってあるので、なんか音読もあるんですかね。
音読というか、ポッドキャスト的なものがあるのかなと思いますけど、
まあ、こっちについてはちょっと変わったりというか、
後ほど記事のリンクはシェアしますので、そこから見てもらえればと思います。
では、早速前者のほうの記事ですね。
入っていけたらなと思っております。はい。
The Web is a Harsh Managerです。
僕はそのハーシュっていうのが単語じゃなかったんですけど、
ハーシュとは厳しいとか過酷なとか、
不快、きつすぎるみたいな意味なんですね。はい。
Webは過酷なマネージメントの領域だという話ですかね。
というところから、はい。では、いきたいと思います。
フロントエンド、Webの責任というのはますます大きくなっています。
サイトをデザインカンプのように見せるための、
3000ものプログラム可能なプロパティと、
値の組みを理解する責任者というのは、
データレイヤーのクエリに必要な言語とエコシステムを理解する責任者でもあります。
まあ、そうね。はい。
法的な危険を避けるために、Webサイトをあらゆる人がアクセスできるようにするための、
1000ページの対応を理解しなければならない担当者というのは、
侵略的なマーケティングがWeb全体で、
ユーザーを追跡できるようにスクリプトタグをコピーペーストする担当者でもあるのですと。
1000ページまで行くかどうかは別ですけど、いろんなもののアクセスできるようにするために、
法的なところを調べると、結果いろんなところのドキュメント、ドキュメント、ドキュメントというところで、
03:04
仕様だったり法的な定義だったりとかでのかと確認しなきゃいけない。
そうなると、大量の確かにその要項とかっていうのを見なきゃいけなくて、
それをわかりやすく例えれば1000ページって言っているだけだと思いますけど、
それだけ大量のものを読まなきゃいけないし、固くて難しい文章を読まなきゃいけないので、
すごく大変だなというところはありますよね。
一方で侵略的な、攻撃をする方というのは結構簡単だったりしますので。
そんなところもあって、侵略的なマーケティングがWeb全体で、
ユーザーを追跡できるようにスクリプトタグをコピーペーストする担当者でもあります。
続いて、ソーシャルメディアカードやGoogle検索結果のメタデータを設定する担当者というのは、
何千ものサードパーティーパッケージの品質とセキュリティを監督する担当者と同じです。
どこまで責務を担当者に負わせるかというのは難しいですけど、
おっしゃっている意味はわかりますという感じですね。
実際その検索結果とかメタデータを設定するって、
プロダクトを持っている会社とか事業をやっている会社だったら当たり前ですから、それは必要だと思うんですけど、
何千ものサードパーティーパッケージの品質とセキュリティを監督するっていうのはなかなか大変だと思いますね。
監督するというか、せめて把握というか、どこまで求められているかによりますけど、
まあまあまあまあそうですね。
結局自分たちは自作しない限りはサードパーティーに依存するしかないので、
その辺の品質とかセキュリティですね。担保しなきゃいけないし、それが依存するものとかやっぱりありますし、
NPMと一緒ですよね。
一つのライブラリーのパッケージのバージョンであったりセキュリティであったり、影響度というところですけど、
それが、だいたいそれって依存する他のNPMライブラリーからバーっと作られていることがほとんどですので、
何千ものって多分そういう意味だと思いますけどね。
またスクロールに合わせてページ上の要素をアニメーション化する担当者っていうのは、
データソースを使って数学ベースのベクトルで画像を作成し、
無限の組み合わせでインパクトのあるチャートやグラフを生み出す担当者でもありますと。
ここはちょっと疑問かな。スクロールに合わせてページの要素をアニメーション化する。
ああ、そっかそっか、そういうことか。なるほどですね。これは確かにごめんなさい。
いるかもしれない。数学ベースのベクトルで画像を作るっていうところの方もいると思います。
そうなんですよね。スクロールに合わせてアニメーションってそんな簡単ではないですし、
それをキャンバスとかでやってる人としても、その画像とかグラフを生み出すところでテクニック必要ですけど、
最終的にアニメーションするときって若干やっぱ数学いるんですよね。
というところで。かつ、チャートとかグラフっていうのをスクロールに合わせて表示したりすることもあるでしょうし、
背景のアニメーションをすることもあるでしょうし、結構大変ですよねってことです。
また、コードベースのキャンバス画像、キャンバス描画アプリケーションですね。
ブラウザーがボックスを描くのを制御する非同期ワーカーを描くっていう人もいらっしゃいますけど、
そういう人はインタラクティブなフォームコントロールやクライアントサイドのエラーメッセージを配線する責任者でもありますと。
06:04
どういうことだ。コードベースでのキャンバス描画アプリケーションで、
ブラウザーがボックスを描くのを制御する非同期ワーカーを描く人。
インタラクティブなフォームコントロールやクライアントサイドのエラーメッセージを配線する責任者でもあります。
ちょっと言わんとしていることが分かりづらいですけど、非同期ワーカーを描く人は、それはもちろんフォームコントロールをする人でもあるし、
エラーメッセージを描く人でもありますよね。非同期で何か処理するんだから、そりゃ描きますよねっていうところはありますけど。
はい、すいません。ちょっとここは僕が意図を読み取りになったです。
はい。あと最後に、内部と外部のすべてのウェブプロパティで消費される特定のユーザーストーリーを満たすために定義された、
シリアライズされたデザイントークンとコンポーネントのハイレベルなシステムを作成する人っていうのは、
制御を担当する人たちです。ここはそうですね。はい、まさしくそんなところだと思いますね。
はい、まあなどなど。いろんなことを書いていたんですけど、要はフロントエンドエンジニアってやることとか、責務が最近多くねって話だと思いますね。
はい。これらの仕事はすべて同一人物です。はい、まあそうですよね。
フロントエンドエンジニアって本当に、ただ単にJSON色付けをするわけでもないし、ビジネス的にはいろんな解析タグだったり追跡タグっていうのを
配置しなきゃいけないし、まあそれがアプリケーションに影響してちょっとパフォーマンス悪くなったりすることもあったりするし、
それぞれの依存するツールとかライブラリーのそのバージョンとかセキュリティをずっと担保しなきゃいけないし、
アニメーションを書かなきゃいけない人っていうのは、全然フロントエンドだとアニメーションを書くんですけど、そのアニメーションするのをちゃんと何ですかね、画面のスクロールに合わせて
アニメーションするためには実は裏側でちょっと数学的な話が必要になったりとか、パフォーマンスセキュリティがどうだろうとか、あとアクセシビリティも最近ありますっていうので、
要はフロントエンドって最近単にJSON色付け係じゃないし、昔のおっさんたちが言うようにサクッと終わるでしょフロントエンドだから、
所詮画面の話だよねみたいな話はとっくに通り過ぎてて、今はめちゃくちゃ複雑度高くかつ要求も高いよって話ですね、これはってことです。
そういう意味でフロントエンドエジニアって需要が高まったり、市場価値が上がっているっていう話は僕は叱るべきだし、そうなってくれないとむしろ俺ら的には不満ですよね。
責務が増えてやることも増えたのに、ずっと軽く見られるのは尺に触らないという感じがありますし、僕も今までそういう経験を過去何回かしたことがあって、
我慢しましたけど、やっぱりモヤモヤしますねって話です。すみません、余談でした。では戻りますね。
これらの仕事は全て同一人物です。ある意味フロントエンドのウェブっていうのは悪いマネージャーのようなもので、時間が経つにつれて範囲がどんどん広がっていきます。
私は逸話的な証拠以外何も持っていませんが、これはフロントエンドの人々の間でコンテキストの切り替えによる燃え尽き証拠部に繋がる問題だと推測しています。
新しいスキルを学ぶことは詳細にあたえしますが、学ぶべきトピックの終わりのないリストと緊急の要求の大きな触れ幅によって常にストレスと再発明の状態に置かれるのです。
09:11
フルスタックは私より先に多くの人が指摘しているようにこの状況を悪化させるものですよというふうに言っています。
そういう意味でフルスタックというのはあまりよろしくないよねっていう話をしていて、すごいですねこの人はそこの辺に対して割と本当にヘイトが溜まっているのがわかりませんが、
英文ではフルスタックas many have noted before meというふうに書いているんですけど、このas many have noted before meってそれぞれに一個一個別の記事のリンクが書かれています。
めちゃくちゃ言いたいことが本当にあるんでしょうけど、ようやくして一言でガンと述べたんでしょうねっていうのがあるので、
だいぶこの人は今までフロントエンドのそういういろんなことを求められる環境下に置かれて割と大変だったんだなっていうのが推察はできますね。
はい、ちょっと面白かったですけど、カチューにいた時は僕もヘイトだらけだったというような記憶がありますね。
ちょっと面白いので、この記事にもっと後ほどリンクを送りますので、皆さんの方で見てみてもらえればと思います。
はい、で、戻りますね。
数年前、クリス・コイヤーはThe Great Divideっていう投稿でこの闘争を要約しています。
The Great Divideっていう記事のリンクがあるんですね。
この投稿は私たちがショップトークで行ったフロントエンド開発者のように考えるというものですけど、
そのものにはシリーズから得たものですと。
フロントエンド開発者のように考えるにはというタイトルのシリーズから得たものだということですね。
で、このシリーズっていうのはブラッドフロス、このシリーズでブラッドフロスっていう方がおっしゃってるんですけど、
フロントオブフロントとバックオブフロントという2つの分断の側面というのを予想してましたけど、
それは今でも私の心に響いてます。
フロントエンドを何通りかに分けてもまだまだやるべき仕事はたくさんあるはずです。
ブリッジの役割を提案する人もいますが、はい、わかります。
フロントエンドも、ざっくりフロントオブフロントエンドとバックオブフロントエンドっていうワードが
ちょっと前ですか、日本でも、どなたかが記事書いてたと思って、
僕もそれはずっと心に残ってるし、いまだにキャリアプランとかメンバーのキャリア相談とかのお話をするときとか、
学生さんから聞かれるときにもこのワードを使ったりはしますね。
本当はどっち方面に行きたいですかっていうところですけども、はい。
で、フロントオブフロントエンドって今は例えばデザインエンジニアみたいなところですね。
エンジニアリングをやった人がデザインをやる、その逆ですね。
デザイナー側からエンジニアリングを学んでいくっていう、両方あると思います。
けど、とりあえずフロント、デザインエンジニアっていう領域が今は隠れしてるのか、
他のいろんな会社さんでもデザインとエンジニア、結局両方やっているフロントエンドの人、
もしくはデザイナーさんって結構いらっしゃって、
それを包括してデザインエンジニアというような一つのクリとかポジションで動いていくっていうのも全然あると思います。
デザインエンジニアと呼ぶか、エンジニアリングデザイナーと呼ぶのかはちょっと難しいですけど、
12:02
ちゃんと言葉を分けて、エンジニアの人がデザインをやると、
結局もともとはエンジニアなので、デザインエンジニアでいいと思います。
その逆はエンジニアリングデザイナーでいいんじゃないかなと思ったりしていて、
明確に分けた方が名前的にバッティングしないなと思ったりしますね。
結局どっちが中心なのみたいな話になりがちだと思いますので、余談ですけど。
ただ、フロントオブフロントエンドもバックオブフロントエンド、
特にバックオブフロントエンドって、
単にバックって一つで、ビジネスロジックとかそういうところがっつり、
中身の処理的なところに注力をする人たちっていると思うんですけど、
バックオブフロントエンドも今、一言ではもう述べられないですよね。
さっきも言った通りですけど、セキュリティの担保をする人もいれば、
パフォーマンスチューニングがある人もいれば、
そのバックエンドAPIとかの仕組みだったり、
そういうエラーハンドリング周りをがっつりガリガリと設計する人もいればというところで、
単にバックオブフロントエンドと言っても、
いろんな多種多様なバックエンドの人がいると思うんですよね。
最近だとBFFとかグラフQLを使ったような設計を開発する人もいらっしゃると思いますので、
いろんなバックオブっていう文脈があって、
単にフロントエンドエンジニアって一言で言っても、
何が得意、何をする人なのか、多種多様すぎるんですよね。
そこを分割分けて、あなたはこのエンジニア、このエンジニアって分けるのは結構ですけど、
結局それをブリッジするフロントエンドエンジニアは何やかんや必要だよねって感じになりますよね。
結局システムを動かすため、ちゃんとシステムを開発するためには、
結局物事が動くようにしなきゃいけないので、
それを繋げる役ってのは絶対必要になるんですよ。
みたいな話が、これは今後もずっと続くんだろうなと思ったりしてます。
結果、求められるのはやっぱりフルスタックだよねっていう話も、
絶対出てくると思って、そういう揺れを戻しだったり、また分断だったりとかは、
この先もずっとそのカーブは続くと思います。
何やかんや、今も例えばRedwood.jsとかFlitzみたいな、
今いわゆるフロントエンドでフルスタックフレームワークって言われるものがまた誕生してきたんですよね。
数年前にフルスタックはもうきつくて、やっぱりバックとフロントって分けて、
クライアントAPI形式でアプリ作った方が良くないっていうのが主流になったんですけど、
結果今またフルスタックフレームワークが来始めているっていうのが何とも言えないですね。
要はフロントの方でタイプスクリプトで型定義ができて、便利じゃんと思ったけど、
その型はバックとフロントで共有できないの辛いよねってなって、
なんかNest.jsみたいなやつが生まれて、結局全部JSでやるんだし、
Node.jsでAPIとか作ったりとか、全部JSでやったら良くないっていうので、
またフルスタックのフレームワークができたと思います。
Redwood.jsもBlitzも結局裏側はJSですからね。
多分バックエンドは基本的にNode.jsで、なんだっけ、Expressで使われてるような気がしますけどね。
で、側の方は自由に選べるんですけど、多分基本的にはリアクトベースだったような気もしています。
15:02
まあちょっとRedwood.jsは僕はちょっと触ってないんですけど、Blitzは確かリアクトだった記憶がありますね。
はい、みたいなお話で、JSがフロントもバックも制御をするっていうのは別に悪くはないなと思ったりしました。
まあデータベースもNode.jsからデータベースにアクセスできるモジュールもいくつかありますのでね。
はい、すいません、余談オブ余談でした。
本記事に戻りますけど、フロントエンドって何通りに分けてもやるべき仕事っていうのは実は分けたけどまだあると思うし、
それをブリッジとする人もなんだかんだ必要だよなっていうところで、
そういう背景もあるから、すいません、また余談ぶち込むんですけど、
現代のフロントエンドエンジニアのエンジニアリングマネージャーとかプロジェクトマネージャーの方ってすごい大変だと思います。
フロントエンドマジ分からんっていうのも気持ちとしては僕も分かるし、
僕らフロントエンドエンジニアも今フロント領域全部が分からんわってなるので、
会話できるようにせめてツールだったりその領域の専門用語とかツール周りを知っておいて、
会話だけはせめてできるようにしとくぐらいが結構責の山だったりしていて悩ましい今この世の中ですね。
はいすいません、本文に戻ります。
でまた続いていきましょう。
ナタリア・シェルバーンという方がこの考えをデザインエンジニアリングと呼ぶ橋渡し役として表現しています。
はい、今言った話がまた登場するんですね。
デザインエンジニアリングと呼ばれる橋渡し役として表現していますと。
これはデザインとエンジニアリングの橋渡しをする人のことです。
また何名かの方々とともに、ちょうどワードが出てますけど、デザインエンジニアリングハンドブックっていうのを書いたそうですね。
デザインエンジニアリングハンドブックっていうのが出たそうです。
リンクもありますね。
デザインエンジニアのすべての役割と責任をここで解説しました。
すべてっていうワードを使うのは結構強いですね。
デザインとエンジニアリング、そして製品、マーケティング、利害関係者の間でコラボレーションとコミュニケーションを促進する個々のワークフローと組織構造を設定する必要があります。
もしあなたが良いデザインにお金を払っているのなら、これは理にかなっています。
デザインがうまく設計されるように投資を保護するのですというところです。
はいはいはい、まあまずそうですよね。
デザインエンジニアってよく考えたデザインとエンジニアリングだけをやるわけではないですし、
マーケティングとか利害関係者のコラボレーションとか、そういうデザインエンジニアって多分一番求められるのは何やかんやコミュニケーションだと僕は思ったりしますね。
デザインで何のためにデザインするかって、ユーザーのためにデザインするし、それを設計するステークホルダーの人とのコミュニケーションをする必要が絶対にあるので、
なおかつデザイナーとエンジニアリングの橋渡し的なポジションをするのがデザインエンジニアだと思うので、
それをやる人は関係者が増えるという限り絶対にコミュニケーション能力とかスキルが必要になってくると思います。
どのポジションでももちろん大事なんですけど、特にデザインエンジニアこそコミュニケーションが必要だなというふうに僕は思ったりはしてますね。
実際そういうところが重要だよなということでした。
18:01
で、続いていきましょう。アレックス・セストンという方ですかね。
ビルドとデプロイメント、パフォーマンスとエラーの監視、依存関係の更新を管理するアプリケーションの意図とアプリケーションの現実との間の橋渡し役として、
フロントエンド運用担当者というのの役割を決めましたと。
運用担当者って言いますけど、要はフロントエンドオプスっていう記事が書かれてますね。
フロントエンドオプス、これはちょっと読んでみたいけど、朝霞で読むからちょっと悩ましいですねこれ。
一応文面ばっかりではあるんで読めるかもしれないんですけど、ちょっと明日はこれ読んでみましょうかね、試しに。
まあまあそのところですね、フロントエンドオプスというような定義をしたそうです。
それはアプリケーションの意図とアプリケーションの現実との間の橋渡し役というふうな定義だそうですね。
これは小規模なものであってもフルタイムで働くのに十分な仕事だと思います。
これらは全て優先順位をつけなければ横並びになってしまう重要な業務ですよというふうに言ってます。
まあそうだよね、横並びになってしまうと結果、大体同時並行で進めてこけることがほとんどですね。
しっかり優先順位をつけて縦線で、高速シングルスレッドで仕事を進めるのがいいよねっていう話だと思います。
もちろんサーバーにはそういう並列で支えればいいじゃないですけど、
人間は結局思考的にシングルスレッドの生き物ですので、
そのシングルスレッドを超高速に回してイテレーションを速くする方が仕事は実は早いよねって話は皆さんご理解だと思います。
サーバーも本来はマルチスレッドだったり、本当にコアが2つあればマルチスレッドできるんですけど、
コアが1つでも一応マルチスレッド処理はかけるんですが、
あれって人間より超超超速い高速なシングルスレッドでマルチにやっているように見せかけているだけですので、
サーバーも本当は高速シングルスレッドの方が良かったりするっていう考え方もあったりしますけどね。
すいません、本番に戻ります。
また、まだ発見されていないブリッジの役割っていうのももちろんあるでしょう。
個人的には新しい専門分野も必要だと考えています。
例えばCSSエンジニアという肩書があればですね、
優れたCSSアーキテクチャの裏表っていうのを知っておいて、
アプリの行動の行数を何千行も減らすことができたりしますと。
これはわかります。本当にCSSバリバリ強い人の書くCSSって、
すごいスッキリしてシンプルで、かつすごい勉強になるんですよね。
なのでこれはわかります。
ちなみにCSSの文字、設計の勉強がしたい方はですね、
僕もいろんなところで発言してるんですけど、
BootstrapっていうCSSのフレームワークあるじゃないですか。
あれのソースコードを読むといいと思います。
めっちゃ勉強になりますよ。
やっぱりすごい設計されてるし、全世界であれだけ、
もう数年ずっと使われ続けているライブラリというのはなかなかないですからね。
この業界で数年ずっと全世界で使われるなんて、
普通ありえないことなんですけど、それが使われ続けているという実績があるので、
やっぱり実績にはしっかりした設計とソースコードがあるっていうのは、
やっぱりすごいなと思ったりするので、
もし興味ある方はBootstrapのCSSコードを読むと、
CSSの設計がすごくできますよっていうのはちょいちょい言ってます。
21:03
別にBootstrapを使えっていう意味ではないです。
使わないけど、勉強の題材としてはかなり優秀だと思ってます。
では行きます。戻りますね。
CSSエンジニアとかいたらアプリのコードを何千業も減らすこともできるでしょう。
しかしそのような肩書きでは十分な報酬も得られないでしょうから、
レンダーオプティマイゼーションエンジニアレベル6のような、
より公式な響きを持つ肩書きにする必要がありますね。
そうすればAmazonからお金がもらえるかもしれません。
まあなるほどね。確かに。
CSSエンジニアってだけで名乗ると、確かに昇給は望めないかもしれないし、
CSSをわからない人が、CSSエンジニアの方がどれだけバリューを出したり、
貢献しているかっていうところを測るのは結構難しいと思うので、
確かに肩書きをレンダーオプティマイゼーションエンジニアってなるのは面白いですね。
いやでも確かにレンダリングの最適化をするエンジニアって言われたら、
いやこれは価値高いでしょう。
そんなこともあったりするかもしれません。
今週はフロントエンドの人ができる様々な仕事のスペクトルを横断している、
自分に気づくので答えはなく疑問だけはまあまあ残りますねって感じですね。
要は問題がどんどん現実がクリアになっていくのはわかりますが、
でも答えがなくて結局モヤモヤは残っちゃいますねって感じですね。
でフロントエンドの専門家になるのはやはり難しいですと。
それにウェブサイトを作るだけで12人必要、出ないとツイッターで怒られるみたいな。
という結論もどうかとやっぱり思います。
どっかで12人必要だっていう理論とかあるんですかね。
すみません僕が不勉強で申し訳ないです。
これもどうかと思います。
それだとぶっちゃけウェブサイトが減ってしまうでしょうと。
まあまあそうかもね。
8割の作業を無くすために何か一つ変えることはないでしょうか?
っていう最後に疑問を投げてこの記事は終了になっています。
はい、そんな感じでした。
記事自体は実は結構短くてリンクだらけだったりはするんですけど、
でも今フロントエンドの複雑さだったり難航だったりとか、
いろんなところの連携関係性が出てきていて、
本当に複雑度の一等増すっていうところは感じれたかなと思います。
ここまでまとまっているとやっぱり分かりやすくていいですね。
要はフロントエンドって簡単ではないし、
かといってブリッジする人もなかなかいなくて大変だねっていう。
でも結果的に答えは出ていないし、
もやもやはするけど皆さんどうしようかなっていうところの疑問だけ投げられたっていう記事ですね。
フロントエンドエッジエンド僕としては共感しかなかったっていう感じはありますけど。
とはいえ皆さんその中でも何とかしてアプリケーションを作ってきているっていう現実はあるんですが、
なかなかここは難しい。
やっぱりビジネス的な要求と、
現在社会の変化っていうのはかなり激しくて、
そこに対して結局フロントエンドっていうのは最後、ユーザーが最初に触れるところですので、
そこをどうやってUX、UIを良くしていくかっていうのは、
デザイナーだけども話でやっぱりないと思います。
24:01
デザイナーさんが起こしたものを現実化する、
具現化するのがフロントエンドかもしれないですけど、
フロントエンドの人が最終的にそのユーザーの体験を良くするっていう領域もちゃんとあるんですよね。
先ほどのパフォーマンス1点を取っても体験が全然ガラッと変わりますし、
そこはもうデザイナーさんじゃなくてまさに僕らエンジニアの領域だったりするので。
というので割とフロントエンドエッジエンジニアってビジネス的なインパクトを持つ領域に実はいるし、
各社いろんなところですね、APIサーバーサイドの人もいれば、
そういうステークホルダーっていうビジネス側の人もいれば、
デザイナーの人もいれば、顧客からのオーダーからもあればみたいな。
実は関係者がかなり多いんですよね、フロントエンドって。
という意味でコミュニケーションスキルも必要だったりするし、
コンテキストも必要だったりするし、
話す人が違うポジションの人だったらまた頭の切り替えもしなきゃいけなくて、
そういう脳がどんどんどんどん使われ続けるみたいなところがあったりするし、
本当に大変なんだよなってことがわかるかなと思います。
グダグダ読んでしまって最後グダグダな感想で終わってしまいますけど、
こんな感じでした。フロントエンド大変だねっていうところはずっとあると思いますし、
だからこそ逆に評価上がってくれたら嬉しいなと思いますし、
この複雑なんだけどでもやっぱりフロントエンドって見た目を作るって意味では、
なんやかんや楽しいんですよね、言うて。
なのでこういうところフロントエンドの人にもちょっと興味持ってもらえる人が増えたら嬉しいなと思いますし、
逆にフロントエンドだから価値が高いのはわかるんですけど、
フロントエンドの方が優先だっていうつもりは全くないですし、
やっぱりなんだかんだ大事なのってシステムとアプリケーションって何が大事かって、
結局データとかアルゴリズムを使ってどのようにユーザーにそのデータを表現するかとか、
データをどう管理するかに尽きるんですよね。
そのための最後のインターフェースとしてフロントエンドがあるだけって言ったらそれまでなんですけど、
なので大事なのはデータなので、
データベースとかサーバーサイトAPIの方が大事だったりするっていうような思想とか意見があってしかるべきだと思ってます。
別にどっちが大事とかいうのは別にここで議論するつもりはないですけど、
個人的にはそっちの方が何やかんや本質的には重要だよなと思ったりはしています。
でもそれを使われなかったらその価値がないので、
そのためにやっぱりフロントエンドっていうのはマストだよねっていうのはありますけどね。
お互いがうまいこと連携できるようになっていけばやっぱりいいなと思います。
ここはもうなんかやっぱりフロントエンドの領域が難しいですけど、
これを解決するにはチームビルディングであったり、
そのビジネス的なところですね、
俯瞰的なところ、組織体制だったりみたいなところまで話を持っていかないと
本本的には解決しないんだろうな、
今後もどんどん複雑度の一途だろうなっていうのは気はしてますが、
その中どうやってやっていくかって僕らですね、
これを楽しめるようになったらエンジニア主体強いかもしれないですけどね。
という感じでグダグダといきましたけど、
これで一旦今日の朝勝は終了にしたいかなと思います。
すみません、だいぶ時間をオーバーしたんですけど、
今日はスタートが12分くらいからスタートしたので、
実は結構後ろ倒しなんですよ。
時間的にはちょうどいいかなっていうところなので、
ここで朝勝終了したいかなと思います。
本日もグダグダ配信だったんですけど、
多くの方へのご参加いただき、大変ありがとうございました。
27:00
明日はですね、さっき読んだリンクですね、
またちょっとフロントエンドの話になって大変申し訳ないんですけど、
フロントエンドオペレーションエンジニアですね、
フロントエンドオプスっていう記事のリンクがあって、
これちょっと面白そうだったので、
明日はこれを読んでいこうかなと思っておりますので、
興味ある方はまた参加してみてください。
というわけで、今日の朝勝は以上にしたいと思います。
また今日も一日頑張っていけたらなと思います。
おつかれさまでした。
