## したこと
* CXO Night関連の自分なりのまとめをクロッキーに書いた
* Inside Frontend へ参加

## Inside Frontend のメモ
☁マークがついているところ ←聞き取れなかったり、見逃したところ
***
### freeeのアクセシビリティ、いまとこれから（セミナー: B1）
* 「できたらやること」感がつよい → 分かりみがつよい
* UX成熟度モデル → これをA11yに置き換える。

#### 最初に行ったこと
* 一人から始めるユーザーエクスペリエンス（入社前）
* 全体会議で「いかに重要で関係あるか」を伝えて知ってもらった
* JACに登壇した際、同僚の方に取材に来てもらう→社内？ブログに書いてもらう
* Workplaceにアクセシビリティグループを作って、情報を流していく
* A11y本の輪読会を会社で行う

#### ☁
* 国内約320万人、 色覚障害の方がいる
* 聴覚障害の方 → テキストコミュニケーションだと助かる人がいる
* Google HOME → 画面を見ずに操作？できることはアクセシビリティなのでは
* Google Driveで画像が文字起こしした件 → これもアクセシビリティ

#### Web サイトのチェック
W3C を使ってEasy Checksテスト（みんなで集まって）
* マークアップの問題は軽微
* 画像や動画の代替テキスト（コピペで違う画像のaltが入ってたり）
  * 空だと画像があることに気づかない
* 水色テキストのコントラスト
* フォーム系のエラー表示（伝わらない可能性がある、エラーを読み上げない）
* 空のi要素でアイコン表示

#### 中根さんにインタビュー
かなり試行錯誤しないといけない現状
* アイコンにラベルがない
* アコーディオンのボタンがdiv…
* for属性のないlabel、inputが入っていない

#### iOS版に切り替えつつ利用
* 結構読み上げてくれる
* ？ボタンとか、アイコン読み上げないから何か分からない
* 画像の代替テキストに、操作の詳細が書かれていない

#### インタビュー所感：20:80の法則ありそう
* 発生する問題のパターンが限られている
* 人はマークアップを間違えるときにパターンがある

#### Webサイトのこれから
* Easy Checksの有志和訳
* 優先課題から解決していく（アプリのヘルプなど）

#### 既存のUIを修正
* 課題をあげる
  * PRをあげてもらう
* なおすのがむずかしい

#### 向き合う
* カスタマーサポートで補えるとこがある…
* 定量化していく必要がある

#### A11yの必要性に向き合う
* 目標と成果の明示が必要そう

#### 必要とする当事者に向き合う
* 当事者の声は、数多の理由より強く響く → ユーザーテストしたい…

### freeeのアクセシビリティ、いまとこれから（AMA: C1-2）

### 「規約に同意」のUX -ストレスフリーな同意UIとその実現方法-（セミナー: B1）
#### コンプライアンスとは？（FOLIO）
* 金融機関は重りがすごい
* 懸念点→ SNSシェアボタン系をつけられない

#### 利用規約
* 全体の7%しか読んでいない → ROOM Bでは1人だけだった
* ＞＞金融商品取引法＜＜
クリエイターとコンプライアンス間で想いにギャップがある
→どちらも正しい。いかにスムーズに慎重な同意ができるか が大事
* モーダルは「負荷的に情報を提示する」認知のあるUI
  * PDFだと文字サイズが小さくなる→ユーザーが逆に警戒心を持ってしまう
  * FOLIO では PDF → HTML化
 
#### ☁
Word → Markdown → HTML
* web以外の成果物に使うことを念頭において拡張性を考えると、中間言語のMarkdownを挟む
  * PandocでざっくりとMarkdown化
  * リッチな表とかは手動で（コンプライアンスの方々と… Confluence で）
  * markdown-styles を使ってHTML化
* ConfluenceとWord、Gitの三重管理 → 一元管理したい
  * 旧原本をなくして、最新のMarkdownを原本としてWordに変換（Wordはコンプライアンスの方が外部の弁護士さんと話すときにいるのだそう）
  * GitLabをコンプライアンスの方にもハンズオンして、使ってもらう
  * GitLabに一元管理！しゅごい

#### ☁
バックグラウンド・慣習が異なる、理解し合う

#### フロントエンド
* クリエイターのコンプライアンスや法律への理解・歩み寄り必須
  * 理解がないと高いUXは無理
  * FOLIOではwebの人も証券外務員を取得している
* フロントは、デザインとシステムをつなぐハブ。できることは広がる

### freeeのアクセシビリティ、いまとこれから（AMA: C1-2）
* ユーザーに会いに行く
* 国内と国外のA11y
  * 米国が進んでる
  * 日本は努力義務、上からの圧力がないので遅れている
  * 韓国はアクセシビリティコンサルタントが多い（完全に義務にしてしまうと、決まったことだけやれば良いんでしょ的なアンチテーゼが…）
* A11y専門ではない → それ以外もやっていくことで、関われる範囲が広がる
  * A11y以外でも、期待以上のことをして説得力を
* 社内勉強会でオススメの手法（質問した！）
  * Easy Check、VoiceOverなど…やってみる、手を動かす会にする
  * 目が見えない状態での操作や、そういった動画を見て気付きを得る
  * カメラのたとえ → ここ社内へ伝えたいし、自分の言葉にしたい
* 事例を参考にする、チャンスを逃さない（周りを巻き込んでおく）
  * 自分と近いレイヤーではない人（えらい人とか）にも話す → 相手に伝わる言葉で話す
