麺の読み物

NOODLE NOTE

技術力不足でもSaaSリプレイスは可能か？「1帳票＝1テーブル」で挑んだAppSheet開発記

2026.2. 5

「毎月発生するSaaSのランニングコストを何とかしたい…」 「業務アプリを内製化したいが、社内に専門知識を持つエンジニアがいない…」

これらは、多くの中小企業が抱える悩みです。高機能なSaaSは便利ですが、そのコストは決して無視できません。一方で、いざ内製化しようにも技術力の壁が立ちはだかります。

この記事では、まさにそのような課題を抱え、プログラミング経験が浅い状態から AppSheet を用いて SaaSリプレイス に成功した、はしづめ製麺の開発事例をご紹介します。完璧な設計思想よりも「まず課題を解決する」ことを優先した、泥臭くも現実的なアプローチは、技術力不足に悩む多くの担当者にとって大きなヒントとなるはずです。

高額SaaSからの脱却とAppSheetという選択

すべての始まりは、事業運営における「コスト」という現実的な課題でした。なぜ高機能なSaaSを手放し、手探りで内製化の道を選んだのか。その背景には、ペーパーレス化の推進と、それに伴って顕在化したコストの問題がありました。

課題：既存SaaSのランニングコスト

はしづめ製麺では、以前から業務のペーパーレス化を進めており、その一環として帳票をデジタル化するSaaS（カミナシ）を導入していました。このSaaSは非常に高機能で、現場の業務効率化に大きく貢献していました。

しかしその一方で、月々のランニングコストが経営上の負担となっていました。特に中小企業にとって、固定費の削減は常に重要な経営課題です。便利なサービスであっても、その対価が事業規模に見合わなければ、いずれ見直しの対象となります。

この「コスト」という避けられない課題を解決するため、弊社はSaaSの利用を中止し、代替アプリを自社で開発する「内製化」という大きな決断を下しました。

解決策：AppSheetとGoogle Sheetsでの内製化

内製化を決めたものの、社内にプログラミングを専門とする開発者はいませんでした。そこで白羽の矢が立ったのが、ノーコード開発プラットフォームの「AppSheet」です。

AppSheetが選ばれた理由は、主に以下の2点です。

  1. Google Workspaceとの親和性: 既にGoogle Workspaceを導入しており、データの保存先となるGoogle Sheetsとの連携がスムーズに行える点。
  2. 開発のハードル: プログラミングコードを書かずにアプリを開発できるため、専門的な技術力が不足していても挑戦しやすいと考えられた点。

こうして、Google Sheetsをデータベース代わりとし、AppSheetでアプリケーションを構築するSaaSリプレイスプロジェクトがスタートしました。それは、コスト削減という明確な目標に向けた、手探りの挑戦の始まりでした。

技術力の壁を乗り越えた「1帳票＝1テーブル」という力技

意気揚々と始まった内製化プロジェクトでしたが、すぐに大きな壁にぶつかります。それは、データベース設計の根幹に関わる「データモデリング」の壁でした。

直面したデータモデリングの壁

効率的でメンテナンスしやすいアプリケーションを開発するには、「正規化」と呼ばれるデータベース設計の手法が一般的に推奨されます。

正規化とは、一言でいえば「データを効率よく整理整頓するための作法」です。例えば、顧客情報を複数の帳票で使う場合、それぞれの帳票に顧客名や住所を何度も入力するのではなく、「顧客マスタ」という一つの場所に情報をまとめておき、各帳票からはそのマスタを参照する、といった考え方です。これにより、データの重複がなくなり、修正も一箇所で済むため、管理が非常に楽になります。

しかし、この正規化の概念を理解して適切に設計するには、相応の知識と経験が必要です。AppSheet初学者であった開発担当者にとって、この「あるべき姿」はあまりにも高く、複雑な壁に感じられました。

シンプルな解決策：「1帳票＝1テーブル」

ここで大胆な決断をしました。それは、「理想的な正規化を、一旦諦める」というものです。

完璧な設計に固執して開発が止まってしまっては本末転倒です。それよりも、まずはSaaSで実現できていた業務を再現し、現場が使えるアプリを完成させることを最優先しました。

