#JaSSTKyushu に参加しました

この記事は、ソフトウェアテスト Advent Calendar 2019 8日目の記事です。

前日の記事はこちら。
探索的テスターがUserstoryを作る話と、UserStoryMappingていいね。って話。

次は @halspring さんがアジャイルとテスト計画について吟じます。

はじめに

11/29に開催された、JaSST’19 Kyushuの参加レポートです。
ポエム多めでお送りします。

@pineapplecandyさんによるtogetterはこちら
JaSST’19九州まとめ #JaSSTKyushu

いままで東京ばかりの参加だったので地方JaSSTはTohokuに続いて2回目でした。
テーマは無し……となっていますが、「関係性とチーム」「開発とテスト」を軸にしているそうです。

オープニング

機材トラブルによりスライドなしｗ
慌てず騒がず場をつなぐ共同実行委員長の松谷さんと、実行委員の吉武さんがさすがでしたｗ

参加者について
- 51人満員御礼 (一度増枠)
- 経験年数10年以上が27名
  - 中堅～ベテラン勢が多め
- 九州とそれ以外でおおよそ半数ずつの人数比

関東勢が多い印象でしたが、九州と関東でだいたい半分ずつくらいとのこと。
九州のテスト系のイベントは最近たくさんあってどれもにぎわっているので実行委員や、勉強会を主催してくださっている方々の影響があるのかなと思いました(/・ω・)/

第一部「チケットシステムで理解するあのチーム」

咳さん、miwaさんのセッションその1 「あのチーム」の紹介
参考資料：https://speakerdeck.com/m_seki/xpjug2019-a-4-tiketutosisutemufalseshe-ji-toshi-zhuang-afalsetimu-falseyun-yong

導入部

20年続くチーム
医療システムの開発・QAを行うteam
- プロダクトを見せながらmiwaさん「大きくてかっこいい」

チケットシステム

世界一長生きなXPのチーム
- 長生きは目標ではなく結果
反復開発
- いわゆるV字モデルを何度も何度も繰り返す
テストファーストとは？
- ファーストは安全第一の「第一」
- 開発のすべての活動の基盤になる
すべての活動をテストする
- テストは終端ではなく発端
- すべての活動を「くり返し」できるように
  - 本当にくり返しか？同じことはくり返さないけど、同じ（ような）ことのくり返しに感じられる
あのチームの特徴
- 人数、担当範囲とも非常に大きく、複数の会社・組織またがって生き残っているチーム
- Wikiの規模は9万ページ（！）
  - 毎日1000ページが更新されている

1. チケット編

チケットは仕事の一つの単位
- V字の上から下、下から上まで、完結したV字
紙の不具合票の使われ方を参考にしている
ワークフローは変わる
運用・設計について説明できるチーム！

チケット番号
- すぐにあふれて4桁になった。4桁は口頭で話しやすい
要件（サマリー）
- 「できること」を一行で表す。内容を思い出せるほどほどの長さ
  - 自分たちがわかれば十分
- イマイチなサマリーでも、みんなが朝会で何とかしてくれる
チケットのstatus
- チケットの種類（3種類）
  - story / bug（課題）：触って確かめるテストを書く
  - task（作業）：テストが書けないもの
- イテレーション
  - 週に名前を付けたもの。いつやるかを示す
- サイン
  - 自分でサインする。いまは製品名＋バージョン＋名前を書いている
- 状態
  - openか、closeか
  - 結局、終わっているかどうかだけ明示すれば十分だった
- 見積
  - ベロシティや、納期を約束するものとしては使っていない。興味があるのは終わるかどうかだけ
テストと履歴
- 確認するためのテストの内容が記載されている
- 毎日テストする（！）
  - たまにNGになる
  - 実装の変化によりテストの意味がなくなるものもある

statusは変わり続けてきた
- 変化を邪魔しない・促すチケットシステム
Wikiページをそのまま使う
- 紙に書くように自由に

