社内ポータルは「月額SaaS」で借りるか、Google Workspaceで作るか — 不動産会社のコスト構造で考える
社内の連絡・申請・スケジュール・掲示板をひとつにまとめる「社内ポータル」。多くの会社が、1ユーザーあたり月いくらの月額サービスで借りています。私は不動産業界で20年、現場の業務を見てきましたが、この「1人月額」という課金の形が、人数の増える会社ほど後で効いてくるのをよく見ます。一方で、多くの不動産会社は既に Google Workspace（Gmail・ドライブ・カレンダー）を契約しています。だとすると、ポータルは「もう1つ契約する」だけでなく「今ある Google Workspace の中に作る」という選択肢が出てきます。この記事は、その2つをコスト構造で並べて、どちらが自社に合うかを判断するためのものです。
月額課金型ポータルの「気づけば高い」構造
月額サービスそのものが悪いわけではありません。導入が速く、保守も提供元が持ってくれます。問題は課金の「形」です。1ユーザー月額の料金は、人数 × 月数 × 年数で効いてきます。10人で始めた会社が20人になれば、使い方は同じでも請求は倍。しかもこれは「毎年出ていく固定費」で、5年使えば単純に月額の60倍が積み上がります。
もうひとつが乗り換えのしにくさです。掲示板・申請履歴・スケジュールがそのサービスの中に貯まっていくほど、他へ移す手間が重くなる。値上げや仕様変更があっても「今さら移せない」となりやすい。これは製品の善し悪しではなく、データを預ける構造そのものが持つ性質です。
Google Workspace を既に使っているなら、選択肢は3つになる
自社が既に Google Workspace を契約している前提で整理すると、ポータルの持ち方は3通りあります。
| 持ち方 | 追加の月額 | 向いている会社 |
|---|---|---|
| ① 月額ポータルを別途契約 | 人数 × 月額（毎年） | 自社で作る体力がなく、多機能をすぐ使いたい会社 |
| ② Google Workspace の中に作る | 追加ライセンス費なし（初期の構築のみ） | 必要な機能が絞れていて、固定費を抑えたい会社 |
| ③ 業務基盤（kintone 等）上に作る | 基盤のライセンス費 | 申請・案件データを業務システムと一体で持ちたい会社 |
②の「Google Workspace で社内ポータルを構築する」が今回の主題です。Google Apps Script という Google Workspace 標準の仕組みを使うと、掲示板・申請ワークフロー・スケジュール・共有ドライブ横断検索といった「ポータルらしい機能」を、追加のサービスを契約せずに Google Workspace の中に組み立てられます。データは会社が管理する Google Workspace の中にとどまり、外部のサービスに渡りません。ここが、外部サービスに預ける①との一番大きな違いです。
コスト構造の比較 — 「毎月の固定費」か「最初の構築費」か
同じポータルでも、お金の出方がまったく違います。数字は会社ごとに変わるので金額は入れず、構造だけ並べます。
| 観点 | ① 月額ポータル | ② Google Workspace で内製 |
|---|---|---|
| 初期費用 | 小さい（すぐ使える） | 構築費がかかる（1回だけ） |
| 毎年の固定費 | 人数 × 月額 × 12（増員で増える） | 追加ライセンス費なし（保守のみ） |
| 人数が増えたとき | 請求が比例して増える | 原則そのまま |
| 機能を足したいとき | 提供元の仕様待ち | 自社仕様で追加できる |
| データの置き場所 | 提供元のサーバー | 会社の Google Workspace の中 |
| 乗り換えやすさ | 貯まるほど動きにくい | 自社資産なので移しやすい |
②は「最初にまとまった構築費を払い、その後の固定費を下げる」形です。だから判断は損益分岐で見ます。内製の構築費 ÷（月額サービスの年額 − 内製後の年間保守費）= 何年で元が取れるか。内製にしても保守の手間は残るので、そのぶんを月額の節約から差し引いて考えます（保守費が月額の年額に近いと、そもそも割安になりません）。加えて、切り替えの時期は旧サービスと新しいポータルを一時的に二重で持つ期間も見込んでおきます。人数が多い会社・長く使う前提の会社ほど、②が早く回収に入ります。逆に、少人数で機能をすぐ全部使いたいなら①の手軽さが勝ちます。「安いから内製」ではなく、「自社の人数と使う年数だと、どこで逆転するか」で決めるのが正しい見方です。
実際に近い話として、私たちは業務システム上のダッシュボードを、有償の追加プラグインを使わず標準機能だけで内製した事例があります。同じ発想で「毎月払い続ける機能を、一度作って自社資産にする」判断は、固定費の重い会社ほど効きます。
内製で絶対に外してはいけないこと — 「誰が操作しているか」の確認
ここが、この記事で一番伝えたい部分です。「Google Workspace で数時間でポータルが作れる」という話は本当です。ネット上には、コピー&ペーストで動く公開コードも出回っています。ただし私たちが実際にその種のコードを1行ずつ検査したところ、そのままでは危険な設計が含まれていました。
具体的には、ポータルが「今この操作をしているのは誰か」を、利用者側から送られてくる自己申告のメールアドレスで判断していたのです。これだと、社内の誰かが「自分は管理者だ」と名乗るだけで、他人の申請を承認したり、管理設定を書き換えたりできてしまう。決裁の乗っ取りが成立する状態でした。作るのが簡単なぶん、この「誰が操作しているか」をサーバー側で信頼できる方法で確認する設計が抜けていると、便利なポータルがそのまま情報事故の入り口になります。
内製を検討するなら、機能の見た目より先に、①操作している人の身元をサーバー側で確認しているか、②他人のデータを ID を変えるだけで見られないか、③管理機能に確実な鍵がかかっているかの3点を必ず確認してください。ここは「動くかどうか」ではなく「安全かどうか」の話で、コピペで作った時に最も抜けやすいところです。
判断の5ステップ
- 今の月額を年額に直す。1ユーザー月額 × 人数 × 12。増員予定があれば3年後の人数でも出す。
- 本当に使っている機能を数える。契約した機能のうち、実際に日常で開くものだけを残す。多機能ほど内製の設計は重くなる。
- 損益分岐を出す。内製の構築費が、月額の何年ぶんに当たるか（内製後の年間保守費は、月額の節約から差し引いて計算する）。使い続ける年数と比べる。
- データの置き場所を決める。会社の Google Workspace の中に置きたいか、外部サービスに預けてよいか。ここは経営とセキュリティの方針で決める。
- 作るなら認可設計を要件に書く。前章の3点（身元確認・他人データ遮断・管理機能の施錠）を、機能一覧と同じ重さで発注要件に入れる。
まとめ — 「借り続けるか、一度作って自社資産にするか」
社内ポータルの判断は、機能比較の前にコスト構造の比較です。月額サービスは手軽さと引き換えに、人数と年数で増える固定費と、乗り換えのしにくさ（囲い込み）を抱えます。Google Workspace を既に契約しているなら、同じ機能を追加ライセンス費なしで自社の中に作り、固定費を初期の構築費に置き換える選択肢がある。判断軸は損益分岐と、データを自社に置きたいかどうか。そして作るなら、便利さより先に「誰が操作しているか」を確認する認可設計を要件に入れること。ここを外さなければ、内製は「安く済む」だけでなく「安全な自社資産になる」打ち手になります。
「今のグループウェアの月額が人数ぶん膨らんでいる」「Google Workspace で社内ポータルを作れないか」というご相談は、業務 DX 無料診断（60 分）で、損益分岐と機能の絞り込み、安全な構成案までその場でご提案します。
---
関連サービス:
関連事例:
あわせて読みたい: