ストーリー
佐
佐藤CTO
アーキテクチャの設計図ができた。次は”何で”作るかだ
佐
佐藤CTO
技術選定は好みで決めるものじゃない。ビジネス要件、チームのスキル、エコシステムの成熟度、長期的なTCO — これらを総合的に評価して、根拠を持って判断する
佐
佐藤CTO
NexPayの技術スタックを、根拠付きで選定してみよう
技術選定のフレームワーク
評価軸
技術選定では、以下の6つの観点から総合的に評価します。
技術選定の6軸:
① 機能適合性 -- 要件を満たすか？
② チーム適合性 -- チームが使いこなせるか？ 採用市場はあるか？
③ エコシステム -- コミュニティ、ライブラリ、ドキュメントの充実度
④ 運用性 -- 監視、デバッグ、障害対応のしやすさ
⑤ TCO -- ライセンス費、学習コスト、運用コストの総計
⑥ リスク -- ベンダーロックイン、EOL、セキュリティリスク決定マトリクス
技術選定マトリクス（例: プログラミング言語の選定）
| 機能適合 | チーム | エコシステム | 運用性 | TCO | リスク | 加重合計 |
重み | 0.25 | 0.20 | 0.20 | 0.15 | 0.10| 0.10 | |
──────────────────────────────────────────────────────────────────────────
Kotlin | 5 | 4 | 4 | 5 | 4 | 4 | 4.40 |
Go | 4 | 3 | 4 | 5 | 5 | 4 | 4.05 |
TypeScript | 4 | 5 | 5 | 4 | 5 | 4 | 4.45 |
Java | 5 | 4 | 5 | 4 | 3 | 4 | 4.30 |
→ Kotlin と TypeScript が僅差。コアサービスはKotlin、BFFはTypeScriptに決定「数値化すると議論が”好み”から”根拠”に変わる。スコアの差が僅差なら、チームの得意な技術を優先するのも合理的な判断だ」 — 佐藤CTO
NexPayの技術スタック
言語・フレームワーク
| レイヤー | 技術 | 選定理由 |
|---|---|---|
| バックエンド（コアサービス） | Kotlin / Spring Boot | 型安全、JVMの実績、コルーチンによる非同期処理、金融系での採用実績 |
| BFF / API Gateway | TypeScript / Node.js | フロントエンドチームとの技術的親和性、Kong/Envoy連携 |
| モバイル | Flutter / Dart | iOS/Android統一開発、決済UIの高品質な描画 |
| Web Dashboard | Next.js / TypeScript | SSR/SSG、加盟店ダッシュボードのSEO不要→SPAでも可 |
| データパイプライン | Python | データサイエンスエコシステム、不正検知モデルの開発 |
データストア
■ データストア選定
Aurora PostgreSQL（メインDB）:
選定理由:
- ACID準拠: 金融取引の整合性保証に必須
- Global Database: マルチリージョンレプリケーション
- Performance Insights: クエリレベルの性能分析
- PCI DSS対応: AWS上での金融サービス実績が豊富
代替案と却下理由:
- CockroachDB: 分散SQLとして優秀だが、AWSマネージドでないため運用負荷が高い
- DynamoDB: トランザクション要件にはRDBの方が適切
DynamoDB（補助DB）:
用途: KYC書類メタデータ、セッション管理、Feature Flags
選定理由:
- ミリ秒レイテンシ: セッション参照に最適
- サーバーレス: キャパシティ管理不要
- オンデマンド課金: アクセスパターンが不均一なデータに最適
ElastiCache Redis:
用途: 残高キャッシュ、セッション、レート制限カウンター
選定理由:
- インメモリ: p99 < 1msの低レイテンシ
- データ構造: Sorted Set（ランキング）、HyperLogLog（ユニーク数集計）
- クラスターモード: 水平スケーリング対応インフラ・ミドルウェア
| カテゴリ | 技術 | 選定理由 |
|---|---|---|
| コンテナオーケストレーション | Amazon EKS | Kubernetes標準、マルチクラウド移行の選択肢を確保 |
| サービスメッシュ | Istio | mTLS、トラフィック制御、サーキットブレーカー |
| メッセージング | Amazon MSK (Kafka) | 高スループット、イベントソーシング基盤、耐障害性 |
| CI/CD | GitHub Actions + ArgoCD | GitOpsフロー、Kubernetes native |
| IaC | Terraform + Terragrunt | マルチリージョン管理、モジュール再利用 |
| 可観測性 | OpenTelemetry + Grafana Stack | ベンダーニュートラル、メトリクス/ログ/トレースの統合 |
| シークレット管理 | AWS Secrets Manager + External Secrets | Kubernetes連携、自動ローテーション |
Build vs Buy vs OSSの判断
NexPayでの判断例
■ Build vs Buy vs OSSの判断マトリクス
| 機能 | 判断 | 理由 |
|------|------|------|
| 決済処理エンジン | Build | コアコンピタンス。競争優位の源泉 |
| 不正検知エンジン | Build | 差別化要因。自社データでの学習が必要 |
| 認証基盤 | Buy (Auth0/Cognito) | 汎用機能。自社構築はセキュリティリスク |
| 通知配信 | OSS (Apache Camel) + Build | カスタマイズが必要だがコア機能ではない |
| 管理ダッシュボード | Build (内製) | 業務フローに密結合。汎用SaaSでは要件不足 |
| 監視基盤 | OSS (Grafana/Prometheus) | 成熟したOSS。マネージドサービスも選択肢 |
| ログ基盤 | Buy (Datadog) or OSS (ELK) | 運用負荷を考慮し、マネージドを推奨 |
判断基準:
コアコンピタンス → Build（差別化の源泉は内製）
セキュリティクリティカル → Buy（認証は専門ベンダーに任せる）
汎用・非差別化 → OSS or Buy（自社リソースを集中すべき領域ではない）「“全部自前で作る”はエンジニアの自尊心を満たすが、ビジネスには貢献しない。コアコンピタンスに集中し、それ以外は賢く外部に頼る — これがCTOの判断だ」 — 佐藤CTO
技術選定のADR
ADR-001: バックエンド言語の選定
# ADR-001: バックエンド言語としてKotlinを採用
## ステータス
承認済み (2026-01-15)
## コンテキスト
NexPayのコアサービス（決済、送金、投資）の開発言語を選定する必要がある。
要件: 型安全性、高い並行処理性能、金融系での実績、チームの採用可能性。
## 決定
Kotlinを採用する。
## 根拠
1. 型安全性: Null安全により実行時エラーを大幅に削減
2. コルーチン: 非同期処理を同期的に記述でき、可読性が高い
3. Spring Boot: 金融系での豊富な実績と成熟したエコシステム
4. JVM: パフォーマンス、GCチューニング、監視ツールの充実
5. 採用: Java経験者のKotlin移行は容易（学習コスト低）
## 検討した代替案
- Go: パフォーマンスは優秀だが、ORMやDIの成熟度が劣る
- TypeScript: フルスタック統一の利点はあるが、大規模金融システムの実績が少ない
- Java: 安定だが、Kotlinと比べて冗長。新規開発ではKotlinが優位
## 影響
- チーム全員にKotlin研修（2週間）が必要
- Spring Bootのバージョンアップに追従するコストまとめ
| ポイント | 内容 |
|---|---|
| 評価軸 | 機能適合性、チーム適合性、エコシステム、運用性、TCO、リスクの6軸 |
| 決定マトリクス | 加重スコアで客観的に比較。僅差ならチーム得意技術を優先 |
| Build vs Buy vs OSS | コアコンピタンスはBuild、汎用機能はBuy/OSS |
| ADR | 選定理由と却下理由を含めて記録。将来の再議論を防止 |
チェックリスト
- 6軸の評価フレームワークで技術選定を行えた
- 決定マトリクスを作成し、加重スコアで客観的に比較できた
- Build vs Buy vs OSSの判断基準を理解した
- 技術選定のADRを作成し、根拠と代替案を記録できた
次のステップへ
次は「CI/CDパイプライン設計」に進みます。選定した技術スタックをどのようにビルド・テスト・デプロイするか、パイプラインを設計しましょう。
推定読了時間: 40分