みなさんは「プログラミング的所作」という言葉をご存じでしょうか？初めて聞いたという方も多いかもしれません。それもそのはず、この言葉は私が考えたものだからです。ネットで検索しても出てこないと思います。
しかし、私はこの「プログラミング的所作」を身に付けることこそが、これから IT を活用するために重要だと考えています。似たような言葉として「プログラミング的思考」が有名ですが、それよりもまずは「プログラミング的所作」が大事なのです。プログラマーだけが必要なのではなく、IT を活用する多くの人にとって所作が重要になっていくと考えています。
プログラミング的所作とは
さて、「プログラミング的所作」とはどのようなものでしょうか？それは、プログラマーがプログラミングを行う際に、当たり前のように行っている行動のことです。
プログラマーは、プログラミング言語を使ってコンピューターに指示を与えます。そして、その指示を実行し、実行結果を見てプログラムを修正したり見直したりします。プログラムを 0 から 100 まで一気に書き上げて、1 回で完璧に動くことはほとんどありません。場合によっては、1 行や数文字を書き換えるだけで実行し、その結果を確認することもあります。プログラミングの作業とは、このようなものです。
これこそが、私が「プログラミング的所作」として考えているものです。指示を与え、実行し、結果を観察し、また指示を調整して実行する。コンピューターと人との間で、このようなフィードバックループを回す“行動”や“振る舞い”です。
なぜプログラミング的所作を身に付ける必要があるのか
一見すると簡単そうに思える「プログラミング的所作」ですが、意外とこれができない人は多くいます。これを考えるきっかけとなったのは、私が 2023 年に執筆した書籍「Power Automate ではじめる業務の完全自動化（できるエキスパート）」の作成中に、そのコンセプトを考えていたときでした。それまでも、何人かの人に Power Automate を用いたフロー作成を教える機会がありましたが、やはり上手くできる人と苦労する人がいます。なぜ苦労するのか、それぞれの行動を思い返してみると、苦労している人にはとある特徴があることに気がつきました。それは、「ずっとフローの編集画面ばかりを見ている」ことです。そしてなかなか実行しない。実行したとしても、動作が失敗したらまたすぐに編集画面に戻ってしまいます。
一方で、フロー作成が上手くできる人は、何度も実行し、実行結果の画面をきちんと観察しています。
こうした業務で用いるフローなどでは、非常に複雑で高度なロジックが求められることは稀です。それよりも、実行結果を観察し、失敗の理由を考え修正する作業のほうが圧倒的に多くあります。そのために必要なものが、「プログラミング的所作」なのではないかと考えました。
生成 AI の活用でもプログラミング的所作が大事になった
ここ数年、生成 AI の活用が話題になっています。生成 AI についても、上手く使える人と苦労する人が出てきます。その違いもやはり、「プログラミング的所作」を身に付けられているかどうかではないかと思っています。生成 AI の活用も、実はプログラミングの作業と似ています。生成 AI に対して何か指示を与え、生成 AI がそれに対して結果を返してきます。私たちはその結果を見て、意図と異なるところがあれば指示を変えてもう一度生成 AI に問いかけます。これを繰り返すことによって、生成 AI を活用するための良い指示を作っていくのです。
他の IT 活用においても、このような所作が必要とされる場面は非常に多いのではないかと考えています。
教本や勉強会、セミナーで学ぶときの注意点
この「プログラミング的所作」を学べる機会は、実はそれほど多くないかもしれません。教本や勉強会、セミナーなどで紹介される手順は、どれも正解を知っている状態で行われることが多く、一から正解にたどり着く手順ではないことがほとんどだからです。多くの場合、紙面上や時間の都合もあり、正解にたどり着くための試行錯誤が省略されてしまっているのです。
例えば、Power Automate のフローを作成する手順を学ぶ場合でも、すでにフローの完成形を知っている状態で作成する手順と、完成形が分からず試行錯誤しながら作成する手順とではまるで違います。そして、本当に学ぶべきは、完成形が分からない状態で試行錯誤して作成する手順です。
生成 AI の活用においても同様です。誰かが作った完成形のプロンプトを教えてもらうことはできても、そのプロンプトを自分で試行錯誤して作成できなければ、活用の幅が広がりません。
その試行錯誤の第一歩として、「プログラミング的所作」を頭に置き、自分で何度も意識的に試すことを繰り返す必要があります。もしも人に教える機会がある場合も、「プログラミング的所作」を見てもらうことを意識すると良いのではないでしょうか。
特に教える側においては、「プログラミング的所作」は、作ったものが上手く動かなかったり、それに対してあれこれ試行錯誤したりと、決してカッコいい姿ではありません。しかし、それを他の人にも見てもらい、試行錯誤の過程を共有するということが非常に大事です。
PDCA サイクルと違うの？OODA ループに近い？
記事公開後に複数の方から「PDCA サイクル」と違うの？という意見も頂きました。たしかに全体の流れとしては似ていますよね。ただ、私がこの「プログラミング的所作」で重視している点は、「観察」と「調整」にあります。「観察」や「調整」を行うために、「指示」や「実行」があります。どれだけ「指示」を考えても、それを「実行」しなければ先には進めません。「観察」や「調整」が重要なのだから、初期の「指示」や「実行」はもっと簡単で気軽に行うべきだろうと考えています。
個人的な印象として、プログラミング的思考では、「指示」を作る際に発揮する能力をイメージする人が多いようにも感じていました。しかしそうではなく、所作全体を捉えた場合の「観察」と「調整」の部分にこそ、プログラミング的思考、または、論理的な思考力を発揮すべき場面ではないかと考えています。
また、この「プログラミング的所作」という考え方は、「OODA ループ」に近いのではないかとの意見も頂きました。OODA ループとは観察（Observe）- 情勢への適応（Orient）- 意思決定（Decide）- 行動（Act）からなるもので、意思決定の理論などを理論化したもののようです。
まずは「観察」するということに重きを置くという点では、たしかに「プログラミング的所作」に近いですね。「プログラミング的所作」では、「観察」のために最初の「実行」が必要になるという感じでしょうか。
まとめ
今回は私が考える「プログラミング的所作」について、少しとりとめもなく書いてみました。この「プログラミング的所作」は、これからの IT を活用するためのスキルのひとつであり、身に付けておくことは何か特定のツールの使い方を覚えるよりも、長期に渡って自分を助けてくれるものになると思います。
もしもこの「プログラミング的所作」という考え方に共感いただける方がいましたら、ぜひ「いいね
」をお願いします！