こんにちは、ギフティでエンジニアをやっている中屋(@nakaryo79）です!
はじめに
私は GiftExperience dev unit というチームに所属しています。
このチームができたばかり（と言っても組成から半年以上経ったタイミングでしたが）の頃、eギフト発行基盤を開発しているという内容の記事を書きました。
その記事の終わりに
eギフト発行時における新しい価値を提供できる機能開発などを推し進めていく予定です
という締めくくりをしています。
本記事ではその続きとして、私たちのチームが現在どのようなことをやっているのかをお話しします。
ギフティのプロダクト全体の中での立ち位置
ギフティは様々な領域に多角的に事業展開しており、事業領域ごとにそれぞれチームやシステムが分かれています。
私たちのチームは主に、以下のエコシステムの中の ギフト付加価値領域（オレンジ色の部分）と ギフト生成領域（紫色の部分）のうちの「コンテンツ集約プロキシ」の開発を行っています。
前回の記事で書いた eギフト発行基盤 はこの「コンテンツ集約プロキシ」を指しています。
そして、2025年現在は付加価値領域の部分の開発に集中しています。
eギフトの付加価値とは何か
付加価値と言っても色々な側面がありますが、私たちの GiftExperience チームで提供しようとしている付加価値について説明したいと思います。
弊社では飲食店やコンビニをはじめとした各ブランド様の商品をeギフトとして発行することができる仕組みを提供しています。それはギフト生成領域のシステムが担っています。また、そのeギフトを流通させるための仕組みとして toC 向けの販売サイトや、法人向けのキャンペーン管理システムなどを提供しており、それらは図の中の各流通領域のシステムが担っています。
付加価値領域は生成と流通の間に入ることで、eギフトに対して弊社が持つ独自の価値を付加することを目指しています。
例えば、eギフトにイラスト付きのメッセージカードをラッピングとして付けたり、giftee Box のようにeギフトの貰い手が複数の選択肢の中から自分の好みのギフトを選ぶことができたり、複数のeギフトを綴りにして一つのeギフトにまとめあげたりできる（綴りギフト）、といったことが付加価値の一例です。
特定の商品のeギフトを贈るというのは、贈り手にとっては一種のハードルを感じることもあります。例えば、カフェで使えるeギフトを贈る場合、相手の生活圏にそのカフェがあるのかだったり、相手はそもそもカフェに行くだろうか、など、もらった人がその価値を気持ちよく享受できるかどうか、は相手のことを深く知らないと推察に頼る部分が多いです。 贈り手が相手のことを考えた上で選んだギフトであっても、受け取り手にとっては「自分が欲しいものではなかった」ということもあるかもしれません（もちろん、そうした側面も合わせてギフトと言うこともできますし、思いもよらなかったものをもらうことで新しい発見に繋がりうるのもギフトというもののメリットの一つではあります）。
そこで、複数のギフトを選択肢としてラインナップできて、もらった人がその中から自分が好きなものを選べるeギフトを提供できれば、贈る側の心理的ハードルを下げることができるかもしれません。贈り手のハードルを下げることは気持ちのロスを減らすことに繋がり、キモチが循環する社会を作るという弊社のミッションを推進する一つのキードライバーとなります。 また、貰い手としても自分が好みの商品と交換できるのであれば、そのギフトにより価値を感じてくれるかもしれません。
さて、これはあくまでもシンプルな一例ですが、要はeギフトというコンテンツに対して、何かしらの付加価値をつけることで、気持ちの循環を促進していくということをやっていきたいのです。 システム的には、ギフト生成領域が取り扱うプリミティブなeギフトデータを使って、そこに付加価値を上乗せし、それを各流通側にシームレスに提供していく、ということを目指しています。
チームのミッション
付加価値領域を構築するにあたって、私たちのチームは大きく二つのミッションを掲げています。
- (贈り手に)価値を感じてもらえるギフト発行機能を、柔軟で、安全で、効率的に提供できる仕組みを作る。
- (受け取り手に)多様でより良いギフト体験を提供し、ギフトの機能的かつ情緒的な付加価値向上を目指す。
eギフトというものを通して、贈り手と受け取り手の両方に価値を提供していきたいと考えています。
贈り手にとっての価値とは、自分が贈りたいと思うギフトが提供されていること、そしてそれを安心して相手に贈ることができることです。 受け取り手にとっての価値とは、贈り主の気持ちを最大限に感じられること、そしてそのギフトを通して気持ちのいい、または新しい体験を得られることです。
それぞれに対してどのような価値を提供できるのか、またそれを実現するためにどのような仕組みを作っていくのか、ということを考えながら開発を進めています。 それぞれのミッションについて、もう少し具体的に掘り下げていきたいと思います。
贈り手に対しての価値
私たちのチームはeギフト発行の基盤部分を開発しているため、eギフトの贈り手に対してはあくまでも間接的な価値提供になります。贈り手に対する直接的な価値提供はこの基盤に繋ぎ込んでいる各流通システムが担っています。
先述したように、メッセージカードなどのラッピングがついたeギフトや、giftee Box など、eギフトの種別は色々と増えてきています。 そうした新規の種別のeギフトを各流通システムに迅速に提供できる状態を作っておくことが私たちの提供価値だと思っています。
それぞれのeギフトの種別が抽象化されていないと、利用側はeギフトの種別が増えるたびにそれをハンドリングしないといけなくなります。また、各種別のシステムが独立して構築されているため、そのままだと利用側はそれぞれ API を繋ぎこむ必要性が出てきます（冒頭に貼った過去記事の内容と同じペインが生じる）。 こうしたペインをなくすために、各種別のeギフトの抽象化とシステム的な API のアグリゲートを担うプロキシを開発しています。上述のエコシステムの図で言うと「eギフト発行プロキシ」の部分です。
また、難しいのが、これらの種別のeギフトを組み合わせて発行することがあるという点です。
どういうことかというと、少し極端な例ですが、綴りギフトにメッセージカードをつけたり、メッセージカード付きギフトを綴りにしたり、複数の綴りギフトを綴って一つの綴りギフトにしたり、など各種別のeギフト同士を組み合わせて発行したいというユースケースがありえます。 eギフトのポテンシャルが高いゆえに、思いもよらない機能の組み合わせが突然求められることが今までも度々ありました。
各種別のeギフトを個別最適化して設計してしまうと、eギフト発行機能に要らぬ制約を生むことになり、そのような柔軟な組み合わせに対応できないリスクが発生してしまいます。そこで、各種別のeギフトを抽象化して、いかなる種別同士のeギフトでも組み合わせて発行できるような仕組みを設計、開発しています。
イメージとしては GoF のデザインパターンでいうところのコンポジットパターンのような感じです。どの種別のeギフトも自分の中に別の種別のeギフトを内包でき、それが何重にもネストできる。そのためのインターフェースを先に規約として決めておきます。そして、新しい種別のeギフトを新規に開発する際は、その組み合わせが可能なインターフェースに則って開発をする、というルールを課しています。こうすることで、各種別の具体的な実装に依存せず、規約のインターフェースに則ってさえいれば、追加の実装なく新しい組み合わせを実現できるようになっています。
このように高度な抽象化を行ってモデリングすることで、柔軟な組み合わせ発行を可能にしています。
今までは個別最適化された機能群をうまく組み合わせて使うことが難しかったのですが、今後は様々なeギフトをスムーズに発行できるよう、基盤の開発を進めています。
2025年現在では必要最低限の仕組みは開発しましたが、今後は機能の追加と並行して、基盤としての安定性を高めていくことに取り組んでいきたいと思っています。 ギフト発行 API がダウンすると弊社の売り上げダウンに直結するため、可用性やセキュリティの向上はやってやりすぎるということはないです。また、全体を分散システムとして構築しているため、分散トレーシングやサーキットブレーカーの導入、協調スケーリングなど、技術的に泥臭い部分の開発も進めていく必要があります。技術的な難易度も高いですが、モデルの抽象化にあたって社内ドメインの幅広い理解も必要で、バランス感のある開発ができるのが面白いところだと思います。
受け取り手に対しての価値
付加価値領域で開発するメッセージカードや giftee Box などは、eギフトを受け取った人がまず最初にアクセスする画面です。それゆえ、この画面のクオリティはユーザー体験に直結します。
実は受け取り手に相対する機能のうち、メッセージカードや giftee Box などの機能はもうすでに数年前に開発され、実際にユーザーに提供されてきました。ただ、それらは各流通領域のシステムの中に個別に実装されていて、汎用的に使える状態になっていませんでした。例えば、giftee Box の機能は現在法人流通のシステム内に実装されており、個人流通向けのシステムが giftee Box を発行する際は法人流通システムの API を叩くという歪なシステム構成になってしまっています。また、メッセージカード機能も各システムが車輪の再発明的に開発をしています。早すぎる最適化を避けるという観点と、まずは粗くても作ってユーザーに出すという観点では、こうした過去の判断は一概に間違ったものではないです。ただ、ユーザーのニーズが明らかになり、ユースケースが増えてきた今現在ではやはり無駄が多い状態となっています。
そうしたバラバラに実装されている機能をどの流通領域のシステムでも汎用的に使えるようにするために、私たちのチームで共通化を行っている最中です。それにより、新しい付加価値機能が開発された際や、新しい流通システムが出てきた際に、迅速にその機能をユーザーに届けることができます。これが受け取り手に対する一つ目の価値です。
さて、ここまではシステム構成の大枠の話でしたが、もう少しズームインして話を進めます。
エンドユーザーが受け取ったeギフトの画面上でのユーザー体験が悪ければ、ギフトを贈るという行為そのものの価値を損なうことにもなりかねません。そこでの体験が悪いことが予想されれば、そもそも贈り手はeギフトを贈ることを躊躇うかもしれません。
また、ギフトというものの特性上、誰かからもらったからそのeギフトを手にしているわけで、貰い手はそのeギフトの使い方に精通しているとは限りません。 もちろん初めて使うというケースも多いと思います。つまり、使い慣れていない人でも使い方を直感的に理解できるようなユーザビリティを備えている必要があります。
その他、eギフトは言ってしまえば金券相当のものになるので、システムがダウンしていて使いたい時に使えなかったり、レジでいざ出そうとして読み込みが遅いなんてことがあれば体験が最悪です。下手したら2度と使う気が起きないかもしれません。そうならないように、システム的にも安定性を担保する必要があります。
上記のような合理性と合わせて、情緒的な価値を備えていることも重要です。上で金券というワードを出しましたが、それはあくまでもeギフトの実利的な側面であって、ギフトの本質はキモチです。もらった人が「贈り手の気持ちを感じられる」という要素がないと成立しません。それゆえに、eギフトを受け取った人が「なんかいい感じ」を感じられるよう、情緒的な価値も作り込んでいく必要があります。 開発者には高い UI/UX スキルと、利用者への共感が求められますが、この領域はエンドユーザーに向き合ってギフティの提供する価値を最大化させていくというやりがいがあります。
eギフトの種別の一つである giftee Box はおかげさまで多くの人に使っていただいており、弊社独自の価値を届けられているのではないかと思っています。今後、それに続く新しい価値の開発を進めることで、キモチの循環を促進していきます。
ちなみに、GiftExperience というチーム名は、ギフトの受け取り手のユーザー体験を追求するという観点から、このような名前がついています。
最後に
本記事では、ギフティがeギフトというものにどのように付加価値を作っていくのかについて、eギフト発行のシステム的な側面と、eギフトの受け取り手の体験の側面を紹介しました。
eギフトというマーケットはまだまだ成熟しておらず、大きな事業ポテンシャルを秘めています。 そこに対して如何に新しい価値を創造していくか、そして、その事業グロースの足枷にならないようにシステムを正しく成長させていく、ということがエンジニアリングとして今後より一層大事になってきます。
私たちはeギフトを軸に様々な事業を展開しています。社内のシステム規模も年々拡大しており、開発チームも増えてきています。 事業の複雑性に応じてシステムの複雑性も増してきており、技術的な課題も山積しています。しかし、世の中に提供できる価値は確実に大きくなっていますし、まだまだやりたいことはたくさんあります。
ギフティでは次の挑戦を一緒に行うエンジニアを募集中です。 カジュアル面談も受け付けていますので、興味がある方はぜひお話ししましょう。
