20世紀の中頃、計算をする機械の開発に成功した人類は、それまで人間の働きで行っていた仕事の一部を、その計算をする機械にやらせるようになりました。それまでの人間の作業を、計算をする機械で置き換えることによって、作業にかかる時間を大幅に短くすることができました。また、人間が作業する場合には、どうしても「間違い」が入り込むのですが、その間違いの発生は、それまでとは比較にならないほど、少なくすることができるようになりました。そのような作業時間の短縮と、誤りの発生の減少の効果に加えて、数多くの作業者が必要なくなり、企業の経営などでは、人件費を大きく減らすことができるようになり、計算する機械の導入は、人類社会の様々な場面で進みました。

計算する機械の導入が進むと、計算する機械を導入するために必要となる、計算の仕方を機械に指示するプログラムを作成しなければならないため、ブログラムを作成する人々を社会が必要とするようになりました。人間社会では、そのような人々を「プログラマ」と呼ぶようになりました。プログラマ人材を数多く養成し、社会で活用できるようにするため、アメリカ社会では、大学の教育課程に「コンピュータ科学」と名付けられた専門が作られました。その「コンピュータ科学」の専門コースでは、コンピュータの利用者から、どのような目的でコンピュータを利用したいのかを聴き、その目的によく合った一連のプログラムを、失敗なしに作り上げるための技術や技能の教育が行われるようになりました。

ソフトウェアの開発に当たる技術者は、まず、どのような「道具」を作らなければならないのかを、利用者から聞き出して、文書にまとめます。その文書を「要求仕様書」と言います。要求仕様書がまとめられると、技術者達は、それをどのようなプログラムの組合せで作り上げるかを考え、皆で議論して、プログラムの機能仕様書と呼ばれる書きものにまとめます。機能仕様者ができ上がると、そこに書かれている一つ一つの機能をどのような計算で行わせるかを考えます。その結果は、プログラム仕様書とか、設計書と呼ばれる書きものになります。このような手順を踏んで、準備が終わると、最後に、その設計に基づいて、プログラム言語を使って、プログラムが書かれます。書かれたプログラムは、技術者達によって、自分達の考えた通りにコンピュータが動くことが確認されます。これを「テスト」とか「試験」と呼んでいます。

このような手順を踏んで、数多くの技術者達が参加して作られる「ソフトウェア」と呼ばれる、数多くのプログラムの塊(かたまり)は、一つ一つのプログラムの動きが、技術者達の思い通りに連動して働かなければ、利用者達が技術者達に伝えた通りの「道具」を作り上げることはできません。このようなことから、開発に関わる技術者の数が増えれば増えるほど、作られたソフトウェアが、利用者の「道具」として思い通りの働きをするかどうかが、分からなくなります。思い通りの働きをしなければ、技術者達は、利用者達の意見を聴きながら、プログラムに変更を加えて、なるべく利用者の思い通りに動くように直す努力をします。この手直しの手間は、最初にソフトウェアを作り上げた時の手間よりも、大きくなることが「しばしば」あります。

コンピュータの大量生産ができるようになって、数多くの小型のコンビュータが社会の様々な場面で利用されるようになると、それらのコンピュータを利用する組織の要求に合わせた仕事をさせるためのプログラムを、利用する組織それぞれの目的と要求に合わせて、作成する人々が必要になりました。初期には、そのような人々は、組織の人々が思うようにコンピュータを動かすため、その細かな計算の仕方を指示する特別な言葉を学んだ人々でした。そのような「コンピュータ言語」と呼ばれる言葉を、学校や企業の教育などで学び、その知識を使ってプログラムの作成作業に当たりました。当時のプログラムを作成する人々の役目は、コンピュータを購入した組織で、コンピュータの活用を考えている人々から、どのような事務処理を行うプログラムを作成すべきかを聴き、それに基づいてプログラムを作ることでした。

どのようなプログラムが必要であるかを説明する、コンピュータを活用したいと考えている組織やその組織で働く人々のことを、「ユーザ」と呼びます。プログラムを作成するためには、プログラムの作成担当者は、ユーザが説明する「こんなことを、コンピュータを使ってやりたい」と思う内容を細かく聞かなければなりません。ユーザは、それまで事務員がやっていた作業を、プログラム作成担当者が分かるように説明します。この説明は、たとえ簡単な給与の計算であっても、そのプログラムとコンピュータを使って、給与計算を行うそれぞれのユーザ企業によって、少しずつ違ってきます。それは、給与の計算の仕方が、企業によって少しずつ違うからです。人間である事務員の場合、それらの「決まりごと」を、それが必要になった時、その場その場で聴いて行えば済むことなのですが、コンピュータで自動的に計算するためには、最初から、「こんな場合は、このように計算する」と言うように、全てを細かく説明してもらい、それに従ってプログラムを書かなければなりません。

