読書の楽しみと達成
こんにちは、readline.fmです。readline.fmは、つんどくが趣味の2人が、何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、ハッシュ・リードライン・FMです。Mixi2にも、readline.fmのコミュニティがありますので、感想やワイワイお待ちしております。
コスト役は、ゲイエーさんと金城です。それではゲイエーさん、よろしくお願いします。
よろしくお願いします。
はい、今日もワインバーグですね。
そうですね、今日も今日とて。
何冊目ですか?
もう何冊目なんですかね。
1、2、3、4、5、6、7、8、9、10、11、12冊目。
そんなに読んでんの?我々。
サーブ、システム、ソフトウェア文化を送るシリーズで4冊、IOTシアルの探検学で5冊目、コンサルタントの秘密6、スーパーエンジニアへの道7、プログラミングの心理学8、
間にあれか、チームの力で組織を動かす挟んで、何を数えてたの、今忘れた。
コンサルタントの道具箱とシステム作りの人間学と、今回ですね、11冊目。
11冊目、すごいね。なんかもう全然半分折り返してましたね、気づいたら。
『パーフェクトソフトウェア』の概要
すごいですね。デマルコを読んだ時にもうこれ以上シリーズというか、横展開しながら読むことないかもなって思ったんですけど、その1.5倍ぐらい読んでますね。
いやー、なんかあっという間に制覇できてしまいそうな気がしますね。
いや、でもこの先がきつい気がするな。
そうですよね。なんか、進んで読みたいかって言われるとみたいな感じがあったりするものもありますからね、一応。
あー、なるほど。
ライトついてますかとか取り上げなくてもみんな読んでるよねみたいなとこありますよね、若干。
確かに。わかった、ピープルウェア読んだのにライトついてますか読まないんだなって言って。
そうそうそう。
いや、今あえて読んでみて、アハハワインバーグだねっていう話をできる気がする。
確かに。
僕はあと文章6本とシステム一般試行入門は読んだんで。
じゃあほぼもう制覇してると言っても過言ではないって感じですね。
あとは、技術レビューハンドブックだけ持ってないですね。
そうそう、それだけ拾い忘れてるんだよな。
あれは読まない気がするけど、余裕があれば、ということで。
今日は何でしょう。
今日は、パーフェクトソフトウェア、テストにまつわる幻想を読んできたので、2人で感想を喋っていこうと思います。
あれですね、日経BPのかわいらしい表紙のやつですね。
いつもの日経BPのトムネマルコのシリーズだったり、ワインバーグだったり、みんな同じテストのやつがおなじみのやつって感じの表紙のやつですね。
で、翻訳者が伊豆原由美さんで、我々のボットテストの半分ぐらいをこの人が支えてる気がするな。
そうですね、この方のおかげで日本語で読めているっていうのはめちゃくちゃありますね。
えーとね、熊戸ワルツオとかゆとりの法則、デッドライン、コンサルタントの道具ばかり、アドレナリンジャンキーがこのボットテストで取り上げた本でいうと、伊豆原さん役。
いやー、かなり助けられてますね。
だから、日経BP的なやつ、この人だなーっていう気がするし、読みやすいな、読みやすいですね、この方。
そうですね、めちゃくちゃ読みやすかったですね。
自然な日本語になるって言うと、どういうことって思われるかもしれないですけど、スッと入ってきやすいですね。
わかんない、新しいからかもしれないけど。
新しいからっていうのも多分一個あるような気がしますけどね。
では、安定した役届けてくれる方。
で、パーフェクトソフトウェアなので、多分一番新しい本ですね、ワインバーグの中で。
そうですね、ワインバーグの中では一番新しい本で、出て発売が、原著が2008年で、出版が2010年になってますね。
厳密にプログラミング心理学25周年記念版ってやつが2011年なので、そっちの新しいと言えば新しいけども、あの本って、個誌というか、おもとはもともと1971年に出ている本なので、そこは飛ばしちゃっていいんじゃないかという気はしますけど。
そうですよね、内容的にも昔のだねっていう感じがしたからな。
で、ワインバーグの本の中ではもう、現代のプログラミングにだいぶ近づいているという感じの本ですね。
そうですね、英語を翻訳されていない本で言うと、この後にも何冊か出ていそうな雰囲気がしますが、レッシュマンマーダーズっていう本があるな、めっちゃ物騒。
物騒ですね。
なんかハンター×ハンターのトンパンみたいな感じなんですかね。ルキーキラーとして。
じゃあ今回の本は軽くどんな本か。ちょっと出版社のサイトに概要があったんで、ちょっとそれを引用して読もうと思いますが、
ワインバーグはテストとは製品の品質についての情報を収集し提供することであると説く。
テストの結果はいく通りもの解釈が可能であり、とがく人は置かれた立場によって自分の都合のいいように考えてしまいがちである。
そうした人間の甘さに釘を刺しながらも、テストの難しさを自らが一番よく知るワインバーグのエンジニアへの愛情が感じられる一冊というふうに書いてありますね。
なるほど。釘刺してましたね、確かに。
そうですね。
釘を刺す本だったな。
なので、Perfect Softwareっていうタイトルは完璧なソフトウェアっていうところは不具合もなくて、顧客の要求も満たして完璧なソフトウェアってことは実現可能かっていうところから、
いやそんな簡単でもないし、それはとてもとても難しいんだよっていうような、みんながこの製品は完璧ですって言うけど、いやそんなことはないんだよっていうようなことを
言いたいがために書いた本なので、結構テストの話がメインでしたね、今回は。
うん、だからタイトルがちょっと皮肉っぽいっちゃ皮肉っぽいですよね。
てかサブタイがテストにまつわる幻想って書いてあるんで。
そうそうそう。
テストの理解とアプローチ
うんうん、Perfect Software and Other Illusions About Testingっていうのがオリジナルのタイトルとサブタイトル、イリュージョンですね。
ただ放題側もそうままですよね、訳が。
そうですね、なんで全てテストしないんですかとか、え、全てテストするってことは、ザ完璧な用途っていうものがどっかにあるんですかみたいな話とかをしていくと。
まあそもそも人間は完璧ではないっていう話をあったりとかして、いやーすごい面白かったですね。
そして読みやすかったですね、今回。
うん、めちゃくちゃ読みやすかった。
スルスルっと読みましたね。
うん、なんかスルスルっと読んじゃったから、結構なんか大事なこと見落としてんじゃねえかなっていう気もするし、このスルスルっと読めたのは時代が近いからとか、
あとまあやっぱそうだよねって結構同意するところが多かったりとかしたから、あんまり新しい発見がなかったのかなっていうのもちょっと自分は思ったりしちゃいましたね。
うん、似たような感想ですね。やっぱりワインバーグの方を立て続けに読んで終えるので、何て言うんだろう、言ってることわかるなーっていうところが多くて、
で、言ってることわかるなーっていうことは、まあどっかしらで同じようなこととか似たようなことを言ってるっていうことでもあるので、なんかね、知ってるなって思うところを読み捨てがちじゃないですか。
ゆっくり読むとか、ここは何だろうなーっていうのをすごい熟読したり掘り下げながら咀嚼しながら読むっていうよりかは、
あ、これは自分の脳みその引き出しに入ってるなーって思ってパパパッと、もっともっと新しい面白い話くれって言いながら読んじゃうので、やってたら気づいたら、あれ、すげえ、もう後半じゃんっていう感じでしたね。
そうそうそう、ほんとそう、ほんとそうなんですよ。
そうだから間違いなくいい本というか、読んでて考えさせられる本。なんか思考に深みを増させるような本だったなーと思いつつ。
うん。
で、そうボリュームもね、そこまで、何ページ?200ページちょいなんで。
うん。
分厚い本ではないですね。
そうですね。もう今までさんざんね、300ページ400ページ500ページとかの本読んできたから、むしろ薄いじゃんみたいな気持ちになるぐらいだったんで。
で、しかも読みやすいだから、結構あっという間に読み終わっちゃうって感じでしたね。
しかも参考文献が1.2ページぐらいしかないんですよ。
そうそうそう。
下手したら10ページぐらいあるやつもあるのに。あれは参考文献というか、読書ガイドとして載せてるからか。
うん。まあそういう部分もあったけど、この本だとこっちも読むといいよみたいなのは確かに何冊か上がってはいたんですけど、そんなたくさんはやっぱなかったので、参考文献もそこまで厚くないって感じでしたね。
うん。で、そうですね。まあとはいえ、テスト技法とかメソッドロジーとか論議的な話っていうよりかは、半分エッセイみたいなところですかね。
そうですね。なんか自分もこれを読んで、テストが上手にできるようになるかって言われたら、そうじゃないよなみたいな。
多分この本でテスト技法とか、テストの上手にやる方法とか、どうやって品質を保証していくのかっていうようなことを教えてくれる本ではないなと思ってて、
それはまた別途専門の本があるんで、そっちを読んでねっていうことで。
プログラミングの心理学と同じようなアプローチで、テストする人とかテストについて考えてる人とか、テストすれば品質が保証されていいものが出来上がるんだっていう、
そういう万能なものであるっていうふうに考えてる人に対して、要は人間に対してフォーカスしてテストっていうもののできることできないこととか、間違った期待値を持ってる人たちに対してどういうふうにアプローチすればいいのかとかっていうことを教えてくれる本だなっていうふうに思ったりもしましたね。
なんかね、なんちゃらなんちゃら手法とかっていうよりかマインドの話だなみたいな感じですね。で、前書き見てみると確かにプログラミングの心理学をプログラミングを理解したい人、必ずしもプログラマーに閉じない表現をしてると思うんですけど、
プログラミングを理解したいと考える人々のためにあの本を書いて、今度はテストに関しても同様にテストを理解したいと考える人々の役に立つためにこの本を書いたよっていうふうに書いてあるんで、ゲインさんが言ってたようなプログラミングの心理学のテスト版っていう感じもしますね。
だから逆に言うと、あのぐらい技法を技法をした話、ハードスキルっぽい話っていうよりかは、なんかテストってなんだっけとか考えさせるような感じで役にも立つと思うんですよね。
テストの意義
テストケースとか自分で作成してる時に、あの本にはこういうのがテストとして必要だって書いてあったから、果たして自分が書いたこれはその基準を満たしてるだろうかみたいな、達してるだろうかみたいな、ちょっと手に取って考えてみたくなるなっていう表現とか観点もすごい多かったなっていう気はしてますね。
ていうような一冊で、18章だてですね。
そうですね、結構章としては長いですよね。
18個、そうですね。あ、しかもエピローグがない今回。
もう飽きちゃったのかな。
終わりにはありますけど。
そうだから、1章ちょうど8ページから10ページぐらい。
短いところはもっと短いか。
そうですね、短いところ一瞬で終わって、え、もう終わり?って思ったのはありましたね。
6ページだから見開き3ページぐらいのがあったりする。
18章あるんで、一個一個一章一章触れながら掘りながらだとちょっと長そうだなという気もするし、かといって章の上の概念の部がないので。
そうなんですよ。
どうやっていきましょうかね、今回は。
今回は前半の方が何でわざわざテストするのかとか、そのテストの役割とかっていう話があるんで、ちょっと前半の方を重めに喋って後半をあれですかね、ちょっと広いつまみ食いしながらいくみたいな感じにしますかね。
そうですね、そうしますか。
うん。
じゃあ何はともがあれ1章は触れると思うので、1章からいきましょうか。
1章がどうしてわざわざテストするのかっていうタイトルですね。
これがあれですよね、パーフェクトソフトウェアに対する皮肉っていうか、完璧だったらテストする必要なくないっていうこととしていきなり最初にこういう問いかけが来ているっていう感じですよね。
そうですね。テストする必要がなかったらテストしなくていいじゃん、そうじゃんって思いますからね。
そうですね。
1章はどんな話でしたかね。
そうですね、1章はなんでテストする必要があるんだっけっていうところで、人の思考は完璧ではないよっていうところで、人間が考えることって全然穴だらけだし、完璧ではないのでそれをちゃんとテストすることによって問題を見つけましょう。
見つけないといけないですよっていうようなところから始まってますね。
これそうだ。これ2ページの人の思考は完璧ではないっていう説で、テストが必要だって言われるのはお前は間違ってる可能性だって言われてるようなものなので、そこで苛立つような人がいるというかそういう反応もあり得るみたいなくだりで書いていって。
それで苛立つってことは、じゃあお前は間違いのない完璧な精密にやれるやつなんだなってことだから、もう読むのやめていいけど、もしその続き、その次の段落が面白くて、まだ読んでる人、ようこそあなたこそ本当の人間であり、自分が本当の人間だと分かっている人である。
本当の人間はどれほど頑張って完璧な仕事をしようとしても、時には誤りがあるものだと知っているって書いてあって。ここちょっとフフってなりました。
そうですよね。人じゃないですよね、完璧に全てが設計できたら。
そうですよね。いや俺の行動は完璧なんで、テストとかいらないですよ、時間の無駄ですよって言ってるやつは人間にあらずと。
もしくは人間として目覚めてないのかもしれないんですけど、少なくともテストを書いた方がいいと思っている人は本当の人間であるっていう、いいですね。
いいですよね。
炎上するぞこんなこと言うと。
人の思考が完璧ではないっていうのと、ソフトウェアについてもろもろ決定を下す必要があるよねっていうのがテストをやる理由ですかね。
リスクと意思決定
そうですね。ここでいうテストってプログラムのテスト工程みたいなテストっていうよりはもうちょい広い範囲で喋ってますよね。
めちゃくちゃ広いですよね。テストっていう広い概念があって、その位置処方とか位置パーツとして我々が思い浮かべやすいような自動化されたユニットテストとかいうのがあるよっていう雰囲気で捉えた方が、この方が多分読みやすいですね。
最初に日記帳で話が出てきて、ソフトウェアを買ってそれが動くかどうかみたいな話をしてるんですけど、確かにテストがいらないんだったらテストしないっていうことは、これWindowsに対応してるのかなMacに対応してるのかとか気にせずに全部ソフトを買ってきていきなりポンと入れて、よし動くでしょみたいな。
大丈夫、私完璧なのでみたいな感じで、そのまま使うみたいなことをするんだけども、でも人間って実際そういうことをするんじゃなくて、本当にこのOSのバージョンってサポートされてるんだっけとか、これを買ったら自分がやりたいことが満たされるんだっけとか、じゃあ試しでちょっと使ってみよう、1ヶ月無料で使ってみようとか、そういうようなことをするよねみたいな話が出てますね。
だからそれもテストっていうことなんですよね、多分。お試しでやってみる、ちゃんと動作するか確認するみたいな。
そうですね。で、この機能に対して値段が高すぎないかみたいなのも一種のテストであるっていうのが、日記その6に出てきますね。
結局テストをして何かを判断するためにテストをしているんだよっていうところでもあるっていうところですよね。
使い物になるんですか的なところですよね。
これぐらいの視点とかで考え出すと普段、例えばPHPユニットでテストを書いてるテストと、もうちょっとユーザビリティみたいな観点でお客さんがやりそうなシナリオを実際にテストとして動かしてみようとか、
いうところとかって全然観点も違うし、結局それをテストやった後に何を我々は判断してるんだっけとか、ちゃんとリリースOKだよねって判断してるとか、そういうようなとこに結構つながってきそうだなみたいなことを読みながら考えてましたね。
なんかちょっと後ろの方の話ともつながるかもしれないですけど、逆に言うといろんな必要な判断に対して何も情報を提供しないテストとかっていうのを結構ユニットテストにガーって視野を狭くしてやってると書きがちみたいな。
これテストが失敗したら結局何が分かるんだっけみたいなって言うと、失敗したんでじゃあ直しますかみたいな。いい状況みたいな。カバレッジを100%に近づけるためにあるだけなんで。
そこはそういう目的が元々わかってればいいけど、そのテストやめるとどうなるんだっけって言われて、カバレッジがちょっと下がっちゃいますねぐらいだったら。
まあだったらいらないんじゃないみたいな判断ができればいいんだけど、それすらわかんないとどうしていいかわかんないですからね。
厳しいですね。そこに対してコストをかけてるのかいっていう話にやっぱりつながるんで。
そうそう。
その、これお前がコストをかけているってことは、こたくの財布からむしり取っているってことだからなみたいな。
そうですね、そうですね。
我々の人権費は原価として扱われるので。
そうなんですよね。人間って高いんだよっていうことが。
で、その第一章の後半になると、決定にはリスクが伴うことがあるとか、テストをすればリスクを軽減するための情報が得られるとか、そんなことが書いてあると。
そうですね。なので、じゃあなんでわざわざテストするのって言ったら、ちゃんと完璧ではないからテストするんだよっていうことだったりとか、テストした結果から何か意思決定をしないといけない。
その意思決定も、○×でもじゃあこっちでってすぐできるものだけでもなく、リスクがある中でそのリスクを減らしながら意思決定をするためにもテストが必要なんだよみたいな話っていう感じですね、全体的に。
製品のリスクについて何を知りたいかっていうのを呪文して、でその呪文した結果、適切な処断っていうのがじゃあテストなんですかっていうところまで、もう一回聞いてみて。
そこの答えがノーですとか、もしくはそもそもこの製品のそういうリスクっていうのは分かってるというか、いやなくないっていう話だったらテストいらないじゃんみたいな、そうそうそう書いてあって。
いいですね。
そうですよね。
最初テストってどうやってテストを書くんだろうとか、何をテストしたらいいんだろうとかっていうことにだんだん当たり前ですけど目がいって、で結局そのテストってなんで必要なんだっけとか、このテストの意味ってなんだろうとか、
なんかもっと価値のあるテストをしようと思った時にだんだん視野を広げたり、視座を上げてみたりとかってしていくと多分こういうような話につながってきそうだなっていうような気はしますね。
この本の大体章の終わりによくある間違いってやつがついてて、これもすごいいいなって、この本の特徴としていいなって思ったりしましたね。
よくある間違い面白いですよね。まとめがちらっとあって、その後によくある間違いっていうのが、大体5個とか多いとこだと10個ちょいいってるところあったかな?みたいなのがついてて。
この章どうしてわざわざテストをするのかっていう章でいうと、よくある間違いに完璧を追求するっていう間違いについて述べられてたりとか、あとテストで製品が良くなると思っているとかね。
俺も全く同じこと付けましたね。
これはでもこの章っていうかこの後にどんどんどんどん追求していく感じがあるな。
そうですね。
あくまでテストっていうのは情報収集のため、製品のリスクについて知るための活動なので、別にそれをしたとて製品が良くなる、品質が上がるって言っちゃっていいのかな?ではないっていうね。
そうなんですよね。そうなんですよ。PHPユニットを書いたら品質が上がるかって言われたら、品質をどう定義するかにももちろんよりますけど。
テストの目的と誤解
確かにカバレッジが品質ですって言われたら、はい、確かに。
けど、じゃあPHPユニットを書いたら素晴らしいなんとかアーキテクチャーになりますとか、なんとかという設計を満たしているとか、良い原則に則ってますっていうことにはやっぱりならないし。
でもカバレッジが満たされてないと、その製品は購入しませんって言われたら、もしかしたらカバレッジがある程度の価値というかお金になるかも嫌なテスト書かれそうだな嫌だな。
しかもカバレッジが高いから、じゃあそれはC0、C1、C2どういう話ですかっていう話もあったりするし、全然境界値見てないっすみたいなテストもあったりするので。
この本の後ろの方にもテスト結果の資料を分厚く積み上げると、小池が喜ぶ可能性があるみたいな話が載ってたりしましたけど、だんだんそっちに近づいちゃいますよね。
ワインバーグそういうところあるなと思って、ゾッとする冗談みたいな話をよく織り混ぜてきますよね。
それを他人事として笑い飛ばしてると、変なおっちゃんが変なこと言ってるなーで終わりなんですけど、地続きじゃないですか。
そうですね。
自分に置き換えたらこれは何を意味しているだろうかっていうのを考えながら読むと非常に気が重くなりますよね、いつもいつも。
そうですね。
ウッディなるやつですね。
そう、自分たちはこれがよくベストプラクティスだと言われるんで導入してやってるが、じゃあそのワインバーグがとことことやってきて、これは何の意味があるんですかって言われて、いや周りがそうやってるんでって説明した瞬間に刺されそうなこと起きるからなーっていうのはありますね。
いややっぱりワインバーグの等身大パネルを質問室に置いとくしかないな。
そうですね。
それだけで品質が上がるんで。
いやー面白いですねやっぱ。
あとよくある間違いがこの章6個で5つ目が今のテストで製品が良くなると思っているなんですけど、6つ目のテストフェーズというものがあってその間に全部のテストをそれもテストだけをやるものだと思っているって書いてあって、
これはなんかよく偶像的に描かれる語られるウォーターフォール的なプロセスだと、まあもしかしたらこういうものがあるかもしれないなーっていう気は、本当に見たことがないので想像でしかないんですけど、まあまあまあするんですけど。
まあでも経験年数が少なかったりすると、なんかここで作ってここでテストしてリリースですみたいなテストとリリースがくっついてるみたいな工程表は見たことあるなと思いながら。
じゃあそこのテストで不具合があったらどこで直すんだいみたいないう話を。
だったらテスト省略してリリースした方がいいのでは。
そうですね。
ってことですよね。なんかまた崖から飛び降りちゃってんじゃんみたいな気がするから。
まあ、もしかしたらその人が完璧である可能性があって、私は間違いはしないんでっていうことかもしれないなっていう。で、テストしましたっていう証拠だけが必要なのかもしれないっていう。
で、この6番目のよくある間違いの中にクライアントとコンサルタントというかエキスパートかの人の例え話だと思うんです。会話でちょっと表現されているのが結構面白いなと思って。
なんか車の運転について考えてみるを話すと、ドライブ中のフロントガラスから外を見るフェーズはいつですか。運転中はほとんどずっとフロントガラスから外を見ているでしょう。それはフェーズじゃありません。っていうちょっと比喩めいたセリフが載ってて。
これ聞くとやばいですよね。フロントガラスから外を見るフェーズ。で、さっきの話とつなげると、この間外しか見てないってことなので。
そうですね。
外しか見てないのはいいんですけど。でも多分ハンドル握ってるかどうかとかは保証されてない気がするんですよね。そこのフェーズ。
そうですね。速度計とかはもう見ないとやばいよね。
いろいろ準備して、よしじゃあ整ったから次はフロントガラスから外を見るフェーズですって言って。
しかも逆に言うとそこまでは外を見てないっていうことだし、見てる間はそれ以外が見えてないし。
鍵を刺して回すフェーズぐらいまでならまだ許せるけどその後は頼むから一緒にやってくれって。
そうなんですよね。ここを読んでて、スクラムのDODを決めましょうみたいな中で、完成の定義みたいなところの話をするときに、ストーリーのチケットが終わったってどういうんだっけって言ったときに、最後にまとめてテストするっていうよりは、こういうものを満たしたら終わりだよね。
それを満たすためにどういう工程でやるかっていうのは別に決まってなくて、とにかくこれが終わったらダウンだよね、第一ダウンだよねっていう風になってるのってすごいよくできてるなって思いましたね。
スクラムはよくできてますよね。
あとは上手に使うだけなんやみたいな。上手に使えないからみんな困るんだけど。
でもよくできましたって言ったら、それテスト書いたって言ったら、テストはこれから書きます。じゃあできてないやんけって言って、できましたテストも書きましたって言って、それ動作確認したって言ったら、いや動作確認してないですみたいなことって本当によくあるので。
最近はAIがよくそれやりますからね。
そうですね。
テスト通りましたって言ったら、はい通りましたって全部消していいんじゃねえかみたいな。
テスト通ったか、フェールしてないですって意味だからね。
通ったって何なんすかね、パスってどっちのパスかなみたいな。スキップの方のパスかな。
なのでこの辺とかはやっぱりAIが出てきてもちゃんと人間がどうやったらテストが終わった、ストーリーが終わったとかいうことを考える、一緒に考えていく必要はやっぱりあるので。
そうですね。運転席と助手席は入れ替わったかもしれないけど、たぶん人間がコパイロットとして頑張る必要があるなみたいな気が。
そうそうそう。
で、さっきのフロントガラスのフェーズの話やると、ウィンドウから外を見ていなかったせいで事故が起きたらどれだけ時間がかかるか考えてみることだって書いてあって。
ここが非常に品質保証とかテストに関するわかりやすい例えというか、事故の時の損失考えたら先にやっておいた方が良くないが一個ありますもんね。
そうですね。
あとは修正コストが早めの方が早くつくっていうのがソフトウェア以外もあるからそっちも大事だと思うんですけど。
てな感じで第1章から盛り上がってますが。
そうですね。これ多分第1章だけで無限にここから連想ゲームしたら話せるなって気持ちになってきたな。
第2章いきますか早めに。
品質保証の重要性
第2章いきましょう。
