おはようございます、リスナーのみなさん！今日は2024年5月30日、木曜日です。ようこそ「zenncast」へ、お相手はマイクです。今日もZennでトレンドの記事をご紹介していきますよ。

さて、前回紹介した記事をさらっとおさらいしますと、「無料で商用にも使える日本の郵便番号APIをリリースしました」、「クラウド時代のデータベースを理解するために①」、そして「React でゼロからフローチャートUIを実装する」といった内容でしたね。

今日は特におたよりがありませんので、早速本日のトレンド記事を紹介していきましょう！今日は全部で5本の記事をご紹介します。

まず1つ目の記事です。「[Playwright]VScodeの拡張機能でらくらくブラウザ操作」というタイトルで、スペースマーケットの新卒Webエンジニアdumbled0reさんが、VScodeのPlaywright拡張機能を使ってブラウザ操作用のコードを簡単に生成する方法を紹介しています。

PlaywrightはMicrosoftが開発したオープンソースのE2Eテスト自動化フレームワークで、主要なブラウザに対応しています。この記事では、VScodeにPlaywrightの拡張機能をインストールし、テストコードを作成する具体的な手順が説明されています。例えば、`tests/example.spec.ts`ファイルを作成し、初期設定を行います。そして、VScodeのサイドバーからPlaywrightのアイコンをクリックし、「Record at cursor」を選択すると、GUI上でブラウザを操作するだけで、その操作に対応するコードが自動生成されるんです。

生成されたコードの一例として、特定のスペースを表示するための操作を記録したコードが紹介されています。さらに、動作確認をしやすくするためにコードに2秒のスリープを追加する方法も説明されています。この記事のまとめとして、Playwrightの拡張機能を用いることで、非エンジニアでもGUI操作だけで簡単にブラウザ操作用のコードを生成できることが強調されています。

....

次に2つ目の記事、「明示的な型注釈によって推論コストを下げるというアプローチ」です。近年、TypeScriptのエコシステムでは、型注釈を明示的にすることで型推論や型生成のコストを削減するアプローチが注目されています。特にTypeScript 5.5 betaで導入された`--isolatedDeclarations`オプションがその代表例です。このオプションは、モジュールからエクスポートされる関数や変数に明示的な型注釈を求めることで、型推論の範囲を限定し、パフォーマンスを向上させるものです。

TypeScriptの型推論は非常に強力である一方、大規模プロジェクトではパフォーマンス問題が発生することがあります。Rust製のツールチェインが増える中で、TypeScriptの型情報を利用する手段がtsc以外にないというロックイン問題も浮上しています。これに対して、型注釈の明示化によってモジュール間の型依存を解消し、型情報の取得を高速化する試みが進められています。

このアプローチは、特に型宣言ファイルを出力する必要があるパッケージやモノレポ環境下でのメリットが大きいとされています。結論として、TypeScriptのエコシステムでは、明示的な型注釈を促進することで、型推論のコストを下げ、開発効率を向上させる取り組みが進んでいます。今後の動向に注目が必要です。

....

続いて3つ目の記事、「デザイナーとエンジニア、両者の目線が大切なコンポーネント粒度の設計」です。この記事は、株式会社SODAが初めて開催した外部向け勉強会「SODA Flutter Talk #1」での内容を一部抜粋したものです。SODAではモバイルアプリの開発をFlutterで行い、デザインをFigmaで作成しています。エンジニアとデザイナーが効率的に協力するためには、コンポーネントの粒度について共通の理解が必要です。

エンジニア目線では、Figmaのコンポーネント粒度とFlutterのWidget粒度を一致させることが重要です。これにより、変更が片方にのみ起こるといった問題が減り、バグの発生を防げます。また、カラーやテキストが異なっても、形が同じであれば一つのコンポーネントとして定義することが望ましいです。これにより、コードの総量が減り、メンテナンスがしやすくなります。

一方、デザイナー目線では、コンポーネントの使いどころが分かりやすいことが重要です。形や役割が同じでも、使用する画面によってコンポーネントを分けている場合、抽象化しすぎると使い方が分かりにくくなります。デザイナーとエンジニアの間で定期的にコミュニケーションを取り、理解を揃えることが大切です。

SODAでは、FigmaのVariant機能とFlutterの名前付きコンストラクタを活用しています。FigmaのVariant機能を使うことで、類似するコンポーネントを一つにまとめ、管理を簡素化しています。Flutterでは、名前付きコンストラクタやFactoryコンストラクタを用いて、Figmaのプロパティと一致するインターフェースを提供しています。

....

そして4つ目の記事、「データモデリングに向き合ってみた話とその気づき」です。レバテック開発部の前原さんが、社内営業支援システムの改修を通じて得たデータモデリングの重要性とその実践結果について述べています。営業支援システムでは、ステークホルダーからの具体的な要望によりカラムを追加することが多く、データモデリングが不十分なため、システム外で問題が解決されることが多く、認知負荷が増加していました。

データモデリングの仮説として、ドメイン理解の深化、問題解決モデルの構築、認知負荷の軽減、将来の機能拡張性の向上が挙げられました。実際にモデリングを行った結果、ドメイン理解の深化や認知負荷の軽減は達成されたものの、問題解決や業務改善には至らないことが分かりました。

具体的な改修例として、案件の流入経路と担当者を記録するためのデータモデルの変更が挙げられます。活動履歴を異なる概念として扱うためにサブタイプとして分割し、認知負荷の軽減を図りました。結果として、データモデリングを通じて業務理解は深まりましたが、根本的な業務改善には至らず、データモデリングは業務改善のための一手段であることが強調されました。ユーザーの入力しやすさや開発者の認知負荷も考慮する必要があると結論付けています。

....

最後に5つ目の記事、「プロダクトを横断したFigmaコンポーネント構築 〜「インスタンスガイドライン」を策定した話〜」です。レバテックのプロダクトデザイナーである成田さんが、Figmaを用いた横断的なデザインシステム『VoLT』の構築過程で直面した課題と、それを解決するために策定した「インスタンスガイドライン」について解説しています。

レバテックは複数のプロダクトを運営しており、それぞれのプロダクトに異なるデザイン仕様が求められます。そのため、UIライブラリ「Levtech-Components」が存在していたものの、デザイナーが独自のコンポーネントを作ることで一貫性が失われる問題がありました。

『VoLT』はこの問題を解決するために、汎用性が高く管理コストの低いコンポーネントの作成と、インスタンスガイドラインの作成を行いました。汎用的かつ効率的な設計を行い、プロダクト横断で使用するコンポーネントを選定しました。また、ステータスの優先順位を明記し、エンジニアが実装時に迷わないように工夫されました。

インスタンスガイドラインは、各コンポーネントのオーバライド可能範囲を明確に定義し、変更を加えて良い箇所を示しました。これにより、デザイナーが個人の判断で変更を加えることが減り、エンジニアも変更点を一目で把握できるようになりました。

結果として、コンポーネントの管理が容易になり、デザイン制作と開発の生産性が向上しました。現在も『VoLT』は成長中であり、さらなる改善が進められています。

さて、今日は5本の記事を紹介しましたが、いかがでしたでしょうか？詳しい内容はショーノートに書いてありますので、ぜひチェックしてみてください。それでは、次回もお楽しみに！感想やご意見もお待ちしています。では、また次回お会いしましょう！