Webサイトのアクセシビリティにどう向き合う？ / How Should We Approach Web Accessibility?

Slide 1

Slide 1 text

Webサイトのアクセシビリティにどう向き合う？ @ymrl MTDDC Meetup TOKYO 2024 2024年11⽉23⽇

Slide 2

Slide 2 text

このセッションは SNS共有OK 写真撮影OK スライドのURLはTwitterのハッシュタグに流します

Slide 3

Slide 3 text

⾃⼰紹介 ● ⼭本伶（@ymrl） ○ ふだんは「やまある」と呼ばれていることが多いです ○ フリー株式会社デザイナー/エンジニア ● 2017年ごろからfreee社内のアクセシビリティの活動を始める ○ 2019年、社内デザインシステムの構築のためにデザイナーに転⾝ ● 2023年、共著書「Webアプリケーションアクセシビリティ」出版 ● freeeの社外では、他社のアクセシビリティ改善の⽀援や、アクセシビリティチェックのためのツール開発などもしています

Slide 4

Slide 4 text

今⽇お話すること ● そもそもアクセシビリティとは？どんなもの？何のためのもの？ ● 法律で定められているの？ ● アクセシビリティのガイドラインとは？ ● そもそも何から始める？どうやって進めていく？ ● 話さないこと: HTMLやJavaScriptやデザインのテクニック ○ そのあたりは「Webアプリケーションアクセシビリティ」で

Slide 5

Slide 5 text

そもそもアクセシビリティとは？

Slide 6

Slide 6 text

「アクセシビリティが⾼い状態」とは…… ● 障害者や⾼齢者を含めて、より幅広い⼈たちが使える ● ユーザーの能⼒や、操作⽅法や、デバイスやブラウザの多様さに対応できる ○ 視覚的に⾒やすい⽂字‧⾊彩‧レイアウト ○ わかりやすい⾔葉遣い、わかりやすいサイト構成 ○ 動きや⾳がユーザーの邪魔をしない ○ PCでもスマホでも使える、ChromeでもFirefoxでもSafariでも使える ○ キーボードでも操作できる、スクリーンリーダーでも読める

Slide 7

Slide 7 text

なぜアクセシビリティが重要なのか ● マイノリティを差別しないため、権利を守るため ○ 知る、教育を受ける、働く、健康で⽂化的に⽣きる、etc… ● 幅広いニーズを取りこぼさないため ○ 顧客になるかもしれない⼈がアクセスできなかったら……？ ● あらゆる⼈にとっての価値を⾼めるため ○ ⼈によって⾒え⽅‧感じ⽅‧使い⽅は異なる ○ あらゆるニーズに応えられるWebサイトはあらゆる⼈に使いやすい

Slide 8

Slide 8 text

アクセシビリティに取り組むことで、多様なユーザーの多様なニーズに応えられる

Slide 9

Slide 9 text

ユーザビリティとアクセシビリティ ● 誰かにとっての使いやすさ: ユーザビリティ ○ ターゲットとなるユーザーと利⽤状況を限定する ○ その⼈にとっての効果‧効率‧満⾜度‧⽬標の達成度合い ● 使える⼈‧状況の広さ: アクセシビリティ ○ ターゲットを限定しない（障害者や⾼齢者にも限定しない） ○ どんな⼈‧どんな利⽤状況であっても、まず使えることを⽬指す ○ その上で、使いやすい状況になっていれば、なお良い ● ⼭を⾼くするのがユーザビリティ、裾野を広げるのがアクセシビリティ

Slide 10

Slide 10 text

間嶋沙知『⾒えにくい、読みにくい「困った！」を解決するデザイン』（マイナビ出版）より引⽤

Slide 11

Slide 11 text

Webアクセシビリティと⼈権

Slide 12

Slide 12 text

Webアクセシビリティは⼈権である ● 私たちはWebからさまざまなものを得て⽣活している ○ 調べもの、学習、仕事、ニュース、娯楽、etc…… ○ もはやWebは私たちの⽣活に必要不可⽋なもの ● 障害者権利条約（2006年採択）では、守られるべき障害者の⼈権のなかに、インターネットも含む情報通信機器‧サービスへの⾔及もある ● 諸外国では、Webアクセシビリティに関する法律を定めている国も多い ○ アメリカでは障害者が障害を理由に使えないWebサイトは裁判で負ける

