こんにちは。完全自動化研究所の小佐井です。

RPAの開発はプログラミングそのものです。

めーたん
めーたん
えっ!RPAってプログラミングしなくていいんじゃないの?
「プログラミング言語」を書かなくていいけど
プログラミングの知識は必要なんだよ。
こさい
こさい

RPAツールは「プログラミング言語」を使わなくていい「ローコードツール」だと思っている方はいきなりで「ぎょっ」としたかもしれませんね。

たしかにUiPathやPower Automate for desktopなどのRPAツールは「プログラミング言語」を必要としません。

しかし、プログラミングの考え方である「プログラミング的思考」は絶対に必要です。

この「プログラミング的思考」を知っているかどうかで、RPA開発が成功するか失敗するかが決まるといっていいくらいです。

この記事に出会ったのを機会に、是非「プログラミング的思考」を知ってください。

それでは、どうぞ!

RPA開発に必要なプログラミング的思考とは

2020 年度より小学校で「プログラミング教育」が全面実施されます。文部科学省によると、プログラミング的思考は以下のように定義されています。

自分が意図する一連の活動を実現するために、どのような動きの組み合わせが必要であり、一つ一つの動きに対応した記号をどのように組み合わせたらいいのか、記号の組み合わせをどのように改善していけば、より意図した活動に近づくのか、といったことを論理的に考えていく力

図1のようなイメージでだいたい大丈夫です。

図1:プログラミング的思考のイメージ

めーたん
めーたん
なんとなくプログラミングのイメージはこんな感じね

「プログラミング的思考」とはコンピュータ・プログラミングの概念にもとづいた問題解決型の思考方法と言えます。

めーたん
めーたん
ちょっとなに言ってるかわからない
もう少し読めばわかってくるかも
がんばれ!
こさい
こさい

「プログラミング的思考」をより簡単に理解するために、「分解」「抽象化」「組み合わせ」「分析」の4つの要素にわけて解説します(図2)。

図2:プログラミング的思考の4つの要素

プログラミング的思考の要素1「分解」

分解とはなにか

プログラミング的思考の定義をもとに説明すると、大きくて複雑な「意図する一連の活動」を小さな「動き」に分けることが「分解」です。

大きくて複雑な事象を、記号で表現できる小さな「動き」に分け、理解できるようにします(図3)。

図3:「分解」のイメージ

めーたん
めーたん
細かくわけるのね。これはわかる!

分解の具体例

例えば、「売上集計表.xlsxというExcelファイルを自分のパソコンのドキュメントフォルダーから、部署の共有フォルダーにコピーする。コピー時、ファイル名に日付を付け加える」という作業を自動化する、とします(図4)。

図4:作業のイメージ

RPA初心者は「さぁ、シナリオを開発しよう」と思っても、何から手を付けたらいいのかわかりません。このため「そもそもシナリオを作れない」といった問題が起きます。

「そもそもシナリオを作れない」といった問題については次の記事の「実務者がシナリオを作れない」をお読みください。

プログラミング的思考では、一連の動きを分解することから始めます。先ほどの作業を分解してみましょう。

1. 自分のPCのドキュメントフォルダーをファイル管理ソフト(Windows の場合、エクスプローラー)で開く。

2. 売上集計表.xlsxを見つける。

3. クリップボードにコピーする。

4. 部署の共有フォルダーをファイル管理ソフトで開く。

5. 売上集計表.xlsxを貼り付ける。

6. 貼り付けた売上集計表.xlsxの名前を「売上集計表_20200301.xlsx」に変更する。

7. ファイル管理ソフトを閉じる。

7つのステップに分解しました。あとは、1つ1つのステップに対応するプログラム(コンピュータに対する命令)がわかれば、「意図する一連の動き」が達成されます。

このように、小さな動きに分割したことにより、問題の解決が可能になったわけです。

めーたん
めーたん
日常的に行っている作業を箇条書きにしたってわけね

プログラミング的思考の要素2「抽象化」

抽象化とはなにか

プログラミング的思考の2つ目の要素は「抽象化」です。

