こんにちは！PAYチームの しいたけ です。
先日、同チームの竹井から 決済領域に特化した「PAYチーム」が誕生しました！ という記事が公開されました。
まだ読まれていない方は、ぜひこちらからご覧ください👇
決済領域に特化した「PAYチーム」が誕生しました！
前回の記事では、PAYチーム発足の経緯や、「注文（配送）」と「決済」が密結合してしまっているという、技術的負債（レガシーコード）について赤裸々に語られていました。
今回は、そんな複雑な決済ドメインに対して、私たちがどうやって立ち向かい、イチから基盤を見直しているのか。現在進行形で進めている設計の裏側をお話ししたいと思います。
キーワードは 「RDRA（ラドラ）」 です！
なぜ「いきなりコード」ではなく「RDRA」なのか？
PAYチームのミッションは、「支援先の医療機関クリニックフォアにとって、また患者さんにとってインパクトのある決済関連施策を、品質高くスピード感持って実行できる状態にすること」です。
しかし、既存のシステムは歴史的経緯により複雑化しており、コードを追うだけでは本来あるべき業務の姿が見えにくくなっていました。特に「診察料だけの決済なのに、システム上は『配送物ありの注文』として扱わないといけない」という制約は、コードを追うだけでは全体像が見えにくい状態でした。
「なんとなくこう直せばいいんじゃない？」で着手して、後から「あ、ここも依存してた！」となるのは避けたい……。
業務が正確に捉えられていなければ、その後のモデル化やシステム設計も誤ったものになってしまう。
そこで私たちは、理想の決済基盤を描くために、まずは現在の業務の姿を正しく捉え直すことから始めました。そのための可視化手法として採用したのが、RDRA2.0です。
そもそもRDRA2.0とは？
RDRA (Relationship Driven Requirements Analysis) は、神崎善司さんが考案された要件定義手法です。
要件をテキストの羅列ではなく、ダイアグラム（図）を用いたモデルベースで整理するのが特徴です。
RDRAでは、システムを以下の4つのレイヤーで整理し、要件を明確化していきます。
出典: RDRA(https://www.rdra.jp/) より引用
- システム価値: 「誰に」「どんな価値」を提供するのか？ アクターや外部システムを洗い出します。
- システム外部環境: その価値を出すための「業務フロー」や「利用シーン」はどうなっているか？
- システム境界: ユーザーや外部システムとの接点（画面・APIイベント）はどこか？
- システム: その裏側で、どのような情報（データ）と状態を管理すべきか？
私たちは FigJam を活用し、ステークホルダーを巻き込んで「実際の業務はどう流れているのか？」を議論しながら、これらの図を作成しています。
RDRAダイアグラムから得られた示唆
実際にRDRAを用いて、現在の業務フローを可視化しつつ情報モデルを作成していく過程で、多くの「気づき」が得られました。
特に、情報モデル（システムが扱う概念） の整理において、既存システムが抱えていた課題の正体が浮き彫りになりました。
1. 概念の分離：注文と請求、予約と診察
前回の記事でも触れられていた 「注文（配送）」と「決済」の密結合 問題。
RDRAで「何が管理されるべき情報なのか」を整理した結果、明確にモデルを分ける必要があると定義できました。
-
注文と請求を分ける
- これまでは「注文」の中に決済情報も含まれていましたが、「請求（Billing）」という概念を切り出しました。これにより、「処方薬の配送（注文）」が発生しない診療のみのケースでも、不自然なデータを作ることなく決済が可能になります。
-
注文と配送情報を分ける
- 「配送先」は注文に付随する情報ですが、すべての注文に配送が必要なわけではありません。ここも概念を分離しました。
-
予約と診察を分ける
- 「予約データ」があれば「診察」が行われたわけではありません（例えば、キャンセルなど）。これらを別のライフサイクルを持つモデルとして再定義しました。
2. 未管理情報の発見：返金記録
モデリングを進める中で、「あれ、返金した時ってシステム上のデータはどうなるんだっけ？」という疑問が湧きました。
返金に関する情報は これまでログや外部決済代行会社側のステータス、スプレッドシート等によって管理されており、システムとして一元的に扱われていなかった ことが分かりました。
3. 既存設計への違和感の言語化
決済関連のUC複合図
決済関連の情報モデル全体像
図として可視化することで、既存データベース設計に対する違和感をチームで共有できました。
特に、実際の業務フローを図式化し、そこで出てきた言葉を分類していく過程で、既存実装では「予約」が情報を持ちすぎていたり、「注文」が本来の意味から外れた情報を抱えていることに気づきました。
例えば、注文なのに診察料を持っているなど、言葉としての概念とデータとしての構造がアンマッチになっているケースが見えてきました。
このように「コードがこうなっているから」というバイアスをいったん脇に置き、業務として“あるべき姿”を基準に概念を再整理できたことは、RDRAを使った大きな成果でした。
今後の展望
現在はまだ「たたき台」を作成している段階ですが、RDRAを導入したことで、私たちは「いきなり実装詳細に入る」のではなく、「自分たちが扱うべきドメイン（業務領域）は何なのか」 という共通認識を作ることができました。
特に、長年の課題であった「注文と決済のねじれ」に対して、論理的な裏付けを持って「概念を分ける」という意思決定ができたのは、このプロセスがあったからこそです。
PAYチームでは、このように「とりあえず動くものを作る」のではなく、「複雑なドメインを紐解き、あるべき姿をモデリングして、堅牢なシステムを築く」 というプロセスをとても大切にしています。
- RDRAに興味がある！
- 「注文」と「決済」を切り離すような、難易度の高いリアーキテクチャに燃える！
- ホワイトボード（FigJam）で議論しながら設計するのが好き！
そんな方は、ぜひPAYチームで一緒に働きませんか？
カルボナーラを食べながら（？）熱く語り合いましょう！
Discussion