はじめに

Pickは便利

Pick（分岐を選択）アクティビティは想定される要素が複数種類あるとき、無駄な待機時間を発生させない点で優れています。

下図は「天気予報の結果次第で洗濯物を干すか決める」ロボットをPick処理で作ったサンプルです。

上記の処理は天気が晴れでも雨でもほぼ同時に要素を認識して次の処理に進みます。

一方、もしもPick処理を用いずにIFとElementExists（要素の存在を確認）のみで処理を構築すると、
1番目の候補が表示された場合はすぐに処理が進みますが、
2番目の候補が表示された場合は最初の候補のタイムアウトを待つため無駄な待機時間が発生します。

記事タイトルの「落とし穴」と形容した部分です。

当然ながら天気は「晴れ」「雨」のみではありません。
今回は天気が「雪」だった場合に先ほどの処理（つまり雪を想定していない）を動かした結果を見てみましょう。

「雪」であるのに「晴れ」であると判定されてしまいました。
これでは洗濯物はびしょ濡れです。

「晴れ」「雨」しかロボットには設定していないので正確に判定できないのは仕方ありません。
しかし、想定した要素が見つからない場合はエラーで止まって欲しいですよね？

なぜこんな事が起きたのでしょうか？

※なお、今回は「晴れ」と判定した結果を載せましたが、ランダムで「雨」にも分岐します。Pickに設置したアクティビティは左側から完了するとは限らないためです。

端的に言えば、リトライスコープとPickは全く別物であるためです。

外観が似ているため誤解を招きやすいですが、

リトライスコープは条件部に設置したElementExists（要素の存在を確認）の結果を判定している。
Pickのトリガー部は単純に「実行できたか？」しか見ていないようです。よってElementExists（要素の存在を確認）の結果がFalseであっても「実行できている」ため、
最初にトリガー部を完了しきった分岐のActionを実行します。

ElementExists（要素の存在を確認）と名前が似ているFindElement（要素を探す）を設置してみた際の結果を見てみましょう。

Actionは実行されず、無事トリガー部でエラー停止する事が出来ました。

最後まで処理を完了することはできませんが、これがもし業務であったならば
想定された要素が見つからないとき、適当な分岐を進む
よりはずっと安全ですね。