プリウスの問題と、テスト実施結果からみた、リリースの判断基準について

ひえー！、下の記事、すごいっす！


トヨタはユーザーをハイブリッドシステムの実験台にしているのか？
http://d.hatena.ne.jp/softether/20050501


トヨタのプリウス、走行中に「エラー」という話。
そのブログから、引用させていただきますと。。。


50km/h 前後で走行中、突然、プリウスの運転席左中央の液晶ディスプレイ（普段は燃費グラフなどが表示される場所）のところから、「ポーン！」という軽快な音と共に、右上のイメージ図のようなエラーメッセージが表示された。

前後にたくさん車がいて、全部同じくらいの速度で走行しているときにこういうエラーが出て、しかも前方が結構急な左カーブの下り坂なので、非常に焦った。

警告が表示されてから数秒すると、今度はアクセルをどんなに強く踏んでもプリウスが全く加速しなくなってきた。後続車が坂道を 50km/h で下ってくる中、自分だけ一生懸命アクセル踏んでも 20km/h くらいしか出ないのである。


これだけでも、あぶないのに、その記事の下のほうをみると


つくばに戻ってから、Web サイト等でハイブリッドシステムエラーに関する情報をいくつか発見する。かなり、走行中に突然コンピュータがエラーを吐いてプリウスが正常走行不能になって恐怖の体験をしたりした人が多いようである。これは危険。

しかもこのエラーの原因は様々で、初期型モデルのコンピュータのプログラムがおかしいらしいとか、電池の残量を監視するセンサーが故障してエラーになるらしいとか、色々な原因があって非常に複雑でトヨタの販売店の人もよくわからない状態らしい。

他にも、Web で探すと、プリウスの走行中のトラブルについて色々な事例やクレームが見つかる。その頻出度は他の普通の車種と比べて圧倒的に多い。


これって、やばくないっすかあ！プリウス、大丈夫なのかあ？？

---

　この記事のコメントで、ベータ版やリリースの話が出てました。
　プロダクトのマネージメントのまねごとをしたこともある、ウィリアムのいたずらの独断と偏見を言うと、

プロダクト（パッケージソフトとか）のリリースは、 テスト結果などからみて、ある程度の品質であれば、リリースしてかまわないと思う。

その「ある程度の品質」とは、 　ユーザーが払うお金と、 　適用分野などによってきまる。

　たとえば、フリーソフトで、適用分野が、ビジネス文書作成などの場合は、正常系が通っていれば、ベータならいいし、異常系に関しても、致命的なバグが見つからなければ、正規リリースでかまわないと思う。

　ただ、適用分野が、自動車のように、人命にかかわるものは別だ。フリーソフトでも、バグで、人が死ぬような事故になったら、もうアウトだ！そんなもん、リリースしてはいけません。

---

　たぶん、プリウスもリリース時、テスト内容はつぶして、大丈夫だったのだろう（だからリリースしたと思いたい）

　でも、想定の範囲外ということが起こりえる。

　たとえば、磁気、電波、交流電気（発電も含む）などを扱う場合、境界値のところで、思わぬエラーになるようなケース。
　部品によっては、寝ぼけていて、立ち上がりが狂ったりして、センサー部分ではタイムアウト寸前に、立ち上がりの信号を送っても、受け取り側で、タイムアウトと思ったり、信号が来ていないと判断されるなどというケースなどなど。
　この場合、部品の品質のばらつきなどの問題もからむので、テストでは、感知できないことがある。。。ということは、理解できる。

　したがって、想定外の致命的なことというのは、確かに起こりえる。
　こういうことが起こった場合、ソフトであれば、製品回収も含め、検討するということになろう。
　製品回収の場合、回収費用がすごいことになる。その資金的な手当てが出来るか？
　また、製品の問題点がわかって、修正完了していれば、売り物の置き換え（交換）ということで済むけど、問題点がわかっていないときなどは、品物を回収したら、もう、置くものがなくなってしまう。。。
　そのため、ソフトの場合は、いろいろ、高度な経営判断の問題となろう。

