問題発生時の自己解決について
UiPathでは様々なところでエラーが発生します。
今回はこれを自己解決するヒントについて書いていきます。
自己解決について
自己解決の必要性
そもそも他に聞く相手がいるのであれば(Enterprise版ならテクニカルサポート、Community版ならフォーラムなど)そちらに聞いたほうがよいのでは？と思う人もいるかもしれません。
しかし、自己解決力を上げることで聞くより様々なメリットがあるため、是非自己解決力を高めてなるべく自己解決するようにすることをお勧めします。
自己解決に向いている問題
ここまで自己解決をしましょうといっていますが、何でもかんでも自己解決するのがよいというわけではなく、自己解決に向いている問題があります。
自己解決に向いている内容
・自己の権限範囲内で解決可能。(自己の権限の範囲で操作できる範囲は調査する）
・緊急性が低いもの。
・ワークフローなどの開発段階のエラー
自己解決に向いていない内容
・権限がなく、調査が難しい内容（Orchestratorなどでアクセス権がない場合など）
・緊急性が高いもの（作成済みのプロセスが止まってしまったなど現在影響が発生している状態等）
自己解決のメリット、デメリット
メリット
・自己の技術が向上する。
・調べる力が付く。（思ったよりこれができない人が多いのでこれが付くのは大きいです）
・短期解決できる可能性が高くなる。（すでにある程度調べている状態なので調査の範囲が絞れる）
デメリット（留意点）
・緊急性が高いときには自己解決しようとすると危険。
・場合によっては時間がかかる場合がある。（権限がない場合など調査ができない場合）
・そもそも自己解決が困難な環境がある。（テストができないような環境）
自己解決に向けた調査手順について
ここではいくつかのケースで自己解決のヒントを記載します。
全問題に共通すること
・エラーが発生している場合はそのエラー文で調べてみましょう。
・UiPathの公式ガイドを読んでみましょう。
ケース１：ワークフローを実行するとエラーが発生した
いくつか切り分けを行いましょう。
以下切り分けの例です。
・ワークフローの実行前にエラーなのか、実行中にエラーなのか確認しましょう。（ワークフロー内でエラー表示がないか確認しましょう。）
・ワークフローのどこでエラーが発生しているか確認しましょう。
・エラー発生個所だけを抜き出して個別テストするとどうなるか確認しましょう。（ワークフローに依存して発生しているかとほかの箇所が影響しているかの確認）
・他の端末があれば他の端末でも検証してみましょう。(端末に依存しているかの確認）
解決できないときの聞き方
切り分けを実施した上で解決できない場合は聞くことになりますが、ここまで試したことをちゃんと伝えてから聞きましょう。
（聞き方の例）
〇〇というワークフローを実行したらXXというエラーが発生した。
エラーは△△という箇所でエラーになっていたので、この部分だけを別のワークフローで検証したが、やはりエラーになった。ほか端末でも同じくエラーになる。解決方法を教えてほしい。
ケース２：開発時にはエラーが出なかったが本番環境ではエラーになった
このケースも切り分けが可能です。以下のような観点で切り分けをしてみましょう。
・本番環境と開発環境で使用しているアプリケーションに差はないか？
(UiPathに限らず、例えばブラウザを使う場合はブラウザのバージョンや設定も同一か？）
・可能であれば実行方法を変えてみましょう。(例：Assistantから実行している場合はOrchestratorから実行してみる）
・可能であればケース１と同様の調査を行いましょう。
解決できないときの聞き方
こちらも自己解決ができないときには試したことをしっかり踏まえて聞くようにしましょう。
（聞き方の例）
開発環境では問題なく動作したプロセスを本番環境でAssistantから実行したら、xxというエラーが発生した。このエラーは〇〇というワークフローの△△という場所で発生しているように見受けられたので、ここ部分だけを抜きだして単体テストをしたところ動いた。しかし、元のプロセスでは動かないので解決方法を教えてほしい。本番環境と開発環境の差は◇◇という点があります。
コメント