■ 1. はじめに
この記事はエイチーム引越し侍 / エイチームコネクトの社員による、Ateam Hikkoshi samurai Inc.× Ateam Connect Inc. Advent Calendar 2021 25日目の記事です。
2021年も早かったですね。
2021年は新規プロダクトの開発とリリースという会社としても新しい挑戦に向けて動いた1年でした。
今回は新しくサービスインしたプロダクトの開発体制についてお話していきます。
主にスクラム開発の話がメインで、実際にどういう形でスクラム開発を浸透、運用させていったかをつらつら書いていきます。
プロダクトはこちら
11月1日に第一弾、12月14日に第二弾とリリースしています！
ちなみに、フロントエンドとバックエンドの総まとめを他のエンジニアが記事にしてくれております。
■ 2. スクラム開発概要
スクラム開発に関しては他の記事や資料をご参照ください。
記事の最後に参考にした書籍やリンクを載せておきます。
2-1 なぜスクラム開発を選んだのか
エイチームグループの子会社で新規サービスが立ちあげがありました。
そこで、どういう開発体制で進めていたのか中の人から話を聞いてました。
その中で、スクラム開発の話になり、
「あー。すごいいい開発体制があるんだな、その新規サービスにすごくマッチして稼働しているな。あれ、これはもしかしてこれから立ち上げる新規サービスにも当てはまるんじゃないか？」
と思い、スクラム開発を調べていきました。
実はこれまでスクラム開発をやっていた気持ちになっていましたが、最後に紹介するスクラム開発の本を読んでこれはなんちゃってスクラム開発だったなと感じました。
改めて、スクラム開発の基礎を学び、自分のスクラム開発に対する熱量があがり、新規サービスに当て込むべく試行錯誤を重ねることで、新規サービスがリリースできる未来が見えたことが大きな変化のタイミングでした。
2−2 スクラム開発をやってよかったこと
- チームメンバーがオーナーシップを持って開発に取り組むことができる
- 問題の発見が早く、問題が起これば柔軟に対応することができる
- PDCAサイクルのスピードが早く、いまいちなところは次週に解決して進めていくことができる
- ストーリー単位で開発工数を見積るため、大枠の完了予定が見えてくる
今回リリースしたプロダクトは稀に見る壮大なプロダクトです。
数ヶ月でリリースできるものではなく、何ヶ月もかかるぐらいのボリュームで、長期目線で開発を見るべきプロダクトでした。
そのため、様々な方面でのケアが大事なので、スクラム開発をすることで大半のものが解決できるのではということで、結果やってよかったなと思うことが多かったです。
2-3 スクラム開発をやってイマイチなところ
- スクラムの知識を一定理解していないと、ひょんなところで歪がでてくる
- 必ず最初は教育コストを払ってでもスクラム開発を全員に理解してもらうことが大事
- 制作職が知ることはもちろんですが、関係者（ステークホルダー含む）にもスクラム開発を理解してもらったほうが話は早く進みます
- スクラムイベントにかける時間が結構多い
- もちろんスクラムイベントの意義は理解していますが、どうしても制作に割く時間が大事だと今でも思います
- とはいえ、スクラムイベントの大事さも理解しています
- スプリントを重ねるごとに試行錯誤をして自分たちの最適解を探して効率化を図りました
守破離という言葉があるように、まずは型をそのまま実施して型を学んで行きました。
その中で色々な制約があるので、自分たちの型を試行錯誤しつつ探していきました。
試行錯誤をしている中で変化についてきてくれたメンバーには本当に感謝しております。
■ 3. スクラムチーム
3-1 開発者
- エンジニア9人
- フロントエンドエンジニア（マークアップ込み）：4人
- バックエンドエンジニア：2人
- フロントエンド＋バックエンドエンジニア：3人
実は当初スタートしたときは6人でした。
モダンな技術を採用し、全員のスキルレベルが上がってくるまではなかなかベロシティも上がらず、苦戦しておりました。
また、仕様の増加に伴って、リリースに間に合うためにはどうしたら良いのかと議論を重ね、結果的に他の事業に携わっていたエンジニアをアサインして、ベロシティを上げていきました。
ベロシティが上がらないときは、そもそもの人数を増やすか一人一人のスキルレベルアップを図ることが大事
3-2 プロダクトオーナー
プロダクトオーナーはもちろん1人です。
プロダクトオーナーは、本プロダクトの業界に対して精通している人でかつ、仕様を決めれる立場の人にお願いしました。
基礎に則ったスクラム開発はプロダクトオーナーも初めてだったため、説明しながら徐々にプロダクトオーナーの役割を務めていただきました。
プロダクトオーナーはエンジニアではりませんが、スクラム開発の理解を深めてもらい、スクラム開発の中に入ってもらいました。
プロダクトオーナーはプロダクトの意思決定者でもあるので、プロダクトの全体像を把握し、業界に精通している人が望ましい
3-3 スクラムマスター
スクラムマスターも1人です。
当初、スクラム開発をやるぞとなったときに導入を進めていた関係もあり、自分がスクラムマスターをやっております。
プロダクトの進捗管理や、開発チームと他チームとのクッション役、会議のファシリテート等を担当しております。
スクラム開発を軌道に乗せるまでは様々な改善が必要
根気強くやれないと開発チームが破綻してしまう
■ 4. スクラムイベント
| 月曜日 | 火曜日 | 水曜日 | 木曜日 | 金曜日 | |
|---|---|---|---|---|---|
| 午前 | デイリースクラム スプリントプランニング |
デイリースクラム | デイリースクラム | デイリースクラム | デイリースクラム |
| 午後 | スプリントレトロスペクティブ | スプリントレビュー |
- スプリントプランニング（12:30~13:00）
- デイリースクラム（10:45~11:00）
- スプリントレビュー（15:00~15:30）
- スプリントレトロスペクティブ（14:30~15:00）
4-1 スプリント
- 期間：1週間
開発を進めていく中で一度スプリント期間を2週間にしたことがあります。
ただ、2週間にすると、期間が長いことによってスプリント完了の期限が先になってしまい、見通しが悪かったです。
また、早くサイクルを回していきたかったこともあり、1週間に戻しました。
ちなみに、1週間で終わらないものももちろん出てきます。
そのときは次週のスプリントに残タスクとして繰越で対応しておりました。
4-2 スプリントプランニング
- 参加者：スクラムマスター＋開発チーム
- 頻度：30分/毎週
事前にプロダクトオーナー、スクラムマスター、関係者で話し合いをして大枠の方針は固めています。
スプリントプランニングが始まる前にざっくりとそのスプリントで完成させたいことを考え、ストーリーを事前に組み込んでおきます。
（だいたい向こう6回分のスプリントは用意しておりました）
スプリントプランニングでは、新規で追加された優先度の高いストーリーを入れ換えてる作業をしてます。
そして、元々いれていたストーリーを含めて、そのスプリントで達成ができるか議論します。
もし、達成が厳しそうであれば、一部ストーリーを次のスプリントにいれて調整していきます。
スプリントプランニングで合意を得たら、あとは開発チームが責任を持って達成に向けて開発を進めていきます。
4-3 デイリースクラム
- 参加者：スクラムマスター＋開発チーム
- 頻度：15分/毎日
弊社は在宅ワークと出社のハイブリッドな働き方をしているため、デイリースクラムはZoomで顔を合わせて実施しております。
最初は全員が1回づつ話をして回しておりましたが、時間がかかる＆やることの共有みたいになってしまっていたので、共有事項がある人のみに絞り、周知させておきたいことのみを話す場に変えていきました。
また、最近では全員が共通で利用する環境設定のすり合わせをこのタイミングでやっていたります。
4-4 スプリントレビュー
- 参加者：プロダクトオーナー＋スクラムマスター＋開発チーム＋デザイナー＋関係者
- 頻度：30分/毎週
事前に開発したものをテスト環境にあげておき、スプリントレビューでは、開発した機能の発表やテストする際の注意点を共有する場にしています。
スプリントレビューが終わったら1週間のスプリントを完了させます。
もし、スプリントレビューでFB修正が発生した場合は次のスプリントでストーリーを切って対応していきます。
スプリントレビューが終わったら、次のスプリントが開始されます。
4-5 スプリントレトロスペクティブ
- 参加者：スクラムマスター＋開発チーム
- 頻度：30分/隔週
KPTで実施しており、事前に資料を記載してスプリントレトロスペクティブを行っております。
元々は1週間に1回約1時間ぐらい（プラス事前資料の記載が30分ぐらい）やっておりました。
しかし、開発を進めていく中で時間がかなりかかるイベントだったので、タイミングを見てやり方を変更しました。
正直、スクラムがあまり浸透できていない時期は1時間/週でやったほうがいいと思います。
おそらくたくさんのProblemがでてくると思いますので、しっかりと一つ一つに対してTryを重ねていくことが大事です。
割となれてくるとクリティカルなProblemも減っていき、Tryを合わせて書いてくれる人も多くなってくるのでタイミングを見てイベントを変更してもいいと思います。
■ 5. スクラムの達成物
5-1 プロダクトバックログ
プロダクトバックログは常に開発の優先順位を意識して並び替えを実施しておりました。
並び替えの際にはスプリントの枠を6回分ぐらいは作成していたので、プロダクトバックログにあるものは新規で追加したストーリーが基本でした。
新規で追加されたストーリーはどの待機スプリントに入れるのかを決定させることを決めておりました。
5-2 スプリントバックログ
スプリントバックログは次の6回分ぐらいの枠を作っておき、そのなかにプロダクトバックログの優先度が高いもの順にいれていき、開発チームの指標であるベロシティの範囲内でストーリーを追加していきました。
例えば、ベロシティが50PTのときはそのまま50PTのストーリーを当て込むのではなく、ある程度バッファを見て40PTぐらいで収めておくことをおすすめします。
ベロシティはざっくりとした工数見積のPTなため、増減があるのは当たり前です。（むしろ想定外のことが起こることが多いので増えることが多かったです）
5-3 インクリメント
インクリメントはそのスプリントで達成したものがプロダクトに対してプラスになることを指しております。
もちろん、プロダクトに組み込むので、生半可なものをリリースしてはいけません。
そのために、プロダクトに組み込むための条件を定義した”完成の定義”というものを設定していきます。
当初、スクラム開発を想定していたときは完成の定義をガチガチで固めておりましたが、実際にスクラム開発を初めてみると、あれ・・うまくできないぞということが多くありました。
もちろん、質を重視するのであれば全部をガチガチで固めたほうがいいのはわかりますが、プロダクトを成長させていくためには良いタイミングで出すことも大事なので、必要とする質を確保しつつ”完成の定義”を変更していきました。
完成の定義（当初）
- コードレビューで最低一人以上からApproveもらっている
- ユニットテストが書かれていること
- POによる受け入れテストができている状態
- 静的解析ツールが通っていること
- 指定したフォーマットでドキュメントが書かれていること
- （クロスブラウザで確認ができていること（Edge、Chrome、Safari））
- （PSIで85点以上がある状態）
- （本番環境にリリースできている状態）
- （セキュリティチェッカーが完了している状態）
完成の定義（現在）
- コードレビューで最低一人以上からApproveもらっている
- テストコードが書かれていること
- ユニットテスト, E2E, Storybook
- POによる受け入れテストができている状態
- CIが通っていること
最低限のコードの質を担保できるまで完成の定義を緩めました。
事業の方針や開発チームのスキルレベルに合わせて変えていくことが大事です。
■ 6. その他
ツールについて
-
JiraSoftware
- スクラムテンプレートもあり、すぐにスクラム開発に則って開発を進めることができる
- 840円/人（10人まで無料）
-
Gitlab
- Gitlab内にあるWikiも利用して開発に関する情報を集約させている
- JiraSoftwareとも相性がよく、MR（マージリクエスト）とストーリーの紐付けを行うことができ、マージされたら自動でステータスを完了にしてくれる
■ 7. 参考
- スクラムガイド
- SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
- ゲーム開発プロジェクトマネジメント講座
■ 8. まとめ
- スクラム開発の基礎を徹底的にインプットしよう
- スクラム開発を開発チームだけでなく、関係者（ステークホルダー）にも理解してもらおう
- まずはスクラム開発の基本をトレースして実施してみよう
- スクラム開発の基礎を回していくともどかしい部分が出てくるはずなので、自分たちの色をつけていこう
- とはいえ、迷ったときはスクラム開発の基礎を改めて学び、考えてみよう
今回の新規サービスでは、スクラム開発を導入させていただきました。
正直いうと、まだまだ改善の余地がある部分は多くあります。（スクラムマスターとして不甲斐ない部分はたくさんあります）
開発メンバーのみんなのおかげでとても楽しく毎日の開発ができていることは事実あります。
スクラム＝チームでものを作っていくことだと認識しているので、やはりチームメンバー全員がお互いを認めあい開発をすすめることこそ大事だなと思います。
■ 9. 最後に
本日で本アドベントカレンダーは終了です！
実は来年から株式会社エイチーム引越し侍は株式会社エイチームライフデザインという会社に社名が変更されて組織が再編成されます。
過去5年間株式会社エイチーム引越し侍としてやってきたアドベントカレンダーもこれで終わります。
変化と挑戦を楽しんで日々仕事できる良い会社にしていきたいと思います！
では、素晴らしいエンジニアライフを！