「Encraft #13 QA Enablement - Insight by QA activity」に参加してきました

  • 2024/4/23
  • https://knowledgework.connpass.com/event/314168/
  • QAがいる環境にいたことがないけどどんな雰囲気か気になって参加してみた
  • QAエンジニアが何を大事にしていてどんなことをしているか何となく知れました
  • 開発チームとの関わり方の話がイメージしやすくてよかった

「品質保証活動からの情報提供」について考えよう

  • 小山 竜治(koyaman)さん / 株式会社 ナレッジワーク

QA からの情報提供

  • テストの目的の 1 つとして情報を提供するというのがある
  • QA における情報
  • テストは知る技術
    • 今どうなってるかを知るためにテストする
    • 知ったことを誰かに伝える
  • QA の活動
    • プロセスがうまくやれてるか
    • プロダクトがいい状態か

事例

  • 情報提供していること

パネルディスカッション

  • パネリスト:湯本 剛さん/風間 裕也さん/小山 竜治さん
  • モデレータ:河野 哲也さん

ケーススタディ

In Dev(開発チームの中にいる入ってスクラムにも参加してる場合)

  • バグちゃんと記録することから始めるといい
    • 何が起きてどう対処したかの記録
    • ユーザにとってどう価値を損なったか
    • 自分がやるかチームにやってもらうかはチーム次第
  • テストを予告する
    • テストするとわかってると意識して開発できる
  • ここから作ってもらうとテストの観点でいいとか言える
    • リファインメントでチケットの完了条件を問う

Out of Dev(開発チームの外の部門にいる場合)

  • プロダクトが出来た段階でQAでテスト
  • QAが外にいるのはリリースに重きをおいてるケース
  • テストの順序
    • 正常系が通ってるかどうか
    • ダメならそこで伝えないとその先のテストできない
  • 企画書をもらってプロダクトの存在意義を探る
    • どこを抑えるべきか把握してテストしていく
    • 安心してプロパティを出すため

Bridge(テストは第三者で開発とのブリッジをする場合)

  • 発注元として
    • 委託先の言うことを鵜呑みにしない
      • 100ケースでいいのに5000ケースやろうとしてるとか
    • バグの見落としがあっても委託先のせいにしないと握っておく
  • 委託先として
    • 何をやらないか発注元と握る
    • やってと言われたらやる

Assistance(QA に関する情報提供)

  • QA部門が外から開発部門を支援する
  • 開発部門が何をやってるか知る
    • 具体的に度のチケットのどういうところで悩んでるか聞いてアドバイスする
    • 一般論言うだけじゃフィットするか分からない

「RESEARCH Conference 2024 プレイベント」に参加してきました

ジャーニーマネジメントを起点とした顧客体験の向上とこれから

今の顧客体験分析

  • 認知/比較検討/利用/利用後
    • フェーズで分断されがち
    • シームレスな顧客体験を創りたい
  • 顧客体験とビジネス効果をデータとデザインで実現
  • CX改善のサイクル
    • 顧客の声をもとにカスタマージャーニーマップを更新してバックログに反映して改善を回していく
    • ただ、これをやるのはとても大変

これからの顧客体験分析

  • CX改善のサイクルをどれだけ自動化できるか
    • qualtrics
      • 指標を統合的に管理
      • 顧客データなどの業務データと背景を探る体験データ
    • thrydo
      • https://www.theydo.com/
      • 利用体験をE2Eで管理
      • カスタマージャーニーマネジメントの省力化民主化
      • miroをコピーしてJourney AIにコピペすると簡単に取り込める
  • データ活用してジャーニーマネジメントする
  • ジャーニーエクセレンスの実現

カスタマーサポートとUXリサーチの融合

  • 株式会社メルペイ 太田 茜さん

合同共有会

  • UXリサーチャー
    • 思考や認知を定性的に理解
  • カスタマーサポート
    • 体験課題の要因を定性的に理解
    • さまざまなインサイトを得られていたが活用できてなかった
  • データアナリスト
    • データから行動を定量的に理解

改善につながった例

  • 利用規約の同意
    • 情報量が多かった
    • 離脱が多かった
    • 一部畳んだりしたけどそれでも変わらない
      • 読み飛ばして後から問い合わせが増える
    • それを元に改善して離脱率が減った

興味関心と組織とリサーチ

リサーチャーの業務スコープ

  • 2020年にpixivでUXリサーチチームが出来た
  • リサーチを依頼する調査主体
    • リサーチをしたい
      • 手段ツール
    • ビジネス課題を解決したい
      • 課題
    • 何かについて知りたい
      • 興味関心

リサーチプロジェクトは単体で完結するか

  • 興味関心アップ <-> リサーチによる課題解決 <-> 手段拡充
  • 興味関心を整理する
    • 継続的な活動に

リサーチャーの組織配置

  • リサーチチームからイネーブルメントチームへ
  • 開発チームが依頼してリサーチ -> 開発チーム自身がリサーチするのを支援する

「Muddy Web #8 ~Special Edition~【ゲスト: LINEヤフー】」に参加してきました

新規開発と並走したリファクタリング戦略

作っているもの

リファクタリング

  • リターンが大きくリスクが小さいものから
  • ドメインやコードの理解が深まってから大物を
  • 新規開発でもリファクタをすることも
    • その方が早くなるケース

フロントエンドのりアーキ

  • やったこと
    • AtimicDesighからFeatureベースへ
    • ReduxからSWRへ
    • カスタムhookでコンポーネントから処理を分離
  • 機能ごとに段階的に
    • 新規機能は新しい方で

Yahoo! 知恵袋フロントエンドをリアーキテクトしている話

知恵袋

問題点

  • 少しだけ違う似たようなコードがたくさん
  • 処理が入り乱れている
  • 少し何かを変えるとテストが落ちまくる
  • 型がないから実行時に発覚するエラーが多い
  • テスト一番大きくて26000行

リファクタリング

  • 一番閲覧/機能が多い質問詳細ページを対象に
  • controllerのロジックをmodelとutilityに移動
  • 共通処理をまとめる
  • 切り出した処理のテストを書く
  • TS化する

WINTICKET における8万行の Redux コードの TanStack Query への段階的移行

TanStack Queryへの移行

  • Reduxでのステート
    • サーバレスポンス
    • グローバルステート
    • ローカルステート
  • Reduxだと非同期処理でライブラリが追加で必要
    • redux-thunkとか
  • サーバレスポンスのキャッシュだけTanStack Queryに移行した
    • それ以外はReduxのまま

