中学校技術/プログラムによる計測・制御

プログラム

コンピュータの処理の手順をプログラムという。 プログラムを記述するための言語をプログラミング言語という。

順次、分岐、反復

フローチャート、順次の例

フローチャート、分岐の例

フローチャート、条件繰り返し（反復）の例

コンピュータは、特に指示がない限りは、前から順番通りに実行する。これを順次という。

コンピュータは、条件によって（あるいは条件によらず）実行する順序を変えることができる。これを分岐という。

コンピュータは、同じ処理を繰り返すこともできる。これを反復という。

簡易なフローチャート これはsに1から10までの数字を足しこむ処理を表した図である。

Nの階乗 N! を計算するフローチャート

分岐と反復を組み合わせて、条件が満たされている間だけ処理を反復するような手順も、プログラムで指示できる。

プログラミング言語には様々な種類があるが、多くのプログラミング言語は、分岐や反復や順次処理などを利用している。

フローチャート

プログラムでの、順次や分岐や反復の組み合わせ方を、人間が理解しやすいように図示したものとしてフローチャートが有る。 横長のひし形(図では◇の横長のもの)で、条件分岐を表し、ひし形の中に、条件の内容を記述している。

順次処理は、横長の長方形で書かれる。処理内容は、四角の中に書かれる。

順番は、原則として、プログラムの最初が、フローチャートの一番上にあり、一番下が、最後の処理である。

プログラミング言語

プログラミング言語には多くの種類があるが、1960年代ごろからある古典的な言語では、BASIC(ベーシック)とC言語（シーげんご）とFORTRAN（フォートラン）やCOBOL（コボル）がある。

BASICは初心者向けとして有名であった。

C言語は、コンピュータで処理しやすいように文法が厳密である。歴史的にはオペレーティングシステムのプログラムの記述のために開発されたため、OSの開発など、システムの深い部分の処理にも利用しやすい。

C言語はコンピュータ技術者にとっては有用だが、それ以外の職業の用途では無用な特徴も多く、そのため、ほかの業界に合わせて開発されたプログラミング言語がある。

テンプレート:コラム

アクチュエータへの応用

外界からの情報を信号として出力する装置をセンサという。 以下、コンピュータに取り付けられるセンサについて記述する。

センサとは別に、コンピュータなどからの信号に基づき外界の物体を動かす装置をアクチュエータという。

センサとアクチュエータをコンピュータに取り付ければ、センサで外界の状況を確認できるので、外界の状況が変わっても、センサで外界を確認しなおして、プログラムの判断基準（プログラムの条件分岐の機能を、アクチュエータの判断基準に応用できる。）に従い、アクチュエータで外界の物体をプログラム通りに動かせる。 このように、コンピュータ制御のアクチュエータを、センサと連動させることで、外界の環境変化に対応するアクチュエータを作ることができる。

一般に、パソコンの単体には、センサやアクチュエータは付属していないので、もしセンサやアクチュエータが必要な場合は、パソコン用のセンサやアクチュエータを購入などで入手してから、それらをパソコンに取り付けることになる。

（※ 範囲外: ）論理代数

※ 2019年現在の中学技術の検定教科書では、下記のような条件判定については習わない。

ただし、資料集などで紹介される可能性があるので、wikibooksに残しておく。

コンピュータの分岐機能での条件判定では、次のような判定が出来ます。

条件	数学の記号
AとBは等しい	$A=B$
AはBより大きい	$A>B$
AはBより小さい	$A<B$
AはB以上	$A\geqq B$
AはB以下	$A\leqq B$
AとBは等しくない	$A\ne B$

センサーなどを用いてアクチュエータ制御の条件判定を行う場合は、センサーの信号を数値に置き換えて行います。

また、複数の条件判定を組み合わせた条件判定もあります。次に示す、論理積や論理和などです。

• 論理積

AND回路の説明図。この図は X and Y の図である。
電球がつくのは、スイッチXとスイッチYの両方が閉まっている時だけである。（スイッチが閉まっている状態を1とする。スイッチが開いている状態を0とする。）

たとえば、条件Xと条件Yの両方が満たされている時にのみ、ある行動を実行する条件判定をAND（アンド）という。このANDとは英語の接続詞の 「and」 のことである。式では、

