コラム

　汎用性・普遍性を優先した多くのECシステム（パッケージやSaaS）が、そうしたユニークなビジネスルールに対応した業務機能を予め用意することは困難です。これは単純に言葉通りの意味であり、つまり何かのフィーチャー（特性）について「汎用的で普遍性の高いもの」はすなわち「ユニークなもの」ではないし、その逆も然りであるという問題です。もし、日本で食べ物について考えるならば「漬物」「白いご飯」は汎用的であるがユニークではなく、「からすみ」「次郎系ラーメン」などはユニークな価値をもつものの普遍的ではないと言って差し支えないでしょう。どの店の定食もからすみを添えるべきだとか、ラーメン屋ならマシマシには必ず対応できるはずだという理屈は横暴です。

　もちろん、ユニークさは価値であり、悪いことではありません。かと言って、普遍性や没個性であることに価値がないということもありません。これらは価値の有無や善悪とは関係のない、確率的な問題に過ぎません。ただし、ユニークさは多くの場合、コストを伴うということはおそらく真実で、悩ましい問題です。

　ECに話を戻せば、ある程度の成長段階に達した事業者は多くの場合、ユニークさを必要としています。コストを払ってでも、競合他社よりも優れたサイト、高効率のバックオフィス、自動処理、より精度の高い分析・・・そうしたものを獲得する必要性に駆られています。なぜ、ユニークでなければならないのか。それは単純に、競争で前に出るためには周囲と同じではならないからです。マラソン大会で他人よりも軽く疲れにくいシューズを履いて走ることは、ズルでも違反でもなく、投資であり戦略です。競争は常にそうであり、ECシステムの構築運用もその例外ではないでしょう。そう、様々なシステムの中でも、ECシステムに特異な重要な性質のひとつは、「常に競争に使われている」ということに他なりません。

　そして、その競争で優位に立つためのユニークさを、コストさえ払えば実現してくれるであろうアプローチが個別カスタマイズです。

　しかし、だからといって安易に個別カスタマイズを選択するべきかどうかは、慎重に検討する必要があります。

　なぜならば、システムのオーダーメイドである個別カスタマイズには、「望んだ機能仕様を実現できる」という強力なメリットがある一方で、そうした場合の常として、対称となるデメリットも存在しているからです。

　そのデメリットは、すでに言及している通り、コストです。コストとは、その時にすぐに支払う費用のみを指すのではなく、何かしらのストレスや不便も含めた不利益全般を含みます。ですが、企業の経済活動においては、どのような種類のコストも結局は経済的コストに集約されていくでしょうから、つまり「お金がかかる」と考えて差し支えないと思われます。

　以下に、そのコストについて、明示的なものと暗示的なものについて考えてみることにします。

　なお、ここで言う個別カスタマイズは、その極端な例として全体をカスタムで開発するという意味でフルスクラッチでのシステム開発も含めています。

明示的コスト

暗黙的コスト

　ECシステムの要件には冒頭のような多様性もある一方で、例えばカートのメタファや個人情報の保護や決済など、かなり多くの共通点もあり、またそれらは重要かつ十分な品質を求められるものでもあります。

　他の業務アプリケーションにも言えることかも知れませんが、ECの主題である売買取引はきわめて社会的な基本ルールに沿って実行される業務ですので、ユーザーが異なってもロジックの類似点は多くあります。ECではとりわけ、顧客の個人情報や決済情報というセンシティブなデータを常に扱う一方で、システムをインターネット上に公開し不特定多数の利用者の接続を許さなければならないという”二重苦”を背負っているため、品質の保証がない状態で安易にスクラッチ開発をすることには大きなリスクが伴います。

　そのため、ある程度の複雑な要件に対応するためにはECパッケージを個別カスタマイズするという手法が長らく定番でした。実際のところ、この方法はある程度上手くいっていました。いまも、上手くいくケースもあるでしょう。

　しかし、EC市場はグローバルでも国内でも近年大きな伸長を見せており、また生成AIのような目立つ部分に限らず近年の技術の発展はますます多様になり、進化の速度を上げています。多様化と適応放散ばかりが進んでいるわけではありません。EC、CRM、ERP、BI、MA、WMS、POS、RPA、etc.・・・そういったECに隣接する業務アプリケーションの領域を意味する言葉は知らぬ間に増え続けているように思えますが、そもそもモノを売り買いしてその情報を管理するという業務において、本質的に必要であった情報の領域が爆発的に増えているとは思えません。ビッグデータという言葉も少し前に流行りましたがこれは領域ではなく量が増えたということです。そして、オムニチャネルというものも、情報の関連が増えてあるシステムからの見かけの量が増えたという見方もできるしょう。オムニチャネル以前にも、顧客自身はオンラインショッピングもすれば店舗を利用することもありました。どこかのデータベースに記録されていなかったとしても、そうした人の行動の情報はこの世界自体には存在していました。ここで言っている情報はデジタル情報のことではありません。人が生きて行動したということ自体の情報です。格好よく言えば、エントロピー増大への抵抗でしょうか。その情報量が、2000年代と2020年代で大きく異なるとは思えないということです（デジタル化された情報に限れば、飛躍的に増えました）。

