Regional Scrum Gathering Tokyo 2018に参加してきました。
参加したセッションで印象に残ったことと簡単な所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。
※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。
Day1
Build a Workplace People Love – Just add Joy
資料 : Richard Sheridan - Build a Workplace People Love – Just add Joy // Speaker Deck
印象に残ったこと
- エンジニアの喜びとは「自分の作ったものが、世に出て、誰かに使われること」
- 喜びとは何か？どうなると喜びが悲しみなるのか？
- 柔軟なオフィスレイアウト
- 上司の許可はいらない。好き勝手移動できる
- 騒音も受け入れる
- 赤ちゃんを連れてきてもOK。もともとガヤガヤしているのでたいした問題ではない
- 赤ちゃんのおかげで顧客がやさしくなるという効果も
- チケットは手書き
- 手で書くとコピーペーストしないから自分の言葉で書くし絶対読む
- 学習とは
- 本を読むことではない
- 人から学ぶ、一緒に作業しながら学ぶ
- コミュニケーション
- Slackなどのチャットツールは使わない
- 声が一番、直接会話
- 全社ミーティングはHey Menlow！Hey Rich！のかけ声でさっと実施
- 恐怖と戦い、変化を受け入れるために実験してみよう
- それはうちではうまくいかないといった反応には「実験しましょう」と促す
- 「今日話したことは簡単にできるものではない、しかし必要なことである」
所感
Joy, Inc.の原作者リチャードさんの生講演ということでとても楽しかったです。この本3回くらい読んだので。
内容的には本に書かれていることが多かったのですが本人の口から聞くとまたあらためていろいろと考えさせられました。
仕事する上で「喜びとは何か？どうなると喜びが悲しみなるのか？」については、やはりきちんと定義できていないといけないなと思いました。インセプションデッキで近いことができそうですがあえて「喜び、悲しみ」みたいな項目を入れてもよいかもと思いました。
文化を形成するのにオフィスレイアウトってやっぱ重要だよなとあらためて思いました。柔軟なオフィスレイアウトができるからこそチャットツールを使わないで直接会話が成り立つし、全社ミーティングも成り立つんだろうなあと。
変化を嫌う人、それはうちではうまくいくはずがないという人には「実験しましょう！」と伝え続け、何かを変えていけたらと思いました。
心が折れてもソシキ・カイゼンを続けられるたった一滴の魔法
資料 : 心が折れてもソシキカイゼンを続けられるたった一滴の魔法 // Speaker Deck
印象に残ったこと
- やってきたこと
- 価値観
- 知的好奇心、学び＝良いこと
- 少年サッカーのコーチ経験
- 「大きい相手でも怖くないよ、そこを気にしたところで何も変わらないから 大変だけどね」 by 小学6年生のキャプテン
- オーストラリアでの留学経験
- 雑な文化、考え方がリフレーミングされた
- 続けられるわけ
- 越境なのでボーダーがない
- ギャザリングの場
- 人を喜ばせるために、笑顔にさせるためにわれわれの仕事があるのではないか？
- 見返りを求めずGive＆Giveしている人はいるんじゃないかな？好きな人を増やそう
- 何ごとも自分の選択
- 義務でも犠牲でもない
- 子供の「いいこと考えた。聞きたい？どーしよっかなー」ということを大人になってもやっていいんじゃないの？
所感
私は普通の人ですってことを強調されていましたが相当すごい方だと思います。ここまでめげずに成し遂げられるのは普通の人ではできませんよ。本当に。
心が折れそうなときにこの資料を読み直したいと思います。しかし、仲間を作っていくことってほんと大事ですよね。
本買います。
サーバント・リーダーシップを掘り下げて考えましょう
資料 : サーバント・リーダーシップを掘り下げて考えましょう
印象に残ったこと
- なぜ必要か？
- セルフマネジメントチームを可能にする
- 日本企業への解毒剤となる
- 縦社会、お偉い様への過剰反応など
- 世界を変えたいのであればまずは自分自身が変わることからはじめなさい by ガンジー
- スクラムマスターとサーバントリーダーシップ
- スクラムマスターという役割には権力、肩書きのパワーが付いていない
- チームのパフォーマンスをあげてプロダクトを出すために何でもする
- サーバントリーダーシップは究極のソフトスキル
- スクラムマスターだけでなくメンバー全員にとって役に立つ
- 単に命令するだけなら誰でもできる、説得してやってもらうにはスキルが必要
- チームメンバーから自分の役割に対してフィードバックをもらう
所感
サーバントリーダーシップの話は至るところで出てくるのですが毎回もやもやします。というか、その時々の状況によって常にリーダーシップのあり方は変わり続けるものなので正解なんてないのだと思います。だからもやもやするのかなと。
講演や本などからいろいろな考え方やパターンをインプットしていってその時々の状況に応じてベストな振る舞いができるようになることを目指していきたいと思いました。
以下は雑なメモ。
- タックマンモデルの段階によってはサーバントリーダーシップだけではうまく回らないこともあると思う
- 出来たての組織とかメンバーが大きく変更した組織の場合は最初のうちはトップダウン型のリーダーシップでよいのでは？
- ある程度、組織がレベルアップしたらサーバント型に移ればいいのでは？
- このあたりエラスティックリーダーシップに書いてあったはずなのでまた読もう
ゲーム開発現場の中心で心理的安全性を叫ぶ
資料 : ゲーム開発現場の中心で心理的安全性を叫ぶ [RSGT2018]
印象に残ったこと
前半
- 社内勉強会に参加しづらいと感じる
- 隣の席の先輩が忙しそうだから...
- 社内勉強会を開催したいが
- 業務時間内にやっていいの？
- いちいち報告しないといけないの？
- こんな状態が続くとモチベーションが下がって何やるにも億劫になるという負の循環が起きてしまう
- 勝手にできないと決めつけて言わずに諦めていた
- RSGTへの参加なども言ってみたら会社から許可おりた
- 研修費用もお願いしたら会社から出してもらえた
- 組織の空気を少しずつ変えていく
- LT大会の実施
- 勉強会のハードルを下げる
- コミュニケーションの活性化
- 起きた変化
- イベント参加報告をレポートからLTに
- 自由参加できる勉強会が増えた
- 継続させるために
- スタート前に協力者を探す
- スペシャル会を開催する（大御所を呼ぶなど）
- 地道な宣伝活動
- Chatwork社員雑談部屋
- 退室自由、避難禁止
- 時期を見て情報の発信量をコントロール
- バカなふりする
- 間違っていても雑に発言してよい空気を作る
- もやっとしてることでも言っていいんだ
- やりたいこと、熱量を吐き出していいんだ
- 言える化
- 思い込みを取り除き気軽に発信できる → 相談したり助けてと言える → 問題や間違いを指摘し合える
- 全員を巻き込めずイライラするよりも今一緒に活動している人達で楽しむにはどうすればよいかに集中する
後半
- チームを潰した話
- 心理的安全性とは
- 仲間に背中を預けチャレンジできる状態・状況
- 個人が安心して本気で取り組める
- 話し合える場を作る
- 対等な立場でプロダクトやチームについて話し合える場
- 話すきっかけ、雰囲気作り
- ムードメーカー（この人だったら多少のことを言っても許されるって人）に期待
- 個人との対話も重要
- 個人の不安はふりかえりでは拾えない
- 人への不満は時間の無駄
- チームVS問題という構図になるようにする
- ふりかえりで感謝の言葉が増えてくると良いチームになってくる
所感
前半のお話は今自分が取り組んでいることに近い話だったのでとても共感できましたし参考になりました。イベント参加報告がレポートからLTになったというのはとてもよいですね。言える化という言葉もしっくりきました。言える化の状態作ってもメンバーの入れ替えがあるとまたちょっと戻った感じになるのでその辺どうしているのかどなたかと意見交換したいなあと思いました。
後半のお話からはとにかく対話が大事ということがビシバシと伝わってきました。やはりなんやかんやで対話大事ですよね。がんがん対話していきましょう。
Scrum プロジェクト開始のベストプラクティス
資料 : 【資料公開】Scrumプロジェクト開始のベストプラクティス | Ryuzee.com
印象に残ったこと
- ベストプラクティスはない
- 自分たちで考える
- インセプションデッキも単なるフレームワーク
- 書けば終わりではない
- 目的は共通理解の形成
- 対象領域によって開発手法を選ぶ必要性
- プロジェクトの特性によって本当にスクラムでやるのか考える
- ウオーターフォールの方がうまくいく場合もあることをきちんと考える
- プロダクトオーナーとスクラムマスターは外部とのインターフェイス。外部パートナーをアサインするというのは好ましくない
- リスクが高いチーム体制
- パートナー比率が高い
- 既存チームが強力な指示型で運営されている
- プロジェクトは初期で決まる。人が大事。兼任辞めさせる、経験がある人を集めるなど
- ワーキングアグリーメントを設定する。みなで話し合って働き方を合意しておく
- スクラムの知識レベルを揃える
- 非機能要件はアーキテクチャ、コスト、開発期間に影響を与える
- 技術検証はキリがないので、タイムボックスを設定する。全てを検証するのは無理。結果によってはプロジェクト中止もあり得る
- プラクティスの選択は最初から盛り込みすぎない
- 学習コストが高すぎる
- 後で変えてもよい
- バージョン管理システムの使い方が分からない人に本番コードは書かせない。まずは教育をしっかり行う
- スプリントの期間はスプリントが長い方が難しい。最初は1週間が楽
- 最初のスプリントの開始までに必要な準備期間のお勧めは1か月。最初のスプリントができるかどうかで判断
- 社歴の長い人がスクラムマスターすると社内に知り合いが多いので調整がスムーズにいくことも多い
- Q:スクラムマスターの評価どうすればいいの？
- A:評価いらなくない？個人の成果よりビジネスとしての成果が大事なのでは？それが許されないならチームメンバーにフィードバックしてもらう
所感
最高でした。学びしかないセッションでした。
冒頭でも述べられていたのですがベストプラクティスなんてなく、その時々の状況応じて自分たちで考えていけないということを忘れてはいけません。
質疑応答で出ていたスクラムマスターの評価の話も印象深かったです。個人の評価よりもビジネスとしての成果が大事なのでは？って話はほんとそうだよなあと思いました。
Day2
敢えて属人化せよ！エキスパートの集団こそが最強のチーム
印象に残ったこと
資料が公開されていないのでここはセッション内容のメモをそのまま貼っておきます。
- 環境は大事
- 超人の同僚といつでも議論、協力できる
- よいマネージャーがいる
- 健全な勤務時間
- いつでもリモート作業、会議
- 広い机と速いマシン
- スペックのよいマシンが使えなければ会社に行く意味なくないですか？
- 楽しく作れる条件
- 大きな裁量、権限
- 頼れる仲間
- 上がる給料
- お金大事
- 始めてアメリカに移ったとき
- 今までの習慣でプランニングドキュメント書きますといったらやってもいいけどコード書けっていわれた
- そのドキュメントを作った1週間を無駄にしていることを身をもって知った
- コードが知識の履歴そのもの
- バックログが常にあるのは最初ツラいことだと思っていた → 常にやること(改善出来ること)があるということは良いことだと思えるようになった
- 最初の数回のスプリントをとにかくやってみる
- 口で聞いても分からない、体験することが大事
- App Servicesの開発プロセスの変遷
- DevOps → NoOps → Dev + Support
- お客様からの意見をいかに反映させるか
- お客様が実際にどう使っているか知ることは非常に学びがある
- よいマネージャーを探すのは難しい
- 自分からよいマネージャーを探してそのチームに入るという考え方
- 評価システム
- 5段階評価だったがなくなった
- どうしてもチームがギクシャクする
- こんなに頑張ったのに...なんであいつの方が...とか
- 無くすことで心理的に楽になり働きやすくなった
- 何かに追われている感がなくなった
- 評価基準はimpact
- マネージャーの力量が問われる
- 同僚をどれくらい助けたかなど
- 評価しあう仕組みはとても大事、チームの雰囲気を良くする
- 自分がいい仕事ができたとき、それを助けてくれた人に感謝したくなる
- マネージャのこともレビュー、その上司が評価するのに使う
- マネージャが悪いと部下が逃げる
- ハッカソンの力
- マネージメントの力
- 本当にそんなことやって意味あるの？って人に対して継続的にメッセージを発信していくのが大事
- トップは大きなビジョンをきちんと伝えることが大事
- MSはそれでだいぶ変わった
- ただし時間はかかる。バルマーのときから変わり始めていた
- スイッチを切り替える
- 上司は使うもの
- バグはあって当たり前
- 内部向けの議事録不要
- 意思決定に参加してない人に対してアピールすることはない
- 積極的に発言しないミーティングは出席不要、途中退席可
- 逆に自分が貢献できそうなミーティングには積極的にアプローチする
- スケジュールがもし合わなかったらリスケしてもらう、同じミーティングをもう1度開いてもらうなど
- 逆に自分が貢献できそうなミーティングには積極的にアプローチする
- 属人化したExport集団こそ最強
- 特定の人しかできない作業があるとその人が休んだり辞めると業務が止まってしまう
- それぞれの分野で尖っている人がいてそれをまとめる人、サポートする人がいる
- サッカーチームと一緒
- 尖っている人たちを集めて最強のチームをつくる(属人化を許容。FW、GKと役割が完全に分かれているってこと)
- 彼らがいなくならないような最高の労働環境を整える
- サッカーだと試合に勝つことがゴール、我々はよいプロダクトをつくることがゴール
所感
なんというか本当に素晴らしかったです。会場もスタンディングオベーションが出るんじゃないかくらいの雰囲気でした。
最高の環境で、自分が本当に好きなことに取り組んでいて毎日楽しいんだ！って気持ちが伝わってきました。そんな状態を支えているのがマネージャーであり評価制度であるわけで。これらをまずはしっかりしないと働き方改革なんてうまくいくはずないよね？と改めて思いました。
リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく
資料 : リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく // Speaker Deck
印象に残ったこと
- 何が難しいのか？
- 突き詰めるとコミュニケーションの難しさ
- つまり、コミュニケーションが難しいということ
- お客様と一緒に仕事するときってオフィス離れて働いてますよね？リモートワークは突き詰めるとそれと一緒なのでは
- コミュニケーション
- メインはSlack
- 仕事も雑談も。雑談重要
- テキストだけに頼らない
- 必要員応じて音声、音声のログはwikiなどに共有
- メインはSlack
- テキストコミュニケーションの難しさ
- 情報が少ない
- 情報とは: 声の抑揚、表情/仕草、空気感
- 感情が分からない
- 良質なコミュニケーションと感情は切り離せない
- フラットな感情はやや不機嫌気味に伝わる
- 大げさに絵文字や感嘆符を入れる
- 情報が少ない
- 雑談
- 情報の欠如を補うもの
- 毛づくろいのためのコミュニケーション
所感
自分とだいたい同じ考えだったのでとてもよく理解できました。リモートワークが難しいのではなく結局はコミュニケーションが難しいのですよね、やっぱり。リモートでうまくいかないチームは同じ場所にいても結局うまくいかないと思っています。ただ、オンラインでの議論については工夫と前提条件が必要だとおもっていてその辺りは以下に以前書きました。
スクラムチームとして、妨害リスト（Impediments List ) を運用して見えてきた課題解決方法
資料 : 妨害リストを運用して見えてきた課題解決方法 // Speaker Deck
印象に残ったこと
- 妨害リスト
- 開発チームの進捗を妨げるものを排除する
- 明確に定義されているものではない
- Trelloのボードで運用
- まずはFactに入れる
- 登録される例
- 人やスキルの話
- 環境に関する話
- プロダクトに関する話
- 品質やスタンスの話
- 何が妨げになるのかを俯瞰できる
- チームで共通の課題認識を持てる
- 問題 VS 私たちの構図になる
- いつも出てくる問題の多くはチームの外にある
- 前提を変えない限り大きな改善にならない
- 妨害リストにも透明性
- 誰でも見えるように
- チームの外の人にも見えるようにすることで相談しやすくなる
- 相談するときには経緯が伝わっている
- 更新されなくなる問題
- デイリースプリントで聞いてみる
- 定期的に棚卸しする時間を取る
- ミーティングで出た課題を追加する
- Slackなどで妨害っぽいものがあったら追加を促す
所感
梶原さんの話は以前にも聞いたことがありその時も妨害リストの考えいいなーと思いつつ行動に移せていませんでいた...これを機に今度こそ実際に試してみようと思いました。確かに前提となるような問題ってチームの外にあること多いですよね。そのため透明性を保って誰にでも見られる状態にしておくのは大事ですよね。
「ふりかえり」の始め方と続け方
資料 : 「ふりかえり」の始め方と続け方 // Speaker Deck
印象に残ったこと
- ふりかえりの大前提
- 心理的安全性があること
- 時には参加者を選ぶことも必要
- 状況にあったやり方を選ぶ
- 何でも感でもKPT使えばよいというものではない
- チームの状況は？
- 参加人数は？
- 何にフォーカスする？
- 点ではなく戦でふりかえる
- メトリクスを取る
- アクションを日々の活動に組み入れる
- タスクボードに見える化する
- タスクをする時間を見積もり確保する
所感
ふりかえりってやっぱ難しいなあとつくづく感じました。いろいろ試行錯誤してパターンを増やしてその時のチームや状況に合うものを選択できるようになりたいです。
モヤモヤ女子大生がプロダクトオーナーになったら！
資料なし
印象に残ったこと
- 専門用語はあえて使う必要は無い。分かりやすいものに変える
- 非エンジニアからすると横文字ばかり使われるのは何言ってるか分からなくて怖い
- 自信をつけてもらう
- 開発者との知識差を負い目と感じてしまう
- 勉強会などを開催して武器を持たせる
所感
軽い気持ちで参加したのですが学びが多かったです。自信がない状態だとやはり引け目を感じてなかなか自分の意見も言えず前に出て行けないものです。それを打開するために勉強会をするなどして何かしら武器を持たせてあげるということはとても大事だと思いました。飛び抜けている武器を身につけられなくても言っていることが分かるくらいの知識レベルを持たせてあげるだけでも十分なこともあります。若手の成長を考える上ではこのことはとても役にたちそうです。
あと、エンジニア以外の人と話すときに横文字を連呼するのは本当にやめようと思いました。
Panel - 実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。
資料 :
印象に残ったこと
- 社内政治を攻略する
- うまく組織をハックできるなら組織にとっても良いこと
- 金とアジャイル
- 金の話
- 決裁権限ある人はやっちゃえばいい
- グレーゾーンわざわざ聞くから黒になる
- 決裁権限ある人はやっちゃえばいい
- 政治の話
- 経営層での支援者は必要
- 角を立てずに波風を立てる
- 偉い人くらい手玉に取れなければいけない
所感
いやー世の中けっきょく何をやるにも結局は金と政治だよねーと改めて思いました。いくらうまくプロセス回せたとしてもお金がなければ何もできませんし、お金を得るためには政治が必要なわけですしね。
さいごに
はじめてRSGTに参加しましたがとてもよいイベントでした。
なんというかこのイベント自体が心理的安全性が確保されているというかなんというか。多少の失敗があっても笑って許し合える雰囲気がある感じがしました。議論も至る所で起きますし、初参加者でも違和感なく参加できる感じでした。
内容も意識が高まるものが多く、同じ悩みを抱えている人がどのように課題に取り組んでいるのか、工夫しているのかが知れて勉強になると同時に元気がもらえました。
失敗しても死ぬわけではないのでとりあえずやってみる、実験してみるの精神で今年もやっていこうという気持ちでいっぱいです。
運営の皆様、発表者の皆様、参加者の皆様、本当にありがとうございました！来年も参加したいです！
