こんにちは。TAIANでPdMをしている川平です。
今回は、TAIANの開発チームがスクラムを導入し、「チームで開発する」ということを本当の意味で理解できるようになるまでの過程をまとめてみました。
この話が、同じようにスクラム導入を検討している方や、チーム開発の在り方に悩んでいる方にとって、少しでも参考になれば嬉しいです！
はじめに
TAIANは現在、ブライダル業界向けにプロダクトを提供しているスタートアップです。2024年11月にはシリーズAの資金調達を実施し、現在はさらなるスケールに向けて走っています。
TAIANでは主に、OiwaiiとConcept Marryを提供しています。
Oiwaii：https://oiwaii.taian-inc.com/
Concept Marry：https://concept-marry.taian-inc.com/
さらにOiwaiiは、Oiwaii Marketing、Oiwaii Produce、Oiwaii Anniversaryに分かれており、今回はスクラムを導入したOiwaii MAチーム、Oiwaii Pチームでの取り組みについてお話します。
スクラム導入までの経緯 〜カオスからの脱却〜
スクラムを取り入れる前の開発チームは、いわば“カオス”の中で開発を進めていました。
メンバー同士がその場のやりとりでタスクを受け渡し、「誰が何をやっているのか」「どこで詰まっているのか」 などの情報は、各自の頭の中にしかありませんでした。
フェーズ1：Notionのテーブルで"とりあえずの見える化"
最初に手をつけたのは、Notionでのタスク一覧の整備でした。
タスクを洗い出し、担当者を明記することで最低限の可視化はできましたが、それは単なるToDoリストにすぎず、 「今週何に集中すべきか」 といった視点はありませんでした。
フェーズ2：スプリントボードを導入してそれっぽく進める
次に、スプリントの概念を導入するためにNotionのスプリントボードを導入しました。
スプリント単位で開発を進める様になりましたが、進め方はまだ我流で、スクラムとは呼べない状況でした。
フェーズ3：Jira導入とスクラムガイドの読み合わせ
Notionのスプリントボードで運用していましたが、徐々に限界を感じる様に。
そこで、以前からスクラムマスターとして、スクラムの導入・運用を経験していた私を中心にスクラムの導入について、本格的に検討を始めました。
このタイミングで、スクラムを回すためには、NotionよりJiraの方が最適だろうと言うことで、Jiraを導入しました。
同時に、 「スクラムガイドをチーム全員で読み合わせる」 という地味だけど本質的な取り組みから、スクラム導入が本格的に始まりました。
スクラム導入前に感じていた課題
当時の開発には、以下のような課題がありました。
- タスクの進捗や担当が見えない
- 開発の優先順位が曖昧
- 属人性が高く、情報が一部の人に偏っていた
- プロダクトの仕様がエンジニア任せになっていた
- 振り返りの文化がなく、改善の機会が生まれない
どれも、今思えば 「チームで開発している」 とは言いがたいものでした。
スクラムを始めて変わったこと
チーム全員でスクラムガイドを読み、イベントを丁寧に回していく中で、少しずつチームの景色が変わっていきました。
スプリントの設計と運用
2週間を1スプリントとし、毎回のスプリントには明確なスプリントゴールを設けています。
Jiraのスプリントボードとバーンダウンチャートを活用しながら、進捗をリアルタイムで確認できる体制にしました。
スプリントの期間は2週間で実施しており、スプリントの流れを図で表すとこの様な形になります。
最終日にスクラムイベントを集約し、スプリントの終了し、次回スプリントの準備をしてスプリントを開始しています。
スクラムイベントの実践
-
バックログリファインメント
お客様からの声、技術的負債、社内で実現したいことなど、さまざまな課題をCS・プロダクトチームで整理・優先順位付けします。 -
スプリントプランニング
優先されたバックログをスプリントに取り込み、誰がどのタスクを担当するのかを明確に。見積もりもこの段階で実施します。 -
デイリースクラム
毎朝15分間、時間厳守でスタンドアップ。バーンダウンチャートの確認とボードを使っての進捗確認、困りごとの早期発見が目的です。必要な議論は別時間に切り出します。 -
スプリントレビュー
実装された機能の動作確認をCS・プロダクトチームで行い、必要に応じてリリースノートやガイドの更新も行います。 -
スプリントレトロスペクティブ
KPT形式で「良かったこと」「問題点」「改善策」を共有。レトロのTryは、次のスプリントでしっかり実行します。
バックログの管理も体系的に
- エピック → バックログ → サブタスク、という明確な階層を設定
- Jiraで一元管理し、誰が見てもチームの状況が把握できる状態を実現
- 大きな課題はエピックとして分割し、段階的にスプリントへ落とし込む運用
チームで開発するということ
スクラムを始めてから、TAIANの良さでもあった、コミュニケーションをとりながら 「一緒に考える」 という文化がさらに洗練されました。
また、仕様に疑問を持ったら誰でも問いを立てられ、 「この機能って本当に必要？」 という議論も歓迎されます。
スクラムイベントを回すことで、他の人の状況が見える様になったり、スクラムを終わらせるために助け合うことが増え、ようやく 「チームで開発するってこういうことか」 と実感しています。
レトロスペクティブを重ねるたびに「今のままでいいのか？」を問い直し、改善のサイクルを回し続けています。
スクラムを導入してよかったこと
- バックログの可視化と役割分担が明確になった
- 無理なスケジュールになりにくくなった
- チームの会話が増え、問題が早期に顕在化するようになった
- スプリントにコミットしてチームで助け合えることが増えた
- 組織の文化として「改善」が根付いた
一緒にチーム開発しませんか？
TAIANでは現在、以下のポジションを募集中です！
- フロントエンドエンジニア（React / TypeScript）
- バックエンドエンジニア（Ruby on Rails）
プロダクトや開発の進め方、文化に少しでも興味を持っていただけたら、ぜひカジュアル面談でお話ししましょう！
おわりに
スクラムを取り入れたことで、単に「開発を進める」だけでなく、 「どうすればより良くできるか」 を自然に考えられるチームになりました。
気合いと根性でなんとかしていた頃とは比べものにならないくらい、今の開発は “チームで進めることの心地よさ” に溢れています。
これからもチームと共に学び、試行錯誤しながら、よりよい開発体験とプロダクト価値の提供を目指していきます。
ここまで読んでいただき、ありがとうございました！
We are hiring!
TAIANでは、このような開発・技術・思想に向き合い、未来をつくる仲間を一人でも多く探しています。少しでも興味を持っていただいた方は弊社の紹介ページをご覧ください。
株式会社TAIANのテックブログです。ブライダル業界向けのVertical SaaSを中心に、お祝いに関するプロダクトを開発中。「日本の未来をもっとアツく、あたたかく」そんな意気込みのメンバーで投稿しています。
Discussion