ハタケ(システムエンジニア→ITコンサル)の日常とナレッジ展開ブログ

【2021年のグローバル(コミュニティ)MVP】

【2022年のグローバル(コミュニティ)MVP】

【2023年のグローバル(コミュニティ)MVP】

uipath-friends.doorkeeper.jp

これまでJapan MVPを認定されている方々は冒頭に記載しているリンク先で確認する事が可能ですが、勝手に分析した結果だと、下記のような特徴があります。

【勝手に分析したUiPath Japan MVP の特徴】

〇フォーラムやメディアで著しく活躍している方

〇Orchestratorやインフラが得意な方

〇Microsoftや.NETに精通している方

〇他の業種(IT以外)からUiPathを初めて活躍している方

〇業務ユーザとしてUiPathを利用して活躍している方

〇グローバルレベルで活躍しており共通部品や新製品の日本展開に貢献している方

〇ハッカソン(グローバル)で活躍するレベルの開発力が高い方

〇幅広い面で有益な情報を公開し、UiPath書籍まで出版している方

〇技術面だけではなくプロジェクト管理等の面でも情報展開している方

〇最新情報や開発で躓くポイントをわかり易く展開されている方

〇UiPathを社会人や仕事だけではなく、それ以外の人にも普及していきたい強いビジョンを持って行動されている方

〇UiPathの新製品(AI Center、クラウド版 Orchestrator 等)に精通している方

UiPathが課題と感じている部分を補ってくれそうな人、くれている人が認定されていると思います。UiPath Japan MVP 特許として検証用ライセンスが利用できる分、それを駆使してForumサポートやナレッジ展開、フィードバック、バグ報告する事への期待値も高いと感じています。

6.UiPath Japan MVPに興味がある方やチャレンジしたい方々へ

MVPに期待される事は大変な事が多いですが、「より多くの人に有益な情報を届けていきたい!」「製品自体やドキュメントをより良いものにするサポートをしたい!」「UiPathへのパッションは誰にも負けない!」という方々は是非次のMVPにチャレンジしてみてください! 若い人でも熟練者でも情熱や製品をよくするために活動できる人には認定のチャンスは十分あると思います。(選考プロセスは毎年7月頃に開始されるためそれまでに評価される活動を行う必要があるためご注意ください)

UiPathには『UiPath Friends』という非営利の公式ユーザコミュニティが存在しています。こちらでも技術交流や勉強会、情報共有が可能になっておりますので、MVPを目指す方はもちろん、目指さない方もこちらのコミュニティに入ると社内以外の情報を得る事もできてお勧めです。(2023年11月時点で2622名のユーザーが登録しています)

こちらのコミュニティ内でも大きな貢献をした人はMVPプログラムとは別に表彰もされております。UiPath Friendsのコミュニティ表彰式の詳細はこちら。

UiPath Friends コミュニティ表彰式 from Shumpei Watanabe

www.slideshare.net

説明は以上となります。グローバル(コミュニティ)MVPにチャレンジする人が今後更に出てきたり、UiPath Japan MVPを目指す人が増えて競争率が上がっていく事で、切磋琢磨しながらUiPathを利用している現場や会社に良い影響を与える事に繋がると良いなと思います。

f:id:syachiku_inu:20201028214646j:plain

UiPathについての情報を纏めており、各記事に下記ブログから飛ぶことができますので、UiPathについて情報を得たい方はこちらの記事もみて頂ければと思います。

https://www.nic.ad.jp/iw2011/nee4X/t3-01.pdf

2020-09-13

【RPA(UiPath)】保守で困らないようにするために必要な情報と工数の掛け方の考え方を徹底解説！

RPA(UiPath) RPA

RPA開発を行う際に、「ドキュメントをどこまで作りこんだらよいのか」や「上手く保守をしていくために必要なものが何かわからない」と困る事が多いと思います。スモールスタートをして、必要な物を徐々に追加や整理していくのが良いですが、その際にも整っている状態はどのような状態かを知っているのと知らないとでは対策の速さに差が出てきます。今回は保守に必要な情報が整っている状態がどのような状態なのかと、各情報のドキュメント化の必要性を判断するための考え方を説明していこうと思います。

<目次>

保守とは？
一般的なシステム開発とRPA開発の違いについて
保守に必要な情報について
さいごに

保守とは？

まず、この記事内で説明する保守の定義について説明します。開発を終えて本番環境にリリースをした後は運用と保守の作業があります。企業によって運用と保守の定義がばらばらなため、この記事内では下記で分類をします。

運用：システムが停止しないようにする業務。起動や停止、バックアップ、システム監視、ログ分析、パスワード変更、ライセンス更新等を行う業務です。

保守：不具合の原因究明や対応、バージョンアップ、機能拡張を行う業務です。

この記事では、上記保守の部分に対しての内容を引き続き説明していきます。

一般的なシステム開発とRPA開発の違いについて

次にRPAへの保守の考え方を身につけるために、RPA開発の特性を大規模システム開発との違いを交えて説明します。大規模なシステム開発では、開発に時間が掛かるのと今後の保守の事を考えて、開発環境と本番環境を用意して開発及び保守を行っていきます。本番で何か問題が起きた時は開発環境でバグ修正した後にテストをしてから本番環境にリリースを行います。重要又は並行開発があるシステムの場合は更に検証用の環境が用意される事もあります。しかしRPA開発は下記の特性があり、開発環境が用意されなかったり、用意できなかったりする場合があります。

<RPA開発の特性>

・小規模な開発を求められやすい

→RPA開発用の開発環境は準備しようとすれば出来るが費用対効果が出にくくなるので敬遠される事が多い。

・自動化対象システムの開発環境が存在しない事がある(クラウドのシステム等)

・RPA開発者とシステムや業務担当者が違う人で、業務担当者側は自動化対応工数の割り振りが少ない又はそもそもない

上記の理由でRPA開発現場では、全て本番環境であったり、一部が本番環境であったりした状態での開発が必要となる場合が多いです。開発環境が存在していても、元々RPA用に準備されているものではない場合があるため、どちらの環境を利用するにしても下記のような一定の制限が掛かる事が多いです。

<環境利用時の制限例>

・環境利用時は業務やシステム担当者の許可を得る必要がある

・データ更新は禁止

・データ更新が許されるのはRPA用に用意されたデータのみに限られる

RPA開発をしていく際には上記のような情報を確認してから開発をしていきますが、この情報をどこかに残しておかないと、トラブル修正や改修があった際に利用許可を得るのを忘れてしまったり、更新してはいけないデータを更新してしまったりの事故が発生します。また、保守の担当者が変わった際にこの情報が残されていないと、修正時にこれらの情報を確認する所から始まり、自動化対象業務やシステムに精通している人でなければ、どんなRPA開発プロフェッショナルでも対応するまでに時間が掛かってしまいます。いわゆる保守作業の属人化が起きます。

保守に必要な情報について

RPA開発の特性を理解頂いたうえで実際に必要なドキュメントや整理すべき内容について説明をしていきます。個人的には業務担当者がRPA開発を行う場合は、マクロやVBAの保守に必要なものとイメージ的には同じなのではないかと考えています。業務担当者以外がRPA保守をする場合は、「マクロやVBAの開発・保守を他部署の人が可能にするために必要なものは何か」を考えていけば必要なものが整理できるのではないかと思います。(RPAはシステムよりに考えられ監査対象となりやすい点で明確な違いがあるのでそこは注意です)

「マクロやVBAもただ作成されているだけでドキュメントはなく、属人化して保守できる人いないけど正常に動いているから使い続けているよ」という現場もあるかと思いますので、一から整っている状態がどんな状態なのかを説明していきます。

まず、属人化しない状態で保守が可能にするためには下記の情報が確認できる状態になっている必要があります。業務担当者がRPA開発と保守する場合と業務担当者以外がRPA開発と保守する場合で、業務への理解度が違うため必須の情報に違いがでます。業務担当者が開発と保守する場合もすべての情報が揃っている方が、属人化を未然に防ぎ担当者変更時の引継ぎを効率良く行えるため望ましいですが、工数とのトレードオフになるためこれから説明する情報を参考にして自分のチームに必要なものを選定頂ければと思います。

<保守に必要な情報一覧>

f:id:syachiku_inu:20200913230850p:plain

上記必要な情報について、確認できる状態(ドキュメント)が存在しているとどんな時に役に立つのか、逆に存在していないとどのように困る可能性があるかをそれぞれ説明していきます。作成しない場合には、困る事に記載している内容を許容する事になります。

UiPathメソドロジーはUiPath社公式が無料で公開している開発フレームワーク(ドキュメント)です。下記サイトからダウンロードする事ができます。各ドキュメントのクオリティがそれぞれ高いためお勧めです。(UiPath以外での利用は禁止されているので注意)

www.uipath.com

「運用研究会 / 日本UNIXユーザ会：運用ドキュメントのあり方と課題」という2011年に公開された運用ドキュメントの考え方や課題を整理した上で、「手軽にスピーディに継続的に保守できるドキュメント」を実現するために必要な「情報の構造化」「再利用」「ドキュメント管理」について、説明されている資料があります。少し情報が古いですが、考え方はとても参考になります。この中で「使われない情報に価値はない」と説明されていますが、誰もどのフェーズでも使わない、使いにくいものも改善すべきと思います。

(1)業務の重要度、複雑度

<存在していると役に立つ時>

・改修や障害対応があった際に、適切な開発レベルの担当者に作業を割り当てる事ができます。

<存在していないと困る事>

・重要度や複雑度の高い業務を不適切な開発レベルの担当者に割り当ててしまい、重大な事故を起こしてしまったり、想定以上に作業に時間が掛かってしまったりしてしまいます。

(2)個人情報等セキュリティに問題のあるものを取り扱っているか

<存在していると役に立つ時>

・上記(1)の記載内容に加え、担当者が作業に関わる際に「慎重に作業をしないといけない」という意識を持たせることができ、情報漏洩リスクを軽減する事ができます。

<存在していないと困る事>

・上記(1)の記載内容に加え、開発者が情報漏洩に対しての意識が足りず、情報漏洩リスクが増加します。

(3)法令・規則の影響有無

<存在していると役に立つ時>

・法令・規則(内部統制)への影響がある業務なのかどうかによって、会社内で定められた統制のルールに従って、ロボットが行う処理が正確かつ網羅的であることを説明可能なドキュメントの対応が必要となるものがあります。財務報告に関わる業務が対象とされている場合が多いです。情報が存在する事によりこれらのドキュメント対応漏れを防ぐ事が可能となります。内部統制対象業務はドキュメントに記載しなくてはいけない粒度が細かくなる事が多いです。実施者が何故こんなに細かく作らないといけないのか不満に感じる場合があるので、内部統制の対応であることを説明しておくと不満を解消させることができます。

<存在していないと困る事>

・内部統制の対応漏れが内部監査の時に発覚して急遽対応が必要になったり、監査で問題を指摘された場合は、是正の計画や報告、ガバナンス修正が必要となったりします。そもそも統制がとれていない事で、重大な問題を引き起こしてしまう可能性もあります。

(4)業務担当者と障害時の問い合わせ先

<存在していると役に立つ時>

・問題が発生時や問合せ時の対応を確実にスムーズに行う事ができます。

<存在していないと困る事>

・問題が発生時や問合せ時の対応が遅れてしまうリスクが増加します。

(5)接続システム、アプリケーションが何か

<存在していると役に立つ時>

・接続システムや、アプリケーションの問題発生時やシステム改修があった際に、ロボットへの影響特定を容易に行う事ができます。

<存在していないと困る事>

・接続システムや、アプリケーションの問題発生時やシステム改修があった際に、影響調査をワークフローの中を見て調査する等、影響調査に時間が掛かります。

(6)利用している共通部品

<存在していると役に立つ時>

・共通部品に改修があった際に、ロボットへの影響特定を容易に行う事ができます。(ログに必ず共通部品を使っている事を出力するようにして、ログから収集する方法も可能)

<存在していないと困る事>

・共通部品に改修があった際に、ロボットへの影響特定をワークフローファイルを検索して調査する等影響調査に時間が掛かります。

(7)業務の対応時限、手動切り替え可否

<存在していると役に立つ時>

・障害時にいつまでにどのロボットを復旧させなくてはいけないのか、復旧を待てない場合人の手で代替する事が可能なのかが確認でき、誤った優先順位でロボットを復旧させたり、対応が遅れてしまったりの事態を防ぐ事ができます。

<存在していないと困る事>

・障害時に対応時限を過ぎて業務に支障が出てしまうリスクが増加します。

(8)実行スケジュール(稼働日、開始、終了予定時刻)

<存在していると役に立つ時>

・どのロボがいつ動くのか把握できる事により、メンテナンスを実施しても良い時間やインフラの障害発生時の影響調査を早く行う事ができます。(各端末でいつどんなロボが動作するかは纏まったスケジュール管理表を作成すると、どのロボをどの端末で動かすのか計画や管理も行う事ができます)実行トリガーが何か分かるようにもしておきましょう。

<存在していないと困る事>

・メンテナンス可能な時間や、インフラ障害時の影響調査に時間が掛かってしまいます。またライセンスの使用状況が把握できず、不必要にライセンスを購入してしまう事も起きてしまいます。

(9)現在のステータス(開発中、稼働中、利用停止中)

<存在していると役に立つ時>

・各ロボの利用・開発状況を容易に把握する事ができます。

<存在していないと困る事>

・各ロボの状況が現在どんな状況なのか(停止中なら何故停止中なのか)が分からず、ロボの棚卸時に状況を担当者に問い合わせをしなくてはいけなくなります。

(10)自動化業務の概要や現状の課題と要件が後で追える事ができる事

<存在していると役に立つ時>

業務ヒアリング時に業務概要、業務手順、現状の問題点や目的、自動化する箇所としない箇所とその理由を整理すると思いますが、こちらの情報を整理して残しておくと後で見返した際に、何故この手順は自動化対象から外されているのか等を知る事ができ、改修時の対応内容を決めていくのに役に立ちます。

<存在していないと困る事>

