1. 雨宿りとWEBの小噺.fm
  2. Season 1-17.「現代のWeb開発..
2022-06-21 12:57

Season 1-17.「現代のWeb開発におけるフロントエンドはそんな簡単じゃないよー」

spotify apple_podcasts youtube

はい.第17回はタイトルの通り,Web アプリエケーション開発におけるフロントエンドエンジニアが考慮していることをザザーッと語ってみました💁私の夢の中で架空の人物に「フロントエンドなんて簡単でしょ.なんでこんな工数かかるの?」と煽られまして,カチンと来てしまいました😂

少しでもフロントエンドエンジニアの大変さが伝われば幸いですー❗

ではでは(=゚ω゚)ノ

  • フロントエンド
  • 工数見積もり
  • jQuery
  • 技術選定
  • アーキテクチャ
  • デザイン,アニメーション
  • パフォーマンス
  • セキュリティ
  • 保守性・拡張性
  • インフラ環境周り
  • タスク管理
  • コミュニケーションフロー
  • ミーティング
  • プロジェクト管理費
  • アクセシビリティ

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

00:06
はい、みなさんこんばんは。kkeethこと桑原です。 本日もやっていきましょう。kkeethの陽気なエンジニア雑談チャンネルです。
この番組では、ウェブ業界に関することや、エンジニアについての雑談などの情報を発信していきたいと思います。
はい、また前回の配信からだいぶ空いてしまいましたけど、基本的に、今最近はTwitterスペースでアーサー活動を朝9時にやっているんですけど、
それとか、あとは、一気にスタンドFMの方の配信がやっぱり多くてですね、
なかなかちょっとこちらの方の配信できなかったんですけど、久しぶりに喋ってみたい内容が出たので、今日はちょっと喋っていこうかなと思います。
第17回ですね、今回は。第17回は、現代のWeb開発におけるフロントエンドという領域はそんな簡単ではないですよ、ということについても話をしようかなと思いました。
はい、結論はもう出てますし、みなさんも全然ご存じのことだと思うんですけど、たまたまですね、
とある日の夢にですね、なぜか僕と全然知らない会社の営業の方がすごくバトっててですね、
営業というか、PM上がりの営業の方ですね。
僕がとあるWebアプリケーション開発のフロントエンド見積もり、外産見積もり、構数を見積もって出したんですけど、
あまりにもかかりすぎとか構数デカすぎるっていう風に言われて、
なんでそういう風に言えるのかってその根拠を、その営業の人ですね、PMの上がりの営業の人に聞いてみたらですね、
別に側作るときにそんなにこう下がる必要ないじゃんというふうにあって、JQueryとかで画面ガラガラガチャガチャ書いていけば別に動くでしょって言って、
なので、自分もその方も書いたことがあるっていう、その夢の中の営業の方ですけど、書いたこと、経験があるっていう前提で、
僕だったらこれぐらいできるけどねって言って、レベル低いんじゃないのっていう風に煽られたわけですよ。
夢の中なんですけど、ちょっとすごくカチンときてめちゃめちゃ論争をして、結局そのままで終わってしまったんですけど。
その辺の話を改めてここでちょっと吐き出したくなかったので、ちょっとしゃべろうかなと思いました。
結論的に言うと、そんなサクッと作れるわけじゃないよっていうのはその通りで、
単純に画面だけを作るって言うんだったら楽勝ですけど、
それってもウェブアプリ開発というか、単純にウェブページのコーディングでしかないので、
それだけでいいんだったら全然楽勝に、確かにそれはいけますね。
いわゆるビューを作ればいいだけでいいのであればってことです。
もちろんそんなことはないですし、拡張性とかも今後考えますし、
いろんな変更があるとか、そのUIパーツもそろそろ変えてみたいとか、時期とか、
ある程度の年数経るとウェブデザインも変えたりする可能性もあるじゃないですか。
例えばユーザーアビリティを変えてとか、日々ABテストもやって、
見せ方と言いますかね、というところも変えたりする可能性もあるので、
その辺もいろんなことを加味して、今後のこととか拡張性も考えたり、
03:03
もしくはユーザーの操作もしますよね、ユーザーって基本的には。
単純にウェブページとか、告知するだけLPみたいなものであるんだったらまた違うんですけど、
ちゃんとウェブアプリケーションというものを作るんであれば、
ユーザーが操作することは全体になるので、
その辺も加味していろんなことを考えながら作るので、
単純にJQuery入れて、ページをガンガン作ればいいというわけではないんですよね。
もちろんそれだけで、とにかくページをガンガン作っていて別にSPAとかじゃなくて、
とにかく来たら来たページをどんどんHTMLだけを出すというのであれば、
それはかからないですけど、そんなのウェブアプリとして僕らはプロとして作りたくはないですし、
そういう仕事は基本的に多分受けないと思いますね。
もしくはそれがどうしてもやりたいんだったらそのPMとか、
基本の方は自分でやってくれよという感じは正直だったりしましたね。
夢の中でそういうふうに言っちゃったんですけど、というところですね。
でも現代で見積もりするときにも、
僕らフロントエンドって何を考えるかってすごく難しくて、
もちろん機能要件、引きの要件も考えますし、
セキュリティとかパフォーマンスも考えますし、
あと技術剪定もしますし、
開発環境周りとか、デプロイどうするのかとかっていうのも考えますし、
あと一方でお客さんとか、別に社内アプリだったら社内のステークホルダーの人と、
どういうコミュニケーションをとるか。
コミュニケーションフローとか、誰が担当者でっていうそのフローを確立しなきゃいけないですしとか、
意思決定するときどうしますかっていうのも考えますし、
定例会いつ何やりますかとか、
誰が参加してどういう話をしますかみたいなことも決めますし、
チケット管理とかタスク管理どうしますかっていうのもやりますしとか、
本当に考えることたくさんあるし、決めることは本当に大量にあるんです。
その上でさらに見積もりも出すっていうので、そんな簡単じゃないですよねって感じです。
フロントエンド開発といっても、さっきも言った通りアーキテクトどうするのってのもありますしね、
SPAにするのか、それともMPAのままいくのかとか、
サーバーサイドレンダリングしなきゃいけないのかとかでもありますし、
ディレクトリ設計とか構成でも今後、
その辺は詳細設計に近いので、開発しながら適宜修正したりとか作り直しとかするとは思うんですけど、
その辺も考えますよね。
あとはCSS周りですよね。
現代はCSS in JSが結構まだモダンなんじゃないかっていう思いはしてたりもしますね。
スタイルコンポーネント使うとか、CSSモジュール使うとか、エモーションを使うとか、
いろんな選択肢ありますけど。
それでもいいですし、ユーティリティの塊であるテイルウィンドみたいなものを使っているのもいいですし、
従来通りのMUI使うとか、Bootstrap入れるとか、
いろんなその辺のものを使ってサクッとやるっていう選択肢も全然あると思いますけどね。
あとフロントエンドで考えるとしたらやはりアニメーション周りとかですよね。
細かいところなんですけどアニメーションは結局お客さんが必要だといったりするし、
画面をスクロールしたりするときにヘッダーとかがくっついてきて欲しいねとか。
スクロール中はヘッダーが隠れてて、止まったらヘッダーがヒュッとまた上から出てきたりして欲しいとかみたいなんですかね。
06:08
あと右下にずっとメニューのボタンがあってそれが追従して欲しいとかっていう、
そういうのも結構アニメーションしたりするし、パララックスしたりとかってあるんで、
アニメーション周りも意外とそれ1本だけでちゃんとコミュニケーション取らなきゃいけないし、
意外と設計と実装時間かかるんですよね。
あとそのAPIコールのところもそうですよね。
APIの仕様とか、APIチームのどういう風にコミュニケーションを取るとか、
その仕様ですね、APIのインターフェースをどうやってコミュニケーションやり取りするのかと。
現代だとやっぱりスワッガーとかを使ったりするんじゃないですかね。
これが普通だと。
スワッガーハブ使うかどうかは別ですけど、
それをするでもいいですし、例えばコンフレースとかにAPIドキュメントを一個一個、
エンドポイントごとのURLにどういう仕様ですっていうのを、
いわゆるドキュメンターツエルでドキュメントを一個一個書くでもいいと思います。
何でもいいと思いますけど、
基本スワッガーの方がありがたかったりしますよね。
Mockデータとかも一緒に書き込めて起動してしまえば使えますし、
なんならそこの環境さえあれば、それをダミーのAPIとして叩くこともできますからね。
とかとか。
あとはやっぱりどこまで言っても、エラーハンドリングのテストですよね。
この辺を考えないといけないと思います。
基本的に正常系っていうのはほぼパターンとしては少ないんですよ、正常系を。
基本僕らは異常系のことをめちゃめちゃ考慮して、
アプリケーションを実装しなきゃいけないんですよ。
テスト項数とかテストコードの量もどう考えても1対9で、
9の方がエラーハンドリングっていう僕の印象です。
もちろんその入力項目の値によってとか、
文字集別に何かわちゃわちゃするみたいな話はありますけど、
それに比例してテスト項数もそれだけ一回乗ってくるというか、
テストケースもそれだけ増えていくので、
それも乗っかりますよねみたいなところがあるんですよね。
などです。
あとは開発チームをまとめるチームリーダーみたいな人も
どうせ立てる必要があると思いますね。
もちろん全員が主体的に動いたり、
全員がリーダーシップを取れるような、
本当に実装できるチームっていうのだったら話は別ですけど、
そういうのが役割を分けているだけなので、
いわゆるプロジェクト管理費みたいな、
プロ管理費みたいに言われるものとか、
リーダーシップを張るっていうそういうソフトスキルをやらなきゃいけない、
あの項数っても絶対出てくると思うんですよね。
担当者割り振りするでもいいし、
ちゃんと専門に人立てるでもいいですけど、
その分の項数も立たなきゃいけないしとか。
あとは開発しててやっぱり僕らは魔法使いではないので、
やってみないとわからないものは絶対あるんですよ。
なのでやってみて意外と繋ぎ込みしたりとか、
こういうパターンとか、
ユーザーは実際こういうふうな使い方しますっていうのは
僕らが知らなかったり、
運用の話も出たりして、
仕様の考慮漏れだったりとか、
こういうパターンに対しての実装が漏れてましたら絶対話出てくるんですよ。
なので結局各家族に対して多少のバッファーは積むんですよね。
でないときっちり最初から予言できるなんて無理ですし、
その最初の予言した項数をオーバーした分、
じゃあ僕らが自前で持って開発するんですかって、
09:00
そういう話はやっぱりないですよ。
逆に言うと最初からも要件定義で、
僕らこういう前提で作りましたって、
その前提崩れたら別の仕様がありましたって言われたら、
それじゃあ追加項数なので、
お金と時間くださいって話をして、
それが飲めるんだったら別にいい話なんですけど、
やっぱり現場としてはそういうことは意外と難しいですよね。
お客さんとしてもやっぱりリリースはこの辺だったりとかで、
ビジネスプランを組んでたり予算の取りもしてたりして、
あとここのリリースに向けて社内もガッと動き始めてますっていうのは、
絶対話出てくると思うんで、
そうするとトレードオフにするか、
どうしても追加料金でもいいのでやってくださいって話になるかって、
絶対出てくると思うんで、
その辺も加味するとやはりバッファー積むっていうのは当たり前の話だと思うんですよ。
とかなので、そんなものを色々考慮していくと、
結果的にお金ってめちゃめちゃ積まれていくんですよね。
で、高数見積もりはデカくなっていくのは当然だと思いますね。
なのでこのJQueryとか使ってババッと側をかけるじゃんっていうのは、
何も考えてない人の発言だなと正直思ってますので、
それについて僕はあまりにも雑すぎて、
しかも煽られたのでカチンときたっていう、
夢の中でそういうコミュニケーションをしたという話でした。
いわゆる現代のフロントエンドってそんなに簡単じゃないし、
いろんなことを考えてエンジニアっていうのは、
高数見積もってまして開発もやってますよってお話ができればと思いました。
やっぱり現代フロントエンドってすごく複雑化してますからね。
今ダークモードみたいな話も入ってきたりしますし、
あれです。
太陽端末のバージョンもあるし、OSのバージョンもあるし、
ブラウザのバージョンもあってそれごとに大陸バラバラだってする。
一番厄介なのはやっぱりiPhoneサファリが、
多分フロントエンドの人達の最大の敵だと思いますけど。
WindowsのIEは、この前サポート終了したと思いますけど、 多分結果的にまだまだ日本のお客さんでお仕事する場合はIEの対応って話は何らかんだ切りづらいなと思っております。
ただもう完全に動作保証をするっていうのではなくて、 多分ベストエフォートでっていう対応に今後どんどん流れとしてなっていくと思いますし、
Edge自体がもうChromiumになるので、 基本的にChromeで最新でやっていれば基本的には動くでしょっていう話には持っていきやすくなってくる。
この辺時間の問題だと思いますけど、ので、 少しずつIEの問題についてはもう時間が解決すると思うんですけど、
iPhone Safariについてはなかなか時間が解決しないし、 iPhone Safari固有の問題、
あとiOSのバージョンこの時のiPhone Safariにしか起きない問題とか結構あったりするので、
僕らってそういうことを考えると、 フロントエンドの方々ってテストコースってめちゃめちゃかかるんですよね。
レスポンシブのブレイクポイントの 数字のバリエーションとかもあったりしますしね。
ほんと大変なんですよ。
僕らあんま全然そんな簡単に作れるとは思ってないです。
あとそうだ、最近だとアクセシビリティっていうフォグアートが出てきて、 もちろんこれは時間の問題だと思いますし、
今後日本でもアクセシビリティの今後どんどんどんどん注目されるとか、 しっかり対応を進めていかなきゃいけないと思いますね。
とにかくフロントエンドの複雑さというか、 大変さっていうのが分かっていただければいいなっていうので、
12:03
ちょっと今日お話ししました。
他にもこんなコースとかありますよとか、 この辺も考慮しなきゃいけない問題いっぱいありますよねとかって、
絶対話は出てくると思うんですけど、 さわりとしてこんなところのお話ができたかなと思っておりました。
ちょっとマーク仕立てるようにすごい早口でしゃべってしまって、 大変申し訳ないんですけど、
一旦今日の話はこの辺で以上にしたいかなと思います。
今後も話していただけることとか、 こんな話題についてくれて欲しいよみたいなのがあれば、
コメントなり意見いただけたらすごく嬉しいなと思います。
今後もこういう開発者目線のお話ができれば、 ゆるく雑なのできればなと思っておりますので、
お楽しみいただければなと思います。
またゲストトークも結構やりたいと思ってますので、
もし電子対応とか対応しなかったら、 いつでもウェルカムですので、
DMいただければなと思います。
では今日の主役をチャレンジをしたいと思います。
ではでは、バイバイ。
12:57

コメント

スクロール