「TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜」に参加してきました

勉強会メモ

ビジネスとエンジニアリングの接合点 ～ そしてコード品質がそこに及ぼす影響

  • LINEヤフー株式会社/松本 成幸@mtx2sさん

ビジネスとエンジニアリングの接合点

  • ビジネスからエンジニアリングへの相談からスタート
  • ビジネス
    • 計画づくりから始める
    • そのために見積もりしてもらう
    • 完成時期を早めたい
  • エンジニアリング
    • 見積もりをする
    • 計画をする
    • 完了する確率を高めたい
  • 両方が調整されて発足する

プロジェクトの成功に求められる要素と接合点

  • 成功は計画だけでなく価値の提供も含む
    • 期間
    • 予算
    • アウトカム
  • プロジェクトの進行中は様々な困難がある
    • プロジェクトプランニングとプロジェクトコントロールも必要
  • 価値があると信じていても顧客によって検証されるまでには仮説にすぎない
    • 実験と計測を回していく

コード品質がビジネスに与える影響

  • 低品質なコードだと
    • 見積もりが難しい
      • 予測可能性が低くなる
    • 欠陥が多い
      • 欠陥の修正に追われてしまう
      • 潜在的な不具合がどこかで顕在化する
    • 開発時間が長い
      • 期待する価値に到達するために何度も繰り返すことができないので価値がさがるか遅延する
  • => 成功に求められる要素のマイナス要因になる
    • ビジネスに悪影響を与えてしまう

対策の実例

  • 保守性の構成
    • テスト容易性
    • 変更容易性
    • 理解容易製
  • テストコードを書く過程でリファクタリングが進み品質が高まる
  • テストのカバレッジを評価軸に入れた
    • テストを書く文化を作りたかった
  • テストが目的とならなようにその他のメトリクスも評価に入れた
  • ジュニアとシニアでペアプロでテストを書いていく

開発者に感謝される品質チームであるために

内部品質チーム

  • 外部品質(QA)とは別動
  • 機能開発を安心して高速に行える基盤づくり
  • 社内標準を磨きプロダクトに反映

品質向上と標準化

  • 煙たがられるのでは
    • 新機能をはやく作りたい
    • お作法を押し付けることになってしまわないか
  • 実際は感謝されていた

やっていること

安心と高速化

  • 注力領域の妨げになる箇所を先んじてリファクタ
  • モノレポのハマりどころの対応
    • ライブラリや言語のVUP
  • CIの安定化高速化

標準化

  • 共通機能のミドルウェアの提供など
  • 使い勝手に敏感であり続ける
    • ライブラリのアップデートで足かせになっていないか
    • 機能は十分か
    • トラブルシュートで困らないか
    • changelogが読めるものになっているか

コード品質向上タスクの優先順位を判断するために必要な観点を探究する

コード品質

  • 内部品質/外部品質
  • コードは内部品質
  • 内部品質は外部品質に依存し外部品質は利用品質に依存する
  • コード品質は内部品質の中でもメンテナビリティ
    • 理解容易性
    • 変更容易性
    • テスト容易性

なぜ改善タスクが進まないか

  • なぜ進まないか
    • 変化が怖い
    • 知識の孤立
    • ビジネスが止まる
    • 終わりが見えない
  • ビジネスメンバーが判断できない

ビジネスへの説明

  • ゴールを決める
    • いろんな指標があるからそれを使う
    • 基準をどうするかはビジネスドメインによる

「UI UX Camp! 2024」に参加してきました

勉強会メモ
  • 2024/3/20
  • https://cp.nijibox.jp/uiuxcamp
  • 生成AIの活用が全体的に話題の中心でした
  • 普段Webしか触れてない自分からすると新鮮に感じる話題が多かったです
  • 最初の講演で「フィルターバブル」の話がありましたがまさにその外側に触れた感じでした
  • 参加者は以外とエンジニアもいたし、大学生や高校生もいました

人間性とテクノロジーの未来〜ぬくもりのデザインを考える〜

  • 内田 舞さん
  • 野々村 健一さん

テクノロジーが人間に与える影響

  • テクノロジーによって認知が変わっているか
    • 自分用の情報をみんなが見てると思ってしまうe
      • フィルターバブル
    • 意識的に外に出てみないとわからない
  • ビジネスの中でフィルターバブルの中でトラフィックをドライブさせるのはどうか
    • 儲けたお金の量は語られるが質を語られることがあまりない

デザイナーのスタンス

  • この10年でスマホが定着
    • 今はITが要請といっていいくらいになってる
  • 新しいテクノロジーが浸透していくフェーズと活用してくフェーズが振り子のようになってる
  • テクノロジーが出てくるのは選択肢を増やすこと

次世代生成AIプロダクトのつくりかた〜技術進化のトレンドから予測する生成AIビジネスの未来〜

  • 梶谷 健人さん

優れた生成AIサービスをつくるポイント

生成AIの本質価値をおさえる

  • 創造コストが限りなく0になる
  • 自然な対話の実現
  • 非構造化データのベクトル化
    • 全く整備されてないデータでもいい感じに処理してくれる
  • コンテンツのマルチモーダル化
    • モーダル・・・データの種類
  • 高単価専門知識の民主化
  • 言語障壁の軽減
    • AIの中ではAIだけにわかる状態で保持されてるので言語の壁がない
    • テキストから多言語の発話動画を作れたり
  • 新しいモーダルでのインプット
    • ラフな絵をもとにWebページ作ったり