初回の自動化で対応していない箇所もRPAの進化によって自動化できるようになって業務を再度見直していく必要があったときに初めからヒアリングをしたり、当時何故ここは自動化していないのかの議論をしたりする工数が発生します。また、保守担当者が変わった際に、業務概要を業務担当者に再度確認が必要となる場合もあります。

(11)自動化前後の業務フローや手順

<存在していると役に立つ時>

自動化前の業務フローや手順が既にある場合はその資料がどこにあるのか、存在しない場合既存手順を整備しておく事が理想です。手順は必ず必要となりますが、業務フローは簡易版だけでも存在していると全体を把握する速度を早くする事ができます。手順が一覧になっており繰り返し条件や条件が記載してあってもそこから流れを把握するのは時間が掛かってしまいます。フローはStudioで作成後にイメージ抽出する事もできるので、なるべく設計書には細かく記載しすぎない方が良いと思います。

<存在していないと困る事>

手順が整備されていない場合、人の手作業で作業が必要になった場合や既存業務のRPA以外の見直しが入る際に、ワークフローから手順を把握していかなければならなくなります。理想は既存の業務手順が完全な状態になっていなければ、自動化する際に既存の業務手順書も最新化しておくことが望ましいです。既存の手順書がしっかりしていれば、ロボの設計書の手順個所は全ての処理を細かく記載する必要はなく、どこからどこまでが自動化の範囲なのか、既存の運用と自動化後で変わる箇所はあるのかの情報を記載できていれば良いと思います。RPA設計書の手順の粒度をどれだけ少なくできるかで設計書に掛かる工数は大きく左右されます。

(12)想定されるエラーや例外パターンと対応内容

<存在していると役に立つ時>

・エラーにはRPA起因のエラーと業務上で発生するエラー(利用システムのチェックエラー等)の大きく2パターンが存在します。両方のパターンの時にそれぞれどのように検知をして、いつまでに誰がどのように対応を行うのかが決まっている事で誰でも正しい対応を行う事が可能となります。

<存在していないと困る事>

・対象ロボに対しての知識がある人でないと対応に時間が掛かってしまうようになります。また、誤った対応を行ってしまうリスクも増加します。

(13)扱っている入出力ファイルの一覧

<存在していると役に立つ時>

・フォルダが変更になった際の影響調査や、どの処理でどのファイルを入出力しているかの把握を早く行う事を可能とします。また、取り扱いに気を付けなくてはいけないファイルを認識でき、誤った更新や利用を防ぐ事にも繋がります。

<存在していないと困る事>

・フォルダの影響調査やファイルの使われ方をワークフローから検索して、把握しなくてはいけなくなります。入出力が複雑なロボの場合、保守担当者が変更になった際、それぞれのファイルがなんのために扱われているものか(参照or更新)、仕様を把握するために時間が掛かります。

(14)どのようなテストが実施されているか

<存在していると役に立つ時>

・本番で障害が発生した際に、テスト考慮漏れだったのか、テスト時は正常だったがどこかのタイミングで変わったのか、何故UATで気づけなかった等分析をして、再発防止策や横展開を実施する際に、テストに問題があったかの特定が可能になります。

<存在していないと困る事>

・本番で障害が発生した際に、テストに問題があったかどうかの特定が難しくなります。

(15)ロボットの資源とドキュメント、設定ファイル等の最新管理場所

<存在していると役に立つ時>

・本番で現在動いているロボット資源とドキュメントの保存先が誰でも最新だと把握できるような状態である必要があります。ライブラリ管理ツール(SVNやGit)で管理できるのが理想ですが、ファイルサーバ上で管理する場合は最新バージョンが分かり難い状態になりやすいので、注意が必要です。また、プロジェクトフォルダ以外の場所で初期設定ファイルを管理している場合や、入出力ファイルがある場合は一覧で整理しておくと良いです。管理場所のルールはロボット毎ではなく、統一したルールを作成してそこに配置させる運用もありかと思います。

<存在していないと困る事>

・どこのフォルダに最新の資源が格納されているのか、格納されている資源は最新のものなのかの確認に時間が掛かったり、誤ったバージョンの資源を修正してしまったり、デグレーションが発生してしまうリスクが増加します。

(16)ロボ実行前のあるべき端末状態(実行手順)

<存在していると役に立つ時>

・ロボが実行可能な前提条件がある場合のロボが存在しますが(Outlookが起動済等)、そのようなロボを動かす際に、準備不足でロボを実行してしまいエラーとなるケースを防ぐ事ができます。

<存在していないと困る事>

・ロボが実行可能な前提条件がある場合、準備不足によりエラーとなってしまうリスクが増加します。また属人化の原因にも繋がります。

(17)仕様面で理解が難しい個所が理解しやすいように整理されたもの

<存在していると役に立つ時>

・各画面に入力する前に値を変換していたり、途中新たに作成したVBAが存在していたり、他システムのインターフェースが複雑な場合は、作成者以外の人でも理解ができるように入出力画面項目定義書やインターフェース仕様書、VBA仕様書の作成が必要となります。作成されていると仕様の理解や本来あるべき正しい状態を確認する事ができます。

<存在していないと困る事>

・保守担当者が変わった際に仕様が難しい個所の把握に時間が掛かります。また難易度が高い場合はドキュメントがなければ高レベルの開発者ではないと扱えなくなってしまう場合もあります。

(18)テスト環境の有無及びテスト方法の注意点やテストデータ

<存在していると役に立つ時>

・トラブル修正やテスト、動作検証時に、注意しなくてはいけない事を担当者が把握可能になります。

<存在していないと困る事>

・担当者が変更されここの引継ぎを受けていない場合、この情報を業務担当者に再度確認したり、フォルダの中を漁って調べたりとかなりの調査時間が必要となります。整備されていないと結構実施者にストレスを与えます。また、注意点を知らず更新してはいけないデータを更新してしまったり、送ってはいけないメールを送信してしまったりといったリスクが増加します。本番、テスト環境の切替作業がある場合はその箇所と手順を纏めておく事が必要です。差分がないワークフローをテスト用、本番用で重複して別資源管理するのもお勧めしません。

(19)複数端末やライセンス毎のスケジュール表

<存在していると役に立つ時>

・各端末やライセンスの空き状態、UiPathバージョンやライセンス期限を容易に把握する事ができます。スケジュール表を作成しておく事で、障害時の影響調査や対応を効率的に行う事もできます。

<存在していないと困る事>

・各端末やライセンスの空き状態や利用状況が確認できず、不必要に端末やライセンスを手配してしまったり、スケジュールを重複して計画してしまったり、リリース直前で利用できる端末やライセンスが足りないといった事が発生してしまう原因となります。

(20)変更管理フローや保守内で対応できる工数の取り決め

<存在していると役に立つ時>

・リリース後に改修できる保守工数が決まっていないと、「業務担当者は本番で何か起きてから修正してもらおう」という気持ちがありUATでしっかりと確認してくれていない事が起きやすくなります。その結果、計画外の保守作業が増えて保守チームの作業が逼迫してしまう原因にも繋がります。定義や整理できる状態にしておく事で何故変更管理が発生してしまったのかの分析や保守チームの作業を適切に運営していく事が可能となります。

<存在していないと困る事>

・上記で記載の通り、本番での障害検出率が高くなる傾向があります。また何故要件定義や開発時に要件の取りこぼしが起きてしまったのか、反省されず同じミスを次の案件でも起こしてしまったり、保守チームに改修依頼が大量に来て作業が逼迫したりしてしまうリスクが増加します。

(21)ロボが稼働している端末、管理者、アカウント、ライセンスの管理

<存在していると役に立つ時>

・ロボが稼働している端末のホスト名やアカウント名、管理者やライセンス利用状況を把握しておくことで追加や更新、バージョンアップ、故障時の手配を漏れなく行う事ができます。開発機と実行機はなるべく近い機種や画面サイズで合わせたほうがロボの動きは安定するため、そこの違いによる障害切り分けにも役に立ちます。

<存在していないと困る事>

・ライセンス更新やバージョンアップの対応をどの端末に実施しなくてはいけないか、誰に連絡すればよいのかの把握を一から実施しなくてはいけなくなります。管理できていない事で突然ライセンス期限や証明書の期限が切れてロボが動作しなくなったり、手配する端末の機種を誤ってしまったりするリスクが増加します。

(22)ロボ端末、サーバーに入っているべきアプリケーションとそのバージョン、設定されているべき情報

<存在していると役に立つ時>

・新規で環境を増やす際に、アプリケーションのインストールや設定漏れを防ぐ事ができます。構築手順も作成しておくのが推奨です。また、Windows updateによって設定が初期化されてしまった際にどこの設定が戻ってしまったか早く問題個所を特定する事ができます。(インターネットオプション等の設定はレジストリという場所に設定が保存されており、それはエクスポートしておくことができるため正しい状態のものをエクスポートしておくと、影響調査の比較作業を容易に行う事が可能です)

<存在していないと困る事>

・新規で環境を増やす際に、作業漏れやミスが発生しやすくなります。また構築作業の属人化もします。また、正しい設定がどの状態なのか分からないため、一度検討したはずのどの設定が正解なのかの調査に多くの時間を消費してしまいます。

(23)Orchestrator端末、サーバーに入っているべきアプリケーションとそのバージョン、設定されているべき設定値

<存在していると役に立つ時>

・上記(22)と同様

<存在していないと困る事>

・上記(22)と同様

f:id:syachiku_inu:20200913140931j:plain

さいごに

「こんなに整備しなきゃいけないのか、、、」とげんなりしてしまった方もいらっしゃると思いますが、会社の文化や、保守する人のレベルや環境によって必要な情報やその粒度は変わってきます。一つずつ現在の現場にこれまで説明してきた情報は必要なのか試行錯誤して取り入れて頂き、最適な保守が実施できるようになればと思います。長く保守していくものに対しては整備してドキュメント化しておいた方が有効だと思います。UiPath社が提供しているメソドロジーのドキュメントに沿って作成していけば『保守に必要な情報一覧』の『UiPathメソドロジーのドキュメント内に記載する場所有無』項目が有のものは考慮できているので、無の部分をどうするかを追加検討頂ければと思います。ドキュメントは作る事自体が目的になってしまいがちですが、なんのために必要なのかを考え、不必要な情報は極力無くすようにしましょう。

この記事には記載していませんが、各ロボ毎の案件フォルダにルールがないとどこになんの情報が入っているのか分からず、同じく保守作業が大変になりますので、フォルダはルールを設けて運用する事をお勧めします。下記記事の『2.案件フォルダ』にフォルダサンプルを記載していますので、参考にして頂ければと思います。皆様の高品質な保守運用のための参考になっていれば幸いです。

また、UiPathについて他の情報の記事も下記リンク一覧に纏めてありますので、興味がある箇所を是非確認頂ければと思います。

Latest フォーラム topics - UiPath Community Forum

2020-08-16

【RPA(UiPath)】よく発生する課題や問題についての解決方法

RPA(UiPath)

この記事ではRPA(UiPath)でよく発生する課題や問題について、どのように解決をしていけば良いかと解決する能力とその伸ばし方とよくある問題と解決策への対応方法を紹介していきます。よくある問題と解決策は日々随時更新していく予定です。

【目次】

分からない事を調べる時のフローについて
分からない事を解決する力(開発力)について
よくある問題と解決策
最後に

分からない事を調べる時のフローについて

はじめに、UiPathで使い方が不明等分からない事が発生した際にどのように解決を行っていくかについての概要を説明していきます。分からない事が発生した際の対応フローは下記イメージ図の通りとなります。対応フローの各段階ごとに実施する内容を説明していきます。

【分からない事を調べる時の対応フローイメージ図】

f:id:syachiku_inu:20200816230852p:plain

分からない事はある程度の種別に分ける事ができます。質問する際に相手に、キーワード情報として渡すと、スムーズに解決する事ができるので、分からない事があった場合は、どんなカテゴリのものか事前に考える癖を付けましょう。続いて各段階での作業内容の詳細を説明していきます。

<第一段階-個人解決>

こちらは勉強や他の仕事の時にもやられていると思いますが、分からない事はまず自分で調べて解決できないか対応をします。インターネットで闇雲に検索するのも良いですが、下記の順番で解決できないかを探していくのが、確実な情報且つほしい情報まで早く辿りつけます。

1.社内ナレッジ資料

過去社内で同じように困っていて、解決した結果が社内ナレッジに蓄積されていれば、まずここに情報がないかを探します。現時点でない場合、ナレッジを蓄積するメモレベルの一覧でも構わないので、作成する事をお勧めします。

2.UiPath 公式ガイド

UiPathは各製品別にガイドを公表しています。公式が出している情報ですので、情報の質が高く信頼性があるものとなります。製品仕様や基本操作についての疑問は必ずこちらを確認しましょう。

UiPathドキュメンテーションポータル

環境構築関連(バージョンアップやAWS、Azure)はナレッジベースという所に情報が別で公表されているので、上記で見つからない場合はここにもほしい情報がないか、探してみてください。

ナレッジベース | UiPath

導入事例系は下記ニュースルームを探してください。

ニュースルームメディア向け情報 | UiPath

3.UiPath フォーラム

UiPath コミュニティフォーラムというユーザ間で情報交換するサイトがUiPathには存在します。ここに過去分の質問が2000件近く投稿されているので、フォーラム内でキーワード検索して、解決策がないか探します。ここにいきなり質問投稿しても良いですが、過去同じ質問があり、解決されているものがないかは調べてから質問しましょう。

4.書籍、インターネット(インターネット記事、他技術や製品のシステムガイド)

次に手持ちの書籍やインターネットで検索をして解決できないか対応します。インターネットは調べ過ぎてもキリがないため、数ぺージ分の情報をみても情報がなさそうであれば、諦めた方が良いです。新技術や新製品等新しい内容の疑問は情報が少なく、検索しても解決できない事が多いです。

エラーメッセージの見方や考え方について、Qiitaにとてもわかり易く纏められている記事がありますので、エラーメッセージからの調査方法よくわからない方はこちらの参照することをお勧めです。

Latest フォーラム topics - UiPath Community Forum

