皆のStudioテンプレートのこだわりを語ろう！エラーハンドリングの今昔物語を添えて

登壇者紹介 ガボッツ ファシリテーター Wacky パネラー Rei パネラー チーフ パネラー UiPath歴：7年 UiPath暦：7年 UiPath歴：7年弱 UiPath歴：7年 Studioテンプレートは ５種類ほど利用経験があ ります。様々なコンセプ トや構成を見てきたので、 皆様のこだわりを聞くの が楽しみです。 現在の職場では、テンプ レート導入・開発し、定 着課題に取組中。前職で はReFrameworkを元 にしたテンプレートをい くつか扱ってました 自社ではAR Frameworkベースのテ ンプレートを使用してい ます。そろそろ最新化し たい。 某市民開発の現場で テンプレートの導入・ カスタマイズの経験あり。 昔のAttended Frameworkが好き でした

PART 1: こだわり 「使いやすさ」と「保守性」の両立をどう捉えるか

3つの軸に集約された「こだわり」 シンプル・標準化 効率・共通化 ガバナンス 初心者でも迷わず書ける 定形処理（Config読込、Kill等）の リリース後の保守性を考慮したア 「最小限」の構成。 事前実装。 セット 粒度や表現を揃え、個人の癖を 1から作らない、使い回せる「全部 活用。 出さない徹底したシンプル主義 入り」での生産性向上。 情報漏洩防止のための「スクショ 禁止」などの独自ルール。

参加者のテンプレートのこだわり 1/2 1.【シンプル・標準化重視】（迷わせない、ばらつきを防ぐ） ⮚ ロボごとにテンプレートをいじる必要がないように、開発初心者でも使いや すいようこころがけています。 ⮚ 全社共通で使用していて差し替えなどもあるため、とにかく思う事があって も個人的に手を入れないようにしてます。 ⮚ 誰でも迷わず書けるシンプルさを重視しています。また粒度や表現を揃えて、 ばらつきが出ないようにしています。 ⮚ なるべくシンプルに！ ⮚ できるだけ最小限に。最初と最後は同じにできるように作りました。 ⮚ いまはＵＲ（Unattended Robot）ロボ作成を自社のテンプレートから作成 しています。

参加者のテンプレートの“こだわり” 2/2 2.【機能・効率重視】（共通処理の埋め込み） ⮚ 似たような処理の場合は1から開発しなくて良いように、共通処理は全部組込 んだテンプレになっている。 ⮚ Configの読み込みやKill Processなどなど、定形のものをいつも設定しなくて よいのがいい。一度作成したら、使いまわせて便利。 3. 【保守性・ガバナンス】 ⮚ アセットとConfigを使い分けてリリース後の保守性を保つこと。 ⮚ エラー時にスクショを撮る機能は情報漏洩に繋がるため禁止にしています。 4. 【未経験・これから】 ⮚ テンプレートの使用実績がありません。 ⮚ テンプレートを使ったことがありません。活用事例を教えてください。

PART 2: 現場からの「教訓」 失敗から学んだ、テンプレートのあるべき姿

運用で見えてきた「テンプレートの落とし穴」 過剰設計の罠 堅牢性の責任 意思疎通の難しさ 作り込みすぎるとソースが肥大 環境起因のエラーも「テンプレ メモやコメントが不足している 化し、不要な部分を整理する手 ートの責任」に。エラーハンド と、修正箇所の判断がつかず、 間が発生。結局「使われない」 リングは想像以上に堅牢である 意図せぬカスタマイズが本番へ。 悲劇へ。 べき。

