こんにちは、GraciaのCTOの林です。
今回はGraciaの開発体制について書こうと思います。
現在の組織体制について
弊社ではギフトEC「TANP」を運営しているのですが、TANPの開発に関わるメンバーは、CTOが管轄するプロダクト部に所属しています。
プロダクト部には「アプリケーションエンジニア」「SRE」「デザイナー」の3つのグループが存在します。
弊社では、ECサイトだけでなくロジスティクス（物流）に関わる管理システム等も含め全てフルスクラッチで開発を行っているのですが、主にサービス全体の新規機能開発や既存機能改修は「アプリケーションエンジニア」が担当しています。
今回はそのアプリケーションエンジニアの開発の流れについて書こうと思います。
開発体制について
アプリケーション開発において、弊社ではスクラム開発を採用しています。
プロダクトオーナーがステークホルダーと議論しながら施策をプロダクトバックログに並べていき、1週間ごとに計画を立てて開発を行っていきます。
また、開発者体験や品質を高めるために、プロダクトバックログにはエンジニアから起案する技術的な取り組み（= Tech Issue）も並べ、毎スプリントの30%の時間をTech Issueに使うように計画を立てています。
スクラムのイベントについて
弊社で実際にスクラムの各イベントをどのように行っているかをご紹介します。
スプリントプランニング
弊社のスプリントは木曜起点からの1週間なので、スプリントプランニングは毎週木曜日に行っています。
ミーティングや休みの予定などを考慮してチーム全体で次のスプリントで使える時間を算出し、その時間内で収まるように次の1週間のゴールと取り組むタスクを決め、スプリントバックログに乗せます。
プロダクトバックログ、スプリントバックログの管理にはGitHub Projectsを利用しています。
デイリースクラム
弊社ではフレックスタイム制を導入しており、エンジニアのコアタイムは12時から17時なので、デイリースクラムは毎日12時から行っています。
デイリースクラムではスプリントバックログの進捗や各々のタスク状況を確認し、障害になっている課題があれば相談しながら解決策を考えます。
スラックのリマインダーでテンプレートを用意し、デイリースクラムが始まるまでにスレッドに各々記載しておき、時間になったらハドルで集まって口頭で共有します。
リファインメント
リファインメントは毎週火曜日と金曜日のデイリースクラム後に1時間行っています。
プロダクトバックログに載っているIssueのうち、まだ要件を詰めきれていないものや見積もりが完了していないものに関して、口頭で話しながら要件を詰めて工数を見積もり、次以降のスプリントで着手できる状態にします。
見積もりの際は、実際にかかるであろう時間を各々算出し、全員で一斉にスレッドに投稿してすり合わせを行います。
各々が算出した時間を比較し、ずれている場合はなぜズレたかを議論することで要件の漏れや実装方針に認識齟齬がないかを確認します。
また、見積もりのタイミングで各々の興味も絵文字で可視化するようにしています。
- 興味ある => 😉
- 普通 => 😐
- あまり興味ない => 🤬
これは、タスクのアサインを決める際に考慮したり、各々がどういうタスクに興味があるかの相互理解を深めたりするために行っています。
スプリントレビュー
毎週木曜日にスプリントが終わるタイミングで、ステークホルダーを集めてスプリントレビューを行っています。
スプリントレビューでは、今回のスプリントで開発した施策に関してステークホルダーから意見をもらい、改善したほうが良い点があれば次以降のスプリントでIssueを起案して進めていきます。
スプリントレトロスペクティブ（振り返り）
毎週木曜日にスプリントが終わるタイミングで、開発チームでスプリントレトロスペクティブ（振り返り）を行っています。
スプリントレトロスペクティブでは今回のスプリントにおける開発や組織に関する振り返りを行います。
振り返りはmiroを使って行い、KPTの観点で意見を集めます。
- Keep：よかったこと
- Problem：改善点・課題
- Try：（Problemに対する）今後の解決策・アクション
集まった意見を元に改善点などを議論し、次以降のスプリントに活かしていきます。
また、ここで決まったルールや方針をチームとして忘れないようにするために、ワーキングアグリーメントとしてボードで管理しています。
スクラム開発の成果
スクラムの導入は開発プロセスの多くの側面において大きな成果をもたらしましたが、特に以下の4つの点において顕著な効果があったと感じています。
属人性の排除
スクラムでは、個々のメンバーが持つ特定のスキルや識に依存することなく、チーム全体でタスクを進めることを重視します。
リファインメントの中でチーム全体で要件を確認していくことで、どのメンバーもプロジェクトの全体像を理解し、必要に応じて様々なタスクを担当できるようになったと感じています。
結果として、メンバーの不在時でもプロジェクトが滞ることなく進行できるなど、様々なリスクを抑えることが可能になったと考えています。
チームとしての振り返りと改善意識の向上
上記のスプリントレトロスペクティブ（振り返り）でも書きましたが、スクラムではスプリントの終了時に振り返りを行い、何がうまくいったか、どう改善できるかをチーム全員で議論します。
これにより、チームとして改善を進めていく文化が生まれ、より開発や組織を良くしていこうという意識がチームに根付いたと感じています。
ゴールの明確化によるモチベーションの向上
スクラムでは、タスクやスプリントが完了したときの条件を明確に定義します。
これにより、チームメンバー全員が何を目指しているのか、そしてその目標に対して現在どの位置にいるのかを常に意識するようになりました。
このクリアな目標設定は、チームの生産性と効率性を向上させるのに大きく貢献しました。
開発状況の可視化とスケジュール管理
GitHubでタスクと工数を可視化することで、プロジェクトの進行状況をリアルタイムで把握しやすくなりました。
これにより透明性が向上され、ステークホルダーとのスケジュールの調整や優先順位付けなどのコミュニケーションや情報共有をスムーズに行えるようになりました。
まとめ
今回は弊社の開発体制についてご紹介しました。
開発体制も事業も順調に改善が進んでいるのですが、まだまだやりたいことに対して開発メンバーが足りていません。
これから事業成長をより加速させていくために、TANPの開発をリードしていただける方を募集中です！
少しでも興味を持っていただけた方はお気軽にご連絡ください！
- CTO林のTwitter：https://twitter.com/takumin513
- 公開中の求人：Webアプリケーションエンジニア - 株式会社Gracia
- エンジニア向け説明資料：株式会社Graciaエンジニア向け説明資料 / Gracia Engineer - Speaker Deck
