2022-02-28

RSGT2022 の動画が公開されたので、社内で視聴会をやりました

この記事は個人ブログと同じ内容です

みなさん、こんにちは！ ROXX で back check のエンジニア兼、スクラムマスターをやっています。ぐっきーこと山口壮太 (@Area029S)です。

さて、Regional SCRUM GATHERING Tokyo 2022（以下、RSGT2022）が終わって早2ヶ月が経ちました。私も仕事の傍ら、 RSGT で知り合ったアジャイルコミュニティの方が開催されているイベントに参加したり、家族でキャンプしたりとバタバタと予定を詰め込んでいたらあっという間に時間が過ぎてしまいました。

RSGT の視聴会やったよ

ありがたいことに今年も RSGT のセッション動画が公開されましたね。 ROXX でも、 agent bank と back check の両事業部で、スクラム開発をおこなっているということで、両事業部みんなで集まって視聴会をしてみました。

会の概要

毎月開催している ROXX Dev Meetup という社内勉強会の1時間枠を使って、 RSGT のセッションの動画を、社内の開発メンバーみんなで試聴しながらわいわいする会を行いました。題材にしたのは、両事業部どちらも参考にできそうなものということで、あなたのSprint Goalは、機能してますか？とプロダクトバックログ Deep Diveを見ました。

超余談ですが、30分以上あるセッションを、1.5倍速でみることでなんとか1時間の枠で納めました。

視聴会の様子

Discord で動画を配信しながらチャットでわいわいしました。

視聴会をやってみた感想

セッションで出てきた、気になった箇所やわからない箇所をみんなで補足しあいながら視聴する体験がよかったです。また、みんなでひとつの題材を取り扱うと、セッションででてきたワードをその後、共通言語として使うことができるというのもよかったと感じました。

逆に残念だったこととしては、今回1時間の枠に絞ってしまったため、視聴後にディスカッションができなかったことです。視聴中に出てきたコメントをふりかえったり、そのまま OST をやったりできていたらより良かったと思います。

RSGT2022 のセッションの中で、チームで共有したいセッションはまだまだあるので、今後ちょこちょこ視聴会をやっていきたいと思います。

参考資料

youtu.be youtu.be

さいごに

さいごに少しだけ宣伝です。

現在 back check 開発チームは一緒にはたらく仲間を募集中です！！私たちと一緒に、 back check を通して「信頼が価値を持ち、信頼によって報われる社会の実装」に挑戦してみませんか？

herp.careers herp.careers herp.careers herp.careers herp.careers herp.careers herp.careers

2022-01-30

アジリティーを高めるために目的不確実性をコントロール下に置く

この記事は下記記事と同じです

note.com

最近PdM活動を行っている中で、アジャイル開発における対峙する不確実性の捉え方を変える事によって、生産性が大きく向上しそうな体験を感じることができたので、言語化してみる。

想定読者

リリースした後にCSから「これじゃ使えない」と言われる
振り返りの場で顧客価値について言及されない
リリースしたのに使ってくれているのかどうかわからない
本当に使ってくれるかわからない のに長期間開発してリリースしている
施策を計画的にリリースすることに重きを置いている

アジャイル開発は不確実性を受け入れる開発

改めて12の原則を照らし合わせてみると本質が書いてあるなぁと思う。 https://agilemanifesto.org/iso/ja/principles.html

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

とある通り、変化することを受け入れるというマインドセットそのものがアジャイル開発における重要なピースの一つになっている。

ではどういった変化を受け入れるべきなのか。「エンジニアリング組織論への招待」では3つの不確実性がソフトウェア開発に含まれているという

目的不確実性
- 何を作るのかという不確実性
方法不確実性
- どうやって作るのかという不確実性
通信不確実性
- コミュニケーション上発生する不確実性

本書においてはアジャイル開発では「目的不確実性と方法不確実性の両方に対して段階的にアプローチする」と書いてあるが、これをしっかり回すことは難しい。

f:id:kotamat:20220130154039p:plain

通常の開発では方法不確実性、通信不確実性に目が行きがち

なぜ不確実性を減らしていくことが難しいのか。それはそれぞれの不確実性が対象領域がかなり異なっているためだと思っている。

f:id:kotamat:20220130154105j:plain — 不確実性の対象領域

目的不確実性
- ビジネス的な成長と顧客理解の合わさったところ
方法不確実性
- スケジュールの予測、ベロシティーの安定化
通信不確実性
- チーム内における情報の非対称性

また、それぞれの不確実性の対処方法も異なる。

目的不確実性
- 顧客や対象者の課題検証、解決策検証。プロダクトのビジョンやゴール設定などのプロダクトマネジメントの実施
方法不確実性
- 多面的な見積もりやベロシティ計測による予測可能性の向上
通信不確実性
- KPTなどでの振り返りによる情報非対称性の解消や、心理的安全性の確保

開発チームという枠組みの中での改善を行おうとすると、影響を及ぼせるのは方法不確実性と通信不確実性のみとなってしまうので、振り返りの場で上がってくるイシューも、方法不確実性や通信不確実性の話題に終止してしまう。

目的不確実性はマーケット環境や顧客理解、ビジネスサイドの動き方といった事業部全体を包含しなければ不確実性の探索が難しいため、目的不確実性をコントロール下に置くことに対して難しさを感じたり、はなから無理だと決めつけて管轄外と捉えるようになってしまう。

対処方法も対象領域も異なりすぎるため、短絡的に考えれば開発チームに閉じる方法不確実性と通信不確実性のみを扱うのが気が楽である。ただ、目的不確実性もコントロール下に置ければ難易度は上がるものの、開発チームにとっても事業部ひいては顧客にとっても良いのではないかと思っている。

目的不確実性をコントロール下に置くとどうなるか

ざっと下記のメリットがあると思う。

どこまで作れば完成なのかがアウトカムベースでわかる。
まずは最低限何を作ればいいかがわかる
顧客への価値提供を身にしみて感じることができる
最も重要なことに取り組んでいる事がわかる。
BizとDev双方協力して顧客への価値提供していることを一体感を持って感じることができる

