カラリアに「香りのギフト」を立ち上げるまで

はじめに

こんにちは。エンジニアの百瀬 (@rn0rno)です。

カラリアは2019年にリリースされましたが、2023年10月に新たに「カラリア香りのギフト」というプロダクトをメインエンジニアとして携わりローンチすることができました。

今回は、新規のプロダクトをどう作っていったか?という話を中心に、既存のプロダクトに新規のプロダクトを組み込むときに気をつけたことについて書いていきます。

カラリアとは

カラリアは、フレグランスのサブスクリプションサービス「カラリア香りの定期便」と、香りに関する情報を紹介する専門メディア「カラリアマガジン」からなる、香りの総合プラットフォームです。

「カラリア香りの定期便」では約1,000種類の香りアイテム（人気ブランド香水やルームフレグランス、バスグッズなど）の中から毎月好きな商品を選ぶことができ、香水は1ヶ月使い切りサイズのアトマイザーでお届けしています。香り選びに悩んだ際は香水診断や充実したサイト検索など、自分に合った香りに出会えるサポートをご用意しています。

サービスサイト: https://coloria.jp

カラリア香りのギフトとは

「カラリア香りのギフト」は、ちょっとしたお祝いや日頃の感謝を伝えるためのカジュアルギフトサービスです。受け取る側が香水を選択することができるため、香りの好みが分からなくても手軽に贈ることができます。香り選びに迷った際は香水診断でピッタリな香水をレコメンドいたします。また、ギフトと一緒にお相手へのメッセージを贈ることも可能です。

サービスサイト: https://coloria.jp/gift/items/1

MVPを最速で出す

2023年8月下旬に、COOの岡本とランチに行ったときに「カラリア香りのギフトを立ち上げようと思っている。」という話をもらいました。

この後すぐにキックオフミーティングがあり、”2023年内に「香りのギフト」の検証が動いている状態を作る”というざっくりの目標のもとギフトチームが発足しました。

どのように検証を動かすかについて話したときに、「とにかく早くMVPを世に出してユーザーさんが実際に喜んでくれるかどうか確認したい」と、MVPを10月頭にリリースし、12月のクリスマスに間に合うように本数や包装のオプションを拡張する、というスケジュールを決めました。開発に携わるエンジニアは自分1名でした。

今思うとだいぶ無理のあるスケジュールだったと思いますが、10月頭にリリースできるような設計にすることを制約として定めました。

MVPの要件

MVPの要件は以下のようなものでした。

図1. MVPのユーザー体験イメージ

別でLPは作らず、カラリアの商品詳細ページ（商品を購入できるページ）をLPとして利用する。
商品詳細ページでは、商品のレビューが投稿できる。他のユーザーが投稿されたレビューが閲覧できる。
商品のバリエーションは、1本・香りの定期便で利用しているクッション封筒での配送の1種類のみ用意する。
香りのギフトは、URLで送付できる。
香りのギフトを受け取ったユーザーは、URLを押すと香水を選ぶ画面で自分がほしい香水を選び、注文を完了させる。
注文完了後、カラリアが発送する。

実装方針

カラリアはすでに提供している定期便、単品ECを上記のようなドメインを軸に実現されています。

ギフトを追加する際、今まで利用している香水・ルームフレグランスといった商品そのものを表現している 商品 を拡張して表現するのか、新しくテーブルを分けるか、下記の観点で迷いがありました。

今回の商品を 商品 を表現してしまうと、扱いが違うため今後拡張していくと 商品 モデルの汚染が発生しそう
商品 は香りの定期便でも利用しているモデルであり、香りの定期便の開発に影響を及ぼしてしまう

しかしながら、商品詳細ページを表示するためのAPI、レビューに関するAPIの開発が不要となるという理由から、「今まで利用している香水・ルームフレグランスといった商品そのものを表現している 商品 を拡張して表現する」こととしました。

商品ID によってDOMの描画部分を分岐する実装とすれば、既存コードへの影響を極小にし、かつ、12月までの期間限定コードとすることで、技術的負債を残す心配がなくなる

この意思決定をしたことで、MVPを作るために必要な実装は以下のようになりました。

１から作らないといけない画面
- 香りのギフトの購入後に、URLを受け取れる画面
- 香りのギフトの購入後にメッセージカード、メッセージを登録できる画面
- 香りのギフトを受け取った後、メッセージカード、メッセージを閲覧できる画面
Viewのみ実装が必要な画面
- 香りのギフトの商品詳細ページ
- 香りのギフトの決済画面
ほぼ既存のコードの再利用で作れる画面
- 香りのギフトを受け取った後、香水の選択画面
- 注文後のロジスティクス

使い回しで実装できる部分については、香りのギフトのための仕様追加や香りの定期便のためのアップデートが今後入ることを見込み、共通コンポーネントとして利用するのではなく別ページ、別コンポーネントとしてファイルを追加することとしました。

一番実装が複雑な商品詳細画面、決済画面、香水選択画面周りを再利用できることによって工数自体は大幅に削減できたと感じます。

実装してみて

再利用できる箇所は積極的に再利用（コピペ）を行い、新規の開発を最小限に抑えることができました。また、コアのロジックは既存機能の再利用を行うことで検証の工数も節約でき、当初の予定通り10月頭にリリースすることができました。

