スクラッチ開発の復権へ――20年の標準化への挑戦が拓く、業務システム開発の新時代

A-ZiPが開発したローコード業務システム開発ツール「SAAP（サープ）」。その誕生の背景と、疲弊したSIer業界が再び輝くためのビジョンを、私、三鍋俊介が語ります。

かつて日本には、お客さんと向き合いながらゼロから業務システムを作る、スクラッチ開発に情熱を注ぐSIerがたくさんありました。私自身も、その現場の熱を近くで見てきた一人です。お客さんの業務を聞き、悩みを理解し、動く仕組みに落とし込んでいく。そこには、ものづくりとしての面白さがありました。

ところが2010年代に入る頃から、スクラッチ開発の現場は少しずつ疲弊していきました。

標準化できていないために同じようなバグを何度も直し、アフターフォローに追われ、要件定義や保守の価値を十分に見積もれない。

結果として、パッケージ販売やSESへと事業を移す会社が増え、「開発そのものが好きだったはずの現場」から活気が失われていくのを感じたことを覚えています。

そんな状況を見ながら、私はずっと考えていました。

スクラッチ開発で、ちゃんと利益が出るようにできないか。

お客さんに合わせたシステムを作る喜びを、もう一度SIerの仕事の中心に戻せないか。

その問いに20年以上向き合いながら生まれたのが、ローコード業務システム開発ツール「SAAP（サープ）」です。

今回は、AIの活用が加速し、システム開発のあり方そのものが問い直されている今だからこそ、SAAPが目指している世界と、その背景にある私たちのストーリーをお伝えしたいと思います。

SAAPとは？

SAAPは、Microsoft AccessとAzure SQL Databaseを組み合わせた、業務システム開発に特化したローコードツールです。

詳細はこちら

既存のAccessテーブル定義やデータを取り込みながら、PC用フォーム、スマートフォン向けWebフォーム、Azure SQL Databaseを利用したクラウドデータベースを構築できます。また、画面名、項目名、データ型、桁数などを設定することで、基本的な画面やデータベースを作成できます。さらに、必要に応じてAccess VBAで自社固有の業務ロジックを追加することも可能です。

一般的なローコードツールの多くは、画面をどう作るか、つまりUIのデザインから入りますが、私たちが開発の起点に置いているのは、テーブル設計、つまり「データモデリング」です。

開発の起点を「UIのデザイン」ではなく「テーブル設計（データモデリング）」に置いている点が、SAAPと他のローコードツールとの大きな違いです。

すべての始まりは居酒屋のオーダーシステム

私がシステム開発の世界に入るまでの道のりは、決してまっすぐなものではありませんでした。

専門学校を卒業して最初に就職したのはトランスコスモスです。

配属先はミノルタ（現在のコニカミノルタ）のデータセンターで、三交代制の運用オペレーターをしていました。

大型コンピューターの紙やテープを交換し続ける毎日で、今振り返るとエンジニアとは程遠い仕事でした。

その後は転職と退職を繰り返し、しばらく定まらない日々が続きました。

転機になったのは、フランチャイズのコンサル会社の研修で入った居酒屋でのアルバイトです。まだタブレットなどなかった時代、その店ではAccessで構築された、非常によくできたオーダーリングシステムが使われていました。

夜中にシステムトラブルが起きると、エンジニアが駆けつけてバグを直します。

私はその様子を横で見ながら、

「どんなバグの取り方をするんやろ」

と興味津々でした。

システムの完成度にも驚きましたし、それがAccessで実現されていることにも強く惹かれました。

その夜、私は「次はAccessを使う会社で働こう」と決意しました。

そんなある朝、折込求人誌で小さな求人を見つけました。「Accessができるパートの主婦の方歓迎」という一行です。

住所を見ると、家から徒歩10分ほど。私はすぐに電話をして、「パートの募集のところに、正社員で入れてもらえませんか」とお願いしました。

半ば強引にアポを取り、履歴書を持って乗り込んだ先が、三光システム、現在のA-ZiPでした。

入社した2002年、私は25歳でした。

プログラミング経験はほぼゼロです。

ただ、以前の仕事でIBMの汎用機、MVSを扱った経験があると履歴書に書いたことで、開発経験もあると誤解されたまま採用されました。

入社初日に渡された仕様書は、今でいうテーブル定義の下書きが書かれた手書きのメモ一枚。「これ作っといて」の一言だけでした。

当時は、仕様書といってもそれくらいのものが珍しくありませんでした。

そこから、手探りで私のA-ZiPでのキャリアが始まりました。

「誰が書いたかわからないコード」という業界の問題と標準化への道のり

スクラッチ開発の現場には、長年解消されてこなかった問題があります。

プログラムを書くとき、ゴールは一つでも、たどり着く道は無数にあります。書き方が違っても動けばそれでいい。その積み重ねが、いわゆるスパゲッティコードを生みます。誰かが書いたコードに別の人が継ぎ足し、また別の人が改造する。やがて誰も全体を把握できなくなっていきます。

