Unknown Error

日頃考えていることとか、読んだ本の感想とか

RSGT2019は今まで参加したどのカンファレンスよりも最高だった

1/9~11で行われたRegional Scrum Gathering Tokyo(RSGT)2019に参加してきたのでレポートを書く。

RSGTには初参加だった

多くの人に驚かれたのだが、実はRSGTに参加したのは初。 去年の7月頃、ふとAgileのカンファレンスに参加したことが無いなーとつぶやいたら、梶原さんにRSGTがあるよ!と教えてくださった。

RSGTの存在は知っていたが、毎年なんだかんだ参加出来ておらず、いつも楽しそうだなーと横目で見てるだけだった。 なので、このときは次のRSGTには絶対参加しようと心に決めたのだった。

9月頃、FacebookTwitterAgile/Scrum界隈の方々がRSGT2019のCFPに出したという報告を続々としていた。 システムを見ると、どうやら早く出した方が有利に働くとのこと。 どうせ参加するなら発表した方が絶対楽しいし、世の中のためにもなるので、すぐにCFPを出すことにした。

Regional Scrum Gathering Tokyo 2019 - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた | ConfEngine - Conference Platform

おかげさまで多くの方にイイネをいただき、11月頃、無事アクセプトされた。

前夜祭で繋がった濃い人たち

RSGTのスピーカー及びスポンサーは前夜祭に参加することが出来る。 場所は会場の1Fの中華WANG'S GARDENで、開催中はこの店で毎晩宴会が行われた。

会社からは1人で参加したが、定期的に飲みに行く仲間の洋さんだったり、何度か一緒にイベントをやったことのあるgaoryuさんだったり、Twitter上で緩く繋がりのあったShiibaさんが参加していたので、そこからいろいろな方をご紹介いただいた。 誰か1人でも知り合いがいると、そこから紹介の連鎖がつながるので、普段から緩くでもコミュニティ活動しておくのは大事だなーと感じた。 この日に知り合いになった人と後の3日間も話すような仲になったりして、この前夜祭に行って本当に良かった。

1日目に聞いた発表

Outcome Delivery: delivering what matters

Mobius double-loop learningを使って、どう計測するか、どう成果を出すか、どうデリバリーするか、という3領域を定義し、事例を用いながら説明されていた。 どう計測するか、というのは何を計測すれば成功といえるのかを定義するというところで、そこからなぜやるのか、誰がやるのかも明らかにしていくところだ。 Agileの文脈では、わりとどう実行するかに重きが置かれている分、その前の価値について触れられることが少ないように感じる。 Scrumでいうと、POがどうやってプロダクトバックログを作るのか、というところ。 プロダクトに依って異なる、と言われたらそれまでなんだけれど、それにしてもあまりに野放しなのでは、と思ったりしていた。 実際の開発の現場に落とし込むにはまだ理解が追いついていないので、以下を読んでみようかな。

www.mobiusloop.com

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

天野さん大友さんによる、サイボウズのプロダクト開発チームをどのように改善してきたかの話。

日本でここまで練度の高い開発チームは無いのでは、と思えるぐらい、練度が高いなーという印象を受けた。

例えば、Readyの定義を捨てたという表現。 多くの開発チームはスプリントバックログが終わらないという問題に対処するために、Readyの定義をしっかり作ろうという流れになる。 しかし、サイボウズでは既にそこは通りこしていて、Readyの定義をすっ飛ばしてすぐに開発に着手するという流れになっているとのこと。 後に天野さんryuzeeさんと議論したときも、既にScrumの守破離の守は通り越していて、破になっていると話していた。(と、同時に、Scrumと言う必要性も無い、という話も)

この発表資料を普通のチームが参考にできても、絶対に真似出来ない領域に入っていて、それだけで価値が高いチームを作れているな、と感じた。

運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた

自分の発表。

聴講いただいた方の評判は良く、特にゲームに関係の無かった方々に、ゲーム開発の裏の話が聞けて良かったという言葉をいただけた。

Moreな点としては、並行バージョン開発のWhyをもう少し説明しても良かったのかなということ。 実際に数名からその後質問が来たので、また何かの機会で補足が出来たら、と。*1

ちゃんとやってるのになんかうまくいかないスクラムからの脱出

Shiibaさんさんによる、楽天の改善サポートとして実際に行ったことのお話。

まず何より絵が可愛すぎてやられた。 やった施策についてはむしろScrumを基本に忠実にやったことで、とても納得感が高い。

印象的だったShiibaさんの言葉は、「Scrumは現実を見せる」という表現。 この言葉は、昔からなぜScrumでやるのか、という自分の理由の1つになっている。 Scrumをやるとうまくいかない問題が絶対に出てくるけれど、それはチームとして進化しようとする成長痛のようなもの。 Scrumを批判するのは簡単だけれど、まずは目の前に発生している問題をちゃんと取り除こう。

1日目その他

スポンサーブースにいて呼び込みしたり、セッション外で話したり。 スポンサーブースにいると、EM.FMを聞いているという方が度々来てくださって、そこから議論にも発展して、めちゃくちゃ嬉しかった。