X and Y

などと書く。

仮に条件が満たされていない場合を数字の0として、条件が満たされている場合を1とすると、andの性質が、掛け算に似ているので、そのことからAND演算を論理積（ろんりせき）ともいう。 ある条件Xが満たされていることを真（しん）と言う。ある条件が満たされていない場合を偽（ぎ）と言う。 条件が真の時、これを数値の1で表すことができる。条件が偽のとき、数値の0で表すことができる。なお、このように、条件の数値を数値の1と0に置き換えて計算する代数学をブール代数（ブールだいすう）という。

論理積の真理値表

条件 P	条件 Q	P and Q
真	真	真
真	偽	偽
偽	真	偽
偽	偽	偽

• 論理和

条件Xと条件Yの少なくとも、どちらか片方が満たされている時に、ある行動を実行する条件判定をOR（オア）という。このORとは英語の接続詞の 「or」 のことである。式では、

X or Y

などと書く。OR演算のことを論理和（ろんりわ）ともいう。

命題 P	命題 Q	P or Q
真	真	真
真	偽	真
偽	真	真
偽	偽	偽

• 否定

他にも、条件Xが満たされていない場合に、（その他の条件Yなどについては不問）、ある行動を実行する条件判定をNOT（ノット）と言う。式では、

not X

などと書く。NOT演算のことを否定（ひてい）と言う。

命題 P	notP
真	偽
偽	真

• 排他的論理和

他にも、条件Xと条件Yの少なくとも、どちらか片方のみが満たされている時に、ある行動を実行する条件判定をXOR（エクスクルーシブ/オア）という。式では、

X xor Y

などと書く。XOR演算のことを、排他的論理和（はいたてき ろんりわ）とも言う。

条件判定のANDやORなどを回路図の一部として図示したものとして、論理回路がある。条件が満たされた時を、回路に電流が流せる時と同一している。 たとえば、AND回路では、A and B なら、Aに対応するスイッチとBに対応するスイッチが閉じることで、回路に電流が流せるようになる。 NOT回路では、not Aなら、普段はスイッチが閉じていて、条件Aが満たされた時に対応するスイッチAが開き、電流が流せなくなる。

• 
  AND回路
  A and B
• 
  OR回路
  A or B
• 
  XOR回路
  A xor B

コンピュータのハードウェア内部では、半導体素子の一種であるトランジスタのスイッチング機能を用いて、論理回路を実現している。このようなハードウェアの仕組みを利用して、コンピュータは論理演算を行っている。なおトランジスタが実用化される前には、パラメトロンや三極真空管を、更に真空管が実用化される前には、継電器（リレー）を用いて、スイッチング機能を実現していた。

（トランジスタのスイッチング機能については工業高校や工学系大学の教育内容になる。）

中学の段階では、トランジスタの仕組みについて、まだ知らなくても良い。

補足

プログラミング言語の具体的な文法については、ウィキブックス内には、記事プログラミングなどに解説があります。 実習などで用いる言語は、時代によって変わるかもしれません。また、実習の内容によっても変わります。 たとえばウェブページを作る場合のプログラムはHTML（エイチ・ティー。エム・エル）という言語で記述を行う場合が多いです。

また、学校で用意された実習キットなどを用いてプログラミングを行う場合は、そのキット用に開発された独自の教育用のプログラミング言語を用いる場合もあります。

中学の段階なら、BASICか、その派生言語を使うことが、あるかもしれません。

デバッグ

※ 令和3年度から、デバッグの話題がこの単元に加わります。（東京書籍などのwebサイトの技術科教材のカタログPDFで確認。）

プログラミングでは、とりあえず一応のプログラムを書けたら、今度はそのプログラムを実験的に動作させてみて、本当に安全かつ正常に動くかどうかを確認する必要があります。

人間の入力ミスや、勘違いなどによって、プログラムが異常な動作をしてしまう場合もあります。

なんらかの原因で、プログラムが異常な動作をすることを「バグ」と言います。

プログラムにもしもバグがあったら、つまり、なにか異常な動作、正常でない動作をするなら、これは修正しないといけません。このように、バグを取り除いて、プログラムを正常に直すことをデバッグ(debug)といいます。

