いづいづブログ

アジャイルコーチになりたい札幌在住SEです。アジャイル札幌スタッフ&ScrumFestSapporo実行委員。Like:パクチー/激辛/牡蠣/猫/初期仏教

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

レビュワーとして関わらせていただいたため「ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方」を発売日より一足早く献本いただきました。わーい。

読者&レビュワーの2つの視点から感想を書きたいと思います。

読者として

ワクワクする

著者はアジャイルサムライで有名なJonathan Rasmusson氏です(以降、ジョナサンと呼ぶことにします)。 本書はジョナサンが在籍していた頃に行っていたSpotifyの取り組みや自身の経験について書かれています。

この本は、読み始めるととてもワクワクします。語り口調で親近感が沸くし、絵が多く表現が面白いのです。この雰囲気はアジャイルサムライと似ていますね!

例えば、"スタートアップは「火星」から来た"、 "エンタープライズ企業は「金星」から来た"という表現は、スタートアップとエンタープライズ企業のそれぞれを取り巻く環境の違いを表した表現なんですが、こう書かれると近未来感が増して、「ユニコーン」という言葉がより一層引き立つ感じがします。こういうのが最後まで飽きずに読める仕組みなんですよね。

これはSpotifyの取り組みの話

私がこの本を読んで感じたことは、ユニコーン企業は成功に向けてのトライをし続けているということです。

Spotifyといえば"Spotifyモデル"が有名ですね。

本書でも、この"Spotify"モデルを軸とした様々な取り組みについて書かれています。

ですが、現在SpotifyではSpotifyモデルを使っていません*1。「なんだ、"Spotify"モデルの話をしておいて、当の企業は使っていないなんて失敗したモデルの話か。」と思われるかもしれませんが、私が大切だと感じたのはこのモデルが良いか悪いかではなく、Spotifyではまずメンバーやチームを信頼するところがスタートだということ*2、模倣ではなくトライした結果から学ぶということ、そして時にはやめることもあるということで、こういった姿勢がいち企業をユニコーンへと成長させるのだと感じました。

"Spotify"モデルに限らずですが、これを模倣すればうまくいくなんてものは私はないと思っています(ソフトウェア開発においては特に)。

なのでSpotifySpotifyモデルを使っているかどうかはあまり重要なことではないと思いました。

皆さんがもし本書をお読みになる際には"Spotify"モデルがどんなものであるか知ると同時に、Spotifyの様々な取り組みの方にもより興味を持って読んでいただけると良いかと思います。

レビュワーとして

今回はレビュワーとして本書の出版前から関わらせていただきました。

まずはこのような貴重な機会を与えてくださった島田さん角谷さんにお礼申し上げます。

レビュワーの人数×フィードバックの数を考えると相当な量だったように思いますが、細かい指摘に対してもより伝わる表現を考えてくださったり、ただひとつの言葉に対しても何度も議論を重ねて選定されていました*3

翻訳とは変換作業ではなく、言葉から著者の想いを想像し読者に伝える架け橋なんだということを間近で感じられたのは最高でした。

微力ながらそのお手伝いができたとすれば大変うれしく思います。

そして他のレビュワーさんの視点や解釈も勉強になりました。

個人的な反省点としては、指摘内容に加えて「こう直したらより良いのでは」というアイディアを一緒に添えたりしていたのですが、素人目線のアドバイスは時として返って混乱させることがあるので、それよりも、指摘箇所に関して「なぜそう思ったか」が明確に伝わるようなフィードバックに全力を注いだほうがレビュワーとしての使命を果たせたような気がしました。よし、次に生かそう。

レビュワーとして参加することは一読者では得られないような学びの機会がたくさんあり、この一冊は私の宝物になりました。

Spotifyで実際に取り組まれていた組織作りのヒントがたくさん書かれていてかつ読みやすいので、興味のある方はぜひご覧になってください!

*1:Spotify’s Failed #SquadGoals

*2:Spotifyでの取り組みはメンバーやチームへの信頼がなければ取り組めないようなことがたくさんある。

