この記事は、DXの実現の一要素である業務の自動化、省人化、効率化を実現するための業務のデジタル化（IT化、ICT化）の基本は業務見直しに付随するシステム化やシステム刷新で重要になるシステム形態について記載しています。
システム形態の理解はDXの基礎
RFP策定やITベンダーから提案での業務のデジタル化やシステム化（IT化、ICT化）を考える上で、先に理解しておくべきなのが「どのような形態のシステムを選ぶのか、どのようなシステム形態でシステムを実現するのか？」です。ベンダーからの提案内容やRFPで想定するシステム形態を正確に理解・把握することです。
システム形態の理解や導入後の影響を把握せずにシステムを導入すると、思わぬトラブルにつながります。
- クラウド導入（Saas）：
本記事では原則Saas（Software As A Service）を指します。Saasとは、システムを所有するのではなく、主にインターネット上で利用できるサービスの利用料（サブスクリプション）を払ってサービスを利用する形態です。Saas はクラウドの概念が広く周知されるまでは ASP（Application Service Provider）として知られていました。
今回、シングルテナントなど実質別のIaas（Infrastracture As A Service）に顧客ごとの環境を作成して構築するものは想定しません、これは実質パッケージ導入と変わらないため、パッケージ導入に近くなります。
また、Paas（Platform As A Service）は、本記事では含めておりません。PaasはアプリケーションはCSP（Cloud Service Provider／Amazon AWS, Microsoft Azureなど）制約はありますが、本記事ではパッケージ導入に近いスクラッチ開発をイメージください。 - パッケージ導入：
主にITベンダーの製品であるソフトウェア・パッケージの導入指します。
実際には、ソフトウェア・パッケージの特徴や機能、質による影響が大きくなります。
本記事では、サーバーやネットワークなどのインフラストラクチャは含みません。 - スクラッチ開発：
オーダーメイドで、利用者の要求に合わせてゼロからシステムを構築し導入するパタン。基本的に費用を無視すれば大抵の要求を実現できます。
※スクラッチ開発の詳細な説明はこちら（→）
システム形態の理解を助ける代表的メタファ
非ITエンジニアやコンサルタントでないとなじみのないシステム形態。ここでは、三つの代表的類型を「住宅」にたとえて説明します。
| システム形態 | 住宅にたとえると | 特徴 |
|---|---|---|
| クラウド導入 (SaaS) | 他の人が所有している賃貸マンションの一室を借り利用する | 低価格ですぐに使えるが変更の自由度は限られる |
| パッケージ導入 | 建売住宅など共通の設計できまった建材での組み立てる。ある程度の自由に変更できる可能性がある | 法律などの制約はあるが一部の設計変更が可能 |
| スクラッチ開発（→） | 最新の技術などをふんだんに使った、唯一無二の注文住宅などの実現も可能 | 自由度最大だが費用も最大 |
※ 各システム形態の詳細な説明は別記事へ
費用とシステムに求める要求適合度の関係は下記のようなイメージとなる。
| システム形態 | 想定 |
|---|---|
| 固定型Saas | Freeeやマネー・フォワードなど最低限の設定で利用するSaas。業務内容自体が各社で固有の部分が少ない業務に向く。具体的には、財務会計や給与計算、POSシステムなど頻繁な法改正などがある業務領域で特に向く。 カスタマイズなどによる回収などは難しいが、法改正などの対応をCSP（Cloud Service Provider、クラウドサービス提供業者）が随時バージョンアップすることで追加の費用なしで対応できる。 |
| 設定型Saas | 固定型に、設定によりカスタマイズやアドオンなしでCSPが想定する範囲で業務に合わせることが可能なSaas。対応できる限界があるため、サービスがどこまでの対応が可能か明確に理解しておく必要がある。具体的には、ワークフローシステムなどが代表的。 |
| カスタマイズ型Saas | 業界・業務分野向けの基幹システムや業務管理システム（販売管理、生産管理など）。変更のためアドオン開発したプログラムの組み込みや、プログラミング可能な仕組みが提供されている場合や、CSPやCSPのパートナー企業がカスタマイズやアドオン開発を行うことを前提としている。具体的には、SAP（Saas版）など。また、もともとパッケージ・ソフトウェアとして開発されていた既製品などをSaas化したものなどもこのサービスに位置付けられていることが多い。 カスタマイズやアドオン開発によって、利用者の要求への対応が可能だが、パッケージ導入と比較すると制約があることが多い。 パッケージ導入と同等の開発プロセスを得て導入することが多い。 |
| 固定型パッケージ | 固定型Saasと同じ特徴を持つが、Saasのように利用ではなくソフトウェアライセンスを購入し所有することになる。また、パッケージをインストールする（Iaasを含む）サーバーなどの調達も必要となる。 導入顧客専用の環境かつソフトウェア（コピー）となるためSaasと比べるとカスタマイズやアドオン開発の制約が少なるなることが多い。 |
| テンプレート型Saas | カスタマイズ型Saasと同じ特徴を持つが、Saasのように利用ではなくソフトウェアライセンスを購入し所有することになる。また、パッケージをインストールする（Iaasを含む）サーバーなどの調達も必要となる。 導入顧客専用の環境かつソフトウェア（コピー）となるためSaasと比べるとカスタマイズやアドオン開発の制約が少なるなることが多い。 |
| スクラッチ開発 | 顧客要求をヒアリングしたうえで、顧客要求を泡あせたうえでシステムを構築する。 費用や期間は大きくなるが、テクノロジーや予算、開発スキルの範囲ですべての顧客要求を実現することが可能になる。 |
Saasは基本インターネットに公開されているサービスを利用するため、利用者サイドの要求に合わせるのは、そのサービスが想定している範囲（設定可能な範囲）になります。これは、Saasの仕組みはサービスによりますが、サーバー、プログラムやデータベース環境なども多数の顧客と共有するため特定の顧客のためのカスタマイズなどはアーキテクチャ上限界があるためです。
パッケージ導入は、Saasと異なり、サーバーやデータベースは顧客ごとの環境、プログラムもコピーされたプログラムを各環境に配置するため別プログラムとなり論理的にはいくらでも変更できます。しかし、ゼロからプログラムを修正する場合、その内容が思想や根本的な部分に寄る場合、ゼロから開発するよりも大きな工数がかかることが多々あります。また、パッケージを選択する目的がベストプラクティスの導入（業界で優れた業務プロセスごとシステムを導入する）やスクラッチ開発と比較してコスト低減・短納期であることが多く、カスタマイズはあまり推奨されません。
スクラッチ開発は基本的に、サーバーやデータベースなども含めて顧客要求に従い設計を行います。そのため、基本的にテクノロジーや開発チームの能力が対応できる限り顧客の要求の実現が可能だが、開発工数が大きくなりより高い費用がかかるケースが多くなります。
Saas・パッケージ・スクラッチだから確実に費用に対して要求適用度が高いとはなりません。それは、同一の業務機能を目的としたSaasやパッケージそれぞれでも特徴・機能が異なるため、そもそも要求に合わせること自体ができないものから、合わせる（カスタマイズ、アドオン開発）ことが可能なもの、合わせることは可能だが高額な費用がかかるものまで様々なものがあります。
ITベンダーが“自称する分類”を鵜呑みにしない
現実には、これらのシステム形態は、ITベンダーが営業戦略上、“自社に有利な分類”として提示している場合が多く、実態とは異なることがあります。
特にクラウド導入 (SaaS)とパッケージ導入の境界はぼかしく、以下のような情報は必ず判断しておくべきです。
- SaaSと言われているが実態はテンプレート型パッケージでイニシャル費用が超高額（運用費の５年分以上など）
- SaaSなのに世の中の動向に沿うセキュリティ対策やバージョンアップに追加料金が必要になる
- 実質パッケージ型にも関わらずSLAや契約上の賠償額上限がSaaSに沿い、ユーザー側にリスクを押し付けている
これらの見極めに本記事ではシステム形態の大きな分類を示します。特にクラウドはクラウドの中でSaasや、クラウド上での反スクラッチPaas、Iaasと分かれており、パッケージ導入・Saas導入に関しては、パッケージ導入、クラウド導入両方を理解しておく必要があり詳細記事も参照ください。
契約・会計・支払い構造の違いを押さえる
| 観点 | クラウド導入（SaaS） | パッケージ導入 | スクラッチ開発 |
|---|---|---|---|
| 初期費用（ソフト） | 原則なし〜小額（設定料等） | ライセンス購入＋初期設定＋カスタマイズ・アドオン開発費用 | システム構築費用 |
| 初期費用（インフラ） | インフラ込み（IaaS） | オンプレ or クラウド（Iaas）構築費・調達費 | 同左 |
| 月額/年額費用 | 月額利用料（サブスク） | 保守委託費または人件費・バージョンUP費用・ライセンス利用料 | 保守委託費または人件費・バージョンUP費用 |
| 会計処理（初期） | 通信費・賃借料（費用処理） ※所有しないため資産でなく費用となり、減価償却できない | ソフトウェア資産＋減価償却（原則5年償却） | 同左 |
| 会計処理（月額/年額） | 支払手数料・サービス利用料（主として通信費） | 保外注費・保守費用等・支払手数料（支払い手数料 or 通信費） | 外注費・保守費用等 |
| 契約形態 | Web利用規約／クリック契約 | 準委任契約・請負契約 | 準委任契約・請負契約 |
| 損害発生時の賠償金額の目安 | 1年間の運用費用 | 上限を初期費用までにするのが一般的 | 同左 |
※Iaas（Infrastracture as a Service）：サーバーやOSなどをインターネット上で提供するクラウドサービス、詳細は別記事で
※システムの契約についてはIPA情報システム・モデル取引・契約書も参照（→）
実態を見抜く重要性
本記事で提示した類型分析や図解マップは、定義をラベルづけするためのものではありません。それぞれの組み合わせや属性を、正しく構造的に理解するための「価値判断の補助線」として使うことを意図しています。
実際には、クラウドのパッケージもあれば、オンプレミスのSaaSに近いものもあり、さらにテンプレート型のスクラッチ開発に近いパッケージもあります。
分類に当てはめるのではなく、「契約条件」「支払い方式」「会計処理」まで含めて全体構造で判断することが、プロジェクト成功・システム導入後の余計な費用などを追加させないための前提条件です。
今後の記事でより詳しく解説します
- クラウド導入の実態とリスク
- パッケージ導入の使い手の違い
- スクラッチ開発が選ばれる環境と違うリスク（→）
そして、これらの違いを、業務サイドの視点から不都合を消滅するアプローチへとつなげていくことで、初めて「デジタル化」ではなく「DXの結果」にたどり着くと考えます。