前提として、プログラムを作った後は、まず開発企業などが自分たちで、本当にそのプログラムが正常かどうかを実際にプログラムを動作させる実験によって試す必要があります（この工程を「テスト」と言います。）。もちろん、時間の制限などもあって、完全には確認しきれませんが、なるべく時間の許すかぎり、プログラムを確認する必要があります。

また、プログラムのエラーだけを除くのではなく、たとえば画面のあるシステムを作っている場合なら、画面が第三者の利用者にも見やすいかのチェックや、操作が分かりやすいかなどもチェックもデバッグにおいて確認する場合もあります（※ 開隆堂の検定教科書）。

（※ たぶん範囲外: ）説明の都合上、プログラムを例にして説明していますが、コンピュータ業界以外の製品開発なども同様に、安全性などを実際に動作させることでテストする必要があります。

自動車会社なら実際に走行試験や衝突実験（エアバッグの動作などの確認）をしています。製薬会社では、実際にネズミやイヌなどの動物を使って実験をしたり（動物実験）、最終段階には人間を希望者をあつめて新薬の実験の被験者になってもらいます（人間を被験者にした新薬の実験のことを「治験」（ちけん）と言います）。

なお、テストのために動作確認をする前提として、まず、その製品の正常な動作を、決める必要があります。（これをIT業界で「仕様」(しよう)などと言います。）

「〇〇の条件のときに、このプログラムは△△の動作をする」という仕様でしたら、果たして本当にプログラムがそのとおりに動作をできているか、実験をして確認をします。

※ なお、温度を電流に変換するための電子素子としては、PTCサーミスタという素子があります（※ ネットの教科書画像でPTCサーミスタの紹介を確認。教育図書の教科書とのこと）。

フェイル・セーフ

バグを見つけて除くデバッグも重要ですが、万が一、バグを見過ごしてしまった場合でも、人が死ぬことや怪我などの取り返しのつかない大被害が出ないように設計することも必要です。

そのように、もしバグや故障などの誤動作などがあっても、システムが安全に稼働するように設計することをフェールセーフ（fail-safe）またはフェールプルーフ（fail-proof）と言います（※ 2022年代の中学技術の検定教科書にフェールセーフが書いてあるらしい）。

「フェイル」fail とは、「失敗する」・「失敗」などの意味の英語です。

たとえば、機械工場で生産システムを管理しているコンピュータの場合、もしシステムが異常を感知したら、そもそも通常起動をしないようにするべきです。

なぜなら、異常のある状態で高圧プレスなどを制御されたら、もしかしたら事故で作業員が死ぬ可能性があります。

かといって、すでに稼働している最中でシステムが級に故障した場合に、果たして急停止するべきかといわれたら、それは場合によっては疑問です。

もしシステムが急停止したことで、逆に人がケガをする事故が起きては困ります。

なので、システム稼働中の事故に対しては、たとえば徐々に減速していく、とかの設計になるでしょうか（職場や製品やシステムによって、適切な設計は変わります）。

ともかく、システムの異常時には、事故防止のため、安全にするための処理が自動的に起動して動作するような感じの設計、または、安全だと認められる処理以外の手作業での入力をシステムが受け付けないように設計するなど、安全措置（あんぜん そち）以外をできないようにする必要があります。

このように、安全側にシステムのモードを移行するための仕組みを組み込むような設計のことが、フェイル・セーフまたはフェイル・プルーフと言われるものです。

なお、仮にプログラムにバグが無くても、部品の故障によってエラーが起きる場合もあります。なので、工場などで使うプログラムでは、フェイル・セーフも必要です。

設計技法の初歩

さて、ある検定教科書では、サーバ・クライアント通信のプログラムを、アクティビティ図を用いて設計する手法を紹介しています。

果たして中学でそこまで必要になるかは不明ですし、そもそも中学レベルの技術力でそういう通信プログラムが書けるのか不明ですが、しかしとりあえず、（※教科書では説明していませんが、）一般的なプログラミングにおける設計技法として、自分の作ろうとしているモノが何なのかを、箇条書き（かじょうがき）などで紙にまとめる必要はあります。

