3.6.1 recognitionとrecallと (非公式訳)

pp.61-62

3.6.1 「見てそれだと分かる」と「意識的に思い出す」と

「見てそれだと分かる(recognition)」と「意識的に思い出す(recall)」はどちらも、記憶から情報を取り出すことですが、両者はメカニズムが異なります。「見てそれだと分かる」は、自身の五感(判断力や常識)の助けを借りてコト・モノを思い出すことです。ヒトの脳はそれが大変に得意であり、ほとんど頭を使う必要がありません。「意識的に思い出す」は、そうした外部の情報の助けを借りずに何かを思い出すことです。「意識的に思い出す」は「見てそれだと分かる」に比べてずっと難しく、ヒトの脳はそれが大変に苦手です。

“「見てそれだと分かる」は「意識的に思い出す」よりも簡単だ”という事実は、ユーザーインターフェイスの設計で特によく使われるヒューリスティック評価の1つです。だからこそ、一般にグラフィカルメニューのほうがコマンドラインインターフェイスよりも使うのが簡単なのです。だからこそ、記述式問題よりも選択式問題のほうが簡単なのです。だからこそ、人の顔は簡単に覚えられるのに人の名前はなかなか覚えられないのです。 何かを使いやすくしたいなら、「見てそれだと分かる」を「意識的に思い出す」よりも重視した設計をしなければなりません。設計理論においてこの2つはしばしば、「広く流布している情報」「頭のなかにある情報」と呼ばれます。何か作業をするときに記憶への負担を極力軽くしたいなら、できる限り多くの情報を「広く流布」させなければならず、同時に、記憶から取り出す情報を減らさなければなりません。

「見てそれだと分かる」が「意識的に思い出す」よりもはるかに容易であるという事実は、プログラミングに直接関係します。たとえば、エンコーディング(001がADD命令、010がXOR命令など)を覚えざるを得ないプログラムを扱うときは毎回、記憶力と注意力の一部が、つまらないデコードの作業に充てられ、その結果、プログラムを本当に理解するための処理能力が削られます。実はこれが、必要以上にプログラミングを難しくしている格好の例なのです。原則として、このようなエンコーディングマッピング、関連づけは、コードのなかに明確に示すことが望ましく、そうすれば記憶のなかから意識的に思い出す必要がなくなります。この方法であれば、何か値を参照する必要のある場合に、あいまいなリテラル数を参照する代わりに意味のある名前を通じてその値が参照できます。

同じことは、名前を選択するときにも通用します。メモリーの1ワードのビット数をwで表し、入力の平方根をyで表すのでも、場合によっては十分簡単です。しかしヒトの情報処理能力には厳しい限界があり、コードの読者にそのような負担を強いるのは能力の無駄遣いです。num_bits_per_wordやsquare_rootのような、意味の通じる名前を使えば、本当に必要なところに頭を使うことができます。

ここで述べたことは逆向きにも適用できます。すなわち、記憶力をほとんど必要とせずに頭も使う必要のないコードを書けば、それだけコードの読者の、さらにはコード作成者自身の情報処理能力が増すということです。

並列(parallel)と並行(concurrent)と

/カンレントゥ/
日経ソフトウエア 2021年1月号 [雑誌], pp.114-115

  • 並列(parallel)は、同時に複数の処理を行うこと。コンビニの複数のレジにそれぞれの列ができていて、同時に複数の客をさばくようなもの。同時に複数の処理を実行して、全体の処理時間を短くする。

  • 並行(concurrent)は、1人の店員が同時に複数の客を受け持つこと。1人の店員の担当する全作業量は変わらないので、全体として処理が速くなるわけではない。複数の処理を受け持って、同時に実行しているように見せかけるけれど、全体では速くならない。