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 と書くだけで同じ動きを実現できる
    • トランスパイル後のコードを見るとわかりやすい

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

「Vue Fes Japan 2023」に参加してきました

勉強会メモ

Vue Fes Japan 2023

キーノート

  • Evan you

Rolldown

  • まだearly WIP
  • esbuild代替?
  • Rust?
  • Rspackの人が開発
  • ビルドツール?バンドラー?

社内UIコンポーネントライブラリがエンジニアチームにもたらした本当の価値

chromatic

画面遷移から考えるNuxtアプリケーションをアクセシブルにする方法

A11y

  • Webはそもそもアクセシビル
  • 改正障害者差別解消法
    • 2024/4から障害を持つ人に対する合理的配慮が民間も義務化される
  • VueやNuxtで作られたアプリはアクセシブルになっているだろうか
    • 調査の結果は改善してるが良くない

クライアントサイドルーティングという手法について

  • 通常はサーバでHTML作って返すが、クライアント側でHMTL作って遷移する
  • ViewTransitionsAPI
    • アニメーションつきで遷移できる
    • Nuxtは現在experimentral/対応するブラウザでしか動かない

画面遷移のアクセシビリティの問題点

①何が変化したか支援技術に伝わらない

  • 資格では変化がわかっても支援技術には伝わらないことも
  • wai-ariaのライブリージョンを使う
    • titleの変更を通知する
    • aria-live="assertive" をつけた要素のテキストを変えると読み上げられる
    • 支援技術向けの要素は非表示にするが display: none は駄目

②フォーカスマネジメント

  • ページ遷移したときにフォーカス位置が遷移前の場所になってしまう
  • ページ遷移時にフォーカスしてほしい位置に当たるように制御する
    • 必要に応じて tabIndex="-1" をつける
  • どこにフォーカスを当てるか
    • コンテンツが多い要素にあててしまうと全部読み上げられてしまう(NVDA)
    • 見出し要素に当てるのがいい
    • 見出しがないならスキップリンクへ移動しタイトルを読み上げるといい
    • 上部から始まるようにしておくとよい

③過渡なアニメーションで閲覧阻害

  • アニメーションが原因で体調不良を起こす人もいる
  • 視差効果を切る設定がありその設定による制御ができる
    • prefers-reduced-motion
    • 設定されてたらアニメーションを起こさないといった処理を入れると良い
    • CSSでもmediaクエリで指定できる

画面遷移をWebAPIで解決

  • HistoryAPI
    • 課題はいろいろある
    • vue routerなど使う必要ある
  • NavigationAPI
    • 画面遷移の視点終点とれる
    • スクロール位置やフォーカス位置の復元もできる

Nuxtのa11y

  • ロードマップにa11yが含まれている
    • axe core入れるとか

Nuxt 3でJamstackテンプレートを作るときの考え方

  • まぁし(TAM)

Jamstack

  • JavaScript/API/Markup
  • フロントエンドとデータを分離できる

2023年のJamstack

  • フロントエンドとバックエンドを分離してマイクロサービスを組み合わせて構築していくことそのものを呼ぶようになっている
    • NextやNuxtをVercelやNetlifyでSSRするようなこと

ディレクトリルール

Vue Language Serverから生まれたVolar.jsと、それが秘める可能性

エディタの言語機能

  • 言語機能
    • コード補完
    • リネーム
    • 検索
    • アウトライン
  • Languahe Server Protcol

VueにおけるLanguage Server

  • VueはSFCが独自のフォーマット
    • Vue独自のLanguage Serverがある
    • 今はVue Language Features(Volar)
    • 昔はVeture
  • SFCはvueファイルの中にHTML/JS/CSSがかける
    • 3言語分の機能提供が必要
    • Embedded Language
  • 組み込み言語のLanguage Server
    • ファイルをブロックに分けて仮想的なファイルがあるとみなす
    • 書く言語向けのServiceで処理する
  • templateの中にJSを埋め込める
    • templateの中にもJSの仮想ファイルが含まれている
    • scriptで定義下変数をtemplate内の埋め込みで補完しないと

Volar.js

  • 組み込み言語のツールを作れる
    • Astroやsvelteなども困っている
    • FW固有の最小限のコードを書くだけでLanguage Serverを作れる
    • Language Server以外にもチェッカー(lint的な)なども作れる

「DIST.31 「DIST 6周年記念イベント」」に参加してきました

勉強会メモ
  • DIST.31 「DIST 6周年記念イベント」に参加してきました。

dist.connpass.com

タイトル 発表者
[IDEA]描きながら学ぶかんたんイラスト講座！＋グラレコの仕事がもらえるようになるためにやったこと 湊川 あい
[IDEA]次代のビジュアルブランディングの鍵 柳 太漢
[DESIGN]なぜダメなデザインが生まれるのか 長谷川 恭久
[DESIGN]SPA/PWA時代のWebデザインのお作法 谷 拓樹
[TECHNOLOGY]フロントエンドの技術選定 西畑 一馬
[TECHNOLOGY]品質の岐路に立ったときの実装術 池田 亮
[SOCIAL]特化するということ 中村 享介
[SOCIAL]Web Creation in Society 伊藤 由暁

描きながら学ぶかんたんイラスト講座！＋グラレコの仕事がもらえるようになるためにやったこと

絵にすると何が良いの

  • 脳は文字より画像を好む
    • 五感が知覚しているうち視覚が83%

絵は誰でも書ける

  • 目と口を5種類ずつ用意したらそれだけで25の表情ができる
    • 同じようなものを書いても必ず個性がでてくる

図解の基本形

  • 対比、内包、因果などいろいろ表現できる
  • 図解+感情
    • 図に加えて、だからどうなのかというのを伝えられるとよい

読む人を「楽しませる」

  • 楽しげなものは注目してもらえる
    • 注目した結果。理解が深まる

次代のビジュアルブランディングの鍵

ブランディング

  • 企業が提供する全ての体験を定義設計し個性を作る
  • ブランディングの鍵
    • Story
    • System
    • Science

Story

  • ストーリーがあることで価値をうむ
  • 単に見た目や味だけでは価値は決まらない
    • 背景があることで価値は変動する

System

  • いろんなふれかたがある
  • 点ではなく線面で伝える

Science

  • 情報の触れ方が変わっている
  • 見た目だけでなく五感を刺激する

どのようにビジュアルブランディングするか

  • ビジネスとビジュアルデザインは分けて考えない
    • ビジュアルデザインは古来からある伝えるためのインターフェース
    • リテラルからビジュアルへ
    • ビジュアルデザインは伝えるための重要な道具
  • 流行ってるものに乗っかるとそれは廃れる
    • 長くコミュニケーションをしていく器にする
  • 考えて言語化していくべきこと
    • 顧客に支持される理由
    • これまでの歴史
    • これから目指す未来
  • あとはセンスを爆発させてデザインするだけ
    • ストーリーができたらほとんど勝ったようなもの
  • ブランディングの価値や意図を理解できていると正しく使える

なぜダメなデザインが生まれるのか

注目してもらうためのテクニック

  • 人の集中力は長く持たない
    • 目に入ってもすぐ次のなにかにうつってしまう

情報をわざと見えにくくする

  • unsubscribeを見えにくくしたり
  • 会員登録しなくても使えるのに登録フォームをだしたり

ベストプラクティスを逆手に取る

  • YesとNoのボタンで
    • Noの色をプライマリーカラーにしたり
    • Yesをレッドにしたり

罪悪感を促す

  • Noのボタンを罪悪感ある文言にしたり

偽ｘを設置する

  • 閉じるのxボタンをおいてタップさせる
    • コンバージョン稼ぎ
  • 偽の髪の毛を画像に入れて払わせる

なぜこんなことをやるか

  • いろんな事情がある
    • 食べていくためしかたない
    • 他がやっているからしかたない
  • スキルを持っているとデザインで騙すことができてしまう
    • デザインでどうやって課題解決するのがよいか立ち向かっていかないといけない
    • 上の例のようなデザインにならないようにしていかないといけない

我々に何ができるか

  • PV数
    • 単純に数値が増えればいいだけなのか？
    • 閲覧したからといって読んでるかわからない
    • それによってユーザは満足しているのか？
  • エンゲージメントの定義が変化している
    • ユーザが有益な時間を過ごせてるかどうかを考える
    • インスタではもう閲覧済みのものを知らせくれる
      • 単純にPV数だけを追い求めない
  • 良い見た目 + 課題解決へのコミット

