2026 年 4 月 12 日、nishinomiya.dev で「サブスクで稼ぐなら、決済は”機能”じゃなく”インフラ”で選べ」というタイトルで話させてもらいました。カウンター席でお酒と料理を片手に、配信なし少人数でディスカッションするスタイルのイベントです。

登壇資料はこちらです。

この記事では、登壇して感じたことについてまとめてみました。

nishinomiya.dev で話したこと

登壇では決済サービスの技術選定は運用から選ぶ必要があるという話をしました。

決済導入は「API を叩いて支払いを通す」で終わらず、そこから請求書発行、未払いリトライ、解約処理、経理への数字共有、新プランやトライアル変更のたびの改修といった運用がずっと続きます。そのため技術選定時には開発のしやすさなどが注目されがちですが、本番はその後の運用です。

この視点からStripe の各機能 — Invoicing、Dashboard、Customer Portal、Workflows、Sigma — を「どの運用を、誰から解放する機能か」という軸で紹介しました。このあたりは機能ベースで話すことも多かったのですが、今回は運用課題ベースで触れてみました。

ちなみに自分も知って驚いたトピックとしては、「領収書PDFの発行は、決済サービスによっては存在しない」ということでしょうか。

そうそう。領収書は自分で加工してつくるものだと思ってたので、Stripeがデフォルトで発行してくれるのみて驚いた記憶ある。#nishinomiya_dev

— Masahiko Sakakibara (@rdlabo) April 12, 2026

あとは自動化などをいつ・どのタイミングでやるべきかみたいな話でも盛り上がりました。運用を見据えた自動化が必要ですが、現場がそれを運用できない自動化を組んでしまうと迂回されるというデメリットもあり、作るだけで終わらない難しさを感じます。

こういう決済周りの業務フローは最初から自動化を作り込むべきなのか、人手で回して困りごとができたタイミングで自動化するべきなんだろうか🤔 #nishinomiya_dev

— tktk / てけてけ / primeNumber SRE (@tk3fftk) April 12, 2026

運用知を得る経路としてのコミュニティ

自分が基調として扱っているコミュニティが 2 つあります。nishinomiya.dev と JP_Stripes です。この 2 つは、それぞれ違うレイヤーの運用知にアクセスできる経路として機能しています。

nishinomiya.dev は、カウンター席でお酒を飲みながら現場の話をする場です。配信もなく、記録も残さず、少人数で回ります。ここで出てくるのは「うちではこういう運用で回している」「この前これで詰まった」という、記事にはまず書かれない粒度の実感です。気兼ねなく話せるサイズで、自分と近いレイヤーのエンジニアが何を見ているかが分かります。

JP_Stripes は、CTO や経営サイドの方、Stripe 社員も参加するコミュニティです。縦と横の両方に広がっていて、自分の目線だけでは届かない情報 — 経営判断として決済をどう評価したか、プロダクト側が何を設計しているか — にアクセスできます。

この 2 つのどちらか片方だけだと、見える景色に偏りが出ます。近いレイヤーの話だけだと自分の観測範囲の延長になりますし、縦の話だけだと現場の実装で実際に何が起きているかが抜け落ちます。両方あることで、「運用で何が起きるか」を多層で先回りできるようになります。

自分にとってコミュニティは、勉強会や発表の場というより、運用知のインフラに近いものです。差し込みが降ってくる前に、差し込みの種類が見えている状態を作るための経路になっています。

運用は歴史から学ぶ

コミュニティのメリットは、運用など実践者しかしらない・アクセスできない情報に触れる機会が得られることだと思います。決済に限らず、SaaSやフレームワークでも当時は最適解だと思ったものが「こんなはずではなかった」になることは少なくありません。

リアルな現場の話を聞いてから設計などに入れる。それこそがコミュニティに参加する、輪に入るメリットではないかと思います。