「なんでもできる」の先に、
設計限界がやってくる
〜1998年、私は税込価格を選んだ〜

要点先に、この回の要点

機能を一つずつ足すのは難しくないが、ポイント・クーポン・会員ランク・送料・税・返品などが掛け合わさると組み合わせが爆発し、「設計限界」に達します。設計とは全部に対応することではなく、何に対応し何にあえて対応しないかを決めること（＝設計思想）です。

• 各機能は簡単でも、金額条件・適用順・端数処理・返品再計算が掛け算で増え、「なんでもできる」は破綻を招く。
• 処理を分けても、どの金額を次へ渡すか（値引前／後、丸め前／後、処理順）という境界の問題が残る。
• 設計者の仕事は組み合わせをむやみに実装することではなく、必要な組み合わせだけが残るよう境界を引くこと。

何を優先するか

もちろん、税込価格で管理する方法にも弱点はあります。消費税率が変われば、商品価格そのものを変更しなければなりません。税抜価格で管理していれば、税率だけを変更し、税込価格を計算し直すこともできます。それでも私は、税込価格を選びました。将来の制度変更への柔軟性よりも、そのときの買い物かごを単純にすることを優先したのです。

これは、正しいか間違っているかという話ではありません。何を優先するかという話です。

当時のインターネット通販は、現在ほど複雑ではありませんでした。ポイント、クーポン、会員ランク、定期購入、軽減税率、複数の決済方法、一部キャンセル、部分返金——現在では当たり前になった多くの機能が、まだ存在していませんでした。税込価格を足して、送料を加える。それで、買い物かごは成立したのです。

30年で変わったもの

それから約30年。買い物かごの中には、多くの機能が入りました。商品価格、消費税、送料、ポイント、クーポン、会員ランク割引、定期購入割引、軽減税率、決済、返品、返金。問題は、機能が増えたことだけではありません。それぞれが、絡み合うようになったことです。

例えば、ポイントを付けるだけでも、決めることがあります。送料を対象にするのか。税込金額を基準にするのか、税抜金額か。クーポン適用前か、適用後か。ポイント利用前か、利用後か。同じ「1％ポイント」でも、何を基準にするかによって結果は変わります。

送料も同じです。「8,000円以上で送料無料」と書かれていても、税込なのか税抜なのか、クーポン適用前か後か、ポイント利用前か後かによって、送料が発生するかどうかが変わります。クーポンも、単純な引き算ではありません。消費税率10％の商品と8％の商品が混在する注文に1,000円引きのクーポンを使うとき、その1,000円を、どの商品からいくら引いたことにするのか。それによって税額が変わり、ポイントが変わり、送料判定が変わり、返品時の返金額まで変わります。

単純に数えてみる

ここで、設計の組み合わせを単純に数えてみます。対象を、クーポン・会員ランク割引・定期購入割引・送料判定・ポイント付与の五つとします。まず、それぞれを使うか使わないかがあり、使う場合には、どの順番で適用するかがあります。

「5,000円以上なら使える」「1万円以上では使えない」といった金額条件を各処理に三通り、一部キャンセル・一部返品・個別例外の可否、軽減税率へのクーポン配分、決済方法。ここまでを掛け合わせるだけで、五つの処理が約760万通りにふくれ上がります。

端数処理を加える

しかし、ここにはまだ端数処理を含めていません。消費税、クーポンの配分、会員ランク割引、ポイント付与、返品や返金の再計算——これらには、小数点以下をどう扱うかという問題があります。切り捨てるのか、四捨五入するのか、切り上げるのか。しかも方法だけではありません。商品ごとに処理するのか、税率ごとにまとめるのか、注文全体の最後に処理するのか。同じ切り捨てでも、どの単位で、どの時点で行うかによって最終金額は変わります。

もちろん、これは実際のシステム仕様を正確に数えたものではありません。成立しない組み合わせもあれば、異なる条件でも同じ結果になる場合もあります。反対に、対象商品・会員ランク・利用回数・有効期限・購入経路などを加えれば、組み合わせはさらに増えます。重要なのは、591億という数字そのものではありません。「なんでもできる」を目指したとき、組み合わせが足し算ではなく、掛け算で増えていくことです。

「なんでもできる」の正体

「ポイントを付けたい」「クーポンを使いたい」「送料無料にしたい」。一つ一つは、それほど難しい機能ではありません。しかし、「なんでもできる」を実現するとは、機能を増やすことだけではありません。

ここまで実現しようとすると、設計は急激に複雑になります。

一つの機能を変更すると、別の機能に影響が出る。なぜその金額になったのか、説明できなくなる。新しい機能を追加するたびに、既存機能を広く確認しなければならなくなる。担当者が変わると、誰も安心して触れなくなる。技術的には作れる。しかし、安全に変更できない。正しく説明できない。将来の変化に耐えられない。

これが、私の考える設計限界です。

処理を分けても、限界はある

では、ポイント、クーポン、送料、税、決済、返金を、それぞれ分ければ解決するのでしょうか。確かに、処理を分ければ、一つ一つは分かりやすくなります。しかし、分けた処理は、最後には再びつながなければなりません。

どの金額を次の処理へ渡すのか。値引き前か、値引き後か。端数処理の前か、後か。どの処理を先に行うのか。返品時には、どこまで元に戻すのか。一つにまとめれば、その中が複雑になる。細かく分ければ、今度は処理同士の関係が複雑になる。

処理を分けることにも、設計限界があります。

設計思想とは何か

1998年、私は税込価格を選びました。買い物かご全体を単純にしたかったからです。その代わり、将来の税率変更への柔軟性は捨てました。当時の私は、「設計思想」という言葉で考えてはいなかったと思います。しかし、振り返れば、そこでしていたのは、まさに設計上の選択でした。何を優先するのか。どこまで対応するのか。何を標準とし、何を例外とするのか。そして、何を捨てるのか。

対応する組み合わせ、対応しない組み合わせ

設計とは、すべての組み合わせに対応することではありません。何に対応し、何にあえて対応しないかを決めることです。

「なんでもできる」は、設計限界を生みます。何に対応し、何にあえて対応しないかを決めること——それが設計思想です。

設計者は、何を減らし、何を残すのか

組み合わせの数に圧倒されて終わり、ではありません。設計者の仕事は、増える組み合わせをむやみに実装することではなく、減らすものと残すものを決めることです。

設計とは、複雑な組み合わせをすべて実装することではなく、
必要な組み合わせだけが残るように境界を引くことです。

実は、ECシステムは、すべて設計思想を持っています。何を優先するのか。どこまでを標準機能とするのか。利用者に、どこまで自由を与えるのか。何を外部サービスに任せ、どこから先を個別対応とするのか。そして、何をあえてできないようにするのか。その考え方は、システムごとに違います。

ECシステムの機能や料金を比較する記事は数多くあります。しかし、何を優先したのか。何を捨てたのか。なぜ、その形になったのか。それを商売の視点から読み解く記事に、私はまだほとんど出会っていません。機能の比較ではなく、料金の比較でもなく、そのシステムが持っている考え方を見る——いままで、あまり語られることのなかった世界です。

姉妹連載 ・ ECシステム論 この「設計限界」を、実在のECモールで読み解く ― 楽天市場・Yahoo!ショッピング Series ・ 特別編 大人の算数・国語・論理的思考 ― 連載一覧へ

よくあるご質問（FAQ）