不具合を見つけるか、お客さんを増やすか、ベリサーブのテスターには、ジレンマに違いない！

　前のブログは、結局まとめると、

大手企業の場合は、テストの目的は、「品質の向上」だが、 　ベンチャーの場合は、テストの目的は、「品質のチェック」というケースがある。

　品質のチェックの場合、結局リリースできる品質かどうかを知りたいのだから、そのチェックレベルにおいて、「バグ ０」というのも、とても有意義なテスト結果である。

　っていうことになります。

---

　つまり、いいかえると、ベンチャーの（特にプロダクトの）マネージャーは、時間がないテストの場合、「不具合をたくさん見つけ」てくれたり、「異常系のテストケースに注力すべく、「遷移が存在しない、誤っている」「本来存在しない遷移」「不正な入力に反応」というようにテスト設計方針」といったテストを、行ってほしいのではない気がします。
　時間がないのであれば、あくまでも、正常系が通るかどうか、リリースして大丈夫かの品質を知りたいわけです。

　つまり、「画面入出力項目に対して、各項目の設定可能項目と設定値の組み合わせをマトリクスにて抽出し」、「最大値／最小値や境界値また異常値を考慮し組み合わせを合理的に少なく」したテストをしてほしいわけです。
　そういうテストをしてくれる会社があれば、「うん、値段が合えば、使ってみようかな？」って考えるわけです。

　ところが、「画面入出力項目に対して（以下中略）」やる方法では、ほかの異常系のテストに注力する方法にくらべ、バグ数を見つけるという意味であれば、圧倒的に不利です。なんたって、前者は、正常系のテストになってしまうので、まあ、ふつう正常系は、つぶしてくるものですから。
　で、バグ数の数字でしか判断できない経営者とかなんかだと、バグが出てこない前者のテストのよさが見抜けないわけです。

---

　さあ、ここで問題です。

　実は、上記の文は、「テスト設計の方針は千差万別」の「テストライブ」でテストを行った方のテスト戦略から、抜き出したものです。

　で、そこの参加者が、問題なんですよ！
・日本IBM（テストエンジニア担当）
・NEC　（テストエンジニア担当）
・ベリサーブ　（テストエンジニア担当）

　上の２社は、大手企業です。これは、問題ないです。バグを見つければいいだけです。

　でも、ベリサーブは、検証屋さんです！検証屋に期待するのは、プロダクトマネージャーでは、先ほど述べた、品質を知りたい、つまり、「画面入出力項目に対して（以下中略）」というやり方です。でも、経営者に売り込むには、バグを多く見つけなければいけません。ほかの異常系の方策を選んだほうがいいです。
　でも、そのやり方を選べば、プロダクトマネージャーや、そーいう関連のコンサルは、「なーんだ、そういうテストじゃあ、使えないな。だったら、「画面入出力項目に対して（以下中略）」みたいな仕様書つくって、パソナの派遣にやらせたほうがいいじゃん」といわれてしまいます。これも、売り上げにつながりません。

　ジレンマです。酷過ぎます。どちらの戦略をとっても、だれかの不評を買います。

　どっちの戦略をとったのか、興味津々。

　それを解説する人も、すごいツッコミになったんでしょうね。
「おお、あくまでも、経営者に売り込みにいく方法をとったかあ、大丈夫か、それで、明日から現場で問題起きないか？」とか、
「おお、現場の人の受けをねらったか、大丈夫なのか、経営者や投資家の歓心を買わなくて、明日の株価とか」「CSKグループだから、大丈夫なんじゃないですか、これが、ホリエモンのライブドアグループならたいへんです。まずは、株価です」とか、ディープなツッコミが・・・入るわけないって(^^;)

大手企業の開発のテスト戦略、ベンチャーの開発のテスト戦略の違い

　最近、テストの話を読んで、ふと思う。
　大手企業の開発の場合のテストと、ベンチャー企業の場合のテストを分けて考えたほうがいいんじゃないかと。

　この２つ、根本的に戦略が違う。と思う。

---

　大手企業の場合、開発のテストは、品質を上げるという戦略でテストする。

　非常に極端な、語弊のある言い方でいうと、バグを見つけるためにテストする。

　非常に複雑な、ありえないような場合でも、それをテストし、バグがあれば報告するのが当然だし、バグを見つけたら、ただちに報告すべきである（さすがにこれは、語弊があるか。再現性のないバグを報告すると、怒られるかも。。。）

　だから、過剰品質や、テストによる現場の混乱というのは、あまり意識しないと思う。過剰品質になったり、自分がバグ表を乱発したせいで、給料がもらえなくなるとか、っていうのは、あんまり、大手の開発のテスターさんは、考えないと思う。

---

