業務マニュアルを安心して共有するための権限とセキュリティの考え方

業務マニュアルには、社内の手順や顧客対応のノウハウ、ときには取引先名や個人情報まで、外に出したくない情報が混ざります。便利に共有できることと、見せてはいけない相手に見せないこと。この両立が、マニュアル運用の肝になります。

結論から言えば、押さえるべきは3点だけです。「誰がどの操作をできるか（権限）」「どこまで外に出すか（共有・公開リンク）」「データはどこに、どう保存されるか（データの扱い）」。この3つを役割と運用ルールで固めておけば、マニュアルは安心して広げられます。逆に、ここが曖昧なまま「とりあえず共有」を続けると、後述する事故パターンに足をすくわれます。

以下、それぞれをFlowbaseの実機能とあわせて整理していきます。最後に、よくある事故パターンと退職者対応のシナリオ、FAQも置きました。

共有のしやすさと、見せない相手に見せない統制。この両立は、「権限・共有範囲・データの扱い」の3点を、役割と運用ルールで固めることで実現できます。

1. 役割ベースの権限管理（RBAC）

Flowbaseでは、マニュアルやフォルダに対して「閲覧だけ」「編集も可」といった権限を役割ごとに設定できます。これは役割ベースのアクセス制御（RBAC: Role-Based Access Control）と呼ばれる考え方で、「誰がどの操作をできるか」を個人単位ではなく役割でまとめて管理します。

なぜ個人単位ではなく役割なのでしょうか。個人ごとに権限を付けていくと、人数が増えるほど設定が複雑になり、「この人にはなぜこの権限があるのか」を誰も説明できない状態に陥りやすくなります。役割に紐づけておけば、「営業は閲覧のみ」「マネージャーは編集可」のように、設定の理由が役割そのものに表れます。新メンバーが入ったときも、組織・メンバー管理の役割を割り当てるだけで適切な範囲が決まります。

最小権限の原則

権限を考えるときの基本は、必要な人に、必要な範囲だけ渡すことです。これは「最小権限の原則（principle of least privilege）」として、情報セキュリティ全般で広く推奨されている考え方です。「念のため広めに」ではなく「必要な分だけ」を初期設定にします。足りなければ後から足せばよく、広すぎる権限は誰も気づかないまま放置されやすいものです。

実務では、次の観点で整理すると考えやすくなります。

フォルダを業務単位（部署・プロジェクト・公開可否）で切り、その単位で役割に権限を割り当てると、見せる範囲が視覚的に管理できます。権限を「とりあえず広く」付けると、退職者や異動者のアクセスが残ったり、想定外の相手に内容が見えたりします。範囲を絞っておくほど、こうしたリスクは小さくなります。

2. 共有・公開リンクの扱い

マニュアルは、チームに渡してこそ価値が出ます。Flowbaseの共有機能には、渡し方が大きく2系統あります。社内のメンバーに役割で権限を割り当てる「社内共有」と、ログインなしでも見られる「公開リンク」です。この2つは見える相手も、向く用途も、抱えるリスクも違います。混同すると事故のもとになるので、まず違いを並べておきます。

社内共有 vs 公開リンク

公開リンクは便利な反面、URLを知っていれば見られる状態になりえます。受け取った相手がリンクを転送すれば、その先まで内容が届きます。だからこそ、何を社内限定にして、何を公開リンクで出すかの線引きを、運用ルールとして決めておきたいところです。

• 社外に渡すリンクには、社内固有の情報や個人情報を含めません
• 公開リンクで出す前に、スクリーンショットに社内システムの画面・氏名・取引先名が写り込んでいないか確認します
• 「誰に・いつ渡したか」を、チーム内で把握できる状態にしておきます
• 不要になった共有は放置せず、定期的に見直して無効化します

共有のしやすさと、見せない相手に見せない統制。この2つを天秤にかけながら設定するのが現実的です。迷ったら「これがそのまま外部に転送されても困らないか」を基準にすると、判断しやすくなります。

