会社を"情報の塊"と捉えて、情報アーキ設計とNotionでハックしてみる：ストック情報編
私は現在、150人程度の医療ベンチャー企業で、Notionを用いた情報管理高度化プロジェクトを推進しています。
第一弾として、Wiki風のストック情報を扱うNoitonページを先日公開しました。
この記事では、当時考えたことを紹介していきます。意外と社内情報管理の分野のナレッジは世で少ないと感じていたので、今後どなたかの参考になれば嬉しいです。
※私が所属するセルソースについてはぜひ公式Noteをご覧ください↓
1)情報整理に取り組んだ理由
メンバー増によって連携が難しくなっていた
私の所属するセルソースはここ数年でメンバーが50人程度から150人に増えていました。
少人数チームでしたら「直接話そう」で済んでいたことも、そうはいかなくなっていました。
当時起きていたこと
・発信済みのツールの使い方を、何度もユーザーから質問される
・色々なルートでタスクを依頼されてよく分からない
・自分が作った資料と似た資料を既に作っている人がいた
・他のメンバーが進めている案件の進捗が分からない
複数あるように見える課題を1つの「情報の課題」と捉えた
当初は、「営業資料の利用ルール設定」「経費精算マニュアルの運用設計」
「システムチームへのタスク依頼の仕方決定」など"各個撃破"を試みました。
この方法は、クイックに進められそうです。
一方で、テーマの数だけルールが生まれることにもなります。
つまり、メンバーは「この件は〇〇、あの件は△△で、、」と何パターンも覚えてもらうことになります。
これは良くないと考えました。仮に現状が整理できたとしても、今後もメンバーが増加した場合、連携すべきテーマも増えると予想されます。
その増えたテーマごとにルールを設定すれば、どんどん複雑になり、また連携が難しくなる構図が繰り返されそうです。
ここで発想の転換をしました。全ての問題を「情報の課題」だと捉えることにしたのです。
マニュアルも、タスクも資料も究極的には「情報」であり、「情報がうまく共有できていない」という課題と言えると考えました。
情報共有の汎用的な考え方を確立できれば、今後増えるテーマにも適用できるので、メンバーは汎用的な考え方だけを覚えれば良くなります。
"会社って情報の塊なのでは"という発想
更に踏み込むと、究極的には社内のあらゆることは「情報」であり、業務のほとんども「情報の共有」と言えると考えました。
会社での出来事=情報共有
・会社の方針(情報)を、メンバーに伝える(共有する)
・対応してほしいタスク(情報)を、依頼する(共有する)
・お客様にサービス(情報)を、説明する(共有する)
・今日実施した作業内容(情報)を、記録する(共有する)
こう見ると「情報の扱いがうまいチーム」は強いチームだと言い換えられないでしょうか。
「情報共有の高度化」は、メンバーがポテンシャルを発揮し、当社が社会にインパクトを与えていくことに繋がると確信し、力を入れることとしました。
2)「社内の全ての情報がスコープ」の状態からどう進めたか
3つのステップに分割
実行にあたっては大きく3ステップに分けることとしました。
実行ステップ
①全社向けのストック情報 ：社内ルール、制度など
②フロー情報 ：タスク、プロジェクト、目標管理など
③特定層に向けたストック情報 ：部内マニュアル、ナレッジ など
「あれ？結局分けるの？」と思われたかもしれませんが、意図があります。
広いスコープを一度に進めれば、その分ユーザーとなる社内メンバーは新しい要素を一度に受け入れる必要がありますが、これは負担が大きいです。重要度と受け入れやすさで順番を考えました。
また、各ステップは完全には独立させません。全体を通して一貫した設計思想で取り組むこととしています。
全領域の設計を私が実施することで、ルールの一貫性を担保しています。(ジョジョは各部独立していても、人間賛歌がテーマなのはブレないのと同じようなイメージです)
質を十分追求できるペースで進めた
当時は冒頭で紹介した問題が発生していた一方で、現場メンバーの努力もあり、致命的な状態ではありませんでした。
この状況下では「とりあえず動くもの」よりも、「切り替える価値が確実にあるもの」を生み出す必要がありました。
そのため、質も十分に追及できるスピード感でプロジェクトを進めました。
更に、ある程度PJチーム内での概念検証が済んだら、ユーザーにもベータ版的に使ってもらい、改善をしたのちに本稼働をする、という2段階でのリリースを採用しています。
実際のスケジュール
• 2022年9月 ：初期検討を開始
• 2022年11月 ：①②③のステップ設計
• 2023年4月 :①「ストック情報管理」ベータ版リリース
• 2023年8月 ：①の本稼働＆②「フロー情報管理」③「ナレッジ管理」のベータ版リリース
• 2023年中：②③の本稼働
Notionの採用
プラットフォームにはNotionを採用しました。選定理由や使い方については、長くなるのでまた次の記事で詳しく紹介できればと思います。
3)全社向けストック情報の取り組み
作成したのはWiki風の社内向けWebサイトです。
対象は「全社員が参照する情報」としており、社規則、各種申請ルール、システムの使い方、人事制度の解説、事業の解説などを対象としています。
ややフロー寄りですが全社向けのお知らせも掲載できる掲示板のような機能も併せて提供しています。
散らかしたくなんかないけれど、散らかっていた。
実は当時も社内Wikiは存在していたのですが、Wiki、Google Drive、Slack、PCのローカルストレージ(！）など情報が散在していました。
この散在の原因の解消に取り組もうとしました。
考えてみると「情報を散らばせようと思って、散らばらせている人」なんて存在しないはずです。
私だって今この記事を書くのに使っているデスクは、なぜか散らかっていますが、散らかそうとは思っていないのです。
当たり前のようですが、これは重要なポイントです。単に新しい情報置き場を作っても、うまくいかない可能性が高いからです。
「情報の置き場の決め方」を決める
情報を置く人の気持ちになって、「情報を置く場所の選び方」を考えてみましょう。
「自分が簡単に使える場所に置いた」か「関係のない人の迷惑にならない場所に置いた」の2パターンが多いのではないでしょうか。
こうして選ぶ情報の置き場が、人やテーマによってばらばらになっているため、情報が散在していると考えてよさそうです。
まとめると「情報をどこに配置するかを、発信者が都度異なる判断軸で決めている」ということが原因だと言えます。
解決のために「情報をどこに置くかを判断する原則」、いわゆる「情報アーキテクチャ」を定めようと考えました。
4)情報アーキテクチャの設計
「情報アーキテクチャ」とは簡単に言うと、情報の置かれ方です。
Webサイト構築をされたことがある方には親しみのある言葉かもしれません。
「 情報アーキテクチャ」はUXやUIを規定する役割をすると言われており、まだまだメジャーでないながら重要な概念です。
家でいうところの、間取りの役割です。間取りが各部屋のレイアウト(UI)を規定して、住み心地(UX)に影響する関係性ですね。
【基礎から分かる】IA（情報アーキテクチャ）とは？基本からサイト設計時の利用法までやさしく解説
Wikiを作る上では大きく①ページの階層構造と②各ページUIの検討に要素が分かれました。
①ページ階層構造の検討
「ページの階層構造」とは、ページをツリーのように配置する際の並べ方のことを指しています。パソコンのフォルダ構造のイメージが近いです。
以下の3ステップで取り組みました。
①-1.ツリーの深さルールの設計
Wikiの中でツリーがいくつかできることとなります。このとき、分岐の仕方や階層の深さがツリーによって違うと、迷子になりやすいです。ゲームのダンジョンのようです。
どこのツリーを見ても、ある程度の作りを同じにする必要があります。
階層の深さと縦横の関係性をそろえれば、ユーザーは「上の階層行けばこうなるのかな」「横に行くとこうなるな」という“土地勘”を持ってもらえます。
色々なパターンを考えてみて、以下に決定しました。
決めたツリーの分岐と深さのルール
• 基本的に本棚、本、章 の関係性の3階層にする
• 実際に情報を持つ(文章が書かれる)のは、3階層目の「章」の部分
• 情報を追加したい際は、4階層目を作るのではなく、3階層目を横に増やす
• 章の内容をまとめると本になり、本の内容をまとめると本棚になる関係性にする (関係のない情報なら、別のツリーに載せるようにする)
①-2. 載せる情報の洗い出し
Wikiに載せたい情報を洗い出します。今社内で共有されている情報だけでなく、今後共有されるべきであろう情報もピックアップすることがポイントです。
ここは私の上司でＨＲ分野も担当している経営企画本部長とブレストのように挙げていきました。
結果、「どうしても隠さなくてはならない情報以外は載せよう」というポリシーでインサイダー情報や個人情報以外は考え付く限り載せることとしました。
この方針は当社が「オープンさ」を重視する故に定まったものだと感じており、組織の目指す方向性によって変わると思います。
①-3. 実際の階層構造の定義
2で洗い出した情報を、1のルールに基づいて、「このテーマはこういう階層」のように、階層構造に当てはめていきます。
このパートのコツは「頑張って絞り出す」ということに尽きるかなと思います。
「階層を考えてみて、当てはまりが良いかを評価して、また改善する」というサイクルを繰り返します。「当てはまりの良さ」は以下を基準としました。
階層構造の良さの判断基準
• ①で決めた階層ルールを守れているか (特に下の階層のまとめが、上の階層を表すか)
• 載せたい情報が増えた際に、対応できるようになっているか
考え方はデータモデリング(≒データベース設計)に似ているかなと感じています。
前職のITコンサル時代の師匠が言っていた「“良いモデルを作る方法”は存在しないから、苦しみながら何度も書いていくしかないんだよ」という言葉を噛みしめながら取り組みました。
全階層は膨大なのでお見せできませんが、一番上の本棚の階層はこのようになりました。総ページ数は全階層合わせて300ページほどでした。多いですが何とかやり切れない量ではなかったです。
②UIの検討
次に各ページの標準UIも定めました。
「見栄えを良くする」というよりも、「各ページで情報の記載のされ方を同じにする」という点を重視して設計しています。
ページによって載っている情報や、場所がばらついて、読み手にストレスがかかることを避ける意図です。
UI検討は当社に所属するWebデザイナーが担当をしてくれました。必ず載せる情報の定義と、使う書式とその意味、画像の載せ方などを定義してもらいました。
③Notionでの実装：タイミングよくWiki機能が爆誕
ちょうどこの作業をしていた2023年3月頃にNotionのWiki機能が公開されました。
Notionでの実装については別途記事を書こうと思っています。
これから
こうした作成したNotionによるWikiは4月からベータ版として運用を始めています。
3か月運用をしてみて見えてきた改善点を反映させて、8月から本稼働とする予定です。改善の中では紹介したツリー構造の見直しも含んでいます、大変でした笑
「情報共有の高度化」という取り組みの全体においてはまだ始まったばかりなので、まだまだ頑張っていこうと思います。
最後まで読んでくださりありがとうございました！
参考にした本
「情報管理の価値」について考える際に参考にした本
失敗の本質―日本軍の組織論的研究 野中 郁次郎ら
サイロ・エフェクト 高度専門化社会の罠 Gillian Tett
情報アーキテクチャを作る際に参考にした本
情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計 Louis Rosenfeldら(オライリー)
考える技術・書く技術―問題解決力を伸ばすピラミッド原則 Barbara Minto
この記事が気に入ったらサポートをしてみませんか？