ニジボックス主催のイベント「BUSINESS & CREATIVE」では、毎回ビジネスとクリエイティブに関する現場発・最前線の情報を発信しています。

今回のイベントテーマは『失敗しない！Webサービスのリニューアル』！
CX/UXストラテジスト、UIデザイナー、テクニカルディレクターと職種の異なる3名の登壇者から、
体験から得た貴重な知見を惜しむことなくご共有いただきました。
この記事では、気づきに満ちたイベントの内容を完全収録版としてお届けします。
Webサービスのリニューアルを検討している方はもちろん、幅広い職種の方にとって必見の内容です！

【オープニング】3つの視点でリニューアルのための「生きたコツ」をお届け

オープニングでは、今回モデレーターを務めるニジボックスの執行役員・丸⼭潤がイベントの概要を説明するところからスタートしました。

今回のイベントの大きな狙いは、Web制作に関わる職種の中でも3つの異なる視点で「リニューアル」について語っていただくということです。
1人目の登壇者の岡さんにはUXデザイナーの視点で、2人目の神田さんはUIデザイナー視点、そして3人目の池田さんからはエンジニア視点で、実践に基づいた解説をしていただきます。

【UXデザイナー視点】数百万人規模のアプリリニューアルで実践した失敗しないテクニック
株式会社メンバーズポップインサイト　岡 昌樹

まずは、CX/UXストラテジストとして数多くのアプリリニューアルに携わった経験のある岡昌樹さんが登壇しました。
Yahoo! JAPANのアプリ責任者やKDDI株式会社のUX戦略責任者などを歴任した経験から、大規模なリニューアルにおける実践的なテクニックを語っていただきました。

「そもそも私たちは何を一新（＝リニューアル）したいのか？」

リニューアルの意味を改めて辞書で調べると、「もとのものに手を入れて新しくすること。一新すること。」と書いてありました。

そこで一つ思い浮かんだ疑問が「そもそも私たちは何を一新したいのか？」ということです。
考えられるのは、UXやUI、バックエンドのオペレーションやシステム、あるいはビジネスも含めたこれら全部、ということもあるでしょう。

みなさんは、どうでしょうか？
「何を一新（＝リニューアル）するか」を決めながらやっていますでしょうか？

この「何を」を明確にしないとリニューアルは失敗しがちです。よくある失敗例を見てみましょう。

例えばUIが古くなってきたからリニューアルするというケース。
なんだか古くさいから新しくしたいというのは、気持ちは分かるけど、いまいち目的がはっきりしていません。
そして、UIを変えるつもりだったのに余計なところもあれこれいじってしまって、結局「誰の」「何を」解決したかったのか分からないまま進んでしまうことで失敗する…となりがちです。

他にも、「ビジネス的にこんな機能を新しく推していきたい」という理由ではじまるリニューアルもよく見かけます。
このパターンは、既存ユーザーからの大炎上、そしてロールバックという結果になることが多いです。
アプリ内で、ユーザーがやりたいことよりも会社の推したいことが目立ってしまって、ヘビーユーザーからの不満が爆発してしまうんですね。

では、どうしてユーザーからこんな不満が生まれてしまうのでしょうか？
それは、「脳は変化を嫌う」からです。
今まで時間を投資して得たものが役に立たなくなったとき、人は大きなストレスを感じるそうです。
アプリがリニューアルされて使い方が変わってしまったら、今まで時間をかけて覚えたことが無駄になって、不満を抱くということなんですね。

「顧客のJOBを把握しないと、リニューアルは必ず炎上します」

それでは、リニューアルにとって大事なことは何でしょうか？

それは、「顧客のJOBを把握すること」です。
顧客はそのアプリを通じて何を達成したいのか、これが分からないままにリニューアルをすると、必ず失敗して炎上します。
なので、ここからは、顧客のJOBを知るためのリニューアルプロセスを解説します。

既存サービスのリニューアルは、

1. ロイヤル顧客のJOBの把握
2. コンセプト評価
3. 既存と新規の体験マージ
4. プロトタイプでネガ最小化
5. 計測と判断

と大きく5つのプロセスで進めていきます。

