意外とこういうのSaaSやソフトウェア製品の導入支援をしているときはお客さんに気を使って言えないんだけど今なら製品を扱ってないので言える。
ソフトウェア製品はIDEとかたたき台じゃないんだぞ！

10年ほどソフトウェア製品を提供する会社におりますので、そこでみたトラブル事例から、SaaSやパッケージソフトウェアなどのソフトウェア製品をうまく活用する場合の心構えを書いてみました。
既存のソフトウェア製品を採用するって、初期開発はコスト削減になるかもしれませんが、戦略的にやらないと長期的には高コスト高リスクになりますよね。

ソフトウェア製品利用上のよくあるトラブル

アップグレード工数の増大

SaaSやソフトウェア製品はどこかのタイミングでアップグレードをしないといけません。
不具合の修正やセキュリティ対応などのパッチが提供されなくなってしまったり、問い合わせしてもバージョンが古いと対応してもらえなかったり、あるいはSaaSであれば強制アップグレードが実施されてしまい、自前で作り込んだ機能が壊れて使い物にならなくなったりします。

アップグレードのスピードについていく時に問題になるのが自前の作り込み のボリュームです。
自前の作り込みは「コンフィグ」とか「カスタマイズ」とか言われます。
ボリュームが大きいほどアップグレード時のテストや確認事項が多くなるため、一回あたりのアップグレードの人的、金銭的コストが高くなります。

何がコンフィグの領域か、何がカスタマイズの領域かの定義は、採用するソフトウェア製品の提供元に確認してください。

ただしアップグレードコストの話はコンフィグだから安全とか、カスタマイズだからコストが高いというわけではなく、その総量が問題になります。

動作不良の問い合わせの回答に時間がかかる

日本のお客様は魔改造が好きなので、魔改造を施した結果、コンフィグやカスタマイズを積み重ねた結果海外のお客様が見つけたこともないような動作不良を発見してしまい、サポートの観点からすると再現条件の特定に時間がかかり、結果解決に時間がかかるということが時々起こります。

パフォーマンス！！！

アーキテクチャに合わない作り込みをするとパフォーマンストラブルにあうことも少なくありません。
例えば拡張を施した結果画面のJavaScriptの書き込みが多くなり、画面の処理が重くなる、あるいはアーキテクチャに見合わない属性追加を繰り返した結果データベースと画面がそろって重くなるなどがよく見受けられます。

いかなるアプリケーションに対する変更もリスクと心得ること

極端な話、いかなるアプリケーションに対する変更もリスクと心得ることです。
例えばSalesforceやServiceNowなどのaPaaSは必要なだけ属性を作りつけたり、テーブルから新しく作ったりすることができます。
ただし作った部分がきちんと動作するか、アップグレードをしても壊れていないかは自分自身で確認する必要が出てきます。

また属性を作れるということはどこまでも属性を作れるということを担保するものではありません。
aPaaSのように多くの属性を作っても快適に動くように作られたものもあるし、属性が作成されるとすると2-3しか想定されていないものもあるし、全く属性の作成が想定されていないものもあります。

属性を作るための機能が提供されているからと言って多くの属性を作りつけるとトラブルが起きることがあります。多ければ多いほどトラブルがあるものだと心得た方が良いと思います。
例えばaPaaSであっても、結果的に採用しているデータベース製品の限界に挑戦してしまったお客様を見たことがありますので、限界がないわけではないです。

トラブルを起こすリスクを最小化するためには、ソフトウェア製品が前提とする状況を推測し、その想定の範囲内で、最小限の機能追加や拡張で済むようにするのがベストです。

例えばとあるソフトウェア製品では、属性を追加できる機能はあるものの、追加した属性をAPI経由で取得するときJSONフォーマットが次のようになっていました。

{
   "code": "(属性のID)",
   "value": "(属性の値)"
}

データベーステーブルからSELECT分の結果をそのままJSONに加工してこのようなAPIのインターフェースになっていることが多いため、この設計ではおそらく追加属性テーブルがあり、そこに「code」というカラムと「value」というカラムがあると推測できます。

このタイプの設計を自分がすると仮定して、それはどんなときでしょうか。
あまり拡張性は必要ないものの、少数の追加属性は発生する可能性があるため、それを吸収するための最小限の設計として採用することが想像できます。

そうなるとあまり多くの属性を持たせてはパフォーマンス低下が想定されるので、追加属性はなくするか、どうしても必要な場合に限定して最大でも2-3にとどめるくらいの工夫をした方が良さそうです。

作り込みを最小限にするためには要件定義段階が大事！

作り込みを最小限にする、なんなら回避するには、要件定義段階で、ソフトウェア製品が想定するプロセスや想定に徹底的に自社の状況をマッピングし、合わない部分がある場合はコンフィグやカスタマイズをすることのビジネス上の重要性を徹底的に確認することが重要です。

どのくらい徹底的にかというと、「データを流し込むとか基本的なパラメータを設定する以外のコンフィグやカスタマイズが発生したら負け」くらいの心構えでいてちょうどです。
このくらいで徹底的に製品に合わせていってやっとシンプルなコンフィグやカスタマイズで済ますことができ、作り込みのリスクを最小化できます。

よく「OOTB (Out-of-the-Box) に合わせる」という言い方をしますが、これはそのくらい徹底的に追求した結果として最小限のコンフィグやカスタマイズで済ませることを指します。

過去プロダクトの導入支援をしていた時によく「これはOOTBの範囲と言えるか」というご質問をいただきましたが、そう聞かれる時はすでにOOTBではないことがほとんどです。

このくらい確認した方がいい

とあるソフトウェア製品を導入してもらうときの窓口になったときのことです。
このソフトウェア製品はまだまだできたばかりで、未実装の機能がたくさんあった時期のことです。
その製品は承認ワークフロー機能がありました。

経費が発生する申請を上げてもらう時に、承認として部門長の承認を取得したいと思いました。
既存機能としてレポートラインの上司承認の機能はありましたが、部門の部門長承認はありませんでした。
実装チームに依頼したときに次のようなやりとりをしたことを覚えています。

• 直属の部下を持っている人であっても、部門のお財布の承認権限を持っていないことがある。例えば大きな部門ではそういうことが発生しがち。

• 他の例では会社内の扱いでは平社員であっても、アウトソースの協力会社と協業する担当者などは、平社員であってもレポートライン的には上司部下の関係性になる。

• したがって既存機能である直属の上司承認では、お財布に対する承認権限がない人が承認する状況になってしまう

• コンプライアンス的に認められない

正直にいうと煩わしいです！
でもこのような議論になるくらい真面目にリスクを削減しようとする姿勢を見て、このチームなら信頼できるなと思った記憶があります。

このくらいしつこく確認するくらいでちょうどだと思っていただくといいかと思います。