当時の三光システムの社長は、この問題を早くから重く見ていました。

社内で繰り返し語られていたのは、

「コーディング技術は必ずAIに取って代わられる。

コーディングができるというのは価値ではない。標準化を目指せ」

という考え方です。

AIが現在のように実用化されていなかった2002年に、すでにそうしたビジョンが語られていたことは、今振り返っても驚くほど先見的だったと思います。

標準化への道のりは簡単ではありませんでした。

三光システムでは以前から、社長が「テーブル定義から先にやるんや」と繰り返していました。

正しいデータモデリングこそが、システム開発の土台だという考え方が社内に根づいていたのです。

その考えをもとに、私たちはERPに近いアプローチにも挑みました。

私たちにとってのERPとは、あらゆる業種・業務に対応できるテーブル定義を作る試みでした。

しかし、業務そのものを徹底的に定義し、すべての会社に当てはまる形にしようとすると、「あの場合もある、この場合もある」と例外が際限なく現れます。

多業種・多業務のシステムを手がけてきたからこそ、業務を一つの型に定義しきる難しさを突きつけられました。

その経験を通じて、私たちは少しずつ気づいていきました。

「大事なのは、すべての業務を一つの型に押し込むことではない。業務に合わせて変化できる余地を残しながら、開発のプロセスとデータの持ち方を標準化することだ、と。」

標準化に向けた開発——SAAPの原型が生まれるまで

2005年頃、三光システムでは標準化に向けた取り組みが段階的に進んでいました。

まずコードの書き方を統一し、次に、テーブル定義から開発を始めるプロセスを標準化しました。

コードとテーブル定義の双方に標準があるなら、開発そのものを自動化できるのではないか。この発想が、SAAP誕生のきっかけになりました。

設計は開発部の会議で議論を重ね、実装はエンジニアを中心に進めていきました。

当初から完成形があったわけではありません。

ERPを目指しながら必要なパーツや機能を一つずつ積み上げ、何世代ものバージョンを経て、ERPにとどまらない汎用的な開発ツールへと発展していきました。

中心となったエンジニアは現在も嘱託として開発に携わっていますが、その知識と技術は若い世代へ着実に受け継がれています。

SAAPは、特定の一人の技術に依存するものではありません。世代を超えて磨き続けてきた、三光システム、そしてA-ZiPの共有資産です。

また、SAAPが少しずつ形になってきた頃、私たちは特別な舞台に立ちました。

データモデリングの第一人者を中心とした「超高速開発コミュニティ」が主催する、ライブコーディングのコンペティションです。

ルールはシンプルでした。

その場でお題が発表され、1時間でシステムを作り上げる。

完成後には仕様変更書が追加で配布され、「20分で対応してください」と告げられる。参加メンバーには、海外産の有力ローコードベンダーの日本法人も名を連ねていました。

兵庫を拠点とする小さなSIerである私たちが、世界水準のツールと同じ土俵に立ったのです。

仕様変更への対応では、面白いことが起きました。

プロが揃っているだけに、各社がすでに想定の実装をしていました。仕様変更書を見たら、全社が「我々のシステムはもう対応しています」と発表した。

結果として、20分もいらなかったのです。あの経験は、私たちが取り組んできた標準化の方向性が間違っていないと感じる大きな出来事でした。

その後、SAAPを社外向けに提供するようになったのは、2017年頃です。ただ、私が「売ろう」と決めた理由は、単なるビジネスの計算だけではありませんでした。

SAAPが形になった2012年頃、スクラッチ開発をやっていた会社の多くは、すでに疲弊していました。

標準化できていないから同じバグを何度もコピーする。

アフターフォローに工数がかかる。

要件定義の価値を正当に見積もれない。

保守費をもらえない。

その積み重ねで、スクラッチ開発の現場はじわじわと苦しくなっていました。

私は、SAAPをツール単体として届けたいわけではありません。

要件定義の進め方、見積もりの作り方、保守費のもらい方まで含めて、「スクラッチ開発で利益を出すビジネスモデル」ごと広めたい。

創業者以来、A-ZiPが大切にしてきた思いはそこにあります。

AI時代に「データの土台」を持つ意味

2026年現在、「AIがシステムを作る」「SaaSはもう終わり」といった言葉が業界を飛び交っています。

私もAIの可能性は非常に大きいと思っています。

ただ、AIがどれだけ進化しても、業務の本質は変わりません。

受注して、製品を売って提供する。在庫を管理する。請求書を出す。入金を確認する。

こうした業務は、これからも企業活動について回ります。

そして、それらをAIで自動化・最適化・有効活用するためには、きちんとしたデータが必要です。

SAAPがテーブル設計から始める思想を持っているのは、まさにここに効いてきます。

UIファーストで画面を作るのではなく、業務データが正規化され、Azure SQL Databaseに蓄積される。

そのデータが、AIによる分析、自動化、経営提案の基盤になります。

また、SAAPのシステムはVBAとSQLで記述されています。

コードをAIに渡して改修を指示しやすく、クエリやマクロを多用した旧来のAccessシステムよりも、AI活用が開発効率化につながりやすい構造になっています。

