00:04
げんえい
先生講義で、金城さん、何か次、どうか、こう喋りたいのはあります?
きんじょうひでき
えーっと、どうしよっかな。難しいんですよね。なんかほぼほぼ全部喋りたいっちゃ喋りたくなってしまい。
げんえい
そう。
きんじょうひでき
まあでも16かな、16章。
はい。
16章がどういう章かっていうところから最初に、そういうというか、複数していくと、もうこれね、章のタイトルからいいというか、殺傷力の高いタイトルしていて、曖昧な仕様書っていう第16章ですね。
げんえい
果たしてそれは仕様書なんですか?
きんじょうひでき
で、曖昧な仕様書っていう章で、ちらちらページめくっていくと、なんかですね、章の下のタイの説で、理解できない仕様書っていう説が出てきたりして、なんかもう、もう残り1ポイントゼロですやめてくださいみたいな気持ちになってきつつ。
で、そっか、トムキースの日記を見れば、この章が何の話してるかわかるのか。
16章で出てくるトムキースの日記の1つは、1つの章に何回か出てくるうちの曖昧な仕様書に関して書いてあるのは、箇条書きで3つ書いてあって、1点目が、仕様書が曖昧なのはシステムの利害関係者の枝で対立が関係されている印である。
2つ目が、入出力の完全なリストのない仕様書は見込みなしである。仕様を明確にする最初の一歩にもならない。で、3つ目が、仕様書がお粗末だとは誰も言わない。自分の方が悪いものだと思い込みがちであるっていうふうに書いてあって。
これなんか読み上げながら、2つ目めちゃくちゃ口悪いですね。これ笑ってしまった。見込みなしとか最初の一歩にもならないとか。これは仕事で使えない表現だな。
げんえい
なんかすごい嫌なことでも過去にあったのかなって聞きたくなるぐらいには酷いようですね。
きんじょうひでき
めちゃくちゃキレてます。トムネマルコ代理でトムキースガチギレおじさんになってるんですけど。
で、3つ目の仕様書がお粗末だとは誰も言わない。自分の方が悪いものだと思い込みがちであるみたいなのはさっきまさに話でですね。
いやこの実装が仕様書通りなんで変更とか良くないですよみたいな話とか。
げんえい
でも俺過去仕様書これ、なっとらんやんけってめちゃくちゃ口言いながら実装したことあるなって思ったりとかしたので。
ちょっとここは自分の方が悪いってこと全然思ったことないから。あれ俺知らないのかなって思っちゃった。
きんじょうひでき
まあね、悪い仕様書、悪いドキュメントマジであるからな。
エラージにはXMLでエラーコードっていう要素を含んだドキュメントを返しますって書いてあるのに、
03:06
きんじょうひでき
500インターナルサーバーアパッチ2.0って書いてあるHTML返ってきたりとか。マジでお前っていう。
げんえい
いい話ですね。
きんじょうひでき
この16章をピッチしたのが、ゲインさんが女優メモに書いてくれてるインプットとアウトプットが書かれてない仕様書は意味がないとか。
ここらへん少し掘り下げて話したいなとか思った次第でございます。
げんえい
そうですね、自分が大学の授業でコンピューターの授業を受けた時に、
コンピューターの本質っていうのはインプットがあって処理があってアウトプットのこの3つからなってるんだよってことをすごく教授に言われることがあって、
中小化して考えるとたったそれだけかって思っちゃうんですよね。
きんじょうひでき
そう、なんか関数とかね、何かを入れたら何かを返してくれる箱ですみたいなそういう例ですよね、多分。
げんえい
で、なってる中ですよ、これが本質だとしたらインプットとアウトプットの安全なリストがない仕様書ってコンピューターに何やらせたいのってことが何にもわからないっていうことなんで、
いやもうボロクと言いたくなる気持ちもなんとなくわかるなってちょっと思いましたね。
つまり自分の目の前に仕事をさせたいものがあるのに本質がわからず適当な指示しかできない状態になってるって、
それはもうなんかどうしようもないよねっていう気持ちにはわかるっていう感じでしたね。
きんじょうひでき
でもそういうなんかね、このインプットがどこからもたらされてその人に対して何を返せばいいのかみたいな話、
本当にUSKスズみたいなアプターがいて、フっていう矢印があって、そこ矢印受けた人がどこに何を返してますかみたいな、
まあUSKスズだとリターンとかないかもしれないですけど、なんか結構そういうイメージ、システムとかサービスってアクターがいてね、
何か受け取ってサービスして返すみたいな、そういう世界観だよなとかっていうのを源井さんの目も見ながら思ったりとか、
そうするとなんかドームルール、ドーム手順とかドメインとかっていうのをちゃんと理解して、
どういう風にユーザーとか利用者が動いてるのかなみたいな話を、イベントストーミングとかってそういう感じだと思うんですけど、
なんかすごい自分の中ではちょっと繋がったというか、使いたい人が何を求めるからどういう入力をして何を返すのか、
その一部がたまたまプログラムに書き換わっただけかみたいな捉え方でいうと、
じゃあ何を置き換えたんですかっていうのを書いてくれるのが要求定義の文章とか、
実際何をやりますっていう仕様書とか、なんかそういう話なのかなって思ったりとかしましたね。
06:05
げんえい
要求分析して仕様を書くような人っていうのは、そういうことが念頭にありながら深掘りができないと結構大変だよなって思ったりとかして、
そうすると、世の中いろんなPDMとかディレクターとかPOとか、ある種要件をステークホルダーと交渉して要求を取りまとめて、
開発チームに仕様を丸投げするって言い方をするとあれなんですけど、開発チームと協調しながらソフトウェアを作っていく、
ソフトウェアプロダクトを作っていくってなった時に、システムのこと分かんないと結構しんどそうだなって思ったりとかして、
自分たちは今ソフトウェアエンジニアで、コンピューターがどういうことかっていうのをそれなりに勉強して理解している中で、
チップとして踏んでいってPDMとかになったら、中身わかるし楽はある程度できるけど、そうじゃない人って結構この辺ってどう捉えているのかなとか、
どうやって勉強するのかとか、どういう投げかけをしてあげると、こっちの話がもうちょっと深く理解ができて、
いい要求仕様だったりとか書けるのかなってちょっと思ったりとかもしちゃいますね。
きんじょうひでき
そうですね。難しいですよ。だからドメインエキスパート、大理コタクとかそういう人に対して要求を語らせる、述べさせるっていうのをうまくやってほしい。
だからシステムのこと分かってないと厳しいよねみたいな感覚はめちゃくちゃ分かるなって思いつつ、
ただ、プログラマー上がりのPDMとかだと楽にビジネスのことを専門家と同じぐらいの解像度で分かってないとみたいなプレッシャーもあるはずで、
いやー大変ですよね。板挟み、板挟まれ職人としては大変なポジションだなーみたいな。
げんえい
だからまあ本来的には別にそこを一人に孤立させずに強調すればいいとは思うんですけど、強調強調で今度また難しい問題もありますからね、相性の問題だったりとか、
エンジニアはやたら実装書材のことしか関心がなかったりとか、なんかそこのプレイヤーが一人増えるだけでやっぱり伝言ゲームが始まるわけだし。
きんじょうひでき
そうですね、だから自分自身で高い解像度を持って、まあいい、十分な水準の、まあ仕様でもない要求でもいいんですけど、
吐き出すことができるみたいなスキルか、もしくは必要な人から十分な情報を引き出すためのファシリテーションスキルみたいな、そっち側の道もありかなーっていう気がしつつ、
09:03
きんじょうひでき
いやー全部大変そうって思ったんですけど、やっぱり自分がプログラマーなので、プログラミング以外は全部大変そうって思ったんですけど、プログラミングですらこんな難しいのに。
げんえい
そうなんですよ、そうなんですよ。一個一個の専門性はそして高いっていう。だからこそ、現代においてこう、なんていうんですかね、高度なことをやっているとみなされているっていうことはあるんだろうなって思いながら。
あとなんかこの辺のこの仕様、特に仕様の方、要求というより仕様の、まあ要求もそうかもしれないとかはやっぱなんか最近そのちょっと前の回でもブロッコリーさんの名前を出しましたけど、ブロッコリーさんとかを見るとやっぱQAエンジニアっていうのは結局何を担保しないといけないかとか、
まずソフトウェアがどう動いていることの正しさと、あと本来的にやりたいこと、要はユースケースみたいなところから仕様を担保して考えていくみたいなことを思ったときに、コンピューターをブラックボックスとして見れる立場の人でもあると思うんで、そう考えるとインプットとアウトプットにフォーカスをしながら上手に仕様を考えるっていうことがもしかしたらできるんじゃないかなっていうのもちょっと自分は思ったりとかしましたね。
きんじょうひでき
なるほどなぁ、そうQAのフィールドの専門家もまた非常に難しそうだなぁって印象が僕はすごいあるので、いやぁみんな大変そうですね、ただまぁそうかリセットするフィールドに関する知識は、もしかしたら自分が使いたいと思っているところの知識とか理解度はあったほうがいいなぁっていう気はするのはなんか、
あれじゃないですか、美味しいコーヒー飲みたいなぁっていう時にどういうコーヒーが飲みたいのかっていうのを自分で語れないとやっぱり最高のものって出ないなぁとか、自分の知らないものが欲しいっていう時にもね、自分の知識が必要になってきたりとかしますもんね。
僕は飲食店とか行ってワインの名前見ても何もわかんないなぁって思いながら、上から頼むかみたいな感じになっちゃうんですけど、だから非常に要求定義をする立場としては非常にまずい状態なんですよね。
システムのことがわからないから、システムというかワインのことがわからないからこういうワインが欲しい、それによってこれを実現したいみたいなことがわかんないから出せない、表現できない、コミュニケーションができない、よくわかんないワインが高い、終わったみたいな感じになっちゃいますね。
げんえい
確かにシステムを作ると、こんなにするのとかって多分みんな思ったりするだろうし、相場感もわからなかったりとかするだろうし、ワインもそんな感じあるなぁと思いながら、私はお酒飲まないので全然わかんないんですけど。
12:00
きんじょうひでき
じゃあまた次の話に行きますか。いかがですか、ゲイジさんは。
げんえい
えーと、そうですね、19章行きますか。プロジェクトの人数の話。これでそうですね。
きんじょうひでき
プロジェクトの人数っていう章のタイトルですね。
げんえい
これはなんかこの章がこういうこと話してますっていうことではなく、章のタイトルがプロジェクトの人数になっていて。
きんじょうひでき
何も抽象化せずにこういう名刺がそれでしたね。
げんえい
この日記の方を見ると、初期に人数が多すぎるとプロジェクトは重要な設計作業を省略せざるを得ない。
設計には2人しか必要ないんだけど、人は10人いるので、余ってる人に仕事をさせるために仕事を割り当てないといけなくなって、結果実装を始めてしまったりとかして、設計がおぞまりになっちゃうよっていう話があったりとか。
そういうことをしていると、人を増やしていくと依存性、相互のコミュニケーションパスが増えて会議が増えたりとか。
あれなんか違ったって言ってやり直しが増えたりするんで、プロジェクトの人数っていうのは大きい場合ほどいいというわけではないですよっていう話だったりしますね。
きんじょうひでき
これね、この章でしたっけ、喜べあと200人使えるようにしたぞみたいな。だから納期を短くしてやるみたいなすごいウォーキングボンビーみたいなことを。
しょっちゅうそういうことを言われてる小説なんですけど。
あとあれがありますよね、人を余らせてしまってはいけない、暇にさせてしまうとごめんなさい感があるみたいなプレッシャーもありますもんね。
げんえい
そうですね、俺は仕事をする必要があると言われて呼ばれてきたのに、仕事はないですって言われたら、え、なんでってなりますね。
きんじょうひでき
マジでなんかね、腹詰めとに直結しますからね、それをやられた側の立場というか気持ちを想像すると。
げんえい
時と場合によっては今のフェーズでいらないんですよってなっちゃって、やることないですねって言って、そういう人が社員で評価みたいなものがあったときに、やることないんで何もしてませんでしたって言ったら、
多分その人評価されないとかっていうことがあるんで、意図的に仕事は与えなかったのかみたいなことに取られたら結構問題になっちゃいます。
きんじょうひでき
いや、めちゃくちゃ問題ですよね。じゃあそういう人にも手を動かしてもらうために仕事を無理矢理作りましょうってなると、プロジェクトが失敗して頑張って仕事を作った側がこの評価落ちるみたいな。
あなたのプロジェクトマネジメントは10点みたいな。合格点には全然達しませんでしたみたいなね。
15:03
げんえい
人を集めてきたよってアサインした奴はどうなるんだみたいな感じになってきますよね。
そういう人は頑張って人を連れてきたんで評価しますみたいなことになってると、なんかおかしなことが起きてるねっていう。
きんじょうひでき
そうなんですよね。それぞれの立場を想像するとやっぱり悪意を持ってる人いないなみたいな。
げんえい
そうなんですよ。
きんじょうひでき
結局悪いのは社会みたいな。
でもねそれは本当に部分最適の罠ってそういうところですよね。
げんえい
そうですね。
きんじょうひでき
最初にリードアーキテクトみたいな人、もしくは本当にリードデザインチーム、デザインターの設計のチームを2,3人ぐらいでバーって組んで、
1ヶ月2ヶ月ぐらい時間を十分に活用してから、じゃあ手を動かす人を増やしましょうみたいな話は。
レッドライン、この本でもすごいわかりやすい線グラフとともに語られてたりもしますし、結構他の別の本でも言われちゃったなーとか思いながらしてましたね。
げんえい
あとはなんかこう、ちょっと違うんですけど連想して、イテレータブルとインクリメンタルは違うって話があるじゃないですか。
モナリザの絵を描くのに下から順番に上に描いていくのと、一回全体こんな感じになるよねってやってから、
じゃあ右手を上にするか左手を上にするかもう一回考えて描き直してとか、じゃあ色塗るとこんな感じ、全体はこんな感じです。
じゃああと細かいところを描いていきましょうねみたいなところで、少人数でいかに早くこのイテレータブルの最初の段階を作って、
そこがうまくいって、あと色塗るだけだよねぐらいまで来たらバッと手分けしてやるみたいな風に作れたら結構理想的だよなーって思ったりとかしましたね。
きんじょうひでき
人数がめちゃくちゃ増えてくると同時で分散的に作業をさせなきゃいけないよねっていうリソース効率って意味で圧力がかかっちゃって、
それで分かりやすい右手と左手と肩を切断して担当をつけてみたいな感じになっちゃって、全体の調和みたいなものがすごい失われるなーっていう感じがしますよね。
ただ逆に全体のバランスをとりながらインクリメンタルにやっていきましょうってなると、全体をみんなで見る。
逆に言うとそこを見てる人同士の同調コミュニケーションが必要になってくるので、
全体を視野に収めながらコミュニケーションを同時的に同期的にとる人数が、
18:05
きんじょうひでき
それが2人がいいんだっけ10人がいいんだっけっていうともうなんか明らかに10人破綻するやろみたいな感じがしますよね。
コミュニケーションパスは指数関数的に増えていくので。
げんえい
あとはそのコミュニケーションの話に行くと、ここにこの本ではコンウェイの法則って言葉は使ってないんですけど、
どういうふうに全体を切り分けますかみたいなところで、
切り分けたものの相互依存性を高くしてしまうと辛いよっていう話が書いてあって、
極力そこの相互依存性が低くなるように切り分けましょうねみたいな話も載ってて、
これって結局そこに対して人を当て込めていくとコンウェイの法則になっていくのかなって思ったりとかしながら読んでましたね。
きんじょうひでき
あとはね早すぎたバイクのサービス化とかありますからね。
結局三つ結合やんけみたいな。
影響がめっちゃこっちに流れ込んできますがみたいな。
げんえい
三つ同時にデプロイが必要で。
っていうところでこの章は知ってる知識もありながら、
現実やっぱりオムネマルコのこの小説の中でも最初に200人人がいたらプロジェクトがガーンと一気に進んで終わりますみたいな。
やっぱそんなことはないよねっていう気持ちになる章でしたね。
あとちょっと戻っちゃうんですけど、17章のセリフ僕めっちゃくちゃ好きなのがあって、
きんじょうひでき
それも掘りたいなって思ったんで。
17章のタイトルが対立解決の指導者っていう話で、
ざっくり言うとお互いにあいつなんか無茶苦茶なこと言ってるぞって思ってた同士がよくよく話をしてみると、
なるほどなんかやりたいこと同じじゃね?いい方法ありそうじゃね?みたいな和解するみたいなエピソードが書かれてるんですけど。
なんかここの章の中で出てくるセリフで結構好きなのが、ちょっと抜粋して読みますけど、
ここで重要なことは私たちはどちらもプロらしくない行動はしていないのだと理解することだ。
二人の間には現実に対立があり、その対立は尊重に値する。
それを水面下に潜らせてしまい、チームワークだとかプロ精神だとかいう会社の言葉で取り繕ってしまうと、難しいが不可能ではない対立解決の仕事が進まなくなってしまう。
21:00
きんじょうひでき
っていうようなことが書いてあって。
これ何個か注目したいポイントがあるんですけど、チームワークだとかプロ精神だとか会社の言葉で取り繕ってしまうと、
ここもまた電話録音めっちゃ切れてるなみたいな感じがすごい表面的なというか、
奇麗事としてのチームワークみたいなミスマナーズっぽい感じの話で取り繕っちゃうと、
なんとなくうまくいったね、よしよしこれでいいかみたいな雰囲気になってしまった時に、
本当に着目すべき要素とか根底にあるものっていうところの共有とか交換が行われない。
だから本質的な解決っていうのが本当はそこにできるチャンスが眠っていたのに、
何かプラらねえ偽善の言葉で取り繕ってしまったがゆえにできなくなったよね、みたいな話とか。
それぞれお互いのチームとかお互いの職種の人たちがちゃんとプロフェッショナルとして、
ちゃんと理想を掲げて会社のためにやるべきことをしっかり考えてやってるべきだっていう、
お互いにプロとして手抜きとかじゃなくて、ちゃんとやるべきことを考えているはずだっていう前提に立って考えてみたらいろいろと和解するというか、
高いレベルで統合していく余地っていうのがあるはずだぜみたいな話がこのセリフに込められてるかなと思ってて。
げんえい
そうですね、やっぱその辺とかが結局、じゃあなんでそこってちゃんとぶつかれないんだっけみたいな、
このノートでいうと書いてくれてる文でいくと健全なコンフリクトが起きないんだっけみたいなところで、
やっぱり無駄に対立したくないみたいな気持ちがあるっていうのは人としてはわかるというか、
ここで面倒なことになってもなみたいなこともわかる一方でやっぱりそういうところが、
友田丸子が社会学って呼んでるのはそういうことなのかなっていう気持ちにもなるなって思いますね。
きんじょうひでき
そうですね、社会性を優先ルール、プライオリティ範囲に設定して動くと、そのOSだと全てが社会性っていう言葉でイグロわされるみたいな。
げんえい
合理的に自分たちは判断してるんだって言い聞かせながら、合理的な判断をずっと繰り返した結果、
本来の目標が達成できなくて失敗に向かってしまうっていうことだと思うので、
なんでそれが合理的だと、ある種外から見たら本当はそれ合理的じゃないはずなのに、そこでコンフリクトしなかったんですかみたいなこととかって、
テクニックとかそういう問題ではないですよね。やっぱりそこには関係性の問題だったりとか、社会制度の問題だったりとか。
24:05
げんえい
やっぱりそっちの方がソフトウェア開発に向いては本質なんだっていうのが友田丸子が言ってることなので、そこってすごく分かるなぁみたいな気持ちになりますね。
きんじょうひでき
そうですよね。だからこのセリフの、その対立は尊重に値するってめっちゃ、これ僕が起業したらこれバリューに入れようって思いました。
げんえい
いいっすね。ちなみに、例えばうちの会社もコンフリクトを恐れないっていうのがバリューに入ってましたね。
きんじょうひでき
やっぱ恐れ、いや、もうちょい踏み込んだ方がいいんじゃないですか。怖くないよって言っているだけじゃなくて、好き好んでコンフリクトしたいわけではもちろんないんですけど。
コンフリクトチャンスやった、飛び込めみたいなぐらいになってくると。
げんえい
エンジニアすぐGitのコンフリクトだとかって、コンフリクト恐れないとかね、言ったりとかしますけど。
Gitのコンフリクトは恐れた方がいい。
でもやっぱその対立する状態っていうのはなんか共通の目標を持ってない場合に対立しちゃう可能性もあるし、持ってるのに対立してるんだったらすごくもったいないし。
きんじょうひでき
そうですね。
げんえい
なんか目的が違ってるんだったら、そもそもなんで我々違うとこ見てんだっけってことをやっぱ話した方がいいし。
きんじょうひでき
そうですね。
やっぱそこにはプロダクトやビジネスがうまくいくチャンスがどっかには眠ってる気配じゃあ気配なんですよね。
コンフリクトっていうのを種にして、これは何でだっけっていうのをちゃんと振り返って観察していくことで、やっぱり資産は上がっていくはずですよね。
げんえい
そうですね。
その時にちゃんと事に向かうような組織だったりチームになってないと、結局あいつが悪いってことになっちゃうんで、そこはやっぱり前提として自分たちはこういう価値観にあるよねとか、普段から気をつけておかないといけない。
そういう時になった時にはガス抜きにならないようにしないといけないとかね。そういうのもありますね。
きんじょうひでき
そうなんですよね。あいつらは間違ってる、あいつらはバカだみたいな気持ちで見ちゃうと対話の余地ってどんどん失われていくので、そこら辺が私たちはどちらもプロらしくない行動はしていないのだと理解する。相手を尊重する信頼するみたいな。
こんな変なことを正気な状態でこんなバカな判断をあの人がするわけないだろう。きっと何かがあるはずだみたいな風に考えるといいんじゃないかなって思いますけどね。
げんえい
そうですね。いい言葉ですね。
27:00
きんじょうひでき
いい言葉ですね。っていう17章でした。
げんえい
そして気づいたらもう2時間ぐらい経ってるんですね。
きんじょうひでき
いやネットライン結構鬼門かなって思ってるんですけど話すボリュームがいつまで減るんじゃないかみたいな思ってたんですけど、割りかし飛ばし気味に来てこの時間ですね。
げんえい
そうですね。いや俺下手したら1時間で終わるかなとかって思ったんですけど。
きんじょうひでき
そうなんですよ。そうなんですよ。まあでも数1更新2週分十分じゃね。週2更新するなんて誰も言ってないぞって思いながら望んだんですけど、完全に週2更新ですねこれ。
げんえい
そろそろ終わりクローズに向けていった方がいいのかなって思いながら。
きんじょうひでき
あとはそうですね今のが19章で全部で23章なのでどっか触れたいところあります。23章のメモに僕はストックホルム症候群って書いてあるんですけどこれはちょっと小説読んだ人はなるほどこれのことかって思ってもらえればいいかなぐらいで。
げんえい
そうですねまあ23章が最後で101の教訓の中で、101の教訓っていうタイトルなんですけど、自分が一番この本で学んだことはあの出されたよくわからない布物は手をつけてはいけないっていうことを一番学びましたねっていうところですかね。
きんじょうひでき
エピローグみたいな感じですもんね。
げんえい
そうですねこれ23話のエピローグです。
きんじょうひでき
じゃあ全体を読んでみましたっていうところで少し改めて感想とかこんな人にお勧めしたいなぁみたいな話とかありますか。
げんえい
そうですね全体振り返ってまあある種これ一冊読むとプロジェクト管理の難しさみたいなところとか読みやすいので非常にとっかかりやすくていいかなみたいな思ったりとかあと人月の神話とかってあの本もすごく有名だけどもやっぱちょっと読みづらさだったりとかちょっと古さだったりとか
書いてある本質は別に古くないと思うんですけどあの出た時代が古いのでなんか今の人が読んでもピンとこないみたいなところがもしかしてあるかもしれないんで
そういう意味では人月の神話よりは実はデッドラインを読んだ方がいいんじゃないのかなっていうのをなんか今日全体通してしゃべってきて思ったりとかをしました。
きんじょうひでき
なるほどなるほどそうですね僕も小説でビジネス的な特訓を摂取することのキラキラ枝みたいなのは結構人によって分かれるかなっていうところもありつつではあるんですけど
読みやすいというかなんて言うんですかね
まあ今でいう異世界転生者みたいなもんですからね
異世界転生者なんですよね目が覚めたらなんか
30:02
きんじょうひでき
国家プロジェクトにアサインされてたけんで
まあまあまあそうですね何て言おうとしたんだっけ
なんかそう割となんか普通のビジネス書とか論文とかだと結構
ここの文章表現がよくわからないな何を言ってるんだろう著作しないとってモードになりやすい人でも小説だと結構気軽に
なんか話の流れでふーんって感じで
まあ良くも悪くもスルーしながら読み進められると思うので
げんえい
そういう意味でもハードルは低いかもしれないですね
きんじょうひでき
だからそうですね冒頭で述べた通りちゃんと理解したぞっていう感覚がもしかしたら人によっては
感じづらいんじゃないかなっていうのは少し個人的には思ったりするところです
それは小説っていうフォーマットだから
ただデマルコの世界から好きな人だったら絶対に読んだほうが良い
ニヤニヤできる一冊でしたね
げんえい
プロジェクト管理がうまくいくかどうかはどうでもよくて
これはデマルコ無事だなとかこの文章の漢字はデマルコだなみたいなのを楽しむという
ちょっと高度な読み方が楽しんでおすすめですねっていうのは確かにありますね
きんじょうひでき
そうですねトムデマルコは一回も出てこないんですけど
ずっとトムデマルコ感じかないみたいな
あとね所々登場人物にガキ切れされててなんかちょっと口が悪いみたいな感じも楽しかったり
げんえい
うん
きんじょうひでき
まあでもそんなとこですかねこの本は
げんえい
そうですね
きんじょうひでき
はいじゃあ終わりに向かっていこうかと思いますが
次はじゃあ何を読みますか
げんえい
はい次はデマルコ大いに語るソフトウェア24のひらめきとさえっていう本ですね
きんじょうひでき
この本はもう表紙が抜群にいいですよね
げんえい
そうですね
きんじょうひでき
僕もさっきというか昨日ぐらいに知ったんですけど
なんか割と放題翻訳された本だとなんかこのデマルコ大いに語るソフトウェア24のひらめきとさえっていう
なんかなかなか何て言うんだろう
カジュアルな感じのタイトルですけど
なんかオリジナルのタイトルは全然そんなことなかった感があったりして
まあ何だっけな割と真面目なタイトルリストっていうところだけ
はい投入しておきます
げんえい
まあその辺も次回ちょっと深掘っていきますかタイトルが全然違うやんけとか
まあタイトルに込められた意図とかも多分いろいろあると思うので
きんじょうひでき
あーそうですねそうですね
現代が今パッと出てきたら紹介しておきたかったけど出てこないな
ホワイラズソフトウェアコストそうマッチっていうタイトルですね
33:04
げんえい
なぜソフトウェアそんな高いの
きんじょうひでき
が日本に入ってくるとデマルコ大いに語るになると
はいまあそんな感じで
じゃあ締めていきますか
はい
はいじゃあいつものアレを読みますね
げんえい
はい
きんじょうひでき
今週も放送をお聞きいただきありがとうございます
ではまた次回さよなら
げんえい
さよなら