SPA/PWA時代のWebデザインのお作法

  • 谷拓樹さん(サーバーエージェント)

Webとアプリ

  • Webがアプリと比べても遜色なくなってきてる
    • そんな中でどうやってWebをデザインしていくか

PWA

  • Progressive Web Apps
    • オフライン
    • プッシュ通知
    • 独立したUI
    • リンク可能
    • 発見性
    • インストール不要
  • Webの特性とアプリの特性を兼ね備える

SPA

  • 非SPA
    • リンクをクリックするとサーバからHTMLを受け取って表示する
    • サーバサイドレンダリング
  • SPA
    • データだけ取得して画面を書き換える
    • ヘッダーなどを継続して表示し続けられる
    • クライアントサイドレンダリング

状態を持つWeb

  • Design for "Stateful" Web
    • 状態を持つWebをデザインする
    • UIデザインにおいても状態を持つことを意識する必要がある
  • 考えるべきページの状態
    • https://yasuhisa.com/could/article/ui-design-bugs/
    • Blank State(空白)
      • 非同期でデータを取得して0件だったら？
    • Loading State(読み込み)
      • 画面全体だけでなく部分的なローディングも考慮が必要
    • Partial State(部分的)
      • データが部分的に取れているときの状態
    • Error State(エラー)
      • 部分的なエラーも考慮が必要
    • Ideal State(理想)
      • 理想のデータが入った状態
    • この5個だけでなく例外もある

読み込み

  • ローディングをデザインする
    • => ユーザにどう待ってもらうかをうデザインする
  • ユーザは待ってくれない
    • どういったデザインで待ってもらうか
      • ローディング中はオーバーレイする
      • 情報を取得中ですと出す
      • ローディングのぐるぐるのUIを工夫する
  • 旧にオフラインになる体験
    • ブラウザのエラー画面を出したくない
    • ネットワークが切れたらオフラインであることを通知してあげるとか
  • オフライン以外にもいろいろある
    • 低速な環境
    • 速度制限がかかった状態
    • データセーブをオンにしている

フロントエンドの技術選定

  • 西畑一馬さん(to-R)

プロジェクトの周期

  • イニシャル開発 - リリース - 運用フェーズ
  • イニシャル開発
    • リリース日が決まってることも
    • 何が何でもその日にリリース
    • リリースというゴールがある
  • 運用フェーズ
    • イニシャル開発と比べると期限がゆるいケースが多い
    • アジャイル的に
    • 目標はあってもゴールはない
      • 走り続けないといけない

人員の周期

  • 約1~2年くらい
  • なぜ辞めていくか
    • 少しずつ破綻していくシステムにストレス
    • スキルや温度感の差にストレス
    • ビジネスサイドとの確執
    • 飽きた
    • 新しいことがしたい
  • 新メンバーの苦悩
    • ビジネスドメインの理解
    • 既存システムの不満
  • プロジェクトは人に依存するが人は流動的

技術選定

  • SPAで作る必要があるか
    • 静的サイト
    • サーバサイドシステム
    • CMS
    • SPA
  • Developer Experiment
    • 作る人が作りやすいもので作らせる
    • DXが高ければ定着しやすい
    • 採用する人員に高いスキルが求められることにもなりかねない
  • 技術選定はイニシャル開発の前だが長いのは運用フェーズ
    • イニシャルのメンバーに依存した技術選定はよくない

品質の岐路に立ったときの実装術

  • 池田亮さん

fps

  • fps(フレームレート)
    • 1秒間に処理されるフレームの数
    • Webブラウザにおけるfpsは60
    • 50以下の場合ブラウザに無理させてるかも
    • マシンスペックにも依存するから注意
  • stats.jsで可視化できる

負荷対策

リアルタイムぼかしをやめる

  • 雰囲気を出しやすいが高負荷
    • 毎フレーム処理をしないといけない
  • ぼかした画像を用意してクロスフェードして対応

大きすぎるテクスチャを使わない

  • 大きい画像は処理するデータ量も多い
  • 同じ画像でも小さく表示するものは小さい画像を使う

素材は使い回す

  • 素材がたくさんあればデータ量も多い
  • 同じ見た目のものなら使い回すようにする
    • three.jsの場合、geometory/materialを必要なパターン用意して使い回す

リアル表現をしない

  • リアルな見た目を追い求めすぎない
    • たとえば球体を正確な球に近づけるほど負荷が高い

fpsを下げる

  • 擬似的にfpsをコントロールすることができる
  • three.jsの場合、renderするところで制御できる
  • アニメーションのスピードが速いところは違和感出るからどこを下げるか工夫はいる

画質を落とす

  • 画質が高いほど負荷が高い

要素情報の取得は効率よく

  • スクロール連動アニメーション
    • いろいろあるけどブラウザごとの対応がまちまちなものも
  • ウィンドウのリサイズ時に位置などとりたい
    • 負荷が高いから毎フレームはできない
    • 30fps下げて2フレームごとに取得するとか
    • 正しい値が取得できたら取るのをやめるとか
    • 正確性と負荷のバランスを見極める

まとめ

  • リアル表現をしない
  • それっぽく見せる工夫をした表現

特化するということ

特化って何？

  • 特定の部分に重点を置くこと
  • 業務内容を限定して専門化すること
  • 狭い範囲を扱う職業の方が特化する

特化する理由

  • 集中できる
    • 特化するとその仕事を繰り返す
    • ノウハウが溜まって詳しくなる
  • ブランディング
    • 何ができるのかわかりやすい
    • プロフェッショナルにみえる

何に特化するのか

  • 特化するものを間違うと大変
  • 何に特化するか
    • 得意なもの
    • 需要があるもの
    • 自分がいいと思ってるもの
  • やらないことを決めておく

特化したものを変えていく

  • 変えるのは簡単
    • 自分で決めれば変えられる
  • あるタイミングで特化していて時間の経過とともに普通になってくることも
    • 10年前ならJavaScript専門の会社なんて全然なかった
    • 今はたくさんあるのでJamstack専門の会社に変えた

まとめ

  • 全部を取得するのは難しいから特化したところのスキルを伸ばす
  • 特化した人が集まるとすごいものが作れる

Web Creation in Society

Web制作はなんのためにやってるか？

  • 生活のため
  • 自己表現のため

Webサイトは誰が使ってる？

  • ユーザはさまざまな属性をもつ
    • 個性
    • デバイス
    • 閲覧環境
    • 一時的な制限
  • 何かを制限してしまっているかもしれない
    • 性別が「男」「女」しかない
    • マウスホバーでしか開けないドロップダウン
    • 色だけに除法をもたせたデザイン
    • などなど

社会におけるWeb制作において必要なこと

  • ユーザが自由に利用できるようにする
  • ユーザが望む形で利用できるようにする
  • いろんな人にやさしいサイトはいろんな人が使いやすいサイト

まとめ

  • Webサイトはユーザのために作る
  • ユーザは多様である
  • ユーザが自由に利用できるようにする

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

勉強会メモ

event.shoeisha.jp

タイムテーブル

10:00～10:45

タイトル 発表者
チーム・ジャーニー 〜逆境を越える変化に強いチームをつくりあげるまで〜 市谷 聡啓[DevLOVE]
「ともにつくる」を実践するドメイン駆動設計 成瀬 允宣[GMOインターネット]
レガシーコードからの脱却 吉羽 龍太郎[アトラクタ]
エンジニアよ、今こそ社会課題に立ち向かおう！ 関 治之[Code for Japan]
AWS障害で考えさせられた、アプリケーションインフラ構成の注意ポイント 城 航太[サーバーワークス]
佐藤 豊[サーバーワークス]
組織の創造性を高めるために必要なこと 伊藤 直樹[PARTY]

11:05～11:50

タイトル 発表者
新しいHTML<portal>を利用した画面遷移設計 〜PayPayモールとYahoo!ニュースの事例を添えて〜 萩野 誠一[ヤフー]
関 真由美[ヤフー]
守りのモニタリングから攻めのモニタリングへ 大谷 和紀[New Relic]
開発に集中するためのJava on Serverless 下川 賢介[アマゾン ウェブ サービス ジャパン]
エンプラアジャイル導入の守破離 小俣 剛貴[Pivotalジャパン]
安西 結[Pivotalジャパン]
プリンシプル・オブ・"ともにつくる"～ Web Performerを支えるドクトリン ～ 上田 勲[キヤノンITソリューションズ]
職種の垣根を越えるコミュニケーションのススメ 池村 和剛[ゆめみ]
吉田 理穂[ゆめみ]
小川 段[ゆめみ]
戸田 修輔[ゆめみ]