そのために採用されたのが、「1帳票＝1テーブル」という、非常にシンプルで力技ともいえるアプローチです。これは、これまで現場で使っていた紙の帳票一枚一枚を、そのままGoogle Sheetsのシート（AppSheet上ではテーブル）に置き換えていく、極めて直感的な方法です。

このアプローチにより、正規化の知識がなくても、目の前にある帳票をそのままデジタルに置き換える作業に集中できました。しかし、その代償としてデータ構造は複雑化し、最終的にGoogle Sheetsのシート数は69枚、アプリ全体で扱うカラム（項目）の総数は1104個にまで膨れ上がりました。

ハブ＆スポーク構造でユーザー体験を維持

テーブル数が69個もあると聞くと、ユーザーが使う画面も非常に複雑で使いにくいものを想像するかもしれません。しかし、そこにはユーザー体験を損なわないための工夫があります。

採用されたのは「ハブ＆スポーク」と呼ばれる画面構造です。これは、空港の「ハブ」から各都市へ飛行機が放射状に（スポーク）飛ぶように、アプリのトップ画面（ハブ）に必要な業務メニューを並べ、そこから各帳票（スポーク）へ簡単にアクセスできるようにする設計です。

ユーザーはまずホーム画面という「ハブ」に着地し、そこから「製造記録」「品質管理」といった目的の業務をタップするだけで、関連する帳票画面に移動できます。裏側のデータ構造は非効率かもしれませんが、ユーザーが触れるインターフェースは、SaaS時代と変わらない直感的な操作性を維持することに成功しました。

Appsheetではかなり基本的なことですが、今回の開発においてはかなり役に立ちました。

大量のテーブルを管理するための現実的な工夫

「1帳票＝1テーブル」というアプローチは、開発初期の技術的なハードルを越えるための有効な手段でした。しかし、その結果として生まれた69個ものテーブルは、開発を進める上で新たな管理上の課題を生み出します。

課題：AppSheet上でのテーブルの表示順序

AppSheetの開発画面（エディタ）にある「Data」タブでは、アプリが使用するすべてのテーブルが一覧表示されます。テーブル数が数個であれば問題ありませんが、69個にもなると、目的のテーブルを探し出すだけでも一苦労です。

さらに、日本語でテーブル名をつけた場合、AppSheetのエディタ上では、テーブルが必ずしも五十音順や作成順に並ぶわけではなく、表示順序が不規則になりがちです。これにより、「あのテーブルはどこだっけ？」と探す時間が増え、開発効率の低下を招いていました。

解決策：接頭辞による命名規則の徹底

この課題を解決するために導入されたのが、テーブル名にプレフィックス（接頭辞）を付けるというシンプルな「命名規則」です。

具体的には、すべてのテーブル名の先頭に「01_hogehoge」といった半角数字とアンダースコアを付け、業務のカテゴリや重要度に応じて番号を割り振るというルールを徹底しました。

例えば、以下のように分類します。

  • 00_XXXX: アプリ全体で使うマスタデータなど、最も重要なテーブル
  • 10_XXXX: 製造工程に関連するテーブル群
  • 20_XXXX: 品質管理に関連するテーブル群
  • 99_XXXX: テスト用や一時的なテーブル

このように接頭辞を付けることで、AppSheetの「Data」タブ内でテーブルが意図した順序で並ぶようになります。関連業務のテーブルが近くにまとまって表示されるため、視認性が劇的に向上し、目的のテーブルをすぐに見つけられるようになりました。

この命名規則という少しの工夫が、大量のテーブルの管理性を高め、複雑なアプリ開発を継続するための重要な支えとなりました。

運用後の成果と今後の課題

泥臭いアプローチと地道な工夫を重ねて完成した内製アプリ。ここでは、達成できた大きな成果と、同時に見えてきた今後の課題についてご紹介します。

成果：コスト削減の達成とアプリの完成

このプロジェクトにおける最大の目的は、「SaaSのランニングコスト削減」でした。そして、その目的は見事に達成されました。AppSheetの費用は（Google Workspaceに含まれている）かかるものの、以前のSaaSと比較して大幅なコストカットを実現できたことは、経営的に最も大きな成果と言えるでしょう。

