例えば、35件のクライアントサイトを管理している少数精鋭の開発チーム。どのサイトも問題なく稼働しており、サーバー環境も安定しています。外から見る限り、特に緊急の問題はありません。

しかし社内に目を向けてみると、以下のような運用上の問題が少しずつ表面化していくことは珍しくありません。

  • 半年前に退職した元シニア開発者に、現在もアカウント内のすべてのサイトに対するアクセス権が付与されたまま
  • WooCommerceサイトのステージング環境が現在の本番環境と同じ状態になっているのか誰も把握していない
  • クライアントサイトのプラグイン更新が溜まり、誰かに時間があるときに不定期で対応している

現時点では技術的な問題は起きていなくても、クライアントが増えるたびに、社内の運用は複雑になっていきます。管理する認証情報やステージング環境、アップデートに関する判断、担当者間の引き継ぎが増え、利用状況やパフォーマンス、コストについて確認すべきことも増えていきます。

WordPress制作会社では、事業の成長に伴い、サーバーの問題より先に運用上の課題が表面化することが少なくありません。この記事では、特に起こりやすい5つの問題とその原因、そしてKinstaを活用してより効率的な運用体制を構築する方法をご紹介します。

見えにくい問題「ワークフローの負債」

規模の小さい制作会社では、日々の業務を効率よく回すために、次のような簡便な方法を取り入れるのが一般的です。

  • アクセス権限を共有する
  • Slack上で承認を行う
  • アップデートを手作業で行う
  • ステージング環境の運用方法を各自の記憶に頼る
  • 特定のクライアントに関する情報を1〜2人の担当者だけが把握する

クライアントが少ないうちは、チーム内で細かな情報まで把握できるため、こうした方法でも問題なく運用できますが、会社が大きくなるにつれて、負担が増していきます。

管理するサイトや外部スタッフ、環境、承認作業、メンテナンス業務が増えるほど、こうした方法では対応が難しくなります。サーバーのキャパシティにはまだ余裕があっても、チーム内では「誰が、何を、どのように進めるのか」が徐々に分かりにくくなっていきます。

これが「ワークフローの負債」です。業務の進め方が明確に定められておらず、その都度手順を思い出さなければならない状態が続くことで、この負債は蓄積していきます。こうしたワークフローの負債は、日々のさまざまな業務に現れます。ここからは、制作会社の成長に伴って特に起こりやすい5つの問題と、それぞれの改善方法を見ていきましょう。

1. アクセス権限の問題─必要以上の権限を付与

規模の小さい制作会社では、手間を省くために幅広いアクセス権限を付与しがちですが、会社の成長とともにその利便性がリスクへと変わっていきます。例えば、退職した社員のアクセス権限がいつまでも残っていたり、クライアントが本来操作する必要のない環境にアクセスできたりするケースです。

実際に情報漏洩などの問題につながることはまれですが、それよりも、誰かが取り返しのつかない変更を加えるまで、気づかれないリスクとしてアカウント内に残り続けることのほうが問題です。

より適切な運用を行うには、それぞれの担当業務に応じて必要なアクセス権限だけを付与することが重要です。MyKinstaのユーザー管理では、企業またはサイト単位でアクセス権限を設定でき、それぞれに必要な役割を割り当てることができます。

MyKinstaでサイトや各種機能へのユーザーおよび企業のアクセス権限を設定
MyKinstaでサイトや各種機能へのユーザーおよび企業のアクセス権限を設定

日常的なWordPressの管理作業においては、MyKinstaからWordPress管理画面に自動でログインできるのも便利です。この機能により、ログイン情報をチーム内で共有する必要性を減らすことができます。MyKinstaで適切なアクセス権限を持つユーザーであれば、WordPress管理者のログイン情報を共有することなく、WordPress管理画面にログイン可能です。

2. ステージング環境の混乱─どれが最新の環境かわからない

チームの成長に運用体制が追いつかなくなると、ステージング環境の管理が複雑になっていきます。一人がサイトのリニューアル用にステージング環境を作成する一方で、別の人が本番サイトに直接修正を加える、といったことが起こります。こうした作業が重なるうちに、どの環境が現在のサイトの状態を反映しているのか、誰も正確に把握できなくなってしまいます。

クライアントが5社程度なら、チーム内で状況を把握しておくこともできますが、20社ともなればそうはいきません。

このような混乱を防ぐには、各環境の用途を明確にすることが重要です。例えば、ローカル開発環境は構築とテスト、ステージング環境は社内レビュー、クライアントの承認、公開前の確認、本番環境は承認済みの変更のみを反映する場所など。

Kinstaの無料ローカル開発ツール「DevKinsta」を使えば、このようなワークフローを構築することができます。

DevKinstaを使って手軽にステージング環境を構築
DevKinstaを使って手軽にステージング環境を構築