12:10〜12:40

タイトル 発表者
A retro on agile ー アジャイルをふりかえる Jason Wong[Atlassian]
K8S使ってますか？リテールテック（小売・決済等）でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ！ 程 建強[Rancher Labs]
山澤 一仁[スーパーソフトウエア]
井川 知幸[カゴヤ・ジャパン]
Python基礎試験とデータ分析の例題解説～稟議に使えるPython市場データと試験も紹介～ 吉政 忠志[Pythonエンジニア育成推進協会]
寺田 学[Pythonエンジニア育成推進協会]
全アプリ開発者に伝えたい、レガシーコードから脱却するための具体的な手法、"ルール駆動開発" 松田 絵里奈[レッドハット]
自己組織的な開発チームを如何にして作り上げるか 木利 友一[TIS]
アジャイルのプロセスとデザイナーの変化-開発チームに欠かせないデザイナーになるために- 樋田 勇也[サイボウズ]

13:05～13:50

タイトル 発表者
問題から目を背けず取り組んでいく ･･･ 一休のこれまで 伊藤 直也[一休]
プロダクトを10年運用するチームをつくる 粕谷 大輔 [はてな]
エッジコンピューティング、エッジAIの可能性 中村 晃一[Idein]
日本にJoy,Incを創る！どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡 安田 忠弘[クリエーションライン]
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう！ ～ベトナムのメンバーとともにつくる～ 藤村 新[クラスメソッド]
デザイナー/リサーチャー/エンジニアが語る、UXとの関わりかた 松薗 美帆[メルペイ]
山本 興一[スマートニュース]
重田 桂誓[クックパッド]

14:10～14:55

タイトル 発表者
事業グロースを加速させる「分析基盤」の作り方【JapanTaxi/ホワイトプラス事例】
1ヶ月でデータ基盤を整え経営の解像度を変えた話 		森谷 光雄[ホワイトプラス]
伊田 正寿[JapanTaxi]
小林 寛和[primeNumber]
グランブルーファンタジーを支えるサーバーサイドの技術 小松 美穂[Cygames]
大橋 庸[Cygames]
クラウド・ネイティブ時代に最適なJavaベースのマイクロサービス・フレームワーク ～ Helidonの実力を見極めろ！ 古手川 忠久[日本オラクル]
マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと 鈴木 孝彰[NGINX (Part of F5)]
AI3分クッキング グティエレス パウロ[Databricks Japan]
テクノロジーとクリエイティブがコマース体験を変革する 河野 貴伸[フラクタ]

15:15～16:00

タイトル 発表者
世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた 鈴木 雄介[アイムデジタルラボ]
河村 明彦[アイムデジタルラボ]
サービスメッシュは本当に必要なのか、何を解決するのか Yasuhiro Tori Hara[Amazon Web Services Japan]
オープンソースのこれまでとこれから 川口 耕介[Launchable]
メルペイリリースとその後一年間の裏側と学び 木村 秀夫[メルペイ]
生涯イチ・エンジニアとして好きな技術でジャンプアップし続けよう - 夢のつづきはビッグデータで 中川 伸一[JX通信社]
クリエイティブとブランディングの関係 山口 義宏[インサイトフォース]
枌谷 力[ベイジ]

16:20～17:05

タイトル 発表者
TOYOTA x Serverless x Microservices 〜 グローバル展開のコネクティッドカーを支えるアーキテクチャとエンジニアリングチーム 浦山 雄也[トヨタ自動車]
松本 崇之[トヨタコネクティッド]
内海 英一郎[アマゾン ウェブ サービス ジャパン]
エッジコンピューティングの時代にサーバーはどこにいくのか、自社製品をハッキングしてもらった話 及川 信一郎[日本ヒューレット・パッカード]
Hackが好きなエンジニアが組織をHackしてみる考えと実践を経てきたヒストリー 萩原 北斗[うるる]
イケてるコードが書けるITコンサル最強説。 知る人ぞ知るエンジニアの楽園。 真野 隼記[フューチャー]
澁川 喜規[フューチャー]
塚本 祥太[フューチャー]
月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？ 仲井 裕紀[FROSK]

17:25～18:45

タイトル 発表者
キャリアトランスフォーメーションをみんなで考えよう～開発者から事業責任者、役員へのキャリアパスはどうよ～
エンジニアの事業継承
自分のハンドルは自分で握れ
偶然の出来事の流れに身を任せエンジニアからマネジメントの道に進んだ話。 		【司会】岩切 晃子[翔泳社]
石井 智康[石井食品]
市谷 聡啓[ギルドワークス/エナジャイル]
黒田 樹[リクルートテクノロジーズ]
雲の中心で愛を叫ぶ！ クラウド横断パネルディスカッション 濱田 孝治[クラスメソッド]
松村 優大[オルターブース]
高野 遼[クラウドエース]
【司会】近藤 佑子[翔泳社]
IT業界で誰もが輝くために：ダイバーシティを考える
技術書におけるジェンダーと 「わからない」を掘り下げる価値
女性向けテックコミュニティが必要な理由とポイント 		川口 耕介[Launchable]
職業「戸倉彩」/湊川 あい[湊川プロジェクト]
今ものづくりは非エンジニアが面白い！～IoTLT・ProtoOut StudioスピンオフLT 【司会】菅原 のびすけ/土井 勝之[千葉厚生会]
三木 啓司/小池 誠[小池農園]
ななみん/農上 裕子/土田 哲哉[Surface&Architecture]
家族型ロボット「LOVOT」から考えるテクノロジーの裏側とその未来 林 要[GROOVE X]

エンジニアよ、今こそ社会課題に立ち向かおう！

  • 関 治之さん[Code for Japan]

Code for Japan

  • 「ともに考え、ともにつくる」
  • 行政と市民がともに考える
  • Civic Tech

社会課題とテクノロジー

  • 社会課題の解決にはテクノロジーが必要
  • 社会課題解決に対する投資が増えてきている
    • SDGs
    • 社会課題を悪化させるような取り組みには投資がされないようになってきてる
  • Society5.0
    • 政府が掲げている取り組み
    • テクノロジーが必須となるものばかり
    • どっかの大きい企業がやってるんでしょ、ではなく多くのデベロッパーが関わるべき
    • 「正しいものを、正しくつくる」を行政もやるべき

伽藍 vs バザール

  • 伽藍
    • 緻密な計画
    • 中央集権
    • 長いリリース期間
  • バザール
    • 変更を受け入れる
    • 自律的な小さい集団
    • 早めに細かくリリース
  • 市区町村などのシステムは伽藍でそれぞれisolate
    • 行政の仕組みもバザールモデルの形にできるんじゃないか
    • 市区町村同士も連携していけるのでは
    • 市民の意見を取り入れていけるのでは

新しいHTML<portal>を利用した画面遷移設計 〜PayPayモールとYahoo!ニュースの事例を添えて〜

  • 萩野 誠一さん[ヤフー]
  • 関 真由美さん[ヤフー]

Portalsとは

  • ページの体感速度が速い方がよい
  • アプリのような遷移体験をWebでも実現できる

の特徴

<a> <iframe> <portal>
ページ遷移 ○ x ○
ページを表示 x ○ ○

導入事例

  • PayPayモール
    • 検索ページから商品ページへの遷移にPortalsを使用
    • List to Detail
  • Yahooニュース
    • 記事から記事への遷移にPortalsを使用
    • Detail to Detail

Portalsのデザイン

  • ページのつながりをシームレスにできる
  • Portalsを使えば音声の再生を継続したままページ遷移できる
    • iframeではできない
  • アプリの設計に似ている
  • SPAでなくMPAであってもリッチな体験を提供できる
  • 意識しておくといいところ
    • プログレッシブエンハンスメント
    • グレースフルデグラデーション
    • 非対応のブラウザを使ってる人にどう見せるかの考慮も必要

