zz - From the Planet with LOVE

http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.0.1.html

『Ｃプログラミング診断室』
第〇章　開院準備

『Ｃプログラミング診断室』目次／次（開院準備・レベル差）

『Ｃプログラミング診断室』

第〇章　開院準備

■ 昔むかし

私がコンピュータを始めたのはもう１６年も前になります。半田ごてを持って、TK-80なんてキットを組み立てたりしました。今から考えるとまるで情報のない時代でした。趣味のパズルで、しらみつぶしに検索するのに、自分でやったらミスはするし、面倒くさくてやってられないので、ばかばかしい作業を代わりにやってくれる道具を捜していました。そのころ世に出てきたのがマイクロコンピュータでした。

当時はパソコンという言葉さえ存在しませんでした。今のパソコンよりも遥かに低速なVAX-11/780という１億円もするコンピュータ、といってもメモリは増設してやっと750キロバイト、ハードディスクは50メガバイトを使って、３次元CADプログラムを組むという、今考えると空恐ろしいことをやったりもしました。あるいは、それよりもさらに前に、1600万色フルカラーの画像処理装置のプログラムの開発をしていました。たった２ＭＢのメモリを管理するために、専用のハードウェアメンテナンス要員がいました。

AppleIIにCP/Mボードを挿して、全部アセンブラでコンパイラを作り上げたりもしました。それどころか、CPU不明のポケットコンピュータ相手に、付属していたBASICを使って、ROMの内容をみんなで解析して、分かった範囲のマシン語を利用して液晶ディスプレイを高速に制御し、ゲームを作って遊ぶという狂気じみたことまでやったり、やらせたりという、旧き良き時代がありました。

そういうことをしていたので、結構周りにはコンピュータをよく知っているのがうろうろしていて、新しい情報を容易に入手できました。コンピュータ関係の雑誌や単行本も少なく、刊行されているものはとにかく全部購入してしまうということをしても金が続きました。全く情報の少ない、旧き良き時代でした。

Ｃ言語については、カーニハンの『プログラミング言語Ｃ』の英語版の青焼を見たのが最初だった記憶があります。その後日本語訳がすぐに出て、使える環境がないにもかかわらず読んでみました。当時、どこまで理解して読んだか全然覚えていません。それからしばらくして、会社でUNIXを導入することになってからは、Ｃを毎日使用するようになりました。もう１０年以上も前のことです。

その後のコンピュータの発展は、予想はしていたものの本当にすばらしいものです。ハードウェア性能はどんどん向上し、どんどん使いやすくなって来ました。美しい３次元コンピュータグラフィックスの表示を家庭で自由に楽しめる時代も現実になりつつあります。

■ レベル差

コンピュータが良くなり、より複雑な処理をするプログラムがどんどん増えてきました。大学には多数の情報関係の学科が新設され、コンピュータ専門学校もどんどん増え、多数のプログラマを排出しました。したがって、プログラムの開発技術の方も着実に進歩したと考えるのが当然でしょう。いまでは、学校で正規にプログラミング教育を受けた人達がプログラムを組むようになってきたので、コンピュータメーカ、大手企業のソフト開発部門から中小ソフトハウスに至るまで、ソフト開発のレベルも自然に上がってきたと考えるべきでしょう。

しかし、現実の姿は全く反対で、技術レベル差はますます広がり、下級レベルは「ごみプログラム」を大量生産しているだけになってしまいました。趣味のプログラマが下手で、どうしようもないのは趣味だからまだ良いのですが、下手なプログラマが報酬を得て下手なプログラムを組み、そのプログラムで社会活動の一部が動いているかと思うとゾッとします。コンピュータは日常生活のあらゆる分野に入り込んでいるので、人権、金銭、財産に関することはもちろん、交通機関、医療機械などでもどんどん利用されているので、バグが生命を奪う危険性も当然考えられます。

プログラマという名前さえついていれば、誰あるいはどの会社に発注しようと同程度のプログラムができ上がると思っている人がいます。相見積りをとり、できるだけ安いところに決定することが良く行なわれています。これはとんでもない間違いです。プログラムの開発は、一度始めたら、あらゆるものがコンピュータ処理になっていくため、少々どころか全然満足できないプログラムでさえ我慢して使い続け、拡張し続ける運命にあります。最初が肝心です。最初にきちんとした人が開発していれば、その後の保守、拡張はスムーズにできたはずなのに、土台がだめなので何をやってもうまく行かず、システム全体を廃棄処分にしてしまうことすらあります。もっと悲惨なのは、リース期限が切れるまで、使いもしない粗大ごみを社内にデーンと置いておくことでしょう。

