RFC-0001: バックエンドAPI推奨言語の統一

概要: バックエンドAPIの推奨言語をGo（高負荷サービス向け）とTypeScript/NestJS（標準サービス向け）の2言語に統一する。既存のJava/Node.js(Express)サービスは段階的に移行する。

動機: 現在4言語（Go, Node.js, Java, Python）が混在し、ナレッジ断片化、人材流動性低下、運用負荷増大が発生。棚卸しの結果、月間約60万円の追加コストが発生していることが判明。

代替案:

• 案A: Go単一言語 → フロントとの共通化を断念。TypeScript人材を活かせない
• 案B: TypeScript単一言語 → 高負荷サービスのパフォーマンス要件を満たせない可能性
• 案C: 現状維持（4言語） → 問題が解消されない

推奨案: Go + TypeScript(NestJS) の2言語体制

移行計画:

• Phase 1（Q1-Q2）: テンプレート整備、ガイドライン策定
• Phase 2（Q2-Q3）: Express→NestJS移行（通知チーム）
• Phase 3（Q3-Q4）: Java→Go/TS移行計画策定（課金チーム）

課金チームへの回答

「ご懸念はごもっともです。Goは型安全性において Javaと同等の静的型付けを提供します。TypeScript(NestJS)もstrictモードにより高い型安全性を確保できます。ただし課金サービスは特に高い信頼性が求められるため、移行はPhase 3（最も後）に位置づけ、十分な検証期間を設けます。また、移行判断は別途RFC/ADRで議論し、技術的に懸念が残る場合は時限的例外として Java継続を認める余地を残します。」

データPFチームへの回答

「Pythonは今回のRFCの対象外（バックエンドAPI）です。データパイプライン用途でのPythonはSecondary Languageとして別途ADRで明文化します。バックエンドAPIとデータパイプラインは用途が異なるため、RFCのスコープを”バックエンドAPI”に限定しています。」

モバイルチームへの回答

「Kotlin Server Side(Ktor等) は代替案として検討しましたが、バックエンドでのKotlinの採用実績が組織内にゼロであること、日本市場での採用事例が限定的であることから、現時点ではリスクが高いと判断しました。将来的にテクノロジーレーダーのAssessに追加し、評価を継続することを提案します。」

ADR-0001 として、コンテキスト（4言語混在の問題）、検討した4つの選択肢（Go単一/TS単一/Go+TS/現状維持）、決定（Go+TypeScript）、結果（ナレッジ集約のメリットと移行コストのデメリット）を記録。関連RFC: RFC-0001、影響範囲: APIチーム、通知チーム、課金チーム。

申請1: 課金チーム → 条件付き承認

判定: 条件付き承認（時限的例外、18ヶ月）

理由: 決済処理の移行は慎重に行うべきであり、リスク評価は妥当。18ヶ月の猶予を認める。ただし以下の条件を付す:

• 6ヶ月以内に移行先言語（Go or TypeScript）の選定と移行計画をRFCで提出
• 3ヶ月ごとに進捗を技術標準委員会に報告
• 新機能追加時は可能な範囲で移行先言語での実装を検討

申請2: 新規プロジェクトチーム → 却下（条件付きで再申請可）

判定: 却下

理由: 恒久的例外としては認められない。Rustは組織内に実績がなく、採用・教育の追加コストが大きい。ただし、以下の条件で再申請を推奨:

• まずGoでプロトタイプを構築し、レイテンシ要件を満たせないことを実データで証明する
• Rustが必要と判明した場合、実験的例外（6ヶ月）として再申請
• 並行してRustをテクノロジーレーダーのAssessに追加するRFCを提出