Portalsの実装例

  • JSでPortalタグを埋め込む
    • 非対応ブラウザのための分岐も入れておく
  • アニメーションで全画面化する(この時点ではページ遷移してない)
  • .activate()を実行するとでページ遷移する
    • 遷移が完了するとportalactivateイベントが発火する
  • portalタグに対して引数も渡すことができる
    • event.dataで受け取れる
  • event.adoptPredeccessor().activate()で自分が埋め込まれていたもとのページに戻ることができる
  • window.portalHost.postMessage(...)でportalとして埋め込まれたページから埋め込んでいるページにメッセージを送れる
    • portal内のページのロードが完了してから表示するといった感じで使うといい

Portalsの良い点/悪い点

  • 良い点
    • MPAでもシームレスな画面遷移が実現できる
  • 悪い点
    • 対応ブラウザがまだChrome(Canaryでフラグを立てると有効)のみ
    • インプレッションが埋め込まれたportalが表示した時点でカウントされてしまうのでの計測の仕方に工夫が必要そう

エッジコンピューティング、エッジAIの可能性

  • 中村 晃一さん[Idein]

Idein

  • 機械学習技術 -> 高い壁 -> プロダクト化/ビジネス化 -> 高い壁 -> ビジネスのスケール
  • 高い壁を取り除く会社

エッジコンピューティング

  • クラウドコンピューティング
    • データがデータセンターに集約されて処理される
  • エッジコンピューティング
    • 末端のデバイス状や近くに設置したサーバで計算をする
    • 複数の階層で分散して処理する
    • デバイスだけで計算してしまうものや、エッジデータセンターをはさむものなどいろいろ

エッジコンピューティングがなぜ注目されてる？

  • データセンター・回線のキャパオーバー
  • プライバシーへの関心の高まり
  • 超低遅延化の需要増加

データセンター・回線のキャパオーバー

  • コネクテッドデバイスの急増
    • 今後も増える傾向
  • 計算負荷・データ量の大きいアプリの需要増加
    • 画像を扱うなど
    • DeepLearning
  • 必要最小限のメタ情報だけ送信することで通信コスト削減

プライバシーへの関心の高まり

  • GDPR
  • GAFAなどに個人情報全部吸い上げられるとかならないように
  • 必要最小限のメタ情報だけをクラウドに

超低遅延化の需要増加

  • リアルタイム性が求められる
    • 自動車、ロボット、ドローンなど
  • 5G
    • 無線の区間のスピードがめちゃくちゃ速くなる
    • その先の有線の区間は遅い
      • 5Gを活かし切るにはデータセンターまでつなげない

ソフトウェア産業

  • インターネットエコシステムが物理的なところまで拡大していく
    • 小売、製造業、物流、医療
    • 複雑化する計算機システムをうまく扱う技術やプロダクトが登場する
  • 既存産業から見ると危機的状況と言えるかもしれない
    • ハード -> ソフト・サービス・データ
    • 組み込み -> 配信
    • 売り切り -> サブスク

Actcast

  • Ideinの提供するサービス
  • SDK
    • 安価なデバイスで高速に動くエッジAIアプリを開発できる
  • Dashboard
    • 多数のデバイスからなるシステムの運用に必要なものを備える
  • Marketplace

SDK

  • SDKかませることでどんなデバイスでも動くものを出力できるようにしている
  • 要件が定義できない領域が多い
    • PoCは安価なデバイスでその後はフィットしたデバイスで
    • そういうことをやろうとしたときにソフトウェアが変わってしまうと大変だから

Dashboard

  • Web上から別のモデルをデプロイしたりとか
  • APIでたたけるようにしたりとか

Marketplace

  • SDKとDashboardは無償でStoreの手数料で売上をあげてる
  • デバイスに遠隔インストールできる
  • サブスクなのでとりあえずあり物で動かして、その後遠隔で差し替えるとかがやれる

ユースケース

  • セキュリティ
  • 製造業IoT
  • 小売・決済等- スマート氏r費
  • デジタルサイネージ
  • 受付システム
  • インフラ監視

テクノロジーとクリエイティブがコマース体験を変革する

  • 河野 貴伸さん[フラクタ]

Eコマース

  • 制約が多い？
  • O2O,OMOが求められるのであればクリエイティブもオンラインオフラインの結合が求められる
    • O2O・・・Online to Offline
    • OMO・・・Online Merges Offline
  • 実際に体験してもらう
    • これらをどう低コストにしていくか
  • Eコマース -> コマース
    • リアルとデジタル(OfflineとOnline)の境目がなくなってきてる

デザイナーとデータサイエンティストの共創

  • データを持ってるのでそれを活用していく
    • 1st Partyなデータを持っているのが強い
  • データをクリエイティブに活かす
    • クリエイティブに説得力を持たせる

クリエイティブリバランス

  • ECは作るものが多い
  • どこに力を入れてどこの力を抜くか
    • テンプレートを使えるものはそれを活用していく
  • 商品の360度プレビュー
  • ARで配置してサイズ感を確認

シンボリックエクスペリエンス

  • 視覚だけでなく音や匂いや手触りなども含む
  • Slackの通知の音をきいたらSlackだなってすぐに思える
  • 音なども含んだブランド設計

これからのコマース

  • 日本だけではジリ貧
  • 世界に目を向けないといけない
  • 日本のものを世界に売っていく力が足りていない
  • デザイナーやエンジニアが持っている知見を投入していくことが必要

サービスメッシュは本当に必要なのか、何を解決するのか

アプリの成長

  • 最初は小さなアプリ
  • 成長するにつれて大きくなる
    • うまく動かないところも出てくる
    • 障害が起きると夜中に叩き起こされる人もでてくる
  • ある日マイクロサービス化しよう、と言い出したとき既存アプリはモノリスとなる

モノリスとマイクロサービス

  • Monolithという呼称に込められるニュアンス
    • 関係者調整にオーバーヘッドがある
    • 変更による影響範囲が広い
    • モジュール構造維持が難しい
    • スケーリングが効率的にできない
    • テスト・ビルドに要する時間が長い
  • マイクロサービスに期待される効果
    • 変更による影響範囲の局所化
    • モジュール協会の維持しやすさ
    • 独立したデプロイとスケーリング
    • 自律的なチームによる開発・運用
    • Polyglot(-able)

モノリスの考察

  • 現実世界のモノリスは複雑
    • ALB - EC2 - Aurora だけならシンプル
      • EC2を冗長化したり
      • バッチ処理があったり
      • Redis使ったり
      • S3にファイル置いたり
      • トレーシングのための処理も組み込まないと追跡できない

マイクロサービスの考察

  • マイクロサービスの課題
    • サービス分割の適切な粒度が分からない(正解がない)
    • 依存物との連携を考えるとテストが難しい
    • 影響範囲を自サービス内に収めるのが難しい(使ってる人が使い続けられる状態での改修)
    • サービス間通信の信頼性(Reliability)
      • ネットワークを経由して連携するということは失敗することは考えないといけない
    • サービス間通信の可観測性(Observability)
      • 各サービスでログがはかれるのでシステム全体として何が起きているか把握しづらい

サービス間通信の信頼性(Reliability)

  • ネットワーク経由で通信 = 失敗が前提
    • => 各サービスで防御的実装が必要
信頼性を高める防御的実装
  • 呼び出し先の場所は一定ではないのでダイナミックに場所を特定できるようにしたい
    • サービスディスカバリ
  • 呼び出し先の都合によって一時的な失敗も起きる
    • リトライ
  • 障害などで継続した呼び出しの失敗が起きていたらアクセスしないようにしたい
    • サーキットブレーカー
  • SLOを守るために呼び出し先サービスのパフォーマンスが悪ければ接続を切りたい
  • 呼び出し元システムの不具合で失敗するアクセスばかり受けることを防ぎたい

サービス間通信の可観測性(Observability)

  • マイクロサービス群は外から見ると1つのシステム
    • どこでなぜ失敗したか追えるようにしておかないといけない
可観測性を高める実装
  • ログ/メトリクス/トレース情報の出力
    • 各サービスで出力フォーマットが不揃いだとコンテキストが見えない
    • => 全サービスの出力フォーマットを統一したい
    • => 考え方もスキルもフレームワークも違うので難しいし変更コストも高い
  • 共通ライブラリを作ってとりこんでもらう？
    • アプリに手を入れないといけない
    • 共通ライブラリのせいでパフォーマンス劣化
    • 言語やフレームワークのバージョンに広く対応する？
    • 共通ライブラリのメンテ側も大変
  • マイクロサービス化して疎結合な実装で自律的なチームで開発したかった
    • 共通ライブラリを作ると結局密結合になってしまう
    • => そこでプロキシ