Slide 13

Slide 13 text

⽇本の法律では…… ● 障害者権利条約によって、障害者関連の法律の整備が進んだ ● 2024年4⽉に施⾏された障害者差別解消法の改正により、⺠間事業者でも「合理的配慮の提供」が法的に義務化 ● このとき「Webアクセシビリティが義務化！？」という情報が錯綜 ● Webのアクセシビリティは「合理的配慮」でない、つまり義務ではないが「環境の整備」として努⼒義務であるという⾒⽅が⼀般的 ○ 内閣府の資料でもそういう扱いになっている

Slide 14

Slide 14 text

障害者権利条約での「障害」の捉え⽅: 社会モデル ● 従来の考え⽅: 医学的な観点から「障害者」を定義（医学モデル‧個⼈モデル） ○ 「障害」は個⼈の側に存在する ● 障害の社会モデル: 社会が不便なせいで、その⼈は「障害者」になっている ○ 「障害」は社会の側に存在する（社会的障壁） ● 社会モデルの考え⽅では、社会の不便なこと = 「障害」を解消していけば、本⼈の状態が変わらなくても、「障害者」を減らしていくことができる ○ 例: 階段でしか2階に上がれない建物では、⾞いすの⼈は「障害者」エレベーターが整備され2階に上がれるようになれば「障害者」ではなくなる

Slide 15

Slide 15 text

社会は急には変わっていかないので、合理的配慮が必要 ● 障害者からの求めに応じて、過度な負担にならない範囲で、不便を解消する調整を⾏うのが、合理的配慮（reasonable accommodation） ○ 障害者の状況にあわせたアドホックな対応（運⽤でカバー） ○ 例: 聴覚に障害のある⼈との会話を、筆談や⾳声認識アプリで⾏った ○ 例: ⾞いすの⼈のために、通路を広くしたり机の⾼さを調整したりした ● 必要になりそうな合理的配慮をシミュレーションしたり、研修したり、そもそも不便な状況が起きないように改善していく: 環境の整備

Slide 16

Slide 16 text

Webサイト運営者に求められること ● 環境の整備として、アクセシビリティの⾼いWebサイトを⽬指す努⼒義務 ○ 現状を評価し、アクセシビリティに関する計画を⽴て、改善する ○ 制作‧運⽤に関わるメンバーに向けて周知や研修を⾏う ● 合理的配慮として、Webサイトを利⽤できないユーザーが申し出た場合に、過度な負担のない範囲で対応する義務 ○ メール、電話、対⾯、etc……（Webが頑張れば減らせる！）

Slide 17

Slide 17 text

freeeの事例: 合理的配慮に関する窓⼝の設置 ● 以前からWebアプリやWebサイトのアクセシビリティ向上に取り組んでいた ○ 本当に困っている⼈が、躊躇なく申し出ることができるだろうか ○ 申し出を受けたメンバーが、適切に対応することができるだろうか ● 2024年に「合理的配慮の対応⽅針」と「合理的配慮委員会」を設置 ○ 合理的配慮に関する⽅針と、社外‧社内に向けた相談窓⼝ freee、「合理的配慮の対応⽅針」公開のお知らせ障害のあるお客様等が「合理的配慮」について相談できる専⽤のお問い合わせ窓⼝を設置 https://corp.freee.co.jp/news/20240625_gouritekihairyo.html

Slide 18

Slide 18 text

Webアクセシビリティの基礎知識

Slide 19

Slide 19 text

⽀援技術 (Assistive Technology) ● 不便を抱えている⼈を⽀援するためのハードウェア、ソフトウェア ● ⾒えない‧⾒えづらい →メガネ‧拡⼤機能‧スクリーンリーダー（画⾯読み上げソフト）‧点字ディスプレイ ● 聞こえない‧聞こえづらい →補聴器‧⼈⼯内⽿‧⽂字起こしアプリ ● ⼿や腕を動かせない‧動かしづらい‧道具を保持しづらい →キーボード操作スティック‧視線や⾳声やタイミングによる⼊⼒‧機材ホルダー ● ⾔葉が難しい‧読み書きが苦⼿ →機械翻訳‧読み上げ‧⾳声⼊⼒