まずは、ロイヤル顧客のJOBの把握から解説します。
これは、ユーザーに対してUXリサーチを通して「アプリで何を達成したいのか」、つまりJOBを把握する作業です。
具体的には、コンテキスト・インタビューで習慣・非言語的な体験を観察します。

みなさんも、例えばPCを使う際に「普段必ずやっている動き」がありますよね？
いつもの習慣のようにチャットソフトを起ち上げて、その後メールを開いて…とやっているはずです。
これと同じように、アプリを利用しているユーザーの「普段の行動」を観察させてもらいます。

ここで重要なのは、対象となるアプリ利用時だけではなく、その前後の行動も把握することです。
アプリを利用する前に他のWebサービスを使っていたり、アプリ利用後に店舗に足を運んだりという全体のUXまで観察します。
その観察を通して、ユーザーにとってそのアプリに無くてはならない機能、あるいは不満を感じているところを確認し「JOBの重みづけ」を行います。

ちなみに、インタビューの対象者は上位20％のヘビーユーザーから選びたいところです。
「パレートの法則」といって、統計学上では上位20％のユーザーが売上の80％を占めると言われているからです。

顧客のJOBを押さえたら、次にリニューアルのコンセプトを作りながら評価をします。

多くのケースで、評価はUIができた後に行われます。
しかし、実はコンセプトの段階で評価することがとても大事なんです。
「今回のリニューアルで、私たちはこんな課題に対してこんなコンセプトでいこうと思っています」ということをユーザーにぶつけていくんですね。

具体的には、コンセプトに沿ったユーザーストーリーを作り、それを元に作ったランディングページやムービーなどコンセプト評価のためのプロトタイプでユーザー評価を進めていきます。
この評価では「課題は合ってますか？」「コンセプトに共感しますか？」を聞いてみましょう。
そして、共感を得られないユーザーがいたらそれはどんな人で、それはなぜかを分析することが重要です。

共感を得られないということは、何か理由があるはずですよね。
そこもケアしながらリニューアルにおける設計をすることが必要なんです。

次は、既存と新規の体験マージです。
新しい機能を追加したいときって、よくアプリの上の方に配置しますよね？
そして、目立たせたいからとバルーン表示（吹き出しの形をした強調表現）で追加してしまいがちです。

でも、ユーザーは普段やりたいことのための操作しかしないので、新しい機能があっても興味が無ければ反応してくれません。
そこで大事なのは、普段のユーザーの体験の中に、新しい機能や情報をマージするということです。

例えば、to B向けの案件におけるECサイトの管理画面で、売上やPVを可視化するリニューアルを考えているとします。
このとき、ユーザーが普段使っている商品の編集ページなどに追加機能を混ぜ込むことで、利用を促進できます。

次は、STEP3の内容を意識しながらプロトタイプを設計し、テストしていきます。
ここでは、既存のヘビーユーザーが迷わずに今までやっていたJOBが達成できるかを見ていきます。
上手くいかなければ、改修をしながら達成できるように調整します。
いわゆる「改悪」と感じてしまうユーザーがいたら、「なぜそう感じるのか？」を引き出し、改修のヒントを得るのがポイントです。

また、新たな対象ユーザーに対しては、通常のユーザビリティテストで「価値を感じるか？」「効率的に操作できるか？」を評価します。

最後に、計測と判断です。
どんなに良いリニューアルでも、ハードクレーマーは必ず出てきます。
このとき、カスタマーサポートや上層部は過剰に反応しがちです。
しかし、ここでプロジェクトメンバーが焦らないようにすることが重要です。

そうするためには、事前に定量のKPIを設定し、サイレントマジョリティになっている人がきちんと利用できているかが分かるようにしておきましょう。
もちろん、ユーザーの声をないがしろにしろ、というわけではありません。
声だけではなく、行動データも把握したうえで冷静に判断しましょう、ということです。

「未来はユーザーに聞くものではなく、自ら描くもの」

ここまでで、リニューアルプロセスの説明は終わりですが、最後に一つだけお話させていただきます。
「ユーザーに聞けば未来は開けるのか？」というお話です。

