「GENBA #2 〜Front-End Opsの現場〜」に参加してきました

名刺アプリ Eight における Frontend Ops

  • 鳥山 らいかさん

Frontend Ops

EightでのFrontend Ops

  • ビルド
    • Viteに寄せてる
    • Chunk分割
    • CSS Modules(ゼロランタイムがいい)
    • BabelからSWCへ
    • 設定のカスタマイズはあまりしない
      • ツールの移行とかで面倒にならないように
  • CI/CD
    • ローカル
      • Lint/format
    • CI
      • テストビルド型チェック
        • 差分に関係ないjobは実行しないで時間やコスト削減
    • CD
      • ビルド結果をデプロイくらい
  • キャッシュ
    • CDN
      • CloudFront
    • ブラウザ
      • 静的アセットにハッシュ付けて管理
      • ReduxやApolloでキャッシュも
    • CI/CD
      • npmpackageキャッシュしたり
  • 監視
    • Datadog使ってる
      • Real User Monitoring
    • 関係ないエラーをフィルタしたり
    • RUMでCWVを計測
  • アップデート
    • 週次Renovate
    • 重大なもの以外は3ヶ月に1回くらい

心がけ

  • シンプルに保つ
    • メンテ大変にならないように
  • マイナスをゼロにする開発に力を入れる
  • アプリコードに手を入れないように

DangerJSを導入してPRレビューを効率化しよう

Danger JS

  • https://danger.systems/js/
  • CIプロセスでコードレビューしてくれる
  • PR作成をフックにコードをチェックしてコメント投稿までできる
    • 投稿はmdで書ける
    • 行数チェック
    • 文字列チェック
      • console.log残ってないかとか

導入時

  • プッシュしてPR作らないと設定のチェックができず面倒
    • dangerのテストを書くと事前にチェックできる

導入して

  • 機械的なチェックでレビューにかける工数が減った
  • いろいろチェックしたいことが出てきた
    • commitした画像容量チェック
    • typoチェック
    • PRのsuggestの活用も

スタートアップのフロントエンド事情

  • 蝦名 潤さん

スタートアップでの開発

  • 1人でMVPを素早く作る必要があった
    • BEはrailsでFEはReact
  • モノリスなSPAにした
    • erbの中でReactを読み込むところがエントリーポイント
      • そこから先はReactの世界
    • ルーティングがないってこと？
  • デプロイがシンプルでCI/CDが楽
    • エントリーポイント以外は疎結合
  • Rails環境に依存してしまったのが懸念
    • Nodeのバージョンあがるのが遅い？
  • 今後インフラを分離
    • ビルドしたものをCDNにデプロイ

いつか来たる大改修のために備えておくべきn個のこと

  • 西浦太基さん

大改修の事例

  • Rails+jQueryをReact+Nextにした
  • 段階的にリプレース
  • その時の知見

泥臭かったこと

  • 仕様がドキュメントにのこってない
    • ソースをみて調査するしかない
  • ユニットテストはあったがE2Eはなかった
    • 手動でテストした
  • レビュー体制が整ってなかった

備えておくべきこと

  • 機能の仕様は背景込みで残す
    • エッジケースなど残してるといい
  • テスト自動化の仕組みを導入
    • UTとVRTがあってもE2Eは大事
  • レビューの観点を明文化しておく
    • 同期的なやりとりが増えてしまわないように

コミュニケーションでフロントエンドの「広さ」に立ち向かう

  • 山下翔太郎さん

FEの知識の広さ

  • FEの知識が広く
  • タイミーFEエンジニア
    • featureチームに数人FEエンジニアが入る感じ
    • 横断組織ののchapterもあるがメインはfeature
  • 課題
    • スコープが広く横断課題が積み重なる
    • 属人化しやすい
  • 広さに立ち向かう体制が整っていない
  • 改善の取り組み
    • 積まれた横断課題を整理し理想や方針の認識を合わせる
    • 課題起票だけで終わらないように改善デーを作ってで対応
  • メンバー間の思考や課題感の違いを理解するコミュニケーションが大事
    • それをきっかけに改善を進めていく
  • 今後
    • いろいろやってるから線でなく点になってることが多い
    • 旗を立て直す

「Developers Summit 2024（2日目）」に参加してきました

勉強会メモ

ビジネスと開発が真のパートナーになる、事業に貢献するエンジニアの姿とは

  • 榊 淳さん[一休]CEO
  • 伊藤 直也さん[一休]CTO
  • 押久保 剛さん[翔泳社]モデレーター

CEOとCTOの壁

  • 伊藤さんがジョインして8年くらい
    • 当初は壁があった
    • レガシーなシステムで技術的負債がたくさんあった
    • システムを整備したいエンジニアとそんなの関係なく進めたいビジネス
  • 変化のきっかけ
    • システムのことやってるだけでビジネスに貢献してない
    • お客さんのところにいって声をきいた
    • CTOが変わると壁の位置がだんだん下にずれていく
      • 数年かけて現場レベルまで落ちた
  • エンジニアの変化
    • コロナ禍のgo to travel
    • 仕様が決まってないけどやることが決まっていて大変だった
    • エンジニア主導でビジネスを動かせた
  • 越境するまで
    • 得意なことだけやっていたかった
      • その世界の中だけでも大変なこともあるしうまくやれれば称賛される
      • 経営者としてはそれじゃダメだった
  • エンジニアが陥りがちなこと
    • 責任を放棄しがち
      • その納期じゃできないとか企画が考えたことがよくなかったとか

GitHubアーキテクトが語るGitHub Copilotが生み出すAIネイティブ開発の実践と次世代エンジニアに求められる新たなスキルとは

  • 服部 佑樹さん[GitHub Japan]
  • 新田 章太さん[ギブリー]

AIネイティブ開発

  • エンジニアの領域で生成AIの利用が広がっている
    • 実際に生産性が向上しているというデータもある

GitHub Copilot

  • GitHub Copilot Chat
    • IDE内でChatGPTらしい体験
  • Copilot for Pull Request
    • PR内でAIによるタグ付け
    • 必要なテストの提案
  • ハレーションの存在
    • あたかもな振る舞いをするのがリスク
  • AIを使いこなしたエンジニアリングが生産性を高める鍵

GitHub Copilotを使ったプラクティス

  • 開発時
    • コードを指定してチャットで聞けるようになっている
    • 対象のスコープをワークスペースとか指定したところとかできる
  • PR
    • PR作成時に見てもらいたいポイントを勝手にコメントしてくれる
    • PRの差分を見てる時に内容についてチャットで質問できる
  • AIを使いこなすコツ
    • ツールの違いを知る
      • 補完/チャットで違う
    • Copilotの特徴を知る
      • 数百ミリ秒でライセンスが問題ないコードを取得できる
    • プロンプトのコツ
      • 文脈/意図/明瞭さ/具体性
  • Copilotデザインパターン

これからのエンジニアに求められるスキル

  • 良いコードを書かせるにはそのためのスキルが必要

ログと徹底的に向き合うデータドリブンなサービス運用

  • 田中 聡さん[うるる]

ログでデータドリブン開発

  • データドリブン開発
    • 顧客の行動や市場データをもとに開発を行う

GitHub Copilotは開発者の生産性をどれだけ上げるのか？ ZOZOでの全社導入とその効果

Copilot導入背景

  • 開発生産性の可視化向上
    • まず量を最大化
  • リソース効率とフロー効率
    • フロー効率を計測可能な状態へ

導入の懸念

  • セキュリティ
    • 脆弱性の混入
      • Copilotで脆弱性防止システムがある
      • 社内でコードレビューをちゃんとやる
    • 社外への流出
      • ビジネスプランなら学習に使用されない
  • ライセンス侵害
    • GitHubが補償してくれる(契約による)
  • 費用対効果
    • 利用料とコスト削減量
      • 試験導入で検証してから入れた

導入して

  • 9割が生産的になったと回答
  • 既存コードを読む助けになる
  • XCodeが公式で未対応なので少しイマイチ
  • 1日あたり1時間以上節約できたという人も
    • 機械学習 x Pythonの組み合わせが多い
      • ここの部門は使い方の勉強会をやっていた
    • Javaも多い
    • うまく使うための学習をすると効率化される

