この記事は「株式会社ログラス Productチーム Advent Calendar 2022」の4日目の記事です🎅
ログラスエンジニアの村本です。
この記事では、ログラスのスクラムチームで取り組んだ改善事例をご紹介しようと思います。
改善事例を紹介しようと思ったキッカケは、2022年8月から私の所属チームのチームリーダーがEMに昇格し、私がチームリーダーになったことです。
チームリーダーになったことで、これまであまり意識してこなかったチームの成果を最大化する方法を考える機会が生まれました。
そして様々な改善アプローチをスピード感を持って試すことで、効果を実感できた改善もいくつか生まれ、チームがどんどん良くなっていくという素晴らしい経験ができました。
この記事では、効果を実感できた改善の中で特に印象的だった7つをご紹介しようと思います。
この記事を通して、スクラムをやりたいと考えている方や、スクラム開発をやっていて課題感を感じている方、ログラスに少しでもご興味がある方のご参考になれば幸いです。
前四半期のはじめに大きく組織構造の変更が入りました。
スタートアップ1人目EMになって 最初にやったこと / The first step of EM
私にとって大きな変化はチームリーダーというロールを与えられたことでした。
当日、ログラスのチームリーダーは"チームの成果を最大化する”という役割が明示されておりました。
(今は内容が少し変わっており、当時私が参照していたドキュメントを貼っております)
旧チームリーダーの責務 (今はアップデートされ内容が変わっています)
チームリーダーになったことで、チームの成果を最大化するにはどうすればよいか考えるようになりました。
が、元々ログラスの開発チームはスクラム開発をしており、レトロスペクティブを通してスプリント毎に改善活動は回っていたので、正直「自分に何ができるんだろう...。」と考えていました。
そういう状態だったので、まずはインプットから始めました。
恥ずかしながら、これまでスクラム開発を体系的に学んだこともなく、何が足りていないのか皆目見当もつかなかったので、スクラムについて学ぶところから始めました。
チームリーダーになって3ヶ月で読んだ本が以下です。
特にScrum Boot Campはスクラム初学者の自分には大変参考になりました。
スクラムを体系的に学んでみると、今の開発チームでもっと良く出来そうなポイントがいくつか見つかり、それらを少しずつ改善していくというところから始めました。
ログラスEMのYoshikiさんがScrumBootCampのコラムを書いているとは知らずビビる図
ここからは、実際に実践してみて効果があった改善事例をご紹介していこうと思います。
課題
これまではプロダクトバックログアイテム(PBI)をある程度の意味のあるタスクの単位で作成していましたが、タスク同士の依存関係が発生し、意図せず大きなリリースになってしまうという事象が発生してしまいました。
これにより、リリース前のテストがめちゃくちゃ大変になり、メンバー全員で泣きながら必死でテストをするという超辛い思いをしました (そのお陰でバグは一つもでなかったのですが)。
どのように改善したのか
まず最初にPBIのタイトルをStory形式に書き換え、”1チケット=1リリース"となるようにPdMに協力してもらい変更していきました。
そうすることで、リリースするための意図しないブロッキングタスクが激減しました。
また、1スプリントで収まりきらないStoryはリファインメント時に分割を見当するようになりました。
PBIの分割方法については、「スクラムケーキの切り方勉強会」をQAのコタツさんに開催していただきました。
これにより、チームメンバー全員がどういった単位でPBIを切るべきか、どういう切り口があるのかの共通認識を得ることができました。
特に、泣きながらテストをした苦い経験があるので、「細かく切っていこう！」というムーブが自然と生まれました。
課題
スプリントに積まれているチケットには受入条件が設けられており、それらを全て満たせば完了という運用でした。
基本的にはPullRequestがマージされたらチケットを完了するという流れになっておりました。
なので、PullRequestのテンプレートにチェックリストを設けて、テスト観点ケースがレビューされていることなどの確認が必ず行われるようになっておりました。
一方で、ローカル環境やステージ環境でのテストをどこまでやるべきなのかや、PdMへの受入確認など、PRチェックリストには表現されておらず、各メンバーの解釈で暗黙的に行われていた部分もいくつか存在していました。
正直、メンバーが少ない頃は特に問題はなかったのですが、新メンバーが増えた中で何をすれば完了になるのかを明確する必要性がでてきました。
どのように改善したのか
まず初めに、"完成の定義を定義する会"を開催しました。
ザンジバルはチーム名です (特に深い意味はありません)
なぜ完成の定義が必要で、いま作る必要があるのかを最初に明確化して、今のチームの完成の定義は何なのか？を考えるワークを実施しました。
ここでもScrumBootCampにお世話になっています
次に作成した完成の定義を、デザイナーのメンバーに綺麗にしてもらい、チームの部屋とポータルに貼り付けるという草の根活動をしました。
これは正直効果が薄かったです...。
理由としては、目につくところに置いたとしても、チェックリストとしての役割を果たすようになっていなかったためかと考えています。
上記の反省を活かし、Sprintに積まれた全てのJiraチケットの中に完成の定義を貼り付けるという運用を始めました。
これは思いつきで始めた運用でしたが、想像以上に効果がありました。
完了したものには斜線を引くことで、何が完了している状態なのかが一目瞭然になりました。
また、全てに斜線が引かれたらチケットが完了になるというシンプルでわかりやすい運用になったことで、完成の定義が一気に浸透していきました。
また、完成の定義を完了にするためのサブタスクを切ってしまうことで、あと何を誰がやればチケットが完了になるのかが明瞭になりました。
これらの改善により、新メンバーだったとしても「あと何をすれば完成なのか？」という疑問に対しても、Jiraチケットを見ることで自己解決することができます。
とはいえ、この完成の定義も運用を開始してまだ3ヶ月程度なので、今後もアップデートを加えていく必要があると思っております。
課題
ログラスでは14:00~18:00まで開発集中タイムというカレンダーをブロックして、開発に集中できるまとまった時間を取る運用を2022年2月から開始しておりました。
この開発集中タイムはとても効果的でした。まとまった開発時間があることで、チケットの完了が早まるなどの実感できた改善施策でした。
ところが、レトロの中で集中した開発時間がとれていないという問題が提起されてしまいました。これは複数チームになったことで、横串でのプロジェクトが増え、メンバーが様々なプロジェクトに関わるようになったことで発生しておりました。
まとまった開発時間が取れないことで細切れに開発することになり、コンテキストスイッチが多発してしまうという事態が発生してしまいました。
どのように改善したのか
完全なる思いつきと、半分冗談でカレンダーのレビューをやってみます？というのを提案してみました。
デイリースクラムの中でメンバーのカレンダーをレビューして、「この予定をこの予定とくっつけると、まとまった開発時間ができそうだね」という感じで予定の調整を行うようにしました。
これにより、午前や午後イチ、就業時間前にMTGを集中させることで、比較的まとまった開発時間を確保できるようになりました。
また、開発集中タイムにMTGが入らないように寄せる意識がメンバーの中で芽生えつつあり、MTGを設定する時点で予定を端に寄せるようになってきています。
また、現在はスクラムイベントを1日にまとめて開催することで、更に開発時間を確保しよう！というTRYも実施しています (先週から始めました)。
一方で、プロジェクトに関わりすぎ問題については、まだ完全解決までは至っておりません。
メンバーが関われるプロジェクト数に制限を設けたり、EMがリソース調整を担うというTRYは出てきており、徐々に改善されそうな気配を感じています。
課題
これまでは2チームだったこともあり、全チームの成果物をSprint Reviewの場で発表しておりました。
これが3チーム体制になり、成果物が増えたことで時間が足りなくなるという事態に陥りました。
時間が足りなくなることで、デモの時間を確保できなかったり、時間短縮のために簡易化していく傾向にありました。
本来、ステークホルダーに成果物のレビューをもらう場だったのですが、リリースして問題ないかの確認をする場のように本来の目的から乖離し始めておりました。
ここでもScrum Boot Campを参考にしています
どのように改善したのか
全チームが同じ時間に開催していたSprint Reviewをチーム別に開催するように変更しました。
時間が足りないという課題感はPdMや他チームも同じように感じていたので、比較的スムーズに調整することができました。
Sprint Reviewをチーム別で開催することで、一つ一つの成果物に時間をかけられるようになり、DEMOの時間も確保することが可能になりました。
Sprint ReviewでDEMOの時間が確保できるようになったので、完成の定義に「Sprint Reviewの準備が完了していること」を入れ込むようになりました。
また、チーム別にしたことで、各チームが好きな時間にSprint Reviewを開催できるようになり、各チームがより自律的に動けるようになったという副次的な効果もありました。
実際に、あるチームではスクラムイベントを水曜日にまとめるというTRYをしていたのですが、Sprint Reviewも自チームで調整可能になったので、実現できたTRYだったと思います。
一方で、時間が確保できたことでSprint Reviewを改善する余地が見えてきています。
特に、今のSprint Reviewでは成果物のレビュー以外はあまりできていないため、Sprintのレビューにフォーカスを当てた以下のような改善の余地が残っています。
ステークホルダーがいるSprint Reviewという場で、発見をすぐに反映したり、進捗や今後の予定を共有することで、よりアジャイルらしい動きになると考えています。
課題
スクラムイベントのファシリテーションは、スクラムイベント開始時に、チームメンバーの中からランダムに選出しておりました。
この方法では、いつ、どのスクラムイベントに選ばれるかわからないので、スクラムイベントの事前準備をするのが困難という明確な課題が存在しておりました。
また、スクラムイベントについて改善したいが明確なオーナーシップがないことで、中々改善が進まないという事象も暗黙的には発生していたと思います。
また、チームメンバーの選出には、ShuffletというSlack Appを用いており、これにとてつもない偏りがあるという問題もありました。
(私は全然ピックされず、メンバーが6人いる中で20回に1度しか選出されませんでした...)
どのように改善したのか
各スクラムイベントに対して担当メンバーを決定し、オーナーシップを明確にしました。
正直、この改善がこの記事で紹介する中で一番効果があったと思います。
実際に、デイリースクラムが15分以内に終了したり、プランニングがタイムボックスを意識して確実に終了するようになったり、レトロが型化されて議論の時間が増加したなど、ここでは書ききれないほどの改善が生まれました！
詳細な改善内容については、各スクラムイベントオーナーが記事を書いてくれているので、そちらをご参照いただけますと幸いです。
オーナーシップを明確にすることで想像以上に改善が進んだので、オーナーを明確にすることは超大事だと体感することができました。
また、リーダーである自分が特に何もせずとも改善が回っていく感じが、これまでにないスピードを感じられ、チームがより良い状態になったことを実感することができました。
課題
エンジニアはCSやSalesから要望の声や課題感を伝えられることは多いのですが、お客様の生の声を聞く機会が中々ありませんでした。
もちろんゼロというわけではなく、商談に同席したり、CSインターン制度や、顧客ヒアリングなどの場は存在していましたが、定常的にあるわけではありませんでした。
これによって、機能要望がどれくらいの温度感で、お客様の課題をどれだけ解決するものなのか、CSがコストをかけて伝えてくれることでようやく理解できるという状態でした。
どのように改善したのか
毎週水曜日のお昼の時間にランチを食べながら、商談動画を鑑賞する会を企画しました。
鑑賞対象の動画は、CSやSalesからオススメをピックしてもらい、その動画を見るようにしています。
会の名前は商談動画鑑賞会ですが、商談動画にとどまらず、CSのお客様MTG動画やCEOヒアリング動画、顧客ヒアリング動画など、お客様の理解に繋がりそうな動画を幅広く取り扱っております
お昼なので任意参加なのですが、ほぼ毎回チームメンバー全員が参加しており、ご飯を食べつつ、気になる点はSlackのスレでわいわいしながら商談動画を見ています。
実際に、機能説明の中でお客様の生の反応を見ることで、「そこが刺さるのか！」という発見があったり、「それは辛い...」と共感できるような運用をされている声を聞いたり、「そういう伝え方をしているのか！わかりやすい！」と他職種へのリスペクトが止まらない会になっています。
(実際に、diagrams.netを使って、その場でリアルタイムにお客様の業務フローを図示して整理するのをみて、「Sales凄い...」となりました。)
2022年8月から開始して、2022年12月時点で計14回開催されています。
仕様を詰める際にも、顧客理解が進んでいることで、「こういうやり方だったら比較的簡単に作れそうです」という提案をエンジニア側からすることができるようになってきています。
特に、今は各チームに特定の業務ドメインが割り振られているので、担当の業務の課題や温度感についてはチームの経験値として溜まってきているのを実感しています。
課題
自分やメンバーが持っている知識や、インプットした内容を試してみたいけど、温度感を上げたり、キッカケを作るのが難しいという課題がありました。
実際に、課題意識も薄いものについては、温度感が上がらないまま進めてしまうと、運用されなくて廃れてしまうというのもいくつか起こっていました。
実は、完成の定義もそのうちの一つでした。今は運用が回り、とても良い体験ができているのですが、チームとして「やってみよう！」とならないと中々運用に乗らないというのは往々にしてあると思います。
どういう改善をしたのか
毎週1時間のチーム勉強会の時間を設けました。
最初は30分で開催していたのですが、想像以上にやりたいテーマが多く、初月特別キャンペーンで1時間に伸ばしています。
2022年12月時点で５回開催されていて、９コマ分の講演がありました。
どれも素晴らしく、内容によってはアクションが生まれるような回もありました。
新しい発見だけではなく、改めて基礎を振り返る場としても機能してしており、普段スクラム開発をしている自分たちがScrumBootCampの1章から示唆を得て、「もっと改善できそうだよね！」と議論が生まれたりしています。
私がチームリーダーになってきてから、チームで取り組んできた改善活動について紹介してきました。
チームリーダーという新しい役割を持つことで、チームの成果を最大化するためにはどうすれば良いのか？という視点で考えるようになりました。
振り返ると、チームの改善をする際に意識にしていたポイントが2つありました。
1つ目に特に意識していたのはチームの成果を最大化するという目的意識を忘れないことでした。
ScrumBootCampを参考にスクラムの改善をやりつつも、チームの成果を最大化するために足りない部分はどこだろう？と考えて進めておりました。
私達は「スクラムをやりたくてスクラムをやる」のではなく、「スクラムを通してチームの成果を最大化したいんだ！」という意識を大事にしていたと思います。
2つ目はチームで改善に取り組むということでした。
独りよがりでやりたい改善を進めるのではなく、チーム全員で「〇〇について改善していくぞ！」と意思統一した上で改善していくことを意識にしておりました。
まずはチーム内で課題を認識し、課題に対する熱感を上げた上で、改善するにはどうしたら良いか考えるという流れを作るようにしておりました。
振り返えると、チームリーダーとしての仕事はチームの成果を最大化させるという視点でチーム改善の火種を起こすことだったと思います。
チームリーダーは一人では改善できないので、メンバー全員で火種を大きくしていく必要があると思います。
今のチームは、メンバー全員が高いスキルとフォロワーシップを持っているので、火種はすぐ大きくなり、トンデモないスピードで改善が回ったんだろうなぁと思います。
ログラスの開発チームはアジリティが高く、変化のスピードがトンデモなく速いです。
毎週何かしらのTRYや実験をして、常に変化をしています。
実際に、この記事に書いた改善は直近4ヶ月間でやってきたことです！!!
現在も継続的にチームが改善しており、良い改善が生まれつつあるので、また3ヶ月後くらいに改善まとめをご紹介できたら幸いです！
「株式会社ログラス Productチーム Advent Calendar 2022」の5日目は、あのDDDの松岡さんの記事です！
ログラスでは関係システムコーチングを使って新たな旋風を巻き起こしております！
ログラスに少しでも興味を持っていただけた方はぜひお気軽にお声がけください！
▽採用ポジション一覧（他多数あります！）
▽ログラスの採用ジョブボードはこちら
/assets/images/4211756/original/b3831c9b-59a3-4da4-87f8-2867f9798924?1572278245)
/assets/images/4211756/original/b3831c9b-59a3-4da4-87f8-2867f9798924?1572278245)
/assets/images/4211756/original/b3831c9b-59a3-4da4-87f8-2867f9798924?1572278245)
/assets/images/11406098/original/b3831c9b-59a3-4da4-87f8-2867f9798924?1670294802)