【よく失敗する話】KGI、KPIの設定で外部ツールに依存しすぎる値を設定するのはやめよう

最近いろんな案件で言われたりするWebサイトのパフォーマンスの向上について解説します。

みなさんこんばんは。
宮城県仙台市にてWebのちからで様々な情報にアクセスしやすくし、様々なパフォーマンス改善をしちゃったりする時にはWebディレクター、時にはWebプランナー、時にはWebエンジニア、時にはWebデザイナー。
世界中の若者エンジニアの味方、ma-sanです。

さて、今日たまたまなのか必然なのか、複数の案件で似たような相談をされたので解説をしていきたいと思います。
内容は「Webサイトを高速化することよって売上が上がるか」と「KPIの値の設定」です。
そして、その設定に外部ツール(他社開発によるツール)、うーん、包み隠さずいうとGoogleさんが提供しているページスピードインサイトですね。

というわけで本日のお話です。

1.なぜ外部ツールに依存してはいけないのか

シンプルですが、外部ツールは読んで字の如し、外部のツールに依存すると大変なことになります。
我々が作ることができない領域だったりサービスを提供してくれることで、いちいち開発を不要としたり、なんらかの手段で数値化(可視化)してくれる便利なものです。

世の中には便利なツールが大量にあって、更には無料だったりします。

とんでもない世界ですよ、Webって世界は。

しかし、外部で開発しているため、その内容はブラックボックス的になっていることもたくさんあります。

SEO対策、なんて言っても所詮Googleの検索エンジンアルゴリズムとの戦い。
この中身の具体的な内容まで理解している人はほとんどいないでしょう。

強いて評価される部分でわかりきっているものと言えば「世の中のたくさんの人が必要とするであろうコンテンツが評価される」というところでしょうか。

外的要因でこれまで順調だったWebサイトが急落して、誰の目にも止まらなくなる、なんてことはよく聞くお話です。
そして、解決する手段も試行錯誤ということに陥りやすいです。

2.PageSpeedInsightの問題

このPageSpeedInsight(以下PSI)の問題は「スコア化」です。
ページのスコア化をしてくれることで、このWebページは早いですよ、遅いですよ、と100点満点でつけてくれます。

PageSpeedInsight
https://developers.google.com/speed/pagespeed/insights/?hl=JA

ここに罠があるんですね。

というのも、PSIのスコアというのは、なにをすれば加点される、というところは具体的には出てきません。

こうすればいいよ、という手段の提案はPSIでしてくれますが、その対応をしたことによってどのくらいの加点が見込めるか、というのも不明です。

更に言ってしまえば、PSIが提示してくれる手段に対して、品質担保は曖昧です。
ここで言われることは「こうすれば早くなる」ということだけで、それに伴う「画像品質」だったり、「演出品質」だったり、「人が見た際に感じるクリエイティブな品質」や「売上増加(CVR向上など)などの数値向上の担保」は微妙に考慮されていません。

このスコアを「KGI」ないしは「KPI」に設定してしまうと、スコアを上げるために極論、「Googleアナリティクスが重くなる要因だから外します」「このJSが重くなる要因なので外します。それに伴い動かなくなるインタラクションデザインは改修して、シンプルなものにします」などPSIファーストになる、ということもあります。

つまり、外部ツールに振り回されて本来担保すべき「品質」というものを見失いやすくなる傾向があります。

もちろん、そこをコントロールしてこそのWeb制作会社だとは思いますが、そこを説得するのはなかなか骨が折れます。

3.リスクヘッジは複数持つことが基本

KGIは大黒柱なので複数持たなくてもいいとは思いますが、KPIの設定としてこのPSIのスコアを設定すると、なかなか骨が折れます。

PSI以外の外部ツールでもしかしたらいい点かもしれませんし、悪い点かもしれません。

また、なにをどうしたらスコアが上がるかという保証もないため、実施した施策が無駄骨になるなどもありえます。