サービスメッシュ

  • 全ての通信を通るプロキシを置いてそこで共通的な処理をする
    • =>これがサービスメッシュ
  • プロキシにサービスディスカバリ、タイムアウト、リトライ、ログ出力など全て入れる
    • 各サービスにマイクロサービス用の実装をいれなくてよくなる
  • EnvoyProxy
    • 代表的なサービスメッシュ
    • OSS
    • CNCFが運営してる
    • 多くの本番実績もある
    • yamlでプロキシの設定を書いて読み込ませる
  • プロキシとアプリケーションの密結合
    • 一貫性と疎結合性のためにプロキシを選択したはず
    • プロキシの設定変更にはデプロイと再起動が必要
    • それぞれのライフサイクルとオペレーションモデルが違う
  • AWS App Mesh
    • Envoyがダウンタイムなしで動的に設定変更できる

　

月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？

  • 仲井 裕紀さん[FROSK]

スマホアプリの品質

  • 品質(UX)
    • UI/速度/不具合

アプリの不具合

  • よくある不具合
    • クラッシュ
    • UIが崩れる
    • かたまる
    • 仕様と異なる
  • アプリ品質が悪いと継続率に10%影響が出る
    • エンジニアだけの問題ではない

アプリのクラッシュ

  • 4割以上が週1回以上アプリクラッシュ経験してる
  • クラッシュすると
    • ユーザが離脱する
      • 7割以上の人がクラッシュが原因で使わなくなったことがある
      • 長期的な継続率に10%くらい差が出る
    • 新規ユーザの獲得率を下げる
      • レビュー見てダウンロードやめちゃう
      • レビューに「落ちる」を含むアプリ:☆1.9
      • 一般的なアプリ:☆3.5
    • GooglePlayではクラッシュ数に応じて順位を降格させている
  • クラッシュを放置することは穴の空いたバケツに水を溜めようとしてるようなもの

なぜクラッシュが起きるのか

  • すべての環境でデバッグ/テストできない
    • Android種類多すぎ問題
      • 上位20端末でようやくシェアの3分の1
      • OSと組み合わせると組み合わせが膨大に
    • iOSはVUPみんなするからころころバージョンが変わる
    • OSの不具合もちらほらと
  • 不具合検知の仕組み
    • 正確にエラーを取るのは困難
    • 保存しておいて次回起動時に送信とかが多い
      • クラッシュしたのに次回起動があるのか？
  • クラッシュの対応
    • 情報量が少ないと対応しようがない
      • 端末依存？
      • OS依存？
      • 環境が特殊？
      • ユーザの勘違い？
    • 再現できないとなおせない

クラッシュ問題への向き合い方

  • 以下のサイクルを回す
    1. 自社アプリの品質を正確に把握
    2. クラッシュ率をKPIとして管理
    3. 影響範囲の大きい不具合から効率的に修正
    4. 品質問題の影響範囲を最小限に留める工夫
  • 週1回くらいのサイクルで回していくといい
    • 評価のいいアプリはそれくらいで回してる

自社アプリの品質を正確に把握

  • 不具合を「社内で気づく」に
  • 日常的に品質をモニタリング

クラッシュ率をKPIとして管理

  • レビューとクラッシュ率の相関が見えている
    • 落ちるのレビューがないと1.5%くらい
    • 落ちるのレビューがあると7%くらい
  • 1%以下を目指すと良い
影響範囲の大きい不具合から効率的に修正
  • どの不具合から改善するか
    • 定量的にどれからやるか決めるよい
    • 発生回数など

品質問題の影響範囲を最小限に留める工夫

  • レビュー依頼はクラッシュ率の高いときは出さない
  • 不具合が分かってるならアナウンスすると低評価を防げる
    • 親切心で報告として☆1つけてレビュー書いてくれる人もいる
  • エラーの情報とユーザの情報を紐付けて管理
    • 改善したことを報告できるように

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

勉強会メモ

event.shoeisha.jp

タイムテーブル

10:00～10:45

タイトル 発表者
出勤から企業開発者を解放し、エンジニアの働き方改革を実現するリモート開発環境構築 増渕 大輔[日本マイクロソフト]
起業家的？！エンジニアのススメ 玉川 憲[ソラコム]
最新のブラウザで変わるCookieの取扱いやプライバシーの考え方 古川 陽介さん[リクルートテクノロジーズ]
LINEがプライベートクラウドを選ぶ理由 室井 雅仁[LINE]
UXデザインが大事なのはわかるけどエンジニアの私ができることってなんでしょう？ 安藤 昌也[千葉工業大学]
ITがモビリティを創る：MaaSに向けた技術とエンジニア像 伊藤 昌毅[東京大学]

11:05～11:50

タイトル 発表者
ノーコードPower？だけど開発者だからこそ知っておきたい、Power Platformの使いこなしかた～〜W王子より愛を込めて 廣瀬 一海[日本マイクロソフト]
清水 優吾[セカンドファクトリー]
モノタロウがGCPで挑戦するデータドリブン・ECプラットフォーム〜持続的成長の舞台裏 普川 泰如[MonotaRO]
藤本 洋一[MonotaRO]
CircleCIの3000 万件のワークフローから得られたDevOpsに関する知見 車井 登[CircleCI]
ぼくらの六十日間戦争 ～ｵﾝﾌﾟﾚからｸﾗｳﾄﾞへの移行～ 左近充 裕樹[ブロードリーフ]
doda開発者が語る IoT＆サーバレスでビジネスサイド変革に挑戦した話～イノベ観点のダッシュボタン＆負債から進化したアーキテクチャ～ 上源 勇朗[パーソルキャリア]
アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？ 松岡 正人[日本シノプシス]

12:10〜12:40

タイトル 発表者
Let's Dive in Developer Community! 小田 祥平[日本マイクロソフト]
加藤 健大[テイ・デイ・エス]
Kubernetes未経験者がGKEの本番リリース〜障害対応を経験して苦悩した話 泉水 朝匡[grasys]
noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦 今 雄一[ピースオブケイク]
サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話 田岡 文利[ミクシィ]
常識を破壊するティール組織とエンジニアリング組織論 片岡 俊行[ゆめみ]
音声認識で質の高い議事録を！議事録サービス「GIJI」 川端 光義[アジャイルウェア]

13:05～13:50

タイトル 発表者
我々はZOZOTOWNのクラウドジャーニーを通じて何を学んだのか？ 川崎 庸市[ZOZOテクノロジーズ]
質とスピード 和田 卓人[タワーズ・クエスト]
インターネットが変えた世界・変える未来 伊勢 幸一[さくらインターネット]
創業105年の旅館運営企業が実現した毎週リリースするチームの作り方 藤井 崇介[星野リゾート]
Webパフォーマンスガチ勢が本当に使っている技術 中村 けん牛[プライム・ストラテジー]
若年層におけるプログラミング的思考の学びの場づくりと動機づけ 鷲崎 弘宜[早稲田大学]
齋藤 大輔[早稲田大学]
坂本 一憲[早稲田大学]

14:10～14:55

タイトル 発表者
楽天がモノリス→マイクロサービス & オンプレ→クラウドで経験した光と闇 柳本 浩一[楽天]
新井 庸介[日本マイクロソフト]
Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法 Baruch Sadogursky[JFrog]
批評家不要！気がつきゃ全員エンジニアリング。アジャイルなTeamでプロダクトを生み出し続けるスマレジとEBILABの挑戦とこれからの企業の存在意義 小田島 春樹[EBILAB]
常盤木 龍治[EBILAB]
山本 博士[スマレジ]
宮崎 龍平[スマレジ]
ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜 福井 勝史[Insight Edge]
Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜 中井 悦司[グーグル・クラウド・ジャパン]
Salesforceで変わるこれからのアプリケーション開発と開発者の働き方 田中 宏樹[セールスフォース・ドットコム]

15:15～16:00

