北海道ギフトの話
さて今回はスクラムフェス札幌で話題になった北海道ギフトの話をします。
北海道ギフトは自分がどうしてもやりたかった企画で半ば強引に押し切りました（笑
今回は地元の美味しい食べ物を楽しめないぶん、北海道ギフトで少しでも北海道を身近に感じてもらいたいと思いました。
結果、オンラインだけども味覚、嗅覚、触覚も使った美味しいフェスになったと思います。
元々、北海道の美味しいスイーツをちょっとずつ楽しめるセットがあるといいのになーと思っていたのですが、今回の北海道ギフトで個人的な夢が実現できて良かったです。
とはいっても実行までにはクリアすべきハードルはいくつかありました。
- 個人情報の問題
- いつまで受け付けるか問題
- 誰が買うのか問題
- 誰が包むのか問題
個人情報の問題
これは実行委員でかなり揉めました。そこまで頑張る必要あるか、リスクが高いのではないか。住所や名前が分からなくても送れる方法がないか色々探したのですが、最終的には申し込み時に個人情報の取り扱いに同意してもらうことにしました。 発送が終わるまでは厳重に管理して、発送が終わり次第、データと控えの用紙を速やかに破棄しました。
いつまで受け付けるのか問題
なるべく多くの人に届けたいという想いはあったのですが、発送の手間があるので申し込み期間を決めました。その前に告知を多めにしてなるべくたくさんの人に届けるようにしたつもりです。その結果、70名の方に申し込んでもらいました。本当にありがとうございました！ 申し込めなかった人ごめんなさい ＞＜
誰が買うのか問題
これは最初は一人でいけると踏んでたのですが、自分の見積もりが甘かったです。お菓子だけに。
両手に持ったお菓子が袋にパンパンで通りすぎる人の目が痛かったです。「あっ これは自分で食べるわけではないです」と心の中で呟いていました。
お菓子をフィニッシュしたあと、北海道名物のガラナジュースを買いに行ったのですが、これがお店で売っているところがなくて、すべて札幌駅周辺の自販機で購入しました。おっさんがガラナを買いだめしている姿もまたシュールだったと思います。
誰が包むのか問題
これも見積もりが甘かったです。おかしいですね。。。
当初は二人でやろうと思いましたが、実行委員の上戸鎖チームが手伝ってくれました。本当に感謝です。包むときはスクラムの話とかをしながら、時折立ち止まりカイゼンをかけながら詰めました。また出来上がった北海道ギフトがイイ感じ過ぎて、プロダクト愛が止まりませんでした。本当に良いプロダクトって毎回うっとりするんですね（笑
反応
ギフトが届いたときの皆さんのTweetが嬉しさに溢れていて、企画した自分もとても嬉しかったのを覚えています。 届いた瞬間に家族に取られてしまって、おかきしか残っていない人もいたようですが、家族サービスだと思っていただければ幸いです。
アジャイル札幌の初期メンバーでもあり、今回スピーカーとしても登壇してくれた前鼻さんがとても喜んでくれました！
東京で頑張っている仲間にも届けることができて良かったです！！
Scrum Fest Sapporo 2020 から北海道ギフトセットとTシャツが届いた！チョイスが分かってる感しかなくて流石すぎます。嬉しくて涙出る。
— Tsuyoshi MAEHANA (@sandinist) 2020年11月3日
これ集めて整えたり、発送するなど大変だったと思います。大感謝。#agilesapporo pic.twitter.com/OeM6FToCIB
本会のときにはもうやらないと宣言したのですが、「銀の弾丸ラジオ」で及部さんがめちゃ良かったと言ってくれて、そんなに言ってくれるならと心がグラっと揺らぎました。もしかしたら、次回も、、、
内容
自分で北海道ギフトを作りたい人のために、内容を書いておきます。
◆お菓子
◆アルコールセット
◆ジュースセット
- コアップガラナ
- トマトジュース / リンゴジュース
イベントの時間的盛り上がりを考える
このエントリは「ScrumFestSapporo2020 Advent Calendar 2020」の3日目のエントリになります。
スクラムフェス札幌のお祭りから1か月経ったんですね。 無事に終わってホッとしてます。 今回はイベントの時間的盛り上がりについて書いていこうと思います。
一般的なイベント
一般的なイベントって当日はすごい盛り上がりを見せるのですが、なかなかその盛り上がりは続きませんよね。
アーカイブ視聴ありのイベント
スクラムフェス大阪、スクラムフェス三河、そしてスクラムフェス札幌と今年実施したスクフェス3兄弟では1か月間のアーカイブ視聴をすることができました。しかもすごいことに一人でも参加者がいれば、社内やコミュニティ内での共有がOKなんです！！
アーカイブ視聴のいいところはこんな感じでしょうか？
- 当日の都合が合わなくても聞けること
- 時間を作れば興味のある全てのコンテンツが視聴できること
- 何回か聞きたいコンテンツを反芻することができること
そしてこのアーカイブ視聴によって、イベントの盛り上がりが終わってからもテールを引いて続く現象が起きている気がします。
今回も実行委員の会社だけではなく、すくすくスクラム仙台でも視聴会のイベントが開かれていました。もちろん自分の会社でも毎週金曜日に鑑賞会をやっています。
プレセッションありのイベント
そしてスクラムフェス札幌ではイベント前にプレセッションというものを3回実施しました。これは基調講演のebackyと一緒に基調講演を作るという試みで、ebackyと参加者が対話しながら、どういうところに困っているか、どういうところが興味があるかを探索していくセッションです。このプレセッションにより参加者はイベントの前から少しずつウォームアップをする形になります。
イベントの繋がり
これが単発のイベントだけではなく、色々なイベントでこの形が続くと全体としてはこういう形になると思います。 この形になると別のイベントで聞いた話と今のイベントの話が繋がってきて、学びがさらに深くなります。
新型コロナの対応でオンラインイベントが増え、技術も進化して、現在のような状況があると考えています。 イベント同士がそれぞれ有機的に繋がっていくことが、学び、モチベーションの維持にとても良いと考えています。
JaSST Online のゲスト出演 第1部
今回JaSST Onlineにゲストとして招かれました。探索的テストの動画を撮って、それをみんなで見てワイワイするという形式でイベントが開かれました。最初話を受けたときはできるかどうか分からない状態でしたが、面白そう！やってみたい！と思って引き受けました。結果として新しい試みに挑戦できたので満足しています。ただ次回やるならこうしたいところもあるので、ふりかえりがてら書いていきたいと思います。ちゅくちゅん。
探索的テストのスタイルの話
探索的テストもフリーな探索、チャーターを決めた探索、時間とミッションを決めたセッションベースドと色々あります。今回はフリーな探索を選んだのですが、これには二つの理由があります。
一つ目は現実のアプリと対話する感じを伝えたかったためです。 チャーターに沿うもの、または仕様書をチャーターとして探索的テストを実施する場合は通常の仕様書のテストと変わらないかもしれないなーという気がしていました。ほぼフリーで触る場合は常にシステムと対話するのでここが伝えれるといいなと思いました。
もう一つは学習している感じを伝えたかったためです。下記はExplore It!!の著者のErisabeth Hendricksonの定義ですが、仕様書を最初に読み込まないことで自分が探索しながら学習していく過程を見せれるかなと思いました。
探索的テスト by Erisabeth Hendrickson
直近の実験から得た”気づき”を次の実験へ活用し、テスト設計と実行を同時に行い、システムについて学習していくこと
Simultaneously designing and executing tests to learn about the system, usingyour insights from the last experiment to inform the next.
最初のイメージはこんな感じです。①の箇所で広く学習するところを見てもらって、そのあと特定の部分②～⑤のどこかに関して深く掘り下げるのがいいかと考えていました。
録画したときの話
自分は朝型なので、頭がスッキリしている朝に収録をしました。 進め方としては、まずはアプリの動きをイメージできるようにしたくて、最初はハッピーパスを通しつつアプリの動きを把握していくことにしました。 当初は30分くらい広めにやって、残り30分は深めにやる感じをイメージしていました。
結果からいうと、アプリの範囲が広くて、広さ優先の探索で終わってしまったという感じになりました。miwaさんの言葉を借りると「アプリケーション全体を草原を走るようにさらっとテストする」感じでした。この印象が強くなってしまったのは少し反省してます。Twitterライクな形なので参加者の共通認識もあるし、もう少し絞っても良かったかと思いました。深さ優先の探索は別機会にリベンジをしたいと思います（笑
また編集なしに拘ったため、テストデータの作成に手がかかるもの（かかりそうなもの）は上手くできませんでした。例えば、プロフィールの画像を設定するところなどは、本来であれば以下のようなバリエーションをパッと思いついて、バグが罠にかかるまでテストを実施していきますが、実際にテストしたのは手元にあったjpegとpngくらいでした。他にも著作権とか色々ありまして…
画像の種類：jpeg, gif, png, txt, 拡張子なし
画像サイズ：小さい、大きい、細長い
画像の特徴：アニメーション、透過
場所：PCから、スマホから
当日の話
皆さん温かく、しかし厳しく見てもらってめちゃくちゃ嬉しかったです。 ただ最初は状況が上手く共有できてなかった気がしたので、このアプリはどういうアプリで、会社的にはどういう状況で、nemorine自身はこういう風なアプローチで実施しますという設定を最初に共有しておけば良かったですね。しかしそこは質問のやり取りで探索的にクリアになっていった気がします。
参加者の皆さんをはじめ、質問者オプションで質問していただいたmiwaさん、かみむらさん、よっしーには感謝しています。どちらかというと質問者の皆さんは思考の状態に興味があって、感情、思考のあたりを聞かれた気がします。さすがだなと思いました。
miwaさんの質問で心に残っているのは、「削除」ボタンのまあいっか発言を的確に突っ込まれたところですね。めちゃくちゃクリアな声で「なぁにぃ～」と言われたのは一生の宝物です。血圧が200くらいまで上昇した気がします。またいつもは探索的テストの講習などでは「違和感」を大事にしてくださいと言っているのですが、スッと流している自分にカツを入れたいですね。 もう一つは、「送信」ボタンと「Tweet」ボタンの誤操作をして、「自分が動作を間違えたところは重要だよ」というところです。これも本当にその通りだと思います。業務中は誤解を生みそうな仕様は開発側に伝えることにしています。
かみむらさんの質問で心に残っているのは、「ビジネス視点を持っているか」です。うちの会社の特性上、社内では他社と比較が難しくビジネス視点というのが難しいと回答しました。が、お金のニオイが好きなので、一般のアプリを触るときはこの視点が強いと思います。最近だとオンラインホワイトボードのmiroを触りまくって探索っぽいことをしていたときは、これはすごい！！！と思った記憶があります。今はmiroの課金ユーザーです。
よっしーの質問で心に残っているのは、「仕様書が怪しいですね」という言葉に対する質問でした。単純なところのミスだったので仕様書を見て実装していないか、もしくは開発者のテストが終わってないかも、みたいな感情が生まれた瞬間ですね。このアプリに対する注意度が上がりました。
今回は自分としても探索的テストを深く考えるきっかけになりました。色々考えたことについてエントリを増やしていきたいと考えています。
実行委員の皆さん、参加者の皆さんどうもありがとうございました。
第2部に関してはまた別エントリで書こうと思います。ちゅくちゅん。
Scrum Master THE BOOK 読了
先日献本いただいたScrum Master THE BOOK（スクラムマスター ザ・ブック）の発売日に合わせて、感想文を書きました！
SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ
- 作者:Zuzana Sochova
- 発売日: 2020/09/09
- メディア: 単行本（ソフトカバー）
スクラムマスターとチーム
この本はスクラムマスターとチームに焦点を当てて書かれています。特にスクラムマスターに必要なマインドセットとソフトスキルがきっちり書かれているのが印象的です。スクラムガイドだけでは分からない現場のリアルな悩みと方針が書かれていますので、自分自身だけではなく、チームの指針にもなりそうです。グレートなスクラムマスターになるまでは、困ったときはすぐに手にとれるようにしておきます。
客観的なチェック
要所にあるExerciseというワークを実施することで、自分がスクラムマスターとして良いふるまいをできているか、チームがどのような状態にいるかが客観的に分かります。 自分達のチームが「個人の集まり」なのか「本当のチーム」か（Exerciseの一つとしてあります）を勇気をもって見てみましょう。 本に書き込みをすることに抵抗がある人いるかもしれないですが、ワークを定期的に実施し、書き込んでいくことで自分やチームの本として育てていけそうです。
読みやすさ
現場の一線で活躍するスクラムマスターたちがモブで翻訳しただけあってかなり読みやすいです。技術書に「なる早」って単語はなかなか見ないと思いますが、それくらい馴染み深く、そしてシンプルな言葉で書かれています。日本語として引っかかるところがなくて、綺麗な訳だなぁと見とれてしまいました。
グッときたところ
個人的にグッと来たところを数点書いておきます。 もちろん他にも良いところはたくさんありますし、その人のステージによって刺さるところも違うと思いますので本書を読んでほしいです。
スクラムマスターは、チームの秘書ではなく、チームが自分で障害物を取り除くのを助けます。
本にも書かれているとおり、スクラムマスター自身が障害を取り除くのは短期的な視点であり、長期的にはチームのためにはならないですよね。 自分達自身で障害を取り除いていく方法を、みんなで学んでいかないといけないですね。
チームや組織の一歩だけ先を行き、、チームを習慣、規範、癖から引きはがします。 あまり先に行きすぎるとチームはスクラムマスターの言うことをほとんど理解できなくなります。
これは自分の経験でもそういうことがありました。人には段階（状態）があって、その状態にないと次の段階にいけないことが多い気がしています。
山のガイドみたいに、少し先を歩くことで後ろの人達がルートに迷わないように、また分かれ道で判断の間違いをしないようにするのがスクラムマスターの役割であるというイメージを持ちました。
スクラムマスターの心理状態モデルにあるアプローチはいずれも重要です。 しかし、とても大事なピースがまだ一つ欠けています。それは観察です。
自分にとっても観察はとても重要なスキルの一つです。意識しないとどうしても現場を見ずに理想だけを語りがちになっちゃいますよね。それはもしかしたら先に行き過ぎている可能性が高いのではないでしょうか。一歩だけ先を行くためには、その人がいまどの状態にいるのか観察をする必要があると思います。
チームの4つの毒 ・非難する ・守りの姿勢 ・壁を作る ・侮辱する
以前所属してたチームが自分にとっては最悪のチームだったため、チームの話には敏感になっているから刺さった可能性が高いです。ただ、内容を読んでいくと、自分もそういうことをしている可能性があるなと気づきました。チームの雰囲気が悪くて悩んでいる人は是非読んでほしいパートです。
この本は自分でも使っていきたいですし、今アドバイスしているチームのスクラムマスターにもお勧めしようと思いました。 原著者のZuziさんと翻訳者の方々に感謝いたします。どうもありがとうございました！
More Effective Agile “ソフトウェアリーダー”になるための28の道標 読了
通称「もえアジャ」を読んでみました。
More Effective Agile “ソフトウェアリーダー”になるための28の道標
- 作者:Steve McConnell
- 発売日: 2020/06/11
- メディア: Kindle版
実は結構前に読み終わってブログも書いていたのですが下書きが消えてしまって、同時にやる気も消えてしまっていました。。。 頑張って書きました（2回目）
この本は英語版のときから上司が絶賛していたのですが、その訳が分かりました！ 先日社内のQA向けに本の内容を紹介したのですが、その上司は「今のエンジニアでアジャイル開発の影響を受けていない人はいないはず。エンジニアは全員読む価値がある。」と言っていました。結構ハッとしました。
自分がこの本が素晴らしいと思うところは以下の3つです。
1. 組織文化、対話、品質・テストを含め開発に必要なものが広く網羅されている
新しくアジャイル開発を取り入れる組織にとっては役立つと思います。シーケンシャル開発と対比されているところもかなり参考になります。
2. 具体的なアクションが書かれている
各章の最後に「推奨リーダーシップアクション」として具体的なアクションが書かれています。そのため導入時や迷ったときにアクションにつなげやすいと思います。 しかもそのアクションが検査と適応になっていてスクラム知っている人ならわかりやすいです。
3. 冷静な目で書かれている
主観ではなく、論文などを引用しながら効果が述べられています。 例えば、モブプロについては「これらのプラクティスを実践して成功を収めているチームもいくつかあるが、その有効性にはまだ疑問の余地がある。」と書かれています。
グッと来たところ
スプリント疲れに対処する方法の 1つは、スプリントの長さをたまに変えてみることである。
これは興味深いですね。リズムを作ることが良いことかと思ってましたが、それにより疲弊することもあるということでスプリントの長さを変えてみるという話でした。本文では2週間6, 1週間1という感じになっていましたが、1週間スプリントをリリース終わったタイミングで2週間とかにするのもいいかなと思いました。
アジャイル開発は従来の「テスト」の重点に 4つの変化をもたらした。 1つ目は、開発者によるテストをさらに重視するようになったことである。 2つ目は、フロントローディングテスト──つまり、機能を作成したらすぐにテストすることを重視するようになったことである。 3つ目は、テストの自動化をさらに重視するようになったことである。そして 4つ目は、要求と設計を改善する手段としてテストを重視するようになったことだ。
これは上司を説得するときなどに使えそうですねｗ
スクラムにおいて最もよくある失敗モードの 1つは、無能なプロダクトオーナー（ PO）である。
以前社内で研修をしたときに、「もしかしてうちの会社の問題はPOが不在ってことなのでは？」という人がいたのを思い出しました。とにかくプロダクトに関する責任や決定権がボンヤリしていると進むものも進まないイメージです。
大規模な組織によく見られるパターンは、変革サイクルをいくつも開始した挙句、そのほとんどが実を結ばない、というものである。このようなサイクルを何回か経験すると、メンバーは身を潜め、自分の身に火の粉が降りかかる前に立ち消えになることを願うようになる。
これも胸が締め付けられるような思い出が蘇ります。自由にできる雰囲気、失敗を責めない雰囲気を作らないで名前だけ先行するとグダグダになることが多い気がします。
改革、イノベーションなどが付けたプロジェクトからはイノベーションが起きないと思っている派です。
上司の受け売りになりますが、現場で困っている人もアジャイル開発懐疑派の人も色々な人に読んでほしい本だと思いました！ あと翻訳者の長澤さんがJSTQBの用語の合わせてくれたということで、テストクラスタの人も読みやすいと思います。
テストの現状調査レポート2020
翻訳チームの一員として毎年翻訳しているテストの現状調査レポート2020が出ました！ 今回で7回目で世界のテストエンジニアに関する調査結果が載っています。
個人的に面白かったところをピックアップします。
テスターの年収
注目はとにかくアジアです。 10年以上のテスターは$95Kとかなり高くなっています。 2019年は$48Kだったので倍くらいですね。若干調査が偏った可能性もありますが、高くなっているのは間違いないでしょう。 アジアの集計には日本も入っているはずですが、それ以上に高いところ（たぶん中国）があったということだと思います。
日本のテストエンジニアの給与が456万円ということで日本とも倍くらいの開きがありそうです。日本でテストやQAの技術をもって、英語のスキルがあれば10年目くらいで1000万は目指せるのかもしれません。
組織内の開発スタイル
これも毎年気にしていますが、アジャイル/アジャイル的が89%とウォーターフォールが32%となってます。テスト側からの切り口で見ているので、そこそこ信頼できる数字だと思います。
CI/CDとの関わり方
46%の回答者が積極的に関わっているとのことです。
これからもテスターがCI/CDに積極的に関わっていくのだと思いますので、来年もこの指標は要チェックです。
テスト技法と方法論
こちらは探索的テストが84%と大きくなってきます。複数回答ありで、スクリプトテストの割合も高いので色々使い分けているのだと思います。もう少し掘り下げれるとさらに面白そうですね。
スクリプト化/自動化
機能テスト、リグレッションテストとCI/CDは安定の感じです。
それに加えて、単体テストが増えてきてます。テスター向けの調査なので、テスターが単体テストも担当するようになってきている流れだと思います。
他にも興味深い情報が沢山載ってます。テスターじゃなくても楽しめると思います。
ダウンロードは下記からどうぞ♪
http://qablog.practitest.com/state-of-testing/
Download report in Japanese: ダウンロード より
TOPページにはこちらも翻訳を手伝ったテスターちゃんが載ってます。
元カノは良かった症候群
チームメンバーに何かあるごとに「昔のチームだったらできた」とか、「（いまはいない）あの人だったらやってくれてたのに」という人はいませんか？
自分はそれを「元カノは良かった症候群」と勝手に呼んでいます。 そう、元カノは良かったのにーというアレです。( ꒪⌓꒪)
症状
こんなセリフがでると要注意です。
- 「昔のチームはこうだったのにー」
- 「あの人ならこうしてくれるのにー」
症状にいたる状況
過去にとても良いチームに所属していた、できる人と仕事をしていた人が別のチームに移ったときに発症することが多い気がします。メンバーでもリーダーでも発症することがあります。リーダーの場合は影響が大きいのでさらに厄介です。
周りへの影響
コミュニケーションとして人と比較してダメだしするのは基本的にNGだと思っています。言われた方もテンションがダダ下がります。
自分が実際に言われたときは「じゃその人連れてこいよ！ク〇が！」と思いました。
処方箋
- 人と比較するのをやめてもらう
- 現状のチームや個人で何が足りないかだけを言ってもらう
- 少しずつ改善していくことに合意してもらう
- 上記ができなかったら「いやー 以前のチームメンバーにはそういう比較する人いなくてよかったなー」とブーメランを返してあげましょう
とにかく理想に近い環境で仕事をできていて、その環境が変わった場合に”現実を認められない”のだと思います。 もちろん言っていることに納得できる部分もあるのですが、比較された瞬間に心の距離が遠くなります。 今のチームや個人の実力を考えると、理想が高すぎてすぐにはできないこともあります。
チームメンバーの心がサメないように、この症状が出そうなときはジンベエの名言を思い出したいと思います。自戒も込めて。無いものは無いんです。
