新チームになってから振り返りで出た課題と試したこと

はじめに

この記事では、私たちのチームがスプリントごと、それに対する取り組みについてお話しします。

弊社は「MicoCloud」というマーケティング支援システムを開発しています。
私が参加したのは2023年1月です。当時、チームは約10人でしたが、数ヶ月でメンバーが18人まで増加しました。
チーム人数の拡大は、多くのタスクを取り組めるようになった一方で、同時にコミュニケーションの課題やタスク管理の複雑さなどが発生しました。
このような状況を改善するために、チームを2つに分けることにしました。

この記事では、チームの振り返りを通して明らかになった課題や、それに対して私たちがどのような試みを行ったのかを紹介していきます。

振り返り手法

振り返りの手法はKPT（Keep, Problem, Try）ベースにMiroボードを作成しています。
何度かボードもブラッシュアップしているので簡単に説明します。

• 前回の試したこと。また話せなかったこと

  前回のTryに対しての振り返りを行えるように、振り返りボード作成時に付箋をコピペします。また、前回の振り返りで時間がなくて話せなかった話題も備忘録としてこちらに移して使っています。

• この1週間で起きた出来事

  振り返り時に1週間の出来事を思い出すのは大変なので、皆でこの1週間を思い出せるよう出来事を書くところです。

• 良かったこと

  個人で良かったことを書く

• 課題だったこと

  個人で課題だったことを書く

• 次に試すこと

  チームでディスカッションして次に試すことを書く

• 振り返りの振り返り

  振り返りの振り返りを書く

「次に試すこと」だと、新規に取り組むことばかりに視点が行きがちになる気がしたので、「続けること」、「やめること」、「試すこと」に三分割にするよう変更しました。

また、個人で考えたTryなどを書けるように「したい(やめたい)こと」を追記しました。

振り返りにも慣れてきたのと、だんだん運用が形骸化したのもあり、今では上記のようなボードの形になっています。

• 前回の試したこと → 使わなくなったので廃止
• この1週間で起きた出来事 → 使われなかったので廃止
• 良かったこと → 良い行動に関してはポジティブフィードバックをして、よりその行動を強めていくために「良かった&感謝」に変更。
• したい(やめたい)こと → 具体的なTryがないと書きづらいので、皆への問い掛けができるように変更。例) 「英語アイスブレイクの進め方どうしましょうか？」

振り返りで出た課題とTry

ここからは、私たちのチームが実際に振り返りを行った後に試みた取り組みについて紹介します。
「課題感」、「トライ」、「結果どうだったか」の内容で書いていきます。

夕会の実施

課題感

当初、私たちのチームは朝会だけを開催していました。これにより、その日に取り組むタスクや直面している問題点を共有していました。

しかし、日中に発生する小さな問題が翌日まで持ち越されることがあり、進捗が滞ることで業務終了時にモヤモヤした感情が残ることが多くありました。また、情報共有が不足していると、突発的な休みが発生した時に、最新の状況を把握するのが難しくなるという課題がありました。

トライ

エンジニアチームだけで夕方を実施する。この夕会では、その日に行った作業や直面している問題点を確認し、必要なフォローアップの時間も考慮し、夕方17時に開催する。

結果どうだったか

導入した結果、情報共有が格段に向上しました。チームメンバーは日中に直面した問題や不明確な点を共有し、次のアクションをチームで決定できるようになりました。

また、夕会で情報を共有することにより、朝会の時間を短縮することが可能になりました。朝は集中力が高まる時間なので、作業時間を最大限に活用できるようになったと感じています。

他チームのカンバンボードを確認

課題感

私たちのチームは2つに分かれたものの、システムの設計上、密接に連携している部分が多くあります。このため、異なるチームが同じシステムコンポーネントに対する修正を行う際に、作業上のコンフリクトが発生していました。

トライ

スプリント開始時に他のチームのカンバンボードを確認することにしました。
他チームが何に取り組んでいるか、どの部分に修正が入りそうかを確認するようにしました。必要に応じて、チケットにコメントを残すか、Slackで直接コミュニケーションを取るようにしています。

結果どうだったか

他チームと作業が重複しそうな時には、事前にコミュニケーションを取ることができるようになりました。これにより、作業のコンフリクトが減少し、チーム間の協調が向上しました。
ただし、チームの数が増えると、このアプローチが難しくなるなとは思っています。

朝会・夕会で話したことはClickUPのコメントを残す

課題感