*3:P.7の"イテレーションを27回繰り返す"についても、「"27回"という数字にはどういった意味が込められているか」というやりとりがあり、色んな考察が発生して面白かった。最終的にジョナサン本人に問い合わせてもらったところ「特に理由はない」というオチも最高。

"Uncle Bob on Clean Agile the Book: Taking it Back to the Basics"の動画を訳してみた

clean agileを読んでから、著者のRobert C Martin(以降、愛称のボブおじさんと呼びます)について興味をもって色々漁っていたら面白い動画を見つけました。

www.youtube.com

開始0:18くらいのところでボブおじさんがなにかに爆笑しているんだけれども、英語なのでなにがツボっているのかさっぱりわからない。

Youtubeの自動翻訳を使ってみたけど精度が良くなくて、やっぱりさっぱりわからない。

ボブおじさんが何にツボっているのかがどうしても気になって仕方がないので、頑張って訳してみました。手順は以下の通りです。

  1. Youtube英語字幕を付けて英文を拾う
  2. 英文をDeepLで日本語に翻訳
  3. 翻訳した文を読みやすくする

昔はYoutubeの視聴者が翻訳した文章をフィードバックする機能があったみたいですが、廃止されちゃったっぽいですね、残念。

news.yahoo.co.jp

そもそも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ミーティングに参加したんです。

どんなことを期待をしていたのか分かりませんが、大勢の人が集まりこのことについて話をしました。

そのミーティングの中で、どういうわけか魔法が起きました。

正確には覚えていませんが、ホワイトボードに4行の言葉が書かれて、彼らは「これは非常に重要なことだ」となったのです*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

しかし、この本で伝えているのはただ「基本に立ち戻れ」ということです。

ナンセンスなことはやめて、これがなんであったかを思い出してください。

agile

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 is

that'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の本からは、ボブおじさんの温かくて豪快な人柄とシステム開発をもっと良くしたいという情熱が随所から感じられるのですが、この短い動画で発している言葉からはそれがよりシンプルに、でも力強い想いが込められているのが伝わってきました。

私は青字で記した部分が特にグッときていて、何度も繰り返して聞きました。

アジャイルは小さなチームが小さなプロジェクトを行うための小さなテクニック。それ以下でもそれ以上でもない、これからもずっとアジャイルはこうなんだよ、と。

アジャイルに限らずあらゆるものが長い年月の中で変化してしまうものだと思います。それが時代に即した変化だったら起こるべくして起こった変化だと言えるのですが、伝言ゲームのような伝わり方で本質が変わってしまっていることもあります。

今もっている知識や今ある形を過信したり鵜吞みにせず、基本に立ち戻るという行為はとても大切だと思いました。

*1:"agile"が"edge hill"と訳されていて、ググったらエッジヒルの戦いが出てきて困惑。

*2:この"4行"というのはアジャイルソフトウェア開発宣言の4つの価値のことです。アジャイルソフトウェア開発宣言のサイトでは、みんなが集まってホワイトボードを囲んでいる様子の画像が使われていますね。

認定研修 Agile Testing for the Whole Teamを受けました

f:id:izumii-19:20210311132616p:plain
このロゴかわいすぎる

3/1(月)~3/3(水)の3日間で認定研修 Agile Testing for the Whole Teamを受けてきました。

まずは参加のきっかけから書くのがよさそうなのですが、RSGT2021の話も絡むので最後にします。

私のAgileTestingレベル

10段階の1くらいでしょうか。 Agileについてはわり勉強していますがテストはほぼ素人です。

QAや品管、テスター、テスト界隈で有名な人達が「より学びたい」という目的をもって参加されている印象でした。私みたいに「すみません、全く知らないので勉強しに来ました」って人はどのくらいいたのかな。

結論から言うとどちらのタイプの人でもたくさんの学びが得られる内容なので、ここはあんまり心配しなくてよさそう。

どんな感じで学ぶのか

研修内容はここに記載していますのでご覧いただければと思います。

