「POST Dev | ビジネスを変革するモダンフロントエンドの祭典」を視聴したのでまとめてみた

# はじめに
就業先ではあまりフロントエンド開発の取り組みは社内で盛んになっておりませんが、
興味があったので視聴させていただきました。
ここでは学んだことを共有させていただきます。

# 概要等
日時:2022/10/01(土) 10:30~17:30
[イベント公式サイト](https://lp.nijibox.jp/cp/postdev/)
[イベントTwitter](https://twitter.com/PostDev_oa)
Twitterで`#postdev`を打つと関連するTweetが出てくる

### 主催者企業様
[株式会社ニジボックス様](https://www.nijibox.jp/)
[公式youtubeチャンネル](https://www.youtube.com/channel/UCd1p76tumQBMM9EAEPuqnaA)
[twitter](https://twitter.com/nijibox_jp?lang=ja)


### conpass掲載全体テーマ
>テーマは「ビジネスを変革！モダンフロントエンド × 組織論」
【フロントエンドエンジニア × 変化するその役割】
近年、フロントエンドの開発手法に大きな変化が起きています。きっかけは、スマートフォンの登場とその急速な進化でした。Webサービスの利用が人々の日常となり、デバイスが多様化。だれが、どこで、どんな使い方をしても、快適なユーザー体験を提供する必要がありました。そして、そのことはフロントエンドエンジニアの役割を大きく変えました。
【モダンフロントエンド × ビジネスを加速する組織】
モダンフロントエンドと呼ばれる、ReactやVueを駆使して行うSPA（Single Page Application）開発。その生産性とWebパフォーマンスの高さから、プロダクトの検証と改善を高速に繰り返すビジネスのグロースにもマッチします。本イベントでは、モダン開発組織の構築ノウハウをはじめ、2022年現在の開発トレンドを多角的にラインナップ。明日からのビジネスを加速させる知見をお届けします。

# 留意事項
<ul>
<li>「感想・学んだこと」は自分が大事だなと思ったことを、自分の言葉でまとめているので、ヌケモレ等不備がある場合がございます。</li>
<li>また、実業務での使用頻度が低かったり、僕の勉強不足等で至らない点が多いかもしれません。そしたらこっそり教えていただけると幸いです。</li>
<li>視聴しながら参考にした外部サイトも添付しております。</li>
</ul>

# Opening
### 登壇者及び全体のナビゲーター
<ul>
<li>
古川 陽介 (株式会社リクルート / 株式会社ニジボックス デベロップメント室室長
Software Engineer)
</li>
</ul>

### 概要
<ul>
<li>
会全体のテーマや進め方の共有
</li>
</ul>

# フロントエンド組織論

### 登壇者
<ul>
<li>
広木 大地　(株式会社レクター 取締役
一般社団法人 日本CTO協会 理事
Software Engineer / Engineering Manager / Organization Architect)
</li>
<li>
佐藤 鉄平　(サイボウズ株式会社 執行役員 開発本部長
Software Engineer / Manager)
</li>
</ul>

### サイト掲載概要
>自らも先端技術を追求し続けるエキスパートでありながら、開発組織を率い、次世代のエキスパートの育成に日々奮闘し続ける3名によるパネルディスカッション。「DXクライテリアの現状」、「開発組織の課題や理想像」をトピックとして、登壇者ご自身の組織のリアルな状況や今後の展望などを共有いただきます。一開発者として、一経営者として気になる、これからのフロントエンド開発の「人」や「組織」の可能性について一緒に考えを深めていきましょう！

### 感想・学んだこと
<ul>
<li>
DXクライテリア…DXのためのチェックリストのようなもの。
</li>
<li>
チェックリストのようなものがあることで、DXに必要なものを網羅しながら、ボトムアップを解消し、わかりやすいエビデンスとなるので便利
</li>
<li>
また、開発者体験の向上や組織の改善状況を見える化できる。これを組織として経営層に共有できていないと、いわゆる「机上の空論」になる。その際に役立つツールとなる。
</li>
<li>
項目が多く、利用への心理的ハードルが高いため、簡易版や英語版などで、組織にとりいれやすい工夫をしている
</li>
<li>
プロパーメインの企業だと、他社の開発方針を取り入れる機会が少ないので、社員個人のレベルで参考にするとよい
</li>
<li>ただ、単純な導入は難しいので抱えている顧客や組織方針に順応させるための最適化や組織編成が必要になる</li>
<li>新しい開発思想・技術はやる理由、やらない理由を明確にするために、一度実践をしてみる。そこであえてやらないことのメリットを知ることで逆説的に文化となる</li>
<li>一般社員とは遥かに生産性の異なる上位の社員が、下位社員を評価をする時間があるなら、生産的な業務にその時間を当てたほうが、貢献につながるのではないか？（評価にコストかかり過ぎではないか）</li>
<li>ジョブ型雇用やインセンティブ制度、社員からアピールしやすい環境など、企業全体で整備すべき</li>
</ul>

### 外部情報
[DX Criteria (v202104)](https://dxcriteria.cto-a.org/)
[簡易診断](https://dxcirt.cto-a.org/) 
[詳細なスライド](https://www.kantei.go.jp/jp/singi/keizaisaisei/miraitoshikaigi/suishinkaigo2018/corporate/dai6/sankou1.pdf)
[ジョブ型雇用について](https://www.manpowergroup.jp/client/manpowerclip/hrconsulting/jobtypeemployment.html#:~:text=%E3%82%B8%E3%83%A7%E3%83%96%E5%9E%8B%E9%9B%87%E7%94%A8%E3%81%A8%E3%81%AF%E3%80%81%E6%98%8E%E7%A2%BA%E3%81%AA%E3%82%B8%E3%83%A7%E3%83%96%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%82%B7%E3%83%A7%E3%83%B3,%E5%9F%BA%E6%9C%AC%E7%9A%84%E3%81%AB%E3%81%AF%E3%81%82%E3%82%8A%E3%81%BE%E3%81%9B%E3%82%93%E3%80%82)

# VS Codeで試みる開発体験の向上

### 登壇者
<ul>
<li>
Tomomi Imura (
Microsoft
Developer advocate)
</li>
</ul>

### サイト掲載概要
>Visual Studio Codeはエンジニアのみなさんでしたら、とても馴染み深い印象をもたれているのではないでしょうか？現在、私はマイクロソフト社でDeveloper AdvocateとしてVS Code開発チームとも一緒に働いています。今回はDeveloper Experienceの観点から、マイクロソフトの開発者たちと試みた取り組みに関してご紹介します。今回の試みでは、開発者の体験をより良いものにし、モチベーションを上げるために、開発者ならば誰もが好きなVS Codeのエクステンションを使ったアイデアを実施しました。また、技術的な観点からVS Codeの新機能や、これからの取り組みについてもお話ししたいと思っています。

### 感想・学んだこと
<ul>
<li>
個人的に業務でteamsを使っているので、開発者側の人がteamsを「Monster Product」って言ってたのに笑いました
</li>
<li>
ユーザーがソフトウェアを使いこなすまでには時間がかかる
</li>
<li>
teams toolkitという拡張機能がある
</li>
<li>
teamsのクライアントから紐づいたアプリのテスト、bot実行などを行えるらしい…
</li>
<li>
全体として拡張機能を存分に使いこなしてvscodeを使いこなすことを勧めていた
</li>
</ul>

### 外部情報
[公式docs](https://learn.microsoft.com/ja-jp/microsoftteams/platform/toolkit/teams-toolkit-fundamentals)
[登壇者Qiitaの参考になる記事](https://qiita.com/girlie_mac/items/a6f8afc7b6b955e018e0)
[Remote Development](https://code.visualstudio.com/docs/remote/remote-overview)
[codespaces](https://github.co.jp/features/codespaces)
[vscode.dev](https://vscode.dev/)
[vscode Server](https://code.visualstudio.com/docs/remote/vscode-server)
[github copilot](https://github.com/features/copilot)
[vscode tiktok](https://www.tiktok.com/@vscode)

# 2万以上のエンジニアの声から分かった「The state of JavaScript」最新レポートと今後のトレンド予測

### 登壇者
<ul>
<li>
Sacha Greif (Maintainer, Devographics
Developer / Designer)
</li>
</ul>

### サイト掲載概要
>JavaScriptのエコシステムは最近、新たなフレームワークやランタイム環境の登場により、Webフロントエンドの領域はますます大きくなっています。ReactとVueにおいては、SvelteやSolidといった新しいフレームワークが登場しました。そして、Node.js自身にも、DenoとBunという、生産性とセキュリティに焦点を当てた2つの新しいランタイム環境が生まれました。この講演では、毎年行われている「State of JavaScript」の調査結果をもとに、現在のデータと傾向を調べ、過去数年間との比較や最新のトレンド、今後の予測についてお伝えします。

### 感想・学んだこと
<ul>
<li>
MPA Vs SPAの論争には決着がついていないが、SPAに関する技術が段々と差分を埋め始めている（JAMStackの実現など）
</li>
<li>
色んなフレームワークが互いに良いところや思想を今後反映し、各技術がアップデートされていくかもしれない
</li>
<li>
「結局何使えばいいんや…」という部分では、今後のトレンドをキャッチアップしつつ適応していくのが重要。そういう意味での参照元として、レポ－トを見るのは参考になる
</li>
</ul>


### 外部情報
[登壇者Twitter](https://twitter.com/sachagreif)
[The State Of JavaScript 2021](https://2021.stateofjs.com/en-US/)
[The State Of GraphQL](https://www.stateofgraphql.com/en-us//)
[The State Of CSS 2021](https://2021.stateofcss.com/en-US/)
[ハイドレ－ドの理解をなんとなくするために参考になった記事](https://zenn.dev/smallstall/articles/5531fd6647f713)
--知らなかったフレームワークや概念など--
[Remix](https://remix.run/)
[Astro](https://astro.build/)
[Qwik](https://qwik.builder.io/)
[Deno](https://deno.land/)
[Bun](https://bun.sh/)
[webcomponents](https://www.webcomponents.org/)
[lit](https://lit.dev/)
[stencil](https://stenciljs.jp/)
[React webcomponents](https://ja.reactjs.org/docs/web-components.html)

# フロントエンド開発テスト最前線
### 登壇者
<ul>
<li>
和田 卓人 (タワーズ・クエスト株式会社 取締役社長
Programmer / IT consultant)
</li>
<li>
倉見 洋輔 (
株式会社リクルート / 株式会社ニジボックス
Software Engineer)
</li>
</ul>

### サイト掲載概要
>近年、急速なWebサービスの進化にあわせ、フロントエンドテストの必要性が高まっています。特に、ビジネスの拡大を目指してスピーディーに検証と改善を繰り返すプロダクト開発において、テストの精度と効率が開発の生産性を上げるための重要な要素とされています。本パネルでは、日本のフロントエンド開発を牽引するゲストをお招きし、これまでのテストの歴史を振り返りながら、その必要性や開発組織に浸透させるメリットをはじめ、これからのテストの可能性についてディスカッションを行います。

### 感想・学んだこと
<ul>
<li>
フロントエンドの概念はここ10年でやっと定着、テストはあまり書かれてこなかった。E2Eでのビュー確認 > ロジック重視の印象
</li>
<li>
フロントエンド動作は、非同期の度合いが強く、繊細。タイミング依存になってしまうので、テストをすることのメンテナンスコストがかかる。壊れやすい。コストを掛けるのがもったいない。テストのコスパが悪いというのが背景にあり、肯定的に捉えられてなかった
</li>
<li>
現在は普通になってきている印象。そのターニングポイントは、フロントエンドという概念が作られたこと。JQuery、Reactなどデータさえ用意できれば画面が作れる技術を用いる時代になってきた。inが決まればoutが決まるため、UTが書きやすい
</li>
<li>
複雑なロジックの責務に対してフロントエンドが担う役割が増えてきた。バックエンドと独立して開発ができるから、必然的にテストをする必要性ができた。また、ブラウザの近代化、パッケージも増えてこの潮流を後押しできている。
</li>
<li>
ユーザとコンピュータに対してのアクセシビリティを高める＝テスタビリティ（テストのしやすさ）を高める。コンピュータに対してのアクセシビリティの高め方ってのは、処理の依存関係の解消とかグローバルな変数を減らすとかのリファクタリング的なやり方が必要になるってことかなぁ…理解できている自信ないです…
</li>
<li>
flakyテスト＝テストの実行結果が不安定
</li>
<li>
要約:フロントエンドでもテストは書いて当たり前の時代。個人的にはこのセクションがReactを使うことを前提としているようにお話をされていた印象があった。やはりモダンスタンダードはReactなのだなと感じた。
</li>
</ul>

### 外部情報
[和田さんのミームの記事](https://engineer-lab.findy-code.io/t-wada)
[スナップショットテスト](https://jestjs.io/ja/docs/snapshot-testing)
[msw](https://mswjs.io/)
[msw良さげな記事](https://zenn.dev/azukiazusa/articles/using-msw-to-mock-frontend-tests)
[storybook snapshot](https://storybook.js.org/docs/react/writing-tests/snapshot-testing)
[VRTに良さげな記事](https://zenn.dev/toshiokun/articles/3d7087b84ba1d9)
[flakyテスト](https://qiita.com/seigot/items/bec2c934b762a2f50821)

# データビジュアライゼーションで切り拓くArt x Technologyの可能性

### 登壇者
<ul>
<li>
Shirley Wu (
Independent Data Visualization Creator, currently Master’s candidate at New York University
Creative Developer)
</li>
</ul>

### サイト掲載概要
>データビジュアライゼーションは、情報を分かりやすく視覚的に伝える手法の一つです。数字やグラフだけでは具体的に把握しづらいことも、データが持つ意味やそこから読み取れるメッセージを可視化することでユーザーの理解と共感を得られ、具体的な行動をうながすことも可能です。 今回は、これまでに手掛けたプロジェクトの事例をご紹介しながら、データビジュアライゼーションの面白さやその価値をぜひ知っていただこうと思います。また、アートとテクノロジーの融合による表現の可能性やビジネスへの活用方法など、オーガナイザーの古川氏とディスカッションします。

### 感想・学んだこと
<ul>
<li>
古川さん、英語の発音がはっきりしていて非ネイティブなのに（だから？）聞きやすかった
</li>
<li>
分析したものを視覚データにしてわかり易く表示
</li>
<li>
登壇者のPJ内だと、歌詞と人物の情報があれば、視覚データにして表示したものにできるらしい。データを集めることができれば、多少の差分はあれど可視化は可能。めっちゃ面白そう
</li>
<li>
質の悪いデータは正しい表示結果ができないため、データの収集や処理、整理に一番時間がかかる。デザインだけでなく、中のもののプロダクトの質が大事
</li>
</ul>

### 外部情報
[登壇者ポートフォリオ](https://shirleywu.studio/)

# UIデザインに役立つ2022年のCSS
### 登壇者
<ul>
<li>
池田 泰延 (式会社ICS 代表取締役
Front-end Engineer)
</li>
</ul>

### サイト掲載概要
>今年2022年は、CSSが飛躍的に進化した一年でした。IE11終了につき利用可能なCSSの選択肢が広がっただけでなく、従来はJavaScriptを必要とした表現もCSSのみでできるようになりました。今後は、新しいCSSを知っているかどうかで、制作効率が変わってくるはずです。 本セッションでは、ウェブで頻出するUIデザインを題材として、最新のCSSで実装するテクニックと注意点を紹介します。アクセシビリティやアニメーションも含めたUIの考え方も説明します。

### 感想・学んだこと
<ul>
<li>
IEが終了し、考慮せずに利用可能になったものがある（Grid,position:sticky,object-fit,mix-blend-mode,flexboxのgap, scroll-behaviorなど）
</li>
<li>
ブラウザの対応できるCSSの差分が縮まってきている
</li>
<li>
HTMLを便利になった（dialog,imgのloading属性）
</li>
<li>
CSSの勉強は際限がないため、バージョンアップ時になんとかキャッチアップできるようにする。にしてもスライドのアニメーションがおしゃれだった…
</li>
</ul>

### 外部情報
[object-fit](https://developer.mozilla.org/ja/docs/Web/CSS/object-fit)
[mix-blend-mode](https://developer.mozilla.org/ja/docs/Web/CSS/mix-blend-mode)
[scroll-behavior](https://developer.mozilla.org/ja/docs/Web/CSS/scroll-behavior)
[@container](https://coliss.com/articles/build-websites/operation/css/about-css-container-queries.html)
[:has()](https://coliss.com/articles/build-websites/operation/css/has-pseudo-class.html)
[dialog要素](https://coliss.com/articles/build-websites/operation/work/how-to-use-dialog-element.html)
[img要素 lazy](https://iwb.jp/img-tag-loading-attribute-lazy-howto/)
[ics media](https://ics.media/)


# フロントエンド組織のつくりかた〜ニジボックスエンジニアの本音トークパネル〜

### 登壇者
<ul>
<li>
株式会社ニジボックス フロントエンドエンジニアチーム
</li>
</ul>

### サイト掲載概要
>ニジボックスには様々なサービスの開発実績があり、Reactコンポーネントの基本実装をはじめ、サービス全体の設計・実装ができるメンバーが多数在籍しています。エンジニアの能力向上施策としては、研修の開催やLTイベントなど、定期的なアウトプットの場を設けています。勉強会やイベントはメンバー主体で企画運営され、ボトムアップ力が高くとても柔軟です。本パネルでは「フロントエンド組織のつくりかた」について、実際に現場で活躍しているメンバーの目線でディスカッションします。
### 感想・学んだこと
<ul>
<li>
雰囲気が良く、フロントエンドチームのラフなパネルトークでした。てかフロントエンドで独立したチームあるのいいな…
</li>
<li>研修では開発だけではなく、そこでのアウトプットをやり取りするためのコミュニケーションへの取り組みに力をいれているとのこと。</li>
<li>もくもく会や技術書輪読会、LT会やSlackになんでもチャンネル設置など、独自の学習取り組みをしているらしい</li>
</ul>

### 外部情報
[ナビゲーターの古川さんが書いた研修に関する記事](https://qiita.com/yosuke_furukawa/items/546601b940fb53c741fb)

# フロント＆バックエンド開発がクロスオーバーする未来

### 登壇者
<ul>
<li>
伊藤 直也 (株式会社一休 執行役員CTO)
</li>
</ul>

### サイト掲載概要
>現在一休では、フロントエンドとバックエンドの実装やテクノロジーについて、お互いのアーキテクチャーの理解を深めながら、生産性の高い開発環境の実現を目指しています。具体的には、フロントエンドではRelayとRecoilを選択、バックエンド開発ではTypeScriptで記述し、薄い設計で宣言的な実装に寄せていく、といったことに挑戦しています。今回は、日々現場で試行錯誤し続ける中で得た考察をご紹介しながら、これからの開発環境について考えていきたいと思います。

### 感想・学んだこと
<ul>
<li>
フロントエンド、バックエンド間の技術に対しての関心の分離を解消するために、TypeScriptやGraphQLで解消しようというお話でした。
</li>
<li>Reactでフロントエンド開発してからバックエンドを書く→従来のようにDTOやInterface記述など開発のメンタルモデルのギャップやコンテキストの切り替えコストも大きい。これをTSで統一することで軽減できる</li>
<li>
Elm設計と状態管理を駆使して、バックエンドのみでの状態遷移を考えるのではなく、フロントの状態を含めた一つのドメインモデルを扱うことと、ほぼ同等の扱いができ、まとまった状態管理ができる（おそらく間違っているかも…難しい…）。
</li>
</ul>

### 外部情報
[Elm設計](https://guide.elm-lang.jp/architecture/)
[Recoil](https://recoiljs.org/)
[Domain modeling made Functional](https://www.amazon.co.jp/-/en/Scott-Wlaschin/dp/1680502549)
[セクション内で共有していた記事](https://zenn.dev/mizchi/articles/oop-think-modern)

# Closing
### 概要
<ul>
<li>会の閉会、サマリー等共有</li>
</ul>

# 終わりに
個人的ベストは「フロントエンド組織論」ですかね。チェックリスト的ツール、仕組みの導入やジョブ型雇用いいなと思いました。<br>
いろんな情報源にアクセスできたり、テスト分野が自分の苦手であるということも再認識できていい機会となりました。<br>
おそらくアーカイブ配信？あると思うので、見返そうと思います。