この投稿は、2024年JINSのアドベントカレンダー1日目の記事です。
自己紹介
JINSのデジタル本部ITデジタル部に所属しています犬置（@Onami_I）です。
JINSには新卒で入社後、数年間は店舗スタッフとして働いていましたが、デジタル領域に興味を持ち3年前にITデジタル部に異動してきました。
現在はフロントエンドからバックエンドまでみれるUIUXデザイナーを目指し、デザイン制作とアプリの開発に携わっています。
はじめに
メガネを買った時に保証書や購入履歴などが管理できるJINSアプリをご存知でしょうか？
最近までは日本と香港のみ展開していたのですが、先月ついにアメリカ版をリリースしました！
アメリカ版のアプリはこれまでのJINSアプリと違って、アジャイルという手法で開発を進めてきました。
私もフロントエンジニアとして開発に携わったのですが、初めてのアジャイル開発ということもあり最初は右も左も分からず大変でした...
ネットで検索すると、アジャイルの概要や各イベントについて色々出てきますが「具体的にこのイベントで何を会話してればOKなのか分からない..」となってしまいました。
アジャイル開発経験のある社内メンバーやベンダーさんの協力を得ながら進めることが出来ましたが、私と同じように「アジャイルの各イベント、どう進めたらいいの？」という方へ向けて少しでもナレッジを残せたらなと思い、この記事を書いていこうと思います。
アジャイル開発をどう進めて良いのか分からない時の参考になれば幸いです!
スプリントのイベント
アジャイル開発には複数の進め方があるようですが、スクラムというフレームワークを採用しました。
今回は１スプリントを２週間とし、その中で「プランニング」「デイリースクラム」「リファイメント」「レビュー」「レトロスペクティブ」の5つのイベントを実施しました。
各イベントの参加者はこんな感じです！
次に、各イベントの内容を記載します。
それぞれのイベントで会話したことをstepで分けていますので、そのままアジェンダとしてもご活用いただけます！
①プランニング
step1. 実施範囲と優先順位の確認
あらかじめ計画していた実施範囲とその中での優先順位、スプリントのゴール（この画面まで出来てたらOKなど）を確認する。
step2. ストーリーポイント見積もり
タスクに対してどのくらいの工数がかかるかストーリーポイントを見積もる。ポイントが大きくなる場合は、タスクを細分化する。
step3.担当決め
誰がどのタスクを行うかを決める。
※ストーリーポイント見積もりについて
本来ストーリーポイントは、「このタスクはどれくらい難しい？」を示すための目安で、タスクの「大きさ」や「複雑さ」を評価する単位としてフィボナッチ数列（1, 2, 3, 5, 8, 13など）を使います。
ただ今回はベンダーさんの月の稼働工数が決まっていたため、1ポイント＝1人日の時間ベースで見積もりました。
②デイリースクラム
step1. 進捗共有
前日の進捗と今日の予定を共有。
step2. 課題＆連携事項の共有
進捗の妨げや課題をチームに共有し解決策を話し合う。
step3. ステータス確認
Backlogで今スプリントタスクの進捗状況を確認。
⭐️ やって良かったこと
MTG前にスペースで「やったこと・今日やること・課題／連携事項」を送っておくことでスムーズな進行が出来ました。
(例)
■前回のデイリースクラムの後、自分は何をしたのか？
・xxxxx
・xxxxx
■次回のデイリースクラムまでの間、どんな作業を完了しようとしているのか？
・xxxxx
■進捗の妨げとなる障壁またはインペディメントは何か
・xxxxx
■連携事項
・xxxxx
初めのうちはフロントエンドの開発メンバーだけで実施していましたが
開発の進行状況に応じてバックエンド側のメンバーにも参加してもらい、それぞれの対応状況や相談事項を共有することでチーム同士の連携を深めていきました。
③リファイメント
step1. スプリントの状況把握現 （次回に影響する可能性があるものがあるか）
POから開発メンバーへの確認。予定より進んでいる場合は実現したいPBIを追加、遅れている場合は、リカバリ案を検討・または優先度の低いPBIを次回スプリントに実施しても良いかPMへ相談を行う。
step2. 次回スプリントで実現する顧客価値の詳細ディスカッション（出来栄えの認識合わせ）
実現したい機能＝優先度の高いPBIの認識合わせを行う。また、現状〜リリースまでの全体的なスケジュールも確認しておく。
④スプリントレビュー
初回のMTGではステークホルダーに向けてレビューを行う目的を説明し、2回目以降はテストアプリを用いて成果物の説明を行ないました。レビューする時はオンサイト実施が望ましいですが、ステークホルダーがアメリカにいたためハイブリッドでの実施でした。成果物の説明する時は、配信したテストアプリを各個人の端末で見てもらう際に、どの画面のことを指しているのかFigmaやシミュレーターを使いながら説明することで認識齟齬がないようにしました。
step1. スプリントで実施したこと
今スプリントで何を実装したかを報告する。以前のレビューでFBをもらって改善した箇所があれば合わせて報告する。
step2. 問題点の共有や相談
実装を進める上で発生した問題点や課題があれば共有し、開発方針についてステークホルダーと相談する。
step3. 進行中タスクと今後のスケジュール確認
レビューまでには対応完了していないがスプリント中に対応完了するものや、ざっくりでも良いので今後の開発スケジュールを共有する。
⭐️ やって良かったこと
事前に関係者へテストアプリを配信して、各自手元で操作してもらうことで
こちらが説明した箇所以外の細かい部分にもフィードバックを得ることが出来ました。
⑤レトロスペクティブ
レトロはベンダーさんの知見をお借りして下記のテンプレートを利用しましたが、他にもKPTやKDAなど他にも多くのやり方があるようなので、やりやすいものを選択するのが良いと思います。
step1. スプリントで「自分が頑張ったこと／ここが良かった！こと」「プロジェクト満足度」を記入
今のスプリントを振り返って各項目を記入していく
step2. 発表
step1で記入した内容について1人ずつ発表を行う
step3. 改善アイデア出しと投票
振り返った内容を元に改善すべき点に対するアイデアを匿名で出す。出し終わったら、改善活動として次のスプリントで何をしていくか投票で決める。
最後に
今回アジャイル開発をやってみて、特に良かった点と課題と感じた点を挙げていこうと思います。
良かった点
①効率的な開発
機能単位で開発し、定期的にステークホルダーにレビューしてもらいながら進められたため、認識齟齬による手戻りのリスクを軽減できた。
②活発なコミュニケーション
毎日のデイリースクラムを通じてフロントチームのみではなく、バックエンドチームなど関係するメンバー間のコミュニケーションが促進された。
課題に感じた点
①少なくとも開発する機能の仕様は決めておく
要件や仕様が決まらない状態で開発がスタートすることもある。
今回はIF仕様が決まっていなかったため機能単位ではなくUIを優先的に開発を行なった。
特にベンダーさんと一緒に開発する場合は工数を余らせる可能性があるため要注意。
②スコープ管理が難しい
開発中に仕様変更が行われるため、スコープの管理が難しい。
レビューでフィードバックがあった要件に対してどこまで1stリリースに入れるか、の認識が後々関係者内でズレることがあり、常に認識合わせができるようにエビデンスなど残しておいた方が良かった。
現在は別のプロジェクトでアジャイル開発を進めていますが、大枠の流れは踏襲しつつも出てくる課題や進めやすさが違うので、その時々によってやり方を工夫する必要があります。
これからも悩みながら、学びながら、開発に携わっていきたいと思っているので、また何か気づきがあれば記事を書きたいと思います。
Discussion