2021-08-18

輪読会のやり方を試行錯誤している話

2021年の1月から、社内でアクセシビリティ関連書籍の輪読会をしています。

参加メンバーはデザイナーメインで、その他にも興味あるメンバーが参加しています。（日によりますが、最近は最大6人くらいでやってます。）

私は言い出しっぺなので、進行をすることが多いのですが、「このやり方で良いのか？」と迷いながら進めてきました。

どのくらい迷っていたかというと、「自分のファシリが悪いんじゃないか、誰か得意な人にファシリお任せしたい、、」と思うほどでした笑

それが、最近ほんの少しやり方を変えただけで、個人的にすごくやりやすくなりました。議論も盛り上がったので、みんな話しやすくなったんじゃないかなと感じています。

うれしかったので、その話を記録しておきたいと思います。

直近のやり方

輪読会の進め方をざっくり説明すると、

毎週月曜17時〜18時開催
事前準備なし
前半は本を読む（大体20ページほど範囲を決めて、35分くらい読む）
- 開始前にesaにページを作っておき、各自読んだ内容で気になったことや疑問・感想などをメモする
後半は各自感想や特に気になったこと、深掘りしたい点を順番に話す

とう感じです。

今読んでいる本は2冊目で、Form Design Patterns という本を読んでいます。毎回だいたい20ページずつ読んでいます。読む時間とメモする時間を合わせて35分とっています。（メモを取りながら読んでいるので、時間が足りないこともあります。少しページ数を減らした方がちょうど良いかもです。）

これだけ聞くと、「ふーん。特に変わったことはなさそう。」という気がするので、初期のやり方も載せておきます。

初期のやり方

輪読会1冊目はデザイニングWebアクセシビリティという本を読んでいました。
その時のやり方は、

毎週月曜17時〜18時開催
事前準備なし
前半は本を読む（大体20ページほど範囲を決めて、35分くらい読む。共有用のメモは特になし。）
後半は「何か気になったことや感想はありますか？」と私が参加メンバー全体に問いかけて、ざっくばらんに話す
ざっくばらんな感想・疑問などをメモしておき、終了後自分が議事録としてまとめて共有する

という方法をとっていました。

何が課題だったのか？

そもそも、自分が輪読会を提案したモチベーションとしては以下のようなものでした。

アクセシビリティを考慮したWebアプリケーションを作る上で、エンジアだけでできる範囲には限界がある。デザイナーと一緒にアクセシビリティを学び、認識を合わせていく必要がる。
- アクセシビリティへの意識を高めるために、まずは輪読会の場を設けて学んだり考える時間を作りたい
プロジェクト毎のノウハウをデザイナー全体に気軽にシェアしたり、プロジェクトを超えてデザイナー・エンジニア間で気軽に意見交換できるようにしたい

そんな中、輪読会を開始したは良いものの、業務のように役割やゴールを明確に決めていなかったので、やり方に迷う日々が続きました。

気にかけていた課題は

後半の意見交換タイムが短い
- せっかく感想や意見交換、日頃の課題を共有して議論が盛り上がったりしても、議論を十分にできないまま時間が来てしまったりする
  - かといって後半の意見交換タイムを長くしようとすると、急いで本を読まないといけなくなる（これはページ数減らせよ、という感じではある）
話す人に偏りが出ることがある
- 時間の関係で遠慮させてしまっているのではないか？
- うまくファシリテーションできていないのではないか？
読むだけはなく、その先へ進にはどうすれば良いか？
- ガッツリ改善をしていくにはプロジェクト的にやっていくべきなのか？
  - 各々業務がある中で、そう入った動きは負荷が高すぎる？？
なんか漠然と課題かんを感じているけど、相談したり考える時間を取れていない

などでした。こうして挙げてみると、客観的に見れるので、どれも改善できそうですね。笑

アクセシビリティやっていきたいと言いつつ、深掘りしたりガッツリ改善していくことがなかなかできていないので、そのズレが自分にとってストレスになっており、難しく考えすぎていたのかなと思います。

何がよくなったの？

1. 本を読みながら各自メモを書くようにした