　でも、ベンチャーの場合、品質を知るためにテストすることも多い。

　重度の社会的な問題を引き起こすようなものに関しては、たしかにテストしないといけない。
　でも、ベンチャーのお仕事って、はじめから、（人の命のかかわるような）そんなに重度なものを受けないことが多い。
　ECサイトとか（そのECサイトもたわいのないものを売ったり）、ちょとしたWebシステム（バグでも、お金で解決しそうな）、ゲームが結構多い（というか、その手の仕事がほとんどだ）。

　この場合、そこまでテストしなくてもいいようなことを、テストしてしまった結果、時間がかかり、納期が遅れた場合、たいへんなことになる。

　納期が遅れる＝入金が遅れるとなると、給料が出ないことがある
　（ウィリアムのいたずらも、あるベンチャー企業で、入金が、数ヶ月、遅れてもらったことがあるぞ）。
　幹部役員、社長は、その間、つながなくてはいけない。
　納品すら、期日に出せない会社に、運転資金を貸してくれる奇特な銀行は、まずない。
　キャッシング、サラ金に頼ることになる。
　それでも、遅れたら。。。彼らは、夜逃げするしかない。

　バグ票を連発して出すことにより（で、本質的なバグを出してくれないことによる）開発現場の混乱も、おなじような結果を招く。

---

　しかし、ベンチャーにおいて、テストしなくていいかというと、そんなことはない！

　テストしないと、サポート部隊の健康状態にかかわる。
　プログラムの品質が悪いと、サポートセンター（以下サポセン）の女性（男性もいるけど、女性がおおいので、女性とする）の、出社時間がまず遅れる。
　彼女たちの言うせりふは、たいていこうだ
「おきられなかったんです！おきたら、お昼になっていて！」
　ベンチャー企業の社長は、この言葉の意味がわからない場合が多い。

　人間というのは、耐えられない刺激がくると、それを回避しようと言う行動に出る。
　つまり、サポセンにクレーム電話が殺到し、みんな、ひどいことを言うので、それに精神的に耐え切れなくなり、無意識のうちに、体が、起こさないのだ。
　それを知っているウィリアムのいたずらは、「やってしもーたー」と思い、開発の品質のチェックに入るが、ベンチャーの社長は、なぜか、そのサポセンの女性を責める。
　なので、逆効果。会社いやになってやめちゃう。そうすると、会社大変。サポセンの人がどんどんやめだし、社員が電話取る。こうなる前に、派遣をいれると、派遣は、クレーム処理に慣れてるからいいんだけど。。。

　まあ、こんな感じで、ある一定の品質を下回ると、会社自体がつぶれる。
　ある一定以上の品質を上回った場合、それで納期がずれたりすると、やっぱり会社がつぶれる。
　どっちも、給料入らない。

　そこで、ベンチャーの場合は、リリースして（サポセンが）耐えられる＆会社として、信用落とさない程度の品質に入っていることを、できるだけ早く保障する。
　もし、入っていない場合、開発がすぐに直せるような報告のあげ方にするということが重要な戦略となる。

---

　その場合、一般ユーザーがやりそうなことをテストして、OKならまあ、いいってことになる。
　だから、結果として、「この品質保証のテストにおいて、バグ０件です」という報告も、むちゃくちゃ意味がある。
　それでリリースGoサインということになるから。


　でも、大手の「バグを見つけるのが、テストの仕事」になった場合、「バグ０件です」と報告すると、「おまえ、仕事してないだろー」っていうことになったりもする。

---

　って、ここまで読んできた人は、「お前、なにがいいたいんだ？」と思ったであろう。
　それについては、この後のブログで書く予定

航空管制官のお言葉と、中国のSEへの指示

　さっきのWBS（ってあのプロジェクト管理のほうじゃなくって、和歌山放送でもなく、テレビ東京の番組の）でやっていた、航空管制官のおことば。

　・迷ったらNO
　・コミュニケーションの行き違いがあるから、指示は簡潔に！

　後者の話について、ウィリアムのいたずらは、中国の人たちともお仕事していたことがあるんだけど、そのとき、同じことを思った。

　「指示は簡潔に」

---

　なぜなら、複雑なことを言うと、ブリッジSEに意味が通じないらしく、
　中国では、どれか１つの指示内容しかやってくれない。

　たとえば、

　もし、プログラミングが終わったら、テストのデータを作ってください。

　みたいに、２つの指示があることをいうと、
　プログラミングが終わっているかいないかにかかわらず、テストデータを作ってたり。。

---

　だから
　
「指示は簡潔に」

　その場合は、

　プログラミングが終わったら、連絡してね、

　だけでいい。
　（次の作業は、次の機会に）

---

　前者の「迷ったらNO」は、なんか、最近、そんな気がする。