少々不満でも、発注先を別の会社に変更すると慣れるまでの時間がかかるとの判断で、いつまでも同じ所に発注し続ける傾向があります。どの専門分野でも同じ傾向がありますが、客はそんなにコンピュータに詳しくないので、どこに発注するのが一番ベストか分からないのが普通です。現在付き合っている会社の技術レベルを標準と考えがちです。複数の会社に仕事を出すと、各社の色々な分野でのレベル差とか特徴が分かってきて、継続して発注すべき所と、早く切り捨てた方が良い所が分かってきます。

プログラムの単価は、まだまだ１行いくらという、内職と同じレベルで評価されることが多いのです。もちろん、コンピュータ会社以外の経理部門などがそういう考え方をするのはやむを得ないと思いますが、まだまだコンピュータで生計を立てている会社ですら、その様な技術を無視した考えを持っているところが多いものです。

■ 教育

今まで、コンピュータ教育、とくにソフトウェア教育というと、プログラミング言語などを覚えて、与えられた仕事をこなすことだと思われていました。そして、実際の仕事についてプログラムを組み始めたら、プログラミングの品質管理などについて社内研修があったりします。プログラムの品質向上は今まで数え切れないほど話題にされ、各種の技法が紹介され実用に供されました。また、最近の開発ツールはいろいろな開発支援をしてくれることも事実です。

しかし、やはりどんな道具を使おうと、下手なプログラマのプログラムは下手なのです。フローチャートや、その他の設計方法でしっかり設計しても、形式だけでは結局だめなのです。プログラムを組むためには、プログラミング言語を理解していなければなりません。でも、これは文法を理解しただけに過ぎません。これでは日本の英語教育の欠陥とまったく同じです。日本語が使えるのは、幼いころ、自分の周囲で日本語を話すのを聞いているうちに自然に身につけたものでしょう。誤ったことを言えば、何度も何度も直してくれた人がいたはずです。

コンピュータ教育も他の分野と同じで、基礎的なことは本から、あるいは講義などで知識を得ることは必要です。しかし、その知識を運用して、やりたいことをやれるように育てることが教育の本質です。それには、どこで誤りを犯すかを指摘し、正しいやり方を教え、使いこなせるようにしなければなりません。それも、正しい方法そのものを「公式」の形で示すだけではなく、その「公式」を使えば良い理由を教えなければなりません。重要なのは公式ではなく、理由の方なのですが、今の学校教育の弊害なのか、「公式の丸暗記」だけをしようとする人がいます。学校教育では、最も単純な生徒の能力判定として、今も暗記力を問うテストが多く行なわれています。

仕事では、記憶は学校教育ほど重要ではありません。不確かな記憶に頼るぐらいなら、メモを取るなり、資料や本を見たり、オンラインヘルプを見て正確を期せば良いのです。不確実な記憶に頼って間違えたら罵倒されるに決まっています。無理をして覚える必要は全然ありません。それより、どこにどんな情報があるかを、どうやったら調べられるかを知っていることが重要なのです。

コンピュータの世界では、情報はどんどん古くなってしまいます。全ての情報はナマモノ、生鮮食料品みたいなものです。学校で習った知識や技術がいつまでも通用する世界ではありません。それどころか、たとえ最新の技術教育を受けたにしろ、卒業した時点ですでに古くなっています。学校で習った知識で一生食べていけるなんてことは有り得ません。私がコンピュータを始めたころの知識で役に立っているものはほとんど有りません。当時は役に立ったのですが、もう使っていたコンピュータも廃棄処分になっています。このように変化の激しいコンピュータの世界で生き抜くためには、記憶に頼るようなことはやめた方が無難です。

■ ネットワーク

コンピュータの世界でネットワークと言うと当然ＬＡＮのことを考えますよね。でも、違うのです。ここで言いたいのは、コンピュータを使っていく上で助けてくれる「お助けネットワーク」のことです。