この概念はかなりわかりにくいので、最初は軽く頭に入れる程度でいいです。実際にプログラミングやRPAシナリオ作成を行っていく中で、この記事で解説している内容がわかってくると思います。

「抽象化」とは意図に応じて、本質的な情報だけを取り出し、他の部分は付属情報として切り分けることです。

付属情報は切り分けるだけでなく、切り捨てることも行います(図5)。

抽象化が進むと、本質的な情報だけになりますので、情報量は少なくなります。

図5:「抽象化」のイメージ

めーたん
めーたん
急に難しくなったような。。
具体例をみてみたら、理解しやすいかもよ
こさい
こさい


抽象化の具体例

「分解」で使用したファイルをコピーする作業の例で、抽象化を行っていましょう。

ドキュメントフォルダーの売上集計表.xlsxを共有フォルダーにコピーする。コピー先のファイル名は売上集計表_20200301.xlsxとする

この時点で「ファイル管理ソフトで開く(閉じる)」「クリップボードにコピーする」といった情報は切り捨てました。

もう一歩、抽象化していきましょう。

ドキュメントフォルダーの売上集計表.xlsxを共有フォルダーの売上集計表_20200301.xlsxにコピーする

さらに本質的な情報だけを抜き出すと、「ファイルのコピー」と単純化されます。

このとき、「コピー元のファイル名(ドキュメントフォルダーの売上集計表.xlsx)」と「コピー先のファイル名(共有フォルダーの売上集計表_20200301.xlsx)」は、付属情報になります(図6)。

図6:ファイルをコピーする作業の抽象化

「ファイルのコピー」「コピー元のファイル名」「コピー先のファイル名」という3つの情報だけあれば、一連の作業は表現できる、ということです。

情報がかなりそぎ落とされて、シンプルに表現できるようになりました。

めーたん
めーたん
ようするに、簡潔にするってわけね!
ええ。本質的な部分だけに絞り込むイメージですね。
こさい
こさい


抽象化のメリット

「なぜわざわざ抽象化を行うか?」

それは大きなメリットがあるからです。

そのメリットについて解説します。

抽象化された一連の動きは、「部品」として捉えることができます。部品化によって、様々なメリットが生じます。

抽象化のメリット1:再利用性の向上

部品は機械や器具の一部となるもので、他の部品と連携しますが、部品自体が独立した機能を持っています。

独立しているため、現在の接続されている機械だけに依存せず、他の機械にも接続できます。

例えば、自動車では部品の共通化が行われ、複数の車種で同じ部品が使われています。

プログラミング的思考でも同様に考えます。

前出の「ファイルのコピー」という作業を再び例にとって解説します。

「売上集計表.xlsxというExcelファイルを自分のパソコンのドキュメントフォルダーから、部署の共有フォルダーにコピーする。コピー時、ファイル名に日付を付け加える」という作業を「ファイルのコピー」に抽象化し、部品化したことにより、元の動きから独立して再利用できるようになっています(図7)。

図7:「ファイルのコピー」が再利用可能になっている

部品化し、再利用性を向上させることにより、何度も同じ動きをプログラミングする必要はなくなり、開発効率が向上します。

めーたん
めーたん
再利用できるのは「エコ」ですね

抽象化のメリット2:例外への対応

部品化することにより、「例外」にも強くなります。例外とは通常実行時とは異なる事象が発生することです。

例外については次の記事の「シナリオがすぐに止まる」をお読みください。

なぜ例外に強くなるかというと、部品は単体で試験(テスト)できるからです。

自動車の部品は、それぞれ独立してテストされています。エンジンは車体に据え付けなくても、エンジン自体でテストできます。

プログラミングも同じです。

前出の「ファイルのコピー」の例で考えてみましょう。この部品も単体でテストすることができます。

テストの中で、例外が発生した場合の対応について解説します。

「コピー先のファイル名」のファイルがすでに存在するとき、「コピーしようとしたら、その場所にすでに同じ名前のファイルがある」ということで、例外が発生する可能性があります。

この場合、「ファイルのコピー」内に、コピー先のファイルが存在する場合の対処方法を組み込むことで、例外は発生しなくなります。部品内で例外を吸収することで、例外に強くなった、という例です(図8)。