<第二段階-社内解決>

第一段階で解決しなかった場合は、次に社内の詳しい人にコミュニケーションツールやチャット、メール等で質問するフローに移ります。あきらかに社内で誰も経験していない内容の疑問は聞いても解決しない可能性が高いので、飛ばしても良いと思います。ただ、把握しておらず自分の思い込みで聞いても答えてくれないだろうという気持ちで第二段階目を飛ばすのは良くありません。

■補足(上手な質問の仕方)

質問をする際は、相手が理解し易いように分かり易いように質問する事が大事です。自分の知りたい事を断片的な個所だけ質問しても相手は情報が少なく、答えられない場合があります。

<タイトル>

分かり易いものを記載する事。質問なのか相談なのか分かるように書く。

例：【質問】クリックアクティビティの使い方について

<質問したい製品名や技術名>

どの製品に対しての質問なのかを分かるように記載する。利用バージョン情報もあると良いです。

<質問、相談したい内容>

内容を簡潔に記載していきます。エラーメッセージが出力されている場合は、メッセージコードが分かるように画面キャプチャか文章を記載する事。何故その対応にこだわっているか経緯や背景の情報もあると、違う対策案がある場合は提案しやすくなります。

<これまで試した事や自身の考察>

解決するまでに自分がやったことを論理的に記載する。

<第三段階-外部解決>

第二段階でも解決できなかった場合は、外部の力を借りて解決を行います。問い合わせ先の選択肢は下記の5通り存在します。UiPath社や他社製品のカスタマーサポートへの質問はその製品に対しての質問でしか、回答は貰えないので質問先が正しいかは質問前に確認しましょう。

1.UiPath コミュニティフォーラム

第一段階でも登場してきましたが、こちらはUiPath Connectのユーザ登録(無料)をすれば、誰でも質問を行う事ができます。製品版を購入していなくても質問が可能です。但し他ユーザからの回答となるので、情報の信頼性は少し低いものとなります。また、全体に質問内容が公表されるため、社内情報や個人情報漏洩しないように質問するように気を付けなくてはいけません。開発方法が分からない系のちょっとした相談はここにすると良いです。なんでも答えくれる方々がいるようですので、余り気負わず投稿してください。

2.UiPath カスタマーサポート

UiPath社に直接問い合わせを行えるものです。製品版を購入していない場合も導入目的であれば、製品や事例/実績、ライセンス相談が可能です。製品版を購入している場合は、開発時の問題をカスタマーサポートに問い合わせする事ができます。(質問の際にライセンスキーの入力が必須で必要となるため、製品版を購入していなければ問い合わせする事はできません)

情報の信頼性は高く、最新製品の事も確認する事が可能です。注意点としては、UiPath製品に関わる内容でしか回答は得られませんので、「Excelの関数どうしたらよいか」や「AWSの仕組みを教えて」等他製品の疑問を解決する事はできません。質問する際に、UiPath製品に対する質問なのか確認してから質問は送信しましょう。サイトのフォームで質問を送信して、その後はメールでやり取りをしていく形式となっています。

下記のような条件の時に利用する事が多いです。必要に応じて優先度を設定しましょう。優先度の設定の詳細は問い合わせページの優先度の箇所に説明があります。

○公式の見解がほしい
○ネットで探しても解決策が見つからない
○自分達で解決できそうもない
○本番影響が大きく早急／確実に対応したい

カスタマーサポート | UiPath

3.その他製品カスタマーサポート

OfficeやAcrobat Reader、.NET等他製品の事で質問を行いたい場合は製品ごとのカスタマーサポートセンターに質問を行ってください。UiPath コミュニティフォーラムのようなものが存在している製品であれば、そちらへの質問も検討すると良いです。

4.有料外部サービス

疑問の解決を代行してくれる外部サービスがいくつか存在しております。どこ宛に質問すれば良いか切り分けをできる人材がいない場合や、解決する情報を探す時間が惜しい企業はこちらのサービスを利用するのも良いと思います。従業員が1~3時間分からない事を調べ続けるより、外部に疑問解決作業を委託する方が本来の業務が止まらない場合や、人件費を安く収める事が可能となるからです。ただ過去誰かが行った質問をもう一度他の誰かがしてしまうのは費用がもったいないので、ナレッジ化しておく事をお勧めします。(チケット制ではなく無限に質問可能な契約であり、契約し続けるのであれば問題なし)

5.Twitter等のSNS

稀にTwitterでツイートすると情報解決の情報を教えてくれる方々がいます。本来であれば有料外部サービス並みの回答も貰う事ができる時がありますが、回答貰える確率は低いので、あまりお勧めではありません。社外に流出してはいけない情報を投稿しないように注意も必要です。

f:id:syachiku_inu:20200816213216j:plain

分からない事を解決する力(開発力)について

分からない事を解決していくにあたって、すぐ答えに辿り着く人と辿り着けない人がいます。すぐ答えに辿り着ける人とそうでない人の違いについては、知識量と情報収集力の違いだと思われます。どんな知識が必要なのか、理解し易くするためにUiPath開発に必要な知識体系を下記にロジックツリーとして表現してみました。RPAは関わる技術が広く、全ての情報を記載する事はできないので、イメージを掴むためのもので第3階層以降は代表的なもののみを記載しています。また、開発に絞っており、管理者やソリューションアーキテクトの知識は下記ロジックツリーには含まれておりません。

【ロジックツリー最新化中、、、】

UiPathは開発をする事自体は簡単に行う事ができますが、上手く開発ができない場合や連携システムによっては各技術知識や経験が必要となります。全て頭の中に入っている人はほぼいないと思いますが、解決に辿り着ける人は下記が出来るようになっています。全ての専門知識や技術を保有していなくても、IT基礎知識を保有しており、情報を利用する能力が高い人であれば、その場その場で調べながら課題や問題を解決していく事が可能となります。

<解決に辿り着ける及び辿り着くのが早い人が出来きている事>

1.分からない事がどこの分野や製品の事なのか特定できる

2.経験や知識からどうあるべきかを想像する事ができる

3.各情報がどこにどんな情報があるか大体把握している

4.インターネット検索で使用する検索キーワードが的確、情報を絞れる

5.各製品の問い合わせ先、問い合わせ方法を知っている

どうやったら上記に記載してある事を身につける事が出来るのかを引き続き解説していきます。

<1.分からない事がどこの分野や製品の事なのか特定できる>

各製品の特長や概要を抑えておく事で判別する事ができます。各製品間の技術の概要も知っていなければ、特定できない場合があるので、ネットワークやOS、Web等の幅広い知識も必要となります。「基本情報技術者試験の知識＋各製品の知識」のようなイメージです。学習しながら実際に知識を使っていく事で身につけていく事ができます。この能力があれば質問先が分かるため、最終的には答えに辿り着く事ができます。基礎があれば、新しい技術や情報を理解する速度も速く、応用が利くため非常に重要なスキルです。

<2.経験や知識からどうあるべきかを想像する事ができる>

今までのシステム開発経験から完成されているシステムがどのような状態であるべきかを把握しているため、あるべき姿とのギャップがあった場合に誤りに気付く事ができます。こちらは色々な開発をしたり完成しているシステムに触れたりして身につけていくしかないと思います。各現場のシステム構成や開発手法、コードや設定値を把握していくと力が付いていきます。技術や言語によってはデザインパターンというベストな構成や作り方が纏められているものがあるので、こちらが存在しているものは知識として抑えておいた方が良いです。

<3.各情報がどこにどんな情報があるか大体知っている>

分からない事を自分で調べて解決している人は有益な情報が集まっている場所を知っていたり、更新情報をチェックして現在どこになにがあるかを大体把握していたりしています。これは普段から色々な情報に触れている必要がありますが、私のように情報を集約している人の情報を追う事で、少し手間を省く事ができます。情報を纏めている人を見つけてその人を監視していくのも技の一つです(twitterお勧め)。社内/社外への問い合わせ先を知っている事も重要です。

<4.インターネットで使用する検索キーワードが的確、情報を絞れる>

闇雲なキーワードで検索をしてもほしい情報に辿り着かない事があります。例えば大量のエラーメッセージが出力されている場合、検索すべきエラーコードを見つけて検索ができる人とまったく関係のない文言で検索していく人のように違いがでてきます。この能力はログが関わっている場合はログの出力内容を理解している、またはログに出力されている内容自体を検索できたり、その他の事であれば問題個所を理解し「製品や技術名＋問題」で検索できたりする事です。1つ目のできる事の能力に似ていますが、製品名や技術名が分からなかったり、対象が誤っていたりで検索していくと、見当違いのものが引っ掛かってきてしまいます。また、ニュース検索、画像検索、Twitter検索したり、ほしい情報のみに絞ったり、検索結果を変えてほしい情報にたどり着く力も重要です。

<5.各製品の問い合わせ先、問い合わせ方法を知っている>

技術的な事で、無料の相談フォームを利用しても解決に至らない場合や正式な回答がほしい時があります。その時に該当の製品についての問題であれば、製品のサポートに問い合わせを行う事で、プロフェッショナルの知見と製品提供者として正式回答を得られて解決に至るケースが多くあります。会社内に情報システム部門がある場合は、情報システム部門に一度問い合わせはした方が良いです。既に窓口担当が決まっており、情報システム部門の人を通じてやり取りした方が、より会社として間違いのない判断を行う事ができるケースがあります。(情報システム部門内だけで解決される可能性もある)

情報システム部門の人が直接やり取りしてくださいと判断したら直接やり取りしましょう。重要な課題がそれでも解決できない際は、有料のサポートによって、解決できそうなのであれば有料のサポート契約を結ぶ事も解決手段の一つです。製品の公式サイトに大体問い合わせ方法が記載されています。

f:id:syachiku_inu:20200816214418j:plain

よくある問題と解決策

ここからはUiPathでよく質問されている(FAQ)について、カテゴリ別に記載していきます。

【Studio】

<アクティビティ編>

1.開発時に動作していたのに、動かなくなった。安定しない。

こちらはセレクターが開発時から変わってしまっていたり、開発機と本番機の環境差異(インターネットオプション設定や権限等)が違っていたり、処理時間が伸びていたり様々な原因があります。UiPath公式が安定したワークフロー開発を行えるためのTIPS集を出しているので、まずこちらを見て対応していないものがあるか確認しましょう。Excelの表示されているツールバーの違いでidx番号が違ってきたりするので、他にも表示されそうな項目名がセレクターになる場合、常に注意して開発する必要があります。

ワークフロー開発実践テクニックレシピ～第1弾～ワークフロー動作安定化

環境変化に強いアクティビティを作成するコツが下記フォーラムの回答で箇条書きで纏められているので、こちらも良いです。

Is there a best practice for creating selectors so they continue to work when a website is updated - Studio - UiPath Community Forum

2.クリックが画面描写よりも早く動作してしまう、正常に動作しない

クリックアクティビィについて、徹底解説されている情報がナレッジベースに存在しているため、こちらを参照して対応を行うと良いです。

クリックアクティビティー徹底解説

<開発手法>

1.Internet Explorerの通知バーの処理が安定しない。

下記ナレッジベースに対応方法が纏められているので、こちらを参照して対応可能です。

Windows 標準 UI の自動化のヒント

UiPath Go!にInternet Explorerの通知バー部品があるので、作り方の参考にこちらも参照してみると良いです。

Save as File Download for Internet Explorer - RPA コンポーネント | UiPath Connect

2.PDFの値が上手く取得できない

下記に公式からのPDFファイルに対する対処方法が記載されています。

PDFファイルからのデータ抽出

3.操作途中(右クリック等)のときにしか表示されない項目を操作したい!

録画機能のF2(一時停止)を扱えば、操作対象をその間に表示してセレクターの取得が可能です。

【できるUiPath】実際に操作するだけでロボットが動き出す！ UiPathのレコーディング機能とは | できるネット

<ライセンスのアクティベート、ディアクティベート>

1.ライセンスアクティベートを手順通り(コマンドライン)実施したが、上手くいかない。

2018.4.7、2019.4.5、2019LTS以降のバージョンはコマンド(exe)が「LicenseTool.exe」に変更されています。バージョンを覚えておくのは大変なので「LicenseTool.exe」が存在すればそちらで実施、ない場合は「regutil.exe」実施と覚えておくのが良いです。コマンドが正しくても認証できない場合、UiPathのライセンスサーバにプロキシの関係でアクセスできない場合が多いです。コマンドがあっている場合はオフラインアクティベーションで実施できるか試してみると良いです。コマンドラインのエラー内容を理解する事ができれば早く問題特定できますので、コマンドラインには慣れておいた方が良いです。

契約更新・ライセンス情報更新後に UiPath Platform で実行する手順

【StudioX】

工事中

【Robot】

工事中

【Orchestrator】

1.Orchestratorが良くわからない、、、

下記ナレッジベースにスターターガイドが公表されているので確認頂き、無料で使えるコミュニティクラウド上で操作すると理解を深める事ができます。

UiPath Orchestrator スターターガイド[第1版]

2.Orchestratorの構築手順が知りたい!

下記ナレッジベースに構築手順が纏められています。環境構築系は自分が対応したいバージョンのものが公式から出されていないか確認してください。

<通常版>

Orchestrator導入ステップバイステップガイド [2020.4 対応版]

<Azure>

Azure環境 UiPath Orchestrator 2019.10 LTS ステップバイステップ構築手順書

Stack-UiPath on Azure - IaaS

<AWS>

Stack-UiPath on AWS - Full Plan (2019LTS対応)

f:id:syachiku_inu:20200816214555j:plain

最後に

よくある問題と解決策は今後UiPath公式が公表する情報の状況を見つつ、UiPath コミュティフォーラムを分析して、質問が多いものから随時更新していく予定です。どのような質問が多いのか、解決にまで至っていない質問数と解決した質問数等分析もする予定なので、分析完了したら別の記事に纏めようと思います。

分からない事をまずは自分で調べるというのは、一般的なスキルとして重要なものです。自分で調べて覚えた事は記憶に残りやすく理解も深まりそのまま自分の力となります。しかし、時間を掛け過ぎていては自分の時間(会社員の場合は工数)がもったいないので、詳しい人に質問して解決したり、複数人で討論して解決策を摸索したり周りを巻き込んでいく事も大事な事です。

