1人目エンジニアがプロダクトリリースで実感した「切っても切れない関係」　経営・事業・開発が一体になった組織は、事業推進を加速させる

相澤氏の自己紹介

相澤雄大氏（以下、相澤）：続いてネットプロテクションズから発表します。ほかの方と少し毛色が違いますが、私は「1人目エンジニア」としてお話しします。

あらためまして自己紹介ですが本日発表する相澤といいます。後払い決済を日本で初めてつくった、ネットプロテクションズという会社でアーキテクトをしています。

経歴は次のページにも書いているので飛ばしますが、ちょっとだけプライベートな話をすると、サウナがすごく好きです。2日に1回は、東京か埼玉のどこかのサウナにいるという感じで、サウナ好きな方も、よかったらお話とか仲良くしていただければなと思っています。

本セッションの目次とatoneの紹介

本日お話しすることです。私は、最初に新卒でフューチャーアーキテクトという会社に入って、そのあとで事業会社に来て、1人目エンジニアとして決済事業の立ち上げに関わりました。

その過程で、ポイント会員事業やカード事業の経験を経て、BtoC向けのカードレス決済の「atone」を立ち上げました。このatoneを立ち上げた時の話をします。

目次です。本編に入る前に、「atoneと言われてもよくわからんぞ」という人もいると思うので、atoneについて最初に簡単に説明させてください。

atoneは何かというと、クレジットカード不要で、誰でも・すぐに・便利に・お得に、ECサイトと実店舗の両方で使える会員登録制の後払い決済サービスです。スマホアプリをダウンロードすると、利用状況の確認やコード決済も可能になります。

atoneは、シンプルでわかりやすい、「やさしい後払い」というものを提供しています。最近はいろいろな決済手段が出てきていて、みなさんもいろいろと使っていると思います。買い物をする時に、そういった決済を含めて不安を抱えている人って、実はけっこう多いんですね。

その中でatoneは、買い物やお金管理の不安をちゃんと取り除いてあげて、安心してお買い物ができるというような、そんなサービス設計で作っています。

もう1つ、ネットプロテクションズという会社が目指す、開発組織と機能群についても、ちょっと最初に補足したいです。ネットプロテクションズは複数の事業を運営していて、開発組織とともに横断思想でシステムを育てて資産価値を上げていくところを目指してやっています。

例えば、ネットプロテクションズは複数の決済事業を運営していて、「NP後払い」という事業を最初に作りました。このために構築した与信の仕組みというのは「この単一事業だけじゃなくて、ほかの事業でもちゃんと活用できるように」というところを意識して取り組んでいます。

あらためてになりますが、今日は、この中でatoneの話をします。

atoneが立ち上がる時は、創業当初から運営していたNP後払い事業とポイント会員という2つを複合的に考えて立ち上げる必要がありました。

組織が育たなければシステムは育たない

前置きが長かったですが、勉強会ということで、本日伝えたいメッセージを3つ持ってきました。

1つ目が、「組織が育たなければシステムは育たない」という話。2つ目は、「技術の弱みというのは使い方次第でカバーできる部分もあるんだな」という話。あと3つ目は、「三位一体だから苦難も乗り越えられた」というところで、これらを一つひとつ説明していきたいと思っています。

最初は「組織が育たなければシステムは育たない」というところです。ここでは、開発組織とシステム構成という2つのトピックでお話しできればなと思っています。

まず「本当はもっとこうしたかったな」という話をします。新規事業への参画が決まった時は、「開発組織もシステム構成も潤沢な予算を手に入れて、後払いやポイント会員の刷新と合わせた開発体制を敷いていきたいな」とか。

あとは、構成においても会員事業の柱になることはわかっていたので、「複数の決済事業で活用できる横断的なプラットフォームというものを構築していくんだ」といった野望を持っていました。

ただ、実際はというところで、エンジニアは自分1人しかいなかったんですね。そのために、限られた予算の中で開発体制をどう増やしていくかも考えなければいけなかったんです。さらに、コードを書ける人がいなかったので、教えながら作っていく必要がありました。

なので、貴重な予算の大半は、当時の体制でちょっと内製化が難しかったスマホアプリの領域へ投じたりしました。

システム構成のところも余裕はまったくなかったので、既存資産を活かして最小限の開発工数で実現できる構成を選択しました。

独立して構成する部分と、既存システムのシナジーを考える領域を見極めてやることがすごく大事だなと思っていて。独立して構築すると、システム開発的にはやはり速くなるので、市場ニーズに合わせた新規機能開発を速く行えるメリットもあるんですね。

あと、出してみないとちょっとわからない領域はやはりあるので、仕様を固定せずに、あえて作り込み過ぎない。そういった戦略も取りました。

ただ、重要なリスクコントロール領域とか、そういったところは横断的なデータ活用ができるような構成で構築したり。あとは「ここだけはサービス化したいな」というところも、どうしても最初は難しかったので、初手はあえてデータ連携させて、後から作り直すみたいなアプローチをしたりもしました。

開発組織のところで、今振り返ってみて思うことを書いています。システム開発は組織開発ということで、決済システムは1人の力では本当にどうにもならなかったなと。ここの話は、後半パートにもちょっとつながっていくので、そちらで詳しくお話しできればなと思っています。

もう1つ、構成のほうです。事業を立ち上げながら未来に向けて資産価値を上げることは本当に大変だというところです。決済は面取りの勝負の世界なので、先手を打つ開発がすごく大事です。これがある種、資産性がある取り組みだとも十分理解できますが、一方で、常に将来の構成を見据えながら今に取り組むべきだなと思っていて、そうしないとやはり技術負債の溜まり方が違ってくるということを実感しています。

