00:06
三つの層ですね、第3部は。 じゃあ第3部、本編入っていきますか。
そうですね。12章有害はもう結構好きなプレイ図というか、いいなーって思うとこ多かったんだよな。
どこら辺好きでした?
168ページで、株の取引かな?金融のシステムの話を、そうですね。株取引のやっていて、フラグをオフにしたままリリース。
リリースして、本当はフラグはオフだったはずが、オンの部分があって、うまいこと動かなかったみたいなことがあって、すごい損失を出しましたよと。
45分間で4億6千万ドルの損失。今だと600とか700億円ぐらいの損失が45分で起きましたよみたいな話があって。
結局このミスって何だったの?っていうところで、プログラマーがシステムが何をしてるか把握してなかったことがミスだよって言って、
一方で全部何がどう動いてるかってことを求めるっていうのはしないけども、どこの設定だってどういうことになってたら害がないっていうことを知ってるかどうかっていうのは大事だよっていうのがあって、
これってシステムがどんどん複雑化してる現代においてとてもとても大事だなって。
難しいかもしれないんだけども、そこは自分たちが書いた行動っていうのが有害でないっていうことのためには考えておく必要があるんだよなっていうふうにすごい思いましたね。
これは本当にゾッとしますよね。1個デプロイしたら会社が倒産したっていう話はすげーよな。
倒産してるんですよね。
そうですね。この本以外にもちょいちょい聞く話な気はするけど、いつの話なんですかね。2012年8月。
全然最近ですね。
2012年以降に出た本で読んだんだろうな多分。
そうですね。未来を知ってない本であるければ。
まあでも難しいですけどね。結局知らないことは知れないんで、あんのあんのはわからないんでやっぱり。
だからロールバックとか段階的デプロイとかちゃんとやろうぜにはなるんでしょうね。
そうですね。
100防ぎ切るのは無理だから、最悪の場合でもなるべく継承で済むようにするみたいな。
これは無限ループが起きてたのでずっと通り切りし続けたみたいなのがあったんですけど、
03:04
例えば無限ループしない入っちゃったりしたらここで打ち切るみたいなフレッシュホルドみたいなサキットブレーカーみたいな仕組みが必要だったのかもしれないし、
だいたいそういうのって何年かに一度しか動いてなくて、動くタイミングがなくて、何年かに一度だからテストしてたんですけど、
と実は動かなかったみたいなことになったりするんで、難しい。
あとこれの場合で言うと、クラスターのうちの1台が多分デプロイが通ってなかったんですよね。
複数のバージョンが同時に存在する状態っていうのが不整合を起こしちゃって問題になったって話なので、
そっちに対策するのがまだ気づけそうというか、簡単そうなのかなっていう気はするような。
AWSさんがここら辺はヨシラにやってくれちゃうからな今。
そうですね。
怖い話でもあり、完璧っていうのは無理だけど、そうやっていろんな対応策考えないと考えていくしかないんだよなってことを思いながら読んでました。
その関連で言うと、ちょっと前のページというか最初の説にある言葉が結構多いと思って、
動いたのはキーボードの上にあるあなたの指であり、あなたのコードである、あなたはコードの動作を把握しなければならないって書いてあって、
プログラムがCPUで動いてましたじゃなくて、それを生んだのは自分が動かしているこの指なんだ的なやつと言われると、
確かに私でございますみたいな。それを動かしたのは私でございますみたいな気持ちになるなと思って。
そう思って今度やっていくと例外が出た時とかシステムがダウンした時とかにすごいショックを受け立ちながらなるというか、
もうちょっとコードを書くの怖いなって思っちゃったりするんですよね。
でもそれはそういう責任を持った人なので頑張って受け止めてくださいという話でもあるんだけど。
そうですね、責任を引き受けるっていうのがやっぱりリリーだなっていう気がしますからね。
いいですね。
このように延長線上でいくとAWSで動いてるからAWSが落ちた時に、うちが悪いんじゃなくてAWSが今サーブ落ちてるんですって言い訳がどこまで通用するのかなとか。
06:08
まあ難しいですけどね。難しいですけど、でもAWSってものを選んだのはあなたたちでしょって言われたらまあそうですねってなるし。
そうですね、いや難しいよな。
でもある種例えば社会っていうものは寛容になると落ちていったらまあしゃーないねって済む場合もあったりするからな。
なんかまあこれはしょうがないねみたいなことあるわけじゃん。
なんかその辺の境界線って今どこにあるんだろうなみたいなことは。
エンジニアが他の会社のAWSが落ちてちょっとサイトが繋がらないっすって見た時にエンジニアは割とまあそういう時あるよねみたいな寛容さがあるような気がするんですけど。
そうですね、そうっすね。
だってそれどうしようもないじゃんみたいな気持ちはもちろんマルチクラウドにしてとかあるけどいやそんなにコストかけられるんでしょとか現実的なところがあるでしょ分かってたりするっていうのもあるから。
そういう寛容なラインっていうのは今どこにあるのかなっていうのをちょっと思ったりも同時に考えちゃいます。
なんかサービスが落ちる落ちないみたいな話だけどね、やっぱりAWSさんに頼ってる以上はみたいな感じで思っちゃいますけど。
じゃあ例えば今まさにすごい誰かを傷つけてしまったりとかめちゃくちゃ経済的に損失を生むようなバグだったりデータの整合だったりっていうのが本番寛容にもう入っちゃって動いてますってなった時になんかロールバックをしようとした瞬間にいやなんかクラウドフレア側とかAWS側とかって言い訳は多分できない訳じゃないですか。
そうですね。
どういう落ち方だよみたいな気はするんですけど、S3だけ使えてダイナモDBが落ちてるせいでコードビルド走らんとかデプロイができないみたいなやつとかなと。
そうですね。
なんか嫌だな、想像して嫌になっちゃったな。それでも言い訳してる場合ではもちろんないので。
データセンターに駆けつけてキーボード繋いでどうにかしたいよな。
そうですね。まずデータセンターに入れないみたいなね、障害が起きてデータセンターに入れないみたいな話が昔ありましたけど、斧持ってきて開けるみたいな話を読んだ気がするけど、あれはデーマだったみたいな話もあったんで。
本当かどうかはよく分かってないですけど、そういう状況はありますよね。
09:00
ちょっと関連してですけど、この有害の章の中に緊急っていうことが緊急ってのは何だろうかっていう話が出てきて、なんでそういう話が出てくるかというと、ソフトウェアっていうのは大事なのは振る舞いの価値とソフトである柔軟に変更できるってことが大事なんだっていう話があって、緊急状の除き全ての状況において優先されるべき価値はソフトである。
構造が変えられるっていうことが大事なんだよって。緊急ってのは何かっていうと会社が一般あたり1000万ドルの損失をしているとか、経済的損失とか人命とかいうところが緊急に当たりますよって話をしていて、
ここの辺の判断とかは結構やっぱり現場でどうにか判断しなきゃいけないタイミングっていうのは何かしら来ると思うので、常に考えとかないといけないなって思いながら、一方でちょっとこれ急ぎなんでとかってよく言われるけど、その時の緊急性って大した緊急じゃないっていうことが、
それはもちろん明日テレビCも打つんで、明日まで行こうってプロレスされてないといけないですとか、そういうのは多分緊急だと思うんですよね、お金がかかってるとかあるから。そうじゃない時っていうのはほとんど緊急じゃないよねっていうのが書かれていて、他の人の引用があって、ソフトウェアに関して言えば急ぐことは割に合わないっていうのもあって、
いろいろなことを考えとかないといけないけど、一方で緊急じゃない時のこともちゃんと考えとかないといけないなっていうのをちょっと思いましたね。
なんかそれとちょっと目線が違う話ですけど、あれでしたね、振る舞いの価値と構造の価値みたいな話が出てきてましたね。
そうですね。
どこだっけな。で、なんかそこら辺はグッドニュースファクトリーでケントペック行ってたなみたいなことを思い出せながら。
そうなんですよね。だから結局ソフトウェアってものの大事なところって何なんだろうなって思うと、柔軟さであり振る舞いの価値もそうであるけども、もちろんそうなんだけども、柔軟さであり柔軟が故にどんどん変わっていくからバグが埋め込まれたりしてぶっ壊れることがあるっていう、難しいですね。
いい面でもあるんだけどそれが取り替えになってしまうっていうこともありみたいな。
ソフトウェア、柔軟さって難しいっすもんね、結局。
そうなんですよね。
じゃあ全部のパラメーターをコンテキストっていうクラスにして何でも突っ込めるようにしましょうみたいなこと言うと、とっても柔軟とは思うんですけど。
そうなんですよね。
そういう話じゃねえんだよなみたいな。
12:00
柔軟だから、それは素早く変更できる、安全に変更できるって意味での柔軟さはなくて、コード、メソッドっていう世界では柔軟かもしれないけど、人間が硬直しとるぞその目の前でみたいな気がした。
リードタイムって見ると全然それ柔軟じゃないでしょってなるいますよね、そのコンテキストインターネットのやつ。結局何やったらいいんだっけっていう。
あとはじゃあユーザーにSQLを書かせたら柔軟ですかみたいなこともあると思ってたんですよね。
好きなようにデータを取りたいんだったらユーザーにSQLを書かせたらええやんみたいな感じになると、見ちゃいけないデータが出てきたりとか。
遅いクリックして実際回ってるとかも起きるけど、そういうことじゃないよね。てかそもそもゼロから考えないといけないの辛すぎるよね。
ある程度の秩序だった構造みたいなものはやっぱ必要だし、何でもできるっていうのはそれだけでは価値にならない。むしろできない制約が多いからこそできることが際立って来る前の価値になっていくような気がしますね。
プログラミングと一緒ですね。さっき話してた。
そうまさにこの章で構造化プログラミングっていうのが出てきて、構造化プログラミング言語っていうレイヤーで構造化がサポートされる、それが使われるようになるっていうのは、
本来はいろんなことができたカオスな世界に秩序をもたらしてるって話なんで、秩序ってやっぱ不自由じゃないですか。
できないことを増やしてるなーっていう感じはあり、だから嫌いかっていうと全くそんなことないんですけど。
そうなんですよね。
なんかそういうことだよなーみたいなことを思ったりしますね。
なので有害な行動、有害な行動、有害な行動やめましょう。
13、14章を一気にさらってみますか。
そうですね。すごいパンチカードの写真が出てくる。パンチカードの話はないって言ったけど。
最近のパンチカードっぽいものやりたいなと思って。
無限にテープを食べるチューリングがくられてしまう。
いやでも、ハードディスクの容量が有限なんで。ハードディスク使ってねーけどなしばらく。
家にあるけど。
それはさておき。まあそうですね。なんか誠実の部分見てると、バージョン管理の話とか出てきて。
ここ超昔話なんですよね。
そうそう。誠実ってよりは単純にソースコードの昔話が来たなって思いながら読んでましたね。
15:01
確かに。なんでこれ誠実になるんですっけ。
そうなんですよね。改善するぞっていう約束の中に、誓いの中に、作品を改善しますように、劣化させることはないですよって言ったときに、
そのバックグラウンドにあるテクニックというか、みたいなものはバージョン管理とか多数で変更するとだいたい競合するけど、
それをどうやって解決していくんだっけ。なんなら解決してきたんだっけっていうような話ですかね。
そうですね。バージョン管理があって、継続デッキレプロイメントとか継続的ビルドっていう話があって、要素ない改善っていうのが話として出てきて。
誠実?
誠実場で繋がるか?あと2歩ぐらい届いてない気がするんだよね。
高速改善、改善をし続けるとか、生産性を高く保つみたいな話をしてるショーではあるんですけどね。
そうですね。
誠実、そうね。
サボってないぐらいな。サボってないぞ、俺はベストを尽くしてるんだっていう話ですかね。っていう意味で誠実なのかな。
あれはありますよね。常に使える状態、準備万端にしておくっていうのは大事だよね。
それはプロフェッショナルとしてもちろん大事で、要するに来週まで待ってくれれば動くものが用意できるんでみたいな話をするんじゃなくて、
常に動くようにしておくみたいな話があって、そこら辺が誠実って話だよねって言うんだったら小さなサイクルとか、
継続的デプロイメントとか、常に改善し続ける、要するにソフトサーバーを保ち続けるみたいなのは繋がってくる気はするけど、本当にそういうことか。
役のクオリティは高いと思うんですよね。翻訳者はめちゃくちゃ信頼してるんで。
ちゃんと選んで誠実って言葉を使ってるはずです。
ちゃんと読み返せばここが誠実に繋がるネタというか仕掛けというか、真意はわかる気はするんですけど。
一旦それはそれとして、僕どこだっけな、この章でいいなと思ったのが、高い生産性を維持するって話が出てくるんですよね。
18:10
そこの中で効率化とか、ちゃんとしっかり意味のあるテストを書いて使っていきましょうとか、無駄なミーティングを減らしましょうとかって話が出てくるんですけど、その流れの中の一つで気分っていう話があって、
めちゃくちゃ人間味があっていいなーって思ったんですけど、例えば大切な人と喧嘩した後に行動をかけるだろうか。IDにランダムな文字列を入力することならできるかもしれない。
だがそれも続かない。あまり関係のなさそうなミーティングに参加したりして切算的なフリをすることになるだろう。
って書いてあって、IDにランダムな文字列を入力することの意味はよくわからないんですけど、仕事してるフリか。そういう場合に無理やり自分の気分をごまかしてどうにか集中しようってするんじゃなくて、
ちゃんとその友達に電話をかけてごめんなさいして問題解決しようっていうふうなことが書いてあって、なんかいいですよねこの小学校の道徳レベルの話でもありつつ。
結局動いているのがこっち、人間なので、そういうところも含めてしっかり生産性を高くしましょう。そのための工夫というか振る舞いだったりしていこうぜ、ちゃんと気をつけていこうぜっていうことを語ってるなと思って。
なんかいいなーって思いますね。
そうですね、なんかテクニックとかっていうところばっかり行くわけではなく、ちゃんと感情っていうものも大事だよねっていう話が出てくるのは、一見見落としそうなんですよね。なんかこういうのって別にこの本で書かなくてもいいでしょっていうふうにもできるだろうし。
けどまぁ、やる気こそ全てじゃないけど、人間の方はやっぱ気分乗らないと仕事できないですからね本当に。ずっとモヤモヤ抱えたまんまやりづらいですからね。
体調管理をしっかりしましょうとかって話にもつながってくると思うし、あとあれなんすよね、あれサイトなくなっちゃったかな、ボボウジさんのサイトに行くとずっと体測計をやってる動画が背景で流れてて。
なるほど。
なんかしっかり集中力とか健康とかを意識してらっしゃるんだろうなーみたいな気持ちになったり。
21:02
あとはあれかな、僕がこの本読んで好きだなーと思ったのは、不老状態みたいなものに入るのやめろっていうふうに書いてあって。
あんまりこういう言い方してる本ないと思うんで、不老状態に入って書かれたコードをその翌日とかに見てみると、なんか理解できない酷いコードがあったりしたんで、考え物だよねーっていうようなことを言ってますね。
普通は不老状態にどうやって入るかっていう話をしてる本がいっぱいありますからね。
そうなんですよね。
でも、そうなんだよな。その時はコンテキストをいっぱい詰めて、お、お、お、って感じでいい感じに書けてるぞってなるけど、後で見ると辛いし、確かにあるからな。
ガッと集中しないとわかんないコードは辛いですからね。集中しなくても読めるようなコードの方がありがたい。
だからね、ある程度負荷をかけながらやっていくみたいな話をしてて、例えばペアプロとかって個々人の不老状態に入らないと思うので、いいよーとかっていう話をしてますね。
まあそんなとこですか。14章13章他なんかありますか。
そうですね、自分はないかな。大丈夫ですね。
あとはあれか、この本に関して役者跡書きも良かったですね。
そうなんです。役者跡書きめっちゃいいと思いました。
役者跡書きの中でクリーンクラフトマンシップっていうのが説というかいう風に出ていて、どんどんどんどんソフトウェアっていうものは影響力を増していて、書き出しエンジニアは5年で倍になっていく。
この本の解決策はシンプルで、伝えるべきことは既に決まっているため、過去の著作のエッセンスをまとめ、その内容を繰り返すというものであるっていう風に書いてあって。
役者自身もなんかこの話どっかで聞いたなとか、またこの話かっていうのもあるんだけど、何度も何度も大事なことっていうのは伝える必要があって、
増えていく書き出しのエンジニアに対して、この本を読んでもらって学習して、よりよく働き精査性を高め、自分が書いたものに誇りを持ったようなエンジニアを増やしていきましょうっていうようなところが書いてあって、すごいいいなと思いましたね。
あとこれね、過去の著作から大事なことが抜粋されてまとめられているため、大変お得なパッケージにもなっている。創集編のような気持ちで読むのがちょうどいいって書いてあって。
やっぱりそうなんだなーみたいな感じがしてるとか。
24:01
そんなに厚くないですもんね。
そうですね。
僕の今のウィンドウサイズだと451ページってなってて、結構あるなって思ったんですけど、そんなになかった。
320ページだから、人によってはちょっと厚いって感じるかもしれないけど、ソースコードが多いっていうのもあるし、全部が全部そんな文字ぎっしりで読むような本ではないので、
ページ数が多いからといって必ずしも読むのがすごい大変かって言われると、全然そんなことはないかなという気はしましたね。
あと本当にロバ都市町の方一冊でも読んだことがある人だったら、似たようなクリーンシリーズで何かそれ読んだことがある人だったら、これはあの本で言ってたあれだなーみたいな感じのところはスルスルっと読んじゃっていいと思いますしね。
そうですね。
これあと、あれな役者と書き、おなじみのボーリングゲームのコードが短くなっていたりって言収されてて、言われてみればそうかもしれない。ちょっと笑ってしまう。
そういう細かいところに気づいてるな。まあね、訳してたらそれ気づくんだろうけど、なんか目のつけどころがそういうところなんだなって思いながら。
さすがですよね。だって一番研究している人じゃないですか、この人。
あとまたこの話かと思われた方はおそらく十分に偉そうになっているだろうっていうのは、その前のくだりから触れてるやつか。
隣にいる見習いに本書を渡してあげてほしい。またその時に自分の経験やトークンについても語ってあげるといいだろうっていうふうに書いてあって。
このように同会全体として見習いを受け入れ、トークとゲームを続けていけば社会的責任を果たせるソフトウェア開発者が育っていくだろう、そうなることを願っているって、めっちゃ綺麗な役者と書きの締め方。
超かっこいいなって。
しかもこれがより大事だねっていう時代になってきたっていうのもあるので、よりこの本の大事さみたいなところは価値が上がってるんじゃないかなっていうふうに思ったりもしますね。
そうですね、そうですね。たぶん上がり続けるだろうしな。
そうですね、この前行くと。
コードを書くのが簡単になっちゃってるんでやっぱり。
難しくなることはAIが禁止されない限りは多分ないんで。
AIが禁止されたとって多分プログラミング言語時代はどんどん日費が低い方にいくと思うんで。
27:04
あるとしたらそんなのわざわざコードを書かないでノーコードでやればいいじゃんという領域が増えてしまった場合か。
まあでもそんなところですかね。
全体通して加えたいこととかあります?でも割と話した気がするんだよな。
おかしいなこんなに話すと思ってなかったんだよな。
確かに。
あとはやっぱり結局今前からずっと読んできて最後倫理だったり大事とかその書き出しに全案に渡してあげたいよねっていうところで。
結局気持ち悪くなってもしょうがないので実際コードを書く技術とかリファクタリングするとかテストをちゃんと書くとか。
いうのが一周回って大事さっていうのがよくわかる本だなっていうのが感じられるようにできていてすごいいいなって思いました。
あとなんか弟子を取りましょうみたいなことを言ってますよね?どっかで。
冷静の話ありましたね。職人技術を思い出すような。
弟子とは言ってないんです。メンターになろうって言ってたのか。
メンタリングの章が14の後ろとかにあったっけ。
あそこらへんは11章かなメンタリング。
先輩社員は新人プログラマーに対して指導する教えるという任務を果たさなければならないと。
先輩社員はこれを読んで若者にこの本渡して読んでこいと。
いろいろ教えてあげましょうというところですかね。
人に教えるとやっぱり強くなりますからね教えてる側も。
そうです。
勇気はするけど全然今の職場ではそんなこと全くしてないからわかんないですね。
スメンティーを探しに行くか。
そんなところですかね。
僕も読んでみた感想としては後書きにあったように結構今まで別のところでボボおじさん自身が言ってたりとか他の人が
とりわけケントベックバーチャファウラあたりが言ってたことがよくたくさん出てくる本だなと思ったんですけど
やっぱりすごいパンチラインみたいなものがちらほら出てくるんで
そこらへんはすごい刺さったり面白がったりできて
っていう一冊だったなぁみたいな感想ですかね。
30:03
じゃあおしまいにしますか。
2時間いかないんじゃねえとか言ってた気がするんだけどな。
この週も放送を聞いていただきありがとうございます。ではまた次回さよなら。