普段からどこになんの情報が存在しているか把握しておく事で、開発力は上がっていくと思います。この記事が皆さまの問題解決や調べる力の向上の役にたてば幸いです。

UiPathに関しての他の情報も纏めているので、そちらも気になる方は下記リンク集から飛んで行っていただければと思います。

2020-08-15

【RPA(UiPath)】のワークフローテンプレート(フレームワーク)まとめ

RPA(UiPath)

この記事ではUiPathのワークフローテンプレート(フレームワーク)の概要と導入や利用方法について説明します。自社や個人用のワークフローテンプレートを検討されている方や開発者の方に見て頂ければと思います。

f:id:syachiku_inu:20200812161022j:plain

【目次】

はじめに
UiPathのワークフローテンプレート(フレームワーク)
UiPathワークフローテンプレートの導入方法
UiPathワークフローテンプレートの使い方
UiPathワークフローテンプレートの運用
さいごに

はじめに

UiPathのワークフローテンプレートについて説明する前に、一般的なフレームワークとその必要性について説明します。まず開発におけるフレームワークとは開発する際に頻繁に必要とされる汎用的な機能を纏めて提供し、作成時の土台として扱われるもの(枠組みや骨組み)の事です。頻繁に扱われるものをテンプレート(フレームワーク)化しておく事によって、下記の効果を得る事ができます。

<フレームワークの効果>

〇先人の知恵や反省/改善点が盛り込まれており開発生産性があがる

〇誰でも一定の品質で開発ができるようになる。(ベストプラクティスや規約を知らなくても真似て作るとベストプラクティスに近いレベルで作成ができている)

〇ある程度決まった形式で開発がされるため、可読性や保守性が高まる

〇該当部分の開発やテストをする工数が削減される

フレームワークがなければ、開発者は各々で好きなように開発を行い、エラーハンドリングが上手くできていなかったり、開発者毎に作りが違い、レビューや処理内容の理解に時間が掛かってしまったり、同じ処理を毎度開発及びテストをして無駄な工数を掛けてしまったりしてしまいます。

フレームワークはあれば便利なものですが、皆が共通的に扱うものであるため、最適化(無駄な部分がない)がされており、品質が担保されている(バグがない)且つ、開発規約通りに作られている状態である必要があり、初めから良いフレームワークを独自に作成するのは難しいです。しかし、UiPathではこのフレームワークに関して、公式とマーケットプレイスでいくつかを無料で提供されているため、それを利用すれば、導入を容易に行う事ができます。

f:id:syachiku_inu:20200814143216j:plain

UiPathのワークフローテンプレート(フレームワーク)

ご存じの方も多いと思いますが、UiPathのワークフローテンプレートはStudioの標準機能の一部として使える状態になっています。該当のテンプレートは下記6つです。公式サイトに情報がありますが、いまいちどのようなテンプレートなのか分かり難いものがありますので、別途検証してそれぞれの解説記事を作成して説明予定です。(今回は概要の説明のみ記載)

<Studioに標準で搭載されているワークフローテンプレート>

1.オーケストレーションプロセス

人間の介入及び実行時間の長いトランザクションを使用するプロセス向けテンプレート

2.バックグラウンドプロセス

バックグラウンド及び並行で動かせなくなる可能性のあるアクティビティに利用制限が掛かっているテンプレート

3.モバイルテストプロジェクト

モバイルアプリの自動化テストケース用のテンプレート

4.Robotic Enterprise Framework

大規模開発向けのテンプレート(ReFramework)

5.トリガーベースの有人の自動化

イベントをトリガーにして動作するプロセス向けテンプレート

6.トランザクションプロセス

基本的なオートメーションプロセス用に最適化されたフローチャートに基くプロジェクトテンプレート

【Studioのテンプレート選択画面】

f:id:syachiku_inu:20200814152934p:plain

以上がStudioの標準に備わっているテンプレートですが、こちらをベースにして扱うのではなく、マーケットプレイス(旧UiPath Go!)の方から作成した方が日本語化もされており、ガイドも充実しているのでお勧めです。マーケットプレイスにどのようなワークフローテンプレートが存在していており、どれを選べばよいのかの情報は「しおちゃんさん(@Jun96427231)」のブログで分かり易く纏められているので、こちらを参照頂ければと思います。

私のブログではテンプレートを運用させていくための処理手順について説明をしていきます。

f:id:syachiku_inu:20200814160519j:plain

UiPathワークフローテンプレートの導入方法

ワークフローテンプレートの導入は下記のSTEPで導入をしていきます。

<ワークフローテンプレートの導入STEP>

STEP1：基にするワークフローテンプレートを選定する

STEP2：STEP1のワークフローテンプレートに対してカスタマイズを施す

STEP3：ワークフローテンプレートの管理方法を決める

STEP4：ワークフローテンプレートのルールを決めてガイドを作成する

STEP5：ワークフローテンプレートとガイドを展開して運用開始させる

それぞれのSTEPで実施する作業内容の詳細は下記の通りです。ワークフローテンプレート構築はRPA管理が部署毎に完全に分断されない限り、社内全体の運用として動いた方が良いです。部署異動したらロボの作りが別ものになっていたらフレームワークの効果が薄れます。初めから全社的な動きが難しい場合は、1部署から運用を初めて徐々に全社に適用していくやり方もあります。

<STEP1：基にするワークフローテンプレートを選定する>

基となるワークフローテンプレートを選んだら、自社/個人用にカスタマイズを行っていきます。ReFrameworkは開発者レベルが高い人以外の人が理解して扱うようになるにはそれなりの教育が必要となるため、開発者レベルが低い人も扱えるテンプレートをまず用意してから、他のバリエーションのテンプレートを徐々に整えていくのが良いと思います。個人的にお勧めのやり方が「日本語版Attended Framework」を初めのテンプレートとして整備して、その後日本語版Attended Frameworkと日本語版ReFrameworkを必要なバリエーション分徐々に増やしていくやり方です。

Attended Frameworkの繰り返しステータス監視対応版や様々なトリガーに対応した版等が増やしていくテンプレートイメージとなります。これらのテンプレートは実際の案件で作成された成果物からテンプレート化して作り出していくやり方も良いと思います。ReFrameworkはマーケットプレイスに様々なトリガー(ExcelやMail)に対応した派生形テンプレートが既に掲載されているのでSTEP2のカスタマイズを同じように対応すれば、派生形テンプレート作成も短い時間で作成する事が可能になっています。

<STEP2：STEP1のワークフローテンプレートに対してカスタマイズを施す>

ワークフローテンプレートに修正が必要な部分がないか確認します。例えば自社の人達が扱う際に問題なく扱う事ができるように初期設定ファイルやテンプレートに注釈や補足を追加したり、初期設定ファイルの定数シートに待機時間やタイムアウト時間の情報を追加したり、ロギングに追加が必要な情報(フレームワークバージョン、本番/開発フラグ等)を追加したりします。そのままでも、テンプレートとしては十分に扱えるので、運用開始前に必要なカスタマイズ内容が思い浮ばない場合、実際に使ってみてからバージョンアップさせる対応でも良いと思います。但し、Main.xamlは社内の命名規則チェックに極力引っかからないように修正しておいた方が良いです。また、Attended FrameworkやReFrameworkのプロジェクトフォルダ内のframeworkフォルダに入っているものは、命名規則対応はせず、開発時のコードチェックの対象からもファイルごと外して良いと思います。変数等修正すると無影響確認をしないといけなくなるのと、バージョンアップがあった際に取り込むに時間が掛かるようになるためです。Main.xamlはコードチェックから除外する事は不可能であり、必ず開発者が修正するファイルのため、やむを得ず対応するものです。

【ReFrameworkのfremeworkフォルダ内】

f:id:syachiku_inu:20200814234924p:plain

また、マーケットプレイスからダウンロードしてきた、テンプレートのプロジェクトフォルダ内には「Documentation」というフォルダがあります。この中に利用ガイドが入っていますが、ガイドはどこか別の場所で管理するようにして、このフォルダ内からは消した方が良いです。皆が使うプロジェクト全てにこのガイドが入っていると容量を圧迫させてしまいます。

<STEP3：ワークフローテンプレートの管理方法を決める>

ワークフローテンプレート資源の管理場所や修正ルールを決めます。バージョン管理ツール(GitやSVN)やファイルサーバー上等、原本を保存する場所と各所への展開、連携や利用方法を決めます。知らずに勝手に修正されたり、修正後の連携が漏れてしまったりしないような管理にしないといけないのが注意点です。

<STEP4：ワークフローテンプレートのルールを決めてガイドを作成する>

ワークフローテンプレートを扱っていくには、下記のようなルールを決める必要があります。

〇ワークフローテンプレートは必ず使わなければいけないのか

〇使わない場合に守らないといけない開発ルールはあるか

〇複数テンプレート存在する場合、どのように使い分ければよいのか

基本的に原則利用させるようにした方が良いと思います。自由にすると利用はされず、効果が薄れる可能性が高いです。今までの開発スタイルを変えるのを嫌がる人は多いですが必要性を伝えて納得して貰う事も重要です。また、私はテンプレートの中で絶対に守らないといけない場所はロギングの個所が該当すると思っています。後々分析を行う際や、障害対応を行う際に、ロギングが規則通りに作成されていないと、保守と運用に支障をきたすためです。このような取り決めが決まったら、開発ガイドにルールの追加や利用手順に取り込みを行います。

<STEP5：ワークフローテンプレートとガイドを展開する>

上記STEP4まで準備が整った段階で、各所にテンプレートを展開して運用を開始していきます。改善要望やこんなテンプレートもほしいといったような意見を送ってもらう運用構築や管理チームの体制構築もこの段階からできれば理想です。また、必ず守ってほしい規則がある場合はコードレビューチェックリストやworkflow Inspecttor、Analyzerのチェック機能でチェックできるようにしておくと尚良いです。

f:id:syachiku_inu:20200814235324j:plain

UiPathワークフローテンプレートの使い方

自社/個人用に作成したワークフローテンプレートは下記2つの方法で利用する事ができます。2に関してはStudioにテンプレートとして保存(ローカル上)して、Studio上からすぐに呼び出す事ができます。

1.ファイルサーバーやバージョン管理ツールから都度テンプレートを取得して開発

2.一度上記1から取得したテンプレートをStudioに登録して、そこから開発。カスタムテンプレートと呼ばれているものです。登録方法についてはUiPath公式ガイドをご参照ください。

プロジェクトテンプレート

UiPathワークフローテンプレートの運用

他の共通部品(カスタムアクティビティやスニペット)と同様ですが、現在社内で扱う事が可能なテンプレートの種類やバージョン情報は、関係者が把握できるような運用を構築する必要があります。一覧を作成しておき、関係者が参照可能なところに一覧を配置して、バージョンアップ等なにかあれば連絡で知らせる事ができる運用を考えて、実施していけば問題なく運用できると思います。RPA推進チームやCoE(センター・オブ・エクセレンス)の体制を組んで、全体的に管理できればベストです。

f:id:syachiku_inu:20200815004604j:plain

さいごに

優れた開発テンプレートは開発面や保守面において非常に有効なものとなります。テンプレートを扱っていないで開発されたワークフローはもう見たくないというな気持ちになるくらい違いが出てきます。RPA推進チームがテンプレートを整備してくれない状態であれば、チームや個人で作って運用開始して効果を伝えて社内に広げていく事もできますし、最悪自分だけで扱うだけでも効果はあります。まだワークフローテンプレートを使って開発していない方はまず、日本語版Attended Frameworkを使ってみる事をお勧めします。

共通部品を上手く扱い、効率的に開発をしていく事でUiPathの力は更にあがっていきます。「開発規約×ワークフローテンプレート×共通部品×コードチェック」を充実させていく事で、新たに開発しなくてはならない範囲を徐々に減らしていく事ができます。ロボを作って共通化していけばいくほど、開発時間が短くなり高い品質の開発が可能になっていくのです。この記事が皆様のワークフローテンプレート導入の手助けやきっかけとなる情報となっていれば幸いです。

その他のUiPath情報も記事で纏めています。下記にリンク集があるので他の情報も気になる方はこちらのリンク集記事から飛んでいって頂ければと思います。

https://cio.go.jp/sites/default/files/uploads/documents/RPA-dounyu-jissen-guide_20210330.pdf

2020-08-12

【RPA(UiPath)】案件の進め方ナレッジ

RPA(UiPath)

この記事ではRPA(UiPath)案件の実践的な進め方や注意点について、説明していきます。これからUiPathを検証していこうとされている方や検証を終えて本格的に導入しようとしている方、導入済みだけど上手く運営できていないと感じている方、開発だけではなく計画にも携わっていきたいという方に読んで頂ければと思います。

f:id:syachiku_inu:20200811173752j:plain

【目次】

はじめに
案件推進/構築の考え方
案件推進時の注意点
まとめ

はじめに

RPA(UiPath)の開発をはじめていく際にどのように開発していくのか(アジャイル型?ウォーターフォール型?)や、どのようなドキュメントや管理が必要なのか等、分からないと思います。これらの問題を解決するためにUiPathでは高品質な開発や管理ができるように無料でドキュメントを公開しています。提供されている代表的なドキュメントは2020年8月11日現在では下記です。

0.政府CIOポータル「RPA導入実践ガイドブック」
各府省が業務改革の手段として RPA を導入する際の基本的な方針及び考慮事項を示すために作成、公表されているものです。RPAの特徴や注意点、進め方等が纏めてられている資料です。推進していく上で参考になります。

1.RPAガバナンス構築のためのガイドラインおよびRPAガバナンスハンドブック

どのように自社にRPAを取り入れていくか、セキュリティ面やその他のリスクはどのようなものがあるのかの考え方を、UiPath以外のRPAでも扱えるような汎用的な内容で説明がされています。戦略を考える人や全体コントロール(ガバナンス構築)する人、監査に関わる人は必読のものです。

ホワイトペーパー：RPAガバナンスガイドブック | UiPath株式会社

