ＳＥ・プログラマーを、安い金額で、死ぬまで、こき使わせる契約の結び方

そうそう、以前のブログで、

　ちなみに、これを応用し、アジャイルとあわせると、ＳＥさん、プログラマーさんを、死ぬまで、こき使うことができる（それも、ものすごーい安い金額で）

と書いておきながら、その方法を示しませんでした。

たとえば、こんな感じ（もちろん、これ以外にも、テクニックあると思うけど）
（つーか、ウィリアムのいたずらは、これで、人生狂いました、はい）

---

方法

１、契約書を、機能ベースで契約する
　　・受注機能
　　・入出庫機能など

２、前払いで全額払う

３、開発者と直接契約を結ばない（中間業者が入る）

４、開発は、アジャイルで行うとする。
　　このため、途中の仕様変更を認める
　（アジャイルでなくても、仕様変更を認めれば、なんでもＯＫ。
　　ただ、アジャイルという言葉を入れると、耳障りが良い
　　契約書には、「アジャイル」とは書かないけど）。
　　仕様変更の場合の費用は、別途話し合いということにする。

５、請負契約にする

---

　これ、ウィリアムのいたずらのような、システムやっている人だったら、絶対結ばない、ありえない契約でしょう。

　だって、途中で仕様変更をみとめて、請負にして、機能ベースにするんだよ！

　論理的に出来ない機能と、あとでわかっても、「機能の意味が違う、おまえの理解が足りない、ヒアリングが悪い、ヒアリング時間が足りない」っていわれたら、どんなにヒアリングを十分やっても、いつまでたっても、出来ないじゃん（論理的に出来ないんだから）！

　しかし、相手が中小企業の場合、どこかおかしいから中小なんですよ！

　とくに、２世経営者の場合、「白いタキシードを着て、農業をやる（だれかのメルマガで読んだ言い回し。だれだかわすれた）」みたいなことを平気で言う。
　つまり、「実現は可能だが、ありえないでしょ！」みたいな。
　もう、論理的以前に、ちょっと考えるとおかしいような話を平気で言うわけ。
（普通、それって、コンピューター化しないよね、出来ないよね、みたいなネタ）

　でも、それが、改善だと、思い込んじゃっているわけよ！
　そういう夢を、ずーっと追っかけているから中小っていうケースがある。

　こういう場合、システム開発をずーっとやらせられる。
　それも、「おまえが理解してないからだ！機能はまったく変更していない」といって、お金払わない！

　仕様変更したら、お金がもらえる！！と思って、中間業者は、受ける。
　しかし、この場合、実際には、「仕様変更でない、お前が馬鹿だから、仕様変更のように聞こえるのだ！」と言い切れれば、お金は払わなくてすむ。

　なぜか。

　実際、裁判にもって言った場合、その期間、ソフトハウスが、費用的に耐えていくには、相当な金がかかる（開発者は、裁判関連に取られるし、弁護士費用もかかるし。。）。だから、実質、裁判になるのを嫌う（とくに、中間業者は）。

　よって、「仕様変更ではない、なんなら、裁判する？」という話になると、お金は取れない。

　結局、仕様変更をみとめてしまったら、相手の機能を満たすまで、いつまででもやらないといけない。契約内容が違うといわれてしまったら、その間、お金はもらえない（だから、仕様変更を認める場合、機能で規定するのでなく、入出力の物で規定する、機能で規定したければ、請負でなく、準委託契約で受けるっていうのが、いいと思う）。

---

　で、問題は、前払いされてしまった場合。

　このように、やばい！とわかった場合、普通、その開発からぬけることを考える。
　しかし、お金を受け取っていた場合、よくて全額、悪い場合は、さらに、違約金などの支払いもありえる。

　で、ここで、自分だけだったら、そういうリスクがあるから、絶対、前受けにしない。ところが、途中にだれかが入ると、そいつが、前受けしちゃう場合があるわけ。

　そうすると、そいつは、金を返したくない（というか、使い込んじゃってるんだよね、たいてい）から、お金をはらわず、契約を続ける。

---

　この結果、どうなるか。。。

　ウィリアムのいたずらのあったケースでは、

・ウィリアムのいたずらの前のＳＥは、はじめ言っていた機能とぜんぜん違う機能を開発させられ、さらに、それが、ＤＯＡでやると、ＤＦＤで矛盾が出るから（情報処理試験なんかの問題で出るパターン。入出力が合わない）でたらめ言ってるって、すぐに気がつくのに、オブジェクト指向で開発し、情報を隠蔽しちゃって、さあたいへん。
　（情報を隠蔽すると、出来そうに見えるのよ。。）

　結局、自分自身では、ユーザーの言っていることが、でたらめだと見抜けず（想像で言ってるだけだった。やっぱり、実際間違ってた）、うつ病になってしまった。
　→理論的にできないのに、その前受けで金をもらった人から、「はやくやれ」と攻め立てられ、何で出来ないのか、自分ではわからず悩み、うつ病になった。

・ウィリアムのいたずらは、その程度は気づいた。
　しかし、契約内容が、「準委託だよね！」と確認したのに、請負になっていた。
　（契約が、２本立てになっていて、もう一本が請負、で、こっちがメインだった）
　その結果、結局システム開発しても、お金がはいってこなかった（＞＿＜！）

　その期間、仕事できないこともあり。。。。

---

　てなかんじなんで、絶対に、機能だけで、契約しないほうがいいよ。

　あと、仕様変更、文書で取っていても、機能でとってたら、意味ない。

「おれは、そういうつもりで言ってない。だからこの契約は無効だ！」

　といわれたら、おわりだからね。。。
（こういって、契約を無効にされた人を、ウィリアムのいたずらは、聞いたことがある。無効にした人っていうのはあ。。やばやばそおな話になってきたので、かかないけど。。）

---

　ただ、この方法、仕様変更だと、すぐにわからせてしまうと、仕様変更のお金がとられてしまうので、うまくいかないのよ。

　その仕様変更と、気づかせないで、ＳＥをこき使うテクニックは、またこんど。

　って、どっちの立場で、書いてるんだか、わかんなくなってきたど。。

　　

仕様書からテスト項目を抜き出す方法と、情報処理試験 午後２の小論文とＴＡＣの関係

　昨日のブログ「仕様書から単体テスト以外のテスト項目を抽出する方法」を、Excelの表に無理やりまとめると、こんな感じになると思う。


