「アプリケーションのパフォーマンスを改善する」という目標を決めたものの、何をすれば達成に近付けるのかが分からず、どこか腑に落ちない。会議では「サーバーの応答をキャッシュする」という案が出たが、それで遅さを解消できるのか判断する材料がない。
このとき確かめたいのは、キャッシュすれば目標に近付くと判断した根拠である。
たとえば、速くする目的が「利用者の作業を待ち時間で中断させないこと」だとする。この目的なら、利用者がどの操作で待たされているかを調べる。処理時間の長い箇所を見つけても、その操作と関係が薄ければ、改善の優先順位は下がる。
対象の操作が分かったら、現状の待ち時間を計測し、どの程度の時間で完了すれば作業を続けられるのか、目指す状態を決める。
目指す状態と現状に差があれば、その待ち時間の内訳を調べる。サーバーからの応答を待っているのか、受け取ったデータを画面に表示する処理が遅いのか。
計測の結果、サーバーからの応答は速く、データを受け取った後の画面表示に時間がかかっていたとする。さらに処理を調べると、表示に使わない大量のデータの加工に時間がかかっていた。この調査結果を根拠に、表示に必要なデータだけを加工するように変えるタスクを選ぶ。
計測せずに改善へ着手するのは、金脈の手がかりを調べずに山を掘り始めるようなものである。調査して掘る場所を絞らなければ、穴が深くなっても金脈に近付いているかは分からない。
タスクを始める前に、目的や目指す状態に加え、「どの調査や計測から、その問題があると判断したのか」「この作業で改善できると考えた根拠は何か」を確かめたい。根拠が足りなければ、何を調べる必要があるのかを決める。その調査自体が、次に取り組むタスクになる。
事前の計測結果は、作業の効果を確かめるときにも使う。たとえば画面を表示する処理を改善したなら、実施後も表示時間を計測し、着手前の値や目指す処理時間と比べる。狙った変化がなければ、原因の見立てやタスクの選び方を見直す。