PLAIDエンジニアブログをJamstackでリニューアルしました🚀
Posted on
こんにちは、エンジニアのmkataigiです。
突然ですが、PLAIDエンジニアブログをリニューアルしていました！
このブログは2016年4月から、プレイドのエンジニアが日々の開発業務のなかで得たさまざまな知見を、社内外の皆さんへと共有する場として運営されてきました。おかげさまで公開済みの記事は100件を超え、各記事を通じてたくさんの方々に私たちのパーソナリティについて知ってもらうことができたのではないかと感じています。
今回は、そんなPLAIDエンジニアブログを（なんとフルスクラッチで！）リニューアルしたので、その経緯や感想について簡単にまとめてみたいと思います🚀
リニューアルの動機
ページビューや採用ページへの流入数が思った以上に多いことが判明
このブログは、「社外の人にプレイドの中のエンジニアのユニークなパーソナリティを知ってもらうこと」を目的として運営されてきました。（参考: プレイドのエンジニアブログを始めました！）
そのため（？）当ブログは、基本的にはエンジニアが書きたいことを自由に書くという風土のもと、良くも悪くもなんとなく運営されていたところがあります。
そんな中で、最近あらためて調べてみると、どうやら思った以上に当ブログからの採用ページをみに来てくれる人が多いということが判明しました。また、社内メンバー数名に話を聞いてみたところ「入社前にブログを見てエンジニアチームの雰囲気を知れたことでプレイドに興味を持った」という声もあがってきました。
こうしたことから、エンジニアが書きたいことを自由に書くというスタンスは活かしながら、ブログ本体の読みやすさや体験を改善することで、このブログのポテンシャルをもっと活かせるのでは？という認識を持つようになりました。
旧ブログは実質メンテナンス不可能で入稿以外では放置状態だった
旧ブログは、Ghost というブログサービスを使って作りました。プレイドでは、Ghostをセルフホストする形で運用しており、デザインは良い感じのサードパーティ製テーマを購入して適用しました。こうすることで、時間と手間をかけずにクオリティの高いオリジナルのブログを立ち上げることができました。
ただ、時間が経つにつれてデザイン面やパフォーマンス面での課題感も目立ち始めていました。具体的には、「文字や画像のサイズ感がおかしい」「記事の一覧性が悪い」「記事の表示速度が遅い」など、いくつかの課題が出てきたのです。
しかし、これを改善しようにもそれをできる人が社内に誰もいないという問題がありました。社内にGhostテーマの書き方を知っているエンジニアはいませんし、これからそれを学びたいと思うエンジニアもいませんでした。
こうして旧ブログはある種の放置状態へと陥っていきました。
プレイドの元同僚チームが、ヘッドレスCMS「Newt（ニュート）」を立ち上げた！
そんな状況のなか、昨年4月にプレイドから独立し新たな会社を創業していた元同僚のチームから、新たな国産ヘッドレスCMS「Newt（ニュート）」がリリースされました。Newtは、従来のヘッドレスCMSをより使いやすく、誰にでも不自由なく扱えるものにしようというコンセプトで開発をしているようです。ヘッドレスCMSという枠を飛び越えていろいろと挑戦していこうと思っているみたいなので、今後にも期待ですね。
国産ヘッドレスCMS「Newt（ニュート）」3月8日より無料プランの提供開始
彼らが今後何に挑戦しようとしているのかについての記事も公開されていました。WordPressを置き換えるという目標は壮大だなwとも思いましたが、そういうチャレンジ精神はプレイド社で育まれたものなのでしょう笑。頑張ってもらいたいなと思っています。
プレイドとして（私個人として..？）は、こういう元同僚のチャレンジは応援していきたいと思っていたので、エンジニアブログをリニューアルするのであればNewtを使ってやってみようと思っていました。そして、去年末に先行ユーザーを募集していたので、このブログ改善にNewtを活用してみることにしました。
Jamstack構成でブログを実装する
そんな経緯でスタートしたエンジニアブログ刷新プロジェクトですが、まずはどんな技術構成で作っていくのかを決めなくてはいけません。今回は、最近フロントエンド界隈でよく耳にするJamstackと呼ばれる構成で作ることにしました。
Jamstackとは？
Jamstackとは、 JavaScript/API/Markup の頭文字をとったアーキテクチャパターンです。
ポイントは、フロントエンドとバックエンドを分離してAPIを通じてデータ通信を行うということです。Jamstackはあくまで考え方のようなものなので、これが正解！といった作り方はないようですが、多くは静的サイトレンダリング（SSR）や静的サイト生成（SSG）などの文脈で使われることが多いようです。
詳細は割愛しますが、詳しくは知りたい方は jamstack.org を確認してみると良いと思います。
せっかく新しい技術を試すなら、本業として開発しているKARTEでも活用できる技術を使いたいなと思い、このJamstackは今後重要になってくる技術だと思っているため、実際に使ってみて、使い所をキャッチアップしてみることにしました。
フロントエンドはNext.jsで実装
次に決めなくてはいけないのは、フロントエンドを何で作るかということです。今回は次のような要件に沿って考え、Next.jsを選択しました。
- 静的サイトレンダリング（SSG）が可能であること
- 本業のプロダクト開発に活かせること
- （個人的にキャッチアップしたい技術であること）
https://jamstack.org/generators に大量の静的サイトジェネレータが紹介されているので、これから検討を始める方はこの中からご自身のニーズに合ったジェネレータを探してみてください。
Newtを使って記事データを管理
記事管理はNewtを使って行います。
Newtでは、1つのスペースの中にAppというコンテンツ管理のユニットを何個でも追加していくことができます。今回はPLAID, Inc. スペースを作成して、その中にEngineer BlogAppを作ることにしました。
また、リニューアル後のブログはパフォーマンスにもこだわったものにしたく、特に重たい画像の最適化にもこだわりたかったため、専用のGCSバケットを作成しNewtの外部ストレージ機能を使い、ImageKitと連携させて利用することにしました。Newtでは外部ストレージ機能を使うことで、ImageKitやimgixのような画像最適化のツールを入れられます。今回はより管理画面が軽快だったImageKitを選択しました。
Netlifyを使ってホスティング
フロントエンドをNext.jsで作ることにしたため、当初はNext.jsの開発元であるVercelを利用することにしていたのですが、ブログ公開の直前に後述する問題が発生したため、Netlifyでのホスティングに切り替えました。現状では、特に大きな問題はなくホスティングすることができています。
NetlifyでもVercelでも、静的サイトのホスティングサービスにそのまま連携することで、めちゃくちゃ簡単にWebサイトをホスティングすることができたので感動しました。
大変だったこと・課題
記事データの移行作業が大変だった..
一番大変だったのは、Ghostからの記事の移行作業です。Ghostからエクスポートした記事データを、1件ずつ手作業でNewtに移していく必要がありました。
Newt社のメンバーに聞いたところ、コンテンツのPOST APIやCSVインポート機能は提供予定とのことだったので、今後はこのような辛い作業を行わなくても良くなっていくのだろうと思います。今回に限ってはデータ移行が一番大変でした。。
Superの影響で、Vercelを使うことができなかった
これはあまり一般的な問題ではありませんが、NotionのホスティングサービスであるSuperを社内の別プロジェクトで利用していたことで、Vercelでホスティングできなくなるという問題が発生しました。
SuperはNotionから静的なWebページをホスティングすることのサービスです。プレイドではSuperを使って recruit.plaid.co.jp というドメインのWebサイトを立ち上げていました。そして、これが原因でVercel上で tech.plaid.co.jp というドメインのWebサイトをホスティングすることができなくなってしまいました。
これは、下記のような原因によるものだと思われます。
- SuperがVercelを使ってホスティングを行なっていること
- Vercelでは、同じドメイン配下の違うサブドメインを、別々のプロジェクトで使用することができないということ
つまり、SuperのインフラとVercelのドメイン扱いに関する仕様が、コンフリクトを起こしてしまったような状況にあるのだと思います。
今回のケースでは、単にVercelからNetlifyへと置き換えることで回避することができました。これもいずれVercelで改善されるかと思いますが、Vercelを前提に実装等を行う場合は注意が必要だと思います。
ビルド時間への慣れが少し必要
Ghostをはじめとする一般的なブログサービスを利用する場合、記事を保存すればWebサイト側に即反映されるのが当たり前でした。ですが、今回のようにCMSをバックエンドにSSGで構築する場合は、記事を保存してからCMSのデータを元に静的ファイルへのビルドが実行され、ビルド結果が新たにホスティングされるため、Webサイトとしてみえるようになるまでにタイムラグが生じてしまいます。
このタイムラグへの慣れというのは少し必要になるかなという感覚を得ました。個人的には、保存ボタンを押すタイミングをちょっと考えてしまいました。
ただ、そうしたビルドによる事前レンダリングによってWebサイトのパフォーマンスがかなり改善されるので、よほどのことがない限りはタイムラグの方に自分を慣らしてしまうのが賢明なのではないかなと思います。
良かったこと
Appテンプレートとスターターで開発工程をスキップできた
Newtでは、モデル設定とサンプルコンテンツのプリセット（Appテンプレート）をインストールしてコンテンツ管理をスタートすることができます。AppテンプレートにはそれぞれNext.jsとNuxt.jsのスターターキットが用意されているため、今回はこれをベースに実装とデザイン（デザイナーさんにも協力してもらいました）を行うことにしました。
モデル設計やヘッドレスCMSとの繋ぎ込み、ブログの基本機能の実装といった作業は、思いのほか手間のかかる作業だと思うので、そうした作業をスキップすることができたのは良い体験でした。
Appテンプレートについてはこちらのドキュメントをご参考ください。
パフォーマンスが大幅に改善
一番良かったと思えたのは、体感値としても計測値としても、ブログのパフォーマンスが大きく改善されたことです。今この記事を書きながらLighthouseを使って測定してみたところ、全ての項目で90点を超える結果になっていました。
社員からも「爆速！」「dev.toかと思った」などと表示速度に関するポジティブな感想が多く出てきました。
エンジニアやデザイナーがコードを書いてメンテナンス可能に
ヘッドレスCMSを使って、フロントエンドを自前で実装したことによって、不具合などがあった場合に社内のエンジニアがPull Requestを作成して修正できるようになりました。
以前のブログだと、何かを修正したくても修正の仕方が分からないという状態でしたが、リニューアル後は普段から仕事で利用しているReact.jsのコードを書くことによって簡単に修正を行うことができます。Pull Requestをマージすれば、即座にデプロイが実行され、普段の開発と同じフローでブログの修正をできるのもかなり楽です。
このように自分達のブログを自分達でメンテナンスできるようになったことで、今後何かしらの改善点が出てきた時にそれを放置してしまわずに済みます。
飛び火的に社内の別プロジェクトで採用され始めた
Newtでは、1つのスペースにAppというコンテンツ管理ユニットを何個も作っていくことで、組織内のあらゆるコンテンツや情報を集約していくことができると謳っています。そして、プレイド社において実際にそういう現象が起きています。
最初はエンジニアブログだけのために作成したNewtスペースですが、少し時間が経つと風の噂を聞いた他チームの社員が何人も参加してきて新たなAppが次々と作られています。
スペースへの参加者は3月11日現在で20名近くになっていて、次々に横展開が進んでいるような状況になっています。個人的にも、今まであまり知ることができなかった他のチームの動きを知ることができて面白いなーと思って眺めています。
最近のフロントエンド技術のキャッチアップができた
個人的には、最近のモダンなフロントエンド開発についてキャッチアップできたことが良かったなと思っています。
どうしてもメインの仕事としてとなると、自分のパフォーマンスが出やすい領域に集中してしまいがちですが、こういった機会を利用して今後重要になるけどまだ詳しくない領域にも手を出していくと良いのではないかなと感じました。
終わりに
今回は、PLAIDエンジニアブログのリニューアルプロジェクトについてご紹介しました。
PLAIDエンジニアブログでは、今後もより一層、社内外のエンジニアに面白いと思ってもらえるような記事を公開していきたいと思っています！
プレイドでは（普段はバリバリと開発しながらも）新しくなったエンジニアブログに面白い記事を公開してくれるエンジニア（インターンも！）を募集しています。詳しくは弊社採用ページまたはWantedlyをご覧ください。