なぜなら、検定教科書では説明されていませんが、

プログラミングは集中力を使うので、いちいち「何を作ろうかな」と考えながらプログラミング作業するのは難しいからです（※ 検定教科書では説明していませんが）.

また、会社や組織などの集団でプログラム製作をする場合は、個々人でイメージしている目標や指示などに食い違いが出ないように、目標などを文書で具体化する必要もあります。

要件定義

仕事などだと、上司や部下・同僚など他人が読んでもわかるように設計書を書く必要があります。（おそらく、検定教科書が意識してるのはコッチ。）

設計書では、大まかな要件を先に決定していき（ただし、比較的に短期間かつ自力たちで実現できる具体的な目標）、それを元に段階的に、追加の文書により細部を決めていきます。

どちらにせよ、まず、設計目標が何なのかを明確に文書に起こす必要があります。別に文体が美文である必要はありません。

そして、その目標に必要な最低限の技術的に実装すべき対象が何なのかを明確にしていきます。

※ 検定教科書にはない用語ですが、こういった作業を「要件定義」（ようけん ていぎ）などと言います。アクティビティ図などを紹介するその検定教科書が説明しようとしているのは、おそらく要件定義の方法でしょう。

※ ただし、中学生では、そもそもプログラミングでどんなことが出来て、何が出来ないかも知らないので、要件定義をするのは難しいかもしれません。だから、とりあえず知識として、仕事などでは要件定義のような手法が必要になる場合も多い、ということを知っていただければ十分かもしれません。

（※ 範囲外: ）やることリスト

プログラマーとしては事前にメモ書きのようなものでいいので、紙またはテキストファイルなどに、作りたいプログラムの満たすべき要件をまとめておくなどしておくと、いちいち目標を定期的に思い出す手間が省け、思考力を節約できるので、プログラミングに集中しやすくなります。（検定教科書では紹介されない用語ですが、こういうのを「To doリスト」とか「作業リスト」とか「タスクリスト」とか「やることリスト」などといいます。）

※ ただし、検定教科書の論点は、どちらかというと自分の思考の整理よりも、他人に設計を伝えるための手法としてアクティビティ図などを紹介していますが。だから「先生や友達」が読んでもわかるように書こう、などと検定教科書で説明しています。

ともかく、プログラミングの入力の前に、まず「自分たちは何を設計したいのか」を具体的に紙または画像データに書き起こすことです。検定教科書ではフローチャートの書き方などを教えていますが、それはあくまで、入力したいものを明確にする手段のひとつです。

そうやって具体的に見て分かるように文章化または印刷化・画像化をしておけば、打ち合わせをするにしても、あるいは忘れないようにするためにメモ代わりにするにしても、どちらにも役立ちます。

要は、「何を入力したいのか？」を読みやすい形式でメモ的に書いておけばいいのです。

プログラミング的な知識

ソート

並び順を変えることを「ソート」と言います。

ソートには、選択ソートや交換ソートがあります（※開隆堂のサイトで確認）。開隆堂サイトでは、トランプ（カードゲームのほう。カード４枚）の並び替えをしていました。

ゲームの「仕様書」

※ 出版社は未確認だが、ゲーム版のラブライブのゲーム（スマホゲー）を例に検定教科書で仕様書の書き方を説明している教科書があるとのこと。（どうやら開隆堂らしい。未確認）

ゲーム業界の例なのですが、ゲーム業界では「仕様書」（しようしょ）として、ある画面の動作の条件をすべて具体的に書きます。

また、基本的に具体的な画面を使って動作説明すことで、客観的に誰でも分かるように説明しています。

※ ゲーム産業だけでなく一般のIT産業の多くでも似たような書類での説明方法が用いられる。なので教科書では

たとえば、ある画面では、

• 「Backボタン」→「呼び出し元の画面へ遷移する」、　

• 「部員のイラスト」→「クリックしても何も起こらない」

• 「変更ボタン」→「自分のプロフィールの場合」→「クリックすると自己紹介ポップアップを表示する」

（「変更ボタン」）→「他ユーザーのプロフィールの場合」→「変更ボタンを表示しない」

