自社製CMSからの脱却：10件のWebサイト再構築に学ぶ運用重視の技術選定 - NIFTY Tech Day 2025

2025年2月8日に開催したNIFTY Tech Day 2025の登壇資料です。
https://techday.nifty.co.jp/2025/

登壇者
ニフティ株式会社
石川 貴之

Transcript

1. 自社製CMSからの脱却 10件のWebサイト再構築に学ぶ 運用重視の技術選定 2025/02/08 NIFTY Tech Day 2025 ニフティ株式会社 石川 貴之 Copyright © NIFTY Corporation All Rights Reserved.
2. 自己紹介 ニフティ株式会社 会員システムグループ N1! Cloud Architect 石川 貴之 (Ishikawa Takayuki) 担当業務 • AWS/GCP組織管理 • 技術寄りSaaS管理（Notion, GitHubなど） • 自社WEBサービスの設計、バックエンド 2

3. プロジェクト 概要 3

4. 自社製CMS(nifty CMS)が持つ機能（ざっくり版） 4

5. 移行対象規模 対象サイト数：11サイト サイト規模： • ファイルサーバー：平均 150ページ　※SSG出力ページ除く ◦ 多いサイトだと1000ページほど ◦ 各サイト内の各サービスページは時代、デザイン、レイアウト、構造がバラバラ • CMS管理テーブル：平均 8テーブル 5

6. プロジェクト体制 • 制作担当：約10名 • 運用担当：約30名 ◦ サイトごとに担当は異なる • エンジニア2名（兼務） ◦ 移行対象サイトのコードは初見 • 設計からPMFまではアジャイル、開発・移行作業はウォーターフォール • スクラムはやらない ◦ サイトごとに関係者違うし、開発も専任ではない ◦ 複雑(Complex)な問題はなく、Simpleが積み重なってComplicatedになってるだけ ◦ 参考：https://en.wikipedia.org/wiki/Project_management#Project_complexity PM・開発 
 サイト運営（受け入れ先） 
 プロジェクトの進め方 
 6

7. プロジェクト期間と開発工数 構成検討と実証実験 • 第一次：EJS+Gulp構成で3サイト試作（5月〜8月） • 第二次：外部委託検討・WordPress構成検討（9月〜11月） • 第三次：HeadlessCMS+Jamstack構成検証（12月〜3月） フェーズ1（2022年4月〜2023年3月）: 4人月/1年 Astro+microCMS構成に書き換えて切り替え • 新環境講習会実施（5月〜7月） • 11サイト移行 フェーズ2（2023年4月〜2024年9月）: 11人月/1年半 今日話すの はココ！ 7

8. プロジェクト マネジメント 方針決めと各所調整 8

9. 20年物の自社製CMSを取り巻く課題 • nifty CMSを使った運用の経験しかない人が多数いる • 過去にnifty CMS移行PJが失敗した実績があり「現状維持」志向が強い ◦ いままでnifty CMSから完全に移行できたサービスは存在しない Salesforceの テーブル設計と Apexに似てる 開発における課題 • 社内独自システム、テンプレ言語、オンボーディングにも時間がかかる • 外部委託メインで開発運用されていたためシステムの保守・改修が困難 運用における課題 • 使用ミドルウェアの多くが EOL（サポート終了）超過 • ファイルアップロード形式なのでリリース作業が煩雑でミスが起きやすい 組織的な影響 9

10. プロジェクトの基本方針とリスク管理戦略 👉 全社的な取り組みとしての位置付けてもらう • 上長の本気度確認 ◦ リップサービスではなく本気でやるつもりなのか、あとでハシゴ外しはないか • 統括部レベル・会社レベルの課題として共有してもらう ◦ 組織課題にすれば協力しないほうが悪であり、逃げられない状況にする ◦ 今回課題共有のための調整はおまかせでやってもらえました 過去と同じ轍は踏まない 10

11. 成果物に関するの基本方針 👉 わかりやすい価値提供を行うことで前に戻りたくないと思ってもらう • わかりやすい価値 ◦ 　　　 開発：一般的な開発者体験 (DX) ◦ 　　　 経営：安い方が正義 ◦ 　　　 運用：便利な方が正義（できなくなることよりできることが勝ればよい） • パフォーマンスとコストと利便性の両立 ◦ 高アクセス負荷対応、運用コストの大幅な削減、利便性でケチらない • 円滑な移行サポート ◦ 各サイトごとの業務分析と要件把握 ◦ 学習が必要な部分は講習や都度ハンズオンの実施 あとで問題に なりそうな所は 丁寧に 早い・安い・うまい(楽) 
 早い
 安い
 うまい 
 11

12. 技術に関する基本方針 👉「時間 > コスト > スコープ」の優先度で判断 ◦ 現状が過剰なのにでとにかくスリムにする、一旦全部ない状態から考える ◦ 運用に手がかからない構成にする 「完璧を目指すよりも終わらせろ」の精神 
 低いところに揃えない 
 👉 組織的ITリテラシーの向上 ◦ 初めはできればいいかなくらいだったが、検証の末に必須になった ◦ これができないと現代的な開発手法の導入が難しい ▪ 便利なものが使えないと運用でカバーや追加開発が増える 12

