要求仕様書に書く項目と、情報処理試験のお勉強について

　このブログで、要求仕様書について、あんまり取り上げていないので、今日はその話。
　きのう、そんなわけて、要求仕様書についての、市場調査？？をしてたら、はてなに、「要求仕様書の書き方サンプルって、どこにありますか？」とあった。

　で、書き方サンプル、昔は、情報処理試験のテキストの中にあったのよ。で、いまは、要求仕様書のサンプルの本が出てるんだけど、今の話をする前に、まずは、その情報処理試験のテキストにでていた、要求仕様書の話。

---

　情報処理試験が、第一種、第二種とかいう感じだった時代、ＣＡＩＴ（中央情報教育研究所）が、情報処理試験のテキストをだした。
　その中の一冊

「第一種共通テキスト　１５　応用システム開発技術」
ISBN 4 -89078-452-7

　のなかに、要求仕様書をはじめ、外部設計、詳細設計で書く、各種のドキュメントと、その書き方が書いてある（ちなみに、これとプロダクションエンジニアテキストの上下、アプリケーションエンジニアテキストを合わせると、一通りのドキュメントの雛形ができると思う）。

　で、要求仕様書は、その第一種共通テキスト１５　の１１０ページが目次、それぞれの内容が、１１１ページから１２３ページまでにある。

　内容を書いてしまうと、著作権違反になりそうなので（インスパイアされたといえばＯＫ？）、まあ、引用として、１１０ページの見出し（目次）だけ書くと、こんなかんじ


・システム開発の必要性
・システムの目的、目標と達成課題
・システム機能
・情報要件
・システム構成
・安全性、信頼性、性能要件
・費用対効果
・システム移行、運用、保守要件
・開発スケジュールと工数
・外部設計指標

---

　で、昔、システムの業界では、こんなかんじで、仕様書雛形の見本みたいなのができ、情報処理試験の勉強をすることで、それがわかっちゃったりした。
　なので、昔は、情報処理試験のお勉強というのは、ちゃんとテキストを読んでやれば、意味あったんだよ。なんたって、はてなで、質問する人がいるくらいなんだから。。

　ただ、その後、オブジェクト指向などがでてきて、この仕様書なんかは、まったく無視されるようになってきた。そして、オブジェクト指向のコンサルなんかが、はばをきかせて、要求分析は、こうだとやってしまい、若手は、それに乗った。その一方で、構造化分析を主張する人たちの要求分析方法っていうのもあるわけで、これも、こーあるべきと主張した。

　この構造化分析とオブジェクト指向は、まさに神々の争いで、そのうち、神学論争になっていくわけだ。細かく流派がわかれ、統合したりして、難しい用語を使い、他人と差別化する。その結果、身内の人間を作業員・ワーカーさんと差別化し、馬鹿にしているうちは、よかったんだけど、ユーザー自体にも？？？となってしまい、わけわかんなくなってしまった。

　さらにさらに、事態を悪化させたのは、このオブジェクト指向も、構造化分析も、機能要件分析はできるんだけど、非機能要件抽出の枠組みや、費用対効果を導き出す部分はない。。。

　。。。やばくなりそうな話なんで、このへんでやめる

　で、今、要求仕様書の業界コンセンサスというと、違ったものになっている（そんなもん、ねーよ！と主張するかもしんないんだけど、売れてる本をみると、みんな、ある規約を基に書いてるの気がする）。

　情報処理試験自体も、いま、テキストってないんじゃないかなー？？あるのかなあ？？

---

　で、上にかいた、ある規約なんだけど、これが、IEEE Std 830-1998なんだけど。。。
　休み中、このブログを見てくれる人がすくないんで、休み明けに「覚えていれば」かきますね。

EVMSの危険性

　っていっても、Linuxのほうのファイル関係ででてくるEnterprise Volume Management SystemのほうのEVMSの話じゃなくって、アーンド・バリュー・マネジメント・システムのほうのEVMS

---

　EVMSは、まあ、情報処理試験のお勉強とかでやったかもしんないけど、まあ、こんなかんじ。っていうことで、すべての作業を金銭価値に置き換える必要がある。っていうことで、仮にテストなんかで、この考え方を導入しようとすれば、m_pixyさんの「PM見習いの読書日記」のこの記事にあるように

なんでスケジュールを細かい作業の１分刻みで与えないといけないの？

っていうことになる。

（なんで、っていうことに答えておくと、EVMSで管理するには、全部金銭的価値に置き換える必要がある。ここで、金銭に関係するのは、１人月単価になる。もし、あるテスト項目が、だれかさんがやって、それが何分ってわかれば、（１人月単価／６０分＊８時間＊２０日（１ヶ月２０日の場合））＊何分で、そのテストの金銭的価値がもとまり、EVMSで管理できる。だから、分単位で管理する。この時、人によって、作業内容が変わってしまうと、何分という細かな時間もずれる。そこで、かなり細かく、一意になるような作業指示にしないといけなくなる。なになにを押すみたいなかんじで）。

---

　しかし、EVMSは、品質を保証するかというと、これは、疑問である。

　品質保障の内容は、含まれていない。そこで、品質保証の指標として、テスト項目の設定率にしてしまうと、昨日の問題が起こる。つまり、これだと、品質が保障できないから、自主的テストをやんないといけないけど、EVMSでやっている場合、そんなことを認める余裕はない（結局、お金が発生するのが分単位っていうことで、分単位で、管理されるから、そんな余計なことをやる余裕はない）。

---

　つまり、EVMSで管理すればいいっていうもんでもない。
　でも、EVMSが、はやっていたりする。

---

　すみません、今日、テスト容易性設計と、自動生成とか、その辺の話を書こうと思って、まあ、こんなところの話でも、もってこようと思ったんだけど。。。そこに

テスタビリティを考慮するトップダウンの階層設計手法を前提としています。現在では、各設計プロセス間（合成とスキャン挿入間など）で設計のやり取りが必要な従来型の「問題解決型」の手法は適用しにくくなっています。問題解決型の設計手法では、各設計プロセス間の統合で発生する問題に対応しきれないことがあり、結果的に設計のやり直しによるスケジュールの遅延の原因となります。


そーだよね、そーなっちゃうよね。
でも、それをかくとお。。。
ひなんごうごうになっちゃうだろーなー

と思って、やめて違う話題にしたので、今日は、しょーもない話になってしまいました。

Linux上でWindowsソフトを動作させるDavidの独占販売契約をターボがとったみたい

世界初！ターボリナックス、リナックス上でWindowsソフトを動作させる
「David」の独占販売契約を締結
らしい。元ネタは、ここ

　で、しくみについてなんですけど

Davidは、動作させるWindowsアプリケーション共通モジュール(Davidエンジン)と、アプリケーションごとに異なるプラグイン型モジュール(Davidイネーブラー)で構成され、Turbolinux上でWindowsアプリケーションを動作させることができます。


