更新日:
日々の業務で、お客様への提案や若手エンジニアへの説明をする機会が多くあります。 限られた時間の中では伝えきれないことや、「これも知っておいてほしいな」「前にも同じ話をしたな」と感じることを、ここに少しずつ書き留めていきます。
スクラッチ開発とパッケージシステム
よくあるお悩み
お客様からシステムに関するご相談をいただく際、いくつか“よくあるパターン”があります。
一つは、
ExcelやAccessで業務を回してきたものの、さすがに限界を感じ始めたケースです。そこでパッケージシステムを検討してみたものの、「全体としては良いが、どうしても一部の業務に合わない」という壁にぶつかります。
もう一つは、
すでにパッケージシステムを導入しているものの、
「そろそろ置き換えたい」「バージョンアップの時期が来た」というケースです。
ところが、バージョンアップに伴ってさらなるカスタマイズが必要になったり、
そもそも対応できないと言われてしまうこともあります。
なぜパッケージは変化し続けるのか
パッケージシステムが変化していく理由は、決して気まぐれではありません。
- 脆弱性への対応
- 法改正や業界動向に合わせた機能追加
- ベンダー自身のビジネス環境の変化や競合への対応
こうした事情から、パッケージは「止まることなく進化する」宿命を持っています。
なぜパッケージのカスタマイズは高いのか
パッケージシステムは、
「そのまま使うこと」を前提に、全体の整合性が丁寧に設計されています。
そこに想定外の処理や独自要件を割り込ませる場合、
全体への影響を考慮しながら調整する必要があります。
結果として、そのコストはどうしても高くなりがちです。
建築にたとえると
パッケージシステムは、いわばプレハブ住宅です。
そのまま使うことを前提に作られているため、
大きな改造や間取り変更は得意ではありません。
一方で、条件に合えば安価で、品質も安定しています。
対してスクラッチ開発は、大工による注文住宅のようなものです。
いびつな土地にも建てられますし、内装や動線に強いこだわりを持たせることもできます。
ただし、費用は高くなりがちで、品質も作り手次第です。
そのあいだをどう埋めるか
理想を言えば、
「パッケージの安定性」と「スクラッチの柔軟性」
その“いいとこ取り”ができるのが一番です。
ヨドック式開発は、まさにその間を埋めるためのアプローチです。
