プログラミングの指導をするとき、一番困るのが、自分のプログラムリスト を隠すことです。もちろん、自分の書いたプログラムに自信がないから隠すの でしょうが、隠せば隠すほど誰からもプログラムの手ほどきを受けられなくな ります。
プログラムは、プロジェクト単位とか、部署単位で自由に見ることができる ようにしておいたほうが、色々な問題点を指摘し合えて、互いに向上の機会が あります。プログラムを誰でも自由に書き換えられるようにしておくと、今度 は管理上の問題がありますので、プログラムの管理ツールを用い、見ることは 自由にできるが、変更は作成者など許可された人だけが変更可能にしておくこ とが必要です。
以前、某社のコンピュータ教育を担当したことがあるのですが、とにかく一 部の人を除いて自分の書いたプログラムを人に見せないので困りました。どう いう風にプログラムを組めば良いかをいくら説明したって、一般論になってし まいます。何を説明しようが、机上の空論、眠けを催す講義にしかなりません。 各人のプログラムの組み方には差があるので、実際に各人の作ったプログラム を使い、悪い点を指摘することが重要です。
この会社では、プログラムを見せないことが一般化し、最終的に動けば内部 はどうなっていても誰も知らないような情況でした。最初は、動けば良いと気 楽に言っていられるのですが、時間が経つとともに次第に混乱が発生してきて、 泥沼に陥っていました。
もちろん、技術者全員が隠そうとしていた訳ではありません。新人や、技術 的なことに興味を持っている一部の人達は相談に来たりするのですが、会社の 上層部あるいは古株の人達が隠したがるのです。今まで作ってきたものに、重 大な欠陥が指摘されたら困るのは分かるのですが、欠陥が分からずに、どんど ん変なプログラムが増えていく方が、長期的には大変に決まっているのですが、 分かっていても自分の立場などもあり、最善の選択が何かが分かっていても取 れないのが実情のようです。
逆の会社もありました。プログラムを見せたがって、ぜひプログラム診断室 の連載に採用して欲しいというところです。社内で独自に研究会を開いたり、 社外の人を呼んでプログラムコンテストまでやっていた会社です。私も部外者 ながら参加して、賞品をいただきました。この会社のプログラムは、残念なが ら、下手なプログラムが発見できず、診断室には利用できませんでした。
大きなプログラムを複数の会社で共同開発することがあります。これは、プ ログラムを作る以上に、各社の体制の違い、レベルの違いに苦労させられます。 人数が増えるだけでも色々なトラブルが発生するものですが、会社まで異なる と調整は一段と難しくなります。大規模なソフトを複数の会社に分割して発注 しているところは、さぞ管理が大変だろうと思います。
こういうとき、だいたい苦労させられるのは、レベルの高い方で、低い方は ついてくるだけ、ということが多いのです。下手をすると、別の下請けの作っ たプログラムのバグ取りまでさせられることにもなりかねません。正直言って、 足手まといです。日本では取引関係のしがらみで、一度発注すると、切るに切 れない下請けとの関係になったり、とにかく諸般の事情があって、理屈だけで は割り切れないようです。色々の問題点を教えて、もっと楽をして、より品質 の良いプログラムを作り、発注側も、受注側もハッピーになるようにと思って も、難しいのが現実ですね。
昔々、小さなソフトハウスに身を置いていたころ、なんとか社内の技術レベ ルを上げようということで、発生したトラブルを社内ミーティングのときに発 表する制度がありました。いちいち些細なミスまで発表されるときりがなくな るので、バグの原因発見まで３０分以上のものを発表するようにしました。あ る人の陥るバグには、他の人も陥りやすいし、また似たような場面に遭遇する こともあるので、そういう場合に役立てようとしたのです。もう遠い昔のこと で内容は覚えていませんが、各自の馬鹿さを発表することにより、随分楽しめ たし、互いのレベルも向上したように思います。
日本では、プログラムに限らず、都合の悪いことはできるだけ隠そうとする 傾向があります。隠すことによって、その場は何とか取り繕うことはできるで しょうが、将来同様のトラブルが起こったとき、前回の経験が生かせません。 トラブルにみんなで対処することにより、よりよい対策を打つことができ、ひ いては被害を最小限に抑えられます。これこそ教育のはずです。けれども、こ ういうことを指導すべき教育機関、そしてそれらを管理指導している教育委員 会とか行政機関に隠す傾向が特に高いのは、いったいどういうことなのでしょ うか。