移行戦略

    1. 影響/依存小さい箇所
    2. 既存アーキテクチャとの共存
    1. コアロジック
    2. 複雑な要件に耐えうるか
    1. 残り
    2. 妥当性は確認済みなので後はやるだけ

デザインコンポーネント vue3マイグレーション体験記

Vue2系EOL

vupの壁

  • vee-validateをv3からv4へ
  • viteとWebpackを共存しないといけない
    • スケジュールの都合で
    • 当初はvue2/webpackをvue2/viteにしてvue3/viteにしようとしていた

viteとwebpackの共存

  • npmのworkspaceを使った
    • モノレポ構成でviteとwebpackを分離した
  • workspaceを使うことによる課題
    • Swiperのscssのビルドが通らない
      • 最新版にしてnode_module配下に対して独自にaliasでかいけつ
    • viteだと変数含んだimportだと~などのエイリアスが使えない
      • Vue.prototypeで双方の書き方の違いを吸収

「Agile Tech Talk vol.3 「PdMに求められる要素とプロダクトの未来」」に参加してきました

2階建てプロダクトマネジメント

  • akippa 井上 直登さん

プロダクト開発のジレンマ

  • バランスをどうとるか
    • 1階:積み上げの開発
      • 足元の課題
    • 2階:逆算の開発
  • 1階が出来てる前提で2階をやってる
    • しっかり利益を出し事を最優先にそのうえでやりたいことをやる
  • 1階と2階でチームを分けている
    • 1階は現実主義で2階は理想主義
    • やってることが全然違うので開発/PdMそれぞれ別
    • どっちにどれだけリソース割いてるか分かりやすい

参照マジックをリリースするまで

参照マジック

  • インタラクティブなフォームを作れる
  • 名刺を読み込んでデータ化してSalseForceなどに連携

リリースプロセス

  • スクラムでやってる
  • リリースまで3ヶ月
  • 初期の段階でのリファインメントが重要だった
  • 最初にコンセプト(体験)の定義
    • できたバックログを元にデザイナー/エンジニアとリファインメント
    • エンジニア中心で最小限のプロトを作る
    • 機能を分割して考えられたのでスコープを絞れた
  • 体験づくりからみんなでやったのがよかった

継続的な改善 x ⾮連続的な進化

継続的な改善

  • 四半期で数百件のPRDの作成100件以上の開発意思決定
  • フェーズ
    • Ideaフェーズ
    • Discoveryフェーズ
    • Designフェーズ

非連続的な進化

  • 1〜3年後の価値を考えて可視化
    • それをブラッシュアップしていく
  • フェーズ
    • 課題整理
    • ソリューション仮説
    • Figmaで可視化
  • 開発を伴わないプロトタイプがアウトプット

今後

  • 1人のPdMが両方やってる
    • 長期と短期のバランス
  • ロジカルな明文化
    • チームで共通認識を持ちながら進める

Helpfeelでの要望管理

  • Helpfeel 松村 祐貴さん

要望管理

  • 昔はScrapboxでチケット管理してた
    • 事例-要望-解決アイデアのネットワークを構造化できる
  • チームの規模拡大
    • いろいろやりたくなってきた
      • 期日でソートとか担当アサインとか
    • いわゆるIssue Trackerではネットワーク構造を実現できない
    • ScrapboxとAsanaの併用になった
      • 本文はScrapboxだけでAsanaで管理
  • タスクの重複
    • HelpfeelでScrapboxを検索すると解決できる
    • 表記揺れを吸収した検索ができる

「[緊急開催]Season 2 キックオフイベント | A11yTokyo Meetup」に参加してきました

  • 2024/4/15
  • https://a11ytyo.connpass.com/event/315138/
  • Season2の初回ということで交流がメインの回でした
  • 知ってるけど話したことない方々とお話しできたのがよかったです

Season2

  • メインホスト植木さん以外2人入れ替えた
  • 奇数月はプレゼン(配信あり)
  • 偶数月はネットワーキング(会場のみ)

CSUN ATC 2024

  • 世界で一番大きなアクセシビリティのカンファレンス
  • 5000人参加
  • 注目セッション
    • エンジニアリングだけじゃなくてデザインdめおアクセシビリティ意識しようという話
    • モバイルでのキーボードサポートのテストの話
    • JSが大きくてパフォーマンスが悪いサイトの話?
      • CPUを多く使ってバッテリーを消費する

国立新美術館のマティス展に行ってきました

  • 国立新美術館マティス展に行って来ました matisse2024.jp www.nact.jp
  • 美術館が好きな後輩の話を聞いて興味がわいたのがきっかけ
  • 初美術館なので不安もありましたが特に困ることもなく楽しむことができました

事前準備

注意事項

  • いろいろ検索してみると注意事項はたくさん出てきます
    • 作品にふれないことや大きな荷物はロッカーに預けること
    • 撮影は可能なもの不可なものあるので案内に従うこと
    • 作品保持のため空調がきいてることがあるので服装注意

チケット

  • 今回行ったマティス展は事前にアプリで購入することができました
  • 会場で買ったとしても迷うことはなかったと思います
    • 美術館の入口に販売所がありました
  • 国立新美術館は○○展が複数開催されていてそれぞれでチケットが売られています
    • 美術館自体のチケットも必要なのか?と最初分からなかったが美術館への入場は無料でした

美術館での鑑賞

駅から美術館へ

美術館入場

  • 入り口には大量の鍵つきの傘立てがありました
    • 雨の日はここに預けて持ち込まないようにするんですね
  • 入ってからは案内を見つけてマティス展のある2階へ
    • 広々した空間で美術館に来たって感じがします

マティス展入場

  • 入り口に受け付けがあるのでチケットを見せます
    • アプリのQRをかざして完了
    • 紙のチケットもくれました
  • 有料で音声案内もあるようでした
  • 展示品を紹介する冊子があったのでそれを持って中へ

マティス展の鑑賞

  • 会場内は前半が撮影NGで後半が撮影OK
  • 日曜の昼過ぎでしたが人はそこそこ
  • 人の流れに乗りながら1つ1つ見て行きました
  • 5つのセクションに分かれていて年代順になっていたようです
    • 書いてある年代からすると後半は70歳くらいでの作品ということでマティスさんすごいなとか思いながら見てました
  • 絵が中心でしたが彫刻やステンドグラスなどいろいろありました

