社内情報の整理術 〜探求編〜

what-is-information.md

https://gist.github.com/naoya/8570256 を見て思った個人的メモ

データと情報

情報に必要なメンテナンス

• 情報の更新

• 間違いの修正

• merge(特定のタグの統合)

• split(特定のタグの分解)

• コメント

  • メンテの要求, 賛否の表明

• ストック

  • データ属性, 不要な情報が少ない, メンテされにくい(Why?)

• フロー

  • データ属性, そもそもメンテを考えていない,

• ディレクトリ表示

  • view, 階層構造

• タイムライン表示

  • view, 時系列に並ぶ

• タグ

  • 文書の属性, 似たような文書をクラスタリング

• 階層化(親の設定)

  • 似たような文書をカテゴライズ, 複数の親を持つことは出来ない(本当に?)

本当に「階層化」では複数の親を持つことは出来ないのか？

• 例えばgitのでは、「merge」という操作によって「commit」というデータには複数の親が設定される
• この場合の「親」は文書の情報が意味する親と言うよりは、状態の関連
• そういえば「シンボリックリンク」って一見複数の親があるようにも見える。
• GoogleDocumentは...

実際の情報は2種類？

• ストック型
  • 研修テキスト, 仕様
• フロー型
  • 日報

情報は本当に2種類か？

「情報の公開範囲」「知ってもらいたい範囲」によっても分類できないか？

• メンションをしてでも積極的に相手に見てもらいたい文書
  • 議事録
• 自分のためだが誰かが見てもいい
  • 日報
• 不特定な誰かには見られたくない
  • privateモード, 限定共有モード

タグ

日報の割合がおおくてバランス悪い

データ管理はmixinなのでは？

rubyで書くとこんなイメージ

class Tag
  @has_security # true/false
  @access_role # [:staff, :manager, :人事]
end

class 日報 < Tag
  include Searchable
  include Flowable  
end

class サイト仕様 < Tag
  include Searchable
  include Stockable
end


class トラブルの顛末 < Tag
  include Searchable
  include Flowable
  include Stockable
end

class Document
  has_many: tags
end