システムのカスタマイズが、悪者とされる理由を考える

経済産業省が、2018年9月に発表したレポート「DXレポート　～ITシステム 『2025年の崖』の克服とDXの本格的な展開～』（以下、「DXレポート」と略す）では、2025年の崖の原因として、経営、人材、技術それぞれの観点から、国内企業のDX化を妨げる要因を指摘している。
このうち、技術の観点から課題とされたのが、ブラックボックス化するレガシーシステムであり、ブラックボックス化の一因として、やり玉に挙げられたのが、カスタマイズである。
だが、DXレポートでは、なぜカスタマイズが良くないのか、その理由に関する言及は十分ではない。
カスタマイズは、システムの導入、もしくは運用の過程において、多くの企業で実施されている。
なぜ、一般的に、そして広く行われているシステムのカスタマイズは、やり玉に挙げられなければならなかったのであろうか？

システムをカスタマイズするメリット

カスタマイズとは、パッケージシステムやソフトウェアに、ユーザー独自の改修を加えることを指す。
システムのカスタマイズが、良くないこととしてやり玉に挙げられる理由を追求する前に、カスタマイズのメリットについて、考えておきたい。

パッケージシステムには、そのシステムの目的にあわせ、必要な機能が広く実装されている。
「必要な機能が広く実装されている」とは言うものの、すべてのユーザーのニーズを満たせるかと言えば、それはNoだ。
パッケージシステムに実装されている機能というのは、求められることが多い機能、すなわちユーザーニーズの最大公約数でしかないからである。

日本には、358.9万社（2016年集計）の企業が存在する。
そのすべての企業にマッチするパッケージシステムなど、どんな用途のシステムであろうとありえない。
企業の活動は、それぞれにユニークである。
中には、一般的に見れば例外的な業務処理であっても、ある企業にとっては、差別化や独自性の肝である場合もある。
また、前例のないビジネスを展開する場合には、パッケージシステムでは対応できないケースもある。

最大公約数からこぼれた機能や処理をシステムに実装するために、カスタマイズは必要なのだ。
カスタマイズは、最大公約数でしかないパッケージシステムの機能を、企業活動におけるユニークな部分にフィッティングするための方策なのである。

システムのカスタマイズに溺れたふたつの会社

これからご紹介するエピソードは、私が経験した、いずれも良くないカスタマイズの例である。
いずれも、実はフルスクラッチ（※ゼロからシステムを開発すること）における事例なのだが、本稿のテーマとして、参考になる点が多いので、ご紹介する。

A社は、健康食品を対象とした通販事業者である。
もともと、A社は、電話、FAXでの注文を主体とした旧来型の通販事業を行っており、時代の流れに従い、ECビジネスを展開し始めようと考えたのだ。

A社の通販事業は、既存のECシステムでは対応が難しかった。
特に難しかったのが、顧客のランク付けに伴う、複雑な価格設定であった。
A社では、過去の購入履歴に応じ、顧客をランク付けすることで、ステイタスを演出していた。そして、顧客のランクに応じ、商品を割引販売していたのだが、割引率は一律ではなく、商品単体、セット購入する商品の組み合わせなどによって、購入価格は複雑に設定、算出されていた。
そこで、フルスクラッチで、ECシステムを構築することになった。

実は、私は、システム構築には関わっていない。まだ、システム開発会社に入社していなかったのだ。私が、A社に関わるようになったのは、ECシステムが稼働し、半年ほど経過してからだ。

稼働し始めたECシステムは大問題を抱えていた。
前述した複雑な価格設定が、顧客の希望通りには稼働しなかったのだ。
当然、A社の担当者は、私どもに対する不信感を隠そうとしなかった。
私は、開発を担当したSE（システムエンジニア）たちに話を聞いた。SEが異口同音にもらした不満は、「私たちは、お客さんの言うとおりに開発した」という言葉であった。

原因のひとつは、A社側のあいまいな価格設定にあった。
「たなかさんは、商品Xと商品Yのセット購入が多いから、セット割引を追加してあげよう」
「さとうさんは、商品Zの購入が多いから、一度の購入数量に応じて割引をしよう」
といった、場当たり的な価格設定が、A社では横行していた。
結果、無数の無秩序な価格設定が存在していたのだ。

さらに問題だったのは、問題の無秩序な価格設定の全容を、A社では把握していなかったことだ。
そして、SEたちは、その事実に気が付かなかった。

運用し始めるにつれ、「たなかさん用の条件が反映されていない」「さとうさん用の条件が反映されていない」といった、ボロが出てきた。当然である。そもそも、要件定義から漏れているのだから。

A社もA社だが、このことに気が付かなかったSEたちも、相当マヌケだ。身内のことながら、恥ずかしいエピソードである。

別の会社におけるエピソードをご紹介しよう。

B社は、ベンチャー企業であった。
B社は、あるジャンルの商品販売を行う店舗に対し、Webサイトのテンプレートを設けることで、手間とコストを抑えて、Webサイトを構築できるプラットフォームビジネスを考えた。
ごくかんたんな、CMS（content management system / コンテンツ管理システム）のプラットフォーム開発を、私のいたシステム開発会社は請け負った。

