設計・実装（コーディング）・テスト
昨日の続き。言及リンクを手繰っていてなんだか色々な話が出てきているので、少し私も混乱しているけど、書けるところから書いてみようと思う。
「それ、どうやってテストするの？」 - サンフランシスコ出羽守手記(masayangの日記
はてなのブログでは「オブジェクト指向とはなんぞや」「どうやったらオブジェクト指向を習得できるのか」という議論が盛んだけど、自分は「それ、どうやってテストするの？」という視点で考えるようにしている。ここでいうテストとはテストコードで機械的に片付けるテストのことね。手動で操作して「動きました」というのは論外。
このエントリに対して言及しているエントリが下。
テスト，カナダの住宅事情，コードなにがし - カレーなる辛口Javaな転職日記
ほとんどのまともなプログラマーなら，無意識のうちにそういうテスト可能／デバッグ可能なコードを書くことを心がけている．テスト／デバッグ不可能なコードを書く人というのは，まともなプログラマとは思えない．
ここまではプログラマが作成したコードを単体（ユニット）テストを意識してコードを組み立てているか？という話で、まあ、至極マットウな論だと思う。
で、このエントリに対する言及で、ちょっと疑問符がでてくる。
「それ、どうやってテストするの？」（続） - サンフランシスコ出羽守手記(masayangの日記
設計担当はコードを書くことはない。書くのは設計書なる文書だけ。「その設計書、どうやってテストするの？」と聞いてみるがよい。答えに窮するか、「作ったものをテストする」と答えるかのどちらかのはずだ。
設計書は動作しないから、設計書をもとに開発したコードをテストするしかない。
でも、「設計書」を書く人はコードの細かいところまでは考えていないから[*1]、細かいところのテストは開発者に任されることになる。
ここの部分はあまりにも自明すぎて何もいえないんだけども、「そうじゃない何か」があるんだろうか？ きっと肝になるのは「細かいところ」なんだけど、これをもっと突き詰めて考える必要があると思う。
設計書とプログラムは、合目的性という点で等価でなければダメなわけだけど、設計書の記述がそのままプログラムと等価ということではない。最上流のコンサル・要件定義から延々と下流に向かって流れてくる工程のすべてにおいて合目的性が確認されなければならないけど、それぞれの工程での抽象度は異なる。どんどん具体化されていって、最後はアルゴリズムというレベルにまで来るわけだ。「細かいところ」を分離するなら、こうじゃないだろうか？
- 実装技術、言語表現、アルゴリズム等、プログラムの内的な要素
- 業務要件、入出力仕様、チェック仕様等、プログラムの外的な要素
内的な要素については、外的な要素が満足されていてなおかつ、上流の設計書に特別な指示がない限り、プログラマの裁量に任せられると思う。そここそがプログラマの仕事で、仕様化することの難しい効率性や応答性といった品質要件をクリアしていく為にテクニックを駆使していくところだと思う（RDBの表の構造とかはもう一個上ぐらいできめちゃうけど）。
でも、外的な要素。業務要件に直結するような内容だけど「細かいところ」は、自分で決めちゃいけないんだ。そこが「これは設計者に確認しないといけない事なのか、自分の裁量で決めていいのか。」という判定を下す能力が問われているんだと思う。たとえば為替レートをもらってきて、円−ドルレートとドル−南アランドレートを元に円−南アランドレートを出すって機能があったとして、小数点以下の始末の仕方が明記されていなかったとしたら、それは設計者を問いたださないといけない。小数点以下何位で丸めるか、丸めの方法は切り捨てか四捨五入か、あと最近だとIEEE 754 Unbiased丸めとかもある。ここが決まっていないのは設計者の罪ではあるけど、これを適当に実装しちゃうプログラマもどうかしていると思う。そして、困ったプログラマに至っては割り算をまっさきにやって精度を何桁かドブに捨てちゃったりする（そーゆー人いました）。
という事を踏まえて続きを読んでみる。
* 設計者が考慮していない「細かいところ」のテストは「何を持ってテスト成功」とするのか。
* それを開発者が勝手に決めちゃっていいのか？
* 開発者が決めたテストの妥当性について誰が検証責任を持つのか？
* テスト結果が設計者の意図するものと異なる場合は開発者の責任なのか？ 設計者の責任なのか？
A1-1)内的な要素なら、ホワイトボックスでOKにすればいい（要は自分が決めた内部仕様通り*1プログラム内部の挙動を確認すればいい）
A1-2,A2)外的な要素なら、設計者を問い詰める
A3)テスト結果をレビューする人が検証責任を負う。通常品質管理責任者が誰かいるはず。レビューを求めなかった場合は開発者がレビューを要求しなかったという事で、責められる可能性がある。「開発者側からレビューの要請をしたが、受け入れてもらえなかった（レビューがなかった）」という事をメールでも紙でもいいので残すべき。
A4)「設計者の意図」＝「設計書」と捉えるなら、それは開発者の責任。設計書に明記されていない何かを検収で求められたら、開発担当者に責任はない。「打ち合わせの時言ったはず！」とかになったら、まあ後は大人の交渉で決まる。
といったあたりでしょう、普通に考えると。
などなどをまじめに考えると疲れちゃうから、常識的には開発者は設計者が提示した範囲の仕事しかしなくなる。
古き良き時代の浪花節的日本のゼネコン構造では、設計業者と開発業者の間に「阿吽の呼吸」があった[*2]からうまく回ったこともあったけど、今の世代ではあまり期待できない。ドライなオフショア業者は「言われたことしかやらない」の典型であろう。
ここの記述に私が「なんだか分からないなあ」と感じちゃったエントリが出来上がった背景があると思う。ひとつに*2それは設計者と開発者の気持ちの乖離というか、ディスコミュニケーションというか、すごく溝があるのがいかんなあと。仕事をしている時、よく考えていた事に「その成果物に愛はあるのか？」という事がある。例えば、論理設計書は上流の要件定義で言わんとするところを１００％汲み取り、なおかつ、次の工程の担当者にわかりやすく、意図が十分に伝わるように文章表現、図形、表とあらゆるテクニックを駆使して書くラブレターなんだ。「この表現でわかりますか？」、「ここは誤解してませんよね？」、「このシステムのゴールはここですよ」伝えたい事は山ほどある。物理設計書ではプログラム仕様を書く人に宛てたラブレターになるし、プログラム仕様はコーディングする人と、今後プログラムの保守を行う人に宛てたものになる。プログラムだって立派な言語表現なんだから、読みやすく、誤解の余地なく書くべきだ。そーゆーわかりやすさ、伝えたい気持ちを持って成果物を作って、次の工程に引き継いでいく。「愛」がイヤなら「思いやり」でもいい。「阿吽の呼吸」という表現がきっと近い部分なんだろうけど、「そんなの今じゃ期待できないね！」って切って捨てられてしまっているのが悲しい。それに続く部分にも書いてあるけど、オフショアしている所は設計者−担当者間のコミュニケーション不全が、困った状況を作り出している典型なのかもね。みんなさー、もっと楽しく仕事しよーぜーｗ
と、微妙なお年頃のエンジニアは思いましたよ。
