モブテストのハジメ

RSGTでの講演やアジャイルジャパン札幌サテライトについて検討していく中でモブという働き方を意識するようになりました。面白そうなので、2月からチームにジョインしたKさんともう一人のエンジニアの人と3人で会社内でモブテストをやってみました。

今回のテストはHDDのRAIDのテストでディスクを引き抜いてステータスが取れるかどうかを確認するというものです。もちろんRAIDの仕様上ホットスワップには対応しているとは知っていても、動いている状態で初めてHDDを抜くときは緊張しますよね。

今回意識するようにしたのは、対話を多くすることです。新しくジョインしたため分からないことが多いと思ったので小ネタや周辺の話も含めてお話しすることを心がけました。個人的には座学より、知識と体験を同時に学んでいく方が学習効果が高いと考えているからです。Kさんからも質問があったり、もう一人のエンジニアからの情報共有もあって盛り上がりました！

情報の共有だけではなく、「このHDDは思った以上にスッと抜けますね」「もう少しグッと刺さっている感が欲しいね」みたいな感覚の共有もできて面白かったです。

今回は試験仕様書に沿ったテスト（スクリプトテスト）をモブでやってみました。みんなでワイワイしながら新しいテストを試していくという探索的なモブテストとはちょっと違いますが、新しいチームメンバーへ周辺知識を伝えるという当初の目的は達成できたと思います。

これからもちょっとずつ実験していこうと思います。

熱かった！スクラムフェス大阪

たこ焼きって何であんなに美味しいの？！

スクラムフェス大阪に札幌からアジャイル札幌の運営を担っている4名のエンジニアで参加しました。 もちろん話を聞くこともそうですが、秋に実施予定の札幌のスクラムイベントへのヒントも探すつもりでした。 初回とは思えないすごい熱量で今の自分の悩みに当てはめながら考えたりして、2日間頭がグルグルしっぱなしでした。 気づいたことや印象的だったところを書き留めておきます。

アジャイル札幌メンバー

コンテンツ

バランスが良いなぁというのが率直な感想です。 首都圏と地方、開発とQA（メトリクス）、真面目とエンタメ(?)、ワークショップ、説教などなど。スクラムに対する知識や実践のレベルがどのような人でも必ず何かを取れるようなコンテンツの作り方だと感じました。 当たり前かもですが、地元関西のコンテンツがしっかり入っていて関西の層の厚さを感じました。

参加者のダイバーシティ

参加者は日本どころか世界からも来ていました。こういうのが普通になるっていい環境ですね。

函館の人いなくて良かった。。。

交流

途切れることなくみんながワイワイ話していた気がします。コーヒーブレイクやネットワーキングのときは沢山の人とお話することができました。自分もたまたま隣になった発表者の方と話していたら、その方の上司と知り合いだったことから話が盛り上がりました。札幌から一緒にいったゲーム好きのいづはスクエニのエンジニアと名刺交換して舞い上がり、そのあともズッと話して舞い上がっていました。これぞギャザリング。

プレゼン

聞いたものは全部書きたいですが、3つを厳選して。

新卒日系ブラジル人がリーン＆アジャイルなメトリクス管理に出会った話 Arissa Nakamura

新人でありながらアジャイルなチームにコミットして、そのチームに必要なメトリクスを取って、そのメトリクスをきっかけにして、チームの考える場を作っているというのは本当に凄いです。

• 生産性
• バグの修正時間
• ストーリーのバーンダーン
• バグの予実

アジャイルプロジェクトのメトリクスは何を取ればいいんでしょ？と思っている人はこの発表を是非聞いてほしいです。発表資料は会社のQA関係者に回したいと思ってます。

speakerdeck.com

基調「公」演 ぼくたちのアンパンマンマーチ（ちんもさんの案）

元気＝およべさん、勇気＝きょんくんの公演（講演ではない）。いままで見た中で一番インパクトがある技術の公演だったと思います。そして多分これからもないだろうなぁ。。。