また、Kinstaでは、各WordPressサイトに1つ標準ステージング環境が付属します。ステージングURLを統一しておくことで、クライアントや社内チームが確認すべき場所に迷うことがなくなり、レビューもスムーズに進められます。

MyKinstaでステージング環境を作成
MyKinstaでステージング環境を作成

環境間での反映方法も重要です。Kinstaでは選択的プッシュ機能を使って、ファイル、データベース、またはその両方を選択して環境間で反映できます。特にWooCommerceストアや会員制サイトなど、本番環境のデータが常に更新されるサイトでは、このように反映するデータを選べることが役立ちます。

MyKinstaの選択的プッシュ機能
MyKinstaの選択的プッシュ機能

より規模の大きなプロジェクトや慎重な対応が求められるプロジェクトでは、プレミアムステージング環境を利用することで、本番環境により近い構成でテストを行うことができます。アクセスの多いサイト、ECサイト、会員制サイト、パフォーマンスが重視されるサイトなどに特に有用です。

ただし、どれだけ便利なツールでも、チーム内で一貫した運用ができていなければ十分に活かせません。環境の命名規則やレビューのルール、プッシュ権限を明確にし、どの環境が最新なのか、誰が変更を本番環境に反映できるのかを全員が把握できる体制を整えましょう。

3. アップデートの滞留─メンテナンスだけで手一杯に

会社が成長していくと、いつの間にかプラグインのアップデートだけで一つの業務が成り立つほど、作業量が増えていることがあります。担当者がサイトの管理画面に一つずつログインしてアップデートを実行し、問題がないか確認して、次のサイトへ移る。この作業を繰り返します。クライアントサイトが40件ともなれば、毎週3〜4時間かかるかもしれません。

さらに、脆弱性への対応も必要です。管理するサイトが増えると、既知のセキュリティ上の問題がある古いプラグインを使用しているサイトがあっても、どのサイトが該当するのかすぐに把握できない可能性があります。

例えば、開発者1人が手動アップデートに毎週4時間を費やし、人件費を1時間あたり5,000円とすると、週2万円、年間では104万円に上ります。アップデートの運用を体系化することで、こうした作業コストの大部分を削減できます。

MyKinstaには、この問題への対策につながる2つの機能があります。

1つ目は、サイト一覧の脆弱性フィルターです。「サイト」画面のドロップダウンを使って、脆弱性のあるプラグインやテーマが検出されたサイトを絞り込むことができます。

脆弱性のあるプラグインをフィルタリングして効率的に更新
脆弱性のあるプラグインをフィルタリングして効率的に更新

2つ目は、Kinsta自動アップデート(1環境あたり月額3ドル)です。更新前後のスクリーンショットを比較するビジュアルリグレッションテストが組み込まれており、表示に問題が発生した場合には自動的にロールバックが行われるため、安全に更新作業を自動化することができます。

Kinsta自動アップデートの詳細
Kinsta自動アップデートの詳細

また、アクセスが集中する時間帯やメンテナンスモード中を避けて更新を実行するよう日時を指定できるため、更新によって一時的に表示が崩れた場合でも、訪問者の目に触れる可能性を抑えることができます。

自動更新スケジュールの変更
自動更新スケジュールの変更

独自のメンテナンスワークフローを構築したい場合は、Kinsta APIを利用できます。アカウント内のすべてのサイトのプラグインやテーマに関するデータをAPI経由で取得できるため、サイトごとに管理画面を開くことなく、管理する全サイトの更新状況を一度に確認することができます。

4. 引き継ぎの問題─オンボーディングとオフボーディングで見える運用上の課題

クライアントのオンボーディングとオフボーディングでは、制作会社の運用体制がどれだけ整っているかがはっきりと表れます。

新規クライアントとの契約が決まると、サイトを移行し、ステージング環境を作成してアクセス権限を設定し、担当者を割り当て、管理画面で適切なラベルを付ける、といった作業が発生します。運用体制が整っていれば、毎回同じ手順で進めることができます。そうでなければ、その都度少しずつ異なる方法で対応することになり、こうした小さな違いが積み重なって運用上の負債につながります。

例によって、クライアントが5社程度なら、その場に応じた対応でも問題ないかもしれません。ある開発者が使用しているプラグイン構成を覚えていて、あるプロジェクトマネージャーがログイン情報の保管場所を把握している、といった方法でも対応できます。しかし、クライアントが40社ともなれば、個人の記憶に頼った運用は成り立ちません。

オフボーディングはさらに複雑になりがちです。クライアントとの契約が終了すると、サイトをクライアント側のサーバー環境へ移行し、WordPressサイトから制作会社側のログイン情報を整理し、ステージング環境を停止して、アクセス権限が残っているユーザーを確認する必要があります。そのうえで、重要なデータや情報を失うことなくサイトを引き渡さなければなりません。

Kinstaでは、オンボーディングとオフボーディングの両方をより体系的に進めることができます。