アジャイル開発においては、目的不確実性と方法不確実性を双方合わせて解消していくプロセスを踏んでいくことになるが、これを前提に開発することを念頭に入れることで、初手は完璧に作りすぎる必要がないことを理解出来、最もコアで不確実性の高いものを先に作る重要性を理解できる。そうすると、「これって無駄に作りすぎているんじゃないか」とか、「このまま長期で開発していくとダレてしまう」などの不要な懸念や不安を感じることなく、目的に向かって迷いなく進んでいくことができる。また、全てを完璧に作る必要がないため、思考のリソース的にも「考えを遅延させて重要なことだけを考えればいい」状態が継続されるため、常に重要なことに取り組んでいるという状態を作ることができる。

目的不確実性をコントロール下に置かない、計画駆動な開発スタイルでいったほうが確かに「モノが作れるスピード」は段違いで早くなるかもしれない。ただそれが顧客に価値を届けられたかどうかをベースに考えていないことで、「これってなんのために作ったんだろう」という、作った後に大きな手戻りが発生する危険をはらみ、中長期的にモチベーションが下がっていってしまう。

小さく答え合わせをしながら、手段と目的の不確実性を言ったり来たりして、少し遠回りしてでも最終的には遠くの地点にたどり着ける。そういった感覚を得られるのではないかと思っている。

目的不確実性の解消には技術が必要だがすべてをやらないといけないわけではない

ではどうやれば目的不確実性をコントロール下におけるのか。それはプログラミングスキルとは違った、技術が求められる。

ビジネス理解
プロダクトゴール、プロダクトビジョンの策定
仮設構築力
開発外の部署の理解
顧客理解
アセットとPLの次元の違い
- https://note.com/kotamat/n/n83af86c6fb11 を参照
etc..

これらはプロダクトマネジメントに求められるスキルであり、非常に多岐に渡る。これらを一朝一夕で身につけるのは非常に難しい。自分自身もまだこのスキルを身につけられたと自信を持って言える状態ではないし、果たしてそんな日が来るのだろうかという不安を覚えるくらい、非常に幅広く、深いスキルが要求される。

ただ、全てが完璧にならないとコントロール下に置けないかというとそうではないと思う。目的不確実性は0 or 100の世界ではなく、次第に少しずつ下げていくものであるため、そこに5でも10でも関与し下げられる事ができるのであれば、それだけでもとても価値のあることであるし、上記に述べたメリットを享受することができる。

まずは技術を習得する前に、できることからやっていくのがいいかなと思う。

目的不確実性を下げるために開発の観点からやれること

目的不確実性は下記の様に、ある特定のフェーズを通過するごとに下がっていく。 f:id:kotamat:20220130154141p:plain

このような活動に積極的に関与していくことだったり、もしここに上がっているフェーズをすっ飛ばしてものを作ろうとしている場合は、一旦立ち止まって「なんのために作ろうとしているのか」というのを考え、たとえ間違ってもいいので、後から検証できるような形に持っていくというのでもいいかもしれない。

また、「1秒でも早く価値を届けるためにどうすればいいか」というのを考え、やれることをやっていってもいいかもしれない。

特におすすめなのは 施策をリリースした後にCSと顧客に展開するのではなく、施策の出来上がりの解像度が少しでも上がったらすぐにFBを求めに行く というもの

まずは動くものを作るというアジャイルの原則を否が応でも実現する必要が出てくる
顧客へのヒアリングより圧倒的に速いスピードでFBを貰える。
CSが「これだとお客さんに使ってもらえない」という意見がリリース後に出てくることがなくなる。
CSに事前に展開しておくことで、リリース後に顧客に使ってもらえるような準備をリリース前に実施してもらえる
例えばCSが顧客と商談するときに、施策に対して顧客からFBをもらい、リリース前に調整ができるかもしれない。

というところで、少なくともリリース時には 「CSが顧客に使ってもらえる」状況まで目的不確実性を下げる ことができ、かつそのプロセス自体も対して難しいことを要求しているものでもないため、すぐに取りかかれる難易度でもある。

また スプリントゴールを設定後に事業部に展開する というのも良い。質は多少劣るもののいくつか同様の効果を得られる。

これ以外にもあるかもしれないが、まずは自分のできるところからやってみるとよい

まとめ

目的不確実性をコントロール下に置く重要性と、まずできることからやっていこうという話をさせてもらった。「もっとこうしたほうがいいんじゃないか」「こういう観点もありそう」みたいな意見があればコメントにいただけると嬉しいです。あと、プロダクトマネジメントや開発手法などに関して、一緒にお話していただける方も募集中です。 https://twitter.com/kotamats にDMいただければと思います。

2022-01-25

Github Actions でのプルリク作成時に特定のファイルの存在を知らせる

この記事は個人ブログと同じ内容です

www.ritolab.com

Github Actions を用いて定期的にプルリクエストを作成する際に、特定のファイルの存在を知らせたかったのでやってみます。

特定のファイルの存在を知らせる

知らせるのは「通知」という意味ではなくて、プルリクの説明欄にこれらのファイル名を記載して、いちいち確認しなくてもこれらのファイルが存在していることをわかるようにします。

定期に自動でプルリクを作成しているような状況なのでフィーチャーブランチのプルリクというよりはリリースのプルリクやローカルに向けたプルリクなどを想定しているとして、例えば PHP フレームワークの Laravel だと、マイグレーションファイルとかサンプルの環境変数ファイルの変更とかは、プルリクの中身を確認しなくても追加や変更の存在がわかるといいな。みたいな状況感です。（プルリクを取り込んだけど環境変数追加あったの見逃しててエラーになるみたいなのを防ぎたいモチベーション）

プルリクの説明欄への記載

hub コマンドでプルリクを作成する場合は、 -m オプションでプルリクのタイトルと説明を指定できます。

最初の 1 行目がプルリクのタイトルになり、空行を挟むとそれ以降が説明欄の文章になります。

MESSAGE="ここがプルリクのタイトルになる

## これ以降が説明欄の文章になる
* テスト
* test

markdown で書ける。
"

hub pull-request -m "$MESSAGE" -b main -h dev

上記コマンドで作成されたプルリクは以下のようになります。

f:id:ro9rito:20220125182046p:plain

特定のファイルを抽出する

差分から検索して抽出しようと思います。

MESSAGE="プルリクのタイトルです。\n\n"

# 変更ファイルを取得
DIFF=`git diff main dev --name-only`