　上とちがって、実感できているのではないが、
　そんな気がする。

　今日、はっきりと言葉で言われて、「やっぱ、そうだよな」と思った。

「コンパイルが通るまで、あんまりテストしてないでね！」というときのマネージャーの気持ち

「悪態のプログラマ」さんの「バグを求めるものたち　前編」というブログをみて、「ひょっとして、このプロジェクトマネージャーさん、似たような言葉を誤解してるのではないかな？」と、ちょっと思ったので、書いてみました。

　ちなみに、上記のブログの中には、こういう言葉が出てきます。

「プログラミング中には、作ったプログラムを動かすな。ただソースコードを書いてコンパイルが通ればよい。とにかく、テスト工程に入るまでは絶対に動かさないこと」 あるプロジェクトマネージャが、プログラマにこのような指示をしていた。 おかしなことを言うものだ。

　たしかに、上記のいいかたは、おかしいです。

---

　しかし、これに似たようなことをいうケースがあります。

「プログラミングは、コンパイルがとおる所まで、一応作っちゃってね。 　で、正常系がとおることを確認したら、いったん、（こっそり）頂戴！。 （「その段階で、誤解が無いかどうかの確認テストをするから。」ということは言わず） 　詳細な単体テストや、異常系の単体テストは、その後にやってね。」

　これは、ウィリアムのいたずらも、言ったことがあります。
　で、意味があります。

　まず、どういうときかというと、

　　　本当に、このプログラム、できるんかい？って

　自信、ちょっとないとき。あと、インターフェースが合うかどうかを早く確認したいとき。

　単体テストを一生懸命やってもらっても、言ってる意味が通じてなかったり、結合で合わなかったら、結局作り直しになって、単体テストが無駄になってしまう。

　もちろん、仕様は書いているんだけど、正直、意味が通じているかどうか、分からない（「あんた、俺の言った意味、通じてないだろう！」と、プログラマには、失礼で、いえない）。

　さらにひどいときになると、できるかどうかも自信が無い(BREWなどで、マニュアルにはこう書いてあるけど、この機種で、この機能がサポートされているかどうか、わからない）。


　そこで、早いところ、全部通してもらって、意味が通じているのかどうかを、確認したい。


　そういうときに、ウィリアムのいたずらは、上記のことを言います。

　で、正常系は通って、インターフェースが合っていれば、さらに品質を上げていただくための単体テスト、もし、インターフェースが間違っている（誤解されている）などの問題があれば、プロジェクトをそこで止めます（単体テストもストップ！だって、そのプログラム自体、捨てちゃうかもしれないから）。
　というかんじです。

---

　上記のプロジェクトマネージャーは、ウィリアムのいたずらなどがいう、「コンパイルがとおる所まで、一応作っちゃって、正常系が出来たら、その時点で頂戴。そしたら、俺が、結合できるかどうか確認する（＝テストする）から。で、それでＯＫだったら、本格的にテストしてね」ということばを、誤解して、あるいは、わざとかもしれないけど、言ったような気がします。

　うーん、たしかに、似てる言葉なんだけど、ちがうんだよなー。言ってる意味は。
　もしかしたら、言う側は、そういう気持ちで言っても、聞く側からすると、そのプロジェクトマネージャーが言った言葉のように聞こえるのかなあ？？

RubyでExcelですとお！

　コメントで、DynaBeansを教えていただいたので、まずはチェックとおもい、調べてみようとおもいました。

　で、検索して、引っかかったページをみてみると、

　うん、DynaBeansとまったくちがう、心引かれる記事が。。。

　「日本の情報投資額 9割が無駄」これも、心惹かれるけど、それより、目が留まってしまったのは、
「RubyでExcel」

RubyでExcelが操作できるのですか。。。おお。
ということで、早速、そのページへGo（おいおい、DynaBeansは、どーしたんだよお）！！

　ほおほお、rubyでかけるのね。。。

　「ひまわり」（ひまわりとExcelの連動は、ここ）よりRubyに興味のいきそうなウィリアムのいたずらであった。

　ひまわりより、Rubyのほうが、お金高そうだし。。。

　え、普通、人工衛星のほうが、ルビーより高いだろうって！

　そういう、オチかい！

データ移行も、けっこうあぶないよね。

　そうそう、おばかなプロジェクト問題（って、囲っちゃっていいのかあ？）の話のついでに。。。
　旧システムから新システムのデータ移行っていうのも、甘くみられちゃいません？

　けっこーたいへんなのよね。
　もちろん、データがおかしくなっていれば、データクレンジングとかしないといけないから、それは大変なのは、わかってもらえると思うんですが、そうじゃなくっても

---

　あるプロジェクトで、データ移行「半日」、SQLを流すだけというのがあった。

　で、その日になった。

　（その時点で、ウィリアムのいたずらは、ぜんぜんデータ移行にタッチしていない。移行後、確認用のテストをするはずだった）

　SQLをながした。

　３０分たっても、返事がない。まあ、そんなもんだろう。

　１時間たっても、返事がない

　１時間半たっても、返事がない。なんか、へん？？

　どんなSQL投げた？？

　しまった、数十万件ものテーブルを、Joinしたり、副問い合わせしたり、いろいろと。。。。。

　これは、おわんないかも。。。

　つくりなおしだ。でも、データ移行に半日しかとってないんだ。

　データ移行は、CSVなり、insert文にするなり、データをあらかじめ作ってウィリアムのいたずらが確認しておくべきだった。

---

　教訓：他人を信じるな

（そー来るかい （^^;)v　）