Slide 20

Slide 20 text

伊原⼒也，⼩林⼤輔，桝⽥草⼀，⼭本伶『Webアプリケーションアクセシビリティ――今⽇から始める現場からの改善』（技術評論社）より

Slide 21

Slide 21 text

⽀援技術の代表例: スクリーンリーダー ● おもに視覚障害者が利⽤する、画⾯を読み上げるソフトウェア ● PC⽤のOSに搭載: ナレーター(Windows), VoiceOver (macOS) ● Windows⽤: PC-Talker, NVDA, JAWSなど ● スマートフォン⽤: VoiceOver (iOS, iPadOS), TalkBack (Android) freeeアクセシビリティー‧ガイドライン内に使い⽅などを掲載しています https://a11y-guidelines.freee.co.jp/explanations/screen-reader-check.html ※ ぜひ試してもらいたいのですが、終了⽅法を確かめてからにしてください

Slide 22

Slide 22 text

WCAG (Web Content Accessibilty Guidelines) ● W3C（Web技術の標準化団体）によるWebアクセシビリティのガイドライン ○ 最新版は昨年勧告となったWCAG 2.2 ○ WCAG 2.0がJIS X 8341-3:2016やISO/IEC40500:2012と⼀致 ● WCAGのほかに解説書 (Understanding) と達成⽅法集 (Techniques) がある ● ⽇本語訳をWAIC（ウェブアクセシビリティ基盤委員会）が公開 ○ WCAG 2.2の解説書と達成⽅法集は現在翻訳中 WCAG 2.2で追加された達成基準の解説のみ⽇本語版が公開されている

Slide 23

Slide 23 text

WCAGと関連⽂書のURL ● WCAG 2.2 ⽇本語訳 https://waic.jp/translations/WCAG22/ ● WCAG 2.2 解説書 https://waic.jp/translations/WCAG22/Un derstanding/ ● WCAG 2.1 達成⽅法集 https://waic.jp/translations/WCAG21/Te chniques/ ● WCAG 2.2 https://www.w3.org/TR/WCAG22/ ● Understanding WCAG 2.2 https://www.w3.org/WAI/WCAG22/Unde rstanding/ ● Techniques for WCAG 2.2 https://www.w3.org/WAI/WCAG22/Tech niques/

Slide 24

Slide 24 text

Webアクセシビリティの4原則 ● 知覚可能: Web上の情報をユーザーが知覚できる ● 操作可能: クリックや⽂字⼊⼒を受け付ける部分を操作できる ● 理解可能: 書かれている内容、画⾯の変化、次にやることを理解できる ● 堅牢: 将来にわたって幅広く互換性がある WCAGでは、これらの4原則に沿って達成基準が定義されている

Slide 25

Slide 25 text

WCAGの適合レベル ● 達成基準ごとに、A‧AA‧AAAの3段階のレベル分けがされている ○ レベルAの項⽬は満たしていないことが致命的になるものが多い ○ レベルAAAには実現がかなり困難なものも含まれる ● どのレベルまでを達成するか⽬標を⽴てるのに使⽤したり、どの程度のアクセシビリティの⾼さなのかを説明するのに使⽤する ○ 例: レベルAのすべての項⽬と、レベルAAの特定の項⽬に適合します

Slide 26

Slide 26 text

WCAGのバージョンと国際規格 ● WCAGの最新バージョンは2023年10⽉に勧告となったWCAG 2.2 ○ JIS X 8341-3:2016, ISO/IEC 40500:2012 となっているWCAG 2.0とは互換性がある（達成基準がいくつか追加され、1つ廃⽌された） ● WCAG 2.1以降スマートフォンを意識した達成基準が追加されているため、 JIS準拠を求められている場合でも、WCAG 2.2 も確認したほうが良い ● W3CはWCAG 2.2の内容でISO/IECを改正するための準備をしている ○ ISO/IEC 40500が改正されると、JIS X 8341-3:2016も改正される⾒込み

Slide 27

Slide 27 text