展示品

  • 花と果実
    • チケットなどにも載っていた作品
    • かなり巨大な絵(4m × 8mらしい)
    • こんな大きい絵は書くのにどらくらいかかるんだろう
    • 失敗したら後戻りできないな
  • ヴァンス礼拝堂の外観のマケット(1/20)
    • 絵じゃない作品も面白い
    • 当たり前だけど横から見るといろいろちゃんと作ってある
  • ステンドグラス「生命の木」のための習作
    • 左右両方とも同じタイトル
    • 後ろからライトが当ってるから明るかったけど、近づいて見てみるとステンドグラスだった
    • ステンドグラスってどうやって作るんだろう
  • 蜜蜂
    • 切り絵なのかな?
    • 作るの面白そう
  • 左:黒色のマニプルス(腕帛)のためのマケット、右:黒色聖杯用覆布のためのマケット
    • この海藻みたいな模様が何度も出てきて印象的
      • 撮影禁止の切り絵でも登場してた
      • マティスさんのお気に入りなのかな?
  • 上:紫色の聖杯用覆布のためのマケット、下:緑色の聖杯用覆布のためのマケット
    • 聖杯用覆布とかマケットとかよく分からないけど可愛らしい色合いが良かった
  • ヴァンスのロザリオ礼拝堂(内部空間の再現)
    • ここだけ違った空間に来たようで綺麗だった

お土産売り場

  • 展示を見終わるとお土産売り場に直結
  • 作品が印刷された小物などいろいろ売っていました
  • 何か買ってもよかったけど人が多かったので眺めるだけでした

感想

  • 初めて行ったので不安はあったけど迷うことはほとんどありませんでした
  • 割とのんびり鑑賞して入場から退場まで1時間くらい楽しめました
  • 最初は真面目に作品を見ようとしたけど普段絵を書いたりする訳じゃないからよく分からなかった
  • 海藻みたいなのよく出てくるな、とか思いながら眺めてたら楽しく見れました
  • 詳しい人に解説してもらうと違った見方もできるのかなと思いました

「第116回「WEB TOUCH MEETING」アクセシビリティSP」に参加してきました

  • 2024/4/13
  • https://www.webtouchmeeting.com/event/21
  • アクセシビリティの話はよく聞きますが新しい学びもあって広島まで行ったかいがありました
    • 障害者差別解消法についてしっかり説明を聞けたのは初めてだった
    • スクリーンリーダーはmacのVoiceOverしか使ったことなかったのでNVDAがどんな感じか知れた
    • iPhoneのVoiceOverで自分が作ったページを聞いてみようと思った
    • 読字障害の人がブラウザ拡張で行間を広げる時に思ってた以上に広くしてたのが学びだった

ウェブアクセシビリティ、今知っておくべきこと

  • 植木 真さん

アクセシビリティ

障害者差別解消法

  • 不当な差別的取扱いの禁止
    • 車椅子で介助者いないと入店断るとか
  • 合理的配慮の提供
    • 障害のある人から対処してほしいと申し出があった場合負担が重すぎない範囲で対応すること
    • 負担がおもすぎるは様々な要素を勘案して判断する
      • ケースバイケース
  • 環境の整備
    • 不特定多数の障害のある人に向けた事前的改善措置

2024/4の改正で何が変わった?

  • 「合理的配慮の提供」が事業者にも義務化されるようになった
    • 東京では2018から義務化されてた
  • 「環境の整備」は努力義務のまま
  • Webのアクセシビリティが義務化されるわけではない

Webサイトでポイント整理

  • アクセシビリティを高めておく
    • 環境の整備
  • 困っていると言われた時に建設的対話で解消を検討
    • 合理的配慮
  • Web以外で解消できることもある
    • 電話やメール
    • ただしWebサイトを改善することでUX向上や同じことで困ってる他の人への対処へつながる
      • 個別対応が減るのでコストも減る

環境の整備のために

アクセシビリティとビジネス

よく見つかる問題点

見出しのマークアップ

  • 見た目だけではなくマシーンリーダブルにする
  • h1はページに1つ
  • 見出しレベルは見手間でなく文書構造で決まる
  • 見出しレベルは1つずつ下げる
  • 何のセクション化見出しで見極められるようにする

画像の代替テキスト

  • 代替テキストwpつけてマシーンリーダブルにする
  • altだと長くなる場合は別手段でも
    • 説明を本文に
    • グラフと同じデータをたbぇで
    • モーダルや別ページでもよい
  • altの書き方
    • 画像にある文言をそのまま過不足なく書く
    • 省略したり主観を入れたりしない
    • altデシジョンツリー

キーボード操作

  • キーボードだけで操作できるように
  • スマホタブレットでも外付けで使ってる人がいる
  • フォーカス移動
    • tab or shift + tab
  • リンクやボタンを押す
    • enter or スペース
  • 選択肢の切り替え
    • 矢印キー
  • フォーカスの可視化
    • フォーカスインジケータを明示する

色のコントラスト

  • 文字色と背景色のコントラスト比を4.5:1以上
    • hover時の色など注意

動画のキャプション

  • 音声情報を字幕でも提供する

見えづらい困りごととアクセシビリティ

  • 常岡 天祐さん

発達障害とは

  • 医療用語ではなく行政が決めた言葉
  • 環境とのミスマッチで困り事が生まれる障害

読字障害当事者のWeb閲覧方法

  • 読み上げツールを使う
    • 読み上げる箇所を探すことに疲れる
  • フォントや行間をカスタマイズする
    • helperbird
    • デモだと行間2行分くらいあけて読んでた

スクリーンリーダーでアクセシビリティチェック

  • 西本 卓也さん

スクリーンリーダーとは

  • 支援技術
  • 視覚的な読みやすさを改善
  • 文字を読む

スクリーンリーダーの状況

  • PC Talker
    • 83%が使ってる(日本以外では使われてない)
  • NVDA
    • 52%(日本で)
  • iPhone VoiceOver
  • JAWS
    • 11%(世界では61%)
  • ナレーター
    • 43%(メインで使う人は少ない)
  • WebAIMのデータ

NVDA

  • NonVisual Desktop Access
  • 請願者と同じコストでパソコンを使えるようにしたい
  • 50以上の言語に対応
  • OSS
  • アドオン
  • 日本語版
    • 日本語の音声と点字に対応