超人と見られることが多い二人の人間っぽい一面を見れたのが凄く良かったです。二人とも考えて、行動して、考えて、行動して、を繰り返していて今の状態にいるのが良くわかりました。そしてエンターテイナーでしたね。面白過ぎました。 そしてねのさんの生演奏。凄すぎる。。。しかも後で基盤チームの人と話したら、JASRACに申請しているとか。どこまでもしっかりしていることにびっくりしましたｗｗｗ 元気代表のおよべさんが3月に札幌に来てくれるので、それもまた楽しみです。

スクラムフレームワークを使用する具体的な方法。僕の場合。

しーばさんのセッションは今チームリーダーとして悩んでいる自分にガツンと響きました。 しーばさんのプレゼンはいつも強い現場感（ドロドロした感）とそれを悲観的にしない強さと優しさで溢れている気がします。 https://bufferings.hatenablog.com/entry/2019/02/24/124752

自分もまずはステークホルダーと今の開発方法、開発の状況を一枚絵にしておこうと決めました。そして一歩ずつカイゼンしていこうと決めました。

今秋予定している札幌でのスクラムイベントも大阪に負けないくらい熱く楽しいイベントにしたいと思います。 面白さでは勝てないので、違う方向性でｗｗｗ

RSGT2019 Day1レポート

今年もリージョナルスクラムギャザリング東京2019（RSGT）へ行ってきました。
最近は一年の計はRSGTにあり的な感覚になっている気がします。今回はアジャイル札幌のメンバーのあべちゃんと勉強会の友人である上戸鎖夫婦と一緒に参加できて最高にHappyなRSGTになりました。

基調講演 Outcome Delivery: delivering what matters / Gabrielle Benefield

Whatではなく、Whyを考えよう！
その方法としてデザイン思考＋アジャイルを統合したメビウスのループを提案するという内容でした。

いきなり素晴らしいコーヒーの絵を描くワークがありました。そのあと素晴らしいコーヒー体験の絵を描きました。自分は山に登って飲んだコーヒーが美味しかったのでそれを絵に描きました。そしてGabrielleさんがコーヒーは何のために飲むのかという問いかけをして、Whyについて考えました。

問題を定義しよう！ということでは新しいことではないんだけど、デザイン思考とアジャイルをグルグル回すイメージでそこに名前を付けてフレームワークにしたのが価値があると思います。 メビウスの図の中のカードがナイスデザインでした。

そしてGabrielleはめっちゃ美人でしたよっ！！

チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方- 天野さん 大友さん

外部のスクラムマスターだった大友さんを連れてきて、サイボウズのチームが一体となってカイゼンした話。 大友さんのチームを見る冷静な観察眼とチームにあえて変化をもたらす天野さんのコンビが凄くて色々勉強になりました。

グッと来たのは見積もりの中に入れるバッファの運用を止めたところ。なかなかできないと思いました。付け足すのって比較的簡単だと思うんですが、やめるとか手放すって難しいですよね。。。

同期会

夜はスクラムマスター講習2014@仙台の同期会に参加しました。fam333というところで飲んだのですが、クラフトビールが美味しいすぎてヤバいです。Day0もよなよなしたので2日連続のクラフトビールになります。
仙台の半谷さんや師匠のエバッキーも来てくれて、同期＋スクラムマスターたちでワイワイ飲みました。札幌からの友人たちもすんなりと受け入れてくれて本当にいい人たちだなぁと改めて思いました。 スクラムギャザリングの話やスクラムの話、会社の話など1年に一回だけど集まってワイワイ話せるってめっちゃいいですね！！企画してくれた野村さんありがとうございます。

www.fam333.com

ってことで、1日目のレポートは終了です～

あるノルウェーの大工の日記 読了

会社の上司から借りたノルウェーの大工さんの本を読みました。 ある大工さんが屋根裏の改築をしていく様子を書いたものです。
語り口は素朴な感じながら、仕事の進め方、チームというもの、お客さまへの信頼感の構築の方法などソフトウェアに共通するコトが書かれています。
特にDIY好きな自分にとっては、大工さんの仕事や思考の一面を知る楽しみも含めて、最後までワクワクしながら読むことができました。

