Webパフォーマンスの振り返り 2019
2019年も、残り一カ月となりました。 今年もWebパフォーマンスのAdventカレンダーを今年も開催したので、その初日のエントリーとして、今年のWebパフォーマンスを振り返ります。
今年は法制面で、経産省が坦々と進めてきた制度整備が大きな目玉でした。 従って、法制度の話が中心です。 エンジニアは、技術だけではなく、関連する法制度もしっかりと理解しなければいけません。
品質保証前夜
ついに、2020年4月1日の改正民法債権法施行まで、4か月となりました。 未だに、改正民法債権法を知らない人は多く、施行後、それなりにトラブルが生じると予想されます。
今一度、改正民法債権法で、Webサイトに関連する箇所をおさらいしましょう。
契約不適合責任
今回の民法債権法改正で、大きく変わるのが、ドイツやフランス由来の大陸法から、英米法へ軸をシフトする点です。 今回の民法債権法の改正は、日本がウィーン売買条約(正式名称は「国際物品売買契約に関する国際連合条約」)に2008年に加入し、2009年に発効したことに端を発しています。
大陸法では「契約とはこうあるべき」という普遍的なあるべき姿という考え方があるのですが、英米法の場合は「当事者間で取り決めた事」を重視します。
従来は、契約が問題なく履行されたかどうかで使われていたのは「瑕疵担保責任」でした。 それが、来年4月1日からは、瑕疵があるかどうかではなく、契約の目的を達成したかどうかで判断します。
「契約を取り交わすからには、その契約で実現したい目的がありますよね？その契約の目的を達成したかどうかで、契約が履行されたかどうかが判断されますよ」という事です。
売買については、562条で規定されています。
第562条
- 引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。ただし、売主は、買主に不相当な負担を課するものでないときは、買主が請求した方法と異なる方法による履行の追完をすることができる。
請負については、636条で規定されています。
第636条
請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき（その引き渡しを要しない場合にあっては、仕事が終了したときに仕事の目的物が種類又は品質に関して契約の内容に適合しないとき）は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。
条文に「品質」という言葉が入ったのが画期的です。
瑕疵担保責任と契約不適合責任の違い
「契約不適合責任って、瑕疵担保責任の言葉が変わっただけでしょ？」と解釈している人もいますが、違います。
今後の契約書には、「契約の目的」を明記することが重要です。 Web関連であれば、以下のような契約の目的が考えられるでしょう。
- Webサイトをリニューアルして、アクセス数を20%を増やすことを目的とする
- A/Bテストツールの契約の目的は、コンバージョン率を現状より10%改善する事とする
- レコメンデーションエンジン導入に際し、この契約の目的は、顧客当たりの売上単価を20%増加する事である
言い換えれば、契約において「目的と手段」を明確に分けるという事です。
リニューアルをしたり、何かのツールを入れる。 それらをちゃんとやりました、ではダメで、その手段を使ってやりたい目的が達成されたかどうかが重要になるという事なのです。
「そんな事は保証できない。そんな契約は結べない」と仰りたい方も多々いらっしゃるでしょう。 そこで考えて欲しいのが、「お客様が実現したい目的を達成できるかどうか分からないツールを売ったり、作業をすることは倫理的に、契約的に正しいのか？」という事です。
効果があるかどうか分からないものを売りつけているなら、それは詐欺です。 効果があっても、実際の効果より大きく見せているなら、それは優良誤認です。
もちろん、契約の目的は任意規定であり、当事者間で好きに定める事ができます。
またWebサイトのリニューアルなどは、売上向上やアクセス数向上に寄与するかどうかは、実際には分からないです。 それは、Webサイトへのアクセス数は、その会社や、その会社が販売している商品やサービスなどが影響する変数としては大きいからです。
「契約の目的」に直接の影響を与えるという因果関係がないのに、「契約の目的」に定めるのは理不尽です。 「契約の目的」は、その因果関係を考えて定める必要があります。
自社の商品やサービスに、実際に効果や効力があるというのであれば、それを「契約の目的」を明記することが可能な筈で、消費者にとっては商品やサービスを選ぶ際の一つの目安になるでしょう。
不良品と不適合品
全てが「契約の目的」に、何かしらの効力を記載できるわけではなく、特に請負契約については、仕事の完成を約して行います。 WebサイトやWebアプリケーションなどの開発に係る請負の「契約の目的」は、その仕事の完成が目的として定められるのが妥当でしょう。
請負での開発で、今までも、そしてこれからも問題になるのは、性能問題です。
機能要件については、0か1かの世界です。 つまり、要望された機能を実装したか、していないかで判断可能です。 機能を実装したら、動くか動かないかで判断可能です。
しかし、機能要件を実装して、実際に動かす事ができたとしても、それが業務上必要とする性能を満たさない場合に問題となります。そして、その性能についての要件(非機能要件)は、契約書できちんと明記せず、検査もされずに納入されている現状が揉める原因となります。
- 顧客が求める機能を実装していなければ、また、実装しても稼働しないのであれば、それは「不良品」です。
- 顧客が求める機能を実装して、稼働していても、それが業務上必要な性能などを出せないのであれば、それは「不適合品」です。
現在、よくニュースで報道される問題の殆どは、非機能要件での問題です。
2018年、経産省はIPAと共に、「非機能要求グレード2018」を発表し、非機能要件を定めるに際してのグレードモデルを提示しました。
| 項目 | 内容 |
|---|---|
| 可用性 | 可用性、耐障害性、災害対策、回復性、成熟性 |
| 性能・拡張性 | 業務処理量、性能目標値、リソース拡張性、性能品質保証 |
| 運用・保守性 | 通常運用、保守運用、障害時運用、運用環境、運用・保守体制、運用管理方針 |
| 移行性 | 移行時期、移行方式、移行対象（機器）、移行対象（データ）、移行計画 |
| セキュリティ | 前提条件・制約条件、セキュリティリスク対応、セキュリティ診断、セキュリティリスク管理、アクセス・利用制限、データの秘匿、不正追跡・監視、ネットワーク対策、マルウェア対策、Web対策 |
| 環境・エコロジー | システム制約/前提条件、システム特性、適合規格、機材設置環境条件、環境マネージメント |
現在は、瑕疵担保責任で問われるのは、バグのような「機能要件」についてが中心です。 性能のような「非機能要件」については、追加費用をもらって行うという事が行われていますが、それは本来あるべき姿ではありません。本来は瑕疵として責任が問えるものです。
今後、Webサイトの構築や、Webアプリケーションの開発などは、性能についての要件を契約書で明記することが重要になります。
DX推進指標とDX格付
経産省は、民法債権法の改正の委員会が法学者を集めて組織された2008年ぐらいから時期を合わせて、システムの品質の可視化をIPAと共に取り組んできました。
今年は、DX推進指標を発表し、その中には当然、性能が「スピード・アジリティ」として入っています。
この「スピード・アジリティ」というのは、開発の速度とシステム性能の速度を掛け合わせたものとなっています。 システムの性能にボトルネックがある場合、新しい機能を追加したり、システムを活用しようとしても、システムのボトルネック解消に足を取られてしまって開発が進まないです。 開発が迅速に進められる軽快さが無ければ、システムのボトルネック解消は進まないからです。
そして、その後、DX格付も発表されました。
この格付により、投資家にとっては、投資に値する実力を持つ企業であるかどうかが判断できるようになります。 銀行にとっては、融資の際の判断材料になります。
この格付認定について根拠となる法律として、情報処理促進法の一部を改正することが10月15日に閣議決定されました。
「Webパフォーマンスがこれと何の関係があるんだ？」と思われる方がいるかもしれません。
よく「Amazonは0.1秒遅くなると、売上が1%減少し、1秒高速化すると10%売上が向上する」とか、「表示速度が1秒遅くなるごとにPVが11%、コンバージョンが7%下がり、顧客満足度は16%下がる。」とか、皆さん、高速化の効果として熱心に書かれていますよね。
高速化によって利益が向上するのであれば、システム性能が悪い企業は、投資家が資金を投じたら投資対効果が低下する(ROIの低下)という事です。銀行が融資をしても、利益が思ったように上がらず回収のリスクが高くなるという事を意味します。
投資家や銀行にとっては、Webがビジネスの中心の企業については、Webパフォーマンスに関する情報は喉から手が出るほどに欲しい情報なのです。
なんちゃって高速化から本格的なWebパフォーマンスチューニングへ
ここまで読んで頂いた皆さんにはお気づきになられたと思いますが、今後、Webパフォーマンスは、「こういうやり方をすればいいらしいよ」というお手軽なもので済まされなくなります。 本来あるべきの、システムパフォーマンスチューニングとしてのWebパフォーマンスチューニングにならないといけないのです。
誤解して欲しくないのですが、このような流れで、Webパフォーマンスの改善の敷居が上がるわけではありません。 そもそも、システムパフォーマンスチューニングは、敷居が高い、技術の難易度が高い分野なのです。
「Webパフォーマンスを民主化」と言った人が居ますが、Webパフォーマンスが限られた人だけの専制主義的なものだった事はありません。 誰でも参加できますし、技術者にとっては、機能要件と非機能要件は表裏一体で、切っても切れない関係のものです。 誰も性能改善を阻みはしません。
Webパフォーマンスに対して敷居が高いと感じるのであれば、単に技術力不足なだけです。
Google PageSpeed Insightsとか、Lighthouseとかに頼っている限り、高速化に関する技術力は向上しないでしょう。 どうしてか、分かりますか？
「使わない能力は磨かれない」と云われます。
パフォーマンスチューニングの際に、ボトルネックの診断や判断を、自動診断ツールに頼っている限り、ボトルネックの診断や解決の能力は決して磨かれる事はありません。そのツールの使い方が上手になるだけです。それを技術力の向上とは言いません。
そして、そのツール自体が間違った診断を出しているのであれば、高速化しません。
You can practice shooting eight hours a day, but if your technique is wrong, then all you become is very good at shooting the wrong way. Get the fundamentals down and the level of everything you do will rise.”
君は、毎日8時間シュートの練習ができる、でも君のテクニックが間違っていれば、間違ったやり方について上手になるだけだ。 基本に戻ることで、君の全てのレベルが向上する。 ― マイケル・ジョーダン
Googleの言ってることを鵜呑みにしているのでは、高速化は成し遂げられません。 もし、Googleが言っている事が正しいのであれば、何故、Google Tag ManagerやGoogle AnalyticsなどのGoogleのサービスは遅延するのか考えてみましょう。
Googleに対して、直接、質問してみたことがありますか？ （私はあります）
マイケル・ジョーダンの言う通り、技術的な困難にぶつかったら、基本に戻りましょう。 基礎知識を学ぶのです。 より下位のレイヤーの技術、よりプリミティブな分野について学ぶのです。
ITシステムに関する技術力は、どうしても属人的でArt(技)の世界になります。 ソフトウェアが物理法則に縛られず、人の思考を紡いで作り出されたものである以上、避けられない事です。 それは、私達、技術者各々の技量が試されるという事を意味します。
来年から品質保証が法律でもきちんと求められる事は、高い技術力を持つ技術者がきちんと評価される事を意味します。
不実証広告規制
性能について、もう一つ大事な話は、現在、消費者庁が強化している不実証広告規制です。
「契約の目的」のところで、「優良誤認」について書きましたが、Webパフォーマンスの改善について、何か広告を出したり、Webサイト上で営業をしている場合には、その表示の裏付けとなる合理的な根拠を示さなければいけません。
試験・調査の方法は、表示された商品・サービスの効果、性能に関連する学術界又は産業界において一般的に認められた方法又は関連分野の専門家多数が認める方法により実施する必要があります。
「Google PageSpeed Insightsで100点を取れます」なんていう表示は、当然ながら、学術界や産業界で一般的に認められた方法でありません。
このような表記は、不実証広告に該当します。 CDNや各種高速化のサービス、ソリューションも、伝統的な品質管理手法に基づく性能試験でのデータを出す必要があります。
品質保証の夜明け前に
来年の改正民法債権法の施行は、日本におけるシステム性能やWebパフォーマンスの本格的な幕開けになるのです。
それは、誰もがWebを作ることができるという、参入障壁を上げる事ではありません。 これからだって、誰でも、Webを作ったり、コーディングすることは可能です。 誰も阻む人はいません。
ただ、技術者であるならば、専門家として、当然身に着けるべき技術というものがあります。 それを身につけましょう。
誰かの意見や発表を参考にするのは良いですが、鵜呑みにせず、必ず検証しましょう。
単にコーディングができるとか、Webを立ち上げる事ができるという事と、技術者として生きるという事の間には、乗り越えなければいけない大きな山や谷があり、だからこそ、専門家としての技術者として存在意義があるのです。
