00:03
きんじょうひでき
次、進みますか。PART3、第3部が費用予測なんですけど、ここが多分一番ピンときづらい。なかなか難しい。
げんえい
そうですね。第3部は今まで作ってきたモデルを使いながら、費用を考えましょうっていう感じですかね。
きんじょうひでき
そうですね。強いて言うと、プロジェクトとかソフトウェアのライフサイクルみたいなところの話が、それは第4部でも出てくるか。
げんえい
どこにフォーカスして話すかっていうので、たぶん第3部が費用、コストのところで、第4部が品質になるのかなみたいなふうに自分は読んでましたね。
きんじょうひでき
そうですね。でもそれにしても第4部は難しいなと思うんですけど、みんな大好き人月のシーンは人と月は交換できないみたいな話が結構出てくるのはこのPARTですね。
げんえい
そうですね。
10人突っ込んだからって10人月が1ヶ月になるわけではないみたいな。結構だから人を増やしていくとコミュニケーションパスが増えるみたいな意味でのインタラクションですね、相互作用にかかってくる費用っていうのがあるよねとか。
きんじょうひでき
あと結構個人的に思ったのが、何でしたっけ?機能を削減すると費用面にどのくらいの効果をもたらし得るかみたいな話があって、なるほどなーっていう気がしたりしましたね。
ゲインさん、PART3話したいことありますか?
げんえい
PART3はね、びっくりするくらい話したいなって思うことなかったんですよね。
これはなんでかなと思ったら、プロジェクトのお財布を自分が握ってないからだと思うんですよね、まずは。
きんじょうひでき
そうですね。それは同じ感覚ですね。
げんえい
結局、我々はある種お金の話はまあまあって言われて、お財布握ってて人を増やしたりとか減らしたりとかっていうことを自分は直接的にあんまりやってないし、
例えばここに100万あるから100万で速いマシンを買って生産性を上げようみたいな話とかもやったことがないので、
でなると私が外注をどうするかみたいな話とか、そういうところも自分が主導して何かをするみたいなところはやっぱりなかったりするんで、
費用モデルと言われてもなぁみたいな感じがすごくして、あんまりしゃべっても5分というか、まあ言ってでもそれやったことないんですけどね、しかなんないから。
03:10
きんじょうひでき
そういう表面的な話しかできなそうだなぁみたいな。
パート3、本当にこの本通して命題というかチャレンジしようとしているのは、どういうふうにプロジェクトを動かしていったり、あるいはその計画っていうのを立てていったときに、
どの変数がどういうふうにとある側面に跳ね返ってくるかみたいな話をしていて、じゃあ例えばプロジェクト運営とかソフトウェアプロダクトをデリバリ完成させるみたいなところまでの一連の流れの中で、
何をやったらどういうふうに費用が上がるんだっけっていうのをモデル化しましょうとか、例によって測定して結果をちゃんと経験データベースに残して使っていきましょうよみたいな話とか、
じゃあ実際のいろんな企業とか大学の研究とかで、どういう話、費用とプロジェクトに関してどういう話がされてるんだっけなぁみたいな話がたくさん載っている部ですね。
で、我々はピンときてないと。
げんえい
実際のプロジェクトからちゃんと調査をして、この成果まで乗っけてるっていうのはほんとすごいですよね。
こういう机上の計論で、こうやったらできるでしょみたいな感じっていうよりは、実際にちゃんと論文にまとめて、それが成果として出ているっていうところまでやってるので、
気合の入り方が全然違うなぁみたいな気持ちになりますね。
きんじょうひでき
そうですね。まあ、そんなとこですかね、パート3。
げんえい
そうですね。
きんじょうひでき
で、じゃあ最後の第4部いきます。結局いつもと同じくらい話してるのかな。
げんえい
いや、今回こんな喋れるのかなぁとか思ってたんですけどね。
きんじょうひでき
今回でも本の中身に触れてない率高めな気がしますね。
げんえい
そうですね。やっぱり現代とちょっと違いすぎるから。
きんじょうひでき
そうですね。逆に言うと、せっかく読んだんだから書いてある内容を話すっていうよりかは、
じゃあこの時代にこの本を読むことにどんな意味があるのかみたいな話をしてる方が、僕は好きなんだよっていうめっちゃ言い訳臭いですけど。
げんえい
いや、俺読書会でいつも本の内容じゃなくて本から連想してる話しかしないんだよな。
会社の読書会とかもそうなんですよ。
だって読んできたでしょ。
書いてあるじゃん。
きんじょうひでき
でも第4部のソフトウェア品質ですね。
ここは2人とも反応が復活してる感じがあり。
06:01
げんえい
そうですね。第3部寝ててここから起きちゃうのかなみたいなクライマックスだけ、
映画の終盤だけ見てる人みたいなガチっぽい感じになっちゃったけど。
きんじょうひでき
それで言うと、第3部は僕はリアルに打とうとしてました。
げんえい
そうですね。
きんじょうひでき
第4部はどうでした?原映さん的な見どころとか。そもそもどんな話がされてるかなとか。
げんえい
そうですね。第4部は面白いなと思ったのは、
ここは品質の話をしているんですけど、
その中で、なんで品質の話が出てくるかっていうと、
ソフトウェア作っても不具合の購入が多かったら時間と費用はとてもかかってしまうので、
品質も大事だよねっていうところであって、
ちょっと面白いなと思ったのが、
20章のソフトウェア品質管理の章があるんですけど、
またここでヒタチが出てくるっていうのは面白いなと思っていて、
毎回出てきますね。
きんじょうひでき
ヒタチ2回目ですよね、出てきたんですか。
げんえい
そうですね。
デマルコーイに語るでも出てきて、
きんじょうひでき
この本でもどっかで出てきてましたよね。
例の人が出てきてた気がする。
げんえい
すいません。
出てきて、235ページ、ちゃんとページ数書いてありますね。
ところで、品質の話をするときに、今はあんまり言わないですけど、
昔で言うと、構造業数あたり、
だいたいどれくらい不具合が埋まってるかみたいな話っていましたよね。
きんじょうひでき
バグ密度みたいなやつですよね。
多分、アクセラレータ本でも触れられて、
4K時にはもちろん入ってないんですけど、
げんえい
あった気がしますね。調査対象になってた気がしますね。
その話がここでも出てきていて、
専業あたりにどれくらいの欠陥があるかみたいな話があって、
アメリカの平均が10から50欠陥がありますよと。専業あたり。
で、中央製造会社の社内目標っていうのは、
だいたい専業あたり0.4らしいんですよね。目標値。
さらにそこの比較として、日本っていうのが言及があって、
専業あたり0.2らしいんですよね、日本は。
だから日本ってめちゃくちゃ品質、
欠陥とかバグがあることを品質が高い、低いっていう
09:00
げんえい
限定した言い方での品質を見ると、
日本ってめっちゃ品質高いんだなっていうのはちょっとこれを読んでて、
びっくりしたというか、だから品質と結局、
その後業界で勝ち残るかどうかっていうのは全然関係ないんだなっていうこととかを思ったりしました。
それは日立がどうのこうのとかっていうよりは、
単純にアメリカはビッグテックがいっぱい生まれたよね、この後はっていうことですね。
きんじょうひでき
そうですね、じゃあなんでこの日本とか、もしくは日立とかが、
っていうのがそんなに欠陥派生の率が低いのかみたいな話も出てきてますね。
あれは言ってましたね、アメリカの企業はそもそも真剣に
欠陥数みたいなの測ってないけど、日立はちゃんとやってたよみたいな話が載ってましたかね。
欠陥数を意識しましょうっていうモラル、開発者の意欲というか、
げんえい
意識か、みたいなところに結構寄ってる部分もあるよねみたいな話も出てきたりとかしてたと思うんですけど、
きんじょうひでき
その後の章に計測しようとすると、可視化しようとすると可視化されることを嫌がって、
ごまかすようになるみたいな話も出た気がするから、あれ一瞬で矛盾してないって思ったんですけど。
日立の話がまた出てきたし、あとあれですね、デマルコを入れ方で失敗例としてちょっと紹介されちゃってた、
これから何個バグが見つかるだろうか埋まってるだろうかっていうのを、
現時点で発見されている機関の数から予測することが可能であるみたいなモデルの話がまた出てきてましたね。
げんえい
そうですね。これちなみにやりたいですか?バグ密度みたいな。今現在の我々は。
きんじょうひでき
バグ密度を使うとしたらリファクターしなきゃいけない場所がどこにあるか。
で見つける。要するにミミッチ負荷がめちゃくちゃ高いか、事前条件事後条件が全然曖昧になってしまっているっていうリスクが高い行動がそこにあるので、
だからエラートラッキングツール入れて、アブネイクラスとか大体どの会社にもあるじゃないですか。
げんえい
はいはい、ゴッドクラスみたいですね。
きんじょうひでき
ゴッドなのかエルなのかわからないですね。やべえやつがいるよねっていうのを定量的に出すことができるはずなので。
げんえい
うん、確かに確かに。
きんじょうひでき
複雑度とかで出してもいいんですけど、ただ複雑であってもエラーを起こしてないとかユーザーから見えるような不具合を出してないんだったら、
12:07
きんじょうひでき
それはね、触らないうちはたたりのない紙クラスということで、放棄を行くこともできるんですけど、
エラートラッキングツールとか、要するにリアルワールドでエラー、欠陥に繋がっちゃってる。
故障に繋がっちゃってるっていうのは、どうにかしないといけないよねっていう説得力を一定持つので、
だからバグが多いクラスは潰すみたいなのはやり打ちはあるかなって聞いてますね。
げんえい
うん、確かにな。
なんか自分はそのアプローチじゃなくて、なんかそのアプローチないな、引き出しになかったなって今話を聞きながら思っていて、
なんか似たような問題に謳歌するときはやっぱ複雑度と、あとこのファイルのコミット回数みたいなものを可視化して、
つまりいっぱい手が入ってるってことは要求が変わっている可能性が高いのと、
不害が頻繁に起きているからいっぱい直されている可能性が高いっていうふうな仮説を持って可視化して、
じゃあこのファイルってのはいっぱい変更が入っていて、入っているっていうことは複雑度も高いってことはきっと危ないんだなみたいなのを思いながら、
要注意としてあげるかなみたいな感じで、自分はやるかなってちょっと思ったりしましたね。
きんじょうひでき
そうですね、Gitのメトリクスはかなり面白いなっていう気がしますね。
ソフトウェアアーキテクチャメトリクスとかっていう本でも、Git系のメトリクスこんなに面白いよって書いてあった気がして。
あったけど済んだままだな。
あれ面白いし、一章ずつが独立してるんで、タイトル気になったとこ見てみるといいかもしれないですね。
げんえい
確かに。
きんじょうひでき
なんだっけ、GQM、GM2かな、面白かったんで。
げんえい
ゴールフェッションメトリクス。
はい、そういうやつ。
きんじょうひでき
おんさんにめちゃくちゃ好きな人がいると思うのでそっちの方に聞いてください。
あとは、本の話に戻ると。
げんえい
自分はこれ読んでて、元も子もないことを言うなみたいなのがあって。
244ページで同時になってるやつであって。
結局品質を上げるみたいなところとかの話をするときに、腕の劣る人を一人グループから外しなさいと。
腕の良い人を一人増員するよりも生産性が上がることがよくあるって書いてあって。
それはでも確かにそうな気がするんだよなって直感と合うなと思ったりとかして。
15:00
げんえい
残酷なんだがまぁそうなんだよなぁみたいなことを思ったりとか。
でも一方でその人の能力が多分足りないのは、もちろん研鑽を積まないから足りないっていう話でもあるかもしれないけど。
例えば経験が浅かったりとかする場合に、この人は今後経験を積んで上達してもらわないといけない。
それは会社で言えばば勝手にあるのかもしれないし。
業界全体で見たときには、例えば協力会社の若い人かもしれないし、もっと成長の伸びしろがある人かもしれないし。
そういう人にどうにかチャンスみたいなものがあると理想的だよなってちょっと読みながら思ったりとかしてましたね。
きんじょうひでき
244ページは僕も付箋が貼ってありますね。
経験が浅い人だとしたら育てなきゃだよねっていうのもある一方で、
同じページの続きの部分だと、実はよく欠陥を生み出しているベテランみたいなのも実はいるんじゃね?みたいな話を書いてますね。
経験が、歴が長いとかで、高度についてはよく知ってます。
自分でバグを、欠陥を埋め込むことはあるんだけど、高度についてよく知ってるから、バグってマース具合があります、欠陥がありますって言われたときに、直すのも実はその人早い。
だから管理者の覚えはいいみたいなことが書いてあって、立ち悪いなって。
げんえい
欠陥を生みやすい作業担当者は往々にして、結果の状況に際して都合で発揮する。経験豊富だからである。って書いてあって、嫌ですね。
正しいっちゃ正しいんですけどね。埋め込むことは良くないんだけど、修理系であるようなシステムにおいて、早く直せるっていうのは良いことでもあるっちゃあるんだけどね。
きんじょうひでき
その人がいなければ生まれなかったバグみたいな話かもしれないし、言われたらすぐ見つかるし見つければ直せるみたいな話と、そもそもそういうことがないように書けるっていうのは結構違う能力だったりしますよね。
そういうテストとかが得意な人は、コード書かせないでそっち側のチームに行かせたら全体クオリティ上がるやんみたいな話書いてあったのって、このパートでしたっけ?
げんえい
書いてありましたっけ?ちょっとそれ読み飛ばしてるかもってある。
きんじょうひでき
あったんですよ。苦手な人に苦手なことをやらせるのはナンセンスだぐらいのことが書いてあって、バグを直すのが得意な人はそういうことをするチームに置けばよかろうみたいなことが書いてありましたね、どっかで。
18:15
きんじょうひでき
ひどいこと言うなって思ったけど、まあそうだよねって思いつつ。
げんえい
まあでも得意なことをやって成果を出してもらっているのは、ある種人材配置という意味では正しいって言ったら正しいですからね、企業内においては。
きんじょうひでき
いや間違いなくそうなんですけどね。どっかに書いてあったはず。
品質向上のための、これも今だと直感に反するみたいな話で、コードを書く人とテストをする人っていうのを別々にしましょうみたいな話が書いてあったりしましたね。
げんえい
結果を無くすことにインセンティブを感じる人と結果を見つけることにインセンティブを感じる人っていうのってそもそも目標が違うんだから、一緒にするとバランスが悪くなる。
きんじょうひでき
開発者が私の書いたコードはバグがありませんっていう責務まで負っちゃうと、適当に見なかったふりをしちゃうこともできるので、そうじゃなくてテストをする人、欠陥が本当にないかっていうのを調みつぶしに調べる人っていうのは別々のプレイヤーにしましょうみたいな話があって、
関西みたいな話だなって思いながら、言われてみればそうなんですよね。今だと開発者テストとかがすごい普及してるんで、なかなかそう直感に反するんですけど。
げんえい
そうですよね。でもそこがもしかしたら、例えばですけど、ちょっとなんか違う視点で捉えたら、そうだよねっていう感じになるものがありそうな気がするな。
例えばですけど、ソフトウェア開発者の関心がソフトウェアをどう作るかっていうことしかない場合においては、もしかしたら要求を満たすことだったりとか、本質的に何が必要なのかみたいなところは、もしかしたら品質を気にかけてるような人。
こういう品質っていうのはバグっていうよりは、もうちょっと利用されるかどうかとか、どういうことをやったら顧客の要求を満たしていると言えるのかみたいなところを分離して責任を担保させるっていうことをやっていくといいのかなってちょっと思ったりとかしましたね。
きんじょうひでき
なんかね、目標設定とか、OKRとかKPIみたいな大きいレベルでもいいんですけど、そういうときもちゃんと矛盾した健全性を担保するような指標もセットで測定しましょうみたいな話もありますよね。
21:05
げんえい
そうですね。
きんじょうひでき
コンバージョン数が目標ですって言って、チャンレートを80%とかでしたらどうしようもないので。
げんえい
なんか勝手にアカウント作られてましたぐらい勢いが。
きんじょうひでき
例は違いやろってなりましたからね。
げんえい
そうそう。
きんじょうひでき
だったらLTVOチームとユーザスのGrowthOチーム、獲得Oチームっていうのを別で立てて、いい意味で緊張関係を構築した方が全体的な健全なんじゃないかみたいな。
げんえい
そうですね。
きんじょうひでき
パート4なんかおかけになったところありますか?
げんえい
あとはあれですね。
欠陥データの取扱いみたいなところで、いろいろこの人がこのバグを発生させたみたいなデータとかを取るっていったときに、ちゃんと取扱いは気をつけましょうねみたいなところがあって。
個人別に収集するデータは個人の利益のためだけに利用できるものであるって話が書いてあって、これとか今だったらチームの課題だよねっていう風な見せ方をすると思うんですけど、
仮にあなたちょっと負が多いっすよっていうときは、みんなの前で言わずにちゃんとライベートなところで言うようにした方がいいよねとかっていうのはちょっと読みながら思ったりしましたね。
きんじょうひでき
これでもなかなか胃が痛い局面ですよね。
げんえい
そうですね。
きんじょうひでき
今だとコードレビューとかで指摘してあげることはできるんでしょうけど、指摘が積もり積もると結構重い気持ちになりますからね、言われる方も。
げんえい
そうですね。プルリクエスト作ってコメントがずらーっと並んでるPRの横にずっとLGTMって書かれて撮ってるやつとかあると、なんで俺だけこんなに読めるんだろうなって絶対思っちゃうよなっていう。
しかもその中のコメントによってさらにいろいろ辛くなるものもあるだろうし、あっちは盛り上がって楽しそうにしてるなって思うようなPRとそうじゃないPRが並ぶわけなんで。
きんじょうひでき
この本にも書いてあるんですけど、欠陥ですね。この本は一貫してバグとか不具合とか言わないで欠陥という言葉を使いますって書いてあるんですけど、ソフトウェアの欠陥は技術的な問題というより社会学的な問題であるっていう風に第20章が240ページから始まっていて、
これ何かっていうと、1個良くないコードっていうのがあった時に、その良くないコードっていうのをパッチ当てて直しましたで終わりにするんじゃなくて、なんでこれが未然に防がれなかったのかとか、そういうコーディングが生まれちゃったんだろうかっていう。
24:08
きんじょうひでき
そのコードを生ませた力学、感想とか社会学的な背景っていうのは何なのかっていうところをちゃんと見直さないと、要するに1個欠陥が生まれたってことは、欠陥を生み出すシステムっていうのがそのチームの中にあるんだから、
結果を生み出すシステム自体っていうのをちゃんと観察して見つけて潰していかないと、お前はずっと結果を生み出し続けるぞみたいな話があるから、ちゃんとやっていこうねみたいな話も書いてますね。
げんえい
そうですね、現代、ちょっと欠陥からすると大げさかもしれないけど、ある種ポストモーティングとかはね、今多分みんな結構やっている会社も多いと思うんですけど、そういうところとかは、じゃあもう1回繰り返さないためにどういうことをやる、どういう対策を根本原因を潰すためにどういうことをやりますかみたいなこととかは、現代においてはやられてたりしますね。
これがトヨタとかだとファイブホワイトというか、なぜなぜ分析になったりとかするんですかね。
きんじょうひでき
あとは、そもそもバグが生まれ込まない、欠陥が生まれないようにしましょうみたいな話が、この本だと欠陥の自制、自らを制御するっていう自制ですね。欠陥の自制っていう風に書いてますけど、
前もって欠陥が入り込まないようにしていこうよみたいな話で言うと、Tワダさんの予防に勝る防御なしっていう話を、ちょっと違うわ違うんですけど、なんとなく想起したりとか、
曖昧な可能性が爆発しているコードを書くんじゃなくて、一個型宣言つけたりとか、PHPスタンで単純なストリングじゃなくて、
対応できる文字列っていうのを列挙してあげたら、当然バグは減るよねみたいな。それで、欠陥がどうしたら頑張って潰せるかなじゃなくて、そもそも欠陥を作れない状況にしてしまうみたいな話に繋がるので、
げんえい
Tワダさんの話に関連して、あのスライドの中でも出てたんですけど、プログラマーが知るべき90なこと。できてはならぬことを禁じるのではなく、初めからできていいことだけをできるようにするみたいな。
間違った使い方をしづらくするみたいなところの話とか、ああいうのとかって結構大事ですよね本当に。
きんじょうひでき
そうですね。そういう登壇をしているので、100%アグリーでございますね。
27:02
げんえい
結局そこがなんていうか、ある種設計の腕の見せ所みたいなところでもあったりするわけですよね。
きんじょうひでき
単純な話で言うと、型宣言しましょうとか、イミュータブルなクラス変えましょうとかもそうなんですけど、ローカル変数の寿命を縮めましょうとか、やたらプロパティの多いクラスは分割しましょうとか、そこら辺に必然的に上がってくると思うので。
げんえい
そうですね。完全コンストラクターにしましょうとか。
きんじょうひでき
そうですね。だからそこら辺を考えていくと、さっき言ってた腕の悪い人を削るのが一番コスパがいい。
げんえい
そうですね。そうなんだよな。やめとこう。
あやしくなったんで、閉じていきますか。
ちなみに一応この21章のソフトウェア品質の改善のところの最後がコーディング机上演習っていう風になってます。
さっきのフレッチのやつですね。
付け止めでコードを書いてみましょうみたいなのをやってるみたいですね。
きんじょうひでき
同じものを書かせて、設計させて、その設計に従って開発させてみたいな。
同じものとも限らないのかな。
でも交換してオフェースとリフェースそれぞれやらせてみたいな。
そうですね。
なんかこれ、普通にワークショップ的に遊びとしてやったら面白そうだなみたいな。
げんえい
昔似たようなことをやったことあって、近いかどうかちょっと微妙ですけど、
きんじょうひでき
workshopとして作ってみました。
ショップ的に遊びでやったら面白そうだなみたいな
げんえい
昔似たようなことやったことあって
似たようなこと近いかとかちょっと微妙ですけど
名前が出てこねえ
マーチン・ファーラーとかがいる会社
きんじょうひでき
ソートワークス
げんえい
ソートワークスの本で
自販機の設計をしましょうみたいな
練習問題である本があって
その本自体は全般のアーティストに手に入らなかったから
ネット上にその本でこういうお題があって
これをオブジェクト思考で設計してみましょう
みたいな練習問題みたいなのがあって
きんじょうひでき
オブジェクト思考エクササイズ
げんえい
それですそれです
それを会社でみんなでやってみて
どういうふうに設計して
どういうふうにコードに落としてやっていきましたか
みたいなのをやったことがあって
参加者はペチパーペチパー
スイフトエンジニア
30:01
げんえい
IOSエンジニアだったんで
みんなで書いたものを見比べて
なんかここがうまく書けなかった
ここちょっと迷ったんだよねとか
PHPで書くとそう書くので
スイフトだとこうなんだよねみたいな
そういうようなことはやりましたね
前
きんじょうひでき
あれですよね
elseを使わないとかそういうやつですよね
げんえい
そうそうそう
みたいなことを
前やったなーっていうのをちょっと今
これを読んで
ちょっと思い出したって感じです
きんじょうひでき
あれ面白いですけどね
面白いんですけど
なんかあれを初めて触れて嬉しくなった人が
コードレビューの時に
オブジェクト思考エクササイズで
課されたギブスをはめようとしてきて
いやあれはエクササイズって言うだけだって
げんえい
芸術だから
きんじょうひでき
やつがね
インディント2つ3つぐらいならいいよ
げんえい
みたいな
そんな難しい制約の中でやってるわけじゃないんで
みたいな
きんじょうひでき
まあまあまあね
2分禁止っていうリストバンドつけてる人たちも
世の中にはいるんで
げんえい
まあそうですね
そういう感じのこぼれ話
きんじょうひでき
まあ止めていきますか
げんえい
はい
きんじょうひでき
なんかだいぶ話したな
げんえい
だいぶ話したんですけど
きんじょうひでき
どうですか全体的になんか
何かお勧めしたい人とか
こういう気持ちで読んで欲しいみたいなのとか
とかとかあります
改めて全体的な何かまとめめいたもの
げんえい
とめめいたものはそうですね
まあなんか
この本読んでピンとくる人って
あんまいないんだろうなっていう気がするので
まずお勧めはしないかなっていう気持ちになりました
なんかもっと多分読みやすい本とか
とっつけやすい本って多分いっぱいあるだろうから
きんじょうひでき
これじゃないよなみたいな気持ちになりましたね
ああそれで言うと
僕なんか思ってたより読みづらくなかったなっていう気がして
そうですね
なんかマルチパラダイムデザインとかよりかは
読みやすいかもしれない
いやどうかなぐらいの感じで読んだんですけど
多分あんまり具体のところには着目しすぎないで
げんえい
半分ぐらいで読み流した部分結構多くて
きんじょうひでき
ただなんか結構まあもちろん一通り目は通して
でどういうふうに銘答したかっていうと
なんか今でも通じそうだなとか
マーチンファーマーチンファラじゃないや
友田丸子が他の著作で言ってたようなこと
っていうものに通ずるようなところとか
彼のスタンスっていうのを誤答して読めるような
誤答してるなっていうふうに読めるようなところとかっていうのを
ちょっと意識的に拾いながら
自分の脳内で解釈かけながら読んだんですけど
33:02
きんじょうひでき
そういう読み方したせいで
あんまり苦しみすぎずに済んだのかなっていう気は
ちょっとしたかもしれないですね
ちょっとまあなんか想像力がいりますね
この時代のパラダイムのプログラミングやったこともないし
デプロいってギター部でボタン1個押せばすぐあれのことですよねみたいな
甘やかさでゆとり世代なので
げんえい
いやわかんないですね
コンパイルってなんすかみたいな気持ちで生きてるから
きんじょうひでき
それはそれはPHP使ってるからなんですけど
げんえい
まあそうですねまあでも結局まあでも背景
人もパンチカードがありアセンブラーがありみたいな構造化プログラミングが出てきて
みたいな歴史的背景はいろいろこう知っておかないと
ちょっと読むのは辛いかなっていう気持ちはあったりとか
さっき近所さんがトムネマルコっていう人を通して読んでるから
辛さがないって言ってたので
逆に言うとトムネマルコにあんまり親しみがないとか
トムネマルコを全部読もうみたいな気概がない人が多分読むと
なんか思ったより面白くないなみたいな気持ちになるのかなっていう気もしますね
きんじょうひでき
そうですねなんか初手でこれを読んで真に受けるぐらいだったらそうだな
まあまあそれだったらエリック・エバースの本とか読んだ方がいいんじゃないみたいな気持ち
げんえい
みんな好きらしいしみたいな
きんじょうひでき
そうそうそう
エリック・エバースの本に比べたらこっち読んでる人は少ないんじゃないみたいな気がしちゃうので
げんえい
そうですねまあ普通に本屋で買えないですからね今これ本はもう
きんじょうひでき
中古じゃないとかじゃないと思うんで
げんえい
大学のね図書館とかだったらあるかもしれないですけど
そうですね
だからね調べないで言ってるんで
いやまあ下手すると廃棄になってる可能性もありますね
もう読まんやろっつって
きんじょうひでき
まあでもそんなとこですかねトム・デュマーコ氏の
デュマーコでしたっけ
げんえい
トム・デュマーコ
きんじょうひでき
ソフトウェア開発プロジェクト技法を読んだわけですけど
でじゃあ次の本がデュマルコシリーズラストですかね
翻訳された本だけでいいんですよね
げんえい
いや翻訳された本だけでいいと思うんですよ
きんじょうひでき
次が構造化分析とシステム仕様っていう本ですね
あれ94年ですか出版
げんえい
これは今手元にある本の奥づけを見ていると
86年が一般位置ずりって書いてあって
94年は真相になってからの位置ずり
一般位置ずりだそうです
きんじょうひでき
なるほどゲイジンさんは真相じゃない方を持ってる
げんえい
いやこれ多分真相の位置ずり
一般の旧ずりですね
2007年にすられてますね
36:02
きんじょうひでき
最近だな
げんえい
結構最近ですね
きんじょうひでき
大丈夫だ僕も真相版ですね
じゃあ大丈夫ですね
げんえい
ちなみにオビはオブジェクト志向
もうここから始まったって書いてありますね
きんじょうひでき
じゃあなんか出る話
げんえい
出る話がきっと書かれていて
そんなに難しい可能性はあるかもしれないけど
なんかニッチもサッチもいかないっていうか
突きづらいのはないんじゃないかなと
勝手に期待しております
きんじょうひでき
まあボリュームですよね一番怖いの
げんえい
そうですねそうですね
ちょい分厚めですもんね
全部で400ページぐらいですねだいたい
きんじょうひでき
まあそんなところですかね
げんえい
じゃあおしまいにしていきますか
きんじょうひでき
はいじゃあまた例のあれを読んで
終わりにしていきたいと思います
今週も放送をお聞きいただきありがとうございます
ではまた次回さよなら
げんえい
さよなら
