「RSGT2023に（エンジニア）みんなで行こうぜ！」

LAPRASのエンジニアほぼ全員である14名もの有志がRSGTに参加するきっかけになったのは弊社スクラムマスターの遠藤さんから送られてきたそんな一通のメッセージでした。この誘いがなければきっとRSGTに参加することはなかっただろう、私はそんなどこにでもいるであろうエンジニアの一人でした。それが今ではスクフェス福岡にプロポーザルを提出し「エンジニア以外のメンバーも一緒に鑑賞会しようよ！」と呼びかける側になりました。

14名という大人数でRSGT2023に参加することができたのは「幸運だった」と言う他ありません。過去のRSGTに参加していた遠藤さんが昨年、二人のエンジニアを誘って参加していました。その三名が社内Slackで盛り上がっている様子をCTOが見ており、その時に「これはもしかして全員で参加したほうがいいのではないか？」と思っていたそうです。そして実際に全員の参加にかかる費用を会社負担にできるように根回ししてくださったことで誘われたエンジニア側は「みんなも一緒なら」とかなり気軽に参加できました。一つでも歯車が狂っていたら「エンジニア全員で行く」という計画は頓挫していたでしょう。組織としての懸念は「参加はしたものの、定常業務を停止してまで参加しておいて投資に対して見合うリターンが得られないかもしれない」という点で、これについてはエンジニア陣を信頼してくださった社員の皆様に感謝してもしきれません。

楽しみに思いつつも「なにか一つでも持ち帰られれば」くらいの気持ちで挑んだRSGTは蓋を開けてみれば学びの連続で、中でも毎日の招待講演はどれも登壇者の熱意がどんどん伝わってきて「後からじゃ質問ができなくなるかも」と真っ先にぶつかりに行きました。特に二日目のLyssaさんに投げかけた「これからアジャイルを受け入れて進むためにどうしたらいいか」という疑問への「私に真っ先に質問したんだからもうあなたはスタートラインに立っている」という返答は私の心の奥深く響きました。他にも日々感じていたもやもやを解消するための具体的なメソドロジーとしてペアプロやモブプロを活用するアイデアをセッションから学んだり、コーチズ・クリニックで実践に結びつけるためのアドバイスを頂いたりすることで具体的なアクションにつなげることができました。

チームとしてはカンファレンス中のSlackは大盛りあがりで、それぞれのメンバーが自分たちのニーズや興味に従ってセッションを聞いたりコーチングを受けたり人と議論をしていたりという様子が見て取れました。最終日はクロージングの後にレンタルスペースに移動して社内OSTを実施して、RSGTに参加して改めて取り組みたい組織内の課題やその改善方法、具体的に取り組みたいアクションについてじっくりと話し合いました。ふりかえりも兼ねたこの社内OSTのおかげで「個々人が参加して学びを得た」という状態から一気に「チームとして参加した」という状態に昇華されました。その結果として週明けから業務中に起こせる具体的なアクションが生じたりそのアクションを起こしやすい空気づくりに繋がりました。

「全員で参加する」というアクションによって「参加のハードルが下がり」「同じ場の空気や熱気を共有し」「様々な視点からの学びを得る」ことができ、「全員でふりかえる」というアクションによって「自分の学びを言語化し」「異なる視点を認識し」「相互理解と次のアクションにつなげる」ことができました。その効果はすでに「エンジニアの自律的なアクションの増加」や「コミュニケーションの増加」といった形で実を結びつつあります。私個人の経験、そしてLAPRASのエンジニアチームが実践した事例がヒントとなって皆さんの組織で仲間を増やしたりアジャイルの文化を広めるきっかけになれば幸いです！

事前社内勉強会の様子

LAPRAS公開社内勉強会「教えて！RSGT2023の楽しみ方」#1

LAPRAS公開社内勉強会「教えて！RSGT2023の楽しみ方」#2

私はアジャイルには20年ほど前から取り組んでおり、アジャイルコーチとして10年ほど活動しています。
10年前から、自分が大切にしていることはそれほど大きく変わっていませんが、もたらすこと、考えていること、やっていることは変わってきています。

そんなアジャイルコーチについて最近特に「アジャイルコーチってどんなことをするの？」と聞かれることが何度かありました。

理由の1つにアジャイルコーチと名乗る人が10年前と比較して増えたこともあるでしょう。また必要に応じて、いろいろな組織が外部の力を適切に借りる選択をすることが増えたかもしれません。その一方、1つのチームや組織が複数のアジャイルコーチの振る舞いを見たり、比べたりする機会を持つことはそこまで多くないかと思います。