スクリーンリーダーでチェック

  • NVDAとiPhoneのVoiceOver
  • 必要なときだけ起動する
  • 操作を少しずつ覚える
  • チェックしたいことを絞る

WAI-ARIA

ウェブアクセシビリティ実現のための組織体制について

  • 神森 勉さん

企業ウェブサイト

  • 企業のウェブ担当でアクセシビリティを大事に思ってる人は多いが手が回らない
  • 自社と顧客をつなげるコミュニケーション
  • ウェブの情報入手の制限
    • 屋外で
    • 音が聞けない状況
    • スマホで操作しづらい
    • 言い回しが難しくて分かりづらい
    • →障害の有無にかかわらず発生する
  • 企業にとってはウェブサイトとから情報が取れないと特定の顧客とのコミュニケーションを拒否してることになる
  • ウェブだけアクセシビリティが高まってもだめ
    • その先についても対応できる環境が整っている必要がある
    • 例えば
      • 採用サイトがアクセシブルになって応募してきたとき受け入れ体制はとれているか
      • レンタルサーバーの申込みがアクセシブルでも実際に利用するコントロールパネルがアクセシブルでないと使えない

人間の尊厳、幸福、アクセシビリティ

  • 中道 一志さん

ヌーラボアクセシビリティ

  • Backlogチーム
    • 課題の管理サービス
    • 表示要素がとにかく多い
      • 基本の内容を地道にやっている
  • Webサイトチーム
    • サービスがたくさんあってWebサイトが多い
    • 主力のサービスのサイトを重点的に
    • 機能やプランの紹介やヘルプなど要素が多い
    • キーボードや読み上げなどを中心に対応

「DIST.43 「Web制作の現場のためのAI活用術」」に参加してきました

フロントエンドエンジニアよく使う生成AIの利用方法

  • 株式会社トゥーアール 扇 克至(OUGI Katsushi)さん

よく利用する方法

  • APIモック
    • レスポンスの型を渡して作ってもらう
    • 配列10件作ってとか
    • それをmswのレスポンスにする
  • コンポーネント命名
  • Copilotでコメント書いてコード生成

良きメンター、良きパートナーとしてのAI

良かったやりとり

  • 枯れている技術は精度高い

微妙なやりとり

  • 複数のレイヤーが絡む場合

クリエイティブコーディングに役立てるAI活用

  • 株式会社ICS 代表・筑波大学非常勤講師 池田 泰延(IKEDA Yasunobu)さん

レガシー技術の移植

  • Flashで作ったものをHTMLに置き換えた
    • Flashのコードはってthree.jsにしてっていったら多少崩れても動くものが出る
  • AIは昔のことに詳しい

開発業務でAIの活きるシーン、活きないシーン

業務でAIを使う

  • 求める成果物が分かっていて検証できないといけない
  • 一発で完成形はでないので最初の足がかりにする
  • コンテキストに依存しないものは正しく生成しやすい
  • 自分がわからない領域で使うのは難しい

フロントエンド制作時に使っている、AIで作ったツールの紹介

  • TERU Inc. フロントエンドディヴェロッパー テル・豊田(Teru TOYODA)さん

べりツールを生成AI活用して作成

  • Chrome拡張など生成AI使って作れる
  • 良い結果がでないときは何度もごねるといい

英語仕事で地味につかうChatGPT

  • カンソクインダストリーズ / よりひろいフロントエンド よりひろいフロントエンドエンジニア 原 一浩(HARA Kazuhiro)さん

テキストのやりとり

  • 自分がわからないような英語にならなかった
    • 中学生でもわかるようにとか
    • 難しい単語を使わないでとか
  • 先生だと思って接する
  • 雑に質問を投げない
    • 状況を言う

顧客体験を作るデザイナーが意思決定速度を上げるために使うAI

AIの使い所

  • 最終成果物には使ってない
    • 中間成果物には使ってる
  • 関係者との相互理解
    • 6up Sketches
    • 6コママンガで顧客体験を書く
  • 作るもののイメージ共有
  • イラストの下書き
    • 生成AIを使っても良いのか?

画像生成AIでポータルサイトのサービス利用者イメージを作成した実例紹介

  • 株式会社ディーカレットDCP UI/UXデザイナー 鳥井 晋吾(TORII Shingo)さん

生成AIの利用ケース

  • サービスがまだローンチされてない
  • 利用者のイメージをAIに作らせて使ってる
  • それを使ってABテストしてる

レスポンシブウェブデザインで活用するAI

GUIでWebを作る

  • WixStudio
  • ノーコードのWebページ生成サービス
  • ドラッグアンドドロップでページを作れる
  • AIでレスポンシブにいい感じに作ってくれる

非エンジニアでもワイヤーフレームから爆速フロントコーディング!?

  • 株式会社IMAKE 代表取締役・UIUXデザイナー 濱野 将(HAMANO Sho)さん

生成AIでワイヤーフレームからコーディング

  • tldraw
  • ワイヤーフレームを作って対象を選択するとUIを作ってくれる
  • 文章で補足をすることもできる
  • 非エンジニアでも作れるのがいい

2024年3月に読んだ本

  • 2024年3月に読んだ本の記録です

ユーザビリティエンジニアリング

shop.ohmsha.co.jp

  • UXデザイン系の勉強会でオススメされたので読んでみました
    • 出版されてからけっこう経っているがこの分野の初心者向けの定番の本のようです
  • UXリサーチに関連する用語や調査手法が幅広く紹介されていました
    • 上述の勉強会で分からなかった用語がこの本のお陰でだいたい分かるようになりました
  • 実際にリサーチを行うにあたっての具体的なチップスがあるのが読んでるだけでもイメージがわいてよかった
    • 経験に基づいているところが説得力があっていい

持続可能なチームのつくり方

www.shoeisha.co.jp

  • デブサミの会場の書籍販売コーナーで見かけて気になったので読んでみました
    • タイトルからチーム開発みたいな内容かと思ったらIT関係なくマネージャー向けのチーム作りの本でした
  • 保健師や労働衛生コンサルタントをやってる人が書いた本
    • 健康的に働いていくためにマネージャーとしてどんなことができるか書かれています
    • 著者が出会った実例をもとに書かれており踏み込んだ内容が多く考えさせられる内容でした
  • 私自身としては部下がいたことはあるものの簡単な研修があったくらいでしっかり学ぶ機会がなかったので読んでよかった本でした

未来のモノのデザイン

