この記事は ギフティ Advent Calendar 2019 24日目のエントリーです。

CTO 柳瀬です。

株主会社ギフティは2010年8月に創業し、創業事業であるgifteeは2011年3月にローンチしています。僕自身は創業からやっている身なので、ここでは8年半運用し続けてきたgifteeの歴史を紐解き、今プロダクトとしてどういう状況にあるかをご紹介させて貰えればと思います。

創業期

2010年8月、onlabというシードアクセラレータプログラムに参加のタイミングでα版をクローズドな形で開発しました。これは関係者のみの公開で、いわばPoCのの為のものでした。下記はその時のキャプチャです。この時からRuby on Railsを使い、インフラはHeroku上で動いていました。

PoCを経て、本運用に耐えうるプロダクトとして再度スクラッチから開発を行い、2011/3/1にβとして一般にサービス公開をします。この時はRailsのバージョンは3.0.3でした。

インフラもこのタイミングでAWSを採用。US-Westリージョンで構築を行いました。 そして2011/3/1のβ公開翌日、AWS東京リージョンが突如として開放され、よくある「問題を頑張って解決した後にAWSが簡単にそれを解決してくれるサービスを出してくる」をいきなり踏むことになります。(ちなみにその9日後には3.11が起き、それどころじゃねー、となります。)

振り返ってみると、当時のgifteeは今以上に外部プレイヤーに大きく影響を受けるプロダクトだったと思います。ギフトの送信方法も最初はTwitterのAPIを呼んでメンションで送る、という方法で、その後数年間SNSのトレンドやAPIの変更に併せて送信方法を追加・更新していく必要がありました。また送る商品に関しても最終的にはチェーン店の商品を取り扱う事を目指していたものの、いきなりそれが実現できるはずも無く、街の小さなカフェに営業をかけ掲載させて貰っていました。なのでプロダクト設計としては小さなカフェが並ぶ形に最適化せざるを得ず、首尾よく大規模チェーンとのトライアルが決まったりすると個別対応が必要となり逆に悩む、みたいな事が起きていました。

尚当時僕がユーザやマーケットの反応から感じたのは、「需要や共感は感じるけど便利さがそれに追いつかない」という状況でした。足元の数字は正直振るわなかったのですが、商品ラインナップが整い便利さが追いつけばゲームチェンジングできる、という感覚は当時から感じていました。

配送期

そういった状況の中、話をより難しくしたのが、大規模チェーンが増えていくスピードが会社として必要なスピードより大幅に劣っていた事でした。商品が整わない中でプロダクトの改善を重ねても限界があり、かといってチェーン店が増えていくのをただ待つ訳にもいかない訳です。これが2013年頃の話です。

これは今でもそうですが、チェーン店さんに弊社の仕組みを導入頂くにはどうしても時間がかかります。(今でも年単位の営業や取り組みが必要なケースがあります) そのため、スピーディーに導入でき、自分たちでコントロールを効かせやすい形の商材として、配送型ギフトへ注力する、という判断をします。URLを友だちに送り、受け取った人が住所を入力するとそこに商品が届くスキームです。プチピボットとも言えるこのタイミングで、既存のコードベースを捨て再構築する、という判断をしました。

この判断は正直悩みました。現Stack OverflowのCEOとして有名なJoel Spolskyのこのエントリが頭をよぎったからです。Joelの邦訳サイトが現在動いていないようなので、僭越ながら要約をすると、

• Netscapeは3年掛け、ようやくメジャーバージョンアップを果たそうとしている。
• 3年というのはインターネットの世界において狂気的に長い時間であり、その間Netscapeのプロダクト改善が止まった結果、大きくマーケットシェアを失った。
• この状態を導いたのは、「コードをスクラッチから書き直す」という最悪の判断をしたからだ。

という話です。

そして、エンジニアに取ってコードを読むことは書くことより遥かに難しく、新しくジョインしたメンバーはコードを書き直したい、作り直したい衝動に駆られがちです。しかし今あるコードは使われており、テストされており、バグ修正がされている。プログラムはテディベアじゃない、素材の新しさに何の意味がある？ と。

ただこの時のgifteeのプロダクトとしての変化は比較的大きく、既存の作りを生かしてもプロダクトの成長期の改善工数を考えると書き直した方がトータルでよいだろう、という判断をしました。当時の僕以外のメンバーの意向としても、現プロダクトの負債や課題をクリアしつつ新しいプロダクトに向き合いたい、という気持ちが大きかったのもあります。

この判断が正しかったのか、6年以上経った今でも正直確かな事は言えません。ただファクトとして言える事を並べると、

• 開発メンバーは書き直し前のプロダクトを知っているメンバーが中心だったため、プロダクト理解と既存の問題点の解消は比較的スムーズに行えた。
• その後チェーン店の商品が揃う状況にも、このコードベースで対応する事ができた
• 上記以外にも多くのプロダクトとして役割が追加されているにも関わらず、現在もこのコードベースはproductionで動いてはいる
• (とはいえ多くの問題があり、それは次記事で触れます)

といった点はあります。

振り返ると個人的に大きかったと思うのは1点目で、こうでは無くリニューアルのタイミングで新規メンバーが大量に増える構成だと課題感の共有やプロダクト理解のオーバーヘッドが重かったのでは無いかと感じています。

長くなったのでこの記事はここまでで、続きは次記事で。