絶対に譲れないものは主目的で変えて、それ以外のものは事業上ROI（Return On Investment）の高い機能開発があるので、こういったところと一緒に混ぜ込んで構成を変えていくみたいなアプローチが多かったと思っています。

技術の弱みは使い方次第でカバーできる

続いて、「技術の弱みは使い方次第でカバーできる」というところです。ここでは技術選定というトピックでお話をします。

技術選択における制約というところで、エンジニアは自分1人で、開発組織において選択できる技術は限られていました。未経験でも習熟が容易で、少ないリソースで早く立ち上げられる技術を選択する必要があったのです。

採用実績や実務経験でいうとJavaでしたが、当時、個人的に取り組んでいたRailsという選択肢があがってきました。

ただ、ここは本当に悩みまして。本当にRailsで決済システムを作っていいのかなって、「うーんうーん」という感じで葛藤していました。

このスライドでは、エンジニア1人状態でRailsを使って決済システムを作る時という限定的なところで、強みと弱みをまとめました。

未経験者でも習熟が容易で、フルスタックなフレームワークでライブラリを活用できると開発工数を最小限に抑えられる。こういったメリットがあります。

一方で、品質やパフォーマンスとか、複数のシステムを作らなければいけなかったので、この選択が本当に正しいのかは悩みました。

この点においては、技術の弱みをカバーする戦略を取ることで、小さな開発組織で迅速な立ち上げを実現できたなと思っています。

品質を求める点においては、テストコード文化ですね。これは型が動的だからこそ、Rubyは当時からすごく成熟していたと思っています。それと、厳格なCI/CDを組み入れて、統合ブランチに誤ったコードが入らないように構築したりとか。

あとは多段階のレビューフローを設けて、サービス仕様面と技術面の両方からチェックするのがけっこうポイントだなと思っていて、ここを徹底しました。

パフォーマンス面においては、初期は許容できる部分もあったので、そこは弱みを許容して、システム移行計画を立てた上でリプレイスしたり。あとは、そのままでもアプリケーションの並列化をしたりというところで、チューニングすることで改善していきました。

システムを複数立ち上げる必要があった点については、Railsをそのまま使うことはせず、共通のビジネスロジック層以下のところをGem化して、フルスタックの恩恵は受けつつも、複数のシステムで同じコードを活用できるようなアプローチをしました。

（スライドを示して）参考までに立ち上げ当初のatoneのシステムというところで、こんな感じになっていますね。補足として、サービスローンチ当初はEC決済のみで、現在はフロントエンド領域をはじめとして、別の技術でリプレイスしているところもあります。（あくまで）当時の構成です。

三位一体だから苦難も乗り越えられた

最後に「三位一体だから苦難も乗り越えられた」というところについてお話しします。

三位一体は何かと言うと、開発と事業と経営です。「本当はこうしたかった」（という）話ですが、atoneの立ち上げにおいて、実は1度大きな事件が起きました。課題を抱えながらもなんとかすべてのシステムを構築して、「さぁ、これからリリースだ！」という時に事業が一時停止するという、けっこうショッキングな事件が起きました。

これは親会社の意向みたいなところがありましたが、ちょっとだけ背景を補足すると、ネットプロテクションズは過去に親会社が3度変わっていて、当初は主要株主の親会社が変わって間もないタイミングだったんですね。

今は2021年に東証一部、現在のプライム市場に上場を果たしていますし、現在では、親会社に納得してもらう戦略の幅の中でしか動けないということはなくて、株主に向き合った上でですが、自由な経営ができるようになっています。

そんなところで、完成したシステムが目の前にあるので、正直かなりショックで。当時、メンバーの一部がひどく打ちひしがれていました。

ここでまた転機が起きまして、約1年後に再稼働いたしました。これもまた親会社が変わって追い風というところですが、ここから半年後にリリースを目指して再びスタートすることになりました。ここから東証一部上場までは、アドバンテッジパートナーズさまに支援いただきながら駆け抜けていくことになります。

ここからの再スタートが、自分でも信じられないぐらいに早かったです。これは、経営・事業・開発というのが一体になっていたからこそできたなと、振り返ってみて思っています。

リリース直前で事業が止まるのは普通だったら嫌で、諦めてしまうことかもしれません。（しかし）ビジネスとシステムの垣根が低い組織というところと、経営陣とも「主戦略の1つとして絶対に復活させたいよね」というコミュニケーションが取れていたので、ここは本気で自分もそう思っていました。

あと、IT投資予算を新たに使えるようになったので、強みを活かしたエンジニア体制を整えることができたんですね。ここが成功要因としてかなり大きかったと思っています。

さらに、やはり1度作り切ると「ここだけは直したいリスト」みたいなのが手に入ります。それがあったので、懸念となっていたアーキテクチャを見直すことで、当初から品質の高い状態でリリースすることができたと思っています。

ビジネスと開発が一体になった組織は事業推進を加速させる

「BizとTechの組織の強み」というスライドで最後に締めていますが、ビジネスと開発が一体になった組織が事業推進を加速させて、次の新しい事業を生み出す土壌になるということは、このatoneの開発の経験を通じてすごく思ったところです。

また、そこに専門性の高いメンバーのサポートが加わることで、組織が強くなっていったと思っています。

一例として、このatoneという事業ですが、現在は事業責任者としてリードしている人間が、当初は開発、実装のところに携わっていたりとか。あと、atoneを一緒に作ってきたメンバーが、2018年に海外事業を立ち上げて、次世代型のスマホ後払い決済の「AFTEE」というのをつくっていたりとか。そんな経緯があったりします。