感想
- 自社イベントですが前職の後輩2人を招待して参加してきました
- Day2はフロントエンド、デザイン、PdMと関心の高い分野が固まってて面白い事例ばかりでした
- 同じ会社でもサービスが違うと何もかも違って新鮮
Keynote
朴イビンさん / LINEヤフー
Kwon Snowさん / LINE Plus
Chen, Hung-Chiaさん (Chen Marco) / LINE Taiwan Limited
Kasetsin, Weeraさん (Ball) / LINE Company (Thailand)
アクセシビリティ改善の実践:プロダクトにおける具体的な取り組みと課題
富田梓さん / LINEヤフー
慶島亜門さん / LINEヤフー
三好健太さん / LINEヤフー
数字が導く洞察：Webパフォーマンスとビジネス指標の相関を探る
戸成拓也さん / LINEヤフー
- Webパフォーマンス指標
- Core Web Vitals
- LCP/CLS/INP
- ビジネスメトリクス
- CVR/Bouns/Exit
- Core Web Vitals
- LCPとCVR
- LCPとCVRに相関はあるという検証結果
- LCPは2.5sが目安と言われるがもっと早くないとCVRは下がる
- サービス特性によっては相関がなかったものも
- サンプルをとるとしてもそれなりの量がないと信頼できるデータにならない
- 数十万はほしい
- LCPとCVRに相関はあるという検証結果
- LCPとBounce/Exit
- LCPが長いほど値は上がる傾向
- CVRと壮観なくても直帰離脱と相関が出るケースも有る
- CLS/INPとCVR
- LCPほど影響は見えなかった
- 計測のための環境
- Webパフォーマンスチームでライブラリを提供
- 計測/可視化の環境も提供
- datalakeにためてTrino検索できる
- Tableauでも可視化
- 改善ポイント
文字コントラストを改めて考える
中野信さん / LINEヤフー
- 色の見え方
- 病気や障害によって色の見え方が変わってくる
- 見えづらい色の組み合わせがある
- 病気や障害によって色の見え方が変わってくる
- WCAG
- 色の使い方についての規定がある
- 文字色と背景色のコントラスト比
- WCAG2.0 = JISX8341-3:2016
- 18pxなら4.5:1
- 24pxなら3:1
- 基準を満たしているかどうかと健常者が見た時の見やすさで感覚が違うこともある
- 4.5:1の基準は研究結果はあるものの今の実態に沿ってない部分も
- APCA
- Advanced Preceptual Contrast Algprithm
- WCAG3.0で検討されている
- より人の感覚に近い基準
- Lc0〜Lc100で示される
- 文字の大きさと太さで満たすべき基準が変わる
- Lookup Tableで判断
- Lc75が従来の4.5:1
- 文字の大きさと太さで満たすべき基準が変わる
- 文字サイズや太さなども考慮
- 色の組み合わせが同じでも文字と背景どちらが明るいかでも変わる
- 彩度や色相は意識されてない
- 従来の基準と逆転するパターンも出てくる
デザインの意思決定を加速するワークショップ設計
田中達也（Tatsu.） / LINEヤフー
- 会議での意思決定での課題
- 結論が出ない
- 意見が中々まとまらない
- 関係差の多さや多様性
- CSAモデル
- Clarify
- ゴールや問題を明確に
- Solutions
- 解決策を決める
- Action
- 具体的な行動
- 各フェーズで発散と収束
- Clarify
- Me - We - Us
- Me
- 個人で考える
- We
- ペアや小グループで創発
- Us
- 全体で共有
- 個から始まって対話を通して全体に広がっていく
- Me
- 納得感だけだと無難なところに落ち着いてしまう
- 背景を理解し合うことと創発することが大切
デザインから開発まで一貫したデザインシステムを構築するベストプラクティス
高橋柊蔵さん / LINEヤフー
- デザインとエンジニアリングの乖離
- 簡単に作れると思って作ったデザインが実装するのが大変だったり
- 曖昧で一貫性のない設計はAI活用でも障壁となる
- エンジニアやAIが理解しやすいデザインが必要
「LINEスタンプ」開発における、チーム全員で継続的に改善を考えるDiscovery & Deliveryの仕組み
野田純生さん / LINEヤフー
- LINEスタンプの体制
- 60人規模
- LeSS Hugeで3〜10人の開発チーム
- PdMと他メンバーとのやりとり
- ユーザの声が開発チームにとどかない
- PdMの決定待ち
- ->チームでなぜを考える体制へ
- チームでのDiscovery
- 何を作るべきかを考えるフェーズ
- ユーザリサーチ
- インタビューしたり
- テンプレート化したり
- 調査結果を振り返りや共有しやすく
- 課題解決のアイデア創出
- チームでのDelivery
- 価値をユーザに届けるために開発するフェーズ
- チームとしての共通認識を深める
- 理想の機能を詰め込みすぎないで価値検証できる最小のMVPを
- ユーザストーリーマップ
- Estimationチャート
- PdMのディシジョンツリーの公開
- PdMは正しい答えを持つ人ではなく正しい問いを設計する人へ
「Yahoo!ファイナンス」 大規模スクラム（LeSS）の運用について
小黒将也さん / LINEヤフー
平野敬祐さん / LINEヤフー
- LeSS
- なぜLeSS
- 1つのプロダクトに多くの機能が入っている
- 複数のバックログを管理するのではなく1つで管理するのがいい
- LeSSでの工夫
- 職種間の連携
- 多職種が同じチームに
- セレモニーで認識共有
- 各チームのSMと企画でスクラム推進チーム
- 各チームの意見を吸い上げ
- リリース遅延に対する取り組み
- 着手前に前提や依存を完了させたい
- Difinition of Doneの定義
- Difinition of Readyの定義
- PBIがロール別でサイロ化
- 開発や試験など工程別ではなくユーザストーリ
- 着手前に前提や依存を完了させたい
- 職種間の連携
TPMがプロダクトに参画した初期フェーズで実施した業務内容の事例紹介
高橋弘幸さん / LINEヤフー
染野大彰さん / LINEヤフー
- LYのTPMという職種
- Technical Program Manager
- 全社的な技術戦略
- クロスファンクショナルな調整
- 6つの柱
「Yahoo!フリマ」の生成AI活用：画像1枚から商品情報を生成する『らくらくAI出品』ができるまで
高西由希子さん / LINEヤフー
武内里早さん / LINEヤフー
- 出品プロセス改善での生成AI導入
- 出品での課題
- 何をどう書けばいいか
- いくらにしたらいいか
- 商品説明文の生成
- 入力した商品名やカテゴリから説明文を生成
- 生成内容がいいか悪いかフィードバックを集める
- ユーザ価値よりも技術手動の側面が強かった
- 導入した経験は次に活きた
- 画像による商品名の生成
- ユーザ価値を考えてMVPを設定
- 撮影した商品の写真から商品名をサジェスト
- 提案したワードの採用率で効果を検証
- これまでの説明文生成とABテスト
- 写真からの生成の方が採用率高い
- 画像から全ての商品情報を生成
- 撮影した商品の写真から全ての情報を生成
- ユーザー価値と技術のバランス
- 検証という目的を持って
- 技術主導からユーザ価値主導へのシフト
- インジェクション対策
- 画像はテキストより情報量が多い
- 危険な画像で事前検査
- インプットの項目を絞る
- 試行回数の制限
- 該当機能をいつでも止められる仕組み
- できれば代替機能も
「Yahoo!ファイナンス」の生成AI活用事例と得られたTipsの共有
関根修斗さん / LINEヤフー
真瀬凱さん / LINEヤフー
- ChatGPT
- プロンプトはmdがいい
- コンテキストウィンドウ128 token
- Claude
- プロンプトはxmlがいい
- コンテキストウィンドウ200 token
- Gemini
- コンテキストウィンドウ1M token
- 選定
- 相性の良いプロントの形式で使えるか
- トークンはどれくらい必要化
- 利用技術との相性
- 製品へのAI導入
- セキュリティチェックなどは時間を費やした
- 社外接続による考慮
- ヤフーファイナンスの掲示板での事例
- 多くのコメントがやりとりされている
- 議論を生成AIで要約
- ユーザ投稿がインプットなので事前に検査
- リスクのあるコメントはインプットに入れない
- 出力のハルシネーションチェックのプロンプトを別で噛ませる
- 特に数字周りでミスがあると影響が大きい
- 決算短信を読むのは初心者には大変
- 生成AIで要約を提供
- 掲出から生成までのリードタイムを減らしたい
- 入力データ量を小さくする
- token数を計算して効率的に並列で
- 多くのコメントがやりとりされている
生成AIを活用した「Yahoo!ニュース」のコメント要約機能：生成AI利用事例のご紹介
青木祥郁さん / LINEヤフー
- ヤフーニュースのコメント要約
- 見出しと要約とキーワード
- プロトタイプの生成
- 最初はChrome拡張を作ってどのように生成されるか検証
- プロンプトの調整
- 要約は本文を読みたくなるような内容を目指した
- 要約だけで終わらないように
- 要約は2点で別の観点になるように調整
- 具体例を出して想定から逸脱しないように
- プロンプトを3つに分ける
- キーワード抽出
- 要約
- 整形
- 要約は本文を読みたくなるような内容を目指した
- リスクへの対処
- 100件以上のコメントがついた記事のみ対象
- おすすめ順の性能がいいのでその上位10件を使う
- リリースなしで緊急停止できる仕組み
- 入出力のチェック
- AIでの判定と人による判定
- 100件以上のコメントがついた記事のみ対象