www.shin-yo-sha.co.jp

  • デザイン系の勉強会に行った時に紹介されてたので読んでみた本
  • あらゆる自動化が進んだ未来においてどのようなデザインが必要か書かれた本です
  • 勉強会でも紹介された「ひとりごとが2つあっても対話にならない」というフレーズが序盤に出てきたのが印象的でした
    • 機械と人がやりとり出来るようになっても双方が一方通行な発信をしているだけではコミュニケーションにならない
    • バックグラウンドを共有した共通基盤を持てないことが原因
      • それを機械に求めることは難しい
    • 機械が人の考えていることを推測しようとすると、人にとって推測できない動きになってしまうので却ってコミュニケーションが取りづらい
      • 人にとって予測可能な動きをしてもらって人の補助として扱っていくのが効果的になりそう

「コミュニケーションデザイナーの現在地 〜タイミー×Gaudiy×コンセントのデザイナー5名が語る」に参加してきました

  • 2024/3/29
  • https://design-halfway01.peatix.com/
  • デザインのイベントですがデザイナーに関するインプットを幅広く増やしたいので参加してみました
  • コンセントの方々や他の参加者の方とたくさん話をすることができました
  • けっこうな数の勉強会に行ってますが今までで一番喋った気がします
  • 普段思ってることを聞いてもらえてありがたかったです

事業を理解し、伝え方をデザインすること

  • 太田 賢一さん|デザインマネージャー|株式会社タイミー

事業を理解する

  • スキマ時間で働いてもらうサービス
    • 募集人数の増加と稼働率の上昇がビジネスモデルとして大事
  • 企業がどこに投資してるのかなど理解すること

伝え方をデザインする

  • ありがとうの伝え方
  • どうやってだけじゃなくて全体を設計してコミュニケーションを設計するのが大事
    • 課題ってなんだっけに戻れること

コミュニケーションデザイナーの “コミュニケーション” がなくなると

  • 稲葉 潤さん|デザイナー|株式会社Gaudiy

Gaudiのコミュニケーションデザイナー

  • コミュニケーションデザイナーがいなかったら
    • Tシャツばっか作って乱立する
    • 会社らしさに瞑想する
      • こういう会社の見方どうですかってコミュニケーション
  • 会社らしさを定義して浸透させていくこと
    • 会社らしさをみんあに浸透できる

今後も"コムデ”を選ぶ上での自分の方向性を考えてみた

  • 田中 翔さん|コミュニケーションデザイナー|株式会社Gaudiy

コミュニケーションデザイナーとしてやってきたこと

  • いいところ探しのプロになる
    • 何が受け取る側のメリットになるか想像する
  • QCDの使い分け
    • タイミングスピードが最適なものを提供
  • デザインをデザイナーだけに閉じない
    • コラボレーションのハードルを下げる
    • デザイナー以外でも使えるアセット

課題悩み

  • 経験の水増しで現状維持しやすい
    • 社内受託的なポジションに甘んじやすい
    • 危険と同時にチャンス
      • 新しいなにかをやれるタイミング

クリエイティブの視点から、対話の場をつくる

  • 今野 綾香さん|コミュニケーションデザイナー|株式会社コンセント

コミュニケーションデザイン

  • クリエイティブのための対話を生み出す
    • 課題解決に向けて論点(フラッグ)を出す
  • クライアントが抱える課題とクライアントが考えるゴールに対してフラッグがたくさんある
    • フラッグを取捨選択して相手に合わせて言葉を選びながら対話の場を作る
  • フラッグがあることに来づけることが必要

あらゆるところに『コミュニケーションデザイン』はある

  • 青木 由季さん|コミュニケーションデザイナー|株式会社コンセント

コミュニケーションデザイナーの捉え方

  • コンセントでは
  • 届けたい相手がいる限りものでもことでもデザインできる

「Encraft #12 Frontend Quiz Night」に参加してきました

DOM Quiz

  • @yoshikoさん

クイズ

  • eventを一回だけ発火させたい
    • addEventListenerの第三引数に { once: true }
    • { passive: true } はpreventDefaultしない宣言
      • スクロールを監視してる時にパフォーマンスがよくなる
  • event.targetにくるもの
    • クリックが発生した要素
    • event.currenTargetにlistenerで登録した要素がくる
    • event.targetは大量の子にlistenerセットしたい時に親にlistener付与するとか
  • input type="number"を数値でとりたい
    • event.target.valueAsNumber

CSS Quiz

  • @zi-dotさん

クイズ

  • media queryのmin-width
    • 指定した値以上の時に適用される
    • 最近は <= とか使えてわかりやすい
  • flex: 1
    • flex-grow: 1; flex-shrink: 1; fkex-basis: 0;

TypeScript Quiz

クイズ

  • 関数の戻り値の推論
    • 文字列1つだとstring
    • 文字列2種類以上だと 'hello( | 'world' みたいな
  • satisfies
    • 型を満たしているかチェックしてくれる
    • 推論を尊重してくれる

「Figma開発モードで実装との合流点を語る | UI+FE合流点 feat. CyberAgent」に参加してきました

  • 2024/3/27
  • https://gaji-lt.connpass.com/event/310872/
  • FigmaのDevModeはベータの時に使ってましたが、知らない機能がたくさんあることが分かりました
  • デザイナーにとっても嬉しいということを初めて知ったので仕事でも使いこなしていきたいと思いました

Dev Mode

  • 谷 拓樹さん

DevModeとは

  • デザインをプロダクトにつなげる
  • 編集はできなくて参照だけ
    • デザインを壊す心配がない
  • 実装OKのマークを付けられる
    • dev modeで実装OKのものが識別される
  • Annotation
    • 注釈をつける機能
    • コメントだけじゃなくてstyleの値も選択して表示できる
  • 変更差分
    • 2つの要素を選択して差分を確認できる?
    • CSSのdiffも見える
  • Dev resource
    • 各データにリンクをつけられる
  • Component Playground
    • プレイグラウンドを開くとprimary/secondaryとか設定を変更して確認できる

ハンドオフ

  • デザイナーが作って開発者に渡す
  • 実際は一本道ではいかないことごおい
  • デザイナーと開発者のコラボレーションを助ける

共通言語の採用

  • Align(整える)
    • Variablesで名前をつければ出力されるCSSを見るとそれが反映される
    • Componentに名前をつけて実装とも統一していくといい
  • Inform(伝える)
    • コンポーネント自信のドキュメント化
    • 仕様やStorybookへのリンク
    • ボタンにどのアイコン使っていいかfigma上で設定できたり
    • annotationで注意すべきポイントに注釈できる
  • Connect(つなげる)

