情報の『海』で 溺れないための航海術 〜フロー情報とストック情報の正しい使い方〜

1日何分、情報を探していますか？
情報の扱い方を覚えて情報をうまく扱えるようになりましょう。

Transcript

1. 情報の『海』で 溺れないための航海術 〜フロー情報とストック情報の正しい使い方〜 株式会社スマレジ CTO室 わたり
2. 1日何分、情報を探していますか？ 情報は増えているのに、見つからない。
3. フロー情報 流れて消える。 ログとして残っていても、 まとまっておらず最新情報が分かりにくい。 ストック情報 積み重ねて育つ。 後から何度でも取り出せる。 一箇所にまとまっているので 「これより新しい情報がないか」等を 確認する必要がない
4. 　　完全なフロー 　　実はフロー寄り 　　ストック その情報、後から探せますか？ 口頭 Slack(メッセージ) Google MEET 議事録 Slack キャンバス 流れて消えて、後から更新できない 文脈が分断されている(最初こう / 一部変更になって...) 「その瞬間」のためにある 残っているように見えるが検索性が低い 体系化されておらず、どこにあるか忘れ去られる（情報の孤島） 「ストックしたつもり」になりがちな危険地帯 社内Wiki Redmine / backlog 検索性が高く、基本的に複数人で更新できる 新旧混在しておらず「新しい情報」に更新されている URL一つで誰でも同じ情報にたどり着ける
5. デジタルの「SLACKで流したルールを守って」は アナログの「この前オフィスで叫んだルールを守って」と同じ アナログの「このマニュアルに書いてあるよ」と同じなのは デジタルの「このWikiのページにまとまっているよ」
6. 補足: Redmine内の情報の性質
7. 情報がまとまっていれば、 更新してSlack2行で済むし漏れもない 今年も◯◯の時期がきました マニュアルを確認して対応してください その丁寧な告知、 もったいない 関連情報を確認し、 去年Aさんが書いた内容を元に文章を書いて、 いざSlackに投稿！ すると即レス 「去年こうでしたけど今年は違いますか？」 確認すると別チャンネルで質問され訂正が... 忘れてました...orz
8. ケーススタディ 「システム調査・対応ログ」 Scenario： エラー調査や仕様確認。 Bad（フローのみ）： Slackスレッドでログを貼り調査。「原因わかりました、対応します」でクローズ。 → チケットには「対応したため完了」としか残らない。 → 半年後、同じアラート発生。「あれ、これ前どうやったっけ？」とSlackの海へダイブ。 Good（ストック化）： 調査プロセスはSlackでもOK。 結論が出たら： 原因と、調査/対応手順をチケットやWikiに転記する。 → 次回は対応するのが他の人でも「検索」ではなく「参照」で5分で解決。
9. メモをWikiに書く 教えてもらったことを必死でメモし、 久々の対応でもメモをみて完璧に対応！ ...したはずが「あ、先週からこっち使うことになってるから」 手元のメモをアップデートして次はミスらないようにします。 それ、Wikiに書いてWikiを見るようにしませんか？ あなたがメモしたいことは他の人もメモしたい内容のはず。 10人が10個のメモを作るより、 10人で1つのメモを作り上げましょう！ （当然パスワードや秘匿情報は手元等で適切に管理しましょう。）
10. ドキュメントを作る時間がない？ それはドキュメントを作っていないから かもしれません 時間がないからまとめている場合じゃない！ いいえ、おそらくあなたはまとめていないことで同じことを何度も質 問されているはずです。 毎回質問に答えていると毎回あなたの時間を消費します。 これは組織が大きく人が多くなるほど回数が増え時間を削られます。 質問されたとき、もう二度と聞かれることがない内容でないなら まずは作成した回答をストック情報(Wikiなど)に貼り付けましょう。
11. 今日からできる アクション いきなり全部をWiki化するのは大変です。まずはこれだけ。 Wikiを気軽に編集する 手元にメモせずWikiにメモる 同じ事を2回聞かれたり指摘したらストック不足のサイン Slackで共有する前に、Wikiや課題管理に書いて、そのURLを貼る ストック見せても分からず質問になるなら改善チャンス 都度改善で次聞かれることも減って情報整理スキルもアップ 新 人 さ ん が 入 っ た 時 、 Slack の 過 去 ロ グ を 漁 ら せ る の で は な く　　 「ここ（Wiki）を見て」と言える場所を一つ増やす
12. THANK YOU.