【UiPath】読みやすいフローを書くコツ（概要編）

# はじめに

この投稿は、RPAツールの「UiPath Studio」で「読みやすいフロー」を書く方法 について、個人的にまとめたものです。量が多いので 数回に分けて書きます。

UiPath Advent カレンダーの 2 日目 の記事でもあります。

https://qiita.com/advent-calendar/2022/uipath

# 読みやすいフローとは

エンジニア界隈では有名な「リーダブルコード」という名著がありますが、その冒頭で以下のように書かれています。


:::note info
リーダブルコード ＝ **読みやすい**コード
**他の人**が読んだ時に、**最短時間**で理解できるコード
美しいコードを見ると **感動** する。
優れたコードは **見た瞬間に何をしているかが伝わってくる**。
そういうコードは **使うのが楽しい** し、
**自分のコードもそうあるべきだ** と思わせてくれる
:::

自分だけでなく、`他の人に取っても「優しい・ストレスレス」` というのがポイントで、「リーダブルコード」の書籍の中では 書き方のテクニックが紹介されています。

この投稿では、UiPathのフロー開発で 読みやすいコードを書くために、自分が「気をつけているポイント」を書きます。

https://www.oreilly.co.jp/books/9784873115658/

# RPA 開発 ならではの「読みにくさ」

RPA 案件は「開発環境」がタイト／ハード／スモールであるため「読みにくさ」を生み出します。

:::note warn
・開発にかける時間が短い　＝　完璧を目指せない、コード見直す時間が少ない
・少人数または一人で開発　＝　学びが少ない、他人の優れたフローに触れられない
・レビューする現場はレア　＝　雑になりがち、自分のダメな書き方に気づけない
・RPAは動かなくなるもの　 ＝　動けば中身はどうでも良い！という危険な発想へ
:::

つまり、**少ないリソース（時間と人）** で、より多くのロボットを作り上げる状況が多いため、見直しや学習に充てられる時間は軽視されがちで、「その時その人にしか分からない」フローになることも多いです。


# ローコードツール ならではの「読みにくさ」

UiPath は「ローコード開発ツール」であり、その特徴が「読みにくさ」を生み出します。

:::note warn
誰でも簡単に作れる　　　　　　　　＝　作る人次第では品質が低くなりがち
アクティビティを組み合わせて作成　＝　無駄に縦横に長くなりがち
お手本的な書き方が世の中に少ない　＝　書き方が強引・自分勝手になりがち
複雑な業務の自動化要望も結構ある　＝　難しい仕様 × 未熟なフロー ＝ 読取不能に
:::

つまり、**何も考えずに作る** と、必然的に複雑になり「読みにくいフロー」になってしまう。
（業務仕様がシンプルでコンパクトであれば、複雑になりにくいですが、それはそれで雑になりがち）


# 作る人の経験差による「読みにくさ」

出来たフローは、作った人の「理解レベル・考え方」を多少なりとも表します。
個人差はありますが、自分の経験でいうと例えば、以下のようなイメージです。

| RPA以外<br>の開発経験|UiPath<br>の開発経験 | 陥りがちな状態 |
|:-|:-|:-|
| なし| 始めたばかり | [Xaml分割] あまり分割せず。ひとつのxamlで色々やりたがり<br>[所感/感想] 迷いを感じる・全体の統一感が低い |
| あり| 始めたばかり | [Xaml分割] 分割はソコソコする（が、引数多めで辛い）<br>[所感/感想] 自分勝手で読みにくい。無駄に複雑化してる |
| なし| 少しあり     | [好きなフロー] フローチャート<br>[書き方ルール] 曖昧・統一感はまだ低い |
| あり| 少しあり     | [好きなフロー] シーケンス<br>[書き方ルール] 編み出したマイルール|

UiPathでロボット開発をする上で「RPA以外の開発経験」は `あったほうが良い` のは確かです。知識の土台として、引き出しとして役に立ちます。

ですが「`ツール＝Studioの理解が低い`」状態で、我流で学習していると「なんだ簡単じゃん！完全に理解した！」と勘違いをしてしまう事も。

そんな感じで調子に乗っていると、大抵「読みにくい」フローを作っています。パッと見は`「キレイ」に見えるけど、よく見ると「複雑」`なフロー。生半可に自身がある分だけ厄介で、勢いで「残念」なフローを沢山作ってしまう。で、あとで「なんであんな作り方してたのか？」って後悔します。

