ディレクション
投稿日:

最近のフロントエンドは”更新性格差”が激しい ─ ディレクターが知らない運用コストの落とし穴

株式会社ファストコーディングで営業を担当しています長谷川と申します。社長の大号令で全員ブログを書いていこうということになりまして、お客様とお話ししていて気づいたことを書いていこうと思っております。

最近、お客様からこんな相談が増えています。

「リニューアル時は良かったんですけど、半年後から更新が止まっちゃって…前の制作会社に聞いても『工数がかかるので別途見積もり』って言われるんです。」

Webサイトは作って終わりじゃないんですよね。むしろ、運用フェーズのほうが長い。でも、最近のフロントエンド技術は「作りやすさ」と「更新しやすさ」に大きな格差があって、それに気づかないまま進めると、運用段階で痛い目に遭うことが増えています。

実際にあった”更新が止まった”プロジェクト

去年、ある中堅企業様のコーポレートサイトリニューアル案件で、こんなことがありました。先方のご担当者様からこんなご相談が。

「半年前にリニューアルをしたけど、ニュースリリースを1本追加するだけで、毎回制作会社に依頼しなきゃいけないんです。簡単な文言修正も全部エンジニアの手が必要で…月の運用費が予算の3倍に。」

どうやら前回のリニューアル時に、制作会社からNext.jsにHeadless CMS、Vercelという、いわゆるモダンなJamstack構成で実装をされたようで、実際にはこういう構成になっていました。

  • CMSで記事を追加すると、ビルド処理が走る(5〜10分)
  • ビルドが失敗するとエンジニアの調査が必要
  • レイアウト変更は全てコード修正が必要
  • 画像の最適化処理が複雑で、担当者が理解できない
  • デプロイ環境の管理画面が英語で、エラー時の対処ができない

ご担当者様が「今回は最新技術で作りたい」とおっしゃったこともあったようで、こういう作りになったようですが、技術的には何も間違っていないんです。でもこれでは「更新しづらい」Webサイト。満足できないですよね。

「更新性」とは何か

いろいろお客様とお話ししていると、こういう会話になりました。

「でも、最新技術って、やっぱり良いものなんでしょ? なんでうちには合わなかったんですか?」

答えは簡単です。「更新性」を考慮していなかったからです。更新性というのは、いいかえますと「誰が、どれくらいの手間で、サイトを更新できるか」ということです。技術的に優れていても、運用フェーズで以下のような問題があれば、更新性は低いと言えます。

  • ビルド工程が必要(コンテンツ追加のたびにビルド→デプロイ)
  • 専門知識が必要(エラー対応にターミナル操作が必要)
  • ツールが複雑(管理画面が英語、専門用語だらけ)
  • 変更範囲が広い(小さな修正でも複数ファイルを触る)

これらは全て「運用コスト」に直結します。

どの構成が危険か ─ 更新性チェックリスト

営業をしていて、お客様から「この見積もり、大丈夫ですかね?」と相談されることがよくあります。以下のチェックリストを使って、提案内容を確認してみてください。

チェック項目高リスク(更新しにくい)低リスク(更新しやすい)
コンテンツ更新CMS → ビルド → デプロイ(10分以上)CMS → 即反映(1分以内)
エラー時の対応エンジニアの調査が必要管理画面でエラー内容がわかる
レイアウト変更コード修正が必要管理画面で変更可能
管理画面の言語英語のみ、専門用語が多い日本語対応、直感的
テスト環境なし、または別途費用標準で用意

このチェックリストで「高リスク」に該当する項目が多いほど、運用段階でコストが跳ね上がる可能性が高くなります。

「じゃあ最新技術は使わないほうがいいんですか?」

答えは「No」です。重要なのは、「誰が更新するのか」「どんな更新が発生するのか」を最初に明確にすることです。

たとえば、以下のようなケースなら、最新技術のメリットを十分に活かせます。

  • 更新頻度が低い(年に数回)
  • 専任エンジニアがいる(運用も担当できる)
  • パフォーマンスが最優先(ECサイトなど)
  • 制作会社と長期契約(運用も含めて一括で任せる)

逆に、以下のようなケースでは、従来型のCMSのほうが結果的にコストを抑えられます。

  • 更新頻度が高い(週に数回、毎日)
  • 非エンジニアが運用(マーケ担当者など)
  • 柔軟な変更が必要(キャンペーンごとにレイアウト変更)
  • 予算が限られている(運用費を抑えたい)

つまり、「技術の良し悪し」ではなく「使い方の適切さ」なんですよね。

クライアントに説明する時のポイント

Webディレクターの方がクライアントに説明する際、こんな風に伝えると理解していただきやすいと思います。

「最新技術は、スポーツカーみたいなものです。速くてかっこいいけど、維持費が高いし、運転にも技術が要ります。一方、従来型のCMSは、ファミリーカーです。速さでは劣るけど、誰でも運転できて、維持費も抑えられます。どちらが良いかは、『誰が運転するのか』『どこを走るのか』で決まります。御社の場合、更新は誰が担当されますか? どれくらいの頻度で更新が発生しますか?」

このように、技術の話を日常的な例えに置き換えると、クライアントも判断しやすくなります。

ハイブリッド構成という選択肢

最初の事例の後日談です。お客様と制作会社、弊社エンジニアで相談して、こんな構成に変更しました。

  • コーポレートサイト本体:WordPress(従来型)
  • 採用サイト:Next.js + Headless CMS(高速化重視)
  • ニュースリリース:WordPressで即時更新
  • 製品紹介ページ:Next.jsで静的生成(SEO重視)

つまり、「更新頻度が高い部分」は従来型CMS、「更新頻度が低く、パフォーマンス重視の部分」は最新技術、というハイブリッド構成です。

結果として、月の運用費が従来の3分の1に削減、担当者だけで90%の更新作業が完結、採用サイトのページ速度は従来比40%向上という成果が出ました。

まずはご相談ください

Web制作は、作って終わりではありません。むしろ、運用フェーズのほうが長く、コストもかかります。だからこそ、「誰が更新するのか」「どんな更新が発生するのか」を最初に明確にすることが大切です。

一般的なWeb制作会社さんだと、システム開発に関わるような要素を含めた方が見積もりが上がるので、最初にお伝えした事例のように、無駄にJavaScriptを用いた構成を提案しがちですが、弊社のようにフロントエンド専業であれば、そういったことはありません。

もし、今進行中のプロジェクトで「この構成、本当に大丈夫かな?」と不安に思われているなら、ぜひ一度ご相談ください。弊社のエンジニアと一緒に、運用フェーズまで見据えた最適な構成を提案させていただきます。

最後までお読みいただき、ありがとうございました。