あるノルウェーの大工の日記

気になったワード

大工道具は私の分身のようなものだ。道具を大切に扱うことは、大工という職業、仕事そして自分自身に対する敬意である。（P7）

道具を大事にするって重要ですよね。

職人、おして職人技（クラフトマンシップ）そのものには、ある程度の自由や裁量が必要だ。それがあって初めて、消費者が製品の美しさや機能性を享受できるようになる。（P79）

余裕、ゆとり、自由、言い方は色々あるかもしれませんが、それが製品の美しさや機能性に繋がる。ここらへんもソフトウェアと一緒だと思いますが、今のプロジェクトでは余裕がないのが実情です。

作業現場が整理整頓されると、作業効率が上がり、より安全になる。それに仕事に行くのも楽しくなる。（P161）

DIY作業のときは特に感じます。道具が行方不明になって探す時間は本当に無駄だと感じますし、めちゃくちゃイライラしますｗ

私たちは一つのチームとして働いているが、必ずどちらかがリーダーとしての責任を負う。（P204）

責任を押し付けあっているチーム、リーダーは居ませんか？（笑

自分の限界を認めるのは職人にとって最も重要なことだが、これについては実際に作業をしながら学んでいくしかない。弟子に口頭で教えることはできるが、その弟子も結局は時間をかけ経験を積みながら実感していくのだ。失敗することは、自分の限界を知るためにも大事だ。良い職場とは、失敗を許してくれて、しかもその失敗が大きくなりすぎないように、うまくカバーしてくれるようなところだろう。（P209）

失敗を許してくれて、大きくなりすぎないようにするっていいですよね。

私は細かい作業が発生する度にさっさとやってしまう方がいいと考えている。ちまちまとした手作業を長々と続けることは少々退屈なので、分散させたほうがいい。（P236）

これは耳が痛いので、退屈な作業もパパッとやる癖をつけたいところです。
が、性格上、、、うまく行かないことも多いんですが、、、

Fun Done Learn

はじめてのアドベントカレンダーの12/19のエントリです。

スクラムトゥギャザーリングのときに川口さんから教えてもらった新しいふりかえりの方法が面白かったので、やり方をまとめておきます。またKPTの違いについて少し考えてみました。（以下の写真はスクラムトゥギャザーリングのふりかえり時のもの）

Fun Done Learn

やり方

• Fun Done Learnのベン図を書く
• 付箋にFun Done Learnと思うものを書いてはりつける
• チームの皆で話ながら、ベン図のどこにあたるかを確認していく（位置をずらしていく）

Fun Done Learnの特長

感情のFunが入っている

カイゼンをするときは事実に目を向け、、、と思ってきました。でもこのふりかえりには『楽しさ』を表すFunが入ってます！ゲーミフィケーションが好きな自分にはしっくりきました。何事も楽しくないと続かないですよね！

ネガティブにならない

KPTの場合はProblem→Tryに集中してしまうことが多く、一歩間違うと犯人捜しが始まります。一方、Fun Done Learnは全てのワードがポジティブなイメージを持っているため、ダークサイドに落ちにくいと感じています。 KPTのProblemはLearn＝Problem＋Tryの形で出てくることが多く、次にどうしたら良いかという未来へつながる思考になることが多いと感じています。

何度も話す機会がある

ベン図上で付箋を貼り替えていくため、何度も付箋に書かれていることに触れることになります。 ポジティブな言葉で書かれているため、チームの自信を深め、信頼を深める効果があると思います。 牛で言うと反芻ですね。

使いどころ

Fun Done Learnはどこでも使えると思いますが、個人的には以下の場合の効果が高そうだと思っています。

• ふりかえり自体をやったことがない場合
• かけだしのチームなどまだお互いの信頼感が薄い場合
• 初めてのことに挑戦した場合
• チームの雰囲気が落ち込んでいる場合
• Problemで犯人捜しが始まることが多い場合

川口さん、ありがとうございました！

境界の仕様

ソフトウェアテストの#2のアドベントカレンダーの12/16のエントリになります。