2.UiPathメソドロジー

戦略立案からPoC(導入検証)、スモールスタート、強化、制度化のフェーズに進んでいくにあたって必要な作業フロー例や案件で使用するサンプルドキュメント一式が格納されているものとなっております。利用規約上UiPath開発以外での利用を禁止されていますが、それぞれのドキュメントのクオリティが非常に高く、ルールやドキュメント作成を行っていくにあたり非常に重要なドキュメントです。ボリュームが多いため全てに目を通すのは大変ですが、パワーポイント(説明資料)だけでも読んでまずは内容を把握しておく事をお勧めします。このメソドロジーの登場で案件推進のし易さは各段にあがったと思います。逆に他のシステム開発にも流用できる部分は多いです。

UiPathメソドロジー | UiPath

3.UiPathコーディング規約とワークフロー品質評価キット

コーディング規約と品質チェックを自動で行ってくれるツールセットです。社内用に規約やチェック内容は変更して扱っていきます。命名規則が例しか記載されていないため命名規則を定義する際のドキュメントは別で作成する必要があります。

コーディング規約とワークフロー評価キットを無料公開 ―RPAユーザーの高品質な開発を支援 | UiPath

4.UiPathデリバリーアセスメント

UiPath導入プロジェクトにおける考慮漏れや準備不足を未然に防ぎ、高品質な開発を実現できるよう支援するものです。上手くいっていない案件にコンサルが入って改善点の洗い出しや改善提案を行う現場がありますが、このうちの改善点の洗い出しをセルフチェックできるようにチェックリストとワークフロー(作ったプログラム)チェックツールを提供する事で可能とさせるものです。あらかじめPMが内容を抑えておく事で問題になる前に対応を行う事もできます。

UiPathデリバリーアセスメント | UiPath

5.ワークフロー開発実践テクニックレシピ～第1弾～ワークフロー動作安定化

RPAは開発時に扱いに気を付けなくてはいけないお作法なようなものが存在します。実際に経験して社内ナレッジ化する事で、問題を回避していくしかなかったですが、テクニック集をUiPath公式が公表をはじめました。ワークフロー開発を行う人やレビューをする人は必読のものです。第2弾以降も今後登場してくると思われます。

ワークフロー開発実践テクニックレシピ～第1弾～ワークフロー動作安定化 | UiPath

7.UiPath 逆引きTips集&トラブルシューティング集

UiPathのStudio、StudioX開発時に役に立つTIPS集＆トラブルシューティング集とサンプルワークフローが格納されています。サンプルワークフローは76機能分入っています。開発時に役立つ事間違いないので、開発者全員が扱えるようにした方が良いです。この資料をベースに修正や追記したり、TIPSを更に追加して育てていくと良いです。

UiPath 逆引きTips集 & トラブルシューティング集 | UiPath

8.UiPath Orchestrator スターターガイド

UiPathの管理サーバーアプリケーション(Orchestrator)についてのスターターガイドです。Orchestratorでどのような事ができるかを把握する事ができます。UiPathではクラウド版のOrchestratorのサービス展開も開始したため、スモールスタートがよりし易くなっています。今までは費用や保守面が不安でOrchestratorを扱っていなかった企業の利用も増えていくと思われます。

UiPath Orchestrator スターターガイド | UiPath

9.UiPath製品バージョンアップガイド

UiPath製品のバージョンアップについてのガイドです。StudioとRobot、Orchestratorについてのバージョンアップ計画方法や手順について説明されています。作業自体は単純ですが、バージョンアップ後にまれに正常に動作しない処理が存在する可能性があるため注意が必要です。

UiPath製品バージョンアップガイド

10.インフラ系のガイド(ミドルウェア、AWS、Azure導入)

インフラ系のガイドが公式のナレッジベースにいくつか掲載されています。

自社内にOrchestrator環境を構築予定やされている方に必要なものとなります。

ミドルウェアのガイドリンクのみ参考で貼っておきます。

Orchestrator 管理者のためのミドルウェア（IIS, SQL Server）運用設定ガイド ver 1.1

f:id:syachiku_inu:20200812094937j:plain

案件推進/構築の考え方

上記「はじめに」で記載している内容を見ればわかるかと思いますが、UiPathでは案件の進め方や保守、運用に至るまでの情報提供がされているため基本的な考え方としては上記のドキュメントを使って案件を進めていく事が、最適解だと思います。量が多いため各役割別に確認した方がよいドキュメントをマトリクスに纏めました

f:id:syachiku_inu:20200917142509p:plain

<UiPath製品を導入するまでを提案・推進する>

BC･･･ビジネスコンサルタント(セールス)

TC･･･テクニカルコンサルタント(プリセールス)

<RPA開発/保守/運用>

BA･･･ビジネスアナリスト

SA･･･ソリューションアーキテクト

IE･･･インフラエンジニア

ただドキュメントは汎用的に扱える記載になっているので、利用する環境(会社)に合わせてカスタマイズをしていかなければなりません。また、実際に使っていかないと気づけない部分があるため一番初めから完璧を目指しているといつまで経っても導入が進まないという事にもなるので、最低限のものだけ整備して徐々に整備を行っていくやり方が推奨です。メソドロジーにも記載がありますが、下記のイメージです。

f:id:syachiku_inu:20200812003006p:plain

『UiPathメソドロジー_ver1.1.0.pptx p26から引用』

案件推進時の注意点

様々な案件に関わってきた中で、注意した方が良いものを紹介していきます。

0.RPAプロジェクト案件フォルダ

フォルダ階層ルールを決めておかないと後々整理するのは大変です。サンプルでRPAプロジェクト案件フォルダ例を掲載しておくので参考にしてください。

f:id:syachiku_inu:20210403190337p:plain

1.設計書の業務フローの粒度

設計書にはAs-Is、To-Beフローを記載する例が存在しておりますが、こちらの設計書の粒度を細かくし過ぎると作成やレビューに膨大な時間が掛かり、簡易的すぎると処理内容が分からず意味を成さないものとなってしまいます。設計書の役割としては、どのような手順でどのような条件分岐や変換をしているのか、業務ユーザと認識相違が起きないようにする事と保守の時に仕様理解できる事が目的となります。既存で作業手順書が存在している場合でRPA化後も処理内容が変わらない場合、その手順詳細を細かくRPA設計書に記載しなくても良いと思います。また、既存の手順書の記載が足りない場合、RPA設計書だけその内容を取り込む事がありますが、既存の手順書にも反映しておくべきです。自動化した後に人で作業を代替する必要になった時に対応できなくなってしまう(有識者がいない)事が起きてしまいます。

2.案件フォルダ

各ロボ事の案件フォルダのテンプレートが決めないまま開発を進めていくとどこに何のドキュメントがあるのかすぐに分からず、非常に非効率になります。案件フォルダテンプレートは初期段階でも用意しておくことをお勧めします。後で整備していくのは非常に大変です、、上記「0.RPAプロジェクト案件フォルダ」の「20.開発案件管理」フォルダ中に「プロセス管理番号.プロセス名_UiPath」等案件フォルダ名のルールも決めたフォルダを作成していくのが良いでしょう。

【案件フォルダサンプル(フォルダ名の例：001.勤怠登録(日次)_UiPath)】

f:id:syachiku_inu:20200812101643p:plain

3.保守が考慮されていない開発

開発した人が保守するから設計書や運用マニュアルを作成しない現場がありますが、この考え方は危険だと思います。開発ができる人が保守にいれば作ったものを見れば分かるからとも言いますが、何もない状態でワークフローだけ見ても業務が分からないと理解に時間が掛かったり、重大なミスを起こしてしまったりの原因となります。RPA開発は低コストでできる観点からテスト環境を用意せず、本番環境だけで開発やテストをするものも存在します。テスト環境がある場合も、テスト環境用に切り替えが必要なものがある場合もあります。このような内容がドキュメントとして存在していないと保守が対応しきれなくなる要因となります。少なくとも下記の情報はないとトラブル対応やバージョンアップ対応時に非常に苦労する事となります。作った人が現場から離れる事も考慮して運用、保守できる体制を構築する事が推奨です。

<ドキュメントとして情報がないと保守の時に困るもの>

〇改修をする際、どこの環境を使ってどのように改修すれば良いかの情報

〇ロボが扱うフォルダやファイル一覧

〇障害時の対応概要

〇そのロボ特有の注意点(実行時に事前承認が必要等)

〇業務担当者の連絡先

保守に関して細かく必要な情報と確認できる状態(ドキュメント化)していないとどのように困るかの記事を別で記載しているので、詳細知りたい方は下記記事をみて頂ければと思います。

4.ナレッジ管理

案件推進していくと、次の開発に活かしていった方がよいものが出てきます。この時誰かの頭の中だけにそのナレッジがある状態にしてしまうと、過去苦労した事を同じように違う誰かが苦労してしまう無駄が発生します。これを防ぐために皆がナレッジをとりあえず記載できる場所を早めに用意しておいた方が良いです。可能であれば更にナレッジを整理して皆が参照できる場所に掲載をしていく事で、教訓を生かした高品質の開発を行う事が可能となります。UiPath開発を初めてやる人はこのTIPS集を必ずみて下さいやこのシステムを開発する人はこのTIPS集を必ず見て下さいというものができれば、品質は向上し、開発速度も早めていく事が可能となります。整理したナレッジの掲載場所はシェアードポイントやAutomationHuB等を導入するのも良いでしょう。ナレッジ整備に時間を掛けてしまいすぎないようにするのが注意点で難しい所です。

5.手順書の作成

ナレッジと似ていますが、端末セットアップ方法や利用申請、Orchestratorの操作手順等は誰でもできるように、本格的な導入を始めていく前に整備しておいた方がよいです。特定の人に頼りすぎると、特定の人に負荷が集中してしまったり、その人がいないと端末を増やせなかったり、リリースができない等の問題が発生してしまいます。作成時に少し時間が掛かってしまいますが、ロボットの数が増えていくにつれて、手順が整備できている現場とできていない現場で、対応速度やミスの多さ等保守の品質に違いが出てきます。

6.なんちゃってアジャイル開発

アジャイル開発という名でただ計画が曖昧なだけのウォーターフォール型プロジェクトが存在します。端末やアカウント、権限の準備は直前にやるものではなく、申請期間も考慮して計画的に行うべきです。案件がスムーズに進まない事で開発者の人は並行で違う案件を進めたりして作業効率も落ちて、ストレスも掛かります。見積もりができないため、計画が立てられない所も多いですが見積もりはアクション数(操作数)、分岐数、扱うシステム数、入出力ファイル数、重要度、複雑度、開発者レベル等で計画と実績の評価を積み上げていく事で、将来的には概算見積もりを機械的に出していく事が可能になります。そのため見積もり表作成のために、案件に掛かっている時間は管理しておくことをお勧めします。PoCの段階で見積もりを任せられそうな人材にUiPath開発をさせておくと、初期段階でもその人が概算見積もりを作る事ができると思います。

7.メーリングリスト

何か全体に不具合があった際や、各業務単位に問題があった際に業務担当者に連絡が必要となります。その際連絡先が一覧化あるいは関係者宛のメーリングリストを作成しておく事で、迅速に対応できるようになります。稼働ロボット一覧に連絡先の情報はあった方が良いです。

8.共通部品や初期テンプレートの利用

UiPathにはUiPath Go!と言われるマーケットプレイスが存在します。ここに無料で使える初期テンプレートや共通部品が1000個以上存在しているため、初期段階から活用していく事をお勧めします。初期テンプレートについては別の記事で詳細説明していますが、初期段階ではとりあえずAttended Frameworkを利用すると良いでしょう。エラーハンドリングやロギングについてを一から考えて作るのは大変です。

9.工数と体制の管理

どの開発現場でも同じですが、今までどの作業にどれだけ時間が掛かっているか把握する事は重要です。保守するロボの数が増えてくれば当然保守や運用に必要な時間も増えていきます。過去分の作業時間を抑えておけば伸び率を把握する事ができて、事前に要員の調整や計画ができます。また、時間が掛かり過ぎている箇所に対して原因を調査して対策していくことも可能です。時間の管理ができていないといざ炎上気味になってきた際に、要員が足りないのか、無駄な作業をやってしまっているのかの把握から始まり、対策が遅れてしまい結果炎上してしまいます。しかし、管理できていれば、適切な時間の増え方をしている事、要員の調達が必要である事を会社側にも納得のいく調整が可能となります。

f:id:syachiku_inu:20200812120702j:plain

まとめ

UiPathの案件はUiPath社が公表しているドキュメントを活用していく事で、高品質な開発や運用をしていく事が可能です。但し、上手く活用していくにはシステム開発に必要な案件管理能力や調整力、あるべき姿を考えられるような人材が必要となります。初期段階や拡大期前は優秀なPMがプロジェクトにいるのといないのとで、その先の開発や保守効率に大きく違いが生まれてくると思います。また、上記「はじめに」に記載しているようなドキュメントの存在を知っているのと知らないのとでも大きな差が生まれます。「はじめに」に記載しているドキュメントは一通りダウンロードして必要な人が学習できる環境の提供(情報展開)をこのブログを読んで頂いた方に実施して頂ければと思います。

その他のUiPath情報も纏めています。下記リンク集の記事があるので、こちらから各場所に飛んで頂ければと思います。

RPA コンポーネント - コレクション、連携パッケージ　| UiPath Marketplace

2020-07-19

SE歴10年の私がRPA(UiPath)を始めて苦戦したこと

RPA(UiPath)

私がRPA(UiPath)に携わって一年くらいが経ち始めようとしていますが、新しい領域へのチャレンジは内心やっていけるのかなという不安もありました。同じようにこれからRPA(UiPath)開発に関わっていく、IT経験者の方々向けへどの辺で苦労するのか、どうやって解決していったかについてのナレッジをこのブログで記載していこうと思います。「少し調べて見たけど難しいと感じた」という方も解決方法が分かれば不安が解消されるかもしれませんので、是非参考にして頂ければと思います。(本記事は2020年7月に投稿した記事です)