UMLを採用しても（したから？）おかしくなるケース

　なんか、最近、アクセス数が多いので、今日もこりずに、おかしなプロジェクトの話。
　昨日のブログの書いた、「商品台帳に在庫数を記入して、更新する方法を採用したら、ディスクがたりなくなっちゃって出来ない！」っていう話。

　この会社、基本的にUMLを採用してるので、たぶん、このプロジェクトもUMLを採用してると思うんです。

---

　実は、そこが問題！

・まず、システム分析に入るため、ユーザーからヒアリングして、UMLのユースケースを作った。
・ユーザーは、在庫を知るのに、商品台帳に在庫数を記入して、（在庫が入ったら在庫数を書き換え）更新していた。
・なので、単純にそのままやった。
・UML上、そのように書いても、矛盾は出ない。
・逆にユースケース図から、別の方法を考えようと思っても。。。考えが浮かばない。

---

　UMLを採用し、業務分析を行う場合、ユーザーからヒアリングしてその内容を書きます（まあ、ユースケース図とか、アクティビティ図とか）。

　この場合、本来業務は、いろんなやり方がありえる（場合が多い）。

　しかし、いろんなやり方のうち、どのやり方かを決めてやらないと、現場が混乱するので、偉い人（じゃない場合もあるけど、結局自分を含め、誰かが）がえいや！ときめてやる。

　その場合、

　コンピューターを導入しない前に現場が決めたことは、
　　　　コンピューターを「入れない」状態での最適解である。

　コンピューターを「入れた後」も、そのやり方がいいとは限らない。



　たとえば、上の例でいうと、コンピューターを「入れる前」であれば、在庫を知るのに、商品台帳に在庫数を記入して、更新するやり方は、最適解となる。
　入庫伝票、出庫伝票を書いても、それを集計する人がいなければ、在庫数がわからないから。

　でも、コンピューターを「入れた（後の）」場合、その集計処理はコンピューターが行うから、入庫処理、出庫処理をしたほうが、システム上よいというケースが多い（今回もそのケース）。

---

　ところが、UMLの図をみてしまうと、そのやり方をもとに考えてしまうので（とくに若手でいろんなやり方を知らない人は）、業務のやり方が悪いとわかっても、それをどう変えたらいいか、気がつかない。

　ユーザーに聞いても、コンピューターを使っていなければ、コンピューターを入れた後で、どんなシステムがよいのかは、本当のところ想像つかない。だから、やっぱり、業務のやり方が悪いとわかっても、それをどう変えたらいいか、気がつかない。

　入出力だけを押さえて、そのプロセスについて、いろいろ発想を広げるか、通論を調べることになる。

　しかし、前者は、データ中心指向的な発想だし、後者も最近言われない（業務のパターン化について、クラス化して公開するなんていう話をあまり聞かない。そのため、このブログで、「業務のモデル化」っていうカテゴリで、それをやろうとしたんだけど）。
　つーことで、UMLのやりかただけを聞いた若手の人なんかが、システムを切ると、こーいう、困ったことが起こることがある。

---

　っていうことが、以前のブログ「テストの失敗や品質不良の問題は、フレームワークのまずさと、仕様変更のためが多いと思う 」で書いた、「ユーザーがいう業務内容が、はたして、コンピューターを載せたとき、最適な方法かどうかわからない。」の具体例です。

独断と偏見の「単体テスト」の解釈：プログラムの仕様書の有無で変わる？

今日は、独断と偏見による、単体テストの解釈なんてーものを書いてみたいと思います。というのも意見募集！単体テストってなんですか？というのを見たので。。

　「単体テスト」というと、プログラム単体のテストのことをさします。
　ので、「システム開発取引の共通フレーム SLCP-JCF」でいう、

・ソフトウェアユニットとデータベースの作成
　（ソフトウエアユニット＝プログラムの基本単位、まあ、プログアムです）
　の後に行われる、

