「アクセシビリティカンファレンス名古屋」に参加してきました

意思疎通支援システムYYSystem〜インクルーシブデザインの実践と開発品のご紹介〜

  • 中村 正樹さん(株式会社アイシン)

YYSystem

  • 発話や環境音を可視化する意思疎通支援アプリ
    • 言葉だけでなく音の雰囲気も可視化する
  • 聴覚障がい者日本で34万人
    • 世の中聞こえる前提のものが多い
  • 少数派だからと後回しにされているところがある
    • 状況が変わると少数多数が逆転する未来も
    • その時にたいおうできるのか
  • 社会モデル/個人モデル両方の面からアプローチ
    • 情報保障ツールの提供
    • 個人の自衛手段としてのツール提供

なぜアイシンで

  • 自社で働く人のために作ったのが始まり
    • グループ会社の特例子会社のメンバーと協力して
  • 利用者の声を取り入れながら機能追加を進めてる
    • 話す人も見えるように両方向に向けて同じものを表示
    • 固定メッセージをすぐに出す
      • 勝手に録音してると勘違いされることがある
    • インターホンの音検知機能
    • 緊急車両のサイレン検出
    • AI意訳機能/自動修正
      • ChatGPTで
    • 言語の自動判定
      • 自動判定して翻訳
    • 話者識別
      • ラベル付できる
    • オフライン対応
      • 災害時など有事の際に

誰もが親しみやすい色使いへカラーパレットのアクセシビリティ改善の流れ

  • ピネイロ カルラさん(株式会社エスケイワード)

カラーパレットのアクセシビリティ

  • 既存のカラーパレットを改善したい
    • WCAG2.2のAA
    • カラーコンセプトは変えたくない
  • コントラスト比
    • テキストは 4.5:1
    • グラフィカルオブジェクトは 3:1
  • 色の調整
    • 色の明度と彩度を調整
    • 組み合わせのルールを見直し

受託制作ウェブアクセシビリティ現場最前線

  • 堀江 哲郎さん(株式会社トルク)

SmartHRの採用ページ

  • https://recruit.smarthr.co.jp/
  • モーション停止機能
    • 停止ボタンでサイト全体の動きを止める
    • ボタンホバー時のアニメーションも
    • 再訪問時も設定を維持
    • OS設定で動きを減らすようにしてたら最初から止める
  • 検索機能
    • 検索結果の件数がリアルタイムで変わるときaria-liveをつけるか
    • 絞り込み項目を押すたびに読まれるのはうるさいのではという判断
  • 検索結果
    • 検索はページ遷移ではなくJSでの書き換え
    • xx件というかしょにフォーカスさせることにした
    • 見た目はxx件だが「絞り込み結果xx件」と読ませる
  • selectとmenu
    • selectはデフォルトのselectタグ
      • 選ぶだけで何も変化は起きない
    • menuは自前で作るドロップダウン
      • 選択項目がリンクやボタンになってたりする場合
  • フォーカスインジケータ

「人にやさしい情報発信」をめざして~花王の4年間のウェブアクセシビリティの道のり~

  • 渡邊 佳菜恵さん(花王株式会社)

花王アクセシビリティ

  • グループ全体でCMSを使ってる
    • 全体で700サイト
    • コンテンツ制作は委託
  • なぜアクセシビリティ
    • Webサイトの改善を検討する中で
    • 「誰にでも使いやすい」が花王の目指すところ
    • ユニバーサル指針
      • シャンプーとリンスのきざみによる区別
      • 字幕付きCM
    • 海外の状況
      • 海外事業もあるため法的なリスク
  • アクセシビリティ診断
    • 現状を知るために外部に診断依頼
    • CMSで使ってるパーツ起因の問題
      • フォーカス順序とか
    • コンテンツ起因
      • 代替テキストがないとか
    • サイト数が多いので担当者にアプローチするのは大変
  • 社内への理解促進
    • 役員まで話を通してトップダウンで動けるように
    • 会社横断の推進体制を作った
    • チェックシート

社内を動かすアクセシビリティ戦略

  • 出口 裕貴さん(Qiita株式会社)

社内を動かすために取り組んだこと

  • メンバーの巻き込み
    • 他のメンバーが行動に移せるように具体的なアクションを提示した
      • セマンティックなhtmlにしていこう
    • その後WCAG勉強会
    • アクセシビリティハンドブック
  • リソース確保
    • エンジニアとデザイナーが通常業務をしながら進める
    • 薄く広く取り組んでいった
  • 決済者の承認

アクセシビリティでキャリアを築く

  • 平尾 優典(ゆうてん)さん(株式会社ディーゼロ)
  • 桝田 草一(masuP9)さん(株式会社SmartHR)
  • 家本 夏子さん(株式会社エスケイワード)

パネルディスカッション

「ゆめみ×LayerX×サイボウズ3社合同フロントエンドカンファレンス北海道2024後夜祭@東京」に参加してきました

shadcn/uiから考えるコンポーネント設計

shadcn/ui

  • インストール不要でコピペで使うUIコンポーネント
  • v0ではかれるコードで使われてる
  • 大規模より小規模向き
  • RadixUIベース
  • cvaでスタイル指定をする
    • Variant指定
  • formはReactHookFormを使ってる

contenteditableと向き合う

contenteditable

  • 請求書発行のプロダクト
    • どんな金額になるか等さまざまなパターンがある
    • リッチエディタが必要
  • contenteditable
    • input要素などではない要素で入力可能にする
    • キー操作を自前で再実装が必要
    • 日本語入力の挙動
  • ADR
    • 技術選択の背景の記録
    • 他の妥当そうな選択肢を並べる
  • やってみて
    • キー操作の再現がとにかく大変

状態管理ライブラリZustandの導入から運用まで