WCAGの達成基準の達成⽅法の例 ● 画像に代替テキストをつける: 1.1.1(A) ● Webサイトに埋め込まれている動画に字幕をつける: 1.2.2(A) ● ⽂字の⾊をコントラスト⽐の⾼い配⾊に変更する: 1.4.3 (AA), 1.4.6 (AAA) ● レスポンシブレイアウトにする: 1.4.10 (AA) ● ボタンなどをキーボードで操作できるようにする: 2.1.1(A), 2.1.3(AAA) ● エラーメッセージの表⽰⽅法や内容を丁寧にする: 3.3.1(A), 3.3.3(AA)

Slide 28

Slide 28 text

Webアクセシビリティのはじめの⼀歩

Slide 29

Slide 29 text

ふたつのアンチパターン ● Webサイト全体のリニューアルまで放置する ○ 困っている⼈は困ったまま、問題のあるコンテンツは増えつづける ○ コンテンツの増加によって予算は膨らみ、スケジュールは遅延する ○ もちろんリニューアルはアクセシビリティ⼤幅向上のチャンスではある ● ボタンを置くだけでアクセシビリティ対応完了！みたいな製品を導⼊する ○ 常に拡⼤や読み上げが必要な⼈は、個別のWebサイト上のボタンは不要 ○ 致命的に問題のあるコンテンツは改善できず、そのまま残り続ける ○ 便利に感じるユーザーはいるかもしれないが、根本の解決ではない

Slide 30

Slide 30 text

なにから始めるのか？ ● アクセシビリティを必要としている⼈たちのことを知る ● Webサイトの現状を評価する ● できるところから改善をしはじめる

Slide 31

Slide 31 text

アクセシビリティを必要としている⼈たちのことを知る ● 「⾒えにくい、読みにくい『困った！』を解決するデザイン」（書籍） ○ 様々な登場⼈物の「困った！」が紹介されている ● インクルーシブなペルソナ拡張 ○ デザインの過程で定義するペルソナに障害や利⽤状況の属性を付加する ● どんなことに困るのか？をまずは知る ● 当事者と話せそうなら話を聞いてみる⾒えにくい、読みにくい「困った！」を解決するデザイン登場⼈物 https://komatta-design.studio.site/persona インクルーシブなペルソナ拡張 https://accessible-usable.net/2018/05/entry_180517.html

Slide 32

Slide 32 text

Webサイトの現状を評価する ● サイト全体をチェックするのは⼤変 ● デジタル庁の「ウェブアクセシビリティ導⼊ガイドブック」を読みながら、サイトのいまの状況をざっくり把握する ● 意外とできていることも、全くできていないこともあるはずウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook

Slide 33

Slide 33 text

できるところから改善をしはじめる ● ⾮⼲渉の要件からやる ● 機械的なチェックで⾒つかるところからやる ● 知覚可能の観点からやる ● キーボード操作からやる

Slide 34

Slide 34 text

⾮⼲渉の要件からやる ● すべてのページで満たさなければいけないとされている、4つの達成基準 ○ ⾳声の制御（1.4.2） ○ キーボードトラップなし（2.1.2） ○ 3 回の閃光、⼜は閾値以下（2.3.1） ○ ⼀時停⽌、停⽌、⾮表⽰（2.2.2） ● どれも、ページの閲覧や他のページへの移動を困難にしてしまうもの ○ 該当するページがある場合は、すぐに直したほうが良い ● ウェブアクセシビリティ導⼊ガイドブックでは「重⼤」と記載

Slide 35

Slide 35 text

⾳声の制御（1.4.2） ● 3秒以上の⾳声を⾃動再⽣させない ○ ⾳の出る動画を含む ● ⾃動再⽣する場合には停⽌や⾳量調整ができるようにする ● ⾳声が邪魔でスクリーンリーダーによる⾳声読み上げでの利⽤が困難になる ● ⾳声により、視覚コンテンツへの集中⼒を妨げられてしまうウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook

Slide 36

Slide 36 text

キーボードトラップなし（2.1.2） ● Tabキーによるフォーカス移動で、抜けだせなくなる場所がないようにする ● むかしはFlashによってよく発⽣したが、今はあまり存在しないかもしれない ○ JavaScriptプログラムのミスにより発⽣することは有り得る ● モーダルダイアログ内にフォーカスを閉じ込め、閉じるまで抜け出せないのはOK ○ ただしキーボード操作で閉じられるようになっている必要があるウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook

Slide 37

