見出し画像

経営・事業・開発、三位一体だったからできた。新規事業「atone」を作ったエンジニアのプロダクトマネジメントについて

こんにちは。ネットプロテクションズ(以下、NP)ビジネスアーキテクトグループの相澤です。ビジネスアーキテクトグループはビジネス企画からシステム開発までの責務を一気通貫で担うNPのエンジニアリング組織です。

8月30日の開発PM勉強会(テーマ:スタートアップや新規事業、1人目PMって何するの?)で「決済システムは一人ではつくれなかった話」というタイトルで登壇しました。

新規事業の立ち上げをする中で「一人目エンジニア」として直面した課題や、その解決方法を経験談としてシェアします。似た境遇の方やPMの採用および受け入れを考えてる方の参考になれば幸いです。

登壇テーマ

  • 事業会社に来て「一人目エンジニア」として決済事業を立ち上げたときの話をします。簡単に経歴をご紹介します。

  • 新卒でフューチャーアーキテクト株式会社に入社し、小売流通系の2つのプロジェクトを通じてシステム開発の企画・要件定義・設計・実装の経験を積みました。

  • NPに来てからは、ポイント会員事業やクレジットカード事業のシステム開発推進を経験し、BtoC向けのカードレス決済「atone」を立ち上げました。

  • 今回は、この「atone」を立ち上げたときの話をします。

はじめに

atoneとは

  • 本編に入るまえに「atone」についての補足です。

  • atoneはクレジットカード不要で誰でも・すぐに・便利に・お得に使える後払いサービスです。

  • シンプルで分かりやすく、安心してお買い物ができる「やさしい後払い」を提供します。

開発組織と事業を支える機能群

  • もう1つ、NPが目指す開発組織と機能群についてです。

  • 複数の事業を運営しているNPは、開発組織と共に横断思想でシステムを育て「資産価値」を上げていく取り組みを行っています。

  • NPは複数の決済事業を運営していますが、たとえば「NP後払い」のために構築した与信の仕組みは、単一事業だけでなく、他事業での活用も意識して取り組んでいます。

atoneが立ち上がるときの状況

  • atoneを立ち上げるときには、創業当初から運営していた「NP後払い」事業と「ポイント会員」のシステムがありました。

  • これらを複合的に考えてatoneを立ち上げる必要がありました。

お伝えしたいこと

  • お伝えしたいことをキーメッセージとしてスライドにまとめました。

  • 1点目は「組織が育たなければシステムは育たない」です。

  • 2点目は「技術の弱みは使い方次第でカバーできる」です。

  • 3点目は「三位一体だったから苦難も乗り越えられた」です。

開発組織とシステム構成

  • まず「組織が育たなければシステムは育たない」についてです。

  • ここでは開発組織とシステム構成についてお話します。

  • 新規事業への参画が決まったときは、開発組織もシステム構成も、潤沢な予算を手に複合的にアプローチして未来につながる良いモノをつくりたいと思っていました。

  • 開発体制で言えば「NP後払い」や「ポイント会員」の刷新も視野に入れたかったです。また、システム構成においても、会員事業の柱となるので、複数の決済事業で活用できる横断的なプラットフォームを構築していく野望を抱いていました。

  • でも実際は、新規事業なんてそんなものかもしれませんが、エンジニアは「自分ひとり」しかいませんでした。

  • そのため、限られた予算の中で組織(開発体制)をどう増やしていくかも考えなければなりませんでした。

  • さらに、コードを書ける人がいないので教えながらつくっていく必要がありました。

  • 限られた貴重な予算は、決済システムとして必要なセキュリティ対策や、当時の体制で内製化が困難だったスマホアプリ開発の領域に投資しました。

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

  • そのうえで、独立して構築する領域と既存システムとのシナジーを考える領域を見定めました。

  • 独立して構築することで市場ニーズに合わせた新規機能開発を速く行えるメリットもあります。また、実際に使ってもらわないと分からない領域は仕様を固定せずにあえて作り込みすぎない戦略もとりました。

  • その一方で、重要なリスクコントロール領域は横断的なデータ活用を視野に入れてシステムを構築しました。

  • また、先々でのサービス化を視野に入れつつ、初手はあえて既存システムとデータ連携させて構築することもありました。

  • ここでは、今振り返って思うことについて書いてます。

  • 開発組織においては、システム開発は組織開発であり、決済システムは一人の力では本当にどうにもならないということです。この話は後半パートにもつながっており、そちらで詳しく説明していきます。

  • システム構成においては、事業を立ち上げながら、未来に向けて資産価値もあげる取り組みは本当に大変だということです。

  • 決済なので、先手を打つ開発の必要性も十分に理解できます。それでも、常に将来の構成を見据えながら、今に取り組むべきだと思います。

  • 絶対に譲れないものは主目的で刷新しました。それ以外のものは、事業上ROIの高い機能開発を行う際に、一緒に混ぜ込んで刷新していくアプローチが多かったです。