スコアに依存せず、「スピード」という品質一本だけでWebサイトのパフォーマンスは測れないです。
Webサイトが高速であれば良い、という方向性は間違いないものの、では高速だから売上が上がるか、といえば「重ければ重いほど売上は下がる。向上するとしたら重くて逃げていたであろう本来のユーザーが目的地にたどり着けるようになる。もしくは早いからこそ活かせるWebサービスである」くらいです。

そもそもKPIやKGIの「数値」を設定すると、短期的な目標に惑わされることが多いです。
残念ながら、数値を出さないと納得できない、動けない、という人もたくさんいますが……。

最低でも「アクセス数」や「売上」や「お問い合わせ件数」や「課題解決数」など、複数の数値をKPIとして持っておかないとここだけでパフォーマンスのお話はできません。
そしてこの数値が達成されたらどんなことが実現するのか、ということが本来KPIに設定することだったりします。

4.品質担保の責任は誰が持つの、というお話

PSIの場合、Googleさんが無償で提供してくれるものです。
世の中のユーザーにとって、Webサイトを閲覧する際に高速であれば良い、という方向性は間違いありません。

では、このPSIの指示どおり、100点を取りました。

ここで問題です。

1.PSIのスコアが100点になりましたが、Webサイトの売上が伸びません。
とあるAmaz0nさんの場合、0.1秒読み込みが遅ければ売上のXX%に影響ほにゃらら、とクライアントに問題提起し、クライアントもそりゃ高速のほうがいいよね、じゃあお金払うからよろしく!

2.PSIの指示通りに問題を解消したらバグのような事象が発生した。
スコアアップのために実施した施策のうち、少し見た目に影響するものがあった。スコアアップのために実施するから、多少の見た目の品質低下は仕方ない。

PSIの言う通り高速化したのに。。。

この責任を取るのは誰でしょう?

もちろん、提案した側の責任であり、PSIというツールも、Google社も、クライアントも悪くはありません。
PSIという一つのツールに依存した結果、品質担保は誰がするのか、という基本的な視点が欠落したことによって発生します。

開発者がよく言うのは「Googleが提供してるサービスだから大丈夫」ということですが、Google社は責任なんか取ってくれません。

5.我々Webクリエイターが担保すべき品質とは

これに関してはシンプルで「Webの力を用いて、課題解決にアクセスさせる」です。
よく「なんとか業界」という立て付けであるべき論を展開することがありますが、Webという世界は「情報」を「アクセス」することです。

ユーザーがなにかしら知りたい情報があり、解決したいこと、実行したいことを情報として利用し、Webにアクセスするわけですね。

つまり、「アクセシブル」であるか。この一点につきます。

アクセシブルであれば、課題解決もしやすくなるでしょう。
必要とするコンテンツへのアクセスもしやすくなるでしょう。

クライアントが「人々の安心を担う」という役割なりサービスを持っているのであれば、少なくとも「可能な限りいつでもアクセスしやすいWebサイト」を構築しなければなりません。
見た目を重視した結果、鈍足なWebサイトとなり、スペックの高いPCやスマートフォン、高速な回線でなければ情報にアクセスできない、なんてことはあってはなりません。

というわけで僕はWebサイトはすべからく「Webアクセシビリティの重要性」を問い続けるべきである、と問題提起し続けています。

当たり前、と言われればそれまでですが「アクセシブルである」ということは重要すぎるが故に軽んじられることや「新たな施策」みたいに思われがちだったりもします。

まとめ

以下のようにまとめます。

  • PSIのスコアに惑わされないようにしましょう
  • 品質は「スピード」だけではなく多種多様に計測しましょう
  • KGI,KPIに定量的な数値を設定しないようにしましょう
  • Googleさんを始め外部ツールは責任を取りません
  • Webアクセシビリティが大事

という感じでしょうか。

そして僕のこの文章は長すぎでしょう。



あわせて読みたい