「ちょっといいですか」が別拠点にも届く環境
以前の記事で、チャットツールは電話とメールの間を埋める「ちょうどいい」手段だと書いた。
→ 中小製造業の社内連絡は、メールでも電話でもなくチャットがちょうどいい
今回はその続きの話。チャットを入れたあと、実際にどういう環境を作ったかという事例になる。
結論から言うと、OSSのチャット＋Web会議＋リモートデスクトップを1台のVPSに載せて、ハードウェアは1人あたり5,000円以下のセットで揃えた。これで拠点間のコミュニケーションのハードルが大きく下がった。
用意したもの
ソフトウェア（すべてOSS・無料）：
- Mattermost： チャットツール。Slackと同等の機能で、データは自社管理
- Jitsi Meet： Web会議ツール。Mattermost上のボタンからワンクリックで会議が始まる
- RustDesk： リモートデスクトップ。別拠点のPCを遠隔操作できる。TeamViewerの代替
ハードウェア（1人あたり）：
- USBオーディオアダプタ（スティック型、約1,000円）
- 有線イヤホンマイク（EarPods等、手持ちがあればそれでいい）
- Webカメラ（数千円のもので十分）
合計で1人あたり5,000円かからない。
インフラ：
- VPS 1台（8コア/24GBメモリ、月額数千円）
- Docker上にMattermost・Jitsi・RustDeskをすべて同居
なぜ商用サービスにしなかったか
Google WorkspaceやMicrosoft 365を入れれば、チャットもWeb会議もまとめて使える。Zoomを契約すればWeb会議は簡単に始められる。それは知った上で、OSSを選んだ。
→ 中小製造業に Google Workspace は必要か
一番大きな理由は、気軽に試せることにある。
商用サービスを導入するとなると、少額であっても稟議が要る。展開するなら説明責任が発生する。活用されるかどうかわからない段階で会社にお金を出してもらうと、「使われなかったらどうするのか」という話になる。判断の手綱が自分の手元から離れてしまう。
OSSなら、まず数人で試してみて、使われなければ静かにやめればいい。逆に手応えがあれば広げればいい。この「試して、だめなら引く」という判断を自分の裁量でできることが、結果的に導入のスピードを上げている。
データが手元に残る。 Mattermostのチャット履歴は自社のサーバーに保存される。SlackやTeamsのように、サービス終了や料金改定で過去の記録にアクセスできなくなるリスクがない。
入れ替えができる。 OSSの組み合わせなので、どれか一つが合わなければ他のツールに差し替えられる。JitsiをやめてBigBlueButtonにする、MattermostをRocket.Chatに変える——こうした選択肢が残る。商用サービスに全部載せた場合、この柔軟性はなくなる。
「ワンクリックで会議」が変えたこと
技術的な構成よりも、実際に使ってみて一番効いたのは チャットからワンクリックでWeb会議に入れる という体験だった。
Zoomだと「会議リンクを発行→チャットやメールで共有→参加者がリンクをクリック→待機室を経由して入室」という手順になる。これは週1回の定例会議なら問題ないが、「ちょっと聞きたい」の場面では重すぎる。
MattermostとJitsiを連携させると、チャット上のボタンを押すだけで会議が始まる。相手はチャットに表示されたリンクをクリックするだけで入れる。アカウント登録もアプリのインストールも要らない。
これによって、チャットで「この件、今ちょっと話せますか？」と送って、相手が「いいですよ」と返したら、そのままボタンひとつで画面共有しながら話せる。別拠点にいても、隣の席に声をかけるのに近い感覚で会話が始まる。
以前の記事で「チャットは電話への入口にもなる」と書いたが、このワンクリックの仕組みがあるかないかで、その入口の広さがまったく違ってくる。
ハードウェアは安くていい
Web会議というと、会議室にカメラとマイクスピーカーを設置して——というイメージを持つ人もいる。しかし拠点間の日常的なコミュニケーションに必要なのは、会議室の設備ではなく、各自のデスクにある手軽なセットのほう。
USBスティック型のオーディオアダプタに有線イヤホンマイクを挿せば、マイクとイヤホンの両方が使える。これが1,000円程度。Webカメラは数千円のもので画質は十分。ヘッドセットのような大げさなものは要らない。
大事なのは 全員が同じセットを持っている こと。特定の人だけが会議に参加できる環境では「ちょっと聞きたい」が機能しない。全員のデスクにイヤホンとカメラがある状態を作ることで、チャットからWeb会議への切り替えが日常になる。
リモートデスクトップがあると「見せて」ができる
RustDeskを入れた理由は、別拠点のPCを直接操作できるようにするため。
社内SEの業務では「画面を見ないとわからない」場面がよくある。Excelの設定がおかしい、プリンタが動かない、システムにエラーが出た——こうした問い合わせに電話やチャットのテキストだけで対応するのは限界がある。「どこのボタンを押しましたか？」「画面に何と出ていますか？」のやりとりを10往復するより、画面を直接見たほうが1分で解決する。
RustDeskはTeamViewerと同じように、相手のPCにアクセスして遠隔操作ができる。違いは、中継サーバーを自社で運用するのでデータが外部を経由しないことと、ライセンス料がかからないこと。
構築の難易度
正直に言えば、GWSやZoomをアカウント契約するのに比べれば、構築の手間はかかる。VPSの契約、Dockerのインストール、各サービスの設定、SSL証明書の取得、ドメインの設定——これらを自分でやる必要がある。
ただ、今はAIに設定手順を聞けばほぼそのまま動くレベルで回答が返ってくる。docker-composeのファイルもnginxの設定も、聞けば出てくる。以前なら公式ドキュメントを読み込んで試行錯誤していた作業が、かなり楽になっている。
→ 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる
気をつけるべきはセキュリティ。ファイアウォールの設定とポートの開放は、何を開けて何を閉じるかを理解した上でやる必要がある。ここだけは「AIが言ったからそのまま」ではなく、自分で判断すべきところになる。
コストの比較
ソフトウェアの費用がゼロなので、商用サービスで揃えた場合と比べると年間コストは桁が一つ違う。かかるのはVPS代だけ。
ただし、この差額は「自分で構築・運用する手間」との引き換えになる。社内に構築できる人がいなければ、商用サービスのほうが正解になることもある。
一つ知っておくべきこととして、Mattermostにはスマートフォン用のアプリがあるが、OSS版ではプッシュ通知に本番品質のサービスが提供されていない。通知が届くこともあるが、保証はない。基本はPCのブラウザやデスクトップアプリで使い、スマホのプッシュ通知には期待しないという前提で運用するのが現実的になる。
仕組みより「使われる状態」を作ること
この構成を入れて思ったのは、ツールを用意しただけでは使われないということ。
最初から全員が使ったわけではない。定着したのは、「チャットで聞いたらすぐ返事が来た」「画面共有したら一発で伝わった」という小さな成功体験が積み重なってからだった。
ツールの選定や構築は最初の一歩にすぎない。使われる状態になるまで付き合う覚悟がないと、仕組みだけ作って誰も使わないという結果になりかねない。
→ 中小製造業の現場にタブレットを配っても定着しない ── 入力は「いつ・どこで」を設計する
このシリーズの他の記事：