# 探したいファイルのパスや名前で該当の行を抽出
ENV_FILES=`echo "$DIFF" | sed -n '/\.env\./p'`
MIGRATION_FILES=`echo $DIFF | sed -n '/database\/migrations\//p'`

# 説明欄のコメントを追加
if [ -n "$ENV_FILES" ]; then
  MESSAGE+="環境変数ファイルの変更が含まれます。\n$ENV_FILES\n\n"
fi
if [ -n "$MIGRATION_FILES"  ]; then
  MESSAGE+="マイグレーションファイルが含まれます。\n$MIGRATION_FILES\n\n"
fi

echo -e "$MESSAGE"

git diff で差分を持ってきます。

ここでは main ブランチと dev ブランチの差分を、--name-only オプションでファイル名のみを取得しています。（変更があった、新規に追加されたファイルの一覧が入ってくる。）

入ってきたファイルリスト（$DIFF）に対して sed -n で指定の文字列を含む行のみを抽出します。

あとはコメントを組み立てて出力です。

上記を実行するとこんな感じで出力されます。

プルリクのタイトルです。

環境変数ファイルの変更が含まれます。
.env.example

マイグレーションファイルが含まれます。
database/migrations/2022_01_22_000000_create_users_table.php
database/migrations/2022_01_22_000000_create_books_table.php

hub コマンドでプルリクを作成するとこんな感じです。

f:id:ro9rito:20220125182150p:plain

Github Actions で作成

上記を踏まえてこれらを Github Actions 側に実装します。

.github/workflows/xxxx.yml（メッセージ・プルリク作成部分のみ抜粋）

# ブランチ名作成
- name: Make branch name
  id  : setting
  env:
    TZ: 'Asia/Tokyo'
  run : |
    DATE=`date +"%Y%m%d_%H%M%S"`
    BRANCH_NAME="release/$DATE"
    echo ::set-output name=branch_name::$BRANCH_NAME

# プルリクのメッセージ作成
- name: Make pull request message
  id: message_making
  env:
    BRANCH_NAME: ${{ steps.setting.outputs.branch_name }}
  run: |
    MESSAGE="$BRANCH_NAME\n\n"
    
    DIFF=`git diff main dev --name-only`
    ENV_FILES=`echo "$DIFF" | sed -n '/\.env\./p'`
    MIGRATION_FILES=`echo "$DIFF" | sed -n '/database\/migrations\//p'`
    if [ -n "$ENV_FILES" ]; then
      MESSAGE+="環境変数ファイルの変更が含まれます。\n$ENV_FILES\n\n"
    fi
    if [ -n "$MIGRATION_FILES"  ]; then
      MESSAGE+="マイグレーションファイルが含まれます。\n$MIGRATION_FILES\n\n"
    fi
    echo ::set-output name=message::$MESSAGE

# ブランチ作成
- name: Create Branch
  uses: peterjgrainger/action-create-branch@v2.1.0
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    branch: ${{ steps.setting.outputs.branch_name }}

# プルリクエスト作成
- name: Create Pull Request
  id: create_pull_request
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    BRANCH_NAME: ${{ steps.setting.outputs.branch_name }}
    MESSAGE: ${{ steps.message_making.outputs.message }}
  run: |
    PULL_REQUEST_MESSAGE=`echo -e "$MESSAGE"`
    hub pull-request -m "$PULL_REQUEST_MESSAGE" -b main -h $BRANCH_NAME

1 点だけポイントで、組み立てたメッセージはエスケープ文字を使用している（改行部分）ため、hub pull-request で指定する前に echo -e で出力してエスケープ文字を有効にしておきます。

# エスケープ文字を有効にする
PULL_REQUEST_MESSAGE=`echo -e "$MESSAGE"`

Github Actions を回して実行してみます。

f:id:ro9rito:20220125182338p:plain

抽出されたファイルのリストが説明欄に書き込まれてプルリクが作成されました。

まとめ

定期のプルリクエスト作成に限らず、手動でのプルリク作成時にもこういったファイルを検出してコメントするみたいな事に応用できそうだなと思いました。

任意のファイル抽出やコメントへの書き込み（プルリク作成も含め）は、探せば GitHub Marketplace にワークフローが公開されているかもしれないので探してみるのも良いかもしれません。

2022-01-08

Regional SCRUM GATHRING Tokyo 2022 速報(3日目)

こんにちは！ ROXX で back check の開発エンジニア兼、スクラムマスターをやっている、ぐっきーこと山口 (@Area029S)です。Regional SCRUM GATHRING Tokyo 2022 3日目のレポートをさせていただきます！

OST(Open Space Technology)

discord とオンサイトそれぞれの会場を交えて、ハイブリットな OST を実施しました。私はオンラインでの OST に慣れていた分、オンサイトではお目当てのテーブル探しに一苦労しましたが、楽しく参加してきましたので一部始終をお届けします。

来週からはじめること、やめること

A 枠 ost-table-1

いきいきいくおさんの「みなさん、いきいきしてますか？せーの、いきいき〜！！」の掛け声にのせて、来週からはじめること、やめることを発表しあう時間になりました。個人的に好きだったのは「ふりかえりをうまくやろうとすることをやめる！」でした。会場で一番いきいきしたテーブルだったと思います。

フルリモート環境でのいい感じなオンボーディング気になっている

B 枠 ost-table-11

オンボーディング、チームビルディングのために、四半期に一回のペースで相互理解のためのワークショップをやっているというお話が印象的でした。バリューズカードゲーム、ドラッカー風エクササイズ、ストレングスファインダーなどを活用しているというお話を聞けました。

ネガティブワードを妥当な表現に変えたい!!!

C 枠 ost-table-1

チームの雰囲気が悪くなるネガティブワードを妥当な表現に変えたい！！！ということで日頃のネガティブワードあるあるをどう改善できるか考えました。気遣いの行き届いた素敵な表現がたくさんでたので、私も積極的に使っていきたいと思います。

~べき → ~の方が好き
結局なにがしたいの → そういえば、この議論の目的ってなんでしたっけ？
それじゃない。◯◯だろ。→ それだったらこれは？
それでいいです → それがいいです
もうちょっとできるでしょ → 満足してる？
とくにないです → 完璧やん！
xxとか、zzとかっていう逃げ方はありますけど… → xxとかzzとかの選択肢を取れますね！

Closing Session