結論としては、見本となるドキュメントや情報、便利なツールが色々登場してきているので、2019年の夏頃よりかは、より理解し易い環境が整っており、学習すれば未経験者でも習得できるのでIT経験者の方は安心して頂いてよいと思います。(ただ開発以外も含めた上級レベルになるにはそれなりの努力は必要となります。製品や業界の成長スピードが速く、皆を先導し続けるような専門的な知識やノウハウを持ち続けるには情報をアップデートし続けなければいけません)

f:id:syachiku_inu:20200718182143j:plain

＜目次＞

RPAの仕事をやろうとしたきっかけ
RPA(UiPath)との出会い
苦戦1：開発画面が小さく、開発した内容を把握しづらい
UiPathアカデミーで入社前に勉強
苦戦2：UiPathの標準機能で何がどこまで出来るのか分からなくて、開発のイメージがつかない
転職後にいざRPA開発!!
苦戦3：エラー時運用が見積もり時に顧客と握られていなく、妥当な工数も判断できずどうすれば良いか困惑
苦戦4：完成形のイメージができず、どうやって作ればいいか考えるのに時間が掛かる
苦戦5：単体テスト仕様書をどうやって作れば良いか分からない
苦戦6：開発機と実行機が違う端末を使っていて、開発機では動くのに実行機で動かない
苦戦7：バージョンや製品名(ロボット種類)とライセンスが複雑
苦戦8：コーディングレビューに時間が掛かる
苦戦9：解決が困難な問題が発生したときの解決が困難
苦戦10：製品や業界の進化が早く、学習量が多い
さいごに

RPAの仕事をやろうとしたきっかけ

まず私がRPAの仕事をやろうとしたきっかけですが、2017年頃にRPAが日本でかなり流行り始めて、これからはAIやRPAの仕事ができた方が市場価値を上げやすいと世間が騒ぎ始めていたのと、私自身身近な業務を効率化していく方が見えない誰かが使うシステムを作っているよりもやりがいがあったので、業務改善系の仕事につきたいと思い、RPA導入が盛んな企業に転職して私のRPA人生が始まりました。(初めての転職だったため、他の会社でも自分の力が通用するのか試したいという気持ちもありました)

RPA(UiPath)との出会い

転職活動時に未知の技術であるRPAについてまずリサーチを始める事にしました。入ろうと考えている転職先がUiPathをメインに取り扱っている事を聞いて、他社導入事例の本と『できるUiPath』という書籍を購入し、どのような事ができるのか、どうやって開発していくかを理解しようとしました。

事例集は「削減時間すごいなぁ」、「いろんな業種に適用できるんだなぁ」とかやれることの大枠が掴める程度でした。『できるUiPath』の方はUiPathの開発ツールである「Studio」の使い方がメインで記載されており、フローチャートを作って、その中にやりたい処理(アクティビティ)を配置してオプションをいじるだけで簡単に作れるんだなぁという感覚を掴む事ができました。この時点ではJava開発を結構やってきたし余裕かなと思っていました。(まさかこれからこんなに苦労する事になるとは思ってもみませんでした)

無料で使えるコミュニティ版があるという事でコミュニティ版をインストールして『できるUiPath』に書いてある事をとりあえず試してみる事にしました。ここで早速1つ目の苦戦ポイントが、、

f:id:syachiku_inu:20200718230714j:plain

苦戦1：開発画面が小さく、開発した内容を把握しづらい

下記が実際のUiPathで開発を行う際の開発ツール(Studio)の画面です。

赤枠部分が実際にフローチャートを作り、処理ごとのパーツ(アクティビティ)を配置していく所ですが、見えている部分が少ししかなく、全体をぱっと見る事が難しいです。右下の表示倍率を調整する事で全体が見えやすいように多少なりますが、それでも小さいと当時は思っていました。さらにフローチャートを久しく書いてなかったので、完成後のフローチャートが頭に浮かばず、作成や確認するのに時間が掛かりました。

f:id:syachiku_inu:20200718190958p:plain

ここの苦戦の解決方法は慣れる事です。頭でフローチャートを作り上げる事ができない人は紙に書いてみてその紙を見ながら開発を行っていくと、そのうち自然と頭の中でフローチャートを描けるようになっていきます。

慣れたからといってフローチャートを全く書かなくなるかと言われれば、そうではありません。複雑な分岐の開発を行っていく場合に頭が混乱してきたときは、まず目に見えるところに書いて整理する事が大事です。誰かにフローを相談するときにも目に見える状態にして相談はしましょう。

赤枠部分で「右クリック」→「イメージとして保存(S)」を押すと画面の内容をイメージとして保存してみる事もできるので、確認する際にはこちらの手法を使うのも良いかもしれません。設計書に詳細の業務フローを作らないでこのイメージを設計書にペタッと張り付けて補足するのもありかなと思います。補足も注釈という機能を上手く使えば文字になりますので、Studio上で表現する事はできます。

f:id:syachiku_inu:20200718192604p:plain

UiPathアカデミーで入社前に勉強

UiPathでは無料でオンライン学習できるサイトを提供しています。入社後はこちらのアカデミーを使って勉強を開始していくという話を聞いていましたが、早く即戦力になってできるやつがきたというイメージをつけたかった私は入社前にアカデミーを使って個人学習を始めました。

変数やデータテーブル等の知識は持っていたので楽々進んでいきました。UiPathアカデミーは2020年5月よりリニューアルされており、一年前もクオリティが高かったですが、今は更に高くなっています。書籍を買って勉強を始めるよりもまずはアカデミーに登録(無料)して学習を進めていく事をお勧めします。

UiPath アカデミートレーニング

理解できてきたところで自分でなにか作ってみようと思い、開発し始めたところで2つ目の苦戦ポイント登場。

f:id:syachiku_inu:20200718232607j:plain

苦戦2：UiPathの標準機能で何がどこまで出来るのか分からなくて、開発のイメージがつかない

標準のUiPathでどこまでの事ができるのか把握できていない状態なので、この操作は標準のアクティビティでできるのか？どのアクティビティを使うのが良いのか？という判断ができなかったり、選んだアクティビティよりも優れたアクティビティがあり、選びミスをしてしまったりが多発しました。

どんなアクティビティが標準に存在していて、どの部分をどうやって作るのかがイメージできないと開発の見積もりもぶれぶれのものになってしまうし、そもそも実はこんな事はできませんでした。という事で開発が失敗してしまう事があると思い焦りました。

この苦戦の解決策はまず基本のアクティビティに慣れてどのような仕組みでUiPathが動いているのか把握した後に、アクティビティ一覧を確認してUiPath標準で出来る事を頭に入れておくことで解決する事ができます。UiPath公式が公表している日英対訳表のアクティビティ一覧か、一覧表を纏めてくれているブログがあるので、そちらを見て把握していくと良いと思います。(現在の私は後記で紹介するworkflowInspectorというUiPath社が無料で提供しているツールを改造して、アクティビティを一覧化してそれを見ています。いつか見やすく整理できたら展開しようかと思います)

アクティビティ名ー日英対訳表

UiPathで実現できる事について、更にレベルを上げていきたい方は旧UiPath Go!(現在はマーケットプレイス)というUiPathのマーケットプレイスで公表されている部品の内容も把握する事をお勧めします。標準機能では作りこみが必要なものや実現が難しい処理がマーケットプレイスの部品を扱う事によって、実現できたり、少ない工数で作成する事が可能となったりする可能性があるからです。会社で利用する際はセキュリティ基準を満たしているかや公式サポートがされているか、サポートが手厚いか注意してください。

転職後にいざRPA開発!!

入社して割とすぐに早速現場で開発を行う事になりました。(2案件同時のリーダー兼開発者)いきなり2つの案件同時かよと思いましたが、できる人を目指すためにYESマン発動でとりあえずやってみる。1件目が要件定義からで2件目が提案(見積もり)からの案件でした。ここで3つ目の苦戦ポイント。

f:id:syachiku_inu:20200718233154j:plain

苦戦3：エラー時運用が見積もり時に顧客と握られていなく、妥当な工数も判断できずどうすれば良いか困惑

今までトラブルが許されないようなシステム開発ばかりしてきていたので、エラー時運用も考えた上で、開発を進めていくのが当たり前の世界で育ってきた私は要件定義からの案件で障害時運用を顧客と相談しました。すると顧客要望は複数手順(システム別)があって、各場所で複数明細の処理をしているが、どこの手順で失敗しても、各明細別に再実行可能な作りにしてほしいという要望だったのです。当時の私は初心者だったので、見積もりの工数を見て、こんな工数でもできるものだと思っていましたが、結果としては全然工数が足りなく、プチ炎上しました。

この苦戦の対応策は見積もり時に障害運用の大枠も顧客側と握った上で見積もりをする事が解決策となります。また、見積もりを正確に行っていくには、処理数(アクティビティ数)と分岐数、扱うファイル数、システム数、開発者レベル等々を係数で掛けて算出する見積もり表を作り、実際に使って実績と照らし合わせて微調整していく事で精度の高い機械的に工数を算出する見積もり表を作り上げていく事ができます。見積もりの根拠があれば顧客も納得感があるので、あると便利です。設計書や移行等の工数は自動化対象業務の設計書や手順が揃っているか等個別に変わってくるため、タスク積み上げで見積もりを算出します。(根拠のある見積もりができないと工数足りないのでそれはできませんと調整することすらできなくなってしまいます)

また、特に初期テンプレートが決まっていないのであれば、Attended Franeworkという初期テンプレートを使って開発することをお勧めします。初期設定ファイル読み込み、エラーハンドリング、ロギング機能が備わっており、初心者向けの作りになっているので便利です。初期テンプレートで決まったものがない場合是非活用してみて下さい。再実行可能とする仕組みは作りこみすぎると保守の難易度も上がりますので、再実行可能なポイントはあまり細かく設定しすぎないようにする事と再実行の仕組みは本当に必要かどうか確認して調整した方がよいです。顧客側は再実行できた方が嬉しいのは当然ですので、業務の重要度や障害時対応内容、開発工数によって、再実行処理実装有無と作りこみレベルを決める事が重要です。また、プログラムのデザインパターンを整えて、使いこなしていけば開発時間がかなり削減できていきます。

苦戦4：完成形のイメージができず、どうやって作ればいいか考えるのに時間が掛かる

入力ファイルを読み取って、結果を同じ入力ファイルの明細毎に書き込む処理や複数の入力ファイル情報をキーで紐づけて開発していくもの等様々な開発パターンがあるのですが、初めのうちは完成形がイメージできないのです。

その場は経験者の人にサポートに入ってもらって、完成したものを見る事で理解できましたが、この苦戦の対策としては誰かが開発したプログラムをたくさん見ておく事です。これは他のプログラム言語でも同じ対応策だと思いますが、完成しているものを見て理解していく事で、作り上げる完成形がイメージできるようになります。また、より効率的な作り方の方で各開発パターンを上書きしていく事で、効率的な開発を行えるようになっていきます。今回は説明を省きますが、ブラウザは何を使うのが一番効率的なのか、Excelアプリケーションスコープとワークブック機能のどちらを使うのがベストなのか等自動化対象や内容によって、ベストな作りは変わってきます。経験によりベストな作り方の法則が見えてきますので、それをTIPS化していく事で、皆が品質の高い開発が行えるようにしていく事が可能です。(UiPathナレッジベースにいくつか情報があがっています)

ナレッジベース | UiPath

UiPathでは初期テンプレートをいくつか公式で用意しています。この初期テンプレートをまずは理解し、その後に誰かが開発したものを会社内で見たり、ネットに転がっているものをみたり、UIPath マーケットプレイス(結構難しい作りのやつ多い)のものを見て徐々に力をつけていくと良いです。初期テンプレート(フレームワーク)についてはしおちゃんさん(@Jun96427231)のブログを参照頂ければと思います。

UiPathあなたに最適なFrameworkはどれ？ - Qiita

f:id:syachiku_inu:20200718233945j:plain

苦戦5：単体テスト仕様書をどうやって作れば良いか分からない

今までは決まったフォーマットが用意されており、過去作られているものを参考に作成していけばよかったのですが、テスト仕様書が顧客毎にフォーマットもばらばらだし、作ってあったり作ってなかったりして、どんな仕様書を作成すればよいのか悩みました。今までの経験を活かして独自のフォーマットを作り、細かい機能単位を単体とみなして当時はテストをしましたが、テストケースを一から作ったりするのに余計な時間が掛かりました。

この苦戦の対応策をしては、現在ではUiPathではUiPathメソドロジーという凄まじいドキュメントが無料提供されており、こちらを活用する事で解決する事ができます。このメソドロジーには、単体、結合、UATテストケースのフォーマットはもちろん、障害管理票やインフラ設計書、ロボット管理表、セキュリティ、ライセンスポリシー等様々なドキュメントが用意されています。色々調べて摸索しましたが、基本こちらのドキュメントを改造して自分達が使うドキュメントを整備していくやり方が最適解だと思います。単体テストケースは対象業務の重要性や開発者のレベルによって作る作らないを変えたり、チェックシートレベルの簡易版としてだけ作ったりするといったやり方もありだと思います。(UiPath以外の利用は免責事項で禁止されているので注意)

UiPathメソドロジー | UiPath

苦戦6：開発機と実行機が違う端末を使っていて、開発機では動くのに実行機で動かない

UATになり実際に扱う端末で動かそうとしたところ、開発時で動いていたものが実行機で動かない事態がおきました。「あれっ？誰かバグった資源を最新にあげたのかな？」と思いましたが、開発機では同じ資源で問題なく動作するのです。

UiPathではセレクター(画面上の構成要素を特定するための文字列)とOCR(イメージ)機能の2種類の仕組みで操作対象を特定して処理をしています。このセレクターが違う端末だと違う値になっている事があり、動かないのです。またインターネットオプションの設定が違ったり権限の設定が違ったりすると正常に動作しないパターンも存在します。全く同じ環境にする事でこの問題は解決できるのですが、アプリ単位(エクセル)のツールバーの表示有無でもセレクターが変わってしまったりしてかなりやっかいです。RPAが敬遠される大きな理由の一つはここです。

