システム開発を検討して、複数の会社に見積もりを依頼する。

返ってきた金額を並べてみると、A社は800万円、B社は1,500万円、C社は2,000万円。

「同じシステムをお願いしたはずなのに、なぜこんなに違うのか？」

担当者としては、当然そう思います。高い会社が必要以上に利益を乗せているのか。それとも、安い会社が企業努力をしているのか。見積書の金額だけを見ても、なかなか判断できません。

実は、システム開発の見積もりに大きな差が出る理由の一つは、会社によって「どこから作り始めるか」が違うからです。すでに完成しているパッケージシステムを使うのか。完全にゼロから作るのか。それとも、共通の基盤だけを利用して、お客様ごとに設計するのか。

同じ「システム開発」という名前でも、中身はかなり違います。そして、最初の見積もりが一番安い方法が、最終的にも一番安いとは限りません。

見積もりが安いのには、理由がある

システム開発会社から、「当社には、すでに完成しているパッケージがあります」「それを御社向けにカスタマイズするので、ゼロから作るより安くできます」と提案されることがあります。

これは、決しておかしな提案ではありません。すでに完成しているシステムを使えば、最初からプログラムを書く必要がありません。基本的な画面や機能もそろっているため、開発期間を短くし、費用も抑えられます。

完成品には、完成品なりの都合があります。最初から決められているデータの持ち方、画面の構成、処理の流れがあります。見た目の一部を変えたり、簡単な機能を追加したりすることはできても、システムの根本に関わる部分までは自由に変えられないことがあります。

家にたとえるなら、すでに完成した建売住宅の壁紙や設備を変えるのは比較的簡単です。しかし、「やっぱり階段を反対側に移したい」「1階と2階を入れ替えたい」となれば、話は急に大きくなります。システムも同じです。

最初は安い。でも、追加見積もりが続く

パッケージを使った開発では、最初の見積もりが安く見えることがあります。その段階では、「標準機能を使えば実現できる」という前提で金額が出ているからです。

ところが、要件を詳しく確認していくと、少しずつ違いが見つかります。

• 「この承認の流れは、御社独自なので追加対応になります」
• 「このデータを扱うには、別の機能が必要です」
• 「標準画面では対応できないため、追加開発になります」
• 「外部システムとの連携は、当初の見積もりに含まれていません」

一つひとつは必要な対応です。しかし、そのたびに追加見積もりが発生すると、最初に安く見えた金額が少しずつ膨らんでいきます。

最終的に、完全にゼロから作った場合とあまり変わらない金額になることもあります。場合によっては、既存パッケージの制約と戦いながら改修するぶん、かえって費用が高くなることさえあります。

費用だけでなく、使いにくさが残ることもある

パッケージの制約による問題は、費用だけではありません。本来はお客様の業務に合わせてシステムを作りたいのに、システムの都合に業務を合わせなければならないことがあります。

• この入力順でなければ登録できない
• 使わない項目だが、標準機能なので画面から消せない
• 本当は一つの画面で完結させたいが、複数の画面を行き来する必要がある
• 例外的な処理には対応できないため、そこだけExcelで管理する

こうした小さな不便が積み重なると、せっかくシステムを導入したのに、現場から「前のやり方のほうが楽だった」と言われることがあります。

もちろん、すべてのパッケージシステムが使いにくいわけではありません。業務がパッケージの想定と合っていれば、安く、早く、使いやすいシステムを導入できます。

大切なのは、パッケージかどうかではなく、どこまで自社の業務に合っているかです。「カスタマイズできます」という言葉だけで判断せず、何を変更できて、何を変更できないのかを、契約前に確認する必要があります。

完全スクラッチなら、自由につくれる

パッケージとは反対に、システムをゼロから作る方法があります。いわゆる「スクラッチ開発」です。

お客様の業務に合わせて、データの持ち方、画面、機能、処理の流れを一から設計します。既存システムの制約を受けないため、自由度は非常に高くなります。複雑な業務や、企業独自の仕組みにも対応しやすい方法です。

その代わり、すべてを一から作るため、時間と費用がかかります。

ログインする機能。利用者を管理する機能。権限を分ける仕組み。基本的な画面の構成。データを安全に扱うための仕組み。多くのWebシステムに共通して必要となる部分まで、毎回ゼロから用意しなければなりません。

