Googleサイトの社内ポータル｜できることと限界になる3つの分岐点
当社は社内ポータルを自作しました。それでも、多くの会社にはGoogleサイトを勧めます。 自作したのは特殊な要件があったからで、その要件がない会社まで同じことをする必要はありません。
当社は社内ポータルを自作しました。それでも、多くの会社にはGoogleサイトを勧めます。
自作したのは特殊な要件があったからで、その要件がない会社まで同じことをする必要はありません。むしろ手を出すべきではないと考えています。
Google Workspaceを使っている会社が社内ポータルを作ろうとすると、まずGoogleサイトが候補に挙がります。追加費用がかからず、標準で含まれているためです。当社も最初はそこから始め、途中でやめました。
ただし、多くの会社にとってはGoogleサイトで足りると考えています。 当社が外したのは特殊な要件があったからで、無条件に自作を勧めるつもりはありません。
この記事では、Googleサイトで足りる会社と、足りなくなる会社の線引きを書きます。
書き手は、従業員約50人の建築・内装会社で総務部長とIT部長を兼任しています。前職はシステムエンジニアを約15年。
Googleサイトの利点を、先に整理する
自作した立場から書きますが、Googleサイトには明確な強みがあります。
1. 追加費用がかからない
Google Workspaceに含まれています。社内ポータル製品を別途契約すれば、ユーザー単位で費用が発生します。この差は50人規模でも小さくありません。
2. 権限管理がGoogle Workspaceと統合されている
閲覧できる範囲を、Google Workspaceのグループでそのまま指定できます。部署ごとに見せるページを変える、といった制御が追加設定なしで実現します。
自作する場合、この権限制御を自分で作り込む必要があります。ここは想像以上に手間がかかる部分です。
3. 誰でも作れて、誰でも直せる
これが最大の利点です。
Googleサイトはノーコードなので、プログラムが書けない人でもページを追加・編集できます。総務の担当者がお知らせを更新する、部署ごとにページを持つ、といった運用が可能です。
自作したポータルは、原則として作った人しか直せません。ただしAIで実装した場合、この前提は以前ほど強くありません。 後述します。
4. 保守が不要
Googleが提供する標準機能なので、動かなくなる心配がありません。仕様変更への追随もGoogle側の責任です。
自作の場合、Google側の仕様変更で動かなくなることがあります。そのときに気づき、直す判断をする人が必要です。
Googleサイトで足りる会社の条件
次のすべてに当てはまるなら、Googleサイトで作るべきです。
- 社内ポータルに載せたいのが、主に静的な情報（規程、マニュアル、連絡先、リンク集）
- 更新を複数人で分担したい
- 社内にプログラムを書ける人がいない、または今後いなくなる可能性がある
- デザインは実用に耐えれば十分
- 数字やデータのリアルタイム表示が不要
この条件に当てはまる会社のほうが、実際には多いはずです。
自作は選択肢が増えるだけで、優れているわけではありません。作れることと、作るべきことは別です。
足りなくなる3つの分岐点
では、どこで足りなくなるのか。当社の場合、次の3点でした。
分岐点1｜動的な表示が必要になったとき
Googleサイトは、基本的に静的なページを作る道具です。
スプレッドシートに入力された数字を、ポータル上にリアルタイムで表示する。データベース的な内容を条件で絞って一覧にする。こうした動的な表示は、Googleサイトの想定範囲を超えます。
当社は月次の売上サマリーや、掲示板の投稿一覧、FAQの蓄積などを扱いたかったため、ここで最初の壁に当たりました。
判断基準はこうです。 ポータルに載せたい情報が、更新のたびに手作業でページを編集するものなら、Googleサイトで足ります。どこかのスプレッドシートやフォームと連動させたいなら、足りません。
分岐点2｜ナビゲーションを自由に組みたいとき
Googleサイトは、レイアウトが用意された枠の中で決まります。配置の自由が利かず、余白の調整もできません。
これが問題になるのは、「どのページからでもワンクリックで各システムに飛べる」という設計を取りたい場合です。
社内ポータルが使われなくなる最大の理由は、開くのが面倒になることです。ブックマークから直接行ったほうが早いと判断された時点で、ポータルは経由されなくなります。
これを避けるには、勤怠・見積・現場管理・チャット・カレンダーといった業務システムへの入口を常時表示し、どこからでも1クリックで飛べる状態にする必要があります。この常時表示のナビゲーションを自由に組めるかどうかが、分岐点になりました。
分岐点3｜スマートフォンでの見え方にこだわるとき
Googleサイトは自動でスマートフォン表示に対応しますが、細かい調整はできません。
当社は建築・内装業で、業務の中心が現場にある社員が多くいます。その人たちが最も多く開くのはスマートフォンです。
そこで表示が野暮ったいと、使う気になりません。見栄えは好みの問題に見えて、実際には利用率に直結します。
デスクワーク中心の会社であれば、この点は問題になりにくいはずです。現場を持つ会社かどうかで、重要度が変わります。
他の選択肢と比べる
Googleサイトで足りないと判断した場合、選択肢は自作だけではありません。整理します。
| 選択肢 | 費用 | 作れる人 | 直せる人 | 自由度 |
|---|---|---|---|---|
| Googleサイト | 追加なし | 誰でも | 誰でも | 低 |
| Notion | ユーザー課金 | 誰でも | 誰でも | 中 |
| SharePoint | M365に含む | 一定の知識が要る | 限られる | 中〜高 |
| ポータル専用製品 | ユーザー課金 | 設定で対応 | ベンダー | 中 |
| GASで自作 | 追加なし | 書ける人（AIで代替可） | 要件を理解している人 | 高 |
表の4列目に注目してください。 「直せる人」が最も重要です。作るのは一度きりですが、直すのは何年も続きます。なお自作の欄は、AIで実装した場合を前提にしています。理由は後述します。
Notionを検討して外した理由
当社では、Notionも候補に挙げていました。情報の集約先としては魅力的です。
外した理由は2つあります。
1つは、費用が別途発生すること。 Google Workspaceの費用に上乗せになります。当社はすでにカレンダー用の追加製品を購入しており、これ以上の上乗せを避けたい事情がありました。
もう1つは、Google Workspaceとの二重管理になること。 ファイルは共有ドライブ、情報はNotion、という状態は、結局「どこにあるか分からない」問題を再生産します。当社がポータルを作った目的は、まさにその解消でした。
Notion自体を否定するものではありません。Google Workspaceを使っておらず、情報の集約先を一から決められる会社なら、有力な選択肢だと思います。
SharePointについて
Microsoft 365を使っている会社であれば、SharePointが標準的な選択肢になります。Googleサイトと同じ位置づけです。
検索してみると分かりますが、社内ポータルの事例や解説記事は、SharePointのものが圧倒的に多いのが現状です。Google Workspace環境での事例は、明らかに情報が少ない。
これは記事を書いている側の実感でもあり、当社が試行錯誤した理由の一つでもあります。
自作は属人化するのか｜AIで書いた場合の答え
自作の最大のリスクは属人化です。作った人しか直せない。 従来はこれが答えでした。
ただし、AIで実装した場合は事情が変わります。 ここは分けて考える必要があります。
解けた部分
- ドキュメントは後から作れる。
以前は、作りながら設計書を残さないと、後から誰も理解できませんでした。いまはコードから仕様を読み取らせて、マニュアルや設計資料を生成できます。「ドキュメントがないから引き継げない」という問題は、実質的に解消しています。
- 再現性がある。
一度AIで書けたものは、別の人がAIで書き直せます。特定の個人の技巧に依存していないという点で、手書きのコードとは性質が違います。
- 修正のハードルが下がった。
コードを読み書きできなくても、AIに聞きながら直せる範囲が広がりました。「コードが書ける人がいないと詰む」という従来型の属人化は、確かに弱まっています。
解けていない部分
一方で、移譲されていないものがあります。
- 何を作るべきかの判断。
仕様は人の頭の中にあります。どの業務課題を解こうとしたのか、なぜその画面構成にしたのか、何を意図的に作らなかったのか。 これはコードには書かれていません。
- 動かないときの切り分け。
AIは指示すれば直そうとしますが、そもそも何が起きているのかを言語化するのは人間の仕事です。原因の見当がつかない状態では、AIに何を聞けばいいかも分かりません。
- 直すべきだと判断する人。
これが見落とされがちです。ポータルが使いにくくなっていることに気づき、直す必要があると判断し、時間を確保する人。 この役割が空いたままだと、システムは静かに劣化します。
属人化は解消ではなく、質が変わった
整理するとこうなります。
| 従来の自作 | AIで実装した自作 | |
|---|---|---|
| 詰む条件 | コードを書ける人がいなくなる | 業務要件を理解し、AIに正確な指示を出せる人がいなくなる |
| 引き継ぎ資料 | 作っていなければ詰む | 後から生成できる |
| 代替可能性 | 低い | 相対的に高い |
後者のほうが、明らかに代替可能性は高い。 プログラムを書ける人材を探すより、業務を理解している人を育てるほうが、中小企業では現実的です。
ただしゼロにはなりません。 「AIがあるから誰でも保守できる」とは言えない、というのが実感です。
引き継ぐべきはコードではない
この経験から言えるのは、残すべきは「なぜそう作ったか」だということです。
- どの業務課題を解こうとしたのか
- 何を意図的に作らなかったのか
- どの判断で既製品を外したのか
コードからは、これらを読み取れません。 AIが生成できるのは「何が書いてあるか」であって、「なぜそうしたか」ではない。
逆に言えば、この記事のような記録を残しておくこと自体が、引き継ぎ資料になります。
それでも、判断は変わらない
外注して作らせるくらいなら、製品を買うべきです。 外注したものは、AIがあっても要件が社内に残りません。
自作が成立するのは、社内に業務要件を理解している人がいて、その人がAIを使える場合です。コードが書けるかどうかは、以前ほど重要ではなくなりました。
判断の順序
まとめます。次の順で検討してください。
1. まずGoogleサイトで作ってみる。 追加費用がかからず、誰でも直せます。ここで足りるなら、それ以上は不要です。
- 足りない点が出たら、それが3つの分岐点のどれかを確認する。 動的表示、ナビゲーションの自由度、スマートフォンの見え方。どれにも当てはまらないなら、運用の工夫で解決できる可能性があります。
- 分岐点に当たったら、製品の購入を先に検討する。 自作は最後の選択肢です。
- 自作するなら、業務要件を理解している人が社内に残る前提で判断する。 AIで実装すれば、コードが書ける人は不要になりました。ただし「何を作るべきか」を判断できる人は必要です。
順序を逆にしないでください。 最初から自作を前提に始めると、必要のない開発をすることになります。
よくある質問
まずGoogleサイトで作ってみるべきですか
そうしてください。追加費用がかからず、誰でも編集でき、保守も不要です。ここで足りるなら、それ以上のことをする必要はありません。当社も最初はGoogleサイトで作ろうとしました。
Googleサイトの何が足りなくなりますか
3点です。動的な表示ができない（スプレッドシートの内容をリアルタイムに出せない）、レイアウトが固定でナビゲーションを自由に組めない、スマートフォンでの見栄えが調整できない。どれにも当てはまらないなら、Googleサイトで十分です。
Notionではだめですか
Google Workspaceを使っていない、または情報の集約先を一から決められる会社なら有力な選択肢です。当社が外したのは、費用が別途発生することと、ファイルは共有ドライブ・情報はNotionという二重管理になることを避けたかったためです。
AIで作れば属人化しませんか
従来型の属人化は弱まります。ドキュメントは後から生成でき、一度AIで書けたものは別の人がAIで書き直せます。ただし「何を作るべきか」の判断と「壊れたときの切り分け」は残ります。詰む条件が、コードを書ける人から、業務要件を理解している人に変わったという整理です。
引き継ぎのために何を残せばいいですか
コードではなく「なぜそう作ったか」です。どの業務課題を解こうとしたのか、何を意図的に作らなかったのか、どの判断で既製品を外したのか。これはコードからは読み取れません。
SharePointとどちらがいいですか
Microsoft 365を使っている会社ならSharePointが標準的な選択肢です。事例や解説記事もSharePointのほうが圧倒的に多く、情報を得やすい環境があります。
この話の、実例を持ち寄る場があります。
記事の内容を「自社ではどう回すか」まで落とすのが、月例の少人数ビジネス深掘り会です。新着コラムと開催案内は、公式LINEでお届けしています。