13. 技術選定 優先度決め 13

14. 再掲：自社製CMS(nifty CMS)が持つ機能 14

15. 全部設計が終わってから見た格言 ※「流行り」という単語はいろいろな捉え方があるが、利用者の母数・コミュニティが大きいもの、数年は注目され続けているものと認 識している どうでもいいことは流行りに従い、重大なことは標準に従い、ド メインのことは自ら設計する
 – 郡山 昭仁
 参考：https://koriym.github.io/blog/2023/03/28/phperkaigi2023/ 15

16. 技術選定の優先度とアプローチ 引越ししやすさ、変更・拡張しやすさ • アーキテクチャ設計 ◦ URL、ディレクトリ構造 ◦ 関心の分離（ロジック /コンテンツ） ◦ コンポーネント分割粒度 ◦ テーブル設計、API設計 ◦ CI/CD 規模次第だが取り返しがつきやすいもの • フロントエンド技術 ◦ Webフレームワーク ◦ テンプレートエンジン ◦ コンポーネント設計手法 • インフラストラクチャ ◦ CMS ◦ ホスティングサービス • マーケティング要素 ◦ SEO どうでもいいこと（トレンド追従） 
 重要なこと（標準準拠） 
 ドメインのこと（独自設計） 
 • 法的要件 • セキュリティ要件 16

17. URL・ディレクトリ構成方針 17
 URL • .htm .html をURLから一掃する ◦ 参考：https://www.w3.org/Provider/Style/URI.html ディレクトリ構成 • URLに影響を与えない部分を整理 ◦ 名と体が合っていないコンポーネントを修正 ▪ コンポーネント名をPascalCaseに統一、名前には構造体名を入れる ◦ Layout機能の導入し冗長な記述を除去 ▪ nifty CMSにはなかった • Atomicデザインにはしない ◦ デザイン変更なしの移行案件には適さない 認知負荷 の軽減 既存資産の 流用重視 引越し やすさUP
18. アーキテクチャ データ・運用フロー 18

19. 移行前：nifty CMS構成 ドメインごとに LBがある 19

20. 第一次検討：EJS + Gulp 特徴 • 最小工数で書き換えが可能（とにかく早く終わらせる） • ゼロベースで最小限の機能だけ作る、 CMSも用意しない • 単一ファイルでビルド可能 課題 • 動的コンテンツ非対応 • 拡張性・将来性の低さ ◦ 20年前から10年前まで技術スタックが進んだが、それでもだいぶ古い ◦ 11ty + Nunjucksも検討したが最善とは言い難い • 手動アップロードなのでリリース作業がミスしやすいのは変わらず 20
 MVPを作って 利用者の 反応を見る
21. CMSをやめてcsvやjsonで管理運用できないか検証 → さすがに運用に無理がある 最初期構成 
 21

22. SSRに対応するなら別途動的構成組んで Fargeteを用意することになる → もっと楽したい！ 最初期構成+CMS 
 22

23. 第二次検討：WordPress + EJS + Gulp関連構成 特徴 • 外部委託メイン • 将来的にWordPress.comにすべて寄せる • 既存htmlは一旦SSG維持 課題 • 外部委託コスト ◦ ページ数が多い、レイアウトやデザインがバラバラなためコスト高 • アーキテクチャの一貫性欠如 ◦ 本当に運用しながら htmlをWordPressに移していけるのか実行性に懸念 • WP本体とプラグインバージョン問題が一生ついてまわる 23

24. WordPressでまとめることで外部委託できないか　 →　見積もりが高額 サイト構造が WP向きでは なかった 24
 WordPress構成 

25. 第三次検討：HeadlessCMS + Jamstack 特徴 • GitOps • SSG/SSR両対応 • 複数環境自動作成 • よくある構成なので学習コストが低い 課題 • 制作部隊の学習コスト ◦ 主にローカル開発環境を用意と GitOpsへの慣れ ▪ 幸いGitでコード管理はしていた （デプロイとは紐づいてないため相違はある） 25
 過去に制作部隊に 異動した開発者が バージョン管理は 広めてくれていた
26. Cloudflareが個人的に好きなので組んでみた TCO 0円構成 Egress無料は最強！仕事で使うなら ProかBusinessプランにはしたい Cloudflare導入 からになるため 今回は保留 0円構成 
 26

27. microCMSで運用の利便性を確保、 Amplifyにまとめたシンプルな構成 図にはないが、一部 Cloudfront+S3構成にしているパスもあり 採用構成 
 27

28. ホスティング環境 フレームワーク CMS 28

