Help us understand the problem. What is going on with this article?

Webパフォーマンス管理の基本 1

More than 1 year has passed since last update.

はじめに

Webパフォーマンスとは

Webパフォーマンスとは、具体的には以下の2つから成り立ちます。

  • 表示速度 - WebブラウザでWebページが表示される速度
  • 可用性 - WebブラウザでWebサイトにアクセスした際に、エラーや遅延がなくアクセスできる率

世界的には、2019年の時点では

  • 表示速度 - 表示開始時間が0.5秒、表示完了時間が2秒
  • 可用性 - 年間を通して、3%以下のエラー率

が目標値となっています。

この目標値は、どこかの組織が策定しているわけではなく、世界各地で開催されているWebパフォーマンス関連のイベントなどの発表でよく話題になる値です。

表示開始時間とは、Webブラウザに最初の1ピクセル目が表示された時間です。
表示完了時間とは、Document Completeを指していて、これを以って、ユーザがWebページ上の操作が可能となります。

私が、Akamaiに勤めていた2006年~2009年頃は、ダウンロード時間が指標値でした。2006年当時は3秒ルールと言われていましたが、2009年には2秒ルールと、より速さを求められるようになりました。
現在、アメリカでは、ダウンロード時間が1秒を切るサイトが普通にあります。
例えば、Appleのデスクトップサイトは、米国においては、0.8秒でダウンロードが完了します。

携帯網の発達によって、現在、下りは100Mbpsまで帯域が広がりました。
それが、LTE Advanced-Pro(4.5Gとか、LTE Premiumとして表示されたりもします)によって、この春からNTTドコモを筆頭に、下り1Gbpsとなります。

Webパフォーマンス管理とは

「改善」と「管理」

Webパフォーマンスについては、改善を一回やれば、それで済むというような話ではありません。
何故ならば、Webサイトを取り巻く状況は常に変化し続けるからです。

何が主に変化するかというと、

  • コンテンツの構成要素
  • ネットワーク状況
  • 負荷状況
  • 3rd Partyコンテンツ(SNSのボタンや、広告のような他社のリソースを読み込むもの)のレスポンス

等が変わっていきます。

変化し続けていくわけですから、一回の「改善」で済むわけではなく、「管理」が必要になります。

ソフトウェア開発プロセスの分野で著名なトム・デマルコ氏は、著書「Controlling Software Projects, Management Measurement & Estimation」(1982)の冒頭で以下のように書いています。

測定できないものは管理できない。
(You can't control what you can't measure.)

ですから、24時間365日、Webサイトのパフォーマンスを計測していなければ、「管理」できません。

Webパフォーマンス管理とは、Webサイトという工場の「品質管理」

世の中の殆どのモノは、このように不確定要素を多分に含んだ、安定していないものばかりです。ソフトウェアのように、一度、設計して、コーディングして、バグを修正してしまえば、同じものが幾らでもコピーできるというモノの方が珍しいのです。

ところが、その「同じものが幾らでもコピーできる」という事が、Webによって崩れてしまいました。

Webサイトを一種の「納品物」と見ている方は多いと思います。
しかし、Webサイトは、Webページを生成する「工場」なのです。

WebページやWebアプリケーションの画面は、HTMLやCSS、JavaScript、画像などの「部品」に分けられて、インターネットという「ベルトコンベア」を通り、ユーザのブラウザで「組み立てられる」からです。
従って、ユーザの端末で組み立てられて表示されたWebページこそが「完成品」です。

素晴らしい工場を建てる事と、素晴らしい製品を製造する事は、異なるお話です。

「Webサイトは工場」という考え方で見てみると、インターネットという「配送路」でHTMLやCSS、JavaScript、画像などの「部品」を自社の「工場」だけなく、広告、計測タグ、SNSボタンなど、サードパーティと呼ばれる自社サーバ以外から配信されるコンテンツも「部品」として使い、それらをユーザの端末に送り込んで、ブラウザで組み立てているので、自社工場だけで完結するお話ではありません。