　ということで、以前のブログ「プログラム設計書・仕様書から、単体テスト項目を浮き上がらせ、テスト仕様書を手作業で作成する方法」とあわせて考えると、結局テスト項目の抽出って、簡単にまとめてしまうと、こういう操作をやればできる？

１．まず、その行おうとしているテストに対して、テスト方法っていうのが、一般的にきまっているので、それを横に書く。
　　単体のモデルの場合、
　　　　その機能のよってちがうが、通過テスト、更新値のログダンプなど
　　単体のコントローラーの場合、
　　　　値の組み合わせ（境界値でチェックがいいかも）に対する起動をログで、など
　　単体のビューの場合
　　　　画面の入力値の境界値、字種、構文など
　　結合以上
　　　　対応する仕様書に書かれている内容のエビデンス収集としての
　　　　シナリオチェック、出力チェックなど

２．今回、調べる対象を縦に書く。これは、行おうとしているテストによって、書き出す内容が変わる。
　　単体のモデルの場合、
　　　　各機能
　　単体のコントローラーの場合、
　　　　値の組み合わせ
　　単体のビューの場合
　　　　画面の項目
　　結合以上
　　　　各機能（仕様書の見出しなど）

３．縦横の交点について、実際にテストが出来るかどうかを考え、テストできそうなら、その内容を記述する。

---

　つーことは、これって、情報処理試験の午後２の小論文のやり方と、一緒ですよね！
　まず、午後２の小論文は、

　あいさつぶん１行

　数十行の、世間話

　問題：あなたの経験なんとかかんとか、書きなさい
　（あ）プロジェクトについてなんとかかんとか　８００字
　（い）その問題についてなんとかかんとか
　（う）それをどう評価するか

　っていう形式ですよね。

　で、やり方としては、こんなふうにやりません？
１．「数十行の世間話」の中に、その問題に対する、一般的な論点と、予想される問題点が書かれているので、それを抜き出し、横に書く。
２．実際の自分のプロジェクトの行ったことを縦に書く
３．その交点が、（い）の解答になる。

答案の作り方は、こんなふうにやりません？
（Ａ）３．の交点が埋まる事項に関して、その縦の項目（つまり、自分の具体例を）わかるように、（あ）に８００字でまとめる。このとき、キーワードを見つけておいて、それを入れておくようにする（そのキーワードが（い）とつながる）
（Ｂ）（い）の部分で、まず、１。で抜き出した横の項目と、一般論としてはということで、予想される問題点を書く。そして、今回のプロジェクトでは、ということで、交点の内容を書く。このとき、（Ａ）のキーワードが入って、対応が付けられるように。。
（Ｃ）（う）は、自画自賛する。

ちなみに、わたしは、こんなかんじで、アプリケーションに、受かりました。

　で、問題は、１．の世間話から、どうやって、一般的な論点を抜き出すかっていうことなんですが、それは、ＴＡＣの午後２対策でも、見てください。

---

　つまり、情報処理試験の午後２って、仕様書からテスト項目とかを抜き出すやり方（じつは、それ以外のドキュメントから、他のドキュメントやプログラムを生成するのも、似たような操作なんだけどね）のテストをやってるだけの気もします。

　で、情報処理試験の場合は、横の項目が、問題用紙に入っている（その抜き出し方は、くどいけど、ＴＡＣのような受験学校で教えてくれる）、縦の項目は、自分のプロジェクトの作業内容（項目）ということになる。

　テスト仕様の場合には、それぞれの状況によって、縦と、横の項目が違い（上記のとおり）横の項目は、すでに、偉い人が決めてくれている（自分が偉い人の立場の場合、世間一般や経験から決める）、縦の項目は、指針はあるので、それを、自分のプロジェクトに当てはめて考える。

---

　と、思うんですけど、こういう説明をしてくれた人、見たことないんですけど。。
　そのわりに、試験受けろ！っていうのよね。。。

VC++で、「CStringを使ったとき、strcoreでメモリーリーク」のまとめ

ウィリアムのいたずらも、ハマったし、検索しても、いろいろでてきますね。

　　　　CStringを使ったとき、strcoreでmemory leaks

けっきょく、こんな感じのケースなんですけどね。。。

---

１．メソッド内で

　　CString buf = "";
　　for(int i = 0 ; i <10; i ++ ) 　　　　buf = buf + "a";
　　}

のように宣言したもので、ポインタでなく、newしたものでもない
　　（なので、deleteもできない。こういうのは、メソッド終了後、解放されるはず）

２．スレッド内で使っていても、強制終了されたものではない。
　　スレッドは、すでに終了しているのに、出る