忍者式テスト
- すべてのチケットに、それを確認するテストを書く
- story / bugが終わるたびにテストが増える
TDDの自然な拡張
- あらゆる設計はテストで駆動。ゴールや意図をテストで表現する
- 顧客が触って分かるような「システムに対する変更」がチケット
  - ライブラリなど部品だけ作っても触れないものはチケットの単位にしない

今はおすすめテストスイート抽出アルゴリズムによってテストの頻度を調整しているということだったけど、それでも、膨大だろうチケット一つ一つをテストする……というのがあまり想像できませんでした。（ただただスゴイの気持ち）

毎回テストするために読み返して、古い記述を修正するので、チケット自体が最新の仕様書であり、テスト項目書になっているのかな。
惰性でやっていると矛盾に気が付かないまま間違った結果でOKをつけてしまいそうだし（ダメです）すごくすごく、仕事に対して集中しているんだろうなあと感じました。

追記
忍者式テストについてはmiwaさんからブログを紹介してもらいました！

http://miwa719.hatenablog.com/entry/daily20190624

2. インデックス編

チケットのリスト
全員が同じリストを見る
表示される場所はほぼ固定
- いつもとどんな風に違うか一目でわかる
面積比でチームの様子がわかる
- 正常（いつも通り）か否か
担当者ごとにまとまるので一人で抱え込みすぎていてもバレる
- 今は製品＋バージョン＋担当者
- チームがどのプロジェクトに注力しているのか見える

毎日同じことを「くり返している」から、「いつもと違う」ことがすぐに感じ取れるのかなと思いました。
見えすぎると集中できないことがあるので、適度に情報を絞るのは、普段の業務でもちゃんと意識していきたいところ。

3. 朝会編

朝会は9:15-10:00
プロジェクターの解像度とメンバーの年齢に合わせた拡大率に設定ｗ
今週のイテレーションのすべてのチケットを音読する
- 音読中は目も耳も集中する
誰かが「これなんだっけ？」と言い出してしばらく、チケットの再学習が行われる
- なぜこれをやるの？いま？
- うまくいくとどうなるの？……あのチームのあのフレーズで思考されている
チケットは、「どう製品を変更したいか」の表明。作業のために作成するのではない
bugはstoryに対してゴールが明確なのであんまりもめない
45分で終わらないこともある。チケットが多すぎるからかも？いろいろと調整が始まる
朝会に限らず「時間割」がみんなの体に染みついている
- XPから学んだものの一つ > タイムボックス
チケットとインデックスは、「付箋紙と壁」のようなもの
- 紙と比べて内容を更新し続けること、参照することが容易
- 更新しないなら捨てたほうがいい
- 毎日チケットを読み返して更新していると、メンバーの脳内配線が強化される
- 人側がプライマリのデータベースになる！

朝会とかミーティングって、なんだかんだ周りが内職していたり、集中していなかったり……多くないですか？という私も、気になることがあると集中していなかったり、聞き逃したり、よくあります。
なんのためにみんな集まってるのかを考えたら絶対によくないのはわかりきってますよね。
集中して、ほかの人の作業＝自分のチームの作業を拾い上げるようにしなきゃなと、改めて思いました。気を付けよう……。

（あと、更新されていないWikiページ……身に覚えが……ありすぎてつらい。
　誰かに許可とって、調整して、更新して……ヨクナイ。変えたいどうすれば。。）

4. おまけ

あえて省いたもの
- はやりのシステムにたいていあるフォームとかワークフローとか
- 理由
  - 変化を阻害する。そもそも使いにくい
  - 他人のための機能

レポートは他人のための機能だったのでいらなかった。
でも上から求められない？いろいろ言われない？という質問に対して、咳さんが一言。
「うまくいってると上からあれこれ聞かれない」
圧倒的自信！めちゃくちゃかっこいいなって思いました。

感想