ですから、Webパフォーマンス管理は、SCM (Supply Chain Management:サプライチェインマネジメント)の要素もあるとも言えます。

SCM とは、供給業者から最終消費者までの業界の流れを統合的に見直し、プロセス全体の効率化と最適化を実現するための経営管理手法の事です。

自社Webサイトから配信される「部品」だけでWebページが構成されるのであれば、自社のWebサイトだけの製造工程だけをしっかりと管理すれば良いです。
しかし、例えば、日本のEコマースサイト売上上位285社の75%以上が、10サーバ以上から「部品」を取り寄せています。
日本のEコマースサイト売上上位285社Webサイト品質調査結果

自社工場がどんなに滞りなく「部品」を配送しても、他の「部品」を作っている会社の工場から部品が届かなければ、製品は完成しません。
このように考えると、「SCMとしてのWebパフォーマンス管理」は、納得して頂けるかと思います。

統計的品質管理の源流

そこで、「統計的品質管理」の理解が重要になってきます。
日本の製造業では、もう半世紀以上に亘って知られていて、企業文化の根幹を成す知識ですが、IT業界やWebサイトの制作では知られていないので、その源流をざっと辿ってみます。

「統計的品質管理の父」ウォルター・アンドリュー・シューハート博士

317564b828bc45cfef69d6ad2f38e785.jpg
ウォルター・アンドリュー・シューハート博士(1891 - 1967)

シューハート博士は、「統計的品質管理の父」と呼ばれています。
1918年にAT&Tの製造部門であるウェスタン・エレクトリックの検査技術部に配属され、通信システムの品質管理に携わっていました。
「統計的品質管理の父」が、実は、通信システムの分野の方だったというのは、とても興味深いと思いませんか?

アナログの電話回線では、銅線の中を通って弱くなった信号を、ある一定区間毎に中継増幅器というものを使って増幅します。
日本だと、電柱を立てて架空に設置しますが、米国だと地下に埋設します。
簡単に交換できる場所ではないため、この中継増幅器の品質を高める必要があったのです。

従来、この中継増幅器の完成品を検査して品質を確認していたものを、シューハート博士は製造工程単位で品質を管理する事も必要だという事で、「管理図」というものを考え出します。

品質の問題を、「特殊原因」と「共通原因(偶然原因)」から成り立つと考えて、それらを区別し、製造工程を共通原因だけが存在する統計的プロセス制御を行い、その制御を維持することが、未来の出力を予測して経済的に製造工程を管理するのに必要であると主張されたのです。

シューハート博士は、1925年に設立したAT&Tの研究機関であるベル研究所で、引退されるまで在籍して研究されていました。

ウィリアム・エドワーズ・デミング博士

DEM-1002 WED 1950s_650.jpg
ウィリアム・エドワーズ・デミング博士(1900 - 1993)

デミング博士は、元々は米国の農務省に勤務し、その後、統計家としてアメリカ国勢調査局に勤務していました。
農務省時代にシューハート博士が米国農務省で行った一連の講義をまとめて、1939年に「Statistical Method from the Viewpoint of Quality Control」 として出版しました。

第二次世界大戦の後、1951年、GHQが日本の国勢調査を行う際に、その計画立案のため、デミング博士を日本に招聘します。

そこで、日科技連(日本科学技術連盟)はデミング博士に講演を依頼します。
日科技連の人たちは、シューハート博士の技法を学んでいて、日本の復興のために、統計的制御の専門家の教えが必要だと考えていたのです。
現代の私達には信じられないかもしれませんが、第二次世界大戦以前は、日本の工業製品は「安かろう・悪かろう」という粗悪品の代名詞だったのです。

日本の製造業の人達は、デミング博士から統計的品質管理を学び、「安かろう・悪かろう」から「安くて高品質」の工業製品を作ることで世界市場を席捲していくことになります。

日本においてデミング博士にちなんだ「デミング賞」が品質に関する賞として日科技連で創設されましたが、米国においてはシューハート博士にちなんだ「シューハート・メダル」がアメリカ品質学会で創設されています。