コンピュータの利用を考えているユーザ企業や組織では、そのような細かな規則は、そのような規則が必要になった時に、その場で決めてきている場合が多く、そのような規則を整理して、最初から筋道をたてて書いてあるわけではありません。そのような、人間社会の柔らかな決まりごとによって、人間の組織は運営されてきていました。しかし、それをコンピュータで処理しようとすると、それらの規則を最初から最後まで、全て言葉で表し、明確に書かなければなりません。このように、人間社会の規則を言葉にして書いてゆくと、ある一つの条件が成り立っている時、それに対する処理が二つ以上、決められている場合があります。それは、もともと、規則を当てはめる人についての細かな条件が違っていたりしているために、違う規則ができていることが多いのです。しかし、それをコンピュータが理解できる言葉で書こうとすると、同じ条件に対して、違った計算をしなくてはならなくなります。それは、機械にはできません。

例えば、ほとんどの社員については、1日8時間以上働くと、その8時間を超えた時間については、残業代の支払いが必要になります。この規則を当てはめると、その会社の課長、部長、社長さんに対しても同じ残業代の計算が必要になります。しかし、多くの会社では、課長以上の地位にある社員や、常務、専務、副社長や社長などの経営者に対しては、残業代を払いません。このことを、コンピュータで計算しようとすると、どのような人の給与を計算しているのかを調べて、その人には残業代を計算しなければならないのかどうかを調べ、必要であれば残業代を計算する方法を使って、残業代を決めなければなりません。このような決まりごとは、プログラムを作成する時に前もって、知っておかなければならないのです。さらに、もっと細かな決まりごとが数多く決められていることが多いのです。プログラムを作る人は、それらのことをしっかりと聞き出してから、プログラムに必要な計算を考えなければならないのです。

さらにもっと難しいことは、そのような現在の組織に決められている様々な規則を調べても、人間社会の場合、その規則はいつまでもそのままであるとは限りません。例えば、社会全体に影響を与える法律が変われば、給与を計算する規則も変わるかも知れません。例えば、「管理職に対しては残業代を支払わなくても良い」と言う法律が変わり、「課長相当の管理職に対しても、1か月当り20時間を超えた場合、残業代を支払わなければならない」とされるようになるかも知れません。そうなった場合、せっかく作成したプログラムを作り直さなければならなくなるかも知れません。一度作ってしまったプログラムは、変えなければならない部分と、変えてはならない部分の「つじつま」を合わせて、それをうまく変えることは簡単ではありません。プログラムを変えたことによって、以前は正しく動いていたプログラムでも、変え方が悪いと、正しく動かなくなることがあるからです。つまり、プログラムを作成する人は、そのようなことも前もって考え、プログラムを変えたとき、別の問題が起こらないようにする工夫をしておく必要があるのです。

つまり、プログラムを作成する人々は、人間社会では、「何が、時間とともに変わるかも知れないのか」、「何が、時間がたっても変わらないのか」をよく考えて、プログラムを考えなければなりません。このようなことは、コンピュータの利用が普及し始めた1960年代の初め頃には分かっていませんでした。似たような問題で、1960年から1975年ごろまでに作られたプログラムでは、日付を表すのに、1900年代を現わす1900の最初の2桁("19")を省いて、下2桁の00だけを書く、6桁の数字だけで表すやり方を使っていました。これは、当時の米国社会では書類の日付を書くのに、1971年6月23日ならば、062371と書き表す方法が使われていたからです。4桁の年号を2桁の数字で書くことで、書く手間を省くことができるからです。プログラムを作る人々も、その社会で普通とされていた方法に従っただけなのです。

しかし、それから30年もしないうちに、このやり方が米国の社会全体の不安を巻き起こしました。それは、2000年になると、1月1日は、010100となり、1900年1月1日なのか、2000年の1月1日なのかが分からなくなるからです。誕生日の日付の場合ならば、新生児なのか、100歳の長寿の人なのかの区別がつかなくなります。この問題は、1990年頃から、コンピュータの利用が普及していた米国社会では、社会的な大問題と言われるようになりました。特に、日付が重要になる政府の各組織や銀行などの金融機関では、この問題は「紀元2000年問題」と呼ばれ、1960年代より前に作られ、1960年代から使われてきたプログラムを、1990年代にも利用している組織では大問題でした。そのような組織では、膨大な量のプログラムがあり、その一つ一つを調べて、全ての年号を4桁の数字で表すように修正するために、どれくらいの人が、どれくらいの時間をプログラムの修正にかけなければならないのかすら計算できないほど、大量の人と時間がかかる問題だったのです。

最初にプログラムを作る時、今、作成しているプログラムが、2000年まで使われることをしっかりと考えていれば、年号を2桁の数字で表す方法はとらなかったでしょう。しかし、普通の人は、日々の生活でやっていた年号を2桁の数字で表す方法が、30年後、40年後の社会で問題になるとは気づかないのです。『今日、問題がないことは、明日でも問題がない。』と考えがちなのです。実は、『今日は問題がないことでも、遠い将来には問題になるかも知れない』と考えなければならないのです。大切なことは、「このプログラムは、いつごろまで使われるのか」をはっきりとさせて、それまでは問題なく使えるように作らなければならないのです。似たようなことは、税金の税率の変化などでも起こります。プログラムを作った直後には全く問題がなくても、法律が変わって、税率が変わってしまえば、プログラムを変えなければならなくなります。もっと難しいのは、「何に、どのような税金をかけるか」が変わるような法律の改正がある場合です。今までは、かからなかった「消費税」が導入されるような場合です。

