品質検査としてのWebパフォーマンス計測手法

Webパフォーマンス(表示速度)は、非機能要求であり、その品質保証には、世界的には統計的品質管理が用いられています。

今、日本で広く用いられているGoogle PageSpeed Insightsや、WebPage Testなどは、品質検査ツールではなく、ITの専門家たるエンジニアは、統計的品質管理による品質保証を行わなくてはいけません。

では、具体的にどのような標準化や規格があり、どのような団体が存在し、どのような計測手法があるのでしょうか？

その詳細と統計分析の観点での重要な概念を解説しました。

Transcript

1. 品質検査としての Webパフォーマンス計測手法 html5j パフォーマンス部 部長 株式会社Spelldata 竹洞 陽一郎
2. 品質保証は、信用経済の基礎 信用は、期待に沿うことであり、 品質管理は、期待のコントロールである
3. 経産省・IPAが進める契約モデル 改正民法債権法に対応するために
4. 経産省の開発プロセスと契約モデル 4
5. 超上流は準委任契約 • ITシステムの構築に必要な知識や知見が高度化 していく中、顧客側で、システム化の方向性を 決めたり、システム化計画を立案したり、要件 定義まで行うことが難しくなっている。 • 建設や建築の設計士が専門家として建造物の設 計を行うように、ITシステムについても、シス テム設計の専門家（アーキテクト）が、顧客の 代理人として設計するのが妥当。
6. 開発は請負契約 • 開発については、従来通り請負型の契約となる。 • 超上流工程は、専門家が設計するため、実現可能性が高くな る – システム化の方向性 – システム化計画立案 – 要件定義策定 • 超上流工程に問題がある場合には、その作業を行った専門家 が善管注意義務を負う • 超上流工程で、専門家が設計した、実現可能性が担保された システムを構築するので、理論上は、その通りにつくれば良 いので、請負契約となる
7. テストは準委任契約 • テストは、どんどん難しくなっているため、発 注者であるユーザ企業がテストを行う事は非現 実的 • テストは、テストの専門家が行うべき – 日本では、テストの専門家の育成が遅れてい る – 日本では、QA/QC/テストエンジニアの地位 が低い
8. デバッグによるテストの問題点 探した場所については砂金の有無を言えるが、探してない場所は分からない
9. V&Vモデル(Verification& Validation) Verification(検証) … 設計どおりに実装されたかどうか Validation(妥当性確認) … 設計され実装されて実現した機能や性能は、本来意図された 用途や目的に適って妥当か？
10. VモデルからWモデルへ 非機能要求ガイド (経済産業省 ソフトウェア開発力強化推進タスクフォース 要求工学・設計開発技術研究部会) より引用
11. VerificationとValidation • Verification – 請負契約での開発についての品質を担保する • Validation – 超上流工程での成果物がそもそも妥当でない 場合には、その責任がValidationで問われる – 超上流工程での成果物が妥当で、開発工程に 問題がある場合にも、その責任がValidation で問われる
12. 性能品質とは • 性能品質が良い・悪い – バラツキが小さい事が、「品質が良い」 – バラツキが大きい事が、「品質が悪い」 • ある目標値に達しているかどうかも大事だが、 その達成度がばらついている場合には、品質が 悪い • 品質管理の目的は、「品質目標に適合しないも のを世に出さない」こと。 – Webパフォーマンスの場合、それは不可能で あるため、「将来」の結果へと繋げる
13. パフォーマンスに関する標準化 国際標準に則って行う
14. Webパフォーマンス計測でよくある話 昨日のAM9:00～PM9:00ま で、自社からChrome Developer Toolsで、1時間 に1回計測してみました。 今日、GoogleのPage Speed Insightsでテストし たら、45点だったよ。 話が噛み合わない。計測手法が異なるため。
15. 標準化の重要性 • 経産省が進める「戦略的国際標準化加速事業」 – 世界に対してモノやサービスを販売する際に、そ の品質の優位性をアピールする、もしくは品質検 査して品質保証する必要がある – 独自の品質検査では、相手に受け入れられない – 品質検査の標準化が重要 – 標準化された品質検査手法に則り、品質保証を行 う事で、品質保証がスムーズに進む – 品質検査手法が、適切ではない場合に、適切な指 標の設定と、その品質検査を標準化することで、 独自の市場を開拓していく
16. 標準化に合わせる重要性 • 共通の「ものさし」で語り合える • 標準化された計測手法に従う事で、正しい計測手法 を導入できる • その都度、相手に要望された「手法」で計測する必 要がなくなる ↓ 品質の比較 品質検査の正しさの保証 業務の効率化
17. W3C Web Performance Working Group https://www.w3.org/webperf/
18. Navigation Timing v2
19. Resource Timing
20. Computer Measurement Group https://www.cmg.org
21. ACM SIGMETRICS https://sigmetrics.acm.org
22. American Software Testing Qualifications Board, Inc. https://astqb.org
23. The Art of Computer Systems Performance Analysis Techniques for Experimental Design, Measurement, Simulation, and Modeling 米国ワシントン大学をはじめとして、コンピューターシステムのパフォーマ ンス計測についての定番教科書
24. Foundations of Software and System Performance Engineering
25. 非機能要求のテスト種別 検証目的に応じてテストを行う
26. Foundation Level Specialist Syllabus Performance Testing 2018 https://astqb.org/assets/documents/ISTQB-CTFL-PT-Syllabus-2018.pdf
27. Principles of Performance Testing • Performance testing is not limited to the web-based domain where the end user is the focus. It is also relevant to different application domains with a variety of system architectures, such as classic client- server, distributed and embedded. Technically, performance efficiency is categorized in the ISO 25010 [ISO25000] Product Quality Model as a non- functional quality characteristic with the three subcharacteristics described below. Proper focus and prioritization depends on the risks assessed and the needs of the various stakeholders. Test results analysis may identify other areas of risk that need to be addressed. International Software Testing Qualifications Board
28. パフォーマンステストの原則 • パフォーマンステストは、エンドユーザーが重視するWebベースのドメインに限定されま せん。 また、従来のクライアント/サーバ、分散型、組み込み型など、さまざまなシステム・ アーキテクチャを持つさまざまなアプリケーション・ドメインにも関連します。 技術的には、ISO25010[ISO25000]の製品品質モデルでは、以下に示す三つの下位特性を 持つ非機能品質特性として、性能効率が分類されています。 適切なフォーカスと優先順位付けは、評価されたリスクとさまざまな利害関係者のニーズ に依存します。 検査結果の分析により、対処すべき他のリスク領域を特定することができます。 International Software Testing Qualifications Board
29. ISO25000における3つの非機能要求 • 時間挙動(Time Behavior) – 一般的に、時間挙動の評価が最も一般的なパフォーマンステストの目的。 – パフォーマンス・テストのこの側面では、コンポーネントまたはシステムが、指定さ れた時間内に指定された条件下でユーザーまたはシステムの入力に応答する能力を調 べる。 – 時間挙動の測定値はシステムが消費する「エンドツーエンド」時間、ユーザー入力へ の応答時間、ソフトウェア・コンポーネントが特定のタスクを実行するために必要な CPUサイクル数などがある。 • リソース使用率(Resource Utilization) – システム・リソースの可用性がリスクとして識別されると、特定の性能試験を実施す ることにより、これらの資源(例えば、限られたRAMの割り当て)の利用状況を調査す ることができる。 • キャパシティ(Capacity) – システムの要求される容量限界におけるシステム挙動の問題(ユーザー数やデータ量 など)がリスクとして特定された場合、性能試験を実施してシステムアーキテクチャ の適合性を評価してもよい。
30. パフォーマンステストの種別 1 • パフォーマンステスト – パフォーマンステストは包括的な用語で、さまざまな負荷の下でのシステムまたはコンポーネントのパ フォーマンス(応答性)に焦点を当てたあらゆる種類のテストを含む。 • 負荷テスト – 負荷テストは、制御された数の同時ユーザーまたはプロセスによって生成されたトランザクション要求か ら生じる、予想される現実的な負荷の増加レベルを処理するシステムの機能に焦点を当てている。 • ストレステスト – ストレステストは、予測または指定されたワークロードの限界または限界を超えるピーク負荷を処理する システムまたはコンポーネントの能力に重点を置く。 – ストレステストは、アクセス可能なコンピューティング能力、使用可能な帯域幅、メモリなど、リソース の可用性が低下した場合のシステムの処理能力を評価するためにも使用される。 • スケーラビリティテスト – 拡張性テストは、現在必要とされている以上の将来の効率要件を満たすシステムの能力に焦点を当てる。 – このテストの目的は、現在指定されているパフォーマンス要件に違反したり障害が発生したりすることな く、システムが拡張(たとえば、ユーザー数が多いほど、保存されるデータの量が増える)できるかどうかを 判断すること。 – スケーラビリティの限界がわかったら、本番環境でしきい値を設定して監視し、発生する可能性のある問 題を警告する。また、適切な量のハードウェアを使用して本番環境を調整することもできる。
31. パフォーマンステストの種別 2 • スパイクテスト – スパイクテストは、ピーク負荷の突然のバーストに正しく応答し、その後定常状態に 戻るシステムの能力に焦点を当てている。 • 耐久性テスト – 耐久性テストでは、システムの運用コンテキストに固有の時間枠におけるシステムの 安定性に重点が置く。 – このタイプのテストでは、最終的にパフォーマンスの低下やブレークポイントでの障 害の原因となるリソース容量の問題(メモリー・リーク、データベース接続、スレッ ド・プールなど)がないことを確認する。 • 同時接続性テスト – 同時接続性テストでは、特定のアクションが同時に発生した場合(たとえば、多数の ユーザーが同時にログインする場合)の影響に重点が置かれる。 – 同時接続性の問題は、特に本番環境のようにテストがほとんど制御できない環境で問 題が発生した場合、発見して再現することが非常に困難であることで知られている。 • キャパシティテスト – 容量テストでは、特定のシステムでサポートされ、規定されたパフォーマンス目標を 満たすユーザーやトランザクションの数を決定する。 – これらの目標は、取引から生じるデータ量に関しても設定される。
32. 今日の焦点は、狭義のパフォーマンス テスト（応答性） • 表示開始、表示完了については、狭義のパ フォーマンステスト（応答性）となる。 • その他のテストについては、今日は取り上げな い。
33. 国際規格に基づく品質設計・検査 ISO/IEC25010と経産省の非機能要求ガイド2018 33
34. 品質モデル ISO/IEC 2501n 品質モデルと品質測定値 34 製品品質モデル ISO/IEC25010 データ品質モデル ISO/IEC25012 利用時品質モデル ISO/IEC25010 人間―コンピュータシステム 情報システム 通信システム 対象コンピュータシステム ハードウェア 非対象 ソフトウェア 対象 ソフトウェア 対象 データ 非対象 データ 一次利用者 二次利用者 もしくは 間接利用者 利用環境 Webパフォーマンスは、利用時品質に属します。
35. 利用時品質モデル 利用時の品質 有効性 有効性 効率性 効率性 満足性 実用性 信用性 快感性 快適性 リスク回避性 経済リスク緩 和性 健康・安全リ スク緩和性 環境リスク緩 和性 利用状況網羅 性 利用状況完全 性 柔軟性 35
36. ソフトウェアライフサイクルと品質ライフサイクルの関係 36
37. プロセス JIS X0133-1＝ISO/IEC14598 37
38. 品質要求プロセス 38 機能要求仕様 品質要求分析 プロセスレベル 制約条件等 • 品質要求分析標準 • 品質モデル • 品質計測 品質要求仕様
39. 品質評価プロセス(JIS X0133-1＝ ISO/IEC14598) 39 評価要求の確立 評価の仕様化 評価の設計 評価の実施 評価目的の確立 評価対象製品の種別の識別 品質モデルの仕様化 測定法の選択 測定法のための評定水準の確立 総合評価のための基準の確立 評価計画の作成 測定値の収集 基準との比較 結果との総合評価
40. WEBサイトのパフォーマンス計測 正しさを保証した
41. パフォーマンス計測の目的 • 速いことを確認するのではなく、遅い観測値が できるだけないことを確認する • 遅い観測値がある＝ばらつきが生じている • インターネットの状況は、刻々と変化している ため、一意に値は定まらない • 計測して検査した期間については結果を語れる が、将来を保証するものではない – 変化し続けるから
42. Chrome Developer Tool
43. Developer Toolは「プロファイラー」 • プロファイリングとは – ソフトウェアエンジニアリングにおいて、プロファイリン グとは、動的プログラム解析の一種で、例えばプログラム の空間(メモリ)とか計算時間、特定の命令の使用、関数呼 び出しの頻度と時間経過を計測する。 – 通常、プロファイリングの情報は、プログラムの最適化の 助けとなるために提供される。 – プロファイリングは、プログラムのソースコードや実行可 能バイナリのどちらかをプロファイラー(もしくはコード プロファイラー)と呼ばれるツールで計測することで成さ れる。 – プロファイラーは、イベントベース、統計的、計測、シ ミュレーション手法など、多数の異なるテクニックが使わ れる。
44. トヨタの自動車の作り方 開発 •企画 •デザイン •設計 •試作・評価 生産技術 •生産性検討 •工程計画→設備検討→設 備調達 •設備トライ→品質確認→ 量産化 生産 •プレス •溶接 •塗装 •組立 •検査
45. 検査だけが品質管理ではない 1か月 検査 (無料) 6か月 検査 (無料) 1年 検査 1年 検査 品質フィードバック
46. 設計 実装 テスト プ ロ フ ァ イ リ ン グ リリース 運用 Web パ フ ォ ー マ ン ス 管 理 フィードバッ ク プロファイリングとパフォーマンス管 理
47. プロファイリングと計測は違う • プロファイリング – 特定環境での調査・試験 – 本番運用して、全国に展開した場合に、その プロファイリングの結果どおりになるとは限 らない – 必ずばらつく • 計測 – 本番運用におけるバラツキの観測 – 実際の品質計測
48. Webサイトパフォーマンスの計測・監視 手法 Last Mile First Mile Middle Mile web server エンドユーザ NTT KDDI エンドユーザ １次ISP RUM Synthetic Server side Last Mile
49. 各計測の補完関係 計測種別 商品名 長所 短所 サーバサイド監視 (Server-side Monitoring) OnPrem インターネットの影響を 受けていないWebサーバ 本来の表示速度を計測で きる。 サードパーティーコンテ ンツ、インターネットの 通信状況の影響が見られ ない。 合成監視 (Synthetic Monitoring) Synthetic Monitoring インターネットの影響を 受けた、ISP毎の表示速度 を計測できる。 実験計画法に基づいた計 測により、問題点を特定 する事が可能。 計測対象ページ以外につ いては、データが得られ ない。 リアルユーザ監視 (Real User Monitoring) Real User Monitoring エンドユーザが体験して いる表示速度を取得する ことが可能。 エラー率が分からないの で可用性分析には使えな い。 エラーになったユーザの データは取得出来ない。 実験に介入できていない ので、因果関係の証明は できない。 表示速度に関わる変数が 非常に多く、それらの数 値が得られないため、品 質管理では使えない。
50. 外形監視という言葉は日本製 • 勝手に言葉をつくるな • Synthetic Monitoringを「外形監視」と称しているが、 Synthetic Monitoringの語源は、Synthetic Dataから来 ている。外形監視というのは、適切な訳語ではない。 • 合成データは「直接測定によって得られていない所定の 状況に適用できる生成データ」である。 – Webパフォーマンスの場合、直接測定によって得ら れたデータはRUM(Real User Monitoring)である。 – Synthetic Monitoringは、測定機器から能動的に1 ユーザとしてアクセスすることで、生成されたパ フォーマンスのデータを獲得するものである。
51. 品質管理の原則 • コントロールできるところに集中する。コントロールで きないところのデータを取っても無駄になる。 web server エンドユーザ NTT KDDI エンドユーザ １次ISP コントロール可能な範疇 コントロール大 コントロール小 コントロール不可能な範疇
52. Webパフォーマンスの 統計的品質管理で重要な概念 • 正確度と精度 • 標本の大きさ • 代表性
53. 世界で用いられている計測手法 Synthetic Monitoring(合成監視） • 統計学に基づいた品質管理手法 – 計測データは、必ずばらつきます。 • システムの状態 • 負荷状態 • インターネット通信網の状態の変化 – 計測値は、決して、一つの値に定まりません。 – 現在の表示速度が、どのくらいの確率で確かな値であるか を求める必要があります。 • 統計学では、「信頼区間」と言います。 信頼区間とは、同じ計測を行った場合に、どれくらいの確率で 同じ結果となるかを指し示す言葉です。 • 合成監視は、実験計画法に基づいた品質管理用計測です。
54. 何故、RUM(Real User Monitoring)ではダメなの？ • 値を形作った変動要因（変数）があまりに多く、且つ、分解できない – ネットワーク要因 – 端末要因 – プラグインの影響 • 品質管理の原則 – 値を知っても、そこに手を出すことができない – コントロール可能な限界はどこかを知り、そこで計測する • 欠損値の存在の有無が確認できない – エラーになったり、観測値が取得できなかった場合には、その存在を知りえない – 欠損値のモデルをつくって分析しなくてはいけない – 欠損値を除外して分析すると、偏ったデータであるため、誤った結論へと導かれる (Garbage in, Garbage out) • Cookieベースの実装が多く、初回訪問の値は取得できない – AppleのITP(Intelligent Tracking Prevention)の影響をモロに受ける • 観察者効果がある – 計測用のJavaScriptが、パフォーマンスに影響を及ぼす
55. 正確度と精度 系統誤差と偶然誤差
56. 正確度と精度 • 正確度 – その値が「真値」に近い値であるかを示す尺度。 – 系統誤差の小ささを指す。 • ある測定における測定値に、同じ手法を用いて測定す る限り、「真の値」に対して系統的にずれて測定され るような誤差 • 精度 – 複数回の観測値の間でのバラツキの小ささを示す 尺度 – 偶然誤差の小ささを指す。 • 測定ごとにばらつく誤差
57. 正確度と精度 低い 低い 正確度 高い 精度 高い 真値～ 神様だけが 知っている値
58. Webパフォーマンスの「真値」とは？ • RUMの値が「真値」なのか？ web server エンドユーザ NTT KDDI エンドユーザ １次ISP コントロール可能な範疇 コントロール大 コントロール小 コントロール不可能な範疇 表示完了1秒 表示完了1.2秒 表示完了1.5秒
59. 正確度と精度 低い 低い 正確度 高い 精度 高い 真値～ 神様だけが 知っている値 Synthetic Monitoringの値 RUMの値 確率的に推測で きる 割り算で 劣化率が測れる 変数を分解できない のでたどり着けない
60. 標本の大きさ 確率的に真の値へと近づいていく
61. 母集団と標本（サンプル） 神のみぞ知る母集団の真の平均の値 μ 標本（サンプ ル） 母集団 標本から得られた平均 ｘ
62. 真の値には、 確率的に近づいていくしかない
63. ラプラスの魔 もしもある瞬間における全ての物質の力 学的状態と力を知ることができ、かつも しもそれらのデータを解析できるだけの 能力の知性が存在するとすれば、この知 性にとっては、不確実なことは何もなく なり、その目には未来も（過去同様に） 全て見えているであろう。 — 『確率の解析的理論』1812年
64. 1回だけの計測は、何も保証できない • 統計学的には、最低でも1日あたり20～30の標 本が欲しい – 標本数が少ない場合は、検定が必須 • データの粒度 – 日単位の表示速度を算出したいのか – 時間単位の表示速度を算出したいのか
65. 偏差 ～ 平均値との「距離」を見る 平均 パフォーマン ス 時 間 の 経 過 平均と実際の計測値との 差 1秒 2秒 3秒 4秒 5秒 6秒 7秒 8秒
66. 平均値と標準偏差
67. 大数の法則 • nが大きい時、標本平均ｘは、真の平均μに近づ く
68. 中心極限定理 • ｎが大きい時、標本平均と真の平均の差、ｘ-μが従 う分布は、平均0、分散σ2/の正規分布に近づく 平均 ｘ 平均 ｘ 平均 ｘ
69. 1時間の計測
70. 12時間の計測
71. 24時間の計測
72. 7日間の計測
73. 30日間の計測
74. 中央値（Median）と75パーセンタイル 値の変化 中央値 75パーセンタイル値 1時間 896.00ミリ秒 1087.00ミリ秒 6時間 886.50ミリ秒 1057.00ミリ秒 24時間 855.00ミリ秒 950.00ミリ秒 1週間 847.00ミリ秒 943.00ミリ秒 2週間 846.00ミリ秒 962.00ミリ秒
75. 累積分布関数 計測期間中、全体の何％までが表示開始0.5秒、表示完了2秒であるかで評価する
76. 代表性 その計測は、何を代表しているのか
77. 代表性とは • 調査・統計において、標本が母集団をよく代表 しているかどうかの程度を指す。 • モバイルサイトの計測をするのに、4Gエミュ レートをして計測した結果は、携帯網でのパ フォーマンスを真に代表するにふさわしいの か？→ No • 自社のネットワークで計測した値は、他のISPで の値を代表するにふさわしいのか？→ No • 東京で計測した値は、日本全国を代表するにふ さわしいのか？→No
78. フィッシャー三原則 実験計画法の基礎
79. 実験計画法に基づく計測 • 実験計画法 – 統計学の大家R・A・ フィッシャーが1920 年代に発案 – 現在の統計分析のデー タ取得の基礎となる。
80. 実験計画法 • 三つの基本原則 – 局所管理化 影響を調べる要因以外の全ての要因を可能な限り、 一定にする。 – 反復 実験ごとの偶然のばらつき(誤差)の影響を除くた めに、同条件で反復して行う。 – 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある 要因の影響を取り除き、偏りを小さくするために 条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くた めに、ランダム化する。
81. 合成計測における実験計画法3原則の適用 • 三つの基本原則 – 局所管理化 影響を調べる要因以外の全ての要因を可能な限り、一定にする。 → 計測機器の統一、回線帯域の統一、ブラウザの統一 – 反復 実験ごとの偶然のばらつき(誤差)の影響を除くために、同条件 で反復して行う。 → 5～60分に1回の計測を24時間365日自動で計測する – 無作為化(ランダム化) 局所管理化や反復でも制御できない可能性のある要因の影響を 取り除き、偏りを小さくするために条件を無作為化する。 計測を行う地域、時間、順序の影響を取り除くために、ランダ ム化する。 → 計測を行う時間をランダム化
82. 実務でどのように検査計測するか 納品時の検査
83. 売買についての追完等の請求 引渡し日 契約目的不適合を知った日 ６ヶ月 追完等の請求を1年以内に 品質の検査 法人は、商法526条により、品 質などを検査しなくてはなら ない 1年
84. 請負についての追完等の請求 引渡し日 契約目的不適合を顧客に通知 1年間 追完等の請求を1年以内に 品質の検査 請負側が行う （試験しないと知りようがないため通知 そのものができないので重過失）
85. デスクトップサイトの 品質検査計測の計画 • 主要動線での計測を行う – トランザクション計測と言う – テンプレートが同じであれば、他のページでもほぼ同じ値となるので、全てのページ を計測する必要はない – ヒューリスティックキャッシュの影響を考慮して、現実的なパフォーマンス計測が可 能 • 計測は、Synthetic Monitoringで行う – 変数を止めて、精度が高い、分解可能なデータを得る事ができる – 複数のISPで行うことが重要 – 計測拠点とISPは、当然ながら、実際のユーザの所在地の分布を考えて選出する – 実務上は、東京と大阪の、NTTとKDDIの計測で、人口の40%以上をカバーできる • 計測期間は、最低でも1カ月行う – 日次パターンだけでなく、週次パターンも得る事ができる。 – 15分に1回の計測であれば、1日あたりの標本の大きさは、1 ISPあたり96なので、十 分な大きさ。 – 1か月計測すると、2,976の標本サイズなので確からしさは十分にある。
86. モバイルサイトの 品質検査計測の計画 • 主要動線での計測を行う – トランザクション計測と言う – テンプレートが同じであれば、他のページでもほぼ同じ値となるので、全てのページを計測する必 要はない – ヒューリスティックキャッシュの影響を考慮して、現実的なパフォーマンス計測が可能 • 計測は、Synthetic Monitoringで行う – 変数を止めて、精度が高い、分解可能なデータを得る事ができる – できれば、3キャリアのリアル4Gで行う – 4Gエミュレートも併せて計測する – リアル4Gと4Gエミュレートと双方計測することで、遅延があった場合に、基地局やキャリアのコ アネットワークに起因するのか、サーバに起因するのか、判別できる • 計測期間は、最低でも1カ月行う – 日次パターンだけでなく、週次パターンも得る事ができる。 – 15分に1回の計測であれば、1日あたりの標本の大きさは、1 ISPあたり96なので、十分な大きさ。 – 1か月計測すると、2,976の標本サイズなので確からしさは十分にある。
87. 高い品質を証明して、信用を高めて、 ブランドを確立しましょう