AI時代だからこそ、データの土台をどう作るかが、これまで以上に重要になると考えています。

SIerのビジネスモデルを変える3つの変化

私がSAAPを通じてSIerに届けたい変化は、大きく3つあります。

一つ目は、ヒアリング当日に「動くシステム」を見せられることです。

SAAPは、パラメーターを設定してボタンを押すだけで、実際に動くプロトタイプを生成できます。

ヒアリングの場で「こういうシステムになります」と操作しながら見せることができます。要件定義で大事なのは、お客さんから「ここが違う」を引き出すことです。

資料や言葉だけでは、お客さんも完成形を具体的にイメージできません。

動くものを見て触ってもらうことで、本人も気づいていなかった要望や認識のずれを早い段階で具体化できます。

二つ目は、利益の出る見積もり構造を作れることです。

SAAPによって開発工数を抑えられれば、その分、業務ヒアリングや現状把握といった上流工程に時間をかけられます。

顧客の業務を深く理解したうえで設計に入ることで、認識のずれや手戻りを防ぎ、より正確な要件定義が可能になります。

ツールを入れたから安くするのではなく、要件定義や現状分析をコンサルティングの価値として、きちんと見積もりに載せるべきだと私は考えています。

三つ目は、月額サービスへの転換です。

SAAPでは、開発者ライセンス1本から複数の利用者へのシステム提供を開始できます。

このライセンスは顧客ごとに独立して紐づく仕様のため、顧客の増加に合わせてライセンスを追加していくスマートな拡張に対応しています。

エンドユーザー数の増加に伴い、顧客ごとの開発者ライセンスを順次追加していくことで、各社に最適化された継続的なサービスを安定して提供できます。

つまり、一社ごとに開発して納品する一括受託型だけではなく、同じ仕組みを複数の顧客に月額で提供する継続サービス提供型の事業モデルを構築できるのです。

すでにSAAPを活用し、エンドユーザーへWebシステムを月額提供しているSIerも現れています。

また、SAAPがAccessをベースにしていると聞くと、

「古いのではないか」

「壊れやすいのではないか」

と言われることがあります。

ですが、SAAPはAccessの機能をそのまま使って構築したシステムではありません。

A-ZiPは長年の開発経験から、Accessの強みと弱みを熟知しています。

フォーム、レポート、VBAといった優れた機能は生かす。

一方で、弱点になりやすいデータベーステーブル、クエリ、マクロには依存せず、別の技術や仕組みで補う。

そのノウハウの集大成がSAAPです。

さらにSAAPでは、PC向けのAccessフォームと同時に、スマートフォンやタブレット向けのWebフォームも自動生成します。

現場ではスマホで入力や進捗報告を行い、事務所ではキーボードを使って素早く処理する。業務に応じた使い分けができます。

現在は完全Web版の開発も進めており、SAAPは今も進化を続けています。

スクラッチ開発が「再び戻ってくる」時代へ

「AIが急速に進化するなかで、スクラッチ開発はどうなるのか。」

そう聞かれることが増えました。

私は、業務システムとして安心してデータを預けられ、安心して利用できるところまでAIが進化すれば、AIが主流になる可能性はあると思っています。

ただ、そこに至るまでの道のりは、まだかなり長いと考えています。

各社固有の要望や特殊な処理をAIが実装できるかどうかだけが論点ではありません。

業務システムには、重要なデータを安全に扱い、安定して動き続けることへの信頼が欠かせません。そこをどう担保するかは、これからも大きなテーマであり続けます。

SAAPが目指すAI活用は、SIerのコーディングや開発速度を支援するだけのものではありません。

SAAPで構築した業務システムに蓄積されたデータを、エンドユーザー自身がより有効に活用するためのAIです。スクラッチ開発で信頼できる業務基盤を作り、そこに蓄積されたデータの活用をAIが支える。私は、両者がそのような形で共存していく未来を描いています。

私たちがSAAPを通じて届けたいものは、要件定義から開発、アフターフォローまでの全工程を標準化し、中小企業向けのスクラッチ開発でもSIerが適正な利益を確保できる構造です。そして、コーディングの手数ではなく、現場を理解するヒアリング力と設計の知恵を価値とするエンジニア文化です。

2002年、私は居酒屋でAccess製のオーダーリングシステムに出会い、システム開発の面白さに惹かれました。2005年頃には、開発部の会議で設計を重ね、一人のエンジニアが中心となってSAAPの原型を実装し、その後も世代を超えてパーツや機能を積み上げ、何度ものバージョンアップを重ねてきました。

二十余年にわたって磨いてきたこの仕組みは、AI時代におけるシステム開発業界の次の形を指し示せると信じています。

『スクラッチ開発は、なくならない。むしろ、標準化とAIを味方につけることで、もう一度、SIerが誇りを持って取り組める仕事にできる。』

SAAPは、そのための道具であり、A-ZiPの挑戦そのものです。これからもさらなる進化に向けた挑戦を続けていきます。