> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2022/w35-new-understanding-of-standardization.md).

# W35-標準化についての新しい理解

標準化について新しく理解したことがある。標準化はシステムの違いを取り除き、循環的複雑度を下げ、予測しやすくする仕事だ。

少し前、WeChatの決済経路切り替えという第三者決済の変更に対応した。MMPの場面で業務の調整と決済画面の互換対応を行い、フロントエンドにはMMP固有の実装が入った。直接の影響は保守の難しさだ。外からMMP上の決済画面の挙動を予測しにくくなり、事業側と自分たちに落とし穴を残した。関連する事例も1件起きた。

露呈したのは、標準化がまだ足りないことだ。決済サービスを3段階に分けると、呼び出し、支払い方法の選択と引き落とし、決済後処理になる。中央の選択と引き落としはTitansで行い、各端末で統一され、業務差分も少ない。内容は多くても予測しやすく、問題の確率も低い。今見ると、問題は両端の呼び出しと決済後処理にある。MMP、MRN、Flutterなどの技術スタックでも、ここは揃え、端末対応の複雑さを下げるべきだ。両端を押さえるよい方法が必要になる。

事業側が選ぶSDKは、JS SDKとNative SDKの2種類ある。以前、Native SDKは呼び出し経路を短くし、決済画面を開く体験を高めるものと理解していた。だが、それだけではない。中間層として、呼び出しと決済後の処理をネイティブにまとめ、すべての技術スタックへ標準の決済ブリッジを提供し、端末間の違いをよく吸収できる。中核サービスの循環的複雑度を下げ、誤りと事故を減らすのだ。これはJS SDKでは代替しにくい。