インタビュー 「Gatebox株式会社 Developer Program プラットフォーム構築」
好きなキャラクターが自分の部屋に現れて、いっしょに暮らす。Gatebox はそんな「キャラクター召喚装置」です。
Gatebox では、スマートフォンのアプリケーションと同じように、キャラクターなどのアプリケーションをストアで購入したり、自分で開発してストアで公開したりできるようになっています。そのためのプラットフォームの開発を、われわれシグマコンサルティングが担当しました。
開発にあたってどう考え、少数精鋭で実装したのか。Gatebox 株式会社 取締役 CSAO (Chief Service Architecture Officer) の久森達郎氏と、シグマコンサルティングの CTO の冨田順、CRO / リードエンジニアの鈴木孝明、アーキテクトの阿武野悠香が振り返りました。
(左から)シグマコンサルティングの CTO の冨田順、Gatebox 株式会社 取締役 CSAO (Chief Service Architecture Officer) の久森達郎氏と、シグマコンサルティングの CRO / リードエンジニアの鈴木孝明、アーキテクトの阿武野悠香
プラットフォーム構想に参画
シグマ子
まずは改めて Gatebox の製品と会社の紹介をお願いします。
久森氏
Gatebox は、代表のファウンダーの武地が、こういうものが欲しいという思いから 2015 年に開発を開始し、2016 年に限定モデルを 300 台リリースし、2018 年 7 月に量産モデルを発表、2019 年 10 月に無事出荷開始したキャラクター召喚装置です。
量産モデルでは、Gatebox 社オリジナルキャラクター型 AI パートナーの「逢妻ヒカリ」、動画をアップロードして召喚できる「Gatebox Video」が標準提供されています。
その他、独自のアプリケーション配信システムを用意し、任意のキャラクターアプリを作って配信する仕組みを提供しています。このようなプラットフォーム構想は量産モデルと同時に発表しました。この部分でシグマコンサルティングさんにプロジェクトに参加していただきました。
シグマ子
プラットフォーム構想は早い時期から考えていたのでしょうか。
久森氏
そうですね、開発当初の計画段階から、複数のキャラクターが出てこられるプラットフォームとして作ることがイメージされていました。私が Gatebox に入社したのが2017年7月で、まだ限定モデルを開発していたときでしたが、量産モデルではこういうのをやりたいとファウンダーの武地と話しており 2018 年終わりに冨田さんに声をかけました。
Gatebox は元々 Azure を採用していたので、Azure に強いところ、そして決済を含めたコマースに詳しいところ、というところでシグマコンサルティングさんが一番だろうと。あと、シグマコンサルティングさんはフットワークが軽いというのもありました。
少数精鋭型(6名)のプロジェクト設計 3 か月、実装 3 か月
シグマ子
シグマコンサルティングが開発したのはどの部分でしょうか。
久森氏
開発者がアプリを公開して利用者が購入する Gatebox App Market と、開発者が使う Developer Console、それと弊社がプラットフォームを運用するための Admin Console です。
注:Admin Console は Gatebox 社内向けシステムのため、この絵には書かれていません。
シグマ子
何人ぐらいで開発したのでしょうか。
久森氏
本体側のプログラムまで含めると全体で 6 名で作りました。そのうちシグマさんと一緒に行った部分の実装は2人 + 私です。
鈴木
私は普段はバックエンドをメインに扱っていますが、今回は悠香さん (阿武野) との分担ということで App Market と Developer Console のフロントエンドの部分を担当しました。
阿武野
私は元々バックエンドの決済まわりのバッチ処理などを担当していることが多くて、今回も主にバックエンド系の API や決済まわりを開発しました。
久森氏
このプロジェクトは 2019 年 1 月からスタートし、3 か月ほど設計フェーズで、そのあとが開発フェーズでした。実装はお2人に参加いただいて、冨田さんにはシグマコンサルティング側の PM として動いていただきました。
鈴木
バックエンド側の API は 4 月から悠香さんが開発に着手し始め、5 月ぐらいには概ねでき上がって、それを使って私がフロントエンドの開発に入りましたね。
阿武野
要件定義ができていたので、画面が決まっていなくても開発できました。そこから開発期間は 3 か月ぐらいですね。作っていて、機能として迷うことがなかったのが大きかったと思います。
鈴木
私の担当したフロントエンドは、API が整備されたおかげでバックエンドの話を意識せずにできました。
阿武野
API の設計は難しいといわれることが多いのですが、REST をベースにきれいに整備できて、省力化できたと思います。
誰が何を売買するのかという点から徹底的に議論
冨田
最初に話をいただいて、売り物が何なのか、誰が買うのか、といったところを徹底的に明らかにすることから、侃々諤々の議論を始めたんですよね。
久森氏
Gatebox を買うのは一般消費者ですが、ほかにも B2B で Gatebox の上にソリューションを乗せて収益を得たい人もいるかもしれない。その上のサービスとしてキャラクターなどのアプリがあって、開発者がいます。その間にプラットフォームの仕組みがあります。
こうした各方面を向いた仕組みを最初から作っておかないと、あとから変えるのは大変です。場当たり的に作ると、改修範囲が広くなって開発期間が長くなりますし、拡大や機能拡張も難しくなります。その設計まで見据えて議論しました。
冨田
「何を売るんですか?」とか「誰がお客さんですか?」のようなことを尋ねると、黙ってしまうお客さんも多いのですが、久森さんには議論に向き合ってもらいました。
阿武野
それが2019年の2〜3月ごろでしたね。
鈴木
私たちが開発に入る前の3か月ぐらい、毎週みっちり議論していました。
(ここで、チャットでの議論のログを見せる)
シグマ子
オンラインとオフラインで活発に議論していたのでしょうか。
鈴木
3月までは、週1回オンラインで、週1回オフラインで4〜5時間ぐらいミーティングしていました。4月からはイメージがつかめてきたので、週1回のオンラインミーティングだけになりました。
アプリケーションを作るだけでは思いつかないアプリケーションのライフサイクル問題
冨田
アプリケーションがどうやって生まれて、どのように成長して、どうやって死んでいくのかのライフサイクルについては、特に時間をかけて図に落としこみましたね。
鈴木
実装でも、この図を見ながら、ほぼこのまま作りました。
久森氏
一口に配布といってもいろいろな段階があります。まず登録して、アプリケーションをアップロードして、限られる人だけ見られるようにして、というように状態遷移を考えました。審査も入りますね。
阿武野
終了するときのことも十分に考えないといけない。Gatebox の場合はサブスクリプション方式なので、「明日からやめます」とはできない。
久森氏
月額の概念についてもしっかり話しあいましたね。日割りしないようにする、とか。いろいろ紛糾もしましたが。
鈴木
先払いにしましょうとか。
久森氏
オンラインゲームと同じような概念にしましょう、よほどのトラブルがないかぎり払い戻しが発生しないようににして、シンプルにしましょうと。細かいところでいうと、アプリの配信停止対応は「販売状態から新規購読停止にして自動更新を止めれば、少なくとも30日後には利用者が0になる」ので「そっとアプリケーションを非表示にすれば終了できる」など。
そういえば、ここで「スイッチを切って止める」というのを用意したのも重要ですね。
冨田
スイッチが必要になると考えたのは、配信を止めるところまではできるけど、アプリケーション自体の寿命を終わらせたいというときにはスイッチがないと無理だと。
久森氏
ライフサイクル全体を受け止めるようにしないと、プラットフォームとしてはまずいですよね、という話をしました。すでにある環境にアプリをリリースするのとは違う、プラットフォームを作ろうとしたときに気を付けないといけない点が多くありました。
要件は解像度の低い状態から上げていく
冨田
要件を決めるにあたって、解像度の低い状態で全体像を掴んで、そこから解像度を上げていきました。進んでいくうちに、全体は変わらず、細かいところでアラが見えてくるので調整する。そして、鑑賞に耐えられる品質のところで開発できるわけです。
鈴木
つまり、「ストア機能を作りたい」というような要件だとうまくいかない。
久森氏
ツール選択の話になってしまうといけない。技術的レイヤー単位で分割しないことですね。解像度の低い全体像があったとき、多くの場合は解像度を上げる前に、手のつけられるところから手をつけてしまうのがよくないと思います。
このプロジェクトでは、最初から「ビジネスとしてこうしたい」というものを出していました。
冨田
解像度を上げていくやりかたは大変ですが、必要なことですね。
久森氏
私は最初に「要求側としてこういうことがしたい」ということをできるだけ網羅的にドキュメント化した上で相談に入ったので、解像度を上げる作業のときは常にそこに立ち返って話すことができたのではないでしょうか。 発注時点で全部見通せているならそれに越したことはないのですが、やってみないとわからないことも含めて出来るだけ発注する前に書ききっておくほうが良いと振り返って思います。
作らない判断も重要
冨田
作るものだけでなく、作らないものは何かということも決めていきましたね。
シグマ子
作らなかったものにはどのようなものがありますか。
久森氏
作らないと決めたものは、少なくとも決済まわりと、認証と。
冨田
作らないという意味では、監視系もですね。
久森氏
監視は Azure Application Insights に寄せましたね。流行りの言葉でいうと NoOps ということで。
阿武野
決済系の基盤には Stripe を使っています。あと、サービス側からディベロッパーに提供している WebHook まわりも作りこんでいません。そうした部分で、SaaS / PaaS を積極的に使いました。全体のサービス構成としては、マイクロサービス風の構成になっています。
久森氏
いまどきは、そういうものを組み合わせていくと、これだけの関係者のいるシステムを、これだけの期間で開発できる時代だなというのを実証できた案件だなと感じます。
冨田
かといって、最初からマイクロサービスありきだったわけではなく、結果としてマイクロサービスになった。
久森氏
一番時間をかけるべきなのは、要求をまとめること、要求の解像度をできるだけ上げることだと思います。 ただし、作らない判断には発注側も技術的なスキルが必要です。Stripe を使う判断にも、決済に対する要求に自覚的である必要があります。
阿武野
Stripe を使って開発するにも、Stripe に合わない部分まで調べ切った上でコードで書く必要があります。そのほかの PaaS なども同じです。クラウドの PaaS などを使うと、コードとしてはビジネスロジックだけ書くようになります。
シグマ子
ちなみに、Stripe に合わなかったところというと、どのあたりでしょうか。
阿武野
開発者への資金の転送が今回の要件に合いませんでした。似たような機能はあるのですが、Gateboxユーザの支払ったお金を30日の猶予期間のあとにデベロッパーに転送するという処理は Stripe のみでは実現できなくて、バッチ処理書いてAzure Functionsで動かしています。コードとしては50行に満たないようなコードです。
久森氏
認証についても、ユーザーアカウントも開発アカウントも、Azure AD/Azure AD B2C に任せることで大幅にショートカットできました。認証を自社開発することが競争優位性ではないので、最初から作らないと判断していた部分です。
冨田
Getebox の中の人も含めて、すべてのユーザーが Azure AD と Azure AD B2C 上で管理されている状態になりました。
動けばいいというものではないから、あえて作らない
シグマ子
Cosmos DB も使っているんですね。
久森氏
カラムが柔軟に変更できるので助かりました。
阿武野
それに加えて、トランザクション設計で、排他制御がすごく楽に実装できるというのもありました。また、Cosmos DB はレイテンシ保証があって、パフォーマンスの劣化が少ないというのもあります。
久森氏
今回は、SQL Database だったら辛かったと思います。いまのところ、4 か月ノーメンテで動いています。 あと、リリース直後に発表された Autopilot 機能も早速利用していて、そのおかげでリリース当初起こっていたキャパシティ設定の課題が解消し、コスト効果も高まりました。
阿武野
Cosmos DB はSQL Databaseと比べて、向いていない場合などもあるのですが、今回の要件ではCosmos DB は非常にマッチしていました。 WebHook 機能を実現するために使用した Azure Event Grid あたりで、Subscribe を動的に追加したりと、あまりやらない使い方をしています。
冨田
ディベロッパーにイベントを通知する仕組みで、動的に通知するようになっています。
阿武野
WebHook の実装も、プログラムでガリガリ作ることもできますが、あえて Azure のサービスを使って、「作らない」ことを選択しました。
冨田
動けばいいというのではなく、開発者もユーザーも大量にいても応えられる必要がありますね。 運用の問題もあります。作ってしまったがために、時期をつぶしてしまってはいけない。
久森氏
全般的に “よい匙加減” だったと思います。
プロジェクトをまとめて Monorepo に変更
久森氏
（チャットのログを見ながら）Visual Studio のソリューション構成なども変更しましたね。
鈴木
CI を回すためにはこう変えましょうというように、どんどん提案して、複数のプロジェクトをまとめて Monorepo 構成にしました。
久森氏
1つのリポジトリに24プロジェクトぐらい入っています。結果として、Monorepo 構成にしてよかったと思います。プロジェクト全体にわたって、アトミックに更新できないといけないので。
Monorepo にしたことで、安心感のあるビルドとデプロイができるようになりました。
Azure DevOps の Azure Pipeline で全部ビルドするといったように、Monorepo が Azure DevOps に向いていると感じましたし、正しく使えたと思います。
阿武野
このような大幅な変更ができたのは、請け負って作るだけの関係ではなく、いっしょにいいものを作ろうねという関係だったからだと思います。
久森氏
「どう考えてもこの構成がいいよね」という技術的な話が通じやすい関係を作れたことも大きかったですね。 もともとあった API は私がメンテして、書いてもらったライブラリをこちらでも参照しますね、というようにいっしょに開発していました。
少ない人数でどう作るかが見えた
少ない人数でどう作るかが見えた
シグマ子
最後に、今回の件でシグマコンサルティングだからうまくいった点を教えてください。
久森氏
たくさんがありますが、Microsoft MVP の人が揃っていたのは大きいですね。Azure を使って仕事をこなせそうな人が一番いると思っていて。その結果、狙いどおり着地できました。あとは、仕事に対する考えかたにも信頼感がありました。
冨田
我々から Gatebox さんを見た場合、要件定義のミーティングを1回あたり5時間やってくれる人がいたというのが大きいですね。本当にこれでいいんですか、という問いを、会社に持ち帰るのではなく、実際にその場で聞いてくれるという。 かつ、何を作らないかということで、今回は、上を説得するためだけの不要な資料は一切書きませんでした。コードを書くのに必要なものだけです。
久森氏
このプロジェクトでは私が最終意思決定者だったので、持ち帰っても考えるのは私なんで(笑)
冨田
今回のようなプロジェクトですと、技術以外の部分で決めなくてはならないことも、いろいろあります。たとえば、経理の人やサポートの人などの部分です。久森さんは、そういった関係者を実際に連れてきてくれました。
久森氏
必要だと思ったらすぐに自社の財務担当の人に事前に話して、こういう資料を持ってきてほしいと手配したりしました。 実際にミーティングに出てもらうことも含めて対応していくことで、話が捻じ曲がることなく理解してもらえるという判断でした。
阿武野
もう一つ弊社ならではの長所として、今回のような PaaS/サーバレス を使いこんでいることがあります。単に機能を知っているというだけでなく、こうやるとうまくいかないとか、こうした方がいいとか、実践的なことを知り尽くしていなければ、今回のような開発はできません。経験を持っているからこそ、技術選択で迷うことがないともいえます。
冨田
こういったプロジェクトは、少し前であれば、何十人や何百人がかりでしたが、いまは少ない人数でもできる世の中になりました。そうした少ない人数でどうやるかが、今回のプロジェクトで見えました。
シグマ子
ありがとうございました。
お問い合わせはこちらから
問い合わせる
