ネットプロテクションズ(以下、NP)にはエンジニアがたくさんいることをご存じでしょうか?
NPというと、「後払い決済の会社」というイメージを持つ方が多いかもしれません。一方で、実は約100人の技術人材を抱える大規模な技術組織があることは、あまり知られていません。バックエンド・フロントエンドエンジニア、データサイエンティストなど、多様な専門性を持つメンバーが事業づくりに携わっています。
システムを設計し、開発することはエンジニアにとって重要な仕事です。しかしNPでは、それに加えて「事業をどう成長させるのか」「どのような構造でサービスを運営するのか」といった問いにも、技術人材が深く関わっています。
後払い決済という事業では、与信、請求、回収、加盟店との取引、法令対応など、多くの要素が複雑に絡み合います。そのため、事業側が考えたものを技術側が実装するという単純な役割分担では成り立ちません。事業と技術が一体となって、サービスそのものを設計していく必要があります。
そうした環境の中で、技術をベースに事業構造そのものを設計する役割を担うのが「ビジネスアーキテクト」(以下、BA)です。
今回は、NP掛け払いの設計をリードするエンジニアの取り組みを通して、NPのBAがどのような視点で事業と向き合い、どのような価値を生み出しているのかをご紹介します。
NPの技術組織が向き合っていること
NPには約100名の技術人材が在籍しています。BtoC・BtoB双方の事業を支えるバックエンドエンジニアやフロントエンドエンジニアに加え、与信モデルの開発を担うデータサイエンティスト、システム全体の設計を担うソリューションアーキテクト、セキュリティや技術組織開発を専門とするチームなど、多様な専門性を持つメンバーが活躍しています。
そうした専門性を持つ技術人材に共通して求められているのが、「技術を使って事業を創り、成長させる」という視点です。
そこで、NPでは「ビジネスアーキテクト」という組織として再定義しました。BAは単なるエンジニアではなく、事業の成長戦略や業務フローを理解したうえで、それを実現するシステムやプロダクトの構造まで設計する技術職です。
NPがBAを重要な役割として位置づけているのは、後払い決済という事業そのものが、技術とビジネスを切り離して考えられない領域だからです。
後払い決済の裏側には、与信、請求、回収、加盟店との取引、法令対応など、多くの要素が複雑に絡み合っています。そのため、事業を成長させるには、単に機能を開発するだけでは十分ではありません。
どのようなビジネスモデルを構築するのか。事業はどのように成長していくのか。制度変更や市場環境の変化にも対応できる構造になっているのか。こうした問いに向き合いながら、事業と技術を一体で設計していくことが求められます。
事業サイドと技術サイドが密接に連携するNPにおいて、エンジニアはそのビジネスと技術の両面から全体最適を考える役割を担っています。システムをつくること自体が目的ではなく、事業が持続的に成長できる構造を描き、それを技術によって実現していく。だからこそ、NPは「事業を設計する者たち」としてビジネスアーキテクト(BA)という組織名としているのです。
事例で見る、ビジネスアーキテクトの仕事
では、実際にBAは現場でどのような役割を担っているのでしょうか。これまで複数の事業の設計をリードしてきたエンジニアの春田の業務をご紹介します。
春田 岬(Haruta Misaki)
新卒でネットプロテクションズに入社。AFTEE、atone、NP掛け払いを中心に、新規事業の立ち上げから既存事業の成長フェーズまで幅広く経験。現在は事業の成長を見据えた事業構造まで踏まえたプロダクト設計やエンジニア組織をリードしている。
事業の成長を見据えて構造を設計する
BAの仕事を理解するうえで重要なのは、「何をつくったか」ではなく、「どのような構造を設計したか」という視点です。
その一例が、NP掛け払いにおける取り組みです。
NP掛け払いは2013年に立ち上がったサービスであり、春田さんが本格的に関わり始めたのは2021〜2022年頃。ゼロから事業を立ち上げるフェーズではなく、すでに一定の事業基盤を持つサービスをさらに成長させる「10→100」のフェーズでした。
しかし当時の状況は決して順調ではありませんでした。2020年頃、融資に関するコベナンツ統制を契機としてIT組織が縮小し、徐々に運用保守中心の体制へ移行。新規開発は投資対効果の観点から優先順位を上げづらく、設計と開発の分断も進んでいました。新規の企画は投資対効果が見合わず動かせない状態が続き、プロダクトは運用保守中心のフェーズに停滞していました。加えて、開発と設計の分断によって全体像を理解する人も減少し、プロダクトはブラックボックス化していきました。
こうした状況に対して、春田さんが最初に取り組んだのは組織体制とプロダクト全体構造の見直しでした。
誰がどの領域を理解しているのか。どのような意思決定プロセスになっているのか。現在のアーキテクチャは将来の事業成長に耐えられるのか。そうした全体構造を整理した上で、オンプレミス環境からクラウド環境への移行を含む再アーキテクチャを進めていきました。
コードを書く前に、まず構造を見直す。目の前の課題ではなく、その課題を生み出している原因に向き合うことが、春田さんのアプローチでした。
ビジネス側の視点を持つ」とは何か
春田さんは、プロダクト設計を「都市計画」に近いものだと捉えています。
街づくりでは、まず道路や区画、用途地域といったルールを決め、街全体のグランドデザインを描きます。その上で住宅や商業施設が建ち、人が集まり、街が発展していきます。
プロダクト設計も同じです。
春田さんが意識しているのは、目の前の機能をどう作るかではありません。事業の発展に合わせてプロダクトと組織がどのように発展していくのか、その全体像を描くことです。各機能が事業全体の中でどのような役割を担うのか。将来的にどのような拡張が想定されるのか。組織が大きくなっても保守し続けられる構造になっているのか。そうした観点から設計を行っています。
もしこうしたグランドデザインが曖昧なまま、その時々で最も簡単な実装や短期的な要望への対応を積み重ねればどうなるでしょうか。街でいえば、無秩序な増改築が繰り返された状態になります。道路は複雑になり、新しい建物を建てる余地もなくなり、全体を理解できる人も限られてしまいます。
春田さんが重視しているのは、まさにそうした状態を防ぐこと。事業が3年後、5年後にどう発展するのかを見据えながら、持続的に成長できる構造を設計する。個別の機能ではなく、事業全体の発展を視野に入れて技術の先にある価値を生むような意思決定を行う点に、BAならではの役割があります。
構造を変えるために、まず組織を変える
プロダクトを超えて事業の全体構造を設計するという考え方は、システムアーキテクチャだけに向けられるものではありません。事業を支える組織や意思決定の仕組みもまた、重要な構造の一部です。
実際にNP掛け払いにおいて春田さんが向き合った課題も、技術的な問題だけではありませんでした。設計と開発が分断され、プロダクト全体を見渡しながら意思決定できる状態になっていなかったことが、大きなボトルネックになっていたのです。
そこで春田さんは、どこに知識が蓄積されているのか、誰がどの意思決定を担っているのかを整理し直し、組織全体でプロダクトを理解できる状態づくりに取り組みました。
事業の成長を支える構造を考えるとき、システムだけを整えても十分ではありません。組織の中で知識が共有され、継続的に意思決定できる状態をつくることも同じくらい重要です。
短期的なROIだけを見れば、こうした取り組みは正当化しづらいかもしれません。しかし春田さんが重視したのは、目先の効率ではなく「事業成長に貢献するかどうか」でした。
事業が将来どのように発展していくのか。その成長を支えるために、今どのようなシステムや組織の構造が必要なのか。技術だけでなく、組織や業務プロセスまで含めて全体最適を考える。だからこそ、春田さんが最初に向き合ったのは目の前の機能開発速度ではなく、構造そのものだったのです。
こうした考え方は、NPの技術組織全体にも通じています。NPでは事業運営を支える重要なシステム群の内製化を進めていますが、その目的は単に開発スピードを上げることだけではありません。事業を最も理解しているメンバー自身がプロダクトをコントロールし、知識やノウハウを組織に蓄積しながら、変化に応じて主体的に意思決定できる状態をつくることにあります。
また近年は、AIの進化によって技術者に求められる役割も変化しつつあります。実装や情報収集のハードルが下がるほど、人に求められるのは「どうつくるか」だけではなく、「何を目的に何を実現するか」を考える力です。事業の構造を理解し、技術を活用しながら価値を生み出す仕組みそのものを設計する。それにいち早く対応できるのが私たちBA組織だと考えています。
おわりに
NPのビジネスアーキテクトにとって大切なことは、磨いた技術のその先に、価値を生む構造を設計する力です。
事業の成長戦略や業務プロセス、組織のあり方まで含めて全体構造を捉え、その構造を技術によって実現可能な形へ落とし込んでいく。ビジネスと技術の境界に立ちながら、事業そのものを設計していく役割です。
目の前の要件を実装するだけではなく、「事業はどうあるべきか」「プロダクトはどう発展していくべきか」という問いから考えたい。技術を手段として、事業や組織の成長にまで踏み込んで価値を生み出したい。そんな人にとって、NPのビジネスアーキテクトは大きな挑戦機会がある仕事です。
AWSハッカソンで入賞/AWS re:Invent 2025に参加