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

はじめに

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

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

読みやすいフローとは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ってどれだけ修正したの？）
-「ワークフローアナライザー」でチェックすると修正ポイントが山盛り

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

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

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

終わりに

以上「概要編」でした。

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

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