ユーザーは、先ほども説明した通り、「変えないで」と思っています。
変化があるとしてもなだらかな変化、つまり連続的な変化を想定しています。

一方で、ありたい未来は非連続的なところにあります。
例えば、ユーザーから「民泊をしたい」という発想が生まれることはありません。
これはつまり、ユーザーリサーチをしてもAirbnbのようなアイデアは生まれないということです。

Airbnbが誕生する前に「空いている人の家に安く泊まれる」サービスのアイデアを聞いたら、おそらく多くの人は「良いアイデアとは思わない」と回答するでしょう。
しかし、一見悪いアイデアに見えても、実は本質的なニーズを捉えていたからこそ、Airbnbはここまで広がりを見せているのです。

ユーザーの本質的ニーズを捉え、テクノロジー・ビジネスドメイン・クリエイティブの知識を持って、ユーザーを「ありたい未来」に連れていくこと。
これが我々の使命です。

そのために、ビジネス（B）・テクノロジー（T）・クリエイティブ（C）の要素を連動させてイノベーションを起こせるBTC型人材が今後は必要とされるでしょう。

未来は聞くものではなく、描くもの。
まずはこれを意識していただければと思います。

【UIデザイナー視点】Webサービスリニューアルを成功に導くデザイナーのドキュメンテーション
株式会社ニジボックス　神田 智哉

次に登壇したのは、ニジボックスでクリエイティブ室マネジャーを務める神田智哉です。
サービス・プロダクトのUIデザイナー向けに、数多くのWebデザイン案件に携わってきた知見を元にした「ドキュメントの最適解」について語りました。

「よくあるリニューアルの失敗事象とは？」

リニューアルプロジェクトでは、これから話す3つが避けるべき事象として挙げられます。

1つ目は、コンセプト設計時に起こる「合意形成の遅れによる後続タスク遅延」。
事業側の方は思ったものがあがってこないと思い、制作側は制作意図と要望がずれていく、というジレンマを抱えがちです。

2つ目は、制作・開発時の「仕様理解のズレによる手戻り」。
仕様と実装が異なる、実現できないなどの事象が起こって、手戻りが発生するのもよくあることです。

そして3つ目は、運用時の「前任不在による制作経緯のブラックボックス化」です。
大規模プロジェクトほど、リリース後の運用も年単位になります。
当然人の入れ替わりもありますので、ブラックボックスが生まれるわけです。
リニューアルの際は、運用時のことも見据えて制作物を作る必要があると私は考えています。

以上を踏まえて、デザイナーが大事にしたいことは、「コンセプト設計時」「制作・開発時」「運用時」に応じてドキュメントの形式を変えるということです。
ドキュメントには「ずっと変わらないもの」「変わっていくもの」があります。
これから作ろうとするドキュメントがそのどちらなのかで、使うツールも異なってきます。

それではここから、制作の流れの中で具体的にどう使い分けているのかを説明していきましょう。

「コンセプト設計時のドキュメント作成はスライド資料をおすすめする理由」

まずは、コンセプト設計時からです。
このフェーズでは、トーン＆マナーの方針や、UI・カラーなどのルール概要をドキュメント化します。
これらはプロジェクトのそもそもの方向性に関わるものなので、「変わらないもの」であると言えます。

コンセプト設計時に作るドキュメントの目的は明快で、コンセプトをビジュアライズすることですね。
留意点は、プロジェクトに携わる全ての職能の人へ伝える必要があることです。
事業側であれば代表の方や事業責任者の方、制作側でも開発サイドまで含めて全方位に伝えることを意識します。

ここでは、PowerPointまたはKeynoteを使用することがほとんどです。
「共有と保管が容易なスライド資料」を作成し、「全ての人が容易に確認、展開できること」を最優先とするからです。
後述しますが、実はこれが後々大いに役立つこととなります。

もう少し詳しく、コンセプト設計時のドキュメント作成をする時に私が意識していることを解説していきましょう。
まずは、図版化することで「百聞は一見に如かず」の状態を作ることです。
全方位に展開されるので、スピード感があり、かつ分かりやすいドキュメントが望ましいということですね。
カンプを載せることもあれば、機能価値の概念を図版化して資料に落とし込むようにしています。

