運用を容易にするために、Next.jsのSSG + S3 + microCMSのJamstackでコーポレートサイト作った

こんにちは。コーポレートガバナンステックのミチビク株式会社CTOの金杉です。
取締役会DXのmichibikuをソフトウェア開発をしております。

皆さんは、静的サイトを作成する時に何を意識していますか？

自分は運用面を一番に意識しています。

toBでビジネスをしてる会社の静的サイトといえば、

• コーポレートサイト（ホームページ）
• オウンドメディア
  この2つがあげられると思います。

運用面を容易にするために、Next.jsのSSG + S3 + microCMSでコーポレートサイト作りました。
https://www.michibiku.co.jp/

なぜ、この構成にしたのか。この記事で紹介しようと思います。

結論

• 運用面にフォーカスを当てて、Next.jsのSSG + S3 + microCMSでコーポレートサイト作成
• メインプロダクトと技術スタックを統一することで、社内のエンジニアが誰でも運用できるようにする
• WordPressを避けることで、ビジネスサイドを静的サイトの作成、運用から切り離し、技術的な運用を容易にする
• microCMSを使用することで、ビジネスサイドはリッチエディタで記事の作成、更新ができる

構成

• Next.js(SSG)
• TypeScript
• Styled Component
• GitHub
• GitHub Actions
• S3
• CloudFront
• Route 53
• Slack
• microCMS

運用面から静的サイトの扱いを考える

メインプロダクトと技術スタックを統一することで、社内のエンジニアが誰でも運用できるようにする

ミチビク株式会社のmichibikuというプロダクトの技術構成は、ざっくりと以下です。

• Next.js(SSR)
• TypeScript
• Styled Component
• GraphQL
• Node.js
• Prisma
• MySQL
• GitHub
• GitHub Actions
• AWS（諸々）

TypeScriptベースで構築し、フロントエンドの開発に関しては、静的サイトもメインプロダクトもNext.js + TypeScriptで統一してるため、基本はメインプロダクトのフロントエンドの開発を担当していたとしても、急に来た静的サイトの対応を yarn dev を叩けば誰でもできるようにしています。

また、AWS、GitHub Actionsも社内に知見があるので、静的サイトのインフラ面やCI面でなにか問題が発生した時も、社内のエンジニアが容易に対応できます。

これがWordPress用のエンジニアに頼んでいたり、静的サイトだけ外注してたりすると、はるかに運用コストが高いです。

WordPressを避けることで、ビジネスサイドを静的サイトの作成、運用から切り離し、技術的な運用を容易にする

静的サイトをつくるとなると、まず候補にあがるのはWordPressになると思います。
WordPressは圧倒的に知名度があるので、使ってる会社も多いです。
しかし、自分はWordPressで静的サイトを作ることに反対です。

理由としては、逆説的かもしれないですが、WordPressが世の中に広まりすぎてることに関係します。
WordPressは誰でも知ってるので、外注がいくらでもできてしまいます。
外注費もピンキリで、有名な会社に頼めば高額でしょうし、フリーランスの個人などに依頼すれば、比較的安価にWordPressでホームページを作成してくれるでしょう。

しかし、作成したタイミングで運用のことを気にしてるビジネスサイドはほとんどいません。ましてや、外注先のエンジニアとしても、契約の範囲、つまり、大抵はホームページをリリースしたら、「納品したので、自分の仕事は終了」となることが多いです。

運用のことを気にしないとなると、WordPressで好きなプラグインを勝手に入れられたり、メンテナンスを意識してないphpのコードを書かれてる状況がほとんどです。

そのような状況でWordPressの運用をしないといけないとなると、ホームページの作成に何も関わってない社内のエンジニアです。

• phpのバージョンを上げないといけない
• プラグイン、ライブラリを更新しないといけない
• 攻撃を受けたので、対応しないといけない
• リリースがバズってサイトがアクセスできなくなったから、早急に復旧したい
• デザインを変えたい
• 移転したり、資金調達したので、会社情報を変更したい

このような依頼が急遽ビジネスサイドから、社内エンジニアに降りかかることがあります。
しかし、社内のエンジニアはどのような構成でどのようなホームページなのかも調査しないとわからない状況であったり、調査開始をするにしても、調査に必要な情報を持ってないなど諸々あって非常に大変です。

しかし、ビジネスサイドをホームページ作成、運用から切り離し、はじめから、社内のエンジニアが企画をして、開発すれば、運用面までも考慮して、設計、実装できるので、このような心配はありません。

microCMSを使用することで、ビジネスサイドはリッチエディタで記事の作成、更新ができる

いわゆるヘッドレスCMSであるmicroCMSを利用して、記事の更新を行っています。
UI上で記事の更新ができないとなると、ビジネスサイド的には運用が難しくなると思います。
実際にある程度、HTMLやCSS、gitの知識がないとコード上で、記事を管理することができないからです。

WordPressをいじったことのあるビジネスサイドの人がいると、WordPressと同じように、記事を更新したいと言ってくるかなと思います。たぶん、本質的には、リッチエディタ形式で入稿したいの意味のはずですので、同じようにできる必要があります。

ヘッドレスCMSには、いくつか種類がありますが、日本製で、日本語で説明が詳しく書かれてるmicroCMSを採用しました。エンジニアサイド的には、英語で説明がされているのは慣れているので、問題ないです。したがって、Contentful、Strapiなども選択肢とあがってきますが、ビジネスサイドのことを考えると、英語のツールを導入しないほうが運用的にメリットがあると考えました。

運用面以外のメリット

運用以外でも、この構成にすると、メリットがあります。

• SSGなので、速い、SEOに強い
• 静的サイト専用のエンジニアを採用する必要がない

この構成のデメリット

ただ、反対にデメリットもあるので、注意は必要です。

• Vercelを使えば、ホスティングは容易にできたが、金銭コスト的に採用できなかった（お金に余裕があれば、Vercelに任せたかった）
• 社内エンジニアの工数を一定持っていかれる
• 開発の初期コストが高い　→ （弊社は単価0円の筆者取締役CTOが対応することで解決）

まとめ

最近はフロントエンドでReactを使うケースが増えてきてると感じてます。
ぜひフロントエンドでReactをつかっていて、技術スタックがメインプロダクトと統一できる場合は、Next.jsのSSG + S3 + microCMSのJamstackで静的サイトを作ってみるのはいかがでしょうか？