Zustandの導入

  • 入力フォームの内容を大きいオブジェクトで管理してる
  • 状態管理ライブラリ
  • 使ってみて
    • ネストしたオブジェクトの管理が大変
      • ... がたくさん
      • Zustandにimmerのmiddlewareが入ってる
    • Providerがいらないので入れやすい
    • 型定義を書いていくのが大変

Open UIによるWeb UI標準化へのアプローチ

Open UI

  • 汎用的なUIパターンやコントロールの検討や提案をしている
  • 標準化団体と協力してhtml/cssなどに仕様追加
  • 最近だとPopoverAPIなど

Rechartsで楽にゴリゴリにカスタマイズする!

Rechartsのカスタマイズ

  • チャートをカスタマイズしたい
  • Rechartsはカスタマイズの口は用意してるがsvgしか入れられない
    • foreignObjectを使うとsvgにhmtlを入れられる
    • createPortalでいい感じの位置にレンダリングさせちゃう

TypeScriptとGraphQLを活用した変化に強いプロダクト作り

GraphQL採用のメリット

  • スキーマ駆動の開発
    • FE/BEでスキーマを前提に開発ができる
    • BEはモックで
  • 1リクエストで必要な情報をとれる
    • 変更があってもクエリ変えるだけ
  • スキーマ変更を型で検知できる

Next.jsでクエリパラメータを楽に扱おう nuqsを紹介!

nuqs

  • URLの文字列を単純な連結で組み立てるのは危険
  • stateの同期など大変
  • nuqsでクエリ管理ができる
    • hooksでクエリと同期させられる
    • 型安全にURL文字列にできる

Cloudflare PagesとCloudflare Accessで安全にWebサイトを共有する

  • tottoさん

Webサイトの限定共有

  • 特定の人だけにページを公開したい場面
  • Cloudflare PagesとCloudflare Access
  • 注意点
    • .pages.dev はデフォルトで認証対象外なので注意
    • GitHub連携するとアクセス制限する前にいきなりデプロイしてしまわないように

「Product Manager Meetup」に参加してきました

感想

  • エンジニアのイベントとは空気感が違って新鮮でした
  • 新規プロダクトでの話が多くあったけど、大きいサービスでも同じようにやっていけた方がいいんだろうなと思った

ドメイン知識ゼロでディスカバリーやってみた話

  • 加藤さん(enechain)

オンボーディング機関でやってみたこと

  • ドメイン知識がなくてもPdM経験あればやっていける
  • 電力の卸売マーケット
    • 卸業者 - 小売業者 - 消費者
    • ドメインが難しい
    • プロダクト組織がよく分からない人が多い
  • ドメイン知識の早期習得
    • 自分で体験するのが難しい
  • ステークホルダーと信頼構築を
    • 受託的にならないように
  • 本質的には目標設定と課題定義、仮説検証

事業会社PdMがアパレルブランド事業責任者を経て、フリーランスPdMになった話

キャリアの広げ方のパターン

  • 事業ドメインの変更
    • スキル/知識/専門性
    • PdMのベーシックスキルがあればそれをベースに動ける
  • 一度レイヤーをあげる
    • 全体像が見えるようになってくる
  • フリーランス
    • 予期せぬ移動やアサイ
    • 会社員だといろんな制約が多い

社内で2つ目3つ目のプロダクトを立ち上げる方法

  • 冨田さん(estie)

新製品の立ち上げ

  • 闇雲に立ち向かうと振り回せれて大変
  • リーンスタートアップに沿って
  • ビジネスクライテリアをころころ変えるのはよくない
    • 変えるくらいなら失敗したことにしてまた別で
  • 新規事業はリソースを使う
    • 他のチームとの軋轢
    • 会社の文化やMVV

2024年8月に読んだ本

  • 読みたい本はたくさん増えたが、消化のペースはイマイチ
  • 著者の話を直接聞くとついつい読みたくなって買ってしまう

アジャイルチームによる目標づくりガイドブック

www.shoeisha.co.jp

  • 単なる目標設定というわけではなく、アジャイルチームにおける目標の本
  • OKRを中心に目標設定とその実現に向けたコツを解説してくれている
  • いい感じに脱線しながらアジャイル開発におけるプラクティスが盛り込まれている
  • このシリーズはチームみんなで共通認識として読んでおきたいと思っていたが、この本もそこに仲間入りした

超速! Webページ速度改善ガイド

gihyo.jp

  • ずいぶん昔に買った本をふと読みたくなったのでようやく手にとった
  • ブラウザ上でのパフォーマンスの課題を検証し改善するステップを解説してくれる本
  • ChromeのDevToolsを使ってパフォーマンスやメモリなどを見ていくのが面白くて試してみたくなった

「第12回 Xデザインフォーラム「カルチャー x チーム x デザイン」」に参加してきました

カルチャーとデザインの実践

組織としてのカルチャー

  • 価値観が揃うと意思決定の軸ができる
  • 誇りやエンゲージメントにつながる

マネーフォーワードのカルチャー

  • MVVC
    • CはCulture
  • MVVC作ってから浸透まで5年とか時間をかけた
    • 2015年くらいに作って020年くらいで浸透した感じ
    • もともとの行動指針がトップダウンな感じだったので共感できるものを作った
      • 当時は組織の状況も大変だった
  • 浸透させるのに
    • Positive
    • Emotion
    • Lets make it
  • ボトムアップで半年かけて作った
    • 経営者の想いがのせられなかった
    • そこから半年かけて経営陣ともディスカッション

チームのカルチャーとチームとデザイン

表現を通じた集団的な自己認識

  • 富田誠さん(東海大学教授)
  • 文化のレベル
    • 人工物
      • 誰かが作った
    • 信念や価値観
    • 基本的な前提
      • 無意識

