業務パッケージ導入のチェックリスト ―「カスタマイズしたい」と言われる前に確認する15項目

「このパッケージ、うちの業務に合わないんです。カスタマイズできますか？」

業務パッケージの導入プロジェクトで、この一言が出ない現場はまずありません。今のやり方には理由があり、変えると取引先や他部署に迷惑がかかる。そう言われると、プロジェクトマネージャーとしては断りにくいものです。

ただ、その場で「わかりました」と引き受けた一つひとつのカスタマイズが、数年後に「バージョンアップできない」「不具合の原因がどこにあるか誰もわからない」「保守費だけが増えていく」という形で返ってきます。

この記事では、業務パッケージを導入するときに確認しておきたいことを、15項目のチェックリストにまとめました。
結論を先に言えば、原則は「パッケージに業務を合わせる」で、カスタマイズは最後の手段です。ただし「カスタマイズは絶対にしない」と言いたいわけではありません。
カスタマイズを進める前に確認することを今回はご紹介します。

全体像：4つの局面と15のチェック項目

チェック項目は、導入プロジェクトの進行に合わせて4つの局面に分けています。

局面	確認すること	項目数
A. 選定前	自社の業務のうち「変えられないもの」を見極める	3
B. 適合確認（Fit&Gap）	パッケージと業務のずれを洗い出し、対処法を分類する	3
C. カスタマイズを決める前	代替策を検討し、カスタマイズの代償を確認する	6
D. 契約・運用	撤退条件と、導入後の要望の扱いを決める	3

Cが最も多いのは、旧来の導入プロジェクトで最もトラブルが起きやすい局面だからです。

なぜ「作る」より「買う」のか

ソフトウェア工学の古典『人月の神話』でフレデリック・ブルックスは、購入できるソフトウェアがあるなら構築すべきではない、という趣旨のことを述べています^[1]フレデリック・P・ブルックス Jr.『人月の神話【新装版】』滝沢徹・牧野祐子・富澤昇訳、丸善出版、2014年、168頁。。1975年の初版から半世紀近く経ちますが、この考え方はむしろ強まっています。

いまや会計、人事労務、顧客管理、プロジェクト管理と、ほぼすべての業務領域でクラウド型のパッケージ（SaaS）が第一候補になり、「まず作る」という発想自体が少数派です。

ここで押さえておきたいのは、パッケージの価値の中核は「提供元が保守してくれること」にあるという点です。機能が揃っていることも大事ですが、バグの修正、セキュリティ対応、法改正への追随を、自社の人手をかけずに受け取れる。これが自社開発との決定的な違いです。

そして独自カスタマイズは、この価値を自分で削る行為です。だからこそ、カスタマイズの判断には慎重さが要ります。

用語をそろえる：設定・カスタマイズ・アドオン・外付け

チェックリストに入る前に、ひとつ整理しておきます。現場で「カスタマイズ」と呼ばれているものは、実は4種類あります。どれを指しているかで、リスクがまったく違います。

呼び方	何をするか	バージョンアップへの影響
設定（パラメータ設定）	提供元が想定した範囲内で挙動を変える。項目の追加、承認ルートの変更など	基本的になし
アドオン／プラグイン	提供元が用意した拡張の仕組みに沿って機能を足す	仕組み次第。提供元の保証範囲を要確認
外付け（連携）プログラム	別のプログラムをAPIなどでつなぐ	公式APIなら小さい。画面操作の自動化や内部データベース直結なら大きい
カスタマイズ（改変）	パッケージ本体のプログラムに手を入れる	大きい。バージョンアップのたびに再検証、最悪は不可

「設定でできること」を「カスタマイズが必要」と誤解して諦めるケースもあれば、逆に「ちょっとした改変」のつもりが本体に手を入れていたというケースもあります。ベンダーとの会話の最初に、どの言葉が何を指すかをそろえるだけで、後半の議論がかなり楽になります。

A. 選定前に確認すること

□ 1. 「変えられない業務」と「慣習にすぎない業務」を分けたか

法令や会計基準で決まっていること、取引先との契約で決まっていることは、変えられません。一方で「昔からこの帳票の形だから」「前任者がこうしていたから」というものは、慣習です。

パッケージ選定の前に、現行業務を一度この2つに仕分けておくと、後で「合わない」と言われたときに、それが変えられないものなのか、慣習なのかをすぐ判断できます。私は、この仕分けができているかどうかで、導入プロジェクトの後半の苦労が半分は決まると考えています。

身近な例を挙げます。「社内で稟議を回したというチェックが、システムの管理画面の中に必要だ」という要望を受けたことがあります。話を聞くと、チェックが画面の中にある必要はなく、メールや別のシステムとの併用で済むものでした。こうした慣習は、当事者ほど気づきにくいものです。気づかないまま既存システムに追加費用を払って改修しようとし、いざ関係者に確認をとったら「別の対応でもよい」と言われる。この流れは、本当によくあります。

ただし、この確認には時間がかかります。マネージャーに聞いて終わることもあれば、いくつもの部署をたらい回しにされて、ようやく答えが出ることもある。その労力を考えると「改修を頼んだほうが早い」と思う気持ちは、私にもよくわかります。それでも仕分けを勧めるのは、逆のケースもあるからです。一見不要に見える機能が、実は法律で作成が義務づけられた書類を自動で出力するものだった、ということもあります。「慣習だろう」と決めつけるのも、「変えられない」と決めつけるのと同じくらい危ういです。

□ 2. 「なければ困る機能」と「あると便利な機能」を分けたか

要件を洗い出すと、現場からは「全部必要」と言われがちです。しかし、なければ業務が止まる機能と、あれば楽になる機能は、分けて考える必要があります。

この区別がないまま選定に入ると、「あると便利」の機能が足りないという理由で有力候補を落としたり、逆にそれを実現するためにカスタマイズを積み上げたりすることになります。

私の本業はWebサイトの制作なので、Webの例になりますが、「会社で気軽に更新できるシステムが必要」「どの部分でもCMSで修正できるようにしてほしい」という相談は、定番といっていいほど多いものです。
ところが掘り下げてみると、更新にいくらかかるかを把握していなかった、あるいは社内の連絡体制が整っていないので「なんでもできるCMS」が必要に思えていただけだった、ということがあります。
あるクライアントとは「更新は2週間前にご連絡ください」「PDFでの差し替えでも構いません」という取り決めをしただけで、高い費用を払ってCMSを入れる必要がなくなり、むしろ運用の工数は減りました。「なければ困る」と思っていた機能が、運用ルールひとつで「なくてもよい」に変わった例です。

□ 3. 候補を複数比較したか（1社の提案だけで決めていないか）

たまたま付き合いのあるベンダーの提案だけで決めてしまうと、「このパッケージでは実現できない」と言われたときに、他の選択肢を持っていません。比較対象があれば、「別の製品なら標準機能でできる」という判断材料になります。

B. 適合確認（Fit&Gap）で確認すること

□ 4. ギャップを一覧にし、対処法を4つに分類したか

パッケージと現行業務のずれ（ギャップ）は、必ず出ます。出ること自体は問題ではありません。問題は、ギャップが出るたびに個別に「じゃあカスタマイズで」と処理してしまうことです。

ギャップは一覧にして、ひとつずつ次の4つに分類します。

1. 設定で吸収する
2. 業務のほうを変える
3. 外付け（連携）で補う
4. カスタマイズする

この順に検討し、4に残ったものだけを次の局面Cに送ります。多くの場合、一覧にしてみると1と2で片付くものが大半です。

□ 5. 「設定」と「カスタマイズ」の境界をベンダーに確認したか

前の節で整理したとおり、同じ「対応できます」でも、設定なのか改変なのかで保守への影響は別物です。「それは設定の範囲ですか、プログラムを改変しますか」「バージョンアップ時に再検証が必要になりますか」と、具体的に聞いておきます。

ベンダーは意図的に隠しているわけではなく、聞かれなければ説明しないだけ、ということがほとんどです。

□ 6. 標準機能で「ほぼできる」なら、業務をパッケージに寄せる検討をしたか

「パッケージが業務に合わない」という言い方をすると、悪いのはパッケージのように聞こえます。しかし、業務パッケージには、多くの企業の業務を観察して作られた「標準的なやり方」が組み込まれています。標準機能で8割方できるなら、残り2割は業務のほうを変えられないか。この問いを一度は立てておきます。

海外のERP導入では、これを Fit to Standard（標準に合わせる）と呼び、Fit&Gapで見つけたギャップを埋めるのではなく、標準に業務を寄せることを前提に進める考え方が主流になっています。

C. カスタマイズを決める前に確認すること

局面Bで「カスタマイズが必要」と判定されたものについて、実際に発注する前に確認する項目です。ここが最も重要です。

□ 7. 他のパッケージなら標準機能で実現できないか、もう一度探したか

カスタマイズの話が出た時点で、選定に戻る。手戻りに見えますが、その機能に絞って再調査するだけなので、最初の選定ほどの手間はかかりません。カスタマイズの開発と、その後の保守に払う時間と比べれば、はるかに小さい投資です。

□ 8. バージョンアップへの影響を確認したか

パッケージは、バグ修正やセキュリティの脆弱性対応のために、定期的にバージョンアップされます。本体に手を入れていると、バージョンアップに失敗する、あるいは「アップデートしたら外付けプログラムが動かなくなるかもしれない」という理由で、アップデートを見送るようになります。

