![見出し画像](https://assets.st-note.com/production/uploads/images/123373860/rectangle_large_type_2_b92ea0ba93ff36f3a31b79c421937071.png?width=1200)
【覚えたい情報伝達tips 1選】その情報、場所はstock型かflow型か
本記事は【初心者優先枠】corp-engr 情シスSlack(コーポレートエンジニア x 情シス)#2 Advent Calendar 2023の2日目の記事です。
※中盤にまとめスライドあるよ
情シス自体2年もやってないペーペーですが、自分のフレームワークをoutputしてみようと思い参加してみました。
今回は、社内の情報伝達tips、ナレッジマネジメント風なもののテクノロジー観点で1つの考え方をお伝えできればと思います!
対象読者
”いくら伝えても見てくれない、対応してくれない” に心当たりある方
”どこにどんな情報あるかわからない”の声を聞いたコーポレートITの方
ストレージサービスを検討している方
情シスSlackご参加のみなさん(いつもありがとうございます)
社内情報伝達において何が問題なのか
端的に言うと、「情報の性質、伝達の目的と情報を置く場所(プラットフォーム)のミスマッチにより、情報伝達の非効率が存在している」です
前提
この記事はあくまでもコーポレートIT担当者目線で、情報伝達が上手くいくためにどのような考え方ができるか、ITアーキテクチャをどうマネージするかに貢献する目的で記載しています。
なお、ここでの”場所"(プラットフォーム)はストレージサービスやコーポレートサイト、チャット等含めた情報を置く場所を指しています。
※いい表現があれば変えたい。。
ミスマッチあるある(情報伝達の非効率)
「ここなら全員見るだろう」と思ったが最後、Slack等チャットの全社案内チャネルで、いろんな情報流れすぎて見てもらえていない
社内アンケートや事務手続き(税関連等)のタスクをリマインドしてもやってくれない
いざ社内の規定関連を探そうとしたらどこにあるかわからない
チャットやストレージ、ナレッジシェアのサービスが増えすぎてどこに何があるか整理できていない
あんまり取り沙汰されない課題感な気がしますが、些細な非効率が積み重なっている可能性があります。
情報に関しては全社員、委託先等が関係するため意外と影響範囲が大きいのです。年月をかけた問題は徐々に小さくしていきましょう。
コーポレートITインフラをいい方向へ舵取りをできるよう1つの考え方を共有します。
その情報/場所はstock型かflow型か
考え方とは、「stock型、flow型」です。情報管理にも適用してみましょう。
![](https://assets.st-note.com/img/1701521829463-n2A5Pgu8n1.png?width=1200)
情報とそれが提供される場所は、”情報がいつまで有用なものか”(情報の効力持続期間)によってstock型(期間が長い)とflow型(期間が短い)に分かれる。とも言えます。
情報と場所の組み合わせを意識したいところですね。
例えば、stock型情報には、社内規定や経費精算マニュアルなど「定常的に利用する資料」が含まれます。また、社内アンケートなど「一定期間記憶に留めてほしい/アクションまで起こしてほしい情報」もstock型にしてみました。
※stock型の場所は基本stock型情報用です。(進次郎文学)
一方flow型情報は、チャットでの雑談やブレストから全社会議の案内やプレスリリースの共有等「定期的または一時的に発生するイベントの情報」を例に挙げています。システムメンテの案内もflow型です。
flow型の場所は、slack等チャットツールが代表的です。場所がstock型かflow型かは使い手によるのでプラットフォームとしてはhybrid利用で、中のチャネルでstock/flow情報を分けるでも良いと思います。
何かのリマインドなどstock型の情報をたまに置くのにも有効です。
公開情報〜社外秘までの重要度/機密性や業務委託先やお客様とのデータ共有といった状況によってどの場所を使うかも変わってくるのであくまで考え方の1つに。個人的には権限設定がキーなのかなと思ってます。
おわりに
今後はshare(共有)かaction required(要対応)で分けられる
stock型とかflow型とか申しましたが、昨今のAI利用によって境界線が無くなりつつあるように思います。
「データレイク、DWHに対して検索すればOK」そんな感じ
極端な話全部社内規定もPJファイルもslackで管理的な。
ただ、場所については「(検索含めて)情報を見るだけのもの」(share)と「アクションが必要なもの」 (action required) で分ける必要性が残るかなと思います。
とはいえ サービス自体は分けなくてもいいかもしれませんし、validationのようにアクションが求められる時だけ通知やpopupが出てくれば十分なので情報の置き方(出方?UI?)はこれからもまだ変わりそうですね
コーポレートITは”仕事のUXを変える仕事”
トピックとはずれますが、個人的には今後求められる情シスの役割は「コーポレートITアーキテクト」という表現が似合うなと感じてます。長いけど。
Corporate IT Architect かっこええやん
実際ユーザベースさんとかはそのように呼んでますね。
組織が使うITは、電気・水道・道路のようなまさに"インフラ"となっており、街を作るように、家を作るように全体を俯瞰しながら有機的な構造をマネージしていくことが求められます。
コーポレートITという仕事は、"仕事のUXを変える仕事"であり、テコの原理のように組織に大きなインパクトをもたらす大切な役割を持っていると私は信じています。
たかが名前ですが、大事なラベルです。さぁ盛り上げていきましょう。
そんな感じの戯画猫でした。
ありがとうございました。
続いては【初心者優先枠】corp-engr 情シスSlack(コーポレートエンジニア x 情シス)#2 Advent Calendar 2023の3日目は hayapi🧶 さんの「なぜセキュリティをやるのか」です!
お楽しみに!(いいね❤️をお忘れなく)