生成AIを忘れる

  • 生成AIを使うことが目的化して課題設定が甘くなることが多い
  • 99%のサービスは課題解決型
    • 顧客 x 課題 x 解決法
  • 顧客課題を深堀って、生成AIが活きる領域を考える

生成AIならではのUXを作る

  • UXの原則を押さえる
    • UX = u(便益) + e(情緒価値) - f(リフレクション)
  • その上で生成AIならではの体験をいれる

AIの進化によってUXの在り方

環境や情報とのインタラクションがどう変わるか

  • デザインの単位がUserからYouへ
    • 特定の人向けのものを簡単に作れるようになった
    • 今のユーザ中心設計は将来的に大量生産大量消費のように見えるかも

人とAIの間衛生

  • 人間の存在意義はどうなるのかとよく聞かれる
    • これは人とAIを分けて考えている
  • AIが人の脳の第三の新皮質になる
    • 能力が1000倍違うと旧人類と新人類くらいの差がでる
  • 人はAIを内包し両者分けずに考えるべき時代が来る

身体を超える「自分」をデザインする〜ゴーストエンジニアリングで広がる生き方の可能性〜

  • 鳴海 拓志さん

バーチャルアバター

ゴーストエンジニアリング

  • ゴーストエンジニアリング
    • 身体の再デザインによる心と認知のデザイン
  • アバターによる自分事/他人事の切り替え
    • 他社視点の体験を得ることで共感醸成
    • 三人称視点で見ることでひらめきの数が増える
  • アバターの動きの融合
    • 2人の動きを合成してアバターを動かす
    • 熟練者のスキルを伝えるのに使える
  • 身体的自己/物語的自己
    • いきなりスキルを得たり変われると言われても使いたいと思う人は少ない
    • 自分の物語があるので突然変わることは望まない
      • Narrative Self
  • アバターだと誰でもチン室な身体を得られる
    • 身体のままならない多様性を意識しなくてよくなる
  • 身体を通じてどのような「こころ」をデザインしたいか
    • 「こころをデザインする技術」を人生において適切に意味づけるためのデザインは

未来のエネルギーをデザインする〜今、全人類が取り組むべき持続可能な社会の実現〜

  • 紺野 亜紀子さん
  • 田子 學さん

エネルギー

  • 太陽光や風力などは安定的に供給できないかもしれない
    • 地域や地形に密接に関わってる
    • 再生可能エネルギーをやってくなら地域にフォーカスする必要ある
  • 石炭は運べる資源
  • 水力
    • ダムは水力で発電してる
    • 貯水してるだけじゃない
    • SAKUMAが古くなってるので改善しようとしてる
    • 地域に還元できたらその地域の価値があがるのでは
  • 地熱

CO2の削減

  • CO2フリー水素発電
    • 石炭から水素だけ取り出して発電する
    • 再生可能エネルギーは不安定
      • それを補って安定供給させることにもつながる
  • 草本系エネルギー作物燃料化

企業における生成AI導入の実際〜デザイン組織リーダーが考える、これからのプロダクト開発の現場〜

  • 古川 陽介さん
  • 吉川 聡史さん
  • 上田 沙緒理さん

AIの活用状況

  • 開発
    • Copilote
    • v0
      • アイデアの種として使ってる程度
    • ChatGPT
  • ディレクション
    • ChatGPT
      • 社内としてセキュリティ担保した上で
    • 自社ナレッジをChatGPT系サービスに入れて困ったときに聞けるようにしてる
    • 分析用途でSQLを生成してもらったり
    • 技術的な質問などの翻訳
    • プロンプトの生成をChatGPTにやってもらう
  • デザイン
    • ChatGPTでアイデアの発散の手助け
    • ライティングやキャッチコピーの手助け
    • デザインそのものを作るところでは活用してない
      • 活用できるほどのものがちょうど生成されない
      • 権利の問題

生成AI普及による課題

  • 楽なタスクはAPIに頼れるから新入者向けの経験を積む簡単なタスクがなくなっていないか
    • 開発ではあえてAI使わずにやらせている
  • AIが出したものをいまいちだと判定できるのは経験によるもの
    • その経験を得る機会が減ってしまっている
  • メンバーが失敗する経験をたくさん提供したい
    • 社内や自社で閉じるところで

今後の展開

  • AI使ってできた気になってる人をどうにかしたい
  • 目より先に手が肥えることはない
  • マネージャーががいいものを作ることで新しい人がそれを見てくれる

ロボティクスとデザインの親密な関係〜社会に溶け込む理想的な身体拡張ロボット開発〜

  • 山村 菜穂子さん

自在肢

  • ロボットの腕を増やす
    • 背負って使う
  • サイボーグ
    • NASA宇宙で活動するための身体の編集
  • デジタルサイボーグ
    • 身体に手を入れずに装着できる
    • 気軽にサイボーグ状態になれる
  • 自在肢のきっかけ
    • デジタルサイボーグが受け入れられるのか
    • どんな時に使われるか
    • 人の身体と調和が取れるデザインがどんなものか
  • 動かし方
    • 今は他の人が遠隔で動かしている