3. データの取り扱い

業務データをどう扱うかは、導入判断を左右します。コンプライアンス・内部統制の観点でも、最低限、次の点は確認しておきたいところです。

• 保存時・通信時のデータが暗号化されているか
• 顧客データなどの業務データが、本人の許可なく外部に共有されないか
• ISO/IEC 27001（ISMS）のような、情報セキュリティ管理の枠組みの考え方に沿った運用ができているか

ここで正直に書いておきます。ISO/IEC 27001 や最小権限の原則は、業界で広く参照される一般的な考え方であって、Flowbaseが特定の認証を取得していることを意味するものではありません。「標準的な考え方に沿って設計している」ことと「第三者認証を取得している」ことは別物です。導入を検討する際は、ベンダーの説明を鵜呑みにせず、自社の基準に照らして要件を一つずつ確認するのがよいでしょう。

よくある事故パターンと予防策

権限と共有は、設定した瞬間ではなく「運用が続く中」で崩れます。代表的な3つのパターンと、その予防策を挙げます。

1. 公開リンクのURL流出

社外に渡した公開リンクが、受け取った相手から別の相手へ転送されることがあります。あるいは、チャットツールや資料に貼られたまま残り、想定外の範囲に届くこともあります。URLを知っていれば見られる以上、「渡した相手だけが見る」という前提は崩れえます。

予防策: 公開リンクには機微情報を含めません。配布先を記録しておき、役目を終えたリンクは無効化します。機微なものは公開リンクではなく、社内共有（権限割り当て）で渡します。

2. 退職者・異動者の権限残存

人は入るときには権限を付けますが、抜けるときに外し忘れます。退職・異動した人のアクセスが残ったまま、ということが起きやすいものです。本人に悪意がなくても、アカウントが残っていること自体がリスクになります。

予防策: 退職・異動の手続きに「Flowbaseの権限を外す」を組み込みます。人事イベントと権限の見直しを連動させます（次節のシナリオ参照）。

3. 公開リンクの放置

一度作った公開リンクを、用が済んでも消さずに放置してしまうことがあります。時間が経つほど「これは何のために、誰に渡したリンクなのか」が分からなくなり、棚卸しもできなくなります。

予防策: 公開リンクは作りっぱなしにせず、定期的に一覧を見直します。「いつ・誰に・何のために」をチームで把握できる形にしておき、不要なものは無効化します。

たとえば、退職者が出たとき

権限の棚卸しは、人事イベントに合わせて回すと漏れにくくなります。たとえば、あるメンバーが退職するケースを考えてみます。

1. 退職が決まった時点で対象を洗い出す。その人がどの役割に属し、どのフォルダ・マニュアルにアクセスできるかを確認します。役割で管理していれば、「この役割を持っていた」という一点から見える範囲が一覧できます。
2. 編集権限と公開リンクを優先して確認する。閲覧より影響が大きいのは編集権限です。あわせて、その人が作成・配布した公開リンクが残っていないかも見ておきます。
3. アクセスを外す。役割からメンバーを外す、もしくは個別に付与した権限を取り消します。退職日に合わせて確実に実施します。
4. 手続きに組み込んで再発を防ぐ。この一連の流れを退職時チェックリストの一項目として固定します。担当者の記憶に頼らず、手順として残すことで、次の退職者でも同じ品質で回ります。

ここで効いてくるのが、最初に役割で権限を整理しておくことです。個人単位でバラバラに付与していると、何を外せばいいのかを一つずつ追う必要があります。役割で束ねてあれば、確認も取り消しもまとめて済みます。

よくある質問

---

マニュアルは、共有して使われて初めて意味を持ちます。だからこそ、見せる範囲を役割で管理し、社内外のリンクを使い分け、データの扱いを把握しておくこと。そして、設定して終わりにせず、人事イベントに合わせて棚卸しを回すこと。この土台があれば、安心して社内にナレッジ共有を広げられます。