コンピュータは非常に性能が上がり、その利用法も複雑多岐に渡っています。たとえどんなに優秀なコンピュータ技術者でも、その全容を理解し利用している人などいません。各自が、自分にとって必要な部分を理解し、使っているに過ぎません。

このようなコンピュータについて、誰にも未知の分野がいっぱいあるのは当然です。新しいことに応用してみようとか、新製品とかについては未知なのは当り前です。でも、どこからか情報を仕入れて使っています。製品を買えば説明書はついてきます。それで一通りの使い方はできるようになるものですが、さて、自分のやりたいことはどうやったら実現できるのかという一番大切なことには答えてくれないものです。もしかすると、自分がわざわざプログラムを作ろうとしていることはすでに誰かが実現しているかも知れないのです。

特定のメーカの製品だけでコンピュータシステムを組んでおけば、それらの組合わせで不都合が起きれば、そのメーカに問い合わせれば何とかなるでしょう。でも、それぞれに適した製品を購入すると、たいていの場合メーカがバラバラになります。複数のメーカの製品を組み合わせて使う場合、相性の問題が良く発生します。規格ぎりぎりで作っているメーカがあるかと思えば、十分なゆとりを持って作っているメーカもあり、トラブルになることは良くあります。さらに、メーカが推奨していない安い製品を利用したいこともあるでしょうが、そのときの信頼度はどうなのかなど知りたいでしょう。

コンピュータの導入時には知りたい情報はいっぱいあるはずです。ディーラーを呼んで資料を請求すれば持ってきてくれますが、十分な資料、知りたい情報はなかなか手に入らないものです。できることなら、実際に使っている人の使用感でも聞ければ最高ですよね。プログラムについても、個人、あるいはソフトハウス、企業の一部署程度では、なかなか情報が集まらないものです。適当な指導者も見つけにくいものです。

では、どうすればそのような情報を提供してくれる人々と知り合いになり、指導してもらったり、情報を交換するのでしょうか。

答えは簡単なんです。待っていても、ダメなんです。もちろん、金を払って指導を受けたり、情報を買う方法もあります。しかし、これではまだ受け身にしか過ぎません。自分の疑問点を持って、あちこちに自ら飛び込んでみるしかありません。失敗をするでしょうが、失敗に懲りずにあちこちに顔を出してみることでしょう。顔の広さと、情報の集まり方はだいたい比例するものです。上達しようと望めばそういう連中のいる集まりの存在を耳にするようになり、自然と顔を出すようになるものです。

コンピュータと言うと、世間では、人と口を聞かず、ただひたすらコンピュータに向かってキーを打ち続けている人間のようなイメージがまだあります。人付き合いが悪くても、コンピュータの仕事なら構わないように誤解されています。私なんか、ディスプレイに向かっていても、実際にプログラムを作成している時間は非常に少なくなりました。多くの時間は、原稿を書いたり、仕事の連絡のための文書を作ったり、電子メールを読んで返事をしたり、電子ニュースの海の中を漂っています。色々な情報を提供し、提供されて日々暮らしています。

色々なソフトハウスを見てきましたが、だいたいレベルの差は、各社の技術者の人的ネットワークの質とサイズに比例するようです。レベルが低いところほど、外部と交流することを拒否する傾向があります。個人、あるいは小さいグループだけでやっていたのでは、相当の強者でもいない限りハイレベルを保つことは無理でしょう。

■ 情報集め

プログラムを作るためには、多数の情報を集めなければなりません。的確な情報を、他社より早く入手し、世の流れに乗ること、あるいは時代に遅れないことは絶対に必要です。

では、情報集めはどうすればよいでしょうか。本、雑誌、新聞などに頼ることはもちろん必要ですが、それだけで十分でしょうか。実際には、そのようなマスコミの媒体に掲載される前に、第一線の技術者の間では衆知の事実と言うことがよくあります。それどころか、第一線の技術者たちの中には、マスコミ媒体に記事を書いたり情報を提供している人達が大勢います。彼らは、いったいどこから情報を得るのでしょうか。

今はコンピュータを使った情報通信が非常に発達しています。その一つがパソコン通信です。その他にもさまざまな通信手段が全世界的に張り巡らされており、短時間の間に情報が全世界を駆け巡ってしまいます。電子メールを使えば、国内はもちろん、海外までも短時間の間に情報が届いてしまいます。また、電子掲示板を読んだり、あるいはもっと積極的に自分の意見や聞きたいことを書き込むと、いろいろ答えてくれる人がいます。このようなコンピュータ通信を利用すると、非常に早期に情報を入手できます。

もう一つの効果的な情報入手手段は、コンピュータによるネットワークではなく、「人のネットワーク」です。コンピュータを良く知っている友人、知人をできるだけ沢山持つことです。直接会って話すことにより、こちらの疑問に的確にこたえてくれたり、一般には公開されていない情報をこっそり教えてくれたりします。

そういえば、もうずいぶん前のことですが、80186-3というCPUを使ったパソコンを販売していたメーカがありました。「-3」がついているのを不思議に思うでしょう。この余分なものは要するにCPUのバグで、本来の80186としては動作しないこと、とくに数値演算プロセッサ8087が使えないバージョンで、正式の80186と交換しなければいけなかったのです。ここまでは、正式バージョンができる前にサンプルを入手してテストする場合にはよくある話です。

けっこう仲間うちではこのパソコンを使ったりしていたものがいたので、そのような事情は仲間達から聞いていました。一部の仲間のところには、メーカから無償で正常なCPUが送られてきていました。また、そのCPUの輸入代理店からも情報が入っていました。それで、私も、「このCPU不良だから交換して」とメーカに言ったら、メーカの人に、「どうしてそんなに詳しいことまで知っているのだ。知り過ぎだ。どこからそのような情報を入手したのだ」と詰問されてしまいました。十数年コンピュータの世界にいますが、バカな対応をする人はいっぱいいましたが、こんなにふざけた対応をされたことはありませんでした。後日、簡単すぎる謝罪文と共に正常なCPUが送られてきました。

その少し後で、そのパソコンが東京大学に大量に納められることに決まり、仲間のいる学科にもまとめて入ることになりました。色々な縁があって、それを手伝う（手伝わされる？）はめになり、そのメーカがどのように納入するか見守っていました。技術計算を頻繁に行なうため、数値演算プロセッサ8087は必須だったので、そのままではCPUの交換が必要でした。すると、CPUだけ正常品に無償交換されており、なおかつその事実も知らされない、つまり最初から正常品が納入されたことにされていて、みんなでびっくりしました。

もうひとつの話です。Ｘウィンドウは一般ユーザが使用する場合、Open WindowsとMotifの２つがあり、互いに張り合っていて、どちらを使うか迷っていたユーザがいっぱいいました。最近、主要メーカ間で、Motifに一本化することに話がまとまりました…ということになっています。しかし、これも遥か前から衆知の事実として知られており、発表の日時がいつになるのかだけが時々話題になっていました。

ところで、世の中には記者会見で発表され、新聞に取り上げられるまで知らなかった人達がいっぱいいたのです。まあ、そのくらいなら、「バカですね、無知ですね」で済ませられますが、そうなることを知らず、OpenWindows対応のソフトをせっせと開発し、発表しようと準備していた会社もあったのです。もう、情報音痴というか、救い難いですね。UNIX上のウィンドウは必ずMotif に対応させなさいと前々から教えていたのに、教えを守らずあわてふためいている会社もあります。情報処理の仕事をしていながら、一番重要な情報の処理ができていないところも結構あるようです。

地方には、なかなか正しい情報が伝わらず、変なコンピュータを買わされたりして後で困っているところが多いようです。地方の公立短期大学や公立高校などでは、公立であるがゆえに入札でしか決定できないため、変なパソコンを安価に大量導入したのはいいけれど、ソフトウェアがないので教育が破綻しているところもあるようです。担当者がきちんと調べて、ダメなものはダメだと言わなかったのがいけないのですが、そこまで彼らに求めるのは無理でしょう。入札の前に、ダメなものはダメと排除しなければいけないのですが、入札金額だけですべてが決定されてしまうような方式をとっているところは、今後もメーカにだまし続けられることでしょう。コンピュータを導入し、成功しているところを何個所か訪問し、自分のところとの相違を考えた上で決定すれば大きな間違いはしないでしょう。

とにかく、プログラム以前の、コンピュータに関する情報の収拾および処理に問題があるところが多く、困ったものです。

■ 隠すことについて

プログラミングの指導をするとき、一番困るのが、自分のプログラムリストを隠すことです。もちろん、自分の書いたプログラムに自信がないから隠すのでしょうが、隠せば隠すほど誰からもプログラムの手ほどきを受けられなくなります。

プログラムは、プロジェクト単位とか、部署単位で自由に見ることができるようにしておいたほうが、色々な問題点を指摘し合えて、互いに向上の機会があります。プログラムを誰でも自由に書き換えられるようにしておくと、今度は管理上の問題がありますので、プログラムの管理ツールを用い、見ることは自由にできるが、変更は作成者など許可された人だけが変更可能にしておくことが必要です。

以前、某社のコンピュータ教育を担当したことがあるのですが、とにかく一部の人を除いて自分の書いたプログラムを人に見せないので困りました。どういう風にプログラムを組めば良いかをいくら説明したって、一般論になってしまいます。何を説明しようが、机上の空論、眠けを催す講義にしかなりません。各人のプログラムの組み方には差があるので、実際に各人の作ったプログラムを使い、悪い点を指摘することが重要です。

この会社では、プログラムを見せないことが一般化し、最終的に動けば内部はどうなっていても誰も知らないような情況でした。最初は、動けば良いと気楽に言っていられるのですが、時間が経つとともに次第に混乱が発生してきて、泥沼に陥っていました。

もちろん、技術者全員が隠そうとしていた訳ではありません。新人や、技術的なことに興味を持っている一部の人達は相談に来たりするのですが、会社の上層部あるいは古株の人達が隠したがるのです。今まで作ってきたものに、重大な欠陥が指摘されたら困るのは分かるのですが、欠陥が分からずに、どんどん変なプログラムが増えていく方が、長期的には大変に決まっているのですが、分かっていても自分の立場などもあり、最善の選択が何かが分かっていても取れないのが実情のようです。

逆の会社もありました。プログラムを見せたがって、ぜひプログラム診断室の連載に採用して欲しいというところです。社内で独自に研究会を開いたり、社外の人を呼んでプログラムコンテストまでやっていた会社です。私も部外者ながら参加して、賞品をいただきました。この会社のプログラムは、残念ながら、下手なプログラムが発見できず、診断室には利用できませんでした。

大きなプログラムを複数の会社で共同開発することがあります。これは、プログラムを作る以上に、各社の体制の違い、レベルの違いに苦労させられます。人数が増えるだけでも色々なトラブルが発生するものですが、会社まで異なると調整は一段と難しくなります。大規模なソフトを複数の会社に分割して発注しているところは、さぞ管理が大変だろうと思います。

こういうとき、だいたい苦労させられるのは、レベルの高い方で、低い方はついてくるだけ、ということが多いのです。下手をすると、別の下請けの作ったプログラムのバグ取りまでさせられることにもなりかねません。正直言って、足手まといです。日本では取引関係のしがらみで、一度発注すると、切るに切れない下請けとの関係になったり、とにかく諸般の事情があって、理屈だけでは割り切れないようです。色々の問題点を教えて、もっと楽をして、より品質の良いプログラムを作り、発注側も、受注側もハッピーになるようにと思っても、難しいのが現実ですね。

昔々、小さなソフトハウスに身を置いていたころ、なんとか社内の技術レベルを上げようということで、発生したトラブルを社内ミーティングのときに発表する制度がありました。いちいち些細なミスまで発表されるときりがなくなるので、バグの原因発見まで３０分以上のものを発表するようにしました。ある人の陥るバグには、他の人も陥りやすいし、また似たような場面に遭遇することもあるので、そういう場合に役立てようとしたのです。もう遠い昔のことで内容は覚えていませんが、各自の馬鹿さを発表することにより、随分楽しめたし、互いのレベルも向上したように思います。

日本では、プログラムに限らず、都合の悪いことはできるだけ隠そうとする傾向があります。隠すことによって、その場は何とか取り繕うことはできるでしょうが、将来同様のトラブルが起こったとき、前回の経験が生かせません。トラブルにみんなで対処することにより、よりよい対策を打つことができ、ひいては被害を最小限に抑えられます。これこそ教育のはずです。けれども、こういうことを指導すべき教育機関、そしてそれらを管理指導している教育委員会とか行政機関に隠す傾向が特に高いのは、いったいどういうことなのでしょうか。

■ プログラムコンテスト

またまた昔の話ですが、社内で共同でプログラムを組むとき、バグを入れてしまった者が、バグを発見し、直した人に昼食や夕食をサービスする、プログラマの間で自然にできた制度がありました。程度の差によって、ちゃんとした料理から、缶ジュース１本だったりしました。この制度のおかげで、ずいぶん食事代が助かりました。でも、得する人と、損する人がいつも固定してしまうので、いつまでも続けられるものではなく、残念ながら自然消滅してしまいました。

アルゴリズムやプログラムの美しさなどについてのコンテストみたいなことをやっている会社は時々聞きます。評価そのものは難しく、優劣の判定は決めにくいものがありますが、とにかく、何とかして技術面の向上を目指していることが重要なことです。

ある会社へ行ったら、社内で実行速度が問題になっている部分の高速化アルゴリズム募集の広告が掲示されていました。なんと、社外の人も応募可能となっていて、ちょっとその気になったこともありました。

■ ドキュメント

プログラムを書くとき、自分に分かればいいやという気持ちで書くときがあります。どうせ自分でメンテナンスをやるのだし、早く完成させるために急いでいるのだから、分かりやすくとか、美しくとか考えられないことがあるでしょう。私だって、使い捨てのプログラムもいっぱい書いています。そういうときは、とりあえずの目的を満たすことだけを念頭に置いてプログラムしています。

しかし、そういうプログラムでも、けっこう後で使ったり、さらには機能拡張したりするものです。こういうとき、作ってから時間がたっていると、自分で作ったものでも忘れてしまっていて、思いだすのに時間がかかるものです。自分のプログラムでも、まるで他人のプログラムのように全然分からなくなったりするものです。いっぱいドキュメントを作るのもいいのですが、キーとなるコメントだけでも入れておくと非常に助かるものです。コメントやドキュメントは量があれば良いというものではありません。

プログラムを移植するとき、ドキュメントを請求したら、1000ページ近いドキュメントを渡されたことがあります。全関数にＡ４一枚の説明がありました。それを、ご丁寧にも関数のアルファベット順に並べてくれていて、シーケンシャルナンバーまで振っていたことがありました。主要な関数について、関数の主要な機能とか、引数の意味とか、特別に注意しなければならない個所だけを知りたかったのですが、分厚いファイル２冊も渡されて、見た瞬間に、「これは無駄だ。裏が白紙だから、裏返してプリント出力にでも使おうか」と思ってしまいました。でも、仕事が終わったら返却しなければならないので、さすが裏紙として使うことはしませんでした。

でも、この1000ページものドキュメント、どうも私が、「何かドキュメントはありませんか」と言ってから作ったらしいのです。もちろん、今まで受託して作業をしていた別のソフトハウスが作ったのですが、なかなか大変だったろうと思います。でも、全く役に立ちませんでした。経理部門が見たら、分厚い２冊のファイルを見て、立派なドキュメントと思うかも知れませんが、全く役に立たなかったのです。

■ 楽するように

今まで多数の人のプログラムを見てきました。動かないから面倒を見てくれ（実際は尻拭い）と言われて人のプログラムをデバッグしたり、その他色々のことをしてきました。プログラミング診断室の連載も同じですが、とにかく下手な人は、ものすごい努力をしてプログラミングし、デバッグして悩んでいるのです。

手間のかかるように、手間のかかるようにとプログラムしています。わざわざ作らなくてもシステムが標準で提供しているものを自作し、バグを入れて四苦八苦していたりします。信じられないような何千行にもおよぶ長大な関数を作ってデバッグしていることもあります。

見ていると、とにかく「作る」ということだけにしか注意がいっていないのです。作業をしていること自体、悩んでいること自体が仕事になっている場合が多いのです。実際に希望のシステムを作り上げるうえで発生する問題点とかの調査とかに頭がいっていなくて、最後の最後に、設計の最も基本的な部分が変だったというのがあります。ここで廃棄し、再設計すればまだ救われるのですが、完全に間違った設計を何とか生かそうとして、プログラムのあちこちにツギを当てて、苦労に苦労をして、結果としては保守できない奇怪なプログラムを作り上げています。

