Scrum Fest Osaka 2021 keynote『誰も嫌な思いをしない変化』
https://confengine.com/conferences/scrum-fest-osaka-2021
2021/06/25に開催されたScrum Fest Osaka 2021 Day 1のキーノート、しーばさんの「誰も嫌な思いをしない変化」を聞いて今の自分の環境と重なるところが多かったので感想を書きます。
え、嫌な思いをしないで変化ってできるの？
私がしーばさんの講演タイトルを見てもっとも興味深かったのは"誰も嫌な思いをしない"というキーワードでした。
なぜかというと、変化には時として克服が伴うし克服は辛い思いをしながらするものだと思うからです。
乗り越えた後にはいろんなことが良くなっていることが多いので変化は歓迎するべきと思います。 一方、その過程で「辛い」という感情と「できていない」という現実に長期的に向き合っていかなければならないことも多く、それは私にとって"苦痛"でした。 だから誰も嫌な思いをしないで変化できるならその方が持続的な変化を期待できるのではと思いました。
嫌な思いの正体
頭では「やらなきゃいけない」とわかっているけど心では「面倒くさい」。このように「頭の流れ」と「心の流れ」が違うと「嫌な思い」が生まれる。
そうか、これが嫌な思いの正体なんだ。
例えば「もっとこういうことができるようになってほしい」と期待を伝えられるとき、本来期待はわくわくするものなはずなのに、重いと感じることがあります。 それは自分で理解していつつも、心が抵抗しているからなんだとわかりました。
- できるようになるべきだとわかっているけど、苦手
- できるようになるべきだとわかっているけど、他のこともやらないといけない
- できるようになるべきだとわかっているけど、そんなに興味がない
- できるようになるべきだとわかっているけど、違うことがしたい
- できるようになるべきだとわかっているけど、できることも見てほしい
こんな感情が沸くときその期待は私には重く、心には嫌な思いが生まれます。
チームが自走するために
相手に期待をしない
自走できるチームを作るには「目の前の誰か一人の行動を変えること」を続けること。 そのためにしーばさんがとっている自分自身の行動の１つは「相手に期待をしない」です。
相手に期待をすると、自分の期待通りにならないとイラッとしてしまい「思い通りにならない」「思い通りにしたい」という自分の感情に注意が向いてしまったり、相手に問題があるのではと考えてしまい、本来の目的から脱線してしまったりします。
そしてしーばさんはうまく行かなかないのは相手せいと考えてもなにも進まないということに気づいて以来相手に期待をしなくなったそうです。
相手に期待をしないことで、期待通りにならない時に起こる自分の気持ちと距離を置くことができます。
相手の気持ちを考えない、相手の気持ちに向き合わない
相手の気持ちを想像する時、自分は相手にどう思われるか？ということも同時に気にしてしまい、 相手の気持ちに向き合う時、自分がうまく答えよう導こうという気持ちに意識がいってしまいます。
なので、相手と向き合うのではなく相手と並走するスタイルにしているそうです。
自分の行動を変える
しーばさんは、誰か行動を直接変えようとせずに自分の行動を変えることで相手の行動が変わることを促すようにしています。相手の行動が変わらなかった時は自分の行動を見直して、自分の行動の方を変えるそうです。
良いところを伸ばす
前述したように克服するというのは、多くの場合嫌な思いが伴います。 苦手なところを無理に克服しようとするのではなく、苦手なところはチームで補える仕組みをつくり 、個々では得意なことをもっとより伸ばせるとようにしているとのことです。 苦手なことに関しては「取り組む数は２つ」などと決めてこれは頑張るけどこれ以外はやらない、と決めて取り組んでいるようです。
これだと楽しそう。
感想
うちの会社の自走できるチームを目指しています。でもなかなかそんな簡単にはいってません。 自分はバリバリコード書いたりするのはまだ苦手ですが、チームを良くすることや流れを作ることは人より得意だと思っているので少しでも楽しくなるように、昨日よりもっと良くなるように積極的に取り組んでいます。
だけど最近は、色んなことが起きていく中でチーム作りのような「成果の測りづらい取り組み」に対して、やる意義を感じられなくなっているのも事実でした。 だからこのセッションは自分の今の状況とすごく重なるところがありとても刺さりました。
最近心身ともに疲れていたので本当はスクフェス大阪の当日参加はやめて休息日にしようと思っていました。でも朝起きてベッドの中でしーばさんの講演を聴いて「やっぱり参加したい」と思い、今札幌トラックに参加しています。
札幌トラックでもさとりゅーさんがしーばさんのセッションの重なるようなお話をされていて、やっぱり参加すると元気になれますね。
しーばさん素晴らしい講演本当にありがとうございました。
ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方
レビュワーとして関わらせていただいたため「ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方」を発売日より一足早く献本いただきました。わーい。
ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方
- 作者:Jonathan Rasmusson
- 発売日: 2021/04/26
- メディア: 単行本（ソフトカバー）
読者＆レビュワーの２つの視点から感想を書きたいと思います。
読者として
ワクワクする
著者はアジャイルサムライで有名なJonathan Rasmusson氏です(以降、ジョナサンと呼ぶことにします)。 本書はジョナサンが在籍していた頃に行っていたSpotifyの取り組みや自身の経験について書かれています。
この本は、読み始めるととてもワクワクします。語り口調で親近感が沸くし、絵が多く表現が面白いのです。この雰囲気はアジャイルサムライと似ていますね！
例えば、"スタートアップは「火星」から来た"、 "エンタープライズ企業は「金星」から来た"という表現は、スタートアップとエンタープライズ企業のそれぞれを取り巻く環境の違いを表した表現なんですが、こう書かれると近未来感が増して、「ユニコーン」という言葉がより一層引き立つ感じがします。こういうのが最後まで飽きずに読める仕組みなんですよね。
これはSpotifyの取り組みの話
私がこの本を読んで感じたことは、ユニコーン企業は成功に向けてのトライをし続けているということです。
Spotifyといえば"Spotifyモデル"が有名ですね。
本書でも、この"Spotify"モデルを軸とした様々な取り組みについて書かれています。
ですが、現在SpotifyではSpotifyモデルを使っていません*1。「なんだ、"Spotify"モデルの話をしておいて、当の企業は使っていないなんて失敗したモデルの話か。」と思われるかもしれませんが、私が大切だと感じたのはこのモデルが良いか悪いかではなく、Spotifyではまずメンバーやチームを信頼するところがスタートだということ*2、模倣ではなくトライした結果から学ぶということ、そして時にはやめることもあるということで、こういった姿勢がいち企業をユニコーンへと成長させるのだと感じました。
"Spotify"モデルに限らずですが、これを模倣すればうまくいくなんてものは私はないと思っています（ソフトウェア開発においては特に）。
なのでSpotifyがSpotifyモデルを使っているかどうかはあまり重要なことではないと思いました。
皆さんがもし本書をお読みになる際には"Spotify"モデルがどんなものであるか知ると同時に、Spotifyの様々な取り組みの方にもより興味を持って読んでいただけると良いかと思います。
レビュワーとして
今回はレビュワーとして本書の出版前から関わらせていただきました。
まずはこのような貴重な機会を与えてくださった島田さん、角谷さんにお礼申し上げます。
レビュワーの人数×フィードバックの数を考えると相当な量だったように思いますが、細かい指摘に対してもより伝わる表現を考えてくださったり、ただひとつの言葉に対しても何度も議論を重ねて選定されていました*3。
翻訳とは変換作業ではなく、言葉から著者の想いを想像し読者に伝える架け橋なんだということを間近で感じられたのは最高でした。
微力ながらそのお手伝いができたとすれば大変うれしく思います。
そして他のレビュワーさんの視点や解釈も勉強になりました。
個人的な反省点としては、指摘内容に加えて「こう直したらより良いのでは」というアイディアを一緒に添えたりしていたのですが、素人目線のアドバイスは時として返って混乱させることがあるので、それよりも、指摘箇所に関して「なぜそう思ったか」が明確に伝わるようなフィードバックに全力を注いだほうがレビュワーとしての使命を果たせたような気がしました。よし、次に生かそう。
レビュワーとして参加することは一読者では得られないような学びの機会がたくさんあり、この一冊は私の宝物になりました。
Spotifyで実際に取り組まれていた組織作りのヒントがたくさん書かれていてかつ読みやすいので、興味のある方はぜひご覧になってください！
"Uncle Bob on Clean Agile the Book: Taking it Back to the Basics"の動画を訳してみた
clean agileを読んでから、著者のRobert C Martin(以降、愛称のボブおじさんと呼びます）について興味をもって色々漁っていたら面白い動画を見つけました。
開始0:18くらいのところでボブおじさんがなにかに爆笑しているんだけれども、英語なのでなにがツボっているのかさっぱりわからない。
Youtubeの自動翻訳を使ってみたけど精度が良くなくて、やっぱりさっぱりわからない。
ボブおじさんが何にツボっているのかがどうしても気になって仕方がないので、頑張って訳してみました。手順は以下の通りです。
- Youtube英語字幕を付けて英文を拾う
- 英文をDeepLで日本語に翻訳
- 翻訳した文を読みやすくする
昔はYoutubeの視聴者が翻訳した文章をフィードバックする機能があったみたいですが、廃止されちゃったっぽいですね、残念。
そもそもYoutube英語字幕が拾い間違っている単語*1もあり、そういうのは耳コピで頑張ったんですがそれでもわからないものはそのままにして雰囲気で訳してます。
あと文章の翻訳と違って、文節の釘地がイマイチわかりづらいので句読点などは一切無視しています。
英文間違い、翻訳間違い、文節が適切でないなどのご指摘や、フィードバックなどあればぜひお願いいたします。
Uncle Bob on Clean Agile the Book: Taking it Back to the Basics
so why did I write clean agile?
Kent Beck his praise quote said that you could feel Uncle Bob's frustration
I think that's a really good explanation for why I wrote clean agile because I am pretty frustrated
なぜ私はクリーン・アジャイルを書いたのか?
ケント・ベックは「アンクル・ボブのフラストレーションが伝わってくるようだ」と賞賛の言葉を述べました。
私がクリーン・アジャイルを書いたのは、かなりのフラストレーションを抱えていたからだというのは、実にいい説明だと思います。
（ここで爆笑）
look we started this whole agile thing almost twenty years ago
and the motivation was simple and it was kind of I don't want to say pure that's the wrong word
but it was motivated by the desire to do something good for the software industry to correct a problem that the software industry had dug itself into which of course was the whole heavyweight process water fallish wrap high level process
that people had gotten themselves all bollixed up into it and a few of us thought you know this is just nots there are simpler ways to do software there are easier ways to do software it doesn't have to be.
アジャイルというものを始めたのは約20年前です。
動機はシンプルで、何というかピュアと言うと間違った表現だけど、しかし、その動機はソフトウェア業界が陥っていたウォーターフォールでハイレベルなプロセスや重量級のプロセスの問題を解決するために、何か良いことをしたいという思いからでした。
人々はそれに夢中になっていましたが、私達の何人かはこうある必要はない、ソフトウェアを作るにはもっとシンプルな方法がある、ソフトウェアを作るにはもっと簡単な方法があると考える人もいました。
so complicated and so you know we met at the Snowbird meeting
and you know we really I don't know what expectation I had it was just a bunch of guys meeting and talking about this
and somehow in that meeting the magic happened that and I you know I don’t remember exactly how or why but all of a sudden there’s those four lines up on the board and they’re like you know that’s really significant
だから私たちはSnowbirdミーティングに参加したんです。
どんなことを期待をしていたのか分かりませんが、大勢の人が集まりこのことについて話をしました。
そのミーティングの中で、どういうわけか魔法が起きました。
正確には覚えていませんが、ホワイトボードに４行の言葉が書かれて、彼らは「これは非常に重要なことだ」となったのです*2。
and these people who should not have ever agreed on anything this bunch of really opinionated people were suddenly agreeing with each other
and you know Ward took that picture and he put up the website people are signing the website like crazy, I thought okay
意見が本当に多くて今まで合わなかったはずの人達の意見が、急に一致するようになりました。
そして、ウォードがその写真を撮ってウェブサイトに掲載したところ、皆狂ったようにウェブサイトに署名してくれました。
maybe something good has happened for the industry and then I don't want to go through the long history but and I do talk about it in the book but something's happened over the years right something’s gone off a little bit
now we’re all first of all there’s so many so many project managers and scrum masters and all the this stuff that we’re talking about and Kanban and lean and this and that and LeSS and SAFe and Meinhard and more
and the ideas were real simple you know it wasn’t that complicated
it doesn’t have to be over branded it doesn't have to be you know twisted and turned and prodded and poked
agile was simple
for the most part agile was a real simple idea mostly based on the ideas in extreme programming and scrum and a little bit of FDD
この業界にとって何か良いことがあったのかもしれませんが、 長い歴史を振り返るつもりはありませんし本の中でも触れていますが、何年も前から何かが起きていて少しずつ狂い始めていました。
まず第一に、非常に多くのプロジェクトマネージャーやスクラムマスターがいます。 そして私たちはカンバンやリーン、LeSS、SAFe、これもあれもと、あらゆるものについて話しています。
そのアイデアはとてもシンプルでそれほど複雑ではありません。ブランド化する必要もなく、ひねったり、回したり、突いたりする必要もありませんでした。
アジャイルはシンプルです。
アジャイルのほとんどはエクストリーム・プログラミングやスクラム、少しのFDDをベースにしたとてもシンプルなアイディアです。
and what I do in then book is I try to boil it back down to its basics I try to go back and say look 20 years ago this is what we thought and I bring up you know Ron Jeffries circle of life which is the core of extreme programming and the core of most of the agile processes like scrum nowadays i scrum has adopted most of the XP practices and just lay it all back out again there are some tweaks and some changes and things that were learned over the years
この本で私が言っていることは、基本に立ち戻って思い返そうということです。 過去にさかのぼって、20年前にはこんなことを考えていたんだよ、と。
そして、エクストリーム・プログラミングの核心であり、スクラムのようなほとんどのアジャイル・プロセスの核心でもある、ロン・ジェフリーの「サークルオブライフ」を取り上げています。
元に戻したり微調整したり変更を行いながら、長い年月をかけて学んできました。
but for most part you know the book just presents the back-to-basics come on guys let's not get all bollixed up with all the nonsense remember what this was
しかし、この本で伝えているのはただ「基本に立ち戻れ」ということです。
ナンセンスなことはやめて、これがなんであったかを思い出してください。
a small technique for small teams to do small projects
that’s about it all right
that's what agile was
that's what agile isthat's what agile always will be
小さなチームが小さなプロジェクトを行うための小さなテクニック
それだけだ
それがアジャイルだった
それがアジャイルだ
アジャイルはこれからもそうであり続けるだろう
a small technique very effective small technique for relatively small teams to do relatively small things
you say well what about big teams and big things well that's not problem agile set out to solve
although I think it is a solved problem I just don't think it’s an agile problem
比較的小さなチームで比較的小さなことをするための小さなテクニックであり、非常に効果的な小さなテクニックです。
あなたは、大きなチームや大きな物事はどうなのかと言いますが、それはアジャイルが解決しようとした問題ではありません。
私はそれ(大きなチームの問題)はすでに解決されており、アジャイルの問題だとは思いません。
感想
ボブおじさんが爆笑していたのは、ケントベック氏に「この本からボブのフラストレーション(つまり欲求不満)が伝わってくるようだ」と賞賛された（イジられた？）のがえらく気に入ったからのようです。
clean agileの本からは、ボブおじさんの温かくて豪快な人柄とシステム開発をもっと良くしたいという情熱が随所から感じられるのですが、この短い動画で発している言葉からはそれがよりシンプルに、でも力強い想いが込められているのが伝わってきました。
私は青字で記した部分が特にグッときていて、何度も繰り返して聞きました。
アジャイルは小さなチームが小さなプロジェクトを行うための小さなテクニック。それ以下でもそれ以上でもない、これからもずっとアジャイルはこうなんだよ、と。
アジャイルに限らずあらゆるものが長い年月の中で変化してしまうものだと思います。それが時代に即した変化だったら起こるべくして起こった変化だと言えるのですが、伝言ゲームのような伝わり方で本質が変わってしまっていることもあります。
今もっている知識や今ある形を過信したり鵜吞みにせず、基本に立ち戻るという行為はとても大切だと思いました。
Clean Agile 基本に立ち戻れ (アスキードワンゴ)
- 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,角谷 信太郎
- 発売日: 2020/10/16
- メディア: Kindle版
認定研修 Agile Testing for the Whole Teamを受けました
3/1(月)～3/3(水)の3日間で認定研修 Agile Testing for the Whole Teamを受けてきました。
まずは参加のきっかけから書くのがよさそうなのですが、RSGT2021の話も絡むので最後にします。
私のAgileTestingレベル
10段階の1くらいでしょうか。 Agileについてはわり勉強していますがテストはほぼ素人です。
QAや品管、テスター、テスト界隈で有名な人達が「より学びたい」という目的をもって参加されている印象でした。私みたいに「すみません、全く知らないので勉強しに来ました」って人はどのくらいいたのかな。
結論から言うとどちらのタイプの人でもたくさんの学びが得られる内容なので、ここはあんまり心配しなくてよさそう。
どんな感じで学ぶのか
研修内容はここに記載していますのでご覧いただければと思います。
3日間で、Janetさん本人の講義を受けながらグループ演習も行います。Janetさんのお話は同時通訳されるので日本語で聞くことができます。さらに各コンテンツの概要は事前にオンライン動画で予習が可能です。*1
私もオンライン動画を見て講習に臨んだのですが、グループ演習でことごとく躓きました。特に2日目のグループ演習はほとんどうまくできなかったです。 ただ同じチームの人達に助けてもらったり川口さんがフォローしてくださるので、落ちこぼれたりはしないので大丈夫*2。
こういうのを体験すると本当に「手を動かして理解する」「わかったことを文字や図に起こせないのは理解してない証拠」というのが身に沁みます。
Whole Team
この研修名にもある"Whole Team"という言葉がすごく大事なメッセージで、テストはテスターの仕事ではなくチーム全体の活動であり、そのためにはチーム全体で対話し、質問し、共通理解を得て行動するのですよってことを研修全体を通じて感じました。
例えば手を動かす演習では、会話が止まると手も止まるという場面がたくさんありました。 逆に「これってどういうこと？」「これはそういう意味じゃなくてこうじゃない？」「あと○分だよ、どうする？」みたいな会話が私達の次のアクションを引き出していて、チーム全体の会話がチームの行動を起こしているのだということを感じました。
もう一つ、Whole Teamが大切だと感じたのが以下のエクササイズです。
Janetさんが図を見せて「この星を書くための点の数はいくつですか？」を質問しました。確かほとんどの人が10と答えていたのですが、中には20とか24とか26という答えもありました*3。
「なぜ答えはバラバラになったと思いますか？それは皆さんが各々、自分が立てた仮説を正しいと思い込んで私に質問しなかったからです。『この点も数えますか？』『ここも含めますか？』という質問があればもっと皆さんの答えは近づいたでしょう。プロジェクトでも同じことがよく起きています。勇気をもって質問してください。」
つまり自分の仮説にそって各々が行動しているうちは共通理解になっていない、すなわち"Whole Team"になれてないということなんですね。
Janetさんのこの言葉を受けて質問と勇気について考えました。
質問と勇気
「勇気をもって質問してください。」
Janetさんの言葉から「なぜ質問には勇気が必要なんだろう。勇気を出さずとも質問することができればもっと簡単に共通理解にたどり着けるのでは？」と思い、Janetさんに質問してみました。
Janetさんは「質問には勇気が必要なんです、だから勇気をもって質問してください。もしその質問をする勇気が出ない人は『その質問をしなかったら未来はどうなるか』を想像してください。そうすればあなたがその質問をするべきかどうかがわかるはずです。」と答えてくださいました。
きっと、質問に対して楽したいという気持ちが自分の中にあったんだと思いますが、"そんなものはないので質問しなかったらどんなヤバいことになるか想像して行動する"っていう答えを聞いて、すごく納得しました。これ一生忘れないと思う*4。
質問しなかったら、さっきの星のエクササイズで起きたようなことがプロジェクトでも起こるってことです。なんだったらすでに起きてます。共通理解はWhole Teamの基盤ですね、大切。
研修の後、ペアプロした話
私はこの頃、実務が設計フェーズに差し掛かっていました。
いつもならここでテストのことまで考えない私ですが、「この設計で今テストを考えてみよう」と思いデシジョンテーブルを書いてみました。
そしたらなんとデシジョンテーブルが爆発しました。
それでテストに詳しい@nemorineに「デシジョンテーブルが爆発したのでたぶんテスト容易性について全然考慮できてないのだけど、テスト容易性が高いってどういう状態のことなの？」と相談しました。
そしたら「よし、今からペアプロしよう！」となり、このブログに書かれていることを実際にペアプロしながらやってみました。
勢い大事！
すると複雑だった１つのメソッドを、相互依存の少ない数個のシンプルなメソッドに変えることができ、テストもAPIテストではなく、単純な数個のUnitTestだけになりました。
「講習で出てきた『テスト自動化ピラミッドの下の方に押し込める』ってのはこういうことだよー」と教えてもらい、なるほど！と腹落ちしました。
手を動かすのほんと最強だな。ねも、ありがとうありがとうー。
参加のきっかけ
RSGT2021のKeynoteでJanetさんの「What’s Testing Got to do with Quality?」を聞きAgileTestingについてもっと勉強したいと思ったのがきっかけです。
Janetさんの講演をきいて「"開発"と"テスト"」ではなく「開発はテスト、テストは開発」だと感じAgileTestingについてきちんと学ぼうと思った次第です。
ただ、この時点では受けるのをだいぶ迷っていました。
理由は仕事とプライベートがかなり忙しいことと、金銭面です。
最終的に受けようと後押ししてくれる出来事となったのが、RSGT2021で受けたコーチズクリニックで、サーバントワークスの長沢さんから受けたアドバイスでした。
コーチズクリニックで相談した話の流れで「自分に投資するということに迷いを感じる、例えばJanetさんの研修も受けたいけど自腹や今の忙しさを考えるとなかなか決断できないんです」という相談をしていて、長沢さんから「投資はそのものにお金を払うのではなくその先の自分にするものだから、その研修を受けた後の自分の姿を想像してみたらいいよ」とアドバイスをもらい、先の自分を考えた結果、よし受けようと決めました。
受けた後の自分が、あらゆる工程でテストのことを今より考えていて、もっとAgileなテストに詳しくなっていて、今より強くなっているのを想像できたからです。
Janetさんも長沢さんも同じ「先を想像して、今の行動を考える」ということをおっしゃっていて、自分の意識の向き先が目の前からその先へ変わりました。
こういう気づきがほんとたまらない。野中先生のおっしゃっている関係性の中で成長するってこういうことなんですよね。
おわりに
研修の中身については他の方もたくさんブログを書いているので参考にしてみてください。
その後assessmentを受けて無事Agile Testing Fellowshipのメンバーになりました。
私は受けてみて本当によかったです。
お世話になったみなさんありがとうございました。
製造業アジャイル勉強会参加レポ：春のオンラインOST＆ライトニングトークビギナー大会
こちらのイベントでLTしてきました。
beyond-hardware-agile.connpass.com
LT枠で参加したモチベーションについてはこんな感じです。
- 楽しそう
- 勢い
- 5分なら気軽だし準備も大変じゃなさそう
- 自分の考えてることをなんか人に話したい気分
- 人前で自分の考えを伝えることのハードルを下げたい
- 友達増やしたい
- いつも楽しませてもらっているので小さい恩返しのつもり
- ここなら失敗したとしても成功として扱ってくれる人の集まりだから、つまり失敗しない
話したこと
恩返しじゃなくて、恩渡し（ペイフォワード）が好きという話をしました。
www.slideshare.net
やってみてどうだった
楽しかった
LT自体は今回が多分3～4回目くらいです。前回はアジャイルジャパンでコミュニティ紹介LTをした時でしょうか。 発表が終わってからDiscordを覗いたらみなさんの反応が温かくてうれしかったです。心地よい場所でLT体験をさせてもらえたことに感謝です*1。
あとオンラインなので緊張しないで話せました。50人以上参加者がいたのでオンサイトだったらもっとグダグダだったかもしれません。
5分という時間
5分は短いので当日のモチベーションとしては気軽に話せます。
どちらかというと5分で話したいことをうまくまとめるほうに頭を使いました。今回のLTはコミュニティとの関わりを前段にもってきたのですがほんとはもっと色々なことを書いていて、発表練習したら前段だけで5分経ちそうだったのでほとんど捨てました。ペイフォワードの部分も最初は映画の話にも触れていたんですがそこもカット。
5分という短い時間で話したいことを最大限に伝えるための「スライドの構成」と「伝わる話し方」についてよい勉強になりました。
こう考えると話す題材によって毎回作戦は変わりそうなので毎回LT初心者であるともいえる気がします。
LTやりたい人がいて嬉しい
今回のLTがきっかけなのかわからないですが「次回やりたいです」って言う人がいて嬉しいかったです。
みんなアジャイル札幌が好きなのがうれしい
自己紹介で「アジャイル札幌から来ました」ってお話をしたら、アジャイル札幌の温かい雰囲気が好きってたくさんの方達が言ってくれてうれしかったなー。きっとこういう人達に囲まれているから温かい場づくりが継続できている気がします。
みんな札幌に来てほしい。連れていきたい美味しいお店がたくさんあるのでツアーやりたい。*2
ぐりとぐら
女性の写真を2枚並べて、それぞれを「利己」と「利他」に見立てる構成にしてたのですが
あー、ぐりとぐらにすればよかった！！！さすがさとりゅーさん、天才か。
次回予告
2021/04/14(水)もLT大会ですー。
分散アジャイルチームについて考える会の参加レポ：スクラム導入支援やコーチ業の成果をメトリクスで確認しようとした話
分散アジャイルチームについて考える会の「スクラム導入支援やコーチ業の成果をメトリクスで確認しようとした話」に参加しました。
distributed-agile-team.connpass.com
RSGTのこのプロポーザルのお話です。
ダイジェスト
- 背景
- そもそもなんでスクラム支援してるんだっけ
- どうやって測定するか？
- メトリクスで気を付けるポイント
困った。からの転換
- 独自の定義を考える方向へ向かう
- アジリティがあがっているということを定義をしたいので、チームがアジリティをあげるための行動ができているか？を図ることにした
- チェックリストを作った
- ロール別に「ロールの責任を果たすための行動がとれているかどうか」を測るチェックリスト
- 難易度別3Step
- 自己評価と他己評価
- あるチームで試してもらいフィードバック、項目のアップデートを繰り返した
- やってみた結果
- 今まで見えてなかったことが見えてきた。
- 自己評価と他己評価の差とか、組織ごとの傾向や強み／弱み
- 収集した結果をもとに組織毎に底上げの仕組みがつくれるのでは
- 今まで見えてなかったことが見えてきた。
- 展開する
- ある分野に関するポイント上位チームの取り組みをヒアリングして他チームに展開
- チーム間の相談ができる環境
- むむむってなったこと
- 今後
- チェックリストの項目OK/NG以外に、障害数や満足度も加えた相関関係を探りたい
感想
本筋から外れるけど、最初「スクラムチームの成果をどうやって測るか」の話をするんだと勘違いしていて、そうではなく「スクラム導入支援やコーチとしての成果をどうやって測るか」の話でした。
いつもタイトルや説明を読まずに食べちゃってすいません。
スクラム導入支援の成果を測定する話ってあんまり聞いたことなかったから、このことについて相関関係がわかるようになったらすごいなぁ。でも取り組みは結構大変そうだった。
「メトリクスで確認しようとした」という話を聞きながら昨日視聴した@ryuzeeさんのセッションに思いを馳せ、スクラムには定量的に測定できないもの、メトリクス化に適さないものも実はたくさんあるって感じたことを思い出していました。
で「メトリクスで測定する」ということから一旦離れて考えてみた時、スクラムチームの支援の成果というは自分がいない状態でもいつものアウトカムを出せるようになっているか、アウトカムが増えているかってことが指標のひとつになると思いました。
その為にはコーチの支援を受ける前の状態も測定しておき比較材料を準備して、支援を受ける前後でチームの改善スピードの変化を計測するとか、前後でおきた変化の数を計測するのは意味がありそうと思いました。
話は変わり、「チェックリストの結果は良い値をたたき出しているのに成果が伴わないことがある」という話に関しては、私は「成果＝方法＋能力」という考えが根底にあるので、スクラムの実施（＝方法）だけではある一定の成果は期待できるもののそこには上限値が存在するんだろうと思いました。
つまり成果を出し続けるにはフレームワークやツールをうまく使うことの他に、個人の能力を伸ばしていく活動が必須なんだと思っています。
なので能力アップにフォーカスした取り組みを加えてみるのも良いかなと思いました。
自分のとこでも計測ちゃんとしたいなー。今は体感的なものに頼ってるもんな。
1日に2回同じセッションを聞いた
このセッションをリアルタイムで聞けなかった人のためにOSTの時間を使って再演してくれたので、私も2回聞きました。
その結果明らかに2回目の方が理解度が上がっていて、ブログもサラサラかけてもう公開できちゃいました！
自分にとっては
- 1回目はインプット作業
- 2回目は前提知識をもっている状態からの咀嚼
となっているようで複数回聞けるのはとても良いのでした。
最近は1つのセッションを2～3回聞いて回数重ねるごとに理解度が上がっていく感覚が快感です。変な遊びを覚えてしまいました。
製造業アジャイル勉強会参加レポ：スクラムにおける「完成」とはなにか？
製造業アジャイル勉強会に参加してきました。
夜打ち合わせが入っていて参加できるか微妙だったんですが、OSTのマーケットプレイスくらいから途中参加できました（家事しながらだったので聞き専状態でしたが）。
beyond-hardware-agile.connpass.com
RSGT2021で@ryuzeeさんが発表された「スクラムにおける「完成」とはなにか？」を視聴しました。 zoom動画公開期日が迫っているのでこういう同時視聴企画ありがたい。*1
ダイジェスト
- スクラムガイド2020の変更点のなかから「完成の定義」について
- インクリメントってなんだ
- プロダクトってなんだ
- 価値を運搬（交換）するもの
- われわれの場合だとソフトウェアなんだけど、ソフトウェアに加えサービスとかサポート、営業とかも含むのでプロダクト＝ソフトウェアではない（プロダク トの一部がソフトウェアではある）。
- 上記の「プロダクト」の定義をふまえて考えた時に、プロダクトバックログには何が含まれるべきか？
- 【本題】完成の定義について考察
- 状態遷移
- PBIが完成の定義を満たした時にインクリメントが誕生する
- PBIが完成の定義を満たさなければPBLに戻す、または削除する
- つまり全てのPBIは完成の定義を満たさなければならないと言える
- どうすれば良いか
- 完成の定義はいつつくる？
- スクラムガイドから考察する（明確に書かれているわけではない）と「スプリント1の開始前までにつくる」が正解っぽい。
- 最初から全部網羅できそうにないので、継続的な手入れが必要。
- 最新をアップデートしつづけて共通理解する。リファイメントの時が良さそう。
- 完成の定義はどうつくる？
- 会社標準があるならそれに則るという考えもあるが、一辺倒に適用すると場合によってはオーバーエンジニアリングになる可能性があるので注意が必要
- 足りないものは足す
- スクラムチームで都度考える。ただし透明性を確保するためになぜそうなったのか説明は必要
- 完成の定義の守り方
- 全員で理解、共通理解することが大事
- 自動化できるものは自動化する
- とはいえ人の力も必要
- レトロスペクティブでアップデート
- まとめ
- 状態遷移
セッションの感想
もともとこのセッションをみたいと思った理由がゴールの定義を理解できていないと何をやっても真のゴールに到達しないので、ゴールの定義を自分の中で明確にしたいという考えが自分の中にあったからなのでした。
「完成の定義」と言われると完成が文書化された状態で定義されているものとイメージしがちだけど、プロダクトは価値を運搬するものでありプロダクト≠ソフトウェアという性質を考慮すると、スプリント1が始まる前までに完成の定義を全網羅することはハードルが相当高いし、スプリントの途中でも変わることを考えるとやる意味とか効果とか微妙だと感じました。
で「透明性、検査、適用」というスクラムの原則に立ち戻り考察すると「完成の定義とは、定義を全網羅した何かを作ることよりもチームやステークホルダーとの共通理解を持ち続けること」ということに行き着くわけですね。
その共通理解の中で自動化できるものは自動化すればよいし、そうでないものはリファイメントやレトロスペクティブでアップデートし共有して最新を共通理解とする必要があります。そしてこれを継続するということ。
最初このセッションのタイトルを見た時に「完成の定義はこう書くべき」という話だと思っていたので、いい意味で裏切られ感がありましたね。
自分ではスクラムガイドからここまで考察できないし、その話を20分でまとめてくれて話してくれるってRSGTってすごくないですか？親切にもほどがありますよね（ほめた）。
おまけ ：プロダクトマネジメントを読んでおいたおかげで前提知識があって聞けたのがよかった。
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
- 作者:Melissa Perri
- 発売日: 2020/10/26
- メディア: 単行本（ソフトカバー）
おまけ：製造業アジャイル勉強会のすきなとこ
今回初参加でしたが、こんなところが気に入ってます
- 製造業アジャイルじゃなくても楽しめるところがすき。
- 途中参加大歓迎なところがすき。
- タイトルの字面で威嚇しぎみなところがすき。
- Discordのボイチャで寝落ちした人にそっとお布団かけてくれるのがすき。