図8:例外を吸収する

今度は「ファイルのコピー」という部品内で例外を吸収できないパターンについて解説します。

「ファイルのコピー」の付属情報「コピー元のファイル名」のファイルが存在しなかった場合(図9❶)、必ず例外が発生します。このような場合に備え、「ファイルのコピー」という部品が、存在しないファイル名が渡されたことを検知し(図9❷)、呼び出し元にエラーを返す設計にしておきます(図9❸)。

図9:呼び出し元にエラーを返す

「ファイルのコピー」が結果としてエラーを返してきた場合は適切に対応する設計をすることで、「予期しないエラー」が発生して、システムが完全にシャットダウンしてしまうことを防げます

このように、部品化することにより、例外の影響を小さな範囲に限定し、どこで例外が発生したのか明確化できるため、多くの部品を組み合わせて大きなシステムを構築することが可能になります。

めーたん
めーたん
けっこう難しいわね
大事なんで何度か読み返してくださいね
こさい
こさい


抽象化のメリット3:変化への対応

本質情報と付属情報を分割したことにより、変化に強くなっています。

「ファイルのコピー」の例で言えば、ファイル名やファイルの保存パスが変更になっても、付属情報を変更するだけです。「ファイルのコピー」本体を改修する必要はありません(図10)。

図10:付属情報を変更するだけ

さらに、付属情報はソフトウェアシステムと切り離して、外部のファイル(例えば、Excelファイルなど)に格納しておけば、メンテナンスが楽になります。

付属情報に変更があった場合は、Excelファイルを修正するだけでよく、プログラムを修正する必要はないからです。

プログラミング的思考の要素3「組み合わせ」

「記号の組み合わせをどのように改善していけば、より意図した活動に近づくのか、といったことを論理的に考えていく力」がプログラミング的思考ですので、要となるのが「組み合わせ」です。

組み合わせには「順次」、「条件分岐」、「反復」があります(図11)。

図11:組み合わせの種類

「順次」は順番に動きを実行することです。「条件分岐」は条件によって、行う動きを変更します。「反復」は条件を満たすまで、一連の動きを繰り返し実行します。

この3つの組み合わせを使って、意図した活動を実現します。

こさい
こさい
組み合わせはたった3つしかないんです!

プログラミング的思考の要素4「分析」

「分析」とは、プログラミングしたものがベストだったのか否かを考え、よりよくするにはどうすればよいかを考えることです。

RPAにおいては、たとえ動くシナリオが開発できたとしても、「より正確に動作し、失敗の少ないシナリオはできないだろうか?」「より早く動作するシナリオを開発するには?」「より読みやすくメンテナンスしやすいシナリオを書けないだろうか?」と見直して、改善していくことが必要です。

この分析を行わないため、いつまでもRPAの失敗が続いてしまうのです。

めーたん
めーたん
作りっぱなしじゃダメってことね
探求心が大事ですね
こさい
こさい


まとめ

この記事ではRPA開発を成功させるために絶対に必要な「プログラミング的思考」について解説しました。

もう一度、要点を確認します。

・プログラミング的思考とはコンピュータ・プログラミングの概念にもとづいた問題解決型の思考方法である

・この思考方法は「分解」「抽象化」「組み合わせ」「分析」の4つの要素からなる

すべてを一度に理解することは難しいです。プログラミングやRPAシナリオ作成を行っていくなかで、「プログラミング的思考」を意識してください。

そのうちに自然とプログラミング的思考が使えるようになります。

プログラミング的思考をRPA開発に活かすには

プログラミング的思考をRPA開発に活かすには、僕の著書「実務者のための失敗しないRPAシナリオ設計入門」を是非お読みください。

お問い合わせ

「こういう問題も深堀してほしい」「ここ間違ってるんじゃない?」「ここわかりにくい」という場合は、こちらからお気軽にお問い合わせください。

Twitterもやっていますので、そちらからアクセスいただいても構いません。

関連する記事

RPA開発に失敗するパターンを知りたいという方は次の記事をお読みください。

RPA自体の知識を深めたいという方は次の記事をお読みください。

「RPAツール」の知識を深めたいという方は次の記事をお読みください。