チームメンバーとの性能検証に関して雑談したのが面白かったので書きます。
その性能検証の対象は体験か、システムか？
検証したい対象がユーザーの体験なのかシステムなのかによって、性能検証のモデルや実施内容、課題解決策も異なります。
体験を検証する場合は、ユーザーの実際の行動を想定し、リアルで大きなデータ量を用いてシステムの性能を検証します。検証結果の評価は、定量的な秒数よりも定性的な待ち時間の感じ方が基準です。TTI（Time To Interactive）を用いることもあります。解決策としても、待ち時間をなくす方法を選択することがあります（レスポンスタイムの削減以外にも、スピナーやメッセージングなどの方法もあります）。
一方、システムを検証する場合は、システムが許容または想定している最大のデータ量で、あらゆる操作について検証する必要があります。検証結果は、全体およびそれぞれの責任分界点（ネットワーク、API、DB、レンダリングなど）の実行時間を確認するでしょう。目標値に達していない場合は、ボトルネックの解消のためにリファクタリングが必要です。
体験とシステム、優先順位が高いのは？
プロダクトの特性によって異なるでしょうが、実際にユーザーが操作して利用するプロダクトの場合、まずは良い体験を保証することが重要です。それぞれの責任分界点での性能基準を満たしていることは、「なんか重いな…」と感じているユーザーには関係のないことです。
体験とシステムの検証を混同しない
性能検証の設計を進める中で、体験とシステムの検証が混ざってしまうことがよくあります。
体験を検証しようとしているにも関わらず、突然「この入力項目の最大文字数は1000文字なので、すべてのデータを1000文字にしよう！（本当にみんな1000文字で使ってる？）」とか。 「このテストケースはNGですが、DBチューニングはやりきったしここまで！（待ち時間を感じさせない方法は考えた？）」とか。 結果として、複雑に捉えてしまい八方塞がりになったり、性能検証やパフォーマンスチューニングに余計な時間を費やすこともあります。
都度、現在行っている性能検証が体験とシステムのどちらを対象にしているのかを再確認し、対象と設計や解決策が適合しているか、もう一方の対象に支障をきたしていないかを常に確認することが重要です。
まとめ
- 性能検証では、「体験」と「システム」の両方が対象となり、それによって「設計」「モデル」「解決策」なども異なる
- 両方の対象を同時に検証しようとすると複雑さが増し、コントロールしづらくなる
- 実際にユーザーが体験する側に立った検証を優先することが大切
- 性能検証中でも体験とシステムが常に混同しやすいため、対象に立ち戻り、自身の目指す方向との適合性を確認し続けることが大切
では🖐️。