しかしながら、実装を進めていくと同時に12月リリースの要件整理も進んでおり、今回実装したコードベースに12月のギフトの仕様を追加すると、コードとして複雑なものになってしまうことも感じ始めました。

プレスリリース: https://prtimes.jp/main/html/rd/p/000000058.000061060.html

仕様追加に向けた再開発

新規サービスを立ち上げるまでは、できる限り既存コードを再利用することでできるだけ早くリリースすることを目的として進めることで、素早い立ち上げを実現できました。

また、リリース後はすぐに香りのギフトを利用するユーザーが現れました。素早く立ち上げをした結果、MVPで一定のニーズがある（売上ができる）ことを立ち上げから1ヶ月でチームで確認することができました。

ユーザーが利用してくれた結果を見て、12月の仕様追加に向けて開発を進める事となりました。メンバーは少し増えてエンジニア1.5人分くらいで作業をしました。

12月の仕様追加の要件

ユーザーは、注文画面で贈る香水の本数を選べる
ユーザーは、注文画面でギフト包装のオプションをつけるか選べる
香りのギフトに受取期限の概念を追加する

実装方針

このとき、「今後も一定の仕様追加をしていくスピード感が求められる。10月に実装したコードベースに仕様を追加していくと、コードとして複雑なものになりスピード感が落ちてしまう」と判断し、12月の仕様追加に向け、根本的なコードベースの改善として以下の意思決定をしました。

お互いに似たような概念は存在するが、香りのギフトに関するコードは名前空間は分けて、できる限りコードベースを分離する。
既存モデルを再利用することを前提にした10月に実装されたテーブル構造は一度忘れて、再度イチから設計し直す。
ギフトを受け取った側の注文については、香りの定期便や単品注文での注文と同じように扱えることがわかっていたため、ロジスティクス周りの改修を必要としないように再利用を続ける。

結果として以下のようにテーブル構造を変更することとしました。商品を扱うテーブルを変更するという大きな変更に見えますが、やることは小さなシステムのリプレースでした。

実装してみて

再開発をする分、工数がかかっているようにも思いましたが、10月リリース時は設計にほとんど工数をかけなかったこと・10月リリース時の知見が活かせること・どのような仕様の追加が出てきそうかの解像度が上がっていることなどの要因で、質・スピードともに優れていたと感じます。総合して、この選択をしてよかったと考えています。

12月の仕様追加では、商品企画やロジスティクスの部署と連携して、梱包資材の作成・発注、ロジスティクスのオペレーションまわりの変更も伴う仕様変更でしたが、このスピード感でリリースできたことはスタートアップならではだったのではないでしょうか。

プレスリリース: https://prtimes.jp/main/html/rd/p/000000060.000061060.html

既存サービスに組み込むにあたって意識したこと

必要な要件だけを愚直に実装する

特に立ち上げのときは、プロダクトもビジネスモデルも大きく変わる可能性があるので、拡張性や柔軟性はあまり考えず、今提供したいものをどうやったら作れるか？にフォーカスしました。
「ここでは拡張性は考えない」「こういう要件が出てきたらテーブルごと作り直す」という決めを設計のときに明示するなど、シンプルな設計を心がけました。
実際にシンプルなものを作ってみると、「こういう要件が出てきたときはこういう設計にするとよさそうだ」という勘所が掴めてきて、新機能追加の速度にも貢献しました。

組織の境界とコードベースの境界を合わせる（コンウェイの法則）

開発メンバーが分かれている場合は、既存サービスに組み込む場合でもコードベースはできるだけ分ける（同じ実装でもコピペをする）ということを意識しました。
コード全体の量は増えるかもしれませんが、その分影響範囲は小さくなりステークホルダーも減るため、逆にスピードが出せました。
実際に、既存のコードベースを開発しているメンバーからも「ギフトを気にすることなく開発できて良かった」とフィードバックをもらっています。

テーブルの改変・モデルの改変は恐れずにやる

粗削りのまま残し続けると「技術的負債」になってしまうため、プロダクトとして安定してきたところから持続可能な設計に作り直さなければならないと思っています。プロダクトが小さいほどやりやすいポイントなのでどんどん作り変えることを意識しています。
マイグレーション作業はやや手間がかかりますが、ビジネスモデルと少しでも歪みが出てきたら設計を見直して、すぐに直していくことが結果として技術的負債を残さないことにつながり、開発速度・開発体験の向上に繋がっています。

余談) スケジュール管理

12月リリースについては、仕様の変更、既存実装のリファクタリングなどやらなくてはならない作業が多くあり、自分の作業工程の整理・元々決めていたスケジュール通りに進行できるかどうかの見立て・遅延が起きていないかを監視をするために、だいそれたものではないですがWBSとガントチャートで見積もりを行いました。

元々は早くて12/4週、遅くて12/11週になりそうな形で進行していましたが、プロジェクトを始める前に必要な作業を洗い出せていたため、作業途中で詰まることスムーズに行うことができました。作業が順調なのか・送れているのかをデイリーで確認することができたため心にゆとりをもって作業をすることができました。

また、途中で開発メンバーが新規で1名増えたのですが、作業の分割・アサインもサクッと行うことができ、本数の追加は11/27週、包装オプションの追加は12/4週と、予定よりも早くリリースすることができました。（実績を中点や矢印でメモしてありますが、見積もりの仕方についてはまだまだ改善余地はありますね）