・テスト手順とテストデータの作成、テストの実施

　に相当するとおもってます。
　（ＰＤＦでよければここにあります。そこの「エンジニアリングの視点」の「１．４　開発サイクル」の「1.4.8 ソフトウェアコード作成及びテスト」)

　で、たしか、上記の共通フレームでは、「プログラムの仕様書があって、その仕様書に対して、プログラムがあっているかどうかをテストする」という形になっていたと思います（記憶違いだったらすみません）。

　上記の場合、詳細設計でプログラムの書き方が書いてあるので、それをもと（基準）に、テストする
　　＝＞結局、ホワイトボックステストの形になると思います。

---

　で、問題は、仮に、プログラムについての仕様書が無かった場合（プログラムを書くための資料やインターフェースは決まっているが、プログラムをこう書きなさいという仕様書はない場合）。

　この場合、共通フレームのように考えると、なにを基準にテストしていいかわからなくなります。そうすると、いったい、単体テストというのは、なにをやることなのか、ぼやけてくると思います。

・インターフェースに入出力するものだけあっていれば良い？
　→でも、これって、インターフェースの結合テスト（ＩＴ１って言ってるところもあるかも？）
　　とどう違うの？

・ホワイトボックステストで、網羅しているかどうかを。。。
　→でも、それって、そもそも、仕様を勘違いしてたらおしまいだしなあ。。。
　　（仕様書を書いてないんだから、だれも確認できないわけで。。。）

　つーことで、プログラムの仕様書が事前に出来ていない場合、なにをテストしたらいいのだか、はっきりしなくなってしまうとウィリアムのいたずらは思ってます。

　なので、下請けフリーのＳＥのウィリアムのいたずらは、「単体テスト、どんな風にやりますか？」とききます。実際、やってること、まちまちなんで。

---

　問題は、プログラムの仕様書、詳細設計書をつくるか？ということです。
　COBOLの時代は、あった記憶があります
　（たぶん、共通フレームもその時代のことの話でしょう）
　で、最近、Webで、たとえば、Actionの中をこう書いてくださいという仕様書は。。。


　ごそうぞうに、おまかせするぞ！

ちなみに、StrutsのActionメソッドに、ロジックなしでSQL文を直接書いた人（会社）の話

　ちなみに、以前のブログで書いた、

（４）Strutsでやるとすると、Actionメソッドに、SQL文を直接書いて、商品台帳テーブルを更新するプログラムを書くのよ(@_@)!

　このはなしを詳しく書くと、
　ある在庫のシステムを、こういう感じで作って、納品してきた会社があり、
　そのあと、仕様追加するということで、ウィリアムのいたずらが、お仕事もらいました。
　（はじめに作ったときには、ウィリアムのいたずらは、かかわっていない）。

-----

　で、その、はじめにシステムを納品した会社は、商品台帳テーブルに数量を持って、その数量を修正することで、在庫としていたわけよ。
　ウィリアムのいたずらは、そのプログラムの仕様追加分の作成を頼まれたんだけど、その会社、もう、わけわかんないこというのよ。

　ちなみに、仕様追加分は、「日次で在庫日報を出す」

　その会社はなんと！
　　　商品台帳テーブルに年月日項目を追加して、
　　　毎日、商品台帳をつくることを提案してきた！
　そうすれば、日次の在庫をとってくるのは、いままでの在庫の取得方法に、年月日＝指定日を付け加えればいいだけ！
　っていう主張をするわけよ、

　だから、ウィリアムのいたずらさん、
　　　その日の終わりに前日のレコードを全部とってきて、
　　　翌営業日（これは求められるメソッドがある）用に
　　　商品台帳テーブルにセットするプログラムをつくって！
　簡単でしょ、「Actionメソッドから！」 insertを発行すればいいだけだから。
　というわけよ！

-----

　おいおいおい、（ActionメソッドにSQLを直接書くことも問題だけど、それより）
　そのテーブル、何レコードになるんだよお！
　（つまり、商品が１万レコードあったら、毎日１万レコードずつ増えるのね。。。１年で約３００倍？）
　（ちなみに、業種は、衣料品関連です。だから商品マスタは大きいけど、そんなに、毎日売れません）

　（その会社の社員に）計算させたら案の定

「１ヶ月半で、ハードディスクがいっぱいになります！だめです、日次在庫は、できません。」

　ちがうだろー！だめなのは、日次在庫じゃなくって、お前の考えだろー！

　その後、ウィリアムのいたずらが、毎日悲惨な生活になったのは、いうまでもない。

----

　もう、終わった話ですけどね。

　ちなみに、昨日のブログで、「わけわかんねえーっていうか、ロジック合わなくなっちゃって！」というのは、この話のつづきで、でてくる話です。こんな調子で、仕様変更ごとに、テーブルに項目追加したら、正規形がくずれちゃって、そのうち、ロジックがあわなくなってきちゃうのよね。

