少人数企業の情報基盤は、何から設計するべきか

複数人で一つのIDとパスワードを使えば、引継ぎは簡単に見えます。しかし誰が操作したか分からず、退職者だけを止められず、2段階認証の受け先も曖昧になります。

人は個人アカウントで操作します。問い合わせ窓口や請求のような役割は、共有パスワードではなくグループ、委任、共同のキューなど、担当が変わっても残る仕組みへ置きます。個人と役割を分けると、記録と継続を両立できます。

Google Workspaceの共有ドライブでは、ファイルは個人ではなく組織に属します。メンバーが離れても、ファイルは共有ドライブに残ります。会社の資料を継続して持つという問題に、所有モデルから答えます。

ただし作れば自動で整理されるわけではありません。案件、部門、経営資料など、どこを正本にするか、誰が移動・削除できるか、外部共有をどこまで許すかを決めます。共有ドライブが増えすぎれば、担当者しか場所を知らない問題が別の形で戻ります。

連絡はチャット、承認はメール、最終版は添付ファイル、修正版は個人Drive。道具を増やすほど、どれが正しいかを人が判断する場面が増えます。

「会話はチャット、正式資料は共有ドライブ、業務状態は業務システム」のように役割を決めます。すべてを一つの製品へ集める必要はありません。重要なのは、同じ事実の最終版を複数に作らないことです。

Googleは2段階認証を、パスワードが盗まれた場合の追加防御として案内しています。導入するときは、本人の端末が使えない、担当者が不在、管理者自身が入れない場面も考えます。

予備手段、管理者の複数化、緊急時の連絡、復旧記録がなければ、安全対策が業務停止の原因になります。AIサービスを使う場合も、会社データをどのアカウントで扱い、何を入力してよいかをIdentityと情報区分へ戻して決めます。

新しい人が入る。担当が変わる。端末を失う。退職する。会社名や組織が変わる。この一連で、どのアカウントを作り、どのグループへ入れ、何を渡し、何を止め、資料がどこに残るかを確認します。

小さな会社では、例外が少ないうちに決めた方が安く済みます。機能一覧を比較する前に、「誰がIdentityを持つか」「役割をどう引き継ぐか」「会社が何を所有するか」「どこが正本か」を一枚にする。それが情報基盤の最初の設計です。

少人数の会社では、便利な個人アカウントへ資料が集まりやすいものです。全員が見られる共有設定でも、所有者が個人なら、退職、権限変更、復旧のときに会社の資産として扱えないことがあります。ファイルの場所だけでなく、誰がIdentityを持ち、誰が役割として送受信し、会社が何を所有するかを分けます。

共有ドライブは単なるフォルダ共有ではありません。個人のマイドライブから所有を広げるための器です。ただし、共有ドライブへ入れれば全て解決するわけではありません。メール、チャット、議事録、申請、台帳のどれを正しい情報源とするか、同じ内容をどこへ書いてはいけないかを決めなければ、検索できても判断できない情報が増えます。

二段階認証も、設定した時点では終わりません。端末を失ったとき、担当者が休んだとき、入社・退職があったときに誰が安全に復旧できるかまでが運用です。Google WorkspaceやMicrosoft 365を選ぶ前に、一人が辞める日を通してみる。そこで会社の仕事が止まるなら、先に直すべきはアプリの機能ではなく情報の所有です。