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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介ニフティ株式会社会員システムグループ N1! Cloud Architect 石川貴之 (Ishikawa Takayuki) 担当業務 ● AWS/GCP組織管理 ● 技術寄りSaaS管理（Notion, GitHubなど） ● 自社WEBサービスの設計、バックエンド 2 

Slide 3

Slide 3 text

プロジェクト概要 3 

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

プロジェクト期間と開発工数構成検討と実証実験 ● 第一次：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 

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

技術選定優先度決め 13 

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

アーキテクチャデータ・運用フロー 18 

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

CMSをやめてcsvやjsonで管理運用できないか検証 → さすがに運用に無理がある最初期構成   21 

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

第三次検討：HeadlessCMS + Jamstack 特徴 ● GitOps ● SSG/SSR両対応 ● 複数環境自動作成 ● よくある構成なので学習コストが低い課題 ● 制作部隊の学習コスト ○ 主にローカル開発環境を用意と GitOpsへの慣れ ■ 幸いGitでコード管理はしていた（デプロイとは紐づいてないため相違はある） 25  過去に制作部隊に異動した開発者がバージョン管理は広めてくれていた

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

フレームワーク選定技術要件 ● 既存JavaScript資産との互換性 ○ JQueryや素のJSとの同居が前提 ● 学習コストが高くない運用要件 ● 情報提供コンテンツがメイン（HTML中心の構成）候補フレームワークざっくり評価 ● Next.js ○ 普及率は一番 ○ TSXは見た目がほぼJS ○ 既存JSコードとの統合が複雑 ● Nuxt.js ○ Vueを使いたいなら選択肢となる ● Astro ○ Frontmatterによる関心の分離 ○ 複数FWコンポーネントのサポート ● SvelteKit ○ ファイル分割による関心の分離 31  Webアプリケーションではなく、Webサイトを作りたい

Slide 32

Slide 32 text

フレームワーク選定 → Astroに決定 ● 引継ぎ容易性 ○ Node.jsフレームワーク、学習コストは低い ● 制作部隊への受け入れやすさ ○ Frontmatterでロジックとhtmlを分けたテンプレート ○ JQueryとほぼ意識せず同居可能 ● 将来性 ○ 複数FWコンポーネントをサポート ○ 正直ギャンブル（現状勝ってる） ■ AstroはState of JS 2024のメタフレームワークで2位に上昇 https://2024.stateofjs.com/ja-JP/libraries/meta-frameworks/ 32 

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

まとめ 35 

Slide 36

Slide 36 text

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 

Slide 37

Slide 37 text

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