次に、原理原則で説明することです。
例えば色彩計画など、人の感覚に左右されがちなものに関しては、色相環を用いて配色の組合せから情緒を見いだすなど、色彩における原理原則を用います。

プレゼンが苦手な方は、ページごとに伝えたいことを一言でまとめた「サマリのテキスト」を用意するといいでしょう。
あとは、「1ページ1コンテンツ」とすることを意識しています。
デザイナーの技能はビジュアライズであり、「大きく、短く、簡単に」を意識することが大事です。

「制作・開発時の資料は2ツールを上手く使い分けています」

制作・開発時では、「変わらないもの」と「変わっていくもの」のドキュメントが混在します。
ここで大事なのは、ドキュメントを使い分けるということです。
具体的には、Adobe XDなどのモダン開発ツールとPowerPointなどのスライド資料を使い分けています。

デザイン意図のすり合わせの場合は、パターンもさまざまで流動的なものなので、モダン開発ツールを用いるのが効率的です。
しかし、デザイン原理原則の認識すり合わせといった普遍的な議題の場合は、図版化したスライド資料を作るようにしています。

特にリニューアルプロジェクトの場合、仕様変更などの手戻りが多いため、「空中戦」（口頭だけで議論を行うこと）になりがちです。
これを避けるために、ビジュアライズされた分かりやすいスライド資料を用いると効果的です。

実際にあった案件の例なのですが、テキストを左揃えにするのか、中央揃えにするのかで事業側・制作側の意見が分かれたことがありました。
このすり合わせの際、「中央揃えは視線誘導を中央に置くことでメッセージに重みが出る」という原理原則を図示した資料を持って臨むことで、合意形成がスムーズに進みました。

「運用時のガイドラインは“生き物”」

最後はリリース後の運用時です。
意外とここを意識せずに進める人が多いですが、実はとても重要です。

通常、リリース後の品質維持・生産性向上を目的としたガイドラインを策定し、運用します。
このガイドライン作成には、効率的に編集することを目指して業務支援ツールとモダン開発ツールを併用しています。
例えば、プロジェクトの最新動向が企画側にも見えるようにNotionなどの業務支援ツールを利用し、ガイドラインの更新にはXDを使う、といった形ですね。

大事なポイントは「ガイドラインは生き物である」と理解する、つまりガイドラインは常に編集する前提とすることです。
リリース後にも、改修施策や機能追加の要望はしばしば発生します。
しかし、現在のガイドラインではそれが実現できないため揉めてしまう…といったケースをたくさん見てきました。

なので、リリース後の改修スピードに合わせて、ガイドラインは常にチューニングするものと捉えましょう。
「ガイドライン」と言われると、それを厳守することが正と考えがちですが、実はそこに固執すると、将来的に運用が上手くいかなくなる原因となってしまいます。

「案外、アナログなスライド資料が生産性を上げる」

最後に伝えたいメッセージは「モダン開発ツールに目が向かいがちだけど、不変なものを大事にする」ということです。

コンセプト設計時の解説のときに、不変のドキュメントとしての「共有と保管が容易なスライド資料」がリニューアル後に役立つ、と話しました。
不変のドキュメントとは、デザインコンセプトやデザイン原理原則をビジュアル化した資料のことです。
この「土台となるもの」の範囲の中で、リニューアル後のプロダクトは改修していきます。

プロダクトの根幹とも言うべきドキュメントが無いと、リリース後に改修をする時の判断基準が不明確になります。
その結果、流動的に更新すべきガイドラインの硬直化を招き、運用時の生産性が大きく下がってしまいます。

モダン開発ツールの進化スピードはすさまじく、便利なものですが、「不変なものを残す」ときはスライド資料が適任です。
ツールの進化に惑わされず、変わらないもの、変わっていくものを組合わせて品質を維持すること。
これが、リニューアルにおけるドキュメントの最適解なのではないでしょうか。

【エンジニア視点】超高速配信を達成したオウンドメディア構築の裏話
株式会社ICS　池田 泰延