私は、プログラミングで一番重要なことは「楽をすること」だと思っています。それも、あらゆる面で楽をすべきだと思っています。プログラムはできることなら短く、もしもプログラムを組まなくて済むのなら組まないべきでしょう。何かしようとしたとき、すぐにＣでプログラムを組むというのは考え物です。特に、ウィンドウシステムに関連するような場合、良く調べると何もしなければちゃんと動くものを、わざわざいっぱいプログラムを書いたために動作しなくなる例がよくあります。

「関数は短く」と何度も書いていますが、これも本質はプログラムが楽に読みとれるようにするためです。

「同じことを書くな」は、同じことを何度も書くと、たとえエディタでコピーしても、後日の保守はもとより、デバッグ中にバグを見つけて何個所も直すという作業をしたくないためです。

プログラムを打ち込むときも、できるだけキー入力を省きたいものです。これは変数名を短くとかではなく、変数名は打ち込まず、画面上に表示されている宣言部分の変数名をマウスを使ってコピーするようにしたいですね。こうすれば、長い名前もなんのそので、入力ミスはなくなるし、変数名自体に意味を持たせられるので楽できます。

とにかく、プログラム、システム設計の基本は楽をすることにあります。それも、トータルで見て楽になるようにすることです。「楽する」という観点から考えてみると、正しい選択を得られるものです。

単純に単純にと設計していても、なんだかんだと要求が入ってきて、あれこれ対応しているうちに複雑になるものです。とにかく、単純明解、楽すれば楽ありです。楽するための勉強をしましょう。人がヒーヒーいいながらプログラムを組んでいる隣で、楽をして成果をあげられるようになると楽しくありませんか。優越感も味わえますしね。

■ 手抜きと下手の違い

良くないプログラムに２種類あります。

１つは手抜きのプログラムです。プログラムのことがよく分かっている者でも、１度しか使わないプログラムとか、動作確認のためだけとか、とにかく数時間で作り上げなければ作ること自体が無意味になるような場合には手抜きのプログラムを作ります。プロのプログラムだって、メンテナンスのまったく必要のないときには、徹底的に手抜きのプログラムを作ります。ただし、元々腕がよいのですが、理由があって手を抜いているわけです。したがって、プログラムの筋はよく、何をやろうとしているのか見当もつかないということはありません。

もう１つは、下手なプログラムです。コンピュータシステム全体のこととか、プログラミング言語の理解不足、経験不足などにより、やるべきことを理解できないまま書き上げたプログラムです。ムダが非常に多く、プログラムが混乱していて、何をやろうとしているのか読み取れないものです。自分で書いたプログラムの面倒を自分でできないでいるのです。

この２つは全く違います。よく「汚いプログラム」という言い方をします。この場合は、だいたい下手なプログラムを意味しています。下手なプログラムに対して「汚い」と指摘すると、時間がないからとか、忙しかったからとか理由をつけますが、それならば手を抜けば良いのです。上手がいくら手を抜いても下手なプログラムを作れるわけではありません。上手が手を抜いたプログラムは手元にいっぱいあるのですが、診断室の対象になるような汚さはありませんでした。上手が下手のふりをして下手なプログラムをねつ造しても、うまくねつ造できません。上手な者には下手な者のまねをするのは困難です。

「汚い」というのにも、様々なパターンがあります。ソースリストが見かけ上ぐちゃぐちゃしている程度のから、設計そのものが完全におかしいのではないか、全部廃棄して作り直す以外に手はないものまであります。全部廃棄して作り直すにしても、どうして完全な再作成をすべきかを理解しないままで作業すると、結局同程度のものができることになります。これは指導するときに非常に注意しなければいけないことです。細かい点をいっぱい指導するより、重要などうしようもない点を１つ２つ指導すれば、見違えるようなプログラムを作ってくるはずです。

診断室では、下手の下手たる本質をできるだけ研究し、まとめようとしたものです。下手にも色々な種類があり、救える者もいれば、もう救い難い者もいっぱいいます。自ら上手になろうと努力している者が救われるだけでしょう。

■ 開院

さて、そろそろ開院です。いくら文章を書き並べて、正しいプログラミング作法の講義をしても訴えるものがなく、眠けを催す本をまた１冊世に送り出すことになってしまいます。医学においても、実際の生身の患者を相手に臨床実習を行ない、現実の切実な問題に対処できて始めて一人前の医者なり看護婦なりになれるのです。これは、医学とか、コンピュータとかに限ったことではないでしょう。あらゆる分野で、実習は最も価値のある教育現場です。