アメリカの超巨大クラウドの「中の人」に転生したガチ三流プログラマが米国システム開発の現実をリークする話 from Tsuyoshi Ushio

Closing Session は @Tsuyoshi Ushio さんによる、アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークするというセッションでした。

Ushio さんは現在アメリカの Microsoft でシニアエンジニアとして働いています。ただ、特別エンジニアとして優秀なわけではありません。偶然、経歴が求められていたものとフィットしただけであり、どうやったら Microsoft で働くエンジニアになれるの？という問いに対しての Tips は、「面接を受けましょう」ということでした。

また、日本とアメリカ（特に Microsoft ）との組織の違いとして、アメリカではウォーターフォールのメリットは0だから、100%の現場でアジャイルを導入している。また、チームのメンバーがインディビジュアルコントリビューター（IC: 個人事業者的な意味合いで使われている）として、管理されるわけではなく自分たちで行動やキャリアを選択していくいう点を挙げられていました。

おわりに

3日間行った RSGT2022 もついに終わってしまいました。 discord のみなさん、オンサイトのみなさん、3日間楽しくギャザリングできましたでしょうか？私ぐっきー個人の振り返りとしては、新たな学びを得たとともに、多くの方と交流できたので有意義なギャザリングができたと感じております。

また、 RSGT2022 の1日目、2日目の速報もあわせてお読みください。

最後に少しだけ、弊社 ROXX の宣伝をさせてください！今回の RSGT ですが、私は業務として参加しています。 RSGT は参加費がお高めなカンファレンスですが、これらは会社負担で参加できます。弊社 ROXX では、エンジニアが技術力をつけるための勉強会については本人が業務に活かせると判断するのであれば、基本的に業務扱いにしてくれます。

もし、弊社にご興味を持っていただけましたら、弊社 ROXX 採用サイトよりお気軽にカジュアル面談のお申し込みください！

最後まで読んでいただき、ありがとうございました！

2022-01-07

Regional SCRUM GATHRING Tokyo 2022 速報(2日目)

こんにちは！ ROXX で back check の開発エンジニア兼、スクラムマスターをやっている、ぐっきーこと山口 (@Area029S)です。Regional SCRUM GATHRING Tokyo 2022 2日目のレポートをさせていただきます！

Keynote

2日目の Keynote は Diana Larsen さんです。 The Agile Fluency Model を用いて、どのようにチームをリードし、彼らの能力を発揮させるために投資をするかについてお話されました。

Fluency （流暢さ）なアジャイルチームになるには Focusing, Delivering, Optimizing, Strengthening の4つの習熟度のゾーンがあります。また、ゾーン毎にそれぞれ以下の指標を計測します。 - Focusing: チームの取り組みに対する、ビジネス価値の観点からの進捗を可視化できている - Delivering: 望まれたタイミングで、いつでも高い品質の機能をデリバリーできる - Optimizing: 自分たちの製品が市場でどのような位置にあり、どのようにその位置を向上（または確保）させるかを説明できる

チームの習熟度はどのゾーンにいるのかを考え、今すぐ行動しましょう。そして、効率ではなく、投資に対する効果を求めましょう。効果にもっとも価値があります。といった内容でした。

Fluency なアジャイルチームとして、より価値を届けられるチームを目指しましょう！

プロダクトバックログ Deep Dive

午後一発目は Ryutaro YOSHIBA (Ryuzee) さんのセッションを聞きました。

プロダクトバックログとはなにか。プロダクトバックログの管理、分割などを通して、プロダクトバックログをきっかけにスクラム全体の思想を感じられた、学びの深いセッションでした。印象的だった言葉は「生煮えプロダクトバックログアイテムを食べると腹を下す」という言葉で、「これを避けるために、火が通って調理済みのプロダクトバックログアイテムを食べていくことが大原則です。検査と適用で自分たちにあった調理済みの状態を探していきましょう。」とワンセットにして、準備完了の状態の大切さを伝える際にぜひ活用させていただきたいと感じました。

QAなんなん？～みんなが納得できるQAのスタイルを見つけよう～

続いて、Kaori Tokiwa さん、 Naoki Kojima さん、 Yasuharu Nishi さん、やすよおおのさんの合同セッションです。

開発と QA が同じ方向に進む組織になるためのハッピーな QA のスタイルづくりについて、独自に考案した QA スタイルファインダーを使って考える。というお話でした。

QA スタイルファインダーの点数づけは左右の軸との相対値であって、チームの中でどこを大事にするか共通認識で持つことが大切です。自分たちで QA スタイルファインダーの採点をする中で、チーム自身で気づきを得られることが QA スタイルファインダーの強みということでした。オーディエンスからは、 QA だけでなく、アジャイルチームにも活用できそうとの声もありました。私個人的にも、可視化しづらいチームの状態というものをチーム全員が共通で認識できる。という意味でとても有効なツールだと感じました。

LeSS もスクラム。プロダクトオーナーがスクラムマスターとともに取り組んだ LeSS チームの合体から融合まで

2日目最後に聴いたセッションは、Yahoo Japan から Saiko Nakai さんです。 Saiko Nakai さんの体験から、スクラム less な LeSS チームと、ゆるふわスクラムチームがいかにして融合できたのかということについてのお話しでした。

融合の過程で学んだこととして、 - プロダクトオーナーはチーム全体に対してプロダクトが目指したい状態を明らかにする - スクラムマスターは、そのためにチームがどうあるべきかを明らかにする

これらを実践するためにも、プロダクトオーナーとスクラムマスターはたくさんおはなしをするべし。

また、スクラムで大事にしていたことは LeSS でも大事にしましょう。規模は大きいけれど、やっていることはスクラムと一緒なので怖がる必要はありません。基本はスクラムガイドに立ち返ろう。 LeSS もスクラムですよ。とのことでした。

プロダクトオーナーである Saiko Nakai さんの言葉で、スクラムチームとして大事にしたい価値観を言語化して、日々チームに伝えているというお話が印象的でした。個人的には、プレゼンの内容から伺えた Saiko Nakai さんの現場推進力に終始圧巻されていました。

おわりに

さて、 RSGT も折り返しを越えまして、明日が 3 日目、最終日となりました！楽しみな気持ち、寂しい気持ちが半分ずつありつつ、明日は最後までたくさん楽しんできたいと思います！

