カスタマイズはどこまで許すべきか｜追加開発が保守費に変わる境目
パッケージのデモを見せると、決まって同じ感想が返ってきます。「これでほぼ大丈夫です。ただ、この承認画面だけ、今のやり方に合わせてもらえますか」。悪気はまったくありません。むしろ真剣に検討しているからこそ出てくる要望です。
発注する側とシステムを作る側の両方を見てきた立場から言うと、この一言こそが、見積もりを跳ね上げ、数年後の保守費まで決めてしまう分岐点です。カスタマイズを許すか断るかは、金額の大小ではなく、別の物差しで判断すべきものです。その物差しと、断ったときの伝え方を、順番にお話しします。
カスタマイズとは何か：まず1分だけ
ここでいうカスタマイズとは、パッケージソフトが標準で備えていない画面・帳票・処理を、追加開発で作り込むことを指します。用意された選択肢を選ぶだけの設定変更とは別物です。設定変更はバージョンアップの影響を受けにくい一方、追加開発はパッケージの内部構造に手を入れるため、更新のたびに動くかどうかを確かめ、動かなければ直す作業がついて回ります。ここが今回の話の出発点です。
本当のコストは見積書ではなく、毎年のバージョンアップに乗ってくる
カスタマイズの相談を受けるとき、多くの経営者が見ているのは追加開発費の見積もり金額です。100万円か300万円か。たしかにそこも大事です。でも私が現場で実際に痛みを感じるのを見てきたのは、その先です。
パッケージがバージョンアップするたびに、追加開発した部分が新しい仕様と噛み合うかを検証し、噛み合わなければ直します。この作業は一度きりでは終わらず、パッケージが動き続ける限り、毎年ついて回ります。
導入時の見積もりには、この毎年の検証・改修費用がほとんど乗っていません。システム投資はいくらまで出していいのかという問いを立てるとき、回収期間の計算に入れる費用は、導入時の一括額だけでは足りないということです。カスタマイズを1つ足すたびに、その先何年分もの保守の予定表に、目に見えない項目が1行増えると考えてください。
要望を3段階でふるいにかける
とはいえ、現場から出てくる要望のすべてを断ればいいわけではありません。私が要望を聞くときは、順番に3つの問いを当てます。どれか一つでも「いいえ」なら、その先の問いには進まず、標準機能か運用の工夫で対応する側に倒します。
①法令・取引先要件で不可避か
まず確かめるのは、その要望が自社の好みではなく、外部から課された制約かどうかです。適格請求書の記載項目、業界特有の伝票様式、取引先システムとの連携仕様。これらは「うちのやり方」ではなく「守らなければ取引が止まる」条件です。ここに該当する要望は、金額の議論より先に、カスタマイズか代替手段のどちらかで必ず対応します。断る対象にはなりません。
②競争力に直結するか
次に確かめるのは、その処理が自社の強みを支えているかどうかです。同業他社と同じやり方をしていたら差がつかない工程、価格や納期で選ばれている理由そのものに関わる処理は、標準機能に業務を合わせてしまうと、強みごと均されてしまいます。ここに該当するかどうかは、担当者の感覚ではなく、その処理をやめたら顧客が離れるかで判定してください。離れないなら、それは強みではなく慣れです。
③運用の工夫で吸収できないか
①にも②にも当てはまらない要望は、最後にこの問いを通します。承認の順番を変える、入力の担当を一人に決める、月末だけ手作業で集計するといった工夫がそれに当たります。画面や帳票を変えなくても、運用の手順を変えるだけで吸収できる要望は、実はこの段階に最も多く紛れ込みます。
この段階で吸収できるものをカスタマイズで作り込むのが、結果としていちばん高くつきます。①②のどちらにも当てはまらない以上、その処理は会社の強みでも取引の条件でもなく、単なる今までのやり方だからです。バージョンアップのたびに検証費を払い続けてまで守る理由は、突き詰めると見つかりません。
断るときは、「できません」で終わらせない
③に該当してカスタマイズを断ると決めたとき、そこで終わらせると現場の納得は得られません。私が必ず添えるのは、次の3つのどれかです。
- 運用手順の代替案を具体的に示す：「この画面は変えられませんが、この2ステップを踏めば同じ結果になります」まで、実際の操作手順に落として渡します。抽象的な「工夫してください」は代替案になりません。
- 標準機能の中でできる範囲を明示する：完全に同じ見た目・同じ操作にはならなくても、設定変更で近づけられる部分があれば先にそこまで詰めます。差分を小さくしてから、それでも残る差を運用で吸収してもらうほうが合意は早くなります。
- 将来の要望として記録に残す：今は運用で吸収しますが、同じ要望が他の部署からも複数上がってくるなら、次のバージョンアップや将来の追加開発として検討します。ここでRFP（提案依頼書）に書く要件と、口頭のまま消える要望との違いが出ます。記録に残った要望だけが、次の判断の材料になります。
断る理由を説明するときも、「予算がないので無理です」ではなく、上の3段階のどこで止まったかを伝えてください。「この要望は③、運用の工夫で吸収できる範囲に入っています」と言えれば、現場も次の一歩を自分で選べます。ERPは“高機能が正解”じゃないという話とも重なりますが、機能を足すこと自体が目的化すると、この判定はいつまでも進みません。
一段深く｜帳票の見た目を守ると、業務が変えられなくなる
システム導入の支援をしていると、カスタマイズ要望の多くが、実は同じ形で出てくることに気づきます。「今の帳票と、まったく同じ見た目にしてほしい」。承認印の位置、項目の並び、罫線の太さまで、今の紙と寸分違わず再現したいという要望です。
これは一見、ただの見た目の話に見えます。でも私が見ている構図は違います。帳票の見た目をそのまま守るために業務ロジックを作り込むと、その帳票が前提にしている業務の順番や承認の流れごと、システムの中に固定されます。あとで業務のやり方そのものを変えたくなったとき、動かせるのはシステムではなく、システムに縛られた帳票の見た目のほうになっています。これが最もよく見る失敗の形です。
デザイン思考の基本は、今あるものを前提にせず、目的から設計しなおすことです。帳票は業務の結果を映す道具であって、業務そのものではありません。守るべきは帳票の見た目ではなく、その帳票が支えている承認や確認の目的です。目的さえ揺らがなければ、見た目は標準機能に合わせても、業務は困りません。
よくある質問
Q. カスタマイズの費用は、初期費用の何割までが目安ですか。
A. 一律の割合で決められるものではありません。①法令・取引先要件で不可避なカスタマイズは、割合に関わらず必要な投資です。目安にすべきは金額の割合ではなく、③運用の工夫で吸収できる要望がどれだけ紛れ込んでいるかです。そこを削るだけで、初期費用だけでなく毎年の保守費も同時に軽くなります。
Q. すでにカスタマイズを入れてしまった部分は、どうすればいいですか。
A. まず、既存のカスタマイズを同じ3段階に当てはめ直してください。棚卸しをすると、当時は必要だと思っていたものの多くが③運用の工夫で吸収できる範囲に収まっていたと気づきます。次のバージョンアップのタイミングは、作り直すより先に、標準機能へ戻せないかを検討する好機です。
まとめ
カスタマイズを許すかどうかは、見積金額の大小では決められません。①法令・取引先要件で不可避か、②競争力に直結するか、③運用の工夫で吸収できないか。この順番で問い、③で止まった要望は、断る理由とセットで代替案を渡してください。まずは今、検討中の要望を1つ選んで、この3つの問いに当ててみるところから始めてみてください。
自社の要望がどの段階に当たるか一緒に整理したい方は、お問い合わせからご相談ください。
この記事を書いた人
小林悠真（こばやし・ゆうま）／LF&L株式会社 代表取締役。九州大学で音響設計・音楽マネジメントを学びデザイン思考を培った後、ヤマトシステム開発・バンテックで物流／生産管理、ラクスル等のITスタートアップで事業開発・SCM構築を経験。製造業・物流業のDXコンサルタントとして、現場の1歩から経営システムまでの全体最適を支援する。テューバ奏者・LFコンサート代表理事も兼務。