💡 始めに
こんにちは！
株式会社ペライチ のスクラムマスター（エンジニアリングマネージャー）の前田です。
ペライチの開発手法にはスクラムを採用しています。
スクラムを採用しているところは基本的にスクラムガイド を参考にしていると思います。
ただ、スクラムはあくまでフレームワークであるので実態は組織ごとに違っていることがほとんどです。
今回の記事では、ペライチではどのようにスクラムを利用しているのか詳細に紹介させていただきます。
ペライチの特色や雰囲気に興味を持っていただいている方、スクラムを実際に運営されている方のご参考になれば幸いです。
💁🏼♂ ️体制
基本的な体制は下記となっています。
※ 2022/11 月時点。
プロダクトオーナー
- 事業計画の策定/プロダクトロードマップの大枠決定
- 基本プロダクトマネージャーが兼務
- プロジェクトによって変わるため、位置付けがあいまい
- CEO、マーケティングチーム、カスタマーサポートチーム、etc
プロダクトマネージャー（3名）
- 事業計画の策定/プロダクトロードマップの大枠決定
- 各スクラムチームに 1 人想定ですが、人数の都合上スクラムマスターと兼任しているチームもあります
UXデザイナー（2名）
- スクラムの開発チームとは別で UI や UX を検討していただくデザインチームがあります
各スクラムチーム（4チーム）
- スクラムマスター（1 名）
- クリエイター
- バックエンドエンジニア（1 ~ 3 名）
- フロントエンドエンジニア（1 ~ 3 名）
🗓 1スプリントの流れ（2週間）
■ 前提
- 基本的にペライチはリモートワークとなっています。
- 後述の説明はリモートでの作業をイメージしてください。
- 主に使われるツールは下記です
- zoom
- Slack のハドル
- ときどき google meet
■ スケジュール感
■ スクラムイベント
1 スプリントに 1 回、だいたい 2~3h くらいかけて行われます。
- スプリントゴールが達成できたか確認
- プロダクトバックログの確認/見積もり（ストーリーポイント）
- 次スプリントのアサイン
- 次スプリントゴールの設定
が主な議題となります。
プロダクトプロダクトバックログは GitHub の issue で作成しています。
プロジェクト管理ツールにはZenHubというツールを用いています。
スクラム用語だと「スプリントレトロスペクティブ」「スプリントプランニング」的なことが行われています。
ただ、言葉が開発チーム以外はわかりづらいこともあり「スプリントレトロスペクティブ」「スプリントプランニング」という用語はほとんど使っていません。
また、チームによって人数が違うので振り返りやタスク決めはこの時間で終わらないこともあり、別途時間をとって行っているチームもあります。
スクラムイベントには「プロダクトオーナー」「プロダクトマネージャー」が参加するのがセオリーですが、
基本的に「プロダクトオーナー」は不参加、「プロダクトマネージャー」は半数ほどのチームに参加しているのが現状です。
理由としましては、後述する会議体があり（プロダクトプロダクト MTG）ここで優先度決めや交渉が行われるためです。
振り返り方法に関しては各チームによって異なります。
スクラムマスターのやりやすい方法を採用しています。
ちなみに、自分のチームでは振り返りには KPT を利用しています。
■ プロダクトMTG
1 スプリントに 2 回行われます。
スクラムガイドに当てはめると「スプリントプランニング」にあたると思います。
中長期的なロードマップの検討をしています。
案件の提示はプロダクトマネージャーによって行われます。
スクラムマスターはチームの状況や案件の工数感を鑑みて、プロダクトマネージャーとともに案件のスケジュールや機能内容を検討していきます。
■ スプリントレビュー
1 スプリントに 1 回、だいたい 2~3h くらいかけて行われます。
2 部制となっており、ほぼ全部署の人が集まる会議体です。
「全社の視点からよりユーザー目線でプロダクト価値向上に向けたフィードバックを受ける」ための会議体です。
（スクラムの範疇を超えている感はあります。。）
第一部：開発中またはリリース直前の機能をデモ
- 目的
- 開発中のものが徐々に形になる中で、早めに FB を受ける。
- リリース後のものであれば、次の改善案件につなげる。
- 参加者
- プロダクトオーナー
- プロダクトマネージャー
- スクラムマスター
- クリエイター
- 他部署（マーケティングチーム、カスタマーサポートチームなど）
事前にデモ内容を共有しておき、 実施時には各チームの担当エンジニアがデモをしていきます。
// 記載例
### メルマガUI改善
- デモ概要: メルマガ編集機能の動作
- 担当:
- 確認事項(あれば): ソースコード編集機能の挙動について
- 時間目安: 10分
デモする際は下記のポリシーにのっとってデモやフィードバックが行われます。
Zoom で行われるのですが、開発している中では見逃してしまうような点も指摘していただき、よい場になっていると思います。
第2部：全体感/リリース直前直後の連携確認編
- 目的
- 円滑にユーザーに機能を使ってもらうために、リリースまでに必要な各チーム間の連携内容を確認する。
- 参加者
- プロダクトオーナー
- プロダクトマネージャー
- スクラムマスター
- 他部署（マーケティングチーム、カスタマーサポートチームなど）
調整関連のやりとりがメインの会議となっています。
■ デイリースクラム
1 日 1 回行われます。
こちらはスクラムガイドにのっとって 15 分で終わらせるようにしています。
自分のチームは AM11:00 ~ ですが、チームによってバラツキがあります。
(とはいえ 10:00 ~ 12:00 の間には収まっていると思います。)
困っていることや他メンバーの意見がほしいときなど、デイリーが 15 分で終わらないときは必要なメンバーで残ってそのままやりとりが行われることもあります。
（スクラム的には 15 分で終わらせるのがよいのですが、長引くことはまあまああります。。。）
ちなみに、自分のチームではデイリーを円滑に進められるようにデイリー前に↓の内容を Slack に投稿していただくようにしています。
【着手】
・
【未着手】
・
【レビュー中】
・
【完了】
・
【進捗率】
・ 〇〇 %
■ 前回やったこと
・
■ 今回やる事
・
■ 困っていること
・
🙆♂ ️まとめ
いかがだったでしょうか？
スクラムガイドに当てはめるとアンチパターンぽいところがあるかと思います。。。
- スクラムイベントに「プロダクトオーナー」「プロダクトマネージャー」が参加していない
- デイリースクラムが15分以上かかることがある
- 「プロダクトオーナー」「ステークホルダー」があいまい
- （他にもあるかもしれません。。）
ただ、
スクラムイベントに「プロダクトオーナー」「プロダクトマネージャー」が参加していない（別会議体のプロダクトMTGで対応）
➔ まるっと全チームのスクラムマスターを含めた会議体を設けることで不要なMTGの時間を減らせる
➔ チーム横断の案件の話がしやすい
➔ 他チームからのアドバイスが得やすい
デイリースクラムが15分以上かかることがある
➔ デイリー後に困っていることなどに対して時間を割くことで個人に負担を負わせないチーム運営ができる（心理的安全性を担保）
「プロダクトオーナー」「ステークホルダー」があいまい
➔ プロダクトを意識した主体的な開発を行うことができる
のような、色々と試行錯誤してきた中で今のペライチにあったスクラムを運営しています。
※ 詳細はこちらの過去記事をご参考ください🙇♂️
それなりに長いことスクラム開発を続けて得た知見とこれから。
今の状態が完璧だとはもちろん思っておらず、まだまだ改善するところもあるのでこれからもよりよいスクラム開発を目指していきたいと思います。
最後まで見ていただいてありがとうございました。
採用情報
現在エンジニア募集しています！
▼ 採用ページ
▼ 選考をご希望の方はこちら（募集職種一覧）
▼ まずはカジュアル面談をご希望の方はこちら
募集中の職種についてご興味がある方は、お気軽にお申し込みください（CTO がお会いします）
Discussion