RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

チーム全員で取り組んだ勉強会発表プロジェクト(アジャイル Nightふりかえり)

id:radiocat です。2/26に大阪オフィスで実施したMeetupでは楽楽精算開発2課のメンバー全員で半年かけて準備をして発表しました。今回はMeetupの内容と合わせて、全員で役割を持って取り組んだ勉強会発表プロジェクトの内容をご紹介します。

rakus.connpass.com

プロジェクトの経緯

私たち楽楽精算開発2課は成長サービスを支える開発組織として、常に新しい領域の開発に取り組んできました。一方で、開発部門としてMeetupというイベントを継続的に開催していくことになり、私たちのチームがどう関わっていくべきかを考えた時に、チームでイベントのコンテンツを作り上げるという新しいチャレンジを行ってその知見を残すことが私たちのチームらしい取り組みではないかと考えました。そして2月のMeetup発表者としてチームで名乗りを上げてプロジェクトをスタートさせました。

2018年10月にプロジェクトスタート

前回のMeetup の開催翌月にキックオフを行いました。 まず、どういうイベントにしたいかを全員で話し合って、発表テーマの候補を出しました。その中からいくつかのテーマに絞り込んでそれぞれのメンバーがいったん持ち帰り、次回までに発表テーマを検討することにしました。

11月

前月にそれぞれが持ち帰って検討した発表テーマと発表のイメージを共有して、イベントの全体像をすり合わせしました。 この時にそれぞれのメンバーが担当する発表内容の大枠が決定しました。若手メンバーは3人1組で発表資料を作って代表者が発表することになりました。

12月

前月に決まった発表テーマと内容の大枠をスライドに落とし込んでアウトラインレベルで中間発表を実施しました。そしてお互いの発表を聞いてフィードバックし合いました。このとき、主力エンジニア、中途社員エンジニア、若手エンジニア、スクラムマスターというそれぞれの視点で発表するという流れがだいたい確定しました。

1月

ドラフト版レベルのスライドで発表練習して、全員でレビューしました。ここまではスクラムマスターが最初に発表する流れにしていましたが、「いきなりスクラムマスターが場を引っ張って発表するのはなんか違うよね」となって、スクラムマスターは最後に発表する流れに変更しました。

2月

本番さながらの練習会を実施し、資料と発表内容の精度を上げていきました。チームで整合性を合わせる部分があるため前日までスライドのチェックや修正を行って当日を迎えました。

f:id:radiocat:20190306104925p:plain



発表したスライド

当日のスライドと合わせて発表に関わったメンバーのコメントをご紹介します。

大阪開発チームが取り組んだスクラム1年目の開発現場

まずはチームを取り巻く状況と、スクラムに取り組んできた経緯を簡単にご紹介しました。


1. 開発チームクエス

楽楽精算開発チームの岡本です。
Meetupでは「開発チームクエスト」というタイトルで、開発チームが歩んだ1年間の振り返りを発表しました。


タイトルは直訳すると「開発する仲間たちで探求する」になります。

探求とは「さぐり求めること。さがし回ること。※1」らしいですが、この1年はまさに仲間たちで課題の解決方法を探し回った1年でした。
中でも一番深刻だった課題がチームの分断問題です。若手とベテラン、新規メンバーと既存メンバーで知識量に差があり、フォローによる稼働圧迫が慢性的に発生していました。我々のチームでは、モブプロ/モブワークの手法を採用して、この課題を克服しようとしました。

当初は知識のあるメンバーがモブを主導することが多かったのですが、回数を重ねるうちにチームの平均知識が上がっていき、今は知識のあるメンバーが一方的に発言するというシーンは少なくなっています。また、モブで開発を進めた結果、必然的にメンバー個々へのフォローも少なくなりました。

ところで、モブプロとは全員でひとつの課題に取り組む開発手法ですが、これを言い換えると「開発する仲間たちで(ひとつの課題を)探求する」と言えるんじゃないかと思います。つまり、色々書いていましたが、今回の発表の結論としては「モブプロやってみると意外と良かった」に尽きると思います。

※1 出典:精選版 日本国語大辞典


2. 中途社員がチームに参加しました