本書では、実際に仕事で使うために書かれた、つまり必要だから書いたプログラムに対して診断を行なっています。できるだけプログラムは全体を掲載するようにしました。直接問題になっている一部だけ見せて、その直し方、治療方法を示しても、それでは現実の世界を反映したことにはなりません。できるだけ作成者の本来の意図を反映した形で元のプログラム全体を書き換えることで、部分的ではない修正方法を示すように努力しました。

本書で示している修正は、完璧をめざしてはいません。完璧などめざしたら、ついついプログラム全体を破棄して、奇麗に書き換えてしまいたくなってしまいます。私も一人の人間だし、完璧なプログラムなどそうそう書ける訳ではありません。しかし、十分に納得できるようなプログラムの修正方法を、私が現場で作業している情況に近い形で示しました。本当は、ビデオで提供できたらもっと良かったかも知れませんが、そうもいかないので紙上で説明しました。

これだけ色々書いて心の準備をしていただいたので、どんなプログラムを見ても卒倒などしないと思います。では、診察を開始することにいたしましょう。

私は、ＵＮＩＸ上で仕事をし、この原稿も書いています。読者から送られてきたＣプログラムもＵＮＩＸのファイルに変換して評価しています。ＭＳ－ＤＯＳに強力に依存していないものは、ＵＮＩＸ上のＧＣＣでコンパイルし、実行して動作確認も行なっています。こういう環境で作業をしている関係で、ＵＮＩＸ上ではあまり都合の良くない半角カタカナは全角カタカナに変換しています。とくに、パソコン上でないと評価できないプログラムは、ＭＳ－Ｃで評価しました。

■参考文献

[0-1]「こちら救命センター／病棟こぼれ話」、浜辺祐一、集英社文庫

『Ｃプログラミング診断室』目次／次（第１章　普通の初心者　プログラムの紹介）
第１章　普通の初心者
上手になる秘訣
上手になるには、上手な師匠につくことが一番ですが、周りにＣをちゃんと教えてくれる人がいない場合も多いでしょう。大都市に住んでいる場合や、大企業の技術者の場合は、その気で探せば結構身近にいるものです。でも、そうでない人にとっては、本や雑誌くらいしか情報がないといえます。パソコン通信を利用するのも手ですが、やはり直接教えてもらう方が優れています。

プログラムを教えてもらうには、まず、自分でプログラムをどんどん書いてください。たぶん、いっぱい失敗をするでしょう。原因の大部分は自分だけで分かるでしょうが、どうしても分からない個所はよく知っている人に聞いてみましょう。

すでにＣでプログラムを組んでいる人は、ソースプログラムを診断してもらってください。できれば、何万行、何十万行のＣプログラム開発経験がある人ならば最高です。でも、「ひどいプログラムだ」と言われるのが普通でしょう。どこが下手なのか、じっくりと聞き出してください。初心者のうちは、上級者の言うことは理解不能な内容も多いですが、できるだけ理解するように努力しましょう。最初は理解できなくても、そのうちできるようになる時期がきます。

自分のプログラムを人に見せると同時に、人のプログラム、できれば優秀なプログラムをできるだけ見て参考にしてください。今では、Ｃで書かれたＰＤＳがいっぱいあるので、入手は比較的簡単ですね。

Ｃの本はいっぱいありますが、Ｃの勉強そのものを目的にした本は、どうしても細部にこだわったものが多く、表面的な知識や技術に終わってしまいがちです。本はいっぱい読んでください。効率良くノウハウを身につけられます。でも、本だけに頼るのは危険です。

本を読み、自分でプログラムも組み、そのプログラムを人に見せて批評してもらい、人のプログラムも読んでください。これだけすれば、絶対上達するはずです。

あるパソコンソフトハウスでの話です。Ｃプログラム経験が何年あっても、すごく下手なプログラムを書いている人たちがいました。彼らは、自分たちのソースプログラムをできるだけ隠し、誰にもソースを見られないよう努力していたのでした。グループ内部にもＣの得意な人もいず、外部に教育やコンサルティングも依頼しなかったため、あまり分からないままＣのプログラムの量だけが肥大していきました。初期にちゃんとした指導がなされていたら、いったい何十人年（何億円）の節約になったことでしょう。