品質管理の重要性

現在、世界的には、IT予算の1/4~1/3が品質管理関係に使われます。
しかし、日本はどうでしょうか? 皆さんのプロジェクトのどの位の割合の費用が、品質管理や品質保証に使われているでしょうか?

そもそも、何故、品質管理が重要なのでしょうか?

ITシステムの大事な品質概念 V&V

「ITシステムの品質管理」としてのWebパフォーマンスを語るときに、是非、押さえていただきたいのが、V&V という概念です。

Verification(検証) & Validation(妥当性確認)です。
Verification(検証)とは、対象が要求された仕様、設計、計画などの要求事項が満たされているかどうかについての確証を指します。
Validation(妥当性確認)とは、対象の機能や性能が本来意図された用途や目的に適っているか、実用上の有効性があるかについての評価を指します。

ri10_vmodel01.gif
情報システム用語辞典: V&VのソフトウェアV&V(ベームのVチャート)より引用

Webパフォーマンスは、Validation(妥当性確認)に該当する品質です。
つまり、Webサイトの場合は、きちんと表示されて、様々な機能が動くところまでの品質はVerificationであり、それが実用に耐えうる、もしくは快適な速度で反応できるかどうかの品質はValidationなのです。

この概念は、ISO 9000にも取り入れられています。

ISO 9000ファミリーについて深く学ばれると、ITシステムとしてのWebパフォーマンス管理について、より理解が深まると思います。
情報マネジメント用語辞典: ISO 9000

Webサイトを受託制作している皆さん

納期までの日数が少なく、価格競争の圧力もある中で、利益を出しつつ完成品を納入するのは大変だと思います。だから、表示速度や可用性は、そこそこで…というのは、まさに「安かろう・悪かろう」です。

しかし、「Webサイトは工場である」と考えれば、Webページそのものだけを納入して終わりではなく、その後の「製造管理」こそが、Webサイト運用の鍵を握ることはお分かり頂けると思います。

今後、ますますWebサイトは増える一方で、減ることはないでしょう。
他のWebサイトとの差別化・優位性確保のために、「素早く表示されて、必ず接続できる」という非機能要件である品質を担保することは、新たな収益源となります。

お客様から、「こんなWebサイトを作って欲しい」という機能要件を満たすだけでなく、非機能要件である品質に一歩踏み出す事は、お客様との長期的なパートナーシップ構築の第一歩だと思います。

自社でWebサイトやクラウドサービスを開発している皆さん

自社の工場の不良品率を分かっていない会社は潰れる

まさにこの一言に尽きます。
品質を管理するということは、お客様の期待を管理することと表裏一体です。
品質の良し悪しは、ビジネスモデルと直結しています。
そこそこの品質で、そこそこの価格というのは、ビジネスモデルとして「あり」です。

私達は、一般的に、価格が安いものについては、そこそこの品質を、価格が高いものについては、素晴らしい品質を期待しています。
商売上、大事なのは、お客様の期待を裏切らないという事です。

もしも、品質がばらついてしまい、価格が高いとか、高品質を売りにしている商品やサービスが、品質が低かったらどうなるでしょうか?
通常の評価のサービスや商品が広まる速度を1とした場合に、良い評価は1.5倍の広まる速度を持ち、悪い評価は10倍の広まる速度を持つと言われています。
品質がばらつくと、お客様の期待を裏切ってしまい、結果として、自社ブランドが悪化していくのです。

価格が無料とか、安いものであっても、そこには、無料とか安いなりの「期待」があるので、品質がばらつくと、同様の結果が訪れます。

大事なのは、品質をばらつかせない事で、お客様の期待を裏切らない事です。

Webパフォーマンス向上の効果

直帰率の改善

Webパフォーマンスを改善すると、まず最初に数字として現れるのが、直帰率の改善です。
これは、今まで、私がやってきた高速化・安定化で、最も共通して現れる数値です。
各Webページにおいて、表示開始時間0.5秒以内、表示完了時間2秒以内にすると、直帰率が50%以下になっています。

