2017-04-02

日報を読めるのは組織図上の親になります

日報のアクセス権限設定は想像以上にシンプルです

日報はある種のプライバシーに関わる部分もあるため、

  • 「同僚には見せたくない」
  • 「自分の直属の上司にしか見せたくない」

といったリクエストが多く出てきます。確かに自分の書いた日報を、
社内の全員が読めるという状況は、決して望ましいものではないでしょう。

では、作成した日報を「誰が読む権利を有するのか」
企業は大きくなるに連れて、組織図が肥大化し、複雑になりがちです。
nipoは複雑な組織図に「NO」を返します

極限までシンプルなアクセス権限の考え方

nipoでは、アカウントが必ず階層構造を持つように設定されています。
アカウントから子アカウントを作り、子アカウントが孫アカウントを作ります。
よって階層から外れたアカウトは作成できません。

そしてアクセス権については至極シンプルです

「自分が作ったアカウントの日報だけ読める」

これだけです。

具体的な例をもとに、日報のアクセス権を確認しましょう

会社組織をイメージしてみましょう
たとえば以下のような会社組織を考えてみます

日報 アクセス権

日報のアクセス権は組織図をそのまま考えてください

自分の直属の部下が作成した日報は、読むことができます
これを前提に考えると

  • あなたは、【Jarvisの日報】【Adaの日報】【あなたの日報】を読むことができます
  • あなたは、【Nianticの日報】を読むことができません
  • Jarvisは、【Nianticの日報】【Jarvis(つまり自分)の日報】を読むことができます
  • Adaは、【Ada(つまり自分)の日報】を読むことができます
  • JarvisとAdaはお互いの日報を読むことができません
  • Nianticは、【Niantic(つまり自分)の日報】を読むことができます

シンプルな親子関係を駆使して複雑な組織図も簡単に作成できる

nipoの基本的な考えかたに、「不要なデータは見せない」という基本思想があります。
他部署の方が書いた日報はあなたにとっておそらく一切関係のないものです。
同様に、部下の部下が書いた日報も、あなたが把握する必要はありません。
このケースでは、部下が部下の部下を管理すべきであり、あなたは「直属の部下」までを
守備範囲とするべきです(責任範囲の明確化)

この親子関係を駆使して、実際の組織図を更に拡張した構造を作ることも可能です。
例えば社外の営業部署や代理店といった外部の組織も、nipoへ組み込んでreportの提出元として
活用させることができます