私は、アジャイルコーチとしての経験が長い人ほど、その経験に応じて引き出しがあり、それぞれのアジャイルコーチとしての考えや特徴が強く出てくるように思います。

アジャイルコーチの力を借りる時には、そのアジャイルコーチがどのような価値をもたらすのか、どんな考えをしているのか、なにを得意としているのかを知ることが、より良い結果を引き出すポイントの1つです。

このセッションでは、私がアジャイルコーチとしてもたらそうとしているのか？何を考えて、どんなことをしているのか？という"アジャイルコーチの1つの類型、中村洋の場合"をお話します。

スクラム開発うまくいってますか？

うまくいってるチームの話を社内外で聞くと、スクラムガイドの基本的ご作法を大事にしているチームが多いという印象があります。基本を大事しつつ、スプリントを通じて得た学びから少しずつチームのオリジナルを加えている。

つまり守破離って大事ですよねと。

”スクラム　アンチパターン”で検索して出てくる記事でも、「スクラムガイドに背くと痛い目を見るぞ！」と散々警鐘が鳴らされています。

そんななか、様々な事情が重なって私が担当するチームではスクラムアンチパータンを踏みまくる状況に陥りました。

例えば・・・

• エンジニアが3人未満のチーム構成
• 全員が他の開発業務を掛け持ち
• スプリントバックログが常に終わらない
• 不完全なインクリメントでスプリントレビュー
• デイリースクラムをやめる  ...etc

なぜ安直なアンチパターンを踏みまくったのか。

アンチパターンを踏んだ結果、このプロダクトやチームはどうなってしまったのか。

起きた事象に対して、スクラムマスターの私は何を考え、行動したのか。

スクラムアンチパターンを踏みまくったときの話をしようか。

複数案件に関わっているという共通点を持つ、デザイナーとQAエンジニア。

現在、デザイナーは主に要件から仕様固め＆UIUX設計を行っています。QAは主にテスト計画やテスト設計・実行のサポートを行っています。

もっとコラボしたいと思いつつも、スクラムと関わるフェーズが異なるため、これまであまり絡んでこれなかった2人が、スクラムチームへの関わり方について語り合います。

様々なロールの人がいるスクラムチームですが、デザイナーとQAがどのような悩みや課題を抱えているのかを聞いていただき、ご自身のスクラムチーム運営のヒントとなったら嬉しいです。

最近はイケてる企業ほどスクラムを導入しているイメージがありますよね？

それに伴いスクラムマスターの需要も上がっているものの、まだまだ専属で熟練のスクラムマスターを雇うより、まずはチームからスクラムマスターを生み出すことの方が多いのではないでしょうか。

このセッションでは、元々Androidエンジニアで経験ゼロの状態からスクラムマスターの役割を持ちモバイルアプリ開発チームでスクラム実施中の新米スクラムマスターが、まだスクラムよくわからんな人に向けて、スクラムマスターになるために何をどう学習すればいいのか？チームにスクラムを導入するにはまずは何を準備しどう動けばいいのか？の最初の一歩をフレッシュな記憶からご紹介します。

私自身8ヶ月前にスクラムマスターを始めたばかりでチームは現在スクラムの「守」を徹底し「破」の準備をするフェーズです。

応用の話はまだまだできない分、ベテランスクラムマスターはもう忘れてしまっているかもしれない、初学者により近い視点から守破離の「守」に辿り着くためのとても具体的な一つの道筋を語りたいと思います。

このセッションを聴き、実践すれば来週にはあなたもスクラムマスターで、3ヶ月後には「守」を体現したスクラムチームの一員となっているはずです。

一緒にスクラムマスターという沼に片足を突っ込みましょう！

発表者

• 株式会社マネーフォワードの家計簿アプリ『ME』のモバイルアプリチーム所属
• スクラムマスター歴8ヶ月の新米スクラムマスター
• 開発プロセス経験はメテオフォール開発→Lean XP→ウォーターフォール風開発でスクラム経験なし
  • スクラムってスプリントがあるやつね。くらいの認識と熱いパッションだけを持ってスクラムマスターを引き受ける
• 1チーム目で二ヶ月ほどスクラムマスターをし、現在移動した2チーム目でも引き続きスクラムマスターを担当、現在は他のチームのスクラムマスターと協力して所属サービスのエンジニアチーム全体をまず「守」に持っていくことをミッションとしている