sakamotoko blog

たぶんweb系の技術ブログ @skmtko

font-family の設定が原因で行ブロック内のテキストが縦中央揃えされない?

話したいこと

font-family:  Roboto, "Hiragino Kaku Gothic ProN", … ;

みたいな設定していたら、日本語のベースラインがずれて、テキスト + アイコン の縦がズレズレになってた。

調べてみたら、詳細な原因はよくわからんけど、フォントによって中央揃えしたときの揃い方だいぶ違いそうだったので、調べて分だけまとめる。

ちなみにデバイスヒラギノ入っている人の表示しか考慮できていないです。

きっかけ

inputRadioのコンポーネントを自作していたら、ラジオインプットのアイコンと、ラベルのテキストがどうしても揃ってくれなかった。

f:id:skmtko:20200628181504p:plain
こんな感じで、テキストが若干上がってしまう

いろいろ試してみたところ、特定のfont-family指定をしたときに縦揃いがしてくれなかった。

英数はmaterialUI推奨のRoboto をGoogleFontsから読み込んで使用、和文は我らのヒラギノを使う(デバイスにインストールされていれば..)ような 合字の指定がされていたが、その指定がなんか悪さをして文字が若干上にあがっていた。

調べたこと

マークアップと、スタイリングを再現して同様の状態を作った。

f:id:skmtko:20200628182441p:plain
font-family 指定なし

f:id:skmtko:20200628182524p:plain
Robot, Hiragino 指定

f:id:skmtko:20200628182623p:plain
Roboto, Noto Sans JP 指定

f:id:skmtko:20200628182721p:plain
Noto Sans JP 指定

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のサイズの変わり方と、位置も見てみた

f:id:skmtko:20200630215553p:plain
各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の中に配置する
    ただし、レイアウトに制限掛かりそう親のブロックに対してテキストは左右中央、アイコンは右寄せとかつらそう
    f:id:skmtko:20200630222734p:plain
    こんな感じの使い方
  • テキストを lineheight: 1 にしてまう。
    テキストの折返しできなくなっちゃうけど
  • 気になる人には気持ち悪く感じるけど、諦める。

いろいろ調べてみたけど、気持ち悪い事実だけがわかって、最適な解決方法はイマイチわかんなかった。 くわしいひとおしえて

ユーティリティークラスベースのcss設計に抵抗感があった俺を、それを使いたい俺が説得する

Tailwind CSSいいなあ熱が自分の中で高まっているので、Tailwind CSSの根幹でもあるユーティリティクラスベースのcss設計について書いてみます。 (ユーティリティクラスベースじゃなくて、Tailwind CSSではユーティリティファーストっていっているけど、まあいいか)

f:id:skmtko:20200525132325p:plain
ユーティリティークラス 結構いいやつなんやなと感じてきた...

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 行く時代来る時代に行ったレポート

f:id:skmtko:20200203013516p:plain 昨年12/21土曜に開催された CSS Night の一年の総まとめ的イベントに参加してきたので、その感想とかをまとめます

(2019年中に書くとか言っておきながら、1ヶ月も経ってしまったが、程よく自分の中で消化できた文章が書けると信じる。)