３．文字列の連結や、format関数を使ったときに起こりやすい。
　　ただし、これだけのケースだけでは、ないようだ。。。
　　逆に、このとき、かならずなるわけでもない。
　　バージョンによっても(VC++ Ver6、VC++ .net）同じプログラムで、
　　出たり、出なかったりする


で、現象は、プログラム終了後、

　strcore.cpp(118) :
　で、メモリーリーク(memory leaks)がおきることがある
（かならずおきるわけではない）

---

原因：不明

回避策：
　CStringを使わない。charの配列で、文字列を表現し、連結するときは、メモリ領域を取り直して、コピーすると、メモリーリークにならない。

　うーん、これじゃあ、自動車事故を減らすには＝自動車に乗らないっていうのと、おなじだな（＞＿＜）！

　もっとも、中学校のとき、「忘れ物をなくすには？」というホームルームの話し合いで、「学校に荷物をすべて置いておく。わすれない！」と提案したことがある。

　「っていうことは、家で勉強しないツーことか？」とかいわれ、先生には、なぜか、反対され、その案は却下になったが、その日から、みんな学校に荷物を置くようになり、次の日から、忘れ物は激減した。。。

。。。って、関係ないか、この話(^^;)

仕様書から単体テスト以外のテスト項目を抽出する方法

　いままで、単体テストの抽出についてまとめたので、それ以外のテスト項目について。

まず、一般に、テストの目的は、２とおり考えられる

・品質の保証（向上）

・契約書・仕様書に書いてあることが実現されていることの証明

---

　上記の「品質の保証（向上）」の場合は、結合以上のテストの場合、シナリオに基づきテストするとか、一般的な、総合テストの話になってしまう。

　これは、市販のテストの本を見るなり、セミナーにでればいいだけだから、このブログでとりたてていうことの話ではないでしょう。

　そういう本を、読んでください。で終わる話。

---

　問題は、下のほうの

・契約書・仕様書に書いてあることが実現されていることの証明

これは、契約書や、それを展開している仕様書の書き方による。

　契約書が機能で定義されているもの、たとえば、

本契約は、甲の受注システムを開発することを目的とし。。。

　なんて、書かれてしまっている場合は、どうしょうもない。
　受注システムの「受注」とは、なんのことかの範囲規定がない。
　相手が、「こんなシステムではない」と言われれば、それにお付き合いするか、お金は切り取れないかのどちらかになってしまう。

　なので、もはや、テストの世界とは、関係ない（テストできない）。

　ちなみに、これを応用し、アジャイルとあわせると、ＳＥさん、プログラマーさんを、死ぬまで、こき使うことができる（それも、ものすごーい安い金額で）。

　その方法については、（やばいかなあ、言うの・・・）まあ、やばくなさそうなら、後日発表するとして、今日は、別の契約書の書き方を検討します。

---

　ふつう、上記の事態を避けるため（奴隷のようにこき使われないために）、契約書の文言は、以下のように、入出力とあわせて規定する（と思う）。

本システムは、受注システム、・・・より構成される
　受注システムは、受注情報、商品情報、。。。を入力とし、受注表、。。。を出力するシステムである。

　このように規定すると、出力データが出力できた時点で開発終了となり、それをテストすることになる。
　そして、この契約書（具体的には発注仕様書）は、コンテキストダイヤグラムをもとに作成すればよい。

　この場合のテストは、素直に、入力情報が記載されているもの（仕様書に、～を入力としとか、～を取得しとか書かれる）から、出力しなければいけないもの（仕様書に～を出力しとか、～を表示しとか書かれる）が、出力されているかどうかを確認すればよい。
　だから、仕様書から、入出力のキーワード（入力し、出力し、など）を拾って、その入出力を実現する機能をみつけて、その機能を、その入出力で、動作させることをテスト項目とすればよい。

　エビデンスは、その入出力した物自体（画面の場合、ハードコピー）や、ログとなる。

　なので、まさにこいつは、情報処理試験の午後２の論文感覚。。。

流通システム開発センターのページにある、ビジネスモデル、結構良く出来てて、参考になると思う

ものものさんの、「たまゆら雑記」のブログの、積読　「ビジネス・プロセス・モデル調査研究報告書」にでてくる、流通システム開発センターの、流通システム化に関する研究開発、いけてる！かもしんない。

　事業自体は、どーでもいいんだけど（いいんかい ^^;)

---

　そこの、(1) ビジネス・プロセス・モデルの策定 にある、「ビジネス・プロセス・モデル調査研究報告書」が、ざっと見た限りでは、よく出来ていると思う。

　参考になるのは、
　　１０、１１ページの図、概略としては、きれいだと思う。
　　１２ページからの表は、一般的なプロセス内容としては、こんなもんだと思うので、
　　　実際に、自分たちが行おうとしている開発は、ふつうとどこが違うのかを比較する
　　　たたき台として使えると思う。
　　２４ページの図（３－１０）、いいっすねえ。
　　　取引条件（特売とか）の説明、きれいかも。。
　　３０ページから６４ページまでの物流関係と支払い関係は、知識として、
　　　読んでおいてもらうと、共通の意識が持ちやすいと思う。
　　　必要なことがきれいにまとまっている。

---

　(2) ビジネス・モジュールの基本設計 にかんしては、ロジックを、追っかけてないので、正しいかどうかわかんかいけど、ちょっと見た範囲では、

「ビジネス・モジュール基本設計報告書」をダウンロードして、解凍すると現れる、

・2-1-0要件定義\2-1-1システムユースケース検討\ユースケース図及び業務フロー.pdf
　内容が細かいので、このままでは、使いずらいが、とても参考になると思う

・2-2-0外部仕様設計
ビジネスプロセスが、まず、全体をつかむのにわかりやすいと思う。
　そのほかについて、よく見てないけど、いいんでないかい！！

・2-3-0内部仕様設計
　一番使えるのは、データベース設計書.pdfのデータベース設計のER図と、テーブル仕様テーブル仕様は、ウィリアムのいたずらが最近のブログで書いてきた、Excelの仕様書に近い形式で書いてあるし、ここまで、はっきりと、テーブル設計してあれば、標準として、わかりやすいんでないかい！

　データディクショナリも、いいかんじでついてきてるし（？？）

---

　ということで、流通業をやっている人は、自分たちのシステムと、標準と、どこが違うかとか、通論を学ぶのには、いいドキュメントだと思います。

　たまには、流通システム開発センターもやるじゃん。バーコード以来のヒットっていう感じです。

　あ、でも、実際にやろうとしている、「流通SCM共通プラットフォーム」は、どーでもいいんだけどね（いいんかい！！）

月末、月初にデータ変えるのも、怖いよね＆納品時に話しかけるのは、やめましょう。

　いま、前のブログで書いた会社から抜け出てきて、他の会社にいるんだけど、

　結局、データを作り直すけど、もう、月末月初だから、月初を過ぎてから、作り直しデータに入れ替えるってことになったみたい。
　たしかに、月末、月初には、月次処理が走るから、そーいうタイミングにデータ入れ替えたくないよね。。。

　新しいデータに入れ替えて、バグがおきて、月次処理を走らせられない！なんてなったら、残業になっちゃったりするから、たしかに、ユーザーさんは、いやだよね。

　なっとく。

---

　で、その入力データを消しちゃった原因なんだけど、

　他の人に話しかけられ、そちらに気をとられ、ついうっかり、入力したデータに、もとの（入力前の）ファイルを、コピーしちゃって、（メッセージボックスがでて）はい！にしてしまったらしい。。

　うーん。

　納品時に話しかけるのは、やめましょう。

　（そーいう問題なのか？そういう問題かも？？）

Access（に限らんが）、自動的にバックアップ取っておいたほうがいいかもよ！

　いまね、ある会社さんにお邪魔してるんだけど、

　そこでね、ある人（その会社の社員の人）が、Accessで入力したデータを
　午後、納品しようとして。。。

　ぎゃー！まちがって、入力したデータのほうを、消しちゃったあ！

　午後納品なのに。。。(@_@!)

　っていう、状態みたいです。。。
　やばやばだよね。。。さあ、にげよーっと。

