2023/01/25(水) にオンラインで開催された下記イベントでの登壇スライド資料です。
Notionを企業で導入する方法〜セキュリティや移行ノウハウも伝授〜 https://info.nextmode.co.jp/20230125_notion-seminar
2023/01/25(水) 15:00 - 16:00 今話題のNotionを企業で導入する方法 ～セキュリティや移行ノウハウも伝授！～ Confluenceから Notionへの 全社移行事例
View Slide
2アジェンダ・企業紹介 ・自己紹介 ・ConfluenceからNotionへの全面データ移行 概要 ・移行作業を終えての振り返り各種 ・情報設計 ・データ移行 ・運用
3企業紹介クラスメソッド株式会社 https://classmethod.jp 創立：2004年07月07日 現在19期目 従業員数：約700名(グループ企業含む、2022年末現在) 2022年：AWS Partner Awards SI Partner of the Year 受賞 業種・規模問わず3,000社以上の支援実績 主なサービス： ・AWS総合支援 ・LINEサービス総合支援 ・内製化支援 ・SaaS導入コンサルティング ・データ分析環境構築支援 ・アプリケーション開発
4ブログ紹介クラスメソッドオウンドメディアブログ「DevelopersIO」 https://dev.classmethod.jp/ ・累計投稿本数： そろそろ40000本 ・Notionに関するブログ： 142本 (※2023年01月25日現在)
5自己紹介しんや@shinyaa31 クラスメソッド株式会社・2013年08月：ジョイン(中途入社) - AWSコンサルティング部(現在のAWS事業本部の前身) ・2016年07月：データインテグレーション部に異動 ・2019年07月：データアナリティクス事業本部に異動 ・自社ブログ「DevelopersIO」にて年間100本投稿(以上)記録を継続中(現在10年連続) ・各種情報発信、情報連携促進 ・Notion Champions Community参加 https://dev.classmethod.jp/author/shinyaa31/
6ConfluenceからNotionへの全面データ移行：これまで＜移行の背景＞ ・会社規模(社員数・ビジネス双方)の急速な拡大に伴うナレッジ共有に対する不満 ・過去の経緯や業務に必要な情報を「個人の情報」から「組織の情報」へ ・Confluenceのドキュメント利活用におけるばらつきがあった ・”全社利用ツールはルールをあまり決めずに始まる”という文化的な側面 ・ストック情報とフロー情報の区分けが不十分 ・全社公開レベルで無くてもいい情報が全社公開に ・ドキュメントの検索精度低下問題 ＜Notion選定の理由＞ ・移行検討の段階で既に複数の部門で個別に採用がされていた ・個人利用で使っている人もいた ・社内Slackで情報共有用のチャンネルが立ち上がっていた
7ConfluenceからNotionへの全面データ移行：完了までの流れ＜スケジュール概略＞ ・2022年01月：契約対応 ・2022年01月：各種設計開始 ・2022年03月：サンドボックス環境期間(〜2022年06月) ・2022年04月：設計のブラッシュアップ作業 ・2022年04月：本番環境の作成＆Confluenceからの移行作業開始 ・2022年07月：本番環境運用開始 〜随時発生した課題やタスクについて対応〜 ・2022年12月：Confluence契約終了
8前回のイベントはこちら：Notionのはじめかた。ーDX時代のあたらしい働き方をNotionで実現する 社内ポータルとしての活用事例、Confluenceからの移行事例も解説 - マジセミ×業務自動化・効率化（デジタルとの新たな出会いと体験） | Doorkeeper https://majisemi-business.doorkeeper.jp/events/134715
9色々振り返る点がありました...
10移行に関わったメンバーから振り返り情報を収集大きく以下の分類の情報が集まった ・情報設計 ・データ移行 ・運用 ※社内タスクフォースメンバーの皆さん、ご協力ありがとうございます！
11情報設計
12情報設計に関する振り返りやっておいて良かった全体向けトップページの構成・デザインについて、 予めデザイナーと詰めていた ページ構成を考える際にあらかじめ社内のデザイナーに 相談したことで、文字色や背景色の色遣いやバランス、 目にとまるアイコン提案などしてもらい、より見やすくなった。
13情報設計に関する振り返りやっておくべきだった組織毎の「トップページの統一」を 全社横断的にしておくべきだった 部署ごとにトップページの作りや並び、粒度がバラバラだと 他の部署の情報を探すときに別会社の情報を探す… みたいな状態になってしまう。 (難しいとは思うが、)各部署ごとにざっくりレイアウトや粒度を合わせておくとわかりやすかったかもしれない。
14今回の移行では大きく2つのワークスペースを設けました全社・公式情報用ワークスペース 各事業本部・組織用ワークスペース AAA事業本部BBB事業本部CCC事業本部XXXチーム：：全社お知らせ組織に関する情報組織に関する情報組織に関する情報総務に関する情報その他全社関連情報：：：：「全社用」のデザインを統一する形で進められた各種組織で移行作業を同時並行遂行していたため、組織横断でのデザイン統一は難しかった
15組織単位で情報レイアウトが異なると目的のページを探すのが大変...※幾つかの組織トップページレイアウトをピックアップ。 今回の移行ではこの部分の統制は特に行わなかったので このようにレイアウトがバラバラになっている。
16[提案] 組織単位で複製して使える情報レイアウトテンプレートを用意「Notionのテンプレート」に関する情報は以下を参照。ただ上記の構成は Notionの機能として取ることは出来ないので「雛型ページを用意しておき、複製する」形がスムーズ。 ・Notionで活用出来る「テンプレート」のまとめ | DevelopersIO https://dev.classmethod.jp/articles/notion-templates-variation/ ・ピックアップ – テンプレートギャラリー https://www.notion.so/ja-jp/templates[事業本部テンプレート ][部署テンプレート][チームテンプレート]組織の形に応じた「テンプレートページ」を用意しておき、組織新設や移行開始の際に活用出来るようにしておくと統制が取りやすい(形になると思う)。[XX事業本部][部署テンプレート] [YY部][AAチーム][BBチーム]
17情報設計に関する振り返りやっておくべきだったNotion移行や運用方法に関する知見を部門ごとに蓄積し、 部門ごとの格差が生まれないように出来ると良かった タスクフォースチームで運用ルールについて定期的に議論していたものの、実態としては部門内での移行体制やリソースの確保状況によって、移行やページ構築に関する情報格差があったと感じた。 細かい部分は部門にお任せでもよいが、ワークスペースのページ構成やトップページのイメージはテンプレートを用意するなど、ざっくりとした全社の共通イメージを作成して全体で進めたほうが、部門によるワークスペースの使い勝手の違いがでなくてよかったのではないかと思っています
18情報設計に関する振り返りやっておくべきだったNotion上での「検索」を考慮した設計が必要だった 運用を考えた場合、あらかじめ検索性を意識して各ページを作るようにレクチャーすべきだったように感じる。 ・DBが乱立していたり、情報がネストしていたりする。 ・(話が違うけれど)権限の違うところに移動して、 戻せなくなるのも困る。。 また、意図しないページが検索結果に出ることへの対応も必要。 部署によっては週報や月報が上位にヒットしてしまって、 知りたい情報にたどり着けない。 ルールがあった方がよかった。 また、検索性を上げることが移行の目的の一つでもあったため、 ここについては、継続して数値化などで利便性を測った方が良いと思う。
19「Notionの検索」に関する参考情報新しくなったNotionの検索機能の挙動を色々確認してみた #notion | DevelopersIOhttps://dev.classmethod.jp/articles/improvement-of-search-in-notion/Slackの検索結果からNotionへ誘導する場合にほしいポイントを挙げてみた | DevelopersIOhttps://dev.classmethod.jp/articles/howto-notion-digest-on-slack/Notion内の検索で除外のフィルタを適用できないかどうか確認してみた | DevelopersIOhttps://dev.classmethod.jp/articles/try-exclude-search-on-notion/
20情報設計に関する振り返りその他Notion上での「アクセス権限」について Notionは割と自由に閲覧・編集ができることがメリットの一つだと 思いますが、いろいろな背景から情シスにアクセス権の設定を かなり頑張って設計していただきました。 その結果、部門間で情報共有したいときに別途申請をするなど 手間が増えたので、運用しながら見直しができるといいなと思っています。 （あるいはNotion側で権限に関するアップデートを期待）
21情報設計に関する振り返りその他情報公開範囲の定義と「プライベートページ」の活用 全ての情報が「全社共有・参照可能」であれば一番シンプルだし 望ましい形の1つだとは思うが、内容や状況によっては 「任意の組織内メンバー限定で参照可能」 なページが欲しい、というケースも出てくると思う。 その場合は任意のページに対してアクセス出来るメンバーを限定する(今回はアクセス可能なグループをページに割り当て、そのグループにメンバーを追加する運用体制を採った)ことで目的は実現出来る。 ※ただこれが乱用されると「情報の共有」という観点でモヤる部分は残る。
22「Notionのアクセス権限」に関する参考情報Notionの共有および権限設定についてのガイド – Notion (ノーション)ヘルプセンターhttps://www.notion.so/ja-jp/help/sharing-and-permissionsNotionの共有設定についてhttps://www.notion.so/ja-jp/help/guides/understanding-notions-sharing-settingsチームスペースやグループへの適切なアクセスレベルの設定https://www.notion.so/ja-jp/help/guides/grant-access-teamspaces
23データ移行
24データ移行に関する振り返りやっておいて良かった情報断捨離をちゃんとやった (移行前／移行後) ConfluenceからNotionへの情報移行を行う際、 Confluenceのコンテンツをそれぞれページ単位で切り分けて「この情報は要るか要らないか」という判断を行った。 ページ単位で切り分けることでそれぞれ担当するメンバーに 『要るor要らない』の判断をお任せすることがスムーズに 出来たし、『要るものだけ持っていく』という考えのもと 進めていくことで移行先環境(Notion)を比較的スッキリさせた 状態で維持出来た。
25「情報断捨離」は大きく分けて2パターン移行前の場所 (Confluence/別のNotion/その他プラットフォーム) 移行後の場所(Notion) (1).移行先のページ構成を設計(2).移行先に持っていくコンテンツだけ選定・引っ越しさせる①.とりあえずまるっと引っ越し②.設計と取捨選択を移行後に実施最初に仕分けるか後で仕分けるか※組織の状況、情報量や移行に掛かる時間、設計内容等に応じて選択。
26データ移行に関する振り返りやっておいて良かったConfluenceのURLとページタイトルの一覧表を 作成しておいた Confluenceをクローズした後、URLのみの記述となっている 場合に中身がわからない可能性が高いため逆引き用途にて作成。 一覧に対して要素追加の要望がしばしば出ていることから 利用されているケースが想定以上にあった模様。
27データ移行に関する振り返りやっておいて良かった「どのコンテンツをどのDBで管理する」かを 移行の際にあらかじめ検討しておいた こうしておくことであとあとの整理もしやすい。 特に議事録など定例テンプレートの置き場として良い。 タグ付けも便利。
28データ移行に関する振り返りやっておいて良かった「添付ファイルのまるごとバックアップ」を取得していた 当初はConfluence各ページの移行担当者が個別に 添付ファイルをダウンロードしてバックアップする想定で いたものの、ページ数と添付ファイル数の乗算で漏れが 発生する可能性は非常に高かった。 バッチにてConfluenceのダウンロード用APIを利用する際、 ついでにディレクトリ構成も再現していたことにより、 Notion上で再添付する時もわかりやすくなってよかった。
29「Confluenceのバックアップ」に関する参考情報Confluence上の文書ツリーをローカルに再現しつつ各ページの添付ファイルをまるっとダウンロードしてみた |DevelopersIOhttps://dev.classmethod.jp/articles/backup-attachments-to-local-from-confluence/Notion断捨離用にConfluenceエクスポートファイル内の最終更新日付を洗い出してみた | DevelopersIOhttps://dev.classmethod.jp/articles/parse-last-modified-date-from-confluence-export-zip/
30データ移行に関する振り返りやっておいて良かったConfluenceのエクスポートデータから 作成日付や作成者の情報を抽出していた ConfluenceからエクスポートしたデータをNotionに 取り込んだ際、全てのデータが取り込んだ時刻に作成された 扱いになっており、古い資料なのか見分けがつかなくなった。 Confluenceのエクスポートデータ内には、作成日付・作成者・最終更新日時・最終更新者名が残っていたため、スクリプトにてファイル毎のそれらを抽出。後日、今後も更新が必要か否かの判断材料に用いた。
31データ移行に関する振り返りやっておいて良かったConfluenceの利用停止時期を事前に決定しておいた タスクフォースのエンドが決まるので、 明確に期日を定めて＆全社共有をしておくべき。
32データ移行に関する振り返りやっておくべきだったコンフルからNotionに移行するときに タイトルをわかりやすいものに変更しておくべきだった メンバーのNotionにおける検索スキル向上までの時間が思ったより 掛かっていたので、移行するときに「このタイトルわからなくない？」 ってのをちゃんと踏まえた方がよかった。 私でさえアクセスできないときがあり、コンフルに立ち戻った時もあった。 データベースは便利だけれど、ディレクトリ構成に弱いデメリット（主観）を踏まえたファイル構成にするべきだったかもしれない。
33データ移行に関する振り返りやっておくべきだったConfluence上でのサードパーティ製拡張の無効化 Confluenceからのエクスポートに対応していない拡張が幾つかあり、 結果エクスポート時に該当拡張を利用して記述していた文面に 欠損等が発生していた。 ※ConfluenceのMarkdown用サードパーティアドオンで Notion取り込み時にサードパーティによる独自タグが認識されず欠落 欠損が発生していない場合があっても、構成の問題で Notionでのインポート時に正常に取り込まれていなかったりする。
34データ移行に関する振り返りその他移行データについて「作成者」を自分以外にしたかった 移行しただけで担当ではないデータも多数あるため、 後から見返した時に「作成者だから」と問い合わせられて困った。 「管理アカウント」とか指定したユーザー名？でインポート できるような仕組みがあると嬉しかった。 あとは同じ意味で、作成年月日も引き継げるとよかった。
35運用
36運用に関する振り返りやっておいて良かったNotion旗振り役の選定、率先して使ってくれている人に 協力を依頼した 「やっておいて良かった」し「やっておくべき」ポイント。 そもそものNotion利用に際して、個人的に先行して使ってくれている人やそういう意欲のある人をタスクフォースのリーダーや推進役としてアサインしておくと進みが全然変わってくる。 熱意や興味を持ってくれる人の協力は何より心強い。
37運用に関する振り返りやっておいて良かった部門以降だけでなく、観点ごとの中心メンバーの ピックアップ 分け方、アウトプットに対して改善が必要なことは前提として。クラスメソッドの現状の社員数を考えるとノールールで導入してルールを後から作るのは無理があったと思う。使い方をある程度想定して事前に観点ごとに最低限のルールを決めるタスクフォースの立て付けにしたのは良かったかな、と。
38運用に関する振り返りやっておくべきだったNotion利活用における啓蒙活動 移行に際しては組織内に代表者を置くことでそのメンバー駆動である程度のスピード感を以って進めることが出来たが、移行が落ち着いたタイミングでの「活用」フェーズで更にNotionを利活用していくための啓蒙活動が十分に出来ていないと感じる部分があった。 移行とはちょっとズレるが「移行後にやっておくべきこと」として挙げておきたい。
39「Notion チャンピオンズコミュニティ」を合わせて活用しよう！Notionチャンピオンズコミュニティの日本語サポートを開始！https://www.notion.so/ja-jp/blog/notion-champions-japaneseNotionチャンピオンズコミュニティ https://notion.notion.site/Notion-7b970ea69e1c471ba462dc2c166d6670[Notion]Notionチャンピオンズコミュニティに参加してみた | DevelopersIO https://dev.classmethod.jp/articles/joined-notion-champions-community/
40運用に関する振り返りやっておくべきだった事前の工数確保の調整 全社のツール移行プロジェクトになるので、社として 「やるべきこと」に対してベストエフォートは 限界があるなと思った。 期間限定の部署を3〜6ヶ月単位で作るなり、 中心メンバーのある程度の工数確保をした上で 一気に進めた方が良かったと思う。
41運用に関する振り返りやっておくべきだったNotion社とのやりとりの定例化 ホットラインは作っていたが、定期的にやって 状況のウォッチやプッシュをしても良かった。
42運用に関する振り返りやっておくべきだった移行プロジェクト後の運用体制の早期構築 移行時にルールを決めるだけでなく、情報資産としては その後の運用の方が重要なので、早期で体制を決めて 運用開始後にどのように浸透させていくかは 移行プロジェクト時から議論をしておいて良い。
43運用に関する振り返りやっておくべきだった部門横断の運用体制づくり 運用方法やルール決め？などが部門ごとに行われ、 ナレッジ共有や改善活動の旗振りがしづらい （見えづらい？）
44運用に関する振り返りやっておくべきだった細かい機能要件 / 非機能要件の作成 あとからアレがない、コレがないとなったので、先に必要な機能 / 非機能要件を洗い出して先方にぶつけたほうが良かった。
45運用に関する振り返りその他情報の特性(ストック/フロー/テンポラリ)による 扱い方の方針決めについて この部分の方針については幾つか案は出たものの、結局確定したものは 無いまま運用フェーズに雪崩込んでしまった印象がある。 どれが良くてどれが悪いというのも無いと思うが、 全社的に大方針を確定したものが出来ると運用も 幾らかスムーズになるのかな？という気がしなくもない。
46「ストック/テンポラリ/フロー」それぞれをNotionでどう扱うか種類 対象となる情報(例) Notionで扱う？ストックデータ(情報資産)Confluenceやその他ドキュメント管理サービスで扱っていた情報◎テンポラリデータ(メモや議事録)ストックデータとして固まる前の一時的なメモやログ情報◯ or △フローデータ(非資産)SlackやTeams等のサービスでやり取りされる会話ログー※上記はあくまでも一例。※移行を行う企業や組織全体での関心事として捉え、どの情報をどういう扱いとするか、 Notionでどのように対応するかについて方針を定めておいた方が良い (と思う)。
47まとめ・事前に出来ることは色々あります 準備大事 ・十分なタスクフォース体制が大事 ・余裕を持ったスケジュール設定が大事 ・Notionに興味を持ってくれる人は超大事 ・移行も大事だけど移行後の運用も大事
48俺達のNotion利活用＆運用はこれからだ！
shinyaa31
addyosmani
geeforr
shlominoach
dotmariusz
lemiorhan
colly
rasmusluckow
productmarketing
samanthasiow
jonrohan
aarron
keathley