対応策としては開発機がそのまま実行機にできればよいですが、できない場合まずは端末間の環境差分を極力なくす努力をする事です。OSの言語設定やタイムゾーン、機種や画面サイズ、グループポリシー(権限)、等々や各Officeのツールバーや設定をあわせておくと同じように動作する確率が上がります。差分をあわせた方が良い項目をチェックリスト化すると良いでしょう。あとはセレクターに注意を払って開発をする事です。セレクター内に「はい」とか「データ」とか画面上他の場所にも登場していきそうな値が入っていれば、パターンによって画面上に2個その項目が出てくる可能性がないか考えます。

セレクターは画面上に同じ要素が2つあったりする場合、idxという連番を振る識別情報が付与されます。「idx=2」というセレクターは画面構成上2番目のものという意味になります。これが状況によって1だったり、3になったりする場合があるので、idxなしでも特定可能とできるか、idxの番号が変わる可能性はないかを考慮して開発を行う事で、環境の変化に強い開発を行う事ができます。ブラウザを扱う場合開発者ツール内でソース内を検索して調べると確実です。画面上に見えていないけど隠れて同じ項目名が存在している場合もあります。

また、特定できていてもオプションの内容によって動作したりしなかったりという場合もあります。対応方法の詳細は様々なブログやUiPathのナレッジベース等に情報があるので、そちらを見ながら環境変化に強い開発を行っていくしかありません。いつかUiPath公式か誰かが各アクティビティで環境変化に強いベストな作り方集を作成して展開されれば良いですね、、ここは扱うシステムによって対応も変わってきたりもするので今でも日々苦戦します、、(アンカー機能を使ったり親要素、子要素を活用したりjavaScriptを仕込んだり、イメージ認識にしたり様々)

f:id:syachiku_inu:20200718234922j:plain

苦戦7：バージョンや製品名(ロボット種類)とライセンスが複雑

UiPathには製品のバージョンとそれを扱うためのライセンスとロボットの種類が存在します。よくAR、UR、OC、STという言葉が飛び交います。初めは慣れないのでこの略称は覚えていた方が良いです。(URはとあるCMで良く聞いていたので聞く度に頭にであーる！が思い浮かんでいました)AR(Attended Robot)、UR(UnAttended Robot)、OC(Orchestrator)、ST(Studio)。

また、よくバージョンとライセンスがごちゃごちゃになってしまう事があります。ライセンスは各製品を使える権利の事であり、バージョンと関連しているものでありません。上記のAR、UR、OCのライセンスを購入し、選んだバージョンをインストールしてライセンス認証する事で利用できます。(ライセンスは正確にはもう少し細かいバリエーションがあります)

バージョンは下記公式の情報をみて覚える事ができます。(会社であればサポート期間が長いロングタームサポートを扱っていくのが多いです。バージョンアップ時には無影響確認やバージョンアップ作業をしないといけませんが、頻繁にあると保守工数が高くなるためです)

ライセンスは新ライセンスに変わってきているので、この記事内では説明を省きます。

Overview - Product Lifecycle (uipath.com)

UiPathのStudioやアクティビティパッケージのバージョンについては、下記Qiitaで解説している記事を別で投稿しているので、各バージョンについて知りたい方はこちらの情報もご活用下さい。

【RPA(UiPath)】各バージョンとアクティビティパッケージの解説(Orchestrator観点無) - Qiita

f:id:syachiku_inu:20200718235440j:plain

苦戦8：コーディングレビューに時間が掛かる

誰かが作ったワークフローの平仄が取れているか、変数名のスコープ(利用範囲)が正しいか等確認するのに苦労しました。Studioで一つ一つアクティビティにフォーカスをあてて移動しながらチェックしていきましたが、全体の平仄が取れているのか確認するのは辛過ぎました、、Excelにエクスポートしてプログラム上で纏めて確認できるものはチェックするような職人みたいなやり方をしていました。。。。

こちらの対応策としては、現在は2019.10のバージョンよりコードチェック機能(WorkFlowAnalyzer)がStudioに搭載されたのと、無料で公開されているWorkFlowInspectorというツールを活用する事である程度自動でチェックできるようになっています。WorkFlowAnalyzerで頻繁に実施者にチェックさせ最後にWorkFlowInspectorでチェックを行うやり方が個人的にお勧めです。コーディング規約も無料で公開されています。コーディング規約には開発のベストプラクティスの要素も入っているので、是非一読して頂ければと思います。

コーディング規約とワークフロー評価キットを無料公開 ―RPAユーザーの高品質な開発を支援 | UiPath

苦戦9：解決が困難な問題が発生したときの解決が困難

開発をしていくとたまに解決困難な問題が発生する事があります。このようなとき大体JavaとかCとかの開発現場では、詳しい人がいて聞いたり、インターネットで調べれば解決できるのですが、まだインターネット上に情報として存在していなかったり、誰も経験したことがない問題が発生する事があります。

この苦戦の対応策としては3つ。社内か知り合いの詳しい人に聞くか、UiPathコミュニティフォーラムに質問を投稿するか、UiPath公式のカスタマーサポートに質問をするかです。UiPathコミュテニィフォーラムには世界中のUiPathユーザーが質問に答えてくれます。社内で解決しない場合は、こちらに問い合わせして解決してみると良いでしょう。誤りが許されない重要な質問や社内機密等の重要情報に関わる質問、コミュニティフォーラムでも解決しなかったものは、UiPathカスタマーサポートで問い合わせすると良いでしょう。(但しカスタマーサポートはライセンスを購入している人しか問い合わせできません。Webのフォームから問い合わせを行い、メールで回答が返ってきます。メールでそのまま不明点をやり取りする事もできます)

Latest 日本FAQ topics - UiPath Community Forum

カスタマーサポート | UiPath

下記記事に分からない事の解決方法を別途纏めているので、解決方法をもっと抑えたい方はこちらの記事も参考にしてください。

UiPathコミュテニィフォーラムの過去質問と回答を頭の中にいれておくと、問題発生時にフォーラムにたしか書いてあったなとすぐ辿り着いたり、その場で解決する事ができるようになったりします。極めたい人はフォーラムの過去投稿分析もすると良いと思います。

f:id:syachiku_inu:20200719001340j:plain

苦戦10：製品や業界の進化が早く、学習量が多い

2019年以降UiPathは一気に成長し、公式サイトが見やすくなったり2020年に入ってからはプロセスマイニングやテスト自動化等の新製品が出てきたりと技術と共に成長していっています。RPAはAI-OCRやAIとも連携して活用されていくため、幅広い専門知識が必要となってきます。最新技術は常に学習が必要となる領域です。まだ誰も分かりやすく纏めていない部分も時には自分で調べて悪戦苦闘しながら進めていかなくてはいけません。チームを牽引していくような立ち位置を目指す方は、学習を続けていく覚悟が必要です。

UiPathの開発をやる方は、UiPath社の公式が出している下記の書籍を机の横に置きながら、分からない所があれば本を見ながら習得していくやり方がお勧めです。現在2バージョンの書籍があるので、最新と古いバージョンを間違わないようにお気を付け下さい。

さいごに

2019年中旬頃に比べて、2020年7月現在では当時苦戦していた事を苦戦しないようにUiPath公式や各ブログを発信されている方々、UiPath Friendsのコミュテニィの人が情報を発信していたり、オンライン上から遠隔サポートをしてくれるサービスを展開している企業やサービスが始まったり、開発の基盤は年々整ってきているのではないかと思います。

ただ、存在している情報に気付く事ができなければ、一から自分で作り上げたものが既に最適解が存在していた、、、というような事が発生してしまいます。このような事にならないようにどこに何の情報が存在しているのかを把握し、ナレッジベースや技術者ブログ、twitterを日々チェックする事はRPA推進者としてとても重要です。私のブログでもUiPath情報取得先を纏めていますが、自分なりに必要な情報を取捨選択して情報収集して頂ければと良いのかなと思います。

これからUiPathに関わっていこうかなと思ってブログを見てくれた人にとって働くイメージがつくような情報になっていれば幸いです。

↓私の方で収集した有益な情報はここに集めていきますのでどこになんの情報があるか知りたい方は参考にして頂ければと思います。ナレッジベースの更新情報とかその他の細かい情報はtwitterで何かあれば都度お知らせしていますので、自分で検知するのが面倒な方はフォローして頂ければと思います。RPA以外にもIT人材育成関連、DX関連等様々なITに関わる事を主にツイートしています。

twitter：@RPA_AI_it

https://www.nri.com/-/media/Corporate/jp/Files/PDF/service/scs/SC7M_new20181019.pdf?la=ja-JP&hash=37FD70B3D6F821F93C2DD21153B43A722440F987

⇩上記リンク先にはこんな情報のリンクが纏まっています。

f:id:syachiku_inu:20220213174414p:plain

2020-04-20

【IT経験者向け】開発やリーダー業務を行う上で知っておくと役に立つ情報(ナレッジ)まとめ

IT知識

この記事では、IT初心者ではなく一年以上IT業界を経験して更なるレベルアップを目指している方や、マネジメントを行っている方向けに知っておくと役に立つ情報を纏めています。未経験の開発フェーズ(基礎検討や要件定義)を任された時に社内にガイドラインがないと自分がやっていることが正しいのかどうかとか、観点が抜けてないかとか不安になると思います。そんな方が参照するとよい情報を纏めています。私もリスク分析やテスト計画、ドキュメント作成を行う際にいまだに参照しているものもあります。一度に全て覚えるのは難しいため、各開発フェーズの担当になる際に参照して知識としてInputして業務でoutputして身につけていくのが良いと思います。相手の立場の仕事で何をやっているか知っていると的確なアドバイスや相手を考えた行動ができるようにもなるので、関わっている人の仕事概要を知るのも働く上では役に立ちます。

f:id:syachiku_inu:20200420110344j:plain

【目次】

【全体的】
Gihub:free-programming-books
デジタル庁：デジタル社会推進標準ガイドライン
【デジタルトランスフォーメーション系】
【IT戦略系】
System Consulting 7Methods（IT運営改革メソドロジ）
企業IT動向調査
経営戦略
ITによる変革の方法論集
経営とＩＴの関係の歴史的変遷
Gertner Japanのサイト
【要件定義系】
IPA：ユーザのための要件定義ガイド
IPA：機能要件の合意形成ガイド
IPA:実務に活かすIT化の原理原則17カ条
【設計・開発系】
プログラマが知るべき97のこと
Qiita：なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】
IPA:企業における情報システムのログ管理に関する実態調査
【テスト系】
テスト計画
日本システム開発株式会社：単体テストのコツ
NTTコムウェア：網羅性の高いテスト設計を目指して
【保守・運用系】
IPAの保守・運用説明資料
IPA：ソフトウェア開発における定量的管理の主な手法
運用研究会 / 日本UNIXユーザ会：運用ドキュメントのあり方と課題
IPA：「障害管理の取組みに関する調査」報告書
IPA：ITシステムにおける緊急時対応計画ガイド
IPA：障害の再発・未然防止に向けた原因分析と知識移転
【プロジェクトマネジメント系】
プロジェクトマネジメントとは
IPA:PM育成ハンドブック
プロジェクト・マネージャーが知るべき97のこと
IPA ITプロジェクトの「見える化」
IPAのセキュリティ資料
IPA:情報処理システム高信頼化教訓集(ITサービス編)
【ITマネジメント、監査・リスク管理系】
情報マネジメントシステム認証センター
ITIL Wiki
システム監査を知るための小冊子
経済産業省のシステム管理基準
IPA:ITプロジェクトのリスク予防への実勢的アプローチ
IPA:情報処理システム高信頼化教訓集 ITサービス編
【その他】
総務省：統計表における機会判読可能なデータの表記方法の統一ルールの策定
総務省：国民のためのサイバーセキュリティサイト
総務省：クラウドサービス提供における情報セキュリティ対策ガイドライン
最強のエクセル使い方講座【たった1動画で全てが分かるExcelの教科書】MicrosoftMVP受賞
IPAの社会基盤センターの資料
政府CIOポータル
仕事で成長できる人に変わるビジネスマインドセット
課題・問題発見のフレームワーク～13の方法とツール
Qiita：新人の方によく展開している有益な情報
IPA：刊行物のご案内
IPA：報告書・成果物
フォルダー、ファイルの名前の付け方
見やすいプレゼン資料の作り方 - リニューアル増量版
さいごに

【全体的】

Gihub:free-programming-books

ソフトウェア開発やコンピュータ科学の技術,その他様々なプログラミング言語や機械学習に関する書籍や資料について，無料かつ日本語で読める洋書の翻訳書などを中心に大量にまとめたリポジトリです。これから紹介していくものと一部内容被っているものもあります。

github.com

デジタル庁：デジタル社会推進標準ガイドライン

日本の政府が扱うサービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理についての手続・手順や、各種技術標準等に関する共通ルールや参考ドキュメントをまとめたガイドラインです。プロジェクト管理、要件定義～保守運用、システム監査まで実施方法や注意点等有益な情報が記載されており、一通り読んで実践して読み直すをやっていくと力が身に付いていくと思います。政府ユニークの部分は企業に置き換えが必要です。セキュリティやクラウド、データ連携、アジャイル開発に関わるドキュメントも揃っています。非常にお勧めです。

www.digital.go.jp

【デジタルトランスフォーメーション系】

「DX全体の流れ」の図が良いです。ツールやシステムを考え無しに入れ替えるだけではDXとは言えません。

note.com

【IT戦略系】

System Consulting 7Methods（IT運営改革メソドロジ）

野村総合研究所のIT運営改革に関わる方法論集。IT戦略を立てる時にどのような事を考えてどのような手法で実施していくか纏められています。

企業IT動向調査

一般社団法人日本情報システム・ユーザ協会が企業のIT部門を対象にアンケート調査とインタビュー調査を行い、企業におけるIT投資、IT利用の現状と経年変化を明らかにするとともに、年度ごとに重点テーマを設定し分析したレポートです。ITトレンドや各企業やサービスの動向を知る事ができます。

juas.or.jp

経営戦略

