# 背景
自社では、Webメディアを展開しており、私は主にメディアのコンテンツ管理システム（CMS）の改善を担当しています。
当該CMSでは、複数人がコンテンツの編集を行うことができるのですが、コンテンツの編集履歴を管理していないため、以下のような問題が発生していました。
- CMSのユーザーはコンテンツの編集履歴を参照できないため、編集前の状態に戻せない。そのため、記事を編集することで記事のSEO評価等が下がった場合等に備え、記事の編集者は記事の編集履歴を手書きの紙で管理していたが、そのやり方も破綻しかけていた。
- コンテンツに対し、誰が、いつ、どのような編集を行なったのかわからないため、複数人によるコンテンツの管理自体が難しくなっていた。
# 目的
コンテンツの編集履歴を参照する機能をCMSユーザーに提供すること。
# 開発の規模感
90人日から120人日程度
# チームの構成
私、プロダクトマネージャー、テックリードの3人でチームを構成した。
開発の目的の策定、設計、実装、テストは私一人で全て行った。
プロダクトマネージャーとテックリードはアドバイス役。
# 技術的に工夫したこと
## アーキテクチャ
CMSでは、リリース時、DBのマイグレーションを適応した際の障害が多発していたため、CMSのDBに対して変更しないようにするべく、編集履歴を管理する仕組みをマイクロサービス（REST API, 編集履歴の保存・参照のインターフェース）をCMSの画面から呼ぶ形で実装した。このことで、マイクロサービスが障害を起こしても、CMSでは編集履歴機能を利用できなくなるだけで、他の主要な機能には影響がないようにした。
## DBの選定
マイクロサービスが管理する編集履歴は、時間の経過とともに膨大になり、パフォーマンスが悪化することが予想された。このため、データの正規化は行わず、編集履歴に付随する編集者のデータなども含め、編集履歴を1つのテーブルで管理することにした。従って、DBとしてはRDBを用いず、ドキュメント指向DBを中心に調査した。その結果、1ヶ月の利用料が定額であったMongo Atlasを用いることにした。
# 結果
CMSのユーザーは、コンテンツに対して、いつ・誰が・どのような内容の編集を行なったのか参照できるようになった。
（GithubのdiffのようなUIで編集履歴を参照できる）
開発を行なった編集履歴機能は、毎日利用され、コンテンツの管理に役立てられている。