情報伝達のプロセス
で、11章からが情報伝達のプロセスっていう話が始まるんですけど、これはですね、サティアさんの話をまたじっくり丁寧めに話してるそうですね。
サティアの交流モデルか。取り込み、意味付け、意義付け、反応のやつですね。
いつものやつですね、みたいな。
いつものやつですね。なので、ここは前30分とか50分かけて話した話の内容とめっちゃ重複してる気がするんで、
そう。
さっといきますが、なんか触れておきたいとか、久しぶりに、久しぶりでもないな。今回読んでみてここがちょっと印象残ったなぁとかありますか?
そうですね、なんか12章の意味付けの部分で135ページ?
135。
で、結局そのテストした結果とか、テストの情報を見て、解釈する前に自分が何を知りたくてそれをテストしてるのかとか、そのテスト結果を見てるのかみたいな話が出てくるんですけど、
結局プログラムとかシステムとか、何をするためのものか理解しなくて、そのテストをしたり、そのテストのレポートを見るみたいなことをやっていても、
プログラムが何をするためのものか理解してなければ、それが間違っているなと断言はできないということだっていうような話が出てて、
普段ソフトウェア開発やってた時に、結局お客さんがこれどう使うのかみたいなことが想像しないまま、これが仕様書だからと渡されて、仕様書の通りに実装して、
じゃあ動くようになった。動くようになったけどそれが使いにくいとか、これで合ってるんだっけとか、本当にこれって何なんだろうみたいな状態のまんま、
テストしたりとか実装したりしてると、それって判断できないよねみたいな、合ってる合ってないが判断できないよねと思ってて、でも仕様にはこう書いてあるからOKとかって、
やってしまうんだけど本当にそれでいいんだっけみたいなことは結構思うことがあったなっていうことがあって、
結局テストする人とかそのテストのレポート読む人が、ちゃんとこのシステムっていうのは何のためにあるものなのかみたいなことの、
ちゃんと理解してないと結局テストした、テストをパスしたって言っていいのかなどうなのかなっていうのって、
とても難しいことなんだなっていうことをちょっと読んでて思いましたね。
仕様書の限界
その話に関連して言うと、何だろうな、結構仕様書ってやっぱり完璧じゃないじゃないですか。
仕様書とか要求とか。完璧じゃないってことはそこに書かれてない、表現しきってない、表現されてないものもある程度頭の中で保管したりとか、
コード読んでこういうことかもなっていうのを組み立てながら実装してやっていくんですけど、本当に書かれてる文字面っていうのをメインに実装していくと、
なんかすごいアプリ上に現れた時にすごい違和感があるものが出来上がったりとかって、オンボーリング見せると発生しがちだなっていう気がしてて。
元々そこのサービスとかアプリケーションの開発、提供に関わってる人から見たら、これだけ書いてれば伝わるだろうっていうふうな書き方されてると、
新しく入ってきた人って、なんかそのアプリの中とかそのユーザーのマインドセットをメンタルモデルとしての当たり前っていうのがわからないので、
なんか言われたものを出来ましたって言った後に、なんか先輩たちはね、いやーこれ使いやすくない、明らかに変なのを普通に考えればわかるやろみたいな態度を取られ、
辛いみたいなっていうのはよくあるんじゃないかなーっていう気がちょっとしましたね。
いやー、それってこうあれですよね、でもなんか一長一短みたいなのがあって、
うまくオンボーディングがいくと、うまくメンタルモデルが作られると阿吽の呼吸みたいに進んでいくんだけど、そうじゃないとうまくいかねえってなるから、
でも人は入れ替わっていくし、普段自分たちがメンテしているソフトウェアの部分って、もしかしたら別のチームが触る可能性もあるし、
移動してチームに入ってくる人もいたりするんだから、極力うまくオンボーディングできるようにしておかないと、持続可能性が低いよねみたいな感じにはなるんですけどね。
非正確な表現の有用性
難しいですよね、なんかエンドユーザーもないし、コタクの目線でアプリケーションにちゃんと触れるみたいなものを経験させるのが一番なんですかね、
生の体験に近いというか、いいんだろうなーっていう気はしつつ、それもまたどこまでやるのかとか。
おだしょー 開発者はユーザーではないですからね、究極的には。
そうですね。
おだしょー なので、そもそも問題を抱えてない人が問題意識を持って頑張って触ってみるって結構難しさはありますからね。
そうですね、確かに。
おだしょー 自分がユーザーになるようなサービスだったらまだやりやすいんですけど。
そうだよな。
おだしょー そうなんですよ。2Cと2Bでは全然違ったりとかね。
そうですね。2Bではまだ、結構スモールビジネスのための2Bとか、一般的な組織運営のために必要なものだったらまだいいんですけど。
なんかわかんないですけど、工場を建築するのをサポートするSaaSとかってなると、
じゃあユーザー目線、インストールするために好きな工場1個作ってきてくださいとか。
おだしょー なんだそれ、シブシティかみたいな。
そうなんですよね。それ系でいくと、フリーとかは透明書店っていう書店を立ち上げて、そこで実際いろいろ使って見えてくるものとかみたいなことやってて、
なんかああいうのとかちょっとすごいなーって思ったりしますね。
結局的にはやっぱりユーザーになるのは結構難しかったりするから、多くのサービスは。
おだしょー 本気でやらないとわかんないですからね。
そう、でもその中でこれはちゃんと使えるサービスだよねっていうことを担保しながらテストしたりしないといけないって大変ですね。
おだしょー ああ、そうだな。それで言うとアクセス解析ツール作ってるときは楽しかったな。
だから自分のサービスにログ仕込んでたんで。
いいですね。
おだしょー アクセス解析ツールの解析はアクセス解析ツールでできたんで。
絶対このページに来た人って実際にその前に2ステップぐらいかけてここから来てるじゃん。
じゃあ直で飛べるようにすりゃええやんみたいな話とかが出やすかったんで。
おだしょー いいですね。それ楽しいですね。
めっちゃ楽しかったですね。
おだしょー なのでテストしましたって言ってOKに丸がいっぱいついてるから大丈夫ってよりは本当にこのシステムはうまくいってんだっけとか
不具合がないけど使い物になるんだっけみたいなところまで考えると良さそうだなっていう気はしたなっていう感じでした。
あとあれかな似たような似てないような話で言うと同じ意味付けの章なんですけど
140ページの不正確の方が良い場合もあるっていうのがちょっとこれは非常にあるよねって思いながら読んでて
例えば我々は専門職としてやってるので職種の人とか違う会社の人に俺たちが本気で正確な説明をしても伝わらんじゃないですか。
ありますね。
おだしょー ここの機能の動きが変ですよって言われて確かに不具合がありました修正しました。
そうなんですね、どういう問題があったんですかって言われたときに
このデザインパターンをここで使っててこれそうするとメモリがどう残ろうでみたいな話をしても
そもそも社外の人にそういう話をするのだいぶ際どいなと思いつつ
社内の別の職種とか別の部署の人とか話してもわからんし
なんか性格っていうよりかは少し性格性は核が伝わるような表現っていうのがあるよねとか
本当に欲しい知りたいところとか相手にとって価値のある切り口ってなんだろうなみたいなところを踏まえて
なんか説明していくの大事だよねっていう気がするし
そうすると相手の質問がつまり何を意味してるんだろうかっていうのを読み取った上で
そこに照準を合わせてボールを返さないといけないよねっていう話ですかねここは
そうですね、今目の前にマックのキーボードを見て
キーにリターンって書いてあってそうだこれエンターキーじゃないなって思うけど
エンターキーで通じるとかことをちょっと思ったりしましたね
確かに
それって性格じゃないけどリターンキーを押してくださいってわざと言わないよなとか
エンターでもエンターでもなくないですか
これエンターキーマックだとリターンって書いてあるけど
Windowsだとエンターとかって書いてあるような気がする
エンターなんですエンターっていう単語なんて意味だっけとなんか入るわけじゃないじゃないですか
そうですねそうですね
入力するって意味があるのか
なるほど
確定キーですもんねだいたい
そうですね
なるほどねなるほど
でもコンピューターの用語なんて冷めいたものばっかりですからね
そうそうそう
オープンって何ですかアロケートでしたかみたいな
あとあれだなここの説で面白かったのがなんか
例えば間違いや過失といった言葉から非難めいた意味や切り合いを話せない人間に理解してもらいたいときは
ここまではすごいまあそうだねわかるねって感じなんですけどその続きが
バグや問題といった厳密でない言葉を使うと良いって書いてあって
これはちょっと皮肉って面白いなって思いました
まあそうそうなんですよねバグとか問題は全然厳密じゃないので
ワインバグっぽさがすごい溢れ出てるところですね
そうですねはい
忌み付け僕はそこですかね印象のこったの
うんうん
情報伝達のプロセスの一連のまあ11から14章で他なんかありますか
そうですね
忌み付けのところであれですね金銭の話がお金の話をしていて
それはなんか結構なんか面白いっていうかそういう考え方してこなかったなみたいなことがあったんですけど
48ページあたりか
そうですねどういうぶんめきかっていうと
まあ重意義まあ重要度みたいなところで
まあ情報は同じでも人によって重要度は異なるよみたいなのとか
意義ってのは状況によって異なるよみたいなところで
あとじゃあその意義みたいなものって金銭的に測れるんですかとか
例えばこの不具合を解消するといくらいくらいくらですよみたいな話とか
これができなかったらどういうような賠償があるんですかみたいなこととか
まあいろいろ出てくるんですけど
人間はそうですね
まあでもじゃあ命ってものを兼ね勘定できるのかみたいなような話があって
ゴールデンゲートブリッジの橋の建設をした時には
11人の人命が失われましたよみたいなことがあって
11人も人が亡くなったっていうことでもあるんだけど
今までは橋を作るのに100万ドルに月1人
100万ドルに月1人ぐらい人が亡くなるっていうような統計的なデータがあったんだけど
35人亡くなるっていうふうに予想されていたのが11人だったから
まあこれはすごいこと新記録なんだみたいなことが書いてあって
じゃあその100万ドルに月1人人が亡くなるっていうことを
じゃあ金勘定で考えたら人が死ぬのは良くないんだからって言って
じゃあ橋を建設するのをやめようっていうふうにもならないし
なんかこの辺とかっていうのはソフトウェアでクリティカルなものを作っているわけじゃないので
普段地味に関わるソフトウェアももちろんあるんだけど
自分が今までやってきたものとかはそういうものがなかったんで
人の命みたいなものが出てきた時に息づけを考えるってすごい難しいなって思いましたね
そうですね人命だと重すぎるなっていうのはあるんですよ
サービスのコンセプトを支えるために重要な機能とかやっちゃいけないラインみたいな話とかも多分ありますよね
一見無駄だし合理的でないけどこれこそうちの魂なんだみたいな話とか
人命の話で重いって言った後に魂とか言うと紛らわしいですね
重要な意義を持つけど別にそこが利益を直接的に生んでるわけではないとかはありそうな気がするな
そうですねセキュリティとかってまさにそれに近いですよね
セキュリティはそうですね
ランサムウェアでシステムが全部使えなくなって流通が止まりましたみたいな話してこの1,2年とても効くような気がしていて
数時間前の聞いた気がするんだよね
ソフトウェアテストの課題
しかもそれは他人事じゃないわけじゃないですか
明日は我が身とかな世界でとかって見た時にじゃあどうですかねみたいな
とてもとても大変なものですねっていう
なんでこの本でこんな重い話をしてるんですかね
意義づけ
バグがあったよねとかっていう時に重要度を判断するみたいな話からか
そうですね
人の命を金鑑上できるのかっていうのはトルク問題とか
定量で人の命測れるのかみたいなのっていうのは哲学の分野でめっちゃ扱ってるから
あとはそっちに任せたみたいな気持ちになります
でもこれ以外は意義づけの章も今までも何回かというか何冊の本かで
何冊かの本で触れてきたサティアさんの話だなっていう感じでしたね
そうですね
そんなところですかね
ですかね
そうするとここら辺から終盤っぽい感じの15章から
18章までありますけど
15章は2人ともメモ入れてるからちょっと触れますか
そうですね
ソフトウェアテストを難しくしないためにっていう章です
結構短い章だけど2人ともめっちゃコメントしてるのはおもろい
確かに短いのか
そうですねここ何言ってるかっていうと
そもそも進化し変わり続けるソフトウェアを複雑化するみたいな話があるいはありますので
そうですね
やっていくうちにどんどんソフトウェアテストっていう意味での状況っていうのは悪くなっていく
1個のプロダクトとかソフトウェアのライフサイクルっていう観点でもそうだし
もっと広いね時代的な世間的な話でもやっぱり大規模化複雑化していくので
そういう意味でもテストってどんどん難しくなってるよね
その中でどうやって抵抗していくっていうような話がこの章ですね
だからそこで語られてるのはシステムはできるだけ小さく抑えるとか
システムのモデルに拡張性を持たせるとか
あと独立したコンポーネントと明確なインターフェースでインクリメンタルに開発するとか
入り込むバグの数を減らすとか書いてますけど
システムの単純化の重要性
入り込むバグの数減らせるならやってるがって感じではない
そうなんですよね
これはあれですかね
バグ早めに見つけるといいよねみたいな
一匹のバグが他のバグを連れてきたりするので
だから終盤でテストフェーズえいやってやるっていうよりかは
なるべくどんどんどんどん早めに細かくやっていこうが
入り込むバグが少なくなるよねとか
そうですね
って話ですね
ここらへんはシステム指向法でよく触れてるやつだな
っていうようなそうですけど
源さん的にはどのあたりがお好きでしたか
やっぱこのシステムはできるだけ小さく抑えるっていう話が好きで
好きなんですけど
例みたいなのがタイトルのちょっと上の方に出てて
化学の会社がすごいでかいプラントを作ったんだけど
それを作ろうとすると
いろいろ考えることがどんどん増えていって
難しいので建設を中止してより小規模なプラント建設へ目を向けて
またそれを複数作るみたいな感じにするんだろうなみたいな感じなんですけど
マイクロソフトミスだ
そう
結局大きいものを作るっていうことの難しさと
小さいものを同じように複数作るみたいな
ちょっとそこまで複数作るっていうところまでは書いてないんだけど
そういうようなことっていうふうにした方が複雑さを減らしたりとか
見積もりの当たる可能性を高めたりするようなっていうのが
なんかここでも言われてるし
最近でも同じようなこと言われてるよなっていう気がして
なんかやっぱりこの辺の考え方って変わってなくて
だからソフトウェアテストを難しくしないためには
ソフトウェアをそもそも単純にするっていうことのほうが
やっぱ大事だよねっていうのを思ったりしましたね
なんかここの辺りの話を読んでて
なるほどな確かにって思ったのは
システムがちっちゃくなってるってことは予定もまた小さくなってるし
単純化されてるんですよね範囲がちっちゃくなってるんで
要求が少なくなるシンプルになる狭くなるってことは
ソフトウェア側に求められる複雑さっていうのも減ってそうだなみたいな
なんかこれはちょっとなるほどなっていうふうに思いましたね
そうですね
やっぱりチームの力で組織を動かすとか読んでても
バリューストリーム少ないほうが
チームをうまく回すって意味では勝てそうだなっていう気がするじゃないですか
偉大化して1個のチームに対して刺さってるバリューストリームが
2個とか5個とか10個とかになっていると
非常に変更が難しいってなりそうだなっていうのは容易に想像できるので
あと172ページもたぶん1つのバリューストリームに
3チーム4チームもできてしまう容易にっぽいものが書いてあって
ソフトウェアで何でもできるかといって
ソフトウェアでしかも全て同じシステムで何でもしなくてはならないということにはならないっていう話があって
これすごい好きで
欲しいって言われたものを全部実装するぞみたいなことをやると
いやソフトウェアで実現できるでしょみたいなこと言われて
じゃあ作りますねっていっていっぱい作ってこんがらがったものが出来上がって
あのお客さんの時はこうでこっちのお客さんの時はこうでみたいなイフ分を増やし
どんどん掛け算的に複雑度を上げていくみたいなことって
たぶんよくある話っていう感じがしていて
でも一方で作りにしても同じシステムにする必要があるのかどうかとか
いや何でもできるようにしてとかってよく言われるけども
何でもできるからといって何でもそれを作らないといけないってことは
まあやっぱないよねっていうことを改めて思ったりしましたね
7割まで自動化してシステム化してあと3割は手で頑張りますとかはね全然ありだと思うので
顧客ニーズに応じた開発
って書いてそういうような話がまさにこのように書かれてるんですけど
そうですね
エッジケース難しいですもんね
そうなんですよね結局だからといっていろんなものを作りませんってやると
誰にとっても価値のないソフトウェアができなくてこれ誰が使うのみたいな感じになったりもして
そこの落としどころみたいなのっていうのを
だからこそパルソナを決めましょうとかちゃんと運用しましょうとか
まずはN1インタビューでN1のユーザーをハッピーにさせるようなベースとなるようなものを作って
そこを拡張していきましょうとか
ユーザーストーリーみたいなものを考えて
みんなが共通するようなユーザーストーリーの部分をまずは作っていきましょうとか
いうような多分手法みたいなものとか考え方みたいなのは多分いっぱい現代ではあると思うんですけど
でもどこが一番顧客が一番取れるケースなのかとかっていうのは
わかんないですからね最初作ってるタイミングでは
わかんないっすねリリースしてもわかんないですからね
そうですね
頑張り続けるしかないみたいな
だからこそ逆に言うとすべてを作りきってから出すとか
何でもできるようにしてから出すんじゃなくて
まずはこれしかできないけどっていう状態で
ある程度は諦めをしてリリースする必要もあるんだよなみたいな
画面に文字が入力できるようになりました
保存はできませんだとちょっと足りなさすぎだろうとかあるんで
全部作らないっていうのはそういうことではないんだけど
今時誰でもスマホ持ってますよねカメラついてますよね
それで保存はできるじゃないですか
そうなんだよな
セキュリティ的にだいぶ怪しいな
スクリーンショットで見たい
でも印刷関係の機能はブラウザのプリントに任せるとかはあり得ますもんね
あり得ますね
CSSだけプリント用に当てておいて
もう大変ですからね
大変ですからね
PDFを自前で生成するの後回しにできるじゃないですか
本当にそれありがたいんだよな
みんな長評のズレをどうやって頑張るのかみたいな
一大知見が溜まってそうな話がいろんなところに転がってそうって感じがありますからね
そうですね
やっぱり住所のパースと長文を作成は
みんながみんなあちこちで実装したものだ
15章そんなとこですかね
そうですね
16、17、18あたりはなんかあればまとめていきますか
どれも面白い面白かったんだけどなと思いながら
どう話そうかなと思ってるまんま線を張らずに過ぎてったな
なんかクライマックスが来そうだぞみたいな気がして
そこで付箋を張ろうと思ってたら意外とそのままスルスルといっちゃうみたいな
これでもそうか16章とか見るとなんかレビューの話に入ってて
この辺はあれですね我々が読んでいない技術レビューハンドブックの書いた人としての知見が埋め込まれてるんだろうな
そうですね
章のテスト詐欺でもまたデモは詐欺であるとデモンストレーションですねは詐欺であるとか書かれてますね
そうですね
でも詐欺をして上手に契約を取ってきて後で頑張って作るっていうのは世の中にあったりしますねそういえば
AIがやってますって言って裏で頑張って逃げがやってるみたいなやつ
それは別にいいんですけどね内部実装は別にみたい
17章がテスト詐欺で18章最終章が無意識の詐欺なのか
18章に分厚いテスト計画書みたいなものがあってこういうのやってるからうちは大丈夫ですよみたいな
信頼してくださいみたいな話があったりするけど
でもその中身が数量があればいいっていうことと中身が価値があるかどうかっていうのは間違いはねみたいな話とかあって
それはそうだよねみたいな
207ページに何も変わっていません詐欺っていうのがありません
そうそう
さっきの
さっきの話はこう読んでるときにこうぐさっとくるやつですね
よくあるのはそこの実装変えた結果全体のシナリオで見たときにはこっちにも不正が起きるよねみたいなのがあったときとか
そうかここだけ直せばいいと思ってたんだよなみたいな
ありますね
APIのレベルで見たら問題ないんだけどシナリオユーザーが操作するシナリオで見たら問題がありましたみたいな
なぜテストしなかったんですかって言われたときに
必要ないと思ったいやーとしか言えないやつ
でも必要あったでしょ
必要あったでしょ
でもそんな発見的やんみたいなとかねロジカルに導出できるんかいみたいな気持ちになるんだよな
でも最後の方はなんかここを超突っ込みたいぜっていうのはあんまりって感じですかね
そうですね最後の方に言葉が強いなゴミはスプレッドシートに並べてゴミである
そうですね
まとめもいいですよね一条だけ書いてあって
18章のまとめが全てがうまくいってほしいと強く願っているときはデータに幻想が入り込みやすい
いやーわかる
そうそうそうですね
なんかリリース前とかそうなんだよな
そうですね
これでうまくいったらもう大丈夫って言いながらうまくいかねえんだよなそういうとき
なんかやだな辛い話になってきた
まあでもそんなところですか必殺
そうですね
いやー面白い面白いワインバーグやっぱり
面白いなこれいつもだと冒頭に聞いているような質問ですけど
なんかどんな人におすすめですかね
開発者じゃないけどソフトウェア開発に携わっている人
そのpディレクターとかpdmとか何ですかね
なんかソフトウェアの開発ってものがどういうものかを知りたいなと思った人に
こう何冊かある本のうちの1冊としてっていう感じかな
いきなり初手でこれを読んでくれたらもちろんないんだけども
なんかプロジェクトマネジメントとか
確かにpm pj向けの人はそうかも
テスト技法の重要性
ってなった時にテストってテスト技法のことを勉強ももちろんしてほしいけど
それだけを知っていればうまくいかかってたらそうではないと思うんで
それだとちょっと入り口のハードルが高いなって感じた時に
なんでいつもプロジェクトマネジメントしてる時にテストで問題が起きて遅延するんだろうとか
って思った時の1冊として読んでみるともしかしたらちょっと違う視点として
こういう感じの本ってあんまないと思うんで
ちょっと違った視点で見るためにいいのかなみたいな気はしましたね
僕はやっぱり自動化テスト的なユニットテストとか
いわゆるCIで回すようなテストをどうしても想起しながら読んでたなっていう気はしてるんですけど
なんか開発者でユニットテストはAPIとか文法とかある程度理解して
一人で書けるようになりましたぐらいの人が読んでみると
なんでテストやるんだっけとか
テストによってどんな価値を提供できればいいんだっけっていうところに
すごいたくさんのヒントになりそうな本だなっていう風な気がしたので
そういう人たちに読んでみてもらいたいかもなって思ってるんですけど
もうちょいコンパクトだと進めやすいなっていう気がしますね
ワインバーグの本の面白さではすごいあるんですけど
脱線とか余談とか例え話が非常に多いので
読み物としての面白さはそれでふんだんに盛り込まれてるような
プラスされてるような気もしつつ
明確にピンポイントにここらへんが知りたいっていう人には
少しまどろっこしく感じるかもしれないし
ワインバーグさんの本だって言って肩肘張って読むと
なんか真面目に読みすぎる気がしちゃうなっていう気もしてて
結構ねあーはいはい的な態度で
軽く読んでもいいところも結構多いと思うんですよね
っていうのもあるのでそういう意味でもうちょいコンパクトだと
僕が思って刺さって欲しい人に進めやすいかなと思ったんですけど
遠い200ページだし文章自体は非常に読みやすいので
読めばよかろうとは思うんですけど
そうですねそうですね
でも今聞きながら確かにこう
昨今こうなんか自動化テストなんかブームだなと思ってて
AIの力によって今までコード書かなかった人も
E2Eテストが書けるんやみたいな話って結構見るように見かけるようになったなとか
プレイライトのMCPとかプレイライトのエージェントみたいな話が出てきて
E2Eってすごく便利は便利だし
ユーザーが実際行動することを模倣してテストできるっていう意味では
すごくありがたいんだけどめちゃくちゃ時間かかるし
そこをどんどん増やしていくと
CIの時間が伸びましたねみたいな話になったりするし
何でもかんでもチェックできるからといって
何でもかんでもチェックすべきではもちろんないんだよなっていうのはあるので
結局そのE2Eでどういう価値を手に入れたいのかとか
この本的にはどういうような情報を仕入れたいと思ってるのか
っていうことを考えるためにこの本を読むと
E2Eでどういう情報を手に入れるようにしたいんだろう
ってことを考えながらテストを書いてくれるようになると
多分どんどん増えていってCIの時間が長くなっちゃったものを
解消することができるようになるのかなっていうのは
ちょっと話を聞きながら思ってます
自動化テストの視点
この辺まで課題が具体的になってる人は
アザラルテスティングの本5冊ぐらいばって並べて
くらえって言って投げつければ勝てそうな気がする
勝てそうな気がする
もうちょっと時間にゆとりがある人が読んでほしいな
そうですね
多分この本が何冊かのオブ1冊みたいな感じになるといいのかな
ぐらいな感じですかね
なるほど
この本1冊で何かを解決してくれるって感じはないので
何かと合わせながら一緒にヘイドックする本になるのがいいのかな
みたいなことを
そうですね
何か本当に
いくつかすごい心に残るフレーズと出会えたらいいんじゃないかな
この本はっていうのが
割と僕自身は読書するときにそういう気持ちで
何か本当に1個でもずっと記憶に残ってるものがあれば
1個って1フレーズでも記憶に残れば
読んだ価値あったなぐらいに思ってるんですけど
何かこの本は本当に
何だろうな
結構人によって刺さるところが違う気もするし
僕らは散々聞いたわと思って読み飛ばした
11から14章だいぶ面白いですからね
そうですね
その辺りが面白かったんですか
じゃあソフトウェア文化を作るってシリーズがあって
っていうのはできづらいしづらいので
そうすると
やっぱりこの本でエッセンスを
汲み取ってもらっての方が
何かお互いにヘルシーな気もするし
面白い本でしたけどね
ただちょっと手に入りにくさはありそうだよね
っていう感じはするので
これも手に入りづらいんでしたっけ
あんまり本屋で見かけ
DKBDだと
電子書出てません?
電子書はありますね
そっちならね
いけそうな
電子書とかはちょっと怪しいかもしれないですね
さすが直近で
でかい書店でワインバーグ覗いただけのことは
そうですね
英語でよければ790円で買えますよ
Kindle版
すごい
安い
要所面白いですね
ペーパーブック3790円でKindle版790円ですね
値段違いすぎだろ
一応紙の本も中古でよければ456円プラス送料みたいな感じですね
2400円なんて低価って感じですよね
新品は手に入りづらいは入りづらいのか
フル本屋で見つけたらぜひ買って読んでもらえるといいなって思いますね
そんなとこですかね
今回は差し得もあんまりなくて
なかったですね
確かに
ほとんどなかったんじゃないかな絵は
図とか書はあるかイラストっぽいものはないな
そうですね
そうするとこの拍子のもぐらたたき
バグたたきっていう説があったんでそれなんでしょうけど
特に解説がないってことですね
そうですね
よしじゃあ終わりにしますか
はい
今週も放送いただきありがとうございます
ではまた次回さよなら
さよなら
