はじめに
特定の業界に深く刺さる「業界特化SaaS（バーティカルSaaS）」の需要が高まっています。汎用ツールでは現場の業務にどうしても合わず、結局Excelと紙と行政サイトを行き来する——そんな業界ほど、専用プラットフォームの価値が大きいからです。
今回ご紹介するのは、現場業務を伴い、行政への許認可申請が必要なある専門業界向けに、業務プラットフォームをゼロから立ち上げた事例です。バラバラだった業務を「申請・機材管理・記録・ナレッジ共有」の4本柱で一元化しました。
「ニッチな業界向けに一気通貫のSaaSを作りたい」という方に向けて、設計の考え方・苦労した点・工夫した点を具体的にお話しします。
導入前の課題：「業務が、4つにバラけている」
この業界の事業者は、日々の業務の中で次のような情報を扱っていました。
- 許認可申請：行政の公的システムで手続き。状況確認のたびにそちらへログイン
- 機材管理：高額な業務用の専門機材を、誰がどれを所有・使用しているかをExcelで管理
- 業務記録・点検記録：日々の業務記録や点検・整備の記録は紙やバラバラのファイル
- ノウハウ（ナレッジ）：規制や手続きの知識がベテランの頭の中に属人化
問題は、これらがまったく繋がっていないことでした。
- 「この機材で、いつ・誰が・どんな業務をして、点検はいつしたか」を横断で追えない
- 申請と機材と記録が別管理なので、抜け漏れ・二重入力・転記ミスが起きる
- ノウハウが共有されず、新しい担当者が育ちにくい
業務そのものは回っているけれど、情報が分断されているためにミスのリスクと管理コストが積み上がっていく——そんな状態でした。
設計の考え方：「すべてを1本の線で繋ぐ」
私たちがまず取り組んだのは、機能を作ることではなくデータモデルの設計です。一元管理を実現する肝は、ここにあります。
ユーザー単位 × 機材単位で、全データを束ねる
設計の中心に「ユーザー（事業者）」を据え、そのユーザーに——
- 保有する機材
- 提出した許認可申請
- 日々の業務記録・点検・整備記録
- 契約・課金の状態
- 通知
——がすべて紐づくようにしました。さらに「機材」を第二の軸として、「この機材での業務記録」「この機材の点検履歴」「この機材での申請」が機材から辿れるようにしています。
これにより、「ユーザーから見る」「機材から見る」のどちらでも、関連情報が一気に手繰れる構造になりました。一元管理SaaSの“一元”は、画面ではなくこのデータ設計で決まります。
4本柱を、1つのプラットフォームに
機能群は、現場の業務フローに沿って4つの柱で整理しました。
- 許認可申請：行政の外部システムと連携し、申請・登録・状況確認を自社内で完結
- 機材管理：機材の登録・仕様・有効期限・状態を管理
- 業務記録・点検：業務記録、日々の点検記録、整備記録を一元的に蓄積
- ナレッジ共有：規制や手続きのノウハウ、運営からのお知らせを共有
「複数人が関わる記録」をどう表現するか
点検や整備は、複数の担当者が関わることがあります。これを素直にモデル化するため、記録に対して担当者を柔軟に複数紐付けられる関連（ポリモーフィックな多対多関連）で表現し、「誰がこの作業に関わったか」を後から正確に辿れるようにしました。
やったこと：SaaSとして“回る”ための周辺機能
業界特化SaaSは、コア機能だけでは商売になりません。課金・通知・認証・運用まで含めて初めて「事業として回るプロダクト」になります。今回実装した周辺機能は次の通りです。
課金・サブスクリプション
決済基盤を統合し、月額サブスクリプション、クレジットカード登録、領収書の発行までを自動化しました。とくに重視したのが、利用停止・再開時にアカウントの状態と課金を自動で同期させること。「解約したのに請求が続く」「停止中なのに機能が使える」といった状態のズレを絶対に起こさないよう、課金状態とアプリの利用可否を一本化しました。
多チャネル通知
通知は利用者の生活動線に合わせて多層化しました。
- アプリ内通知（未読/既読管理つき）
- チャットアプリへのメッセージ配信（連携済みユーザー向け）
- メール通知（送信ログつき）
- 運営者向けのチーム通知（重要イベントの即時把握用）
重要な手続きの期限や申請ステータスの変化を、利用者が見ているチャネルに確実に届けることを狙っています。
その他の基盤
- ソーシャルログインによる、かんたんなアカウント連携・登録
- クラウドストレージでの申請書類・登録書類の安全な保管
- PDF出力（領収書など）
- 定期バッチによる外部システムとの同期やデータ更新の自動化
特に大変だったこと
ドメインが広く、整合性の維持が難しい
申請・機材・記録・ナレッジ・課金・通知と、扱う領域がとにかく広いのがバーティカルSaaSの宿命です。機能間でデータの整合性を保ち続けるのは想像以上に大変で、「ある機能の変更が、別の機能の前提を崩していないか」を常に意識する必要がありました。ここはデータモデル設計を最初に固めたことが効きました。
外部システムとの状態同期
許認可情報は外部の公的システムが正、自社DBはその写し、という関係です。どちらをいつ正とするか、同期のタイミングと衝突の扱いを丁寧に設計しないと、「画面の情報が古い／実態と違う」が起きます。
「契約状態」と「使える機能」のズレを防ぐ
課金とアカウント状態の同期は、地味ですが最も神経を使った部分です。決済側とアプリ側で状態がズレると、お金のトラブルに直結します。ここは自動同期の仕組みを設けて、人手の判断に依存しない形にしました。
通知の多層化
「どのイベントを、誰に、どのチャネルで送るか」は、増やすほど複雑になります。通知の生成と配信を共通の仕組みに集約し、チャネルが増えても破綻しない構成にしました。
工夫したこと
- コア4機能から段階的に拡張できる構成：最初に全部を完璧に作ろうとせず、申請・機材・記録・ナレッジのコアを固め、課金や通知を後から積み増せる土台にしました。スモールスタートしたい事業者にも向く形です。
- 利用者向け／運営者向けの責務分離：エンドユーザーが使う領域と、運営側が管理する領域をはっきり分け、それぞれの画面・権限・操作をシンプルに保ちました。
- 開発速度と保守性の両立：バックエンドはLaravel、フロントエンドはVue.jsを採用。フロントは過度なSPA化を避けて画面ごとに必要な箇所だけをリッチにする方針とし、開発スピードと長期保守のバランスを取りました。
得られた結果
導入後は、申請・機材・記録・ナレッジが1つのプラットフォームに集約され、「この機材で誰がいつ何をして、点検・申請はどうなっているか」を横断で追えるようになりました。バラバラだったExcel・紙・外部サイトの行き来がなくなり、抜け漏れと二重管理が構造的に減少。属人化していたノウハウも、共有できる資産へと変わりつつあります。
こんな方は、ぜひご相談ください
- 特定の業界向けに、汎用ツールでは合わない専用SaaSを立ち上げたい
- 申請・管理・記録・ノウハウがバラバラで、横断して見られない
- サブスク課金や通知まで含めて、事業として回るプロダクトにしたい
- まずはコア機能から、段階的に育てていけるSaaSを作りたい
業界特化SaaSは、「現場の業務を、いかに正しくデータモデルへ落とし込むか」で成否がほぼ決まります。私たちは、ニッチな業界の複雑な業務を一気通貫のプラットフォームにまとめてきた経験があります。同じ課題感をお持ちでしたら、お気軽にお問い合わせください。