デザインプロセス

  • 人間拡張技術の研究とデザインラボの共同ではじめた
  • 身体の形をじざ員に変化させる研究
  • ロボットアーム
    • どう動かすかにフォーカスしていた
    • 動かしてる人は自分の一部と認識してるか心理学的な面での調査
  • 特徴
    • 身体と調和したスタイリング
    • 人間の身体とのスケールの類似性
    • 工具無しで着脱可能
  • 装着性の確認を工程ごとにこまめに確認

AIのある日常 2024〜「自分流」がカギをにぎる、これからの生成AIとのつきあいかた〜

  • 深津 貴之さん
  • 砂金 信一郎さん

生成AIの追い方

  • 個別の技術をおうよりも全体を見てる
  • どれが勝って負けるとかおってもしかたない

生成AIの失敗パターン

  • AIを使うことが木底になるとだめ
    • ペインがないところとか
  • やりたいことにAIがあってないとだめ
    • AI使うより人のレビュアー増やしたほうがよっぽど効果があるケースとか

生成AIの使い所

  • パーソナライズしたいところ
    • 生成AIを使うにはコストがかかるのでそれくらいやれないとペイしない
  • ある程度の一般知識があるだけでできる業務
  • サービスの裏側で実は使われているというくらいがいいのかも
  • 作業は人間でアシストするのがAIという分担がいいのでは

「Google Developer Expertsが語るWeb技術の最前線」に参加してきました

勉強会メモ

プライバシーサンドボックスとサードパーティCookieの廃止

  • 田中 洋一郎さん
  • 異なるサイトからトップレベルサイトに送信される任意のcookie
  • 広告以外にも使われる
  • トラッキングによるプライバシーの侵害が問題
  • 3rd party cookieを廃止する代わりに主要なユースケースをサポートする技術が用意された
  • 2024/1から1%展開された
    • 2024の終わりには100%展開される予定

準備

対策

ブラウザと仕様のアップデート

  • 矢倉 眞隆さん

HTML/UI

  • JSに頼らないUIが増えてる
    • a11yを標準で担保
  • OpenUI
    • UI標準を提案するグループ

CSS

  • CSSの根幹に手をいれる機能拡張が増えた
    • CSS Nesting
    • :has
    • @scope
    • @property
    • sub-grid
    • align-content

仕様の課題

  • 小さい機能が多い
  • 最小限の機能の実装は早い
  • 仕様の課題の解決に時間がかかってる印象

実装の状況を道知る

  • ブラウザのリリースノート
  • ベースライン
    • 各ブラウザの実装が揃っているかなどの状況が見える

互換性と相互運用性

  • Interop
    • 仕様と実装の互換性を上げるプロジェクト
    • 各ブラウザの実装状況のスコアも見れる
      • web platform testsでスコアを出している
    • 毎年どこに注力するか発表される

ブラウザ動向

  • Chromeの3pcd
    • 2024/1から適用が始まった
  • iOSのブラウザ変更
    • EUでwebkit以外のエンジンが使えるようになりそう

Getting started with designing for web accessibility

  • Julia Undeutschさん

Color Contrast

  • テキストを読めるか
  • リンクとして認識できるか
  • 色を認識できるか
  • Color Contrast Checkerで確認するといい

Color Independency

  • 色だけで情報を伝えてはだめ
  • エラーが起きた時に文字色を返るだけで伝えるとよくない
    • アイコン入れたり色に頼らない情報で伝えるといい

Link text

  • Read more や Clck here だけでは何のリンクか分からない
    • リンク先が分かるようなテキストを入れるのがいい
    • スクリーンリーダーでリンク一覧を見ると Read more が連続されるようなのは避ける

「Repro Tech Meetup: Deep Dive into Browsers」に参加してきました

勉強会メモ
  • 2024/3/15
  • https://repro-tech.connpass.com/event/311742/
  • ブラウザAPIの話を聞けるのは珍しいので面白かったです
  • Service Worker static routing APIが名前だけ知ってて気になってたので詳細聞けたのがよかったです

No more parser-inserted js

script要素

  • 標準は同期実行 & parser-inserted mode
    • DLと実行待ちでHTMLパーサが停止する
  • これが標準なのは互換性のため
    • JavaScript1.0(1996)
    • document.write
    • 今は警告出るしもう使わない
  • JavaScript1.0

HTMLパーサとJS実行

  • parser-insertedな実行
    • HTMLだけなら普通のパース処理
      • 順番に処理してく
    • JSが入るとややこしくなる
      • JSでHTML入力ストリームにインサートできる
      • JSでDOMツリーを改変できる
    • 当然かなり遅い
  • 今はもうquerySelectorがあれば十分
  • DOM APIがあればパースとめて処理実行する必要ない
    • それを実現するのがdeferとasync

defer/asyncの話

  • defer
    • ダウンロードは並行
    • 入力ストリームの終端で実行
    • document.writeは虫
  • async
    • ダウンロードは並行
    • パーサを止めて実行
    • document.writeは虫

document.write再考

document.write

  • 文字列で渡されたHTMLをHTMLに追加する
    • 壊れてても入れられる

いいところ

  • レンダリングプロセスに介入できる唯一の方法
    • 画面が表示されたときには必ず処理が終わってる
    • 計測タグ
    • レンダリングまでに必ず必要な処理