www.jp.agilergo.com

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に「デシジョンテーブルが爆発したのでたぶんテスト容易性について全然考慮できてないのだけど、テスト容易性が高いってどういう状態のことなの?」と相談しました。

そしたら「よし、今からペアプロしよう!」となり、このブログに書かれていることを実際にペアプロしながらやってみました。

勢い大事!

nemorine.hateblo.jp

すると複雑だった1つのメソッドを、相互依存の少ない数個のシンプルなメソッドに変えることができ、テストもAPIテストではなく、単純な数個のUnitTestだけになりました。

「講習で出てきた『テスト自動化ピラミッドの下の方に押し込める』ってのはこういうことだよー」と教えてもらい、なるほど!と腹落ちしました。

手を動かすのほんと最強だな。ねも、ありがとうありがとうー。

参加のきっかけ

RSGT2021のKeynoteでJanetさんの「What’s Testing Got to do with Quality?」を聞きAgileTestingについてもっと勉強したいと思ったのがきっかけです。

confengine.com

Janetさんの講演をきいて「"開発"と"テスト"」ではなく「開発はテスト、テストは開発」だと感じAgileTestingについてきちんと学ぼうと思った次第です。

ただ、この時点では受けるのをだいぶ迷っていました。

理由は仕事とプライベートがかなり忙しいことと、金銭面です。

最終的に受けようと後押ししてくれる出来事となったのが、RSGT2021で受けたコーチズクリニックで、サーバントワークスの長沢さんから受けたアドバイスでした。

コーチズクリニックで相談した話の流れで「自分に投資するということに迷いを感じる、例えばJanetさんの研修も受けたいけど自腹や今の忙しさを考えるとなかなか決断できないんです」という相談をしていて、長沢さんから「投資はそのものにお金を払うのではなくその先の自分にするものだから、その研修を受けた後の自分の姿を想像してみたらいいよ」とアドバイスをもらい、先の自分を考えた結果、よし受けようと決めました。

受けた後の自分が、あらゆる工程でテストのことを今より考えていて、もっとAgileなテストに詳しくなっていて、今より強くなっているのを想像できたからです。

Janetさんも長沢さんも同じ「先を想像して、今の行動を考える」ということをおっしゃっていて、自分の意識の向き先が目の前からその先へ変わりました。

こういう気づきがほんとたまらない。野中先生のおっしゃっている関係性の中で成長するってこういうことなんですよね。

おわりに

研修の中身については他の方もたくさんブログを書いているので参考にしてみてください。

medium.com

ky-yk-d.hatenablog.com

その後assessmentを受けて無事Agile Testing Fellowshipのメンバーになりました。

私は受けてみて本当によかったです。

お世話になったみなさんありがとうございました。

*1:通訳といい事前のオンライン動画の翻訳といい、手厚い準備に大変感謝します!

*2:自分には知らないことがありすぎるなぁってちょっとへこんだりはしてみた。

*3:この星の図にはちょっとした仕掛けがあって、見方によっては20や24などの答えが出うる図になっているのでした。

*4:ちなみにこの日のレビューコメントを覗いていたら、勇気をもって質問するということにグッと来た人た達がたくさんいました。

製造業アジャイル勉強会参加レポ:春のオンラインOST&ライトニングトークビギナー大会

f:id:izumii-19:20210204102155p:plain

こちらのイベントで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枚並べて、それぞれを「利己」と「利他」に見立てる構成にしてたのですが

f:id:izumii-19:20210311095018p:plain

あー、ぐりとぐらにすればよかった!!!さすがさとりゅーさん、天才か。

次回予告

2021/04/14(水)もLT大会ですー。

beyond-hardware-agile.connpass.com

*1:たくさんの仏コールありがとうございました。

*2:アジャイル札幌には「札幌に来てくれたゲストはおいしい食べ物で3kg太らせて帰す」というミッションがあります

分散アジャイルチームについて考える会の参加レポ:スクラム導入支援やコーチ業の成果をメトリクスで確認しようとした話

