RSGT2023 day2 イベントレポート
これは RSGT2023 のday2のイベントレポートです
day1の分は書いてませんが、余力がある時に書くかもしれません。 とりあえずday2で参加したセッションを思い出しながら、自分の理解を整理しながら、忘れる前に思ったことなどをなるべき簡潔に書きます。
Sponsor Talk / Keynote Preparation
- この日は、fun done learn の歌から始まった。(day1 は青い顔面のサムライの寸劇だった。文章にするとすごいなあ)
- RSGTは遊び心満載なんやなあ。
- 会場には温かい笑いが溢れていました。
10:00 ~ メインホール | Lyssa Adkins - The Agilists’ Emerging Superpower and Our Planetary Challenge
- "変化"に関する話だった。
- スクラムは変化に適応する、変化を楽しむ、変化を歓迎するみたいな感じで、変化を栄養に変えていく。
- change edges の話が興味深かった。
- 変化のために、まず自分が何をやるのか、関係者に伝えるためにどう準備するか的な
- まずは、置かれている状況をしっかりと整理したり、エッジに追い込まれているぞ??みたいなのを自覚することだぞってことなのかな?と理解した。(あっているのだろうか)
- 全体的に、あの時間だけだと咀嚼しきれなかった感があるので、じっくり発表を見返したりしたい気持ち(Lyssaの発表に対する解説ほしい)
- discordでみんなが、色々考えや参考を発言しあってるのがすげえ助かった
- 後でスタッフの方とお話ししてた時に、自分がまだ理解できてなかった情報がたくさん出てきた
- 自分の中で完結するじゃなく、他の人と「あれどういうこと?」「俺こう思ったよ」とか話すのめっちゃ良い
13:00 ~ メインホール奥 | Tsuyoshi Ushio - ログの書き方がチームの生産性を爆上げする話
- 生産性を爆上げ = インシデント対応や、問い合わせ対応の時間をめっちゃ減らす って印象だった
- 実際にあった例や経験をもとに、ログの残し方のアイデアや考え方を整理してくれた発表だった。とても参考になりそう
- ログを見る人(ユーザー)のことを考えて、ちゃんと使う場面目的を想定しようぜっていうのがすごい響いた。ログ関係なくプロダクト作る上でユーザーを具体的にイメージするの大事ーーとおもった。
- 詳しいロギングのテクニックについてはブログを出してくれるらしいので、とても参考にできそう。参考にする。
14:25 ~ テラスルーム | Masahiro Sato - デイリースクラムの”守破離” - 日々をより楽しく有意義にするヒント -
- 一番頻度の高いイベントなので、楽しく有意義なものになるように工夫しようぜ!っていうのがとても響いた。
- 結構具体的にデイリースクラムをよくするためのヒントを提示してくれた。
- 守破離の3段階ごとのヒントの紹介なので、これは試してみれるかもがあった
- 4つ目の質問として「チームへの提案依頼はある?」を聞くは、個人的に試してみたいとおもった
- 発表のあと質問に行って、DSの時間が長引いちゃうことに対して、4つ目の質問の質問とても効きそうって話した。
- 前もって書いておいてもいいよねっても話した
- 事前に4つに対しての回答を簡単に書いておくとかすると、いいたいこと整理されて、特に4つ目のじゃあどうしたい?が考えやすそう
15:15 ~ roomB | Omar Galeano / Nicholas Wilson - Extreme Team Ownership
- 「リーダーシップは一人の人間がチームを率いることではい、チームが協力すること」これ好き
- Navy SEALsの例を参考に、チームで責任を持つってどんなこと?を話してくれた。
- チームのメンバーみんなで責任を100%もつ、他人への非難は0っていうのが、Navy SEALs のhell weekの例で痛感した。
- みんなで責任を持つの話で、自分の役割以外の部分に関しても、責任を持つ
- 確かにチームとして目標を達成するために、自分の役割外の部分でも責任は持てるよね?
- 任せっきりで何もしないじゃなくて、本当にやれることないの?って考えれば色々ありそう。
- 英語のセッションだったけど、zoomの同時通訳とスライドの日本語でそんなに困らなかった
- 右耳日本語、左耳英語状態だったけど、通訳なしでも大体内容掴めるような発表になってた。感謝。
- 質問に行ったら、Nicholas めっちゃ日本語で答えてくれた。
1615 ~ メイン手前 | Hiroyuki Ito / Shigetaka Kumagai - 「笑顔の合意」のテクニック - 噛み合わない会話と対立を克服するための、エモさを排した実践的なスキルと技法 -
- day2 keynoteのLyssaの話や、day2での発表いくつかと重なる部分があった
- まずは各々が持っているものを考えを明らかにしてくっていうのの大事さあるなあ
- 話が噛み合わない会話と対立(=空中戦)に対して、本当にちゃんとスキルで克服をできるぞというのを、3つのスキルとその実践例から感じれた。早くやってみたい。
- 実際に紹介するテクニックを二人で実演してくれたのが凄くよかった。やるイメージみたいなのが浮かんだ。
- 紹介されたスキルはアンガーマネジメント、NVC、マインドフルネス
- NVCの説明の中で、人間って「自分でさえ自分のニーズを理解できてないし」「相手のニーズを勝手に解釈するし」みたいな感じで、すれ違いしやすくできてるんよって出てきたのが、わかるうううってなった。
- 空中戦がおきるメカニズムと、じゃあどうする?をすごいわかりやすく伝えてくれた。めっっっちゃよかった。
まとめ
聞いたセッションの感想をつらつらと書いたが、複数の発表の中に関連を見出せたり、日頃感じているモヤモヤやもしかしたらこうなんじゃないか?みたいなものに対して、発表を聞く中で輪郭を与えられたような気がした。 掴めなかったものちゃんと認識できなかったものが認識できるようになった気がするので、これらに対して、小さくトライと地道にコミュニケーションを続けて良い変化を作っていきたい。 ただ、あまりにもこれ試してみたいぞ?っていうものが多い気がするので、また再度自分の中で整理をして、ちゃんとチームに伝えていきたい
これからday3だけど、高揚とか、緊張とか疲労でなんだかフラフラしている。 day3でもしっかり聞いて、たくさん話して、いろんな気持ちと知識を持って帰れるようにしたい。
そしてまた後で、ちゃんとした記事も書く
ふりかえりの設計からファシリを最近2回したのでふりかえる(熱気球とStory of Storyやった)
最近ブログ更新できていなかったので、久しぶりの投稿
話したいこと
先週と先々週にそれぞれ毛色の違ったチームふりかえりを行った。
さらにその2つのふりかえりに対してふりかえりの設計と、ファシリテーションを担当したので、そのことについて個人的に整理をする。
やったこと、わかったことを整理してみる。
本題
やったこと(大まかに)
まず、「毛色の違ったチームふりかえりって何やねん」ですが、
- ① 3名で約1ヶ月分くらいのふりかえり
- ② 8名で1スプリント(1週間)のふりかえり
を実施しました。
各ふりかえりの前には、「ふりかえりの後にどうなれていたらよいか」を上げるなどして、ふりかえりの手法の選定と、ふりかえりを実施する場所を準備するなどした。
ふりかえりの当日には、ファシリテーター役として、ふりかえりの進行を行った。
① 3名で約1ヶ月分くらいのふりかえり
自分を含めた開発チームのメンバーx2, 副業メンバーx1 の3名で行った。
どういう集まりかとういうと、約1ヶ月ほど前から、副業メンバーにジョインいただき、プロダクトのe2eテスト導入を進めてもらっているので、それに関わっているメンバーの集まりだった。
以下のような属性を含むので、さすがにふりかえりちゃんとしたほうがいいでしょうと思い、ふりかえりを計画 - 新しい試み - 新しくジョインしたメンバー - 副業メンバー - なかなか複雑なプロダクト
ふりかえりは、「熱気球」という手法をメインに取り入れて行った。
② 8名で1スプリント(1週間)のふりかえり
自分のいるagent bank開発チームではスクラム開発を採用しているので、スプリント(うちでは1スプリント=1週間でやってる)の節目に、次のスプリントをより良くするためにという目的で、ふりかえりを行っている。
最近は、「KPTA」という手法を用いてふりかえりを行っているが、この前の回のときに「他の手法でもやりたい!」と自分が発言したのがきっかけで、この回ではいつもとはいつもとは違う手法でやってみることになった。
結果的に「Story of Story」をやってみた。
やったことと、わかったこと(詳細に)
2回のふりかえりでやったことをそれぞれ説明する
① 3名で約1ヶ月分くらいのふりかえり
上に書いていたものを再度整理する。こんな感じのチームでのふりかえり。
- 自分を含めた開発チームのメンバーx2, 副業メンバーx1 の3名
- プロジェクトとして
- 新しい試み
- 新しくジョインしたメンバー
- 副業メンバー
- なかなか複雑なプロダクト
- メンバージョインから1ヶ月たった
やったこと
このふりかえりの後にどうなっていたいか?を出す(ふりかえりの目的)
スクラムマスター(以降SM)の協力を得て、自分を含めた開発チームのメンバーx2 + SMの3人でふりかえりの設計を行った。
まず、手法を選定するために、ふりかえる期間にどんな事があって、ふりかえりをした結果、我々がどういい状態になっていたいかを出しあった。
割と、コミュニケーションや、お互いの状況把握の点に関して少し改善の余地がありそうな印象だったので、上のようなアイデアが出た。
これをベースに、どんな手法を採用するかを考えていった。
ふりかえり手法の選定
ふりかえりチートシートや、https://www.funretrospectives.com/ を参考に、ふりかえり手法を選定していった。 結果的には、「何度かやったことがある」「楽しい」を理由に熱気球を採用することになった。あとで書くが、結果楽しかった。
参考: 熱気球 blog.engineer.adways.net
ふりかえりの構成を考える
手法の選定も、ふりかえりの構成にはいるだろうなあとは思うけど、細かいことは気にしない。
大きな構成としては、以下のようになる
- 場の設定
- データ収集(熱気球に決定)
- アイデア出し(熱気球に決定)
- 次やることの決定
- ふりかえりのふりかえり
それぞれどのようにすすめるかを決めていった。
ふりかえりの目的として、「現状の進捗把握」も上がっていたので、熱気球の前に現状把握のステップを追加した。
結果として、 以下のような構成になった
- 場の設定 → ハピネスレーダー(顔文字でこの1ヶ月を表現)
- データ収集① → 現状把握
- データ収集②、アイデア出し → 熱気球
- 次やることの決定 → 熱気球で出たアイデアから、投票などして決める(その場の状況次第)
- ふりかえりのふりかえり → 雑談形式
MTGを設定していた時間が1時間だったので、それに収まりきれうように、書くステップに必要な時間を割り振ることまでした
事前にデータ収集
各ステップの時間を設定したところ、「現状把握の時間」そんなに時間取れないな、というのが判明した & おそらく0からやると半端なく時間がかかるのが予想された。
解決策としては、「前もって聞けば分かるっしょ」ということで、slackで事前に質問して回答をもらっておいた。
結果聞いててよかった、ふりかえりの時間では読み合わせて認識合わせる&わからんこと質問する に集中することができて時間を効率よく進めれた。
ふりかえりに必要な物理的な場を作る
以下のツールを使用してふりかえりを行うことを決定した
Miroには、ふりかえり用のボードを用意しその中に、各ステップでやること、必要な時間、熱気球のイラストを事前に設置して、スムーズに始めれるように準備した。
ここまでしてやっとふりかえりの準備 DONE
実際にふりかえりを実施
SMにファシリテーターをお願いしたかったがきれいに予定がかぶっていたので、自分がファシリテーターをしつつ、ちょこちょこふりかえりにも参加するのをやった。
ちなみに、熱気球やった形跡はこんな感じになりました
次やることの決定で、ほぼすべてのアイデアを次やることにした
出たアイデアの実施難易度が低いものが割と多かったので、結果的に出たアイデア全てに対して、具体的にどういうアクションが取れるかを決めて、次やることとして整理できた。 アイデア整理などして、5個の次やるアクションが出せた。
10分オーバー
1時間のMTGであったが、すべて完了するまでに10分オーバーしてしまった。今回は、幸い副業メンバーの方の後の予定が空いていたため、最後まで全員参加で、ふりかえりのふりかえりまで実施できた。
わかったこと
少人数だとスムーズに進む
いつもやっているチームのスプリントふりかえりだと、だいたい5-8名ほどで実施してるが、今回は3名だけだったので、凄くスムーズに進んだ気がする。
というのも、話す人少ないので、必然的に参加者が自発的に発言しやすい状態になっていたのかもしれない。
また、大人数だと、全員分話し聞こうとして物量てきに時間食っちゃうみたいなことになる。
ハピネスレーダー面白い
場の設定に使ったハピネスレーダーが意外と面白かった。
ネガティブそうな顔文字を貼っている人がいて不安になりながら話を聞いてみると、「なるほど、そんなことあったんか〜」みたいな予想外の展開あった。
貼られたのはこれで、「ヤバイドウシヨウ」ってなった。
聞いてみたら深刻な内容ではなかったので一安心した
ふりかえり始めての体験の人だったが、楽しく質の高い場にできた
副業メンバーが、今回やったようなふりかえりをやるのが、初めてとのことだったが、とても楽しかったとの感想を貰えることができた。
次回1.5ヶ月くらい立ってから再度やりたいねとなったので、ほんとにちゃんと準備かいがありました。
よかったーーーーー
8名で1スプリント(1週間)のふりかえり
上の熱気球の文でだいぶ、力尽きた感あるので、こっちはシンプルな文章になりそう...
やったこと
いつもと違うふりかえり試したい発言
この回の前の回のふりかえりのふりかえり最後のSMの「なんにかやってみたいことあります?」問に対して「いつも違う(KPTAじゃない)ふりかえり手法でやってみたい」と発言したことにより、今回設計からファシリまでを務めることになりました。
SMの支援を受けながら進めた。
ふりかえり手法の選定
まず、ここでもふりかえりチートなどを参考に、どんな手法を取るかというのを考えていきました。
毎日の終了時に夕会としてその日あったことや次何やるかを、YWTを使って簡単に振り返ってます。
こんな感じ
縦長の四角が一日ごとのフレームでその中で上から「Yやったこと」「Wわかったこと」「Tつぎやること」をためています 付箋の色は、赤→ポジティブ、黄→ニュートラル、青→ネガティブ を表現してもらってます
このスプリントでは、新しくジョインしたメンバーが開発に本格的に参加し始めた & メンターと一緒に進めている様子がなかなかうまくいっているようだったので、良い学びが多かったのでは、YWTの結果もポジティブな付箋多めかな?という肌感だった。
良い学びを伸ばす系のふりかえりにしてみようというのと、毎日のYWTの内容を生かしてできないかなということで、Story of Storyを採用してみることにした
ちなみにふりかえりチートシートには、こんなふうに書いてた
「良いところを伸ばす◎」なるほど良さそう。
Story of Story の参考webでみっけたの英語のページしかなかった...
ふりかえりの構成を考える
結果的に以下のような構成に落ち着いた
- 場の設定 → ハピネスレーダー(①でやったときに楽しかったので、味をしめたため)
- データ収集① → 毎日ためてたYWTのYだけさらっと眺める
- データ収集② → Story of Story
- アイデア出し → Story of Storyで集めた
- 次やることの決定 → 出たアイデアから、Effort x Value という手法を使って、絞り込み、やることの具体案を決める話をする
- ふりかえりのふりかえり → 3人くらいに話してもらう
次やることの決定に関しては、いつもは投票によって、アクションを決める対象を絞り込んでいるが、ここもチャレンジしようということで、Effort x Value という手法を取り入れてみた。
簡単に説明すると、Effort(必要な努力)と Value(得られる価値)の2軸のマトリックスに対して、アイデアをマッピングする。より少ない努力で得られる価値の大きいアイデアに対してアクションを考えるというもの。
マッピングする中で、どうやったら少ない努力にできるかとか、アイデアの共通認識を合わせる的なやつです
ふりかえりに必要な物理的な場を作る
Miroにこんな感じのボードをつくった、
会話はDiscordで音声チャットをしながらおこなう。 また、①のときと同様にスッテプで何をするのかと、各ステップでどのくらい時間を使うかを見積もって記した。
実際にふりかえりを実施
実際にStory of Storyやった形跡はこんな感じになった
わかったこと
ふりかえり慣れている人達がやっても、ハピネスレーダー楽しい
前回味をしめて、今回もやってみたがやっぱり楽しかった。 これからも困ったらこれやりそう
Story of Story 結構時間かかる
ステップとして、以下があるが、なかなかステップが多かったのと、すべてのステップで少しづつ予定の時間をオーバーしてた。ざっくり2倍づつくらい。
- 期間の間に起きたことを書き出すステップ(以下を書き出す)
- 事実
- コミュニケーション・コラボレーション
- 続けること
- 避けること・やめること
- 書き出したものを皆で共有する
- 上で書き出したものから以下と書き出す
- 個人の学び・成長
- チームの学び・変化
事実の付箋がとても大量に書き出された事により、各ステップで、全部を見ながら次の付箋を貼るのがかなり負担だったみたい。 起きた出来事が多かったり、参加者が多いふりかえりに使う場合は、注意が必要かなあとおもった。 もしくは、テーマを絞るとかしても良かったのかな?
プロブレムに焦点が当たりづらかった
毎回やっているKPTAに比べると、プロブレム(課題)に対して焦点が当たりづらかあったという感想があった。
確かに、割と良いコミュニケーションや、良い学びに対して焦点が行きがちで、「このモヤモヤに対して話そうぜ」てきな雰囲気に行きづらかった感がある。
また、データの量が多すぎてアイデア出すのが大変みたいな感想もあった。
Effort x Value の使い方工夫必要そう
アイデアの絞り込みにEffort x Value を使ってみたが、これもプロブレムに焦点が行きづらい要因だったかも。 プロブレムの解決って、大体すごいパワー必要そうなことが多い気がするので...
なので、ここぞというときに使えるように使い所を探ってみようと思う。
大人数疲れる!
6人+ファシリ(俺)+SM(俺の支援)みたいな感じだったんですが、みんなの出したアイデアを全部みたり、話を深ぼったりすると単純に時間がかかるし、超パワーがいりますね。
まとめ
2つの毛色のちがうふりかえりの設計から、ファシリまでやってみたんですが、 人数や、期間、目的によって適したやり方全く違うんだなと、実感した。
手法によって、得意不得意があるっぽいので、どんな手法がどんなときに効果的かみたいなことを実践で覚えていきたいなとおもった。
また、既存の手法も目的によってカスタマイズしながら進めれるようになりたい。
オンライン、オフライン関係なく少人数のほうが進めやすいんだろうなとは思うが、オフラインだと、途中で少人数に分離して合流的なことするにも、ツールとかの準備必要でめんどいなあ。ガッツリやるときは、zoomとかGoogleMeetのブレイクアウトセッション準備したりなんしたりするのだろうなあ...
最後に定期的に行っているスプリントのふりかえりで、実験的な事ができたのは、チームとしてとても良かったなと思う。
引き続きチャレンジしていきたい!
VueのSFC 簡単にcodepen.ioでさくっと書けるけどみんな知ってる?(vue3でも書ける)
結論
https://codepen.io/pen/editor/vue
上のリンクから codepen.ioで VueのSFC簡単に試せます
codepen使うけど、vueのときは...
みなさんは、ブログ記事用のサンプルだったり、いちいち環境作るほどでもないけど試しにコード書きたい時とかにcodepen.ioでサクッとコード書くみたいなことが結構ありますよね。あります僕は。
しかし、Vueの場合には、codepenだとサクッとSFC(.vueファイルの書き方)で書けなかったので、codesandbox.io に書いてました。 それかlocalでvue-cliするか、諦めるかしてた。
最近vueのSFC に対応した
codepen.ioじゃ、vueサクッと書くなんてできないんだよな...と思っていたんですが、2020/4/14 にできるようになったらしいです。最近気づいた。
https://blog.codepen.io/2020/04/14/a-custom-editor-just-for-vue-single-file-components-vue-files/
しかもvue3も
しかもです、vue3でもかけちゃうので、composition-apiやら何やらがお手軽に試せます。嬉しいですね
ちなみに通常のpenと同じように埋め込みも可能です。
サンプルで貼ってるのは、https://codepen.io/pen/editor/vue で作れるやつを vue3に書き換えたやつ
See the Pen vue3 sfc on codepen by kohei sakamoto (@eeonk) on CodePen.
終わり
codepen.ioでVueのSFCもvue3も書けるのとても嬉しいです。
みんなcodepen.ioでvue3をSFCで書こうぜ。
以上、codepen.ioのvue SFC editor機能知ってる人少なそうな気がしたので書きました。
font-family の設定が原因で行ブロック内のテキストが縦中央揃えされない?
話したいこと
font-family: Roboto, "Hiragino Kaku Gothic ProN", … ;
みたいな設定していたら、日本語のベースラインがずれて、テキスト + アイコン の縦がズレズレになってた。
調べてみたら、詳細な原因はよくわからんけど、フォントによって中央揃えしたときの揃い方だいぶ違いそうだったので、調べて分だけまとめる。
ちなみにデバイスにヒラギノ入っている人の表示しか考慮できていないです。
きっかけ
inputRadioのコンポーネントを自作していたら、ラジオインプットのアイコンと、ラベルのテキストがどうしても揃ってくれなかった。
いろいろ試してみたところ、特定のfont-family指定をしたときに縦揃いがしてくれなかった。
英数はmaterialUI推奨のRoboto をGoogleFontsから読み込んで使用、和文は我らのヒラギノを使う(デバイスにインストールされていれば..)ような 合字の指定がされていたが、その指定がなんか悪さをして文字が若干上にあがっていた。
調べたこと
マークアップと、スタイリングを再現して同様の状態を作った。
font-famiryを適当に当てたとこと、ヒラギノとRobotoが共存してるときに、微妙な縦のズレが発生してるようだった。1pxくらいだけど
あと、Noto Sans JPと Robotoでも同じようなズレあった。 さらにNoto Sans JP のみのとき では逆方向に1pxずれてる謎。
ちなみに
icon-fontを使用して、アイコンとテキストを同じinline-blockの親を持つような構造にしてあげればアイコンとテキストでズレは生じませんでした。 こんな感じ↓
<span> <i /> <span>text</span> </span>
ちなみに2
ズレを起こしたのは以下みたいな感じで、フレックスで縦中央揃えをさせようとしてたけど、アイコンの中央と、inline-blockの中央が揃わなかったからずれちゃったんでしょう。
<span style="display: flex: align-items: center"> <i> <span>text</span> </span>
調べるのにつくたcodepenのpen
See the Pen baseline shifts because of font-family __ with checking text block size by kohei sakamoto (@eeonk) on CodePen.
各font-family のときのinline-blockのサイズの変わり方と、位置も見てみた
なんだか、inline-block内でも中央若干ずれてるやついるし、inline-block自体も行ブロックに対して中央にいないやついる。何も信じれなくなった。 そしてfont-size: 20px とか大きい指定をし始めると、特に縦ずれたりしなくなる。つらい
おそらく、フォントによってbase-lineが違うとかそんな理由で、縦のサイズが変わったり中心が動いたりするんだろうなと、無理やり納得することにします。詳しくはわからない。 font-size が大きくなると解決するのもよくわからんけど、font-size小さいときには、小数点以下の数値の扱いのせいできっとズレが生じるんだろうなと勝手に思っておきます。
調べるのにつくたcodepenのpen
See the Pen flex & text block size by kohei sakamoto (@eeonk) on CodePen.
解決案
ちなみに、原因調査前の応急処置としては、iconのheightを -2pxとかしてごまかした。(ラジオではサイズが可変する想定はなかったので)
その他の解決案としてはいかがかんがえられるのかなと言う感じ
- font-family 見直す
変えれるものなら... - icon-font使用して同じinline-blockの中に配置する
ただし、レイアウトに制限掛かりそう親のブロックに対してテキストは左右中央、アイコンは右寄せとかつらそう - テキストを lineheight: 1 にしてまう。
テキストの折返しできなくなっちゃうけど - 気になる人には気持ち悪く感じるけど、諦める。
いろいろ調べてみたけど、気持ち悪い事実だけがわかって、最適な解決方法はイマイチわかんなかった。 くわしいひとおしえて
ユーティリティークラスベースのcss設計に抵抗感があった俺を、それを使いたい俺が説得する
Tailwind CSSいいなあ熱が自分の中で高まっているので、Tailwind CSSの根幹でもあるユーティリティクラスベースのcss設計について書いてみます。 (ユーティリティクラスベースじゃなくて、Tailwind CSSではユーティリティファーストっていっているけど、まあいいか)
cssに関してreact、vueとかのコンポーネントベースのフロント実装をしっかり始める前までは、スクラッチでフロント開発を行う際には、FLOCSSやら、SMACCSやらのCSS設計思想に基づいて、ガッチガチのCSS設計をして、CSSの崩れや破綻を根絶する!と息巻いていました。
というのも、3年とか前の話です。
その後reactを書き始めると、css_modules, styledComponents などの恩恵で、そこまでガチガチな、css設計思想が不要になって来ます。
ユーティリティクラスとは何
クラス名がそのまま、cssのプロパティとその値をそのまま表現しているもの。
例えば極端な話、margin-top-10px
とかをdiv要素に当てると、そのままmargin-top: 10px
を 指定することができるというもの(本当はそんなそんな直球な命名じゃなくて、mt-4
みたいな感じだけど)
FLOCSS(https://github.com/hiloki/flocss)では以下の様に説明されています。
ComponentとProjectレイヤーのObjectのモディファイアで解決することが難しい・適切では無い、わずかなスタイルの調整のための便利クラスなどを定義します。 Utilityは、Component、ProjectレイヤーのObjectを無尽蔵に増やしてしまうことを防いだり、またこれらのObject自体が持つべきではないmarginの代わりに.mbs { margin-bottom: 10px; }のようなUtility Objectを用いて、隣接するモジュールとの間隔をつくるといった役割を担います。 またclearfixテクニックのためのルールセットが定義されているヘルパークラスも、このレイヤーに含めます。
つまり、ユーティリティークラスは、あくまで補助としての役割である。
これだけみると、「ユーティリティークラスベースでcss書いていくとかどういうことやねん」です。
話は変わってきた
「ユーティリティークラスベースでcss書いていくとかどういうことやねん」だったわけだったんですが、話しは変わってきました。
まずそもそも、なぜユーティリティークラスを補助として使わなかったのか、それはなるべく要素に対して、少ないクラス名をつけることでスタイリングをしたかったから。
例えば、list
とつければリストの見た目になって欲しかったし、リストの子要素はlist__item
とつければちゃんとした見た目になって欲しかったから。
同じ部品を作るために、同じクラスをつける必要があったから。
でも、vueやreactならば、部品(コンポーネント)を呼び出せば、特に毎回classを当てなくても(component内部でclassを当てたりはしてるはずだけど)、listはリストの見た目をしてくれるし、list__itemはリストの子要素の見た目をしてくれる。 さらにcssModulesや scoped style や styledComponents を使えば、componentの中に影響範囲を絞ることもできる幸せ
コンポーネントにスタイルが閉じ込められているのではれば、たとえばコンポーネント内で
<div class=“display-block background-color-blue border-rardius-50 border-1px border-style-solid border-color-bloack box-sizing-border-box margin-none padding-10px”>
みたいなえげつないクラスをつけていても、同じような部品を使いたいときは、その部品をきっと呼び出すだろうし、 コンポーネントの呼び出し先ではきっと、コンポーネントの命名が正しければそれで良くて、きっと中身のクラスに関してはクラスの命名なんて全く気にしないはず。
みたいな感じで、コンポーネントベースでの実装においては、CSS の命名規則はそこまで厳格にガッチガチにする必要はないのでは?(コンポーネントが適当に分けられていて、かつちゃんと命名されていれば)
駄目押し
割とここまでで、個人的に結構ユーティリティークラスベースいいやんとなってきましたが、駄目押しに Tailwind CSS のドキュメントで紹介されいる利点をあげます。
" You aren't wasting energy inventing class names. "
クラス名に悩む必要がない!
明確に main-content
とか list-card
とかがあるんだったら良いけれど、ドキュメント内で例であげられている様な、sidebar-inner-wrapper
の様な「おそらくレイアウトのために生まれたんだろうなあ...」な要素に対してのクラス名に悩ませる必要がなくなります!幸せ。
" Your CSS stops growing. "
CSSが成長し続けることがない!
そりゃあそうですね、普通に画面やパーツが増えるごとにcssを追加していけば、cssの量はどんどん増え続けます。基本的にユーティリティークラスを再利用してスタイリグを進めていくので、cssの増加はほとんどないはずです。
" Making changes feels safer. "
変更が怖くない!
cssはグローバルに影響を及ぼします。そのために、命名記法を厳格に設計し名前空間を区切るなどをして、なんとかそれを回避するぞするんですが、ユーティリティークラスベースならば、基本的に要素へのクラスの追加、付け替えしか起きないはずなのでグローバルのstyleに影響を及ぼさない。つまり変更により他のクラスを壊してしまう心配がありません。
まとめ
ざっくりとこんな感じの理由で、ユーティリティークラスベースのcss設計やりたくなりました。 多分他にも旨みや、これだから「ユーティリティークラスベース」でも心配ないとか多分きっとあると思いますが、結局はフロント開発を進める上でcssとHTMLとで構造を二重で管理するのが辛かんったんだなあとしみじみ感じました。
参考
GitHub - hiloki/flocss: CSS organization methodology. Utility-First - Tailwind CSS CSS Utility Classes and "Separation of Concerns" 翻訳 - Qiita
cssnight shift#13 行く時代来る時代に行ったレポート
昨年12/21土曜に開催された CSS Night の一年の総まとめ的イベントに参加してきたので、その感想とかをまとめます
(2019年中に書くとか言っておきながら、1ヶ月も経ってしまったが、程よく自分の中で消化できた文章が書けると信じる。)
(CSS Nightについてよく知らない人は CSS Nightについてを見ると良いです。cssの話するだけのイベントじゃなくて、デザイン要素多めのweb制作系の勉強会です。)
当日の様子は、Togetterを見ると雰囲気わかります。
本題
なぜこのイベント来たのか
去年も行って楽しかったから。毎年のほぼ固定セッションとしてあるwebアクセシビリティ、デザイントレンドが個人的にストライクなのでというのと、そのほかセッションに関しても思わぬ発見があって楽しいのでという理由で行きました。
総括
とくにWebアクセシビリティの良かった。全盲の辻さん((@katsutoshitsuji)https://twitter.com/katsutoshitsuji)の話を聞けたこと、実際にスクリーン・リーダーでWebを読むときにある、読みやすい/づらいことを当事者から聞けたことがすごくよかった。
あと、スペシャルセッションの「Webサイト制作とビジネスの話」よかった。
当日の資料について
イベント参加者に対して、フォローアップという形で、資料と登壇者からのコメント(話し漏れとか質問への回答)が共有されてます。
しばらくの間はイベント参加者だけの特典という形で限定公開されてます(id, passを参加者に共有されてる)。
当面は参加者のみの特典、3ヶ月後くらいをめどに一般公開という流れです。ブログやTwitterにて、ログイン情報の露出は避けてください。社内であればOKです。
ということなので、すいませんここでは資料共有できません。(一応、id, pass あったら入れるリンク https://cssnite.jp/lp/shift13/followup/)
早くみたい方は身近なshift13行った人間を探して、共有してもらうと良いと思います。 あと、当日のセッションの動画もアップされてるので、気になったセッションは見返せるみたいです。
(ちなみに前回の 2018-2019の様子はこちらのリンクです)
各セッションの内容
※ 全セッションに対して本気で内容と、感想書くと書くのも辛いし読むのも辛いので、適度に力を抜きます
基調講演 「2020年、ウェブ業界で活躍し続けるために」
登壇者: 中川 直樹さん(アンティー・ファクトリー)、 志水 哲也さん(タービン・インタラクティブ)
長年Web業界で仕事をしてきた中、また昨今の業界の変化からの、これから我々どうあるべきか的な話でした。
だいたいこんな感じ
ハイライト
- 突然始まる漫才
- 仕事で壁にぶつかったとき、どうする? → 壁あったら絵を描く(バンクシー) → 壁絵といえばアルタミラの洞窟壁画 → 壁画描くのも仕事だったはず → 今も昔もやってることは変わらないんや…(本題へ…)
- 壮大な始まり方にビビる。会場若干取り残され気味
- (本題はしっかりしてた)
- 取り巻く環境の変化の目まぐるしさ → Web制作の現場で扱うものもどんどん変わってくる
- さらに、AI等による自動化ツールの顧客への普及でWeb制作会社のあり方が変わってくるでしょう
Web制作業界に対して、昔のような「クライアント『コレ作って』、制作『作ったよ』」 みたいな関係はもう厳しいよね、でも仕事のスタンスはきっと変わらないはず!、これを意識して、取り残されないように頑張りましょう! ということかな。わかる!
話のスピード的にも怒濤の基調講演だった。
マーケティング「トレンドを総ざらい ウェブマーケティング」
登壇者: 益子 貴寛さん(まぼろし)、吉村 正裕さん(サイバーアシスト)
8つの事柄について、今年あった目立ったニュースを総ざらい。
8つの事柄は、プライバシー
SNS
クチコミ
オウンドメディア
動画
広告
EC
AI
について。
オウンドメディアの話で、「各社のオウンドメディア外部化が増えてる」「 外部サービス(note, youtube, ~~ブログ)で公開することで、顧客とつながるコンテンツは、外に置く というトレンドがあった。」というのがったが、 たしかに、楽だし、リソースも少ないし、見てくれる導線作りやすい。
あとは、プライバシーの話で出た、私生活データの売買実験「PROJECT EXOGRAPH」とかは初見だった。きになる。 (https://exograph.plasma.inc/)
自分と離れてる分野のことも、ある程度把握しときたいなあと思えるセッションだった。
アドビ「2019年Adobe最新情報+αをしっかりおさえる30分!」
登壇者: 浅野 桜さん(タガス)、黒野 明子さん(crema design)
AdobeMAX で発表された、Adobeツールの最新情報の話がメインのセッションだった。
気になったのは
- Adobe ipad アプリ
- photoshop(写真編集から機能が用意されてる)。機能拡充に期待。 * 開発中のillustolator。 パスをペンで書けるらしい。← 触りたい
- セッションのスライドを XDを使って共同編集していた。 * 実際に業務で使う上でのAi,PsとXDの、特徴の説明の中で、「XD共同編集に向いてるよ」からの今回のスライドを実はXDで作っていた事実。 ← 良さそう。今度やりたい。
発表最後の方の、デザインツール戦国時代みたいな感じじゃなくて、相互のツールが連携するようになってきていることを表すスライドがすごい良だった。
adobe sensei すげえなもあったけど、早くファイルフォーマットに縛られずに、デザインファイルを好きなツールで開ける時代が来てほしいと思えるセッションだった。
スペシャル「ウェブサイトをビジネスから考えるための競合分析」
登壇者: 権 成俊さん(ゴンウェブコンサルティング)
若干基調講演と話題と似ている感じの話だが、より具体的な話でとても興味深い内容だった。
概要はWeb制作において、顧客に提供する価値は、成果物じゃなくて成果物から得られる結果であり、それを実現するためにWeb制作の段階で戦略必要だよね という話。
Web制作者が中小企業の命運を握る言っても過言ではない状況になってきており、その状況に対してWeb制作会社は依頼された制作物を作るだけ、調査されたことを調査するだけにならないようにしようぜで、 実際に権さんが AB3C分析 という手法で、分析と提案を行った事例の紹介がメインだった。
AB3C分析とは、お客さま(customer)、競合他社 (competitor)、自社の強み(company)の3Cに加えて、お客様が自社、競合に対して求めるベネフィット(Benefit)、競合と自社の間にある優位点(Advantages)まで分析して戦略立てましょうというもの。
事例は、信州の小諸産そば粉を目玉として売るそば粉屋さんの売り上げ減に対する施策で、最終的に 顧客を信州の居酒屋、競合を鍋の締めのラーメン・雑炊、そば湯として使ってもらう蕎麦以外の使用法としてもそば粉を売れるのではという提案をしていた。
また、まとめで言っていた『「分析しました、これが分析結果です」では「だから、なに?」となってしまう、クライアントが求めているのは「分析結果に基づいた、戦略提案」である』というのも、お客様が求めているものは何なのかを、考えればあたりまえのことだし、 依頼されて作っている身としては、お客様が複数種類存在して(クライアントと、クライアントのお客さんなど)それぞれが求めているものを順を追って満たさないといけんのだよなあとしみじみ思った。
成果物をつくるというよりも、ツールとしての成果物をつくってそれが実際に機能する(問い合わせ増えるとか、売上ふえるとか)につながらないと、つくっただけになっちゃって意味がないんだよな...。
あと、デジタルトランスフォーメーション(DX)という用語を初めて知った。 DepelopmentExperience ではないDX。
アクセシビリティ「辻ちゃん・ウエちゃんのAccessiブル GO! GO!「アクセシビリティ ゆく年来る年 2019」の巻」
登壇者: 植木 真さん(インフォアクシア)、辻 勝利さん(コンセント)
ただただ楽しかった。 植木さんの、飽きさせず、アクセシビリティのことを伝える熱意的なものがバシバシ伝わってきた。
本編はWebアクセシビリティあるあるランキングということで、診断を行った36サイト内で、多く見受けられたアクセシビリティ満たせてない要件のランキングと共に、「こうすると良いね」とかをはなす感じ。
全盲の辻さんの実体験だったりを交えて聞くことで、新しい発見や身近に感じることが多かった。
ランキング内では「画像の代替テキストが適切ではない」が堂々の1位。その中でも多いと思っていた 「imgのalt属性ついてない」が全体の5%程しかないのに結構おどろきだった。みんなちゃんと付けるようになってる! 「css背景画像を用いている」が一番多いのには、なんとなく納得できたし、やったことが結構ある身としては胸が痛かった...
ほとんどの対応項目が少し気をつければ簡単にできそうなことだが、話を聞くと少し怠るだけで結構インパクトのあるの使いづらさが生まれるというのが結構響いた。 ランクイン項目の殆どが、weba11y.jp | Webアクセシビリティ確保 基本の「キ」 に書いてるよとのことだったが、結構初めて聞くこと多かった。(ちゃんと読めてない...読む)
A11y対応はすべてのWeb閲覧者に対して必要というのと、WebA11yは「対応する」ではなく「高めていくもの」というのが再認識できてよかった。
あと、2020年は 辻さん植木さんで スクリーンリーダを使ったweb閲覧のサンプル動画集てきなのをYouTubeに公開するらしい楽しいみ。
フォント「おさえておきたい文字まわりのトレンド 2019」
登壇者: 関口 浩之さん(SBテクノロジー)、鷹野 雅弘さん(スイッチ)
フォントの熱い話だった。 いつもは関口さんが暴走して、さらに熱く語り始めたりとかがあるが今回は若干控え気味だった。でも熱かった。
特に衝撃だったのは、
- 「ヴ」がなくなるはなし https://www.nhk.or.jp/politics/articles/feature/15156.html
- オリンピックピクトグラム刷新&追加の話からの 「綾瀬はるか、雑に画像切り抜きレギュレーション説」
- IKEAの行き過ぎたコーポレートフォント”SOFFA Sans”
- などなど...
ふつうにスライド見返すだけでもおもしろいわ
早くスライド一般公開してくれ...
まとめで高野さんが言っていた 「ウェブコンテンツはデザイナーのこだわりから自由になった」というのがよかった。
端末やブラウザの設定で、フォントや文字サイズ、色まで自由に変えれるようになったことで、利用者が気分や好みでそれらを変えれるようになったという話。 自覚はしていたけど、実際にそういうコンテンツの使われ方がすることに対して、しっかり考えていなかったので、デザイナどうすんだ?という期待みたいなのをかんじた。 個人的には、どんな見方をされても、「ちゃんと見える・使える」を目指しつつ、ブランド的に「こう見えてほしいんや」をデフォルトの表示として作っていくのかなと思う。
動画「字幕がつなぐ、ウェブと動画のこれからの関係」
登壇者: 後藤 賢司さん(よつばデザイン)、たにぐち まこと さん(ともすた)
本題は、動画をより効果的にするために 動画に付ける 字幕の大事さ を伝える話でした。
かといって、映像の中に字幕を入れてしまうと、ものによっては意図していた動画のイメージを壊してしまう場合もあります。 なので場合によって使い分けましょうね、というのと...
CC(Closed Caption) とうやつがあるので、つけれる場合はできる限りつけましょうという話でした。
動画メディア配信するときに、字幕入れよう & 字幕入れるときの最低限守ろうがある
あと、CCつけるときにも 1行の文字数が多すぎる
行が多すぎる
切り替わりが早すぎる
みたいなことがないように気をつけなきゃなのは確かに忘れそう、気をつけよう。
あと、字幕の話が始まる前の
動画コンテンツどういうときに使ったらいいの?どんなふうに使ったらいいの? → 理屈よりも、脳で一瞬で理解、直感的に理解してもらいたいときに! みたいな話、すごいよかった。
動画コンテンツ活用するタイミング(作り始める前)には、このセッションの内容とても役に立ちそうな感じがした。そのときに参考にします。
Webデザイントレンド
登壇者: 原 一浩さん(カンソクインダストリーズ)、矢野 りん さん(バイドゥ)
cssnite shiftのおなじみセッションで、その年のデザイントレンド総ざらいするというもの。 今回は、以下の4つのカテゴリについて、それぞれベスト7を作成してふりかえっていました。 - 海外Webデザイン編 ( 3000 サイトより ) - 世界の大学編 ( 1800 サイトより ) - 日本の上場企業編 ( 3400 サイトより ) - 日本の自治体編 ( 1700 サイトより )
ちなみに”トレンドとは最先端ではない 時代に最適化されつつある現象である” というトレンドの定義で、 好きなwebデザイン、良いwebデザインのランキングではない。
個人的に、スライドの見方のところに書いてある、ランクインした各サイトにつけられるキャッチコピーの的確な感じや、独特な言い回しがすごいツボだった。
↓ 下の画像の左肩の文字
あと、発表内の個人的見解がとても良かった。ので、このセッションはぜひ動画で見たがいい。
あとは、発表スライド用いて数人でデザイン分析みたいなのやっても楽しそう、ためになりそうやなと思った。
まとめ
40minくらいのセッションが8本、楽しいのは楽しかったが、終わったあと感じたのは「疲れた」だった。情報量が多くて話聞いてるだけなの、後半息切れするくらいハードなイベントでした。次行くときは体力をもっとつけて望むか
あと、会場に同時ライブ字幕システムみたいなのを入れてたけど、休憩中のBGMを必死に翻訳姿がよかった
同時字幕システムがBGMも字幕に起こしてくれようとしている
— さかもとこうへい (@12kohe3i) December 21, 2019
多分こう
うーん→ シンセの低い音
です→ ドラムの音
提訴→ ていそ?#cssnite pic.twitter.com/JnGAYMZBN2
'UX Engineer Meetup' に行ってきた
先週末(10/7)に行われたイベント、'UX Engineer Meetup' に行ってきたので、その感想を書きます。
イベント概要
- 'UX Engineer Meetup'
- twitterハッシュタグ: #uxe_meetup
- 主催: Goodpatch Inc.
- 概要
近年、エンジニアでありながらもデザイン領域へ越境し、独自の価値を提供する人たちがいます。 しかし、その役割は組織やプロダクトによって様々であるためにイメージは定着しておらず、具体的に何をしているのか、よく分からないと感じる人も多いのではないかと思います。 今回はUXエンジニアとして活動している人たちが、どのような価値観を持ち、どのような活動をしているのかを共有することによって、同じような価値観を持つ人たちに向けて、ざっくばらんにナレッジや悩みを共有し合う場にしたいと考えています。
なぜこのイベントに行ったのか
いくぞと思ったきっかけは、今年の5月にあった 'InsideFrontend #3' で 'デザインエンジニアとフロントエンド 'という話があり、その中でデザインエンジニアやUXエンジニアに触れてたから。そっからずっと気になってた。
続きを読む