結論
(この記事も例に漏れずワイのコンテンツ方針に則って結論から)
当初、notion を共同編集できるマークダウンエディタ(リッチテキスト寄りだけど大丈夫だろ)と思って使い続けてたら、だんだん独自のブロックが増えてきて、notion にロックインされている状況を作ってしまった。(みんな使える機能は使っちゃう)
のちのちコンテンツの移植が必要になったときに大変だったので、標準仕様に乗っかり続ける重要性を学んだ。
背景
- コンテンツを管理するというシンプルなニーズで、いつかシステム化するかもね、くらいの温度感の業務があった。
- 一旦事業の立ち上げを優先するために、要件を満たしていた notion を選定。
- 移植性を検討するために、APIやマークダウンのエクスポート機能があることを確認。
- 開発は必要になったらするということで、一旦見送り。
- 事業も無事に立ち上がって、しばらくは問題なく運用されていた。(今も問題なく運用されてる)
- ひょんなことから、コンテンツを載せたシステムを開発するニーズが高まった。
- マークダウンとして notion からエクスポートして利用することを機能設計に盛り込んだ。
- 画像
- リッチテキスト
- 非標準マークダウン記法(独自ブロック)
- などの移植困難な要素が多数使われていることを確認
- notion からエクスポートしたマークダウンを独自の parser で読み取り、カスタムコンポーネントで表示することで対応
- エクスポート時に文字の色など、情報的に失われている部分があることが分かった。
- 対応困難なコンテンツはデータ構造やコンテンツ内容を刷新した。(手動)
どうすれば回避できたのか？
(実際に事業が立ち上がっていて、当初の用途では現在でも運用できていることを考えると、正しい意思決定だった可能性もあるが、思考実験として考えたい。)
- 標準に準拠したマークダウンを作成して、ユーザインタフェースとしての notion にはインポート
- 将来的にコンテンツを移植する可能性が少なからずあった状況下では notion に依存したコンテンツ開発をするべきではなかった。
- notion は権限管理が細かくできるので、社内ユーザには read only で更新させないようにするとか。
- とはいえ、マークダウンを書けない人はコンテンツを作れないという状況になると、業務上スケールしにくいので、notion とか wysiwyg なエディタは必須だった。
- 最初からリッチテキストだと割り切って、WordPress などの簡易的な CMS を使用する
- ぶっちゃけ、保守できる体制があるならこれが一番良かったかも。
- とはいえ、当初はインフラを持ちたくなくてシステム化を延期した背景があるので、コスト要件的な意味でこの選択肢を選べなかった。
- あと共同編集ができないのもキツイ。
- コンテンツを移植するのではなく、notion をデータ層に見立てて API などからラップする
- こちらは、APIの仕様などを評価した際に、実装面で複雑性を吸収する層が必要になることや、notion 側に新しいブロックが実装された際、知らずにコンテンツを改変してシステム側で未対応の不具合が高頻度で発生するリスクがあったため選定しなかった。
- 開発チームの規模にゆとりがあれば追随できるので、こちらでも良かったと思う。
学び
根本的な学びとしては、下記の3点。
- コンテンツは “データ” なので、しっかりと要求仕様の明確化と要件定義を実施するべきだった。
- データはいつか移植する前提で、自分たちでコントロール可能な場所に置くべきだった。
- マークダウンなら GitHub で管理するとか。
- リッチテキストなら WordPress でも良かった。
- 非構造化データの取り回しは難しい。