ページビュー数の改善

高速化に伴い、Webページの閲覧にストレスが無くなる事から、ページビュー数が1.4~2.2倍の範疇で増加しています。

売上の増大

Eコマースサイトでは、売上の増大を観測しています。
これは、現状のアクセス数に依存します。何故かと言うと、商品やサービスが売れる・売れないを左右するのは、表示速度ではなく、商品やサービスそのものの魅力に依存しているからです。
つまり、Webパフォーマンスの改善は、機会損失を改善しているのです。

検索ランキングの上昇

あまりSEOに効果があるとは言いたくないのですが、現状、Webパフォーマンスを改善すると検索ランキングが上昇するという結果が伴っています。
だからといって、SEOだけを目的にWebパフォーマンスを改善するというのは、私個人としてはどうかなと思います。

検索ランキングへの影響については、2016年11月からGoogleが、日本の重要顧客を中心に訪問して、Webパフォーマンスとコンバージョン率やオーガニック検索の順位の関係を説いています。

きっと、読者の方の中にもGoogleの訪問を受けた方もいらっしゃるのではないでしょうか?

品質管理と技術力

この記事を読んでいらっしゃる方は、多分、技術者の方が大半でしょう。もしかしたら、マネージャークラスや、CTOなどの技術者もいらっしゃるかもしれません。

よく、技術者の力量や、IT会社の技術力について、「xxxができるから、技術力が高い」という話になります。

私は、統計学でとある大学の先生に師事しているのですが、先日、先生から、このような事を言われました。

日本の製造業の技術力が高いと言えるのは、標準偏差を小さくして、ばらつきを抑えることが出来るからである。速度が関係するものであれば、その平均と標準偏差を小さくできることが技術力である。

「標準偏差」がよく分からない方は、そこを「ばらつき」と読み替えて下さい。

料理で例えてみましょう。
家庭料理だけど作るのが難しい料理ランキングという記事がありましたので、これを使わせて頂きます。

1位は、だし巻き卵だそうです。

だし巻き卵を作れるからと言って、「料理上手」と言っていいかどうか、という話なのです。
この記事の女性の皆さんのコメントを読むと、どうやら料理上手な人は、だし巻き卵を、何度でも、きれいに巻いて、甘さや柔らかさも毎回同じくして、美味しく作ることが出来るのでしょう。

つまり、ばらつきが小さいわけです。

技術も同様で、「作ったことがある」という実績をWebサイトに掲載しているIT企業やWeb制作会社は多いものの、性能については、全く記載がありません。

WebサイトやWebアプリケーションを作ったとしても、その性能が、常に安定して顧客の期待に沿う数値を叩き出していないとしたら、それは、技術力があると言えるのでしょうか?

品質管理では「分散は力なり」、「分散の小ささが技術力」と言われます。
フロントエンドの技術は、次から次へと新しいものが出てきますが、自分たちで実装できたから「技術力がある」ではなくて、実装した上で表示速度の「分散」が小さいことで「技術力がある」という指標へと、是非転換して頂ければと思います。

キャリアの上でも、会社の差別化の上でも、チャンスとなる「品質管理」

もし、あなたが、エンジニアとして一歩抜きん出てキャリアを積み上げたいのであれば、「品質管理」は、確実に大きなアドバンテージになります。殆どのエンジニアは、品質管理と無縁だからです。

でも、おかしな話だと思いませんか? 製造業で、エンジニアが品質管理は分からないなんて言ったら、会社に居られないと思います。製造業のエンジニアは品質管理を当たり前に知っているのに、ITのエンジニアは知らないという方がおかしいのです。

もし、自分の職務経歴書に、こんな一文を記述できるとしたらどうでしょうか?

PHPを使ったWebアプリケーション構築プロジェクトに、フロントエンドエンジニアとして参加。実装したシステムは、パフォーマンスを平均2秒、標準偏差0.5(96%の確率で2秒±1のパフォーマンス)で、安定高速稼働させた。

