IDAREプロダクトチームのスクラム開発 ~ 現在の取り組みとこれから ~

年率2%の高還元と、独自路線をいくユニークな貯蓄機能を兼ね備えたIDARE。プロダクトローンチから4年を経過する今でも、機能改善、新たな機能開発に日々取り組んでいます。この記事では、開発体制の効率化・強化として、チームとして導入を始めたスクラムイベントに焦点を当て、現在の進め方や効果を具体的に解説します。

はじめに

IDAREプロダクトチームは、サービスの成長と機能拡張、そしてメンバー増加という変化の中で、より強固なチーム体制と効率的な開発の実現を目指しています。この記事では、チームとして導入を始めたスクラムイベントに焦点を当て、現在の進め方や効果を具体的に解説します。
プロダクトチーム（ここではフロントエンド・バックエンド双方を含むIDAREのエンジニアチーム全体を指します）では、以前から毎朝デイリースクラムを行い、日々のタスクの進捗を確認していました。
しかし、デイリースクラムは「昨日と今日」にフォーカスしているため、一定期間での計画や振り返りをするには十分ではありませんでした。
また、以前はメンバーそれぞれが自立してタスクを進めるスタイルでした。
しかし、IDAREがサービスとして成長していく中、メンバーの増加やプロダクト自体の機能の拡張に伴って、属人的な進め方から脱却し、チームとして支え合う体制へと変化する必要が出てきました。
こうした背景から、まずはチームに必要で目的が明確なスクラムイベントを取り入れることにしました。

現在のスクラムイベント

レトロスペクティブ

プロダクトチームでは毎週1時間、KPTを用いたレトロスペクティブを行っています。
KPTとは、

• Keep（続けたいこと、良かったこと）

• Problem（問題だったこと）

• Try（試したいこと）

の頭文字をとった振り返りのフレームワークです。

レトロスペクティブの進め方は以下のとおりです。

1. 前回のTryを振り返り、実践できたか確認する

   • 実践できていなければ今回のTryに引き継ぐ

2. MiroのKPTボードに、各自KeepとProblemを記入（業務以外のことでもOK）

3. 特に気になる点を深掘り（Drill）

4. 次スプリントで取り組むTryを全員で考える

レトロスペクティブを定期的に行うことで、問題の大小に関わらず、問題を放置せずに向き合える体制ができていると感じています。
特に、冒頭の工程である「前回のTryの振り返り」を必ず実施することを重視しています。
これにより、毎週設定したTryが確実に実行され、レトロスペクティブ自体が行動とその結果の振り返りを確実に行える意味のある場となっています。
ある回のレトロスペクティブでは、「一人で解決するのが難しい要件定義がある」というProblemが挙がりました。
チームでTryを検討した結果、プロダクト開発チームだけでは対応が困難なため、CEOに相談することを決めました。
そして、レトロスペクティブ終了後すぐにCEOに相談し、問題（＝要件定義の確定）を迅速に解決することができました。
このように、各メンバーが抱えている課題を早めに共有できることは、日々の業務を効率的に実行していくことに加え、各メンバーの心理的安全性の向上にもつながっていると感じています。

スプリントプランニング

チームとして1週間を1スプリントと定義し、木曜日をスプリント開始日として、スプリントプランニング（以下、プランニング）を行っています。
プランニングでは、次のスプリントで対応するタスクをバックログから抽出し、担当をアサインします。
タスク管理にはNotionのスプリント機能を活用しています。既存のタスクデータベースをそのまま利用でき、余計な管理工数も発生しないのでとても便利に感じています。
プランニングを通じて、短い期間ごとの明確な目標を設定できるようになり、大規模プロジェクトに取り組む際にも安心感を持って進められるようになっています。
特に、今年7月にリリースしたdポイント交換機能は、社外連携やプレスリリースとの兼ね合いから、リリース日を厳守しなければならない難易度の高い大規模プロジェクトでした。
そんな中でも、このプランニングを通じ、設計・実装・社外調整といったタスクを分担し、計画的に進めたことで、スケジュール通りにリリースすることができました。

デイリースクラム

デイリースクラムは以前から継続しているイベントで、毎朝15分、タスクとスケジュールの確認を行います。
過去から行っていたものであるものの、スプリント導入以前は単なる日々の進捗共有のみで終わってしまうこともあり、うまく活用しきれていませんでした。
現在は、スプリントをベースとしたプランニングに基づく中長期の進捗も確認しやすくなり、大規模プロジェクトにおけるスケジュール遅延リスクも早い段階で察知できるようになりました。
実際に直近リリースされた
・dポイント交換機能
・プロ野球応援ボックス
は比較的大規模な機能開発でしたが、中長期のリリース期限を念頭に日々の業務を入念に確認しながら進めることができ、当初のスケジュールから大きな遅延が発生することなくリリースすることができました。

これから

スクラムを取り入れてチームの動きは良くなってきていますが、まだまだ改善の余地はあると考えています。

・プランニングの精度
アサインしたタスクが終わらず、次のスプリントに持ち越してしまうことが少なくありません。
例えば、リファインメントを実施してタスクごとにストーリーポイントを設定し見積もり精度を高める、といった方法も考えられそうです。 

・スプリントごとのパフォーマンスの見える化
レトロスペクティブでチームの成長は実感できていますが、現状では「どれだけ効率化できたか」が定量的に見えていません。
例えば、ベロシティを計測して、振り返りやモチベーション向上に活かす、というのも一つの方法かもしれません。

まだまだ課題は多いですが、柔軟に改善していけるのもスクラムの面白さだと思っています。

最後に

以上、プロダクトチームで取り組んでいるスクラムイベントをご紹介しました。これらの仕組みによって、効率的かつ安心感を持って開発を進められていると感じています。
ただし、これからさらにサービスが成長していく、プロダクトの機能が拡張していくという局面に置いては、プロダクト開発にはメンバーの入れ替えや増員、プロジェクトの規模や難易度など、常に変化が伴います。
今後もその時々の状況に合わせ、柔軟かつ慎重に開発スタイルを進化させていきたいと考えています。
そんなチームに加わって、一緒にプロダクトを育てていける仲間をお待ちしています！

カジュアル面談を実施しています。ご興味のある方は以下より随時お申し込みください。