　ポテンシャルとしての本質的な情報が激的に増えたわけではないのに、関連付けの強化によりある点から見える範囲が広がり、それぞれの領域にあるシステムが扱う情報量が増えたということであれば、それは互いの重なりが増えたということであって、ある意味での収斂も起こっているのではないかと思えます。そして、収斂もまた進化です。周囲の環境で進化が起こったのであれば、それにいち早く自身も適応することは、生存戦略として重要でしょう。

　そうした、いわば概念的な社会の進化のダイナミズムの中にあって、先に述べた”ユニーク業務への固着”は、ビジネスを推し進める足枷となってしまうリスクが高いと言わざるを得ません。

　進め、変われ、という警句はビジネス界においては大昔からの定番ですが、今後もきっと定番であり続けるでしょう。ですので、”いつかのスタイル”を具象化したシステムの実装に捉われたままで日々の業務を受け入れ続けることは、まず良いアイデアではなさそうです。

　ここまでで論じた問題は、つまるところECプラットフォームなどの業務アプリケーションにおいて、ユーザーは特定のユニークな業務をシステム化する必要があるが、システムはそのコスト面の問題から、その特定の業務の様式を組織に固着させてしまうということです。そして、その背景には、ECにおける業務の多くを占めるユニークではない部分に対して、常に個別の投資を行うことはユーザーにとっては負担が大きく、競争力を損なうという制約が存在しています。

　多くのユーザー（EC事業者）はこの共有可能なロジックの新規開発コストを受け入れられないのでパッケージ製品を選択しますが、個別カスタマイズで大きな追加コストを投じたそのシステムのリプレイスを、短い期間で再び行うことは出来ません。

　そして、この制約と問題を結び付けているものは、そのユニークな部分と非ユニークな部分がソフトウェアの内部で実際に結びついているという事実です。

　過去の多くのECシステムベンダーは、そうした事実にもちろん気づいています。ですが、その処方箋となるモジュール化は高度な設計を要求するため十分なレベルで実現することは容易ではないということが問題の解消を妨げています。

　そしてシステム内部のモジュール化の不十分さに業を煮やした（？）人々（開発者）が実現した仕組みが、いわゆるサードパーティ製のプラグインやアプリといった、明確に外挿されるモジュールによる機能拡張を前提としたECプラットフォームです。これはひとつの解決策ですが、次の問題として、物理的にも設計思想的にも、あらゆる意味で本体から切り離されて自由となったモジュール群が、相互に協調することが困難であるという事態を招きます。高みを目指した結果として対話ができなくなってしまうという成り行きはバベルの塔の寓話を思い起こさせます（何かズレている気もしますが）。ともかく、モジュールの独立性をパブリックなレベルで確保すると、その疎結合ぶりはどうしても無視できないディスコミュニケーションを伴い（早い話が機能と機能が連携できない）、そのあたりがMSA(Micro Service Architecture)の評価が微妙になってしまった要因かと思われます。

　このように、問題を解決するための方法論はいくつも存在しているのに、不思議となかなか実際に問題を解くことが出来ません。ここでの問題とは、結局のところ、個別カスタマイズによる負債を背負いこまずにECとしての共通基盤を共有し、システムのライフタイムを通じて開発成果をシェアすることで高い投資対効果をもたらすことは出来ないものか？ということです。

　さて、そもそも、なぜ業務ロジックのユニーク要素と共通要素が結合してしまうのでしょうか。それは、ソフトウェアがアーキテクチャとしてモジュール化を欠いているからではありません。

　そもそものロジックの解像度が低いからです。モジュール化のやり方が不味いケースもあるかも知れませんが、致命的な問題はそこではなく、モジュール化をしようとする対象の選定が不味いのです。

　これは喩えれば、「特製玉子ご飯」と「謹製バター醤油ライス」を出すお店が、それらの完成品を前に、「どうしたらこの玉子ご飯のライスを、バター醤油ライスに利用することができるだろうか？」と思案しているようなものです。ライスを洗ってみるとかいろいろ手を尽くすことは出来ますが、いずれも結果はイマイチで、なおかつ手間がとてもかかります。

　解決方法はお察しの通り、「ライスは別にしておけばよい」という非常に簡単なものです。「特製玉子ご飯」と「謹製バター醤油ライス」というユニークな存在は、要素に分解することで、ライス（ごはん）、玉子、醤油、バターというとても汎用性の高い存在として捉えなおすことが可能になります。

　ですので、先のECプラットフォームの問題に対しても、回答自体はシンプルです。個々のEC事業者に固有に見えるユニークな業務を、ロジック、それに必要なモデル、そのプロパティや振舞いについて、ユニークさが消滅するまで分解しきれば、そこには普遍性が残り、再利用性は損なわれません。

