Regional Scrum Gathering Tokyo 2018 に参加してきました
気分が良いので、1日で2記事書きます。笑
1月11,12日で Regional Scrum Gathering Tokyo 2018 に参加してきました。 イベント自体は13日まであるのですが、2日間で得た学びが多く、これ以上インプットすると頭が弾けそうだったので、2日でやめておきました。
参加したきっかけ
弊社 scouty では複数人開発が始まった2017年10月からスクラム(っぽい)開発を始めています。 開発メンバーはだれもしっかりとしたスクラムでの開発経験がなかったため、始めの一ヶ月半ぐらいスクラムの経験が豊富な外部の方にアドバイザーとして入ってもらっていました。
プロセスの改善を続けて、最近では落ち着いてスクラムな開発ができるようになってきたのですがまだまだ不安な点もあり、ちょうど関わりのあった eureka の @kajinari さんに相談したところ、このイベントを紹介してもらいました。
イベントで学んだこと
聞いていた発表はだいたいTwitterでリアルタイムまとめをしていました。 #RSGT2018 showwin で検索するとみれます。
自分的に良いなと思ったものをいくつか列挙すると、
カンファレンスに行って学んで来たことを社内に持ち込むが、「うちではそれはワークしないよ…」と言われて結局社内に変化が持たされない事が多い。「上手くいくか分からないけど試してみよう！」という強い思いを持ってとりあえず取り組んで見ることが大事。(Run the experiment!) #RSGT2018
— Shogo ITO (@showwin) 2018年1月11日
これは1日目のKeynoteの内容なのですが、会場でも頷いている人が多かった話でした。 今回のイベントでも、これ帰ったら試してみよう！というものがいくつもあった(後述)ので、 うまくいくかわかりませんが自分のチームで試してみたいと思っています。
Run the experiment !!
スクラムを導入した後の働き方変化
— Shogo ITO (@showwin) 2018年1月11日
・残業がほとんどなくなった
・スプリントの計画を達成した後のんびり過ごす (空いた時間でKAIZEN)
・属人化が排除されたので、長期間の休暇が取れるようになった
・ペアやモブワークを行うことが多くなった (難しい課題に複数人で取り組む)
#RSGT2018 #HALL_A
(スレッド機能でつなげてかいていたので、前のツイートも表示されてしまっています)
サイボウズさんで、ウォーターフォールからスクラムに切り替えたことで得られたメリットの話です。 うちのチームではまだまだこれらのメリットを享受できていないので、こうなれるようになりたいなと強く思いました。
・残業がほとんどなくなった
(発表では触れられていませんでしたが)ベロシティが上がっているように見えているけど、実は残業時間が増えているだけだった、ということが起きうるなと自分で勝手に思っていました。
スプリントレビューの時にベロシティの確認と一緒にチーム全体の残業時間を確認してみると面白そうなので取り組んでみます。
・スプリントの計画を達成した後のんびり過ごす (空いた時間でKAIZEN)
に関しては、いろいろと思うことがあります。
私はスタートアップ(scouty)で働いているのですが、完全に同じことをしている競合は今のところいないため、先行優位性を活かして(なるべく早く製品を成熟させ)今のうちにマーケットを取りに行きたいという会社としての思いがあります。
そのため、今スプリントの計画を達成したら、次スプリントのバックログからタスクを引っ張ってきて新しい価値の提供に取り掛かりたいのです。 そしてまた、そうすることでのみチームのベロシティが向上していることが測れるのでは？とも思います。
一方で、その方法ではスプリントの計画を早く達成しても何のアメ(ご褒美)も与えられず、高いモチベーションを保って開発を続けるのは難しいとも感じます。 KAIZEN系のタスクを定義してスプリントに突っ込むのは、"やらされてる感"があってちょっと違うなぁとも思い。なかなか自分の中で納得いく答えが出ません。 (私も"やらされてる感"のある仕事って大嫌いなので、ちょっと空き時間に「ちょっとこのページの描画遅いと思ってたから高速化しといたよ🤤」みたいなことをしたいんですよね。。)
ここは組織の状態によって答えが違う部分な気がするので、POとちゃんと話し合う必要がありそうです。
・ペアやモブワークを行うことが多くなった
この発表に限らず、いろいろな人と話していても、うちでも取り組んでいるよ。という話をよく聞きました。 スクラムガイドには、開発チームの特徴として
• 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
(略)
• 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。
とあり、開発チーム全員が共通なスキルセットを持ち、どのタスクでもこなせることが理想であると書かれています。 そのために、みなさんスキルトランスファーを目的として実施しているようでした。
その他にも複数人で開発することで、タスクを誤解していてレビューされてやり直しになる、のようなことも起きなくなり、レビュー済の状態に近い精度で開発ができるメリットもあるとのことでした。
弊社でも、ネット上の不定形/非構造なデータを扱っていることや、(機械学習まではいかないレベルの)複雑なドメインロジックの実装が多いこともあり、タスクによってはレビュー→差し戻しが多く発生するものがあるため、そういった難易度の高いタスクに関してはペアワークをすることで開発効率があがるかもしれないと思いました。
働く環境は大事。(Microsoft at USの話)
— Shogo ITO (@showwin) 2018年1月12日
会社に広い机、速いマシンがあって、超優秀な社員と直接話せる。みたいなメリットがなければ出社する意味がない。
リモートワークは当然やりたいときにできるし、休暇も 1ヶ月/年 とっている。 #RSGT2018
(サッカーが11人でそれぞれ役割が違うように) 尖っている人たちを集めて最強のチームをつくる(属人化を許容)。 そして彼らがいなくならないような最高の労働環境を整えること。そうすれば良いアイデアが出てきて、良いプロダクトが作れる。 #RSGT2018
— Shogo ITO (@showwin) 2018年1月12日
これについては私も同意で、技術が発達したことにより高い専門性を保つためには、多くの時間を学習につぎ込まないといけない世の中になっていると思います。
個人的には、バックログのうち8~9割ぐらいのタスクについては全員ができ、他プロダクトとの優位性に関わるような1~2割の部分は高い専門性をもった人しかできなくても仕方ないと思っています。 むしろその1~2割ができる稀有な人材を確保できているからこそ、その組織が他に勝てるのではないでしょうか。
弊社では採用基準の一つに「既存のメンバーが持っていない特長(スキル)をもっていること」というものがあります。当然人が増えていくにつれてこの条件を満たすのは難しくなっていくため、どこかでこの条件を諦めないといけなくなるフェーズは来ると思っていますが、なるべく長く続けていき最強のチームを作りたいと思っています。
今回答えがわからなかったところ
私自身 SCRUM BOOT CAMP THE BOOK
• 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
• 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
• 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか？
を共有すると書かれています。「輪になって口頭で共有する」とは書かれていませんが、イベントに参加してこのようにやっているチームが多いように感じました。
弊社では、上記2つについてはデイリースクラム前にSlackで各自文字ベースで報告するようにしており(そもそもKANBANを見ればわかる)、デイリースクラムではBurndownが予定通りかと、障害物がないかの2点のみ確認するようにしています。それにより時間短縮ができ、Burnが予定どおりではなかった場合に、小さなふりかえり/スプリント計画をデイリーで行えています。
デイリースクラムの目的が "スプリントゴールを達成するため" であれば、単なる報告会よりもこちらの方が有効な気がしているのですが、どうなんでしょうか。 答えをお持ちのスクラムマスターな方々 @showwin にツッコミ頂けたら嬉しいです！ (答えを頂いたので最下部に追記しています)
帰ったら試すもの
- スプリントレビューでベロシティと一緒にチーム全体の残業時間を確認する
- 複雑なタスクはペアワークで取り組み、生産性があがるのか、働き方に対する満足度が上がるのか確認する
- スプリントレビューで機能開発タスクとバグ修正タスクの比率を確認する (長期的に見て70%機能開発が理想)
- スクラムイベントのファシリテートを別の人にやってもらう (スクラムマスターがでしゃばりすぎず、開発チームにも主体的に動いてもらうために、一度経験してもらって何か変化があるのかみてみたい)
- POもリファインメントに参加する。(現状開発チームがメインでリファインメントしているが、タスクの定義が曖昧なものもあるので、事前にPOに行ってもらう)
- リリース可能かどうかはPOが判断する。(POが忙しいので、SMの私が品質の確認もしてしまっている状態)
代表がPOをしているのですが、経営に集中させたいので、(エンジニア社員が増えたら)そこからPOを任せる人を別で立てないと、今のままでは役割を十分に果たせないなと感じています。
おわりに
Regional Scrum Gathering Tokyo 2018 の運営に関わっていた皆さん、ありがとうございました！とても勉強になったカンファレンスでした。来年も参加します！
繰り返しになりますが、イベントを紹介してくれた @kajinari さんありがとうございました！！
追記
@ryuzee さんと @haradakiro さんからデイリースクラムについてご意見頂きました。ありがとうございます！
デイリースクラムは再計画のイベントなので、いまのやり方でも大丈夫です。2017/11に改訂された最新のスクラムガイドでは3つの質問はオプションに変わってます。ガイドからはHowっぽいものが除かれてっていますね
— Ryutaro YOSHIBA (@ryuzee) 2018年1月13日
進捗を確認するよりも、より良いやり方がないか検討する会なので、全員いる必要があるんです。進捗確認をSlackとかで事前に出来てると、より良い方法を探すに集中できていいですね。
— HARADA Kiro (@haradakiro) 2018年1月13日
上で私が参照していたのは、2016年7月版のスクラムガイドでしたが、2017年11月にスクラムガイドの改訂があったようです。
2017年11月版では、デイリースクラムの章に以下のような説明がありました。
デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。
デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。たとえば、以下のような例を使用するといいだろう。
• 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
• 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
• 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
中身の例として上の3つが提案されている形になっており、 "開発チームがスプリントゴールを達成する可能性を最適化する" 方向を向いていれば他の方法でも問題ないようでした。
