はじめに
こんにちは。Webフロントエンドチームの山口です。
この記事では、N予備校の規約類を microCMS で管理して、運用を改善した取り組みについてご紹介します。早速ですが、前置きは抜きにして本題に入りたいと思います。ぜひお付き合いください！
背景、前提
N予備校では、基本的な 利用規約 の他、定期的に開催されるキャンペーンの応募規約など、様々な規約を公開しています。
総数は年々少しずつ増加しており、記事の執筆時点で23件もの規約が存在します。これらは全てプロダクトのコードベースにハードコードされており、開発チームが社内のステークホルダーから変更依頼を受け付ける形で管理されていました。
新しく規約を追加することもあれば、既存の規約に変更を加えることもあります。開発チームは依頼元と必要なコミュニケーションを取りながら対応を進め、最終的に規約が公開されます。
課題
コミュニケーションコスト
開発チームと依頼元の間で、都度コミュニケーションを取りながら対応を進めるため、その分のコミュニケーションコストが積み重なっていました。
- 文面の受け渡し
- 公開日の調整
- 公開後の事後連絡
- etc...
変更依頼のテンプレートを用意するなど、コミュニケーションコストを軽減する方向性も考えられますが、開発チームがステークホルダーから依頼を受けるという構造上、双方間のコミュニケーションを完全に失くすことはできません。
開発チームとしても、日々の定型業務に限られた時間を割くのではなく、より創造的で本質的なコトに集中したい思いがあり、そのためには軽減策ではなく根本の構造から見直す必要がありました。
プロダクトとの密結合
規約はコードベースにハードコードされており、プロダクトと密結合の関係にありました。故に、プロダクトの開発プロセスとも密になっており、最適な変更方法を取れずにいました。
例えば、規約を変更するためには Pull Request を作り、マージし、リリースをする必要があります。リリースの準備や調整などを含めると、変更依頼を受けてからリリースされるまでに5営業日ほどかかっていました。
加えて、規約は公開日が決められているため、リリース時に問題が発覚したとしても、ロールバックし後日再リリースの選択は取りづらい性質を持ちます。極力ロールバックを避けるため、他の変更とは混ぜずに規約単独でリリースするなど、手間と工夫が必要になっていました。
コミュニケーションコストについても、規約とプロダクトが密結合の関係にあるからこその課題だと捉えることができます。ステークホルダーは非開発者であるため、変更依頼という形で開発チームを通して、規約を変更せざるを得ないのです。
解決方法
これらの課題を解決するために、CMS を活用することにしました。規約をコードベースから引き剥がし、CMSで管理し、プロダクトと疎結合にします。
一般的なCMSでは、コンテンツ（規約に相当する）を操作するための管理画面が提供されています。専門知識も不要であるため、ステークホルダーはCMSから直接規約の変更が可能になります。開発チームを通す必要はありません。
加えて、プロダクトと疎結合にできるため、開発プロセスとも疎であり、より最適な変更方法を取ることができます。ロールバックの心配もなく、柔軟に任意のタイミングで規約を公開できます。
要するに「プロダクトと疎の関係でコンテンツを管理でき、非エンジニアが扱うためのGUIを提供するモノ」があれば課題を解決できると考えました。CMSはまさにその性質を満たしています。
CMSの選定
次に具体的なCMSの選定です。記事タイトルの通り、 最終的には日本製ヘッドレスCMSのmircoCMSを選びました。ここでは「何を考えその決定をしたのか」を記します。
まず、今回の事情に適したCMSの条件は何か？を考えました。
- プロダクトの全体ではなく一部分（規約）だけを管理する
- プロダクトが担うためヘッドの役割は不要である
という性質から、ヘッドレスCMS が適しており、尚且つ、日本語話者が扱うため、日本語対応が重要であると考えました。日本語に対応している海外製ヘッドレスCMSも少なからずありますが、今回は日本製ヘッドレスCMSを優先的に検討しました。
日本製ヘッドレスCMSの選択肢は多くありません。それらの選択肢を比較し、プロトタイプを実装して機能面の不足や使用感を確認しながら、最終的にmircoCMSを選びました。
非エンジニアを含めた人物が扱うこともあり、導線を含めたサービスのわかりやすさ、使いやすさを重視しましたが、今振り返ってみても良い選択だと思っています（*1）
アーテクチャ
早速ですが、今回採用したアーキテクチャです。
microCMSから規約を編集すると Webhook が発火し、HTTPエンドポイントを通してAPIがキックされます。このAPIは新しい規約をS3に保存します。ユーザーから規約ページが要求されると、保存した規約を取得し、規約ページを表示します。これが全体の流れです。
ヘッドレスCMSを使用した仕組みを構築する場合、Jamstack の構成にし、SSGやISRのレンダリング方式を採用するパターンが良くあるかと思います。しかし後からプロダクトの一部に追加することになった場合、採用しているフレームワークがSSGやISRに対応していないこともあるでしょう。今回も同様の事情などからSSGやISRではなくCSRを採用しています。
さて、CSR + microCMS ならではの課題がいくつかあります。このアーキテクチャはそれらの課題を解決するための1つの選択肢と言えます。他に検討した案を2つ交えながら深掘りしていきます。
案1
microCMSが提供する コンテンツAPI から規約を直接取得する案です。利点は何より簡潔なところです。バックエンドを作る必要がありません。
一方で APIキー の取り扱いに課題があります。APIキーはコンテンツAPIを呼び出す際に必要なもので、フロントエンドから直接コンテンツAPIを呼び出してしまうと外に露出します。APIキーが外に露出すると、コンテンツを自由に操作できるため、悪用の恐れがあります。原則的には秘匿すべきものであり、秘匿することを公式から推奨されています。
なお、APIキーにはアクセス権限を設定できるため、必要最低限のGET操作のみを許可し、リスクを抑え、露出を許容する考え方もあります。
今回採用したアーキテクチャでは、バックエンドにAPIキーを隠蔽し、根本的に露出自体を避けることで、この課題を解決しています。
案2
規約取得用のAPIを作成し、フロントエンドはそのAPIから規約を取得する案です。バックエンドからコンテンツAPIを呼び出すことにより、APIキーを隠蔽できます（*2）
一方で、規約取得用APIの呼び出し毎にコンテンツAPIへのアクセスが発生するため、microCMSの制限を受けやすい課題があります。
microCMSでは データ転送量 と呼ばれるものがあり、例えばコンテンツAPIからデータを取得すると加算されます。このデータ転送量は料金プランごとに月の上限が定められており、上限を超えた分は従量課金が発生します。
また、コンテンツAPIにはレートリミット等の 制限 が設けられており、GET APIのレートリミットは60回/1秒です。場合によってはリクエスト数を制限する。リトライ処理を組み込む。といった対策が必要になってきます。
今回採用したアーキテクチャでは、コンテンツAPIへのアクセスは、WebhookからキックされるAPIからのみです。つまり、規約の変更時に限りコンテンツAPIを呼び出すことで、制限を殆んど受けない仕組みになっています（*3）
なお、例えばCDNレベルのキャッシュを有効に活用してオリジン（規約取得用API）へのアクセスを抑える方法も考えられます。その場合、キャッシュを削除するタイミングが重要になりますが、microCMSのWebhook機能を使用すればコンテンツの変更に合わせてキャッシュを削除する仕組みを作れます。今回はデータ（規約）数が数十件程度であり、検索機能も不要であるため、S3にJSONファイルを置いておくだけで事足りますが、そうでない場合は有効な選択肢になり得ます。
構築
それでは実際に構築した仕組みをご紹介します。個々の細かな実装レベルの話はあまり大切なことではないため省略します。
microCMSの管理画面
microCMSでは、様々な入力項目を組み合わせることで、コンテンツの管理画面を構築できます。
今回は
- パス
- タイトル
- 本文
の入力項目を用意しています。これらの項目を入力し、画面右上の公開ボタンをクリックすると、N予備校上で規約を公開できます。
ここでは簡単な工夫を施しています。
- 入力項目は必要最低限に留める
- 入力漏れを防ぐため、それぞれの入力項目にrequired制約を設定
- 入力ミスを防ぐため、パスに正規表現による入力チェックを設定
規約ページ
実際に公開された規約ページです。上の赤枠から順に、管理画面から入力した「パス」「タイトル」「本文」に対応しています。
さて、内部でどのように規約データを取得しているのか。少し見てみましょう。
まず、ブラウザのデベロッパーツールからNetworkタブを開くと、paths.jsonと${id}.jsonを取得していることがわかります。
paths.jsonには、全種類の規約のIDとパスが含まれています。
${id}.jsonには、単一の規約のID、パス、タイトル、本文が含まれています。
この2つのJSONファイルはS3から取得したものです。microCMSの管理画面から公開ボタンをクリックすると、Webhookが発火し、APIがキックされ、この2つのJSONファイルをS3に保存します。
paths.jsonは規約ページのルーティングを定義するために使用しており、いずれかの規約ページにアクセスがあると、個別の${id}.jsonを取得し、規約ページを表示する仕組みです。
これらを1つのJSONファイルにまとめることもできますが、「パスの一覧ファイル」と「個別の規約ファイル」に分けることで、1つの規約ページを表示するために必要なデータ取得サイズを1/10程度に抑えることができます。
結果
今回の運用改善は、新しい仕組みを構築するだけでは達成できないものです。より具体的な運用手順を定め、属人性を排除すべく体系的な運用マニュアルを整備し、ステークホルダーへの説明の場を設け、合意を形成し、最終的に新しい仕組みでの運用を開始するに至りました。
その後、早速3つの規約が公開されています。
公開に際して、開発チームは関わっておらず、ステークホルダー側で完結しています。「操作方法や手順がわからないから教えて欲しい」といったこともなく、コミュニケーションコストの課題については、当初の狙い通りに根本から解決できていると言えそうです。
プロダクトと規約の関係も疎に保つことができました。以前は公開までに5営業日ほどかかっていましたが、現在は数分〜数十分程度で公開できます。ロールバックの心配もなく、柔軟に任意のタイミングで公開できます。
総じて、事情に適した方法と道具を選んだこと。運用手順やマニュアルの整備など、運用面の視点を疎かにしなかったこと。それぞれが功を奏し、良い結果として表れてくれているのではないかなと考えています。
以上、N予備校の規約類を microCMS で管理して、運用を改善した取り組みについてご紹介しました。あくまで1つの事例でしかありませんが、少しでも参考になる部分がありましたら幸いです。
We are hiring!
株式会社ドワンゴの教育事業では、一緒に未来の当たり前の教育をつくるメンバーを募集しています。カジュアル面談も行っています。お気軽にご連絡ください！
開発チームの取り組み、教育事業の今後については、他の記事や採用資料をご覧ください。