自分が担当しているプロダクトを「かっこいい」とさらりと言えることがかっこいい。
試行錯誤があって、経験があって、自分たちで考え行動してきた結果だから言えることなのかなと。

自分のプロダクトを胸を張って人に勧められるか？と聞かれたら、どこかに不安があったり、気になるところがあったり……今の私はできないです。

今まで関わってきたプロダクトは間違いなく勧められる / 好きだったんだけど、今関わっているプロダクトに対してなにかモヤモヤしたものがあります。
第三者検証のときに出来ていたことが、自社サービスでできない。
開発は開発、テストはテストと分かれてしまっていて、より良いものを一緒に作る！感がないのが原因かなーと思ってはいるものの、垣根をどうやったら壊せるのかなー。

あのフレーズを使っていけば、よくなるのかな？

第二部「フレーズで体験するあのチーム」

参考資料： https://speakerdeck.com/m_seki/xp-2018-f-7

あのチームでよく使うフレーズ、喜ばれるふるまいについて、みんなで考えたり話したりする参加型セッションでした。

反省
- チームを俯瞰しての開発の流れを報告してきた
- でもこれはチームの様子を説明しただけ
  - 読んだり聞いたりしただけではできない！！
仮説
- 問題を解決していく最中に起こる「小さな会話」が「よいチーム」を形作る
- フレーズ > ふるまい > 価値観

題材として選ばれたフレーズは以下の4つ。

「うまくいったらどうなるの？」
「見せて」
「ワザと？」
「わかんない」

「うまくいったらどうなるの？」

うまく迷えるための問い。
自分が、「何がわかっていて、何がわからないのか」を明らかにするためのもの。

未知の領域に対して、初めから答えだけ与えられても納得感がないので、うまく迷って、自分でゴールまでのステップを見つけられるのはいいなあと思いました。ぜひ使いたいフレーズ。

「見せて」

みせてぇ～♡と語尾を上げて、ハートをつけて使いましょう（笑）
今の状態がわかるのはもちろんですが、「隠さなくてよい」にふんふん、となりました。

なんとなく状況がまずいときとか、全然わかんなくて困っているときとか、どうしても「なんとか自分で解決しなきゃ！」と思ってしまいがちだけど、見せて、って言われたら見せざるを得ない。

見せて、と言う側も、「見た」瞬間にそれは自分の問題としてとらえる必要があって、他人事から自分事に変わる。
「チームで」「みんなで」の空気が素敵で泣きそう。

「ワザと？」

これだけ、すごくネガティブというか、否定的な言い回しだな？と感じたんですが、実際はそうではない。
「私たちはワザとこうしたんだっけ？」という、チームみんなに向かっての問いかけとして使われる。

例えば過去に時間の都合で暫定で対応したところなど、時間が経つとそれが事実になってしまうことがある。
後から思い返して、「ワザと？」と聞くことで本来やりたかったことを思い出す。

よくわからない仕様や、もはや誰も把握していないような「経緯」と戦うために使えるのかな。
フレーズが浸透するまでは言い回しに気を付けつつ、まずは自分に近いところから、問いかけに使っていきたいです。

「わかんない」

私は常にわかんないわかんない言っている気がします（笑）
違和感があって、ちゃんと深堀しなきゃ！みたいなのはあんまりなくて、とにかく何がわかんないのかもわかんないから、ひとつづつ話を聞いてほしいときｗ

自分もわかってないけど、みんなもわかってないこと、確かによくあって、そのたびにザワザワバタバタするので、積極的に発信していくのが良いのかなと。

あと、質問を受ける側のとき。同じ質問をされるってことは何かに問題があるはずと考えて、例えば資料がちゃんと整理されているかとか、もっとわかりやすい伝え方はないのか？とか、検討していきたい。
もちろん聞きやすい空気を作るのも大事！

喜ばれるふるまい

こんなことがあったら、すぐに誰かに言う / 見せる / 聞くこと。