ただこれは、みんなが辿る、ある種の「通過点」とも思います。その先に目指すべきものがありそう。

アジャイル開発やコードレビューの経験、チームでの開発経験も大事。なぜなら`「良いフロー」は、自分以外も含めた、沢山の知見が無いと書けない`からです。

一人チームや周りに\相談できる人がいないような環境でも大丈夫、ネットやコミュニティで積極的に情報を仕入れれば、補えます。

大事なポイントは「自分がベストだ！最高だ！」と思わず、`より良いものを目指し、素直に周りの意見を聞く姿勢`です。「過去の自分よりも良くしよう！」「このやり方は良くなかったかも？」「他の人の良いところを仕入れよう」という気持ちが大事。


# 「読みにくい」フローはなぜダメなのか？

読みにくいフロー と 読みやすいフロー では、チームと保守開発にとって、大きく差が出ます。

| | 読み「にくい」フロー | 読み「やすい」フロー |
|:-:|:-:|:-:|
| **他の人**<br>にとって | **厳しい**<br>・読んだだけで　「嫌悪」を感じる<br>・頑張って読むが「疑問」が増える<br>・なぜこうなのか「怒り」を感じる  | **優しい**<br>・読んだだけで「概要」が分かる<br>・内容が「ストレス無く」分かる<br>・書き方を「真似」したくなる　 |
| **追加開発**<br>をする時に | **保守できない**<br>・読み解きに「異常に時間」かかる<br>・「分からな過ぎ」て微修正も怖い<br>・手を出せなくて「作り直し」たい |**保守しやすい**<br>・やってる事が「明確」に分かる<br>・手を入れる所が「すぐ」わかる<br>・この機能は「長く」付き合える

自分勝手に書かれた「分かりにくい」フローは、チームにとって「マイナス」になります。時にそれは「負の遺産」として重くのしかかり、保守しにくくなってしまいます。


# UiPath で「読みやすい」フローを書くには

UiPath では、Studio やアクティビティの「特徴」を使うと「読みやすい」フローが書けます。
例えば、以下のような「コツ」があります。

```
# 変数・引数
- 名前にこだわる／すっと理解できる名前／誤解や疑問の生まれない名前
- 変数は英語より「日本語」のほうが、書きやすく分かりやすい
- 変数に「型名」を付けたほうが伝わるなら、付けても良いかも
- 未使用変数／引数／xaml等は「ワークフローアナライザ」でチェック／削除できる
- 変数・引数の並びは「引数に移動／変数に移動」でキレイに揃えられる
- 「隠れ変数」を防ぐために、スコープは広いほうが把握しやすい
- 引数パネルのコメントは見にくいので、Xaml先頭注釈のほうが伝わる
- リストにない型は「他のXaml」でクリックすると選択できて、作成ミス＆手間が減る

# フローチャートとシーケンス
- フローチャートとシーケンスは、場面によって使い分ける
- 処理の「大枠」はフローチャートで書いた方が良い
- 長すぎるシーケンスはフローチャートで書いた方が分かりやすい
- 短くシンプルな処理はシーケンスで書いたほうが分かりやすい
- フローチャートは基本「上から下」だが「コ」や「Ｎ」字型など横にブロック化もあり

# フローの視認性
- 同類の処理は「シーケンス」で囲むと切れ目が分かりやすい
- 処理ブロックやループの先頭で「コメント」を挟むと理解しやすい
- 「複数代入」でまとめて代入すると、コンパクトで見やすい
- 「三項演算子」を使うと、if分岐アクティビティを省ける
- 「If」アクティビティは複数の入れ子は避けて別で配置すれば。横幅を節約できる
- 「ElseIf」アクティビティを使えば、フローが横に広がらない
- if分岐で横に並べる時は「縦位置を揃える」と左右対比しやすい
- 条件分岐は見ただけで「条件・内容」が分かるように書く
- トライキャッチ内はワークフロー呼び出しで処理させる

# ログ出力
- Xamlの「最初と最後」でログを出力すると、障害時の調査に役立つ
- 「分岐」でどちらに入ったかログ出力すると、処理を追いかけやすい
- 重要処理をする時は。ログを入れておくと「証跡」になる
- ログには値だけでなく「見出し」も書いて分かりやすくする
- DataTableやDictionaryの途中デバッグ出力は積極的にする

# Xamlファイルの作り方・切り方
- xamlファイル名は「日本語」のほうが圧倒的に分かりやすい
- xamlファイル名は「先頭に分類名」を書くと、並びか揃って分かりやすい
- 役割や処理の「切れ目」でXamlを割ったほうが、保守しやすい
- Xaml「単体」で動かせるようにすると、保守しやすい

# 注釈・コメントの書き方
- コメントは「最低限」で良い。敬語や「ですます」口調は不要
- コメントアクティビティは「マークダウン形式」で書くと見やすい
- アクティビティの注釈コメントは「メモ」としても使える

# その他
-「ワークフローアナライザー」を使わないのはもったいない
- 複数のアクティビティを１つの「InvokeCode」で代替すると短くわかりやすく出来る
- 「バージョン値」は数字を意識して決めると、変遷を追いやすい
```

