🥹

『やっぱり最速で価値を届けることが正義だよね』が、深く身にしみた話

2024/07/04に公開

こんにちは!J-CAT株式会社でエンジニアをしております引山です!

私たちは、『テクノロジーとクリエイティビティで魅力あふれる日本の姿を世界へ』をミッションに掲げている観光テックカンパニーです。弊社では、特別な感動体験に出会える予約サイト『Otonami』と、日本の魅力を世界へ届ける訪日外国人向け予約サービス 『Wabunka』を運営しています。

現在私は、Wabunkaスクラムtmのメンバとして開発業務を担当しております。
Wabunkaの具体的なサービス内容や開発体制に関しては、以下記事を参考にしていただけますと幸いです。
https://zenn.dev/jcat/articles/3954286013acfe

今回は2024年2月にリリースしましたWabunkaの開発案件『通称:Wabunka DX』において、当初の想定より大幅にスコープを削減し段階的リリースに至った背景や、そこで得られた学びについてお話させていたければと思います!

TL;DR

  • 1秒でも早く、最速に価値を提供していく意識を持ち、考え、行動することが重要
  • MVPを念頭においた要件定義で開発スコープを決めても、実はまだまだミニマムにしていける余地がある
  • 開発フェーズに入っても定期的なスコープや要件の見直し、リリース単位の分割を検討していく必要がある

Wabunka DXプロジェクトとは?

Wabunkaは2022年10月に必要最低限の機能(体験の紹介機能と申込みフォームのみ)でサービスローンチし、システム化されていない部分はCSチームの人力オペレーションでカバーすることで、1年ほど運営をして参りました。弊社サービスの魅力的な体験 + コロナ収束と円安の効果も相まって、ありがたいことに人力では耐えきれないほどの予約申込みをいただくようになり、Wabunkaは爆速成長を遂げてきました。

その中で、以下のような喫緊の課題がありました。

  • オペレーションが需要に追いつかないため、広告を控えるなどサービス拡大のためのアクセルをかけにくい状況である
  • サービス拡大に伴い問い合わせ数が増加しているが、Webサイト上の決済機能がないため最終的に受注に繋がらない問い合わせが多く含まれており、その分の対応コストが無駄になってしまっている

そこで立ち上がったのがWabunkaをDXしようプロジェクト、通称 『Wabunka DX』 でした!

要件定義、開発スコープをどう決めていったか

ローンチから1年間最低限の機能で運用してきたため、その間に業務も複雑化し、システム化したい案件が山ほどある中での要件定義は嬉しい反面、大変な側面も多々ありました。

やりたいこと、やれること青天井の状態。

ただ弊社にはMVPで開発を進めるカルチャー、そしてスーパー優秀なメンバーが在籍しておりました。

  • MVP(ユーザーに価値提供できる最小の)スコープを定義すること
  • MVPな要件定義をするにあたって、『その機能を実装しなければリリースしない方がマシか?』という問いを各自が胸に刻み、判断基準としていくこと

以上を意識しながら、課題解決に必要な機能を関係者(Biz、CS、PdM、エンジニア)にてあげ、以下ユーザーストーリーマップを作成する方針としました。


引用:ユーザーストーリーマッピング:https://www.agile-studio.jp/post/apm-user-story-mapping

最終的に作成した成果物はこちらです。

横軸はユーザーストーリー、縦軸は優先度となっており、関係者で現状の運用を理解しながら必要な機能を付箋で貼り、MVPラインを決定していきました。

開発対象は大きく分けて『クレジット決済機能』、『予約カレンダー機能(ユーザーが体験予約可能な日程を閲覧、選択可能にする)』、『予約関連メール送信機能』、『社内向け管理機能(マスタ管理、予約管理)』となりました。

今回は趣旨とずれてしまうため記載できないのですが、MVP決定の後、

  • 鬼のようにPdMがPBIを書いたり
  • マルチプロダクトにおける技術選定に悩んだり
  • そもそも開発メンバが全然不足していたので採用活動を行ったり
  • J-CAT初となるスクラム開発をスタートしたり
  • 裏ではフロントエンドバージョンアップ(Nuxt2→3)の大規模プロジェクトが並行で進んでいたり

など大変かつチャレンジングな要素はたくさんあったのですが、これはまた別の機会に…

そんな中、リリース時期はインバウンドピークが予想される2024年2月としてプロジェクトは走り始めました!🔥

開発開始!何が起きたか…?

上述しましたが採用活動が実を結び、優秀な方に数名ジョインしていただくことで、スクラム開発をスタートすることができました。

スクラム開発立ち上げ直後はまだチーム内のノウハウやナレッジが溜まっていないため、ベロシティがなかなか上がらない状況でした。

しかし、スプリントを回すごとに成熟していき、1スプリント内でこなせる量が個人としてもチームとしても徐々に可視化されていきました。

(以下記事にも記載がありますが、スクラムのタスク管理にはLinearを、スクラムMTGにはAroundを使っており、結構イケイケなツールを使っていたりします 👏)
https://zenn.dev/jcat/articles/50d32f118194cf

その結果、明確になってきたのが 『2月リリース、厳しいんじゃないか…?』 でした。

窮地から取ったアクション

J-CAT VALUEとして『Respect』を掲げているように、仮にリリース間に合わないかも…となったときに怒号が飛び交うような思考停止する組織ではありません(笑)