無料サイト移行サービスを利用すれば、オンボーディングで特に負担の大きいサイト移行作業を任せることができます。その後は、ステージング環境の作成、アクセス権限の割り当て、サイトへのラベル付けという一貫した手順でセットアップできます。ラベルを使用すれば、クライアント、サービスプラン、契約状況などに応じて管理するサイトを整理できます。

Kinstaでサイト移行を申請
Kinstaでサイト移行を申請

オフボーディングでは、サイトの譲渡ツールを利用して、スムーズにサイトを引き渡すことができます。サイトは別のMyKinstaアカウントに譲渡できるほか、MyKinstaアカウントを持っていないユーザーに譲渡することも可能です。その場合、譲渡先のユーザーにはアカウント作成の案内が届きます。MyKinstaで管理しているDNSレコードもサイトとともに移行され、Redisやプレミアムステージング環境などのアドオンも自動的に引き継がれます。

多数のクライアントをオンボーディングする制作会社では、Kinsta APIを活用することで、新規WordPressサイトの作成、ステージング環境の構築、アクセス権限の設定を自動化することも。クライアントごとに繰り返し発生する管理画面での手作業を減らし、オンボーディングを効率化できます。

5. 可視性の問題─利用状況やボット、クライアントのコストを説明しづらくなる

クライアントサイトのリソース使用量が増えている一方で、コンバージョンや売上に変化がなければ、制作会社は明確な成果がないままコストが増加した理由をクライアントに説明しなければなりません。

何が使用量の急増を引き起こしたのかをすぐに把握できなければ、その説明はさらに難しくなります。キャンペーンによって実際の訪問者が増えたのかもしれません。AIクローラーがサイトの大部分を巡回した可能性もあれば、不要なボットが同じページに繰り返しアクセスしていた可能性もあります。検索エンジンのクローラー、監視ツール、実際の訪問者など、さまざまなトラフィックが同時に影響していることもあります。

ここで重要なのは、すべての自動トラフィックが「悪」ではないという点です。検索エンジンはクライアントサイトをクロールする必要があり、稼働状況を監視するツールも定期的にサイトへアクセスします。EC、セキュリティ、外部サービスとの連携に使用するツールの中にも、自動アクセスを必要とするものがあります。すべてをブロックすれば別の問題が生じる一方、すべてのボットを無条件に許可すれば、リソース使用量の管理やその増加理由の説明が難しくなります。

クライアントに適切な説明をするには、まずトラフィックの実態を把握できることが重要です。

Kinstaのボット対策機能では、サイトごとに自動トラフィックへの対策を設定できます。必要な対策はクライアントサイトによって異なります。AIクローラーをブロックしたいサイトもあれば、監視ツールや外部サービスとの連携、WordPressで一般的に使用される自動処理などを許可する必要があるサイトもあります。

また、この機能では自動トラフィックの状況を確認できるため、使用量が急増してから原因を推測するのではなく、各サイトに自動トラフィックがどのような影響を与えているかを把握できます。

過去24時間のトラフィックをタイプ別に分類したリクエスト内訳チャート
過去24時間のトラフィックをタイプ別に分類したリクエスト内訳チャート

分析」画面の「キャッシュ」タブでは、さらに詳しく状況を把握できます。トラフィックが増加しているにもかかわらずキャッシュの効果が低下している場合、単純にサイトへのアクセスが増えたと判断するのではなく、キャッシュされていないリクエスト、ボットによるアクセス、サイト側の設定など、原因を切り分けて確認できます。

リクエストの処理状況を示す「キャッシュ内訳」チャート
リクエストの処理状況を示す「キャッシュ内訳」チャート

利用状況に変化があれば、その理由をクライアントにわかりやすく説明する必要があります。トラフィック、ボット、キャッシュ、コストの関係を可視化できれば、クライアントにも状況を説明しやすくなります。こうした情報がなければ、使用量が急増するたびに原因を推測することになってしまいます。

運用体制を整えて事業の成長に対応

制作会社が軌道に乗った時、最初に問題が生じるのは必ずしもサーバー環境ではありません。むしろ、それまで日々の業務を支えてきた属人的な運用方法が、規模の拡大に対応できなくなるケースが多くあります。

成長する制作会社に必要なのは、むやみに複雑な仕組みを導入することではありません。アクセス権限の割り当て、変更内容のテスト、アップデートの管理、クライアントのオンボーディング、サイトの譲渡、利用状況の説明など、日常的に行っている業務をより明確なルールと仕組みで運用できる体制が重要です。

クライアントの増加に現在の運用体制が追いつかなくなってきたら、Kinstaの制作会社向けプランエージェンシーパートナープログラムをぜひお試しください。Kinstaは、成長中の制作会社に必要な運用体制の構築を支援しています。

Joel Olawanle Kinsta

Kinstaでテクニカルエディターとして働くフロントエンド開発者。オープンソースをこよなく愛する講師でもあり、JavaScriptとそのフレームワークを中心に200件以上の技術記事を執筆している。