情報共有の仕方、粒度を考える
情シス的なものになってから、社内での情報共有が課題となりました。
約2年それに取り組みながら考えて来たこと、やって来たことをまとめます。
情報の粒度を考える
情シス部門は情報発信をする機会が多くあります。サポートデスクとして、今後の施策の浸透のため、上位部門への説明、時には説得のため、多くの発信をしていくことが課題です。
そんな時、どのように伝えるか、あるいは伝えたいことが適切かどうか、まず見極めることができないと発信先と噛み合わず無駄なコストと疲労感・徒労感が生じます。
情シス的なことを始めてから、この粒度や、私憤に近い私のお気持ちの切り分けがしばらくできず、だいぶ疲弊しました。
あちこちにぶつかってすり減りながら、今いま考えていることをまとめます。
ユーザ、受信側に必要なこと
情シス部門と実際のユーザ＝社員が必要とする情報には粒度の差があります。
情シス部門は網羅的な情報が必要としますが、ユーザは個別具体的な情報を求めています。またその情報がユーザの理解・技能の範囲に収まっていないと、ユーザは簡単に情報をリジェクトします。
例えばメールの送受信サーバが変更になった際、情シス部門は技術背景や仕組みの情報を求めますが、ユーザはメーラの設定変更方法さえ分かれば構いません。
ユーザが分からないこと、分かる必要を感じていないこと以外はノイズとなり、ユーザの業務進捗の障害となりますし、気持ち的にも「分からねーよ」と手放してしまいます。
単に設定の情報であれば、情シス部門は変更のあったサーバアドレスとポート番号さえ掴んでいれば構いません。でもユーザはメーラの設定を変えるために必要な手順が分からず路頭に迷います。ユーザの身の丈にあった落とし方を考えないと、情報発信自体が無駄になります。
踏み込んで、ユーザやユーザ部門の長には理解しておいて欲しいこともあります。なぜそれが必要なのか、手順だけでなく理由、理屈を理解して頂かないと届かない、そして必要な情報があります。
例えばファイルサーバの権限設定などは、ユーザには細かな理解を求めることは酷かもしれません。しかし管理職には理解しておいてもらわないと、ユーザの振り分け指示が出来ません。
またIDやパスワードの扱いについては、面倒でも最低限全てのユーザ・社員に知っていてほしいことです。
情シス部門はユーザに対して明確に伝えるべきことをまず把握して、粒度を測って下ろす必要があります。また、段階的に下ろしていくためのある程度の計画も必要になります（今は都度都度の必要性に応じて対応していますが、もう少しきちんとしなければいけないと感じている部分です。
さてそうなると、発信側には社業の基礎知識が必要となります。各部門が何をしているか、それに対してどのような情報を発信すべきなのか。またユーザのレベルの把握も必須です。言葉で通じるのか、図解しないと通じないのか。勉強会を開く必要があるのか、などなど。
こうした情報の重みと粒度の判定を誤るとミスマッチが発生し、結果的に不要なコストが発生して情シス部門は疲弊します。
なんで分かってくれないんだというのは情理ですが、理解してもらうための技術を身につけ、道理に適った伝達を行う必要が情シス部門にはあると考えています。
なんというか、日本を関する企業さんのマニュアルなどのオレオレっぷりを見ると、ああ俺もこうなっているかなと反省をします。相手が分かっていないことを、分かりやすく適切に伝えることの難しさ！ 初期Appleのマニュアルのようなものを、いずれ作ることができるようになりたい。
適切な情報発信のために心がけていること
まずつい忘れがちなユーザの立場を大切にするよう意識しています。
- ユーザの業務を知る
- ユーザの技能レベルを知る
- ユーザに必要な知識、技能を把握・設定し、適切な情報発信方法を考える
そしてもちろん（私は特に初心者ですので）、自分が分かっていることが重要です。自分が分からないことを発信しようとしても碌な結果になりません。
- 発信する内容を学び、熟知する
- ユーザのレベルに合わせて噛み砕く
- 必要であれば図示を心がける（スクショも多用します）
発信することは同時に自分の理解を深める最短の道なのかもしれません。
情報発信の仕組みを作る
色々書きましたが、情報発信の仕組みについては悩みながら整備しているところです。
＊ここからは汎用的な話ではなく、当社環境に沿った話になります。
情報発信に使えるツールは様々あり、それぞれに特徴があります。例えば当社では次のようなツール・サービスがあります。
- 社内ポータルサイト
- メール
- Slack
- 部署Wiki
- 社内IT情報ポータル
当社の場合はPCを利用しない部門があり、これらのツール・サービスのどれも、社員全員には行き渡っていません。ですので情報発信の際は各部門の部門長への根回し・依頼が必要になります。
情報発信の際に行なっていること
前提としてSlackの導入を推し進めています。せめて全管理職に行き渡らせたいのですが、まだまだ理解をしていただけず、また拒否感も強く（ツールが増えると煩雑になる、言質を残したくないなど）、道半ばです。
さて、私の部署から情報発信をする際は、おおよそ次の順で下ろしていきます。
- 部署Wiki作成
- 必要に応じ社内IT情報ポータルに展開
- 社内ポータルへ展開
- 記事の直接掲載
- 社内IT情報ポータルへの案内
- Slack展開
- 記事とポータルのURL掲載
- 必要な場合はMLで全管理職へ展開
＊ただし、ネットワーク障害等緊急時はこの限りでありません。緊急案件についてはまず対応し、後から報告書として情報共有をします。
部署Wiki
一番粒度が細かく、部署業務の継承を目的として書いています。
ここに書かれなかったことは業務として無かったことになるという緊張感があります。特に私はひとり情シスですので、サボると暗黙知として情報の私秘化を進めることになってしまい、会社にとって不利益となります。
残念ながら100％出来ているかというとそんなことはないのですが、重要度に応じてまず記事化を心がけています。
社内ポータル
社内ポータルの掲示板に記載されたことは全管理者必読というルールがあり、ITツール・サービスに接続していない社員にも情報が下りる前提になっています。ここを優先して情報発信をします。
掲示板がプアなので、長い記事には向かず、また、ストック用途にも向きません。長い解説や繰り返し利用する記事は、自分で立ち上げた社内ITポータル（WordPress運用）に掲載し、概要とURLを掲載する形で下ろします。
Slackとメール
社内ポータルに記載した記事は即時Slackへ展開します。前述のようにアカウントを持っているユーザがまだ少ない状態ですが、プッシュ配信できるのはSlackに限られます。メールは時間差がありますのでよほどのことでないと使いません。
メールを使う場合は全管理職向けのMLで念押しをしたい場合です。一般ユーザに不要な情報や公開できない情報を補って情報拡散を促します。
今後まとめていきたいこと
部署Wiki、社内ポータル、社内ITポータル、Slack、メール（最悪電話）という多段構成は私にとって負担が大きく、この軽減を狙っています。
社内ポータルは当初、昼食の予約！が目的で導入された経緯があり、サービスとして様々な機能を持っていますが使いこなされていません（例えばPMS関連の文書・仕様が蓄えられていますが、PK00のような文書名でしか登録されておらず、ユーザにとっては全く分からない状態になっています）。
Wiki掲載の記事を含めて、できれば一つのサービス内でユーザ権限を分けて管理できるようにしたいと考えています。ポストからのSlack連携ができると実に気持ちがいいのですが、利用の練度・予算都合で、いつ実現できるかは全く予測ができない状況です。
まずはWordPressをもう少しセキュアで使いやすいものに置き換え、ゆくゆくはGWSの導入、連携までいきたいと今いまは検討しています。
まとめ？
情報発信の仕方、情報の粒度の考え方などについてだらだら書いて来ました。おそらく各社さんで苦労が多い部分と考えています。Zennで記事にするときは、自分の考えをまず吐き出すことを意識してあまりコンパクトにしていませんが、コードを書くときのように文書をシンプルで分かりやすくする（それ以前に図示を多様する）ことも課題です。いずれそれについても書いてみたいと考えています。
Discussion