また、もう一つの重要な成果は、「技術力が未熟でも、実用的な業務アプリは完成させられる」という事実を証明したことです。これは、完璧な設計でなくとも、熱意と試行錯誤の物量で課題を乗り越え、現場で使えるレベルのアプリをリリースできる可能性を示しています。この経験は、同様の課題を抱える多くの企業にとって、参考にしてほしい体験と感じます。

反省点：管理の煩雑さと保守性の課題

一方で、この「1帳票＝1テーブル」アプローチには、当然ながらいくつかの課題も残されています。

まず、データソースであるGoogle Sheetsの管理が煩雑になる点です。69枚ものシートが存在するため、全体像を把握しにくく、誤って重要なシートを編集・削除してしまうといったヒューマンエラーのリスクも高まります。

また、将来的な「保守性」にも懸念があります。アプリに新しい機能を追加したり、既存の仕様を大きく変更したりする場合、この非正規化の構造が足かせになる可能性があります。関連する複数のテーブルを一つずつ修正する必要が生じるなど、改修に多くの手間と時間がかかるかもしれません。

さらに、データ量が増加し続けた場合のGoogle Sheetsのパフォーマンス（アプリの動作速度）も、長期的に見ていくべき課題の一つです。

これらの課題は、いわば「スピードとシンプルさを優先したトレードオフ」の結果です。バージョン2.0、3.0へとアプリを成長させていく段階で、データ構造の見直しや、より効率的な設計へのリファクタリングを検討する必要があるでしょう。

まとめ

今回の、はしづめ製麺様の AppSheet による SaaSリプレイス 事例は、多くの示唆に富んでいます。高額なSaaSコストに悩みながらも、技術力不足を理由に内製化をためらっている企業にとって、その一歩を踏み出すための力強い後押しとなるはずです。

本記事のポイントを改めて振り返ってみましょう。

  • 技術力不足は乗り越えられる: AppSheetのようなノーコードツールを使えば、高度なプログラミング知識がなくても実用的な業務アプリは開発可能です。
  • 完璧より完成を優先する: 最初から理想的な設計（正規化など）に固執するのではなく、「1帳票＝1テーブル」のようなシンプルな方法で「まず動くものを作る」ことが重要です。
  • 工夫で管理性は向上できる: テーブル数が多くなっても、命名規則などの簡単なルールを徹底するだけで、開発時の管理しやすさは大きく改善できます。
  • 熱意と物量が道を拓く: 技術的なスマートさだけでなく、課題を解決したいという強い熱意と、試行錯誤を厭わない泥臭い努力が、プロジェクトを成功に導く原動力となります。

もしあなたが「SaaSのコストを削減したいけれど、何から手をつければいいかわからない」と感じているなら、まずは身近な業務の帳票一つを、AppSheetとGoogle Sheetsでアプリ化することから始めてみてはいかがでしょうか。完璧なアプリでなくても、その小さな成功体験が、やがて大きな業務改善へとつながっていくはずです。

よくある質問

Q: AppSheet開発には専門的なデータベースの知識が必須ですか？

A: 必須ではありません。この事例のように「1帳票＝1テーブル」といったシンプルな構造から始めることで、専門知識がなくても業務課題を解決するアプリを開発することは可能です。

Q: テーブル数が多くなると、どのような問題がありますか？

A: アプリの全体像が把握しにくくなり、管理が煩雑になる可能性があります。また、データソースであるGoogle Sheetsのパフォーマンスや保守性が将来的な課題となることも考えられます。

Q: なぜ「1帳票＝1テーブル」というアプローチを取ったのですか？

A: 開発当時に高度なデータベース設計（正規化）を行う技術力が不足していたため、現場で使われている紙帳票をそのまま再現する、最もシンプルで直感的な方法として採用されました。

Q: この開発で最も大きな成果は何ですか？

A: 高額なSaaSのランニングコストを削減するという、当初の目的を達成できたことです。また、技術力が十分でなくても、工夫と努力で実用的なアプリを完成させられることを証明しました。

今回の事例のように、AppSheetはSaaSコストの削減や業務のデジタル化において強力なツールとなり得ます。自社のSaaSコストにお悩みの方、AppSheetを活用した業務改善に興味がある方は、ぜひ一度お気軽にご相談ください。貴社の状況や課題に合わせた、最適な内製化や開発支援のプランをご提案します。