参加者のテンプレートの“教訓” 1/3 1. 【作り込みすぎの失敗】（シンプルへの回帰） ⮚ 以前は細かく作りすぎて入力が大変になり、使われなくなったこ とがありました。それ以降は使い続けられるシンプルさを優先し ています。 ⮚ 様々な処理内容を組み込んで作成することを考えていましたが、 自動化したい業務内容がとても幅広いため、部品を作り込みすぎ るとソースがやや見づらくなってしまう。また、不要な部分を整 理する際に時間がかかってしまうことが想定されたので、Config ファイルの存在確認と読み込み＋ログ出力のみに落ち着きました。 あとはライブラリ＆気合でカバーします。 ⮚ テンプレートなのに意味のない（使ってない）変数を設定したま まにしていた。また、実装してあるものの結局誰も使わない機能 があった。

参加者のテンプレートの“教訓” 2/3 2. 【エラーハンドリングの落とし穴】 ⮚ テンプレートで発生したエラーは環境起因でもテンプレート の責任になるため、エラー発生時の処理は堅牢に作ったほう がよいです。 ⮚ 開発当初はエラーハンドリングを意識せずに開発を進めてい ました。おかげでエラー対応には多くの工数が……。スクリ ーンショットの撮影、エラーアクティビティのログを残すこ との重要性を学びました。

参加者のテンプレートの“教訓” 2/3 3. 【可読性とコミュニケーションの課題】 ⮚ どの部分を修正する必要があるのか、修正してはいけないの かが分かりにくい。 ⮚ カスタマイズして使ってもらうことが前提で入れておいたコ メントが、そのまま本番使用まで行ってしまうことがあった。 もう少し使用方法をわかりやすくするようにメモを入れるよ うにしないとと思いました。 4. 【データハンドリングの最適化】 ⮚ 設定ファイルを読み込んで辞書型にして……とやっていまし たが、辞書型の変数を使って毎度毎度書くのは大変なので、 使用頻度が高いものは変数に格納させることを身に着けてい きました。

PART 3: 今後の「質問」と論点 これからのテンプレート設計に欠かせない問い

議論したい「4つの問い」 設計思想の選択 共通化の範囲 最新機能の活用 運用・寿命 REFramework（キュ 共通部品は「ライブ Orchestratorのレコ メンテナンスのタイ ーなし）はあり？ステ ラリ化」すべきか？ ーディング機能があ ミングは？長時間実 ートマシンは必要？ メール送信やアセッ る今、エラー時のス 行ロボの生存確認は BusinessRuleExceptio ト取得はテンプレに クリーンショットは どうする？堅牢 vs 自 nの使い分けは？ どこまで含める？ 本当に必要か？ 由度の決着は？

参加者の質問 1/2 1. 【設計思想：シンプル vs 堅牢】 ⮚ テンプレートは「簡素でユーザー改変多少あり」 or 「堅牢で ユーザー編集は許さない」どちらですか？ ⮚ ステートマシン使う？ ⮚ REFrameworkのキューを使わないものってどうだろうか？ 2. 【共通化と保守運用のリアル】 ⮚ 共通部品はライブラリー化する？ ⮚ アセットからのデータ取得はテンプレートに含める？ / アセ ットとConfigの使い分け ⮚ テンプレートのメンテナンスのタイミングと内容は？

参加者の質問 2/2 3. 【エラーハンドリング・ログの今昔】 ⮚ BusinessRuleException使ってる？ ⮚ OC（Orchestrator）のレコーディング機能がある現在、エラ ー時のスクリーンショットは必要ですか？ ⮚ 保守の人が嫌がるエラーはありますか？ 4. 【固有の個別実装に関する悩み】 ⮚ メール送信どうしてる？ ⮚ 長時間実行のＵＲロボってどうして確認している？ ⮚ SharePointからのDLやアップロードを使うことがあるけど難 しくて、DLで失敗することがあるんだけど、どう対応したら いい？

まとめ 質問：“現在”の皆様のテンプレートのこだわり要素は？ 最初は気合でカバーできても、規模が拡大するにつれてテンプレートの重要性は増します。 今日集まった「教訓」を活かし、自社に最適なバランスを見つけましょう。