#RSGT2019 2日目の感想

はじめに

2018/01/10(木)にRSGT2109の2日目に参加してきました!
2日目もセッション中心に視聴し、
引き続きメモした内容と自分が感じた感想をアウトプットしたいと思います。

RSGTについてはこちら。
2019.scrumgatheringtokyo.org

目次

全体的な気づき

全体通して特にこれがよかったなぁと思ったことを先にまとめました。
セッション数が多いので、全部みていくのも(自分が見返すのも)ツライと思ったので…。

セッションの資料や詳細がみたい方はそれぞれみていただければと思います。

表面上は全てうまくいっているように見えて…

Keynoteより。

表面上は全てうまくいっているように見えると、
何も変えなくて(改善しなくて)良いという意見や結論になってしまうことがある。
何かを変えたい(始めたい)時に別にいま困ってないしとか、
問題ないから別に良くない?とか。

ですが、開発に伴う環境は変化しています。
そして競合他社も変わっているかもしれないし、
知らないところで新たな競合が生まれていたり、
メイン事業の分野が突然無くなってしまうかもしれません。

常に環境にあわせて変わっていかなければ、いけないはず。

見積もりをなくす

なぜ見積もりをなくすのか?

見積もりは何度もやってきているはず。
ITエンジニアなら何度もやっていることは自動化したいよね?
見積もりは必須の作業だと、繰り返しの作業だといっているのに、なぜ自動化しない…?

そして単純に時間がかかる。
見積もりを出す時間もそうだし、見積もりを維持するコスト、
遅れた見積もりを無理して挽回するコスト、見積もりを管理するコスト…。

だったら、見積もりしなくても毎日リリースして価値を届けるチームが良いんじゃないか?
ということでした。

実際、私はいまのチームでは見積もりをやっていません。
なので納期(締切)もありません。
完成したらリリースするだけです。

ただ、本心を言えばダラダラやっているので、
期限があったほうがもっとアウトプットが出るかなぁとは思っています。

A vs BではなくA + Bでよい解決策を模索する

森さんのセッションから。

振り返りに限った話ではないですが、
自分が他人と意見が食い違った時、
つい自分の意見の方が正しいと思う!という押し付けをしてしまいがちでした。

本質は別に自分の意見を通すことが大事ではないので、
よりよい方策であるA + B = Xが生まれるようにしたほうが良いのかなと。
自分の意見を押し通す努力するなら、Xが生まれる努力をしたほうが良いよね。

チーム開発はチームビルディングが大事。

Yosuke Otaさんのセッションから。

個人的な印象として開発を始める前から、
チームビルディングされるなんてことは無いと思っていました。
開発しながらビルドされていくものなのかなぁと。

お話を聞いた感じだと最初からそこを意識して、
チームが一体になるように心を砕く必要があるのだと感じました。
そこで躓いたら、周りの力を借りてチームビルディングするのが良いというのも、
前回のRSGTがキッカケだったと聞いてなるほど、と腹落ち。

もっと上手い方法があったんじゃないか?ということを認めること

及部さんのセッションから。

これは言葉とか学びというよりも、単にすげぇ…と思っただけなのですが…。
今まで良いと思っていた考えよりも、もっと良い考えが見つかったので、
「思考停止していた部分がありました」(うろ覚え)というようなことを言った時です。

このとき、ちゃんとまっすぐを前を向いて堂々とそれを喋る姿にびっくりしました。

自らの改善点を素直に認めるのはともかく、
あれだけの人数の前で登壇していて、
眼の前にPCがあったらそれに目を落とすような感じで流すこともできました。
それでもちゃんとまっすぐ前を喋っていることに、妙に驚きと感動を覚えてしまいました。

まぁ、ここまで書いてたまたま前を向いただけだったかも…とも思いましたが、
偶然でも感動したことは事実なので書いておきます。
見習いたい。

感想

参加したセッションで気になったことと、
そのセッションの感想を書いていきます。
詳細にセッションの内容を説明しているわけではないので悪しからず…。

Welcome Note

ほぼ1日目と同じだったので省略します。
1日目を読んでください。
(スポンサーセッションがあったけどメモしてなかった…w)

Keynote　Chris Lucian - Learning to Experiment

全体的に、実験していこう、変わっていこうというような内容でした。

Chrisさんはモブプロを最初に始めたHunter Industriesのエンジニアさん。
いつも変化(改善)は緊急事態から起こる。
だけど、緊急事態が無くてもプロセスは変えていけるのではないか?
というところから実験の話へ。