29. ホスティング環境の選定 候補プラットフォーム評価 • Cloudflare ◦ Egress無料、画像最適化機能 ◦ SAML/SSO対応にはEnterprise契約 が必要 • Netlify/Vercel ◦ 充実した機能セット ◦ 一定以上の規模はコストに懸念 • AWS Amplify ◦ 必要十分な機能セット、社内の技術ス タックに合致 ◦ Gen2で多数のFWのSSRに対応 技術要件 • GitOps対応 • SSG/SSR対応 • CDN/エッジコンピューティング機能 • リダイレクト制御機能 運用要件 • 低コスト • ブランチ・PRごとに自動環境作成 制作部隊の感触が すごくよかった 29

30. ホスティング環境の選定 → Amplifyに決定 • 引継ぎ容易性 ◦ 社内で多くの利用実績がある AWS • 開発利便性 ◦ 他よりも低いが必要十分は満たしている ▪ GitOps、ブランチ・PRごとに自動環境作成、インフラ運用不要 ◦ Gen2から多数のフレームワークの SSRに対応 • コスト ◦ 最安ではないが気にしなくていいレベルの価格 ◦ Cloudfrontのコストが問題になってきたら引越しも検討 30

31. フレームワーク選定 技術要件 • 既存JavaScript資産との互換性 ◦ JQueryや素のJSとの同居が前提 • 学習コストが高くない 運用要件 • 情報提供コンテンツがメイン （HTML中心の構成） 候補フレームワークざっくり評価 • Next.js ◦ 普及率は一番 ◦ TSXは見た目がほぼJS ◦ 既存JSコードとの統合が複雑 • Nuxt.js ◦ Vueを使いたいなら選択肢となる • Astro ◦ Frontmatterによる関心の分離 ◦ 複数FWコンポーネントのサポート • SvelteKit ◦ ファイル分割による関心の分離 31
 Webアプリケーションでは なく、Webサイトを作りた い
32. フレームワーク選定 → Astroに決定 • 引継ぎ容易性 ◦ Node.jsフレームワーク、学習コストは低い • 制作部隊への受け入れやすさ ◦ Frontmatterでロジックとhtmlを分けたテンプレート ◦ JQueryとほぼ意識せず同居可能 • 将来性 ◦ 複数FWコンポーネントをサポート ◦ 正直ギャンブル （現状勝ってる） ▪ AstroはState of JS 2024のメタフレームワークで2位に上昇 https://2024.stateofjs.com/ja-JP/libraries/meta-frameworks/ 32

33. CMS選定基準と評価 技術要件 • カスタム可能なスキーマ設計 • カスタム可能なロール管理 • 複数環境対応 • SAML/SCIM • 監査ログ 運用要件 • 日本語インターフェース対応 • 直感的な操作性 候補製品のざっくり評価 • microCMS ◦ 使いやすい、SAML対応、日本語 • Newt ◦ 使いやすい、日本語 • Contentful ◦ 多機能、Premiumプラン必須 • Prismic ◦ コンポーネント管理メイン • WordPress/Shifter ◦ WPが好きだったら選択肢になる • Strapi ◦ 多機能、サーバー運用必須 33

34. CMS選定基準と評価 → microCMSに決定 • 使いやすさ ◦ 日本語対応、ドキュメントを見ずに大抵の操作が理解できた ◦ 公式ドキュメントやブログ作例が豊富 • 運用の幅が広がる機能性 ◦ フィールドの自由度が高く、 部分的拡張がしやすい ◦ 公開中の記事に下書きが作れる ◦ 複数環境対応（Businessプラン以上） • コスト ◦ 他のCMSよりも安くはないが特別高いわけではない ◦ 投資すべき場所と判断 34

35. まとめ 35

36. Before After クラウド FJcloud-V AWS ホスティング先構成 LB+サーバー CloudFront+Amplify フレームワーク Struts Astro テンプレート言語 Velocity改造版 / JSP Astro 複数環境対応 2 ※一部共用利用 50 ※Amplify上限 デプロイ方法 ファイルアップロード GitOps CMS nifty CMS(独自) microCMS CMS認証 nifty ID(自社) SAML ビルド時間 - 大幅改善 CWV - 大幅改善 コスト(SaaS費用含む) - 76%削減 高アクセス負荷対応力 - 100倍以上 開発オンボーディング 1ヶ月以上 数日 36

37. プロジェクトの成功要因 組織的な課題化は強い！ • 課題認識の共有により初手の話が早かった • 長期プロジェクトだが順次サイト移行できていて成果が出ていたのも良かった 37
 プロジェクトマネジメント パフォーマンスとコストと利便性の両立 
 流行りのアーキテクチャを採用、コストをかける場所の判断 • サーバーレス・SSG構成により高パフォーマンス、低 TCO、低学習コスト • CMSは多機能性より使い勝手を優先 組織的ITリテラシの向上 
 低いところに揃えない！学習対効果が高いなら学習してもらう • ツールに運用を合わせる働き方（ microCMSへの切り替え）、GitOps導入
38. Copyright © NIFTY Corporation All Rights Reserved.