自社製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 ニフティ株式会社 石川 貴之
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を使った運用の経験しかない人が多数いる • 過去の移行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. 技術選定 ホスティング先 デプロイフロー 17

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

19. 第一次検討：EJS + Gulp 特徴 • 最小工数で書き換えが可能（とにかく早く終わらせる） • 単一ファイルでビルド可能 • CMSも用意しない（ゼロベースから考える） 課題 • 動的コンテンツ非対応 • 拡張性・将来性の低さ ◦ 20年前から10年前まで技術スタックが進んだが、それでもだいぶ古い • 手動アップロードなのでリリース作業がミスしやすいのは変わらず 19

20. CMSをやめてcsvやjsonで管理運用できないか検証 → 無理でした 最初期構成 
 20

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

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

23. WPでまとめることで外注できないか　→　見積もりが高額 外注プラン は断念 外注WP構成 
 23

24. 第三次検討：HeadlessCMS + Jamstack 特徴 • GitOps • SSG/SSR両対応 • 複数環境自動作成 • よくある構成なので学習コストが低い 課題 • 制作部隊の学習コスト ◦ 主にローカル開発環境を用意と GitOpsへの慣れ ▪ 幸い多数はGitでコード管理はしていた（デプロイとは紐づいてない） 24

25. Cloudflareが個人的に好きなので組んでみたTCO 0円構成 Egress無料は最強！仕事で使うならProかBusinessプランにはしたい Cloudflare導入 からになるため 今回は保留 0円構成 
 25

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

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

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

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

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

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

33. まとめ 33

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

35. プロジェクトの成功要因 プロジェクトマネジメント • 組織的な課題化は強い！ ◦ 事業部レベルでの課題認識の共有による話が早かった ◦ 順次サイト移行ができていたため、現場や管理職からの悪い印象はなかった パフォーマンスとコストと利便性の両立 • 流行りのアーキテクチャを採用 ◦ サーバーレス・SSG構成による高パフォーマンス、低 TCO、低学習コスト • コストをかける場所の判断 ◦ 利便性を重視したCMSへの投資 組織的ITリテラシの向上 • 低いところに揃えない！学習対効果が高いなら学習してもらう 35

36. Appendix 36

37. CWV 37