経理部がRSGT2019に参加してみた
はじめに
今回が初ブログなので、はじめに簡単な自己紹介をしようと思います。
2018年春に新卒で楽天株式会社に入社、6ヵ月に及ぶ最&高なプログラミング研修を経て、現在はプログラミングと一番無縁といっても過言ではない経理部で経費の管理についての勉強を行っています。(実際は配属された部署はRPAなどを扱っていたため、ものすごくプログラミングの研修が生きているのはここだけの話。)
今回は、及部さんや会社同期の誘いがあり、新卒一年目ながらRSGT2019に登壇し、お話をさせていただいたので、遅ればせながら、参加してみての感想などを思いのままに述べていければなと思います。
RSGT2019
とても熱量のあるイベントで参加者同士の距離が近く、人に話しかけに行くのが苦手な自分でもこのギャザリングを通じて様々な人とかかわることができました。ノベルティもものすごく豪華で、チケットが即完売するのも頷けます。
(来年は会場が大きくなるそうですがきっと即完売してしまうんだろうなあ…。)
学習する/Unlearnするチームへ ー新卒研修とスクラムとモブプログラミング
資料: 学習する/Unlearnするチームへ #RSGT2019 / Learning and Unlearning Team - Speaker Deck
自分たちは二日目のトリとして、上記のようなセッションを行いました。聴きにいらしてくださった方、誠にありがとうございます。
自分たちよりも長年スクラムを行ってきている人々にたかが数か月の経験で学んだことを話すことに一抹の不安がありましたが、川口さん、及部さん、きょんさんら最強メンター陣にたくさんのことを教わったこの数か月はここの会場にいる誰よりも濃いものでありかつ、学びが大きかったという自信のもと、練習の成果もあり、本番は慌てふためくことなくお話しすることができたのかなと思います。
スピーカールームで一日中何回も何回も予行練習して完璧に発表した楽天の新卒は今回のMVPだと思う。私も次なんか発表するときは人前だろうがちゃんと声出して練習しよ。すんごい刺激もらった。負けないぞーR18!#RSGT2019
— Atsuko Tsujioka (@kappezoro) January 10, 2019
「ほかのどんなチームより自分のチームが最高のチームだ」って言えるのは本当にいいチームだったんだろうな #RSGT2019 #hall_a
— futabooo (@futabooo) January 10, 2019
発表中も泣きそうでしたが、発表後もこのようなありがたいお言葉をたくさんいただき、本当に感動しまた泣きそうになりました。自分たちの言葉はこんなにも影響力があることも同時に深く実感しました。また、
— ゆーじ (@ug23_) January 10, 2019
自分のパートで一番伝えたいことが伝わっていてよかったです笑
再演依頼も来ているので今度はもっとブラッシュアップしたものを見せたいなあ…。
各セッションに対する学びや感想
もちろん、自分たちのセッションだけでなく、自分が参加した二日間で多くのセッションに参加しました。
一日目
Outcome Delivery: delivering what matters
印象に残ったこと
- 学びは本や経験(体験)などによって行うことができる
- その一方で、学びは騒音や邪魔、恐れ、疲労等が妨げになる
- デザイン思考・・・「正しい」ものを作る→分析等で行き詰まる可能性がある
- アジャイル ・・・「正しく」ものを作る→間違ったものを素早く作ってしまう可能性がある
- そのため、「デザイン思考」と「アジャイル」のバランスが大事
- メビウスの輪・・・「何が問題で、なぜそれが問題なのか」を特定し、「それをどのように届けるか」を選択し、「実際に実験を遂行し、顧客に価値を届けられたかを計測する」を繰り返すことで正しいものを正しく作ることができる
- 「怠け」は最短で目的を達成しようとする表れなので悪ではなくむしろ良い
感想
最初にコーヒー体験を描いてしまったのは僕だけじゃないはず…。
そのようなことは置いておいて、この話を聞いて、思ったことは自分たちの研修時のプロダクトの作り方がまさに「正しい」ものを作ろうと意気込むあまり、分析などで行き詰まってしまったことです。顧客が本当に求めているものは何かを調査するためにとにかくいろんな人にインタビューを重ねた結果、毎回のようにプロダクトのコンセプトがぐらついた自分たちの過去がよみがえってきました。しかし、この悪戦苦闘がなければ、自分たちが納得するプロダクトは作れなかったことを考えると、分析に行き詰まってしまった際に二つのバランスをとるために何をしたらよいのかは気になります。(セッションの中に答えがあった場合は教えていただければ幸いです。)
あとなによりも自分がデザイン思考に関してあまりにも何も知らないことを痛感しました。デザイン思考入門はこの一冊のような本やおすすめの一冊があればぜひ教えていただきたいです。
チームワークの会社で最高のプロダクトを目指すチームができるまで -強くてスケールするチームの作り方-
資料: チームワークの会社で最高のプロダクトを目指すチームができるまで / RSGT2019 - Speaker Deck
印象に残ったこと
<Cybozuの特徴>
- 社内情報の透明度がとても高く、トップの意思決定の経緯まで見ることができ、むしろ情報に溺れるレベル
- リモートチームなのに交流が盛んでリモートな状況を感じさせない
- 巻き込み力の高い人の多さ
- 社外の有識者のノウハウを社内の関係者に一気にインストールする
<スプリントのイベントについて>
- ただプロダクトを作るだけないビジネスサイドにも通じるエンジニアになるのが目的
- レトロスペクティブは問題共有の場ではなく、仮説を立て、それを検証する場
- KPTのTはコードを書くのと同じくらい重要で、TをDoneに落とし込めるようなタスク化をすることが大事
- プランニングは翌週のタスクに関して事前調査を行うタスクを廃止、品質を向上する時間の枠も廃止した
<現状>
感想
僕にとってはチームワークでおなじみのCybozuのチームビルディング、最高に興味ある #RSGT2019
— きもりた (@mori_PYON_miwa) January 9, 2019
というようにこのセッションに対する期待はとても高いものでした。「Cybozu Days 2018」にもひそかに参加しており、僕はCybozuの1ファンなのかもしれません笑
このようにワクワクしながらセッションに参加したのですが、新発見が多く、とても有意義なものになりました。とりわけ、TryをDoneすることのできるタスクを落とし込むことは普段あまり意識してなかったうえに自分でもすぐできることだと感じましたので、現在実践中です。
スピーカーの天野さんとは川口さんの紹介もあり、外でお話しさせていただきました。Cybozuではエンジニアだけでなく、人事部などのビジネス職でもスクラムやモブワークを実践している話を伺い、決してスクラムはエンジニアのためのツールではなく、チームを進化させ、仕事を楽しく効率的に進めるためのツールであることを実感しました。
採用チームがスクラムに取り組んでもうすぐ1年。最初はなんちゃってカンバンから始めたけど、より本格的なスクラム化してからどんどん前進してる。開発手法をビジネス側で実行する難しさを色々感じたけど、今は毎週少しずつ良くなっている感覚が凄い楽しい。
— 庭屋 一浩/Kazuhiro Niwaya (@kazu_niwaya) November 29, 2018
RSGTをTwitterで振り返って、いろいろな方のTweetを眺めていたら遭遇。一度お話を伺ってみたい…。
行動分析学に基づくScrumの導入
印象に残ったこと
- スクラムの導入は難しいのは生まれてくる課題が状況によって異なるから
- 昔は工学の面が強く使われる側をどう使うかということに主眼が置かれていたが、アジャイルは人を人として扱うため、個人や組織、プロダクトはそれぞれ違う。それゆえにプロセスに従うのでは柔軟性に欠けてしまう。
- 行動分析学=状況を考慮して理想を探索する方法
- 行動分析学の特徴として、何かができないことを意志の弱さや能力のせいにしない
- ABC分析(Antecedent(先行事象)→Behavior(行動)→Consequence(後続事象))のフレームワークで人の行動を分析する
- 行動随伴性にはその行動を強化する刺激である「好子」とその行動を弱化する刺激の「嫌子」が存在する
- 確率的な「好子」の方が確実に出現する「好子」よりも特定の行動を強化する
- 遠い将来の「好子」は特定の行動を強化する力が弱い
- 「嫌子」を出現させるとマネジメント効果は高いが、モチベーションの低下を招く
- チームを機能させるには機能しない原因である可視化できる「標的行動」を特定し、個人の好子や嫌子を考慮し、後続事象をデザインする必要がある
感想
このセッション全体を通じて、行動分析学は面白い学問だなと感じました。とりわけその特徴である何かができないことを意志の弱さや能力のせいにしない点は大変興味深いものでした。自分はよく何かができなかったら能力不足を考えるのですが、きっともう数段行動分析学にのっとって掘り下げたらなにか別の原因が出てくるのでしょうか。こちらに関してもおすすめの一冊等があれば教えていただきたいです。
行動分析学も興味深いものでしたが、このセッションを聞いて、「スクラムって難しいものなんだ」ということを感じました。我々は目の前にスクラムという選択肢しかなかったため、スクラムを通じてどれだけ良いプロダクトを作るかに注力していましたが、実際はそのような環境にいることがもはや恵まれていることなんだな、と感じました。
超Scrum入門〜未完成フラクタルと15minSprint〜
資料: 超Scrum入門〜未完成フラクタルと15minSprint〜 #RSGT2019 - Speaker Deck
印象に残ったこと
- 15min Sprintはモブ or ペア or ソロの強制的な切り替えのタイミング
- Krebs Cycle of Creativity
- 新卒は「Engineering」や「Design」をあまり知らないためにサイクルのバランスが良く、基盤チームは「Engineering」や「Design」に詳しくなるがあまり、「Art」や「Science」に関して、おろそかになってしまい、結果サイクルのバランスが悪くなってしまったという仮説
- 素晴らしいプラクティスも一つの目的に従属すると生き生きしない
- 「うまくいく」と「楽しい」は直交しており、どちらかだけを求めるのではなく、両方を追い求める
- 恐れずに自然に生き、世界の美しさに触れよう!
感想
研修時に開発からまさかりの投げ方までとてもお世話になったきょんさんのセッション。15分スプリントでモブかペアかソロかを集まって考え、手法を都度切り替えるのは問題に対してどの手法が最適かを素早いサイクルで実験できる点が良いのかなと思いました。どの手法にも良し悪しがあり、それを組み合わせることで「うまくいく」ようにしているのかと。Krebs Cycle of Creativityに関しては以下のウェブサイトで少し知見を補いました。(すべては読み切れていない)
このサイトに記載されている「Art」や「Science」の定義を読むと、このサイクルのバランスをとることは、メビウスの輪の左側と右側のバランスをとることにとても似ているなあと感じました。問題を特定し、それを解決手段を決め、効果を測定し、その最大化を図る共通点がそこにはあるように感じられます。
様々な学問に精通されているきょんさん。最近のおすすめは軍事学だそうです。
- 作者: 戸部良一,寺本義也,鎌田伸一,杉之尾孝生,村井友秀,野中郁次郎
- 出版社/メーカー: 中央公論社
- 発売日: 1991/08/01
- メディア: 文庫
- 購入: 55人 クリック: 1,360回
- この商品を含むブログ (304件) を見る
おすすめの一冊とのこと。よく名著と聞くので読んでみようかな…。
Effective Retrospective / とにかく楽しいふりかえり
資料: Effective Retrospective とにかく楽しいふりかえり - Speaker Deck
印象に残ったこと
-
KPTのなかで、感情をぶつける、感謝を言い合う
-
問題をすべて解決する必要はない、とにかくコアな問題を解決する
-
マイナスをプラスにするのは労力がかかる、だからプラスをよりプラスにするほうが良い(KPTのKがないのはまずい、自己承認の力を高める)
-
自己承認の力を高める→他己承認の力も高まる
-
振り返りの3ステップ
→立ち止まる、チームを成長させる(チーム内のコミュニケーション、コラボレーションを促進)、プロセスを改善する
<振り返りの楽しさとして場を作る>
【心理的な場】
- 前向きな対話ができるように準備する
- この準備を振り返りの最初5~10分行えるようにする→気持ちに余裕ができる
- 「Good&New」→一週間で新しいことあった?いいことあった?と聞く→振り返り前にやるのがおすすめ
- 対話の意識を持つ(議論ではない)
- DPA・・・振り返りの雰囲気を決めるための会話からルールを制定
- 場を設定するアクティビティはたくさんあるので、飽きないように楽しそうなものをいろいろやってみる
【物理的な場】
- 対話しやすい場の構成→「人対人」でなく「人対問題」
- リラックス→音楽、飲食によるリラックス効果
<学ぶために振り返り>
- 他者からの学び、失敗からも学ぶ
- チャレンジしやすい土台できる
<成長のために振り返り>
- 自己効力感を高める→自分やチームがよくやったじゃんと思える
感想
配属され、個人で行う毎日の振り返りがマンネリ化していた自分に現れた救世主のようなセッション。振り返りを楽しんでやることを軸に、「場」の設定方法や、振り返りの内容、その仕方を説明してくださりました。研修中に自分たちが実際にやっていたこともあり、こういうことをしていたから研修時の振り返りは学びがあって楽しいものだったのかなあと少し感傷に浸っていました。
しかし、一番聞きたかったセッションでありながら資料の最終調整に追われ、半分しか聞くことができず、またセッション終了後も自分たちのセッションが控えていたので質問する時間もありませんでした。そこで、
森さんにはチームでなく、個人的にする振り返りのマンネリ化を避ける方法を時間があれば是非お聞きしたかった…#RSGT2019
— きもりた (@mori_PYON_miwa) January 10, 2019
という内容をTwitterにPostしました。すると、翌日の飲み会で相談に乗ってくださる運びになりました(参加者の距離が近いのは本当にRSGTのいいところ)。その場では振り返りやチーム作りに関して様々なアドバイスをいただき、大変有意義な場になりました(このために最終日大崎まで足を運びましたが、本当に運んでおいてよかったと思いました)。現在森さんに教えていただいた方法で振り返りを行っているのですが、今までのマンネリから抜け出し、新しい学びがたくさん出てきて充実しています。振り返りに困っている方、ぜひ一度森さんに相談してみてはいかがでしょうか。
スクラム1年生のチームが全員でRSGT2018に参加してわかったチーム開発、はじめの一歩
印象に残ったこと
- チーム開発はチームビルディングから、だがそのチームビルディングは難しい
<スクラムの導入>
-
依存度の低下を狙って
-
バックログ、見積もり、計画など普遍的なものを導入
<導入時の課題>
- ベロシティの不確実性
- メンバーの状態でタスク進捗変動する
- レビューで未完了のものが発覚した
- 振り返りが要望、問題に踏み込めてない
<RSGTにて>
<参加後>
- どうなりたいか、を三時間かけて語り合う→変化のきっかけ
- スクラムガイドを全員で読む
- チームとしてコアタイムの導入
- ペアプロ、モブプロで知見の差をなくす
- スクラムに最適な場の創造(物理的に壁を取っ払うなど)
<結果>
任せたいといわれる案件ができ、隣のチームが真似し始めた
<まとめ>
- 周りの力を使うと、チームビルディングの大きな助けになる
- RSGTなどのイベントにチームで参加してもよいのでは、共通体験の創造
→共通体験の創造、振り返りでなりたいチーム像を話し合うことの重要性
感想
チームとしてスクラムを導入してみたが、課題が多く、効果があまり見られない中、RSGTにチーム全員で参加したことによって、チームがみるみる変化し、ほかのチームからの羨望の的になるまでのいいチームになったというお話でした。
チームの皆で共通体験を創造するのは、チームの一体感を生むために大事だと思いました。この話を聞いていて、研修中にチームみんなで取り組んでいた問題がようやく解けて周りの人ににらまれるほど大声で喜んだことを思い出しました。あの時にチームが一つになったような印象を受けたし、本当にうれしかったなあ。
この共通体験ももちろん大事ですが、理想のチーム像を突き詰めるのもまた同じくらい大事なことだと思いました。理想が定まることによって現状とのギャップを測ることができ、そこからどうすべきかが初めて見えてくると思います。この理想がチームで一致できていると、そこまでのアクションが加速し、どんどんいいチームになっていくんだと感じました。
リーダーシップを一度捨ててチームの輪の中に置いた話
資料: RSGT2019 リーダーシップを一度捨ててチームの輪の中に置いた話
印象に残ったこと
開発は社内の言いなり
ある社内表彰者の意見から、社内担当者のためではなく、お客様のための開発をしたくなった
そこでスクラムを導入し、変えていったが、緊急実装、緊急運用、要件授受が消えなかった
→POがいない
→適任者が不在
→じゃあどうしたらお客様のためになる?
→リーダーシップを捨てる決断
リーダーシップ
- 持とうと思えばだれでも持てる
- 属人化が避けられなくなる
リーダーシップを捨て、チームのために何ができる
- チームレビュー
- チーム勉強会
- 振り返りで本音トーク
- やりたいことをできる環境づくり
マーケ担当などとの相互理解
→POもリーダーもチームの中に入っていった
結果
- 緊急対応、エラーがなくなった
- チーム一人一人があらゆる理由を考えるようになった
- チームリーダーの時間が増えた(休める時間がある)
感想
元楽天の方でした。会社の同期が「いい人はこの会社を辞めて転職してしまうんだなあ。」と話していたのが印象的なほど素敵な方で、話からも「お客様のため」という一つの大事な芯が通っている人だということを感じ取ることができました。
この話の中で、リーダーシップを誰でも持てるからという理由で捨てるという決断をしたのは大変驚きました。というのも個人的にはリーダーシップというのは指導力や統率力など組織を良くするための様々な素養が求められ、それがゆえに一部の人しか持つことができないと考えていたからです。しかしリーダーシップを捨てた結果、チームの皆が自立し、「Product Owner」はいないけれども「Product Ownership」が浸透している組織が完成し、お客様のための開発ができています。そのことを考えると、本当に持とうと思えば、リーダーシップって誰でも持ててしまうのかな、というよりもいい組織を作るのにはリーダーシップはそもそも不要なのではないかということを考えてしまいます。
おわりに
RSGTに参加する前に資料を作っている際、自分は「エンジニアになることがなければ、これが開発関係のイベントに参加する最後の機会かなあ」というようなことを考えていました。しかし、RSGTは開発者のためのイベントではなく、チームをよくしたい、もっといいプロダクトを作りたいをいう熱い思いを持った人の集まりで、そこにはビジネスかエンジニアかというそんな垣根は存在しませんでした。
現にビジネスの方でもスクラムは導入されていて、それは一定の成果を見せているように思われます。そのような現状を鑑みると、自分のいる組織にもスクラムを導入するという実験をしたいと欲が出てきます。来年は「経理部にスクラムを導入してみた」でスピーカーとして参加するぞー。
最後になりますが、このようなとりとめのない駄文をお読みいただきありがとうございました。