* アプリケーションでは、Googleスプレッドシートがつよい
  * そのレベルになると、A11yやってるのは当たり前すぎて、やってるって言わない
* A11yで質問があれば、A11yのSlackへ

### 攻めつづける FRESH! の Web ver.新春（セミナー: B3）
#### Payment Request APIの導入
* カード情報をFRESH!で持たないように、GMOサービスを利用
  * 購入のたびに別ドメインへ行く、テンプレ更新面倒（デザイン変更とか）という点もある
  * 決済に必要なインターフェイスをブラウザネイティブで提供
  * APIに支払い処理は行わない
  * https://developers.google.com/web/updates/2016/07/payment-request?hl=ja

#### React V15→v16
* <Fragment />の使用
  * <div>や<span>で囲まなくてよい
* return String
  * Autocannonで測定してみる
* Node.jsのStreamAPI Writable を使って非同期処理
  * 副作用：スレッドセーフ
 
#### Puppeteer
* リリース確認の流れ（web・バックエンドAPIリリースでも同じ）
  1. STG（QAとか、公開2〜3日前）
  2. Standby（リリースチェック、チェックシート）
  3. PRD（チェックシート）
  * チェックシートの項目　＞＞約150項目＜＜
  * ↑自動化　＞＞Puppeteer＜＜
* 大変なこと
  * テストを行う前の下ごしらえ（テスト実行時要件など）

#### ☁
* 隔週金曜など、長いスパンで
* 新しく得た知見をesaに

### Web パフォーマンスについて何でも訊いて下さい（AMA: C3-3）
* box-shadow・border-radiusによるパフォーマンス劣化
  * CSS…レンダリングコスト（パスの描画）
  * 組み合わせるとコスト跳ね上がる
  * 多少デザイン面で妥協 or box-shadow・border-radiusの図形を2つ重ねる
  * ↑デザイナーとコミュニケーションとっていこう
  * DevToolのぺいんとぷろばいだ
  * ぼかし部分を画像にする術もある
* 指標、目標値
  * 計測方法2つある（→CAデベロッパーブログよんで）
    * speedcurve
    * ☁
* GTMタグ → いろんなものを勝手に呼び込んじゃう
* CAさんではwebページ早くしようキャンペーンが起きてボトムアップが 

### 動的デザインガイドのつくり方（セミナー: B4）
#### Design Systemについて
* SGDD（スタイルガイド・ドリブン・デベロップメント）
* Living Design Guideline
**生きたデザインガイドの仕組みを、どうやってサービスで実現するか**
* 定義しただけでは実現しない
* 開発するために考えることがたくさん
  * デザインの整合性があっているか毎回検討？ ←これ自分的に社内問題
* デザイン（仕様や意図の明確化）→プロトタイピング→UIコンポーネント→を、自動生成してガイドラインへ
  * 技術工数の削減（低コストで実現）、再利用性の高い開発コード
  * UXの統一、再利用性の高いデザインアセット
  * **アイデアを速やかに製品に反映するプロセス**

#### 作成ポイント
1.  **実コードで使われているコンポーネント** を使うことで、生きたデザインガイドラインへ
2. ドキュメントには多レイヤーの情報を含める
  * プロジェクト全体のためになるような情報を
3. UIコンポーネント間のデータ型を明確に定義する
  * Reactとかは型ある
  * UIが受け取るデータ型を定義しておく
  * 実例：Riff、ATLASKIT 

#### Web刷新事例（どうやって既存構成のものを変えていく？）
* PHPのリファクタリング
* コード→ロジックとテンプレートに分離
* テンプレートエンジン（pug）を利用
* ↑コンポーネントごとに大きく分離
* View⇔Server間のデータ定義 （JSON-schema）

##### ワークフローの変化の周知
新しいことを導入→プロセスが変わる
デザイナー・エンジニアで協力して、一緒に考える・維持していく

##### 企画・経営陣・周囲の説得
理解してもらう（現状の問題点や、やりたい理想など、洗い出して準備する）
**＞＞誰得チートシート＜＜**
* 開発者→パフォーマンス、短期開発
* デザイナー→UXの統一性を担保、作業効率の向上
* 経営者→理解できる資料、事故や工数が減らせるよ
コンポーネントを理解してもらえるように、**練習課題**をつくる（レベル別）
↑これすごく素敵。レベル別、新規メンバーに優しい。フォローアップ。

### デザインとエンジニアリングのワークフローについて語りましょう（AMA: C4-2）
* UXデザイナーに、エンジニアが仕様の確認や質問をして、その返答やデザインの練り直しに時間をとられてしまう（本質的な仕事にかける時間がへる）話
  * 練り直しや足りないデザインパーツ等を作るのも、UXデザイナーの本質的な仕事
  * デザインレビュー時に、フロントエンドエンジニアにも見てもらう
  * デザイナー・エンジニアが歩み寄って一緒に作る・高めていくって考えにシフトしてゆきたい
* Introduction to Design System Manager

### デザインシステムとコードを密結合するワークフロー（セミナー: B5）
その前に考えることがある！
* コミュニケーションコスト
  * それぞれのステップでレビュー

## よんだ
* https://twitter.com/38_mot/status/962490899493105664
* https://twitter.com/38_mot/status/962513742297669634

## 日報の書き方
* 色んな人の日報に書いてること・書き方をもっと知って、自分の日報に反映していきたい