だが、B社のビジネスは、なかなか軌道に乗らなかった。顧客が増えないのだ。
すでに完成したシステムに対し、やがてB社はひんぱんに機能追加のためのカスタマイズを要求するようになる。
「○○という機能があれば、契約してもいいと言うお客さんがいるんです」、B社の社長は、嬉しそうにカスタマイズの理由を、私に語った。

だが、やがて社長の顔は曇り始める。
依然として顧客獲得は低調であった。さらに、顧客の望むカスタマイズを施したのにも関わらず、契約してくれないケースも多々あった。
ある時、私は、社長に進言をした。
「お客さんが増えないのは、システムの問題ではなく、営業に問題があるからしゃないですか？
もうこれ以上、カスタマイズに投資するのはやめるべきです」

心配する私に、社長は、にこやかに答えた。
「いえ、私のお客様に対する理解が乏しいのが原因です。
良いモノを作れば、必ずお客様は振り向いてくれます。それまで、ご協力いただけないですか！」

だが、やがてB社はカスタマイズをできなくなった。B社はベンチャー企業である。潤沢な資金があるわけではなく、ついに資金ショートしてしまったのだ。

なぜ、カスタマイズを行うのか？

「カスタマイズは、最大公約数でしかないパッケージシステムの機能を、企業活動におけるユニークな部分にフィッティングするための方策なのである」と申し上げた。

だが、無制限、無計画にシステムをカスタマイズすることは、さまざまな弊害が生じる。
カスタマイズにはコストが掛かるし、そもそも延々とカスタマイズを続けては、いつまで経ってもシステムが本当の意味で完成せず、腰を据えた運用ができない。

カスタマイズを要求する顧客担当者は、しばしばこのような言葉を口にする。
「『この機能がないと困る』と、現場から言われておりまして」

だが、その「困る」は、本当にシリアスな悩みなのだろうか？
その困るを解消しないと、致命的なロスを引き起こすような、重大な痛みがそこにはあるのか？
新たなシステムを求め、業務改善、生産性向上などを目指すのは、そこに痛みがあるからである。痛みとは、すなわち今後の業務や営業、さらには経営にまで、悪影響をもたらす（もしくは、既に「もたらしている」）病巣である。
病気になってもいないのに、医者にかかる人はいないだろう。

例えば、「背中が、ちょっとかゆいんです…」というだけで皮膚科に行く人はいない。
だが、コトがカスタマイズになると、重大な痛みではなく、「背中がちょっとかゆい」レベルで、カスタマイズを要求してないだろうか？

ちなみに、前述のA社でも、要件定義時に同様の会話が繰り返されていたらしい。
だが、本当の痛みは、無秩序な価格設定を再現することで解消されるものではなく、無秩序な価格設定そのものにあった。

つまり、痛みの部位を間違えてしまっていたことになる。
カスタマイズで対応すべきではないことを、システムのカスタマイズで対応しようというケースもある。
B社のケースは、その分かりやすい例であろう。

別の例も挙げよう。

経費精算機能を備えたシステムにおいては、締切期限を過ぎても処理を追加できるようなカスタマイズを望まれるケースが多々あるのだと聞いたことがある。
だが例えば、交通費の精算期限を守らない人たちのために、わざわざコストをかけて、例外処理を追加するカスタマイズを施す必要があるのだろうか？

これは、システムのカスタマイズで対応すべき痛みなどではなく、上司が部下に対し、きちんと社内ルールを周知徹底する、マネジメントの課題だと思うのは、私だけだろうか。

カスタマイズは、ユーザーのわがままをシステムに取り込むための方便ではない。
これは、決して失念してはならないのだが・・・。
往々にして、失念、もしくはあえてシステムの目的を無視し、カスマイズが行われてしまうケースも多いのであろう。
 

カスタマイズと上手に向き合うために、必要なこと

DXレポートでは、カスタマイズを、CEOの承認事項とした事例が掲載されている。
「何を大げさな!?」、そう思う方もいると思う。
なぜこの会社は、カスタマイズをCEOの承認事項としたのであろうか？

「システム」（System）という言葉は、単にコンピュータープログラムを指す言葉ではない。本来、システムとは、仕組みのことである。
コンピューターで動作するシステムを導入/構築する背景には、そのシステムが担う社内業務（営業、経理、生産、品質、人事、財務等）の仕組み（業務プロセス）があるはずである。
システムとは、あくまで業務プロセスの一環を担うものである。
そして業務プロセスは、人の手や目によって行われる業務（人力業務）と、システムが一体となって遂行されるものである。
システムをカスタマイズすれば、人力業務にも影響を与える。そして、ひいては業務プロセス全体にも影響を与えかねない。

カスタマイズをCEOの承認事項とした会社は、カスタマイズによって、業務プロセスに影響が出ることを恐れているのであろう。
業務プロセスが、不適切なカスタマイズによって歪められてしまえば、最終的に経営に悪影響を及ぼす可能性すらあるからだ。

カスタマイズというのは、単なる手段であって、手段そのものには、良いも悪いもない。
だが、考えなしにカスタマイズを連発すれば、やがて弊害をもたらす。
逆に、より良い目的を実現するために、カスタマイズを用いれば、企業の発展に貢献するような、良い結果をきっともたらす。
要は、使いようなのだ。
システムをカスタマイズする本意を忘れることなく、上手にカスタマイズを利用して欲しい。