技術選定

  • 続いては「技術の弱みは使い方次第でカバーできる」についてです。

  • ここでは「技術選定」というトピックでお話します。

  • エンジニアは自分ひとりの開発組織において選択できる「技術」も限られていました。

  • 未経験者でも習熟が容易で、少人数でもはやく開発組織を立ち上げることができる技術を選択する必要がありました。

  • そのような中で、採用実績もあり実務経験もあった「Java」ではなく、当時、個人的に取り組んでいた「Rails」が選択肢にあがりました。

  • ですが、本当にRailsで決済システムをつくって良いのだろうかと当時は真剣に悩みました。

  • このスライドでは、エンジニア1人状態で「Ruby on Rails」を使って決済システムを作るときの「強み」と「弱み」をまとめています。

  • 未経験者でも習熟が容易であり、フルスタックなフレームワークやライブラリを活用して開発工数を最小限におさえられるメリットはあります。

  • 一方で、品質やパフォーマンス、複数のシステムを構築する必要がある中で、果たしてこの選択が正しいのかと最後まで悩みました。

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

  • 品質を求める点においては、テストコード文化と厳格なCI/CDを組み入れ、統合ブランチに誤ったコードが入らないよう仕組みを準備しました。また、多段階のレビューフローを設け、サービス仕様と技術の両面からチェックするよう徹底しました。

  • パフォーマンス面においては初期は許容できる部分もあったので、システム移行計画を立てた上でリプレイスまたはチューニングを実施しました。

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

  • ご参考までに、立ち上げ当初のatoneのシステム構成をご紹介します。

  • サービスローンチ当初は「EC決済」のみでした。

  • 現在はフロントエンド領域をはじめ、部分的に別の技術でリプレイスしています。

事業と経営

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

  • 三位とは何か?というと、開発と事業と経営の3つです。

  • 実はatoneの立ち上げにおいては一度大きな事件が起きました。

  • 課題を抱えながらも、なんとか全てのシステムを構築。最後の総合テストも間もなく終えて、さぁこれからリリースだという時に…

  • 親会社の意向により事業が一時停止するというショッキングな出来事が起こりました。

  • ここの点について少し背景を補足させていただくと、NPは過去に親会社が3度変わっていて、当初は主要株主(親会社)が変わって間もないタイミングでした。

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

  • 完成したシステムが目の前にある中での事業停止はかなりショックで、当時はメンバー一同ひどく打ちひしがれていました。

  • ですが、ここでまた転機が訪れます。

  • ストップからおよそ1年後、再び親会社(株主)の変更を受けて、半年後のリリースを目指して再びスタートすることになりました。

  • ここから東証一部上場までアドバンテッジパートナーズ様にご支援をいただきながら駆け抜けていきます。

  • そして再スタートからローンチまでが、信じられないくらいに早かったです。これは、経営・事業・開発が一体になっていたからだと振り返ってみて思います。

  • リリース直前で事業が止まる = 普通だったら嫌になってあきらめてしまうことかもしれませんが、ビジネスとシステムの垣根が低く、経営陣とも主戦略の1つとして絶対に復活させたいというコミュニケーションが取れていたので、ここは本気でそう思ってました。

  • また、IT投資予算を新たに獲得し、強みを活かせるエンジニア組織体制を整えることができた点も成功要因として大きかったです。

  • さらに、一度作りきっていたからこそ事業性質を考えたときに「ここだけは直したい」リストが手元にありました。

  • 懸念となっていたアーキテクチャを見直すことで、より品質の高い状態でシステムをリリースすることができました。

  • ビジネスと開発が一体となった組織は事業推進を加速させて次の新しい事業を生み出す土壌になると考えています。

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

  • 現在、atoneでは事業立ち上げ初期からシステムの実装を一部担っていたメンバーが事業責任者として事業をリードしています。

  • また、atoneの開発に携わったメンバーが翌年に海外事業として次世代型スマホ後払い決済「AFTEE」を立ち上げました。

  • サービスローンチまでのスケジュールと組織の変遷についてまとめています。

  • 最初は2名から構想実現に向けて動き出したatoneでしたが、開発組織を大きくしていきながら、一度は空白の期間を経験して、最終的には12名の体制でローンチまで漕ぎ着けました。

  • ちなみに、私が参画したのは14年5月の3人目のタイミングです。

おわりに

まとめ

  • 最後にまとめです。お伝えしたいことは「組織が育たなければシステムは育たない」「技術の弱みは使い方次第でカバーできる」「三位一体だったから苦難も乗り越えられた」の3点でした。

  • 今回のスライドをつくってみて、開発組織とシステム、そして事業は切っても切れない関係でつながっていることを改めて痛感しました。

以上です。お読みいただきありがとうございました!
スライドはSpeaker Deckでも公開しています。



ご興味を持った方へ

ネットプロテクションズでは一緒につぎのアタリマエをつくる仲間を募集しています。記事を読んでご興味を持っていただいた方は、ぜひ一度お話しましょう。

この記事が参加している募集

PMの仕事

この記事が気に入ったらサポートをしてみませんか?