RPAの開発に必要な『プログラミング的思考』とは何か、について解説します。
こんにちは。完全自動化研究所の小佐井です。早速ですがRPAの開発はプログラミングそのものです。RPAツールは「プログラミング言語」を使わなくていい「ローコードツール」がほとんどですが、「言語を書かなくていい」というだけで、「プログラミング的思考」は絶対に必要です。
それでは、どうぞ！
[追記]動画で観たい方は「プログラミング的思考を学ぼう｜RPAシナリオ設計入門Vol.3～5」へどうぞ！
RPA開発に必要なプログラミング的思考とは
2020 年度より小学校で「プログラミング教育」が全面実施されました。文部科学省によると、プログラミング的思考は以下のように定義されています。
図1のようなイメージです。四角やひし形で書かれた図形は「動きに対応した記号」を表しています。「ファイルを開く」とか「Excelを起動する」とかです。これらの「動きに対応した記号」を組み合わせて、実行すると何らかの動作をします。この動作が「意図する一連の活動」を成すようにするのがプログラミングです。
プログラミングとは「意図する一連の活動を実現するにはどうすればいいか？」という問題解決を行う思考方法と言えます。そのためには「動きに対応した記号」の知識や「記号の組み合わせ方」の知識が必要ですね。
これらを理解してプログラミングができるようになるために、「分解」「抽象化」「組み合わせ」「分析」の4つの要素にわけて解説します（図2）。
要素1：分解
分解とは小さな動きに分けること
大きくて複雑な「意図する一連の活動」を小さな「動き」に分けることが「分解」です。大きくて複雑な事象を、記号で表現できる小さな「動き」に分け、理解できるようにします（図3）。「記号で表現できる」というのが大事です。常に記号を使って考えられるようになるクセを付けましょう。
分解の具体例
例えば、「売上集計表.xlsxというExcelファイルを自分のパソコンのドキュメントフォルダーから、部署の共有フォルダーにコピーする。コピー時、ファイル名に日付を付け加える」という作業を自動化する、とします（図4）。
RPA初心者は「さぁ、シナリオを開発しよう」と思っても、何から手を付けたらいいのかわかりません。このため「そもそもシナリオを作れない」といった問題が起きます。「そもそもシナリオを作れない」といった問題については記事「RPA開発に失敗する典型的な5つのパターン」の「実務者がシナリオを作れない」をお読みください。
「実務者がシナリオを作れない」という問題を解決するためには、一連の動きを分解することから始めればいいでしょう。先ほどの作業を分解してみましょう。
- 自分のPCのドキュメントフォルダーをファイル管理ソフト（Windows の場合、エクスプローラー）で開く。
- 売上集計表.xlsxを見つける。
- クリップボードにコピーする。
- 部署の共有フォルダーをファイル管理ソフトで開く。
- 売上集計表.xlsxを貼り付ける。
- 貼り付けた売上集計表.xlsxの名前を「売上集計表_20200301.xlsx」に変更する。
- ファイル管理ソフトを閉じる。
7つのステップに分解しました。あとは、1つ1つのステップに対応するプログラム（コンピュータに対する命令）がわかれば、「意図する一連の動き」が達成されます。このように、小さな動きに分割したことにより、問題の解決が可能になったわけです。
要素2「抽象化」
抽象化とは本質を取り出すこと
プログラミング的思考の2つ目の要素は「抽象化」です。この概念はかなりわかりにくいので、最初は軽く頭に入れる程度でいいです。実際にプログラミングやRPAシナリオ作成を行っていく中で、この記事で解説している内容がわかってくると思います。
「抽象化」とは意図に応じて、本質的な情報だけを取り出し、他の部分は付属情報として切り分けることです。付属情報は切り分けるだけでなく、切り捨てることも行います（図5）。抽象化が進むと、本質的な情報だけになりますので、情報量は少なくなります。
抽象化の具体例
「分解」で使用したファイルをコピーする作業の例で、抽象化を行っていましょう。
この時点で「ファイル管理ソフトで開く（閉じる）」「クリップボードにコピーする」といった情報は切り捨てました。
もう一歩、抽象化していきましょう。
さらに本質的な情報だけを抜き出すと、「ファイルのコピー」と単純化されます。
このとき、「コピー元のファイル名（ドキュメントフォルダーの売上集計表.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つの組み合わせを使って、意図した活動を実現します。
プログラミング的思考の要素4「分析」
「分析」とは、プログラミングしたものがベストだったのか否かを考え、よりよくするにはどうすればよいかを考えることです。
RPAにおいては、たとえ動くシナリオが開発できたとしても、「より正確に動作し、失敗の少ないシナリオはできないだろうか？」「より早く動作するシナリオを開発するには？」「より読みやすくメンテナンスしやすいシナリオを書けないだろうか？」と見直して、改善していくことが必要です。
この分析を行わないため、いつまでもRPAの失敗が続いてしまうのです。
まとめ
この記事ではRPA開発を成功させるために絶対に必要な「プログラミング的思考」について解説しました。
もう一度、要点を確認します。
・プログラミング的思考とはコンピュータ・プログラミングの概念にもとづいた問題解決型の思考方法である
・この思考方法は「分解」「抽象化」「組み合わせ」「分析」の4つの要素からなる
すべてを一度に理解することは難しいです。プログラミングやRPAシナリオ作成を行っていくなかで、「プログラミング的思考」を意識してください。
そのうちに自然とプログラミング的思考が使えるようになります。
プログラミング的思考をRPA開発に活かすには
プログラミング的思考をRPA開発に活かすには、僕の著書「実務者のための失敗しないRPAシナリオ設計入門」を是非お読みください。