---

しかーーっし！！

　自動車の場合は、そーいうことを考えるまでもなく、リコールという制度があるのではないかあ！

　ここまで、問題があって、リコールにならないのだろうか？？

　だって、あぶなくないっすかあ、これ？？

「走行中に突然コンピュータがエラーを吐いてプリウスが正常走行不能」

これでも、リコールにならないのかしら。。。？？

まあ、初代の問題ということで、二代目以降は良くなってるんだろうけど？？
しかーし！！
ソフトの場合は、サイクルがはやいから、問題にならないけど、
車の場合、初代のプリウスに乗っている人、中古で買っちゃう人など、まだまだ
いるのではないだろうか。。。

あぶないっす。

結局、結論は、その記事と同じく

プリウスにはよく注意しましょう。

モーツアルトと、佐藤 江梨子の関係？？

　今日は、トヨタのプリウスと、テストとの関係を書きたかったんだけど、時間が無かったので、明日書きます。

　そこで、昨日の、技術者と作業員のブログに関して２つ。

１．「作業員」って、なんで、「作業員」って言う言い方？
　って、ずーっとおもってたんだけど、やっと気づいた。
　これ、よく、エラーいひとたちがいう、「ワーカー(worker)さん」の日本語訳っすね、きっと(^^;)なっとく！

２．この記事を見たのが、「みかまま」さんのところ（この日の、一番最後の記事）だったのですが、そこでの「みかまま」さんのコメントが


ただ、天才と凡才がいるだけ。モーツアルトとサリエリみたいな。適材適所というか、天才だけでも社会は回っていかないし、凡才だけでは発達はない。


　ここ、「モーツアルトと、サトエリ」と読んでしまい、モーツアルトと、佐藤江梨子？？たしかに、佐藤江梨子は、凡才だ。最近は、エステに通い詰めた結果、胸がしぼんだらしいし。。。でも、たしかに、佐藤江梨子は、必要かもしれん。。。でも、なんとなく、意味通じない？？

　と思って、今、よーく見たら

　　　　「モーツアルトとサリエリ」

　あ、トじゃなくって、リね！
　サリエリ！了解です！！

　ウィリアムのいたずらの無教養さが、よく分かるお話でした。

　では、あした、プリウスで！

64Kbpsの６４Kって、どっからきているか、知ってた？？

　ＩＳＤＮなんかで、６４Ｋｂｐｓ、とかあるじゃないですか（すごい言い方だけど）
　あの６４Ｋって、どっから来てるか、知ってました？
　ここをよんで、あたしゃーはじめて、しりました。

今は、技術者と作業員？昔はソフト業界に、３種類の人がいた気がする

　うーん、フリーのSEとはいえ、ぷー太郎に近いようなウィリアムのいたずらが、この業界を代表するような、雲の上の人である、ソフトイーサ株式会社の登社長のブログにたいして、ツッコミを入れることは、不謹慎きわまりないことかもしれないけど。。。
　まあ、本人は見てないだろうから、いいか（いいんかい？？）ということで。。。。

---

　登社長のブログの記事技術者と作業員の中で、こんな文がでてきます。


ここで、コンピュータに関する分野で、『1. 本当の意味での技術者』対『2. 作業員的な技術者』の人数比は、たぶん２０年前とかであれば、前者のほうが比較的多かったのだと思う。そんな大昔は、1. のような能力を持った人たちでなければ、わざわざコンピュータに関する職業に手を出そうとは思わなかったからだと思う。以前は、コンピュータに関する仕事は極めて人気が低く、開発者というのはとくに偏見の目で大衆から見られていたに違いない。


