目次
- はじめに
- プロジェクトの発足
- 直面した「2つの壁」
- 完璧なインポートは幻想（技術の壁）
- 金融事業ゆえの厳しい制約（コンプライアンスの壁）
- 現状と今後
- もし過去に戻れるとしたら？
- Confluence導入時まで戻れたら…
- Confluence→Notion移行プロジェクト開始時に戻れたら…
- おわりに
はじめに
こんにちは。Engineering Officeのkikoです。
今、私はCentral Knowledge Management Committeeのメンバーとして、社内のドキュメント基盤をConfluenceからNotionへ移行するプロジェクトを推進しています。
当プロジェクトはまだ完遂していませんが、3月末に一つの節目を迎えたので、同Committeeメンバーのt-yamaさんと共に、これまでの振り返りをまとめました。
これから社内ドキュメントツールを導入しようとしている方や、他ツールからNotionへの大規模移行を検討している方にとって、少しでも役立てば幸いです。
プロジェクトの発足
このプロジェクトは、単なるツールの乗り換えではなく、メルカリ全体のKnowledge Management（ナレッジマネジメント）の再構築として発足しました。(メルカリのNotion導入についてのブログ)
これまでConfluence含め複数のツールに分散していた社内ドキュメントを、AI/LLMとの親和性が高いNotionに集約することで、以下のメリットがあると考えています。
- ツールとして構造が一元化されるため、AIがコンテキストにしやすい
- AIや他ツールとの連携コストを下げられる
- ドキュメンテーションの重複やメンテナンスコストを減らせる
- ツールの利用自体のナレッジを社内で共有、蓄積しやすくなる
- ツールの違いによる、チーム間のナレッジのシェアや、働き方の違いといった分断を減らせる
- 将来別のツールに移行する場合にコストを低くできる
直面した「2つの壁」
Confluenceからの移行の検討が始まったのは、2025年7月のこと。
まずは、VP、PM Office、リスク・コンプライアンスチーム等へヒアリングしました。ヒアリングの結果、「一部移行を見送るドキュメントは在るものの、全体としては大きなブロッカーはない」と判断し、本格始動しました。しかし、プロジェクトを進めるうちに、2つの大きな壁にぶつかることになります。参考までに、それぞれに対する判断と対策についても合わせて付記します。
1. 完璧なインポートは幻想（技術の壁）
エクスポート・インポートの過程で、情報の欠損やレイアウト崩れが発生しました(我々が調べた当時、50項目以上)。これは、ConfluenceとNotionが別ツールである限り仕様として当然に起きるものです。ただ、その量と範囲は結構なもの…ITチームは泥臭い検証を繰り返しました。
- 判断：手間をかけずに100%完璧な移行は不可能。移行後に必ず手作業が発生すること前提で進める。
- 対策：欠損箇所（マクロや特殊な表など）を特定。移行前に修正すべき点や、インポート後に対応すべき点、修正のベストプラクティスなどをまとめたガイドラインを整備。
2. 金融事業ゆえの厳しい制約（コンプライアンスの壁）
プロジェクト中盤、メルペイ・メルコインといった金融事業において、特定のドキュメントに求められるコンプライアンス要件が、現時点のNotion標準機能ではクリアしきれないことが判明しました。
- 判断：対象ドキュメントの移行は全社の移行とは分ける。
- 対策：メルペイ・メルコイン側で担当者を立ててもらい、全社の移行とは別で対象ドキュメントの要件定義・ソリューション考案を進めてもらう。
現状と今後
2つの大きな壁はありましたが、当初から対象外としていたものや別ルート対応になったものを除き、今後も利用する社内ドキュメントはほぼNotionへのインポートが完了。3月末に、Confluenceへの常時アクセスが不要なライセンスの棚卸しが完了しました。
ただ、Confluenceには、情報のオーナーがいない等の理由でNotionへ移行しなかったものの、情報資産として有用なドキュメントが多数残っています。これらの情報を、必要な時にいつでも閲覧できるよう、一時・恒久アクセス付与の仕組みを提供しています。
最終的には、Confluence内のドキュメントは閉架図書のように取り扱う形を目指しています。
もし過去に戻れるとしたら？
さて、「もし最初から今の知見があったら何をするか？」を考えると、やり直したいポイントはいくつかあります。戻るポイントを、Confluence導入時とプロジェクト開始時のそれぞれに設定して考えてみました。
Confluence導入時まで戻れたら…
どんなツールでも、導入時から完璧な運用ができるわけではありません。何年も運用していれば前提が変わってくるもので、それは導入時に何かしていれば防げたという類のものでもないと思います。
ただ、もし今からConfluence導入時期に戻れるとしたら、Confluenceはもっと自由度を抑えた運用設定にしておくべきだったと思います。弊社のConfluence利用はユーザの自由度が高く、スペース作成やAPIの発行など、ルールはあってもシステム的に制御できている状態ではありませんでした。良く言えば「自由」、悪く言えば「制御できていなかった」状態だったと思います。
自由度が高いと、ユーザが意図せずセキュリティ上リスクのある設定をしてしまったり、例外的な使い方やエッジケースが大量に生まれてしまうというデメリットもあります。例えばAPIトークンはユーザ自身で発行できたため、個人やチーム単位でConfluenceとのAPI連携を前提とした仕組み・運用が多数存在していました。その結果、Notionへの移行が決まると、「同じようにAPIを使わせてほしい」「システム連携も対応してほしい」という声が自然と出てきました。
Notion導入時にこうしたルールを再度整備し運用に落とし込んだところ、「前より不便になった」「自由ではなくなった」という声も一部からありました。ただ、これはNotionが厳しいのではなく、前が自由すぎたのが問題だったと考えています。
とはいえ、最初は自由であとから制限をかけるというのは、反発を生みやすいものです。これはツール移行に限らず、プラットフォーム運用全般に言えることだと思います。組織が成熟していく過程で、後からルールを導入するのは仕方がない面もあります。ただ、自由な期間が長いほど反発は大きくなるので、できるだけ早いタイミングでルールを整備しておくのが望ましいと思います。
Confluence→Notion移行プロジェクト開始時に戻れたら…
今回のような大規模な社内ドキュメントツールの移行は何度もやるようなものではありません。全員が初めての経験で、ノウハウも正解もない中、手探りで進めていくことになります。
その中で一番感じたのは、Confluenceの現状に対する解像度をもっと早く高めておくべきだったということです。ConfluenceとNotionは別のサービスである以上、完璧な移行はできず、人的リソースや期限もあるため必然的にベストエフォートでの対応になります。何に力を入れて、何を割り切るか——その判断には、ある問題がどれだけのユーザに影響するのか、メジャーな話なのかエッジケースなのかを見極める必要があります。
しかし実際には、その見極めに必要な情報が足りないことが多くありました。本当はエッジケースなので割り切った方がよいのに、ニーズの総数がわからないために決断できない、ということがよく発生しました。例えばマクロが移行できないとわかったとき、そもそも何のマクロが会社全体でどのくらい使われているのかがすぐには把握できませんでした。このあたりは後からわかるようになりましたが、技術面だけでなく、ユーザが実際にどう使っているか、どのスペースの更新頻度が高いか、特殊な要件があるかといったユースケースの理解を早期に深めておけば、判断はもっと速くできたと思います。
解像度の問題に加えて、「やった方がよいのはわかっているが、リソースが足りなくてできない」という場面もかなり多くありました。例えば、自前で移行ツールを作れば、移行できない問題やエッジケースに部分的に対応できるかもしれません。しかし、ツールの冪等性の担保や、逆に新たな移行不能要素が生まれないかの検証など、別のリスクが発生します。それが起きたときにプロジェクトが破綻しないかというリスク許容度も含めると、安易には踏み切れません。やれたら良いけれど余裕がない——でも周りから見ると「なぜやらないのか」と思われてしまう——というジレンマは常にありました。
このように移行プロジェクトでは、技術的な対応に加えて、現場での使われ方の把握、リソース管理、ベストエフォートの判断、ユーザへのコミュニケーションなど、さまざまな観点での対応力が求められます。そのため、移行専任のプロジェクトとして適切なメンバーをアサインすることが非常に重要だと感じています。
おわりに
今回のプロジェクトは、社内ドキュメントツールの管理・運用の仕組みを考え直す良い機会になりました。
また、移行のやり方に唯一の正解はありませんが、少なくとも言えるのは次の1点です。
「欠損や崩れが起きることを前提に、準備と運用設計をしておくほど、移行は楽になる。」
今回の経験をもとに、今後もNotionの環境構築・設計に力を入れていきたいと思います。