タスク管理ツールはClickUPを使っています。朝会や夕会ではボードを見ながら状況などを共有していました。口頭のみでメモを残していなかったので、休んだときや土日を挟むと内容を忘れてしまうことがあり、もっと情報のストック性を上げる必要がでてきました。

トライ

口頭での確認事項や簡単なメモをClickUPのコメント欄に記録するようにしました。
これらの情報は生存期間が短いものなので、次のミーティングで思い出せる程度の情報を残すことにしました。

結果どうだったか

チケットごとに関連する情報が記録されるようになりました。これにより、「昨日（または先週）何を話したのか」という疑問が生じることが少なくなりました。

設計方針の共有: モブプロの実施

課題感

タスクを進めた際に設計や実装の認識があっておらず、プルリク時にコメントのやりとり50個以上発生したこともありました。「さすがにもっとやり方があったよね」という話が上がってました。

トライ

大きなタスクや複数の案が出ている場面では、個々に設計や実装を進めるのではなく、チーム全員で認識を合わせるためにペアやモブを実施するようにする。

結果どうだったか

ペアやモブプログラミングを導入したことで、チーム全員が設計について合意しやすくなり、設計の大幅な変更や再作業が必要になるような事態は減少しました。
ただ、現在チームが6人となり、全員でモブプログラミングを行うには少し人数が多いと感じています。このため、さらなるチーム分割を検討しているフェーズにあります。

スプリントの目標とドキュメント化の必要性再考

課題感

これまでのプロセスでは、各スプリントごとに目標やゴールを記載するためのNotionドキュメントを作成していました。
しかし、このドキュメント作成には時間と労力がかかり、実際にそれを頻繁に参照することも少なかったため、その必要性について疑問が生じました。

トライ

ドキュメントを書くのをやめてみました。

結果どうだったか

特になくても困らなかったので状態だったので廃止になりました。
ただ、スプリントのゴールに対して明確に意識を向ける必要性はあるので、この部分に関しては再度課題になっています。

夕会でのファシリテーションと議事録の役割分担

課題感

朝会・夕会でファシリテータの人が議事録を取っていたのですが、どちらもやるのは大変そうというのが上がりました。

トライ

ファシリテーションと議事録の役割を分け、別々の人が担当することにしました。

結果どうだったか

役割分担を試した結果、新たな問題が発生しました。ClickUPはリアルタイム編集に適しておらず、ファシリテータが画面を共有すると、議事録の内容が見えなくなるという問題がありました。このため、この新しいアプローチは1週間試した後に、逆に作業が難しくなると判断され、廃止されました。

バックログチケットの内容テンプレート化

課題感

私たちのチームでは、安定化やスケール化対応のタスクが多く、これまではエンジニアが手動でチケットを作成していました。しかし、チケットの内容がエンジニアの視点に偏っており、QAチームがチケットを確認した際のお客様への価値や受け入れ基準を理解するのが難しいという問題がありました。

トライ

チケットの記載内容を標準化するためのテンプレートを用意して、それを埋めるようにしました。

下記は必須で埋めている項目です。

📘実装目的
誰に対して、なぜ作るのか？

📘このStoryで実現したいこと

📘受け入れ基準
テスト可能であり、テスト方法がわかっていること

📘備考・参照情報

結果どうだったか

チケットの内容が統一され、チーム間の認識合わせが容易になりました。また、QAチームがテストケースを考える際の質問も減少し、全体的なコミュニケーションの効率が向上しました。

振り返り時間の調整：30分から1時間へ

課題感

振り返りを30分で行っていました。しかし、メンバーからのフィードバックや課題点が多く出されるようになり、この時間では十分な議論ができず、急いで終わらせる必要があることが多くなりました。

トライ

事前にボードに記載するという方法も試みましたが、振り返り前に他のスプリントイベントがあるため、事前に記載する時間が十分に確保できませんでした。そのため、記載時間を含めて振り返りの時間を1時間に延長することにしました。

結果どうだったか

振り返り時間を延長したことで、チームメンバー全員がボードに書かれた内容をしっかり確認できるようになりました。

振り返りは、45分から60分の範囲で終了することが多いです。

1日30分はスプリントタスク以外の改善活動をしてもよいと明文化する

課題感

日々の業務を進める中で、改善すべき点が多く見つかりますが、これらはしばしばスプリントタスクから外れた作業となります。このため、スプリントタスクを優先する傾向があり、小さな改善作業に着手する際にためらいが生じていました。

トライ