悪いところ

  • レンダリングプロセスに介入してしまう
    • 同期的でブロックされる
  • 実行タイミングがずれるとページを壊す

何が問題化

  • 適切に使えば問題ないがそれが難しい
  • 文字列渡すので何でも実行されてしまう

document.writeへの介入

  • chromeは介入して止める
    • scriptが実行されない
    • ただし介入するのはいろんな条件を満たした時

Render Blocking

  • 特定の要素にたどり着くまでブロッキングする
    • レイアウトシフトを防ぐのが目的
  • ABテストで画面の表示が確定するまで止めるとか

エディタ付きのReact開発環境をブラウザだけで実装した話

  • steelydylanさん

ブラウザエディタ

  • https://mosya.dev/react
  • StackBlitzのブラウザでnode動かす製品とかあるが有料なので自分で作った
  • lintエラーとか型情報とかちゃんと表示される
    • Biomeのwasm webをブラウザで動かせる
    • workerで動かさないと重すぎる
      • ComLinkが便利

プレビュー環境

  • SWを活用
    • 通信に介入するのを利用した
    • 必要なファイルを通信しにいってSWでァイルを返す
    • 全部mjs化して返して解決させてる
  • reactなどのライブラリはimportmapで対応
  • SWでHonoを動かしてる
  • tsは@swc/wasm-webでトランスパイル

採点機能

  • ブラウザでtesting-libraryを動かしてる
  • jest-liteで実行

Memory leaks in Web Application

メモリ管理

  • アプリの変化
    • SPで滞在時間長期化JSの肥大化
    • ヒープを圧迫すると最悪タブクラッシュ
  • なぜリークするか
    • GC言語なのでメモリは自動管理
    • 到達可能だけど不要なオブジェクトがリークしてるオブジェクト
    • windowから参照されてる
    • listener
  • 頻出パターン

どうやって特定する

  • Memory heap snapshot diffing
    • snapshotをn回とって+nなオブジェクトが怪しい
  • Retainer treeを確認
  • 3snapshot
    • 2回だとキャッシュとか意図的に残ってるかも
  • ノイズが多くて大変

自動化

  • fuite
    • puppeteer使ってる
  • MemLab
    • meta製
  • BLeak
    • Proxy使ってJS書き換えて
  • LeakPair
    • ASTで解析してリークしやすいパターンを見つけてパッチあてる

モニタリング

  • フィールドデータが貴重
    • 実際のユーザがどれだけメモリ使ってるか

Service Worker static routing API

SorviceWorker

  • fetchをproxyするがその時には起動済みでないといけない
  • SWの起動はnavigationにクリティカル
    • Androidだとp95で500ms
    • cold状態からの起動だとp95で940ms
      • 30%くらいでこっちの挙動になる
  • SWが介入しなかった時のコストも無駄がある
    • SWがなにもせずブラウザから通信を改めてするので
  • navigationPreloadを使うとnavigationと起動を並行できる
    • とはいってもswの方が時間かかると待たされて遅い

SorviceWorkerのコスト改善

  • いらない時は動かさない
  • Static Routing API
    • どういうリソースにどう介入させるのかを宣言的に指定する
    • event.addRoutes に定義する
    • confition
      • URLPatternやmethodなどの指定
    • source
      • networkなのかcacheなのかなど
    • or
      • pngかjpgならchacheからといった使い方

Use case

  • navigationはキャッシュしてないとか
  • formのPOSTはキャッシュしてないとか
  • サブリソースはキャッシュにあればキャッシュがいいとか

dev tools

  • networkタブでserviceworker routerと出るようになる
  • 指定した定義も確認できる

「「Tailwind CSS実践入門」出版記念イベント」に参加してきました

勉強会メモ

出版記念基調講演

TailwindCSSとの出会い

  • https://charcoal-web.pixiv.design/
  • デザインシステムの技術選定
    • プロダクトたくさん
    • 全部Reactというわけではない
    • ->Tailwindがちょうどよかった
  • もともとCSS in JSとかよりCSS Modulesが好きだった

CSSのレビューをしやすくする

  • write-onlyな言語になりがち
    • コードレビューがちゃんとされづらい
  • CSS+StylelintとTailwindCSSでの対比
  • Tailwindの方がレビューしやすい
    • 上書きされてるかもと考えなくていい
    • ArbitaryValuesがあったら警戒
    • モディファイアが少なかったら警戒
    • 機会にわかりやすいコードは人間もレビューしやすい

書籍の執筆

  • WebDBPressでtailwindの特集書いた人から紹介されて書くことになった
  • CSS初心者はターゲットにできない
    • デザインシステムでの活用を期待されているので
  • デザイナやマークアップやサーバサイドの人も読んでほしい
  • ユーティリティファースト vs セマンティックCSS
    • 対立があると議論が見やすくなる
  • 差分ではなくストーリーを書く
    • ブログなら前回からのアップデートで書けるけど本だとそうはいかない
  • フレームワークの入門書は歴史と思想を扱う

大変だったこと

  • 周辺技術全部使ったことあるわけじゃなかった
    • どれが必須でどれが好みの問題かはある程度見えていたしレビューもしてもらった
  • CSS設計の話は古いものもあってBEM以外詳しくなかった
  • tailwindのclassを紹介していく4章を書くのが大変だった
    • 5~10万文字かと見積もったら14万文字になった