また、私ぐっきーも FIRST TIMER のリボンをつけて会場にいるので、この記事を読んだ方はお声がけしてくれると嬉しいです！

もし、弊社にご興味を持っていただけましたら、弊社 ROXX 採用サイトよりお気軽にカジュアル面談のお申し込みください！

それではまた、明日 RSGT 3日目でお会いしましょう！

2022-01-06

Regional SCRUM GATHRING Tokyo 2022 速報(1日目)

こんにちは！ ROXX で back check の開発エンジニア兼、スクラムマスターをやっている山口 (@Area029S)です。Regional SCRUM GATHRING Tokyo 2022 1日目のレポートをさせていただきます！

Keynote

RSGT 初日の一日目の Keynote は、Manage It！　現場開発者のための達人式プロジェクトマネジメントの著者の Johanna Rothman さんから「Agile Program Management: Scaling Collaboration Across the Organization」です。

発表では Johanna さんが自身の経験（1980年台のコンピュータープロダクト開発）を題材にアジャイルなプログラムマネジメントについてお話しされました。コラボレーションをスケールすることが大事であり、チームが自立して行動したり、 Small World Networks を作成することでこれが実現できるとのことでした。

計画については、ロードマップは4半期単位でも予定通りに進んだ試しがないのでつくらず、4週間分を1週間ずつにわけて計画を立てていき、1週間経過したらみえてきた課題に対しての改善をするために次の5週目の計画を立てる方法で計画しました。

また、進捗の見方としてベロシティの測定ではなくサイクルタイムで計測を行いました。これは顧客の求めているのは開発速度ではないこと。プロダクトが完成品にどれだけ近づいているかを確認するためです。また、顧客はフィーチャーを求めているので、バーンアップチャートを用いて確認することができます。

最後に、プロダクトがなんのためにあるのか、我々がどこに向かうのか、そのために我々は何をするのかの順で徹底的にプロダクトへフォーカスすると、メンバーが自律性を高めるための道筋が作れるとのことでした。

1980年代のアジャイル開発を実際に携わっていた人から聞くのは、スクラムのルーツを知れたような気がしてとても感動しました。

「いい感じのチーム」になるためにやること

@yohhatuさんからは"いい感じ"のチームになるにはどのような活動を行い、どのような関心を持てばいいのでしょうか？というお話しでした。リーダーシップ、感情、実験の3つのテーマについて話しました。

リーダーシップ

みんなでリードしましょう。リーダーだけでなく、フォロワーシップも大切です。また、チームとしてのバランスも大切です。チームビルディングはスパイラルを登っていくことを意識しながら、継続的にやりましょう。

感情

感情を大切にすることで余白的な部分からでてくる気づきがあります。お互いのことを知り、理解することを心がけましょう。感情を大切にしてもらうためには、自分の弱みからオープンにしていくことがおすすめです。

実験

日常的に実験し続けましょう。 Tips として常になにかを変え続けていくことで変化に強くなります。また、継続的に行う中で、予想や仮説を持った上で一つ一つに対して本気で実験しましょう。

当たり前のことを当たり前に継続することが、いい感じのチームに近づけるヒントですとのことでした。

個人的には、普段の実験が習慣として定着していないことから、@yohhatuさんの「日常的に実験しましょう」という言葉が胸に刺さりました。

フリカエリ星人との邂逅　～ふりかえりのお道具箱＆お悩み相談～

@higuyumeさん / @viva_tweet_xさん

ここでは OST(Open Space Technology) 形式でお悩み+日頃のスクラムに対する Tips について、フーリーとカエリーの2人？が回答したり掘り下げたりしました。

最後にはこのセッションの振り返りも。とてもたくさんの振り返りがでました。

他のセッションは聴く側に回ることが多い中で、このセッションでは自分も一員になることができてとても楽しかったです。個人的には、頑張ってファしらない。 work together の一言でどこかほっとした気持ちになりました。

プロダクトゴールとは？あるいはプロダクトのゴールを設定するには何が必要か？

続いては、@tnagasawaさんによるセッションです。セッション中に@tnagasawaさんがお話しされたプロダクトゴールの特性 FAST（Frequent discussions, Ambitiously, Specific metrics, Transparent）を元に設計されたプロダクトゴールのフォーマットは、ぜひ活用させていただきたいと思います。

また、プロダクトゴールには常に指標を計測して　検査・適用することが重要であり、プロダクトゴールと価値指標の検査は、経験主義に基づいたマネジメントフレームワーク - エビデンスベースドマネジメント（EBM）が参考になるとのことでした。 20分間のセッションではとても足りないほど学びの深い内容でした。

参考：EBM ガイド https://scrumorg-website-prod.s3.amazonaws.com/drupal/2021-02/2020-EBM-Guide-Japanese.pdf?nexus-file=https%3A%2F%2Fscrumorg-website-prod.s3.amazonaws.com%2Fdrupal%2F2021-02%2F2020-EBM-Guide-Japanese.pdf

あなたのSprint Goalは、機能してますか？

次に@KazuhideInanoさんによるセッションです。スクラムガイドでのスプリントゴールと完成の定義の扱いは、今までは成果に付随するものでしたが、2020年からスプリントゴールを導入し、位置付けが明確になりました。よく聞く話でスプリントゴールは決めづらい。決めなくてもなんとかなる。との意見がありますが、実際は年々重要視されるようになってきているのです。

例えばスプリントゴールの効果として、チームの活動に軸を据える。ステークホルダーとのコミュニケーションの質を上げる。活動の透明性をあげ、検査し、適用を促す。などがあります。具体的な例として、スプリントレビューの前に、スプリントゴールをステークホルダーに共有することで、スプリントレビュー時にはステークホルダーの理解度が深くなっており、より検査、適応にフォーカスしたコミュニケーションをとることができるようになります。

また、気をつけたい兆候としてスプリントゴールが単に行動の達成目標になってしまったり、ムーンショットすぎてどれも達成できなかったりなどが現れた場合は、振り返りをして改善できることはないか検討してみましょう。という内容でした。

私が所属するチームでも、スプリントゴールの扱いについては課題感がある中で、改めてスプリントゴールの重要性を確認できる内容のセッションでした。

おわりに

まだまだ RSGT は初日が終わったばかり！ 2,3 日目のセッションも楽しみですね！私もわくわくしながら明日を待ちたいと思います！