Slide 37 text

3 回の閃光、⼜は閾値以下（2.3.1） ● 1秒間に3回以上光るものを作らない ○ （または減光処理をする） ● 光感受性てんかんの発作を引き起こす ● いわゆる「ポケモンショック」ウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook

Slide 38

Slide 38 text

⼀時停⽌、停⽌、⾮表⽰（2.2.2） ● 5秒より⻑く動きつづけるコンテンツは、⽌めたり消したりできるようにする ○ ⾃動で切り替わっていく、バナーや写真などの画像（カルーセル） ○ アニメーションの演出 ○ ⾃動再⽣されている動画 ● 動き続けるものが⽬に⼊ると集中⼒を奪われてしまう障害のある⼈に影響があるウェブアクセシビリティ導⼊ガイドブック https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook

Slide 39

Slide 39 text

知覚可能の観点からやる ● Webアクセシビリティの4原則（知覚可能‧操作可能‧理解可能‧堅牢）の最初の3つは、知覚ができなければ、操作や理解もできないことになる ● 知覚可能の達成基準（1.X.X）から着⼿するのは、特に静的なページの多い Webサイトで有効 ● 画像の代替テキスト、動画の字幕や書き起こし、⾊のコントラスト、 HTMLの記述順、マウスオーバーによる表⽰など……

Slide 40

Slide 40 text

機械的なチェックで⾒つかるところからやる ● Lighthouseの「ユーザー補助 (Accessibility)」で採点できる ○ 採点に使われるaxe-coreは、axe DevToolsとして単体で使える（アクセシビリティの評価ではaxe DevToolsのほうが使いやすい） ● 機械によるチェックだけでは完璧なチェックはできないので注意 ○ WCAGの全ての項⽬をチェックできるわけではない ○ 間違ったやり⽅でスコアを上げると、アクセシビリティをむしろ下げる

Slide 41

Slide 41 text

キーボード操作からやる ● スクリーンリーダーをはじめ、キーボードによる操作をする⽀援技術は多い ● 静的なページの多いWebサイトでは、「操作」をする場所は少ないはず ○ リンク（普通にやっていればキーボードで操作できる） ○ フォーム（普通にやっていればキーボードで操作できる） ○ JavaScriptにより制御しているところ ■ 開閉するやつ、カルーセル、モーダルダイアログ、etc…

Slide 42

Slide 42 text

アクセシビリティに本格的に取り組む

Slide 43

Slide 43 text

アクセシビリティを必要としている⼈のことを知る ● ユーザーに会ってみる、当事者に会ってみる ○ ⾃社のユーザー内で探す、クラウドソーシングを活⽤する ● 体験してみる ○ ⾊のシミュレータ、ロービジョン体験キット ○ キーボードだけで、いろんなWebサイトを操作してみる ○ スクリーンリーダーで、いろんなWebサイトを読んでみる https://a11y-guidelines.freee.co.jp/explanations/screen-reader-check.html

Slide 44

Slide 44 text

アクセシビリティを網羅的にチェックする ● WCAGの達成レベルに基づいた「どこまでやる」の⽬標を⽴てて、⾃分たちの現在地点はどこなのかをチェックする ○ 本当は最初にやるべきです ○ アクセシビリティ向上を視野にいれたリニューアルでは必須 ● 状況の把握が⽬的なら、代表的ないくつかのページをチェックするでも良い ● ⽬標を⽴てるのもチェックするのも、いきなりやるのは難しいので、 freeeの公開しているガイドラインとチェックリストを活⽤してください

Slide 45

Slide 45 text

https://a11y-guidelines.freee.co.jp/

Slide 46

Slide 46 text

freeeのガイドラインとチェックリスト ● WCAGのAAと⼀部AAAの達成基準と対応するように作られている ○ ⼀部に基準を変更しているものがある ● チェックリストはデザイナー⽤‧エンジニア⽤‧QA⽤が⽤意されている ○ できあがっているサイトには「プロダクト」（QA⽤）を使⽤する ● ツールの使い⽅など、いろいろな参考情報がガイドラインのサイト内にある ● JISやWCAGへの適合が求められる場合には、JISやWCAGを使⽤してください

Slide 47

Slide 47 text