経営コンサルタントの方が分かりやく、経営の分析手法やノウハウを解説しているサイトです。コンサルタントを目指す方や、マネージャーになった方、目指す方にお勧めです。

www.s-naga.jp

ITによる変革の方法論集

日本ITガバナンス協会 ITコンサルタントの方法論が纏められているサイトです。各マネジメントと変革についての方法論が纏められています。別のページにはITガバナンスについての情報が豊富に存在します。

itgi.jp

経営とＩＴの関係の歴史的変遷

1960~2010年頃までの経営においてITがどのように期待され利用されてきたかの歴史を知る事ができます。歴史を知る事で過去の教訓を活かしたり、現在のトレンドを掴むのに役に立ちます。

www.kogures.com

Gertner Japanのサイト

ホワイトペーパーやウェビナー(日本語も有)から、企業が抱える問題や課題に対しての考え方やどのように対応していけば良いかの情報を得る事ができます。

www.gartner.co.jp

【要件定義系】

IPA：ユーザのための要件定義ガイド

システム開発の現状や要件定義を成功に導く128の勘所が紹介されている資料です。要件定義に関わる方にお勧めです。PDFは無料でダウンロードして参照できます。

IPA：機能要件の合意形成ガイド

各機能別にどのようにユーザと要件をすり合わせを行えばよいかのガイドラインです。ユーザと要件を決める機会がある方にお勧め。

https://www.ipa.go.jp/files/000005141.pdf

IPA:実務に活かすIT化の原理原則17カ条

要件定義を行うにあたって原理原則事項を17つに纏めているものです。

【設計・開発系】

プログラマが知るべき97のこと

大人気の書籍の内容が無料で見れるサイトです。

実際の開発で経験して覚えていくような知識を知る事ができます。かなりお勧め。

xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com

Qiita：なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】

システムエンジニアの人が設計しがちな見難い画面の理由と対策を解説している記事です。利用者がどう使うのか、何が知りたいのか考えながら設計していく画面設計の考え方は人が画面操作するシステム開発に携わる方に役に立つ情報です。利用者が求めているものを作るという部分では、ほとんどのシステム開発に共通する考え方かもしれません。

https://www.ipa.go.jp/files/000052999.pdf

IPA:企業における情報システムのログ管理に関する実態調査

ログがどのように役立てられているか、ログ管理はどのような事をしないといけないのか、保有期間どれくらい必要なのかについて説明されているものです。会社によって既にルールが決められている場合もありますので、社内ルールがないかまずは確認しましょう。

【テスト系】

テスト計画

テストの計画をどのように立てていくかについてですが、下記Qiitaの記事が分かりやすくてお勧めです。

https://www.nskint.co.jp/wp-content/uploads/2015/08/ESEC2011_Session_Unit_test.pdf

日本システム開発株式会社：単体テストのコツ

単体テストの考え方、レビューとテストの違い、手法を学ぶことができます。

NTTコムウェア：網羅性の高いテスト設計を目指して

テストケース作成の考え方、作り方や観点を学ぶことができます。

http://www.aster.or.jp/business/contest/contest2015/pdf/presentation_TCC.pdf

【保守・運用系】

IPAの保守・運用説明資料

システム保守・運用の作業内容、達成基準指標の立て方についてや、信頼性測定方法、サービスレベル、アウトソーシング概要について説明されています。

https://www.ipa.go.jp/about/jigyoseika/04fy-pro/chosa/srm/srm4.pdf

IPA：ソフトウェア開発における定量的管理の主な手法

プロジェクト管理を成功に導くためにはどのような手法があるのか、定量的に把握するためにどうすればよいかを説明してくれている資料です。

https://www.ipa.go.jp/files/000072870.pdf

運用研究会 / 日本UNIXユーザ会：運用ドキュメントのあり方と課題

運用ドキュメントの考え方や課題を整理した上で、「手軽にスピーディに継続的に保守できるドキュメント」を実現するために必要な「情報の構造化」「再利用」「ドキュメント管理」について、説明されている資料。少し情報が古いですが、考え方はとても参考になります。

https://www.nic.ad.jp/iw2011/nee4X/t3-01.pdf

IPA：「障害管理の取組みに関する調査」報告書

トラブル管理方法やあるべき姿、報告内容等の情報が纏められています。保守を担当される方にお勧め。

https://www.ipa.go.jp/files/000025327.pdf

IPA：ITシステムにおける緊急時対応計画ガイド

7種類のプラットフォームに対して推奨する緊急時対応計画や共通戦略、手法の知識を得る事ができます。保守や運用に携わらない人でも保守や運用を気にした設計や開発を行えるようになるのでお勧めです。

IPA：障害の再発・未然防止に向けた原因分析と知識移転

障害時の原因分析や真因分析についてのやり方や再発未然防止策の対策を学ぶ事ができます。

https://www.ipa.go.jp/files/000056176.pdf

【プロジェクトマネジメント系】

プロジェクトマネジメントとは

案件リーダーになって自身でプロジェクト管理をされる方に必要な知識です。プロジェクトマネジメントとは？や管理手法の概要等は下記のサイトを見ると理解しやすいです。

tech-camp.in

PMBOKというプロジェクトマネジメントに関わるノウハウや手法をまとめたものがあるため、これを参照する事で基本的なプロジェクト計画や管理、推進を行っていく事が可能になります。資料を手にいれるためにはPMPという資格を提供している企業のサイトに会員登録が必要となります。会員登録方法はこちらの記事をご参照ください。最近だとプロジェクトマネジメントツールを使えば管理し易くはなってきていますが、課題に対しての対処は経験やPMBOKの知識が役立ちます。

www.pm-samurai.net

IPA:PM育成ハンドブック

PMとは？PMに求められるスキル、PMの育成方法について纏められています。育成方法検討される方やレベルを上げていくにはどうすれば良いか考える方にお勧めです。

https://www.ipa.go.jp/jinzai/itss/activity/PM_handbook.pdf

プロジェクト・マネージャーが知るべき97のこと

大人気の書籍の内容が無料で見る事ができるサイトです。実際のプロジェクトで経験して覚えていくような知識を知る事ができます。かなりお勧め。

xn--97-273ae6a4irb6e2h2k6c0ec7tvc3h1e0dwi7lj952k.com

IPA ITプロジェクトの「見える化」

各工程でのプロジェクトを「見える化」する事によって、プロジェクト運営の成功率を高めていくための活動についての説明がされているものです。どのようにプロジェクトを見える化すれば良いのか、どのように評価して改善していけば良いのか、プロジェクトマネージャーやPMOに必要な知識を得る事ができます。最後に各観点での測定の目的や尺度の一覧がありますので、ここから観点の抜け漏れがないか確認するのにも活用できます。

IPAのセキュリティ資料

IPAとは「日本におけるIT国家戦略を技術面、人材面から支えるために設立された、経済産業省所管の中期目標管理法人たる独立行政法人」の事で国家資格である情報処理技術者試験を実施している法人です。こちらのホームページにセキュリティに関わるものが纏められています。例えばWindow7のサポートが切れるのが問題らしいけど、何が問題なのか、どんな対策をすればよいか分からないときにこちらの情報を参照します。個人、経営者向け、システム管理者向け、技術者・研究者向けでカテゴリ分けされているので、自身が見るべき資料をここで絞る事ができます。

開発をする上でセキュリティ観点はどんな事を知っておかなければいけないのか、概要を知っている事でセキュリティ事故を未然に防ぐことができます。「情報セキュリティ白書」という資料にセキュリティ全般の内容が記載されていますので、まずこちらを読んでセキュリティ概要を抑えるのが良いと思います。

IPA:情報処理システム高信頼化教訓集(ITサービス編)

下記教訓と事例から見えてくる傾向を知る事ができます。知っておく事で経験が無くても対策できるものはあります。視野を広げるためにお勧めです。知らないで防げなくて失敗してしまうのはもったいないです。

・ガバナンス/マネジメント領域
・技術領域

認証基準・ガイド等 - 情報マネジメントシステム認定センター（ISMS-AC）

【ITマネジメント、監査・リスク管理系】

情報マネジメントシステム認証センター

ITSMS等、情報マネジメントシステムを効率的、効果的に運営管理するための仕組みができているか認定をしている機関。運営管理についてのガイドがホームページ内に存在しており、セキュリティ対策の学習ができます。

ITIL Wiki

ITILとは「ITサービスマネジメントにおいてそれぞれの組織に適応したグッドプラクティスの成功事例を体系化したガイドライン」です。どのようにマネジメントすれば良いか、各管理を行うドキュメントはどのような内容にすれば良いのかを参考にする事ができます。

IT Process Wiki - The ITIL® Wiki | IT Process Maps

システム監査を知るための小冊子

リスクをコントロールするための管理と監査の視点についての概要が記載されています。問題を起きにくい状態にするにはどうすれば良いのかの観点ややり方の知識を習得する事ができます。知っておくと一見無駄に見える作業も監査のための作業である事を理解できたり、監査対応を気にして管理を行う事ができます。

https://www.saaj.or.jp/csa/system_audit_booklet2016.pdf

経済産業省のシステム管理基準

情報システムに想定されるリスクを適切に管理・コントロールするためのガイドラインが掲載されています。開発したシステムが基準を満たせるように計画を行う際や評価をおこなう際に必要なものです。監査がメインの仕事でない方はリスクへの対応方法について学んでおくくらいで良いと思います。

www.meti.go.jp

IPA:ITプロジェクトのリスク予防への実勢的アプローチ

プロジェクトを推進していく上で想定されるリスクの洗い出し方や対処方法についての考え方の情報を得る事ができる資料です。

https://www.ipa.go.jp/files/000026834.pdf

IPA:情報処理システム高信頼化教訓集 ITサービス編

主にソフトウェアに起因するシステム障害関連情報を収集し、それらの分析や対策手法の整理・体系化を通して得られる教訓として取りまとめたものです。過去の事例を知る事で対策の視野が広がったり、同じ失敗を未然に検知して防ぐ事ができます。

【その他】

総務省：統計表における機会判読可能なデータの表記方法の統一ルールの策定

統計データ(EXCEL等)を作成する時に「セル結合するな」「1セル1データになっているか」「オブジェクト使うな」等、分析や集計をし易くするためのルールを総務省が公開しています。こちらは通常の業務でも当てはまるため、全オフィスワーカーが知っておいた方が良い知識なのではないかと思うくらいのものです。できていない人や新人には身に付けて貰いましょう！

www.soumu.go.jp

総務省：国民のためのサイバーセキュリティサイト

サイバーセキュリティの基礎知識や必要な対策をわかり易く説明している初心者向けの情報です。子供向けのページも存在しています。

www.soumu.go.jp

総務省：クラウドサービス提供における情報セキュリティ対策ガイドライン

安全・安心なクラウドサービスの利活用推進をするために必要な情報が纏められています。クラウドに関わる方は是非目を通しておきましょう。

www.soumu.go.jp

最強のエクセル使い方講座【たった1動画で全てが分かるExcelの教科書】MicrosoftMVP受賞

Excelの基礎を3時間30分で学習する事ができる動画です。とてもわかり易く、Excelを使っている方は是非一度見る事をお勧めします。新社会人の方々には特にお勧めです。情報量が多いので、一度に全部見るのではなく複数回に分けて見るのも良いと思います。

www.youtube.com

IPAの社会基盤センターの資料

同じくIPAのホームページの情報です。このページは下記の情報が掲載されています。

・IT社会の動向情報

→現在のIT社会の動向や求められる人材、各企業の取り組み状況の情報を得る事ができます。

・スキル変換の推進資料

→アジャイル開発、データサイエンス、IoT、デジタルトランスフォーメーションの考え方や進め方についての情報を得る事ができます。

・データ利活用の推進

→他システム連携を踏まえた開発が必要な場合に考慮すべきデータや文字の共通化の定義例が掲載されています。他システム間連携のインターフェースを検討する際に役に立つ情報です。

・高信頼化を実現するためのアプローチや手法

→高品質なシステム開発をどのようにすれば実現できるのかのガイドライン情報が掲載されています。非機能要求グレードはユーザと要件を調整する際に使うと便利なため、社内にこのような情報がなければ、ダウンロードして自社用にカスタマイズすると良いです。

www.missiondrivenbrand.jp

政府CIOポータル

日本政府のIT活用についてのガバナンスが定義されているものです。定義内容等参考にできるものがあります。どういう観点でガバナンス構築しているか把握するのに役立ちます。徐々に全体の方でお勧めしているデジタル庁のページに情報が移管されていっています。

cio.go.jp

仕事で成長できる人に変わるビジネスマインドセット

仕事で成長している、成果を出している人はどんなマインドセットを持っているのかを知る事ができます。自身の成長にするために必要な事も知れますし、成果を出すメンバーを育成するために必要な観点を知る事もできます。こちらのサイトはブランディングについての情報も有益なので、ブランディングに興味がある方はブランディングの方もお勧めです。

課題・問題発見のフレームワーク～13の方法とツール

課題・問題発見方法と考え方について13個紹介しているサイトです。自身の仕事でも見えない課題を見つけたり、何から手を付けて解決したら良いのか整理したりにこのようなやり方を使います。やり方を知らないと、課題に押しつぶされてしまうので、課題解決能力は考え方(フレームワークと共に)徐々に身に付けていくのがお勧めです。

www.consultsourcing.jp

Qiita：新人の方によく展開している有益な情報

コーディングの読み方や質問の検索のやり方や思考法等についてのよい情報が纏められています。新人以外でも見直したら理解を深めたりするのに良いと思います。Qiitaはキーワードで検索してストック、LGTM順で見ると良い情報が結構あります。

IPA：刊行物のご案内

IPAが刊行している情報の一覧です。これまで紹介しているもの以外でも有益な情報がありますので、自身の知りたいものがあるか覗いてみると良いです。「用途別分類表」から探せばほしい情報があるか見つけやすいです。

IPA：報告書・成果物

IPAが研修した結果報告や成果物を見ることができます。DXの動向や進め方についての情報もあるため、どのように変革してきたかやこれから何を考え対応していく必要があるか等の情報を得るのにお勧めです。