最後は、フロントエンドのテクニカルディレクターとして活躍し、著書も多数の池田泰延さんの登壇です。
技術面から、サイトリニューアルにまつわる様々な裏話を教えていただきました！

「残念なお知らせです。ウェブサイトは、勝手に壊れます」

いきなりですが、ウェブサイトは勝手に壊れるというセンセーショナルなお話をしたいと思います。

ウェブの技術は、いろんな外的要因によって変化します。
例えば、ブラウザの変化。
2018年7月から、常時SSL化の非対応サイトは「保護されていない通信」と表示されるようになりました。
他にもトラッキング防止機能がそれぞれのブラウザで強化されたことで、今まで使えていた機能が使えなくなることも増えています。

また、技術のサポート期間という要因もあります。
PHP5.6は2018年末で終了しましたし、Flash Playerのサポートが2020年末に終了したのは記憶に新しいと思います。
あとは、ウェブサイトの改変、OS・ブラウザのアップデートなんかも要因として挙げられます。

リニューアルをするしないに関わらず、時代の変化に対応するために必要な改善をしないとリスクが増します。
また、ユーザーの満足度を向上させ、事業価値を最大化させるための改善という側面からも、技術面でのリニューアルは必要になってきます。

「WordPressをやめてみたら、表示速度が4倍になりました」

ここからは、私の会社で管理しているオウンドメディア「ICS MEDIA」のリニューアル事例を紹介していきます。

2013年にサイトオープンし、このときはレンタルサーバーでWordPressという簡単な仕組みでした。
しかし、2015年にある記事がバズったことが原因でサーバーが落ちてしまったんですね。
これがきっかけで、大きなリニューアルをすることになりました。
この時はAWSに移転したことで解決したのですが、2019年に再度大きなリニューアルを行いました。

2回目のリニューアルでは、「速さ重視の構成」を目指しました。
そこでまず着手したのが、WordPressをやめてJamstackに変更したことです。
Jamstackとは、フロントエンドの技術で静的HTML群を生成し、そのファイルをそのままサーバーにアップして記事を配信する技術です。

このJamstackの特徴は、サーバーに余計な負荷がかからないということです。
読み込みが速く、アクセス数の増加に強く、セキュリティ性も高く、開発体験も良い感じと多くのメリットがあります。

他にも、フロントエンドではAMP（検索エンジンからの遷移が速くなる）やSPA（ページ間遷移が速くなる）を導入しました。
そしてインフラ周りでは、落ちにくく配信も速いサーバーを用意しています。

このような努力の甲斐があって、Webサイトの品質チェックができるツール、Lighthouseのスコアが大幅に改善しました。
ページの表示速度も約4倍になったということで、ある程度リニューアルが成功したのではないかと感じています。

ここまでは技術面でのリニューアルの話でしたが、UIの改善も頻繁に実施しています。
ダークテーマ対応、高速な検索窓の実装、検索スニペット（検索結果のタイトル下に表示されるテキスト情報）への著作権表示対応など、細かいところまでこだわってやってきました。

技術面もUIに関わる部分でも、段階的に新技術を導入してきたのがポイントです。
そうすることで、リスクを最小化し、導入価値を早く発見することができます。
そして、大きなリニューアルのタイミングで一気に全面展開するといった判断も可能になります。

「失敗談も…アクセス数の減少や、更新の手間が増大」

ここまでは成功事例のお話をしてきましたが、ここからは失敗談をいくつかお話しします。

ひとつ目の失敗談は、リニューアル後にアクセス数が減少した話です。
2019年のリニューアル後、PVが顕著に右肩下がりとなりました。

この原因は、ページ分割を廃止したことです。
WordPress時代は、ページの読み込みを早くするために1記事を複数のページに分けていました。
ページを分割すれば、1記事あたりのPV数も増えるので「見かけ上のPV」は多くなります。
このUIを廃止したために、一時的にPVが下がってしまったのです。

ただ、ユーザー数はそこまで減少せず、2020年からは回復傾向にあるので、そこまで不安視はしていません。
リニューアル時は短期的な変動に一喜一憂せず、さまざまな尺度の評価基準で検証するのが重要です。

