スクラッチ VS ERPのSAP, CRMのSalesForce
一般的には下の表のようになっているかと思います
| スクラッチ | ERP | |
| 導入までの期間 | 遅い | 早い |
| 導入までのコスト | 高い | 低い |
| オリジナリティ | 〇 | × |
| 属人化 | 高い | 低い |
| 運用コスト | 低い | 高い |
この比較も長年議論されてる話ですが、他の記事にはない視点から書きたいと思います。
ERPが入っている大企業でしか経験がない場合はいまだにスクラッチ？？
と思う方もいますし、スクラッチで開発している側からすればシステムのライセンスでそんなにお金払ってるの？？
って思う方多いかと思います。
導入までの期間
これはパッケージ、SaaSの圧倒的勝利かと思います。
スクラッチになれば、まず現状どのページをどう使っていて、どういった業務フローなのかをヒアリングしないといけないです。
ERPだと基本的には現場の意見関係なしにトップダウンでERPに業務を合わせないといけないって事なので、
業務フローの細かいヒアリングなどする必要もないです。
（スクラッチに比べればであって業務分析は必要ですが）
導入までのコスト
開発する期間がパッケージの方が圧倒的に短いので、大量にエンジニアを抱えるスクラッチに比べれば安いように思います。
しかし、ライセンス料が桁違いに高いので、本当にスクラッチの初期費用が高くなっているのかが疑問です。
特にSAP、SalesForceに関してはシェアがトップクラスなので、料金もかなり強気の料金です。
例えば、月3000件程度の売り上げ件数しかないのに年間4000万円払っている所もあるぐらいです。
年間4000万円って事はベトナムのエンジニアの単価が30万円なので、10人のエンジニアを雇っても 10人 x 30万円 x 12か月 = 3600万円でお釣りがくるくらいです。
SaleseForceのベンダー側ではなく、ユーザー側にもシステムに詳しい人を置かないといけないので、ライセンス料金だけでは済まなくなってきます。
なので、導入までのコストは若干ERP,SaaSが有利でもそこまでのアドバンテージはないのかもしれません。
システムに強い会社なのであればもともとエンジニアを多数抱えているはずなので、そこから何人かを割り当てて、エンジニアの人件費を抑えながら、プロジェクトを進めるといったＰＪの回し方もあります。
小松が回したプロジェクトもそういう風にした経験があります。
大きく分けて、業務ヒアリング期、絶賛開発期、テスト・リリース期
業務ヒアリング期にはプロジェクトマネージャーの稼働が高く
開発期はエンジニアの稼働が最も高くエンジニアの人件費も高い時です。
テスト・リリース期になるとエンジニアの稼働は収まってきます。
が、リリース後の突発的な対応などで準備しておく必要があります。
期間に分けましたがあくまで目安で開発期にも業務ヒアリングすることはありますし、簡易なテストすることもあります。
並行して進めればアジャイルにプロジェクトを進められるかと思います。
なので、スクラッチでもうまく回せば初期費用を抑えられるんじゃないかって思います。
業務のオリジナリティ
スクラッチでは現場の声を拾い上げて開発していけるので、現場優先の文化の日本ではスクラッチが多い
ERPではトップダウンで決めていくスタイルが本来のスタイルなので、どうしても、今まで慣れ親しんだツールやシステムから変わって
「これ使え！これがグローバルスタンダード」
って言われても文句を言いたくなる現場従業員が多いかと思います。
現場の声を聞いて、都度都度カスタマイズやアドオンを入れてしまえばせっかくパッケージを入れた魅力がなくなってしまいます。
なぜならば、カスタマイズをした分属人的になり、ベンダーではサポートがしづらくなるためです。
日本とグローバルソリューションは合わない！？
少し話はずれますが、日本の現場優先文化はひとえに現場で働く従業員が優秀すぎるのが逆に問題かと思います。
現場の従業員が優秀だとシステムに頼る所が従業員の知恵でやりくりできてしまうので、システム導入の効果が得られないという事になっています。
アメリカの倉庫システムの導入に携わった経験がありますが、応用もきかないし、隙があれば物を盗もうとする従業員すらいるくらいです。
昼ごはんに外に出て倉庫に帰ってこなくなった
→外出してのランチは上長に何時何分に帰ってくると予定を組ませる
仮病で休む人が多い
→診断表を持ってこい
→ネットからダウンロードした診断表で誤魔化す
→病気も欠勤扱い
方針や賞罰も含めた仕組みづくりをしっかりしないと、業務が回らなくなるので、システム導入の価値が上がるといった側面もあります。
上の例を日本に当てはまると優秀だけど、よく体調不良で休む従業員がいたとしてもシステムで変えられないので、病欠扱いでしか
取り扱いができなくなってしまいます。
逆にメリットとしてはシステムでドライに決まるため、誰かのせいという事で責められる人も少なくてすみそうです。
日本の現場の従業員は質がよすぎるので、こういった事をしなくても勝手に効率よく働いてくれるって事でシステム革新が遅れる原因にもなります。
属人化
スクラッチになると開発すればするほど、属人化がすすんでしまうとよく聞く話です。
代わりにSAPやSaleseForceはもしわからない事があればベンダーに聞けるって事で属人的にならないと思われています。
しかしながら、SAPやSalesForceでもせっかくある項目を間違って入力していたり、空白のままなどの運用になっている事もよくあります。
BIである分析しようとするとどっかの期間だけデータが上手く取れなくて調査していくと
「あの時、誰々さんが退職してドタバタしてた時だったからそれから運用が変わった」
「新任のリーダーになってから運用が変わった」
ってERPのあるあるの話ではないでしょうか？
具体例
日本ではERPをカスタマイズするケースがよくあります。
せっかくERP入れたのにカスタマイズしてしまうと、結局そのカスタマイズしたエンジニアに聞かないとわからないって事も多分に起きてる気がします。
ググるとパッケージ・SaaSの評価が高い理由
「スクラッチ SAP 比較」
「スクラッチ SalesForce 比較」
などで検索しても、絶対にSAP、SalesForceを導入した方がいいよって薦めるページばかりです。
なぜか？
それは明らかに導入する側の利益がSAP、SalesForceの方が高いからです。
証拠に導入する側・エンジニア視点で求人を検索しても
「PHP 求人」
「SAP 求人」
と検索して比べてみても明らかに給料に違いがあり、SAP求人の方がはるかに高額の給料です
なので、企業としてはできる限り儲かる生き物ですからナレッジやスキルの向上を目指せば
その利益が高いSAP、SalesForceを目指すわけです。
利益が高いのでSEOに引っかかるようなページをお金を費やして作ることも可能です。
結局は
「スクラッチ SAP 比較」
「スクラッチ SalesForce 比較」
で検索して１ページ目に表示される広告やSEOに強いページは真実とかけ離れた事になっています。
AWSの悲劇でも説明したようにデメリットしかないのにどうしてAWSがここまで流行るのかと同じ理由です。
儲かるからです。
資本主義なので、より利益率が高いソリューションが生き残っていくという仕組みになっています。
ただ、導入側が儲かるため大衆にそっちを促すように羊のように扇動させらていることを多くの人は気づいてないです。
事業側、つまり何を導入するか、スクラッチにするかを選定する企業に取ってはベンダーの利益が高い分高額でコストが無駄に高くなっている事を改めてじっくり考え直してもいいのではと思います。
無駄に払わされていることに多くの人が気づいてないです。
ローコード、ノーコードなどのうたい文句で。。😱
となればopen sourceのERP、CRMを使えばベンダーに払うお金がないのでいいのでは？
と思われますが、２０年も前からERPのオープンソースはありますが、実際に導入している企業を聞いたことはないです。
資本主義の原理でオープンソースも負けてしまうって構図になってしまいます。
Odooというオープンソースが最近聞くようにはなったけども、流行るかどうかは疑わしいかと思います。
エンジニア視点で考えると結局の所基幹システムはDBのスキーマを見れば業務フローとシステムの出来がわかります。
なので、今まで培ってきたベンダーのDBのスキーマのテンプレートさえあればスクラッチでもそこまで時間を費やすことなく開発を完了できるのではと思います。
スクラッチのデメリット
世間一般の比較に比べればスクラッチをおすすめする記事になってますが、初期導入に時間がかかる以外の隠れたデメリットもあります。
それは担当者のスキルに大きく左右されてしまう事にあります。
DBの設計がめちゃくちゃ、余計なサードパーティのツールを入れてこねくり回すなどしてリリースが大幅に遅れる事もありえます。
最悪の場合２年間１０億円でスクラッチで作りました。でも「まともに動きません！」という事もありえます。😱
そうすると、経営者からの目線では多少高いお金を払っても確実に動いて実績があるSAP,SalesForceを入れたくなります。
このエンジニアができる人なのか、できない人なのかは経営者からはわからないですし、エンジニアでも面接しただけでは難しいです。
実績から見ればわかるかもですが、その実績もチームに助けられたり、実は炎上してたというのもありえる話です。
そういった炎上させないように開発していくやり方もたくさんあります。
そのためシステムをめちゃくちゃに作らないように今までプログラミングやシステム設計の思想に関した記事をいくつかアップしました。
その通りにプロジェクトを進めれば確実にコストを抑えながら大規模な開発も可能になります。
あともう１点スクラッチをするべきでない時は単なるＥＣサイトを立ち上げたいだけなのであればBASE, Shopifyが安く、簡単に作れます。
トラフィックの量が膨大やオークション機能が欲しいなど特別な理由がない限りは一からフルスクラッチよりもSaaSの方がコスパはいいかと
SaaSでもSFCCとかになると月に３００件もない受注しかないのに月３０００万円支払ってる会社もあるぐらいなので、ベンダー選びはしっかり見極めないといけないかと思います。
オープンソースのECcubeというのがあり、ひと昔前はよく聞いたのですが、BaseやShopifyに取って代わられました。
これもSAP,SalesForceと同じで儲かるソリューションなので、その儲かる方法にエンジニア、マーケティングが群がりオープンソースがすたびれてしまいました。
キャリアとして
エンジニア、コンサルタントとしてのキャリアでもSAP,SalesForceは魅力で月単価もだいぶ高くなります。
市場を独占しているので、このスキルを身につけておくと汎用性があり、つぶしがきく状態になるかと思います。
とはいえそれでもＤＢのＳＱＬやスキーマ、テーブル構成を身につけた方がはるかにそれ以上に汎用性があるスキルです
なので、超長期的には１ベンダーの使い方のスキルをつけるより、もっとシステムの根源的な部分を身につけてた方が得かと
とはいえ、CRMのSaleseForceからスクラッチに切り替えるならまだしもERPのSAPからスクラッチに切り替える決断する経営者はほぼ皆無かと思います。
元来ITに使う予算は余った利益で投資的に使う事が多いので、そのシステム自体のコストカットの考えにいたる経営者は少ないのではと思います。
SAPの保守が切れる２０２７年問題とありますが、大まかに４つのパターンになるかと思います。
1.契約更新
2.他のベンダー製品に乗り換え
3.お金がないので、保守が切れたまま使い続ける
4.思い切ってスクラッチでいちから開発
４の担当になったエンジニアのやりがいは大きいものになるとは思いますが、やはりリスクも大きいですね。
登録日：
更新日：