Wordpress で動いていたコーポレートサイトを Middleman でリプレイスしたら色々改善できた話

みんなのウェディング技術開発部で開発基盤を担当している濱口(@jaru)です。
先日、開発基盤の改善の一環として、Wordpress で動いていたコーポレートサイトをMiddleman でリプレイスしました。 リプレイスしてみて、良かったことや悪かったことなどを、まとめておこうと思います。

リプレイスした結果

リプレイスすることで以下の改善ができました。

  • 1〜2時間程度かかっていた改修が、5分程度に短縮
  • 属人性の排除
  • https化、混合コンテンツの撲滅
  • アクセス速度が爆速に
  • 運用にかかる費用が10分の1以下に

なぜリプレイスしようと思ったのか

以前まで、弊社のコーポレートサイトは PHP で魔改造された Wordpress で動いていました。ですが Wordpress を触れる人が社内におらず、何か修正や変更を加えるにしてもエンジニアに依頼が来て、対応するというフローになっていました。

とはいえ、エンジニアも普段書いている言語は主にRubyです。なので、PHPで書かれているコードを読んで修正するにも結構コストがかかり、文言を修正する簡単な変更でも1時間程度かかってしまっていました。

というわけでエンジニア側で対応するなら、エンジニアで運用しやすい技術で置き換えようよ、ということになりリプレイスが始まりました。

技術選定

今回は以下のように選定して進めました。

フレームワーク

フレームワークとして Middleman という Rubyベースの静的サイト構築用のフレームワークを利用しました。 選定の際には、以下のような軸で考えていました。

  • 保守しやすいかどうか
  • スキルとして役に立つものかどうか

その他にも、同じく Ruby ベースの Jekyll や、React ベースの Gatsby などを検討していました。とはいえ、 今回は保守しやすいかどうか を最優先に考えていたので

  • 普段のメインの業務で扱っている技術セットに近く、学習コストが低い
  • ドキュメントが充実している

という2点を考慮した結果、Middlemanを利用することにしました。

Middleman は、日本語のドキュメントだけでなく、ドキュメント内に動画などもあったりして、とてもドキュメントが充実しているなと感じました。

CSSフレームワーク

CSSフレームワークも同様に選定していました。 候補として

を考えていました。しかし、デザイナーさんにヒアリングしたところ、 自分たちでデザインシステムを構築した方が保守しやすそう とのフィードバックをもらいました。
また、1からデザインシステムを構築するのは 担当するデザイナーの経験としても良さそう というお話もいただいたので、今回はCSSフレームワークを使わずに進めることにしました。

CI環境

CI環境は CircleCIAWS Amplify を利用しました。

当初は以下のように、みんなのウェディングエンジニアリングブログと同じ構成にしようと考えていました。(詳しくは こちら)

しかし、AWS Amplify を利用することで、とても簡単にデプロイ環境を作成することができました。コンソールをポチポチして、ちょっとだけ設定ファイルを書いて、ほんの10~20分程度待つだけで構築できました(環境によって変化するとは思います)

また、移行前は特定の1つの検証のための環境が存在していましたが、移行後には用意しませんでした。というのも AWS Amplify ではブランチ毎にデプロイが可能です。なので、必要になった時に作業の担当者が作業ブランチを AWS Amplify から設定してデプロイして、検証が終わったら削除するという形に変更しました。

良かった点

属人性を排除できた

リプレイス前は、慣れている人が作業すると早く終わるけど、触ったことない人が作業をするととても時間がかかるという状態でした。

なので自然と PHP で魔改造された Wordpress を触ったことがある人にタスクが集まり、やがて PHP で魔改造された Wordpress の達人が誕生します。
徐々にありとあらゆるタスクに関して「達人にやってもらえば早いから、達人にやってもらおう」という流れになり、特定の一人の達人にタスクが集まる状態でした。こうなってしまうと

  • 特定の一人の達人がいなくなった時に、改修できる人がいなくなってしまう
  • 特定の一人の達人のスキルアップが阻害される

という問題が発生することが考えられました。

Middleman でリプレイスしたことにより、弊社のエンジニアが普段使っている Ruby での作業になりました。
改修時間の短縮に繋がっただけでなく、誰がやっても同じくらいの時間がかかる状態に改善することができました。

いらないものを消せた

今回のリプレイスのタイミングで、不要なものを消すことができました。具体的には

  • 使われていなさそうな機能
  • 3年以上古いプレスリリースなどの削除
  • 不要なページ

などです。
不要なページや古いプレスリリースには、現在では古くなってしまって正しくない情報なども掲載されていました。使われてなさそうな機能には、保守が少し面倒な機能も存在していたので、一掃できてとても良かったと思います。

プレスリリース投稿などの業務フローを整理できた

弊社のコーポレートサイトでは、プレスリリースやIR情報の公開などの業務が存在します。

今までは動作確認なども行われず PHP で魔改造された Wordpress から多分動くと思うからリリースしようぜといったようなノリでリリースされていました。また誰が、何を、どこまで作業するのかが明確に決まっておらず、無駄なコミュニケーションコストが発生するという状況でもありました。

というわけで、リプレイス時にエンジニア・デザイナーの担当者広報担当者プレスリリース担当者のそれぞれで行う作業を明確に定めて、業務フローを作成しました。

辛かった点

痒いところに手が届かない middleman-blog

Middleman には middelman-blog というプラグインを利用したブログ機能が用意されています。 弊社のコーポレートサイトでは、プレスリリースの投稿部分で利用していますが、なかなかかゆいところに手が届かない印象でした。具体的には

  • ページネーションのデフォルトでは、1つ先のページか、1つ後ろのページにしか遷移ができない
  • 年度毎に用意した一覧ページでは、ページネーションを実装するのがつらい

などがありました。じゃあどうやって解決したのかと言うと、今回のタイミングでは実装しないことにしました。 もちろん Helper を用意してゴリゴリ書いて、テストの環境を用意してテストも書いて、自前で実装してしまうという選択肢もありました。

一方で「この機能本当に必要なんだっけ?」と思うところもあり、プロダクトオーナーと相談した結果、今回は実装しないという選択肢を取りました。

まとめ

少し大きめな技術的負債でしたが、強い気持ち持って返済することで

  • 改修時間の短縮はもちろん、属人性も排除できた
  • 「いるもの」「いらないもの」を整理して、「いらないもの」を一掃できた
  • middleman-blog は高機能なブログ機能を実装したい時には不向き
  • ついでにアクセス速度も爆速になった

などなど、様々なモノゴトを改善することができたので良かったです。

PageSpeedInsights の結果がこちら

Before ☠️

After 🎉

これからもめげずに地道にコツコツと技術的負債を返済していこうと思います。

最後になりますが、みんなのウェディングでは、一緒に働く仲間を募集しています!
技術的負債をやっつけるのにワクワクする人、 技術的負債では極力苦しみたくない人、そもそも技術的負債なんてつくるんじゃない!という人、それ以外の方でも興味のある方は、濱口(@jaru) までご連絡ください。