もし、弊社にご興味を持っていただけましたら、弊社 ROXX 採用サイトよりお気軽にカジュアル面談のお申し込みください！

それではまた、明日 RSGT 2日目でお会いしましょう！

2021-12-30

ウェブアクセシビリティ再入門 − 2021年版

この記事は個人Qiita と同じ内容です

qiita.com/sekiyaeiji

ウェブアクセシビリティ再入門

ウェブアクセシビリティ再入門 202112 記事バージョン

※ 本稿は過去の登壇用のスライドの箇条書きのテキストを文章に起こし直し、更新されているデータを最新のものに置き換え、いくつかコメントを加筆して再編しました。

アクセシビリティ

"アクセシビリティ" とは、「accessibility」と書きヌメロニム表記でしばしば「a11y」と記載されます。

単語の意味としては以下の通り「アクセス可能性、アクセスのしやすさ」となります。

入手［利用］可能性、可触性、近接性、手の届きやすさ
近づきやすさ、アクセス可能性
アクセス可能性、アクセスのしやすさ

accessibilityとは − 英辞郎 on the WEB

Web アクセシビリティとは

"ウェブアクセシビリティ" とは、現在市場において以下のように理解されているようです。

高齢者、障害者を含むあらゆるユーザーを意識したユニバーサルで高品質なウェブUXとその提供

また、Web の創始者、ティム・バーナーズ・リーがWeb アクセシビリティについて2009年に触れた一節があるそうです。

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
Web のパワーは、その普遍性にある。障害の有無に関係なく、誰もが使えることが、その本質である。

加えて、W3C は accessibility についての見解を現在このように記しています。

Accessibility is essential for developers and organizations that want to create high quality websites and web tools, and not exclude people from using their products and services.
サービスを高品質に提供したり、プロダクトを利用してくれるあらゆるユーザーを排除したくない開発者にとって、アクセシビリティは不可欠なものである。

引用： Accessibility - W3C

障害の種別

障害には以下のようなカテゴリーがあるのと、それぞれ定義がなされています。

身体障害
知的障害
精神障害
難病

障害種別ごとの定義

「障害者」の定義って？障害者手帳や障害年金などのサービス、障害者雇用の対象、支援の根拠となる障害者総合支援法について説明します。 − LITALICO仕事ナビ

障害者のネット利用状況

障害を持つ方々は、インターネットにどのように接し、どのくらいの割合が利用し、どのような課題感を持っているのでしょうか。

障害者総数

ネット利用率

障害者によるインターネットの利用率：NICT
2014年のデータ
障害者全体
- 53.0％
増加傾向、アップトレンド

日本人全体のネット利用率

ちなみに国民全体のネット利用率はどの程度でしょうか。

2010年代は80％あたりでほぼ横ばいの推移をしていましたが、時世の影響でしょうか、2019年に突然約10％上昇しました。

ネット利用障害者数

510万人
- 人口比 4.0％
- 障害者比 53.0％が利用
- 増加傾向

ネット利用目的

趣味、娯楽
調べる
情報発信
勉強、仕事
交流、コミュニケーション
障害ハンディキャップの補完
- 文字情報、テロップの充実
- 文字メディアの音声化
- 意思伝達の文字化・音声化ツール
- 肢体不自由の補完

インターネット利用に際して困ること

コンピューターウイルスや不正アクセス
障害に配慮したホームページの少なさ
障害を補う機器、ソフトが少ない
障害者向きの情報不足
画面がごちゃごちゃして見にくい
欲しい情報を見つけるのが困難
通信費用が高い
わからないときに相談する人がいない
利用者同士のトラブルが怖い

以上の情報をまとめると、Web プロダクトがこれら感情をユーザーに感じさせる状態がつまり、「Web アクセシビリティが悪い」状態ということになります。

極端に質の低いサイトやサービスでは、健常者も感じたことがある内容ではないでしょうか。

共感できる項目も多そうです。

・・・

さて、ここまで現状とユーザー課題についてまとめました。この現状を理解した上で、Web アクセシビリティにおいて実際に発生している課題は何か、について掘り下げて行きましょう。

モダンウェブアクセシビリティ

英国内務省が提唱し取りまとめる「Dos and don'ts」という accessibility に関する記事は、Web アクセシビリティ観点において、してほしいこと、してほしくないことについて詳細をよくまとめられています。

「Dos and don'ts on designing for accessibility」

@onouchidebe

・英国内務省 (UK Home Office) Accessibility
・ Dos and don'ts on designing for accessibility
・ Dos and don'ts on designing for accessibility（pdf）
・英国内務省 (UK Home Office) によるウェブアクセシビリティの「べき/べからず」ポスター
・ウェブアクセシビリティの「べき/べからず」ポスター (UK Home Office) 日本語版

対象分類

Web アクセシビリティにおいて以下のカテゴライズごとに対策をまとめてくれています。

自閉症スペクトラム、ディスレクシア、不安状態というカテゴリーに言及できているところがこれまであまりなかったポイントであり有用です。

自閉症スペクトラム
- コミュニケーションや言語に関する困難
スクリーンリーダー
- 視覚障害
- 見えない、見えにくい
ロービジョン
- 視覚障害
- 矯正できない視機能の弱さ
- 低視力、見えにくい
ディスレクシア
- 文字の読み書きに限定した困難
- 発達性読み書き障害
身体障害・運動障害
聴覚障害・難聴
不安状態
- 不安障害
- 不安神経症、強迫性障害

詳細

詳細はそれぞれ以下のとおりです。ひじょうに役立てやすい情報にまとまっています。

自閉症スペクトラム

すること	しないこと
単純な色を使う	鮮やかでまぶしい色を使う
優しい言葉で書く	比喩表現や慣用句を使う
簡単な文章と箇条書きを使う	区切りのない長文で文字の壁をつくる
説明的なボタンにする	曖昧で予測不能なボタンにする
簡潔で一貫したレイアウトを構築する	複雑でごちゃごちゃしたレイアウトを構築する

スクリーンリーダー

すること	しないこと
画面の説明、動画の書き起こしを提供する	画像や動画だけで情報を表示する
順序立てた論理的なレイアウトにする	ページ全体にコンテンツをバラバラに配置する
HTML5を使ってコンテンツを構造化する	文字サイズや配置に頼って構造化する
キーボードだけで使えるように構築する	マウスや画面の使用を強制する
リンクや見出しは説明的に書く	リンクや見出しを役立たずにする