座談会

  • 谷 拓樹さん
  • 原 一成さん
  • 出口 裕貴さん

DevMode事情

  • Qiita まだエンジニアは使ってない
    • 編集権限あるデザイナーがannotationとか使ってる
  • Ameba
    • エンジニアは申請したら使えるように使える
      • 10人くらいのうちの半分くらい使ってる
  • プラン
    • DevMode専用のプランはまだない
    • proプランから使えるけど編集もできる

DevModeの推し機能

  • annotationでマークダウンが書ける
    • コードブロックが書ける
  • Annotationにメモを書いてコメントに議論を書いて使い分けられる
  • Compare Changesがない時は差分を伝えるために赤入れしてた

DdevModeの将来性

  • エンジニアがFigmaをさわる機会が増えそう
  • ハンドオフ(引き継ぎ)ではなく一緒に構築していく助けになる

「CI/CD Test Night #7」に参加してきました

業務で役立つ…かもしれない?!GitHub Actions Tips 集

matrix job

  • 似てるけど微妙にパラメータが違うジョブ
    • まとめて並列実行したい
  • matrix jobでパラメータを差し替えながら並列実行できる
    • バージョンとかOSだけ変えてまとめて動かすとか
    • 複数の条件の組み合わせで動かせる
  • inputにjsonを使えるのが便利
    • workflowの外からデータを注入できる
  • secretsを出し分けたい場面がある
    • matrixではkeyだけ指定して使うといい

動的job実行

  • Branch Protection
    • PR作成時にCIが通らないとマージできないとか
    • 条件にjobを指定できる
  • jobをフィルタリングしたくなることがある
    • 実行時間や課金面で毎回全部動かしたいわけではない
  • pathsフィルター
    • 特定のファイルが更新された時に実行させることができる
    • 対象外だった時にworkflowが動かずpendingでマージがブロックされてしまう
      • pathsフィルターとBranch Protectionの相性が悪い
  • paths-filterを使ってworkflowは実行しつつjobをフィルターできる
  • Status Check Job
    • このjobをpass/failさせることでBranch Protectionを機能させる
    • passの条件
      • exit 0で終わる
      • jobをスキップして実行されない

GITHUB_TOKEN

  • GitHub Actions上で利用可能なGitHubのtoken
  • GITHUB_TOKENによるコミットではworkflowをトリガーできない

CI/CD のセキュリティや Developer Experience を改善するツールやプラクティス

  • @szkdashさん

PRコメントでCIの結果通知

  • CIがこけたら原因をPRにコメントしたい
    • ログ見に行くよりすぐ見れてわかりやすい
  • github comment
    • コメントのテンプレートも用意できるので使うと見通しがよくなる
    • 古いコメントを非表示にして新しくコメントできる

複数リポジトリのメンテナンス

GItHub Actionsのセキュリティベストプラクティス

  • ベストプラクティス
    • jobのpermissionsを最小限
    • secretの公開範囲を最小step/job
    • Actionのバージョンをfull commit hashで固定する
  • ghalintでチェックできる
    • CIで実行してセキュリティを担保
  • ツールのバージョン固定
    • ツールが汚染されてもいきなり反映されない
    • コードを変更してないのにCIが壊れるようなことを防ぐ
    • バージョンやタグもあるが変更されることがある
      • フルコミットハッシュが一番安全
    • コードコメントでバージョンを書けばRenovateも見てくれる
      • バージョンはパッチまでしっかり書くと更新時の差分が見やすい

CIで使うツールの管理

  • バージョン固定
    • latestは突然壊れる
  • ツールの自動アップデート
  • shellでやるのは面倒
  • aqua

一歩先のセキュリティ

  • CIを書き換えられないようにする
    • 任意のコード実行を防ぐ
    • 強い権限与えないといけない時特に
    • pull_request_target event
  • feature branchのスクリプトを実行するのは危険

古いrevisionでの実行を防ぐ

  • defaultブランチの最新のHEADかチェック

CI/CDがあたりまえの今の時代にAPIテスティングツールに求められていること

runn

runnの機能

  • 1バイナリで作られてる
  • さまざまなプロトコルに対応
  • OpenAPI Specライクなシナリオ
  • 複数のシナリオが想定されている
    • 分割実行
    • サンプリング実行
    • ランダム実行
  • プロファイルの取得
  • ステップ実行できる

APIテストのモチベーション

  • アプリケーションの外側からテストしたいというニーズ
  • スモールテストよりコストが高い
    • 実装コスト
      • 環境整備が面倒
    • 実行コスト
  • CIでの自動実行が前提になってる
    • コンピューティングリソースは気にならなくなった

APIテスティングツールに求められること

ChainingRequestに対応していること

  • 複数リクエストで成り立つテストが求められる
  • 個別に作るより実は低コスト

親和性の高いテストダブル環境

  • 規模が大きくなりがち
  • テストダブルをアプリの外で構築できると望ましいが難しい
  • Postmanはstubサーバのサポートがある
  • runnはないので自前でstubサーバ動かしてやる

テストケースにIDがあること

  • テストを一意にできるIDが必要
    • 全てを毎回実行するのはコストが高い
  • IDとメトリクスの連携
    • 特定のものだけリトライとか
    • 実行時間を特定するためにとか
    • よく失敗するのを先にとか
    • IDを使うと柔軟にできる
  • runnは自動で動的に生成してる

APIスキーマとの連携がある

  • テストケース自体がある程度正しいことを確認したい
  • runnでは各ランナーにAPIスキーマを設定できる

ポータビリティがある

  • 開発環境とCI環境で同一の環境にしやすいこと
  • 負荷試験としても活用できる
  • 本番強への外形監視/計測として使える
  • runnではいろんな環境で使えるようにしてる

リリース戦略を支えるCI/CDパイプライン

  • @katzchumさん

リリース管理のつらみ

  • システムが複雑になり依存が増えると管理が複雑になる
    • リリース判断できる人が固定化されてくる

リリース戦略の事例

  • 複数バージョンが並行するプロダクト
    • クライアントによってバージョンが違う
  • リリーストレイン
    • リリースの日が決まっていて間に合ったものだけリリースする
  • ブランチカットするタイミング
    • リリース日が未定な状態でもタグをつける
    • 開発環境にデプロイするタイミングでタグつける
  • タグはOSSの開発スタイルに倣う
    • セマンティックバージョニング
  • tagpr

