最近寒くて布団から出るのが辛いPdMのハットリです。
今回は、緊急系サービスをリリースするにあたってどんな取り組みをしていたかを書いていきたいと思います。
緊急系サービスを一言で説明すると「24時間以内の作業を実現させるサービス」です。
詳しい説明は、PR担当の小田さんが書いた素晴らしいnoteがありますので、興味がある方はこちらをお読みください。
では緊急系チームについて書いていきます。
開発メンバー
- カテゴリーマネージャー
- PdM
- デザイナー
- エンジニア
開発手法
アジャイル開発
日々やっていたこと
デイリーMTG
毎日15時からチーム全員で集まりMTGをしていました。
進捗管理シートというもの作りそれを見ながら進捗確認を行っていました。
みんマではGitHubのissueベースで開発要件を整理しています。
3rdpartyプラグインのZenHubを使うことも考えたのですが、issue数や期限などが一覧で見にくいのとステータスの変更漏れなどがあるので、手間ですがスプレッドシートで管理するようになりました。
それを見ながら自分が担当しているissueの進捗共有と、困っていることがあればチームメンバーに相談して早期に解決するようにしていました。
毎日やると開発時間が減るのでは？と感じるかもしれませんが、15分〜30分程度の短時間で終わるのでそんなに影響ないのかなと思っています。
ウィークリーMTG
週次でチーム全員+CTOで集まりMTGをしていました。
デイリーMTGとは異なりissue単位での進捗共有ではなく、各自が今週やったことと来週やることを報告していました。
マンスリーKPT
月次でチーム全員で集まりKPTをしていました。
KPTとはプロダクトの進め方がどうだったのかを振り返り、「Keep」「Problem」「Try」の3項目を出し合い今後どう取り組んでいくかを決めます。
miroというツールを使い、各自KeepとProblemを出し合い全員でTryを考えました。
業務のKeepとProblemだけではなく、自然発生的にプライベートのKeepやProblemも出ていました。
ルールでプライベートのKeepやProblemも出してねって決めるのではなく、自然発生的に出てくるのがみんマっぽかったです。
月次で振り返ってみるとメンバーが同じようなKeepやProblemを持っていたことが分かりました。チーム全員が同じ認識を持っているのでTryに納得感があり来月からの行動に移しやすかったと思います。
業務のTryは改善策を真剣に考えて来月に生かす、プライベートのTryはちょっとふざけた改善策を出したりネタっぽくなっていたのもよかったです。
チーム発足後すぐにフルリモートになり、物理的に雑談する機会も減っていたのでKPT内で自然に雑談が生まれていたのもKPTのよかった点だなと思います。
うまくいったこと
リリース前にユーザーテストを行い最善の状態でリリースできたこと
プロダクトのリリース前に社員を対象にSUS評価を使ってユーザーテストを行っていました。
4回実施しリリース直前のユーザーテストでは、100点中82点を獲得しA評価のプロダクトになりました。
緊急系カテゴリの狙っていたポイント（会員登録から電話予約までスピーディーでスムーズ、わかりやすいUIなど）が評価されていたのが良かったです。
第三者からの意見をもらうことで、プロダクトの方向性が間違ってないことが分かり自信にも繋がりました。
開発していると気がつけない部分や抜け漏れなど、他部署からのフィードバックはありがたかったです。
エンジニアとデザイナーがプロダクトの仕様理解度が高いこと
日々やっていたことの影響かもしれませんが、エンジニアとデザイナーのプロダクトの仕様理解度が高いなと感じました。
高い理由としては、エンジニアだからデザイナーだからという枠にとらわれず、自分が作っているプロダクトに興味を持っていたからだと思います。
その結果として実装時の要件漏れなどが少なかったです。
さらには「ユーザー的にはこうした方が使いやすくないですか？」など仕様の提案もしてくれました。
カテゴリマネージャーやPdMに仕様の最終的な決定権はあるのですが、少人数で考えると考慮漏れや抜け漏れが発生してしまいます。
エンジニアとデザイナーからの仕様の提案で考慮もれや抜け漏れが発生していたのに何度か気づくことができました。
どうせ仕様提案しても採用されないんでしょって投げやりになるのではなく、提案してくれたのは個人的にすごい嬉しかったです。
うまくいかなかったこと
issue内容やUIの更新ができていなかった
仕様やUIが変わった時に更新漏れがあり、issueの詳細やUIの内容が整理されておらず実装と解離がありました。
その結果、テストケース作成やテスト実施に影響があり想定以上にテストに時間がかかりました。
また、Webブラウザ、iOSアプリ、Androidアプリで実装に差異がある事もあり、都度仕様を確認する必要が発生しました。
アジャイル開発で開発を行っており、開発途中で仕様の変更・追加が多々あります。
その際にissue内容やUIの更新より先に実装を進めてしまったことに原因があると思っています。
開発スピードを求めた結果このようになってしまいました。
第二弾の緊急系カテゴリではその反省を生かし、仕様やUIが変わった際には開発に入る前にissueやUIの更新を行うようにしています。
リリースが1週間遅延してしまった
issue内容やUIの更新ができていなかったことが影響してリリースが1週間遅延してしまいました。
リリース後のKPTでチーム全員からリリースが遅延してしまって悔しいというProblemが出ました。
ほんとにあと少しのところで間に合わなかったです。
規模の大きい開発なので1週間は誤差でしょって考えもありますが、自分たちで決めたリリーススケジュールにあと少しのところで間に合わなかったのが悔しかったです。
今回の悔しさを晴らすために、第二弾の緊急系カテゴリはissueやUIの更新漏れをなくしスケジュール通りにリリースできるようにします。
最後に
緊急系サービスは生まれたばかりですが、今後飛躍的に成長するプロダクトだと思います！
一緒に開発したい方はぜひコーポレートサイトまでお気軽にご連絡ください！