SIerな会社の中でXR(VR・メタバース）を用いた新規事業開発に挑戦して見えてきた景色

XRを使った新規事業

  • XR: AR/MR/VRの総称
  • 事例
    • RE:COLLAB Rooms
    • TeleAttend
    • XRCampus
    • BURALIT

XRアプリの開発

  • 3Dモデルなどの部分を除けば普通のWebアプリ
  • デザイン
    • 事例が少なくノウハウがスクアに
    • 触ってみるまで良し悪し判断できない
    • プロト作って検証を回す必要がある
  • システム構成
    • 複数プレイヤーでのマルチプレイは特殊
      • 頻繁なデータのやりとり
      • 数十人とか動悸させるには専用サーバが必要でコストがかかる
  • アーキテクチャー
    • unityの世界だとあまり確立したパターンがない
  • テスト
    • 普段とあまり変わらない
    • モンキーテストで不具合を出し切る
  • 体制
    • XRエンジニアを集めるのは大変

探索型のプロダクト開発を始めよう～正しいものを正しくつくる2.0～

プロダクト開発

  • ソフトウェアとプロダクト
    • 前者は仕様があってそれを作る
    • 後者は仮説検証して価値のあるものを作る
  • スクラム開発
    • 開発チームとPO分断しがち
    • 間違ったものを正しく作るになってしまう
  • 何を持って正しい？
    • プロダクトを届けるのは大事だが届けるだけでもダメ
    • アウトカムが発生しているかどうか
  • アウトカムとは収益のこと？
    • 収益は活動を続けるために必要な動力源なので目的そのものにはならない
    • 収益は結果でしかない
      • 後ろだけ見ててもダメ
  • 前をみよう
    • 成果を捉え直す

プロダクト開発における成果とは

  • 成果
    • ユーザの目的を果たせているか
    • チームが健全であるか
    • プロダクトが健全であるか
  • チームとプロダクトの健全性を保たないと持続しない
  • 3者は一定でなく常に変化する
    • 今の判断はいつの根拠によるものか
    • プロダクト探索に出て新たな学びを得よう

プロダクト探索

  • 成果とはなにか
    • ユーザ/チーム/プロダクトの3軸でOKR
    • 成果と収益を混ぜない
  • 3者の仮説を立てる
    • 何がボトルネックか
      • 道具は3観点で異なる
    • ユーザ調査
    • チームの振り返り
    • プロダクトの指標計測
  • 探索活動をバックログ積む
  • 最適化の罠にははならないように
    • いつまでも動けなくなってしまう
    • 複雑なことやいろんなことはできないので最初の1つを積んで始める
    • スプリントを回して改善していく
    • 熱意を持てるものを1つ選んで始める
  • 新たな成果を上げるには新たな武器知識が必要
    • 学ぶことを置き去りにしてはいけない

テストの完了をゴールにしない！～仮説検証を繰り返し、開発・QA・ユーザーが交流しながら開発することで見えてくる理想の姿～

  • 風間 裕也さん[10X]

アウトプットとアウトカム

  • アウトプット
    • こなしたタスク
    • 書いたコード
  • アウトカム
    • ユーザの行動の変化
  • テストの完了 = ゴール ではない

継続的テストモデル

  • いろんなフェーズでテストする
    • 実装の前にするテスト
      • シフトレフト
    • リリース後にするテスト
      • シフトライト
  • テストはフェーズではなくアクティビティ

シフトレフトの例

  • コード実装前に行うテスト
    • TDDなどもあるが今回はそれより前段の話
  • 受け入れ基準を作成する時のテスト
    • リファインメントでやる
    • 開発/PO/QAが集まって要件を確認する
    • ユーザの操作としてどうなるべきなのかを受け入れ条件に入れるようにする
    • 何をもってこのタスクが完了となるかはっきりする
    • →テストと思ってないけど意外と自分はやってる気がする

シフトライトの例

  • リリース後に行うテスト

ログを仕込んで効果検証

  • そもそもの仕様が効果的かどうか検討もつかない時にログを仕込む
    • ログだけ入った状態でリリース（機能はまだ変えない）
    • 結果に応じて本当に修正を入れるか判断できる
    • やみくもにログを仕込まない
      • 扱いに困ってしまう
    • リリース後のテストだけど検討はもっと前の段階から

実際のオペレーションの観察

  • プロダクトがどうあるべきか認識する
  • 現場リサーチ
    • 教えたりするのではなくそばでただ観察
    • 運用でカバーしてるところが見えてくる
    • その現場固有の事象も見えてくる
    • データだけ見てても気付けないことが分かる
  • 全部を解決できるわけではないしする必要もない
  • 気づきをアイデアの源泉にして次に活かす
  • 使われ方をみることでリリースに意識が向くようになる

ユーザと協力してオペレーションが進行できるか確認

  • 新機能を試す場を作る
    • 開発者が現場に行って使ってみる
      • 遂行できることを確認
      • 業務遂行性
    • スタッフ研修でユーザに試してみてもらう
      • ユーザが本当にできることを確認
      • 習得性
      • 運用操作性
    • 正式リリース
      • 機能正確性
  • 最後のフェーズまではちょっとミスがあっても目を瞑ってもらう
  • フィードバックをもらいながら調整できる
  • 新機能に対してびっくりしない

徹底解剖!?JALインフォテック様が取り組む予兆検知/早期復旧を可能にするデータ分析/活用戦略とは？

  • 松尾 健史さん[JALインフォテック]
  • 鈴木 慶秀さん[JAL インフォテック]
  • 角田 勝義さん[Dynatrace]
  • 白石 武さん[Dynatrace]

データ連携基盤のオブザーバビリティ

  • 旅客/運行/整備/空港/貨物などさまざまな領域のデータがある
    • SOA、SOFIA、EPICの3分類
  • 500近いシステムと接続
  • 3000を超えるサービスとデータ連携

従来の課題

  • ユーザ問い合わせなどが多くてやりたいことができない
    • 本番アクセスしてログみて、みたいな作業
  • ユーザが自由に見られるサービスを作る
    • そのシステムのメンテに追われてしまって結局状況は変わらない
  • データを管理するサービスを導入すると解決するかもしれない

Dynatraceの導入

  • 他社製品と比べてDynatraceを採用
    • 構築がはやかった
    • 既存のソフトウェアともマッチしていた
    • ライセンス費用は高いがお金で解決できるなら

Dynatrace導入後

  • 初期の目標
    • 自社開発サービスも併用したデータ検索
    • システム構成可視化
    • Ansibleで自動操作
  • ユーザ向けダッシュボード作ったが利用されなかった
    • トラブルが起きないと見ない
    • 連動の可視化だけでなく何か起きた時の業務影響などもっと先まで求められていた

Dynatrace活用事例1

  • 預け入れて荷物の振り分けシステム
    • 去年末に障害があった
  • ダッシュボードに監視対象が並んでるのですぐに確認できる
    • データの流れを誰でも確認できる
    • 以前なら担当者がサーバにアクセスしてログを見ていた

Dynatrace活用事例2

  • 通常とは異なる流入数の検知
    • 毎日流入が少ない時間帯で増加していると検知できた
    • タイムセールが行われていて流入が増えていた
  • 長期的にリソース情報を蓄積している
    • 異常があると管理者に通知できる
    • 自前で検知システムを作っていたが、Dynatrace側の機能でもできるかも?
  • フロントエンドでエラーが起きた時にバックエンドのエラーと紐づけて確認できる機能がある

今後

  • データをどう活用するか
  • ビジネスプロセスの理解
  • 予測AIの活用

「Developers Summit 2024（1日目）」に参加してきました

勉強会メモ

我々はなぜアサーションするのか～現場に寄り添うANA DXの取り組み～

  • 室木 梨沙さん[ANAシステムズ]
  • 渡辺 亮介さん[ANAシステムズ]
  • 橋本 憲洋さん[永和システムマネジメント]

スクラム開発

  • 開発チームは2社のメンバー混ざってる
  • リモート
  • ANA社員が使うWebやアプリ開発
  • ユーザ部門は多岐にわたり毎回変わる

チーム開発

  • 対ユーザ
    • 毎回ユーザ部門が変わるのでwhyをよく聞く
    • 現場見学したり
    • お互い意見を出し合って改善
  • チーム内
    • 個人ではなくチームで進める
    • みんなが全部知ってる状態でs進める
  • コミュニケーション
    • 納得共感するまで話をする
    • 中途半端にすると後々困る

アサーション文化

アサーション文化と開発チーム

チーム内で率直に発言できる土台作り

  • デイリー
    • 1日3回(朝昼夕)
    • 会議のアジェンダ確認
    • 課題や気になること中心
    • 昼夕はコンパクト
      • 困りごとモヤモヤ確認
  • レンジャー
    • 9人が3x3でチームを組む
    • 常に3人で動く
      • ずっとカメラマイクon
      • 視覚で伝わる情報が多いから
    • 常にモブでワーク
    • springごとにシャッフル
    • 苦手分野も勇気を持って取り組める
  • ふりかえり
    • 日常的に感謝を伝える
    • 失敗やもやもやを共有
      • 認知判断意図しない行動による失敗
      • チャレンジ検証による失敗
      • モアモヤ

会社の契約関係を越えたコミュニケーション

WebシステムやモバイルアプリにおけるUIからの自動テスト事例3選

自動テストの山

  • 山が2つ
    • 始める山
      • 初期構築を素早く
    • 継続する山
      • テストをリファクタできるか

環境の変化

  • WFからアジャイルへ
    • 自動テストしないと気づかないバグが発生してしまう
  • ツールの変化
  • テストへの期待
    • 実施するものではなく実行されているもの
    • テストはバグを見つけるものではなくフィードバックを得るもの

事例1

  • Webアプリ(PHPとJava)
  • 課題
  • 思い
    • アップデートでデグレがないか確認したい
    • 毎日自動テスト動いてる状態にしたい
  • ユーザに提供してる基本的な機能をテスト
    • Seleniumで
    • テストピラミッド的にもUIのテストで詳細までやらない方がいい
    • 最初の1ケースが回り始めるまでに3週間
    • 100ケースすべて作るまでに2ヶ月
  • テストは毎日1回
    • 失敗時はSlackへ概要とスクショを送信
  • とにかく1テストケースが毎日実行される実行環境を最速で作る

事例2

  • CASIO WATCHES
    • アプリ
  • デグレを中心に自動テストを実施したい
    • 工数削減
    • 本番リリース後のチェック
  • 284ケース
  • 1日2回
  • Mac miniに実機繋いでテストする
    • bluetoothでつなぐので実機じゃないと
  • jenkinsのパイプライン
    • appiumの起動チェックとかもやってる
  • テスト失敗時の調査修正が数時間かかる
    • 1ケースの実行時間が長い(10〜30分)
    • 再実行->途中で落ちるとかあるので修正確認も時間かかる
    • 画面単位のテストケースを分割した
      • テストが安定した
  • 継続のポイント
    • まずは属人化させる
    • 失敗テストを放置しない
    • 不安定なテストは捨てる
    • テストのリファクタする
    • 開発など他のメンバーとコラボレーションする

自動テスト歴0年でもできる！テスト工数を46時間/月削減した方法　～1年目で得られた成果と展望～

  • おだしょー(小田祥平)さん[mabl]
  • 三上 鹿さん[ビットキー]

mabl

  • テスト自動化プラットフォーム
    • UI,API,モバイルのテスト
    • a11yとかパフォーマンスの計測もできる
      • a11yは何やってるんだろう?axe実行してるとか?

bitkeyの事例

  • 機能拡充でリグレッションテストが増加した
  • mablを選んだ
    • ノーコードローコードで自動テスト作れる
    • (他と比べて?)レスポンスが速くて動作が快適だった
  • 1年で約25%自動化
    • 月1回回してる

Kubernetesは怖くない！開発者のためのインフラトラブルシューティング入門

kubernetesの特徴

  • 障害時に各コンテナ設定復旧を簡単にする
    • 障害から自動復旧してくれる
  • コンテナの仕様の管理を簡単にする
    • ファイルで設定を管理できる
    • Infrastructure as Code
  • 複数台サーバでコンテナ起動し最適な起動先の決定を簡単にする
    • 設定書くだけで細かいこと設定しなくても勝手にやってくれる

kubernetesのアーキテクチャーを知る

  • Control Plane
    • etcd
      • データベース
    • kube-apiserver
    • kubctlでkube-apiserverを叩いてデータがとれる
  • Worker Node

何が起きてるか知る方法を知る

  • kubernetesを使うと見る場所や味方が集約される
  • ログ
    • kubectlで全てのコンテナのログが見れる
    • ログは永久保存ではない
      • 別のサービスにログ転送してたらその見方を覚える必要はある
  • kubernetesのEvents
    • リソースごとに何が起こったか見ることができる
  • kubectlを使えるように

リソース

  • Pod
    • コンテナを起動する最小単位
  • ReplicaSet
    • Podを複数管理するリソース
  • Deployment
    • ReplicaSetを複数管理するリソース
  • Service
    • Deploymentで作成した複数Podへのアクセスをルーティングするために使うリソース

トラブルシューティングのコツ

  • 狭い範囲から調査
    • Podからきりわけていく
  • 仮説検証を繰り返す
    • 証拠をたくさん集める
      • kubectlを駆使する

AIを活用した誰でもテストが自動化できるプラットフォームの実現に向けて

  • 松浦 隼人さん[オーティファイ]

Autify

  • E2Eテストを自動化するサービス
    • ノーコード
      • 実際の操作をリプレイしてテストする
    • Web/アプリ

AIの活用

  • 要素の特定
    • クリックした対象の特定
    • 特徴情報を記憶して特定している
      • HTMLも見ている
      • アプリの場合は画像情報に頼ってる
    • テスト対象が変わった時も壊れないように
    • セルフヒーリング
  • チェックボックスの認識
    • 見た目や実装が多様すぎる

マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB

TiDB

TiDB Cloud

  • PingCat提供のDBaaS
  • AWSとGoogleCloudで提供されている
  • ServerlessとDedicated

TiDB Cloud検討

  • 現状の課題
    • スケーラビリティ
    • シャーディングによる運用コスト増加

マイクロサービスの課題

  • 0からマイクロサービスで作るのはアンチパターン
    • 大きくなってから分割するのがいいらしい
  • 分散トランザクション
    • 設計や実装難易度が高い
    • 発生した時点で設計敗北
  • サービスとリンクしていない組織設計
    • devとopsが分かれていた

TiDB Cloud導入でどう変わる

  • 自動シャーディング/バージョンアップ
    • アプリケーション側での実装不要

AI時代を乗り切るための実装力をつけよう

AI時代にプログラマは必要か

  • コードはChatGPTが書いてくれる
  • プログラムの外とのつながりはプログラマが設定する
  • 処理をちゃんと書けることが大切

逐次実行

  • ループ処理での状態遷移
  • Streamを使えると順番に処理を読めばいいからわかりやすい
  • 逐次実行はプログラムカウンタの状態遷移
  • 状態遷移のコードは意図が分かりづらい

まとめ

  • ライブラリの使い方はAIがわかる
  • 処理を発想できること把握できることが大事

ゼロから大規模アジャイル組織への進化～推進者が語る立ち上げ背景と開発生産性～

  • 佐藤 将高さん[ファインディ]
  • 岡澤 克暢さん[KDDIアジャイル開発センター]

なぜアジャイル開発センターが設立されたのか

  • 流れ
  • 初期
    • コア人材育成が重要
    • 最低限のツール整備
    • 守破離の守を実施
  • 拡大期
    • 部の立ち上げ
    • 事業領域拡大
    • グループ会社もまたいで

アジャイル推進の過程での課題と役割

  • 課題
    • 複数案件掛け持ち
    • いろいろスキルや人材不足
    • ビジネスマインド
    • ゴールの定義/共通意識
  • 必要な役割
    • スクラムマスターに似た感覚を常に持つ
      • オープンマインド
      • 視点視座

生産性

  • 生産性を見える化することが重要
    • 改善が見えるから
    • メンバーに気づきを促せる
  • 開発生産性工場のアクション
    • Findy Team+
      • 透明性が向上した
    • 指標の全体を俯瞰
      • サイクルタイム
      • レビューリードタイム

今後の組織づくりにおけるトライ

  • ここの強みをもっと活かす
  • 成長速度を加速する仕組み
  • Reteamingのベストサイクル
  • 楽しいの追求

AI時代のソフトウェアテストの現在と未来

  • 和田 卓人さん
  • 川口 耕介さん[Launchable]
  • 近澤 良さん[オーティファイ]

テストが定着してきた？

  • 自動テストの認知が進んできてるかも
  • 自動テストを書くことの大切さを技術者以外の人に伝わるようになってきた
    • 統計のデータとかが出てるのでそれが説得材料になる

国内のテスト事情と海外のテスト事情

  • 海外
    • サンフランシスコは自社で全部やってるところが多い
    • ワシントンで官公庁のシステムエンジニアの給料が高いから公務員として雇えないからSIerに委託
      • インドが多い
      • 準委任みたいな形
    • QAチームが離れてるケース
      • インドに部隊がいるとか
  • 日本
    • 自社で開発を取り組もうとしてる人からの関心が高まってる
      • 継続して成長させたい
      • スキルのある人はいないから準委任みたいな形も増えてる

開発でのAI活用の浸透

  • copilotやChatGPTは日本も海外もみんな使ってる
  • 現場で使ってるツールはあるがその次をみんな模索してる

ソフトウェアテストでのAI活用の浸透

  • AIを使ったサービスがいろいろある
    • AIを使った機能が部品としてあるのが当たり前になってきてる
  • ソフトウェアの開発はAI活用で生産性向上した
    • AIを組み込んだサービスの不確実性が増してテストは難しくなった
  • LLMの作ったものをLLMでテストするような取り組みが進んです

「今さら聞けないペルソナの活用術」に参加してきました

勉強会メモ

ペルソナを"作る"ときのヒント

  • 渡邊 陽介さん(LINEヤフー株式会社)

活用できるペルソナ

何を設定すればいいか

  • 1枚のシートで共有するので何でも設定すればいいわけではない
  • 設定する項目
    • ユーザゴール/名前/価値観/シナリオ
    • それ以外は目的を達成するために必要な情報であればなんでも
      • （ペルソナをなんのために作るかを整理できた上でその目的を達成できるなら）何でもいい
  • チェック項目
    • 価値観状況理解を補足する情報か
    • 意思決定に影響する情報か
    • その情報で調査目的を達成できるか
  • 調査設計
    • 何を明らかにしてどう活用するのか(調査目的)

実在しないペルソナになってしまう

  • 都合に合わせて伸縮自在な ゴムのユーザー ができてしまう
    • 万人に受けるサービスは誰にも受けない
    • 1人に刺さらないサービスが100人に刺さるはずない
      • 百徳ナイフ
  • 慎重に被験者を分類する
    • 四象限での分類
    • スペクトラムでの分類・・オススメとのこと
      • 5〜15の軸を作ってあてはめる

大量に出てきてしまう

  • 性別年齢などのデモグラ情報で分けてしまう
    • 価値観は似てても別になってしまう
    • ターゲットに価値観を後付してる感じになってしまう
    • ターゲット：顧客層、ペルソナ：顧客像
  • 十人十色？いいえ十人三四色
    • 10人のユーザに話を聞くとだいたい3、4パターンになる
    • 必ず優先順位をつける

ペルソナを"共有・理解する"時のヒント

  • 河井 恵理さん(株式会社mediba)

ペルソナのメリット

  • 同じ認識を持って方向性を決めていける
  • 同じ認識が難しい
    • 思考の癖がある
    • xxがいいと言ってる裏にはそれぞれのバックグラウンドがある
  • 共感できた状態
    • 主語がペルソナになっている
    • シートにないこともこうしそうと想像できる
    • 自分や周囲の発言に「わかる」と思える

理解されにくい理由

信憑性が低い(と思われる)

  • 裏にあるデータを示す
  • ステップごとに結果を共有
  • 質問が出たらすぐにデータを出して説明できるように
  • 元になった生のユーザを見せる

粒度が粗い/多すぎ

  • 図示する
    • 時系列で書くとか
    • チャートで示すとか
  • ツールを使い分ける
    • 無理にペルソナシートだけでまとめない
  • 名前を付けて印象を確立する
    • 特徴を表す名前にして覚えてもらう

事業イメージとつながらない

  • キーポイントの見定めと強弱をつけた共有
  • 次に繋げる具体的な提言まで

ペルソナを活用したプロセス3選と好事例

  • 秋野 比彩美さん(Goodpatch Inc.)

後続リサーチのリクルート条件にする

構造化シナリオの主人公にする

  • 構造化シナリオ
    • 主人公のシナリオとの関わり
    • バリューシナリオ
    • アクティビティシナリオ
    • インタラクションシナリオ
    • オブジェクトの抽出
    • 要素と要素のつながり

機能の優先度をペルソナを軸に判断する

  • 機能の優先度をどんな軸で判断してるか
    • ペルソナを軸に判断できる

「UI＋FE合流点 - UIデザイナーから見た実装の話 feat. プレイド」に参加してきました

勉強会メモ
  • 2024/2/6
  • https://gaji-lt.connpass.com/event/304576/
  • 座談会なのでメモあんまり意味なさそうですが記録として
  • 勉強会は懇親会がメインって感じになることはあまりなかったけど今回はそれだった
    • デザイナーに聞いてみたいことをたくさん聞けた

座談会

  • tori（鳥越 良子）さん（@ryoko_torigoe）
  • sekig（関口 裕）さん（@hanarenoheya_im）
  • putchom（福嶋 瞭）さん（@putchom）
  • 今西さん（@harembiii）
  • 原田さん（@neotag）

デザインスタイル

  • コードは書けないがそれ以外はできる
    • インタラクションデザインとか
  • コードも書く環境だった
  • コードも書けるで入ったけどデザインだけやりたくなった
    • 理詰めでデザインするようになった

デザイナーって呼ばれたくない

  • デザイナー/エンジニアとか言ってると距離が離れる
  • 一緒に作ってるって感じを出したい
  • デザイナー視点でもっとエンジニアに踏み込んできてほしい
  • 土台を作ってる感じ
    • 完成形でそれを作れという意味じゃない

その1px重要ですか

  • UIデザインのフェーズ
    • プロトタイピング
    • 詳細設計
  • プロトタイピングで勝ち確になってからこだわる

状態のパターン

  • デザイナーもテストを学ぶといいのでは
  • 経験則でパターンを学んでいってる

共通言語/デザインシステム

  • デザインシステムを固く作りすぎない
    • 制約になりすぎないように
  • 実装メインのフェーズになった凪の時間にデザインシステムにバックポートしてる
  • なぜその色なのかなど言語化されるのがいい

2024年1月に読んだ本

読書メモ
  • 2024年1月に読んだ本の記録です
  • 去年は1年まとめて書きましたが今年は毎月書いてみようと思います
  • あんまり少なくてもあれなので毎月3冊くらいは書きたい

フロントエンドの知識地図

gihyo.jp

  • 2023年末時点でのフロントエンドをとりまく技術要素を広く浅く紹介してくれています
  • WebサイトとWebアプリケーションを区別して2軸で話を進めている点がとてもよかったです
    • フロントエンドと言ってもどちらを指してるかで話が噛み合わないこともよくあるので
  • これからフロントエンドを始める人にとっては知っておくべき要素を一通り認知することができるので有用だと思います

フロントエンド向けWebAssembly入門

bookplus.nikkei.com

  • WebAssemblyはまったくふれたことがありませんでしたが「フロントエンド向け」という文言につられて読みました
  • WebAssemblyの特徴や、ブラウザ上でWebAssemblyをどう使っていくのかをハンズオン形式で学べます
  • 使う機会があるかわかりませんがどのようなステップで開発していくのかを知ることができました

プログラマー脳

www.shuwasystem.co.jp

  • 人がプログラムを読む時にどのようにして理解しているかなどを様々な研究などをもとに紹介されています
  • プログラムを理解する仕組みを知ることでどうやったら読みやすいコードになるか意識が変わった気がします
  • 単純に読み物としても面白かった

2023年に読んだ本

読書メモ
  • 2022年に続いて本を読む習慣が今年も続いたので記録しておきます
  • 新刊のチェックは下記のサイトが便利で「登録日の新しい順」を定期的に見るようにしてます

techplay.jp

読んだ本一覧

改訂3版JavaScript本格入門

gihyo.jp

実践Node.js入門

gihyo.jp

これからはじめるReact実践入門

www.sbcr.jp

フロントエンド開発のためのセキュリティ入門

  • 具体的な対応のしかたも書いてあるので実務でも役に立った

www.shoeisha.co.jp

フロントエンド開発のためのテスト入門

  • いつもこの本を見ながらテストを書いてます

www.shoeisha.co.jp

Web APIテスト技法

www.shoeisha.co.jp

Webアプリケーションアクセシビリティ

  • どう実装するか悩んだときに何度も読んだ
  • 具体的な実装がたくさん載ってるのがありがたい

gihyo.jp

ウェブ・インクルーシブデザイン

book.mynavi.jp

カラー・アクセシビリティ

book.mynavi.jp

デザイナーのための心理学

book.mynavi.jp

縁の下のUIデザイン

gihyo.jp

Figmaデザイン入門

gihyo.jp

UXデザイン100の原則

UXデザイン100の原則bnn.co.jp

アジャイルプラクティスガイドブック

  • このシリーズの本は読みやすくて一気に読み切れる
  • 自分が普段やってることとの対比ができて学びになった

www.shoeisha.co.jp

SCRUM BOOT CAMP THE BOOK

  • 初心者向けによく勧められてるが確かにいいと思った

www.shoeisha.co.jp

SCRUMMASTER THE BOOK

  • 同じシリーズなのでまとめ買いしたがこの本は外国の本の日本語訳版で違う雰囲気だった

www.shoeisha.co.jp

アジャイルなチームをつくる ふりかえりガイドブック

  • 振り返り手法がたくさん載ってるのでいつもと違う振り返りをしたい時にこの本から探してる

www.shoeisha.co.jp

スクラムの拡張による組織づくり

gihyo.jp

仕組みと使い方がわかる Docker＆Kubernetesのきほんのきほん

  • かなり読みやすいのでWeb開発者なら使う機会はなくても基礎知識として読んでおくといいと思った本

book.mynavi.jp

Web Designing 2023年4月号

book.mynavi.jp

Software Design 2023年8月号

gihyo.jp

WEB+DB PRESS Vol.133〜136

gihyo.jp gihyo.jp gihyo.jp gihyo.jp

2022年に読んだ本

読書メモ
  • 転職してから書籍購入補助が出るようになったので技術書を読むようになりました
  • 読んだ本を何かしらに記録しておきたかったので以下にまとめておきます
  • 本当は1冊1記事書きたいので今後やる気になれば書いてみます

読んだ本一覧

  • カテゴリ分けが難しかったのでだいたいグラデーションになるように並べてみました

HTML解体新書

  • HTMLタグを理解するのに役立った
    • 知ってることも多かったが知らないことも多かった

www.borndigital.co.jp

武器になるHTML

  • HTML解体新書よりも初心者向け

gihyo.jp

CSS設計完全ガイド

  • BEMなどちゃんと勉強したことがなかったのでそのあたりをちゃんと学べた

gihyo.jp

Every Layout

  • 自分がよく使うCSSの書き方に名前があるか調べてたらたどり着いた本
  • 本の内容を全部を採用することはないが考え方は参考になった

www.borndigital.co.jp

プロを目指す人のためのTypeScript入門

gihyo.jp

TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発

gihyo.jp

デザイニングWebアクセシビリティ

  • 買った当時はアクセシビリティの本があまりなく、古めの本で探すのも大変だった
  • こっちはエンジニアというより企画サイドの人向け

wgn-obs.shop-pro.jp

コーディングWebアクセシビリティ

  • デザイニングとセットで買った本
  • アクセシビリティに配慮した実装の参考になる本
    • もっといろんなパターンを紹介してほしいと思ったところで2023年に別の本が出た

wgn-obs.shop-pro.jp

見えにくい、読みにくい「困った！」を解決するデザイン

book.mynavi.jp

ノンデザイナーズ・デザインブック

  • 上の困ったを解決するデザインで紹介されてたので買った本
  • 4つの原則は知っておいて損はないと思った
  • 英語前提のところも多くてその辺は参考程度

book.mynavi.jp

Webを支える技術

  • Webに携わるなら全員読んだ方がいいと思った本

gihyo.jp

ドメイン駆動設計入門

  • 読みやすくて分かりやすかった

www.shoeisha.co.jp

良いコード／悪いコードで学ぶ設計入門

  • いろいろなケースに対して良い例と悪い例を紹介してくれる本
  • すべて鵜呑みにはしない方が良さそうだが考え方の1つとして参考になった

gihyo.jp

良いコードを書く技術

gihyo.jp

オブジェクト指向UIデザイン

  • 内容はともかくとして、この本が推奨しないパターンを否定しまくる感じが自分にはあわなくて全部読めなかった

gihyo.jp

SQLアンチパターン

www.oreilly.co.jp

テスト駆動開発

shop.ohmsha.co.jp

WEB+DB PRESS Vol.126〜132

gihyo.jp

gihyo.jp

gihyo.jp

gihyo.jp

gihyo.jp

gihyo.jp

gihyo.jp

「次世代 Web カンファレンス 2023」に参加してきました

勉強会メモ

CSS

scopedなCSS

  • shadowDOMは独立してて外の影響をうけない
  • @scopeは影響を受けたいときに使う
    • リンクはglobalなCSSを適用したいとか
    • どの親要素からどの子要素の間まで適用するといった感じで範囲指定もできる
      • 複雑なクラスをつけなくて良くなって要素セレクタも気軽に?使える

Utility First CSS

  • デバッグが大変?
  • CSSの新しい記法活かしきれるか？
    • :hasは独自の書き方で実現はできる
    • tailwindとかのツールを学ぶ感じになってしまう？
  • KumaUI
    • utility classではない
    • CSS props
    • 型の恩恵を受けたかった
  • CSSとJS
    • UIに関するstateはCSSに寄せるべき？
    • CSSを分からなくてもJSだけで書けるツールが増えてる
  • LayoutShift
    • スケルトン出してもシフトする問題
  • zero runtime css
    • RSC対応のために流行ってきた面はある
    • 元々runtimeに手が入るのでパフォーマンスに課題があった
    • なのでRSC対応できればいいというものでもなくちゃんとパフォーマンスも気にするべき
  • AIフレンドリー
    • AIに吐かせるならtailwindが相性いいらしい
    • copilotで補完とかだとファイルまたがない方が相性いいかも

Accessibility

a11yの歴史

  • 2008年流行っていたデザイン
  • WCAG2.2
    • 2023/10
    • JISはまだ追いついてない
      • 今のはとても古い

開発時のチェック

  • ESLintとかaxeとかで静的解析もできる
    • 全部をできるわけではない
    • 静的解析でOKならいいというわけでもない？
    • 人の目で見るにしても思いのある人が見ないとちゃんとチェックできない
      • altにaって入っててもOKしちゃう人もいる？
  • 最近だとa11yに配慮されたコードだとテストが書きやすい

AI

  • 画像のaltを自動生成できないか
    • コンテキストを把握した上で生成してもらわないといけない
    • コンテンツ提供者の意図を含めないといけない

クローリング

  • スクロールしないと要素がでないページが増えてきている
    • クローリングできなくて困るしa11y的にも悪い

Design Technology

デザインテクノロジー

  • デザインとエンジニアリングは不可分
  • デザインという言葉のスコープ広すぎ

デザインシステム

  • 用語が曖昧
  • 実質的にコンポーネントライブラリのことを指す使われ方も増えている

Frontend Architecture

クライアント/サーバ

  • どちらに寄せるか行ったり来たりしている
  • 今はサーバに寄り始めてる
    • JSサイズがでかくなる
      • 操作可能になるまでのパフォーマンス
    • SSR
      • パフォーマンス
      • SEO
      • インフラのコスト

SSR/CSR

  • 作るものの性質による
    • 認証必要なアプリはSSRする必要もない？
    • 速度やSEOなど気にする必要あるならSSRしたい
  • Next.js以前は自前でSSRやってた
    • SSRは負荷がかかったりパフォーマンスでなくて大変だった
    • 自前FWはReactの進化など追従が大変だった

RSC

  • サーバだけで動くコンポーネントを作れる
    • RSCはSSRしなくても使える
    • APIアクセスなどサーバ側でやっちゃえる
  • データを取得するところもReactの範疇になってきた
  • Reactコアチームの人たちはGraphQLの次のものとしてRSCを考えてる
  • fetchしてそこでキャッシュするライブラリが増えてる
    • swr
    • TanStack Query

プロダクション採用

  • 歴史のあるサービスは簡単にUXを変えられない
  • 多少の不具合が起きてもいい場所でトライアルしてる
    • 同じサービスでも複数アプリ入ってるケースも多くその中で選んだり

「UIT × Bonfire Front-end Meetup #1」に参加してきました

勉強会メモ

社内ツールから生まれたOSS "ts-remove-unused" によるフロントエンド開発の効率化と品質の向上

ts-remove-unused

  • https://github.com/line/ts-remove-unused
  • export付いてるのに利用されてないコードを削除してくれる
    • exportがなければlintでき付けるけどexportあると気づきづらい
  • なぜ作ったか
    • コンポーネントライブラリを置き換える時にデッドコードが大量に発生した
    • 依存関係をたどる必要があり簡単に削除できない
  • 構文の解析
  • 振り返って
    • 全部のケースをカバーできなくても手動でやるより効率化できた

ヤフーのユーザー 5,400 万人から"同意"を得るための技術

  • 今谷祐通さん

プライバシーポリシーの同意モジュール

  • 合併に際して新しいポリシーの同意画面のSDKを作った
    • Modal版/FullScreen版
    • いろんなサイズのいろんなデバイスに対応させる必要があった
    • iOS/Android/Web
  • 苦労した点
    • 影響度
      • ヤフーサービス利用者5400万人
      • サービスの利用体験に影響する
      • 広告に影響が内容シビアな速度
      • 法的/ビジネス的影響度
    • 対象範囲
      • 様々なOS/ブラウザ/通信環境
      • 数千万台のデバイスで安定動作が必要
      • 1つのミスや考慮不足が致命的な問題に
      • シェア0.1%でも無視できない
    • 保守性
      • 開発後は案件先の担当者だけで運用できるように
        • エラーコードを細かく整備
        • コードを見ただけでどこでどんなエラーが起きたか分かるように

管理画面向けUIコンポーネントの設計 - Web componentsでフレームワーク非依存を目指す

  • Tamada Akihiro (spring-raining)さん

既存プロジェクトへのCSSフレームワーク導入

  • LINE公式アカウントの管理画面
  • Vueファイル2600超え
  • 機能が多岐だが利用頻度はまちまち
    • 特定ユーザ向けの画面がたくさんある
  • Bootstrap4をカスタマイズした独自ライブラリ
    • 問題なく使えてるがCSSへのパッチが増えていき変更困難に
  • Tailwindへの移行を徐々に
    • BootstrapのckassがTailwindと重複するのでprefixつけたり
  • TailwindはユーティリティなのででCSSフレームワークを作ろうとするとUIコンポーネントを作る必要がある
    • 今後他の画面でも使われるかもしれないのでVue依存はダメ
    • WebComponentsで作ろうか

WebComponents

  • フレームワークに依存しないUIコンポーネントを提供できる
  • ShadowDOMでスコープ分離できる
  • いろいろ問題が
  • WebComponentsの開発
    • litを使ってる
    • ClassベースなのがFE開発とコンテキストスイッチを切り替える必要あり
    • litのmixinがTS対応が難しい
  • Zag
    • https://zagjs.com/
    • UIコンポーネント実装のためのライブラリ
    • ArkやPandaCSSはZagベース
    • FWに依存しない実装でReact/Vue/Solidに対応
    • litにも対応可能
    • Classベースではない
    • ステートマシンで状態管理を抽象化できる
    • WebComponentsからの脱却も見据えることができる
  • custom-element-manifest
    • WebComponentsをReactなどで使えるようにラップしたい
    • jsonで宣言してコンポーネントを自動生成する
  • SSR対応
    • エコシステムとしてはまだ
    • 今回の事例ではSSR必要なかった
    • Declarative ShadowDOM
      • SSRでShadowDOMを使える技術
      • まだ全ブラウザで使えるわけではないので今後に期待

まとめ

  • WebComponentsはFW非依存の選択肢としてはよい
  • Zagによるふるまいの分離がいい
  • 将来を考えたエスケープハッチが重要

Web Componentsを使ったUIコンポーネント

リニューアルで学んだ通説の捉え方

  • 長内創太郎さん

ヤフーメールリニューアル

  • SP版Webの技術刷新
  • 技術スタック
    • Before:jQuery/PHP
    • After:React/Redux AsyncThunk
  • リニューアル後
    • ReduxToolkitを使ってもパフォーマンスは大きく落ちなかった
      • 非同期処理の見直し
      • lazyImport導入

「GDG DevFest Tokyo 2023」に参加してきました

勉強会メモ

Google CloudのGenAIサービスで「AIにファッションを褒めてもらうアプリ」を作ってみよう

  • 中井 悦司さん(Solutions Architect)

GCPの生成AI機能

  • 画像を認識して字幕を出したり
  • Visual Q&A
    • アップした画像に対してどんな情報がほしいかチャットでやり取りできたり
  • PaLM2
    • 多言語に強い
    • 日本語のダジャレを英語で説明できたり

個人アプリ開発（メンテナンス）14年の歴史

個人でのAndroidアプリ開発

  • Androidアプリは2009年からで2009年の終わりには個人アプリを出してた
  • 個人開発のモチベーション
    • 使ってくれてる人がいる（課金してくれてる人も）
    • 自分でも使ってる
    • 新機能の実験台にできる
  • 2012年にAndroidMarketからGooglePlayに
  • 2013年にAndroidStudioが出た
  • 2017年にKotlinサポート発表
  • 気をつけるといいこと
    • READMEちゃんと書くといい
      • 自分で書いたことでも忘れる
    • ライブラリの自動更新便利
      • 年単位でメンテしないとかあるので自動化するといい

大画面デバイスにどう向き合えば良いのか？

大画面デバイス

大画面デバイスだと

  • アプリ作成の前提が変わる
    • 横向きで使われる
    • マルチウィンドウで使われる
      • 画面サイズが頻繁に変わる
    • タッチだけでなくキーボードやマウスなども使われる

大画面デバイスのサポートレベル

  • 3段階で規定されてる
    • Tier3:Basic
      • 壊れずに動くレベル
    • Tier2:Better
      • 大画面に最適化された状態
    • Tier1:Best
      • 大画面の特性を活かしてる

2023年のウェブ

2024のWeb

  • 3rd p cookieのブロックを実感できるようになる
  • パスキーの浸透
  • chrome拡張のv2が2024/6に動かなくなる
  • a11y元年(2024/4法改正がある)

2023/1

  • lh
    • 高さを行数で指定できる
  • MathMML

2023/2

  • :picture-in-picture
    • PinPの擬似クラス
  • launch_handler
    • PWAの起動
  • credentialless iframe
  • コンテナクエリをFFでもサポート

2023/3

  • View Transitionn API
  • Safari16.4
    • Web Push

2023/4

  • CSS nesting
  • PWA要件のハンドラーが空だったら無視するようになった

2023/5

  • WebGPU
  • ファーストパーティーセット
  • Google I/O
    • WebGPU
    • パスキー
    • Baseline
      • 主要ブラウザでサポートされてる技術をまとめて故障(ex. Baseline 23)

2023/6

  • text-wrap: balance
  • CHIPS
    • クッキーの話
  • Popover

2023/7

  • Scroll-driven Animation
  • fencedframe
  • Topics API

2023/8

2023/9

  • transition-behavior
  • Safari17

2023/10

  • @scope
  • prefers-reduced-transparency

2023/11

  • Cookieの有効期限
    • 昔に発行されたものも400日期限に
  • :user-valid/:user-invalid

2023/12

  • CloseWatcher API
  • detailsタグのname属性

Compose 時代のパフォーマンス感覚

  • 荒木 佑一さん(デベロッパー リレーションズ エンジニア)

View時代の感覚からの脱却

  • ViewGroupのネストは最小限にすべき
    • 子の大きさを測って配置する
      • Compose:Layout、View:ViewGroup
      • ViewGroupは2回測られるので累乗で増えていってしまう
      • LayoutはIntrinsic Measurementと計測で別れてる
        • ->Composeならネストはそんなに気にしなくていい
  • ランタイムとGC
    • GCでとまるのはDalvik(APIレベル19)まで
    • Composeなら小さいオブジェクトなッッらGCそんなに気にしなくていい
  • 計算結果のキャッシュ
    • rememberでmemo化できる
  • Composeのフェーズ
    • Composition
      • ソースからUIのツリーを作る
    • Layout
      • どれをどこにどの大きさで配置するか
    • Drawing
      • 描画する
    • コードブロックがどのフェーズで実行されるか意識するといい
      • stateの値取得を後のフェーズでできるならその方が再実行する量が少ないのでいい

New in Angular

v16(2023/5)

  • Standalone API
  • Signals
    • reactivityのための機能
    • 他のライブラリでもあるのと同じ感じ
    • v17でstable
  • Hydration
    • SSRされたHTMLを破棄して一から作ってた
    • SSRされたHTMLを使いまわして動かせるようになった
  • esbuild-based build system
    • webpackをesbuildに変えて高速化した
    • v17からデフォルトに

v17(2023/11)

  • Angular.dev
  • Built-in Control Flow
    • @if/@for/@switch
    • v17ではdeveloper preview
    • @forの@emptyが特徴的
    • 書き方が変わるだけじゃなくてパフォーマンスが大幅に改善
  • Deferrable Views
  • New SSR Developer Experience
    • 雛形生成で簡単にSSR作れるようになった
    • ng new --ssr

2024のロードマップ

  • Angular.devの完全移行
  • Zone-less
  • SSRデフォルト有効化
  • PartialHydration対応
  • AngularMaterialのMaterial3対応

2023 Flutter/Dart Summary

Impeller

  • 新しいレンダラー
    • パフォーマンスがいい
    • 明らかに起動が速い
  • iOSはデフォルトになった
  • Androidはプレビュー版でまだSkiaがデフォルト

Material3

  • Material3のコンポーネントが追加された
  • 画像などからColorSchemeを作成できるようになった

Web

  • Flutter WebでFragment Shadersが使えるようになった

Dart3

  • Record
    • return ('a', 'b') みたいに複数値を返せる
  • Patterns
    • swich文で便利
  • Class modifies
    • クラスが増えた
  • DevTools Extensions
    • DevToolsを独自拡張できるようになった
  • Skwasm
    • SKottie
      • SkiaでLottieを動かすためのSkottieをWasmで動かせる

ページ遷移の高速化 2023 年最新のページナビゲーション事情

  • 弘田 百合子さん(Partner Solutions Engineer)

ページ遷移

  • 1度の訪問で4.6ページ
  • 直感的で高速なページ遷移

View Transitions

  • ページ遷移時にフェードイン/アウトがつく
    • document.startViewTransition(() => ...)
  • 仕組み
    • 遷移すると最初のページのoldが上にかぶさる
    • 下のページが切り替わる
    • oldと下の間に新しいページのnewができる
    • newができたらoldからnewにフェード
  • zoom in/out
    • CSSでview-transition-nameをつける
    • ページ感で同じnameがついてるとそれらを連動させて遷移できる
  • 挙動の確認
    • devtoolsのAnimationsタブでアニメーションのスピードを遅くしたり止めたりできる
  • MPAでの利用
    • 今はchromeでflagを建てないと使えないが対応は進んでる
    • metaタグでname指定したりする

Prerendering

  • preloadingの技術
    • prefetch
      • リソースを事前に取得するだけ
    • prerender
      • ページを表示する準備を整えるところまで
  • Speculation rules APIで実装する
    • prefetchとprerenderどちらでも使える
    • 対象のページのURLを <script type="speculationrules"> で指定する
  • 挙動の確認
    • devtoolsのApplicationタブの中のSpeculations
    • prerenderしてるページが並んでる
    • prerenderingされたページのinspectも見れる
      • domが見えたりネットワークタブも見れる

Back Forward Cache

  • デスクトップは10回に1回、スマホは5回に1回のページ遷移は「戻る」
  • 遷移前のページをメモリに持っておいてそれを返すから戻ったときの表示が速い
  • BFCacheの有効化
    • Aviod unload handlers
    • 専用のheader?

Google Marketing Solutions のGithub から学ぶ Google Style Guides

  • Sho Tanaka (tsho)さん(Technical Solutions Consultant, Google)

Google styleguide

「Meguro.css #9 @ oRo」に参加してきました

勉強会メモ

Meguro.css #9 @ oRo

ユーザースタイルシートや拡張機能で作る広告ブロック入門

  • Kaitouさん

ユーザースタイルシート

  • 自分で作ったCSSを適用できる
  • SafariとかFFとかで使える
  • Chromeはないので使うとしたらChrome拡張で

Chrome拡張を自分で作る

  • 自分で使うだけならパッケージ化されてないものも読み込める
  • 簡単に作れるのでよく使うページのちょっとした改良とかできちゃう

2020年から2023年までのCSSの変遷を振り返る

ブラウザやFEのできごと

CSSの進化

  • where/is
  • aspect-ratio
  • flexboxのgap
  • subgrid
  • ContainerQueries
  • focus-visible
  • margin-inline-start/end/margin-block-top/bottom
  • accent-color
  • scroll-snap
  • scroll-behavior
  • inset
  • media queryの範囲指定
  • @scope/@layer
  • has
  • CSS Nesting
  • View Transition API

Scroll-driven AnimationsとCSSの進化

スクロール駆動アニメーション

  • スクロールに合わせて要素をアニメーションさせることができる
  • Scroll Progress Timeline
  • View Progress Timeline
  • パララックスがCSSだけで簡単に作れる
  • 対応ブラウザはまだまだ

カスタムプロパティのアニメーション

アニメーションの作り方

  • 昔はkeyframesで0,25,50,75,100みたいに指定してた
  • sin()を使うともっといい感じにできる
    • 引数にカスタムプロパティを入れてその値を変化させる
      • sin(var(--x))
    • 設定を書く必要もある
  • iOSのアニメーション

アニメーションのパフォーマンス

  • CSSでやった方がJSでやるより速い
    • opacityやtransformなどは速い
    • カスタムプロパティはそうでもなかった

2年ぶりにCSSアニメーションを作ったよ！

  • うえむーさん

アニメーションを作ってみた

CSSだけでCookie Clickerを作る

  • はとさん

CookieClicker

「フロントエンドカンファレンス沖縄2023」に参加してきました

勉強会メモ

フロントエンドカンファレンス沖縄2023

Figmaプロトタイプ入門〜インタラクションイメージのつくりかた〜

  • 株式会社necco / 中川 小雪

Figmaのプロトタイプ

  • デザインを繋いで動きを確認できる
    • 画面遷移を確認できる
    • インタラクションも作れる
  • 実機でデザインを確認できる
    • URLの共有で顧客にプロトタイプを共有できる

プライベートプロダクト戦略。Webアプリを起点にしたクロスプラットフォームで大企業が真似できない価値をつくる

Web制作

  • 需要は拡大したが作りても増えている
    • ノーコードツールなども

個人プロダクト

  • アイデア勝負に出ても大企業が入ってきたら負けてしまう
    • 大企業が入ってこないようなターゲットを絞ったものがいい

技術選定

  • 1人で開発運用できること
    • 細部までこだわりすぎない
      • SaaSそのまま乗っかれるのはそのまま使う
    • web/ios/android全部作る
      • アプリストアで検索するユーザが多い
    • sshで入れる環境を持たない
      • セキュリティは妥協できない
    • 認証も外部のSaaSを使う
      • 個人情報を持つだけでリスク
    • 決済は法律が多いのでSaaSに乗っかったほうがトータル安いくらい

Bunで変わるフロントエンドの世界

  • tada

CommonJS/ESModules問題

  • CommonJSとESModulesは混在できない
  • ライブラリ開発者
    • デュアルパッケージで頑張る
    • 片方見捨てる
  • Bunならこれが解決できる

Bun

  • JavaScriptランタイム
  • TS標準サポート
  • Denoと違ってNodeとの互換重視
  • 2023/9/8に正式リリース

今後

  • ESModules前提で作られるライブラリが増えてくる
    • そうしたらBunの次のなにかがくるかも

ビジネスサイドの要望をかなえながらVue2からVue3にアップグレードした話

  • てつえもん

Vue2

  • 2023/12にVue2のサポート終了

Vue3移行

  • Laravel-mix(Webpackラップしてるようなやつ)をViteに移行
  • 技術選定
    • VeeValodateもメジャーVUP必要あり
    • Vue3対応してないライブラリどうするか(DatePickerなど)
  • Vue2を3に
    • 文法書き換え
    • ESLintとTSエラーをignore(いったんこらえてアップグレードに注力)

デザインシステムはじめの一歩

  • yuuri

デザインシステムとは

  • メリット
    • 一貫したデザインや操作性の提供
    • 再利用性の向上
  • 構成要素
  • サービスの成長に伴ってデザインシステムも変化し続ける

リッチなアニメーションを手軽に実装！ Lottieアニメーションの基本と活用事例

  • 株式会社necco / 田口 冬菜

Lottieの基本

  • アニメーションライブラリ
  • AEやFigmaで作ったアニメーションをWebやアプリに取り込める
  • キャラクターやイラストなどのリッチな動きもJSONベースのベクターなので軽量

Lottieの特徴

Lottieで使える表現

  • シンプルなアニメーション
    • 透明度、スケール、回転、位置の変化
  • 背景の透過
  • パスの編集
    • モーフィング、トリミング
  • SVGとしてできることができること

デザインシステムの技術選定・設計の勘所 2023

デザインシステムの構成技術要素

  • デザインの再現性を高め一貫した歯品体験を効率よく表現することを目的に導入される「ドキュメントやリソース群」
  • 設計思想
    • デザインデータが雑でもUI実装できる
    • 標準化にのっとる
    • 更新運用まで組み込む
    • ドキュメントサイトも一部

デザイントークン

  • Figmaで一元管理したい
    • 値と見た目をセットで管理できるのがいい

UIコンポーネント

ビルドツール

  • tsupがおすすめ
    • esbuildをラップしたもの
    • viteと同じような立ち位置?

VisualRegressionTest

  • Chromatic
    • 高い
  • reg-suit + Storycap
    • 自前で作るやつ

Lint

  • 厳しくした方がいい
    • 妥協を輸出しないように

ドキュメントサイト

  • 読まれることが大事
  • 選択肢
    • Notion
      • 実装のpreviewのせるのが大変
    • Zeroheight
      • 高い
    • 自前で構築
      • 初期コストは高いがこれが良さそうとのこと
      • 自動化など運用もしやすい
      • AstroをUbieでは使ってる
      • mdxで管理するといい

フロントエンドエンジニアも知っておきたい HTTP/3 で変わること

HTTP3

  • TCPのかわりにQUIC上で動作する
  • HTTP3になると高速な人がもっと速くなるというより通信環境が悪い人の速度が改善していく

ReactメインのチームにNext.jsを導入した道のり

  • ペンギン丸

対象プロジェクト

  • Reactで作られていた
  • Next入れてSSRしても恩恵はないタイプのプロジェクト
    • SSRせずにstaticな出力で利用するようにした
    • SSRしないならPagesRouterでもAppRouterでも変わらない

イベント設計におけるフロントエンドな考え方、その魅力

進化したWeb技術でPWAをネイティブアプリに近づける

PWAとは

  • 最新のWeb機能を使用して機能と信頼性を強化しどこでもどのデバイスでも単一のコードでインストールできる
  • 3つの柱
    • Capable/機能性
    • Reliable/信頼性
    • Installable/インストール可能

PWAチェックリスト

  • Core
    • 素早く起動し高速
    • どのブラウザでも動く
    • あらゆる画面サイズに応答
    • カスタムオフラインページの用意
    • インストール可能
  • Optimal
    • オフライン機能
    • アクセシビリティ担保
    • 検索で見つけられう
    • すべての入力タイプに対応
    • 権限リクエストのコンテキスト提供
    • 正常なコードのためのベストプラクティスに従う

PWAをネイティブアプリに近づける

Web Share API

  • SNS共有の機能を呼び出すAPI
    • OS標準のUIを表示できる

Web Share Target API

  • 他アプリからの共有を受け取るAPI
  • manifestで設定するだけで使える
  • インストールされてるときじゃないと使えない

Shortcuts API

  • ショートカットメニューを追加する
  • インストールしたアイコンを長押しするとショートカットが出る

フロントエンジニアの戦闘力をエンパワメントするheadlessCMSという選択肢

  • Takuya Takeda

WEBサイト制作の

  • HeadlessCMS
    • APIを介して利用できるコンテンツ管理システム
    • コンテンツ管理者はGUIでデータを投入する
    • そのデータをAPIを介して取得し画面を更新する

GraphQLクライアントの技術選定

GraphQL

  • APIの規格
  • GraphQLのメリット
    • 柔軟なデータフェッチ
    • 型付けされたスキーマ
    • エコシステム
    • FragmentColocation

技術選定

  • 観点 　 - FragmentColocation
    • 型の自動生成
    • キャッシュ機構
    • 学習コスト
  • 候補
    • Relay
    • ApolloClient
    • urql
    • graphql-request
  • 現状FragmentColocationへの最適化を考えるとRelayがいいとのこと

アクセシビリティを理解するとフロントエンドのテストが楽になる！

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

  • WCAG(WebContentAccessibilityGuidelines)
    • シングルA〜トリプルAの3段階基準がある

wai-aria

  • 適したHTMLを使えない場合はwai-ariaで意味を補強する
  • buttonじゃないけどクリッカブルな要素に role="button" をつけたり

roleを使ったコンポーネントのテスト

  • testing-libraryではroleを指定して要素を取得する機能がある

SupabaseとSvelteKitで作るバックエンドレスなサーバーレスWebサイト

svelte

  • write less code
  • no virtual dom
  • truly reactive

sveltkit

Supabase

  • postgreSQLをAPIで呼び出せるDBMS
  • subscriptionもできる
  • 認証認可の仕組みもある
  • SQLクエリをREST APIに変換する機能
  • ストレージ(裏側はS3)
  • サーバーレス関数
  • Firebaseと似た立ち位置？

なぜコピペで利用するコンポーネント集を採用するのか？

コンポーネント集

Unstyledコンポーネント

  • スタイルがなく機能だけを提供する
  • a11yを担保しながら作る観点もある
  • HeadlessUI,RadixPrimitives
  • MUIなどは楽だが縛りは強い、unstyledは自由だけど大変

両方いいとこ取りする

Expo RouterはExpo導入の決め手となるか

Expo使うかどうか

  • Expo使うと
    • 開発環境構築が容易
    • デプロイ配布が楽
    • Expoに含まれないネイティブ機能にアクセスできない
    • アプリサイズが増える
    • 最新のReactNativeを利用できない

Expo Router

Now and Next generation of CSS Cascading Model

CSSの詳細度

  • 詳細度負けて無理やり!importantつけることないか
  • 詳細度で頑張るにしても無理やり属性つけたりすることになっていまいち

Layer

  • 新しく増えた宣言のしかた
  • @layer xxx と定義すると何もつけてないものより優先される(詳細度で負けてても)
  • layerどうしだと宣言順
  • 外部CSSのimport時にlayer指定もできる

Scope

  • stylesheetをどこからどこまで適用するか定義できる
  • @scope (.nav-bar) {} だと .nav-bar 配下だけに適用される
  • 下限も設定できる @scope (.nav-bar) to (.sub-list) {}
  • styleタグにもscopeを書ける

LT: React Native for web導入失敗記

  • sori

LT: Figma Widgetを自作して、デザイナーとエンジニアのコラボレーション強化を図る

  • Toya Yamanishi

LT: Web フロントエンドにおける副作用との向き合い方

LT: フロントエンドエンジニアが「Webサービスアプリ化して」と言われた時にWebViewでリリースした話

  • tada

LT: 2023年のゼロランタイムCSS in JSを考える

LT: ユーザー登録とログインフォームにautocomplete属性を使いましょう

LT: Astro3.0+TranstionAPIでイケてるサイトを爆速開発していく feat. React

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

勉強会メモ

アクセシビリティカンファレンス福岡

「伝わる」を拡張するアクセシビリティ

  • 間嶋沙知さん

アクセシビリティとは

伝わるを阻む壁を知る

  • 知らないうちに壁を作ってしまうことも多い
    • 知ることで壁は減らせる
    • 想定していないところまで届いていることもある

ここから始めるアクセシビリティ

  • エンジニアだけでなく企画/設計/デザイン/制作などの役割でもできることはある
  • 色覚多様性への配慮
    • 色の見分けにくさを確認するアプリやツールなどがある
  • コントラストの確保
    • テキスト 4.5:1以上
    • 非テキスト 3:1以上
  • 見出しをつける
    • リーダーモードでも見出しとして区別してくれる
  • 非テキストコンテンツに代替テキストをつける
  • https://www.aaa11y.com/

ウェブアクセシビリティ社内教育のすゝめ 〜品質か、営業か〜

  • 柴田宏仙さん
  • 伊原力也さん

テーマ

  • 社内で広げていく人のモチベーションをどうあげていくか

品質

  • HTMLとCSSは分けて学ばせてる
    • まとめて学ぶとHTMLはCSSで装飾するためのものと思ってしまうことがある
  • 正しくないHTMLを見てもやもやする人を増やしていく

営業

  • (受託会社でa11yの案件を取るためといった前提の話)
  • 手元でひとりでやる→仕事としてチームでやる
    • 3人いるとやめにくくて継続する
    • 「やってみた」マインドで半歩ずつ前進
    • 「やってみた」を表に出すと既成事実になる

「違う人生を生きる人と一緒に働く」ということ

聴覚障害

  • パターン
    • ろう者：生まれつき聞こえない
    • 難聴者：聞こえづらい
    • 中途失聴者：聞こえていたが聞こえなくなった
  • 人によって状況はさまざま
    • 読唇できる人できない人
    • 話せる人話さない人
    • 手話が第一言語のため日本語に苦手意識のある人もいる

デジタル庁でのアクセシビリティへの取り組み ―誰一人取り残されない、人にやさしいデジタル化をの実現に向けて―

  • 伊敷政英さん

デジタル庁

  • ミッション
    • 誰ひとり取り残されない、人に優しいデジタル化を。
  • ビジョン
    • 優しいサービスのつくり手へ。
    • 大胆に革新していく行政へ。
  • バリュー
    • 一人ひとりのために
    • 常に目的を問い
    • あらゆる立場を超えて
    • 成果への挑戦を続けます

デジタル庁のアクセシビリティチーム

  • アプリやWebサイトのレビュー
  • どのタイミングでアクセシビリティテストをしたらいいかなどの助言
  • 画像のaltこれでいいかとか仕様書どう書いたらいいかなど幅広く

最近の取り組み

10/30デジタル庁のサイトをリニューアル

  • Figmaのデザインの段階でアクセシビリティチェックした
    • 何が書いてあるか上から下まで教えてもらってチェック
  • CMS実装前のHTMLでもチェック
  • カルーセルの議論
    • FVに情報掲載の依頼が多いから
    • JISの基準を満たす実装はやれるがそれで十分ではないかも
      • カルーセルをアクセシブルにするのは限界がある

マイナポータルの実証ベータ版

デジタル推進員ポータル

  • 「ご意見ボックス」の追加
  • デジタル推進員が意見などを投稿する
  • アクセシビリティチェックを実施

デジタル庁デザインシステム

  • デザインシステムを公開している
    • 毎月VUPして拡充公開している
  • デジタル庁所管システムで順次採用
  • 地方公共団体でも活用が進む
  • デザインシステムのメリット
    • 効率的にアクセシブルにできる
      • 試験をする際の効率もあがる
    • 一貫したデザインを提供できる
      • 使い方の学習コストが減る

ウェブアクセシビリティ導入ガイドブック

  • 2022/12に公開
  • 最後の更新が2023/5だったが機能(2023/11/10)更新した
  • スターターキットで導入のための参考資料

今後

「ZOZO Tech Meetup - Webフロントエンド」に参加してきました

勉強会メモ
  • ZOZO Tech Meetup - Webフロントエンドに参加してきました
  • zozoのwebフロントエンド開発の現場の声を聞けました
  • 共感できるところや詳しく聞きたくなるようなところが多くて楽しかったです
  • 特にアクセシビリティの話は具体的な苦労話などもっと聞きたいと思えました

ZOZOTOWNにCSS in JS（Emotion）を導入して1年後の状況

  • 菊地 宏之さん

導入の背景

styled.div`
    color: red;
`
  • ThemeProvider
    • 端末の判定などをする関数などを紐づけている

使い心地アンケート

  • 全体的にポジティブ
    • 導入前から後のアンケートだとまあそうなるだろうなって気がする

今後

  • CSS in JSの動向注視
    • パフォーマンスの問題(Runtime CSS in JSなので)
    • AppRouterとの相性

React でコンポーネントを利用したテストをゴリゴリ書く

  • 渋谷 拓正さん

はじめに

コンポーネントを利用したテスト

カスタムフックのテスト

ゼロから始めるアクセシビリティ啓蒙活動

  • 田嶋 幸智子さん

zozoでのアクセシビリティ

  • 個々で興味があったり改善してる人がいた
  • デザインシステムを作る動きがあるのでそこに取り込め寺いい
  • トップのaxeでのスコアはあまりよくない

改善活動

  • 取り組む意義の言語化
  • ロードマップ作成

ここまでの状況

  • はじめて1ヶ月
  • 興味のある人を集めることに成功
  • トップの修正項目のタスク化ができた

現代のReactivityとSvelteの魔法

  • 冨川 宗太郎さん

Reactivity

  • さまざまなライブラリ/FWあるがどれも「状態を画面にどう反映するか」
  • ReactならuseState/preactなどはsignalsで状態管理し更新/反映することができる
  • sveltは let count = 0 と書くだけで同じ動きを実現できる
    • トランスパイル後のコードを見るとわかりやすい

コンポーネントをまたぐ状態管理