「AI4D Gathering @虎ノ門」に参加してきました

  • 2024/3/25
  • https://connpass.com/event/312085/
  • 生成AIの事例をいくつも聞けて、デザインの領域でのAI活用が盛んなんだなという印象でした
  • 自分ももっと活用できるのかもと思えたので工夫してみたいと思った
  • デザイナーの人たちといろいろ話せたのも楽しかったです

生成AIプロダクト開発におけるプロセスシェア

生成AIプロダクト

  • 法人向けに生成AIプロダクトを作っている
  • PoCやって検証して製品を作った

プロジェクトの目的整理

  • 生成AIを使うのが目的か、生成AIがマッチしてそうだから使うのか目線を合わせる
  • 生成AI使ってどんなもんかを検証したいから前者だった

SEPIA法での分類

  • AIに興味ある軸と業務への理解度の軸に分ける
    • システムを使う気があるか、自信を持って使えるか
    • AIへの関心と業務の詳しさで4象限つくると属性ごとに課題感を持っていた
    • 不慣れな人はプロンプト分からない

独自の軸での分類

  • プロダクトに詳しい軸とAIリテラシーの軸に分ける
    • 初心者も対象にしたかった
    • プロダクト詳しくてAIリテラシー低いユーザが盲点だった
    • 1回目と2回目の利用といったUXの時間軸で区切ってみたがしっくりこなかった

プロダクトを理解するための機能設計

  • サービス機能を充実化させてプロダクトを理解させる
  • マニュアルは読まれない
  • プロダクトに詳しくなってもらってからAIリテラシーを高めてもらった

機能の価値を再定義

  • 戦略ターゲットから機能の価値を再定義
  • プロンプトテンプレート
    • プロダクトに詳しいがAIリテラシー低い人を引き上げる

導入担当者のためのUX設計

  • 導入担当者の目線でUX設計する
  • DX推進者は効果を上司へ報告しやすくしたい

生成AIを活用した動画制作による共創アプローチの可能性

  • 有澤寛則さん/富士通株式会社 デザインセンター フロントデザイン部

生成AIを活用した動画制作

  • 日本酒づくり
    • 飲み手を巻き込んで作る
    • 音楽で醸造に参加
  • =>コンセプトムービーをAIで作った

動画作成のプロセス

  • 人の手と生成AIを組み合わせ
    • ChatGPTで絵コンテ作成
    • 人がシナリオ精査
    • AdobeFireflyで画像生成
    • runwayで動画生成

生成AIを使った動画

  • 特徴
    • 人の手で作るよりクオリティは下がってしまう
    • 制作時間は圧倒的にはやい
  • 議論しながら一緒に作るのに向いてそう
    • 余白のあるラフコンセプト動画をもとに進めるといい
    • お客さんのアイデアを上乗せした新しいコンセプト動画を作れる

AIとブランドを作る。UXライティングにAIを活用する方法

分類して使い分ける

  • AIでできること
    • 壁打ち
      • 何もわからない時
    • 起案
    • 発散
      • いいと思ったことのニュアンスが違うものを探す
    • 客観視
      • 客観的なレビューが欲しい時
    • 精査
      • 細かいところの精査
      • 言い回しや文章が変じゃないか

ブランドを守る

  • noteのUXライティング
    • 言い回しが親しみやすい感じで特徴的
    • 80%までAIで作って最後は人間がチェックしている
  • UXライティングやブランドの基準を持っておくこと
    • noteさんという人格を作っている
    • noteさんならそうは言わないでしょとか

情報設計フェーズでの生成AIとの協業

  • 池田拓司さん/株式会社くふうカンパニー

アバターと生成AIの融合、UIの可能性を探る

  • 岩﨑勝利さん/AVITA株式会社

UXライターが語る「生成AIはプロンプトが9割」

ユーザーとシステムを繋ぐエージェントUX

  • 亀田重幸さん/ディップ株式会社

「Object-Oriented Conference 2024」に参加してきました

オブジェクト指向のリ・オリエンテーション ~歴史を振り返り、AI時代に向きなおる~

  • 羽生田 栄一さん

オブジェクト指向の嬉しいところ

  • プリミティブだけじゃなくてドメインに対して操作できるようになった
    • 意味のある領域にクラスを割り当ててプログラミングできるのがいい
    • 概念を使ってプログラミングするのを可能にした

オブジェクト指向の段階

  1. オブジェクト指向ミニマム
    • idを持っていて1つ1つ区別できる
    • カプセル化された状態をもっている
  2. 責務/ロールの概念整理
    • メッセージへの応答能力
    • 存在理由を1つに定めて1つの責務を果たす
    • SRP(Signle Responsibility Principle)
  3. クラス/継承/ポリモフィズム
    • 意味のあるメソッドが体系付けられてクラスの中に閉じ込める必要がある
    • リスコフの置換原則が理解できてないなら継承を使うな
    • 継承はサブタイピングとして強い型付けを意識
  4. 構造主義的なオブジェクト指向
  5. レイヤー化
    • 依存関係の制御

オブジェクト指向と関数型

生成AIの不確実性と向き合うためのオブジェクト指向設計

  • 菊池 琢弥さん

生成AIのユースケース

  • copilotなどの開発での活用ではなくプロダクトへの埋め込みの話
  • 技術視点から
    • システムで扱いにくかったデータが扱いやすくなる
      • 表記揺れの吸収とか
        • 文脈を意識した分類とか
  • 体験から
    • 自動化(Automation)
    • 代行(Agent)
    • 助言(Advice)
    • 強化(Augment)

クソコード動画『カプセル化 Mk-II』で考える、上手くカプセル化できない理由

  • ミノ駆動さん

カプセル化と関心

  • データとデータ操作ロジックをひとまとめにすること
  • 正常に操作可能なメソッドのみ公開する
    • setterは不整地も含めて代入できてしまうため避けること
  • 関心ごとに構成を分離する
    • Aを修正してもBに影響がでないように

目的と手段

  • システム手段で実現したい目的があるはず
  • 目的には下位目的が発生する
    • それぞれの目的を達成するための手段を用意する
  • 目的が決まると達成したいことが決まる
    • それぞれの目的に必要な要素は異なる
  • [上位目的]商品を売買したい
    • [下位目的]在庫管理したい/注文したい/配送したい
  • 手段に紐づく目的は1つ
    • 目的外の利用はだめ
    • システムでも一緒とのこと
    • 特定のクラスが多目的に使われると崩壊する
    • 手段からみて目的が1つになるように設計するといい

