多くのソフトウェアの開発組織では、ソフトウェア・エラー（以下バグと呼ぶ）の対処の仕方を間違えています。それらの組織では、発見されたバグに対して、その「原因＝発症の仕組み」を解明し、それが発症しないように修正することでバグの対応は終わったことになっていますが、原理１２５は、それだけに止まってはならないことを指摘しているのです。
バグはソフトウェアの開発に携わる人たちの手で、無意識のうちにプログラムの中に織り込まれるのです。にも関わらず、バグの所在を確認して、それを取り除くだけで作業は終了しているのです。
でも、これは本当に解決したのではありません。その証拠に、そのような開発組織では、何度も同じバグを出すはずです。関係者も同じで、何度も経験している筈なのに、何度も同じ性質のバグを埋め込んでしまうのです。
故意にバグを埋め込む人などいません。それなのにバグはまた入り込んでしまうのです。それは、これまでの対応が、本当の原因に及んでいなかったことを意味します。
もっと徹底的にバグが“入り込んだ本当の原因”を分析する必要があります。そのような結果になる原因の一つは、「原因」という言葉の使い方にあります。バグが発症する仕組みに対して「原因」という言葉を使ってしまったため、別の所に本当の「原因」があることに考えが及ばないのです。
“だれも君を呼んだ覚えもないのに、どうして厚かましく家の中に入ってくるの！”と彼は叫ぶ。でも間違いなくバグ達の手元には、“ビッグバン”の当日
― それは大勢の開発者のプログラムが初めて一堂に集まって一斉に披露される日
― の「招待状」があるのです。
開発者の誰も彼らを呼んだつもりはありません。だって誰もバグ達の住所を知らないのですから。でも確かに、家の中や、庭のあちこちに大勢のバグ達が来ています。
あッ？、去年の秋に植えたあの新種のシークレットというバラの木の陰に佇んでいるのもバグではないか？ 花の色によく似た服装をしているので見分けがつかないよ。あ〜ぁこれでは一体、何人のバグ達が押しかけてきているのか分からないではないか。
それらの組織で行われていることは、バグ達を片っ端から追い出すこと、すなわち「テスト」という方法でバグをあぶり出し、見つけ次第につまみ出すのです。だが、バグ達は、まるで昆虫の保護色のように、周囲の色に溶け込んでいてなかなか見つからない。その上、一人のバグを追い出すのにてこずっていると、その隙に新しいバグが入り込んでしまう。今もバグを追い出したあとの隙間を塞ぐために新しく植えられた植木に二人潜んでいるのに誰も気付いていない。まったく油断も隙もない！
こうして、やっとの思いでバグ達を追い払ったとしても、本当に全員追い払ったのかどうか分からないのです。もっとも、彼らだって自分からノコノコ動きだすことはありません。わざわざ西の部屋に備え付けの上から３番目の引き出し
― そういえば、この引き出しは一度も開けていなかった！ ― を開けない限り動きだすことはないのです。だが、いつかそのことを知らない人が来て、その引き出しを開けたらどうしよう。
１ヵ月後、彼は次の仕事に忙しく走り回って、３番目の引き出しのことなどすっかり忘れてしまっているのです。まるで何事もなかったかのように。そしてこのパターンは、ここ５年以上続いているのです。
彼はバグを再現させながらプログラムの流れを追跡するのです。そしてやっとの思いで、渡されたパラメータのチェックが抜けていたことに気付き、パラーメータの正当性のチェックを追加します。その後、もう一度同じデータを流してみて、発症しなくなったことを確認しておしまいとなるのです。
多くの開発組織では、これでバグに対処したことになっています。でも彼は、「どうしてあの時、パラメータをチェックしなかったのか」ということの原因（本当の原因）を解明していません。彼が解明したのは発症の仕組みであって、バグが入り込んだ原因ではありません。
こうして彼は、前の“出来事”は全て忘れ（解決したのですから）、３ヵ月後には次のプロジェクトで忙しい思いをしていることでしょう。そのとき、“このパラメータはチェックした方がいいのかな”“いや、チェックしたらエラーコードを決めなくちゃならないし．．．”というフレーズが頭の中を、一瞬駆け抜けたことに気付きませんでした。
それから１ヵ月後・・・４日間の格闘の結果、あるパラメータの正当性のチェックを追加しなければならないことを「発見」して、最後？までてこずったバグを解決するのです。もちろん半年前とは別の関数です。
バグが入り込んだ本当の原因は、パラメータをチェックするかどうかが、一人ひとりの判断に任されている組織の体制であり、その時点でエラーコードが決められていない作業の手順であり、さらに言えば、彼にそこで“まぁいいや！”と言わしめた職場の文化なのです。おそらく、彼は「設計」を飛ばして、直ちにコーディングの作業に入っているものと思われます。
バグは、一連の作業が上手く流れていない結果として招き入れられているのです。したがって、結果を変えたければ過程、すなわちプロセスを変えなければなりません。
ソフトウェア開発に於けるプロセスとしては、組織の体制や作業手順、さらには各人の発想パターンがそれに該当します。これらが同じである限り、同じようなバグが入り込むのです。特に明確な作業手順を持たない開発組織の場合、各人の思考パターンがプロセスの大きな割合を占めてしまいます。
バグ発症の仕組みが、パラメータのチェック漏れにあると判明した場合も、なぜチェックが為されなかったのか、さらにはどうして最初に設計書が書かれなかったのかが問われなければなりません。原理１２５で言う＜徹底的に分析＞するということは、こういうことを指します。そうして初めて、どうすれば設計書が書けるのか、どうすればレビューが出来るのかといったプロセスの改善に至ることが出来るのです。
そうやって本当の原因に至れば、殆どの場合、何らかのプロセスが変更される筈です。前回と同じやり方では無くなっているはずです。一度で解決しないかもしれませんが、それは「原因」だと思われたことが、実は別の原因の結果であった場合であり、今度はそこまで徹底的に分析されることでしょう。
こうした本当の原因に至らないかぎり、同じような性質のバグが毎回侵入してくるのです。そしてそのような組織では「ソフトウェアの開発は、誰がやってもこんなもんだ。バグなんて無くならない」という神話すら成立させてしまうのです。
もし、そのような神話が本当に成立するならば、「クリーンルーム手法」は成立しないでしょうし、欠陥率を
3.4/1000000 にするという「６Σ」なる手法も成立しないことになります。だが現実に、その２つの手法とも成立しているのです。
要するに、やり方が悪いだけです。そしてこの問題を解決しない限り、日本のソフトウェア開発は間違いなく行き詰まるでしょう。
（次号へ続く）
“いじめ”が深刻化する中で、文部省の依託を受けた審議会が、「二年」の審議を経て“いじめ”対策の最終報告を発表した。報告書の副題からして、これ以上の対策は考えられないとも受け取れる。新聞に発表された内容を読んでみると、加害者に対しては、学校への登校を見合わせるように指導できるようにする一方で、被害者に対しては、緊急避難的に欠席を認めるという形になっている。確かに今までとは違って「柔軟」な姿勢を見せている。
これに対して、家庭については“しつけ”と子供の状態をチェックすることを求めているが、核家族化に伴って家庭の中で子供が取り残される状態は、社会的経済的変化であって簡単に元に戻るものではない。言い換えれば構造的な問題である。問題が社会の仕組み的、構造的な問題である以上、答えも仕組み的・構造的なものでなければならない。
！ ？ ！
今までのいじめの事件をみていると、学校側は“いじめ”の実体を認識していないケースが多い。十二、三歳の子供が死を選択するに至ったにもかかわらず、いじめの実体は存在せず、当人の思い過ごしではないかという発表まで出る始末である。現実がこのような状態である限り、その学校には犠牲者が出るまで被害者や加害者そのものが「存在しない」ことになる。
このことは、今回の報告書の大きな欠陥の一つである。審議官が何処に立ってこの問題を検討したかが問われる。
！ ？ ！
実際に子供を学校に通わせてみて分かることは、学校の教師の対応に、“いじめ”の原形の一つを感じることがある。普段の授業中や、クラブ活動の場で特定の生徒を「無視」したり、皆の前で恥をかかせたりすることがある。教師の方は“いじめ”ている意識はないかも知れないが、本人は“いじめ”られていると認識している。逆にいじめている意識がないだけに厄介である。
！ ？ ！
たとえ“いじめ”の実体が明らかになって、その対応として「欠席」や「転校」が認められたとして、それで一体何が解決するのだろうか。確かに「暴力」からは一時的に逃れることは出来るかも知れないが、この生徒が学校で授業を受ける権利はどこにも省みられていない。そのような生徒にとっては「自分は何も悪くないのに、どうして自分が逃げなくてはならないのか、という問題が彼の心に一生残りはしないか。
「転校」も簡単にはできない。単に学校を変えただけでは、普段の生活範囲で双方が顔を合わせる危険がある。実際にそのような状況で命をなくした生徒もいる。「転校」はその家庭の生活環境を変えなければならず、これも不合理な話である。
報告書はこられの問題に対しては「中学校卒業程度認定試験」しか示していない。これは救済措置であって、問題の解決にはならない。
！ ？ ！
“いじめ”は「個」の存在が認められない組織で必ず起こる。一つの「枠」にはめようとする組織では避けられない。その意味では、学校の生徒に限られたものでもない。職員室にも、一般の企業の職場にも起きている。その結果、その職場に残った人は同じ行動パターンを持った人になってしまう。この国は、全員が同じ方向を向くことを求めてきた。だがこのままでは「個」は存在できないし、そのような社会から“いじめ”は消えることはないだろう。
！ ？ ！
国際金融の専門家でリチャード・クーと言う人がいる。氏が家庭の事情で米国に行くことになり、それに備えてアメリカン・スクールに転校したが、そこで体験したことが著書の中に書かれているので、その一部を紹介する。
『本当なら、中学一年に編入するはずだったが、英語ができないので小学校の五年生に入れられた。（中略）ところがアメリカン・スクールは、英語が出来ない、人種も違う私にとって想像を絶するほどの天国だった。（中略）アメリカン・スクールは私を全く一人の人間として扱ってくれたのである。
アメリカン・スクールでの体育は野球をやることが多かった。クラスにはケネス君という運動神経が鈍く、いつもばたばた歩いて、少し女っぽいところもある少年がいた。（中略）驚いたのは、野球のゲームが始まって、ケネス君の打順が回ってきたときである。二塁に一人いる。日本の小学校だったら、バットもまともに振れないケネス君にすぐ代打、ということになったに違いない。ところが、クラスのキャプテン格のクリス・ワーグナー君は、代打を出さなかった。それどころか「頑張れ、頑張れ」と大声で応援した。しかもチーム全員が応援した。当然ケネス君は三振する。しかし、みんなが彼に寄っていって「ナイストライ、ナイストライ」と本心で言ったのである。こんな光景はそれまで一回も見たことがなかった。』
？ ！ ？
今、いじめを受けている子供たちが求めているのは、このような学校（世界）ではないのか。これが「欠席」や「転校」を認めたり、加害者の児童に登校自粛を求めるところから得られる世界なのだろうか。
一体この国の学校は子供達に何を与えようというのだろうか。 ■
平尾氏は神戸製鋼入社三年目にしてキャプテンに就任した。当時神戸製鋼は既に監督制を廃止し、キャプテンを中心とした選手達の自主運営に移行していた。
だが、自主運営すれば全てうまく行くほど現実は甘くはない。東芝府中によもやの一回戦敗退し、その年は普通の人と同じ正月を送ったのを機に、入社三年目の超若手がキャプテンに就任したのである。当時では異例のバックスからの抜擢であった。
平尾氏は神戸製鋼入社前の一年間、イギリスの名門クラブチームで、厳しいが合理的で楽しめる「ラグビー」を体に叩き込んできている。彼はそれをチームに移植するのであるが、彼の目指すラグビーは、それまでのフォワードの突進を中心としたラグビーとはまるで違うのである。そのため、先輩たちの意識を変えるために苦労したという。
こうして、その年の三洋電機戦で、あの華麗な「神鋼ラグビー」がお目見えするのである。この試合が、「七連破」の始まりであった。
平尾氏は「チームリーダーは三○％の謎」が必要だという。「何のために、こんな練習をするのか」という疑問を感じさせる部分が三〇％必要で、それが選手達にとって興味となり、納得することで前進するという。こうしてキャプテンのイメージするチームが作られていく。
だが、三年目に、彼はキャプテンの座を譲った。それは「創造的な破壊」を絶やさないために決断されたことであった。