RSGT2019 Day1レポート

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

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

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

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

f:id:nemorine:20190113225205j:plain

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

f:id:nemorine:20190113225214j:plain

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

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

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

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

同期会

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

www.fam333.com

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

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

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

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

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

気になったワード

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

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

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

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

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

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

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

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

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

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

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

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

Fun Done Learn

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

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

f:id:nemorine:20181222090026j:plain
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…(省略)になります。
仕様作成時、コード実装次に、以下の図の●と○の中間をちょっと考えることで変更に強い仕様やコードになると思います。
f:id:nemorine:20181216074832p:plain

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

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文字しか残されていなければ、キミはその文字を大切な人に贈るだろう。
元来、言葉は美しい。
言葉を汚している原因は、「文字」が無尽蔵に発行できてしまうことと、そこからくるボクらの甘えだと知った。

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

量を質に変えるキーポイント

アドベントカレンダーの12/9のエントリです

量をこなすことで質に変わる、すなわち何かを沢山やることで上達するというのはほんとにそうなのでしょうか?

量を質に変えるにはキーポイントが存在すると考えています。それは何かと言うと、『意識をしながら量をこなす』ことです。

自分は幼稚園の時から大学1年の時まで毎年スキーを滑っていました。もちろん滑るだけならだいたいどこでも滑れましたが、技術的には上手くなかったです。大学2年からは流行っていたスノーボードを滑るようになりました。*1
社会人になって5年目くらいのときに、知り合いのスキー大好きオジさんに誘われて、久しぶりにスキーを滑ることになりました。そのときにカービングのポイントである「角付け」、「荷重」、「回旋」という3つの要素を教えてもらいました。 3つを一気には難しいので、まずは「角付け」を意識しながら滑る、ビデオを見る、また意識して滑る。「角付け」ができたら次に「荷重」を意識する、ということを繰り返すことで、スキーのカービングが圧倒的に上手くなりました*2。そして何かを意識するためには、余裕が必要です。自分のスピードや斜度の範囲内で練習することで余裕ができ、意識したいことに集中することができます。

いまとなってふりかえると、どんだけ量をこなしても、ただそれだけでは質には変化しないと思います。もちろん慣れることでどこでも滑れるようになりました。しかし、その滑り方を続けていても、カービングが綺麗にできるようになるとは到底思えません。

まとめると、、、

  • 意識しながら量をこなすことで質に変換することが可能となる。
  • 意識を集中するためには、余裕が必要である。

最後に体重はいくら頑張っても質には変わりませんのであしからず。*3

*1:流行ってたので、、、

*2:この年はスキーを15日くらい滑りました

*3:痩せろ!!

ヒエラルキー組織における情報伝達パターン

現場では「無理」だという認識なのに、TOPは「上手くいっている」と認識しているという経験はありませんか?

自分の観察によると、この現象は以下の条件が揃うと発生しやすいようです。

  • 階層構造が深めのヒエラルキー組織である
  • 悪い報告をよしとしない文化を持つ

どうやって現場の無理という声がTOPまで伝わっていくかのイメージ図です。

f:id:nemorine:20181203194001p:plain
悪い報告が良い報告に変化する仕組み

【NO:無理です】 現場(図では一番下になっています)
【NO?:難しい可能性があります。】
【Yes?:大丈夫ですが、リスクあります】
【Yes:上手くいってます。大きな問題ありません。】

一番考えないといけないことは「報告は正しくない可能性がある」ということです。 人が報告をすると必ず伝言ゲームの要素が入ります。また悪い報告をして怒られたくないという感情や昇進のために悪い報告を隠して何とかリカバーしようとして報告を作為的に変更することも考えられます。

この状態になるとTOPが間違った情報を元に経営判断をする可能性があります。不幸なことですよね。

この解決策としては、TOPが現場を直に見に行ったり、現場の声をTOPに直接届けることができるような仕組みが必要です。このような活動を通して報告書だけでは得られない正しい現場の姿を認識することができます。 現場としては、オープンなデータを用意することで、TOPを含む誰もがいつでもアクセスできる環境を提供するのが良いと思います。

f:id:nemorine:20181203194030p:plain
解決策

また組織としては、『悪い報告を歓迎する雰囲気』を作らないといけません。 悪い報告をすると上司の機嫌が悪くなる、上司からの叱責を回避したいという状態であれば、やはり悪い報告は後回しになってしまいます。 ここは文化なので組織に所属する人みんなで作っていきたいところですね。