スクラッチ開発とは パッケージ・ノーコードとの違いと選び方

自社の業務に合わせて一から作るシステム開発を、スクラッチ開発と呼ぶ。既製のソフトを導入する方法や、画面の操作で作るノーコード開発と並べて検討されることが多い。選び方を間違えると、費用と期間が想定を超えやすい。ここでは、スクラッチ開発の意味、パッケージ導入やノーコードとの違い、契約や進め方で注意する点を整理する。

スクラッチ開発とは

スクラッチ開発は、既製のソフトを土台にせず、要件の整理から設計、プログラミング、テストまでを自社の業務に合わせて行う開発の進め方である。「スクラッチ」はゼロからの意味で使われる言葉で、公的な用語集に定義が載っているわけではない。IPA(情報処理推進機構)の資料では、経済産業省とIPAが公開する「情報システム・モデル取引・契約書」の現行のモデル契約を「スクラッチ型の新規開発を念頭においたもの」と説明している。同じ資料の第二版の公表文書によると、第一版は重要インフラや企業の基幹システムの受託開発を念頭に置いたもので、ユーザーとベンダーの契約を扱っている。

一般には、開発会社に発注する受託開発の形をとることが多い。自社の開発チームで作る場合もスクラッチ開発にあたる。

パッケージ・ノーコードとの違い

比べる点	スクラッチ開発	パッケージ導入	ノーコード・ローコード
作り方	要件に合わせてゼロから設計・開発	既製のソフトを導入し、設定や一部の改修で合わせる	画面の操作で部品を組み合わせる
業務への合わせやすさ	高い	製品の機能の範囲内	ツールの機能の範囲内
期間	要件定義から稼働まで長くなりやすい	導入作業が中心	小さな業務なら短くできる
費用の払い方	開発費が先にかかり、保守費が続く	ライセンス費(または利用料)と導入費	利用料が中心
運用	作った後の保守を自社または開発会社が担う	製品の保守に沿う	ツールの提供者が基盤を保守する
契約の型	受託開発の契約	パッケージ導入に沿った契約	利用規約・サービス契約

IPAの用語集は、ノーコード開発を「プログラムコードを書くことなくソフトウェア開発をすること」、ローコード開発を「最小限のプログラムコードを書くことでソフトウェア開発をすること」と説明している。たとえばkintoneは、プログラミングなしで業務アプリを作れるクラウドサービスである。パッケージは、国産のERPパッケージとして案内されているGRANDITのように、あらかじめ業務の機能がそろった製品である。ノーコードとローコードの詳しい違いはノーコード・ローコードとはに書いた。

契約の型も異なる。経済産業省とIPAのモデル取引・契約書は、第一版を受託開発(一部企画を含む)と保守運用の契約として作り、パッケージを使った導入向けには追補版を用意している。第二版の公表文書は、追補版が想定するのはITの専門知識を持たないユーザーと、業として情報サービスを提供するベンダーの契約で、必ずしも基幹システムのような大きな開発は想定していないと記している。

メリットと注意点

メリット

• 業務の流れや画面を、自社のやり方に合わせて設計できる
• 他社と同じ機能にならない部分(独自の計算、現場特有の手順)を実現できる
• ソースコードやデータの構造を自社の資産として持てる(契約で権利の帰属を決めた場合)

注意点

• 要件が固まらないまま始めると、途中で仕様が変わり、費用と期間が増える。IPAの講演資料は、第一版の公開以降の論点として、プロジェクトの途中で問題が起きたときにユーザーが上流の工程まで遡って解除に基づく代金返還請求や損害賠償を求める紛争が起きていることを挙げている
• 作った後の保守(OSや部品の更新、セキュリティ対応)を継続して担う人が要る
• 担当した人や会社が離れると、仕組みが分かる人がいなくなる。設計書とソースコードの引き渡しを契約で決める

向いている場面・向いていない場面

• 向いている: 業務の流れが独自で既製品が合わない場面、競争力の源になる業務、他システムと細かく連携する必要がある場面
• 向いていない: 会計・勤怠・給与のように多くの会社で業務の形が共通している分野(弥生会計 Nextのような既製のクラウドサービスがそろっている)、短期間で始めたい場面、保守を担う人を置けない場面

OSSを土台に改造する方法もある。EC-CUBEはネットショップを自社で構築するためのオープンソースのソフトで、改造もできる。WordPressやOdooも、ソースコードが公開されており、自社の環境で運用できる。スクラッチとパッケージの中間の選択肢である。

選ぶとき・進めるときの手順

1. 業務のうち、既製品で足りる部分と、独自でなければならない部分を分ける
2. 既製のパッケージやクラウドサービスで足りる範囲を調べる(大全の業務システムの一覧で機能と料金の形を比べる)
3. 独自の部分が残る場合に、スクラッチ開発の範囲を最小にする。残りは既製品やノーコードに任せる
4. 開発会社の候補を探す(大全の開発会社の一覧、発注先探しを助けるシステム幹事など)。実績と、保守の体制を確認する
5. 要件定義の段階で、完成の条件、変更時の費用の扱い、権利の帰属、納品物(設計書・ソースコード)、保守の範囲を契約に書く
6. 小さな範囲から作り、動くものを見ながら進める進め方(アジャイル型など)も検討する。IPAは非ウォーターフォール型の開発用に別のモデル契約書を公開している

よくある質問

スクラッチ開発は必ず高いのか

一般に、同じ機能をそろえるなら、既製品より初期の費用と期間がかかりやすい。ただし、既製品を大きく改修するより安くなる場合もある。要件の量と、保守にかかる年数で比べる。

パッケージを改修するのとスクラッチの境目はどこか

法的な定義はない。契約書で、元になる製品と、追加開発の範囲を分けて書いておくと、保守や権利の扱いが明確になる。

ノーコードで作ったものは後で作り直せるか

画面で作った仕組みは、そのツールの中でのみ動くことが多い。他のシステムへ移すときは、データの書き出しの方法を先に確認する。

自社に開発できる人がいなくても発注できるか

発注はできるが、要件を決める担当者は必要になる。ユーザー側の協力が足りないと、開発が進まない。経済産業省とIPAのモデル契約でも、ユーザーとベンダーの役割分担が論点になっている。

次にやること

• 業務を「既製品で足りる部分」と「独自の部分」に分けて書き出す
• 既製品の候補を大全で絞り、足りない機能を確かめる
• 開発会社に声をかける前に、完成の条件と予算の上限、稼働させたい時期をまとめる