ロービジョン

すること	しないこと
良いコントラストと読みやすい文字サイズを使う	低いコントラストと小さい文字サイズを使う
すべての情報をウェブページ（HTML）で公開する	ダウンロードの中に情報を埋没させる
色、形、文字の組み合わせで意味を伝える	色だけで意味を伝える
順序立てた論理的なレイアウトにする（拡大表示したとき文章は折り返して表示される）	ページ全体にコンテンツを広げる（拡大表示したとき横スクロールが必要(※)）
ボタンと通知は文脈にそって配置する	文脈と分離した操作をさせる

ディスレクシア

すること	しないこと
理解を助けるために画像や図を使う	長い文章で大きな文字のブロックをつくる
文字揃えは左揃えで一貫したレイアウトを保つ	下線を引く、斜体を使う、大文字で書く
他のフォーマットでの情報提供を検討する（例：音声や動画）	前のページを覚えておく必要がある（リマインドやヒントを出しましょう）
コンテンツを短く、明確に、簡潔にする	正確なことばで入力する必要がある（予測入力や自動補正の機能を使いましょう）
背景と文字のコントラストを利用者が変更できる(※)	ひとつの場所に情報をつめこむ

身体障害・運動障害

すること	しないこと
クリック可能な範囲を大きくする	精密さを要求する
操作対象のあいだを空ける	操作対象を近づけすぎる
キーボードや音声だけで使えるように設計する	マウスをたくさん動かす必要がある
携帯電話やタッチスクリーンを想定して設計する(※)	短い時間制限をもうける
ショートカットを提供する	タイピングやスクロールで利用者を疲れさせる

聴覚障害・難聴

すること	しないこと
やさしい言葉で書く	難しい言葉や比喩表現を使う
字幕を使うか。動画の書き起こし文を提供する	音声や動画のみで情報提供する
順序立てた論理的なレイアウトにする	複雑なレイアウトやメニューをつくる
小見出し、画像、動画でコンテンツを分割する	長いかたまりのコンテンツを読ませる
予約や手続きの際に利用者が希望するコミュニケーション支援を利用できる	電話を唯一の連絡手段にする

不安状態

すること	しないこと
操作を終えるのに十分な時間がある	ユーザーを急がせたり、必要のない時間制限を設ける
これから何が起こるかを説明する	次にすることや時間制限で利用者を混乱させる
重要な情報は明確に	操作の結果がはっきりわからない
操作を完了するために必要なサポートを提供する	サポートやヘルプにアクセスしづらい
ユーザーが送信前に入力内容を確認できる	質問に回答したユーザーを放置しない

詳細補足

以上詳細について少し補足します。

拡大表示したとき横スクロールが必要

レスポンシブレイアウトで解決できます

背景と文字のコントラストを利用者が変更できる

現在では多くのOSにおいて設定が対応できています
- OSの設定、操作を妨げない対応が重要です

携帯電話やタッチスクリーンを想定して設計する

レスポンシブレイアウトが重要です

実際に利用している様子がわかる動画から学ぶ

開発者が Web アクセシビリティに取り組む際に、以下の動画は必ず確認しておく必要があります。

説明テキストで知ったつもりになるだけではなく、ユーザーストーリーを見て実感した上で開発、デザインに取り組むことが肝要です。

障害者のウェブページ利用方法の紹介ビデオ

視覚障害者（全盲）のウェブページ利用方法（YouTube再生）

この動画でわかることは以下のとおりです。

スクリーンリーダーを利用
点字ディスプレイも併用
FireFoxを利用
適切なマークアップ、見出し構造（h要素）が重要
画像の代替テキスト（alt属性）が必要
- alt属性が存在しないとファイル名や「画像」が読み上げられる
表組み（table要素）の適切なマークアップが重要
画像認証の代替手段を用意する
各ページを識別できるタイトル要素をつける
入力系にラベル要素やタイトルを付与する
スマホ、タブレットへのa11y配慮
JISX8341-3 （JIS X 8341-3:2016 達成基準早見表（レベルA & AA））を意識する
- JIS X 8341-3: 2016の適合レベルA、AA、AAA 全リスト
  - 難易度は A ＜ AA ＜ AAA
- 満たせない場合は、情報への代替アクセス手段を提供する

まとめ

まずは JIS X 8341-3:2016 達成基準早見表（レベルA & AA） の適合レベル A から実装してみたいと実感することができました。

視覚障害者（弱視）のウェブページ利用方法（YouTube再生）

この動画でわかることは以下のとおりです。

弱視
先天的、右：0.02（矯正）、左：光を感じる
グラフィック利用
Win拡大鏡による画面拡大
支援技術なしでテキストを200％までサイズ変更できるようにする
白背景がまぶしいため明暗反転する
- JIS達成基準のコントラスト比は 4.5:1 以上
自動再生されるカルーセル等画像スライドは一時停止機能が必要
スマホ、タブレットも反転表示利用

まとめ

OSやブラウザの設定、操作を妨げない対応、確認が重要だと実感として知ることができます。

肢体不自由者のウェブページ利用方法（WMVダウンロード）

この動画でわかることは以下のとおりです。

手指に力がなく書籍のページをめくるのも困難
- 活字メディアが利用できない
トラックボールを腕全体の動きで操作
オンスクリーンキーボードを利用
IE利用
文字が小さく読みづらい
横スクロールは発生してほしくない
情報発信に挑戦中

まとめ

むしろデジタル機器やウェブコンテンツは より必要とされている と実感できます。

今日からできること

ここまで、アクセシビリティをとりまく具体的な課題を知ることができました。

ではまず、われわれが実際に行動を起こす際に、まず何から着手ができそうでしょうか。

・・・

最初に対応できることとしてたとえば、Google DevTool の Lighthouse で計測できる Accessibility のスコアアップから目指してみるのはいかがでしょう。

何も行動しないよりは、すぐできることからまず始めてみましょう。

Lighthouse 頻出メッセージと対策例

Lighthouse で Accessibility 対策に取り組むとよく出てくる結果メッセージついて、以下に対策例をまとめてみました。

Background and foreground colors do not have a sufficient contrast ratio