　つーことは、たぶん、共通モジュールで、システムコールの呼び出しをおこない、プラグインモジュールのほうで、EXEファイルから、システムコール変換をするのかなあ？？

　問題は、このてのやつって、ちゃんと動くかどうか、どこまでテストしてくれるかどうかだよね。。
　文書作成系は、すぐに、おちてもらっちゃ、困るわけだし。。。

　ただ。。。

Linux上でWindowsアプリケーションを違和感無く共存させる同機能の実現により、ユーザーのリナックス利用が格段に容易になり、今後ビジネスとコンシューマの両市場においてリナックスの採用が加速されると期待しています。


　あのー、Linuxべんちゃーのお偉いさんと話すと、そう思ってる人、多い印象受けるんだけど、WindowsのソフトがLinuxで動いても、Linuxを使わないのよ。。

　なぜならね。。。

　Windowsソフトは、パソコン買うとついてくる
　Linuxは、フリーとか言いながら、お金出さないとかえない。

　わざわざ、お金だして、Linuxかって、今と同じWindowsアプリケーション動かして何が楽しいのよ？
　Linuxじゃないと、できないことがないと、わざわざ、お金出して買わないだけど。。。

　でも、Linuxのお偉いさんたちは、ユーザー層を広げるために（そうすると、多くさばけて儲かると思っている）、Winodows層の人たち、とくに初心者を取り込んで。。そのためにインストールはやさしく、Windowsソフトはうごいて。。って、かんがえるのよねー。

　その考え方は、売り上げはあがっても、利益は上がんないと思うんだけどね。

　利用者を増やすと、サポート要員も増やさないといけない。パッケージの売れる量より、サポート要員の費用のほうが、普通高い（すべてノンサポートにしても、ある程度売れ出すと、会社に電話がかかってくるのが実情のはず。なので、サポート版とノンサポートを分けたほうがＧｏｏｄ）

　そこで、ＯＳより、サーバーサイドのアプリのものをとりいれ、一件当たりの単価をあげたほうがＧｏｏｄ。

　そういう意味では、前、Turboを持っていて、ライブドアに売った、ＳＲＡの戦略は正しいと思う。
　ＳＲＡは、PostgreSQLのほうにすすんだけど、たしかにPostgreSQLのほうが、ＤＢコンサルなど、利益率の高いビジネスが組めるから。。。

　って、話ぜんぜんそれてきたので、このへんで。

テスト項目設定率で品質をはかる危険性

　テストの品質の指標のひとつとして、テスト項目設定率として、１０００ステップ（１Ｋｓ）あたり何件のテスト項目を設定したかどうかで確認する方法があります。
　何年前かのたしか、情報処理試験、プロジェクトマネージャーの午後１にも、それを基にした、問題があったと思います（この設定項目数を満たしていなかった場合、どうするか、その場合の費用負担はどうなるかなど）。
　なので、これと、バグ出現件数（これも１Ｋｓあたりの件数で表す）をあわせて指標にすることがあると思います。

　でも、この指標、危険だったりします。

---

　ループや、場合わけの場合に問題が起こります。
　たとえば、１００個の場合があって、それらが、１０個あるメソッドのいずれか１個を呼び出している場合、こんなプログラムになります
switch(sts)
{
　　　　case　1:
　　　　case　3:
　　　　case　16:
　　　　　　　　return M01(args);

　　　　case　2:
　　　　case　4:
　　　　case　19:
　　　　　　　　return M02(args);

　　　　　　　　:
　　　　　　（省略）
　　　　case　35:
　　　　　　　　return M10(args);　　//　１０個目のモジュール
　　　　}