中途入社の福岡です。昨年5月に入社してからの1年間について発表しました。


当初は、入社してからの苦労話を発表しようとしたのですが、全く思い出せず、最初は何を話せるだろう、どういった価値を参加者へ提供できるだろうと悩みました。そこで発想を変え、どうして苦労話がでてこないのか?から、スクラムチームが実施しているイベントを振り返り、これがなかったら苦労しただろうなという事例をピックアップしました。

またイベントだけでなく、HRTという考えから得るもの、これまでの自分を反省することが多々ありました。このブログを見た方は「HRT」についてだけでも、Google先生に聞いてみてください(笑)

今後チームに新たにメンバーを迎えられる方、またチームへ参加される方に何か響くものがあればと思います。


3. 学習スクラムをやってみた件

入社3年目の中野です。私は「若手エンジニア」パートの発表を担当させていただきました。


チームの教育課題にスクラムを適用するという内容で登壇させていただきましたが、今回のMeetupに参加された方の多くは、プロダクトの開発にスクラムを適用することはあっても、新人の教育課題にまでスクラムを適用した例はあまり無いのではないかと思います。

実際、弊社のチームでも教育課題にスクラムを適用したのは今回が初めてでした。「教える側」はスクラムの経験が約1年と浅く、「学ぶ側」はスクラムの経験が皆無という状況で、お互い様々な苦労がありました。登壇の際にも触れましたが、最初の頃はタスクの残量がバーンダウンせず、どうすれば計画通りタスクを消化できるかを考える日々が続きました。スプリント内で確実にタスクを完了させるために1つのタスクの粒度を小さくしてみたり、前提知識を補うための事前学習的なタスクを作ってみたり、試行錯誤を繰り返しました。思い返せばスクラムにおいて最初の難関はこの「バーンダウンしない問題」なのかもしれません。

今回は上記のような問題が発生するたびに「教える側」と「学ぶ側」が一緒になって解決策を考えたので、お互いにとって学びや成長があったと思っています。まだまだスクラム初学者の私が言うのも恐縮ではありますが、もし貴社で新人教育にスクラムを取り入れようと考えておられるならば、今回の発表が少しでも参考になれば幸いです。



入社二年目の桑原です。

私は学習スクラムに教える側として参加し、Meetupでは資料作成に協力しました。ここでは発表であまり触れることのできなかった、学習スクラムの中で、教える側がプロダクトオーナー(以後PO)やスクラムマスター(以後SM)のロールを体験して感じたことについて記載したいと思います。

私は1年ほどスクラムの開発に参加してきました。もちろん、POやSMの立場の人とも関わることがありました。そのため、学習スクラム実施前は、それなりにロールを担うことができるだろうと考えていました。しかし、実際に学習スクラムが始まると全然ダメでした。例えばPOを担当した際のプロダクトバックログ1つに着目しても、バックログの順番やどこまで作りこむか、エラー時の動作等、考慮が足りないことは多くありました。結果、最初のスプリントは計画段階で躓き、開発時間を圧迫、進捗も悪くなり、次のスプリントの準備も不十分になるという悪循環に陥っていました。最終的に、イベントの実施日は決めたものの、そのイベントのゴールは何か、そのゴールのために誰が何をどこまで準備するのかを整理できていなかったことに気づき、各イベントで最低限やることをリスト化、イベントまでに誰が何をするのか整理することで改善しました。

今思い返してみると、POやSMの役割、チームが動きやすいように舵をとることに関して、表面上は知っていた(見ていた)ものの、その役割を果たすためにどのような準備をしているのかが分かっていなかったのだと思います。1年間スクラムに触れ、少しは分かったつもりになっていましたが、まだまだ学ぶべきことは多いのだと感じさせられました。学習スクラムという取り組みは、新規メンバーがスクラムに慣れていくという面だけでなく、教える側の若手にとっても、チームがよりよく動くために自分達が何をすべきかを改めて考えさせられる良い取り組みであったと思います。



入社一年目の庄禮です。

「学習スクラムをやってみた件」で実際に教えていただく立場にあり、中野(登壇者)の資料作成に協力しました。