２７日の「コピーされるほど儲かるシステム！開発日記」は、要求仕様書

４月２７日に出す、「コピーされるほど儲かるシステム！開発日記」第１７号は、今回作るものの、要求仕様書です。

----------

　以前のブログ本家はSkipeAPIのまとめ、ここは要求仕様書の書き方のまとめ（項目例）の項目例と、それを実際に埋めたものがでています。

　埋めたものに関しては、ブログに、書いていませんが、そのうち、このメルマガのWebにはりつけておきます。
　
　ということで、あとは決り文句。

----------

　１７号のメルマガについての、感想などはここの「コメント」にどうぞ！

　メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム！開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参照してください

機密保護や個人情報保護に役立ちそうな、Excelの一部分しか見えなくできるファイル

「コピーされるほど儲かるシステム！開発日記」では、
　　　パスワードを知らない人は、一部しか見れないけど、
　　　パスワードを知ってる人は、全部見える
というExcelファイルを作成するとしてるけど（これだけではないが）

このExcelシート、こんなことにも利用できそう。

---

放送大学大学院のテキスト、「法システム３　情報法」（３は、本当はローマ数字）の３７ページに、
「昔、業者から機器を購入する時に、見積もりを表計算のソフトウェアのデータでもらったが、見積もりのシートと別のシートを選ぶと、仕入先や原価、値引率のデータがあり、業者の内情を知ってしまったことがある。」

---

　おお、これはまずいです。

　そこで、上記のExcelシート、お客様に見せるところと、業者の人がデータを入力するとことに分けて、データを保存すると、パスワードを知らない限り、お客様に見せるところしか表示しないってーのはどう？？

　ちなみに、「コピーされるほど儲かるシステム！開発日記」の最新号は、４月２７日にでます。
　そのおしらせは、次の記事で！

テストの失敗や品質不良の問題は、フレームワークのまずさと、仕様変更のためが多いと思う

ちょっと昨日の話しからは飛んじゃうんだけど、結局考えていたことは、

システム開発の手法としては、２つ考えられる。

（１）フレームワークを作る段階から、あらかじめ単体テストなどをしやすいフレームワークにしておく。 　（結果としてMVCにわけ、さらにDB操作なども分離して、モデルと乖離させると思う）。 　　そこから業務を（通論などを参照しながら）考えるという手法 　　→若くない人がやることが多い

（２）はじめからあるシステム分析理論に基づき（って、たいていUMLだけど） 　　　業務を分析して、それに基づき、システムをつくる 　　（現状の業務に沿ったプログラムを作る） 　　→若い人におおい。

　どちらも致命的な問題がある。というか、下請けの場合、（１）をやらせてもらえないケースがおおい。また、要求仕様をまとめる手順などにおいては、（１）の手法を否定しているものもある。

　で、（２）のケースが現在多いわけだけど（この業界、若い人もおおいし）
　（２）の場合、致命的な問題がある。

その１：
　ユーザーの言っていることを元に、現状のシステムを分析するので、
　ユーザーが言った業務が、伝票書きと書類チェックみたいなものを、延々と言いつづけた場合、
　（末端の現場の人にヒアリングするとこうる）
　あるテーブルを更新するだけのような業務の積み重ねになってしまい、
　業務らしい業務が存在しないので、単体テストなしになってしまう。
　その上、やっている業務内容の関連がみえない。

　そこに仕様変更が入ると、修正した場合に全体が読みきれず、矛盾が起こる
　この場合、結合テストで大きな矛盾が出る（しかし、上記のように、単体テストができるしくみには、初めからなっていない）。それを無理にあわせようとして、プログラムがわけわからなくなる危険がある。
　
（はじめ、在庫で具体論をかいていたが、長くなりそうなので省略。気分が向いたら、今度書きます）

その２：
　ユーザーがいう業務内容が、はたして、コンピューターを載せたとき、最適な方法かどうかわからない。
　というか、いままで人がやってたから、矛盾をごまかして運用できたけど、コンピューターのシステム化して、矛盾を顕在化させると、成立しないような業務もありえる。

（これも、具体例をあげていたが、長くなりそうなので省略。気分が向いたら、今度書きます）

---

　結局、はじめに決めたフレームワークが悪いと、仕様変更が起こったとき、後からなおせなくなっちゃうのよね。でも、作り直しは、プロジェクトマネージャーとかは認めないしね。

　はじめのフレームワーク設計が問題なんだけど、それを問題にしないで、最終的に問題が顕在化する（単体などの）テストの問題にしてしまうケースが、あまりにも気に障ったので、ちょっと書いてみました。

