オーダーメイドのソフトウェアか、既製のソリューション（SaaS）か？
ブダペストのソフトウェア開発会社であるMesterséges Intelligencia Központ Kft. の考えでは、既製のソフトウェア（SaaS）は業務プロセスをカバーしていれば十分であり、オーダーメイドが見合うのは、業務の進め方が一般的なものと異なる場合か、ソフトウェアそのものがビジネス上の強みになる場合です。
要点： 既製品が開発なしで業務プロセスの大部分をカバーし、企業がそれに合わせられるなら、既製のソリューションのほうが早道です。業務の進め方が既製品の前提と異なる場合、多くのシステムをつなぐ必要がある場合、あるいはデータと追加開発の主導権が戦略的な問題である場合は、オーダーメイド開発が見合います。多くの場合、良い答えは両方の組み合わせ、つまり既製の基盤にオーダーメイドの追加開発を加える形です。
オーダーメイドのソフトウェア、既製のソフトウェア、SaaSとはそれぞれ何ですか？
この3つの用語は、2つの異なる問いに答えるものです。1つはソフトウェアが誰のために作られたのか、もう1つはそれがどのようにユーザーに届くのかという問いです。
- オーダーメイドのソフトウェア： 特定の企業のニーズに合わせて、発注を受けて開発するプログラムです。発注者が仕様書で求めたことを、その企業での仕事の進め方どおりに実行し、追加開発の方向も発注者が決めます。
- 既製の（パッケージ）ソフトウェア： 多くの顧客向けに作られる製品で、企業はそのライセンスを購入し、通常は自社のコンピューターやサーバーにインストールして運用します。設定によって調整できますが、動作のロジックは提供元が決めます。
- SaaS（Software as a Service、サービスとしてのソフトウェア）： 提供元が自社のクラウドで稼働させる既製のソフトウェアで、企業はサブスクリプションで、ブラウザーから、またはプログラミングインターフェースを通じて利用します。プログラミングインターフェース（API、application programming interface）とは、2つのプログラムが人の手を介さずにデータをやり取りするための接続口です。
米国国立標準技術研究所（NIST）によるクラウドの定義では、SaaSの場合、利用者はクラウド上で稼働するサービス提供者のアプリケーションを使い、その基盤となるインフラストラクチャー（ネットワーク、サーバー、オペレーティングシステム、ストレージ）も、個々のアプリケーション機能も管理しません。管理できるのは、せいぜい限定的なユーザー単位の設定だけです（NIST SP 800-145）。これはSaaSの強みであると同時に限界でもあります。提供元は運用の負担を企業から引き受けますが、製品の何を、いつ変えるのかを決めるのも提供元です。
第3の道：既製の基盤にオーダーメイドの追加開発
判断が「どちらか一方」になることはまれです。多くの企業にとって現実的なのは、一般的な業務（会計、メール、事務作業）には既製品を使い続け、その企業がほかの企業と本当に異なる働き方をしている部分にオーダーメイド開発を行う道です。ハイブリッドなソリューションの代表的な形は次のとおりです：
- 連携： オーダーメイドのプログラムがAPIやWebhookを通じて既製のシステム同士をつなぐため、データを手作業で書き写す必要がなくなります。Webhookとは、あるイベントが発生したとき、たとえば新しい注文が届いたときに、あるシステムが別のシステムへ送る自動通知です。
- オーダーメイドのモジュール： 既製品がカバーしていないプロセスのために、既製のシステムの横に独自のアプリケーションを作ります。たとえば特殊な価格設定ルール、生産スケジューリング、業界固有の台帳などです。
- 既製のシステムの上に置く独自の画面： 顧客や現場で働く社員は、自分の作業に合わせたシンプルな画面を使い、その裏側では既製のシステムが動きます。
ハイブリッドな道の利点は、本当に独自の部分にだけ開発費を支払えばよいことです。欠点は、オーダーメイドの部分が既製のシステムのインターフェースの変更に追随しなければならないことです。そのため連携にはログ記録とエラー通知が必要で、その保守を誰かが担わなければなりません。システム同士の連携と繰り返し作業の自動化については、業務プロセス自動化のページでご説明しています。
判断基準の一覧表
| 観点 | 既製のソフトウェア（SaaS）に傾くのは… | オーダーメイド開発に傾くのは… |
|---|---|---|
| 業務プロセスへの適合 | プロセスが一般的で、企業がソフトウェアに合わせることを受け入れる場合 | 企業の業務が一般的なものと異なり、その違いを維持したい場合 |
| 競争上の優位性 | その分野が、企業を競合他社と差別化するものではない場合 | ソフトウェアそのものがビジネス上の強みである、またはそれを支えている場合 |
| 連携の数 | 接続するシステムが少なく、それらに既製のコネクターがある場合 | 多くのシステムをつなぐ必要がある、または既製のコネクターがない場合 |
| データと解約 | 提供元が完全な機械可読形式のエクスポートを提供し、解約の条件が明確な場合 | データモデルとシステムの主導権が戦略的な問題である場合 |
| ユーザーとライセンス形態 | ユーザーが少なく、人数が予測できる場合 | ユーザーが多い、または急速に増え、ユーザー単位の料金が大きな比重を占める場合 |
| 立ち上げの速さ | すぐに稼働させる必要があり、既製の機能で足りる場合 | 開発を待ってから始められる、または段階的に始められる場合 |
| 保守は誰が担うか？ | 社内にITの人員の余力がなく、提供元の保守で足りる場合 | 運用を担える人がいる場合：社内チームまたは契約した開発会社 |
| データの保管場所とコンプライアンス | 提供元のデータ保管場所と契約が要件を満たしている場合 | データを特定の場所にとどめる必要がある、または厳しい業界規制が適用される場合 |
すべての行で同じ側に傾く必要はありません。大半の基準が既製品の側に傾くなら、まずは既製品から始めるのがよいでしょう。一方、重要度の高い行（適合性、競争上の優位性、連携）がオーダーメイド開発の側を指している場合は、より踏み込んで計画し、少なくとも1つの機能グループについて具体的な比較を行うことをお勧めします。
総保有コスト（TCO）は何によって決まりますか？
総保有コスト（英語ではtotal cost of ownership、略してTCO）とは、導入時の価格だけでなく、ソフトウェアを使用する期間全体にかかる支出のことです。2つの道ではコスト構造が異なるため、1年分だけを比較すると判断を誤るおそれがあります。予定している使用期間全体で見ることをお勧めします。
既製のソフトウェアやSaaSでは、通常、次の要素がコストを左右します：
- ユーザー数や選択したプランに応じて増えることが多い、サブスクリプション料金。
- 追加モジュールと上位プラン（必要な機能がそこでしか使えない場合）。
- 導入、設定、社員のトレーニング。
- 連携とカスタマイズ。別のパートナー企業が担当することもよくあります。
- 解約：いつか乗り換える必要が生じた場合の、データのエクスポートと移行。
オーダーメイドのソフトウェアでは：
- 開発。費用は主にソフトウェアの機能規模によって決まります。
- 運用：ホスティング、監視、セキュリティアップデート。
- 企業のニーズの変化に応じた保守と追加開発。
- ノウハウの維持：システムが特定の1人に依存しないようにするための、ドキュメントと完全なソースコード。
オーダーメイド開発の費用は、作業範囲を感覚で見積もるのではなく測定すれば、計画できるようになります。当社は開発の機能規模をCOSMICファンクションポイント（ISO/IEC 19761）で測定し、そこからお見積もりとスケジュールを作成します。手法は料金の考え方のページでご説明しています。長期的にどちらの道の費用が少なくて済むかは、ユーザー数、変更の頻度、連携の数によって決まります。これに一般的な答えはなく、個々のケースに合わせた試算があるだけです。
ベンダーロックインとデータポータビリティ
ベンダーロックイン（英語ではvendor lock-in）とは、別の製品への乗り換えが非常に難しい、あるいは費用がかかるために、企業が事実上その製品から離れられない状態を指します。原因としては、閉じたデータ形式、不完全なエクスポート、その製品だけに結びついた多数の設定、解約しにくい契約などが考えられます。
欧州連合のデータ法（Data Act、規則（EU）2023/2854）は2025年9月12日から適用されており、データ処理サービス間の切り替えを独立した章で定めています。その前文では、SaaSもこうしたサービスに含まれるとしています。規則の本文は、特に次のことを定めています（2026年10月17日確認）：
- 切り替えの条件は書面の契約で定めなければならず、切り替えを開始するための解約予告期間は最長2か月です（第25条）。
- 切り替えは、要請があれば不当な遅滞なく、最長30暦日の移行期間内に可能にしなければならず、その間もサービスは稼働し続けなければなりません。これが技術的に実現不可能な場合、サービス提供者は理由を示したうえで、最長7か月の移行期間を指定できます（第25条）。
- 契約では、移行できるデータを網羅的に列挙し、データを取り戻すための期間を少なくとも30暦日確保しなければなりません（第25条）。
- 2027年1月12日以降、サービス提供者は切り替えの手続きに料金を課すことができません。それまでは、切り替えに直接関連する費用を超えない、減額された料金のみが認められます（第29条）。
重要な例外として、料金に関する規定と一部の技術的義務は、主な特徴の大部分が1社の顧客のニーズに合わせて作られ、広く提供されていないサービスには適用されません（第31条）。既製のシステムが企業の委託を受けて個人データを処理する場合は、一般データ保護規則（GDPR）もサービス提供者に義務を課します。サービスの終了時には、管理者の選択に従い、すべての個人データを消去するか返還しなければなりません（GDPR第28条第3項(g)）。これは情報提供であり、法的助言ではありません。
法律は条件を改善しますが、解約の計画は企業自身が立てなければなりません。できれば、製品を選ぶ段階で立てておくべきです。確認しておきたい点は次のとおりです：
- すべてのデータをどのような形式でエクスポートできるか。たとえばCSV（カンマ区切りのテキストファイル）、JSON（機械可読な構造化テキスト形式）、データベースのバックアップなどで、添付ファイル、メモ、変更履歴が含まれるかどうか。
- データを継続的に取り出すこともできる、ドキュメント化されたAPIがあるかどうか。
- 試験エクスポートによって、データを別のシステムに読み込めることを確認できるかどうか。
- 契約が解約、切り替えの料金、データの消去について何を定めているか。
ソースコードは誰のものですか？
既製のソフトウェアやSaaSでは、企業が購入するのは利用権です。ソースコードは提供元に残り、新機能、価格の変更、製品の提供終了といった製品の行く末は提供元が決めます。製品が安定していて、データを持ち出せるのであれば、それ自体は問題ではありません。
オーダーメイド開発では、ソースコードと利用権の扱いは契約で定めます。そのため、コードが誰のものか、発注者が完全なソースコードとドキュメントを受け取れるか、別の開発会社がシステムの追加開発を行えるかを、明確に定めておくことをお勧めします。当社でも、ソースコードと利用権の扱いは契約で定めます。契約のそのほかの重要なポイントについては、ソフトウェア開発会社はどのように選べばよいですか？の記事でご説明しています。
システムの種類によって判断の重点は異なります
上記の基準は一般的なものですが、システムの種類によってその重みは異なります。統合基幹業務システムでは、カスタマイズとアップグレードのしやすさのバランスが決め手になります。これについてはオーダーメイドのERPか、カスタマイズした既製のERPか？の記事でご説明しています。顧客管理システムでは、独自の営業プロセスとユーザー単位のライセンスが大きな意味を持ちます。オーダーメイドのCRMを開発する価値があるのはどのような場合ですか？の記事をご覧ください。ECサイトでは、レンタル型プラットフォームの立ち上げの速さと、自由に拡張できることとが比較の対象になります。ECサイト：レンタル型システムか、オーダーメイド開発か？の記事をご覧ください。業務システムの開発全般については、業務ソフトウェアのページでお読みいただけます。
判断のためのチェックリスト
次の質問への答えが、多くの場合、おのずと進むべき道を示してくれます：
- 既製品のデモで項目ごとに確認できるほど、業務プロセスを詳しく書き出せますか？
- 既製品は、開発なしの設定だけで、プロセスのどれくらいをカバーできますか？
- この分野は、企業を競合他社と差別化するものですか、それともどの企業でも同じように行われているものですか？
- いくつのシステムと接続する必要があり、それらには提供元がサポートする既製のコネクターがありますか？
- 数年後には何人のユーザーがシステムで作業し、それに伴ってサブスクリプション料金はどう変わりますか？
- 完全な機械可読形式のエクスポートを受け取れますか。また、それを試験エクスポートで試しましたか？
- データはどこに保存され、どこで処理されますか。それは企業のデータ保護上および業界上の要件を満たしていますか？
- 誰がシステムを運用し、追加開発を行いますか。そのパートナーがいなくなった場合はどうなりますか？
- 稼働開始までにどれくらいの時間がありますか。システムを段階的に稼働させることはできますか？
典型的な失敗
- プロセスではなく機能一覧を比較すること： 2つの製品が同じ機能をうたっていても、違いはそれが企業の日々の業務にどう合うかにあります。デモでは自社の実際の事例に沿って確認することをお勧めします。
- 初年度の費用だけを比較すること： サブスクリプション料金は人数とともに増え、オーダーメイドのシステムの運用と追加開発の費用は年月をかけて発生します。
- 解約を忘れること： データのエクスポートは、解約するときではなく、選ぶときに確認しなければなりません。
- 既製品の過度なカスタマイズ： ある一線を越えると、何重にもカスタマイズした既製のシステムのアップグレードは、きちんと切り分けたオーダーメイドのモジュールの保守よりも手間がかかります。
- すべてを一度に置き換えること： 段階的な移行（まず1つのモジュール、続いて次のモジュール）のほうが、一度きりの大規模な切り替えよりもリスクは小さくなります。
よくあるご質問
オーダーメイドのソフトウェアを開発する価値があるのはどのような場合ですか？
企業の業務の進め方が既製品の前提と異なり、その違いを維持したい場合、多くのシステムをつなぐ必要があり、それらに既製のコネクターがない場合、あるいはソフトウェアそのものがビジネス上の強みである場合です。既製品が開発なしでプロセスの大部分をカバーできるなら、通常はそのほうが早道です。その場合は、初回のご相談の際にそのようにお伝えします。
オーダーメイドのソフトウェアは長期的に見て割高ですか？
必ずしもそうではありませんが、自動的に割安になるわけでもありません。既製のソフトウェアのサブスクリプション料金はユーザー数やプランとともに増え、オーダーメイドのシステムでは運用と追加開発が継続的な費用になります。どちらの費用が少なくて済むかは、予定している使用期間、人数、連携、変更の頻度によって決まります。個々のケースについて試算することをお勧めします。
SaaSを解約したら、データはどうなりますか？
それは主に契約によって決まるため、選ぶ段階で確認しておくことをお勧めします。EUのデータ法によれば、契約では移行できるデータを網羅的に定め、データを取り出すために少なくとも30暦日を確保しなければなりません。また個人データは、GDPRに基づき、サービスの終了時に管理者の選択に従って消去または返還しなければなりません。実際には、試験エクスポートを行えば、データが別のシステムでどの程度使えるかがわかります。
両方を組み合わせることはできますか？
はい。多くの企業にとって、それが現実的な道です。一般的な業務には既製のシステムを使い続け、オーダーメイドの連携でほかのシステムとつなぎ、企業が他社と異なる部分にはオーダーメイドのモジュールを作ります。その前提条件は、既製のシステムにドキュメント化されたAPIでアクセスできることです。
ソースコードは誰のものになりますか？
既製のソフトウェアやSaaSでは、ソースコードは提供元のもので、企業は利用権を得ます。オーダーメイド開発では、ソースコードと利用権の扱いは契約で定めます。当社でも同様です。
当社がお手伝いできること
Mesterséges Intelligencia Központ Kft. は、オーダーメイドのソフトウェアを開発し、既製のシステム同士をつなぎます。実際に作業を省ける場面では人工知能も活用し、OpenAI（ChatGPT）、Anthropic（Claude）、Google（Gemini）の言語モデルを既存のシステムに組み込みます。初回のご相談は無料で、既製品で足りる場合はその旨もお伝えします。オーダーメイド開発が必要な場合は、その機能規模をCOSMICファンクションポイントで測定し、そこからお見積もりとスケジュールを作成します。ご要望に応じて秘密保持契約（NDA）を締結します。引き渡し後の運用・保守もお引き受けします。ソースコードと利用権の扱いは、契約で定めます。
詳しくはオーダーメイドのソフトウェア開発のページをご覧ください。御社の状況についてご相談をご希望の場合は、お問い合わせのページに記載の連絡先までご連絡ください。