リサーチカルチャーブックを形作るチーム体制

知が生まれてくるチームづくりとは?

「ゆるSRE勉強会 #7 ~1周年記念企画 真夏のSRE怖い話~」に参加してきました

ある日突然DBの性能が1/2になった話

  • hmatsu47さん

2028/1のメルトダウン

  • Aurora使ってた
  • 2018/1のSpectre Meltdownの対応で性能一時的に落ちた

DynamoDBのcapacityを1にしてしまった話

  • ssmtさん

DynamoDBのcapacity

  • オンデマンドキャパシティとプロビジョンドキャパシティがある
    • 前者は負荷に応じてスケールで後者は事前に指定
  • メンテナンス時にどうするか
    • プロビジョンドをオンデマンドに一時的に変更する
    • メンテ後にプロビジョンドに戻したらcapacityが1になった
    • terraformでignore_change指定してたからっぽい?
      • オンデマンドでスケールさせてるとignore_changeしないと元に戻っちゃう

知らないサーバ

新プラットフォームへの移設

  • VMのAnsibleの一覧をリストアップし対応した
  • なのに古い方でサーバが動いてると連絡が
  • Ansibleの一覧にもないし検索しても何も出てこない
  • SSHでは入れた
  • /var/log見てみたらログがたくさん

障害が起きたらどう動く? 今日からできるインシデントレスポンス

  • 曽根壮大さん
  • 藤原俊一郎さん
  • あんどぅさんさん
  • jacopenさん

一番震えた障害

  • いつものハングの対応と思ってサーバ落としたら違うものを止めてしまった
  • 開発のmysql初期化しようとしたらポートフォーワードで本番に流れた
  • とりあえず再起動で起動しないとか設定が初期化されちゃうとか

好きな障害

  • パフォーマンスチューニングで解決する系
  • 見たことある障害は好きじゃない

ポストモーテム

  • できるだけすぐにステークホルダーが揃うタイミングで
  • 翌営業日に書き始めて長くて一週間で
  • 他のチームとシェアできるのがいい

#インシデント発生時の初動をはやくする工夫

  • アラート起きたときのファーストアクションを用意しておく
  • インシデントコマンダーを育成していく
    • 意思決定ができるとか
  • 普段の状況を知っていること
    • そうすると異常が起きた時にあたりをつけやすい

「開発生産性向上の鍵 〜開発者体験・効率・検証改善・リードタイム短縮の実例〜」に参加してきました

感想

  • 普段は生産性に関する取り組みは特別やってないけど、やりたいと思うことやらなくていいやと思うこといろいろあったので参加してよかったです

目標設定と習慣化で今よりも一歩生産性を上げる

目標の設定と達成

  • 生産性を定量的に測っていなかった
    • 現状いいのか悪いのか分からなかった
  • 目標の設定
    • PRのオープンからマージを指標に
      • その中でもオープン/レビュー/approce/マージのステップがある
    • 現状の値を測ってその半分を目標にした
  • 目標への取り組み
    • レビューがたまると進まなくてもっとたまる
    • レビューを優先するルールに
    • 目標を毎日朝会で確認

bugbashを導入して検証工程をカイゼンした取り組み

bugbash

  • 職種関係なくみんなでバグ出しをする
    • sprintの中盤のデイリー後にやる
    • 30〜60分程度
    • 不具合だけでなく提案もOK
  • 全体の2-4割の不具合はbugbashで検出
  • bugbashやってみて
    • 仕様把握に時間かかって操作の時間が減る
    • 出す人が偏る
    • チームを作って対象を絞る
    • モブテスト
    • 不具合がまとめてあがるので対応もしやすい

開発者体験を意識した開発チームの生産性向上の取り組み

開発生産性の可視化

  • DORA Core Model
    • Capabilities
    • Performance
      • Four Keysも含まれてる
    • Outcomes
  • 指標が向上しただけではダメでその先の価値につながらないと意味がない

FourKeys

  • デプロイ頻度
    • 高いほどよい
    • 現状の頻度になっている理由を解消しないと意味がない
    • フィーチャーフラグ使ったりとかの工夫
  • 変更のリードタイム
    • 本番に変更が反映されるまでの時間が短いほどいい
    • 実装やレビューに時間がかかるとか
  • 変更障害率
    • 本番に反映した際の障害率が低いほどいい
    • 予期せず既存処理を壊してしまうとか
  • 平均復旧時間
    • 障害発生から復旧までの時間が短いほどいい
    • デプロイに時間がかかる
    • エラーの特定に時間がかかる
    • エラーの検知までに時間がかかる

「フロントエンド・オブザーバビリティ Meetup」に参加してきました

感想

  • 発表はフロントエンド固有じゃない話も多かったけど、参加者で取り組みが進んでる人の話を聞けたのが学びでした
  • 自分のところでも何ができると嬉しいのか考えてやれることからやってみようと思った

フロントエンドエンジニアとして、オブザーバビリティにコミットすること

  • イイダ ユカコさん

オブサーバビリティ

  • 不具合発生時に何が起きてるかわからない
  • ユーザ体験に問題があるかどうかわからない

ClassiにおけるSentry活用事例

  • lacolacoさん

SentryとObservability

  • エラーモニタリング
    • ブラウザ上でのエラーを収集して可視化してくれる
  • パフォーマンスのトレーシング
  • セッションリプレイ
    • どういう操作をしてエラーにたどり着いたか画面として再現できる
    • DOMの流れを見られる
  • web vitalsの計測

Sentryの活用

  • エラー監視
    • 定期的なモニタリング
      • 週次レポート
      • エラー増減の原因が特定できてるかどうか
  • パフォーマンス分析
    • web vitals見てどこに伸びしろがあるか
    • どのページから手をつけるか
  • セキュリティ強化
    • ContentSecurityPolicy
    • レポートの送り先にSentryを使ってる