自らの失敗談を含めた実験の話は非常に参考になりました。
いくつか上げると、
ビッグバンアプローチは上手くいかない(事が多い)。
いっきに全部変えるのはハードルが高いですよね。
稀にうまくいく場合もありますが、それは生存バイアスな気もする。

それから自己満足の危険性。
相手を変えようとしない。
透明性を高めることで相手に変化するきっかけを作る。
相手はコントロールできないので自分のアウトプットを変えて(増やして)透明性を高めて、
相手に期待するということかな。

メモし忘れたか、別のセッションだったかもしれないけど、
相手に期待しすぎるのもよくないので、相手が変わらなくても気にしない。
それよりも、自分のやるべきことをやっていくということも言っていた気がします。

気づきにも書いた見積もりの話は3日目にOpen Space Technologyという、
お題を決めて参加者で自由に話し合う場があるので、そこで話をしてみたいと思っています。

非常に分かりやすく、かつ、学びが多い内容でした。
スクラムや開発をする上では当たり前のことを言っているだけだと思いますが、
それがやれていないのが現在よくある開発なんだと思います。

そのために日々実験して、緊急事態がなくてもプロセスを変えていきたいですね。

Kazuki Mori - Effective Retrospective / とにかく楽しいふりかえり

資料。

Effective Retrospective、効果的な振り返りという感じかな。
仕事でも個人的にも振り返りはしているけど、
振り返りの方法をちゃんと考えたことはなかったので非常に刺さるセッションでした。
(KPTかYWTかぐらいでしょ?みたいな…)

仕事で一緒に振り返りをしているメンバーに、
まず振り返りの3ステップ(立ち止まる、チームを成長させる、プロセスをカイゼンする)を伝えるところからやりたいと思います。

特にすぐ試したいなと思ったのは、場作り。
心理的、物理的な場作りは意識するだけでできることが多いですし、
また意識しないとできないことは習慣化したほうが絶対良いと思うので。
アクティビティと音楽はすぐやれそうだし、楽しそうなのでやります。

あと、いままではなんとなく「そろそろ振り返りやるー?」みたいな感じでダラっとやってたので、
意識的に場づくりするということもやりたい。

タイトル通り非常に楽しいセッションでした!
開始前の音楽や、身振り手振りがまさに意識的に場作りしていることなのかなぁと思ったり。

セッション中にあったYWT振り返りはYWTではないけどプログに書いているので、
最終日にYWTでRSGT2019そのものを振り返ろうと思います。

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

資料。

負債と化してしまっている機能を、A/Bテストで本当に負債なのか確認した話。
A/Bテストのやり方の話ではなく、
意思決定に定量的なデータが用いられているか?という部分が主眼な感じでした。

グッと来たのは自分たちを騙さないということ。
エンジニアは常に合理的に考えている、と思い込んでいませんか?
以外と「この機能だれが使うんだよ」とか、
「このソースは汚いから時間をかけてもリファクタすべき!」みたいになります。

ですが、本当はその機能よく使われているのでは?とか、
そのソースめったに使わない機能かつ重要度が低いので費用対効果が薄いのでは?とか、ありますよね?

だからこそ定量的なデータで意思決定する、というのは非常に刺さる話でした。
特に資料P.62の楽観バイアス、代表制バイアス、確証バイアスには気をつけたいです。

asato Ishigaki - プロダクトオーナーとして『開発プロセス』を思考せよ〜EBM(Evidence-Based Management)を軸とした『プロセスの見える化』と『ムダからの解放』を実践したインパクトについて〜

資料。

VSM(バリュー・ストリーム・マップ)で可視化された、
POとのやり取りを簡略化してリリースまでのリードタイムを大幅に削減した話。

個人的にはEBM(エビデンスベース・マネジメント)というのが初めて知った概念だったので、興味深い内容でした。
計測方法まで含んだ、ビジネス価値が生み出されているかをフォーカスするための概念。

よく実装とテストが終わればリリースは放置されることが多かったので、
プロセス改善としてはそういった部分に目を向ける必要があると気づきがありました。

Yosuke Ota - スクラム1年生のチームが全員でRSGT2018に参加してわかったチーム開発、はじめの一歩

資料が見つからず…。

スクラム1年生向けに2年生からの振り返りを含む話。
私はいまスクラムをやっておらずやる予定もありませんが、
これからやるかもしれない立場からすると非常にありがたいセッションでした。

いろいろやった結果、チームで踏み込んで仕組みで改善することができるようになった、
ということをおっしゃっていましたが、
「完了の条件をしっかり」を踏み込んできちっと定義できるようになったと言うことですね。