自由度は高い。しかし、助走も長い。これが完全スクラッチ開発です。

完成品とスクラッチの間に、もう一つの選択肢がある

ここまで読むと、「安いパッケージを選んで、後から追加費用が増えるのも困る」「だからといって、完全スクラッチで高額になるのも困る」と思われるかもしれません。

実は、この二つの間にもう一つの選択肢があります。

完成したパッケージを無理に作り変えるのではなく、システムに共通して必要となる「基盤」だけをあらかじめ用意し、その上にお客様専用の機能を設計する方法です。

建物にたとえるなら、完成済みの家を改造するのではありません。基礎や柱など、どの建物にも必要な部分はすでに用意されている。ただし、間取りや内装、設備は、そこで暮らす人に合わせて自由に設計できる。そのようなイメージです。

ゼロからすべてを作る必要がないため、開発を早く始められます。一方で、完成品を改造するわけではないため、パッケージ固有の制約にも縛られにくくなります。

EFGフレームワークは、完成品ではない

EFGでは、この考え方を形にした「EFGフレームワークシステム」を用意しています。

名前に「システム」とついていますが、完成済みの業務システムではありません。

EFGのエンジニアが、20年にわたるシステム開発の経験から、「業種や用途が違っても、ここは多くのシステムで共通して必要になる」という部分を抽出し、開発の土台として使えるようにしたものです。

ここで重要なのは、共通化する範囲です。

多くの機能を最初から組み込めば、たしかに完成品には近づきます。しかし、決められた機能や設計が増えるほど、パッケージと同じようにカスタマイズの自由度が下がってしまいます。

反対に、共通部分が少なすぎれば、スクラッチ開発とほとんど変わらず、時間や費用を抑える効果がありません。

どこまでを共通の土台として持ち、どこからをお客様ごとに作るのか。この境目を、20年の開発経験をもとに、ぎりぎりまで磨いてきたのがEFGフレームワークです。

三つの開発方法は、安さの意味が違う

パッケージのカスタマイズ、完全スクラッチ、EFGフレームワーク。この三つは、単純に価格だけで比較できるものではありません。

どの方法が正解かは、案件によって異なります。パッケージで十分に対応できる案件なら、無理に独自システムを作る必要はありません。

反対に、業務が独自で、パッケージの制約に合わせることが難しいなら、最初の見積もりが安いという理由だけで選ぶと、後から苦しくなる可能性があります。

見積書では、金額より先にここを見る

システム開発の見積もりを比較するときは、合計金額だけでなく、その見積もりが何を基盤にしているのかを確認してください。

完成済みのパッケージなのか、ゼロから作るのか、それとも共通基盤から作るのか。提示された金額に、要件定義、設計、テスト、導入支援まで含まれているのか。どこからが追加費用になるのか。そして、変更できる部分と変更できない部分はどこなのか。

少なくとも、開発会社へ次のように質問してみてください。

1. この見積もりは、何をベースに作る前提ですか？
2. 標準機能で対応できない部分は、どこですか？
3. 追加費用が発生する可能性があるのは、どのような場合ですか？
4. このシステムで、変更が難しい部分はどこですか？
5. 将来機能を追加するとき、どの程度の自由がありますか？

この質問に具体的に答えられる会社であれば、少なくとも安い金額だけを見せて契約を急がせる会社ではないはずです。

最初の見積もりではなく、最終的な費用で考える

システム開発は、最初の見積もり金額だけで終わるものではありません。

開発中の追加費用、完成後の改修費用、保守費用。そして、使いにくいシステムに合わせて現場が負担する時間も、広い意味ではすべてコストです。

最初に安く見えたとしても、追加開発が続き、現場に合わないシステムが残れば、本当に安かったとは言えません。

EFGフレームワークは、単に見積もりを安く見せるための仕組みではありません。多くのシステムに共通する部分は効率よく利用し、お客様ごとに違う大切な部分には、きちんと時間と費用を使う。安さと自由度のどちらかを諦めるのではなく、両方のバランスを取るための開発基盤です。

「パッケージでは自社の業務に合わない。でも、完全スクラッチほどの費用はかけにくい」。そのようなときに、EFGフレームワークという選択肢があります。

最初の数字だけを安くするのではなく、必要なものを、無理なく、長く使える形で作る。それが、EFGの考える“ちょうどいい”システム開発です。