文章を書く工夫

  • かっこいいルビを入れる
    • 着脱可能(プラガブル)
    • 修飾子(モディファイア)
    • 日本語と外来語の紐づけを簡単に示せる
  • 傍点を活用
    • 日本語にイタリックがないし太字多様も嫌だった

CharcoalとTailwindCSS

  • mimoさん

Charcoal

Iconify for TailwindCSSのすすめ

Iconify

引数のあるmixinのような仕組みをプラグインとして実装する

  • _yuheiyさん

CSSのmxin

  • matchUtilitiesを使うと引数のあるユーティリティを作れる
    • matchConponentsもある
    • 引数は1つしかとれない
  • tailwindの内部の書き方を真似ると参考になる
  • custom variablesを使うと1つのclassで複数指定するものを個別に指定できる

「メドレー & Ubie 共催：なるほど！人を助けるデザインのひみつ」に参加してきました

メドレーという会社とデザインチームのひみつ

  • 波切 雅也さん (メドレー)

メドレーのデザイン組織

  • 人材と医療のサービスをあってる
  • デザイナー12名
    • 2016: 1-3名
    • 2019: 5-6名
    • 2022: 10-12名
  • 人材PFと医療PFが分かれた
    • デザイナーも2つに分かれた
    • ドメインの課題を解決するため
    • 1つのままだと社内受託みたいになりそうだった
  • 少ない人数でスピードと効率重視
  • 中途半端に運用コストかかり続けるようなものがやらないという選択もとった
  • デザインチームの構造
    • 横断チーム
    • 人材PFチーム
    • 医療PFトーム

Product Design is Parenting

  • 前田 邦織さん (メドレー)

プロダクトデザイン

  • プロダクトデザインは子育て
  • リサーチ
    • 社内に医療従事者がいる
      • ペアプロみたいな感じできける
      • インプットをもらってデザイナーがドメインエキスパートになれるように
    • プロトタイピングをまず作る
  • 検証
    • 医科と歯科でオペレーションが違うとかあった
  • 評価/改善
    • リリース後要望やクレームに対して改善
    • 顧客が少ないと偏りがあって使われない機能があった
  • 子育てもプロダクトも成功失敗を繰り返して愛着がわいていく

ドン・ノーマンを超えていけ！未来のモノのデザイン

  • 畠山 糧与さん (Ubie)

未来のモノのデザイン

  • https://www.shin-yo-sha.co.jp/book/b455872.html
  • 「ひとりごとが2つあっても対話にならない」
  • 患者と医師の対話
    • 言いたいことが言えないとかがある
    • ユビーが翻訳者しての役割
    • ひとりごとではなく対話ができるようにデザイン

なるほど人を助けるデザインのひみつ

  • 吉井 裕貴さん (Ubie)

Ubieのミッション

  • テクノロジーで人々を適切な医療に案内する
    • 病気ではなく患者にアプローチする
    • 早期発見/早期受診につなげる
  • 医療に関する行動の本がいろいろでてる
    • なぜ病院受診しないかとか
    • 行動変容ステージ
      • 6ヶ月以内に行動する気があるって感じのたまにみるやつ
  • 人の行動を促すコミュニケーションのデザイン
    • 高度な医療のデザインもやってるけど特別難しいことをやってるわけじゃない

2024年2月に読んだ本

読書メモ
  • 2024年2月に読んだ本の記録です
  • 3冊目は読み終わらなかったので3月分で

ちいさくはじめるデザインシステム

ちいさくはじめるデザインシステムbnn.co.jp

  • SmartHRでのデザインシステムの事例を紹介した本です
  • 以下の点が印象的でした
    • まずは役に立つものを提供して使ってもらうところから始める
    • ミッション・バリューなど組織ぐるみで取り組まないと決められないことも含まれている
    • コンポーネント集が公開されていて実装を参考にできそう
    • ライティングについてのルールが多いのに驚いた
      • いろいろなパターンの言い回しがルール付けされてる

Tailwind CSS実践入門

gihyo.jp

「JAWS DAYS 2024」に参加してきました

勉強会メモ
  • 2024/3/2
  • https://jawsdays2024.jaws-ug.jp/
  • AWSからはここ数年離れてたので知らない話ばかりでした
  • IaC周り、データ連携周り、セキュリティ周りが知らないことが多くて聞いてて面白かった
  • 今はAWSは使ってないけど、使うとしたら話に出てきたこれを使うのかなとか思いながら聞けました

Keynote

  • Jeff Barr

ユーザコミュニティの話

  • 日本のユーザコミュニティは10年以上続いてる
  • 土曜日に自発的に参加しようと思う人が1000人いるだけですごい
  • スピーカーになれる人をもっと増やしていくと良い
  • 新しい人を受け入れていくために初心者向けのコンテンツも大事

ぼくのかんがえたさいきょうのAWSへのリソースデプロイ