　Accessに限らんが、ある程度データを入力したら、バックアップを取ってくれるような仕組み（人的仕組みにしろ、自動化するにしろ）が、必要かもかも。。。

　みなさんは、注意しましょうね！
　（もちろん、ウィリアムのいたずらもだけど。。。）

プログラム設計書・仕様書から、単体テスト項目を浮き上がらせ、テスト仕様書を手作業で作成する方法

　今まで書いてきた、
仕様書から、テスト項目を浮き上がらせる（モデルと、コントロール編）と
仕様書から、テスト項目を浮き上がるためのExcelシートって、こんな感じ？
のまとめ＆これらの作業は手作業でもできるので、手作業でやる場合の方法を示します。
これによって、単体テストのやり方は、一応、いいんでないかい？

---

手作業で作成する場合の方法

１．テスト対象をモデル・ビュー・コントロールにわけます

　それぞれテスト方法が違うので、分けます。

　ビューとは、ユーザーへの入出力をするところをさしてます。
　コントロールとは、モデルの起動部分を指します
　モデルとは、処理を行っているところをさします。

　モデルの中で、資源の入出力を行っているところは、そこでも、資源の実際の入出力部分と、それらの呼び出し・セッション管理と分かれているかもしれません。そうした場合、実際の入出力部分をモデル、呼び出し・セッション管理部分をコントロールとします。
　つまり、このときは、業務モデルと、資源管理部分の２階層になっているということです。
　２階層以上になることもあります（例：Webサービスをよびだし、そのWebサービスがほかのWebサービスを呼ぶ）。
　何階層になっているかは、コントロールがいくつあるかで見分けます。

---

２．ビュー部分のテスト作成

・外部仕様書等から、画面（ウィンドウ）の項目を拾い出します。ふつう、一覧表になっています。

・その項目のタイプ（テキスト入力、ラジオボタン、チェックボックスなど）を判断します。

・あらかじめ、偉い人（プロジェクトマネージャーなど）が、前もって、どのタイプは、どのテスト（たとえば、テキスト入力は、字種チェック、限界値チェック、入力値の構文チェックなど）を行う可能性があるかのテスト候補を決めておき、

・仕様書をみて、どのテストを行うべきかを決めていきます。

---

３．コントロール部分のテスト作成

・プログラム設計書から、どの値のとき、どのモデルを動かすとか、エラーにするとかが書いてある部分を拾い出します。
　気の利いたSEなら、表にしてあります（単なる表か、決定表かは別として）

・その値を入力（引数なら、ドライバから入力、メソッドの返り値なら、スタブからの返り値とか、スローされたエラー）したとき、どのモデルが動く、エラーになる等をエラー項目として書く。エビデンスは、ログとなる

・それに基づき、ドライバ、スタブを書く。また、どのメソッド（モデル）を起動したかわかるように、テストしようとしているコントローラーからメソッド（モデル）を起動するところに、ログを入れる。

---

４．モデル部分のテスト方法
・プログラム設計書から、処理内容が書かれているところ（フリーフォーマットで書かれているところが多い）を見て、後述するプログラムのパターン単位になるように、拾い出します。

・あらかじめ、偉い人が、このプログラムパターンなら、このテストというふうに決めておきます。
　プログラムパターンっていうのは（デザインパターンとは違い）
　　　　前処理
　　　　値チェック
　　　　主処理：値設定・更新
　　　　主処理：ソート
　　　　　：
　　　　（中略）
　　　　　：
　　　　主処理：ＤＢ更新
　　　　後処理

　のように、処理内容部分を意味ある処理ごとに、まとめたものです。
　これは、意識的にSEさんが、仕様書を書かないと、できないです。
　このパターンごとに、テスト内容が違います。
　（どんなパターンと、どんなテスト項目が考えられるかは、今度、気が向いたら書きます）

・そのプログラムパターンに対し、偉い人が決めたテストができるか（というか、たいていできるはず）を判断し、テスト仕様書に書きます。
　たいてい、エビデンスは、ログです。
　プログラムには、あらかじめ、偉い人が定めたログの書き方（たとえば、ソート処理の場合、順番に、ソートキーを出力など）にしたがって、ログを入れます。

---

　したがって、この方法で抽出するには、SEさんと偉い人が、どういう処理機能を使い、その処理機能ごとに、プログラムをまとめ、その処理機能に対し、どういうテストをするから、機能を満たしているといえるということを、あらかじめ決めて、熟知させる必要があります。
　でも、そんなもん、熟知させるのは、難しい。そこで、パターンを作ってしまい、パターンに当てはまるようにすると、ある程度、この処理機能の型にはまるというようにします。
　なので、パターン（フレームワークの場合もあるけど）は、必要。

　モデルとコントロールに分かれていない場合、モデルに、「条件分岐」というプログラムパターンを入れておき、そこにコントロールに相当するところを押し込めばOK
　そうすれば、ユーザーインターフェースと、それ以外の部分というふうに分けてテストできる。

　ということで、あとは情報処理試験のテキストでも、なんでもいいんだけど、そんなのを参考に、偉い人が、この項目、このプログラムパターンには、このテストを行う可能性あり！ときめてしまえば、いいわけっす。

　ちなみに、これは、仕様書がある場合。
　仕様書がなく、さらにパターンもないと、プログラムを読んで、ここまでの品質保証ができるテストをするのは、難しい。
　（仕様書を作らない場合、プログラムパターンに当てはめないことが多い。なんとなく、処理をならべ、結果をだすというような。。その場合、どういうテストをやれば、品質保証できるのかがわからない。ログも、なんとなく入れていて、通過したエビデンスにしかならないことも！！）

---

　というのが、単体テストの場合でした。
　それ以外のテスト（結合テスト）については、また、仕様書のみる箇所と、テスト項目の作り方が違います。

　それは、別の機会に。
　

仕様書から、テスト項目を浮き上がらせる（モデルと、コントロール編）

　先ほど、 「仕様書から、テスト項目を浮き上がらせる」話のView編を書きました。

　今回は、コントローラーと、モデルは、このViewと、どう違うのか。
　コントローラーとモデルのテストに関しては、以前のブログ、 コントローラーとモデルのテスト方法って、多分、違うと思う に書き、一部、引数の値を変えただけのメソッド単位のテストでは、網羅しきれないときのスタブについてで修正しました。

　まとめると、こんなかんじ。

■■　コントローラー
チェック項目：引数や呼び出しメソッドの帰り値