observabilityを支える要素技術

  • sadnessOjisanさん

フロントエンドのo11y

  • インフラのモニタリング
    • 計測するやつが収集先に送ってそれを見る
  • ブラウザのモニタリング
    • Lighthouse
    • 人の環境で実行する
      • Real User Monitering
      • ヒートマップ
    • ブラウザのAPIでパフォーマンスとれるのでそれを収集
  • OpenTelemetry
    • トレーシングとかメトリクスをとるもの
    • ライブラリを入れるだけで動かせる
      • よく使われるライブラリの特定の関数が呼ばれたときに処理をはさむ
      • それだけだと足りないので手動で追加する方がいい
        • 大変だだし計測のコードで汚れていく

こつこつ育てる SLO

  • ニッシーさん

SLOとオブサーバビリティ

  • SLOがあることで今やるべきことを判断できる
    • 開発するべきか改善するべきか
  • SLOにオブサーバビリティのデータを使うことでデバッグ容易な値を定められる
    • SLOを改善することがユーザへの価値につながる
  • SLOの継続見直し
    • 月次でチェックしてる

「Muddy Web #9 - 泥臭いフロントエンドの現場」に参加してきました

FastlyとfalcoでNode.jsレスなWebサーバーの構築: IPTV版ABEMAアプリのインフラ刷新

IPTV版ABEMA

  • ABEMAをテレビで見ることができる
    • Linuxを搭載していてWebベースのもの
    • Androidを搭載してAndroid技術で作るもの
  • IPTV
    • IP技術でビデオコンテンツをテレビへ提供する技術

インフラ構成

  • もともとはhtmlをNodeサーバからcss/jsはCloudStorage
    • NodeやCloudStorageが露出している
    • gzip化されてない
    • Nodeサーバの物理的な位置
  • CDNを導入
    • htmlは事前に静的ビルドできたのでNodeサーバなくせた
    • 動的部分はCDNのエッジでファイル出し分け
    • CloudStorageはCDNからしかアクセスできないように制御
    • CDNgzip/br圧縮できた

Fastlyとfalco

  • Fastly
    • Web版で使ってた
    • VCLでエッジにロジックおける
    • ロジックのテストどうするか
      • ローカルではNode環境で
  • falco
    • Fastly VCLの開発補助ツール
    • Linter/Formatter/テストなどなど
    • simulatorでローカルで動かすことも
      • バックエンド差し替えてCloudStorageには向かないようにできる
    • vscode拡張にも組み込まれてる

コードメトリクス計測による課題可視化と品質確保

  • Masatoshi Morita(@texdeath)さん

コードメトリクス

  • チームの具体的な品質指標がほしかった
    • FEチーム/BEチーム行き来しながら開発することも
    • ルールを固めてスピードを落とすのは避けたかった
  • 技術選定
    • octocov
      • GitHub Actionsに特化
      • 特定の用途しか使えなさそう
    • SonarCube
      • ダッシュボードがあって分析できそう
      • カスタマイズの敷居が高い
        • 環境の構築とか
    • ESLint
      • 導入が手軽で拡張性が高かった
  • ESLintのルール
    • 循環的複雑度を重点的にチェック
    • jsonにレポートを出力して修正すべき箇所をまとめる

Amebaチョイス立ち上げの裏側 ~ 依存システムとの闘い ~

  • Daichi Igarashiさん

Amebaチョイス

  • 商品を比較するメディア
  • 商品情報のCMSと記事情報のCMSがある
    • 記事用のCMSはhtmlが返ってくる
    • Reactで扱いづらい
  • それぞれアクセスするサーバがある
    • React/ExpressとNext

マイグレーションコード自作して File-Based Routing に自動移行!! ~250 ページの歴史的経緯を添えて~

  • Rei Katoさん

TanStack Routerへの移行

  • 管理画面の話
  • SPAでSSRしていない
    • GCSからhtml/css/js返してる
  • 250ページある
  • ロール管理が複雑
  • ReactRouterのv5使ってた
    • 型がつかないのが大変
  • TanStack Routerに移行
    • ファイルベースのルーティングに
    • 既存のファイルを読み込んでディレクトリを生成していく
    • jscodeshiftでAST見て頑張った
  • 状態管理ライブラリの混在
    • Unstated/Recoil/TanStack Query
    • Unstatedを使ってるところはコンポーネントの構造が違うから地道に分岐

「フロントエンドカンファレンス北海道2024」に参加してきました

感想

  • フロントエンドのカンファレンスは一昔前だとJSフレームワークが中心だった印象なので、時代の流れが変わったなと思った
  • CSS周りの話が面白くてもっと深堀りしたくなった
  • 初開催の中でもハイブリットでオフラインは200名程度のイベントを用意してもらえて感謝です
    • もともと1トラック予定のところ、たくさんのプロポーザルが来てなんとか2トラック調整をつけたとか苦労話も聞きました
  • 次回開催も期待してます

ダークテーマとアクセシビリティの融合したカラートークンの設計

カラートークンの設計

  • global tokenとalias tokenを定義して使ってた
  • カラーパレット
    • ブランドカラーの組み合わせがコントラスト比満たしてなかった
      • プライマリー/セカンダリーで定義した色のほとんどが満たしてなかった
    • グレースケールは色差が同じくらいになるよう輝度を変えていくようにした
      • そこに青緑がかった色になるよう調整
    • 有彩色もコントラスト比を確認しながら作成
  • カラートーク
    • base/container/text/borderに分類
    • 特定のコンポーネントでしか使わない色もそれ用に定義
      • markdownの編集の中でしか使わない色とか

AI時代のこれから、もっと重要になるフロントエンドのお話

  • 米井 優顕さん

