はじめに
JINSで開発のプロジェクトリーダーを担当している森田です。
Zennの投稿は2回目になります。
前回の記事はこちら
今回、店舗システム刷新プロジェクトで2チーム合同でアジャイル開発をやってみたので、その紹介をしたいと思います。
プロジェクト概要
店舗システムの刷新プロジェクトは、名前のとおりJINSの店舗で使うシステムの刷新になります。
具体的には店舗のスタッフが使う業務アプリや、お客様が使うメガネを買う際に使う受付サービスなど販売に関わるものが対象で、お客様の体験向上や店舗スタッフの業務効率に直結するものなので、現場からの要望に柔軟に対応する必要がありました。
※イメージ図（こちらは日本の店舗で使われているものです。）
アーキテクチャと開発手法
新しい基盤では、UI層・BFF層・デジタル基盤層の3つに分かれています。
デジタル基盤層はOder Management System・商品カタログなど、サービス単位で分かれており開発チームもサービスごとに存在するので、業務アプリを作るのにトータル7つのチームが開発を同時進行することになります。
その中で、UI層を担うチームとBFF層を担うチームについては業務要件をダイレクトで受けるのと、前述のとおり販売系システムは現場の要望に柔軟に応えていく必要があり、この2チームについてはアジャイル開発を採用しました。
2チーム合同のアジャイル開発
経緯
アジャイル開発ではスクラムのフレームワークを活用しました。今回初めての試みとしてFront・BFF（＋α）の2チーム合同でスクラムイベントを実施しました。
元々、バラバラで開発を進行していましたが、最後の疎通確認で上手くいかなかったため、仕切り直しのタイミングで合同で開催する運びとなりました。
体制と役割
スクラムマスター（森田）…プランニングの準備や仕切りを行う。チーム全体の支援及び進捗管理に責任を持つ。
開発チーム…開発に責任を持つ。各チームタスクや進捗を管理するリーダーを立ててもらう。
合同スクラムイベント
参加者は各チームのリーダー含めた主要メンバーに限定しました。
各イベントで決まったことは、各チームのリーダーから開発メンバーに落としてもらっていました。
1Sprint＝2週間で実施
プランニング事前準備
次のSprintで開発するPBI（プロダクトバックログアイテム）の要件を整理します。
デザインの修正が必要な場合はデザイナーさんに協力いただき、要件とセットで用意します。
要件はビジネスオーナーやプロダクトオーナーと一緒に、UI・業務フローをベースにあるべき姿を議論しながら決めていきました。
プランニング（1W火曜日）
Sprintの初日に開催し、直近のマイルストーンの確認や今Sprintで開発を進めるPBIの目的や要件を擦り合わせし、チーム全体の認識を揃えます。
デイリーMTG（毎日AM10:15）/リファイメント（月水木PM16:00）
参会者全員がアジェンダを自由に持ち込み、QAや仕様の確認、ネクストアクション等を擦り合わせる場としていました。
リファイメントは通常Sprintの2週目に1回行うものですが、今回は週3回30分枠で設けました。直接会話する機会を増やすことで開発のスピードアップに繋げていました。
レトロスペクティブ（2w金曜日）
Sprintの終わりにチーム間をまたぐ課題について全員で話し合うようにしていました。
上記のリファイメントの運用ルールもメンバーが提案して、全員で合意のうえ決めました。
その他
火金は対面でコミュニケーショする場として、同じオフィスに関係者全員が集まるようにしていました。
振り返って
良かった点
①APIのIFの認識齟齬が減った
合同でプランニングを行うことにより、要件の理解、懸念事項や開発方針の擦り合わせ等をその場で議論することができ、結果として疎通確認の手戻りが減ったように思えます。
②任せられる体制を構築できた
開発チーム間でコミュニケーションが活発になると物事がどんどん決まっていき、設計以降は任せることができるようになりました。スクラムマスターとして基本見守って必要なときはサポートに徹するだけで済むようになりました。
③都度ルールの整備ができた
疎通確認の進め方やQA管理方法など、レトロスペクティブで都度課題を話し合うことでルールが整備でき、スムーズなプロジェクト進行ができました。
改善点
①他のチームも巻き込むべきだった
BFF層-デジタル基盤層のIF間の認識齟齬については依然として課題となり、PBIの開発内容によってはデジタル基盤層の開発チームも巻き込んでいけば疎通確認がもっとスムーズに進んだのかなと思います。
実際、シナリオテストの障害分析を行ったところ、設計ミス（考慮不足による誤り）が10件発生していて、動き方次第では未然に防げたかもしれません。
障害分析結果
②仕様変更の管理を徹底すべきだった
店舗からのFBなど開発途中で発生した仕様変更は、開発チーム経由で伝達してもらうと一部漏れてしまったり優先度も曖昧になってしまったりするため、プロジェクトとして正式に管理すべきでした。
プロジェクトの振り返りで実際に出た意見
PMPのやり方ほど厳密にしなくて良いですが、プロジェクト共通のドキュメントに残していつでも参照できるようにし、優先度や各チームの影響範囲、修正目途などを見える化しておくと良いと思いました。
最後に
この記事では開発の話を中心に書きましたが、プロジェクト自体は去年の7月から始動しており、サービスのコンセプト決めや業務要件整理から始まって直近のローンチまで約1年を費やしてきました。
私自身アジャイル開発や業務要件定義など初めてのチャレンジが多く、関係者には迷惑を掛けてしまうこともありましたが、ゼロからサービスを形にできたこと、一つの目標に向かってチーム全員で協力し合えたことはかけがえのない経験だと思っています。
実際にローンチした店舗でメガネを購入してみました
最後まで読んでいただき、ありがとうございました。
Discussion