セッション外にはアジャイルコーチや、優秀なボランティアスタッフの方々がいて、ちょっと話すだけでどんどん話が膨れ上がっていく。 話したことが無い人をスポンサーブースに呼び込んで、遊んでもらって、そこから意見交換して、という流れが出来たのは良い流れだった。

2日目に聞いた発表

Learning to Experiment

常日頃から息を吸うように実験をしなければならない、という話。 大事故が起こってから実験を始めるのではなく、あらゆるところに実験を繰り返していかないと、茹でガエルになってしまうぞ、と。

この発表で最も盛り上がったトピックの1つが、見積もりをしない、というもの。 Chrisさんはもうチームで8年間ソフトウェアの見積もりをしていないらしい。 見積もりにどのようなコストがかかるのか、見積もりの副作用とは何か、を隣の人と議論する時間があったのだが、どうも自分は腑に落ちなかった。 というのも、見積もりをすることの弊害については触れているが、見積もりをしないことの弊害については全く触れなかったためだ。

Agile界隈で悪い習慣だと思っているのが、何かの正しさを説明するときに、他方の悪いところを上げる風潮があることだ。 場合による、が口癖なのに、自分の主張を通したいときだけ、一般化して伝えるのは良い行動とは言えない。

Twitterでそんなのフェアじゃないぞーとつぶやいたら、洋さん関さんが拾ってくださって、次の日のOSTで話すことに。

OSTで何を話したかは、後述する。

プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー / Fact based decision making

EM Meetupの主宰者であり、EMFMの最初のゲスト大庭さんさんの発表。 のっけから、「ソフトウェア開発をしている人は合理的にものごとを考えられていると思いがちだが、定量化することでバイアスがかかっていることを理解出来る」とどストレートなボールを投げてきて、さすがだなーなどと。

キャリア決済いらなくね?負債になっていない?という内部の声から、無い方がプロダクト的に本当に幸せになるのかを定量的に判断するためにA/Bテストを用いたという話。 結果、負債だと思っていたものは売上に貢献する大事な機能であることがわかったとのこと。

人は不本意な問題を負債と呼びたがり、楽観バイアス・代表性バイアス・確証バイアスを駆使して、自分たちを騙す。 これを克服するには定量的な評価が大事だ、というのは、1日目のMobius double-loop learningにもあったなーと思いだした。

EMFMでも穏やかな物腰で本質をつく言葉をズバズバと言う姿勢は素晴らしかったので、いつもの大庭さんらしく、なんか頼もしいなーと思ってしまった。

明日現場で使える!とにかく明るいScrum Patterns 活用ワークショップ

SasaさんとIwaoさんによる、Scrum Patternsのワークショップ。 名前は聞いたことがあったが、実際に触れてみたのは初めて。 以前お世話になった、Nikkiさんにオススメされて、アディと一緒に参加してきた。

雰囲気としては、Sasaさんのキャラを全面に押し出したワークショップで、タイトル通り、とにかく明るく笑いが絶えなかった。 一緒のテーブルになったのは、森さん遠藤さんアディ、木村さん、サポーターとしてアジャイルコーチのたくぼんさん。

テーマとしては、HyperproductiveTeamで開発をすることになり、様々な問題に立ち向かうために、Scrum Patternsを適用しようというもの。 黎明編としてチームが出来始めた頃に発生する問題について、野望編として開発が進んでいった頃に発生する問題について、飛翔編としてチームが良くなったらどういう良いことが起こるかについて、Scrum Patternsに当てはめながら考えていった。

森さんがバシバシ仕切って、短時間で成果が出せるようにしていたのはさすがだなーと横目で見ながら、これはどのパターンに入るんだーと考えるのが非常に楽しかった。 このワークショップで一番の収穫は、自分がこれまでやってきたことが知識体系として既にまとまったものがあるという発見が出来たこと。 もっとScrum Patternsを理解出来れば、自分の暗黙知をScrum Patternsを使って形式知化出来るし、自分のやったことのないパターンを学習する機会にもなるなーと感じた。

2日目その他

オープンスペースで、ikikkoさんを捕まえて、組織パターンについて議論していたら、Fun Done Learn(FDL)の話へ。 FDLって連続的に使えるのだろうかーと議論していたら、FDLの創始者の1人である有野さんも加わり、FDLがどういう経緯で作られたのか、どういうことに使えるかの議論に。 議論していたらどんどん人が集まってきて、広がっていくのがまさにギャザリングだ!

森さんのふりかえり実践ワークショップでも、ポジティブな振り返りから始めた方が良いという話があったように、FDLもポジティブな振り返りに利用できそうだなーという印象を受けた。

そのときはまだチラホラとしか付箋が無かったが、次の日、この図は大変なことに・・・

f:id:yunon_phys:20190113112144j:plain

3日目に聞いた発表

OST

いよいよ最終日はOpen Space Technology(OST)。 OSTについては以下の本が参考になる。*2

前日から以下のように席が配置されていて、「え・・・自分の知っているOSTより遥かにでかい・・・」と思ってしまった。