生成AIとフロントエンド

  • チャットで生成した成果物をどう埋め込むか
    • コピペする?
    • Copilotだとそのままエディタに反映できる
  • メシウスの製品だとエクセルライクなサービスにチャット機能があって生成結果を埋め込める
    • Next.jsで作ってAzure叩いてる

CSSレイアウト再入門:完全に理解してCSSを記述するために

整形コンテキスト

  • CSSボックスモデル
    • ブロックレベルのボックス
      • ブロック整形コンテキスト
    • インラインレベルのボックス
      • インライン整形コンテキスト
  • ブロック整形コンテキスト
    • 参加されるボックスはすべてブロックレベルボックス
    • 段落が増えていく
    • ボックス間はmarginの相殺が起きる
    • 何もしなければ横幅いっぱい
  • インライン整形コンテキスト
    • 参加するボックスはインラインレベルボックス
    • 行方向に増えていく
  • ボックス種別は外側と内側がある
    • ブロックやインラインは外側
    • flexとかは内側
  • フレックスボックスレイアウト
    • フレックスボックスレイアウト
  • グリッドレイアウト
    • グリッド整形コンテキスト
  • 独自の整形コンテキスト
    • float
    • position

Webサイトをキュッと引き締めるモーションデザイン

Webサイトにおけるモーション

  • モーションのマイナス面
    • 動くと読みづらい
    • 気を取られてしまう
    • 動くのが苦手な人も
  • 大事なこと
    • 読み手にとって大事な演出であること
    • ユーザのメンタルモデルに合うこと
  • モーションの要素
    • 長さ
    • イージング
    • ディレイ
  • モーションの目的にあわせたサイズの使い分け
    • クイックに動かすもの
      • ホバーとか
    • 中くらい
      • ドロワーアニメーション
    • 大きいモーション
      • 画面遷移
  • 体感の重心
    • イージングをかけて変化の速度を変える
    • 1から100に変化させる必要もない
      • 75から100とか

デザインシステムとコンポーネント指向によるフロントエンド開発プロセスの革新

コンポーネント指向による開発

  • jQueryしか経験ないような人が多いチーム
    • グローバルでいろいろさわれちゃうのが問題
    • 何をどう共通化するか難しい
    • コンポーネント指向で何とかする
  • コンポーネント指向知らない人に
    • AtomicDesignをガイドラインとして進めていった
    • どれがどの分類か定義は難しいが方向性をイメージするのにはいい
  • デザインシステム
    • デザイナーとエンジニアの共通言語になるように
    • それぞれ勘所が違うので

10年ものの jQuery フロントエンドを良くしていくための道筋

uQuery

  • 昔のブラウザ互換性問題
    • prototype.jsはネイティブのオブジェクトにいろいろ生やしてた
    • jQueryはグローバルな$にいろいろ詰め込んでるのが新しかった
  • jQueryで抱えていた問題
  • 改善
    • 命名を工夫する
      • cspellでスペルミス計測
    • Lintrでしばる
      • ESLint入れる
      • どんなglobal変数を使ってるかコメントで各とignoreされる
    • bundlerを入れる

ESLint Plugin により事業, 技術ドメインに沿った制約と誓約を敷衍させるアプローチのすゝめ

制約と誓約

  • 開発におけるルールを守ることでアプリケーションの質を高める
  • アプリケーション開発/運用と普遍的/固有の2x2の4パターン
    • 今回は開発の固有部分がスコープ
  • 日経電子版では
    • HTTP Request Header Fieldから取得の制約
      • 素早いページ遷移のため
      • スパイク時の負荷対策
      • CDNでのShared Cache Firstな戦略
        • 90%ヒットしてる
      • CDNcookieを元にユーザ判別しサーバへheader付与して渡す
        • Varyの値もキャッシュの計算に使うことでユーザ属性の差もひろう
        • これをセットし忘れるとキャッシュのルールが壊れてしまう
    • CSS in JSの制約
      • CSS in JSの処理をwebpackでやっていてbabelに依存してる
      • CSS in JSの処理をするファイルを絞ることでその処理を実行する対象を最小限に
        • ファイル名に命名ルールを設けることで実現
  • 制約を守るために
    • 人の手だけだと完全に実現するのは難しい
    • 機械でできることは機械的
    • Custom Linter Ruleで
  • Custom Linter Ruleの開発
    • OSSでなければ自分で作るしかない
    • ASTを見て特定の場合にwarn/error
    • ASTを見ると言っても参考になるものも多いしそんなに難しいものではない
    • アプリケーションと同一リポジトリに置くのもいい
      • 背景とかわかるし

Component-Driven Design & Development

Component-Driven Design

  • コンポーネント
    • FIRST
    • 焦点を絞る/独立/再利用/小さい/テスト可能
  • Component-Driven Development
  • Component-Driven Design
    • デザインもコンポーネントドリブンがいいしそうなりつつある
    • AtomicDesighnもデザイナーも巻き込んで浸透してればうまくいくのでは
    • デザインツールも進化してきてる

Design Token

  • プラットフォームに依存しない形で共有できるもの
  • 色とかタイポグラフィとか余白とか
  • GlobalToken/SemanticToken
    • Globalは直接的な定義
    • Semanticは意味をもたせた定義
    • デザイン/開発で使うのはSemanticToken
  • デザインと開発の橋渡し
  • JSONのフォーマットがW3Cで定義されている
    • Design Token Format Module
    • これをいい感じにCSSなどに変換して使う
      • style dictionary
  • Headless Componentと相性がいい
    • デザイントークンをはめるとstyleがつく

Figma

Storybook

  • Storybookでテストも
    • Chromaticと組み合わせてVRT
    • Story単位でのテスト
    • PlaywrightでStoryを動かすことも

The Future of Frontend i18n : Intl.MessageFormat

  • Sajikixさん

