最初にも述べたように、この「Good Enough」には、ソフトウェアの開発組織のマネージャーを魅了するものを持っています。しかしながら、未熟な組織にあっては、その言葉の響きや香りは、関係者の体をしびれさせ、思考をマヒさせる力を持っています。この素晴らしい「薬」は、飲む人によっては「劇薬」ともなってしまうのです。
現実のソフトウェアの開発状況や「ISO 9000」への取り組みを通して、今の日本のソフトウェア開発組織の状況を考えると、「Good Enough」は劇薬になる危険性の方が高いと思われます。
今から約２０年前、この国に一つの「言葉」が行き渡ったのを、私はこの目で目撃しました。それは『ソフトウェアにはバグは付き物』という言葉です。当時、毎日バグに追い回されていたソフトウェア・エンジニアの多くは、この言葉に飛び付きました。“そうなんだ。ソフトウェアのバグは無くせないのだ”と、まるで、バグが無くならないのは自分たちの所為ではないとでも言うかのように、この言葉を盾にとったのです。そしてバグを根絶するための努力を放棄してしまいました。これは実際に私の目の前で展開されたのです。
３０年間ソフトウェア開発の世界に携わってきて、これまで２回、日本のソフトウェア・エンジニアの質が落ちた時期があります。それは「派遣」という制度が導入されたときと、この「バグは付き物」という言葉が流行したときです。前者は通産省の出した、情報処理技術者が数１０万人不足するという根拠の薄い安易な予測を背景にして成立した制度で、これによって禄に訓練も受けていないエンジニア？が、大量に集められ景気の拡大の波に乗って各社に派遣されたのですが、同時に、ソフトウェア・エンジニアの質を一気に落としてしまいました。
もう一つの「バグは付き物」の流行の方は、これによってバグを根絶するための工夫が途絶えてしまったのです。当時、私の周りで、構造化手法を本気で勉強していた人は他には一人も居ませんでした。構造化プログラミングに始まり、構造化設計、構造化分析と、今のオブジェクト指向と比べると、比較的まとまった内容で順次公表されていましたので、それをきっちりと追いかけて身に付けていけば良かったのですが、誰もそこに手をつける人はいませんでしした。
そのほか、組み込みシステムに於けるリアルタイム・モニターの効果的な使い方や、徹底した分析によってグローバル・データを出さない為の工夫など、バグを発生させないための工夫に本気で取り組んでいた人は、他には誰も居ませんでした。「ソフトウェアにバグは付き物」という言葉が、凡庸なソフトウェアを作る言い訳に使われてしまったのです。
そして「Good Enough」もまた、「バグは付き物」という言葉と同じように、今日の疲弊したソフトウェア・エンジニアの心の隙間に入り込んでいく危険があります。「ソフトウェアのバグなんて、簡単には無くならない」という言葉の響きと、「これでも問題ないじゃない」という言葉の響きが、とてもよく似ているのです。
日常の作業に追われている状況にあっては、オブジェクト指向の分析手法を身に付けるのは簡単ではありません。いや殆ど絶望的と言えるでしょう。そのうえ、「ＣＭＭ」の考え方も身に付けていないとなると、おそらく、約束できる状態で仕事をしていることはないと思われます。そうなると、必然的に“遅れ気味”の開発に追いまくられることになり、「藁をもすがる」思いに陥る危険性が高くなります。そうなると、「Good Enough」は、かっての「バグは付き物」と同じように、凡庸なソフトウェアを作る言い訳に使われてしまう危険があるのです。
かって、この国では「バグは付き物」ということを言い訳にして凡庸なシステムを作ってしまいました。そして凡庸なソフトウェア・システムしか作ることが出来ないことによる、精神的、肉体的疲弊が、未だに「３５歳定年」が存在し続けている背景の一つなのです。
（インデックスに戻るときはウィンドウをクローズしてください）
我が国は、少なくとも明治維新以来、欧米の文化や分明の「表面」を輸入してきました。特に戦後は復興に急ぐ余り、目に見えるものを中心に輸入され、日本の企業もそれを模倣して行った。テレビやビデオなども、元は外国製品である。日本の小売業態を変えたコンビニや新しい映画館などの「ソフト製品」も輸入されたが、実際にそのような「製品」を産み出す「背景」は輸入されないままです。
つまり、新しいルールを考え出すことに意義を見出す社会環境や、それを支援し評価する社会の仕組み等は入ってきていません。もちろん、このようなものは、そう簡単に持って来ることはできないかも知れませんが、教育やルール、価値観や報酬などを変えていくことで、そのような社会基盤をつくることが出来るようになるはずです。授業に付いていけない学生の為に４１％の大学で特別クラスの編成が行なわれている（日経新聞11/16）という事実は、我が国には優れた者が評価される社会の仕組みが存在しないことを物語ってもいます。
最近では、「ビッグバン」に「エージェンシー」という「制度」や「仕組み」をイギリスから“輸入”しようとしていますが、これも、このような仕組みを考え出す「元」を仕掛けなければ、何時まで経っても自分の田畑からは何も生えてこないでしょう。
これらと同じように、「Good Enough」もまた、それを産みだす背景を残したまま、表面に現れた「制度」だけを輸入してしまう危険があります。「Good Enough」は「ＣＭＭ」のレベル３をベースにすることで、継続的に実現できるはずですし、先ずそちらを目指すべきなのです。
しかしながら、我が国はどうしても、表面に囚われてしまう傾向があります。「ISO 9000」に対する最近の企業の行動をみても、同じような傾向が窺えます。「ISO 9000」は、ある丘の上に立てられた「旗」であり、これを取得するということは、その企業は「そのレベルに居る」ことを証明するもののはずなのに、実際にはジャンプして「そのレベルに飛び付いた」結果として取得しているのです。
つまり、それは「普段の能力」ではないため、その「レベル」を維持するために実際の作業とは別に“ジャンプ”し続けなければならないということを意味します。「ISO 9000」も「ＣＭＭ」のレベル３で、無理なく認定を受けることが出来るはずです。そしてその後も、“ジャンプ”することなく、通常の活動を続ければ「ISO 9000」は更新出来るのです。実際、アメリカでは「ISO 9000」を追うのではなく、「ＣＭＭ」のレベル３を目指す動きに変わっています。
では我が国ではどうしてこのような問題が起きてしまうのかというと、「ISO 9000」は「ゴール」を示しているだけで、そこ至る道筋は何も示して居ないからです。その道筋を探すという行為は、文化としてアメリカやヨーロッパには根付いているため、わざわざ「ISO 9000」で示す必要はないのでしょう。これにたいして、「ＣＭＭ」は、その顧客（国防総省）の要求もあって、入札業者のレベル確保の為に、業者がレベルをアップするステップを示す必要があったのです。
しかしながら、日本にはそのような目標に至る道筋を探し、そこに幾つかの「ゴール（＝マイルストーン）」を設定し、それを日常の目標にするという文化はありません。あるのは、最終目標に向かって、手段を無視してひたすら進むという「２０３高地型」の行動だけです。したがってベースが上がっていないために、直に元に戻ってしまうのです。
「今期の売上目標」という「目標」も、我が国では、それを恒常的に実現する方法や状態を考えるのではなく、兎に角、なんでもいいからそれを達することに集中します。「売上」が「利益」に変わっても同じことでしたし、新しく「ＲＯＥ」に変わっても同じことが繰り返されるでしょう。
このような文化を背景に持つ中に、不用意に「Good Enough」を持ち込んでしまったら、殆ど１００％本来の主旨を損ねた形で、これを追うことになるでしょう。
（インデックスに戻るときはウィンドウをクローズしてください）
ここで認識して欲しいのは、「Good Enough」を認めるかどうかは市場が決めるということです。おそらく、突然「Good Enough」という考え方を提示していたら、市場は受け入れなかったかもしれません。しかしながら、ここに至る前に、「Statistical Testing」や「ＣＭＭ」という、品質を支援する方法や環境が整備され、ソフトウェアに信頼性の考え方を持ち込むことに成功し、さらに品質保証が可能となったことなどで、「Good Enough」を受け入れる環境が整ったということです。したがって、それらの環境が整備されていない状況では、「Good Enough」という考え方は成立しないことになります。
今日、「Good Enough」が受け入れられつつあるというのも、長年にわたって「Statistical Testing」や「ＣＭＭ」など、ユーザーの視点に立って品質を改善する取り組みが、一定の成果を上げてきたからであり、それをを市場が認めつつあるということです。
したがって、ここで気をつけなければならないのは、「Good Enough」に叶っているかどうかを判断するのも、あるいは、その開発組織が「Good Enough」を選択することを認めるのも、「市場」であり「顧客」であるということです。決して、開発者の勝手な都合で、この判断をしてはならないということです。
開発者の能力の不足によって、要求されたものが実現できなくなったとき、一般に「トレードオフ」の交渉に入ったり、納期の延長の交渉が行われます。発注側も、そこまで来ている以上、今更開発者を入れ換えることも出来ず、結局、延長に応じたり、トレードオフに応じるしかないという判断を選ぶことになるのですが、これと同じ論法で開発者が「Good Enough」を使ってはならないということです。あくまでも、市場や顧客が判断することなのです。
その製品に要求されている「機能」や「品質」「タイムリー性」「コスト」がどの程度のものか、市場は知っています。それが実現できる（はずの）ものかどうかも知っています。したがって、その開発組織が、それらをどのように実現しようか心を砕いて、工夫しているか、市場は知っています。自分たちの手抜きや能力のなさを「Good Enough」で隠そうとしているのかどうかも、知っています。
一つでも、そのような不心得な事例が世の中に出てしまうと、市場は「Good Enough」は“悪い考え”として排除してしまう可能性があります。そうなると、消費者は高いコストを払わされることになります。
「Good Enough」が「凡庸なソフトを作る言い訳」に使われないためにも、ソフトウェア開発の関係者は、「市場の判断」を決して曲げないようにしてほしいと思います。
（インデックスに戻るときはウィンドウをクローズしてください）
この点については、ヨードンの著書にも書かれていますので、簡単に紹介だけしておきます。
言うまでもなく、「Good Enough」には「バグ」が含まれていることが想定されています。しかしながら１件のバグも許されない製品もあります。高度な医療用の装置や、ペースメーカーなどの体内に埋め込むような装置などは、１件のバグもあって欲しくないし、「Good Enough」と言う考え方を導入して欲しくはありません。また、航空機や管制用のソフトもそうです。人工衛星などのソフトも１件のバグによって、目の飛び出るほどの開発コストをドブに捨てる結果となります。
通信のインフラに関するソフトも「Good Enough」の対象外にすべきでしょうし、電力やガスなどの社会基盤の管理システムも、バグを認めたくありません。
ロボットなども、その使い道によっては、人命に関わる可能性もありますし、近い将来に実現しそうなロボットによる自動運航システムなども、１件のバグが大混乱を引き起こす可能性があります。
このようなシステムに於ては、今後も「Good Enough」の考え方が入る余地はないと考えられます。したがって、そのようなシステムの開発に従事するエンジニアの人たちは、今後も「完全」を目指す技術を探求して欲しいものです。
（インデックスに戻るときはウィンドウをクローズしてください）