同じ装置、異なる文書：製造企業のキャビネットとグループ権限の運用事例

営業担当者は顧客に送る製品仕様書を探していました。技術サポート担当者は同じ装置の現地点検手順を探し、研究開発担当者は最近の試験で確認した設計変更を検討していました。

どの資料にも同じ装置名が入っています。しかし、全員にすべての資料が必要なわけではありません。顧客向けの承認済み仕様と社内検討中の設計案では、目的も閲覧対象も異なります。

本記事は、架空の産業機器メーカーがRAGO-Xで文書キャビネットとグループ権限を設計する運用事例です。実顧客の導入実績や測定成果を紹介するものではありません。

最初は「装置ごとに一つのフォルダー」でした

会社は装置モデル別に製品紹介、導入マニュアル、現地点検表、設計レビュー、試験結果をまとめていました。収集には便利でしたが、利用時には疑問が生じました。

「この仕様書は顧客に渡してよい最終版ですか？」

「現地技術者に必要な導入手順だけを見せられませんか？」

「営業に製品資料を開くとき、社内試験記録も公開する必要がありますか？」

RAGO-Xへ移す前に、担当者は基準を決めます。装置名だけでまとめず、同じ人に提供してよい文書を同じキャビネットに入れるという方針です。

グループ単位のキャビネットアクセスでは、主題と閲覧対象の両方を考えます。タイトルに「社内用」と書くだけでアクセス権が分かれるわけではありません。

まず五つの業務単位に分類

所有者と部門の文書担当者が資料一覧を確認しました。営業は承認済み製品資料、技術サポートは現地手順、研究開発は設計・試験資料を確認します。

同じ装置の資料でも別々に置けます。承認仕様書は「製品・営業」、社内設計レビューは「設計・試験」で確認します。

「協力会社向け共有」は公開リンクや自動外部共有を意味しません。この例では、外部提供可能な資料を集め、社内担当者が確認して渡すキャビネットです。

外部提供資料は個別に確認

導入マニュアルに社内向け注記がある場合、原本をそのまま共有用へ置きません。技術サポートが外部に必要な内容と提供範囲を確認した資料を準備します。

RAGO-Xが機密部分を自動で隠したり公開を承認したりするという意味ではありません。分類は組織の担当者が判断します。

同じ承認資料を複数のキャビネットで扱う場合は、版のずれを防ぐ更新担当者を決めます。分類後も原本変更を反映する手順が必要です。

次は部署名だけでなく業務範囲に合うグループ

所有者は文書利用者に一般ユーザーの役割を付与し、次のグループを作ります。

• 全社員： 共通案内が必要な社員。
• 営業： 製品説明と提案の担当者。
• 技術サポート： 導入・点検・顧客技術支援の担当者。
• 研究開発： 設計レビューと試験の担当者。
• 協力会社対応： 外部向け資料を確認・提供する社内担当者。

「協力会社対応」は部署ではありません。協力会社の仕事を担当する営業と技術サポートの社員をまとめ、部署とは別の業務権限を表します。

「全社員」もこの例で作るグループで、招待による自動所属は想定しません。

設定の順序

所有者は権限管理 → ユーザーグループ → 新規グループで名前と説明を入力し、有効状態を確認して登録ユーザーを追加します。

次に権限管理 → キャビネットアクセスでスペースとキャビネットを選び、許可グループを選択して保存します。

初期設定は所有者が行い、運用管理者は管理可能なスペース内で設定を担当します。

キャビネットとグループを接続

次は一般ユーザーを対象としたアクセス設計です。「許可」はそのグループをキャビネットへ指定したことを表します。

社員は複数のグループに所属できます。営業社員は「全社員」と「営業」に属し、協力会社業務も担当するなら「協力会社対応」に追加します。

「—」は明示的な拒否規則ではなく、そのグループから許可を与えていないという意味です。別の有効なグループから同じキャビネットが許可されていれば、アクセスは残ります。

本人の有効なグループと接続されていないキャビネットは全員公開ではありません。「グループ未指定なら全員が見える」とは考えません。

所有者・管理者だけで確認しない

「管理者」というグループ名と ADMIN 役割は別です。この例のグループは文書利用範囲を定めるもので、管理権限を与える設定ではありません。