変だな？と思ったとき
これバグかな？と思ったとき
仕様がわからないとき
テストのやり方がわからないとき
テストを思いついたとき

自分が困ったときに、誰かに言ったり、見てもらったりするのがあのチームで喜ばれるふるまい。
勤務時間が自分の時間だと思っていたけど、あのチームでは、チームの時間。
悩んだぶんだけ、チームの時間が浪費されていく。
ならば、早く共有して早く解決したほうが絶対良い！

悩んでる時ほど時計が見れなかったり、熱中しすぎたりするので、構わずみんなに共有できる空気感をもったチームを作っていきたいな。

「明日からできそう？」

がんば……！る！！！

招待講演「オンラインコミュニケーション時代における日本語文章の書き方～チーム内とチーム外のコミュニケーションで気をつけること～」

町田さんによる「日本語文章」のセッション。

無駄なドキュメントをできるだけ作らない傾向にある。
以前の開発よりも、文章を書く量が減ってきたが、開発にとって価値がある情報を文書化している。
重要な情報なので、きちんと書いていかなくてはいけない。

1. 自己紹介と背景

仕事でさまざまな文書をレビューする機会がある
- 自チームで作成した文書
- 社内のプロジェクトが作成した文書
- 社外活動で作成した文書
自分が気になることを共有することでレビューの負担を減らしたい
- 共有することで、文章の質が上がって自分のレビューが楽になる！
- 日本語の難しさや面白さを、楽しく学べるようにしよう！

2. 文章によるコミュニケーション

文章（文書）
- じっくりと考え、遂行できることは文章の大きなメリット
- 半面、書いていないことを伝えにくいデメリットがある
口頭
- 表情や声のトーンなど、言葉以外の情報で伝わるメリット
- 残せないことが多い、考える時間を取れない、言い直せないことがあるデメリット
チーム内
- 互いに気心が知れている
- 共有範囲が狭い
チーム外
- 互いのことを知らないことがある
- 共有範囲が広い
最近のソフトウェア開発でよく使われるコミュニケーションツール
- Slack,Chatwork,Teams,LINE,Twitter,Skype……
- チャットやメッセンジャーツールでは、文字を利用するが話し言葉中心
- 言葉以外の情報がないため、誤解が生じやすい

3. 町田さんが文章を書くときにしていること

3つのポリシー
- 読み手の立場に立つ
- 一字一句に魂を込める
- できるだけ書かない
心掛けている7つ（+1）のこと
- 読み手を知る
- 読み手のスタイルに合わせる
- 背景を伝える
- 簡単な言葉を使う
- 見た目をきれいにする
- 文章以外で表現する
- 簡潔に書く
- 翻訳ツールが理解できるかを確認する（現地で紹介された8つ目）
実践している7つのこと
- 何度も読み返す
- 真似をする／しない
- 意味を調べる
- 類義語を調べる
- 校正ツールを使う
- 頭を冷やす
- 俯瞰する
こだわっている7つのこと
- 係り受け
- 主語
- 長文
- 指示代名詞
- 否定文
- 専門用語
- 助詞

読み手の立場に立つ、当たり前なんだけどなかなかできてないことが多いかなと思います。
どうしても前提知識や主語が抜けてしまったり、わかりづらい文章になってしまったり。
私はいま海外のステークホルダとやり取りをすることが多いので、翻訳ツール / botをよく使います。
日本語的な表現ってどうしても過剰に装飾してしまうことが多くて、機械翻訳にかけてみると意味が分かりづらい文章になっていることが多いです。
簡単な言葉で、簡潔にって大事だなあ……と実感しているところです。

QAは特に文章を書くことが多い仕事だと思います。
各方面のステークホルダとやり取りしたり、チームメンバーとやり取りしたり、チーム内外ともに文章をやり取りします。
日本語に興味を持って、より良い文章・コミュニケーションができるように心掛けていきたいと思います。