　普遍性は汎用性をもたらします。普遍性を確保したロジックで構成されているのであれば、仮にそこに新たなロジックが加わるのだとしても、そのソフトウェアは異なるユーザーが共有可能な標準たり得るということです。つまり、個別カスタマイズが必要ありません。

　個別カスタマイズが不要で標準形を利用できるということは、共通部分に対する開発コストを、より多くのユーザーが共同で賄うことが出来るということです。つまり、先に申し上げた通りに「タダでプログラムを書く開発会社はない」のだとしても、いちユーザーあたりの負担は激減します。言わずもがなですが、皆さんが毎日お使いのiPhone（iOS）やWindows、Google製品などは、そこらのECプラットフォーム（我々のものを含む）よりもはるかに大きな開発コストをかけて開発されているはずですが、それを皆さんがECの初期ライセンスなどに比べればさほどの対価も払わずに利用できるのはそのためです。

　ただし先の通り、ECの業務というものは、OSなどに比べれば抽象度が低く、普遍化をするためには困難が伴います。ひとつひとつの業務をよく観察し、分解可能な要素は何か、それらはどう関係するのかを洞察しなければなりません。実際にこれを行うためには、要件定義のような場面でユーザーの声を聞くことはもちろん大切です。しかしそれだけでは足りません。ユーザーの周囲をとりまく環境、業界の知識・ルール・慣行はもちろん、法令、組織の構造に関する問題、物理的な制約、ステークホルダーの立場や感情、生理的な問題、社会情勢、あらゆる観点を踏まえて可能な限りの洞察を行うことが、設計の精度を高めることにつながります。

　もちろん、そのような洞察を完璧なレベルで行うということは、いちエンジニアにそうそう出来ることではありません。しかし、「お客さんが言うんだからしょうがない」「元請けが決めた仕様書だから」そういった事を言ってしまった瞬間に、もう答えには一歩も近づけなくなるということだけは間違いないと言えるでしょう。

　ここでひとつ、この節の冒頭で述べた「より多くのユーザーが共有可能」なシステムという点について、別の見方を補足しておきます。異なるユーザーが利用できるということは、他社の成果を利用できるとか、自社の成果を他社が利用できるといったことだけを意味しません。１年後のあなたは、現在のあなたから見れば、異なる知識と環境を持つ他者であるという事実に注目しましょう。つまり、自分と異なる価値観やルールを持つ他人にも価値がある道具は、将来に変化してしまった自分にも価値があるということです。短く言えば、本当の普遍性は変更にも強いということです。

　Lexicaは数々のユニークなECにも標準機能のみで対応してきた実績があります。

　E-リテイリングシステムズは、設立時点から、個別カスタマイズ不要で高度な要求に答えるECプラットフォームを開発するという目標を掲げ、チャレンジを続けています。そのため、請負開発はこれまでに行っていません。また、継続的な研鑽と、期間に制約されずに議論を徹底的に深めるために、プロダクトのコーディングを行う開発者は正社員のみとしています。長期の教育が必要であり、自身が関わるプロダクトへのコミットメントが必要だからです。

　我々は、顧客の要望ベースでの機能追加にあたっても、20年近いEC業界での経験に加えて、さまざまな知識、時には社員の過去の倉庫や物流サービスでの勤務経験までを援用し、求道者のごとくオブジェクトをモデリングします（つまり設計をします）。けっして、顧客の要望通りの機能は実装しません。それよりも良いものを、提示した見積もり工数以上の工数をかけて開発します。請負開発でこんなことをしていたら倒産してしまう気がしますが、標準化前提の開発成果は我々にとっても資産となるので、そうしたことも可能になります。

　その結果、E-リテイリングシステムズは、10年近くにわたる事例において難易度の高いECの構築を得意としながらも、直販案件についてはすべてノンカスタマイズでのローンチを達成しています。

　およそ10年前、設立直後の1号案件としてLexicaを導入いただいたお客様も、幾度ものアップデートを経て、現在も最新版を利用されていることは我々にとっても誇らしい実績です。導入初期に比べれば管理メニューも2倍近くになっています。それらの追加メニューのほとんどは製品として追加されたものですので、そのお客様からは開発費用もいただいていません。

　これが、我々が主張するところの「脱 カスタマイズ」の効用であり、Lexicaを導入いただくことの圧倒的なメリットです。繰り返すリプレイスのコストから解放され、常に最新の機能を利用可能で、新たなサービスや施策もスピーディに実現可能であり、サイトのデザインの全面リニューアルも好きなタイミングで行えます。

　さて、この1万字に迫る長文を読んでくださったあなたは、それなりの確率でECシステムを運用されている事業者でいらっしゃるかも知れません。

　ぜひ、次のECリプレイスでは、脱カスタマイズを検討してみてはいかがでしょうか。