IaCツール

  • CloudFormation
    • 記述量多くなる
    • Lambdaのデプロイが大変
  • Terraform
    • マルチクラウド
    • 独自の柔軟なyamlみたいな言語で書く
      • 設定値を並べる感じなので誰が書いても同じようなコードになりやすい
    • デプロイがはやい
  • SAM
    • サーバーレスなら便利
  • CDK
    • 中はCloudFormation
    • 抽象化されて便利だがされすぎというのもある
      • いろんなroleが作られてたり
    • TS/JS,Java,Python,C#,goなどいろんな言語で書ける
  • Pulumi
    • 中はTerraform
    • コードを書いていくタイプ
  • other
    • ServerlessFramework -有料になった？

どうデプロイしてるか

  • GitHub Actions
  • Terraform Cloud
    • Terraforの有料版で使える
  • CodePipeline
  • CodeCatalyst
    • 開発に必要な工程をまとめて提供してくれるAWSのサービス
    • CIのワークフローを作れる
    • サンプルがたくさんあるから0から作らなくてもいい
    • 東京リージョン未対応
  • PipeCD
    • GitOpsを実現するツール
    • コンテナイメージが配置されたらデプロイが動く
  • CLI
    • 手動でコマンドたたく

サービスクォータ、ちゃんと監視してますか？

クオーターの枯渇

  • 新しいリソースを建てられなくなる
  • 増加のリクエストが即時に対応されるわけじゃない
  • 監視してモニタリングするのがベストプラクティス

AWSクオーターモニター

  • AWS公式にある
    • 通知してくれるソリューション
    • cloud formationのテンプレート何パターンかある
  • 最低で月12ドルくらい
    • 監視する量による
  • 対応範囲がいのものもある
    • それらはCloudWatchで監視

人材育成専門企業の内製開発の現場から

  • 山下 光洋さん、木村 啓秀さん[トレノケート株式会社]

トレノケート

トレーニングで使うシステム

  • 受講者とインストラクターが使うシステム
  • ベースはEC2 - RDS
  • 拡張機能はLambdaとかいろいろ
  • 出席管理をシステム化したり
  • リマインドの電話かけるところをAmazon Conenct使ったり

クラウド黎明期、いかにしてJAWSは始まったのか～熱い歴史をコミュニティ史として語り継ぐ

  • 渥美 俊英さん
  • 竹下 康平さん
  • 得上 竜一さん

JAWSの歴史

  • 2010/2の第0回が最初
    • Jeff BarrがLTしてくれた

コミュニティ

  • 2000年くらいまではエンジニアの勉強は資格だった
  • その後インターネットで様々な技術が広がった
  • OSSのユーザコミュニティが出てきた
    • Seasar2
    • そこに関わってた人でその後AWSに携わってる人多い

3.11

  • 震災時にAWSの力を体感した
    • ユーザコミュニティでの動きも大きかった
    • 募金を集めるようなサイトを短時間で一気に作った
    • サービス継続するITリソースが足りない人に呼びかけてサポートした

Leap Beyond

  • 変わらないもの
  • 変わったもの
    • サービス数10から240超
  • 語り継ぐもの
    • エンジニアが日本を救う

クラウドネイティブなデータ連携の最新動向:AWSサービスアップデートで何が変わった？

クラウドでデータ連携

  • API連携/データ同期/メッセージキュー/クラウドストレージ/ファイル転送

API連携

Amazon AppFlow

  • SaaSアプリやAWS感でデータ転送できるサービス
  • 対応コネクターが増えている
    • SaaS/AWSあわせて80サービスサポート
    • ex. BigQueryからS3へ転送
  • AWSサービスへの組み込み
    • 意識せず内部で使われるケース
    • ex. Amazon SageMaker Data Wrangler

AWS Step Functions

  • いろんなAWSサービスを組み合わえて分散アプリケーションを作成できる
  • JSONでワークフローを作る
  • Workflow StudioでGUIでもできる
  • Stepの中で外部のAPIをたたけるようになった
    • それまでは外部のAPIをたたくLambdaを作ったりしてた
  • ワークフローの失敗したところから再実行できるようになった
    • インプット変えたり編集してからの再実行はできない

データ同期

zero-ETL統合

  • ETLプロセスの家データ移動の課題を解決するもの
  • データ系サービスがニアリアルにつながる
  • AuroraからRrdshiftだとストレージレイヤで同期される
  • RDSからRedshiftはバイナリログに依存して同期される

ファイル転送

SFTP

  • プロトコルが枯れてる
  • 自動化や前処理後処理の作り込み
  • 監視やリトライが必要
  • AWS Trasfer Family
    • マネージドワークフロー機能
      • ファイル受信後に後処理できる
      • 複雑なことしたければLambdaでカスタムフロー
    • SFTP Connectorによる転送
    • EventBridgeへのイベントパブリッシュ
      • 転送成功失敗などフィルタ条件を設定し対応するアクションを実行できる

AWS DataSync

  • オンプレとAWS間でデータ転送するサービス
  • S3とかEFSとか対応してる

サーバーレスで豊島区の緊急設備トラブルを解決するアプリを作った話

サーバーレス

  • マネージドサービス
    • 提供から運用まで面倒を見てくれるサービス
  • サーバーレス
    • サーバー管理が不要（サーバーはある）
    • 実行環境を素早く準備できる
    • オートスケーリング
    • 高可用性
    • 使用量に応じた課金

なぜサーバーレス

  • 開発スピード
  • 売上の見込めない段階で初期コストを削減したいので従量課金がいい
  • 定期的な運用作業を減らしたい