所有者・管理者にはグループ検査の例外になる参照処理があります。人事・設計資料をグループ分けしても、管理者に同じ境界が適用されるとは限りません。

管理役割を任せる人を別途選び、表は一般ユーザーで検証します。管理者が見えることと、特定グループの社員が見えることは別の検証結果です。

月曜の朝、三人が同じ装置について質問

部門担当者が実際の業務質問で構成を確認します。以下は必ず得られる回答の例ではなく、用途とアクセス範囲を確認するための状況です。

営業：顧客に案内する仕様を探す

ジスは「製品・営業」を選びます。

この装置を提案するとき、顧客に説明すべき設置スペースと基本仕様をまとめてください。

承認資料を基に確認し、根拠が提供されれば原文と照合して提案書に反映します。開発中の数値を確定仕様として案内しないために、内部レビューと分けた意味が現れます。

回答品質だけでなく、一般ユーザーのジスが「設計・試験」を利用できないことも確認します。

技術サポート：現地点検手順を探す

ミンホは「導入・保守」を選びます。

初期導入後に装置が正常起動しない場合、マニュアルでは最初にどの項目を確認するよう案内していますか？

案内を読み、現地の装置モデルとマニュアルの版が一致するか確認します。仕様説明が必要なら、別途許可された「製品・営業」を選びます。

二つにアクセスできても、一つの質問が自動で両方を横断検索するとは想定しません。業務に合うキャビネットを選んで質問する運用です。

研究開発：試験の根拠を検討

ソヨンは「設計・試験」で尋ねます。

最近の試験結果と設計レビュー記録で繰り返し言及された検討項目を探してください。

回答と原文を確認して開発会議の資料を作り、現地手順との比較には「導入・保守」を利用します。

表では研究開発を「製品・営業」に接続していません。必要になれば担当者が目的を確認して変更します。最初から全グループを全キャビネットに接続せず、必要な範囲を明示します。

一か月後、技術サポートの社員が営業へ異動

ミンホを「営業」に追加するだけで終わりにはしません。新業務で必要なのは全社共通と製品・営業資料であり、現地保守と協力会社対応からは外れます。

「製品・営業」は異動前には技術サポート経由、異動後には営業経由で見えます。表示が続くことは変更失敗ではありません。どのグループから許可されるかを確認します。

不要になった「導入・保守」と「協力会社向け共有」には、別の有効なグループ経由でもアクセスが残っていないかを確認します。

一人の異動のためにキャビネットから技術サポートグループ全体を外すと、他の社員にも影響します。この場合は本人の所属を変更します。

協力会社の作業終了後、何を閉じるか

導入準備が終わったら、共有キャビネットを次の作業でも使うかによって対応を分けます。

• 一人だけ担当を外れるなら「協力会社対応」から削除します。
• グループ全体を停止するなら無効化します。
• グループを別業務で使い続け、特定キャビネットだけ終了するなら接続を外して保存します。

「協力会社向け共有」という名前で協力会社社員のアカウントに権限が自動発生することはありません。社内担当者が確認済み資料を別の提供手順で渡します。

すでに外部へ渡したファイルもグループ設定では回収できません。今後のアクセスと配布済み資料の管理を分けて扱います。

分類後も文書担当者は必要

キャビネットごとに担当者を決め、文書変更と人事変更時の確認事項を記録します。

これはRAGO-Xが自動実行する承認・人事連携機能ではなく、会社が定めた運用手順です。

重要なのはキャビネットの数ではない

数を増やすだけでは整理できません。全キャビネットに「全社員」を接続すると業務別の区分が失われます。細分化しすぎても質問先を選びにくくなります。

会社は三つの質問で構成を確認します。

1. 同じキャビネットの資料を同じ人に提供してよいか？
2. そのグループに利用を許可する業務上の理由は明確か？
3. 入社・異動・共同作業終了後に誰が接続関係を確認するか？

同じ装置でも営業、技術サポート、研究開発が必要とする知識は異なります。キャビネットが資料を集め、グループが必要な人をつなぎます。利用者の視点での検証と変更時の点検により、分類が日常の権限運用につながります。

設定画面はユーザー・アクセス管理ガイド、既存画面との連携はAPIガイド、機能範囲は製品概要をご覧ください。