Shift13:Webデザイン行く年来る年(CSS Nite LP59)

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」とかは初見だった。きになる。 f:id:skmtko:20200202180159p:plainf:id:skmtko:20200202180215p:plain (https://exograph.plasma.inc/)

自分と離れてる分野のことも、ある程度把握しときたいなあと思えるセッションだった。    

アドビ「2019年Adobe最新情報+αをしっかりおさえる30分!」

登壇者: 浅野 桜さん(タガス)、黒野 明子さん(crema design)

AdobeMAX で発表された、Adobeツールの最新情報の話がメインのセッションだった。 

気になったのは

  • Adobe ipad アプリ
    • photoshop(写真編集から機能が用意されてる)。機能拡充に期待。   * 開発中のillustolator。 パスをペンで書けるらしい。← 触りたい
  • セッションのスライドを XDを使って共同編集していた。   * 実際に業務で使う上でのAi,PsとXDの、特徴の説明の中で、「XD共同編集に向いてるよ」からの今回のスライドを実はXDで作っていた事実。 ← 良さそう。今度やりたい。
    f:id:skmtko:20200202180537p:plain
    共有されたスライドの一部(XDの共有リンクだった)

発表最後の方の、デザインツール戦国時代みたいな感じじゃなくて、相互のツールが連携するようになってきていることを表すスライドがすごい良だった。

f:id:skmtko:20200202180843p:plain
発表スライドの最後あたりのスライド

adobe sensei すげえなもあったけど、早くファイルフォーマットに縛られずに、デザインファイルを好きなツールで開ける時代が来てほしいと思えるセッションだった。

 

スペシャル「ウェブサイトをビジネスから考えるための競合分析」

登壇者: 権 成俊さん(ゴンウェブコンサルティング

若干基調講演と話題と似ている感じの話だが、より具体的な話でとても興味深い内容だった。

概要はWeb制作において、顧客に提供する価値は、成果物じゃなくて成果物から得られる結果であり、それを実現するためにWeb制作の段階で戦略必要だよね という話。

Web制作者が中小企業の命運を握る言っても過言ではない状況になってきており、その状況に対してWeb制作会社は依頼された制作物を作るだけ、調査されたことを調査するだけにならないようにしようぜで、 実際に権さんが AB3C分析 という手法で、分析と提案を行った事例の紹介がメインだった。

AB3C分析とは、お客さま(customer)、競合他社 (competitor)、自社の強み(company)の3Cに加えて、お客様が自社、競合に対して求めるベネフィット(Benefit)、競合と自社の間にある優位点(Advantages)まで分析して戦略立てましょうというもの。

事例は、信州の小諸産そば粉を目玉として売るそば粉屋さんの売り上げ減に対する施策で、最終的に 顧客を信州の居酒屋、競合を鍋の締めのラーメン・雑炊、そば湯として使ってもらう蕎麦以外の使用法としてもそば粉を売れるのではという提案をしていた。

また、まとめで言っていた『「分析しました、これが分析結果です」では「だから、なに?」となってしまう、クライアントが求めているのは「分析結果に基づいた、戦略提案」である』というのも、お客様が求めているものは何なのかを、考えればあたりまえのことだし、 依頼されて作っている身としては、お客様が複数種類存在して(クライアントと、クライアントのお客さんなど)それぞれが求めているものを順を追って満たさないといけんのだよなあとしみじみ思った。

成果物をつくるというよりも、ツールとしての成果物をつくってそれが実際に機能する(問い合わせ増えるとか、売上ふえるとか)につながらないと、つくっただけになっちゃって意味がないんだよな...。

あと、デジタルトランスフォーメーション(DX)という用語を初めて知った。 DepelopmentExperience ではないDX。

アクセシビリティ辻ちゃん・ウエちゃんのAccessiブル GO! GO!「アクセシビリティ ゆく年来る年 2019」の巻」

登壇者: 植木 真さん(インフォアクシア)、辻 勝利さん(コンセント)

ただただ楽しかった。 植木さんの、飽きさせず、アクセシビリティのことを伝える熱意的なものがバシバシ伝わってきた。

本編はWebアクセシビリティあるあるランキングということで、診断を行った36サイト内で、多く見受けられたアクセシビリティ満たせてない要件のランキングと共に、「こうすると良いね」とかをはなす感じ。
全盲の辻さんの実体験だったりを交えて聞くことで、新しい発見や身近に感じることが多かった。

f:id:skmtko:20200203021327p:plain

ランキング内では「画像の代替テキストが適切ではない」が堂々の1位。その中でも多いと思っていた 「imgのalt属性ついてない」が全体の5%程しかないのに結構おどろきだった。みんなちゃんと付けるようになってる! 「css背景画像を用いている」が一番多いのには、なんとなく納得できたし、やったことが結構ある身としては胸が痛かった...

f:id:skmtko:20200203020916p:plain

ほとんどの対応項目が少し気をつければ簡単にできそうなことだが、話を聞くと少し怠るだけで結構インパクトのあるの使いづらさが生まれるというのが結構響いた。 ランクイン項目の殆どが、weba11y.jp | Webアクセシビリティ確保 基本の「キ」 に書いてるよとのことだったが、結構初めて聞くこと多かった。(ちゃんと読めてない...読む)

A11y対応はすべてのWeb閲覧者に対して必要というのと、WebA11yは「対応する」ではなく「高めていくもの」というのが再認識できてよかった。

あと、2020年は 辻さん植木さんで スクリーンリーダを使ったweb閲覧のサンプル動画集てきなのをYouTubeに公開するらしい楽しいみ。   

フォント「おさえておきたい文字まわりのトレンド 2019」

登壇者: 関口 浩之さん(SBテクノロジー)、鷹野 雅弘さん(スイッチ)

フォントの熱い話だった。 いつもは関口さんが暴走して、さらに熱く語り始めたりとかがあるが今回は若干控え気味だった。でも熱かった。

特に衝撃だったのは、

ふつうにスライド見返すだけでもおもしろいわ

早くスライド一般公開してくれ...

まとめで高野さんが言っていた 「ウェブコンテンツはデザイナーのこだわりから自由になった」というのがよかった。

端末やブラウザの設定で、フォントや文字サイズ、色まで自由に変えれるようになったことで、利用者が気分や好みでそれらを変えれるようになったという話。 自覚はしていたけど、実際にそういうコンテンツの使われ方がすることに対して、しっかり考えていなかったので、デザイナどうすんだ?という期待みたいなのをかんじた。 個人的には、どんな見方をされても、「ちゃんと見える・使える」を目指しつつ、ブランド的に「こう見えてほしいんや」をデフォルトの表示として作っていくのかなと思う。

動画「字幕がつなぐ、ウェブと動画のこれからの関係」

登壇者: 後藤 賢司さん(よつばデザイン)、たにぐち まこと さん(ともすた)

本題は、動画をより効果的にするために 動画に付ける 字幕の大事さ を伝える話でした。

かといって、映像の中に字幕を入れてしまうと、ものによっては意図していた動画のイメージを壊してしまう場合もあります。 なので場合によって使い分けましょうね、というのと...

CC(Closed Caption) とうやつがあるので、つけれる場合はできる限りつけましょうという話でした。

動画メディア配信するときに、字幕入れよう & 字幕入れるときの最低限守ろうがある あと、CCつけるときにも 1行の文字数が多すぎる 行が多すぎる 切り替わりが早すぎる みたいなことがないように気をつけなきゃなのは確かに忘れそう、気をつけよう。

あと、字幕の話が始まる前の

動画コンテンツどういうときに使ったらいいの?どんなふうに使ったらいいの? → 理屈よりも、脳で一瞬で理解、直感的に理解してもらいたいときに! みたいな話、すごいよかった。

動画コンテンツ活用するタイミング(作り始める前)には、このセッションの内容とても役に立ちそうな感じがした。そのときに参考にします。

 

Webデザイントレンド

登壇者: 原 一浩さん(カンソクインダストリーズ)、矢野 りん さん(バイドゥ

cssnite shiftのおなじみセッションで、その年のデザイントレンド総ざらいするというもの。 今回は、以下の4つのカテゴリについて、それぞれベスト7を作成してふりかえっていました。 - 海外Webデザイン編 ( 3000 サイトより ) - 世界の大学編 ( 1800 サイトより ) - 日本の上場企業編 ( 3400 サイトより ) - 日本の自治体編 ( 1700 サイトより )

ちなみに”トレンドとは最先端ではない 時代に最適化されつつある現象である” というトレンドの定義で、 好きなwebデザイン、良いwebデザインのランキングではない。

個人的に、スライドの見方のところに書いてある、ランクインした各サイトにつけられるキャッチコピーの的確な感じや、独特な言い回しがすごいツボだった。

↓ 下の画像の左肩の文字

f:id:skmtko:20200202174222p:plain
デザイントレンドのスライドの見方のスライド

あと、発表内の個人的見解がとても良かった。ので、このセッションはぜひ動画で見たがいい。

あとは、発表スライド用いて数人でデザイン分析みたいなのやっても楽しそう、ためになりそうやなと思った。

 

まとめ

40minくらいのセッションが8本、楽しいのは楽しかったが、終わったあと感じたのは「疲れた」だった。情報量が多くて話聞いてるだけなの、後半息切れするくらいハードなイベントでした。次行くときは体力をもっとつけて望むか

あと、会場に同時ライブ字幕システムみたいなのを入れてたけど、休憩中のBGMを必死に翻訳姿がよかった

'UX Engineer Meetup' に行ってきた

f:id:skmtko:20191015032840p:plain 

先週末(10/7)に行われたイベント、'UX Engineer Meetup' に行ってきたので、その感想を書きます。

イベント概要

  • 'UX Engineer Meetup'
  • twitterハッシュタグ: #uxe_meetup
  • 主催: Goodpatch Inc.
  • 概要

    近年、エンジニアでありながらもデザイン領域へ越境し、独自の価値を提供する人たちがいます。 しかし、その役割は組織やプロダクトによって様々であるためにイメージは定着しておらず、具体的に何をしているのか、よく分からないと感じる人も多いのではないかと思います。 今回はUXエンジニアとして活動している人たちが、どのような価値観を持ち、どのような活動をしているのかを共有することによって、同じような価値観を持つ人たちに向けて、ざっくばらんにナレッジや悩みを共有し合う場にしたいと考えています。

なぜこのイベントに行ったのか

いくぞと思ったきっかけは、今年の5月にあった 'InsideFrontend #3' で 'デザインエンジニアとフロントエンド 'という話があり、その中でデザインエンジニアやUXエンジニアに触れてたから。そっからずっと気になってた。

続きを読む

約1ヶ月スクラム開発したので、スクラムガイド(公式)を読む

はじめに

今月頭に転職し新しい会社(ROXX.inc)に入社して、担当になったプロダクト(agent bank)の開発でスクラム開発を採用していたのでそれについて書きます。

個人的にかっちりしたスクラム開発のするのが初めてで、結構新鮮だったので、スクラムガイドを読みながらスクラム開発について復習しつつ、1ヶ月のスクラムを振り返る。振り返りというか、ちゃんとスクラム読んだよっていう記録。

スクラムをよく知らない人はこれから読む スクラムガイドの日本語訳 を読んだり、ググったりお願いします土下座。

スクラムガイドとは

スクラムの開発者であるKen Schwaber 氏, Jeff Sutherland 氏による公式のルールブック。https://www.scrumguides.org
日本語版の翻訳はMasanori Kadoさん他。感謝

スクラム開発を行なうのなら読むべきらしい。

先にまとめ

全部読んで長かった、ので先にまとめ書いとく。
振り返ると言いつつ後半疲れてほぼ読むだけになった。

「透明性」、「検査」、「適応」がすごく大事 & 大事なことがわかった。
個人的に1ヶ月スクラムに参加してみて、まだその恩恵的なものははっきり実感できてないが、(あと、各イベントにパワー & 時間がかかる)
もう少しすれば実感が出てくるんだろうなという漠然とした感じ。とりあえず、今回おさらいした内容ちゃんと頭に再びスクラム頑張る。

本題

こっから読む。
(適度にはしょりながら読みます。スクラムガイドを読みながら or 頭に入ってる状態で読んでいただければ助かります)
(特にスクラムガイドの内容を要約するとかはしてない)

スクラムの定義

スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
スクラムとは、以下のようなものである。
• 軽量
• 理解が容易
• 習得は困難

「理解が容易 習得は困難」とあったが、「スクラムとは」とか「どう動く」みたいなことはなんとなく分かった。(以前カジュアルなスクラム開発の経験があったのもあると思うが、たぶん初でもすぐ馴染めただろう...たぶん)
が、やはり実践するとなると、チームの一人ひとりが意識して動かないと、しっかり成果を発揮できるスクラムにはならなそうと感じた。(コミュニケーションの取り方だったり、議論を円滑に進めたりとか)

スクラムは、プロセスフレームワーク」「さまざまなプロセスや技法を取り入れることのできる」と何回も書いてある。確かに、スプリントの振り返りの時とかに毎回 振り返りの方法が変わってた。(みんな毎回同じだと飽きる)
その他の面でも色々とプロセス、技法等の選択肢があるっぽい(詳しく把握してない)

スクラムの用途

クラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、自動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、個人や社会が日常的に使用するあらゆるものに使用されている。
(中略)
スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プロダクト、サービス、所属する組織の管理に広く利用されている。
スクラムの本質は、少人数制のチームである。

確かに少人数チーム。(1チームあたり5人くらい x2チームでやってる)
チームの人数が大幅に増えたらやりずらそうなの、なんとなくわかる。

スクラムの理論

スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。(中略) 経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。 (中略) スクラムでは、検査と適応のための 4 つの公式なイベントを規定している。詳しくは、「スクラムイベント」の節で説明する。

周期的に行われるスクラムイベントによって、チーム全体の経験値を確実に積んでいこうとしているのを感じた。
実際に全員でプランニング(見積もり)やレトロスペクティブ(振り返り)を行うことで、チームで情報を共有できる場が作られていた。
下のスクラムイベントのところで詳しく書く。

大事そうなので、3本柱の「透明性、検査、適応」をさらに噛み砕いてまとめてみる。(違ったら教えて)

• 透明性 ... 「何をするべき」「どういう成果が必要」が明確になっており、チーム内でそのイメージが共有されている。
• 検査 ... 「進捗ダメです」を早めに検知できるようにする。
• 適応 ... 「進捗ダメ」などが許容できないレベルになった時に、必要な成果物を調整するなどして、やばくない状態にする。(決して「命を削ってでも間に合わせるべし」とかいう世界ではない。はず)

スクラムの価値基準

スクラムチームが、確約(commitment)・勇気(courage)・集中(focus)・公開(openness)・尊敬 (respect)の価値基準を取り入れ、それらを実践するとき、スクラムの柱(透明性・検査・適応)は現実のものとなり、あらゆる人に対する信頼が築かれる。

なんだかすごくかっこいい文章が書いてあるぞ。
つまり、スクラム開発を進めながら、5つの価値基準(確約、勇気、.etc)を実践すべしということか。
頑張る。

個人は、スクラムチームのゴールの達成を確約しなければいけない。
スクラムチームのメンバーは、正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。
全員が、スプリントの作業とスクラム チームのゴールに集中しなければいけない。
スクラムチームとステークホルダーは、すべての仕事 とそれらを遂行する上での課題を公開することに合意しなければいけない。
スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。

スクラムチーム

スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。(あと略)

翻訳文が結構英語文でところどころ読解にパワーいる...
スクラムチームとはなんたるかが書いてあった。

つまり、スクラムチームとは ...
 ・ 自己組織化されたチーム( 最善の策を、チーム外からの指示ではなく、自分たちで選択する。)
 ・ 機能横断的なチーム(チーム以外に頼らずに作業を成し遂げる能力を持っている。)
 ・ 柔軟 性・創造性・生産性を最適化するように設計されている。
 ・ プロダクトを反復的・漸進的に届ける。(フィードバックの機会を最大化するため。漸進的に完成プロダクトを提供することで、役立つ可能性のあるバージョンを常に利用可能にする。)

なるほど。
記憶があるうちにフィードバックできるのでありがたいと思います。

プロダクトオーナー

プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。(中略)プロダクトバックログの管理に責任を持つ 1 人の人間である。
(中略)
プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。異なる要求の作業を開発チームに強制することは誰にもできない。

「プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。」にしっくりきた。多分そうなってた。

開発チーム

開発チームは、各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。
開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。 その相乗効果によって、開発チーム全体の効率と効果が最適化される。

「インクリメント」は「成果」的な翻訳であってるだろうか?たぶんあっていると信じる。
開発チームの特徴の内容を読むとメンバーそれぞれの専門や得意不得意がある前提で「インクリメントを作成するスキルをチームとしてすべて備えている」「サブチームは認めない」「最終的な責任は開発チー ム全体が持つ」とあり。開発チーム内のコミュニケーションを促進させるルールになってるなーと感じる。

開発チームの規模

開発チームに最適な人数は、小回りが利く程度に少なく、1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である。

多すぎても、少なすぎてもダメわかる。

スクラムマスター

スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。

大変そう。スクラム行ううえで要的存在だなと感じた。 まだ具体的に何やってるかよく分かってないが、関わりのある場では、スクラムマスターの調整と開発メンバーの協力で成り立ってるな感があった。頼ろう。

スクラムイベント

スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する。

スクラムイベントはだいたい開催タイミングと、所要時間が固定されている。
今のチームでは金曜にたくさんスクラムイベントが集まってる。

スプリント

スクラムの中心はスプリントである。

スプリントを構成するのは

  • スプリントプランニング
  • デイリースクラム
  • 開発作業
  • スプリントレビュー
  • スプリントレトロスペクティブ

今のチームでは1スプリント = 1週間。
スプリントの期間を短め(1ヶ月以内)にするのは、長いとリスクが増えるから。短ければそこまでリスクは大きくならないだろうという考え。だと思っている。

スプリントの中止

スプリントはタイムボックスの終了前に中止できる。(中略)とはいえ、スプリントの中止はめったに発生しない。

なるほどそんな事もあるのかと思った。うちの場合は1週間スプリントなのでそこまでなさそうう & 起きる事ほぼなさそう。

スプリントプランニング

スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業である。

プロダクトバックログから作業を棚卸しして、チーム全体で見積もりを行う場。
作業見積もりする際に曖昧だったりすると、割としっかりタスクを完了するためにどういう方法でやるかまで話してる。
全員で見積もりを行うので、詳しくない分野への見積もりも求められるので、慣れないと負担に感じるが、重ねるたびに「透明性」が上がるんだろう。

ちなみにプランニング時にはプランニングポーカーが採用されている。やってみたかったやつやれて嬉しい。

スプリントゴール

スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するものである。(中略) スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる。(中略) スプリントゴールがあれば、開発チームは一致団結して作業ができる。(中略) 開発チームの予想と異なることが判明した場合は、プロダクトオーナ ーと交渉してスプリントバックログのスコープを調整する。

これちゃんと把握してなかった。
「スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる」なるほど、確かに。ここで「適応」を発揮する。

デイリースクラム

スプリントでは、毎日デイリースクラムを開催する。開発チームは、次の 24 時間の作業を計画する。前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、チームのコラボレーションやパフォーマンスを最適化するのである。(中略)
開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。 (中略)デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害物 を特定・排除し、迅速な意思決定を強調・助長して、開発チームのプロジェクト知識のレベルを向 上させるものである。これは、検査と適応の重要なイベントである。

思いの外長かった、(つまりそれだけ大事なんだろう)
直近の出来事について話す事で「検査」「適応」を活発化させる的なことかな?毎日のイベントになるが作業化せずに、どういう場かちゃんと意識しながら行うのが大事そう。

スプリントレビュー

スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。(中略)
これはステータスミーティングではなく、略式のミーティングである。インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。

開発チームから代表者とスクラムマスター、プロダクトオーナーでやってた気がする。

スプリントレトロスペクティブ

スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。(中略)
スクラムマスターは、このミーティングがポジティブで生産的になるようにする。

結構好きな会だった。(個人的に課題について話すのが好き)
(が、所要時間オーバーしがちなのでなかなか難しい)

組織改善の場として結構重要な場になっていると感じた。

レトロスペクティブの目的は下記の3つ

  • 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
  • うまくいった項目や今後の改善が必要な項目を特定・整理する。
  • スクラムチームの作業の改善実施計画を作成する。

スクラムの作成物

スクラムの作成物は、作業や価値を表したものであり、透明性や検査・適応の機会を提供するものである。スクラムで定義された作成物は、全員が共通理解を得るために必要な情報の透明性を最大化するように設計されている。

プロダクトバックログ

プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。プロダクトに対する変更要求の唯一の情報源である。(中略)プロダクトが存在する限り、プロダクトバックログも存在し続けるのである。 (中略)プロダクトバックログは生きた作成物である。ビジネス要求、市場の状態、技術の変化などが、プロダクトバックログの変化につながる。 複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は1つのプロダクトバックログに記述する。 (中略)プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。 開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。

プロダクトバックログ大事覚えた。
バックログの管理はAtlassianのJIRA使ってる。

ゴールへの進捗を追跡する

いずれかの時点で、ゴールに対する残作業を合計する。

スプリントの期間が1週間なのでデイリースプリント時にたまに進捗の見通しを立てる程度だった。

スプリントバックログ

スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。スプリントバックログは、次のインクリメントに含まれる機能と、その機能を「完成」したインクリメントにして届けるために必要な作業について、開発チームが予想したものである。 スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。(中略)スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チームが計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。
(中略)スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。

スプリントの進捗を追跡する

スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なくともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立 てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。

インクリメント

インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックロ グアイテムを合わせたものである。スプリントの終了時には、新しいインクリメントが「完成」していなければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。インクリメントは、完成していて、検査可能なものであり、スプリントの終了時の経験主義を支援するものである。インクリメントは、ビジョンやゴールに向かうステップである。 プロダクトオーナーがリリースを決定する/しないにかかわらず、インクリメントは常に動作する状態にしておかなければいけない。

インクリメント = 完成している、リリース可能な(ちゃんと動作する)成果だと理解した。

作成物の透明性

スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物の透明性が不完全であれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。 (中略) スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させることである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明性とは長い道のりなのである。

「透明性は一夜にしてならず。透明性とは長い道のりなのである。」かっこいい文章。ただ、実際にやってみた感想はこのかっこいい文章の通りっぽいと実感した。

「完成(Done)」の定義

プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるかもしれないが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これは、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうかの評価に使われる。 (中略)インクリメントの「完成」の定義が開発組織に存在しない場合は、スクラムチームの開発チームはプロダクトに適した「完成」を定義しなければいけない。複数のスクラムチームがシステムやプロダクトのリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使用しなければいけない。

「完成」の定義にも「透明性」が重要。

終わり

長かった。来月以降も頑張る

ブログを始める

熊本出身フロントエンドエンジニアの坂本です。

転職したのをきっかけに 転職先のエンジニアのミッションになっているので ブログを始めます。

このブログでは、仕事などで得た知見や、勉強会参加の記録などを書いていきます多分。

テンションで文章を書きがちなので、おそらく文章が乱れることが予想されるが、自分で振り返った時にちゃんと読めるレベルになるようになんとか制御していきます。

あと最低でも 1本/月 以上のペースで書くように心がける。 あと、前の職場で書いてたブログをこっちに転載するなどして読めるようにする。(リマインド)

以上終わります。