作ったもの

  • 豊島区限定で使える
  • ビル店舗でのトラブル時に手の空いてる作業員とマッチングするアプリ
  • 作業員とチャットでやり取りして見積もりとったりする
  • だいたいサーバーレスだが一部そうでないものも使ってる

モバイルアプリ

管理画面

  • React/TS/SPA
  • CloudFront + S3
  • API Gateway + Lambda

バックエンド

  • golang
  • GitHub ActionsでCI回してLambdaにデプロイ
  • AppSync(チャット機能で利用)

コールセンター

  • Amazon Connectで電話で自動応答し担当割り振る

決済

技術書を書く技術：あなたの知識を世界に届けよう！！

  • 佐々木 拓郎さん

ほんの企画

  • 潜在読者市場
    • 初心者が一番多い
    • カテゴリ内にニッチ市場が存在する
  • 大きな市場で競争するか、ニッチな市場でオンリーワンを狙うか
  • 市場が育ってない分野は初心者向き
  • 大きな市場では大きめなニッチを狙う
  • 上級者向けは茨の道
  • 企画の作成
    • ペルソナとか決める
    • 目次レベルに詳細化

執筆

  • ツール
    • Word
      • 出版社に指定されることも
    • テキストファイル
  • 心得
    • 位置行目を書くのが一番難しい
    • まずは章節項をコピーするところから
    • 文章でなく箇条書きから
    • ChatGPTに相談
  • 校正補助ツール
    • textlint
      • Web+DB Pressで整備されたtextlint-rule-web-plus-dbがお勧め
    • ChapGPT

本の宣伝

  • 増刷しないと出版社の利益は殆ど出ない
  • 初版を売り切ることが大事
  • 執筆に書ける労力の1/10は費やす覚悟

AWSセンセーション私とみんなが作ったAWSセキュリティ

セキュリティ対策の進め方

  • やってることはいろいろ言えるかもしれないがどれくらできてるか表現するのは難しい
  • AWS Well-Architectedフレームワーク
    • 長年蓄積されたベストプラクティス集
    • 6つの柱の1つがセキュリティ
    • 優先度付けや達成度の評価には向いていない
  • セキュリティ成熟度モデル
    • セキュリティの現在地を確認できる

IAMとSecurity HubとGuardDuty

IAM

  • 必ず多要素認証(MFA)
    • すぐにやる
  • アクセスキーを極力使わない
  • roleを活用し一時的な認証情報を使う
  • IAM Access Analyzerで不要な公開を検出
    • すぐに有効化する
    • 公開されてるものを1つずつチェックできる
  • 定期的な店降りし/最小権限

SecurityHub

  • 危険な設定がないか検出してくれる
  • 100%を維持するのが理想

GuardDuty

  • AWS上で発生しているインシデントの検出
    • マイニングされてるよとか

成熟度モデルで素早く強化

  • AWSセキュリティ成熟度モデル
    • 9つのカテゴリに対して4段階のフェーズに区切ってセキュリティ対策をマッピングしたもの
      • クイックウィン/基礎/効率化/最適化
      • Phase1のQuicWinで素早く対処できて効果の高いもの
      • Phase2の基礎が最低限できていてほしいレベル

基礎のレベルまで頑張る

  • AWS公式トレーニング
    • Security Engineering on AWS
      • 3日間のセキュリティ管理者向けのコース
  • AWS Control Towerによるマルチアカウント管理
    • Organizationsを利用する必要がある

「TechBrew in 東京 〜フロントエンド技術選定、その後どうなった？〜」に参加してきました

勉強会メモ

RemixでWeb標準を学んだ1年

to BプロダクトでVite+React Routerを採用して半年後の感想」

技術選定

  • 背景
    • ユーザごとにUIをカスタマイズするようなサービス
    • 初期フェーズで技術で詰まることはさけたい
  • SSR
    • SSRは特に必要なかった
      • 業務用PCで使うアプリ
      • 認証前のページはログイン画面だけ
    • SPAでよさそう
  • Next
    • Static Exportの選択肢もあった
    • Dynamic Routingがビルド時に決まったidしか使えないのがダメだった
    • Nextの高機能のものはほとんどいらない
  • FWを使わない
    • GraphQLを使うがそこはFW影響ない
    • routingはReact Routerでよさそう
    • Reactとは心中するがそれ以外は切り捨てられるようにしたい
  • Vite + React Router

その後

  • Viteで困ることはない
  • React RouterがSentryと相性いい
  • トップレベルのコンポーネント以外はrouterの情報はpropsでもらって純粋にした方がよかったかも
  • チャンク分割は試行錯誤が合った

フロントエンドのEMが技術選定するときに取り組んだこと

  • 伊代田 大樹さん
  • ウェルスナビ株式会社

EMの領域

技術選定

  • プロダクトの戦略から考える
  • なるべく技術課題と組織課題は分ける
    • 学習コストがどうこうとか
  • フロントエンドエンジニアとしてのキャリアの観点
    • 特定技術にロックインしない
    • いろいろな技術を採用して触れやすい環境
  • エンジニア採用のしやすさ
  • メンバーの成長へのリスクマネジメント
    • レビュー体制とか

レガシーなフロントエンドをReact / Next.jsにリプレースした結果