ちょうど２０年ではないのだけれど、８０年代後半というくらいなら、ウィリアムのいたずらは、そのころ、この業界でバイトしてました(大学に行きながら）。

で、そのころは、上記の分類を参考にかくと、こんな感じです。

（あ）．技術者というよりは、研究者に近い人、コンピューターの技術的な問題を、コンピューターの技術で解決することによって、仕事を得てる人
（い）２．SEさん。コンピューターの技術的な問題を、いろんな技術や知識（コンピュータに限らない）を使って解決し、仕事を得る人
（う）３．SEさんに使われる人たち（プログラマ、コーダー、オペレーターその他おおぜい）

---

この違い、『1. 本当の意味での技術者』対『2. 作業員的な技術者』との違いとわかりにくいので、上記ブログにある

現に存在する問題を解決する通信プロトコルを設計したり、これまでに無い斬新で革新的な通信システムを開発したりすることができるかといえば、絶対にそのようなことは無い。


という文脈を使って説明してみます。

たとえば、CORBA使って、サーバー側のプログラム呼び出すと、遅いですよね。そのとき、

■■（あ）．技術者？研究者？の人
　CORBAを早くする、これまでに無い斬新で革新的な方法を研究する

■■（い）．SEさん
　別にCORBAじゃなくっていいじゃん。ソケットで通信しちゃってさあ、リフレクション使ってクラス呼び出して、引数はシリアライズ使って渡して。。。とかいって、いままでの簡単な知識を組み合わせて、仕様を満たす。通信プロトコルを設計してるわけでなければ、斬新でも、革新的でもないが、問題は解決している。

■■（う）．その他の人
　２の人たちのお手伝い。


　で、「１．本当の意味の技術者」というのは、（あ）の人たちのことを指していると思いますが（（い）の人たちは、理系の人とは限らないというか、理系では、踏み込めない部分が、実はある。）この人たちは、多かったかどうか？？？
　研究所や研究員が２０年前より、ふえたたのかなあ？あんまり、気づかないです。

　２０年前と大きく違うのは（い）の人が極端に減ったことです。
　人の数も減ったけど、仕事も減ったというか、システム開発業界から抹殺されたというのが、ただしい表現かな？と

　まず、人の数が減った理由として、この（い）を担うはずの人が、
　　１、うつ病や自律神経失調症などで、業界をはなれた
　　２、営業にまわされた
　　３、マネージャー、会社重役、社長になった
　　　→これらの人は、多くは、人集めと金勘定と、伝言係で、開発に直接はたずさわっていない
　　４、フリーになった
　　５．転職した
　などで、いなくなりはじめたところへもってきて
　　６．早期退職＆リストラ
　によって、会社から「いらない」と言われ、人数がへってきました。

　で、いらないとされた理由なんですが、それは、この業界全体が、営業のためのテーマをつくり、それにそった開発しか、できなくなったからだとおもいます。

　たとえば、上記の例でいうと、CORBAがブームだったときは、CORBAがらみにしないと、営業がとれないので、たとえ、ソケットで直接通信したほうがはやくてもCORBAなのです。
　Strutsがはやれば、それ、サーブレットでもいいじゃん！と思ってもStrutsなのです。
　創意工夫しちゃだめなのです。売れないから(^^;)


　このような状態では、技術的なヒーローの(＝営業に貢献しそう）（あ）の研究者と、（う）の人たちしか要りません。
　ただ、市場は小さくなります。で、その結果なのですが。。。


運良くコンピュータ業界はまだ儲かっているので、他の同様の職業（たとえば工事作業員とか）と比べると、報酬は割高である。


　そ、そうなのですか？私のまわりは、サービス残業＆年棒制で、ひどい人になると、時給になおすと、マクドナルド以下という人もいるみたいですが。。。私のまわりだけ(^^;)

　最近は、儲かっているより、引き合いバブルっていう話もありますが（日経ソリューションビジネスの４月３０日号の特集）
　これは結局、（い）のシステムを見切って仕切る人がいないから、バグの多発になっている部分があると思います（システム全体を見切らないと、矛盾は、どうしても起こる）

---

じゃあ、今後どうなるか？という予想にかんしては、また景気が悪くなり、（い）の人は、更なるリストラで減り（（う）の人は、首になると再就職が大変なので、やめない。やめるのは、（い）の人）、結局、この業界は、いまのまま進むと思いますね。（あ）の研究者さんたちが、神学論争を起こすような気配もあるが（つまり、方法論はなになにがいい、ツールはなになにじゃなきゃだめ！ということを、盛んに言い出す）。。

　で、（い）の人たちは、違う分野をめざすんじゃないか？それが、ホリエモンの進出しようとしている分野、
　　　１．放送
　　　２．通信（とくにスカイプのような、P2P)
　　　３．金融
　なのだとおもう。特に、今後、金融が有望なんであろう（SEが個人投資家となり、自由に売買手法を発想していく）。

　ただ、最近、ライブドアといえば、乙部さん、乙部さんといえば、この記事でわかるとおり、メガネっこということで、今後、システム系にかわり、萌えとメガネっ子が、日本の産業を作っていくかもしれない。。。

　ウィリアムのいたずららしい結論だが、登社長がみたとしたら、本気で怒られそうな結論だ。

すげー、富士通のお菓子（クッキー？）なんてあるよ！

　富士通すげー、富士通のお菓子（写真からみると、クッキー？って、javascriptでgetCookieとかやる、クッキーじゃなくって、お菓子のクッキー）があるよ。

　それを紹介？してるのが、ここ

　すげー、どーやって、入手するんだ？
　富士通行くと、売店で売ってるのかなあ？？（まさか？）
　それとも、株主総会かなんかで、帰り際にくれるとか？？
　総会で売ってるとか？
　まさか、まさか、まさか？？？株主優待品？？

　うーん、なぞだ。。。
　つーか、なんで、富士通、こんなお菓子作ってるんだろう？？

　というわけで、ほんとうにどーでもいい、小ネタでした
　（ただ、ウィリアムのいたずらのツボに、はまったもんで）

UMLとDOAとパッケージの利用を考えるとき

今日は、忙しいので小ネタ。

UMLのようなOOAを使ったほうがいいとき、DOAを使ったほうがいいとき、あるいは、両者のような、１からの開発（スクラッチ開発？）でなく、パッケージを使ったほうがいいときの、ウィリアムのいたずらの考え
（つまり、昨日のブログの続き）

---

　既存の業務で、その手順などがきまっている場合（手順が動きにくい場合）は、UMLを使って、OOAで分析していったほうが早いと思います。なぜなら、プログラムとの親和性が高いから。

　しかし、既存の業務でない場合、手順が本当のところわかりません。それをUMLで開発すると、手順が抜けたり、変更して、鬼のような仕様変更になる場合があります。

　たとえば、たしか、どっかのサイトで話題になってたと思うけど、オークションサイトを２日で作る場合。
　これをUMLで開発すると、多分、経理とのつなぎ部分は、

　手数料収入の発生の仕訳
　　　（売掛金）XXXX　　　　　　（売上）XXXX

　手数料徴収時
　　　（現金預金）XXXX　　　　　（売掛金） XXXX

　とするため、手数料発生と、お金を受け取る、ユースケースが出てくると思う。
　しかし、これだけしかないと、仕様は大幅変更になる。

---

　これには、キャンセルがない。たぶん、社長あたりは、「キャンセルの場合でも、手数料はもらう！」などと強気に発言をするが、社長の本当の目的は金儲けであり、金儲けのためには上場しないといけないわけで、その際、キャンセルの場合（たとえ、会社側が悪くても）すべての場合手数料をもらうというやり方では、たぶん、監査が降りない。

　そこで、急に、「やっぱ、キャンセルを作れ！」となり、仕様変更になる。

　当然、この程度のこと（ベンチャー企業の社長は、「絶対あり得ない」と言い切っておきながら、後日「なんで、そうなることを想定してなかったんだ」と、自分がいったことをまったく忘れ、無責任な発言をする）は、SEにとって、想定の範囲内なのだが、問題は、このとき、業務内容は聞けないこと。

　なぜなら、絶対あり得ないと言い切ってるんだから、「その絶対あり得ない業務は、どうやりますか？」とは、聞けない。

　このような、新規業務、ユーザーに聞きにくい業務や、ユーザーも想定していない業務、ユーザーもどうやったらいいのかわからない（ベンチャーには、おおい。っていうか、ぜんぜん考えてないでしょう！っていうときもある。例：放送と、ネットの融合って？？）。
　そんな場合は、データからDOAで解析をかけて、そのデータをそろえるには、どういう業務が必要なはずかをかんがえたほうがいい。

---

　ただし、データから解析をかけると、やりかたが何通りにもなったり、よくわかんなかったりすることがある。
　たとえば、上記のキャンセルの経理処理などは、どうやったらいいか、よくわかんなかったりする。
（売上返品に相当するんだけど、売上返品という科目を設ける場合と、売上の逆仕訳の場合がある。また、現金をもらう前か後かで、またかわる）
　で、そういうときは、その業界のやりかたの通論があるかないかしらべる。とくに、パッケージがあれば、それをしらべる。そして、今回、その通論どおりでいけるか（あるいは、パッケージを使ってやれるか）、しらべる。
　通論どおりいけない場合、
　　　　それが、営業の競争上、有利になる点であれば、その部分のカスタマイズ（新規作成）
　　　　そうじゃなきゃ、通論やパッケージに、業務をあわせる
　という形になると思う。

---

　なので、OOAもDOAも、パッケージも、みんな、必要。
　とくに（パッケージがなくても）、これが、この業界の標準的なやり方という通論は必要だと思う。
　ただし、かならずしもその通論や、パッケージにあわせるわけはない。
　自分たちと、標準との違いを知るために必要。

ＤＯＡとＯＯＡと試験とパッケージと統一伝票による標準的クラスより、引越し

「スクラッチ開発」という名のゴムボートというブログの記事をみて、私、ウィリアムのいたずらの様子と近況がちょっと、伝わりそうなので、そのブログをもとに、今日は書いてみます（斜体の部分は、そのブログからの引用です）。

---

◆「ＤＯＡ対ＯＯＡ」でも「改革派ＶＳ守旧派」でもなく

平澤さんとのやりとりを読んで、システム開発の世界に「ＤＯＡ対ＯＯＡ」の対立があると理解してもらっても間違いではない。


　やば！

　ウィリアムのいたずら、ＵＭＬ（を使う場合って、ＯＯＡですよね）で開発する場合、以前のブログでも、書いているけど、ヒアリングをもとに業務分析してユースケースとか書いていくと、そのヒアリングした業務内容に矛盾があっても、見破れないことがあるので、とりあえず、ＤＯＡっぽく、ＥＲ図をかいて（あぶないときはＤＦＤまで書いて）ＵＭＬのユースケース図に無理がないか、確認していたりします。

　つまり、ＤＯＡとＯＯＡの対立じゃなくって、両方使ってた(^^;)

　た、対立してたのね！

　両方使ったりしてたら、ＤＯＡの人にも、ＯＯＡの人にも怒られるよね。

　ひやひやひや（ひやあせをかいているさま）

---

◆業務知識のライブラリー化が急務


　おっしゃるとおりだと思います。はげしく同意します。
　で、この点に関して、ウィリアムのいたずらは流通ＸＭＬ－ＥＤＩをもとにして、クラスを作成しようとして、前に、矛盾っていうか、やばさを発見してしまったわけです。
　
　そこで、このＧＷを利用して、今度は、もうひとつの流通業界の業務知識である、統一伝票とその流れによるクラス化を試みようとおもっていたぴょ。

　そ、それなのに、そんなひまは、一挙になくなってしまったぴょ！

　理由は、本家のブログ（ここ）

　大家さん、ひどいぴょ(;_;)!!
　（って、大家さん、体が悪いから、しょうがないんだけどね。。。）
　当分、ブログを書いてる暇すらあぶないぞ。

　とかいいつつ、ブログ書いてるぴょ！

---

そう。「スクラッチ開発」という名のゴムボートに乗っている我々にとっての「敵」は、彼らのようにやる気と実質的な専門技能にあふれた「日本の商習慣にアドオンやカスタマイズなしで馴染む業務パッケージの開発企業」だ。

いや、あわてて訂正する。彼らは我々の「好敵手」ではあるが「倒すべき敵」ではない。


　やば、やばの２乗（ただし、やば＞１　つまり、やばが急速に大きくなっていくさまをあらわす）

　ウィリアムのいたずら、このブログのＵＲＬから想像できるように？？(xmldtp)
　DTPパッケージソフトの開発をやっていたぴょ。
　で、最近は、（ＤＴＰとはぜんぜん関係ない分野で）「スクラッチ開発（一からの手作り）」もやってるぴょ！

　つまり、お金になれば、どんな開発でもやってるわけで、こーいうやつは、敵の陣地を行ったり来たりする、危険人物になっちゃうぴょ！

　それと、どーでもいいはなしだけど、パッケージ開発の場合、ソフトにあわせるよりも、業務をあわせてもらったほうが簡単な場合があるぴょ。
　　業務がばっちり出来ているなら、スクラッチ
　　業務に矛盾があるならパッケージ
　のほうが、うまくいくぴょ

　でも、そうすると、パッケージなんかを導入する場合、システムのＳＥさんというより、業務コンサルだよね。で、ウィリアムのいたずらは、お金になれば。。。
　っていって、想像つくと思うけど、コンサルもやってたことあるぴょ。

　なんて、せっそうのないやつ。。。
　

---

ある有名なパッケージのシリーズを扱っている企業では、社員全員が日商簿記２級とマイクロソフト認定技術者の資格を持っているという。


　やば、やば、やばの３乗（ただし、やば＞１）

　ウィリアムのいたずら、日商簿記一級と全経上級は、持っているけど、
　マイクロソフト認定技術者もってないよ(^^;）
　コ、コ、コンピューターの勉強しなくちゃ。
　（ちなみに、ＦＰも持ってるんだけど。。。）

　ちなみに、情報処理試験は、アプリケーションエンジニア（と、データベーススペシャリストと、ソフ開）持ってるけど、最近は、情報処理試験より、やっぱり、マイクロソフトやJavaや、オラクルや、Ciscoの試験のほうが、重要なんですよねー。きっと。そんな気がします。

　あんまり、雑誌なんかで、筆者紹介で情報処理試験のなんとか。。。とか、書いてない気もするなあ。。。

　でも、マイクロソフト認定技術者試験、高いのよ。
　だから、受けるのに、二の足を踏む、ウィリアムのいたずらなのでした。

　（つっか、そんなことより、引越しするお金のほうが、必要ぴょ！
　　これが、一番やばいぴょ！やばの無限大ぴょ
　（ただし　やば　＞１　くどいぴょ！））

「バックスラッシュモデル」って、別に「モデル駆動型開発」に”しなければ”、あり得る話の気が。。

　「バックスラッシュモデル」っていうのが、あるようだ（ここをみた）

　要するに、単体～システムテストまで「（動的検証フェイズ）をざっくり切り落とした考え方」だそうな。

　これ、モデル駆動型開発（MDD)にするから、目新しい話で、そうじゃなかったら、あり得る話ですよねえ？？

---

まず、比較のため

「バックスラッシュモデル」でない方法で作る「システム」

・ある顧客マスタ（既存）をもとに、ダイレクトメールを送るシステムを作ります
　→送るDMは１プログラムにつき、１種類のDM、顧客の抽出条件も１種類
　　（DMの種類が変わったり、顧客の抽出条件が変わる場合、別プログラムを作る）

これをStruts、MySQLでつくるとしたら、多分、テストをすると思うんですよ。

---

「バックスラッシュモデル」で作るかもしれない「システム」

まったく同じシステム、つまり

・ある顧客マスタをもとに、ダイレクトメールを送るシステムを作ります
　→送るDMは１プログラムにつき、１種類のDM、顧客の抽出条件も１種類
　　（DMの種類が変わったり、顧客の抽出条件が変わる場合、別プログラムを作る）

これをAccessで作るとしてください。

そうすると、
１．Accessで、既存の顧客マスタをインポートする
２．DMの出力の可変内容、選択条件を設定したクエリを作る
　　可変内容は、
　　　・ある位置に、項目をそのまま出力する場合は、項目名のみ
　　　・項目名に、文章が付け加わる場合は、連結する文字もつけて設定
　　　　例えば
　　　　　「○○様のご来店を心から、お待ちしております。」
　　　　のような、項目名に、文章が付け加わる場合、クエリの項目に
　　　　　あいさつ文1:[顧客マスタ].[氏名] & "様のご来店を心から、お待ちしております。"
　　　　と設定する
３．クエリを基にしたレポートをデザインビューで作成
４．出力

　たぶん、１から４の間、テストする人もいるかもしれないけど、Accessに慣れてる人は、テストしない気がする。
　できたものを、出力する前にちょっとプレビューするかもしれないけど、それで、出力させてしまい、その結果をざっと確認するだけのような気がする。
　これ、Accessでやったから、テストということも考えられるけど、ExcelとWordの差込印刷でもできるわけで、その場合、テストする可能性は、もっと少ないと思う。

　おお、テストしてないぞ！

---

　このAccessで作った例を、「そもそも、システムじゃない！」と議論するかもしれないが、Javaで作ったほうは、システムっぽいですよね。なら、Accessだって、使うツールがちがうだけだから、やっぱ、システムじゃない？？

　そーやって考えると、たぶん、「システムを作るとき、テストしないですむ条件」っていうのがあって、それは、こんなかんじ？？

・そのツール(Javaの場合は、Java開発環境、Accessの場合、Accessそのもの）を使って作れるものが、予測できる
　　Java開発環境があっても、どんなものができるか、予測できません。
　　Accessの場合、どんなものができるか予測できます。

・作業手順が明確で、その手順は、枯れている。
　　上記のDMをAccessで作成する場合は、上のとおり

・ツールも枯れていて、想定の範囲内に動く

・仕様と、できるものの対応が明確である
　今回の場合、DMと検索条件が決まっているので、できるものが明確。

・間違える要素があまりなく、間違えたとしても、そんなに大きな被害がない
　Accessの場合、使い方がわかれば、あまり間違える要素は、打ち間違い以外ない。
　打ち間違いは、ある程度、Accessが、はじいてくれる
　上記のDMの場合、間違えたとしても、たいした被害がない。

これ以外にもあるかもしれないけど、こんな感じのツール＆適用範囲であれば、テストは省略可能だと思います。

---

っていうことは、モデル駆動型開発（MDD)でテストが省略できるようになるとしたら

・そのツールで、何ができるか、はっきりわかる
・MDDにおける、要件定義からプログラミングまでの手法が明確であり、枯れている
・そのツールが枯れている
・要求仕様と、欲しいシステムの対応が明確である
・間違える要素があまりなく、間違えたとしても、そんなに大きな被害がない

なら、できるようになるかもしれない。
うーん、まだ、ずーっと先のような気がする。