モデリング

  • ECサイトで「商品モデル」を作ると巨大化する
    • 中心的になるモデルはあらゆる目的に紐づいてしまう
  • 目的論的抽象/存在論的抽象
    • 存在論:魚類
    • 目的論:夕食の素材
    • 存在論では目的に合う要素だけをうまく抽出できない
  • モデル
    • ある目的を達成するために目的に合致した特徴のみを抜き出し他を捨て去ったもの
  • モデリング
    • 特徴を抜き出し他を捨て去る活動

DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁

  • pospomeさん

DDDを理解する

  • ドメイン
    • 領域
    • ユーザがソフトウェアを適用する対象領域
  • DB駆動設計
    • テーブルと1対1でクラスを作る
    • 複数のクラスにまたがるロジックの置き場所に困る
    • FatModelかドメインモデル貧血症になる

良いコード

  • ICONIX
    • 図を書いて設計に落とす
  • 実装ファーストで考えるのが良い
    • 図を書くだけではうまく設計できない
  • 保守性
    • モジュール性
    • 再利用性
    • 解析性
    • 修正性
    • 試験性

設計能力の壁

  • 基礎力が必要
    • よくある原則的なもの
  • DDDの本はプラクティスを教えてくれるだけ
  • 時間を消費する割に品質がそれほど高くないものになってしまう

ビジネスロジックを「型」で表現するOOPのための関数型DDD

関数型DDD

  • 関数型のエッセンスを加えてビジネスロジックを型の力で柔軟にしたDDD
  • 型があると実装ミスをコンパイルで検知できる
  • 例えば特定の条件のときだけ値があるフィールド、みたいなものをコンパイルで検知できる

モデルの状態を代数的データ型で表現する

  • 特定の条件のときだけ必須の項目
  • コンストラクタで検証する?
    • 実装なのでテストしないといけない
  • 状態ごとにモデルを作ると良い
    • 注文取得したときのどの状態か分からないのでanyにするしかないのが課題
    • 各ステータスの注文をまとめて扱いたい
  • 代数的データ型
    • 直積集合と直和集合で表される構造体
    • 継承はどんな子クラスがあるか制限できないのが違う(直和の性質がない)
    • Enumは個別の構造体が持てない(直積の性質がない)

モデルの状態遷移を型と全域関数で表現する

  • ステータスの繊維のダメなルートをコンパイルで落としたい
  • ルールの適用と違反時のハンドリングがある
    • 前者を型で守る
    • 校舎はテストで担保
  • 関数の全域性
    • すべての入力が対応する出力を持つこと
    • inputが決まるとすべてのoutputが同じ挙動をするもの
    • ルール違反になるパターンが有るときはinputの型を絞る
      • 割り算で0以外の整数の方を作ると全域関数になる

ロジック内のDBアクセスを高階関数で表現する

  • DBアクセスの理想
    • 最初に全部読み込み、処理して、最後に書き込み
    • ドメインモデルがシンプルになってテストが書きやすい
  • ドメイン層に隠蔽したいところだけを高階関数にする

設計の知識と技能で駆動するソフトウェア開発

はじめに

  • 開発プロセスの中に開発と設計がある
    • 設計が良いと開発が楽になる
  • 設計は経験則の面も大きい
    • 技能として身につけるには手を動かすことが重要
    • 知識と技能を持ち寄って組み合わせるとさらにレベルアップする

ソフトウェア設計の基礎知識

  • 基本課題
    • 本質的な複雑さ/発展性に対応できない
    • 巨大なモノリス/大きな泥団子
  • 解決アプローチ
    • 関心の分離
    • 部品化
    • モジュール化
      • 交換容易性
      • 交換するかは置いておいてできる状態になってるのがいい状態
  • 基本となる技法
    • モジュラー性
      • モデル(要約)
      • カプセル化(自立性)
      • 直接的な写像(分かりやすい構造)
      • 仕様(意図の伝達)

モジュール設計スタイル

  • モジュールの設計スタイルの分類
    • 抽象化の方向
      • 機能/データ
    • 用途
      • インバウンド/アウトバウンド/演算
    • 状態の扱い
      • 可変/不変
    • システム構築の原理
      • ブレークダウン/ビルドアップ
  • オブジェクト指向の設計スタイル
    • データ/演算/不変/ビルドアップ
    • クラスとメソッドで演算ロジックをモジュール化
  • ドメイン駆動設計の設計スタイル
    • データ/演算/不変/ビルドアップ
    • 複雑な業務ロジックに焦点を合わせる

アプリケーション全体のモジュール構成

  • ポート&アダプターの設計スタイル
    • コア
      • 業務ロジック(データ/演算/不変/ビルドアップ)
      • アプリケーション(データ/演算/可変/ブレークダウン)
    • アダプター
      • プライマリ(機能/インバウンド/可変/ビルドアップ)
      • セカンダリ(機能/アウトバウンド/可変/ビルドアップ)
  • コアの分析設計に投資する
  • コアの実装
    • 高密度/強度/交換容易性
  • アダプターの実装

モデル駆動設計

全体

  • 事業活動モデル/基本設計
    • 事業活動を最適化するのが目的
    • いろいろな制約の中で何が貢献できるか

コア

  • 業務ロジックモデル/ドメインモデルのクラス設計
  • 業務機能モデル/アプリケーションサービスのクラス設計

アダプター

オブジェクト指向は必要なのか

初心者にとってのオブジェクト指向

  • 初心者が目指すべきものみたいになってる
    • 初心者にとってはすぐに学ばなくて良いもの
  • オブジェクト指向という言葉が曖昧
    • その中の要素を別の名前として定義した方が良い

オブジェクト指向の定義

抽象データ型

  • データの操作だけを公開することで変更に強く柔軟
  • データのカプセル化

オブジェクト指向と関数型D

  • 区分けに意味はない
  • オブジェクトと関数は可換

デザインパターン

  • デザインパターンは言語に足りない機能の補完
    • 多くのパターンが言語の機能導入で不要になっている

オブジェクト指向の使い所

  • オブジェクト指向は状態管理技術
    • I/O
    • List
  • 状態管理はモジュールの協会に現れる
    • DOM/HTTP/DB接続