# UiPath で「読みにくい」フローとは（良くない例）

「読みにくい」フローを知れば、そうならないように気をつける事が出来ます。
例えば 以下のような「バッドプラクティス」があります。

```
# 変数・引数
- 変数の名前がざっくり過ぎ（中身が区別・推測できない）
- 何度も使い回される変数（何が入ってるかはお楽しみ）
- 謎の番号・謎の数値（番号や数字から推測するゲーム）
- スコープが曖昧・雑（どこで使ってるか分かりにくい）

# フローチャートとシーケンス
- よく考えずにコピペされたフロー（ネットで拾ってきた？余計な処理入ってない？）
- 処理が少ないのにフローチャート（全部読むのに何クリックも必要）
- 縦横に長いシーケンスで読みにくい（ディスプレイモニターサイズ泣かせ）
- 複数のルール（人の影）があるコード（何人で書いたのか不明）

# フローの視認性
- 謎のコメントアウト（消さない理由がある？どういう特に使う？意図は？）
- 縦横に点在する見た目が同じアクティビティ（間違い探しの強要）
- プロパティ開かないと分からない（注釈に書いても良いのに）
- 似たような処理を何箇所も書いている（修正時で何箇所も手を入れる）
- ループの終了条件がよく分からない（説明を簡単に書いてほしい）
- 待機アクティビティが多過ぎ（待機しすぎじゃない？）

# Xamlファイルの切り方
- やたら色々やるxaml（分割すると見やすくなるのに）
- 分解する位置が良くない（分割ポイントはそこじゃないのでは？）
- テストするのが大変なフロー（面倒だけど一番上から流さないとダメ？）

# ログ出力
- 処理途中のログがゼロ（エラーになっても、手がかりゼロ）
- 見出しが無く、値しか出力しないログ（なんの値か分からない）
- 無駄に多いログ（多ければ良いって訳じゃない）

# 注釈・コメントの書き方
- コメントが古い・ウソ（直すタイミングは無かった？）
- コメントが上手では無い（どういう意味？長くない？シンプルで良くない？）
- コメントが無駄に多い（多ければ良いって訳じゃない）

# その他
- 前提理解を強要するフロー（わざと難読化してる？）
- 変更への耐久性を重視しすぎた仕組み（そこまで頑張る必要あった？）
- .netの強要（どこを触って良いか分からず。説明が欲しくなる）
- バージョン値の数字が謎（例：1.0.12345ってどれだけ修正したの？）
-「ワークフローアナライザー」でチェックすると修正ポイントが山盛り
```

# もちろん「読みやすさ」には個人差がある

人によっては「これは逆に読みにくいな」と思うものもあります。「すべての人に読みやすい」というのはなかなか難しい。

また、読みやすさを優先するために、ある意味「非効率」な書き方をすることもありますが「効率重視」のシーンもあると思いますので、状態・チーム編成・場面に合わせた「読みやすさ」を選んで下さい。ここで書いていくことは「参考」であり「絶対」ではありません。


# 終わりに

以上「概要編」でした。

自分でフローを書いて習得する事 も大事ですが、他の人の話やフローを見て学ぶ事 も勉強になります。次回以降では、自分が「こう書くと読みやすくなる」と思う 具体的なポイントについて紹介します。

この記事が参考になったら、 いいね をお願いします。閲覧ありがとうございました。