チームでは日々の小さな改善をどんどんやっていこうという方針です。
この考えをさらに推進するために、チームドキュメントに「スプリントタスク以外にも1日30分は改善活動を行っても良い」というルールを明文化しました。

結果どうだったか

Slackワークフロー改善やCI改善、ちょっとしたリファクタリング、ドキュメント作成など改善活動を堂々と行いやすくなりました。

この文章も日々この時間を使って少しずつ書いています！！

プランニングを木曜日に戻したい

課題感

2つのチームに分かれたことにより、スプリントプランニングのスケジュールが重複し、QAチームが両チームのプランニングに参加しキャッチアップするのが難しくなりました。これを解決するため、基盤チームのプランニングは金曜日に変更しましたが、これにより週のリズムが合わなくなるという新たな問題が発生しました。

トライ

スプリントイベントを効率的に運用するため、スプリントレビュー、振り返り、プランニングを1日にまとめ、木曜日にすべて行うよう変更しました。

結果どうだったか

この変更により、木曜日はミーティングが多くなるものの、金曜日から開発に取りかかることができ、週の作業リズムが改善されました。また、QAチームの人員も増えたため、同時に複数のプランニングを行っても問題なくキャッチアップできる体制が整いました。

slackに共有内容を雑に投稿できるようにする

課題感

日中に業務を進める中で、共有すべき情報が生じることがあります。しかし、朝会や夕会の時間にそれらを忘れてしまい、重要な共有が漏れることがありました。

トライ

毎朝10時にSlackに「朝会・夕方共有事項・確認事項」という投稿を行い、そこに日中の共有したい事項をログとして残すようにしました。

結果どうだったか

情報の共有が活発になり、情報漏れが減少しました。

例えば下記のようなことが共有されることが多いです。

• 他の人が参加したMTGの内容の共有
• 全社で共有された内容
• 他のチャンネルでチームもみておいたほうが良い投稿
• 開発のTips
• おすすめの勉強会など

朝会の時間でリファインメントを実施する

課題感

これまで、リファインメントはプランニング前に一括して約1時間行っていました。しかし、異なるコンテキストのタスクを複数同時にリファインメントすることは、集中力を維持する上で大変でした。

トライ

朝会の時間を利用して、毎日少しずつリファインメントを行うようにしました。

結果どうだったか

毎日1つのタスクに焦点を当ててリファインメントを行うことで、負担が軽減されました。また、朝の時間に議論することで、集中力が高まった気がします。

定期的なプロダクトとシステム理解のための共有会

課題感

バックエンド開発をしているとプロダクトを実際に触る機会が減ってきたなと感じました。
プロダクトやシステムの情報を理解しないといけないという課題感がありました。

トライ

2週間に一度のペースでプロダクトやシステムを理解する時間を設けることにしました。
この時間には以下のようなトピックを取り上げ、関連する内容を確認しています。

• プロダクトの操作の理解
• 最新の営業資料
• クライアント様とのやり取りの内容
• ビジネスの状況(数値)を知る
• 競合とかの理解
• New Relicのメトリクスの理解
• DBの状況やslow query
• warning logの状況

結果どうだったか

まだ初めて日が浅いですが、最近ではSaaSのビジネス構造やNew Relicのメトリクスの情報を可視化を確認しました。引き続き継続してチーム内での理解度を深めていきます。

オンボーディングタスクはリファクタリングや単体テストにする。

課題感

開発チームの拡大に伴い、新入社員のオンボーディングプロセスにも改善の必要があると感じていました。
特に、環境構築後に初めて取り組むタスクの内容について課題がありました。

トライ

開発プロセスの全体を素早く体験できるように、1日で完了できる粒度のリファクタリングや単体テストのタスクを用意しました。
1週間の期間で様々なタスクを経験してもらうため、これらのチケットは常に用意しておきます。

結果どうだったか

以前は、簡単なスプリントタスクを割り当てていましたが、仕様の変更や調整により完了まで1週間かかることがありました。

新しいアプローチにより、新入社員は1日で実装からプルリクの作成、マージまでのプロセスを経験できるようになり、効率的なオンボーディングが可能になりました。

スプリント期間の変更：1週間から2週間へ

課題感

当初はチームビルディングのためにスプリント期間を1週間としていましたが、これにより、毎週1日がスプリント関連のイベントに割かれてしまい、十分な作業時間の確保が難しいという問題が生じていました。

トライ

スプリントを2週間で試す。

結果どうだったか