タイトル 発表者
GitHubやMicrosoftが機能リリースする舞台裏 服部 佑樹[日本マイクロソフト]
田中 裕一[ギットハブ・ジャパン]
Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦 岩根 義忠[ホンダエンジニアリング]
松浦 洋介[NECソリューションイノベータ]
星 直人[ホンダエンジニアリング]
矢田 将[ホンダエンジニアリング]
礼節から育てるチームの健康と信頼性 塩谷 啓[クラスメソッド]
テストエンジニアが教える　テストコードを書き始める前に考えるべきテスト 風間 裕也[ビズリーチ]
なぜ技術力評価会の評価者はペアなのか？ー 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果 ー 小賀 昌法[VOYAGE GROUP]
「厳密な共通言語」としての形式手法 チェシャ猫[ProofCafe]

16:20～17:05

タイトル 発表者
GateboxにおけるAzure AD/AD B2Cを基盤としたID Centricな組織・サービス・プラットフォームの設計 久森 達郎[Gatebox]
コンテナをシンプルに使おう 〜 Cloud Run のすゝめ 2020 冬 篠原 一徳[グーグル・クラウド・ジャパン]
InterSystems IRIS Data Platformで高度なデータ分析のための基盤を整備しよう 堀田 稔[インターシステムズジャパン]
エンジニアはものづくりの夢を見るか - AWS Loft Tokyo 入館アプリの開発事例 - 西谷 圭介[アマゾン ウェブ サービス ジャパン]
今村 優太[アマゾン ウェブ サービス ジャパン]
クラウドサービスとゲーミフィケーション:「TwilioQuest 3」を用いた開発者オンボーディング 池原 大然[Twilio Japan]
少量データで軽量な機械学習の手法について 秋吉 信吾[QuantumCore]

17:25～18:45

タイトル 発表者
俺たち一生楽しい厨二病〜トッキー、ジニアス、漆原の赤裸々トーク〜 漆原 茂[ウルシステムズ]
常盤木 龍治[EBILAB]
ジニアス平井[日本マイクロソフト]
「ITエンジニア本大賞 2020」プレゼン大会 【司会】高柳 謙/【特別ゲスト】永瀬 美穂[アトラクタ]
【特別ゲスト】広木 大地[レクター]
【特別ゲスト】山下 智也[英治出版]
若手エンジニアの登竜門「Developers Boost 2019」優秀セッション再演！
組織にモヤッとしたら聞く話
エンジニア×〇〇 ～職種を「越境」して希少性を出すキャリア～
入社2年目からスクラムマスターとしてチーム改善に取り組んだ話 		蜂須賀 大貴[IMAGICA Lab.]
池上 純平[プレイド]
西山 慧[ヤフー]
エンジニアと人事がともに考えるエンジニア採用
エンジニアと企業、それぞれの立場から見た採用市場の実情
エンジニアが人事と一緒に採用活動する時に考えたいジョブディスクリプション
認識ギャップが不幸の始まり・・・不思議な造語「カジュアル面談」を考える 		【モデレーター】金山 貴泰[うるる]
てぃーびー（田部井 勝彦）[スタディスト]
伊藤 哲弥[LAPRAS]
安立 沙耶佳[ヌーラボ]
梶原 成親[ヤプリ]
チームをつくるモブプログラミング ～内側と外側から語る～ 及部 敬雄[デンソー]
安井 力
あのイベントの裏側が知れる！？カンファレンス運営者LT 西馬 一郎[Backlog World]
島根 義和[JaSST Tokyo]
岸川 孝明[JAWS DAYS]
高橋 慎一[明日の開発カンファレンス]
谷本 心[JJUG CCC]
細澤 あゆみ[XP祭り]
柏岡 秀男[PHPカンファレンス]
【司会】鍋島 英莉[翔泳社]

最新のブラウザで変わるCookieの取扱いやプライバシーの考え方

最近のブラウザ

  • セキュリティ/プライバシー周りの変更が多い
  • Safari
    • ITP
  • Firefox
    • ETP
  • Chrome
    • SameSite Cookie
      • クロスサイトでのCookieの受け渡し禁止
    • Mixed Contentsブロック
      • HTTPSからHTTPのリソース読み込みブロック
    • UserAgent文字列固定化
      • フィンガープリンティングに使われてしまわないように
  • 3rd party Cookieに関してはChromeが一番厳しい対応
    • 他は非推奨に対してChromeは廃止という語気
  • 表示しているページのoriginと異なるなるoriginのCookie
    • これを制限しようという動きが広まってる

Cookieとは

Cookieを使ったトラッキング

  • a.comのページでb.comの広告を見た
    • b.comにアクセスしたという情報がCookieに保存される
  • b.comにアクセスすると過去にアクセスしたことがわかる
  • c.comでb.comの広告を見る
    • 過去にa.comにも行っている人だと紐付けられる
  • Cookieを使うことで広告の最適化などしていた

JavaScriptによるCookieのセット

トラッキング

  • トラッキング全てNGにするとWebの収益モデルが崩れる
  • Cookieでトラッキングするのがダメと言われてる
    • なんでもCookieを使うのがよくない
  • プライバシーに配慮した利便性のいい仕組みが必要
  • Safari
    • Private Click Measurement
      • 広告をクリックしてそこから購入したことをCookieなしで検知できるようになる
      • コンバージョンしたかどうかだけしか分からず何を買ったかなどは削られる
  • Chrome
    • Privacy Sandbox
      • Cross-Site Trackingの再定義
      • 3rd Party Cookieの廃止
      • 新しい方法への移行を表明(まだ何も決まってない)
    • Privacy Budget
      • 個人識別情報を一定数超えたらもう渡さない
        • UserAgent固定も予算制限のため
      • どれだけの情報が個人識別可能なのか
    • Trust Tokens API
      • Botじゃ答えられない問題出して人かどうか判別
    • Federated Learning of Cohorts

どう対応すればよいか

  • Cookieの取り扱い
    • セッションとしての扱いにとどめる
    • Secure属性とHttpOnly属性をつけてサーバで発行する
    • JSでのCookie書き込みは極力減らす

アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？

サイバーインシデントはなぜ起こる

  • サイバーインシデント
    • ある調査によるとビジネス上の課題でサイバーインシデントはトップ要因
    • ソフトウェアの品質がビジネスに直結する
  • サイバーインシデントの要因
    • 悪い人が意図して起こす
    • 悪意のない人が意図せず起こす
  • コード量が増えるとリスクは増える
  • サイバーインシデントによる影響
    • 制御プログラムの不具合によるリコールが増大
    • 生命の危機や社会インフラの停止につながることもある
      • 飛行機の墜落の事故
    • => 攻撃されたときの影響も甚大
  • 現代のソフトウェア開発の課題
    • コード量
      • ソフトウェアはミッションクリティカルなインフラ
    • 複雑度
      • 様々な技術
    • 開発速度
    • リスク

よりセキュアなアプリケーションの開発

  • 解決すべき課題を明確にする
    • どんなものを扱っていて何をやったら何がわかるのか知らないといけない
    • フレームワーク/プログラム/OSS/API/OSなどなど
  • どんな脆弱性を持っていてどういう危険性があるのかちゃんと理解して対策をとる

品質を向上しセキュリティリスクを低減する

  • 脅威モデル
    • 攻撃の入り口
      • 外部から
      • 内部から
        • 事例の7割は内部に協力者がいる
    • アセットの配置を整理
    • 人を想定
    • 管理策を構成
  • Microsoft: STRIDE
  • OWASP: Application Threat Modeling
  • Openid Foundation: OAuth 2.0 Treat Model/IETF RFC6819

noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦

noteのグロースモデル

  • 作者が集まる -> コンテンツが集まる -> 読者が集まる -> コンテンツが売れる -> 作者が集まる
    • 矢印の数値を監視して数字が落ちているところを補強していく
  • 単一のKPIを追わない
    • バランス良く勝手に伸びるような構造

noteのチーム

  • 基盤チーム
    • グロースモデル全体を活性化
    • KPIの監視
    • プッシュ通知の基盤
  • 機能開発チーム
    • MAX3ヶ月くらいのスパンで主要な機能を開発
  • カイゼンチーム
    • アジリティ重視でPDCAをひたすら回す
    • 長くても2週間くらいのスピード感

noteのデータ

  • noteが成長してきてグロースモデルの状態が把握しづらくなってきた
    • 人も増えて関係者が増えてきた
  • データ活用の機運が高まった
  • データの取得
    • 言葉の定義
      • 離脱とはなんなのか？などなど
  • データ収集のための分析基盤構築