これは、輪読会メンバーの方が提案してくださり取り入れたものです。（最近、参加できる時はファシリもになってくださり感謝しかない）

これにより、

議事録を書く時間が省略できる
議事録の内容の偏りがなくなる（毎回私が書いていたので、拾えているところや拾えていないところがあったため）
各自からこれまで引き出せていなかった感想や意見を引き出すことができる（すばら）

というメリットを感じています。

2. 参加者全員に順番に話してもらうようにした

読み終わった時点で、それぞれ感想、気になったこと、疑問、特に話したいことを順番に話ていくというやり方を先日試してみました。これがすごくよかったなと思っています。

ちなみに、これまでやってみて難しかったやり方は、

いきなり全体に対して「さぁどうぞ！」という感じでふる
- みんな話を切り出しにくそうだった...
各自のメモを見つつ、「〇〇さんXXについて気になったみたいですが、どうですか？」などと聞いていく
- 1つずつ聞いていくには時間が足りない。。
- 各自本当に話したい内容を話せていないかも？と気になってしまう。

というものです。ファシリ力がある方が進行したら違うんだと思うのですが、私には難しかったです。

なのでいっそのこと順番に、特に話したい点をピックアップして話てもらうことにしました。こうすることで、各々気になっている点を深掘りできるし、みんな話しやすくなったのではないかなと思います。

この日は議論も盛り上がり、個人的にはこのやり方がとても気に入りました。

終わりに

「輪読会の進め方難しい...」と悩んでいた時期が続いていたので、今回やりやすい方法を見つけられてとても嬉しいです。「事前準備なしで1時間」という条件で、割と満足度の高い1時間にできるようになったのではないかと感じています。

どんな場合にもマッチする方法だと思っていませんが、どなたかの参考になれば嬉しいです。

2021-07-27

「はじめてのUIデザイン」を読んだ

はじめてのUIデザイン改訂版 Kindle版を読みました。（なんと、Kindle版100円で購入できます！買うしかない！）

www.amazon.co.jp

せっかく読んだので、簡単に感想を書こうと思います。

本を読む前のモチベーション

自分はUIについて考えることが好きです。より良いUIを提供することはフロントエンドエンジニアをやる上で、大きなモチベーションの一つです。

実務でも実装やアクセシビリティの観点から検討・議論・フィードバックを行なっています。
たまに "うまく言語化できないが直感的に違和感を感じるUI" に直面することがあり、そんな時、「なぜ違和感を感じているのか？」「その違和感は単なる好みなのか？」をぱっと説明できず、もどかしさを感じることがありました。その度に、もっと知識を増やし、多面的にUIの適切さを考えられるようにしていきたいと思っていました。

必要に応じて断片的にUIについて調べることはあっても、体系的な学習は恥ずかしながらできていなかったように思います。

この本は、「UIを体系的に学びたい初心者向け」の本として書かれているため、断片的な知識を整理し、「基本だが抜けている知識」を補う手助けとなるのではないかと思いました。

また、デザイナーの視点も知れるのではないかと思い、多面的な視点からUIを検討するためにプラスになることを期待して読みはじめました。

面白かった点

個人的に面白いなと感じたことを2つ挙げたいと思います。（他に興味深かったことは深掘りして別記事にしたい）

フロー図

自分のチームでは基本的に、デザイナーさんが要件から情報、フロー、画面デザインを起こし、それをもとにチームで確認・議論などを行います。そのため、「フロー図」という形で情報のみを整理した状態でフローや一つ一つの画面を整理するというやり方はとても面白いと感じました。

おそらく作業段階ではみんなやっていると思うのですが、エンジニアである私やその他チームメンバーにはデザインが当たっている状態で共有されます。

そうすると、情報、フロー、デザインが一緒になった状態で確認や議論をするため、何に対しての確認・議論なのか曖昧になることがあります。

そのため、デザイン適用前の情報だけの状態で、フロー図として整理し、そこで一度確認・議論する方が個人的にはとてもわかりやすくて良いなと感じました。その方が、それぞれ何に違和感を感じているのかわかりやすいですし、手戻りも少なくなるのではないかと感じました。