こうして、セキュリティリスクを抱えたまま古いバージョンを使い続ける状態が生まれます。この状態は、パッケージを導入した意味の大半を失っています。

確認すべきは次の3点です。カスタマイズ後もバージョンアップは保証されるのか。バージョンアップ時にカスタマイズ部分の再検証は誰が、いくらでやるのか。提供元がカスタマイズ部分を理由にサポートを制限することはないか。

□ 9. 不具合が起きたときの責任範囲を文書化したか

市販パッケージは、提供元が不具合を潰した状態で提供されます。一方、カスタマイズや外付けプログラムは、テストを経ても実運用で想定外の不具合が出やすい。これはどの開発会社に頼んでも同じで、利用者の数が桁違いに少ないのですから当然です。

そして、パッケージの提供元とカスタマイズの開発元が別会社だと、不具合が起きたときに「うちの製品の問題ではない」「パッケージ側の仕様変更が原因だ」と、責任の押し付け合いが起きます。どちらも自社の立場からは筋の通った主張をしているので、解決に時間がかかります。

発注前に、どの範囲は誰が対応するのかを文書にしておきます。口頭の「大丈夫です」は、トラブル時にはほとんど役に立ちません。

この責任の押し付け合いは、ローコード・ノーコードで自社でもカスタマイズできると謳う業務アプリで、とくに起こりやすいと感じています。自社でも手を入れられる。そこにベンダーの開発が乗る。すると、不具合が起きたときに、どちらの変更が原因なのかを切り分けられなくなります。そして往々にして、技術的な知識で勝るベンダー側のほうが現象を正確に把握しているため、「〇〇の理由で御社側に責任があります」と説明され、トラブル対応の費用や、トラブルシューティングのための高い月額保守費を払うことになる。裁判という手段もあるのでしょうが、不毛です。

私は、責任の線引きのためにも、「あなた方が完全だと言った状態で使っていたのに、不具合が起きた」と言える状態を保っておくことを勧めています。自社で手を入れられる仕組みであっても、あえて入れない。それが、いざというときに自社を守ります。

□ 10. カスタマイズ部分の保守費用を、複数年で見積もったか

カスタマイズは、作って終わりではありません。パッケージのバージョンアップのたびに検証が要り、不具合が出れば修正が要ります。外付けプログラムを別の業者に頼んだ場合は、パッケージの利用料に加えて、その業者への保守料が発生します。

初期の開発費だけを見て判断せず、5年程度の保守費を含めた総額で比較します。初期費用の安さに惹かれて別業者に頼んだ結果、保守費で逆転するケースは珍しくありません。

この構造が最もわかりやすく現れるのが、WordPressです。無料で使えるツールなので「安い」というイメージがありますが、そもそも構築には開発費がかかりますし、仕様が複雑になるほど、それを把握して保守できる人材が限られ、その人たちの時間を確保する分だけ保守費は上がります。
さらにWordPress本体は定期的にアップデートされるので、これまで作った独自機能をそのたびに適応させる開発費が要ります。一度のアップデートの影響を調査するだけで、会社として丸一日の作業になり、10万円近い金額が請求されることがあります。

「カスタマイズが増えるほど保守費がかさむ」という感覚は、専門家でないとなかなか持っていないものです。だからこそ、項目として明示しておく価値があります。

□ 11. パッケージの提供元（または認定パートナー）に頼めないか確認したか

どうしてもカスタマイズが必要なら、まず提供元か、提供元が認定しているパートナーに依頼できないかを確認します。理由は3つあります。

バージョンアップを妨げない作り方を知っている。責任の所在が一社に集約される。そして、パッケージの内部構造を理解しているので、保守性への悪影響を小さくできる。

第三者の開発会社でも対応できることは多いのですが、項目9の責任問題を考えると、提供元に頼めるなら、それが最も安全な選択です。

□ 12. 外付けにするなら、提供元が保証するインターフェースを使うか

外付け（連携）プログラムで補う場合も、つなぎ方で将来のリスクが変わります。提供元が公開している 公式API を使うなら、仕様変更は事前に告知され、互換性もある程度守られます。

一方、画面操作を自動化する方法や、内部のデータベースに直接つなぐ方法は、提供元の想定外です。画面が少し変わっただけで止まり、そのときに提供元は責任を負いません。

「保証されたインターフェース」は、APIのような大がかりなものである必要はありません。以前、会計ソフトの情報を配送関係の書類に流し込みたい、という相談を受けたことがあります。会計ソフト側にカスタマイズを頼むとかなりの費用になるとわかり、その方は一度あきらめていました。そこで提案したのは、会計ソフトが標準で出力するCSVを読み込んで、配送業務用のExcelに反映させる小さなツールです。パッケージ本体には一切触れず、提供元が正式に用意している出力だけを使う。それで用が足りました。

