hacomono TECH BLOG

フィットネスクラブ・スクールなど施設・店舗のための会員管理・予約・決済システム「hacomono」 開発チームの技術ブログ

hacomono のプロダクト開発サイクル 2021 秋 ver.

こんにちは、hacomono CTO の工藤です。最近は空いた時間で息子とマイクラで遊ぶ日々を過ごしてます。

久しぶりのブログですが、今回はカジュアル面談などで良くご質問いただく「hacomono ってどんなフローで開発しているんですか?」に対する回答として、2021年10月現在の開発フローについて記事を書きたいと思います。

www.hacomono.jp

hacomono ではスクラム開発を採用し、2週間スプリントで開発を回しています。下図が開発サイクルの全体像になりますが、順に説明していきたいと思います。

f:id:hacomono-tech:20211015090336p:plain

プロダクトの構成

まず先にプロダクトの構成について触れておきます。現状 hacomono というプロダクトはざっくり下図の構成となっており、用途によってサイトが大きく5つに分かれています。現状サイトや機能毎に体制を分けておらず、必要に応じて全てのコードベースを触るモノリシックな構成です。(GitHub リポジトリも monorepo 構成となっています)

f:id:hacomono-tech:20211011225145p:plain
インストラクターの方向けの管理サイトも提供しています

プロダクトの要望・要件管理

各チームや事業戦略ベースから集まってくる要望・要件は Jira の PdM ボードで管理しています。Biz サイドから挙がる要望などは一時的に Notion に蓄積されることもありますが、最終的に Jira に集約するようにしています。

また、なるべく起票する側に負荷をかからない形で投稿してもらえるよう、重複した内容があったとしても気にせず Jira にどんどん挙げて OK、という運用としています。これは代わりに PdM が大変になってしまうのですが、後から同一の要望であることを示すラベルを付けるようにし、各要望に対してどれくらいの声が挙がっているのかを把握するのに役立ちます。

各要望がどのステータスにあるかは、下図のようなステージで管理していきます。挙がった要望が今どのステータスにあるか正しく把握できるようにしているのと、最終的にリリースされた後に要望を挙げていただいたお客様へのフィードバックなども行っています。

f:id:hacomono-tech:20211011212318p:plain

ロードマップの検討

蓄積された要望に対して、優先順位を付けながらプロダクトバックログ化を検討していきます。

  • 優先度付けの基本は、開発コスト・改修インパクト・お客様の温度感のバランスから判断
  • whimisical などのツールを使ってざっくりワイヤーを引きながら改修方針を検討していく
  • 大きめのバックログについては、別途実施しているロードマップ検討ミーティングの中でも議論していく
  • 必要に応じて社内の有識者から意見をもらったり、ユーザーヒアリングを行う

フィットネス市場といっても、総合フィットネス・24H・パーソナル・スクールなど業種は様々です。広く浅いプロダクトで終わらせず特定業種に深く刺さるプロダクトにするため、特定業種の要件を集中的に対応していくことも意識しています。例えば先日予約機能のアップデートを行ったのですが、これはこれまであまり hacomono がハマらなかったパーソナルの市場に展開していくという戦略の一貫となっておりました。

japan.cnet.com

また、週次でプロダクトバックログリファインメントを実施しています。ここでは改修方針のレビューや、次のスプリントプランニングに向けてバックログを整理をする時間としています。リファインメントには開発メンバーも耳だけ参加してくれているので、何か聞きたいことがあればその場で質問できてとても助かっています。

スプリントの進行

開発チームでは毎週金曜日に1週間を振り返る OKR チェックインミーティングを開催しています。このミーティングの中で、次週から始まるスプリントのプランニングも合わせて実施します。ここでバックログの調整することもありますが、ほとんどのケースで前述のリファインメントのタイミングで整理ができているので、プランニングに割く時間はそこまで多くはありません。

f:id:hacomono-tech:20211011223831p:plain

スプリントが始まると、毎日デイリースクラムを実施して進捗状況を確認していきます。主目的を「スプリントが問題なく進行しているかを確認する」をとし、スプリントに関わる情報共有をメインとしています。個別に相談をしたいケースについては、その後に oVice や Slack huddle を使ってコミュニケーションを取るようにしています。

次の OKR チェックインミーティングでは、またスプリントの振り返りを KPT 形式で実施し、改善ポイントを日々話し合いながら開発を進めていきます。

リリース

2週間スプリントの中で開発されたものは、後半週にて QA チームによる検証を通して全環境にリリースが行われます。一方、スプリントに収まらないサイズの大きい開発も随時進行しており、これらは hacomono 大型アップデートとして、エンドユーザーに対するインパクトを常に意識しながらリリース計画を検討します。

リリース前には、事前に改修内容をまとめたリリースノートを作成・公開します。

f:id:hacomono-tech:20211015090854p:plain

また、開発以外のチームにも改修内容を周知したりフィードバックをもらう機会を作るため、上記リリースノートとは別に事前のレビュー会 (おさわり会と呼んでます) を実施していたりもします。他チームも通常業務で忙しく、「見ておいてね」だけだとなかなか周知が難しい面もあり、こういった機会を今後も積極的に作っていきたいと思っています。

現状の課題 + まとめ

少しずつ改善を進めて上手く回っている部分もありますが、まだまだ以下のような課題も多い状況です。

  • お客様に価値を素早く届けるためのデプロイ高速化
  • スプリントレビューがサイクルに組み込めてない (SmartHR さんのバザールという施策がとても良さそう)
  • PdM、開発共に手が足りておらず、開発・フロー両面で細かい改善の方になかなか手が回せていない
  • デザイナー不在のため、UI/UX 領域の開発メンバーの負荷が高まっている (弊社メンバーは UI/UX への意識が高いおかげで、なんとか品質を担保しているような状況)

こんな開発チームですが、自分の手で作品と言えるプロダクトを生み出したい、業界を驚かせるようなプロダクトを作りたい、という方にはとてもチャレンジングかつ裁量のある現場だと思います。少しでも興味を持っていただいた方、ぜひお話しましょう。

課題・今後の取り組みをまとめた採用ウィッシュリストというものを作っていますので、こちらもぜひご覧ください。