今回は自分がやらかしてしまった境界の仕様の話をしようと思います。

あるセンサーのデータを収集する機能があります。
そのままデータ収集を続けるとデータが多くなって、DBの容量がいっぱいになりますので、沢山たまったデータを削除するパージという機能が必要です。
それではそのパージの機能ですが、どちらの仕様(コード)が良いでしょうか？
※ここでは仕様に沿ってコードが実装されると仮定しています。

ID	仕様	条件の疑似コード例
A0	ある日付より前のデータは消す	date < "2018/12/11"
B0	ある日付以前のデータは消す	date <= "2018/12/10"

もちろんどちらでも大丈夫そうに見えますね。 dateは日付なのでどちらも期待通りに動作します。

さて、ここに時間の概念が入ってきたらどうなるでしょうか？

ID	仕様	条件の疑似コード例
A1	ある日時より前のデータは消す	dateTime < "2018/12/11 00:00:00"
B1	ある日時以前のデータは消す	dateTime <= "2018/12/10 00:00:00"

あれ？B1のパターンは2018/12/10 12:00:00のデータが消えないというバグがありそうですね。 これを期待通りに動作するように変更すると以下のようになります。

ID	仕様	条件の疑似コード例
A2	ある日時より前のデータは消す	dateTime < "2018/12/11 00:00:00"
B2	ある日時以前のデータは消す	dateTime <= "2018/12/10 23:59:59"

23:59:59なんて何か嫌な感じですね。

さて、さらにミリ秒の概念が入ってきたらどうでしょうか？

ID	仕様	条件の疑似コード例
A3	ある日時より前のデータは消す	dateTime < "2018/12/11 00:00:00.000"
B3	ある日時以前のデータは消す	dateTime <= "2018/12/10 23:59:59.999"

ここまで来るとだんだんわかってきますね。
日付というのは実は範囲を持っていて、2018/12/10 00:00:00.000 から 2018/12/10 23:59:59.999…（省略）になります。
仕様作成時、コード実装次に、以下の図の●と○の中間をちょっと考えることで変更に強い仕様やコードになると思います。

ちなみに自分が埋め込んだバグは 以前の仕様に則って、<=を使用し、

dateTime <= "2018/12/10 23:59:59.999"

と実装したのですが、小数点以下がなんと6桁のケースもありました ＞＜
すなわち、2018/12/10 23:59:59.999001 ~ 2018/12/10 23:59:59.999999が削除されないことになります。
レビュー指摘されて、事なきを得ましたが危なかったですねぇ。

新世界 読了

初めてのアドベントカレンダーの12/14のエントリです

キンコン西野さんの本を会社の先輩から借りたので読んでみました。 好き嫌いがかなり分かれる人だと思いますが、自分は西野さん好き派ですね。 東京のプペルの展覧会も行きました。

新世界

この本では「信用」と「お金」の話が出てきます。

• どのように信用を積み上げるのか
• どのように信用をお金に変えるのか
• これからの世界はどうなっていくのか

色々な話が西野さんの視点と具体例を交えながら書かれています。 文もサクサクと読めるし、内容も面白いです。

自分的には特に興味をひかれたのは、文字数に応じて文字をお金のように扱うレターポットというサービス。 100レターを500円で買って、特定の宛先に送れるような仕組み。 例えば、被災地へ応援メッセージを送ることで、その文字数に応じて被災地の義援金になります。 実際に2018年の西日本豪雨では、135万円が岡山へ寄付されたとのことです。 発想とか考え方が既に面白いですね。

西野さんがレターポットのサービスから気づいたことが書かれているのですが、それにハッとしたので書き留めておきます。

ボクらは、使える文字に制限があると、わざわざ誰かを傷つけるようなことに文字を割かない。
たとえばキミの手元に、あと20文字しか残されていなければ、キミはその文字を大切な人に贈るだろう。
元来、言葉は美しい。
言葉を汚している原因は、「文字」が無尽蔵に発行できてしまうことと、そこからくるボクらの甘えだと知った。

言葉、、、気を付けようっと。