Contentful+JAMstackで脱WordPressした話
こんにちは!
エンジニアをしております上村です。
これはコーポレートサイトならびにRefcomeのプロダクトLPをJAMstackで作り直した際の経験談です。
脱WordPressへのきざし
弊社のマーケターなど開発者以外の人が更新を担当するサイトは、これまでWordPressで構築されていました。
導入当時は、社内にエンジニアが少なかったため、マーケターが外部ベンダーにサイト構築を依頼していました。そのため、社内のエンジニアでは手が入れづらく、新規開発コストが高いという状態が続いていました。当初は適切な選択として採用されたWordPressでしたが、社員や会社フェーズの移り変わりによって、だんだんと様々な問題が現れ始めていました。
なぜJAMstack化するのか
JAMstack化計画の背景には、戦略として「今後LPやメディアを増やすことを考えていたこと」や「SEOを強化しようとしていたこと」があります。
それらを実践するにあたって
・LPやメディアを増やすたびにWordPressを建てることは避けたい
・SEOの観点で、パフォーマンス向上をしたいが、WordPressの細かなチューニングをするノウハウが自分たちにない
といった問題が浮上していました。これらを克服すべく、JAMstack化に踏み込みました。
技術の選定
とはいえWordPressである良さは、マーケターでもコンテンツの更新が簡単なことで、これは今後も維持したいと考えていました。そのためエンジニアでなくても扱いやすい記事管理画面を利用できる、ヘッドレスCMSの導入を前提に選びました。
SSG (Static Site Generator)
SSGを実現する手段はいくつかありますが、リフカムではReactやGraphQLでプロダクト開発をしているので、親和性を考えてGatsbyJSにしました。
ヘッドレスCMS
ヘッドレスCMSとしては、Contentfulを採用しました。
採用した理由は
・エンジニアが扱いやすい(開発しやすい)
・JAMstackでの利用が想定されていて、GatsbyJS側にもプラグインが用意されている
・APIが充実しており、Github Actionsなど周辺サービスとの連携が楽
・コンテンツモデルを柔軟に定義でき、記事構成の変更に対応しやすい
・本番環境・テスト環境の切り分け、ユーザー毎に権限の切り分けがしやすい
・WYSIWYGエディタがある等、開発者以外でも操作しやすい
といったものです。内製部分が増えるので、エンジニア観点に重きをおいています。
Contentfulでの運用
基本的にエンジニアライクに作られているCMSなため、ほぼ全ての項目がカスタマイズできます。カテゴリ構造など、記事のモデリングを入念に詰めていくことで、安定した運用体勢が整えられていきます。
数あるContentfulのカスタム機能ですが、使い込んでいく中で「かゆいところに手が届く！」と感じた例を1つ紹介します。
Contentfulには入力フィールドの型を自分で作成して追加する機能があります。
たとえば記事内でテーブルを使いたいことがありますが、Contentfulにはデフォルトでは用意されていません。その場合でも、独自に入力フィールドを定義できます。
弊社ではこんな形でテーブルフィールドを作っています。
作る時は特にエンジニアではない人が使うことを意識して、トンマナや言葉選びに気をつけました。独自の入力フィールドはCSSやJavaScriptも使えるため、自由に独自UIを組み込めます。ここではユーザーが迷わないよう出来るだけ「Contentfulっぽい動作」になるようにしています。
システム構成
システム構成は以下の通りです。
・GatsbyJS→SSG
・TypeScript
・GraphQL
・React
・Contentful→CMS
・Github Actions→それぞれのタスクを繋げる
・Amazon S3→ホスティング
・Preview app→Contentfulの表示確認用プレビューアプリ
・Netlify→ホスティング
・React→静的サイト
今回は自社サイトのデザインと同じ状態で記事を閲覧できる、独自のプレビューアプリも用意しました。用途はコンテンツ作成者の表示確認・外部のインタビュー先への確認だったため、プレビューアプリのリンクにアクセスすれば見られる状態にしています。
記事投稿からデプロイまでのフロー
マーケターや広報がコンテンツを更新した際に、サイトのビルドが自動で行われることを目指したかったため、デプロイの自動化をしました。
本番サーバーへのデプロイが発生するトリガーは二つあります。
1つは「Contentful側で記事を投稿した時」、2つ目は「開発者の変更をmaster branchにマージした時」です。
ContentfulにはWebhook機能があるので、投稿した時や記事を更新した時などにフックできます。今回はContentfulから、GitHub Actionsにrepository_dispatchイベントを送り、ビルド用のworkflowを動かしています。
実際のデプロイフローの流れを紹介します。
1. Contentfulに記事を投稿する。WebhookでGithub Actionsにイベントを送信する。
2. Github ActionsからGatsbyJSのビルドコマンドを実行する。
3. GatsbyJSのbuild時にContentfulからAPIでデータを取得。
4. GatsbyJSでbuildを実行する。
5. build完了後、Gitgub ActionsからコンパイルされたものをAmazon S3にデプロイ。
以上の工程を通ったのち、サイトの更新をSlackに通知するようにしました。ここまでをGithub Actionsのworkflowで定義しています。
プレビュー環境のフロー
Contentfulは記事の変更をリアルタイムに保存していくので、プレビューアプリではページロードで最新編集データの画面表示をできるようにしました。
実際の挙動としては、プレビューアプリのURLパラメータに記事のIDを渡し、ロード時にContentfulのAPIでデータ取得させています。
デプロイタイミングは開発者がコードを変更した時に限られたため、ホスティングには自動デプロイの設定が楽なNetlifyを使用しました。
サーバーレスアーキテクチャにおけるフォームについて
コーポレートサイトのお問い合わせフォームにはFormspreeを採用しました。
旧コーポレートサイトではGoogle Formsを使用していましたが、「トンマナがサイトと異なるのでユーザーを驚かせてしまう」という意見があがっていました。また、コーポレートサイトのJAMstack化作業はデザインの刷新と同時に進めており、新デザインに合わせたフォームを作る方向で考えていました。
Formspreeのよかった点は機能が必要最低限で、価格も手頃だったことです。
Formspree側に独自のスタイルはなく、素のHTMLのform要素に少しFormspree用のデータを追加すれば機能するということが最大の魅力でした。独自UIで作り込みたい時には相性のいいサービスです。
Wordpressから移植して何が変わった?
新しい技術を使用する以上、マーケターの記事作成もWordPressからContentfulに変わるため、慣れてもらうのに時間はかかりました。ですが、開発速度、保守性能が上がったことで、今まで以上にLPの追加や変更が早くできるようになったのは確かです。大変な移行作業でしたが、やる価値はあったと思っています。
量産のため、弊社用にカスタマイズしたボイラーテンプレートも用意しています。
これでますますLP作成は爆速になっていきますね！
さいごに
余談ですが、私がこのプロジェクトに投下された時はまだReactもTypeScriptもGatsbyJSもGraphQLもGithub Actionsもわからない新米でした。技術キャッチアップ含め、コーポレートサイトの移植には1ヶ月程度を要しました。
キャッチアップについては、まだContentfulでの国内事例が少ないこともあり、公式の英語ドキュメントを読んだりして理解を深めていきました。Formspreeなどのサーバーレス技術の選定なども自分で行い、技術構成についても知識をつけることができました。
悩むこともありましたが、「この技術を使ったらいいのでは」「このコードを参考にすると良さそう」など社内でアドバイスを貰いつつ、なんとか完遂しました。相談しやすい職場環境に助けられました！感謝です😌
こうして新しい技術に触れて学びながらものづくりをさせてくれる機会を得て、とても幸せです。まだまだ無限にわからないことがありますが、これからも臆せず新しいことに挑戦したいですね。
リフカムはこんな感じで成長させてくれる会社です。
エンジニアもモリモリ募集中ですので、ご興味あればご連絡ください！
この記事が気に入ったらサポートをしてみませんか？