今後何をやっていくのか

  • グロースモデルの発展は継続
  • パフォーマンスの改善に力を入れる
  • レコメンドの向上

我々はZOZOTOWNのクラウドジャーニーを通じて何を学んだのか？

ZOZOTWONのリプレース

課題

  • 時間がかかるリソース調達
  • インフラ構築運用の手間増大
  • システム負荷に波がある
  • セールのタイミングで負荷が大きくかかる
    • 一番使われる量に合わえせてサーバを毎年買い足さないといけない
    • オンプレからクラウドへ

リプレース戦略

  • リプレース前は超密結合

  • 戦略

  • アクセスを受けるサーバはそのまま(いろいろあるので)

  • そこから呼び出すAPIをクラウド/コンテナ化
    • 負荷の増減が激しいところなので
    • Nginx+SpringBoot
  • マルチクラウド
    • SPOFを回避したい
    • AzureとAWSで
    • 最初にAzure選んだのはID周りがいいから

ZOZOのクラウドジャーニー

  • クラウドは不安定であるという前提で考える
    • 再起動などでサービス断が必要になる場合も
    • リソース共有型相乗り型である場合がほとんど
  • クラウドは責任共有モデル

堅牢性より回復性

  • ダウンタイムやデータ損失を回避してサービスを維持できるシステムに
  • 参照系APIの回復性機能
    • マルチエンドポイント
      • 負荷分散
    • オートヒーリング
      • k8sの機能で
    • APIリクエストのリトライ
      • マルチクラウド間でリトライ+流量割合制御
    • APIリクエストのサーキットブレーカー
      • 無限リトライ防止

クラウドリソースは有限

  • 抽象化してるだけで有限である
  • 想定を上回るような利用をする場合は注意
  • ピーク時にキャパシティ確保失敗した事例あり

クラウドは決して安くない

  • オンプレとはモデルが違う
    • 減価償却モデル/従量課金モデル
    • 長期的にみると割高になることも
  • コスト削減の取り組み
    • アクセス少ないタイミングでDBのコア数を調整
    • リソースの使用率を平準化させる
    • できれば動的にこれをやりたい

学習の基本姿勢

  • クラウドにおいては自己学習が基本
  • Slerやベンダーサポートへの丸投げ方式ではスピード感を保つことは難しい
    • メンターメンティーの関係がちょうどよい
  • 最後は自分たちで闘うという姿勢

Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜

  • 中井 悦司さん[グーグル・クラウド・ジャパン]

テーマ

  • デブサミで毎回インフラの話しをしてる
  • インフラの次を考える時代になってきてるので今回のテーマにした
  • マイクロサービスアーキテクト
    • SREとペアになるような考え方

GCPの魅力

  • Googleのソフトウェアエンジンと同じ体験を一般のデベロッパーに提供するもの
  • Googleの考え方
    • 世界中の情報を整理し世界中の人ボトがアクセスできて使えるようにする
  • 専用回線によるグローバルネットワーク
  • 社内でコンテナ管理Borg
    • それをOSSにしたのがk8s

GCPを使っていく上での悩み

  • どう組み合わせればいいの？中の人はどうやって使ってるの？
  • Google社内ではマイクロサービスという言葉は使わない
    • 最初に作った検索エンジンがマイクロサービスだった
    • それが当たり前なのでわざわざマイクロサービスって呼ばない
  • インフラの中の話はいろんな論文がたくさんでてる
    • どういう風にサービスを組み合わせるといいかはほとんどない
    • 社内にはあるけど公開できない

