業務システム開発においてまず問題になるのが「パッケージソフトを利用するか、フルスクラッチで構築するか」という悩みです。今回は「両者のメリット・デメリット比較」「システム開発のよくある失敗」の2点を解説します。システム開発を担当するベンダーを探している担当者の方はぜひ参考にしてください。
まずはメリット・デメリットを比較する前に、それぞれの定義を確認してみましょう。パッケージは、すでに開発済みのシステムに月額費を支払って利用する手法です。既存の業務システムにパッケージを組み込むケースもありますが、基本的には開発工程を行わず「お金を払ってシステムを利用する」という理解でOKです。
一方フルスクラッチ開発はゼロから自社独自のシステムを構築する手法を指します。パッケージと異なり時間も費用もかかりますが、自社のニーズに最適なシステムを導入できます。そして両者の中間にあたるのが、パッケージをベースに部分的なカスタマイズを行うハーフスクラッチです。それぞれに特長や注意点がありますが、ざっくりと「パッケージ=お金を払って構築済みのシステムを利用する」「フルスクラッチ=自社システムをオーダーメイドで設計する」と理解しておきましょう。
クイックスタートに最適
①開発の予算を抑えられる
まず挙げられるパッケージのメリットは、開発コストを削減できる点です。あらかじめ設計されたシステムをすぐに利用できるため、開発時の初期費用がほとんど発生しません。
②導入期間が短い
要件定義や設計、開発の時間が必要ないため、マスター登録などの初期設定が済めばすぐに業務をスタートできます。
③保守・運用の手間が減る
システムは開発して終わりではなく、問題なく動作するような保守・運用の手間が欠かせません。パッケージならシステムを提供する企業が保守・運用などのメンテナンスや機能のアップデートを担当してくれるので、社内の人的リソースが足りない場合も安心です。
「帯に短し襷に長し」に要注意
①業務に必要な機能を満たしていない可能性がある
完成されたシステムを利用できるのがパッケージの利点ですが、弱点でもあります。業務上必要な機能が最低限しか搭載されていない場合はオプションで機能を追加しなければいけません。その場合、開発期間やコストが追加で発生してしまいます。
②毎月のコストが発生する
パッケージの多くは月額料金制です。初期費用を安く抑えられる一方で、ランニングコストが発生します。オプション機能なども追加した結果、結局フルスクラッチで開発した方がよかった、というケースも。初期費用だけでなく、長期的な目線での費用対効果を考慮しましょう。
③サービス終了で使えない機能が発生する恐れがある
システムの提供事業者が一部の機能を停止した場合には利用を続けることができません。また最悪のケースではシステムそのものの運営を停止する恐れもあり、提供元の経営判断が自社の事業に影響してしまうリスクを踏まえておくことが重要です。
世界に一つのシステムで事業に貢献
①自社の要件に最適なシステムを構築できる
パッケージが手に取りやすいカジュアルファッションなら、フルスクラッチはオーダーメイドスーツに例えられます。自社オリジナルのシステムを開発できるので、特定の業界に求められる専門的・先進的な機能を求める場合に力を発揮します。
②機能の追加がしやすい
パッケージはできること・できないことが既に決められているため、機能を追加する難易度が高くなってしまいます。一方でフルスクラッチなら保守対応や機能の追加が容易です。自社の事業や市場ニーズの変化に対応しながら機能を追加できる点も、事業運営において大きなメリットになります。
③長期的な運用が可能
パッケージ開発は提供元の企業がサービスを打ち切ってしまうと利用できなくなるリスクがありますが、フルスクラッチの場合はその恐れはありません。また②で挙げたように機能の追加や改修も比較的容易なため、長期的な目線で運営することができます。
【フルスクラッチのデメリット】
長期的な目線でコスト回収が必要
①導入費用が高額
パッケージと異なりゼロからシステムを設計する必要があるので、その分導入費用が高額になってしまいます。見積もりの段階で必要な機能を精査し、予算との折り合いを見極める必要があります。
②開発期間が長い
こちらも①と同じく、フルスクラッチの大きなデメリットです。どのような機能を実装するかを決定する要件定義の工程、実際にシステムを構築する実作業の工程に加え、そもそもどのベンダーに開発を委託すべきかを選定する期間も必要になるので、あらかじめ長期的なスケジュールを考慮することが大切です。
③条件によっては月額コストが発生する場合もある
システムの一部に外部システムを使用する場合や運用維持費として、月額数万~数十万円のコストが発生する場合があります。「オリジナルのシステムだからランニングコストは軽微だろう」という認識で依頼してしまい、思わぬコストにプロジェクトが中断してしまうケースも散見されます。
システム開発ではパッケージとフルスクラッチ、双方のメリット・デメリットを把握することが必要です。しかし、これはシステム開発のいわばスタート地点。「パッケージかフルスクラッチか」ばかりを注視してしまったため、思わぬトラブルに見舞われる事例も後を絶ちません
パッケージソフトのカスタマイズは規定のオプションを想定していることが多く、独自の仕様を実装するためには多くの工数が発生してしまいます。
特に規模感の大きな企業の場合は厳しいセキュリティ規定を設けていることが多く、特定のアプリケーションを利用できないケースが見受けられます。このようなミスを防ぐために、企業の開発担当者は情報システム部門だけでなく総務部門などとも密接にコミュニケーションを行う必要があります。
システムを導入する目的があいまいだったり、関係者があまりに多いと上記のような失敗に陥ってしまいます。システムを主に使用する部門、予算やスケジュール、そしてオーナーシップを取る責任者(部門長)などの前提条件について精査し、社内の合意を獲得しておくことが重要です。
上記のような失敗はなぜ生まれるのでしょうか。これらの失敗を防ぐためにはシステムを開発する前の段階、つまり事前の情報整理が大切です。
システム開発の目的によってKPIは変わります。例えば現場の担当者が業務効率化を求めてシステム刷新を提案するも、経営層には「そのシステムでどれだけ事業が成長するのか」を求められてしまい、プロジェクトが頓挫してしまうケースが少なくありません。事業の成長とは別軸で、システム刷新によってどのような目的を達成したいのかをあらためて考慮してみましょう。
業務システムの導入や、業務のデジタル化を実現するための最初のステップが業務整理です。業務フローや個別の業務内容を整理し「何を・どのようにデジタル化するのか」「デジタル化してどのような価値を生み出したいのか」などの目的を明確にする必要があります。一見地味ですがシステム開発においてはとても重要な工程であり、この部分をきちんと行えていない企業がとても多いことも事実です。
パッケージにしろフルスクラッチにしろ、求められるのは目的に合った最適なシステムを選ぶことです。特にフルスクラッチの場合は大きな予算が動くので、その企業がどれだけ業務のデジタル化に投資できるかの経営判断にも左右されます。システムの選定、目標設定や業務整理を各部門の担当者のみで行おうとすると、どうしても視野が狭くなってしまいます。全社的・客観的な視点で推進する機能・役割を担う部門や担当者を明確にすることが、最適なシステムを実現する第一歩です。
パッケージかフルスクラッチかを判断するためにはそもそも自社の課題やシステムの導入目的、予算状況などをあらかじめ精査し、マッチングを見極める必要があります。そのためには IT技術だけではなく、システムの運用のノウハウや事業理解などが求められます。
日常の業務に取り組みながらこのような作業を行うのはとても大変ですが、かといってベンダーに丸投げしてしまうと、自社の事業やビジネスに合わないシステムが出来上がってしまいます。ベンターを選定する際には、自社事業への理解度やシステム導入に対する理解度、それらを前提とした費用対効果への意識の有無などを選定の基準とすることが重要です。