SaaS導入におけるカスタマイズ要求への対応

SaaS導入を行っていると、よくカスタマイズ要求を頂きます。これに対する対応方針についてシェアします。なお、ここでいう「カスタマイズ」とは、標準で用意されている設定項目で設定できる範囲を超えた、コーディングを伴う改修を行う行為を指します。

要点
・個別最適のビジネスプロセスの変更要求は「業界標準・デファクトスタンダード」に合わるという形でユーザ側に業務の整理・変革をして頂く
・個人の感覚や好みの要求は、削減工数などの具体的なメリットと根拠を示してもらうようにすることでスクリーニングする
・押し切られそうな場合はバックログに積んで判断を先延ばしにし、既成事実を作ってから再度議論する

基本的にカスタマイズは避けるべき

まず前提として、基本的にカスタマイズは避けるべきです。SaaSは標準的なビジネスプロセスに基づいた業務ができるように初めから作られており、導入初日から活用できるようになっています。これに対し、カスタマイズは単純に工数がかかる上にシステムを肥大化・複雑化させることで保守性を下げ、技術負債の原因となり、また場合によってはサポートを受けられなくなることもあります。このように、カスタマイズはSaaSの最大のメリットである早い、安い、うまいを享受できなくしてしまうため、避けるべきです。

とはいえ、ユーザは何が標準で対応できて何がカスタマイズが必要になるかわからないので、様々な要求をします。ユーザからカスタマイズが必要な要求を頂いたとき、どのように対応すればよいでしょう？

カスタマイズの前に - その要求は個別最適になっていないか？

カスタマイズの前にまず考えるべきことは、個別最適になっていないか？ということです。

最も多いパターンが、自社業務とシステムが想定する業務が一致していないからカスタマイズしたい、というものです。SaaSは業界の標準的なビジネスプロセスに基づいて作られているため、それが前提とする業務と自社業務が異なっているなら、むしろ自社業務の方が業界標準からずれていることも少なくありません。また、社内でも特定の部署に個別の業務に合わせたい、という場合もあります。こちらは業界標準から逸脱するだけでなく、他部署や全社への展開を行うことが困難になり、スケールメリットが出しづらくなります。

このように個別最適になっている場合は、カスタマイズを避け、ユーザ側に業務を整理・変革してもらうようにすべきです。

対応策: 製品ではなく業界標準・デファクトスタンダードに合わせて頂く
この際、結論としては「製品仕様に合わせてください」なんですが、そのまま伝えると、ユーザの要望よりもシステム（機械）を優先するのか、ということで、中々理解を得られません。そこで、「これが業界標準・デファクトスタンダードです」という説明をします。特に、ITILやISO～のような、一般的に認知されたフレームワークや規格に準拠していることをうたっている製品の場合は、それを伝えることで、あくまでシステムではなく、先人の知恵に従うんだ、という形にでき、より説得がしやすいです。

カスタマイズの前に - 個人の感覚や好みで言っていないか？

ユーザに純粋な要望を聞く場を設けると、個人の感覚や好みに基づいた要求を頂くことが多いです。特に多いのがUI、UXに関する、「レイアウトが見づらいから変えてほしい」「見落としそうだから目立つ色にしてほしい」といったものです。これらは仮にカスタマイズしたところで「元の方がよかった」と思うユーザが必ず存在し、答えが無いため、結果として修正工数に見合ったメリットがでないことが多いです。このような効果を客観的に説明できないカスタマイズは避けるべきです。

対応策: 削減工数などの具体的なメリットと根拠を示してもらうようにすることでスクリーニングする
このような要求への対応策は、そのカスタマイズによってどれだけのメリットがあるか、その根拠は何か、を明確にしてもらうことです。その上で、見積もった実装工数とメリットを比較し、その要求が本当に実装すべきかを判断します。これにより、感覚的な要求については明確なメリットや根拠を示すことが難しいため、要求を取り下げて頂いたり、要求の優先度を下げることに納得してもらいやすいです。

押し切られそうな場合の対応策 - バックログに積んで決断を先延ばしにする

個別最適であったり個人の感覚や好みであることが明らかだが、立場が強かったり、声が大きいがために、押し切られそうになる場合があります。このような場合は、ひとまずバックログに積み、実装する意思があることを伝え留飲を下げて頂き、判断を先延ばしにします。そして、バックログを優先度順に対応していき、再びその要求の実装を考える際に「これについて他の方からの問い合わせは特に来ていません…」「現在の仕様に慣れてしまっている人も多いので、今変更するとかえって混乱を生むかもしれません…」というような、既成事実を持って再度議論するのです。

始めに方針を決め淡々と実行する

上述した対応策は、場当たり的にやってもあまり効果を発揮しません。なぜなら、明確な基準を持たずに要求に対してOK、NGを出していると「あの要求はOKでこの要求がNGなのはなんで？」となってしまうからです。プロジェクトの初期段階で個別のカスタマイズ要求が出たときにどう対応するかを決めておき、それに従って淡々と進めていくことが重要です。その際のヒントになると幸いです。

以上です。