フルスクラッチ開発とパッケージ開発の違い | 導入時のポイントを解説
こんにちは。Wakka Inc.のWebディレクターの安藤です。
システムを開発する際に検討すべき課題のひとつとして、フルスクラッチとパッケージのどちらを選ぶかがあると思います。フルスクラッチとパッケージ、それぞれの特徴はなんとなく理解していても、実際に選ぶとなると
「うちの場合はどちらが適しているのだろう？」
「どちらかを選ぶための基準やポイントはどこにあるのだろう？」
といった疑問がわいてくる方もいらっしゃるのではないでしょうか。そこでこの記事では、みなさまが疑問を解消する参考になるように、
- フルスクラッチ開発とパッケージ開発の進め方の違い
- それぞれのメリット・デメリットの比較
- 導入を検討する際にチェックしておきたいポイント
についてくわしく解説していきますので、ぜひお役立てください。
Wakka Inc.ではフルスクラッチ開発を得意としています。
フルスクラッチ開発のちょっとした疑問から お見積もり依頼までお気軽にお問い合わせください
▼関連記事
フルスクラッチ開発とパッケージ開発の違い
フルスクラッチ開発とパッケージ開発ではどのような違いがあるでしょうか？まずはそれぞれの開発の進め方について解説します。
フルスクラッチ開発の進め方
フルスクラッチ開発では、ウォーターフォール型と呼ばれる開発手法が今も多く使われている傾向です。ウォーターフォール型の開発は、大きく区分すると次の工程で順番に進めます。
- 要件定義
- 設計
- プログラム開発
- テスト
- 移行・導入
- 運用
フルスクラッチ開発はゼロからオーダーメイドのシステムを構築するため、まず業務に必要となる機能要件と、性能やセキュリティなどの非機能要件をゼロベースで洗い出すのが、最上流である要件定義で実施すべきことです。
要件定義で確定した機能要件、非機能要件をもとに、以降の設計～テストの工程を順に進めていきます。
ウォーターフォール型の開発では、ひとつの工程が終了するまで次の工程へは進みません。テスト工程までが終わると製品としては一旦完成で、あとは構築したシステムを本番に移行する工程へと移ります。
無事に本番移行が完了すると、運用工程の開始です。
パッケージ開発の進め方
パッケージ開発も、基本的な流れはフルスクラッチ開発と大きくは変わりません。フルスクラッチ開発と違って特徴的なのは、要件定義の進め方にあるといって良いでしょう。
パッケージ開発の場合、要件定義ではまずフィット・ギャップ分析を行います。
フィット・ギャップ分析とは、パッケージ製品が持つ機能と設定オプションを自社の業務と突き合わせ、適合している部分と不適合の部分を明らかにすることです。パッケージ製品の機能仕様をもとにして、
「Aの機能は今の業務にそのまま使える」
「Bの機能は使えなくもないけど、うちの業務の手順では使い勝手が悪い」
「Cの機能は使わないので不要」
「Dという業務手順があるが、適した機能がない」
などのような評価をするわけです。
フィット・ギャップ分析の結果、ギャップがあった部分についてそれぞれどう対応するか方針を決めます。基本的には、
- パッケージ製品の機能に合わせて業務の手順を変更する
- 業務の手順に合うようにパッケージの機能をカスタマイズする
のどちらかになるでしょう。分析によって業務を棚卸して、重要度の低い業務を廃止するといった整理をする場合もあります。
フィット・ギャップ分析でパッケージの機能をカスタマイズする箇所が決まったら、要件定義は完了です。
あとはフルスクラッチ開発と同様、ウォーターフォール型の開発手法でカスタマイズする機能の設計～テストを進めます。
フルスクラッチとパッケージの導入比率
ところで、パッケージ開発は日本国内でどれくらい普及しているのでしょうか。フルスクラッチ開発とパッケージ開発の比率を見てみましょう。
出典：『ソフトウェアメトリックス調査2020 システム開発・保守調査』― 一般社団法人 日本情報システム・ユーザー協会（JUAS）（PDF）
上の表は、一般社団法人 日本情報システム・ユーザー協会（JUAS）が、2020年に発表した調査資料から引用したものです。
資料によると、2018-2020年累積でフルスクラッチ開発（業務パッケージの使用状況が”使用せず”）が64.5%。対してパッケージの使用状況は、ERP、単体パッケージ、その他ツールを合計して全体の35.5%という比率です。
資料では2016年時点と比較するとパッケージが2倍以上に増加しているとも報告されており、35.5%という結果は、過去の数値と比較すると決して低い比率ではありません。
この資料は、JUASの会員企業を対象にしたアンケートの回答結果から集計されているためサンプル数はやや少ないですが、国内全体で見てもパッケージが増加している傾向に大きな違いはありません。
一方で、アメリカやヨーロッパ諸国など、海外ではこの比率が完全に逆で、パッケージを導入するケースがほとんどだといわれています。
先述したとおり日本国内ではフルスクラッチ開発が6割以上を占めているため、海外と比較すると日本のパッケージの導入比率は少ないといえるでしょう。
フルスクラッチ開発のメリット・デメリット
フルスクラッチ開発のメリット
フルスクラッチ開発のメリットは自由度が高いことです。オーダーメイドで完全オリジナルのシステムをゼロから構築するため、どのような機能をどのような仕様で実装するかは自由で、何の制約もありません。
したがって、自社の業務に適合したシステムを構築できるのです。
また、システムが本番稼働してからも、機能の追加や改善にスピーディに対応できます。
フルスクラッチ開発のデメリット
フルスクラッチ開発のデメリットは開発費用が高額になることです。
パッケージ製品のように多数の企業に導入することを前提にしておらず、特定の企業向けにオーダーメイドのシステムを構築するため、当然それなりの費用がかかってくるでしょう。
また、ゼロから開発するため、導入までに長期間を要するのもデメリットのひとつです。さらに、オーダーメイドのシステムを構築するためには高い技術力が必要になってきます。
- システム要件を適切に整理する技術
- 利用者が使いやすい機能を設計する技術
- プログラミングの技術
- Webデザインの技術
- セキュリティの技術
このような技術が総合的に高いレベルで必要とされるため、開発プロジェクトの技術者を確保するのが容易ではありません。
パッケージ開発のメリット・デメリット
パッケージ開発のメリット
フルスクラッチ開発とは反対に、パッケージ開発のメリットは導入期間を短くできることです。
また、多数の企業向けに開発されたパッケージ製品を導入するため、フルスクラッチ開発で同じ規模の機能を構築するのに比べると、開発費用は安く済みます。
ただし、パッケージ製品の購入料金だけなら安価ですが、カスタマイズの規模が大きくなるとそれなりに開発費用がかさみますし、開発期間も必要です。
パッケージ開発のメリットを活かすためには、いかにカスタマイズの量を少なく済ませるかがポイントになるでしょう。
パッケージ開発のデメリット
パッケージ開発のデメリットは、カスタマイズの自由度が制限されることです。パッケージ製品ははじめから決まった仕様に基づいて開発され、製品として完成されています。
ある程度のカスタマイズは可能ですが、製品の元の仕様から大きく外れたカスタマイズはできません。
また、開発費用をおさえるためにはカスタマイズの量を減らすことが必要ですが、カスタマイズの量を無理に減らすと使い勝手が犠牲になってしまい、利用者の満足度を下げることにもつながります。
フィット・ギャップ分析の時点で業務をしっかりと整理し、業務を最適化すべきかカスタマイズすべきか、適切に判断することが重要なポイントになるのです。
フルスクラッチ開発とパッケージ開発の比較表
これまでに解説してきた内容を簡単な比較表にまとめました。開発手法を検討される際の参考にしていただければ幸いです。
| フルスクラッチ開発 | パッケージ開発 | |
|---|---|---|
| 開発の進め方 | ・ウォーターフォール型が主流 ・すべてのシステム要件をゼロから定義する | ・パッケージの機能を中心にフィット・ギャップ分析をする ・カスタマイズ機能のみ個別に開発する |
| メリット | ・自社の業務に適合したシステムを構築できる ・機能追加や改善にスピーディに対応できる | ・短期間で導入できる ・開発費用が低額 |
| デメリット | ・開発費用が高額 ・導入までに長期間を要する | ・カスタマイズの自由度が限られている ・使い勝手が悪いと利用者の満足度が下がる |
フルスクラッチ開発とパッケージ開発の比較ポイント
これまでフルスクラッチ開発とパッケージ開発の特徴について、両者を比較しながら解説してきました。では、実際に開発手法を検討する際には、どのようなところに注意すれば良いのでしょうか？
このパートでは、「フルスクラッチ開発とパッケージ開発のどちらを選ぶべきか？」を決めるときのポイントをくわしく解説します。
システム開発の目的と優先事項を明確にする
まず、開発手法を選ぶ際の前提として、システム開発の目的を明確にしておきましょう。目的を明確に意識しておくことで、何を優先して検討すべきかがクリアになるからです。
「サービスをいち早く起ち上げたいので、利用するシステムも早急に整えたい」
「複雑な業務手順を見直して最適化したい」
「業務部門の利用者が使いやすく、業務を効率的に回せるようにしたい」
など、システムを開発する目的は企業を取り巻く事情によってさまざまでしょう。
目的によって優先事項は違いますし、向いている開発手法も変わってきます。次のパートからはシステム開発の目的別に、開発手法の選び方を解説します。
新規ビジネスを起ち上げるためスピード優先
新規ビジネスを起ち上げる計画があって、起ち上げに合わせてシステムもスピーディに導入したいケースがあると思います。新規ビジネスでなくてもたとえば、
「これまで対面販売しかやっていなかったが、ネット販売にも対応したいのでECサイトを構築したい」
「電話やメールの予約しか受け付けていなかったが、ネット予約にも対応したいので予約システムを構築したい」
このようなケースが最近では特に増えているのではないでしょうか。
新規ビジネスの起ち上げや、業務のネット対応などはスピードが重要になってきます。自社のビジネスに適したパッケージを見つけてスピーディに導入し、いち早くビジネスを軌道に乗せるのが適した方法といえるでしょう。
フルスクラッチで半年、1年と時間をかけて開発していると、ビジネスを取り巻く環境が大きく変化し、ビジネスチャンスを逃すことになりかねません。
一旦はシステムを導入してから、より自社に適した形に改善を重ねていけば良いのです。必要であれば、部分的にフルスクラッチ開発の採用を検討しても良いのではないでしょうか。
現状の業務を整理して最適化したい
「現状の自社業務を整理して最適化したい」
「複雑な業務手順をさらに合理的でシンプルなものにしたい」
このような場合はどうでしょう？
業務の整理自体が目的にはならないかもしれませんが、システムの導入をきっかけに、現状の業務を整理したいと考える企業は少なくありません。
パッケージ製品はグローバルな規格や、ベストプラクティスを集めた運用ガイドラインに沿って設計されたものも多いのです。
さきほど、フルスクラッチとパッケージの導入比率についてのパートで、海外ではパッケージを導入するケースがほとんどだとご紹介しました。海外でパッケージの導入が進んでいる理由は下記のとおりです。
- コアでない業務については自社の独自性を排除し、標準的な業務に対応するパッケージを利用して、導入コストをおさえるため
- パッケージは、グローバルで統一された規格や運用ガイドライン（ITILなど）に基づいて開発されているため、パッケージに業務を合わせて運用を最適化するため
- コアでない業務でコストをおさえた分、競合他社と差別化したいコアな業務に思い切って投資をするため
このように戦略的な意図をもってコアでない業務を効率化するために、海外ではパッケージの導入が進んでいるといわれています。
パッケージ製品には多くの効果的なノウハウが詰まっているため、パッケージに合わせて業務を変更することが、結果的に業務の最適化につながることもあるのです。
自社業務に合わせた独自のシステムが必要
最後に、自社業務に合わせて独自のシステムを開発したい場合です。
独自のシステムを開発するとなると、フルスクラッチ開発が選択肢として有力になるわけですが、結論を出すのは少し待ってください。
- 本当に自社業務に合った独自のシステムが必要なのか？
- パッケージの機能に合わせて業務を合理化することは考えられないか？
- パッケージの中には自社業務に合わせて使えそうな製品がないか？
フルスクラッチ開発を選ぶ前にぜひ、上記の視点でパッケージの導入が可能か十分にリサーチと検討をしてみてください。
その上でなお、自社業務に合わせた独自のシステムが必要とお考えであれば、フルスクラッチ開発を検討するのが良いでしょう。
自社の中でもコアな業務のためのシステム化であれば、戦略的に競合他社と差別化を図ることが必要な場合もあります。差別化を図るならむしろ、パッケージを導入すべきではありません。コア業務の部分で独自のノウハウを活かしてシステム化するなら、フルスクラッチ開発を選ぶのが適しているといえるでしょう。
信頼できる発注先を選ぶポイント
「開発手法の検討を終え、フルスクラッチ開発を採り入れることに決まった。
しかし、開発プロジェクトを自社内で編成できるだけの技術者はそろえられない。」
そのような中で、フルスクラッチ開発のメリットを活かしてプロジェクトを成功させるには、いかに信頼できる発注先を選ぶかが重要です。このパートではシステム開発を成功させるために、信頼できる発注先を選ぶポイントをお伝えします。
要件を引き出すリサーチ力があるか？
フルスクラッチ開発では、開発工程の最上流である要件定義をいかに正確にまとめるかが成功のカギを握っています。
- 顧客が要求した内容をただ鵜呑みにするのではなく、要求を深掘りして背景情報まで明らかにする
- 必要であればさらにヒアリングを重ね、要求の裏側にある根拠を明確にし、的確に整理する
- 要求の間に矛盾がないかなど、引き出した情報を総合的に分析する
- 顧客が気づいていない要求の矛盾や不都合な点を発見したら、代替策を提示して要求の変更をうながす
- 最終的に整理され、確定した要件を要件定義書にまとめる
このようなプロセスを経て、より質の高い要件定義を作り上げることが必要です。そのためには真の要求を引き出し、正確にまとめるリサーチ力が重要になってくるのです。
リサーチ力は、発注先の信頼度をはかる大切な要素のひとつといえるでしょう。リサーチ力を評価するには、開発ベンダーにシステム開発の見積もりを依頼するときに、次のような点に注目しておくのがオススメです。
- こちらの要求に対して、曖昧な点や不明点を深掘りして、納得いくまで質問してくれるか？
- 提案内容の土台となる根拠がしっかり積み上げられているか？
- こちらからの問い合わせや相談に対して、丁寧にリサーチして回答してくれるか？
開発ベンダーが出してくる提案内容や、提案活動における振る舞いを注意して見ておくと、ある程度は力量を評価できるでしょう。
確かな技術力と実績があるか？
技術力と実績がどれほどかを評価するには、開発ベンダーのホームページや会社案内のパンフレットなどを確認しておくと良いでしょう。
ホームページやパンフレットには取引先の企業や、過去の開発実績が掲載されていることが多いものです。
もし、自社と同じ業界の開発実績が多ければ、同業界のシステム開発に関するノウハウを豊富に持っている可能性が高いでしょう。
具体的にお客様の実名を出して、システム導入の成功事例を紹介している企業もあります。それだけ高い技術力を持っている裏付けと考えられるため、積極的に問い合わせたり情報を収集したりして、より確かな情報を入手するのがオススメです。
また、弊社のようにブログなどのコンテンツを使って、開発技術やビジネスに関する有用な情報を公開している企業もあります。
技術的に信頼できる企業かどうかを評価するためにも、公開されている情報をチェックしておくと良いでしょう。
コストをおさえる提案ができるか？
実際にフルスクラッチ開発を開発ベンダーに発注すると、開発費用が高額になる可能性が出てきます。確保していた開発予算を上回る見積もりが提示され、予算をどうやりくりするか悩ましいケースに直面する場合もあるでしょう。
そのようなときに、気軽に相談に乗ってくれる開発ベンダーが発注先にいると心強いものです。たとえば、
「開発を2フェーズに分けて、優先度の高い機能を厳選してフェーズ1で開発しましょう。残りはフェーズ2でやりませんか？」
「要件定義が固まっていないので開発ボリュームが膨らむリスクが高そうです。まずは要件定義だけで契約させてください。要件定義が終わったら残りの開発を再見積もりします。」
コストをおさえるために、親身になってこのような提案をしてくれる開発ベンダーは、信頼できる発注先の候補と考えて良いでしょう。
また、フルスクラッチ開発で高い技術力と低コストを両立させるのは難しいものですが、ラボ型開発であれば、コストをおさえながら高い技術力を得ることも可能です。
ラボ型開発は海外の企業と提携、または子会社や開発拠点を置いて、海外でシステムを開発します。
コストをおさえるためにオフショア開発を採り入れるなら、経験と実績が豊富でラボ型開発を得意とする企業を発注先に選ぶのがオススメです。
システム導入時のポイントを押さえ、最適な開発手法の選択を！
フルスクラッチ開発とパッケージ開発はどちらにもメリット・デメリットがあります。それぞれのメリット・デメリットを押さえたうえで、自社が優先すべきポイントを明確にしておきましょう。
優先すべきポイントが明確になっていれば、「フルスクラッチ開発とパッケージ開発のどちらのメリットを活かせるか？」をきちんと判断でき、最適な開発手法を選択できるでしょう。
お読みくださっているみなさまが、この記事を参考に最適な開発手法の選択をしてくださることを願ってやみません。
学生時代にWebサイトを自作したことがきっかけでWebの世界に。制作会社でデザイン、WordPressテーマ開発の実務を経て、テクニカル・ディレクターとして大規模サイト構築のディレクションを経験。2021年からWakka Inc.の日本拠点でWebディレクターとして参画。最近はブロックエディタになったWordPressをもう一度、勉強しています。