　ただ、そんだけ。

　でも、ここまでかくと、「じゃあ、どーいうフレームにすんだよ！」といわれそうなんで、それは、気が向いたら書きます。だって、どーせウィリアムのいたずらが、こーいうのがいいっていっても、結局、開発なんて、えらーいアメリカの人が持ってきた考え使うんでしょ。
　それを、現場にもってくれば、どれほど多くの人間が苦しみ、多大な犠牲をはらうと、わかっていても。
　で、テストできないのがわるいと、プログラマのせいにして、優秀（憂愁？）なプログラマをうつ病にさせたり、病気にさせてしまうと。。。

　ＩＴＳＳも、そーいう偉い人の横のものを縦にして、本かいた人が一番えらくて（レベル７）金がとれるとしたんだから、ウィリアムのいたずらのような、フリーの人間が、なにいっても、むだだよねえ。。。この業界、終わってるかも（＾＾）ｖ

XMLからJava自動生成その４:XMLの内容をHashMapに入れるクラス、まとめました

　ちょっと前のブログ「XMLからJava（以外もOK)自動生成その３:DOMで、属性・テキスト・タグ名取り出し（２）」のプログラムをすこし変えて、

ＸＭＬファイル名を指定して、メソッドを呼び出すと、
　　その構造を解析して、HashMapに入れるクラス、

つくっておきました。

　やっぱ、ＨａｓｈＭａｐとかＶｅｃｔｏｒになってないと、使いにくいですよね。

---

　Javaのソースプログラムは、こちら

　そこで、staticになっている、fromXmlToHashmapメソッドを

// XMLファイルをハッシュマップに変換する // inFnameは、ＸＭＬファイル名 　　　 HashMap mp = XmlHashMap.fromXmlToHashmap(inFname);

の形で、使います（mpに結果が返ってくる）

　帰ってくるHashMapの中身などについて、書いてあるのはこちら

---

　もちろん、勝手に使ってかまいませんが、まったくの無保証です。修正して使っていただいても、ＯＫっす（というか、たぶん、パッケージとかは変えるだろう）
　現在は、最後のノード（つまり葉）にしかテキストデータがない場合について対応していますが、そのうち、どこにテキストがあってもＯＫというようにしたいと思ってます。
　あと、将来的には、書き出しもいれるかも。。。

　ということで、今、公開しましたけど、今後、もっと増えていくと思います。

単体テストの議論では、世代間のシステム設計法（思考法）の違いを考慮しないと。。

ちょっと、最近のブログの単体テストの議論で、
　・システムの共通部分と
　・実際の業務開発と
　・テスト部分と
　・若手（２８歳くらいまでをさしましょうか）への指示を出している
人が分業されているせいか、話が？？？と思うことが多くあります。

　なんで、ちょっと、「ウィリアムのいたずら」が思うことをかいときます。（最後にも書いてありますが、ウィリアムのいたずらが思うことであって、ブログを引用している人の考えとは違ったりしている可能性もおおいです。あくまで、それらのブログを見て，ウィリアムのいたずらが、感じたこと、思いついたことを書いています）

---

単体テストの議論で

・単体テストをしなくてもいいようなプログラムがある。 　　　マスタメンテナンス的な業務ロジックが存在しないようなシステムなら

　という議論を認めた場合、
　最近の若手が設計するシステムって（本来業務ロジックが存在するようなものでも、存在しないように書いてしまうから）、マスタメンテみたいなかんじのばっかりになっちゃて、単体できないっていうことが、あるんです。

　で、この議論が間違いだとすると、「じゃあ、どういうふうにテストしろというの！」って聞かれちゃうと思います（プログラムが切れないので、単体テストのしようがない）

---

　たぶん、これらのブログを書いている人が、自分の立場を特定されないため、あまりにも抽象論で書いているので、話が見えなくなっていると思います。具体論でいきましょう（まあ、この程度なら、ばれないだろう。身元は ^^;)

在庫管理システムをＷｅｂでつくる

としますよね。

たぶん、若くないＳＥさん（ここでは、３３歳以上をさします。語弊ある？？）だと
（１）ＭＶＣにもとづき、画面系とモデルをわけ、
（２）在庫数は、棚卸数と入出庫業務からもとめるモデルを作成し
　　　（あるいは現在商品数を書き換える方法もあるけどね）
（３）ＤＢ部分、画面部分を切り分ける
っていうふうに書きますよね。

---

ところがね、若いＳＥさん（２８歳以下、語弊ある？）はちがうのよ。
（１）ＵＭＬにもとづき、業務分析をおこなう
（２）そうすると、システム入ってない会社の在庫って、たいてい商品台帳を直してますよね
（３）なので、商品台帳テーブルを作成し（商品と倉庫ごとに、現在数を持つ形）
（４）Strutsでやるとすると、Actionメソッドに、SQL文を直接書いて、商品台帳テーブルを更新するプログラムを書くのよ(@_@)!