聞いていて笑ってしまいましたが、自分でもやってそう。
(バグってるからなんとかする、とか…w)

スクラムを知らない人も、同じようなよちよち歩きの人も、マスターな人も、
非常に共感できる良いセッションだったんじゃないかなーと思います!
素晴らしい内容でした!

Atsuko Tsujioka - リーダーシップを一度捨ててチームの輪の中に置いた話

資料。

RSGT2019 リーダーシップを一度捨ててチームの輪の中に置いた話 from Atsuko Tsujioka

www.slideshare.net

いまのところ個人的に一番グッときたセッションでした!
もう転職しようかなー?というところから、
「それってお客様のためですか?」という言葉を聞いて一念発起、
楽しく開発できるところまで持っていったのに本当に感動しました。

プラクティス的なところは資料を読んでいただくとしてw
個人的に刺さったのはリーダーシップを捨ててまで、
お客様のために、リーダーの仕事ってなんだろうと考えて行動したこと。
この覚悟がスゴイなぁと思って、非常に刺さったのです。

セッション後の短い休憩時間で見かけたので、
とっ捕まえてこの覚悟について聞いてみました。

質問:正直、しんどかったのでは?覚悟はあったんですか?
答え:お客様のためにやりたかったからやった
　　失敗してもいいや(資料にもありますが評価を気にしない)

質問:お客様のために、というと俺は技術をやりたいんだ!っていう人いませんでした?
答え:いたけど、自分も技術好きだったから、
　　一緒に技術ができるようにやっていこうって。
　　どうしても合わない人は諦めた。

この話を聞いていて、やはり自分にはチームをより良くする覚悟が足りないなぁと。
つい今やっているプロダクト、チーム、会社に興味がないから、そんなに頑張らないと、
言い訳してしまいます(ソレはソレで正しいとも思いますが…)

本当に興味が無いなら、とことんまでやるのもアリだよなぁとも思ったり…。
その辺、自分は楽をしていると言うか、覚悟が無いのかなぁとも思っています。
(他にやりたい事があるのも事実なので難しいところ…)

明日の3日目でタイミングが合えば、また具体的なお話を聞きたいところ。
振り返りで本音トークとかのプラクティスをやり始めた辺のチームの話とか聞きたい。

Takao Oyobe - 学習する／Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー

楽天新入社員の皆様(長かったので別記載ですいません…)
Haruna Iizuka / Masahiko Morita / Megumi Tsuchihashi / Ryota Nagatomo / Saki Ota / Saki Tanaka / Takuya Uchida / Tsubasa Kanemura / Yuki Misumi

資料。

楽天新入社員に突然プログラミング研修をすることになり、
実際にやったところからの学びについて。

新入社員の皆さんの学習速度にただ驚くのと同時に、
ちゃんとプラクティスを使えばものは作れるんだ、というある種の証明にハッとしました。
つまり(重々承知していますが)上手く開発できないのは、
プラクティス(道具)が悪いのではなくやはりそれを使う人間にあるのです。

やはり使い方や、使うタイミング、いわゆる用法・用量が良くないケースがあるのかなと。
その辺をUnlearnしてより成長していきたいと思います。

個人的にチームLe Monde(新入社員さんの研修チームのひとつ)の、
話し合いが長いのにタイムボックスを入れたのは良いプラクティスだと思ったので真似したい。
ついつい長く喋りすぎてしまうので…。
(ブログも長い…)

Unlearnについて、経験則的に上手くいかなさそうだからUnlearnしてちゃんと考えてみようという感じでしたが、
逆に経験則的に上手くいきそうだからこれで行こう!というときも気をつけたほうが良いなと思いました。

特に、無意識にいつもの行動を選択してしまい、改善する余地もなくやり続けてしまうと思ったので。
振り返りなどのタイミングになるかもしれませんが、
日々やっていることもちゃんと棚卸ししてUnlearnしたほうが良いと思いました。

毎回、及部さんのセッションは多大な刺激を受けるのですが、
今回も素晴らしかったです!

おわりに

また長くなりました…w

スクラムって概要だけ分かった(気になっていて)チームがやらないから勉強しなくていいやって感じだったんですが、
Unlearnしてみるとスクラムガイドすら読んだこと無いなぁと気づきました。
スクラムをやるかどうかはともかく、
これだけ学びがあるイベントの原典なのでキチンと勉強したいと思います。

まだ3日目もあるのでもっといろいろ吸収して最高の3日間にしたいです!
明日はOpen Space Technologyがあるので、
受動的ではなく能動的にいろいろ動いて行く所存。

最終日も楽しむ!