システムを導入する場合、以下の3点から選択することになります。

• パッケージをそのまま使用
• パッケージをカスタマイズして使用
• オリジナルシステムを開発して使用
  このオリジナルシステムはフルスクラッチ（後述）を指します

特に、パッケージのカスタマイズとフルスクラッチについて辛口な意見を聞く機会が多いような気がします。

どちらも多くの企業で採用されている開発手法です。

base on https://www.nttpc.co.jp/yougo/フルスクラッチ開発.html

カスタマイズ
企業向けの情報システムも、多くは基本的な機能や構成が決まっていて、各企業の使い方に合わせてメニュー項目を変えたり、不要な機能を削ったり、逆に機能を追加したりして使用されている。つまり、カスタマイズと呼ばれる作業を行って導入しているケースが多い。

フルスクラッチ
情報システムやソフトウェアを作るとき、既存のプログラムを一切使わないで、全体の構成から細部に至るまで新たに作り上げて行くのがスクラッチ開発あるいはフルスクラッチ開発と呼ばれる方式だ。
スクラッチ開発の場合、本当にその会社の業務に合った情報システムやプログラムを作れる可能性が高い。その反面、開発に手間と時間がかかり、当然それはコスト要因になる可能性が高い。

パッケージのカスタマイズもフルスクラッチ開発も、膨大なコスト（時間とお金と労力）を支払ってシステムを導入することには変わりありません。

そのため、インターネットの記事を見ると「パッケージのカスタマイズやフルスクラッチ開発はＮＧ」で、パッケージをそのまま利用すべきだという主張も見られます。
※ここでいうＮＧはＮｏＧｏｏｄ（ダメという意味ではなく建設的でない）という意味で使われていると私は理解しています

その主張は正しいと思います。
ただ誤解も生みやすいと感じています。

私はお客様の立場でシステム提案をできるように日々精進しています。
顧客という意味では、経営者の方がお客様に当たるのですが、システム導入・運用がスムーズに進むようシステム担当者・エンドユーザ双方の立場からも意見を言えるように心がけています。

会社を運営している全ての人のことを考えると「フルスクラッチは決して悪いものではない、ただ"複雑なだけ"だ」と言いたいのです。
要は適材適所です。

それぞれにおいての使いどころを誤らなければ最大の効果が得られます。

それぞれの特徴

パッケージをそのまま使用

文字通り、ソフトウェアハウスから販売されているパッケージをそのまま利用します。

以下の3点が当てはまるでしょう。

• 一般的な業務
• 差別化を図る必要のない業務
• 安価、且つスピーディに導入したい

代表的な例としては、給与計算や会計処理などが上げられます。
処理自体が一般的ですし、差別化する理由が見当たりません。
また、販売数が多いソフトウェアであれば、操作に長けた人材を見つけやすいというメリットもあります。
それを逆手に取って「社内でブラックボックス化した業務を一般化したい」といった要望にもマッチします。

パッケージソフトは広く一般に販売されていますので、オリジナルシステムに比べ安定性が高いことも特徴です。
※あくまでソフトウェア単体の安定性です（Windows上でフリーズする・・・ということはありますので）。
また、複数顧客に販売している（所有権はソフトウェアハウスにある）ため、価格もリーズナブルになる傾向があります。

パッケージをカスタマイズして使用

パッケージをカスタマイズして使用する、というと聞こえは良いですがLubtechではオススメしておりません。
良心的なエンジニアなら、きっとあなたを説得しようとしてくれるはずです。

なぜならば、既成品をカスタマイズすることのデメリットが大きいからです。

カスタマイズのデメリット

カスタマイズすることにより生じるデメリットは、以下の3点です。

• コストがかかる
  パッケージにはそれ自体に外部との連携機能がありファイルの受け渡しなどができるものもありますが、その範疇を超えると融通がききません。
  なぜなら、パッケージはそのまま利用した場合に効果が最大になるよう製品化されているからです。
  当初想定されていた利用方法を超えたカスタマイズは多くの時間と対価が必要になります。
  （画面に表示されている部分の変更だけですまないケースが多いのが現状です）。

• 長期利用に適さない
  業務利用であればそれなりの期間利用することになると思います。
  システムに不満がないのであれば、変更しないほうがユーザの習熟度も上がり生産性が向上するからです。

  • アップデート（パッチ）を適用しづらい
    税制など法改正への対応や（パッケージは広く販売されている性質上）機能追加や改善などのアップデートが配布されます。
    カスタマイズを行っていると、そのアップデートを直接適用することができなくなるケースがほとんどです。
    アップデートしたことで機能に不具合が生じないように、少なくとも事前の検証作業が必要になります。
    検証後に不具合が見つかれば改修しなければなりませんので、追加コストが発生します。
• 緊急対応が難しくなる
  システムの不具合が発覚した際やセキュリティパッチを適用したい時など、早急に対応したい場合に（カスタマイズが）壁になります。
  日々使う業務システムが何らかの理由で使えなくなった場合、プレーンな状態で利用していればメーカーの迅速な対応が期待できますが、カスタマイズを行っているとそうはいきません。
  販売元のソフトウェアハウスはカスタマイズ部分に関与していないからです。
  仮に、販売元にカスタマイズを依頼していた場合でもカスタマイズ部分は一意なプログラムとなるため、対応に時間がかかるのが一般的です。

メリット

メリットももちろんあります。

• 業務フローに合わせられる
  今の作業手順を極力変更しないでシステム化が可能なため、以下の特徴があります。
  • システム化による一時的な生産性の低下が防げる
  • 従業員の心理的ストレスが少ない
• 戦略的な意図がある
  競合他社との差別化を図るために一般的なシステムではなく、自社の要求に特化したシステムが必要な場合は十分価値があります。
  但し、内向き（社内的）な利用の場合はカスタマイズによる差別化ではなく、パッケージやクラウドなどから自社にフィットしたものを選択することをオススメします。

• 特殊な業務でフローにあったパッケージが存在しない
  この場合は、見極めが必要になります。
  カスタマイズのデメリットを踏まえつつ、後述するフルスクラッチも視野に入れて勘案すべきです。

オリジナルシステムを開発して使用

上記、フルスクラッチ開発が的を得ているので多く記載することはないのですが、メリットとデメリットが相反します。

• 会社の業務フローに則ったシステムが作れる
  一から制作するので希望に沿ったシステムが作れる反面、完成までの日数が多くなる傾向があります。
  結果として、コスト高になりやすいので予算感が重要になります。

• 業務の生産性を追求しやすい
  パッケージのカスタマイズのように枠にとらわれる必要がないため、柔軟なシステム設計が可能です。
  既存システムとの連携や業務の変化に応じたシステム変更も比較的安価に対応できます。
  その代償として、ベンダーロックインになりやすいという点に注意が必要です。
  システムの費用感を社内で試算できない場合、高額な請求をされる恐れが出てきます。

• 小さく初めて大きく育てることが可能
  必要な業務のみをシンプルにシステム化することで分かりやすく使いやすい仕組みづくりができます。
  しかし、そのためには入念な社内調整が必要です。
  部署ごと、あるいは人ごとに自動化したい業務は違うものです。
  時間も予算も有限ですから、経営者様・システム担当者様のお力添えが必要不可欠です。