『Professional』な集団として、この状況でどのようなアクションを取れるかを考えていきました。

  • リリース時期を延伸する?

    最終手段としてはもちろんあり得ますが、当初スケジュールの2024年2月までに価値提供できる方法がないかをまずは考えることにしました。

  • 2月のピーク期を迎えるために一番重要なことは何なのか?どうなっていたいのか?

    ここは現状抱えているイシューに立ち返ることで、改めてCSチームの対応コストを下げることが最優先であることの共通認識を持ちました。では、どの機能が一番CSコスト削減に寄与できるのか?議論の結果、『クレジット決済機能』を実現することがコスト削減にクリティカルであるこという結論を導き出しました。『クレジット決済機能』を最優先としてリリースし、以降は段階的にリリースを行う意思決定を行いました。

  • 段階的リリースを行うにあたって、運用への影響はどのくらい発生するか?
    中途半端にリリース分割したことで、逆にCSチームの運用が複雑になりコストが増してしまうと本末転倒です。段階的リリースになったとしても、ちゃんと価値として提供ができる形となるかの確認をしていきました。

  • 段階的リリースを行うにあたって、設計や開発への影響はどのくらい発生するか?

    一部機能がない状態でリリースすることになるため、全体設計への影響は少なからず発生しました。
    しかし、段階的リリースを行う場合も、その先のリリースステップにスムーズに進めるように、なるべくその場しのぎの一時的な実装とはならない、今後を見据えた設計・開発方針を検討していきました。

上記のような議論を要件定義時に作成したユーザーストーリーマップをベースに議論し、結果的には当初MVPだよねと考えていた案件を4STEPに分割することができました。

また、当然ですがスコープが小さくなったことで検討する範囲が絞られたため、開発を進める際も余計なことを考えず一点集中で臨めるので、その後の開発スピードが向上する効果もありました。

2月リリース達成 🎉 Wabunka DXから得た教訓は…

上記のような変遷をたどり、2024.2.19に悲願のWabunka DX 1stリリースを行うことができました!リリース後の大きなトラブルもなく、事業成長にインパクトを与える案件となりました。

リリースから4ヶ月迎えて、改めて今回得た教訓を振り返ると、

【教訓①】最小価値で最速にリリースできたことがめちゃくちゃよかった

削って削ってのリリースではありましたが、当初の見立てどおり、『クレジット決済機能』の導入により受注率がアップし、全体の問合せを受注確度の高いものに絞り込むことができました。

その結果、CSコストが削減がされ、適切なマーケ施策を打つことができたことで、GMVが拡大し、Wabunkaサービスの爆速成長に大きな貢献ができました。

今回の意思決定がもし、『スコープを削らずリリース延期する』だった場合、リリース時期は数ヶ月遅れることになってしまったと思います。その結果、現在のWabunkaの成長タイミングが遅れてしまい、最悪時期を逃したことで競合にシェアを取られてしまった場合、その損失は取り返しのつかない多大なものだと考えています。

よってスタートアップは特にですが、最速で価値提供することの重要さが身にしみてわかりました。1日でも1分でも早く届けるためにできることを突き詰めて行きたいです。

現在はスクラム開発が軌道に乗って、PBIもかなり細い粒度で安定した開発ができていますが、担当するチケットをスケジュール通りにこなすではなく、その中でも過剰な機能要件となっていないか、分割して更に早く価値提供できないかを考えていきたいです。

【教訓②】開発スコープや要件の見直しは常に行うべし

要件定義時に『これがMVPだ!!』と思っていた開発スコープも、今振り返るとまだまだ削り落とすことができたのだなと痛感しました。

ただ、要件定義時はリリース時期も先ですし、開発がまだ進んでいない段階での不確実性を多く抱えています。

工程が進むにつれて解像度が増していき、またリリース日が近くなることでより現実味を帯びてきて見えてくるものがたくさんありました。

なので開発スコープや要件は要件定義時に確定ではなく、後続工程でも不要なものは削ぎ落として、更に細かく分割できるものは分割することを考えること、更に最小価値を最速に提供するカルチャーをチーム内で醸成していくことが非常に重要であることがわかりました。

私も参考にさせていただいたのですが、以下記事が本当に素晴らしいのでぜひご一読ください!
https://blog.kyash.co/entry/2023/12/21/121848

https://tech.smarthr.jp/entry/2024/02/22/104939?utm_source=subscription_mail&utm_medium=email&utm_campaign=subscription

最後に

長くなりましたが、Wabunka DX案件で得られた教訓でした 🙏

子供の頃からよく聞いたり言われたりしていますが、期限を決めることはやっぱり重要ですね 🙇

開発規模が大きい案件ほど見積もりが難しく、精緻なスケジュールを組むことが困難ですが、その中でもチャレンジングなリリース日を設けてしまう。(プレスリリース出してしまうとかもいいですよね!)
一度期日を決めたらもうやるしかない状況になり、追い込まれたときにどうしたら達成できるかチーム全員で脳みそフル回転させる。そうしたら意外と無理そうだったこともできてしまうことありますよね 🙌

多くの経験や教訓を得た刺激的な案件でした!

Wabunka、Otonamiは爆速成長中でこれから届けたい価値がたくさんあります!
よりビジネスやプロダクトに近いポジションで開発ができることが今のJ-CATで働くことの面白さの一つです。
もしご興味を持っていただけた方は、ぜひぜひカジュアルにお話しましょうー! 🎉

ご応募はこちらからお願い致します!↓
https://www.wantedly.com/projects/1721064

J-CATテックブログ

Discussion