　まるで、商品台帳テーブルをマスタテーブルとして、画面の文字をＳＱＬ文に入れて更新、検索するだけのマスタメンテ的プログラムが乱立しちゃうのよ(@_@!)
（複雑な検索は、あらかじめViewを作成しておく。結果として、Viewの乱立になるが。。。）

　そこで、「マスタメンテのような業務ロジックがいらないプログラムは単体テストがいらない」とすると。。ね、単体テストがいらなくなっちゃうでしょ!（つーか、できないでしょ）
　でも、Actionメソッドにすべて埋め込み、ＤＢをいきなり更新するプログラムが一杯できて。。。
　わけわかんねえーっていうか、ロジック合わなくなっちゃって！
　（なぜ、合わなくなるかは、後日書きます。これだけでは、ロジックを合わせられるのですが、仕様変更が入ると、おかしくなってしまうのです）
　おかしなはなしになっちゃうわけ。

　単体テストができない！っていう話で、ロジック部分が分かれていない場合、この考えで進んで、仕様変更がおきて、おかしくなったっていう話が結構あると思う。

---

　若くない人は、この構図を頭に入れて、「納期を守るために、ドライバやスタブは作ってられない」って言う言葉を読みましょう。
　そうしないと、この文、意味通じませんよね。

　若くないＳＥさんのやり方だと、モデル部分とＤＢ部分、画面部分は分けて開発するので、テストどころか、ＰＧのかなり早い段階で、ドライバやスタブは出来ている（そうしないと、eclipseで赤いＸがついて、リンクできないじゃん！）言い換えると、「納期を守るために、ドライバやスタブは作ってよ！」ってなるのに？？？

　ただ、若い人のやり方だと、Actionメソッドにいきなりデータ操作を書く話になるので、これだと、スタブの作りようが無いのよ。せいぜい、Ｏ／Ｒマッピングみたいにして、ＤＢ部分を分離して、そこにスタブをかくだけ。。。でも、もう、ＳＱＬ直接発行してたら、それも、意味ないでしょ。ってなっちゃうわけ。

（したがって、「ホワイトボックスレベルの単体テストをやるべき」と「納期を守るために、ドライバやスタブは作ってられない」っていうのは、対立している話でなく、どちらも、初めに採用したアーキテクチャの失敗（＝アーキが汎用フレームワーク(Strutsなど）をプロジェクトのリソースに合うようにカスタマイズする時点の失敗）の傍証をしている可能性が高い）

---

　そこで、単体テストをやるとすると、　 「このつくりで業務ロジック部の単体テストはできますか？」と書いてある人がいるように、システム設計部分から業務ロジック部分をわけて、（単体テストができるような設計）にしないと、いけないんだけど、若手の人は、「なぜ、そういう設計をしないといけないのか？、どうしてActionメソッドにすべてを書いてはいけないんだ（コントロールにすべてをかいてはいけないんだ！）」という、明確な答えが無いから、？？？なわけよ。

　なんで、そこを説明しないといけないわけよ。

　で、そこ説明しようと思ったんだけど、書くと長くなりそうなんで、またいつか（たぶん、次回ではない。次回は違う話の予定）。

＊今日の話で、いろんな人のブログから引用しています。
　それぞれの引用箇所には、リンクを張っておきました。
ただし、リンク先の人が、ウィリアムのいたずらと同じ文意で、この言葉を書いているかどうかは疑問です（というか、ちがう気がかなりする）。

＊ブログの文字の大きさ実験中。今日は、おおきくなってるかも？？

windowsパソコンのリスクヘッジとしてのLinuxとOpenOffice

　ウィルスバスターのパターンファイルをアップデートすると、コンピューターが使用できなくなってしまう問題（現在は直っている模様）について、多分、多くの記事は、テストの問題なんかを挙げるんだと思います。

　しかし、バグをなくすというのは現実的だとは思えない。

　現実的な回答としては、これからも、ウィルス対策ソフトで障害がおきたりすることを想定し、Windowsパソコン以外でも、最低限の作業ができるように、LinuxやMacをおき、OpenOfficeをいれておくなどのリスクヘッジが必要になってくるだろう。

　そうしておかないと、障害がおきたパソコンを復旧する情報をWebで流される可能性があるからだ。
　パソコンが障害で動かなくなっているのに、その情報を、（パソコンを使わないと見れない）Webで公開されてもねえ。。。

　ということで、Linux関連会社が、この機会を商売に結び付けられるか。。。
　たぶん、結び付けられないだろうな。。。