このように書いた場合、１００通りしらべる方法と、１００個の値のうち、同じモジュールを呼び出すものは同値と考え、１０個分調べる考え方があります。
　でも、ここで、一番間違えやすいのは、case文の文字です。
　今回はいいけど、case '19':とcase 19 （数字と文字）の間違い(''が抜けている）とかとか。。こぴぺしたとき、最後の行が抜けたとか（最後の行に改行を打たず、一番下まで言ったと思ってこぴぺしたら、最後の行だけつかめてなくて、コピーできていないとか）。
　つーことを考えると、１００とおり、やるべきです。

　でも、１００とおりやらなくても、上記の場合だと、１０通りしらべるだけで、テスト項目設定率は結構高くなり、品質上、問題なくなります。逆に、ここで１００通りやると、やりすぎみたいな数字が出ます。
　この手で、特に困るのは、ループしている場合です。順番で、Ａメソッド、Ｂメソッド、Ｃメソッドとやるのと、Ｂメソッド、Ａメソッド、Ｃメソッドとやるケースがあるとき、１つだけチェックしただけで、テスト項目設定率的には、十分ってことがあります。

---

　実際には、仮にテスト項目設定率的には、十分なので、単体テストでやらなくても、結合や、総合テストで、たいてい、全ケーステストされるので、大丈夫なことは多いんですけど、結合、総合で、テストを縮退してしまった場合や、仕様書を書く人が、そういうことに気づかなかった場合、テストされずじまいになってしまい、お客さんのところで、急に問題が起こり、どういうテストしてるんじゃいということになったりするかもしれません（え、そういう話があるのかもしれません、ないかもしれません。ご想像にお任せします）。

---

　逆に、帳票出力の場合、こまります。値を設定するのに、いろいろプログラムを書くのですが、結局１本道で、分岐もなく、帳票を出せばわかるというときがあります。
　だからといって、テスト項目設定率でいくと、このテストを１個しかしないと、２００ステップにテスト１個なんていうケースが出てきてしまい、とうてい許されない話になってきてしまったりします。
　なので、この場合は、ログをいれて（いれなくて、帳票の目視でもＯＫだと思うけど）、各項目の値を確認するので、１項目にしたりします。

---

　基本的に、テスト項目設定率は、上記のように、ループの問題を解決できないという点で、C0（命令網羅）の指標に近いのですが、じゃーＣ０かというと、命令網羅としては、帳票なんか、一本道だから、１つのテストでいいはずなのに、いくつもテストしなきゃならなかったりします。

　ということで、この指標は絶対ではないんですけど、情報処理試験にもでるように、かなり使われています。

---

　で、この問題を、どうしているかというと、自主的テストというのがあって、ＰＭの判断で、テスト項目設定率がすでに規定を満たしているのにもかかわらず、テストをしてもいい（する）場合があります（情報処理試験のさっきの問題は、設定率が規定に満たさないとき、理由を書くものだったが、その逆のパターン）。

　で、ふつうは、どこかのテストで、全数をテストする形になっていると思います。
　じゃないと、客先で問題出るかもしれないので。。。

全数をテストする形になっていると思います。

全数をテストする形になっていると思います。

そうですよね。はい。やっぱ、全数テストしないといけないですよね。

たった、５００通りくらいですもんね（＾＾；）

さ、ばかいってないでやろうっと。

コンサルティングコーチングをヒアリングへ応用できる？

ものものさんのブログのコンサルタントの中に、

でも「考えることを迫る」ことを可能にするには、かなりのブランドや権威を持たないと難しいだろうなぁ。

ってあったので、このことについてのお話。

---

　たぶん、コンサルタントの世界のなかでいえば、これをやらせる方法として、コーチングが存在するんでしょうね。ということで、コーチングについては、atsushifxさんの「流行ってるみたいですよ」にも取り上げられているけど、たしかに、数年前から、はやりのようですね。

　中小企業診断士の実務更新研修（ことしで、実務研修は終わりだけど）なんかだと、コーチングがいちばん面白い（つーか、ほかのつまんなーい！）ので、コーチングに何度も出てしまい、まあ、一応そのやり方というのを教わってくるのですが（といっても、コーチのプロである、コーチ２１の人たちには、ぜんぜん及びもしないわけですが）そこで、習うことは、
コーチングは、相手に考えさせえる（考えることを迫る？）ことであり、その方法として、質問によって、相手に考えさせるわけですが（この辺、ソクラテスの問答法と同じなわけね）

その方法は、
・限定質問をしない（２者択一で答えられる質問でなく、どうしたいというように聞く）
・肯定的にする
・・・あとひとつ、なんだっけ？？
とかあったと思います。

　もちろん、ソクラテスの問答法みたいにやるわけですから、このブログのかなーり前のほうに書いたとおり、ソクラテスの問答法を応用すると、わるいおにいさんが、きれいなおねーさまをふーぞくに売り飛ばす方法になってしまうので、そのような手法は、コーチングでは禁じられています。
（つまり、自分の意図に反する質問に対し反論し、自分の意図に沿った質問を肯定するというような行為は禁止されています。基本的に、相手の言葉を受け入れてあげる）

---

　で、なんで、コンピューターのブログにこんなことを書いているのかというと、コーチングの手法をとりいれ、業務のヒアリングができるのではないか？考えることを迫るんだから、それがいいじゃないか？と思われるかたが、いらっしゃると思うからです。

　ウィリアムのいたずらも、はじめ、そう思ったんだけど、最近は、どーなのどーなの？と思います。

　コーチングのやりかたは、限定質問をしません。なので、話がまとまんなかったり、ひろがってしまったりします。なんで、まとまりのない話になってしまったりします（たぶん、コーチ２１出身のプロコーチなんかだと、テクニックを持っていて、ちがうのかもしんないけど・・・それを受講するほど、金がなかったりする）
　そいと、コーチングの質問は、4W2H(1Hだったかな？）で、(5W1Hの中にある）Whyというのを、ききません。Whyというのは、相手を責める質問になるから。なので、これはこれでいいですけど、目的を知りたがる人だと、使いにくいかも。ついつい、「なぜーなぜーあなーたは」と聞いてしまうかも。

---

　てなかんじで、実際に意識してやろうとすると、やりにくいかも。。。

　プロレベルになると、またちがうんだろうけどね。

　でも今度、プロコーチになってしまったら、システム開発なんて、やんないよねえ、きっと。
　プロコーチ＝コンサルでかっこいいし、おかねいっぱいもらえるしさ。
　（そのための、投資金額が、またたいへんなんだけどね）

　そーいえば、更新研修の講師って、いつも、黒須先生と、米澤先生だけど、黒須先生はＳＥさんだったみたいだし。。

---

　あ、ただ、一言つけくわえると、コーチングは、上司が部下を動かすのに使うより、部下が上司にしたほうがやりやすいといわれる。

　なぜなら、上司が部下に「どう思う？」と聞いても、部下は何も考えてない、それを考えるのが上司の仕事だろう！って思っていることが多いんだけど、逆に、部下が上司に聞くと、「だからあ、おまえにやってほしいことは、”これなんだよお”」と、明確にやって欲しいことを思っている場合が多いからなんだそうな。

　うん？そーするとだよ、

　上司が部下に、コーチングする
　　＋わるいおにいさんが、きれいなおねーさまをふーぞくに売り飛ばす方法
　　　　＝上司のことを、操れる！？

　そして、

　わるいおにいさんが、きれいなおねーさまをふーぞくに売り飛ばす方法
　　＝自分の意図に反する質問に対し反論し、自分の意図に沿った質問を肯定するというような行為！？

。。。実践してみて、どうなっても、ウィリアムのいたずらは、責任は持ちません。

　コーチングは自己責任で（＾＾）ｖ

富士通は、マイクロソフトとまではいわないけど、他社よりかは優位にたてたのに。。。って話

　富士通は、J2EEのプラットフォームとしてInterStageというのを使い、そのプログラミング方法として、CBM,CBSというものを使います（表現としては、不適切かもしれません。とにかく、富士通は、J2EEのとき、CBM,CBSを使います）。

　このCBMとCBS、ちょっと考え方を変えれば、MicrosoftのLINQのような考え方を、Javaで容易に実現でき、生産性も、他の会社に比べてあげることができたのに。。。みんなが、楽に開発できたのに。。でも、考え方が悪かったせいで（＞＿＜！）というお話。

---

　このＣＢＭとＣＢＳとは、
　ＣＢＳ＝ほぼセッションBeanのこと。
　　　　　トランザクション管理と、エンティティの呼び出しを行う
　ＣＢＭ＝ほぼ、エンティティBeanのこと
　　　　　資源に対するマッピング、操作を行うクラスです。

　で、たしか、私の記憶だと、ＣＢＭ，ＣＢＳともに、コントローラーとなる部分と、実態の操作部分をもち、クライアントとやりとりするメッセージクラスを持ちます（CBMメッセージ、CBSメッセージ、バリューオブジェクトに、役割的には相当する）。
　で、このメッセージ交換は、CAANMsgクラス（だったかな）なのですが、このCAANMsgは、ハッシュマップに変換できます。実際には、ハッシュマップが飛んでいるイメージです。

---

　ということは、昨日までのウィリアムのいたずらの考え方を応用すれば、

　ＣＢＭに、汎用ＲＤＢアクセスのクラス、
　　　　　　汎用ＸＭＬアクセスのクラス
　　　　　　汎用的メールアクセスクラス
　などを１つつくって、

　ＣＢＳに、とりあえず、その汎用ＲＤＢアクセスのクラスを読み出したり、書き出したりするクラスを１つづつ提供しておけば。。。

　ＳＱＬで、Where句をかくとき、どのように変換しなければならないかは、クラスからわかるわけですから（それは、前のブログで示した）それをもとに、SQLを作れるわけです（しんふぉうえあを使う場合には、NCを付けないといけないけど、それは、日本語クラスを作ればいいだけだし、そもそも、Prepare Statemantを使う場合は、いらない気がした。。。気のせいかも）。
　つまり、ＤＢアクセスクラスは、ＣＢＭ，ＣＢＳ１つづつ（実際にはいくつかのクラスに分かれるが、各テーブル分用意する必要はないという意味）。でＯＫとなるはずです。

---

　この場合、各テーブルごとに用意するときにくらべ、ソースが少なくなるので、管理が楽になり、生産性があがる。。。だけじゃないんです。

　この方法を採用すれば、ＣＢＭに、ＣＳＶを読み込むテキストファイルのものを提供することにより、ＤＢアクセスしないダミー用のものをつくれる（シナリオをテキストファイルをつくってチェックするツールはあるけど、ＣＳＶファイルをテーブル代わりに、読み込み、更新するっていうものではない）っていうこともあるし、そもそも、テーブルごとだと、ＣＢＭ，ＣＢＳを作る人が必要になる。その人がつくって入れるまで、業務で利用する側は、作業がとまる。
　ところが、これの場合は、ＤＢのほうが対応すれば、すぐに、使うことができる。

　つまり、途中に人を介在させないため、各テーブル作成時に必要となる人の都合・連絡・コミュニケーション一切考えないでいい。
　なので、生産性は、ずいぶん上がる。。。（コミュニケーション不要という部分で、ずいぶん上がる）

---

　なんだけど、実際には、そういう方向には進まなかった。

　たぶん、世の中の流れからなんでしょうね。

　世の中は
・入出力用のハッシュマップを使い、テーブルごとにクラスを作成する
・入出力用のハッシュマップを使い、１つのクラスで行う
　とあったとき（ハッシュマップ＝CAANMsg)下の方向でなく、上の方向に進んだ。

　つまり、すべてのテーブルのクラスを作成し、その作成が大変なので、自動化する方向へすすんだ。（それが、EJBBuilder）。そのため、EJBBuilderのバージョン管理まで必要になって、現場は。。。って言う話は、あんまりにもやばやばな話になってくるので、カットしよう。

　しかし、このテーブルごとにクラスを作成してしまう方法は、結局、Ｏ／Ｒマッピングとおんなじようなもんで、ここをEJBBulderでカイゼンしても、他社との差別化は、さほどできないことは、想像できよう（Hibernateを使うのと同じようなもんっすからね）。

　ただ、もし、関係者が読んでいれば（って、読んでいるとは思ってないで書いているんだけど）そこ（＝テーブルアクセス部分。それ以外の部分は必要）のＣＢＭ，ＣＢＳ作成部分がなくなるというだけで、かなり生産性が上がり、他社との差別化が出来そうなことは、想像できるんではないでしょうか・・・

　そして、MicrosoftのLINQは、それをやろうとしているって、ことだね。

---

なーんて書いちゃって、じつは、やばやばだったりして。。。
もし、ゆりかもめのなかとか、もんじゃやきたべながら、みんなよんでたら。。。
どーしよー（＞＿＜！）

ハッシュマップとＸＭＬの相違点とハッシュマップの優位性

　非常に唐突なのですが、あるメソッドに対して、データの受け渡しを考える場合、普通は，ハッシュマップ（項目名が必要ない場合はVector)か、XMLが検討されると思います。

　富士通のJ2EEフレームワークである、InterStageにおいても、Beanとのやり取りに、XMLとハッシュマップが検討され、ハッシュマップになったというのが、どこかのマニュアルに書いてあったと思います（ごめん、どのマニュアルだったか、思い出せない）

　そこには、HashMapのほうが、当時は「良く使われているから」という話でしたが、実は、それ以外にも、大きな優位性があります。

　それは、XMLの場合、インスタンスだけでは、項目名（タグ名）と値だけしか表現できません。もし、その値の型を表現したければ、それ以外のところに型を持つか、属性として、型をあらわす属性を持たないといけません。

　それに対し、HashMapの場合には、値を格納するクラスの型が取得できます。
　つまり、HashMap のgetで取り出した値のgetClass()をすれば、クラス名が分かります。
　instanceOf演算子によって、クラスによる振り分け処理が出来たりします。

---

　この、HashMapの場合、値を格納するクラスが取得できるということに、どれだけのメリットがあるのか？ということなのですが、例えば、データベースアクセスのようなとき、便利です。
検索結果を、HashMap１個につき、１レコード、検索条件をHashMap1個につき１And条件とします（orで結ぶ場合、orの分、ハッシュマップができる）。

　SQL文を書く場合、Where句は、
　　　Stringであれば、''でくくる
　　　数値であればそのまま
　　　日付はＤＢによって記述が違う
　という特徴があります。これらについて、ハッシュマップの値の型をみれば、振り分けられます。
　したがって、あらかじめ、各テーブルの項目の型をしらなくても、HashMapなら、SQL文が作れます。ということは、テーブルに依存しない汎用的なSQL作成クラスが作れるということです（＝１つのアクセスクラスでＯＫ）。

---

　現実的には、ＤＢに、しんふぉうぇあを使う場合、SQL文で、日本語のところはNCという言葉がつきます（例：　item1 = NC'ある'　） このような場合、渡された値が日本語かどうかをチェックしてもＯＫですが、ncharというクラスをつくり、そこに値をセットし、ハッシュマップに入れてもＯＫです。nchar型がきたとき、しんふぉうえあだったら、NCをつけ、そうでないＤＢのときには付けないといった使い分けが出来ます。

　つまり、型をみて、処理を切り分けることができるということです。
　ちなみにさらに、リフレクションを使うと、型によって、必要な処理をプラグインで行うことができるということになります。

　また、自分でクラスを作る場合には、その中に、値以外の、いろんな属性値を作ることが出来ます。やる気になれば（必要ないと思うけど）仕様書の内容、まるまる入れることもできるわけです。

---

　ただし、これはHashMapの専売特許というわけではなくて、XMLでも、属性値に、型や、その他の事項を盛り込むことで、可能ではあります。

ＬＩＮＱがDBアクセス方法を変えるかもしれない

データベースのアクセス法については、ここ２，３日のブログに書いているように

・テーブルごとにクラスを作成する
・１つのクラスで行う

　とあり、現在はテーブルごとに、クラスを作るのが、普通になっている気がする。
　しかし、昨日のブログに書いたように、ある日突然、方法論が変わることがある。
　で、この突然変わる変化になるかもしれないと思うのが、Microsoftが発表したLINQだったっりします。

　LINQは、ＤＢアクセス、ＸＭＬアクセスなどを統合したアクセス方法です。
　つまり、後者の「１つのクラスで行う」に近い方法だと思います（かならずしも、１つのクラスになるわけでなく、この上に、テーブルごとのクラスを作っちゃえば、やっぱり今までどおりになっちゃうんですけどね）

ＭｉｃｒｏｓｏｆｔのＬＩＮＱ説明はここ
http://msdn.microsoft.com/netframework/future/linq/

日本語で、説明している方がいます。
C# 3.0 + Linq Project PDCにて発表!!!

XMLとＯ／Ｒマッピングを統合したレイヤを設けていて、その下にＯ／ＲマッピングのＤＬｉｎｑ、ＸＭＬのXLinqがあり、さらに、レイヤはプラグイン可能ということですので、テキストファイル、プロパティファイル、外部のＳＯＡを利用したい場合なんかは、それぞれそれらのサポートレイヤを作るということになるんじゃないでしょーか？

　これ自体は、Windowsベースですが、今までウィリアムのいたずらが示してきたとおり、ハッシュマップを使って、おんなじようなものが作れるわけです。これが、今度、時間があったらかくかもお！といっている

４．入出力用のハッシュマップを使い、１つのクラスで行う

だったりします。今までは、この方法は、無視されてきたけど、今後、急激に、こちらの方向に行く可能性はあり得るかも？？（まったくあり得ないかも知んないけどね）

コンピューターのトレンドは、正反対の方向に変わる。なので、先端企業が、出遅れ企業になりやすい

　昨日のブログで、コンピューターのトレンドは、宗教的になっていて（＝事前に批判的に検証していないで、盲目的に、その意見は正しいと思い込む）その時々のトレンドによって、開発が進み、そして最後に「で、さらに、この宗教には、宗教改革があるんだな（＾＾）ｖ」
　と、書きました。今日は、その宗教改革について

---

　この業界のトレンドは、大きく変化します。それも、昨日言ったことと、正反対じゃん！という方向にかわります。
　引越し中、昔の日経コンピューターが出てきたんだけど、そこでは、「ＣＯＢＯＬ文化は終わらない」みたいなことが書いてあった。いま、そんなこという人、いないでしょ。

　昔、インターネットつーか、イーサネットのＣＤＭＡ／ＣＤという方式自体、かなり批判的だった。コリジョンが起きると回線が急速に利用しにくくなる、優先的にデータを送れないなど。。でもいま、そんなこという人いないでしょ。ＨＤＬＣ伝送制御手順なんて、多分言葉すらわかってもらえない。

　昔、コンピューターのテストで、ＪＵＮＩＴみたいに、ドライバから呼び出してテストしたやつで、「単体テストしました」っていったら、もう、その時点で、「お前クビ！」でしょ。
　ホワイトボックステストして、値を確認して、確認したエビデンスをとってだなあ。。

---

　でも、この業界、ある日突然、いままで、「ありえなーい！」と馬鹿にしていたものが主流になって、今まで主流だったものが、今度「ありえなーい！」と馬鹿にされる立場にまわるのです。突然です。後から考えると、どこで変わったかわかんないくらいです。

　ＮＥＣのＰＣ９８０１シリーズ、パソコンといえば、これだったのが、ある日、どこからか突然、パソコンといえばＤＯＳ／Ｖに変わりましたよね。。。あんなかんじ。

---

　ということで、人でも、会社でも、設備でも、今主流なものに、本格的に投資してしまうとたいへんです。投資すればするほど、宗教改革が起こって、いままでのものが異端になると、いままでの投資に足を引っ張られて、出遅れます。

　たとえば、ＣＯＢＯＬで汎用機で莫大な資産を投じて、システムを作ってしまうと、今度、今のように汎用機を否定されてしまった場合、その資産の移行に莫大な労力を必要とします。
　お金だけの問題なら、新品を作るのと変わらないので、いいのですが、問題は人です。

　人の考えは、そうそうかわらないし、プライドもあります。

　ひどい会社だと、部下のことを、○○！と、呼びつけにします。
　こんな場合、時代が切り替わると、呼びつけにされてた人が主役です。会社の中心は、その人になります。もしかすると、いままで呼びつけにして、「後輩」なんて、思ってた人が、自分の上司や、もっと上の雲の上の人になるわけです。なんたって、時流に乗ってますからね。

　こんなときに、まだ、自分の後輩だったと思って、○○！と呼びつけにするとさあたいへん。

　後輩だった人は、なにも気にしないかもしれないけど、後から入ってきた人などは、「なによ、あの馬鹿、えらそーにしてるけど、ただの昔の人じゃない。それなのに、呼びつけにして、自分の能力すらわからない、権威おやじなのかしら！」と思われ、周囲の白い視線であります。

　なこともあるので、ふつう、ソフトハウスでは、○○とよびつけにせず、○○さんと、さん付けでよびます（逆に大学教授なんかでも、さん付けで呼んでもかまわなかったりする。。けど、私はめんどくさいので、偉そうな学会の人は、全部「先生」をつけておく。一般企業は、さん付けで。私は、新入社員に対してもそうしてました。。っていうか、本当は新入社員が一番能力ないといけないんだけどね。今まで学校行って、一番新しいこと仕入れてきているんだから）

---

　てなわけで、宗教改革がおこると、一番投資していた企業が、一番出遅れちゃったりします。

　最先端行ってたはずの人が、今まで自分のやってきたことに固執すると、時代の空気を読めないただの馬鹿になってしまったりします。そうすると、いままで、「作業員、わーかーさん」と、馬鹿にしきってきた人以下です。

　なぜなら、ワーカーさんはそれなりに仕事します。
　　人によっては、馬鹿なりに、まじめに仕事をこなします。
　自分の仕事に固執する人は、固執してるから、まじめにやりません（やれません）。
　会社は仕事する人を評価します。

　ゆえに、ワーカーさん以下です。


　ということはですよ、実は、コンピューター投資っていうのは、必要最小限のほうが、変わり身がはやくできるので、本当はいいんですけど、そんなことをいうと、売れなくなるので、だれも、いいません。

---

　で、いままでなんで、こんな、どーでもいい世間話を書いたかというと。。。
　なんか、宗教改革が起こりそうな予感がするから。。。
　（つまり、今のＪａｖａのトレンドが変わるかも。。。え、この仕事がやたら来てる最中に、と思うだろうけど、そんな気が）
　それについて、覚えていたら書きます。

実際には、非効率的でも、新しいものをやりたい上の若手の人やお客さんの意見にきまってしまう。

　さっきのブログでは、ＤＢアクセスなどで、
３．入出力用のハッシュマップを使い、テーブルごとにクラスを作成する
４．入出力用のハッシュマップを使い、１つのクラスで行う

　だと、宗教上の理由で３になると書きました。
　その意味と、説明を書きます。

---

　実際に、どのように作るかという場合、工数的に楽とか、効率的とか、リスキーでないというよりも、

・現在の流行の人たちが、主張している意見とか、
・トレンドの流れから、そっちのほうがおしゃれな場合、

　そっちのほうの意見になります。

　ひどい場合なんかだと、本やネットで読んだくらいで、プロトも、てきとーに本にでているものを応用したくらいのものを作った状態のものでも、そっちがトレンドだと、やってみようと言い出す人がいます。
　コンピューター関係者以外だったら、ありえない！と思うでしょう。
　自分で、徹底的に使いこなして会得していないやつ、そんなリスキーなものを、平気で使うなんてと。。でも、今のコンピューター業界は、この流れが多いです。

　そのカラクリは、こんなかんじです。

---

　最近、オフコンを使ってＣＯＢＯＬで開発するっていう話、聞かないですよねえ。。。あんまり
　（まあ、売っていないということもあるが。。。）
　ＣＯＢＯＬでの新規案件って、かなり少ないと思います。

　でも、ＣＯＢＯＬとＪａｖａでは、どっちが生産性が高いかっていうこと、自分で書いて比べている、若い人は少ないと思います。最近の若い人の中には、ＣＯＢＯＬを馬鹿にするわりに、自分で書いてなかったりします。

　ＣＯＢＯＬでも、オフコンの富士通Ｋシリーズの場合には、画面もＤＢも、まったく同じレコード構造に入ってくる上、それらはツールで作成でき、画面側でエラーチェックしてくれるし、画面操作をレコード内の値を設定することでできる（レコードのある箇所に値を入れるとプロテクトになる）ので、生産性は高いです。

　でも、今ＣＯＢＯＬの、そういうものを使うという意見はありえないし、それどころか、その考え方をJavaにとりいれ、画面から、ＤＢから、すべての情報を１レコード、HashMapの中に入れるというような考え方をする人もいません。絶対いません。ただみんな、やってないけどばかにするだけです。人を馬鹿にするくらいだから、昔の技術なんていうことを、聞かれることもありません。

　２００７年問題とは、ＣＯＢＯＬを継承することではなく、それを言葉をネタに、新しくリプレースするためのセールストークです

---

　そんな感じで、この業界は、まったく新しいものが常に出てきて（といっても、昔の焼き直し＋あるふぁだったりするんだが）、それが妄信的に信じられ、宗教的になり、若手のプロジェクトマネージャーやアーキテクトクラス、プロジェクトリーダークラスのひとが、「絶対とりいれるんだ！」といいはります。なぜいいはるか、おしゃれでかっこいいから、今の仕事が面白くないから。

　で、営業はそれに乗ります。なぜなら、新しい考えのほうが、「売れるから！」

　なぜ、売れるか。。。お客さんが、新しい考えのほうが、先進的でかっこいいから、
　新しい、先進的技術を導入すると、売り上げ、生産性あーっぷと思って買っちゃうんですねー
　（実は、儲かるかどうかというのは、お客さん自体も、わからないし、検証してないことが多い）

　そのため、この業界は、宗教的にその考えを取り入れる（＝事前に批判的に検証していないで、盲目的に、その意見は正しいと思い込む）ことになり、神学論争に発展します。
　はたからみると、「それって、どーでもいーじゃん！」っていうことを、熱心に議論したり、やたら、難しい言葉をとりいれるのです。。。

　「どーでもいいじゃん！」などと、言ってはいけません。
　かれらは、それを主張することにより、先端をやっているというプライドと居場所を確保するのですから。

　そのような考えが出てきたら、営業といっしょに、「すばらしい！」といっておきましょう
　（営業はそのような考え、大歓迎です。なぜなら、「売れるから」）

---

　で、じゃあ、ウィリアムのいたずらのような、こっぱワーカーさんたち（末端の作業する人たち）は、どーするかというと、

　上の若手のえらーい人たち（でも、えらーいといっても、２次請けとか３次請けクラスなんだけどね）がいう技法で、本当にできるかどうか検証し、その考え方が、受け入れられない（明らかに破綻する）ときだけ、反対します。

　それ以外は、反対してもあんまり、意味ないので（反対すると、すげー、若手の上のほうの人から文句言われる割には、メリットがない。なぜなら、どんなやり方をしても、たいして、かわんないから、つーか、どんなやり方、どんな言語でも作れないと、いま、お仕事つづかない）はんたいはせず、対処法だけ考えます。

---

　つまり、３のやり方が多い理由は、今、それが、トレンドだからです。
　それ以上でも、それ以下でもない（おれは、ぷっちゃんか。。。極上生徒会を見てない人には、わからないと思うけど）

　で、さらに、この宗教には、宗教改革があるんだな（＾＾）ｖ

ＲＤＢで１００個テーブルがあると、１００個のクラスを作るが、実は１個のクラスだけでいい方法がある

　きしださんのブログに、ソフトウェア技術者は自分たちが哲学を行っているということを自覚すべきという記事があります。
　この記事は、そのとおりに思います（ただし、最後のほうの「メシ食わせろ」の意味は通じていませんが。。元がわからないので）。なんたって、「開発思想」なんていう言葉があるくらいで、昔のドキュメントには、延々と、それがかかれてましたから・・

　で、最近は、哲学通り越して、神学論争、さらには、宗教まで発展していると思います。
　そんな具体例をひとつ。

---

　このブログで、データベースのテストのお話を書いたとき、（１，２は省略）

３．入出力用のハッシュマップを使い、テーブルごとにクラスを作成する
４．入出力用のハッシュマップを使い、１つのクラスで行う

で、３について説明し、４はあまりないと書きました。

　つまり、現在の主流の考え方は、３の、テーブルごとに、クラスを作るという方法です（ハッシュマップにするか、データ受け渡しのクラスにするかの差はありますが）。
　こうすると、ばりゅーおぶじぇくととかＰＯＪＯとかの話が出てきて、かっこいいです。
　そいから、O/Rマッピングの話におとしこめて、Hibernateとか知ってるよ！使ってるよ！っていうと、かっこいいです。先端っぽいです。だから、みんな、こっちを使ってますよね。

　ウィリアムのいたずらも、こちらの自動化の話しかきません。

---

　でも、きっと、みんな、知っていると思います。
　しってるけど、いえないんだと思います。

　匿名（ウィリアムのいたずらというハンドル名しか、皆さんはしらない）ということで、この際言ってしまいましょう。

　「多くのプログラムでは、ＤＢアクセスクラスは１つですみます。さらにそれは、ファイルやEJB,SOAで、リモート先にアクセスでも、全部、そのクラスがかぶることができます。」

　こうつくります。

　さっき出した、ここのブログのメソッドに、テーブル(selectの場合From句、insertの場合into句など）を指定する引数を追加してください。そうすると、できます。
　Where句の作り方は、そのあとの説明「入出力用のハッシュマップを使い、テーブルごとにクラスを作成する」プログラムの中身のはじめのほう（もしくはの前まで）のやり方でできます。つまり、ハッシュマップで型がわかるので、それをもとに作ります。

　項目指定は、ならべればいいだけだし。。。

　ということで、From句の問題です。

　ここは、AccessとほかのＤＢで異なります。ほかのＤＢなら、テーブル名だけを並べておけば、自然結合してくれます。Where句の内容とかみて。。でもAccessは、Join－on指定が必要です。
　したがって、String MakeLeftJoinState(String imamadeNoState,String tbl,HashMap onKu)のようなメソッドを作って、on句の条件と、Joinするテーブルと、その前までのステートメントを引数として渡して、LeftJoinしたステートメントを返す（あるいはRightJoinしたステートメントを返す）メソッドをつくる必要があります。

　なんですけど、とにかく、そんなこんなで、クラスは１つにまとめられます。

---

　しかし、宗教上の理由から、このようにクラスを１つにまとめて使うという開発には、「私は、大きい仕事では」やったことないです。いつも、上の形です。（私が、大きい仕事でやったことないというだけで、ほかの人はあるんじゃないかな？また、自分で勝手にできる場合は、こっちを使っちゃうかな。。）

　その宗教上の理由とは。。。

　ひえー、こんな時間だ。。覚えていたら、今度書きます。

次期WindowsのＵＩ記述言語のXAMLやStrutsのタグは、画面設計書から自動生成可能か

　次期Windows Longhornにおいて、ユーザーインターフェースの記述言語として、XAMLっていうのがありますよね（ちょっと書き方正確でないかもしれんが）。
　で、今、どんなかんじか見てるんですけど（もちろん、将来、自動生成のお仕事がきたら、対応できるかどうかのチェック）。。。

　こんなところをね
http://www.microsoft.com/japan/msdn/longhorn/introducing/longhornch03.asp

うーん、どーなのかなー。
画面設計書をいったん書いてもらって、入出力項目を出してもらって、それをこのタグにおきかえるのが一番素直ではあるんだれどー。。。

　HTMLでFormで書いてもらって、FormのInputとかTextAreaを解析して、このXMLに置き換えるって言うのもありかなあ。。でも、めんどーそーだなー。もろに、HTML解析になりそうだ。。。やめよう。

　富士通の「ふぉーむこーでぃねーたー」（ごめん、正式名は英語だけど、つづり忘れた）の入力用ＸＭＬから、こいつに変換は、いけるかもしれないけど、テキスト部分って、あれ、とれたっけ。。

　たぶん、ドキュメントを生かすという点においては、
　ＨＴＭＬで作って、顧客に同意をもらって、そのHTMLからFormのINput,TextArea部分を切り出して
　画面設計書を自動生成、ないしは、画面設計書を書いてもらって、
　（１）今は、コントロール部分をStrutsタグで書き出してフレームワークはStruts、
　　　　ないしはHTMLのFormタグで書き出して、CGIとか、サーブレットとか

　（２）将来的にはXAML

　（３）テキスト部分は、あとから追加してよ

って言う線かなあ

---

　あと、もしくは、

（１）ツールでＧＵＩを作成してXAMLにして
（２）そこのタグをみて、画面設計書を自動生成

　うーん、こっちのほうが素直だな、

　ちょとまてよ！

　それって、画面設計書をＸＭＬで記述しちゃえば、Xalanとかの、XSLT使えばできるのか。。

　さらにちょっとまてよ、

　それができるんなら、画面設計書をXMLで記述すれば、XSLTで、ActionFormメソッドが自動生成できる
　　ってこと？？
　
　つーことは、ちょっとまってねちょっとまってね。。。

　あれ、GNOMEのやつのＧＵＩの（ちょー不正確ないいかたです）GTK+の画面を作るgladeって、保存形式XMLじゃなかったでしたっけ？

　じゃあ、それをつかって、コントローラー部分と、文字部分をXSLTでわけて、
　コントローラー部分から画面設計書を自動生成できるし、
　gladeのXMLから、XSLTで、Strutsタグをいれて、HTML書き出したり、
　ActionForm自動生成できて、

　さらに、将来的にはXAMLを生成できるということ？？

---

　gladeは、タダだし。。。。なにげにおもしろそう。。。

　え、ゆかりたんの、メイド服姿のほうが、興味しんしん！？

　そろそろ、おやすみやめて、おしごとしようっと！

ＩＢＭのＣＭで、迷子になったことをＲＦＩＤで知るって、ほんとにできる？？

　ウィリアムのいたずらが無知だから、知らないだけなのかもしれない。ということははじめにお断りしておきます。その場合は、ごめんなさい。

　ＩＢＭの、最近のＣＭで、
　　トラックがはしっていて、道の真ん中に女の人が出てくる。
　　トラックの人が、「あんただれ」ときくと、
　　女の人は、「ヘルプデスク、道に迷っているでしょう？」
　　トラックの人「どうしてわかる？」

　で、問題は、この後の、女の人の答え。無線はいいんだけど、最後、「ＲＦＩＤで」って言ってるよねえ。本当に、ＲＦＩＤの電波で、（数十メートルの範囲では「なく」、自動車に乗って道を迷った人が）迷子になったことを知ることができる？？

---

　ふつう、あのような迷子になったことを知る方法としては、プレゼンスを使うと思う。
　ケータイを使って、居場所を確認するってわけ。

　この場合、ケータイの居場所を知るには、ＧＰＳを使うか、ケータイの基地局を探す方法でわかる。
　これが可能なのは、ケータイがＧＰＳを受信できること、ないしは、ケータイの電波は、基地局までは飛ぶから。

---

　で、一方ＲＦＩＤなんだけど、ＲＦＩＤは、電波法で、免許をとらないでいい出力で、電波をだしているはず。

　あ、その前にＲＦＩＤつーのは、こちら
そこに

●長距離通信：数センチから数十メートル

ってあるように、ふつう１００メートル以内、つまり、目で見える範囲であり、迷子にはならない。

　で、たしかに、アクティブ型を使えば、定期的に送信はできる。
　（でも、ＲＦＩＤって、パッシブ型だった気が。。。）
　なんで、数十メートルなら、位置を確認できる。

　でも、数十メートルごとに、基地局をおく（もしくは、アンテナを立てて受信する）っていうのは、現実的じゃない。。。もし、そんなことが可能なら、ＲＦＩＤを使う必要はない。
　ETCみたいな形でできる。つまり、ETCみたいな装置を使って、各基地局（つーかＥＴＣと交信できる場所）を通過した車両を記録しておけば、いいことになってしまう。

　つまり、ＲＦＩＤの現行の出力では、迷子になったことに気づいたり、行き先を知って、先回りすることはできない

---

　じゃあ、免許をとり、無線機を商品に取り付け、それをＲＦＩＤだといったら、どうなるか。。（って、それって、ＲＦＩＤじゃないけどね）

　これも不可能。

　仮に何十ワットの無線機を取り付ければ、ある程度の距離への送信は、可能。
　でも、その周波数帯が問題。高い周波数帯にすれば、位置は、わかりやすい。
　だけど、直進してしまうので、多くの基地局が必要になるか、パラボラアンテナを立てて、一度、宇宙に向けて発射し、人工衛星か月に当てて、跳ね返ってくる電波を受信することになる。
　でも、多くの基地局をつくるのには、莫大なお金がかかるし、パラボラアンテナを商品につけることも無理でしょう。

　周波数帯を低くすれば、電波はとおるけど、跳ね返った電波なども受信してしまうため、指向性がよわくなる。そのため、位置を確認することが困難。
　もし、確認するとすると、巨大な八木アンテナかパラボラをもち、受信機片手に、探すことになる。。

　このかっこって、街中でやったらちょっとへんでしょ。

　きっと、片山さつき議員が、永田町を、タキシードセーラーきて歩くぐらい違和感あると思うよ（いや、そっちのほうが、違和感あるか）。

　きっと、佐藤ゆかり議員が、閣僚になり、メイド服をきて、閣議で小泉さんがきたら、「おかえりなさいご主人様」というくらい、アブナイ人に見えるよ（いや、そっちのほうが危ないか。。）

　つーことで（どーいうことだ）周波数を低くする線もないとおもう。

---

　なので、ＲＦＩＤで、迷子を捜す方法って。。。思いつかないのですよ。
　ふつうは、ケータイのプレゼンス技術を使うと思うんだけど。。。

　ほんとうにＲＦＩＤで、今の日本の電波法の範囲で、迷子になったのを見つけて、先回りできるの？？

（なお、ちなみにアクティブＲＦＩＤは、社内の迷子や、入退室管理、避難所にいるかどうかなどには使えます。そういうレベル（数十メートルの範囲にいるかどうか）の迷子については、つかえます。ここで問題にしてるのは、アメリカのアリゾナ砂漠のような、何十キロのところで迷子になった場合）

NHKでやっていた、中国のアンチウィルスソフト１００万本をだたで配るという話のＵＲＬ

ＮＨＫのニュース１０でやっていた、キングソフトという中国の会社が、日本参入するにあたり、アンチウィルスソフト（「キングソフトインターネットセキュリティ２００６」）を、１００万本、ただで配るという話のＵＲＬは、ここみたいよ
http://download.kingsoft.jp/is/?partner=kingsoft_000&header=1
（ただし１年目が無償であって、２年目からは９８０円はらう。詳しくはここ）

会社のＵＲＬは<ここ

ＮＨＫのニュース１０でちょこっと言っていた、オフィスソフトとかの話はここらしい

注：ただし、ウィリアムのいたずらも、まだダウンロードしていない。

最近のユーザーさんは、ものすごーいテストを求めてきたりするんです。

　テストについての話。
　ここのかたの話にたいして、ここのブログのかたが、意見を述べています。
　で、その内容を、問題にしようというのではなく、そこからちょっと単語だけをピックアップして、よたばなし（なので、おふたかたの言いたい内容とは、かけ離れてるって言うか、ぜんぜん関係ないことを前提に読んでね）。

ここのブログで、


突き合わせのテストを指向する限り、特に組み合わせテストを行おうとすると、現実的な工数でテストできることはあまりない


　って書いてあるんですけど、昔は確かにそうなんですけど、最近、そうでもないんですよ。。。

　ユーザーさんって、その現実的でないテストを求めてきたりします。

　ただし、ここでいう、テストは、ちなみに、平鍋さんのブログで出てくる、現実領域での、問題と解との突合せ、すなわち「テスト」である。で、さしている「テスト」じゃなくって、なんですけどね。
　つまり、平鍋さんの指しているテストは、分析モデルと設計モデル間の確認ですよね。つまり、要求仕様書に記載されている業務モデルと、設計したプログラムの一致の確認で、これは発注仕様書（＝契約書別添となるのが普通）に書かれている内容を、実機で動かして確認することになるので、これを全部確認しなきゃいけないのは、普通つーか、当然ですよね、じゃなきゃ、契約書別添にする意味がない。

　問題は、そうじゃなくって、単体テストとか、ＩＴ１についても、ぜーんぶの条件のテストを、最近求められるんです。

　なぜかというと、その答えが、m_pixyさんの「PM見習いの読書日記」のブログのなかの「テスト項目抽出方法」っていうのに出てくるんですけど、 ユーザーさんや、もしくは元請けさんが、「このテスト項目が出てきた理由はなぜか？」というふうにたずねられるんですよ。最近は。

　つまり、最近は、そのテスト項目を出してきた理由を説明する責任がでてきたんですよ。

　昔のユーザーさんは、そんなの求めなかった気がするんだけど。。。
　最近は、そうなんです。

　で、そこで、m_pixyさんも書いているけど、ＫＫＤとは、お客さんに提出するものには、かけない。

　つーことで、同じように、「バグの多そうなところを狙」うっていうのも、「なぜここが、バグが多いと主張できるのか、その根拠を説明し、ほかのところにバグがないことを証明せよ！」と言われると。。。答えられないので。。。

　結局そういうテストじゃなくって、全数の命令網羅か、条件網羅をするしかないんです。現場的には。

---

　でも、それって、非現実的なほど、ケース多いじゃないですか。

　そこで、方針を切り出して、テストを自動化しちゃうわけです。
　その方法を、このブログで、書いているのね。。。

　で、実は、最近のテストっていうのは、「バグの多そうなところを狙」うテストっていうのは、単体テスト「前に」やっておいて、バグをなくしてから、自動化したテストを通していたりする。
（そうしないと、時間がたりないのね）

　実際に、そういうテストをしないと、網羅率のステップ数が上がらないので、テストをやったことにならないんっすよ。それがいいかどうかなんていうことは、別問題っす。
　納品して、お金をもらうためには、それをしないといけないってことです。

---

　で、ウィリアムのいたずらのような自動化のテストをすると、

　ホワイトボックスに関しては、
「仕様書の記述における変数の値をログで確認するという観点から、すべてのケースをテストしました。」
っていえるし、ブラックボックスにおいては、
「画面において、入力項目にたいして、同値条件から分類し、全項目に対して、値チェックを行いました。」
　と、一応、かっこがつく説明がかけるわけよ。

　で、エビデンスがそろうわけよ。

　そうすると、納品できるわけよ。

　で、それが、いやなら、大きな仕事の下請けはやれない。。
　（でも、別にそれをやんなくても、お金がもらえるんなら、やる必要はないわけだし）
　っていうだけの話だと思う。