『どのようなプログラムを作りたいのか』をはっきりとさせることは、プログラムの作成を頼む人々が、「自分達が欲しいと思っているプログラムが、どのようなものなのか」を説明すれば良いと考えがちです。しかし、プログラムを頼む人々は、自分たちが「欲しいと思っている」プログラムは、現在の自分達が「今、欲しいと考えている」ものであると考えがちです。それは、いつも正しいとは言えません。プログラムの作成を頼む人々を取り巻く社会の状況は、少しずつ変わってゆくからです。そのような社会の変化をしっかりと考えて、「今の状況にも、将来の状況の変化にも合わせられるプログラム」がどんなものなのかを明らかにしなければなりません。もちろん、同じことはプログラムを作る人々にも言うことができます。将来、自分が作ったプログラムを修正しなければならない人が、プログラムを「どう修正すれば良いのか」を考えやすく、プログラムを作っておくことも重要です。

プログラムは、私たちが思っているよりも、はるかに長い間、使われることがしばしばあります。コンピュータは、私たちが思っているくらいの期間しか、動きません。計算機械であるコンピュータは、全ての生き物がそうであるように、いつまでも動くことはできません。生き物であれば、年を取って動けなくなり、死んでしまうのと同じように、機械は、故障して正しく動くことができなくなり、ある程度の間は、修理してもう一度、動くようにすることができても、生き物が死ぬのと同じように、いつかは修理しても動かすことができなくなります。しかし、プログラムは違います。プログラムは、年月が経っても、動かなくなることはありません。使う人が思っているのとは違って、『正しい』とは思えないような動き方をするだけです。コンピュータが、生き物の身体だとすれば、プログラムは、生き物の精神のようなものなのです。ですから、動かせば、いつまでも動くのが、プログラムです。人間が年を取ると、「ぽける」ことがあります。プログラムも、同じように「ポケ」ますが、死にません。

どんなプログラムを作るかが決まると、今度は、プログラムを作る人が、それを作ることを頼んだ人々が、はっきりとさせた「どんなプログラムが欲しいのか」についての説明に基づいて、「どうすれば、それを作れるのか」を考えます。それは、そのプログラムを使う人達が、「どんな入力を入れて、どんな出力を望んでいるのか」の説明をよく考えて、コンピュータに、「どんな順番で、どんな計算をさせて、何の値をどの場所にしまい、その後で、それをどう使うのか」を考えます。同じ計算でも、その順番を変えると、答えは違ってしまいます。ですから、計算と順番を注意深く決めてゆきます。ここで、計算とは、記憶装置のどの場所にしまってある値を使って、それがどのような値の時、どのような計算をして、計算結果をどこにしまうのかを言います。数学や算数の式で言えば、等号(=記号)を挟んだ、左側(左辺)と右側(右辺)の計算を決めることになります。

例えば、社員の給与を計算するプログラムであれば、最初に給与の合計額をゼロにして、その社員は、「普通の社員であるのか」「管理職の社員であるのか」を調べて、普通の社員であれば、その月に出勤した日数を調べ、標準の出勤日数であれば、給与の合計額にその社員の標準月給を足します。さらに、普通の社員であれば、全ての出勤日別に、退社時間から出勤時間を引いて、勤務時間を計算し、その時間が9時間以上であれば、勤務時間から9時間を引いた時間を残業時間とします。その残業時間にその社員に対する時間当たりの残業手当を掛けて、1日分の残業手当を計算し、合計額に残業手当を足します。このようにして、各月の勤務日ごとに残業手当を計算した後、これ以外の住宅手当や家族手当などを計算し、合計額に足してゆきます。その後、年金や健康保険料の月別請求金額を引き、残った合計額に対して決められている所得税や住民税などを計算して、最終的な給与支払額を計算します。

この例で書かれている計算方法の詳細は、フログラムが何をしなければならないのかについての「給与計算」について、社内での計算の仕方を細かく調べて、決めなければなりません。このような作業を管理職の社員や、アルバイト社員などと、社員の全ての種類別にしっかりと調べて、明確に理解してゆくことが必要です。この細かな計算の方法を、実際にその計算を担当していた事務員の人たちから聞き出して、書き出し、それが終わったら、コンピュータが理解できるコンピュータ言語を使って書き、実際にコンピュータを使って、給与額が思った通りに計算されていることを確認します。もし、計算結果が自分が思っていたものと違っていれば、計算方法のどの部分に間違いがあるのかを調べ、その間違いを正しい計算に直します。この動作の確認と誤りの修正を続けて、自分の考えている通りの計算ができるようになった時、プログラムの作成が終わります。

(つづく)