背景色と前景色は十分なコントラスト比を持っていません。

対策例

UIデザイナーと相談して色設定の変更を検討しましょう
Color Contrast Analyzer
- レベルAA、レベルAAA への対応色（コントラスト値）を導き出せる

Heading elements are not in a sequentially-descending order

見出し要素は順番に降順ではありません

対策例

見出しの階層構造を適正化しましょう

before

after

Image elements do not have [alt] attributes

img要素には alt属性がありません

対策例

推奨

alt属性値に写真画像の内容を表現するテキストを設定しましょう
alt属性値にテキスト入り画像のテキストを設定しましょう
- 文字情報はテキスト文字列でマークアップしましょう

ミニマム対応

空値のalt属性を設定しましょう
- 読み上げ対象から外すことができます

Form elements do not have associated labels

フォーム要素にラベル要素が関連付けられていません

対策例

入力系に label要素を設定するか、title属性を設置しましょう

before

    <input type="checkbox"> メールニュースを希望する

    <select> 〜 </select>

after

    <input type="checkbox" for="form-mailnews">
    <label id="form-mailnews"> メールニュースを希望する</label>

    <select title="都道府県"> 〜 </select>

Links do not have a discernible name

リンクには識別可能な名前がありません

対策例

a要素内にアンカーテキストを付与するか、alt属性、title属性、aria-label属性などのいずれかにテキストを設定しましょう

before

    <a href="hoge"></a>

after

    <a href="hoge">記事ページへ</a>

    <a href="hoge"><img alt="記事ページへ"></a>

    <a href="hoge"><span title="記事ページへ"></span></a>

    <a href="hoge" aria-label="記事ページへ"></a>

frame or iframe elements do not have a title

frame要素または iframe要素にタイトルがありません

対策例

frame要素、iframe要素に title属性を設定しましょう

before

    <iframe>></iframe>

after

    <iframe title="YouTube動画"></iframe>

ARIA IDs are not unique

ARIAIDは一意ではありません

対策例

id属性値を1ドキュメント内で重複させないようにしましょう

さらに深堀りする

Google DevTool の Lighthouse の対応が一通りパスできたら、つぎにやるべきことは以下のとおりです。

レベルAA、レベルAAA 実装を目指す

【参考】JIS X 8341-3: 2016の適合レベルA、AA、AAA 全リスト

WAI-ARIA を利用する

role属性
aria属性

【参考】WAI-ARIAを活用したフロントエンド実装 | CodeGrid

まとめ − "ウェブアクセシビリティ再入門 202112 記事バージョン" について総括

以上、重要なポイントを再確認しましょう

ウェブアクセシビリティとは、ユニバーサルで高品質なウェブUX のことです
国内ユーザー数は現在 約510万人 で、さらに増え続けています
ウェブは障害のある方々に必要とされています
容易なことから着手しましょう
BE、FE、Des が協力して調査、改修しましょう

最後に

最後に、世界で最も有名な障害者と称された指導者、著作家の ヘレン・ケラー（Helen Adams Keller − 1880年 - 1968年）のフレーズに触れて本稿を締めさせていただきます。

So long as you can sweeten another’s pain, life is not in vain.
人の苦しみをやわらげてあげられる限り、生きている意味はある

今回取り上げたウェブアクセシビリティの件に限らず企業活動とは、ヒトの幸福と悩みの解決に根ざしてこそ継続でき得る活動である、と私は理解しています。

その延長線上に Webアクセシビリティが存在し、国内だけでも 500万以上のユーザーがコンテンツの提供を望んでいるということを定期的に再認識し、プロダクト提供における自身の視野を広い状態に保っておくことは重要そうです。

RSGT の視聴会やったよ

会の概要

視聴会の様子

視聴会をやってみた感想

参考資料

さいごに

想定読者

アジャイル開発は不確実性を受け入れる開発

通常の開発では方法不確実性、通信不確実性に目が行きがち

目的不確実性をコントロール下に置くとどうなるか

目的不確実性の解消には技術が必要だがすべてをやらないといけないわけではない

目的不確実性を下げるために開発の観点からやれること

まとめ

特定のファイルの存在を知らせる

プルリクの説明欄への記載

特定のファイルを抽出する

Github Actions で作成

まとめ

OST(Open Space Technology)

来週からはじめること、やめること

フルリモート環境でのいい感じなオンボーディング気になっている

ネガティブワードを妥当な表現に変えたい!!!

Closing Session

おわりに

プロダクトバックログ Deep Dive

QAなんなん？～みんなが納得できるQAのスタイルを見つけよう～

LeSS もスクラム。プロダクトオーナーがスクラムマスターとともに取り組んだ LeSS チームの合体から融合まで

おわりに

「いい感じのチーム」になるためにやること

リーダーシップ

感情

実験

フリカエリ星人との邂逅 ～ふりかえりのお道具箱＆お悩み相談～

プロダクトゴールとは？あるいはプロダクトのゴールを設定するには何が必要か？

あなたのSprint Goalは、機能してますか？

おわりに

ウェブアクセシビリティ 再入門

Web アクセシビリティとは

障害の種別

障害種別ごとの定義

障害者のネット利用状況

障害者総数

ネット利用率

日本人全体のネット利用率

ネット利用障害者数

ネット利用目的

インターネット利用に際して困ること

モダンウェブアクセシビリティ

「Dos and don'ts on designing for accessibility」

対象分類

詳細

スクリーンリーダー

ロービジョン

身体障害・運動障害

聴覚障害・難聴

不安状態

詳細補足

拡大表示したとき横スクロールが必要

背景と文字のコントラストを利用者が変更できる

携帯電話やタッチスクリーンを想定して設計する

実際に利用している様子がわかる動画から学ぶ

まとめ

まとめ

まとめ

今日からできること

Lighthouse 頻出メッセージと対策例

Background and foreground colors do not have a sufficient contrast ratio

対策例

Heading elements are not in a sequentially-descending order

対策例

before

after

Image elements do not have [alt] attributes

対策例

推奨

ミニマム対応

Form elements do not have associated labels

対策例

before

after

フリカエリ星人との邂逅　～ふりかえりのお道具箱＆お悩み相談～

ウェブアクセシビリティ再入門

まとめ − "ウェブアクセシビリティ再入門 202112 記事バージョン" について総括