学習課題をスクラムで回すという初めての取り組みで、「こんなの上手くいくわけがない!」と始める前や始めた当初は思っていました、しかし、スクラムを回していく中で徐々に改善していき、イベントの役割などを身をもって体感することができたので、結果的に取り組んでよかったと思っています。

この度Meetupの題材にあがって資料作成をおこなうまで教育者側の苦労などは意識できていなかったのですが、資料づくりの中で今後のチームや教育の改善の観点から学習スクラムを見ることができたので、今回のMeetupでアウトプットすることができて良かったと思っています。

来年、チームに入ってくる新人がいれば私も教育に関わることになるので、今回の反省点や課題点も踏まえて取り組んでいきます。もし機会がありましたら、学習スクラムの取り組みの進捗・変化をみなさんにお伝えしたいと思います。


4. アジャイルであり続けるためのチームリーディング

スクラムマスター担当の大塚です。

9月末に大阪オフィスで1回目のMeetupを開催した時に、次回は私たちのチーム全員で取り組んでみたら面白いのではないかと考え、チームに提案してみたのがきっかけで準備がスタートしました。半年もあれば準備万端で当日を迎えられるかというと、実際はそんなに単純ではありませんでした。業務の合間を縫って少しずつ準備を進める必要がありました。また、半年前から内容が決まっていたわけではなく全員が「これからやること」をイメージして2月に「こういう発表ができそう」というテーマを決めて、仕事でそのイメージに向かって進んでいくことで発表内容も同時に組み立てられていきました。つまり、Meetupに向けて発表の準備をすること自体が、ひとりひとりがチームの未来をイメージしてそれに向かって進んでいく作業にもなっていました。




主力メンバーが別のチームに移った時、今こそチームでアジャイルになるべきだと私は考えました。「誰か」ではなく「私が」でもなく「チームで」が大事な理由は同じことを繰り返さないためです。誰かがチームを引っ張るのではなく、チームで未来をイメージしてみんなで取り組んで作り上げる過程こそアジャイルではないでしょうか。そうやってMeetupに向けて進みながら少しずつイメージを具体化していく過程をスクラムマスターとして支援してきました。

  • 「やってみたら面白そう」と思えるようなアイデアを見つける
  • それを実践するきっかけを作る
  • 実現イメージの具体化をファシリテートする
  • 実行するうえでの課題や懸念の解消を手伝う

このようなちょっとした支援で少しずつチームが前進していくのを手助けすることこそがサーバントリーダーの醍醐味だと思います。




ふりかえり

アジャイル Night らしく、ふりかえりは 「Fun Done Learn」をやりました。

f:id:radiocat:20190306010557p:plain

Fun Done Learnって何?というかたはこちらをご確認ください。

qiita.com

Fun Done Learnをやってチームで議論した内容を以下にまとめます。

良かったこと・学び

  • スクラムの取り組みについて参加者との交流や外部のエンジニアとの情報交換ができた
  • 自分たちがやってきた事へのフィードバックが得られて今後のモチベーションに繋げられた
  • 自社開催でチームでの取り組みなのでアウトプットへのハードルが低く、心理的障壁が少ない中で前向きに取り組めた
  • 半年間の活動でしっかり時間を確保して学んだことや取り組みの総括ができた

改善点や今後に向けたTry

  • 資料作りが基本であり一番大事、これを極めればもっと良い内容にできそう
  • スケジュールを立ててチェックポイントを設けて計画的に取り組むことが大事
  • 当日の発表を想定した練習が大事(もっとやっておくべきだった)

ふりかえった内容は社内で共有して、他のチームの新たなチャレンジに役立ててもらいたいと思っています。また、社内だけでなくこの記事を読んで頂いた皆さんの何かの取り組みに役立てば幸いです。

おわりに

次回のMeetupは6月を予定しています。内容は決まり次第、connpassで告知します。

rakus.connpass.com

また、大阪オフィスでは毎月1回エンジニアもくもく勉強会を開催しています。今回の発表内容に関しても興味を持たれましたら情報交換できればと思っていますので、是非ご参加ください。

rakus.connpass.com

Copyright © RAKUS Co., Ltd. All rights reserved.