Intl.MessageFormat

  • Intl
  • Intl.MessageFormat
    • 新しく追加されようとしている
    • 日時など各要素の書式化は充実してきてる
    • アプリ全体の国際化を進めようという話
    • ECMAScriptUnicodeと連携して進めている
      • 文言管理とか
  • ICU MessageFormat
    • プレースホルダーを設置してそこに言語ごとの値を入れる
      • よくある機能と同じ感じ
    • 細かい書式指定や条件分岐も書ける
    • 20年くらい前からある
  • ECMAScriptとMessageFormat v2
    • v1は歴史があって問題を抱えていた
    • unicodeECMAが協力してv2
      • unicode:MessageFormatに課題がある
      • ECMA:IntlでMessageFormat管理し実行したい
  • MessageFormat v2のち買い方
    • 2種類のメッセージ
      • simple message
      • complex message
        • 全体を管理して {{}} で値を組み立てる
  • simple message
  • {} の中に $username みたいな形で埋め込む
  • 関数を埋めることもできる
    • デフォルトでも用意されてる
    • 数値のフォーマットとか単数複数のためのものとか
  • {#button}Submit{/button} みたいにマークアップすることも
  • complex message
    • message内だけで使える変数の宣言ができる
    • match でswitchみたいなこともできる
  • 実際はIntl.MessageFormatを通してv2を使うことになる
    • newする時にいろいろ指定する
    • formatする時に変数を渡す

ブラウザはどのようにしてテキストを描画しているのか?――Chromiumにみるテキスト描画の深淵

  • canalunさん

テキスト描画

  • text shaping
    • フォントデータのglyphをどこに配置するか
    • フォントが持つcmapでglyphを決定
    • ligature
      • 隣に来る文字に応じて字体を変える
      • fが2個あるとつながるとか
    • 隣の文字によって距離を変える
  • テキストの描画
    • chromiumはSkiaを使ってる
    • 下線/上線/テキスト/打ち消し線
    • 縦書きなど回転させる場合の影問題
      • ベースを描画してから後から影をつければいける
      • 直してるが大変

「DX DESIGN DIALOGUE #02」に参加してきました

感想

  • その場限りの話も多くあまりメモとってませんが、デザイナーに閉じずに通じる経験談を聞けたのがよかったです

開発について、過去最大の失敗

  • 副業の人に依頼したときのコミットメントの違い
  • エンジニア外部に依頼してフレームワークが乱立
  • リファクタリングを待ってたらなかなか終わらなくて何もできなかった
  • フロントエンドの干渉を手放した
    • デザイナーから放れたものがエンジニアの判断によることになってしまった
    • アクセシビリティ配慮されないとか
    • ユーザ体験の最後の手触りを作るのはエンジニア

組織づくりについて、過去最大の失敗

  • 価値観をあわせたうえでのコミュニケーション
    • それがないとハレーションが起きる
  • デザイナーもKPIに責任を
    • 手段なしに伝えたらモチベーション低下に
  • 個人の価値観と会社の価値観のすり合わせ
  • デザイナーは色を塗るだけの仕事じゃない
    • 情報設計をしっかりと
    • その結果UIのスキルがとぼしく
  • 縦軸横軸のスキル
    • 職能としてのデザインのスキル
    • ドメインのスキル
    • 前者だけだと社内で頭打ちしてくる
    • 後者だけだと外で通用しない

最近あった、失敗から得られた学び

  • オーナーシップ不在を放置しない
  • チームレジリエンス
  • まずは型を知るところから入ってもいい
    • コミュニケーションのフィーマット
  • リモートワークで誰が何をやってるかわからない
    • Slackでの発信でお互いわかるように

「アクセシビリティやるぞ!LT祭り #6」に参加してきました

クラウドサイン 視認性改善PJTの裏側

視認性の改善

  • 文字が小さいとか薄いとフィードバックを受けていた
    • 重要視されてなかった
    • 解像度の高いマシンで作業していた
  • コントラスト比の改善を優先
    • 4.5:1以上
  • 多くの画面で使ってるグレーの文字が基準を満たしていなかった
    • 文字色のルールが定まっていなかった
    • ブランドカラーを基準にベースとなるグレーを作って文字色の定義も作った
  • デザインシステムに定義

アクセシビリティオーバーレイはなぜ解決策にならないのか?

アクセシビリティオーバーレイ

  • アクセシビリティオーバーレイ
  • 技術的な限界
    • 代替テキスト
    • ラベルやエラー管理
    • キーボードフォーカス
    • pdf/svg/canvasは修正できない
    • パフォーマンス落ちる
  • 法的なリスク
    • WCAGに準拠できると言い切れない
    • 使っていたのに訴えられた
  • プライバシー
    • 支援技術を使ってることを検知
    • 勝手にcookieセットされたり
  • UXの低下
    • 逆に使いにくくなる
  • https://overlayfactsheet.com/ja/

ジャンプTOON Web におけるアクセシビリティの取り組み

アクセシビリティの浸透

開発の進め方

  • 開発速度やスケジュールへの影響が懸念
    • アクセシビリティ開発ガイドを作った
    • チームで決めたルールのまとめ
    • lintで縛れるところはそっちで
  • PR作成前にやってほしいことのまとめ作った
  • lighthouseで計測して懸念箇所洗い出し

アクセシビリティの取り組みをまとめるデータベースを作ってみた話

アクセシビリティの取り組みのまとめ

  • 背景
    • 徐々に浸透してるが散発的だった
    • 他部署の取り組みを知るのが大変
  • Notion上に取り組みをストックするようにした
  • 社内の取り組みがひと目で分かるようになった
  • 取り組んでるカテゴリーの偏りが見えて次のアクションにつながった

「JaSST'24 Niigata」に参加してきました

感想

いま求められるソフトウェアのアクセシビリティ

アクセシビリティとは

  • 多様なユーザや状況への対応のこと
    • 障害者や高齢者のためだけというわけではない
  • アクセシビリティに取り組むことで多様なユーザの多様なニーズに応えられる
  • さまざまな支援技術
    • メガネ/補聴器
    • スクリーンリーダー/文字起こしアプリ
    • キーボード操作スティック/視線入力/音声入力
    • 機械翻訳

なぜアクセシビリティに取り組むか

  • 取り組む価値
    • 社会的な価値
    • 法的な価値
    • 経済的な価値
  • 障害の社会モデル
    • 個人に問題があると考える視点(医学モデル)
    • 社会が不便なせいで障害者になっていると考える視点(社会モデル)
      • 社会が便利になれば障害者はいなくなる

アクセシビリティの取り組み内容

  • ソフトウェアの利用
    • 出力装置
      • 見えない/聞こえない/色がわからない
    • 入力装置
      • 装置を正確に動かしたり速く動かせない
      • 出力装置からのフィードバックがわからない
    • ユーザによる情報の認識
      • 言葉がわからない
      • 何が起きてるのかわからない
  • WCAG
    • 4つの原則
      • 知覚可能
      • 操作可能
      • 理解可能
      • 堅牢
    • 適合レベル
      • A/AA/AAAの3段階
      • Aが少ないものは満たしてないと致命的なものが多い
      • AAAは実現が難しいものもある
  • WCAGの最新は2.2(2023/10)
    • JISは2.0と互換性があるがそのうち2.2にも対応される

横断的組織が取り組むマネーフォワード クラウドアクセシビリティ向上

マネーフォーワードクラウド

  • 30以上のプロダクト
  • 3~5名の小さいチーム
  • UIや振る舞いのばらつき
  • 技術スタックもバラバラ(rails, react, vue)
  • 横串の知見共有が進んでなかった

フロントエンド推進グループ

アクセシビリティガイドラインの整備

  • MFC Accessibility Guidelinesを作った
  • WCAG2.2のシングルAに対応
  • 整備して模索してる段階

アクセシビリティ委員会

共通UIライブラリ

  • MFUI(Money Forward UI)
  • デザイン標準の時点でアクセシビリティを考慮
  • Storybookで管理
  • ChromaticでVRT

Webアプリケーション開発におけるアクセシビリティテストの実践事例

  • 村岡 里紗さん(freee)

なぜアクセシビリティに取り組むか

  • 全ての人に使ってもらいたいから
  • 会社のvisionにもつながってる
  • テストの際に当たり前にやることの1つ
  • テストをするのはQAエンジニア
    • デザイナーやエンジニアも当たり前に意識してる

QAエンジニアのアクセシビリティとの関わり

  • デザインや設計の段階でアクセシビリティの視点でチェックしてる
    • シフトレフトで動くことが多い
  • 実装後の試験
    • スクリーンリーダー動かしてチェックしたり
    • OSのカラーフィルターで色合い変えて確認したり
    • axe devtoolsで確認したり
  • 困ること
    • 時間がない中で作業するので全画面全部やってられない
      • 事前に見積もっておいて時間と人を確保する
      • デザインシステムの部品を使ってれば致命的な問題は起きないはず
    • 実装が終わってからじゃないとテストできない
    • Windows使ってる人少ない問題
    • 検知箇所が多すぎる問題
      • 重篤度に応じて優先順位を

「Playwright本出版記念!Node学園 43時限目」に参加してきました

リーダブルなE2Eテストコードのための3つのC

本の紹介

  • テストをなぜ書くのかみたいな内容
  • CodeceptJSでサンプルを作ってる
    • Playwrightなどをラップして単一のAPIを提供するライブラリ
    • I ckick xxxみたいな書き方

E2Eテストの認知負荷

  • 認知負荷
    • コードを読む妨げになること
  • E2Eテストでの認知負荷
    • 今どのページにいるのか
    • どのユーザか
    • どんな操作をしてるのか
    • 何も考えずに作ると手続き的になりがち
    • コメントに頼らずに何をしようとしてるかわかるといい
  • 3つのC
    • Context
      • 状況を表現する
        • どこにいる
        • だれなのか
    • Capability
      • 何が出来るべきか
        • フォームの入力内容の整備などまとめてやっておく
    • Component
      • ページ内のかたまりをコンポーネント化する
        • 目当ての要素を探索しやすく
      • どんな操作をしようとしてるのか

[入門]Webフロントエンド E2E テスト執筆の裏側

  • 渋川よしきさん

執筆の裏側

  • きっかけ
    • 執筆メンバーの一人がCypressの技術ブログ書いたりしてた
    • SoftwareDesignで連載
    • 書籍執筆スタート
    • Cypressで進めてたがPlaywrightは流行ってきたのでテーマを移した
  • なぜCypressやPlaywrightにはまったか
    • ユニットテストだけで全てをカバーするのは難しい
    • E2Eが便利
      • どこで落ちたかとかどんな操作がされたかなど見れる
      • スナップショットとってくれたり
      • どんな通信がされたかも見られる

書籍の紹介

  • テストの価値を説明したような章もある
    • 社内で誰かを説得するような時に使える内容
  • 今のE2Eで足りてないパーツ
    • DBの初期化
      • E2Eでは毎回初期化しないといけない
      • Playwrightではセットアップの手段がHTTPリクエストくらいしかない

最新のPlaywright

  • 毎月バージョンが上がってる
  • 1.43.0
    • クッキー削除API
    • タグ情報をテストの中で取得できるようになった
    • iframeの中のロケーターが取得できるようになった
  • 1.44.0
    • a11y関連のマッチャーが追加
      • アクセシブルネームのチェックとか
    • fetchのmultipartでFormDataを渡せるようになった
    • --last-faild で前回失敗したテストだけ再実行できる
  • 1.45.0
    • ClockAPIで時間を固定できるようになった

パネルトーク

  • テストはどこまで複雑に書くか
    • 過去事例では一筆書きで一通り機能をさわった
    • ユニットテストと使い分けするといい
      • 細かいバリデーションのパターンはそっちで
    • 全画面作り込んだことあった
      • 実行時間がとても長い
      • しかもテスト壊れやすくてメンテ大変
      • 一度破綻すると次やろうと思えなくなる
    • 最初は軽量に始めて育てていくといいかも
    • 一筆書きで最初書いても分割していくといいかも
    • インフラの状況や生成AIの活用で課題感は解決される未来も
  • VRTとE2Eの使い分け
    • E2Eやってるなかでキャプチャとっていく?
      • でもキャプチャ取る場面が違うのでVRT用でまたテスト書く?
    • スナップショットテストで事足りるならそれでいいのでは
      • CSSのテキストが変わってなければUIも壊れてないはず

E2Eテストがない?!pino型テストピラミッドの現状

  • dk-tanioさん

テストピラミッド

  • E2Eがないパターン
    • pinoみたいな形
  • E2Eなくてもある程度担保できる状況はある
    • 技術が進化してきているので負担かけすぎずにテストを作れるようにもなってきてる

strip types と storage について

Nodeの新しい機能

  • strip types
    • 22.6.0から
    • ソースコードから型を引き抜く機能
    • TSをJSに変換して実行できる
    • 型を取り除くだけなのでそれ以外のTSの機能はダメ
    • 型チェックもしてくれない
      • DenoとかBunも一応同じ?
    • tsconfigサポートされてない
      • import時の拡張子周り動かないとか
  • storage
    • 22.4.0から
    • local storage/session storage/sqlite
    • ブラウザで書くコードと同じコードで動く
    • データはsqliteに置かれる
    • 同期で保存されるのでイマイチ
      • ブロッキングAPI増えてほしくない
      • asyncならまだわかる
      • AsyncStorageというのもすでにある(ファイル保存はできないけど)
    • sessionStorageはただのグローバル変数になる
    • なんかあった時のエスケープハッチ的に使うくらいになりそう
  • まだexperimentalで使ってみて評価するフェーズ

Playwright + reg-suitを使ってみた

  • FUJITO SHIONさん

VRT

  • reg-suit
    • VRTのためのライブラリ
  • テストの流れ

「Japan Datadog User Group Meetup#5」に参加してきました

Datadog APM による性能改善から始める技術的負債解消

Datadogで性能改善

  • レガシーソフトウェアの改善
    • 計測してから改善すること
    • 指標が必要
      • Datadogで
  • レイテンシを計測して改善する
  • 改善対象
    • POSTされるエンドポイント
  • Dashboard整備
    • グラフをいい感じに
    • APMと連携
      • アプリの時間計測して送信
    • 不要なクエリを見つけて削減
    • クエリ回数が無駄に多いの削減

DMMの動画SREにおけるDatadogの活用について

  • Kosuke Suganoさん

動画サービスでのDatadog活用

  • 社内でGoogleCloudやk8sを使うのが初めてだった
    • 初挑戦の技術が多くメトリクスを1つずつ集めてナレッジをためていった
  • Google Cloud Integration
    • メトリクス取得のタイムラブ
    • Cloud Monitoring自体が1分ペース
    • Redis周りで使いづらいところが
      • CPUを使用率で見れなかった
  • FEチームへの布教
    • CoreWebVitalsの通知をリリース後に必ず確認するように
  • Notebookの活用
    • テンプレートを活用して誰でもレポートを書けるように
    • メトリクスのグラフを画像で残せる

Trace Queriesの活用でfreee会計のDB負荷削減のきっかけとした話

  • 大木竜勝さん

DB負荷改善

  • 長年運用していて意図せずn+1問題が起きていた
    • どのAPIで頻発しているかわからなかった
    • DB負荷につながっていた
    • 他のクラスタからn+1で飛んでくると大きすぎてTraceを見る画面を開くことすらできない
  • DatadogのTrace Queries
    • 2024/2頃にリリース
    • span間の依存を含めて検索できる機能
      • A,Bという親子関係のspanでAとB両方でエラーといった検索ができるようになった
      • Bに10sかかってるAのSpanといった集計もできるようになった

Kubernetes で Datadog を飼うならオートディスカバリー機能を使わないと損

オートディスカバリー

  • 自動でサーバを監視する機能
    • 自分で登録しなくても条件に当てはまるものを見てくれる
  • yamlにannotationを書くことで設定できる

DatadogでPHP/Laravelアプリケーションを監視する

Laravelの監視

  • DatadogでLaravelを監視
    • Datadog Agent入れる
    • PHP拡張を入れる
    • 環境変数を追加
    • Datadog APMを入れる

SLO導入とDatadog SLO Dashboard

SLOの導入

  • ユーザに与える影響が見えない状況
    • 品質改善が進まない
    • アラートが形骸化
  • SLOを策定
    • ダッシュボードにも反映
    • SLOを関係者が来にするようになった
  • エラーバジェットが消費されるとエンジニアがすぐに反応するようになった

AWS Summit JapanのDatadogブースに立ち寄って得られたAPM活用

  • anecho108さん

APMの活用

  • Datadog APMの活用
    • n+1を簡単に見つけられる
      • クエリが用意されてる
    • ドメイン単位でのgroup byができる
      • マルチテナントだと便利
    • Dashboardへエクスポートできる
    • URL単位でのgroup by
    • resource_nameでのgroup by
  • ユーザに影響のある部分を見つけてそこに対してSLOを設定するといい