シアトルで実践する「プログラミング的思考」[2] 〜アルゴリズムを考える（２）いろんな名前がある

いろんな名前で登場するアルゴリズム

アルゴリズムを「ある目的を解決するためのステップの組み合わせ」だと考えた時、ソフトウェア開発の様々な状況で、アルゴリズムは異なる名称でもって登場します。そのどの場合でも、原則的に目的とその性質はおおよそ同じだと考えられます。その中から、いくつか紹介したいと思います。

プロセス

「プロセス」という言葉があります。これは抽象的な「手順・手続き・処理」などを指します。プロセスはアルゴリズムと同様に、ある一連の手順の流れを指しており、アルゴリズムの別名と考えて良いでしょう。また、プログラムの「実行」を指してプロセスと呼ぶこともあります。

ただし、この言葉が表すものは必ずしもコンピュータを使って行う手続きだけとは限りません。日本で「プロセスチーズ」と呼ばれる食品の分類がありますが、英語では processed cheese と書きます。「プロセスされたチーズ」という意味です。なんらかの処理をされたチーズという意味です。

プロセスはどちらかというと粒が大きめで、コンピュータだけでなく人に参加するような、完了するのにある程度の時間を要する手順を指すことが多いです。

関数

「関数」もアルゴリズムと深い関わりがある言葉です。コンピュータの世界でいう関数とは、入力を受け取り、何らかの処理を入力に対して行い、その結果を出力する「名前の付いたアルゴリズムの実装」のことです。関数の中身が、あるアルゴリズムを記号を用いて記述されており、その関数が実行すると、アルゴリズムに従って、処理がコンピュータによって実行されるのです。

ところでプログラムも、粒の大きな関数として捉えることも出来ます。実際、あるプログラムが別のプログラムを呼び出したりすることは一般的です。同様に、関数も別の関数を呼び出して処理の一部を委託するので、その点がよく似ています。

プロシージャ、ルーティン、スクリプトなど

これらの用語が示すものも、アルゴリズムの実装です。なんらかのステップの組み合わせが記号を使って表記されていて、再利用できるパッケージの形で保存されているのです。プロシージャは「手続き」というニュアンスが強く、入力と出力という概念がはっきりしている関数に比べて、ややカジュアルな定義だという印象を個人的には持っています。ルーティンは少し古い言い方で、何度も繰り返し実行する決まり事(routine)という言葉から来ています。

スクリプトという言葉もソフトウェア開発の現場でよく出てきます。スクリィプティング言語というものもあり、プログラミング言語の一種ですが、やや柔軟にコーディング出来るものを指すという印象があります。JavaScriptという有名なプログラミング言語がありますが、これもスクリプトの特徴を持っているのでそう名付けられたのでしょう。これもアルゴリズムを実装するという点では同じです。

ここまでアルゴリズムと本質的に同じだけれど、別の名前とニュアンスをもつものをいくつか紹介しました。「プログラミング的思考」を理解するという目的に置いては、これらすべてを理解する必要はありません。ソフトウェア開発の現場では様々な呼び名でアルゴリズムが実装されているという理解で十分でしょう。

プロセスをモデル化する

ある問題を解決する時、それ全体を「プロセス」と呼ばれる単位で表すことがあります。ひとつのプロセスは、いくつかのステップの組み合わせで構成されます。アルゴリズムと同じですね。

ソフトウェア開発ではプロセスをステップに「分解」して考える力が重要になります。この思考を「プロセスモデリング（プロセスのモデル化）」と呼びます。プロセスモデリングとはいくつかの具体的な事例を元に、手順を整理しフォーミュラとしてモデル化し、それをもとに同じ種類の問題を何度でも解決できるようにすることです。そうやってモデル化されたステップの記述がアルゴリズムなのです。

ソフトウェアエンジニアは、プロセスを分析し、いくつかの部分に分解する際に、コンピュータシステムを利用した自動化の可能性を最大化しようとします。この際、コンピュータの基本的な理解が必要になります。現場で使われる「プログラミング的思考」には、コンピューターサイエンスの知識が必要になるのです。

プロセスダイアグラム

ソフトウェアエンジニアは、あるプロセスをモデル化するとき、頭の中や紙に「図を描く」ことがあります。人によってスタイルは様々でしょうが、長方形などの箱をいくつかと、それらを結ぶ矢印線などを使って表すのが一般的です。