47 UXチームがUIデザインを作成→エンジニアが開発→QAチームがテストの流れがあるので、   デザイナーがデザイン、エンジニアがコード、QAがプロダクトのアクセシビリティチェックを行う   チェックのタイミング（プロダクト開発）   デザイナー   エンジニア   QA  デザインの  アクセシビリティチェック   コードの  アクセシビリティチェック   プロダクトの  アクセシビリティチェック   freeeの研修資料「アクセシビリティー研修 Basic」より引⽤ https://developers.freee.co.jp/entry/a11y-training

Slide 48

Slide 48 text

サイトのリニューアルはアクセシビリティ向上チャンス ● サイト全体のナビゲーションや、共通のナビゲーション、テンプレートなど単体のページだけの修正では直せないものを直すチャンス ● サイトの要件定義に、具体的なアクセシビリティ要件も⼊れておく ● ナビゲーション設計やコーディングなどの各所でチェックを実施する ● 制作‧運⽤のプロセスを、アクセシビリティを前提としたものに変える

Slide 49

Slide 49 text

機械的なチェックをプロセスに組み込む ● axe-core（Lighthouse, axe DevTools） ● markuplint, eslint (jsx-a11y, vuejs-accessibility), biome ● コーディング時にチェックするほか、コンテンツの追加更新時にも使⽤する ○ コンテンツの追加更新をするメンバーに⼿順を説明して実施してもらう ● もちろん、⾃動的なチェックだけでは完璧にならない ○ コンテンツの追加更新時に⾏うチェックについて決めておく ○ そもそもどうコンテンツを作るべきかの指針を⽰しておく

Slide 50

Slide 50 text

スクリーンリーダーなしで、同等のチェックをする ● ⾃動チェックでチェックできないものは⼈の⼿でチェックをしなければならない ● チェックするには、コードを読むか、⽀援技術（スクリーンリーダー）を使う ○ 使い⽅を憶えるのが⼤変 ○ QAしかチェックしなくなる ● それらを簡単に⾒ることができる Accessibility Visualizer拡張機能を開発 https://github.com/ymrl/a11y-visualizer 画像は「駒瑠市〜アクセシビリティ上の問題の体験サイト〜」上で Accessibility Visualizerを使⽤したもの https://a11yc.com/city-komaru/

Slide 51

Slide 51 text

今⽇のまとめ ● アクセシビリティに取り組むと、多様なニーズに応えられるようになり、障害者や⾼齢者を含めてあらゆる⼈にとって使いやすくなる ● Webサイトが利⽤できない⼈がいることは、⼈権の問題でもある。努⼒義務ではあるが、合理的配慮を提供する義務のためにも取り組むべき。 ● まずはできるところから始める。リニューアルまで放置したりしない。いまあるコンテンツをすこしずつチェックして直していく。 ● アクセシビリティを前提にした制作‧運⽤プロセスにしていけるのがベスト

Slide 52

Slide 52 text

来週はアクセシビリティカンファレンス福岡！ 2024年11⽉30⽇(⼟曜⽇) 警固神社社務所ビル（福岡） + YouTube 13:00〜18:00 フリー株式会社オフィス（⼤崎）でパブリックビューイングをやります！いますぐconnpassから登録！ https://fukuoka-a11yconf.connpass.com/event/322934/ https://freee.connpass.com/event/337258/

Slide 53

Slide 53 text

アクセシビリティを考えはじめるための本技術書典オンラインマーケットにて、「アクセシビリティを考えはじめるための本」電⼦書籍版を800円で販売しています。法律の解説や、⽀援技術体験のチュートリアルなど今⽇は触れられなかったことを詳しく書いています。 https://techbookfest.org/product/2KX3LTZs66Y6v8cZZ62mDW

Slide 54

Slide 54 text

書籍「モバイルアプリアクセシビリティ⼊⾨」発売「Webアプリケーションアクセシビリティ」の姉妹書モバイルアプリのアクセシビリティの本 12⽉2⽇、透明書店（蔵前）にて刊⾏記念イベント https://tomei-bookstore-event-20241202.peatix.com/ 12⽉3⽇より、公開読書会を開催 https://freee.connpass.com/event/337478/

Slide 55

Slide 55 text

ご清聴ありがとうございました続きはAsk The Speaker / 懇親会で