最初にOSTで議論したい内容を、このサークルの中心でみんなの前(300人近い人の前)で発表する、というのがあった。 驚いたのは次々と発表していくこと。結果的に全体で30個近くの議題が集まった。

f:id:yunon_phys:20190113115538p:plain

自分も負けじと、前日のモヤモヤだった、見積もりのメリットについて話し合う場を設けた。

f:id:yunon_phys:20190113123056j:plain

結構モヤモヤしていた人が多かったのか、30人近くが集まり、オープンに議論をした。 見積もりをするメリットについては、大きくは、

  • 顧客への説明のため
  • 計画のため
  • モチベーションのため
  • 仕様の深化・手戻り防止のため

というのが挙げられた。特に多かった意見が前2つで、どちらも誰かしらへの説明のために必要だというものだ。

さらに、途中でChrisさんも来てくださり、及部さんが通訳してくださった。 Chrisさんも見積もりをしないとは言え、1日単位で分割出来るレベルにまでタスクを落とし込んでいて、もし1日単位で終わらなそうであれば、都度顧客と話し合っているとのこと。

ざっくりと、議論の結論としては以下の通りだ。

  • 大前提として、見積もりをコミットメントとされてしまうと弊害が大きくなってしまうので、見積もりを利用する際はステークホルダーとの調整は必須になる
  • 見積もりが必要なとき
    • ステークホルダーと信頼関係が出来ていないとき
    • チームがどれだけのスピードで出来ているかわからないとき
  • 見積もりが不要なとき
    • ステークホルダーと十分信頼関係が出来ていて、ステークホルダーの期待値とチームの開発スピードの認識が合っているとき
    • 見積もりをすることによる弊害が大きくなってきたとき
      • 例: 見積もり時間が開発の邪魔になっているとき

短い時間だったのでまだまだ議論したいことはあったが、見積もりって本当に必要?という問いを真正面から考えることには成功したのではないか。

OSTの外で・・・

見積もりの話をして、次のOSTを探していたら、たまたま大和さんのメイド長のおなやみ相談コーナーを見つけた。 NLP8フレームアウトカムをベースに相談者の洋さんに大和さんが質問していて、おお、これは使えそうだと横で見ていた。

洋さんの相談が終わってから、自分が面白いってたくさん言ってたら、森野さんから*3別のフレームワークで葛藤について考えるワーク(クラウドというらしい)があるからちょっと試してみる?ということになり、やってみることに。 詳細は割愛するが、1時間ぐらいやって、自分の中にあった葛藤が浮き彫りになった。 結果的に自分の葛藤だと思っていたものが、実はそれではなく、別のところにあることがわかったのは大きな発見だった。 1/26にクラウドのワークショップを1日かけてやるみたいなので、もし興味のある方は参加してみていただきたい。

tocfebc.doorkeeper.jp

よなよなエール流 熱狂を生むチームづくり ~8年連続赤字から13年連続増収増益までの軌跡~

大好きなビールであるよなよなエールを作っているヤッホーブルーイング社の社長である井出さんの発表。 とにかく引き込まれる発表内容で、終始笑いっぱなしだった。

発表中に特に強調されていたのが、100社中1社しかやらないトレードオフを選択し続けるということ。 短期的な売上は追わず、熱狂的なファンを生み出すために、一見非合理とも思えることをやり続けることが結果的に会社の強みになる。 例えばヤッホーブルーイング社では、大規模な赤字イベントをやったり、チームづくりのために自分たち用の研修を作り上げ、9期連続で実施したりしているらしい。 こういう取り組みを地道に積み重ねた結果として、13年連続増収増益を上げている、というのは驚きだ。 少なくとも他のビール会社で同じような取り組みをしているのは聞いたことがない。

講演が終わったら井出さんを交えて参加者全員で乾杯したのは良い思い出だ。 当日配られていたよなよなエールの本にも、井出さんのサインをちゃっかりもらい、大満足。

ぷしゅ よなよなエールがお世話になります

ぷしゅ よなよなエールがお世話になります

よなよなエール 350ml×24本

よなよなエール 350ml×24本

まとめ

RSGTは初参加だったが、今まで参加してきたどのカンファレンスよりも本当に楽しすぎた。 その一番根っこにあるのは、Nagaseさんのカンファレンスではなく、ギャザリングである、という言葉だ。

この記事でも、何度も何度もいろいろな人の名前を上げて、どういうコミュニケーションをしたのかを書いてきた。 RSGTはセッションを聞いて帰るのでは、本当の楽しみをしたとは言えない。 隣にいる人に声をかけ、議論をし、その輪を広げていくこと、それがこのカンファレンス、もとい、ギャザリングの醍醐味と言える。

来年も絶対に参加するぞ、と決意表明をするためにこの記事を書いた。 スタッフの皆さま、参加者の皆さま、最高の3日間をどうもありがとうございました。

*1:本ブログでは会社の取り組みについては書かないようにしている

*2:著者の大川さんもいらしていたが、ご挨拶の機会を失ってしまった

*3:後でわかったことだが、このワークのファシリをやってくださった方は認定スクラムマスター研修で一緒だった森野さんの奥さんだった