マネージャークラス、CxOレベルの方であれば、以下のようなSLAを保証できたとしたらどうでしょうか?

弊社で納品するECサイトシステムは、96%の確率で、表示開始時間が0.5秒以内、操作可能時間が1秒以内となるように品質を保証し、SEO対策が最大限に効果を発揮するようにいたします。また遅延による離脱が最小限に留められるようにいたします。

民法改正に伴う瑕疵責任の変化

2017年5月26日に民法債権法改正が国会を通過しました。
今後3年以内に施行となります。

その中で、私達にとって、重要な条文の改定があります。
瑕疵責任の範囲です。

現在の第634条では、以下のようになっています。

仕事の目的物に瑕疵があるときは、注文者は、請負人に対し、相当の期間を定めて、その瑕疵の修補を請求することができる。ただし、瑕疵が重要でない場合において、その修補に過分の費用を要するときは、この限りでない。

それが今度の民法改正案では、第570条として、以下のようになっています。

売主が種類又は品質に関して契約の内容に適合しない目的物を買主に引き渡した場合において、買主がその不適合を知った時から1年以内にその旨を売主に通知しないときは、買主は、その不適合を理由とする履行の追完の請求、代金の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、売主が引渡しの時にその不適合を知り、又は重大な過失によって知らなかったときは、この限りでない。

瑕疵責任に、「品質」が入ったのです。

誤解しないで頂きたいのですが、現在でも、品質が悪いと裁判で訴えられると損害賠償を負います。
今回の民法改正案は、この130年に及ぶ判例を反映して更新するためのものです。

従来、瑕疵担保責任の期間は、民法637条で以下のように一年と定められていました。

前二条の規定は、仕事の目的物の瑕疵が注文者の供した材料の性質又は注文者の与えた指図によって生じたときは、適用しない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。

この条文が改正案ではなくなり、改正案570条の但書にあるように「売主が引き渡しの時にその不適合を知り、又は重大な過失によって知らなかったときは、この限りでない。」と、重大な過失によって知らなかった場合も責任を負うのです。

この時効は5年となります。

従って、今後、納品時のWebサイトの表示速度や可用性のテストを行い、製造業がやっているように品質保証書を提出する事は瑕疵責任のリスク管理上、必須となります。

当然ながら、それが「自分でChromeの開発者ツールで計測してみて2秒でした」というのでは、品質保証にならないことはお分かり頂けると思います。

この辺りについては、ITプロセスコンサルタントの細川義洋さんの記事「ユーザーの要件が間違ってるのはベンダーの責任です!――全ベンダー涙目の民法改正案を解説しよう その1 (1/3)」が参考になると思います。

Webサイトは一つ一つ違う、だから一つ一つ計測して調べることが大事

人間が一人ひとり違うように、会社も一社一社が違い、Webサイトも一つ一つ違います。もし、全てのWebサイトが全く同じ構造で、全く同じ環境下にあるのであれば、一度、Best Practiceが確立すれば、それを適用すれば事が足ります。

しかし、実際はそうではありません。

今までに、Google PageSpeed Insightsで分析して高速化しましたとか、Firebugで分析して高速化しましたとか、Chrome Developer Toolで分析して高速化しましたとか言われて、計測してみたら遅かったという事を多数経験しています。

それらのツールで計測した数値は、その瞬間そうであったというだけで、常にその数値ではないのです。
「サンプル1」でしかないのです。

計測数値を見せたら、「そんなはずはない」と逆ギレされたこともあります。

また、幾つかのSIerや、Web制作会社からは、「遅いことがバレるから計測したくない」と言われた事もあります。

皆さん、私達エンジニアは、知識労働者です。
理性と論理に重きを置いて働くのがエンジニアです。

統計学を学ぶことは面倒かもしれません。
計測してデータを分析することは、費用がかかるでしょう。
それでも、品質管理は、エンジニアのキャリアとしても、ビジネスのアドバンテージとしても、多大なメリットを齎します。

連載 他の記事

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした