24のサービスを説明し、技術コンテンツを蓄積し、韓国語・英語・日本語で顧客と出会うウェブサイト。IXCは増え続けるページを継続的に管理するために、別のCMSではなくMDXベースのコンテンツ構造を選び、マネージドクラウドとエンタープライズ級のCDN、WAF、マルウェア検知を組み合わせました。
ウェブサイトに載せるべき内容は増えていました。サービスの範囲は広がり、プロジェクトで得た経験は事例とインサイトとして残す必要がありました。韓国語だけで説明していた内容を、英語と日本語でも伝えなければなりませんでした。
だからといって、サイトを管理する仕事まで同じ速さで増やすわけにはいきません。新しいサービスを一つ紹介するために複数の管理画面を行き来したり、3言語を修正したかどうかを毎回記憶に頼ったりするやり方は、長くは続けられません。
今回のリニューアルで解きたかった問題はここにありました。載せられる内容は増えても、次の内容を追加し直す仕事は複雑にならないウェブサイト。
いまご覧いただいているIXCのウェブサイトは、その目標をもとに企画し構築した自社プロジェクトです。
会社が変わった分だけ、ウェブサイトの役割から定め直しました
IXCはソフトウェアQA、クラウド、ペイメント、カスタマーエンゲージメントの4部門でサービスを提供しています。ウェブサイトはこれらの事業を紹介しながら、訪問者が自分の課題に合うサービスを見つけられるように支える必要がありました。
たとえば、リリースを控えたチームとクラウド移行を検討しているチームでは、確認したい内容が違います。前者はどのリスクを検証し、何を成果物として受け取るかが重要です。後者はどこまで移行を任せられ、その後の運用がどう続くのかを知りたいのです。
すべてのサービスを一文で広く紹介するのではなく、各サービスの問題と範囲を分けて説明する方向を選びました。そうして分かれたサービス詳細が24件です。
コンテンツの役割も分けました。サービスページでは任せられる仕事を説明し、事例では実際の選択と遂行の過程を示します。インサイトは、技術を導入したり運用したりするときに必要な判断基準を扱います。
私たちが期待した訪問の流れは単純です。記事を通じて問題を理解した人が、関連する事例でアプローチを確認し、自分に必要なサービスまでたどり着けること。初回の訪問で問い合わせに至らなくても、次の意思決定のときにまた訪れる理由のあるウェブサイトをつくろうとしました。
ページは増えるのに、なぜCMSを外したのか
コンテンツの多いウェブサイトなら、まずCMSを思い浮かべがちです。編集画面で記事を書き、画像を入れ、公開するやり方には明確な利点があります。私たちも最初はCMSを導入しました。
しかし運用の構造を整理するうちに、より重要な問いが生まれました。コンテンツの正本をどこに置き、変更をどの経路で確認して公開するのか。
IXCにとっては、記事の本文だけを管理することより、サービス情報、言語別の原稿、画面構成の関係を一緒に管理することが重要でした。開発とコンテンツの作業も、分かれた部署のあいだで引き継ぐのではなく、近くでつながっていました。
この条件で選んだ方法が、別のCMSを運用せず、MDXファイルをコンテンツの正本として使うことでした。
MDXは、文書形式の本文のなかに再利用できる画面要素を一緒に置ける形式です。長い記事は文書のように書きながら、必要なところには画像や説明ブロック、表や案内要素を組み合わせられます。
これはデザインをあきらめてテキストだけを載せるという選択ではありません。原稿は原稿として管理し、繰り返し現れる画面表現は共通のコンポーネントとして管理するという選択です。
ファイルベースの運用がどの組織にとっても便利なわけではありません。非開発者の編集者が多い組織や、複雑な承認・予約公開が必要な組織では、CMSのほうが適している場合があります。IXCは、自分たちの編集主体と開発のやり方に合わせて、別途維持しなければならないシステムを減らす側を選びました。
軽くしたかった対象は、ウェブサイトの画面だけではありません。サイトを運用し続けるためにチームが担う仕事も含まれていました。
3言語をつくることより、3言語を合わせ続けることが重要でした
韓国語・英語・日本語でウェブサイトをつくる仕事は、最初の翻訳では終わりません。
サービスの範囲が変われば、3言語の説明を一緒に見直す必要があります。新しい事例ができれば、各言語の読者が同じプロジェクトを理解できなければなりません。韓国語では提供しないと変更した項目が英語のページに残っていれば、それは翻訳の問題ではなく、異なる約束をしているという問題です。
そこで3言語を離れたサイトのように管理するのではなく、同じコンテンツに属する言語別の原稿としてまとめました。共通情報と言語別本文の関係をはっきりさせる方式です。
必須言語の原稿の欠落は、ビルドの過程で検査するようにしました。公開に必要な3言語が揃っていなければ、配信前に表面化するようにしたのです。
もちろん、原稿ファイルがあるという事実が翻訳の正確さまで保証するわけではありません。自動検査で確認できる欠落と、人が読んで初めて判断できる意味・表現の違いは区別する必要があります。
私たちが立てた運用原則はその区別にあります。繰り返し確認できることはシステムに任せ、サービスの意味が正しく伝わっているかは人が判断します。
多言語運用を特別な追加作業として残すのではなく、コンテンツを一つ公開するときに自然に通る基本の過程にしようとしました。
ページごとに違う画面より、一貫して読める構造を選びました
サービスと言語が増えると、デザインも運用の問題になります。新しいページをつくるたびに見出し、カード、表、ボタンの規則を決め直していると、修正すべき基準も増え続けます。
IXCはデザインシステムをもとに、繰り返し現れる画面要素の基準を共有する方向を選びました。原稿の内容が違っても、訪問者が情報を読み、次の行動を見つける方法は慣れたままに保つという選択です。
ここでの一貫性は、すべてのページを同じにするという意味ではありません。サービス紹介には範囲と進め方が、事例には背景と意思決定が、技術記事には説明と根拠が必要です。コンテンツの性格は生かしながら、表現の基本規則を共有するということです。
3言語では文の長さと改行も変わります。韓国語の画面がよく見えるという理由だけで英語と日本語まで完成したとは見なさないこと、共通コンポーネントと各言語の実際の画面を一緒に確かめることが、重要な基準になりました。
ウェブサイトを知識が積み上がる場にしようとしました
今回のリニューアルにおいて、インサイトは会社の知らせをより頻繁に載せるための掲示板ではありませんでした。
リリース前には何を検証すべきか、クラウド移行ではどのリスクを先に見るべきか、障害に備えるには何を準備すべきか。IXCが現場で扱う問いを、読者が自分の状況に当てはめられるコンテンツとして残す場です。
こうした記事が公開当日にだけ読まれて終わるのでは惜しい。関連する記事とつながり、技術と運用の条件が変わればあらためて見直せる必要があります。時間が経っても見つけて直せる構造が必要でした。
MDXベースのコンテンツ運用を選んだ理由には、この長期的な蓄積も含まれています。サービス紹介と事例、インサイトが増え続けても、原稿を管理する基準は一貫させたいと考えました。
検索を通じて訪れた読者にとっても、まず必要なのは答えです。技術の名前を繰り返すのではなく、どんな問題から出発し、何を比較し、なぜその方法を選んだのかを説明すること。ウェブサイトがIXCの知識資産として残るために守りたい編集の方向です。
コンテンツは自分たちで管理し、インフラはマネージド環境へ移しました
コンテンツをファイルで管理するからといって、サーバー運用まですべて自分たちで担う必要はありません。
私たちが直接コントロールしたかったのは、サービスの説明、コンテンツの構造、ユーザー体験、そして変更を公開する基準でした。一方で、サイトを運用するために必要な基盤環境まですべて別途管理することは、別の種類の負担でした。
そこで配信環境はマネージドクラウドへ移しました。コンテンツとアプリケーションは自分たちで管理しつつ、インフラ運用にはマネージド環境を活用する方式です。
この決定では、サーバー料金だけでなく運用にかかる仕事も一緒に考えました。サイトが公開された後も、修正と点検は続きます。基盤環境に割く注意を減らし、コンテンツとサービスの改善に集中できる構成のほうが、私たちには合っていました。
マネージド環境を選んだからといって、運用責任がなくなるわけではありません。アプリケーションの動作とアクセス権限、公開されるコンテンツを確認する仕事は、依然として私たちの役目です。任せられる部分と自分たちが責任を持つ部分を分けた選択に近いものです。
海外からのアクセスとセキュリティを、別々の層で扱いました
3言語を提供するウェブサイトなら、アクセス環境も国内だけに合わせて考えることはできません。コンテンツを届ける経路と、公開されたアプリケーションを守る仕組みを一緒に構成しました。
コンテンツ配信にはエンタープライズ級のCDN
キャッシュできるコンテンツを分散した配信網から提供できるよう、エンタープライズ級のCDNを適用しました。オリジンサーバーがすべてのリクエストを直接処理する負担を減らし、海外の訪問者にもコンテンツを効率よく届けるための構成です。
ただし、CDNを適用したという事実だけで、すべてのページが同じ速さで開くわけではありません。キャッシュ可能なコンテンツと動的に処理するリクエストを区別し、実際のアクセス環境で結果を確かめる必要があります。
公開リクエストの保護にはWAFとDDoS防御
WAF（ウェブアプリケーションファイアウォール）とDDoS防御も適用しました。WAFは入ってくるウェブリクエストを検査し、攻撃性のあるリクエストを除きます。DDoS防御は大量の攻撃トラフィックに対応する役割を担います。
会社紹介のサイトであっても、問い合わせのように外部の入力を受け取る接点があります。コンテンツをきちんと届けることと、公開された接点を守ることは、別の課題として扱いました。
運用環境にはマルウェア検知
マルウェア検知の機能も導入しました。リクエストを検査するWAFと、運用環境の悪意あるファイルを検知する機能は、それぞれ別の役割を担います。
どれか一つを適用すればセキュリティが完成するわけではありません。アプリケーションの更新、権限管理、安全なコードまで一緒に扱う必要があるという前提で、保護の層を構成しました。
配信は簡単にしつつ、公開前の確認は省きませんでした
更新が面倒だと、小さな修正も先送りになります。逆に、公開だけが簡単になって確認の手順がなければ、誤りまで簡単に配信されてしまいます。
IXCは、変更が検査を経てビルドと配信につながるように構成しました。コードとコンテンツを確認する検査に加えて、実際のブラウザでメニュー・検索・問い合わせフォームなどの主要な動作を点検する過程もつなぎました。検査は変更を上げるたびに自動で走り、検査を経た変更がメインブランチに統合されると、マネージド環境がビルドと配信を引き継ぎます。
公開前の確認には、IXCが製品として整えたリリース準備レビュー Qoretix（qoretix.com）を使います。ビルド一つを対象に主要な流れ三つを実際のブラウザで確認し、修正後にもう一度確認する基準を、このサイトにもそのまま適用しました。
重視したのは、自動配信そのものより、その前にどんな確認があるかでした。
新しいページ一つは、独立した文書としてだけ存在するのではありません。言語別の画面、一覧とリンク、共通コンポーネントのなかで動きます。変更した部分がきちんと見えるかだけでなく、訪問者が使っていた流れが保たれているかも確かめる必要があります。
自動検査は繰り返しの点検を担います。原稿に説得力があるか、説明が実際のサービス範囲と合っているかまで代わりに判断してくれるわけではありません。技術的な公開条件とコンテンツの編集判断を一緒に持っていく方式です。
今回のリニューアルの成果は、次の変更の扱い方にあります
新しいウェブサイトには、より多くのサービスを載せました。韓国語・英語・日本語のコンテンツを運用し、事例とインサイトを継続的に積み上げられる基盤も整えました。
このプロジェクトで重要だった変化は、いくつもの選択が一つの運用方式につながったことです。コンテンツの正本はファイルに集め、繰り返し現れる画面は共通の規則を使い、変更は検査と配信の流れを経て公開します。コンテンツ配信とセキュリティには、それぞれの役割に合った技術を適用しました。
私たちはこれを、構築直後の検索順位や問い合わせの増加で説明しようとはしません。そうした成果は、実際の運用データを積み上げて確認することです。今回整えたのは、コンテンツが増えていくウェブサイトを直し続け、運用し続けられる構造です。
これからの基準もここにあります。新しいサービスを紹介するとき、既存の説明を修正するとき、3言語で新しい事例を公開するときに、いまの構造が実際に仕事を減らしているかを確認し、改善していきます。
IXCが変えたのは、ウェブサイトの見た目だけではありません。会社が積み上げていくサービスと知識を、ウェブサイトに反映し続ける方法です。