ターンアラウンドタイムとレスポンスタイム
- Sun
- 17:27
- misc
ターンアラウンドタイムとレスポンスタイムについて、誤解があるのか方言があるのか人により微妙に意味が異なっているような時があります。
一般的にターンアラウンドタイムが短縮されるとユーザの満足度が上がり、レスポンスタイムが短縮されるとユーザのイライライ(ストレス)が減るとされています。
で、最近気づいたのが銀行やレンタル屋さんなど昔からあるIBMでいうところの「適用業務」の経験がある人と、Webサービスしか経験がない人との間でその差が大きいような気がします。
どちらの場合も重要なのは、「処理」の区切りをどこにするかというこです。特にターンアラウンドタイムは一連の処理が完了するまでという区切りになるので「処理」の定義をあいまいにしておくと実際にはやらなくていい処理、業後や夜間バッチでやるべき処理まで含めてしまい業務が回らない作業フローやJOBフローを作ってしまう場合があります。

レンタル店の会員カード発行の処理はターンアラウンド/レスポンスタイムを説明するのによく使われる例です。
ポイントは、レスポンス2のところで申込書にある項目全てをその場で入力するのではなく、カード発行に必要な申込書とカードの紐付けだけを行うということです。そうしないと、貸出・返却のお客さんを待たせてしまい、カウンターに長蛇の列ができてしまいます。
名前や住所等その場で必要のない情報は、暇な時間やお店を閉めた後でゆっくりやればいいのです。

昔のGoogleはいち早くユーザを検索結果のページの先に飛ばすことを優先していましたが最近は検索結果内で完結できるようにして満足度を上げようとしています。
例えば、queen don't stop me now lyricsを検索すると検索結果ページに歌詞が表示されます。これは、レスポンスタイム3の処理を2に含めることでターンアラウンドタイムを短縮しています。ユーザはさらに別のページ飛ぶ必要がない(待たされない)ので、顧客満足度の向上が期待できます。
このように、ターンアラウンドタイムとレスポンスタイムはサービスを向上させるための大事な指標になります。
処理の区切りを単に「リンクをクリックしてページを表示する」とした場合、ターンアラウンドタイムとレスポンスタイムはほぼ同じものになります。しかし実際にはそういったものを「処理の単位」とすることはほとんどありません。Googleのレスポンスタイム2のように「ユーザの入力時間」「送信時間」「Google側の処理時間」「結果の受信時間」というようにそれぞれの時間の合算になります。
また「ユーザ登録」という処理を考える場合、「ユーザ登録ボタン押下」「ユーザ情報の入力」「内容の確認」「完了報告」というレスポンスタイムを計る必要があるかもしれません。もし「ユーザ情報の入力」の時間が長い場合は、UIが分かり難い、不要な項目まで入力させている、そもそも入力し辛い、などが考えられます。改善することで登録完了数を増やすことが可能かもしれません。但し時間だけを見ても分かり難い場合が多いのでトラッキングや他の指標なんかも参考にする必要があります。
ということで、この2つの処理時間を使ってサービスを改善するためにはターゲットとする処理の単位をどう設定するかが重要になります。
ターンアラウンドタイム | 一連の処理の開始から完了までの時間 |
レスポンスタイム | ユーザのアクションから応答までの時間 |
で、最近気づいたのが銀行やレンタル屋さんなど昔からあるIBMでいうところの「適用業務」の経験がある人と、Webサービスしか経験がない人との間でその差が大きいような気がします。
どちらの場合も重要なのは、「処理」の区切りをどこにするかというこです。特にターンアラウンドタイムは一連の処理が完了するまでという区切りになるので「処理」の定義をあいまいにしておくと実際にはやらなくていい処理、業後や夜間バッチでやるべき処理まで含めてしまい業務が回らない作業フローやJOBフローを作ってしまう場合があります。
レンタル会員のカード発行処理のターンアラウンドタイムとレスポンスタイム

レンタル店の会員カード発行の処理はターンアラウンド/レスポンスタイムを説明するのによく使われる例です。
ポイントは、レスポンス2のところで申込書にある項目全てをその場で入力するのではなく、カード発行に必要な申込書とカードの紐付けだけを行うということです。そうしないと、貸出・返却のお客さんを待たせてしまい、カウンターに長蛇の列ができてしまいます。
名前や住所等その場で必要のない情報は、暇な時間やお店を閉めた後でゆっくりやればいいのです。
GoogleでTPPを調べる処理のターンアラウンドタイムとレスポンスタイム

昔のGoogleはいち早くユーザを検索結果のページの先に飛ばすことを優先していましたが最近は検索結果内で完結できるようにして満足度を上げようとしています。
例えば、queen don't stop me now lyricsを検索すると検索結果ページに歌詞が表示されます。これは、レスポンスタイム3の処理を2に含めることでターンアラウンドタイムを短縮しています。ユーザはさらに別のページ飛ぶ必要がない(待たされない)ので、顧客満足度の向上が期待できます。
このように、ターンアラウンドタイムとレスポンスタイムはサービスを向上させるための大事な指標になります。
処理の区切りを単に「リンクをクリックしてページを表示する」とした場合、ターンアラウンドタイムとレスポンスタイムはほぼ同じものになります。しかし実際にはそういったものを「処理の単位」とすることはほとんどありません。Googleのレスポンスタイム2のように「ユーザの入力時間」「送信時間」「Google側の処理時間」「結果の受信時間」というようにそれぞれの時間の合算になります。
また「ユーザ登録」という処理を考える場合、「ユーザ登録ボタン押下」「ユーザ情報の入力」「内容の確認」「完了報告」というレスポンスタイムを計る必要があるかもしれません。もし「ユーザ情報の入力」の時間が長い場合は、UIが分かり難い、不要な項目まで入力させている、そもそも入力し辛い、などが考えられます。改善することで登録完了数を増やすことが可能かもしれません。但し時間だけを見ても分かり難い場合が多いのでトラッキングや他の指標なんかも参考にする必要があります。
ということで、この2つの処理時間を使ってサービスを改善するためにはターゲットとする処理の単位をどう設定するかが重要になります。
- 関連記事
-
- Nokia 2を購入したので早速開封
- 2018年元旦にアメリカのAmazon.comでお買い物
- ターンアラウンドタイムとレスポンスタイム
- graphvizのノードにHTMLを記述
- Gitでのtag付けについて
Comment
Trackback
- URL
- https://nosource.blog.fc2.com/tb.php/161-32085280
- この記事にトラックバック(FC2Blog User)