チェック内容：その値の組み合わせで、呼び出しメソッド等が変わるので、それがただしく呼び出されているか

チェック方法：指定された値（または値の範囲）で、正しく呼び出されるか
　　　　　　　または、エラーになるか

■■　モデル
チェック項目：仕様書に書かれている手順（おおまかに）

チェック内容：ちゃんと、やってるか？

チェック方法：更新された値をログで出したり、通過しているかどうか確認する。

ちなみに、前回のビューも同じようにまとめると

■■　ビュー
チェック項目：各入出力項目

チェック内容：入力できるか、出力されているか、エラーになるか

チェック方法：境界値チェック、字種チェックなどなど

---

では、チェックシートについてです。
さっきのチェックシートは、結局

　　項目名　　　＝チェック項目
　　チェック方法＝各桁に並べたチェック

になります。種別は、そのチェック方法を限定するものです。
ということで、以下、見ていきます。

■■　コントローラーのチェックシート
　こんなかんじです。

　ここで、ステータス１、ステータス２、ステータス３となっているのは、「引数や呼び出しメソッドの帰り値」で、これは、気の利いたＳＥなら、プログラムの仕様書に表にしているので、それを貼りこむ（実際にはステータス１とかじゃなくって、引数名などになります）。

　ある引数の値だけを調べたい場合は、最後の行(A2以外空白）のように調べたいところ以外、空欄にします。

　で、横に、起動するメソッドを書いたり、値を返す場合は、その値を書いたり、エラーになる場合は、「エラー」と書いておきます。「通過」は、そこを通過したことをログでしらべるだけでＯＫのとき、「通過」のところに、「ログで確認」とか、書きます。


■■　モデルのチェックシート

こんなかんじです。

VIEWの「項目名」のところが、「調べる箇所」になっています。
　そこに、プログラム仕様書のフリーフォーマットの部分に書かれている手順の、おおまかな処理内容を書きます。

　そこの種別を書きます。どんな種別を想定するかは、マネージャーしだいになります。
　普通は、
　前処理
　値チェック
　主処理：値設定・更新
　主処理：ソート
　主処理：マージ
　主処理：マッチング・ＪＯＩＮ
　主処理：（このほか、あれば）
　主処理：ＤＢ更新
　主処理：通信
　主処理：ＤＢ，通信以外
　後処理
なんかかなあ。。。お好みっす。
で、その種別に応じて、エラーの項目も変わってくるということです。
（共通なのって、あまりないかも。結構散漫に広がってしまうかも）

---

　こんな、かんじで作ることを今、考えています。

　なお、この方法では、以下のことに注意です。

・この方法では、複数の項目が絡むもののチェックは、できません。
　→シートに、もう一ひねり必要。

・出力がテスト項目だけですが、実際のテストにおいては、テストの条件なども記入しなければならないし、小項目、中項目も必要だったりします。そもそも、テキストファイルでなく、Excelに出すのが、普通です。
　なので、これを利用する場合、個別のプロジェクトごとに対応しなければなりません。
　つーか、手作業でやってもいいんだけどね。

---

　というか、そもそも、こんなの、Excelのシートにしなくったって、手作業でやってもいいことですよね。

　つまり、手作業でも、上記の手順でやれば、仕様書からテスト項目が（まるで、情報処理試験午後２の小論文で、問題から、書かなきゃいけない内容を浮かび上がらせるときのように）、浮かび上がってくるっていうことです。

　なので、次回は、いままでのまとめとして、手作業でやる場合の、「仕様書からテスト項目を浮かび上がらせる方法」を体系化してみたいと思います。

仕様書から、テスト項目を浮き上がるためのExcelシートって、こんな感じ？

m_pixyさんのブログ「PM見習いの読書日記」のテスト仕様の作り方に出てくる、


仕様書に色つきペンで書き込みしていくとあら不思議、テスト項目が浮き上がる。みたいになるといいのかも。


　っていう箇所ですが、こういうものを言ってるんじゃあないでしょうか？というものを書きます。

　といっても、前のブログで、コントローラーとモデルのテストは違うと書きました。
　で、モデルと、コントローラーについてのテスト方法は書きました。
　だけど、ＭＶＣモデルでの、Viewのテストについては、書いていません。
　なので、今日は、まずＭＶＣモデルにおける、Viewのテスト方法で、説明します。

---

　外部設計書の、画面関連のものに、たいてい、画面表示項目の一覧と、その各項目の内容、制約（字種の制約や、範囲制約など）が書いてある部分が、あります。


（１）それを、「ウィリアムのいたずら開発中？」の以下のシートの、「項目名」のところに貼り込みます。


（２）そのあと、その項目の種別（テキストボックスとかリストとか）を選ぶと、


　あらかじめ、この種別なら、こういうチェックが必要という候補が登録してあるので
　（これは、プロジェクトごとに、プロジェクトの偉い人が登録する。
　　一般的なテスト要件などを参考にして）



（３）そのテストを作らなければいけない候補のところに、色がつきます。

（４）その候補のところ、チェックする必要があるかどうかを、仕様書で確認して、
　　　必要なら埋めます。

（５）正常値のときは、そのまま、
　　　異常値のとき（エラーとなることをチェックしたい場合）
　　　　　そのマスを選択して、
　　　　　「異常値に」にして、
　　　　　「項目種別設定」ボタンをクリックすると
　　　その部分の文字が赤くなって、異常値設定とわかります。

（６）ある項目値において、複数チェックをしたい場合、
　　　たとえば、クラスで、値チェックに、「ブロンズ、シルバー、ゴールド」
　　　になることを確認したいとき
　　　　　ブロンズ;シルバー;ゴールド
　　　というふうに;で区切って入れます。
　　　郵便番号、数字のときＯＫ、漢字のときエラーにしたいときは、
　　　郵便番号の行を、もう一つ増やし、
　　　　　現在の「郵便番号」の字種チェックに、「数字」
　　　　　増やした行の「郵便番号」の字種チェックに、「漢字」として、異常値設定
　　　します

（７）全部記入したら、「仕様書作成」ボタンをクリックすると。。。

（８）テキストファイルに以下のように、テスト内容が生成されます。
・郵便番号が数字のとき、正常にとおることを確認する
・郵便番号が漢字のとき、エラーになることを確認する
・クラスが、「ブロンズ」に設定できることを確認する
・クラスが、「シルバー」に設定できることを確認する
・クラスが、「ゴールド」に設定できることを確認する

---

このからくり

　まず、色が変わるのは、別のシートに下図のように、種別と、チェック候補となるものの設定（色づけ）がされているからです。

　種別が切り替わったとき、この表をみて、設定しています。


　次に、「仕様書作成」ボタンを押すと仕様書ができるからくり
　別のシートに、下図のように、チェック、種別、異常正常で、テスト文サンプルが、あらかじめ登録されています。


　ボタンが押されると、これをもとに、$で囲まれている、「項目名」や、「値」を、置き換えて、ファイル出力します。

---

　つまり、このシートは、

（あ）まず、プロジェクトの偉い人が、この種別（画面項目の種類）だったら、こういうテストが必要という候補を挙げておきます。

（い）そして、そのとき、どういうテスト文になるかも登録しておきます。

（う）一般ぴいぷるは、画面仕様の項目を貼りこみ、項目の種類を設定して、仕様書からエラーを抜き出します。

（え）かきだす

という風に使います。テストの作成支援です。

　実は、m_pixyさんが書く以前から、ウィリアムのいたずら、こいつを考えていて、現在、鋭意作成中？？です。
　できたら、公開しようかな。。と思ってます。

---

　ちなみに、上記は、Viewでの例でしたけど、コントロール、モデルでは、一部を変えると、似たように出来ます。それについては、長くなるので、次のブログで。

Excelの仕様書の決まっている部分と、フリーフォーマットの部分

前のブログで、Excelの仕様書は、入出力用、プログラム用、テスト用が多く作られると書いた。今回は、そこに書かれる内容を説明するわけだが、そのまえに一言。

　これは、あくまでも、そういうのをExcel書く場合、意味があるというだけで、べつにこれらのものを、Wordで書いてもいいし（事実、書いていることも多いと思う）、これ以外のドキュメントをExcelで書いてもよい（書いたほうが管理は便利）。

　実際は、プロジェクトマネージャーさんの好み。

　では、本題。

---

入出力用、プログラム用、テスト用でかく内容。

・入出力用のドキュメントで書く内容
　これは、逆算して求められる。
　このドキュメントから、テーブル入出力インターフェースと、ＤＤＬが作成される。
　ということは、そこに書かれる情報は、仕様書のどこかに書かないといけないということ。あとは、テーブル入出力インターフェースと、ＤＤＬを自分で分析して考えてくれ。それがＳＥの仕事なのだから。。。

　テーブル入出力インターフェースのプログラムは、プロジェクトごとに違う。ということは、この仕様書の項目も、違うことになる。
　このドキュメントは、備考は自由にかけるが、フリーフォーマット部分は、ないことが多いと思う

・プログラムのドキュメントで書く内容
　本来は、以下の３つの部分に分かれる
　　（１）JavaDocで書くような、メソッド、クラスの情報
　　（２）このクラスまたはメソッドが扱う入出力データ
　　（３）実際のメソッドの内容（手順）

　本来は、（２）の書かれた入出力と、外部設計書の間に矛盾がないか（新しいデータ、テーブルなんかをつくっちゃってないか、外部定義書に書かれているデータを入力し、規定のデータを返しているか、意味を取り違えていないか）を確認し、（２）で示されたデータを使って、（３）が、処理加工されているかどうかを確認できるようにしておく。

　しかし、前のブログでかいたように、オブジェクト指向がはやっている最近は、（２）を書かない。なので、定型部分は、（１）の部分の内容（ＪａｖａＤｏｃに書いているようなこと）、フリーフォーマット部分に、（３）の内容を書く。
　なお、フリーフォーマット部分に、サンプルデータも書くこともある。

　ちなみに、（３）の内容中、プログラムの説明部分が、構造化分析における、ミニスペックに当たる。

・テストで書く内容
１テスト１レコードの部分は、定型フォーマット。それに付け足すサンプルデータなどが、付録として、フリーフォーマット部分に書く

---

って、こんなところかな。。

開発の仕様書全体における、Excelの仕様書の位置づけとその理由、オブジェクト指向との関係など

　いままで、「Excelの仕様書」とか、「フリーフォーマット部分」とか、書いてきましたが、これ、「Excelの仕様書」を見たことない人、さっぱり意味通じませんよね！

　ということで、今日は、「Excelの仕様書」というのは、どういうことが書かれているか、その種類と、平均的な内容についてと、オブジェクト指向で作成するドキュメントと、どこがどうちがい、なぜ、違うのかを書きます。

---

まず、仕様書って呼ばれるものは、こんなかんじかな？
（ＳＡ，ＵＩなどは、意味が通じない人は無視してください。一部の人たちがいう、呼び方です）

１．発注仕様書
　契約書についている場合がおおい。
　プロジェクト憲章になる場合もあるが、ふつうＳＥさんが書くものではない
（といいつつ、ウィリアムのいたずらは、何回か書いた＝客が書くより、仕事を請けるほうが書く場合が多い）

２．要件定義書
　要求仕様書になっている場合もあるし、暴言すると、概要設計書も、似たようなもんだ。ＳＡのドキュメントは、ここに入る

３．外部設計書
　システム外部の見た目を書くことが多い（かならずしも、そういいきれない場合もある）。ＵＩドキュメントは、ここに入ると思う。
　テーブル構造など、入出力のドキュメントは、ここに入れるべきか、詳細に入れるべきか。。

４．内部（詳細）設計書
　システム内部のプログラムについてのドキュメント、こんなもんかなあ。
　・プログラムに関するドキュメントと、
　・メソッド間で渡されるクラス（ようするに、バリューオブジェクト）の定義
　・システム共通定数
　・システムメッセージ定義（エラーメッセージとかの定義）
　ＰＧのときのドキュメント。
　自動生成するために作成するドキュメントは、ここに入ってくるね。たいてい。

５．テストドキュメント
　ＰＴ，ＩＴ用ドキュメントなど。
　最近は、２種類のものがある
　・１テスト、１レコードとして、表形式で書く。
　　データや手順に関しての詳細を別紙として添えるこの別紙がフリーフォーマット）
　・１テスト、１枚（または１シート）として書く
　　この紙の中に、そのテスト分の、テスト方法などをかく
　もちろん、この２つをあわせて、１テスト１レコードのものを、一覧としているものもある。

ちなみに、ドキュメントとしては、あと、進捗関連、バグ関連、フレームワークなどの説明、開発用インストール関連、などなどあり、進捗関連、バグ関連が定型フォーマット。

---

　で、上記のドキュメントを書く本来の目的は、発注仕様書に書かれた成果物（出力）が、各処理において論理的に矛盾なく、出力されているかどうか、要件をうけて、外部仕様、それを受けて内部仕様という仕様の一貫性が保たれているかを確認すること。

　そのためには、処理と、データ入出力が、ドキュメントのフォーマットの中で、定型化されていないといけない。

　しかし、オブジェクト指向で行った場合、開発初期の段階でユースケースを作り、そこからクラス→プログラムに展開してしまう。
　このユースケース内には、ＤＦＤと違い、データの詳細とその流れを記載しない。

　したがって、オブジェクト指向で考えていった場合、この定型フォーマットは使いにくい。そこで、現在、定型フォーマットの中から、入出力記述を抜いてしまっているものもある（それでいいのか。。いいわけない。ドキュメント作っている意味がない）。

　オブジェクト指向の人から見ると、したがって、（データの裏をとるために仕様書を作っているのに、その部分がないんだから）仕様書って、意味ないじゃん！っていうことになる。。。

---

　ということで、仕様書全体は、以上のとおり。そのうち、現在、Excelでの定型フォーマットの多くは、以下の部分に使われることが多いと思う。（ほかのドキュメントはWordや、お絵かきソフトが多い）。

・（「３．外部設計書」であげた）入出力関連
　・画面／ウィンドウのようすを書いたもの(Wordのこともある）
　・テーブル定義書（ＥＲ図の場合は、WordやVisioのほうが、書きやすい）
　・ファイルフォーマット定義（最近、フリーフォーマットなんで、作らないかな？）
　・通信関係のデータグラム（っていったっけ？レコードに相当するやつ）の定義
　　→ソケット間通信などがあれば
　などなど

・（「４．内部（詳細）設計書」であげた）プログラム関係
　・クラス内の変数、メソッドの引数・帰り値と処理内容などをかいたもの
　・引数中、バリューオブジェクトの定義
　・システム共通定数
　・システムメッセージ定義（エラーメッセージとかの定義）

・（「５．テストドキュメント」で書いた）テスト関連
　・テスト仕様

---

　これらのドキュメントが、なぜ、(Wordでなく）Excelで書かれるのかについて。

・入出力関連の場合
　入出力インターフェースと、ＤＢスキーマの矛盾をなくすため、ＤＢ追加・変更に関しては、ＤＢ管理者が、入出力操作クラス（メソッド）、ＤＢ用ＤＤＬを自動生成し、そのうち、プログラム部分を構成管理担当者に渡すというしくみに（おおきなシステムだと）する。その自動生成が、しやすく、構成管理の人やＤＢ担当者、開発者が、「紙に出して」みやすいのがExcelだということ。

　紙でないと、これらのドキュメントを１０個くらいならべて、比較するときめんどう（うーん、１メートルくらいの見やすい画面のディスプレイが出来れば、紙がいらないんだけどね。。）

・プログラム仕様書
　プログラムを作成する前に、インターフェースの打ち合わせをする。
　その打ち合わせ資料として使うのにExcelだと、見やすいというのがあるが、最近はスタブをあらかじめ作成し、JavaDocで済ますということも多くなってきた。

　→つまり、この場合、スタブを作成する必要がある！

　スタブがないと、この場合、JavaDocが作れず、インターフェースの打ち合わせが出来ない。スタブも作成しないで、ドキュメントも作らず、インターフェースをあわせようというのは、無理。

　ただ、JavaDocの方法でかかれると、テストの自動生成に、データを持ってくることが出来ないので、リスクは、大きくなる。

・テスト仕様書
　１テスト１レコードの場合、Excelが書きやすいからだと思う。
　たしかに、テスト仕様書を自動生成することもあるが、そのためにExcelというわけではない気がする。ひょっとすると、成り行きかも？？

---

　ごめんなさい。思ったより長くなるんで、この記事は、ここまでにして、続きを次の記事に書きます。

設計がまとまらない、障害が出るのは、Excelの仕様書への落とし方、ＰＧとの対応がわからないから？

m_pixyさんのブログ、「PM見習いの読書日記」の、「その作業にかかる時間」
を読んでいて思ったこと。
揚げ足取り的なツッコミなのですが。。。

（あ）「その仕様書を作るのには１ＫＳあたり○○時間でやれますか？」と聞いてしまう理由と、
（い）設計段階での工数がひとつ前のプロジェクトの２，３倍かかってる理由と、
（う）その前のプロジェクトで設計工程起因のバグを出しまくってお客さんに迷惑かけて

いる理由って、普通、おなじと思っちゃうんですけど。。

あ、ついでにいうと、

（え）EclipseやIDEAでコード書くような感覚で仕様書を書けるツールない理由も
（お）ExcelやWordに書いてあるだけの仕様書より、ExcelやWordに書いてあるだけの仕様書より，ソースコードのほうが，はるかに有益の情報を知る事が出来る人がいるのに、ExcelやWordで仕様書を書く理由も、

全部、おなじことだと思ってるんですけど。。。(@_@!)

---

　はじめの件。
　要するに、「設計工程起因のバグ」が出る理由は、たいていこんなかんじじゃない？？

（１）ヒアリングを体系的にやってない
　→これは、論外。ふつう、やってるよね。
　　まさか、客先にいって、「さあ、どういう風にシステム作りましょう？
　　って、営業みたいに単純に聞く人はいないよね。
　　この辺の、意識あわせ。。する？しなくていいよね！

（２）ヒアリングから資源関連への落とし込みが出来る、体系的テクニックを持っていない
　→こいつも、論外。普通、（本に書いてあるのは、いい加減だけど）
　　佐藤正美さんのセミナーなんかでは、教えてくれるから、
　　（さらに実際には、アレンジしないといけないけど）
　　まあ、できてるよね。これも、いいよねえ。
　　
（３）客が言っていることを、真に受けている。客が、うそを言いうる
　　（っていうか、たいていうそだ）ことをわかっていない。
　→こいつも、いいよねえ。。説明いらないよねえ。。
　　客がヒアリングでいうことは、たいてい、いい加減だ。
　　つーか、人間って、たいていいいかげんだ。

（４）客がうそを言っている場合、その矛盾を見抜くテクニックがない。。。
　　→こういうやつは、救えない。一生、客に踊らされる。
　　　仕事を変えるか、テクニック身に付けないと、どんなに働いても、
　　　たぶん、仕事が出来ずにつぶされる。

（５）客が言っている正しいラインから、資源への結びつきをつける、業務パターンを構築する能力が「ない」人が、ＳＥになっている。
　　→ＳＥかえたほうがいい。じゃないと、システムできない。

（６）その業務パターンから、仕様書のフリーフォーマット欄に書くパターンと、プログラム・テストが、自分の頭の仲で結びついていない。
　　→つーか、あのExcelのフリーフォーマット欄を、本気で、フリーフォーマットに
　　　使うやつがいるのよ！！

　　　　お、おい！それで、理解できるわけないだろう。。。

---

　で、たいてい、設計でミスるのは、（４）、（５）、（６）の能力に欠ける場合だと思う。客に言われたことを、なにもかんがえずに、システムにしようとしたり、仕様書に落としてしまう場合。

　仕様書には、明確な書き方があって、それは、ソースコードとだいたい結びついている。だから、「仕様書のフリーフォーマットに書くパターンなになにのばあい、プログラム１ＫＳあたり、どれだけ」というのは、いえる。

　ところが、この仕様書への落とし込み方がわからないと、客が言ったことに振り回される。
　客は思いつきでいうから、話がぶれる。アジャイルで開発するとき、この客の話の「ブレ」を見抜かないと、客に振り回される（っていうことは、アジャイルの本に書いてない気がする。。つまり、客のうそや、夢、本心でないところの見分け方、おばかな客のあしらい方など。。。あんまり、本に書いてないよね。。）

　で、振り回されると、設計段階での工数が、普通より、何倍もかかる。

---

　つまり、設計起因のバグが多いのとか、逆に、工数が伸びるのって、
　　・ヒアリングから、客のうそをみぬき、
　　・本筋のラインから、ビジネスのパターンに落とし込んで、
　　・必要な仕様書に展開し、
　　・その仕様書から、ソース、テストを作っていく
流れが、わかってない場合が、結構あるとおもう。

　で、これがわかっている人が、「短期納品、大量生産」できるんだけど、これを出来る能力がない人が、みようみまねでやると、「１ＫＳあたり○○時間」っていう質問になるのよ。。。
　ということで、（あ）から（う）が、上記の理由だということは説明した。
　

---

　のこり、（お）について。
　プロジェクトによって、プログラムの書き方が違います（フレームワークを作る、共通部分の開発の人の好みとか。。）。

　でも、Excelの仕様書は、それらの違いがあっても、だいたい、おなじになるから。
　Excel仕様書のフリーフォーマット欄の書き方は、大体同じに出来て、そこから、各プロジェクトごとの書き方にあったプログラムに自動生成できる。

　それに、そもそもプロジェクトが大きくなってしまいと、Javaでやるとは限らないし(今日はウィリアムのいたずら、VC++の日だし）。。。

　つまり、（え）の、そういうツールがないのは、上記の「ビジネスのパターンに落とし込んで、必要な仕様書に展開し、その仕様書から、ソース、テストを作っていく」流れがわかる人にとっては、仕様書で書いても、プログラムで書いても同じなのよ。
　なので、自動生成しやすいExcelで書いて、パターン変更があったとき、その自動生成プログラムを修正するという手を使うためだと思う。

---

　つまり、問題は、「ビジネスのパターンに落とし込んで、必要な仕様書に展開し、その仕様書から、ソース、テストを作っていく」流れっていうのがある。

　そんな、仕様書のフリーフォーマット欄の使い方とプログラムの手抜きの実態とかを、書こうと思ってるんだけど。。。最近、ウィリアムのいたずら、個人的に忙しいのよ。
　それに、今日はＶＣ＋＋の日だし（明日もかなあ。。）
　別にＶＣ＋＋で説明してもいいんだけど。。きっと、見てる人って、Javaだよなあ。。

　つーことで、この「仕様書のフリーフォーマット欄の使い方とプログラムの対応」は、後日になるのであった（つーか、そもそも、そんなこと書いていいのかなあ。。あれって、どっこの本にも書いてないってことは、世間では、企業機密なの？？）。

　さ、ブログなんか書いてないで、おしごとおしごと。
　

VC++の不可解なメモリーリーク？？

今日は、ＶＣ＋＋の話です
（Javaじゃないっす。Javaにメモリーリークって、聞いたことないっす）

Detected memory leaks!ってでてきたんだけど。。。

調べてみたら、

	CTime theTime = CTime::GetCurrentTime();
	CString buf = theTime.Format("%Y/%m/%d %H:%M:%S");
	fprintf(fp,"時間 %s",buf);

こいつがメモリーリークに「なるときと、ならないときがある」。。。
でも、bufを使わないで、

	CTime theTime = CTime::GetCurrentTime();
	fprintf(fp,"時間 %s",theTime.Format("%Y/%m/%d %H:%M:%S"));

と書くと、メモリーリークにならない。

なんでだ？？
（ちなみに、なるときは、マルチスレッドの生成されたスレッド内）

---

次。
ソケットを使って、マルチスレッドでやってるんだけど、
こんなかんじのを、かいてます。

CString rec = "";
char buf[2];
memset(buf,0,2)			//	NULLをいれている
ret = recv(Sock,buf,1,0);

while(ret > 0 )
{
	rec += buf;	

//	ここにいろんな処理。
//	場合によって、rec=""にしている
//	処理は、省略

			//	次の読み込み

	memset(buf,0,2)			//	NULLをいれている
	ret = recv(Sock,buf,1,0);

}

//	以下省略

これも、メモリーリークになる。

ループを抜けたところで
rec = "";
と入れるとＯＫ。

---

なんか、よくわかんないけど、メモリーリークが消えたから、まあいいや。
いいのか本当に。。。
こんなのに、２日、なやんだ。
（なやんでるわりには、昨日も、ブログかいてたりする）

プリウス、アメリカでも問題になってるみたいだけど。。。

　ものものさんのブログの記事「走行中にPriusが停止する問題、原因はソフトに」の話って、ウィリアムのいたずらが、５月６日のブログに紹介した、「SoftEther VPN 日記」のトヨタはユーザーをハイブリッドシステムの実験台にしているのか？と同件なのかなあ？

　まあ、同件にしろ、違うにしろ。。。結構、いろいろありそうですね。プリウス

　（って、そもそも、ウィリアムのいたずらは、運転免許もってないから、関係ないんだけどね）