D. 契約・運用で確認すること

2020年に初稿を書いたとき、この局面は書いていませんでした。SaaSが前提になった今、導入時に確認しておかないと後で困る項目です。

□ 13. データのエクスポートと、乗り換えの手段を確認したか

パッケージは永遠に使うものではありません。事業の変化で合わなくなることも、提供元がサービスを終えることもあります。そのとき、自社のデータを標準的な形式で取り出せるか。契約前に確認しておきます。

カスタマイズを重ねたパッケージほど、乗り換えが難しくなります。項目8〜12が「カスタマイズの代償」だとすれば、これは「出口を塞がれる代償」です。

□ 14. 料金改定と、サポート終了（EOL）の条件を確認したか

サブスクリプション型では、料金改定はめずらしくありません。値上げの通知期間、ユーザー数やデータ量による課金の変わり方、そして製品やバージョンのサポート終了がどのように告知されるか。契約書か利用規約のどこに書いてあるかを、契約前に把握しておきます。

□ 15. 導入後の「カスタマイズ要望」を判断するルールを決めたか

導入が終わった後も、要望は出続けます。運用が始まってから「やっぱりこの機能が欲しい」と言われたとき、誰が、どんな基準で判断するのか。ここを決めていないと、担当者が個別に対応し、気づけば誰も全体を把握していないカスタマイズの山ができあがります。

判断ルールは、このチェックリストのA〜Cをそのまま使えます。「まず設定でできないか。次に業務を変えられないか。それでも必要なら項目7〜12を確認する」。この順番を、運用ルールとして残しておきます。

現場の「合わない」に、どう向き合うか

ここまで読むと、現場の要望を突っぱねる記事のように見えるかもしれません。そうではありません。

「合わない」と言ってくる人は、業務を真面目にやっている人です。だから、その要望を否定するのではなく、「その業務は、変えられないものですか、慣習ですか」 と一緒に確認する。パッケージに業務を合わせる作業は、これまで当たり前だと思っていた業務を見直す機会でもあります。「必須だと思っていたが、なくても回る」と気づく業務は、思っているより多いものです。

ベンダーの側にも、カスタマイズを勧める合理性があります。要望に応えたいという誠実さもあれば、開発売上になるという事情もある。一方的に悪者にする必要はありません。ただ、数年後に保守費を払い、バージョンアップに悩むのは自社です。だからこそ、判断の基準は自社が持っておく必要があります。

そのために、カスタマイズのデメリット（項目8〜10）を、決裁者と現場の双方に事前に共有しておくことをおすすめします。デメリットを知っていれば、「業務を変える」という選択肢が、現実的なものとして検討できるようになります。

最後に、Webの話をもうひとつだけ。私はWordPressのサイトを作るとき、「とにかくカスタマイズしない」「プラグインも可能な限り入れない」という提案をしています。それを受け入れてくださったサイトは、5年経っても元気に動いています。一方で世間のWordPressサイトを見ると、レイアウトが崩れていたり、エラーの文言をそのまま画面に吐き出していたりするものが少なくありません。派手さはありませんが、手を加えない形がいちばん壊れない。これは業務パッケージでも同じだと考えています。

チェックリストを手元に置く

最後に、15項目を一覧にしておきます。導入プロジェクトのキックオフ時に、そしてカスタマイズの話が出たときに、見返してみてください。

A. 選定前
□ 1. 「変えられない業務」と「慣習」を分けたか
□ 2. 「なければ困る」と「あると便利」を分けたか
□ 3. 候補を複数比較したか

B. 適合確認（Fit&Gap）
□ 4. ギャップを一覧にし、設定／業務変更／外付け／カスタマイズに分類したか
□ 5. 設定とカスタマイズの境界をベンダーに確認したか
□ 6. 標準機能に業務を寄せる検討をしたか

C. カスタマイズを決める前
□ 7. 他のパッケージで標準機能として実現できないか再調査したか
□ 8. バージョンアップへの影響を確認したか
□ 9. 不具合時の責任範囲を文書化したか
□ 10. 保守費用を複数年で見積もったか
□ 11. 提供元または認定パートナーに頼めないか確認したか
□ 12. 外付けは公式APIなど保証されたインターフェースを使うか

D. 契約・運用
□ 13. データのエクスポートと乗り換えの手段を確認したか
□ 14. 料金改定とサポート終了の条件を確認したか
□ 15. 導入後の要望を判断するルールを決めたか

全部にチェックがつかなくても構いません。チェックがつかない項目が、そのプロジェクトで先に手を打っておくべき場所です。

ベンダーの提案書やカスタマイズの見積りを、第三者の目で一度見てほしいというときは、SSAITSでもご相談を受けています。必要がなければ、そのようにお伝えします。