言葉のデザイン

「詳しくはこちら」のような具体性のないラベルや、「送信を受け付ける」のようなシステム主体のラベルは避けましょう、という内容が記載されていました。

「こちら」のような表現はアクセシビリティの観点から気にしており、敏感になってきたのですが、システム主体のラベルは少し怪しいかもしれないと感じました。

エンジニアをしていて開発部署だけの会話に慣れていると、他部署の方やIT業界と全く異なった業界のお客さまに説明する時、すぐわかりやすい言葉が見つからないことがあります。

そのような感じで、システム的なラベルや表現に気付きにくくなっている面もあるのかなと思い、言葉のデザインは改めて気をつけようと思いました。

本の中では、「UIデザインにおいてビジュアルと同じくらい大事なものは「言葉」」と表現されていましたが、それほどまでに言葉を重要視できていただろうか？と考え直す機会となりました。

感想

読んでみたところ、期待通りでした。初心者向けということで、とてもわかりやすかったです。

基本的なことが体系的にまとめられているため、頭の中にあった断片的な知識が整理されていくようでした。

そしてこちらも期待通り、「基本的なことだが足りていない知識」を補う手助けとなりました。この本の中で紹介されていた記事や本を手に取りさらに深めて行ったり、キーワードで調べたり、実戦でトライしたりと、次のステップに進むために十分な要素を盛り込んでくれているように感じました。

実務の中で、『デザイナーにどこまでのことをフィードバックして良いのだろうか』『単なる主観や好みになってしまっていないか』『エンジニア目線の意見に偏り過ぎてしまっていないか』と迷うこともあるのですが、本には実装者目線での考え方もしっかりと記載してあって共感と共に、安心感を得られました。

チームでこの書籍を読んで、共通認識を揃えておけば、コミュニケーションも取りやすいのかなぁと感じました。

最後に

面白かった！良い本を驚きの安価で提供してくださっており、多くの人に読んで欲しいというお気持ちを感じました。しっかり生かしていきたいです。ありがとうございました！

2021-07-03

【UIについて考える会】固定メニュー

UIについて、自分なりに調べたり検討したことをちょっとずつメモしていこうと思います。
検討材料や考え方が変わった場合は随時更新予定です。

今回は 固定メニュー についてです。

背景

現在、スマートフォンで使うWebアプリケーションを作っており、固定メニューを設置するかの検討をしています。

当初は、コンテンツ表示領域が狭くなるという理由でやらない方針としていたのですが、やはり使いにくいのではないかという声が上がり再検討となりました。

そこで再検討する上で改めて自分なりに検討してみました。

メリット

回遊率の向上が期待できる
- メニューが目につきやすいため、回遊率の向上が期待できる
最上部、最下部までの移動が不要になり、ユーザビリティの改善につながる
- 縦に長いサイト・アプリケーションなどで効果が大きいと考えられる

デメリット

表示領域が狭くなる
- スマートフォンなど画面が小さい場合、さらに狭くなる
- タッチデバイスの場合、画面上にキーボードが表示された際、固定メニューがあるとかなり狭くなる
- 画面拡大時は致命的とも言える
  - 参考：ヘッダー (ナビゲーションバー) の固定表示
意図せずメニューをタップしてしまう可能性がある
- ブラウザの上下にはアドレスバーやソフトウェアキーボード、「戻る」「ホーム」などが密集しており、誤ってタップする可能性が高い

デメリットを回避するには

固定メニューの領域を小さくする
- 開閉可能にする
  - ハンバーガーメニューがよくみられる例。ただ、ハンバーガーメニューは知らない人にとってはメニューだと伝わらないなどの課題がある
- リッチなメニューではなく最低限に絞ったものにする
少なくとも、画面上にキーボードが表示されるページには固定メニューを置かないようにする
- タッチデバイスの場合、入力欄にフォーカスが当たると画面上にキーボードが表示されるため
下スクロール時にメニューを隠し、上スクロール時にメニューを表示する
- 止むを得ず固定メニューを設ける場合、この案が一番良いとこどりなのでは？と今の所思っている

最後に

スマートフォンのように画面が小さいデバイスの場合、その中でコンテンツをどう表現するかはとても難しい課題です。

コンテンツやアプリで何を重視するかにもよるので一概にどのような表現が良いとは言えませんが、採用する場合はデメリットを認識した上で、表現方法を検討していきたいところです。

また、UIの良し悪しは実際にユーザーに使ってもらわないとわからない部分も多いと思います。

ユーザーに使ってもらった上でフィードバックを得るなり、行動分析するなりして、必要に応じて柔軟に改善していく姿勢も重要と言えるでしょう。

追記

以下の記事面白かったので追記。

www.nngroup.com

2021-05-29

今週のハイライト（2021/5/29）

今週のハイライト

仕事

アクセシビリティ輪読会（社内）
- 「デザイニングWebアクセシビリティ」を読了したので、参加メンバーでチェックリストを作成した。曖昧な表現になっている箇所は、具体的な観点を補足して運用で迷わず使えるチェックリストを目指した。ひとまず、運用し、運用しながらチェックリストを成長させていく方針とした。
CSSに苦戦した
動画を表示する対応ではデバイスやブラウザで挙動が異なる点が多々あったのでまとめておきたい。
設計難しいなぁと思った。リファクタリングして改善していきたい。

プライベート

アクセシビリティ課外活動（社外）
- Zennの記事を読んでくれた知り合いの方に話を聞かれたので、1hくらいお話しした
  - ヒアリングされることで改めて振り返りになったし、考えさせられることがあった。また改めて言語化したいと思った
- 東京都コロナウイルス感染症対策サイトのアクセシビリティのプレ試験に参加した（5/25-5/27）
ものもらいになった
- 火曜日から目が痛くて木曜日からちょっと腫れていた。金曜日に眼科に行ったらものもらいだった。
- 初めて行く眼科だった。予約と問診票登録がWebからできたのがよかった。
- 眼科の会計、セルフレジだった。使い方がわからない人には都度説明してた。最初は手間でもユーザーに学習させていくスタイルは正解だと思った。
人との関わりが欲しいなぁと思う
- 基本リモートなのもあって雑談が少ない。社内の人ともそうだけど、社外とか仕事関係なくとか、もっと人と関わって話す場が欲しいなぁと思う今日この頃。所属コミュニティが少ないのだけど、みんなどうやって人との出会いを増やしているんだろう。
久々に星野源さんのラジオを聴いた
- 5/19にガッキーとの結婚が発表されてから初のラジオだったので、リアルタイムで視聴した。数年ぶりに聴いたけど、相変わらずだったw
- 源さんならかわさないだろうと言う期待通り、源さんの口から結婚の報告があり、リスナーからの質問にもちゃんと答えてくれて、これだから好きなんだよなぁという気がした。そういったプライベートな話をするもしないもご本人の自由なのでとやかく言える立場ではないけど、なんか源さんっぽいと思った。寺ちゃんの前口上も最高で、深い愛情を感じた。とてもよかった！

ひとりごと

オープンな日記とクローズドな日記ってどっちが良いんだろう。オープンな日記だと仕事のことをあまり書けないけど、オープンな日記の方がなんか達成感があるんだよな。

2021-04-27

Vercel の Response header に X-Frame-Optionsを追加する

はじめに

Vercel を使っているプロジェクトでQAの方にセキュリティチェックを実施していただいたところ、X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks という内容のチェックに引っかかりました。

Vercelにデプロイした場合、デフォルトだとレスポンスヘッダーに X-Frame-Options が含まれないようです。

そこで、X-Frame-Options: DENY の追加を試みました。

Vercel の Response header に X-Frame-Optionsを追加する

前提：AngularのプロジェクトをVercelにデプロイしています。

プロジェクト直下に vercel.json を新規作成します。
vercel.jsonの内容は以下のようにします。

{
  "headers": [
    {
      "source": "/(.*)",
      "headers" : [
        {
          "key" : "X-Frame-Options",
          "value" : "DENY"
        }
      ]
    }
  ]
}