リプレース

  • リプレース前
    • jQuery使ったり
    • Vue2もあったり
  • 技術選定
    • NextとNuxtを比較
    • 他社事例とか
    • React/Nextに決めた
  • LPなどはNext
  • 新規開発はVite + React

LaravelからフロントエンドをNext.jsに段階的に移行している話

リプレース

  • リプレース前
    • Laravel
    • Vue
    • jQuery
    • 歴史があるので可読性悪い
    • ビルド/リリース時間かかる
    • デザインの統一感ない
  • 負債の解消

フロントエンドの移行

  • 段階的に移行
    • 開発者の負担
    • ビジネス側に段階的に見せたい
    • トップページから段階的に
      • デザインも最新に

技術選定

  • Nextを採用
    • フロントエンド専任はいなかった
    • C向けなのでSEOも意識
    • 情報量が多い
    • チューニングの選択肢が広そう
    • パッケージングされてるのが楽

よかったこと

  • Lint/Formatterはいってて品質あがった
  • Storybookでデザイナーとのコミュニケーションが楽に
  • 情報はたくさんあるから困ることは少なかった
  • App Routerのコロケーションで見通し良くなった

残念だったこと

  • vercel使ってないから使えないものがある
  • Nextへの依存
  • ベストプラクティスがわからなくて試行錯誤

コンパウンドスタートアップにおけるフロントエンド技術選定のこれまでとこれから

今バウンドスタートアップ

  • 創業から複数プロダクト
  • 部署でサービスを区切らずデータを中心にサービス統合
  • プロダクト間で連携
  • 複数のプロダクトを管理

技術スタック

  • VueとNextが共存
    • Vueで型がつかなくてつらいところがあった
    • Reactも使うようになった

Vue3

  • Vue2から3に移行しないといけない
    • React化も選択肢に合ったがコストが高かったし開発を止めるわけにもいかない
    • React行くにしてもVue3を経由して型安全になってからの方がいい
  • Vue3に移行して
    • WebpackからViteにしてはやくなった
    • 型がきいていい
    • 機能開発と並行して進められた
    • bootstrap-vueがVue3の恩恵受けにくいので剥がしてる

React/Vue共存

  • 共存して2年くらい
  • よかったこと
    • 採用の間口が広くなった
    • 既存資産を活かしづらいのでゼロベースで改善できる
  • 困っていること

今後

  • 新規はNext
  • VueもReactに移行
    • 開発が止まらないようにしながら

「花王インハウスデザイナーの「よきモノづくり」 | A11yTokyo Meetup」に参加してきました

勉強会メモ
  • 2024/2/27
  • https://a11ytyo.connpass.com/event/308749/
  • 普段webだけやってる立場からすると全然違う分野の話でしたが、デザインのプロセスはwebに近いところもあり面白かったです

現在のインハウスデザイナーの視点、役割、デザインプロセス

  • 平田 智久さん
  • 花王株式会社
  • 商品デザイン作成部

商品デザイン作成部

花王のユニバーサルデザイン

  • 2011年に指針として発表
    • 見やすい、わかりやすい、使いやすい
    • 1995年からやってる

デザインの考え方

デザイン手法

  • 以下の2軸でプロトを繰り返す
  • アイデア的方法
    • 創意工夫
  • 定量的方法
    • 人間工学/感性工学

ブランド価値

  • 購入前〜購入〜廃棄のライフサイクルがある
    • 後ろに行くほど満足度が高いものがいい

ワークショップ

  • 要介護の人の感覚を体感するワークショップを多くの社員が体験

シャンプーきざみ開発〜現在

  • シャンプーとリンスが紛らわしいという消費者からの声
    • 調査すると間違える人は多かった
    • 色や大きさなどメーカーによって様々なので判別がつかない
    • 目が不自由な人に聞くと触覚にたよった識別をしてると分かった
  • 形を変えたりいろいろ試した
    • ぎざぎざが評価がよかった
    • 一般の人に受け入れてもらえるか
      • アンケートとったら受け入れてもらえそうだった
  • ぎざぎざの形などもパターンを試して1991年10月に第一号発売
  • 業界で統一した方が消費者の利益が大きい
    • 各社数年で導入が進んだ
  • その後日本や国際的な規格になった

インハウスデザイン事例

アタックZEROの容器

  • キャップ計量にさまざまなストレスがあった
    • メモリが見にくい
    • 開け締めを両手でやらないといけない
    • 液漏れして汚れる
  • →正確な計量を片手で使えるようにしたい
  • ワンハンドボトル
    • 親指方とか洗濯バサミ方とか
    • 家庭訪問のべ2756人でどこに置いてるかやどう使ってるかを調査

クイックルワイパーミニ

  • 介護用品の掃除道具として開発
    • 壁や廊下を掃除する商品がなかった
    • トイレ周りの掃除
  • 3Dプリンタでプロトタイプ作ったりして検証
  • ワイパータイプが床の掃除がしやすいくてよかった
    • 膝を曲げなくていい
    • 顔をトイレに近づけなくていい
  • ユニバーサルデザインが商品価値を上げている例

「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デザインのフェーズ
    • プロトタイピング
    • 詳細設計
  • プロトタイピングで勝ち確になってからこだわる

状態のパターン

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

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

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