スプリントを2週間に延長しても問題なかったので、現在は2週間スプリントが定着しています。
ポジティブフィードバックに関しては、1週間ごとに続けることにしており、「良かったこと」の振り返りは毎週約15分間行っています。
個人的には、チームで感じる課題や試したいことを1週間の振り返りまで待つのは、時間が長いと感じてきました。毎日共有して、毎日ちょっと変えるようにして1日で試行錯誤を回していきたい気持ちです。

英会話アイスブレイクの実施

課題感

弊社のVISIONで「Asia No.1 Brand Empowerment Company」を掲げています。開発組織でも海外採用を進めいるので、今後チームもグローバルな体制になることが予想されています。
現状は英語を話す機会もないので、まずは英語に触れる機会を増やしたいねという話が上がっていました。

トライ

いきなりハードル高くやるのは大変なので、朝会の最初に英会話でアイスブレイクを実施しました。

試行錯誤を繰り返していますが、下記のような進行で取り組んでいます。

今日の状況を話す

- ファシリ:「Good morning! everyone!」
- 各メンバー:「Good morning!!」
- ファシリ: 「My condition is ….」
- ファシリ:「〇〇-san, How do you feel?」
    - メンバー:「I'm happy…..thank you!」「I'm tired….thank you!」「I'm excited….thank you!」など
        - 最大30秒ぐらいでお願いします。
        - 最初は質疑応答とかないので、業務や文脈に関わらず言いたいことを一方的にいってOKです！！
        - 終わりが分からないので終わったら、「thank you!」で締めてください。
    - ファシリ: 「thank you!」
    - (各メンバーで繰り返す)

トピックを決めて進める

今日の状況を話すだと、一方的に話して終わってします。どんなことを話すのが事前に分からず聞き取りづらいという課題感もあったので、事前にTopicを決めて話すようにしました。

毎日、全員が話すのはやめて、話す人は二人にして質疑をいれるように変更しました。

- ファシリ:「Let’s practice English today!! Good morning! everyone!」
- 各メンバー:「Good morning!!」
- ファシリ: 「Today's topic is XX. Presentation is by 〇〇-san and 〇〇-san.」
- ファシリ: 「The first presentation is by 〇〇-san.」
    - 〇〇-sanの発表
    - 伝わったかやどんなことを話したかや、どんな英文だったかを軽く話す(ここはどんな雰囲気なのかはちょっとやってみたないとイメージつかないです…)
- ファシリ: 「thank you 〇〇-san. The next presentation is by 〇〇-san.」
    - 以下、繰り替えし….

事前に準備していやる

トピックで話すものは決めましたが、使う英語がまちまちで聞き取れないという課題感もありました。なので、事前に簡単なスクリプトも用意するようにもしました。

結果どうだったか

最初のメンタルブロックである「英語喋るの恥ずかしい問題」は段々なくなった気がします。
この施策を自分が提案したときは、皆ストレスにならないか不安でしたが、続けてやっていきたいというフィードバックがあり安心した記憶があります。
まずは話を聞いたときの反応を返すための「thank you!」「I see」「that’s great」を覚えました。

プルリクのナレッジ共有や依頼

課題感

チームメンバーも参画して直近のこともあり、プルリクのレビューが来てもコンテキストの把握に時間が掛かることがありました。また、エンジニアも6人いるので、レビュワーが偏りナレッジ共有ができていない課題感もありました。

レビュー体制は1Approveでマージ可能になりますが、どうしてもプロジェクトの経験が長い人がレビューしてしまい、他の人が見る機会がなくなってしまうこともありました。

トライ

夕会の時に今出しているプルリクの内容確認を確認する。
プルリクの背景だったり、レビューしてほしいポイントを補足説明することで、レビュワーのコストを下げるようにしました。

夕会は17時から実施するので、そのタイミングで出ているプルリクがslackに通知されるようにしています。GitHubの Scheduled reminders を使ってます。

結果どうだったか

簡単なプルリクであればその場でマージ可能なのでリードタイムも短くなった気がします。
また、モブレビューのような形なのでナレッジ共有もしやすくなりました。

おわりに

新しいチームが結成されてから4ヶ月が経過しました。今回記載した内容以外にも細かい改善は日々行っています。全メンバーが主体的に動いており、非常に良いチームワークを築いていると感じています。

開発チームのメンバーは引き続き増加しており、来年からはさらにチーム分割をする予定です。開発スピードを落とすことなく、スケールできるような開発チームになれるよう頑張っていく所存です。