マイクロサービスWebアーキテクチャ

  • Web3層アーキテクチャ
    • クライアント - Webサーバ - Appサーバ
  • マイクロサービスWebアーキテクチャ
    • クライアント - reverse proxy - BFF - 同期系サービス(n個) - 非同期系サービス(n個)
    • BFFで外部に見せるAPIとサービス実装を分離
  • Googleにおけるマイクロサービス基盤の構成
    • Magleb - GFE - (grpc) - 同期系Borg Job(n個 - 非同期系Borg Job(n個)
    • だいたい同じ
    • GCPのサービスに置き換えて考えることもできる
  • スクラッチで新しく作るならこれでできるかもね

既存アプリのマイクロサービス化

  • マイクロサービスのメリット
    • スケーラビリティ
    • サービス単位での開発デプロイ
    • 新異能のリリースを安全に素早く
      • 依存関係を気にせずに特定機能の改修に集中
      • チームごとの独立性、並行開発並行リリース
    • 何か改修する時に色んな所に手を加えなくて良いのがメリット
      • 人間がマイクロサービス単位で捉えられるので理解しやすい
      • トラブルシュートもやりやすくなる
      • 他のチームと合わせて開発リリースするのは大変
  • マイクロサービスのデメリット
    • サービスの独立性を確保した設計を初期段階で行うのは難しい
    • 将来の機能拡張なんて予想できない
    • サービス全体をリファクタリングする瞬間はどうしてもでてくる
  • 既存アプリがMVCで実装されている場合
    • 特定のコントローラーを外だししてみよう
    • 既存モデルの参照を必要としない機能を外出ししてみる
      • 既存モデルの参照が必要な部分は残す
  • オンプレ塩漬けの場合
    • BFF作って既存システムを抽象化して機能単位でリプレース
    • 既存クライアントは廃止して新規クライアントからBFFを叩く
    • 塩漬けオンプレがサービスの一つととらえることができるようになる

マイクロサービスによるシステム設計

  • アプリケーションの機能を適切に分割する作業
    • BFFで外部公開する機能とサービスとして内部実装する機能の切り分け
    • サービス感の連携方式
  • それぞれのマイクロサービスを実装する方式を考える作業
    • 実行プラットフォーム
    • xxx

Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦

  • 岩根 義忠さん[ホンダエンジニアリング]
  • 松浦 洋介さん[NECソリューションイノベータ]
  • 星 直人さん[ホンダエンジニアリング]
  • 矢田 将さん[ホンダエンジニアリング]

登壇者

従来

  • プロジェクト制だとカットオーバー後の変化に追従できなかった
  • OneTeamでやっていくには属人化を防がないといけない
  • 動くソフトウェアこそが要求を洗練させる最善の方法

アジャイル開発

スクラム開発スタート

  • 振り返りに力を入れた
  • 自ら考えるチームへ
    • 各スプリントで課題を何か一つでも解決させようとした
    • いつでもNowが自己ベスト

スクラムマスターから7つの質問

  • 最初からチームとして成立していた？
    • さまざまな部門の人がかかわっていた
      • それぞれ優先するものが違う
      • 同じ方を向くことが難しかった
  • PO/SMはどうやって決めた？
    • 入社したての人を選定
      • 新しいことをやるなら新しい人がいい
  • チーム編成は何が一番大切？
    • ロールに対してどんな期待値があるのか
    • 同じ方向を向くために価値観をあわせる
  • ベロシティって上がらないし周りに見せにくいどう管理したらいい？
    • xxx
  • ベロシティを下げるプラクティスってどうなの？
    • モブプロやペアプロ
    • どういった課題にたいするアプローチか共有してやってくといい
  • 開発チームに全て委ねるって怖いのでは？
    • 開発チーム以外も含めてみんなで議論して進めていったから大丈夫だった
  • チームの成長を促す方法ってどんなことをすればいいの？
    • 学びのスピードフィードバックを得るまでのスピード

不確実性のコーン

  • 最初はウォーターフォールでやろうとしてたから仕様書があった
    • 突き合わせてみたら25%程度しか必要なものは残らなかった
    • 不確実性のコーンが実証できた

今後の展開

  • 対象を広げる
    • 他のプロジェクトでも
  • フェーズを広げる
    • 運用段階でも
    • DevOpsを回せるように

少量データで軽量な機械学習の手法について

  • 秋吉 信吾さん[QuantumCore]

リザーバコンピューティング

  • 特徴
    • 簡単かつ高精度
      • 少ないデータでも十分な精度を出せる
    • とにかく速い
    • 安価
  • もともと物理学
  • 特徴抽出で活用する
  • 線形分岐不可能な問題を分類できるようになる

なぜリザーバコンピューティング

  • 市場規模
    • 2030年に国内AI市場2兆円超え
  • データの質と量
    • データ不足/ユーザからの利用許諾
    • データクレンジング/偏り
  • 軸
    • バッチ処理 <-> リアルタイム
    • パーソナル/少数データ <-> ビッグデータ
    • リアルタイム + パーソナル/少数データが空いている
  • ターゲット
    • 個人に合わせる必要がある分野
    • 環境に合わせる必要がある分野

活用例

  • スマートウォッチ
    • 加速度データ
    • 泳法判定など
  • 画像データ
    • 骨格情報抽出/骨格の動き波形
    • モーション判定など
  • 振動データ
    • 振動センサー
    • 寝姿勢はんていなど

課題

  • ビジネス上の課題
    • なぜうまくいくのか説明するのが難しい
  • 技術的な課題
    • 音声などノイズが多いものは難しい

エンジニアと人事がともに考えるエンジニア採用

  • 【モデレーター】金山 貴泰さん[うるる]
  • てぃーびー（田部井 勝彦さん）[スタディスト]
  • 伊藤 哲弥さん[LAPRAS]
  • 安立 沙耶佳さん[ヌーラボ]
  • 梶原 成親さん[ヤプリ]

転職透明化ラボ

  • 採用担当者と求職者の間の情報の非対称性
    • 採用担当者の知識を求職者へ還元する取り組みをやっている
  • 今回はエンジニアと人事との間

エンジニアにとって採用はなぜ重要？

  • 会社にとって重要なのはわかる
  • 個人にとって何が嬉しい？
  • 給料
    • 優秀な人を採用できると事業が成功して自分の給料が上がる
  • 職場体験
    • コミュニケーション能力の高い人が入って組織内の関係性が良くなると職場体験が向上する
  • キャリアアップ
    • 自分にはないスキルを持った人が入ってきたら新しいスキルを教えてもらえる
  • 直接的ではないが大きな影響がある

エンジニアと企業、それぞれの立場から見た採用市場の実情

  • 伊藤 哲弥さん[LAPRAS]

エンジニア側から見た採用市場

  • 超売り手市場の実態
    • IT人材が不足している
  • エンジニアの質
    • 課題解決型から価値創造型へ
  • 一極集中の構図
    • n数の企業から1候補者に送られてスカウトメールの数
      • 1企業:22%
      • 2-5企業: 50%
      • 6-10企業: 18%
      • 11-20企業: 8%
  • Laprasに53万人エンジニアが登録してる
    • スカウトメールを受け取ってるのは1%
  • 企業の採用要件も特定の技術領域に集中してる

企業側から見た採用市場

  • エンジニアが採用に関わるべき背景
  • ディスコーズを形成することが重要
    • TechBlogなど
  • エンジニアは採用担当と面談したいと思っていない
    • 技術のわかるエンジニアと話したい
  • エンジニアのキャリア
    • Engineering Manager
    • Tech Lead
    • Product Manager
    • こいったキャリアを目指すのであれば採用に関わるべき

まとめ

  • IT市場は今後も超売り手市場
    • ただし引く手あまたの人とそうでない人がいる
  • 人事がエンジニア採用のフロントに立つことの弊害
    • エンジニアも協力していく必要性

エンジニアが人事と一緒に採用活動する時に考えたいジョブディスクリプション

  • 梶原 成親さん[ヤプリ]

ジョブディスクリプション

  • 具体的な職務内容
  • 必要とされるスキルなど
  • 企業側の情報開示のひとつ
  • 業務の内容や進め方までイメージできたら最高

書いておきたいポイント

  • やってほしい職務
  • 採用している言語技術関連ツール
  • 応募資格(前提条件)
  • 歓迎要件

書いてあるとなおよいもの

  • 仕事の進め方
    • 案件開始から終了まで
  • 仕事で関わる人
  • 直面している課題
  • 採用している背景

いいジョブディスクリプションの書き方

  • いろんな会社のJDを読みまくる
    • 30くらい見ると良いものと悪いものが見えてくる
  • 現場の課題をヒアリングしてそれが欲しい人材ということ

認識ギャップが不幸の始まり・・・不思議な造語「カジュアル面談」

IT業界市場

  • エンジニアが足りない
  • 企業の側から声を掛けていかないと人がとれない
  • => カジュアル面談

カジュアル面談

  • 面談？面接？
  • Wantedlyが作った用語という説
  • カジュアル面談ブームで困ったこと
    • いきなり志望動機を聞かれる
    • 逆パターンもあって興味あるからメール送っただけでなぜ採用しようと思ったか聞かれることも
    • 両者の認識齟齬が起きる

ヌーラボでは

  • 面談の定義を決めて候補者に伝える
    • 候補者と企業のギャップを埋められるように何を話すか決めておく
    • 興味があったら応募してくださいと一回相手にボールを渡す
  • 選考フローを設計ししゃないで共有する
    • 面談の前後で採用担当者と面談担当のエンジニアで認識合わせの打ち合わせをしてる

「LINE API × Tech API Vol. 2 Powered by AWS」に参加してきました

勉強会メモ
  • LINE API × Tech API Vol. 2 Powered by AWSに参加してきました。

linedev.connpass.com

  • 日本ではスマホアプリがなかなかインストールされなくなっていて、スーパーアプリからミニアプリを使うという流れが中国(WeChat)で進んできているとのことです
    • 先日のPWA Night Conferenceの基調講演でも同じような話ありました
  • その流れからのLINE内でミニアプリを作るハンズオンをやりました
    • LINEという誰もがインストールしているスーパーアプリに乗っかってしまえという発想で説得力ありました
タイトル 発表者
LINE APIでAWS上でアプリを作ろう 2020！ 比企 宏之さん(LINE)
サーバーレスでの分散トランザクション Taewoo Kimさん(クラスメソッド)
AWSでつくるLIFFアプリ 松永勇太さん(ACCESS)
LIFF meets AWS serverless 鈴木哲詩さん(AWS)

LINE APIでAWS上でアプリを作ろう 2020！

  • 比企 宏之さん(LINE)

日本のアプリ事情

  • なかなかインストールされない
  • ホーム画面も埋まってる
  • 通知も見てくれない
  • 使ってないと気付いたらアンインストールされちゃう

中国のアプリ事情

  • WeChat Mini Program
  • WeChat上にアプリ(Mini Program)があってそこから開く
  • WeChat Mini Programのアクセス
    • QRコード
    • 公式アカウント
    • GPSで近くの店舗に対応したもの
  • 日本のスーパーアプリ
    • 決済アプリが次々スーパーアプリ化を表明

LINEの状況

  • LIFF
    • LINE内にWebアプリ
  • LINE MINI App
    • LIFFをミニアプリとしてパブリッシング
    • すでにいくつも公開されている
      • 「ホーム」->「サービス」

LIFF

  • LINE Frontend Framework
  • HTMLやJSで作れる
  • LIFF UI <-> LIFF SDK <-> クラウドサービス
  • LINEのトーク画面に3段階の大きさで表示できる(全画面も)
  • LINEの通知使える
  • 端末変えても情報引き継げる
  • Share TargetPicker(3月上旬リリース)
  • ミニマイズウィンドウ(4月以降リリース)

サーバーレスでの分散トランザクション

  • Taewoo Kimさん(クラスメソッド)

マイクロサービス

分散トランザクション

  • 全部成功するか全部失敗するか
  • マイクロサービスで実現したい
    • Distributed Saga
  • AWS Step Functions
    • どんな順番で処理をするか定義できる
    • 失敗した場合はこういう分岐とか

AWSでつくるLIFFアプリ

LIFFアプリをデプロイする

  • AWS CDK
    • プログラミングするだけでCloudFormationが作れる
    • GUIでやらなくていい
    • TypeScript
  • 構成
    • S3にReactアプリ配置
    • CloudFront経由でアクセス
  • LIFFをReact+TSで作る
    • LIFFの型定義は野良のしかない
    • liff-type

LIFF meets AWS serverless

  • 鈴木哲詩さん(AWS)

Chalice

  • マイクロフレームワーク
    • サーバーレスアプリをPythonで作る
  • AWS公式のフレームワーク
  • Lambdaを使う上で考えること
    • アプリ作る
    • どうやってLambdaにデプロイ
    • Lambdaはどのサービスへのアクセス権限を持つ
  • ChaliceとAPI Gatewayを組み合わせる
    • chalice deployでデプロイできる
    • IAMロールの設定勝手にやってくれる
    • chalice invokeで叩くこともできる
    • S3へのアップロードをトリガーにみたいなこともできる

ハンズオン