次の失敗談は、更新の手間が増えたことです。
Jamstackにしたことで、OGPやサイトマップXMLといったWordPressでは容易に実現できたことを、自前で開発しなければならなくなりました。
他にも、記事更新時の待ち時間が長い、下書きプレビューができない、予約公開ができないといったJamstackの機能面でのデメリットも、更新の手間を増やす原因となりました。

現在は人力で対応していますが、長期的に見ると機能面のデメリットを補う技術進化に期待できると考えています。

「ウェブコンテンツは永続的であってほしいから、リニューアルする」

過去のリニューアルで成功も失敗もありましたが、今後も定期的にリニューアルをやっていくつもりです。

最後に、私がリニューアルを続ける理由をお話しして締めとしたいと思います。
それは、「ウェブコンテンツはずっと見られるものであってほしい」という想いからです。

昔のサイトを見たら、コンテンツが見られなくなっていた、という経験はみなさんもあると思いますが、これってすごく残念なことですよね。
情報を未来に残していくために、リニューアルを続けることが、私たちWeb制作者にとって大事なアクションなのではないでしょうか。

登壇者によるQ＆A

イベントの最後には、参加者から多数寄せられた質問に登壇者が回答する時間が設けられました。
ここでは、特に他の参加者からも興味を集めたQ＆Aを3つ紹介します。

Q、ヘビーユーザーが見えにくいプロダクトへのアプローチは？

A.「コンシェルジュ型リサーチ」をおこなうことです。

岡さん「確かに、LPやコーポレートサイトなどではヘビーユーザーが少ないことも多いと思います。そこで実施するのが、単なるユーザビリティテストではなく、私が“コンシェルジュ”になってヒアリングするリサーチ手法です。『実はこの会社はこんな背景がある会社です』『実はこんな機能もあるサービスなんです』などと追加情報を伝えた上でヒアリングします。その中でテスト対象者の行動変容が起こりうる要素となったものをプロダクトに反映させるというやり方です。」

Q、リクルートは大規模なリニューアルが少ない気がしますが、その理由は？具体的な事例も交えて教えて欲しい

A.ヘビーユーザーの学習コストを加味して、という理由です。

神田さん「過去、某プロダクトをガラッとリニューアルしたら、数字が一気に下がって慌ててロールバックした事例があったそうなんです。その経験から、特にTOP画面などリスクが高いところはゆっくり検証して、段階的にリニューアルを進めることがほとんどです。」

Q、Jamstackを勉強する価値はありますか？

A.はい、スキルとしての資産になると考えています。

池田さん「日本ではまだメジャーではありませんので、仕事になることは現状ほとんどないでしょう。ただ、Jamstackを勉強すれば、技術面でのさまざまな学びにつながります。Jamstackを習得しようとするとかなり難易度が高く、それはサーバーサイドレンダリングやスタティックサイトジェネレーターといった複数の技術を正しく理解する必要があるからです。そういう意味で、スキルとしての資産が得られるチャンスと言えます。」

【お知らせ】BUSINESS & CREATEVE online 次回3/30開催！

開催テーマは『つながることでひろがるUXリサーチの可能性』です。
UXデザインの手法のひとつ、ユーザーインタビューやユーザーテストを通して、ユーザーの真のニーズを探索する「UXリサーチ」について、株式会社メルペイ デザインチーム UXリサーチャーの松薗美帆さん、株式会社リクルート UXリサーチ組織のチームリーダー 大草真紀 (べぢまき)さんを迎えて知見の共有をいただき、UXリサーチャーが多様な領域と連携・協働することでひろがる、その可能性についてみなさんと一緒に考えたいと思います。
ご興味のある方はぜひご参加ください。
connpass申し込みページはこちらです！

また、ニジボックスではオンラインイベントの設計・開催を多数手がけています。
オンライン全社イベント、オンラインセミナー、オンラインワークショップなど、イベント趣旨に沿って設計から映像制作までワンストップでご支援いたします。
オンラインでのイベントやワークショップにご興味のある方はお気軽にご相談ください！