2019.02.08

マーフィーの法則 （2）

マーフィーの法則は、日本では1980年にコンピューター雑誌で紹介され、
まずコンピューター・プログラマーの間で話題になった。
プログラマーにマーフィーの法則がもてはやされたのは、
経験者の少ない新しい分野で若手の技術者が多く、失敗を自嘲しつつ
自戒するということの必要性が最も高い分野だったからであろう。

プログラムがうまく動作しないときに、
その原因を探るデバッグ（虫取り）の作業は地道で気がめいることである。
自分で書いたコードのミスであればまだしも、
他人が書いたプログラムコードの場合は、どのような意図で
そのコードが書かれたのかを判読しながら、ミスの在りかを探さなければならず、
時として気が遠くなるような作業となる。

初期のプログラマーは、それぞれが独自のやり方でコーディングをしていたので、
プログラムの流れがあちこちに飛び、「スパゲティ・プログラム」と
呼ばれるようなロジックが絡み合って、判読困難なプログラムが多かった。

そこでマーフィーの法則が役立つことになる。
「判読困難なプログラムコードを書くと、必ずそのプログラムには、
探すのが困難なバグが住み着く」という法則である。
バグが潜んでいる可能性を最初から想定して、
あとでバグが発見しやすいようなプログラムを書けば、たとえバグがあっても
容易に修正して正しいプログラムを早く完成させることができる。
わかりやすいプログラムコードを書くためには、少しの手間が必要になるが、
その手間を掛けるだけで、後で災厄のように降りかかる膨大な修正作業から
解放されるのであればありがたいことである。

わかりやすいプログラムコードを書く方法として編み出されたのが、
構造化プログラミングと、プログラムのモジュール化という手法である。
当時、多く用いられていたFORTRAN、COBOL、BASICは、
プログラムのロジックを分岐して記述するタイプの言語で、
スパゲティ化しやすかった。

構造化プログラミングでは、IF構文や、繰り返し処理の場合に、
条件によって場合分けをして行う処理を、階層化して記述する。
段階的に詳細を書くようにプログラムすることで、見直しがしやすくなる。

モジュール化では、頻繁に使われるひとまとまりの処理を、
サブルーチンや関数という形の小さいモジュールのプログラムで作り、
メインルーチンからサブルーチンを呼び出すようにプログラムコードを書くと、
メインのロジックの流れが読みやすくなる。

似たような処理を何カ所もプログラムの中で使っているときに、
その処理にバグが見つかると、プログラム全体の「似たような処理」を探して
修正していかなければならないが、サブルーチンで処理を小分けしておけば、
バグが見つかっても、その1カ所を修正するだけで、
プログラム全体の見直しは不要となる。

構造化プログラミングをしやすくするために、
それに向いたコンピューター言語が開発され、広まった。
現在も主流となっているC言語は、
構造化に適した言語として普及したものである。
C言語では、関数という形でモジュール化した処理を呼び出し、
また、ポインタという概念でメモリ空間の取り扱いを共通化しており、
バグを比較的生みにくく設計されている。

マーフィーの法則を用いて業務改善すると、
業務に用いるツールまでも再設計される。
教育の情報化の分野でもさまざまなアプリが開発され販売されているが、
きらびやかな機能ばかりでなく、ミスの少なさや修正のしやすさという
使いやすさの原点にも目を向けて、適切なツールやアプリを選びたい。

高橋先生

千葉学芸高等学校理事長・校長・理学博士。
日本教育工学協会評議員、全国高等学校長協会理事。
1995年100校プロジェクト参加を契機に、
ネチケットをはじめとする情報モラル教育の研究に取り組む。
日本教育情報化振興会「ネット社会の歩き方」検討委員、
文部科学省 情報モラル教育検討委員、文化庁 著作権教育検討委員、
総務省 情報リテラシー指標検討委員、JST社会技術研究開発センター
「犯罪からの子どもの安全」領域アドバイザーなどを歴任。

著書：教師と学校のインターネット(オデッセウス出版)、
　　　先生のための実践インターネット講座（NHK出版）他