f:id:izumii-19:20210204231101p:plain

分散アジャイルチームについて考える会の「スクラム導入支援やコーチ業の成果をメトリクスで確認しようとした話」に参加しました。

distributed-agile-team.connpass.com

RSGTのこのプロポーザルのお話です。

confengine.com

ダイジェスト

  • 背景
    • 本部レベルでスクラム支援をやることになったが、その中で支援の成果ってどう測るのか疑問を抱いた
    • スクラムの支援活動と、改善結果の相関関係について知りたくなった
  • そもそもなんでスクラム支援してるんだっけ
    • アジリティをあげるために組織としてスクラムを選択している(スクラムはHowである)
    • アジリティが上がっている状態を定義し、測れるようにしたい
  • どうやって測定するか?
    • 世の中のアジリティを図るための指標を使ってみる?
    • エビデンスベースドマネジメント(EBM
      • これはスクラムチームの成果はわかるがスクラムチームの支援の成果はわからないなぁ。(スクラム支援の効果なのか、チームそのものの能力でアジリティが向上しているのかが識別できない)
  • メトリクスで気を付けるポイント
    • 指標を決めることで部分最適が起こりやすい
    • 計測するのではあれば、複数組み合わせたい
    • EBMの指標がよくなれば組織の目標に向かえているのだろうか?

困った。からの転換

  • 独自の定義を考える方向へ向かう
    • アジリティがあがっているということを定義をしたいので、チームがアジリティをあげるための行動ができているか?を図ることにした
  • チェックリストを作った
    • ロール別に「ロールの責任を果たすための行動がとれているかどうか」を測るチェックリスト
    • 難易度別3Step
    • 自己評価と他己評価
    • あるチームで試してもらいフィードバック、項目のアップデートを繰り返した
  • やってみた結果
    • 今まで見えてなかったことが見えてきた。
      • 自己評価と他己評価の差とか、組織ごとの傾向や強み/弱み
      • 収集した結果をもとに組織毎に底上げの仕組みがつくれるのでは
  • 展開する
    • ある分野に関するポイント上位チームの取り組みをヒアリングして他チームに展開
    • チーム間の相談ができる環境
  • むむむってなったこと
    • チェックリストの結果と成果のギャップ
    • スクラムを実施しているだけで成果をあげるってのは難しいってことかな、テクニカルプラクティスの導入いる?
    • チェックリスト「やりなさい」感をなくしたい
    • ガイド作成
    • チェックリストの目的、観点など作成者の意図を伝えるガイドを作成
    • いつも私たちがつきっきりでできるわけではないのでね
  • 今後
    • チェックリストの項目OK/NG以外に、障害数や満足度も加えた相関関係を探りたい

感想

本筋から外れるけど、最初「スクラムチームの成果をどうやって測るか」の話をするんだと勘違いしていて、そうではなく「スクラム導入支援やコーチとしての成果をどうやって測るか」の話でした。

いつもタイトルや説明を読まずに食べちゃってすいません。

スクラム導入支援の成果を測定する話ってあんまり聞いたことなかったから、このことについて相関関係がわかるようになったらすごいなぁ。でも取り組みは結構大変そうだった。

「メトリクスで確認しようとした」という話を聞きながら昨日視聴した@ryuzeeさんのセッションに思いを馳せ、スクラムには定量的に測定できないもの、メトリクス化に適さないものも実はたくさんあるって感じたことを思い出していました。

で「メトリクスで測定する」ということから一旦離れて考えてみた時、スクラムチームの支援の成果というは自分がいない状態でもいつものアウトカムを出せるようになっているか、アウトカムが増えているかってことが指標のひとつになると思いました。

その為にはコーチの支援を受ける前の状態も測定しておき比較材料を準備して、支援を受ける前後でチームの改善スピードの変化を計測するとか、前後でおきた変化の数を計測するのは意味がありそうと思いました。

話は変わり、「チェックリストの結果は良い値をたたき出しているのに成果が伴わないことがある」という話に関しては、私は「成果=方法+能力」という考えが根底にあるので、スクラムの実施(=方法)だけではある一定の成果は期待できるもののそこには上限値が存在するんだろうと思いました。

つまり成果を出し続けるにはフレームワークやツールをうまく使うことの他に、個人の能力を伸ばしていく活動が必須なんだと思っています。

なので能力アップにフォーカスした取り組みを加えてみるのも良いかなと思いました。

自分のとこでも計測ちゃんとしたいなー。今は体感的なものに頼ってるもんな。

1日に2回同じセッションを聞いた

このセッションをリアルタイムで聞けなかった人のためにOSTの時間を使って再演してくれたので、私も2回聞きました。

その結果明らかに2回目の方が理解度が上がっていて、ブログもサラサラかけてもう公開できちゃいました!

自分にとっては

  • 1回目はインプット作業
  • 2回目は前提知識をもっている状態からの咀嚼

となっているようで複数回聞けるのはとても良いのでした。

最近は1つのセッションを2~3回聞いて回数重ねるごとに理解度が上がっていく感覚が快感です。変な遊びを覚えてしまいました。

製造業アジャイル勉強会参加レポ:スクラムにおける「完成」とはなにか?

f:id:izumii-19:20210204102155p:plain

製造業アジャイル勉強会に参加してきました。

夜打ち合わせが入っていて参加できるか微妙だったんですが、OSTマーケットプレイスくらいから途中参加できました(家事しながらだったので聞き専状態でしたが)。

beyond-hardware-agile.connpass.com

RSGT2021@ryuzeeさんが発表された「スクラムにおける「完成」とはなにか?」を視聴しました。 zoom動画公開期日が迫っているのでこういう同時視聴企画ありがたい。*1

confengine.com

ダイジェスト

  • スクラムガイド2020の変更点のなかから「完成の定義」について
    • 3つの作成物に関するコミットメントが追加された
      • プロダクトバックログのコミットメントは、プロダクトゴール
      • スプリントバックログのコミットメントは、スプリントゴール
      • インクリメントのコミットメントは、完成の定義 ←これ
  • インクリメントってなんだ
    • スクラムガイドにやたら登場する。が説明しづらいし誤解されやすい
    • インクリメントとは、過去に作った員栗目のと今回のスプリントで作ったインクリメントの集合体。 i++ってことだね。
    • スクラムガイドから読み解く「インクリメント」
      • その集合体が全体として機能しないとならない
      • その集合体が全体として利用可能しないとならない
      • その集合体が価値がないとならない
      • 完成の定義を満たさなければならない - プロダクトゴールの実現に寄与するものでなければならない
  • プロダクトってなんだ
    • 価値を運搬(交換)するもの
    • われわれの場合だとソフトウェアなんだけど、ソフトウェアに加えサービスとかサポート、営業とかも含むのでプロダクト=ソフトウェアではない(プロダク トの一部がソフトウェアではある)。
  • 上記の「プロダクト」の定義をふまえて考えた時に、プロダクトバックログには何が含まれるべきか?
    • プロダクトバックログとはプロダクトの改善に必要なものの一覧
      • ソフトウェアの顧客に見える部分
      • ソフトウェアの顧客に見えない部分
      • ソフトウェア以外のもの(インフラとか)
      • 将来の価値をうむもの(検証、学習、実験)
      • その他
    • つまりプロダクトに関するものならなんでもプロダクトバックログになる。なんということでしょう!
  • 【本題】完成の定義について考察
    • 状態遷移
      • PBIが完成の定義を満たした時にインクリメントが誕生する
      • PBIが完成の定義を満たさなければPBLに戻す、または削除する
      • つまり全てのPBIは完成の定義を満たさなければならないと言える
    • どうすれば良いか
      • プロダクトの各領域ごとに完成の定義を定義するようなマトリクス作成する?
      • マトリクスキレイに埋めることよりも、スクラムチームやステークホルダーとの共通理解を作ることが大事。
    • 完成の定義はいつつくる?
      • スクラムガイドから考察する(明確に書かれているわけではない)と「スプリント1の開始前までにつくる」が正解っぽい。
      • 最初から全部網羅できそうにないので、継続的な手入れが必要。
      • 最新をアップデートしつづけて共通理解する。リファイメントの時が良さそう。
    • 完成の定義はどうつくる?
      • 会社標準があるならそれに則るという考えもあるが、一辺倒に適用すると場合によってはオーバーエンジニアリングになる可能性があるので注意が必要
      • 足りないものは足す
      • スクラムチームで都度考える。ただし透明性を確保するためになぜそうなったのか説明は必要
    • 完成の定義の守り方
      • 全員で理解、共通理解することが大事
      • 自動化できるものは自動化する
      • とはいえ人の力も必要
      • レトロスペクティブでアップデート
    • まとめ
      • 完成の定義は定義をまとめた文書ではなく共通理解である。突きつめると「透明性、検査、適用」に立ち戻った考え方になる
      • 共通理解は透明性を担保するために必要不可欠
      • スクラムにおける完成はスクラムでの完成でしかない

セッションの感想

もともとこのセッションをみたいと思った理由がゴールの定義を理解できていないと何をやっても真のゴールに到達しないので、ゴールの定義を自分の中で明確にしたいという考えが自分の中にあったからなのでした。

「完成の定義」と言われると完成が文書化された状態で定義されているものとイメージしがちだけど、プロダクトは価値を運搬するものでありプロダクト≠ソフトウェアという性質を考慮すると、スプリント1が始まる前までに完成の定義を全網羅することはハードルが相当高いし、スプリントの途中でも変わることを考えるとやる意味とか効果とか微妙だと感じました。

で「透明性、検査、適用」というスクラムの原則に立ち戻り考察すると「完成の定義とは、定義を全網羅した何かを作ることよりもチームやステークホルダーとの共通理解を持ち続けること」ということに行き着くわけですね。

その共通理解の中で自動化できるものは自動化すればよいし、そうでないものはリファイメントやレトロスペクティブでアップデートし共有して最新を共通理解とする必要があります。そしてこれを継続するということ。

最初このセッションのタイトルを見た時に「完成の定義はこう書くべき」という話だと思っていたので、いい意味で裏切られ感がありましたね。

自分ではスクラムガイドからここまで考察できないし、その話を20分でまとめてくれて話してくれるってRSGTってすごくないですか?親切にもほどがありますよね(ほめた)。

おまけ プロダクトマネジメントを読んでおいたおかげで前提知識があって聞けたのがよかった。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

  • 作者:Melissa Perri
  • 発売日: 2020/10/26
  • メディア: 単行本(ソフトカバー)

おまけ:製造業アジャイル勉強会のすきなとこ

今回初参加でしたが、こんなところが気に入ってます

  • 製造業アジャイルじゃなくても楽しめるところがすき。
  • 途中参加大歓迎なところがすき。
  • タイトルの字面で威嚇しぎみなところがすき。
  • Discordのボイチャで寝落ちした人にそっとお布団かけてくれるのがすき。

*1:後日Youtube公開はされます

「アジャイルコーチで得た経験知」がささりまくる話だった

f:id:izumii-19:20210116215911p:plain

分散アジャイルチームについて考える会の「アジャイルコーチで得た経験知」に参加しました。

distributed-agile-team.connpass.com

さささんアジャイルコーチと役割を通じて得た経験と、経験から得た学びについてお話してくださいました。

さささんのセッションを聞いて自分がグッときたところをまとめました。

自分らしさ

「めっちゃ明るくてポジティブなアジャイルコーチ」といえばさささん!

さささんはコーチについて「問いで導く第三者」というイメージを持っていたそうですが、このイメージは自分の性に合わなかったそうです。その時「さささんにはさささんに合ったやり方があると思いますよ」とアドバイスされたことが転機となり現在のスタイルになったそうです。

「コーチは問で導くというイメージがあったために、自分の考えをどこまで言っていいのか悩んだ」とセッションの中で話していたのですが、これは私も同じことを悩んでいたのでハッとさせられました。

私も「コーチはこうあれ」というあるべき像を抱いていて、あるべき像と今の自分にギャップがあった時に自分をあるべき像に寄せようとしてしまいます。自分に自信がないので理想像で上書きする方が正しいと思ってしまうんだろうなぁ。

でも、それって自分らしさも失うことなのでは?と思いました。

私がなりたいのは標準的で模範的なコーチではなく「伊藤さんにお願いしたいんだよね」って言ってもらえるような自分らしさを生かしたアジャイルコーチです。

だから、アジャイルコーチとしての理想は持ちつつも、自分の良いところ*1を必要以上に殺さないようにしよう思いました。自分の個性も大切にしたい。

コーチが答えを言うのはNG、誘導はNGという印象が強すぎて、いつ何時もそれをしてはいけないと思いが強くありましたが、でもそれを気にしすぎるあまり一休さんのとんちみたいこと言って混乱させるくらいなら言ってしまえ!

コミュニティ

※ここでの"コミュニティ"は人間関係のこと

さささんに合ったやり方があるはずとアドバイスを受けたことが転機になったと話していていました。

「自分が知っている自分」はごく一部の自分でしかなく、他者と関わる上では「自分が知ってる自分」に加えて「他人が知っている自分」の存在も重要なんじゃないかと思っています*2

でも「他人から見た自分は何者なのか」というのは自分で知りえないことなので、こうやって忖度なくアドバイスをしてくれる人の存在って尊いと思いました。

そして自分のまわりを改めて見渡した時、会社のメンバーやアジャイル札幌の仲間、イベントでつながった人達など良いコミュニティに支えられていると感じました。

自分も誰かにペイフォワードできるような存在になりたい。

境界とエネルギーの話

さささんは「関係性の中にはいろんな境界が存在する」ということを話してくれました。大まかには以下のような感じです。

  • いろんな境界線がある
  • 境界線は意図せず自分が 作っていることもある
  • 境界には抵抗が存在する
  • 境界を越えるときのゆらぎには何かしらの変化を起こすことがある
  • 境界の抵抗を少なくするとエネルギーの流れが良くなる。場合によってはエネルギーが増幅することもある。

さささんの言う「境界の抵抗を少なくすることでエネルギーの流れがよくなったり増幅したりする」ということが、野中先生の「知識を創造するというのは人と人との関係性の中で起こるイノベーション」ということとで、表現は違うけど同じことを言っているぞ!と点と点がつながったとき「おおおっ」って震えました。

知識を創造するってこういうことか!

「関係性の中にはいろんな境界が存在する」というのはめちゃくちゃ大事なことを言ってると思います。

何による境界なのかの違いがわからなければ着地点を見つけることもできないし、自分達の主張ばかりしていれば対立構造になってしまいますが、「いろんな境界が存在する」ということをわかっていれば違って当たり前という観点からものをみることが、まずできるようになるなぁと。

これはアジャイルコーチとしてめちゃくちゃ大事な視点だと思い、チームや組織を観察する時に忘れないようにしようと思いました。

おわりに

自分がアジャイルコーチを目指しているというのもあり、さささんの話はささりまくりました(笹だけに)。 この話を聞いて「自分は無理に何者かになろうとせず、自分のままでよいのかもしれない」と思え良い感じに力が抜けました。

個人的にはこれがRSGT2021で採択されなかったの不思議なくらいいい話だったなー。良い話すぎて、自分だったら人に話すのもったいなくなっちゃいそうなくらい。

今回に限らずですが、コミュニティやイベントってその人が感じた暗黙知を形式化することで、他の人へバトンを渡していく利他的な活動じゃないですか。これってめちゃくちゃ尊いことだなって改めて思いました。

今回もステキなイベントありがとうございました。

*1:自分の良いところってなんだろ。明るくてわりと気配りができるのは良いところだと思うな。今度人に聞いてみたいな。

*2:ジョハリの窓