00:06
きんじょうひでき
こんにちは、readline.fmです。readline.fmはつんどくが趣味の2人が何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグはハッシュreadline.fmです。ホスト役は源永さんと金城です。
それでは、源永さん、よろしくお願いします。
げんえい
よろしくお願いします。
きんじょうひでき
はい、ということで、今回はトム・デ・マルコの新しい本ですね。
げんえい
新しい。
きんじょうひでき
新しい本というと語彙がある。次の本で、品質と生産性を重視したソフトウェア開発プロジェクト技法
見積り設計テストの効果的な構造化っていう本ですね。新しい本、1982年発売みたいな。
げんえい
めちゃくちゃ古くて生まれてないみたいな、こういう世界ですね。
きんじょうひでき
生まれてないですね。82年っていうとプログラミング言語的には、パイソンもまだないですよね、たぶん。
げんえい
ないですね。
きんじょうひでき
ましてや、ロームで使われてないだろうし。
げんえい
うん。まだたぶん全然パソコンっていう、パソコンじゃないか。パーソナルじゃないですよね、きっと。
確かに。
オフィスとかにでかいサーバーがあるみたいな、たぶんそういう、これは勝手なイメージですけど、そんな世界なんだろうなって思ってますね。
きんじょうひでき
そうですね。フロッピーディスクとかもでかい時代かな?3.5インチじゃない?
げんえい
じゃなくて、5インチでもない、下手するとたぶんもっとでかいとか、そんな世界がありそうな気がしますね。
きんじょうひでき
今、プログラミング言語年表って日本語のウィキペディアをちらっと見てるんですけど、そっか、1983年にCプラが命名されるって書いてますね。
おー。
で、83年がオブジェクティブC、84年がポストスクリプトですね。なるほど。
げんえい
もう、今となってオブジェクティブCを書いてる人はほとんどいないだろうし、ポストスクリプトももういないだろうっていう感じなので、だいぶ時代が昔って感じがやっぱしますね。
きんじょうひでき
そうですね。ポストスクリプトはあれですね、PDFになって生き残ってると思うんで。
げんえい
そうですね。
きんじょうひでき
なるほどなぁ。
げんえい
そういう時代に仕事をしていた人たちが、きっと本屋でこの本を買って読んでいるみたいなイメージですかね。
きんじょうひでき
そうですね。本当にオブジェクト思考っていうのがあるらしいぞって言われ始めたぐらいか、物好きって言うとあれかもしれないですけど、ちょっと尖った人たちが触っているぐらいなのかなぁ。
03:16
げんえい
うん。それぐらいな感じですね、多分今から見るとみたいな。
きんじょうひでき
まあでもそうか、そんな時代に働いてた人というか、プロジェクトとしてソフトウェア開発をしてた人たちの、どうやってたかみたいなところですね。
はい。
で、これはなんだろうなぁ、どこら辺から話していきましょうかね。なんか全体的にどんな本でしたっていう、いつものお決まりの入り方をしたいんですけど。
げんえい
そうですね。
きんじょうひでき
特徴としてはやっぱり、開発プロジェクト技法っていうのとあと構造化っていうところですかね。
げんえい
うんうんうん。
きんじょうひでき
これは多分まあ時代的には本当になんかプロジェクトうまくいかないねみたいなソフトウェアはなぜそんなに高いのかみたいなことを言われてた時代で、どうにかしてちょっと科学的にやれないか、工学的な意味でのちゃんと成功させる。
なんていうんだろう、行き当たりばったりの出たとこ運勝負みたいな開発やめて、ちゃんと何ヶ月かけて何ドルのコストでこれが出来上がりますみたいな、ちゃんとしたプロジェクト管理をどうにかできないかみたいなところに挑んでいるっていうような、何ですかね、パッションなのかミッションなのかをちょっと感じながらやってたので、
だからそうか構造化って言ってるのが多分あれですよね。職人的な技芸的な技じゃなくて、イメージとしては本当に数式で表せるようなものにどうにか一般化できないかみたいな、公式みたいな作れないかなみたいな感じのニュアンスっていうのがあれですかね。
伝わりやすいのかな、わかんないですけど、なんか僕はそんなイメージをちょっと感じたりしましたね。
げんえい
でもそこはやっぱ自分も全く同じで、やっぱりソフトウェア開発のプロジェクトがあまりにも失敗しすぎる。で、これをじゃあ誰かが上手いことやっているではなくて、今後この業界が大きくなっていくためにも誰がやってもある程度は同じような成功をしていくようなフレームワークというか考え方だったりとか
みたいなものを探求するために、こういう方法どうですかっていう提案みたいなものをしていくぞっていうような本なんだろうなっていうふうに思いながら読みましたね。
06:07
げんえい
そうですね。で、前回読んだデマルコ大井に語るの前に出版されている本なんですよね。だからデマルコ大井に語るに書かれていた内容がちょっとネタバレっぽいというか。
きんじょうひでき
なんか実はあっちでいやそんなうまくいかなかったやんみたいな、デマルコ自身が語っているのが、なんかこの本だと実は最近だとここに注目している可能性を感じているみたいなスタンスで取り上げられてたりとか、なかなかそういう意味でもちょっとね面白かったなぁとか思いながらっていう感じですけど。
そうですね。なんか全体的に読んでみて感想とかいかがでした?面白いところありましたか?
げんえい
全体的に読んでて、思ったのは、こういう構造家だったりとかプロジェクト技法みたいなものを世に出したが、しかし現実のたぶん今我々?現実のって言ったらいい。
今日の我々はたぶんここに書いてあることなんて、全然知らずに普通に仕事をしていて、つまりこれって生き残ってないものであるので、なんでそういうものが生き残らなかったのかみたいなところをここで話せると面白いなって思いながら、なんでこれうまくいかなかったんだろうなって思いながらこの本を読むみたいな感じで読んでて、それがなんか自分の中ではすごい面白かったなって思いましたね。
きんじょうひでき
そうですね、簡単だとは言ってないがこんなに可能性があるみたいな。
トム・デ・マルコの考えた最長のプロジェクト計画技法みたいなのがある中で、最近どうしてますかっていうと相変わらず見積もりが計画が、費用が苦しんでいる時代は続いているので、じゃあそれって何でだっけなぁみたいなところはあったりするし、
僕も似たような感想ではあるんですけど、加えて言うとそれでもエッセンス一つ一つでは今の時代にも活かせそうなものを少し感じたりとか、
あとなんか、ブシブシにやっぱり最近のというか、今まで僕たちが読んできたトム・デ・マルコっていう人っぽい変臨は見かけたりするというか、動機づけ、モチベーションどうするかみたいな話とか、
あとまあ結構何だっけな、好きな表現が出てきたのは、技術的なものと政治的なものを分けて考えようみたいな話とかがまた出てきたりして、なんかそこら辺はトム・デ・マルコっぽい気がするけど、多分この後何かしらがあってピープルウェアを書いてるなみたいな感じはするみたいな。
09:20
げんえい
はい、そうですね。
きんじょうひでき
感じがありましたね。面白い、なんか学ぶものはやっぱりありそう。ちょっと時代背景とか古かったり、今とは全然違うよねみたいなところは多分あるんですけど、その中でもね、
今日の我々が読んで、何か感じるものとか学べるものとかがありそうだなみたいな、なんかそんな一冊でしたね。
げんえい
ちょっとこの余談というかに触れたいんですけど、たちにリスターさんの名前があったりとか。
きんじょうひでき
ああ、そうですね。
げんえい
これ読んでてすごい面白いなと思ったのは、トム・デ・マルコっていう表記ではなく、トム・ドゥ・マーコ氏ってなってて、なんか全然今までの訳と違うやんけみたいなと思って。
確かにこれは本の表紙でもカタカナ表記じゃなくて英語で表記してるんですよね。トム・デ・マルコ長って書いてあって、これは確かに検索で引っかからんわなっていう気持ちになりました。
きんじょうひでき
そうですね。トム・デ・マルコってカタカナで検索しても多分Amazon、正直引っかからないんですよね。
げんえい
そうですね。
きんじょうひでき
トム・ドゥ・マーコで調べたら引っかかるのかしら。
げんえい
いや、さすがに著者名のとこいないから引っかからないと思うんですけど。
きんじょうひでき
アルファベットというか、オリジナルの名前の表記で調べたらちゃんと引っかかるんで。
げんえい
この辺とかも結構はじめの方に紹介されたっていう感じなんだろうなみたいな定番訳がない中で、どういう表記するかみたいなところもない中で、全然知らないんですけど時代背景を。
海外ではこういうものがあるらしいっていうのを誰かが見つけてきて、この本を翻訳したのかなって思ったりとかしましたね。
きんじょうひでき
そうですね。87年ですもんね。
一昔、二昔前。
げんえい
多分、プロジェクトはこうやったらいいよみたいなノウハウが全然ない中で、海外ではこんなことをやってるらしいぞっていうので、頑張って探してきたみたいな。
きんじょうひでき
そうですね、そうですね。なるほどな。
げんえい
というわけで、じゃあ中に入っていきますか。
12:02
きんじょうひでき
そうですね。本題、本編に入っていきますか。
これ、まあそうか、アウトラインみたいなところだけ最初に共有しちゃうと、何部構成だっけ。
げんえい
4部構成ですね、全部で。
きんじょうひでき
4部構成ですね。
そうかそうか、付録があるのか。
第1部がソフトウェア開発過程における混乱と秩序っていう話をしていて、第2部がシステムのモデルとシステムの測定値っていう話をしていて、第3部が費用モデル、第4部がソフトウェア品質っていう話ですね。
第1部からじゃあ入っていきましょうか。
この本、一冊通してどんなところに課題を感じていて、何を解決していきたいんだっけみたいなところを出だしの第1部でやられていっているわけですけど、第1章の冒頭でいきなり特定できない事柄をコントロールするわけにはいかないっていきなりボールドで書かれてますね。
げんえい
これこないだ大井に語るでは、これは私の言葉だがって言って、トムデマルコが言ったことに話だったけど、調べるとドラッガーも言ってるらしいですね。
なんか時代的にはドラッガーの方が早そうだったんだけど、これはどっちが本当なのかみたいなのは、どう訳すかみたいな問題でもあるかもしれないんで、もしかしたらその原文の言葉はちょっと違うのかもしれないですけどね、2人とも。
きんじょうひでき
そうですね、あと言い回しが違うんでしょうね。
げんえい
うんうん、それもありそうですね。
きんじょうひでき
まあでも、少なくともこの本を丸々一冊通してこれは何かキーとなる概念というか前提みたいになってきますね。
げんえい
そうですね。
きんじょうひでき
プロジェクトっていうのがアンコントローラブル、大変だ、うまくいかないってお前ら言ってるけど、そもそも真面目に即答してるんかみたいな話をしてますね。
げんえい
ソフトウェアプロジェクトっていうのは基本的には失敗するもんだよみたいなぐらいな感じに捉えているので、じゃあこれをどうやって改善していきますかっていうのがこの本のテーマですよね。
きんじょうひでき
これ第一部でいうと何かどこら辺が源井さん的には面白かったですか?
げんえい
いやもう最初から面白くて、一番最初にまあじゃあ失敗してるって言うけどどれぐらい失敗してるんですかみたいな話をやっていて、
ソフトウェアプロジェクトの全数の15%にあたるプロジェクトは何も作り出せずに終わっている。つまり設定したプロジェクト目標全く達成できずに終わっていることって書いてあって、
15:07
げんえい
作り始めることすらできてないじゃんお前らみたいな、そんな皮肉というか、まあ現実相談だろうけどっていうところだったりとか、
あと100から200%も予定を超過するのはソフトウェアプロジェクトでは珍しくないことって書いてあって、本当に何も成功してないんだなっていう気持ちになりましたね。
きんじょうひでき
でそのちょっと下にあれですよね、なんかこの3条理由成功の敷地が緩すぎるみたいな。
なんか超過が30%超過っていうのはコストとかにスケジュールですね。30%しかオーバーしなかったから成功とかお前ら言ってるけどさみたいな。
あと想定してた期待してた利用者の4分の1ぐらいしか言ってないけど成功だよねみたいな話を君たちはしてるけどちょっと冷静に考えたらありえなくないみたいな話が書かれてますね。
げんえい
で結局それが大きい小さいっていう比較対象として建築工事だと6%も超過すると大変な失敗とみなされますって書いてあって。
まあ確かに6%に比べてさっきから100%200%とか30%とか15%とか言ってると全然ダメだねみたいな気持ちになってて。
本当にストステアのプロジェクトってこの本を書かなきゃいけないっていう動機だったりとかみたいなところっていうのはすごく伝わってくるなって思いましたね。
きんじょうひでき
そうですね。で第一章はその失敗とかあるいはコントロールできないコントロールするっていうのがそもそもどういう話なんだっけみたいなことが書かれている感じですね。
げんえい
そうですねそうですね。でなんでプロジェクトまず失敗するんですかっていうところで結構これ大事だなと思ったのがいろんな5ページのところですね。
きんじょうひでき
5ページですね。プロジェクトが失敗する原因っていう説がありますね。
げんえい
でまさにいろんな要因はあるんだけどプロジェクト要因に対する協力の動機づけだったりとか課題の十分な理解とか政治力とかあるんだけどもそのプロジェクトはにもかかわらず失敗してるっていう風な話があるんですけど
結局ほとんどの場合は当初の期待に沿わなかったんですよっていうのが失敗の原因でなっていてだんだんだんだん膨れ上がっていく崩壊な期待にその責任がある失敗する責任があるというようなことを言っていて
18:10
げんえい
多分これってソフトウェアっていうものがまだ目新しい時代においてなんかあれもできるらしいこれもできるらしいとか制約条件がまだわからない中でものを作っていってすごいものができるんだなみたいな期待値のコントロールとまではここには書いてないんだけども期待値のコントロールみたいなところにも失敗をしていて
その結果プロジェクトが思った通りにいかないっていうようなことが書いてあってこの辺とかもう本当に何て言うんですかねまあてが今でも起きてるよなって思いながら読んでましたね
きんじょうひでき
これの裏側にあれですよねアドレナリンジャンキーというところのニュースの改善技術的な可能ですって言ったら楽勝ですっていうふうに上層部のスタールみたいな話こういうことができるって上からできたのを現場の人はやる気に満ち溢れてすぐにでもやりたいと申してましたっていう返事になってるみたいな
っていうのがあって多分でそれが起きるのってやっぱりこの本の中だと測定とか定量化みたいなところが散々語られてますけど
なんかそういうところがあるからこそ良いように良いように取られていってしまっていいニュースと悪いニュースがあったはずなのにいいニュースしか生き残らないどころか強くなった良いニュースしか上に伝わっていかないみたいな
なんかそういうのがあってなんか本当にこのだんだん膨れ上がっていく方がいなきたいってわざわざボールドでこの本の中では書いてあるんですけどちょっとそういうイメージを僕は持ちながら読んでましたね
げんえい
いやなんか難しいですよね目の前に物がないからこそなんかあれできるんでしょみたいなことを言われたらいやそれできないんだけどなってこっちは思っててとか裏側でそれはもう無理っしょって思っててもなんかボタンを押したら時間とかかけずにビャッとこういい感じにグラフとか出してよみたいな
裏でどういう集計走ってるかわかってないけども横に未来予想の数値が出てきたらさこれ見ながら改善できるじゃんって出してよみたいなこととか言われかねないですからね
きんじょうひでき
見えないものはね難しい見えないしマインドセットじゃないですけど受け入れる側の頭の中で勝手にレコードされて素晴らしいものになっちゃうのでなんかなんかね僕がげんえさんに昨日めっちゃ美味しいラーメン食べたんですよすごかったですよみたいな話をした時にげんえさんはまさか金城が昨日食べたチキンラーメンの話をしてるとか思わないわけじゃないですか
21:13
げんえい
そうですね今めちゃくちゃ外食で1000円ちょっとするめちゃくちゃこうなんていうか美味いラーメンを食べたってイメージしてましたね
きんじょうひでき
そうですよね先月朝日香に行ってた男が美味しいラーメンとしてチキンラーメンみたいな話はイメージしないんですけどまあソフトウェア開発そういうところがあるんだろうなみたいな
魔法のような道具として見てしまうと期待が膨らんじゃいますよね
げんえい
今でさえみんなこうパソコンを持ったりとかまあマートフォンだったりとかこうデジタルの端末を持ってコンピューターを持っていろんなソフトウェアを扱っていても現代でもその期待値のずれみたいなのってめちゃくちゃ起きてるのでまあこれはなくならないんだろうなっていう気がしますね
きんじょうひでき
そうですね
そんな風にしてソフトウェア開発とかプロジェクトがなかなか成功しづらいものになっていくっていう話があってあと測定の重要性みたいな話をしていってますよね
げんえい
そうですね
この本で測定をしてコントロールしてうまくやっているっていうところの例として建築の業界の話がやっぱ出てきて
基本的にこれを見て見積もりをしていけばじゃあこれぐらいの規模感で人員はこれぐらいの規模感で人員はこれぐらいの規模感で人員はこれぐらいの規模感で
これぐらいの日数がかかるよねみたいな日数だったり時間だったりとかかかるよねっていうのがわかると
この青本は8ドル25セントも出せば買えるとなのでそう考えるとなんか別にすごい見積もりをするために100万かかりますみたいな世界ではなくて8ドルですよ8ドル
いやなんかこの収録始まる前にゲインさんとこの本4200円もしますねって言ってなかなかインパクトありますねって話をしてたのを思い出して8ドルくすやすいよなっていう気が
8ドル出せば誰でも見積もりができるようなもちろん本の読み方とかあると思うんですけどそれなりにその業界にいて人が8ドルも出せば見積もりができるような状態になっている業界とオフィステア業界っていうのは全然違う
24:15
げんえい
まさにこの8ドルでも払えば8ドル10ドル払えばうまくいくようなところをなんとなく目指してたのかなっていうのはちょっとここで感じましたね
きんじょうひでき
そうですね本当に例えばこのブルーブック青本の中にどんな項目がありますかみたいなちょっと表みたいなのも紹介されてるんですけど
例えば歩道の固定塗り100平方フィートあたりなんだ作業時間かまぁだいたい2,3時間でしょうとかなんか凹凸ですねデコボコの報酬にまぁだいたい2,3時間でしょうとか
グラインダー磨き普通仕上げ6時間みたいな作業の内容をまあそれの面積で本当に何時間ですねっていう話がされていてソフトウェア開発においても同じことができないかみたいな話で
構造化っていうのがこの本のサブタイにもついてるんですけどどこだっけなこの後に出てきますけどあれですよね分解できる最小の単位まで作業とか
モジュールみたいなものを分解していってモジュール同士のどういう繋がりがあるかインターフェースっていうのを定義してっていう風にやっていけばだんだんその複雑度とかモジュール自体のどのくらい難しいものなのか簡単なものなのかっていうのが分かるから
そういう本当に細かい細かい単位まで分解していって構造化していってあとは本当にめちゃくちゃ小さい単位なんでそこの青本みたいなものがあれば丸々データベースアクセスなんちゃらモジュールだいたい何時間かかるでしょみたいな単位まで分解していってしまえば
正確な予測が立てられるだろうみたいな本になっていってるわけですね
げんえい
そうですねそう考えるとガントチャートが引かれ未来でエクセルでガントチャートを引きなんとかここにアサインしてこうやっていけば絶対に見積もり通りに終わるはずだってなっていくわけですよね
まあしかししかししかし未来は点々みたいな感じですけど
きんじょうひでき
あとはあれか第一部そうですなんか見積もりと予測みたいな話がちょっと先進んじゃいますけど先進んじゃいますけどとか言ってどのくらい先進んでるんだ
27:03
きんじょうひでき
第4章か今ちょっと行ったり戻ったりはあるかもしれないですけどなんかですね予測と見積もりっていうのを明確にというか別のものとして扱っていて
予測っていう手段が使えないときに限って見積もりをやりましょうみたいな話をしてるんですよね
で見積もり予測っていうのは結構確実性の高いものっていうのを積み上げていきましょうで合計どのくらいですねみたいな話っていうニュアンスで予測っていう言葉を使っていて
見積もりはもうちょい曖昧だったり不確実性が高いもの要する幅があるようなものっていうのを
まあでもなんか数字出さないといけないよねみたいな時に見積もりっていうものを使うようにしましょうみたいな話をしていて
でもどこがこの構造化したまあなんちゃらモデル化したなんちゃらで目指しているのが結構この見積もりっていうところの領域を減らして
なるべく予測で戦える世界を広げていくみたいなチャレンジではあるんですよね
げんえい
この予測みたいなものが立つためにはまあ経験だったりとか経験ですかね一番
きんじょうひでき
経験ですねはい
げんえい
過去にやったことがあって似たようなプロジェクトをやって例えばまた毎度毎度こうLPを作っていて
過去まあ大体こう3ページのLPが1週間2週間で終わったから今回もページ数が大体3ページぐらいで
構成も大体同じでじゃあこれはまあ2週間ぐらいで終わるでしょうみたいな
そういうぐらいな確実さがないみたいな場合は多分この予測が使えるみたいな感じですよね
きんじょうひでき
そうですね結構この本の中で強烈な言い回しが出てきたなって思ったのが
許しがたい唯一の怠慢は過去の失敗から学ぶのを怠ることであるっていう風に書いてあって
許しがたい唯一の怠慢ってすげえなって思ったんですけど
まあだから過去にこういう作業をした時にこういう内容でしたでこのぐらい時間がかかりました
っていうちゃんとデータを貯めていかないとそれ予測可能なものなんて増えていくわけないじゃん
なんでそこをちゃんと記録していかないんだみたいな話で
まあ許しがたいな唯一の怠慢って言ってもいいぐらいのひどい失敗だなっていう風に
でわどこがおっしゃってるわけですね
げんえい
まあでもその辺ってやっぱこう出丸子の本で一貫しているなと思ってて
30:00
げんえい
えっと熊戸ワルツオとかでもリスクに対してどう立ち向かいますかって言って
こうちゃんとリスクをコントロールせよって言っていて
その難しいリスクをどう立ち向かいますかって言った時に
過去の他のプロジェクトを参考にして他のプロジェクトでどうだったかっていうことを
ちゃんと記録しておいてそれを用いながらリスクと対峙しましょうねって話が
あの本に書かれていたはずで
結局この過去の経験とかっていうものをずっと蓄積をしていかないと
ちゃんと使えないんだよっていう話をずっとしてたんだなっていうのを
この本を読みながらも思いましたね
きんじょうひでき
なんか一貫しているというか根底にあるところはすごい
昔というかこの本が書かれた80年代ぐらいのトムレ丸子も
本当に21世紀になってからのトムレ丸子も
通ずるものがあってすごいそこら辺は面白いですよね
連続で読んでいってよかったなみたいな
げんえい
トムレ丸子を批評を書こうと思ったら
絶対ここは外せるなみたいな感じになるなって思ってますね
きんじょうひでき
そうですね
あと予測とか経験とか測定結果の蓄積みたいなところで言うと
4の34ページからのところなんですけど
経験的予測に対する5つの反対意見みたいな話が書いてあって
5つの反対意見なんで5つ書いてあるんですけど
例えば1個目がデータがないあんな立派な青本がなければ
民族を押し出す政権の見積りがかりだってお手上げだろう
これが我々の現状なんだみたいな話とか
あと2つ目がデータを持っていたとしても
それと関連づけるものなど何もない
開発業務の規模を早い時期に測定する仕様として
何が使えるだろうかとか
あと3番目がソフトウェアシステムはみんな違うとか
4番目がデータが収束しない
許容限界が広すぎるものだから誰も結果を受け入れてくれないとか
5つ目が政治ですねいいですね
上層管理者は予測の数字が大きすぎるといって受け入れてくれないだろう
働き場地たちは無茶苦茶頑張らないとできない数字でないと仕事に打ち込まないだろう
見積もった仕事が達成可能なものであり
誰でもやればできる仕事だということになると
これは管理者担当者それぞれの立場にとって面白くないことになる
っていうことが書いてあって
1つ目だけめちゃくちゃ饒舌だ面白い
げんえい
そうですね自分交付箋貼ってますね
きんじょうひでき
これなんかもういいじゃないですか
トムデマルコのすべてみたいな
33:02
きんじょうひでき
プレッシャーで人は早くならんみたいな話とか
げんえい
そうですねそうですね
あと頑張らないのはつい目標がないからみたいな話とか
きんじょうひでき
見積もりはプロジェクトをうまく活かせるためじゃなくて
社内で合意を得るための道具なんだみたいな話とか
毎回聞くやつだなっていう気がします
げんえい
この辺ってあれじゃないですか
結局上層部への報告は悪いニュースは改ざんされるで
これ難しいから3ヶ月はかかりますね
どんなに頑張っても2ヶ月ですかねって気づいたら
2ヶ月もあればできるよとか
2ヶ月あれば余裕で1ヶ月には収まるんじゃないですかね
気づいたら全然違うみたいになってる
その方がみんな合理的?みんながハッピーになるんですよね
たぶんその報告を聞いた方が最後の作業者以外は
そうですね
これマコネルの見積もりの本
本を前なんかで紹介したんですけど
その本の中でも
作業者自身も見積もりをする時に
無能だと思われたくないから
自分ができるだろうって思う機会よりも
ちょっと短く伝えちゃうことがあるみたいな話があって
楽観的に見積もった方がみんなハッピー
作業者も俺は優秀だからこれぐらいかなって
本当はもうちょっとかかると思ってるかもしれないけど
これぐらいできたら俺すげーだろって言えるから
楽観的に見積もり
もっと短い功績をいった方が上に上がれば上がるほど
これはハッピーなことになっていくんで
みんなが楽観的に考えて最後失敗するみたいな話があって
大きい数字って得する人って
本当に手すまが嫌でとか
いろんな失敗を経験したから分かってる人は
大きい数字言いたいと思うんですけど
そうじゃない人にとっては小さい数字いった方が
実はみんなハッピー作業するまでは
っていうことだったりとかするっていうので
この辺はなかなか難しいねって思いますね
きんじょうひでき
そうですよね
だからこそなんでこれ10ヶ月そんな時間がかかるんだ
っていうのに対してしっかりやっていかないといけないから
よしじゃあ構造化して見積もるじゃないのか
予測可能なエリアにソフトウェア開発を落とし込むぞみたいな
デマ力が癒しを燃やしているわけですよね
げんえい
そうですね
じゃあそれがどうやったらうまくいくのかなみたいな話ですね
36:04
げんえい
そうですね
