スクラッチ開発は悪？

情報システムを導入する際に、比較検討されるパターンとして、スクラッチ開発とパッケージ導入があると思います。スクラッチ開発は利用ユーザの要望をヒアリングして０からシステムを構築する方法で、パッケージ導入は、既成のパッケージを利用する方法です。

実際は、パッケージ導入でも、パッケージ＋カスタマイズ(既存機能の修正)・アドオン(機能の追加)である程度の工数をかけて構築する場合もありますし、スクラッチ開発でも既存の開発フレームワークやコンポーネントなどを利用して工数削減する場合もあります。

気になるのが、欧米諸外国は情報システムを導入する場合はパッケージ導入が前提で、いまどき０からシステムを構築するなんて時代遅れ。日本企業は直ぐに０から作りたがるので・・・という論調です。（少々大げさになっています）

スクラッチ開発はいまどきＮＧなんでしょうか？あるいは、日本企業に当てはまるスタンダードな業務フローってあるんでしょうか。

確かに外資系企業のシステム構成図をみてみると、ERP,CRM,EAI,BIなど主要領域でメジャーなパッケージメーカの名前が並び雑誌の事例を見ているかのような場合が少なくありません。逆に日本企業の中堅、中小企業の場合、現在でも汎用機を使っている企業も多くありますし、特に基幹系業務となると、まだまだERPのようなパッケージを導入している企業は非常に少ないと感じます。

パッケージ導入のメリットは確かに多くあると思います。よく挙げられる点としては、

• 既存システム(パッケージ)の導入なので、導入期間が短くて済む
• 稼動しているシステムなのでバグが少ない
• 導入コストが安く済む
• プロジェクト失敗のリスク軽減となる可能性がある

と言った点でしょうか。他にも

• 導入企業の業務ノウハウのエッセンスが詰まっているので、スタンダードな業務フローを踏襲することができる。(BPRしましょう！)

と言ったことも挙げられます。

確かにパッケージにもメリットがあることは確かなのですが、本当に日本企業の業務は相当複雑なので、各社に十分Ｆｉｔするパッケージを探すことは至難の業ではないかと思います。

例えばよく挙げられる例としては決済のパターンがあります。

金種で言うと、手形(自振り、廻り）、小切手、振込み(現金)、様々ですし、入金も手形小切手の混合や一部入金、売掛、買掛の相殺など。請求にしても顧客側の条件を呑む場合が多いので、顧客ごとに請求入金のサイクルがバラバラだったりします。更には、相手企業の与信調査の結果、金種手形サイトなどを細かく規定する場合もあるでしょう。

そこそこのパッケージでは太刀打ちできません。では、この場合、この際だからBPRして、全部決済条件を合わせて、振込み、末〆翌末入金のみにして、・・・。現実からは程遠かったりします。

システムを導入する場合はユーザ要件が複雑なので面倒であるばかりか、開発の難易度も高くなりいいことは見えてこないのですが、ユーザ側の業務を深く知ると、それはそれでいい面も多くあり、日本企業の「よき」改善の結果である場合が少なくありません。

与信ごとに決済条件を変えて、不渡りリスクを抑えたり(与信が低い会社であってもそれなりに安全圏で取引する）できますし、入金・支払いのサイトを工夫することで資金繰りを大幅に改善できたりする場合があります。（確かに日本全体の商習慣決済方法がシンプルになることでのメリットもあるとは思いますが、短期的には非現実的です）

過去にパッケージ導入支援する際に、標準の入金登録のWEB画面を検討しました。１伝票＝入金の登録で６クリック必要であり、どうなれても10秒程度かかります。既存のシステムは汎用機ですが、テンキーを使い1,2秒で入金登録、売掛金消込、掛金と入金の差額処理(消費税の計上の違いや、振り込み手数料で差額が発生する場合の処理）までこなしていました。いやはやこんな場合もあるもんですね。（とてもスタンダードな業務に合わせましょうとは言えず、他の改善策で対応しました）

ユーザの業務を深く知れば知るほど、納得・感心することが多くパッケージの想定する業務のパターンを大きく超えています。

スクラッチかパッケージかという議論より、日本の企業力が細かい業務の改善の積み重ねの結果であるとすると、その多種多様な業務にＩＴ導入側はきちんと向かい合い、低コスト短期間で導入できる仕組みを提供する必要があると思います。あるいは、効率化のみではなく、ＩＴ導入により戦略的な企画案件の支援ができるようにしていく必要があると思います。正直、現状では、業務の改善の結果にシステムが追いつくのが精一杯であり、そのためどのパッケージでも合わずにスクラッチ開発をする結果となっている気がします。