のように具体的に書きます。（※　なお、製図などとは違い、仕様書では日本共通の書き方というのは存在しません。仕様書の規格も存在しません（2023年の時点ではそう）。）

（※ wiki注）上記の仕様の「呼び出し元の画面へ遷移する」などの文章は教科書画像からの引用。なので、決して上記文章の言い回しを変えないでください。

前の画面に戻るためのボタンのように、文脈から分かることでも、上記のように具体的に書きます。

イラストのように、クリックしても何も起こらない場合ですら、何も起こらないことを仕様書では明記します。そうすることで、その仕様書のそのページさえ読めば、これからプログラミングで作るべき動作のゴール地点が分かるようにします。

もちろん、変更ボタンのように、クリックすると変更が起きる場合は、

「自分のプロフィールの場合」→「クリックすると自己紹介ポップアップを表示する」

のように何をどう表示するかも具体的に書きます。

このように、ソフトウェアの設計（デザイン）というのは、先にゴール地点を具体的かつ客観的に決めて、あとから細部をデザインしていきます。一般にゲームも同様、ゴール設定を先に行い、あとから細部を決めていきます。アイデアは、「なんのために」というゴールを達成するための手段です。

ゲームデザインではない単元ですが、教育図書（教科書会社）の検定教科書でも木工などの単元で、目的や条件から逆に（設計の）構想を考えるように指導しています。なお、実用品などの場合は、問題を先に見つけ、その問題を解決するために上記の目的や条件を考えます（※ 教育図書の見解）。

また、設計のための書類で使われれる文章のレベルも、中学卒業したレベルの知識さえあれば、とりあえず内容は分かるような文章で書く必要があります。

※ なお、同じコラムで、フローチャートの代わりにUMlを教えてる。ラブライブのゲームの仕様設計では、UMLを使っているらしい。

※ ほか、仕様書中のゲーム画面自体、ほぼ完成品と見間違えるような完成度の高いものを、検定教科書では掲載しています。検定教科書では「画面のモックアップ（模型）」と言ってますが、しかし一般人の目には、まるで完成品と見間違えるような、きれいな作りこみです。

果たして最初からそこまで完成度の高い画面をつくれるかは疑問ですが、しかし一般に他のIT業界（ゲーム業界以外のIT企業）でも、製品の完成段階でのソフトウェアの「仕様書」の一種として、そういった完成品と同等の画面を掲載した書類を作成する場合もあります。（※ 出典は非公開。理由は、詳しい出典の説明が、この文を書いた編集者の過去の勤務先の企業秘密に当たるため。）　

仕様書に掲載する画面をつくるためのプログラミングが別に必要になりそうですが、ともかく、そういう完成品に近い画面を掲載した「仕様書」も必要な業界があります。（ただしゲーム業界がどうなのかは知りません。）

もし、そういう完成画面のある「仕様書」が無いと、たとえばソフトウェアがもし将来的に故障して、動作や画面表示などが変わってしまった時に、どういう状態に戻すプログラミングをすれば良いかが仕様書が無いと分からなくなってしまうから、完成度の高い画面をつかった仕様書が必要なのです。だから、故障時にもどす対象のゴールとしても、完成品に近い画面をつかった「仕様書」も一般IT企業では必要です。

※ 該当の教科書では「モック（模型）」という言い方をしています。

「モック」は、業界によってニュアンスが微妙に異なりますが、本物とは違います。

辞書を見ると、良い意味で使う場合もあれば、悪い意味で使う場合もあります。良い意味では、たとえば「模擬線」 a mock battle や（実験用・教育用などの）「実物大の模型」のように良い意味で「モックアップ」 mock-up という語を使う場合もあります（大修館書店ジーニアスや三省堂グランドセンチュリーで確認しました）。悪い意味では、完成度のひくい真似として使う場合もあります。、

ゲーム仕様書の「モック」は、おそらく、実物大ではないと思います（なぜなら、端末によって画面の大きさが変わるかもしれない。該当ゲームのことをよく知らないので、分かりません。詳しい人は wiki編集してください。）

なお、mock は大学入試での受験英語です（旺文社ターゲット1900や、鉄緑単語集に mock があります）。

※ 範囲外

ロボット教材など

テンプレート:コラム