長方形は「ステップ」もしくは「タスク」などと呼ばれ、独立したひとつの「動作」や「作業」を表します。「AをBする」というような一文で表せる動作のことです。矢印線を使うのは、矢印の向きでステップ間の順序を表すためです。ある動作のあとに起こるべき動作を矢印線が示すのです。見た目の好みという点で、長方形の替わりに丸や楕円を選んで使う人もいるでしょう。

長方形以外にも「選択」を表すために菱形を使うこともあります。このような図のことをプロセスダイヤグラムや、フローチャートなどと呼びます。ステップの組み合わせを可視化するテクニックのひとつです。

こういったプロセスを表す図の利用はソフトウェア開発だけに限りません。私たちの身の回りでもよく見かけるものです。新しく買ったテレビに「初期設定の手順を表す図」が付いていたり、役所で何かの手続きをする際「大まかな流れを解説してある図」を受け取ったりしたことがあるでしょう。そういったものも、プロセスを表す図です。ただソフトウェア開発においては、プロセスダイアグラムなどを作成することで、それを設計図にして、スムーズにコードとして記述することが出来るようになります。

疑似コード

プロセスダイアグラムなどの「図」の代わりに「言葉」を使ってプロセスのステップの流れを表す方法を好む人もいます。これも、料理のレシピなどでよく見られる方法ですね。アルゴリズムを表す場合は「疑似コード」と呼ばれることもあります。

この場合ステップの動作を表す疑似コード文は、どの特定のコンピュータにも依存していない、けれども人が読んで理解出来て、なおかつコンピュータへの処理命令のニュアンスを含む、抽象的な文を使って表します。いずれにしても、モデル化されたプロセスをステップの組み合わせとして表し、記号を使って表記(コーディング)の作業にスムーズに移行できるように工夫しているのです。

プロセスダイアグラムも疑似コードも、あくまでもコミュニケーションのツールであって、重要なのは、いかにアルゴリズムを分かりやすく表せるかです。ここでは、コーディングやプログラミング言語の知識は必要ありません。むしろ、論理的に考える力や高い国語力が必要になります。

What を定義して抽象化する

プロセスをモデル化する際にまず考えなくてはならないのが、プロセスの目的や機能を表す「プロセス名」を決めるとことです。同時に、プロセスの開始時に与えられる「入力」と、プロセスの終了時に利用できるようになる「出力」について明確に定義することも重要です。その３つを定義することで、今までに存在しなかった「抽象化された処理」が生まれるのです。

プロセスの名前はそれが何（what）を達成できるか、見てすぐに分かるような言葉が選ばれます。一方、プロセスの本体である「ステップの組み合わせ」は手順であり方法であり「どうやって（ How）」 に相当します。入力もプロセスに何を渡すかを定義し、同様に出力はプロセスが何を結果として返すかを決めます。全て what です。How は見えません。これが抽象化を実現しています。

プロセスを利用する外部主体、例えばユーザや他のソフトウェアは、プロセスの名前とその入力・出力についてだけを知っていればそのプロセスを利用できます。How の部分は見えなくてもそのプロセスの恩恵を受けられるのです。こうすることでプロセスは抽象化され、アルゴリズムの内部ディテールはパッケージの中に見えないように隠してしまいます。パッケージ化されたプロセスは扱いやくなるので再利用の機会が増えることになります。

How をアルゴリズムとして実装する

次に、プロセスの中身であるアルゴリズム、つまり 「どうやって（how）」 の部分がどのように定義されるのかを見ていきましょう。

アルゴリズムは「複数のステップの組み合わせ」なので、いくつかのステップに分解され、なんらかの規則に従う組み合わせとして配置されます。それぞれのステップは「AをBする」といった1つの動作（アクション）として表されます。

プロセスに入力と出力があるように、一つ一つのステップでも入力と出力をあります。通常、あるステップは次のステップに自分の処理結果を引き渡していきます。これが一連の処理となり、あるステップの出力が次のステップの入力になり、次のステップの出力がさらに後に続くステップの入力になる、といった具合で繋がるのです。

このようにステップをブロックのように組み合わせるのですが、組み合わせ方にもいくつかあり、それらを「制御構造（制御文）」と呼びます。次の記事で詳しく見ていきます。