月数万の売上からスタートしたプロダクトを、1年足らずで年間数億規模に成長させたエンジニア
＜プロフィール：菊川 史貴（きくかわ ふみたか）＞
奈良県出身。奈良工業高等専門学校、和歌山大学 大学院システム工学研究科を卒業後、新卒でリクルートに入社し、BtoB アプリ開発を担当。2016年10月よりギフティにジョイン。入社から約1年で新規プロダクトを生み出し、約8ヶ月で年間数億規模に成長させる。
──自己紹介をお願いします。
ギフティではSolutionチームでエンジニアをしていて、ギフティに来てからもうすぐ2年になります。社外ではkikunantokaで活動しています。休日は個人サービスの開発をしたり、フットサルをしたり、ベースを弾いたり、ボードゲームをしたりしています。
リリースすべき機能を考えるところからインフラ構築まで担当プロダクトの開発側のすべて
──現在の業務を具体的に教えてください。
僕が所属しているチームは、Solutionチームといいます。Solutionチームは、次の事業の種となるプロダクトを事業開発チームと密に連携しながら仮説検証を回す、インキュベーション機能を持っているチームです。
その中で僕は、「GCP（Giftee Campaign Platform）」という新規プロダクトの開発を生み出すところから担当しています。GCPとは、クライアントが自社のLINEやTwitterのアカウント上でeGiftを用いたキャンペーンを実施することができるプラットフォームです。一番分かりやすい例で言うと、「Twitter インスタントウィン」機能を活用したキャンペーンです。
つい最近まで、チーム内でコードレビューや相談ができる環境なものの、僕一人がメインで開発をしていたので、下記のようなことを全部担当していました。
- マーケットニーズからどのような機能を開発すべきか洗い出し、優先順位付け
- 要件定義
- 実装（バックエンド、フロントエンド、デザイン）
- インフラ構築
- 障害対応や運用業務
受託開発ではなく、プラットフォームを創ること
──GCP誕生のキッカケって何だったんですか？
あるクライアントからギフティのeGiftを使って、Twitterのキャンペーンをやりたい、という問い合わせが来たのがきっかけでした。
最初は、その場限りのキャンペーン案件として請け負う想定だったのですが、僕が受託開発としてやりたくないっていうのと、うちの優秀な事業開発メンバーなら今後も似たような案件をたくさん取ってくるだろうと思っていたので、マネージャーと相談して、スケジュールにコミットすることを前提にプラットフォーム化してプロダクトとして進めていけるように開発を進めました。
技術の好き嫌いではなくプロダクトの性質との相性をもとに選定
──技術選定はどのように行っていますか？
エンジニアの中には、自分の好きな流行りの言語やニッチな技術を優先したいと強く思う方もいるかもしれませんが、僕は、プロダクトの性質と相性が良いかどうかを軸に判断しています。リアルタイムに情報更新が行われて、SPAっぽく動いて欲しいアプリケーションであれば、フロントにReactやVueを入れますし、その必要がないのであれば、Railsのviewで十分と判断することもあります。インフラに関しても同様で、今回はキャンペーンを実施するプラットフォームということもあり、スケーラビリティが必須要件だったので、Elastic Beanstalkを導入しました。
「やらないことを決める。」プラットフォームを提供することを忘れない
──運用面で難しいことは何ですか？
カスタマイズをしたいという要望が多いので、プロダクトとしてどこまで対応できるようにするのか、という判断が難しいです。プラットフォームを提供しているので、基本的に 1 社のために特別対応する、ということはしていません。目の前の短期的な利益に揺れることもありますが（笑）、長期的な視点を持って開発をするよう心がけています。
そのため、要望があった機能はどのくらい汎用化できるのか、期待できる将来の利益はいくらか、運用が回るのか、ということを考えながら、事業開発メンバーと一緒にどのような機能を開発するかを決めていっています。
様々な観点からのインフラの負荷対策を考える
──技術面で難しい点は何ですか？
キャンペーンという性質上、告知の方法次第では、開始時刻直後にアクセスが集中するケースがあり、数万reqs/minというアクセスに耐えられる環境が必要になります。インフラはスケーラブルな構成にしているので、大きな案件がある場合は事前にスケールアウトした状態で待機しておくのですが、結局アプリケーションの書き方がまずいとインフラをいくら増強してもどうにもならないケースが出てくるし、費用も嵩むので、アプリケーションの書き方には常に注意しています。まずいクエリが発行されないかとか、この実装はスケールアウトした時でも耐えうる設計になっているか、という部分を特に注意しながら開発をしています。
納得感を持って実装をする、その方が圧倒的に楽しい
──GCP を開発する中で、こだわっていることは何ですか？
エンハンスをやっていく中で、自分の納得感はすごく大切にしています。クライアントがこういう機能が欲しいって言っているけど、本質的にはこういうことなんじゃないか？とか、本当にその機能を入れることでプロダクトが成長するんだっけ？といった疑問点は事業開発担当と会話をしながらちゃんと潰していくようにしています。やっぱり納得感がある中で、実装をするのと、納得感がない中で実装をするのでは、働いている時の気分や品質も違う気がするので。提供したい価値としては、エンドユーザには、gifteeというサービスを知ってもらうきっかけをたくさん創りたいということと、クライアントには、今までキャンペーンを実施するのにかかっていた手間がギフティと一緒にやることで大幅に削減できた、ちゃんと効果が出た、と納得していただいて、継続して使いたいと思ってもらえるようにしていきたいです。
業務の属人化を排除しながら、開発の当たり前の質を高める
──安定運用のために行っていることはありますか？
最近取り組んでいることは、個人依存を減らすように努めています。以前はレビューがチーム内で入っているとはいえ、一人で開発と運用を回していたので、トラックナンバーが1の状態でした。プロダクトが成長してきてエンジニアを複数人入れても利益がちゃんと出る状態まで持ってこれたので、ちゃんと人を入れてチームとして活動して、個人依存を減らして、もし僕がトラックに轢かれてもプロダクトがちゃんと回る状態にできるようにしていってます。（笑）
技術面で言うと、当たり前のことですが、死活監視をちゃんとして、インフラが落ちたら通知が来るようにしたり、エラーが発生したら通知が来るようにしていて、問題が起きたらすぐに気付いて対応できるようにしています。
インフラに関しては、過去のアクセスが集中した時の実績データを蓄積していっていて、この構成でこのアクセス数だと問題なかった、とか、CPU利用率に余裕があったからもうちょっと減らせたんじゃないか、といった振り返りを元に、次はこれくらいのアクセス数が見込まれるから、この構成にしようという意思決定ができるように、必要なデータは蓄積していくようにしています。
コードの品質面で言うと、テストコードを書いたり、ちゃんとレビューをしたり、チーム開発で当たり前となっていることを当たり前にやっていくのが大切だと思っています。開発初期でスケジュールもかつかつな時はなかなか当たり前のことを当たり前にやるっていうのが難しいので。
0->1 の開発、さらにはビジネス戦略まで
──GCP の開発だからこそできる経験はありますか？
事業開発担当と一緒にビジネス戦略を練りながら、プロダクトを成長させていくフェーズが体験できると思います。ビジネス側の数値を見ながら、次にどういったエンハンスをしていけば、目標数値を達成していけるのかといった意思決定を事業開発担当と一緒にできます。事業開発担当とエンジニアの少人数構成の小さいチームでPDCAをどんどん回していけるというのが、とても良い経験になっているのではと思っています。また、プロダクトの特色として、LINE Push通知やTVでの告知といった、瞬間的に大量のアクセスが来るのを経験できるので、インフラ面の経験としてはチャレンジングで面白いと思います。
Solutionチームとしては、こういった 0->1 のチャンスがたくさん転がっていて、プロダクトの立ち上げ時期に関わることができる、というのは良い特色だと思っています。自分で裁量権を持って、要件を詰めたり、仕様を決めて、それを実装に落とし込んでいく、ということがやりたい人はとても良い環境だと思っています。
責任のある仕事をしっかりと任せてくれる
──ギフティの特徴的な文化は何だと思いますか？
現在GCPの開発の意思決定に関しては、基本的にマストなレポートラインはなく、事業開発のメンバーとエンジニアだけで進めています。もちろん、悩みがある場合はマネージャーなどに相談はしていますが。また、報告をするためのドキュメントを作成することもほとんど必要ないです。そのため、スピーディに意思決定をし、日々変化していくマーケットニーズに答えられ続けていると思います。
自分を信頼してくれていることを感じるので、僕もそれに答えられるために成長し、成果を出していきたいと常に考えています。