＃異世界転生と、忘れ去られたWordPress
・・・おや・・？
私の名前は、Maki。 ある日、私は仕事中に突然の睡魔に襲われ、あっという間にこの世を去ってしまった。 そして、気がつくと私は、見知らぬ草原にいた。 私は、自分が異世界に転生したことを悟った。そう、ここは、フロント・エンドと言う世界ーーーー。
異世界で目を覚ました私は、そこで見慣れたロゴが表示されているパソコンを眼の前に見た。それは、私がかつて使っていた、あのWordPressのロゴだ。
「WordPress！？」
私は思わず声を出してしまった。 そうだ。前世の私は、BBSakuraというエンジニア集団の会社でモバイルコアのバックエンドエンジニアとして働いており、自社のホームページをWordPressで構築した経験があった。しかし、その記憶はなぜか断片的で、詳細を思い出せない。
＃WordPressの課題感
・・WordPress・・そうだ！
私は前世の記憶を一つ思い出した。それは、WordPressの運用がとても大変だったこと。
「しばらくさわってないし、まずはこのWordPressをメンテしよう！」
そう思った私は、さっそくパソコンの前に座る。しかし、WordPressの操作方法はほとんど覚えていない。
WordPressでホームページを本格運用した場合、以下のような問題が発生したはずだ。
- ステージングと本番を分けるのが大変
- 開発ブランチを作りたい（開発自体をGitでやりたい）
- 投稿記事のフォーマットが記事によってズレてしまったりする
- 動作がもっさり
- プラグインのバージョンメンテが大変
- 子テーマを作らないといけない問題
- プラグインのバージョンメンテナンス、脆弱性の問題
そこで、最新の技術を使って、もっと簡単にホームページを作成できないかと考えた。
最近話題のRemixというフレームワークを使えば、Reactのコンポーネントをサーバーサイドでレンダリングできると聞いたことがある。これなら、動的なホームページを簡単に作成できるはずだ。
＃モジュールの壁にぶつかる
そこで、私は、初めてのフロントエンドフレームワークであるRemixを使って、自社ホームページを構築することにした。 Remixは、最新のWeb開発のトレンドを取り入れた、とても便利なフレームワークらしい。フロントエンドやWebの知識がまったくないところからのスタートだけど、便利で最新って書いてある。
バックエンドもやってたし、Remixもなんとかなるはず！簡単だ！（フラグ）
私は、Remixでプロジェクトを作成し、さっそく記事を作成するためのモジュールを探し始めた。しかし、なかなか良いものが見つからない。記事を誰でも簡単に書けるように、Markdown形式で入力できるようにしたい。 ようやく見つけたモジュールは、機能的には申し分なかったが、なんとRemixに対応していなかったのだ。
＃フロントの基礎を学ぶ
Remixの壁にぶつかり、私は改めてWeb開発の基礎を学び直すことにした。JavaScript、TypeScript、Reactといったフロントエンドの技術を、一から勉強し直す。
JavaScriptは、Webの基本となる言語だ。TypeScriptは、JavaScriptの静的型付け言語だ。Reactは、Facebookが開発した、Webアプリケーションの開発によく使われるフレームワークだ。 まずは会社で契約しているUdemyを使ってJavaScriptの勉強をスタートしてみた。
JavaScriptとTypeScriptの学習は、それほど苦労しなかった。しかし、Reactの学習は、とても難しかった。Reactの考え方は、今までのGoでのプログラミングの経験とはまったく異なるものだった。
- React
- フロントエンド開発に特化したJavaScriptのライブラリ
- ブラウザ（クライアント）で実行されるコードと、サーバーで実行されるコードを、シームレスに書くことができる。
- UIの部品（コンポーネント）を作成し、作成したコンポーネントを組み合わせることで画面を構築する。
- 非同期処理が中心（沼）。ユーザー入力やバックエンドとのAPI通信のために最適化されている。
- DOM（ウェブページの設計図）を直接更新せず、仮想DOM（DOMのレプリカのようなもの）を使って間接的にレンダリングを行うことで、DOMを直接更新するより高速に動作する。
- コンポーネントごとに状態管理を行い、状態が変わるとコンポーネントを再レンダリングする。
- Go
- 汎用プログラミング言語。
- Goroutineによる並行処理がシンプルに記述でき、高負荷なバックエンドの処理を効率化できる。
また、Reactと同じくフロントエンド開発の2大巨塔のひとつとしてVueも存在するが、この検討段階では選択肢に入らなかった。なぜなら、BBSakuraが開発しているプロダクトのひとつであるネットワーキングポータル「OCX」はReactで書かれているからだ。できるだけ同じライブラリで作った方が、メンテナンスもしやすく、また、「OCX」で実現したいことの実験場としてホームページを使うこともできるかもしれない。
それでも、私は諦めずにReactの学習を続けた。そして、ようやくReactの基本的な部分を理解することができた。
＃Next.jsで再挑戦
しばらくの間、基礎を固めた後、再びホームページの開発に取り掛かる。今回は、Next.jsというReactフレームワークを使うことにした。Next.jsは、静的サイト生成とサーバーサイドレンダリングの両方に対応している。また、静的サイト生成により高速に動作するため、SEOにも強いという点が魅力だ。
ホームページの開発にNext.jsなどのフレームワークを使うのは、少々オーバーキルかもしれない。しかし、フロントの基礎を学んでいるときに感じたように、「OCX」はNext.jsを使って開発されており、「OCX」で実現したいことの実験場としてホームページを使うには、Next.jsという選択が一番良いと考えた。
Markdown形式で記事を作成するためのモジュールも、Next.jsに対応しており、スムーズに開発を進めることができた。
＃社内リソースの確保と開発の大義名分の建てつけ
この世界、フロント・エンドに降り立ってからというもの、私の使命は「OCX」を開発することだった。しかし、いきなり未経験の状態から既存のプロダクトに手を付けるにはいささか手腕がたりない。それならば、この忘れ去られたホームページをプロジェクト化し、人を募っていろいろな知見のアウトプットの場にしよう。部署横断でわちゃわちゃして、Geeks' Playground を実現しよう。ないのなら作る。そう、自らの手で。それが私であり、BBSakuraだ。
少しずつ感覚を取り戻してきた。
この案件をプロジェクト化するには、まずは以下のことが必要だ。
- 直接お金を生まないという性質上、この案件を実行する大義名分が必要（体力）
- ホームページという性質上、デザイン実装が得意なメンバーと事業が得意なメンバーが必要（パーティメンバー）
- 納期を自ら設定し、最後までやりきる根気（SAN値）
私は、事業メンバーをつかまえ、「Geeks' Playground を実現したい」「後進の育成に使いたい」「部署横断のコミュニケーションの場をつくりたい」「BBSakuraのプロモーションに力を入れるための第一歩を踏みたい」という大義名分を伝えたところ、快く同意していただいた。また、デザイン実装が得意なメンバーも集めてくれるというのだ。とても助かった。
ここからみんなで力を合わせて、ホームページを作っていこう。
＃力を入れたはじめてのフルスクラッチ自社ホームページ
私がこの業界で仕事をするにあたって、とても大切にしている心がある。それは、「技術を人に意識させない」こと。せっかくフルスクラッチで少数精鋭で取り組んできたプロジェクトだ。ここに、自分の思いを思い切りぶつけたい。その思いを体現するために重視したのは、以下の1つのシンプルなポイントだ。
- ユーザーの「自然体」をじゃましないデザインにする
このポイントは奥が深い。自然体をじゃましないためには、色調やデザインもシンプルにしたい。また、目の導線を遮らないボタンやテキストの配置にも工夫した。また、上に書いたように、記事を誰でも簡単に書けるように、Markdown形式 にすることも、メンテナーの自然体にできるだけ近づけるための努力だ。
＃新たな壁、そして決断
ホームページの開発が完了し、Vercelでデプロイできた喜びも束の間、新たな問題が浮上した。グループ会社の方針により、特定の認証局が発行したSSL証明書を使用する必要が生じたのだ。Vercelでは、この要件を満たすことが困難だった。
Vercelは、GitHubのリポジトリと連携するだけで簡単にWebサイトのデプロイ〜ホスティングまでを実現できる便利なツールだ。しかし、持ち込み証明書を利用できるEnterpriseプランに切り替えるには多額の費用がかかる。弊社で利用するアカウントの数を考慮すると、会社を倒産させる規模の価格の試算がでてしまった。（執筆時点の情報）
これらの問題を解決するため、私は別のプラットフォームへの移行を決意した。
＃Google Cloudへの移行
いくつかのクラウドホスティングサービスの中から、私はGoogle Cloudを使うことを決意した。比較対象は以下の3つ。
- Cloudflare Pages
- さくらのクラウド
- Google Firebase Hosting
この中から、以下の条件を満たすものを絞り込んだ結果、Google Cloudを選ぶこととなった。
- 低コスト: 費用をできるだけ安く抑える。
- シンプル構成: 組み合わせるサービスを最小限にする。
- 簡易機能: 複数サービスを組み合わせる場合、シンプルな機能のものを選ぶ。
- サーバーレス: 運用の負担を軽減するため、サーバーレス構成にする。
- 環境分離: ステージング環境と本番環境を分離する。
- 限定公開: ステージング環境を社内のみに公開することでセキュリティを強化する。
Google Cloudへの移行を決意した私は、よりスケーラブルで効率的な環境を目指し、Compute Engineではなく、Cloud BuildとCloud Run、そしてCloud Load Balancingという組み合わせを選択した。 まず、Cloud Buildを使って、Dockerイメージを作成する。Next.jsのアプリケーションをDockerfileで定義し、Cloud Buildトリガーを設定することで、コードの変更を検知し、自動的に新しいイメージをビルドするようにした。
次に、Cloud Runにコンテナをデプロイする。Cloud Runは、サーバーレスコンテナプラットフォームであり、リクエストに応じてコンテナを起動・停止するため、非常にコスト効率が良いのが特徴だ。また、自動スケーリング機能も備わっており、トラフィックの変動に柔軟に対応できる。 最後に、Cloud Load Balancingを使って、複数のCloud Runインスタンスにトラフィックを分散させる。これにより、高い可用性と耐障害性を確保することができる。
＃新たな章へ、そして未来へ
Cloud Build、Cloud Run、Cloud Load Balancingという組み合わせは、私にとって新たな挑戦だった。しかし、これらのツールを組み合わせることで、非常に効率的でスケーラブルなWebアプリケーションを構築することができた。
現在は、Cloud RunのログをCloud Loggingで集計し、Cloud Monitoringで監視することで、アプリケーションの状況を常に把握している。 異世界に転生し、WordPressから始まり、Next.js、そしてGoogle Cloudのサーバーレス環境へと、私のWeb開発の旅はますます加速している。一生懸命制作したホームページだが、まだまだ改善点はもりだくさん。もっといいUI、もっといいデザインを求め、もっといいUXを探求しよう。この異世界で、私はこれからもWeb開発のスキルを磨き、より革新的なWebアプリケーションを作り続けていきたい。
＃最後に
この記事は BBSakura Networks アドベントカレンダー 12 日目の記事です。
