ソフトウェアの開発にかかる時間の見積を廃止したいプログラマーたち 150
ストーリー by headless
無駄 部門より
無駄 部門より
本家/.「The Programmers Who Want To Get Rid of Software Estimates」より
ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。
記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事を先送りにする儀式となっている。」とのことだ。
Mediumの記事で最初にリンクしているツイートは2年以上前のものだが、実際に見積がなくなるまでにはどれぐらいの期間が必要だろうか。
こうなる (スコア:4, おもしろおかしい)
「ディレクトリ作って、そこにファイルを置いて、SVNにコミットするだけのプログラム。簡単でしょ?」
「簡単っすねー」
↓
「あ、ディレクトリは "dir1" だけじゃなくて "dir1/dir2" と数回層の指定が来る場合もあるからね」
↓
「あ、ファイルは複数のファイルが来るよ。既存のファイルと同名のファイルが来た場合はエラーを報告してね」
↓
「あ、排他制御とか当然やるよね?見積りに入ってるよね?」
↓
「あ、そもそもSVNに同名のディレクトリがあったら、先にcheckoutしてからね。そこにあるファイルと同名のファイルが来た場合は、エラーじゃなくて、黙って上書きでいいよ」
↓
「あ、」
↓
「あ、」
Re:こうなる (スコア:3, おもしろおかしい)
ちょっと前にYahoo!だったかで見たツィートのネタを思い出した(笑)。
曰く「俺なんか喋り始めに必ず「あっ」って言うから小林製薬ってあだ名ついたからな」
きっと、その発注元は小林製薬に違いない。
Re: (スコア:0)
それ、人間がやる作業なら要求が後から増えてもそんなに問題がないんだよな…
Re: (スコア:0)
クソワロタw
他の産業との違い (スコア:3)
> プログラマーに責任をもって仕事をさせるために見積が必要だと考えている
こんな理由で作業者に見積をやらせてる産業って他にあるのかな?
Re:他の産業との違い (スコア:2, 興味深い)
でも見積もりは、プログラムを知らない監督者との接点で有り、止めると、
監督者としての旨みだけ手に入れて、実質的な監督は作業者にやらせる
だって、接点が無いから
となる。
さらに、
見積もりで絞りに絞れば、向こうから実質的な監督を**無償で**志願して
くるだろう
ともなるでしょう?
要するに、実作業(プログラム)を知らない監督者を作ったのが間違いで、
例外なく『鶏小屋の狐』症候群になる。
まぁ、今次バブルの原因は明確にITが桁違いの金喰いだったので、
それをなんとかするための拘束具としての、実作業を知らない監督者
だったのかも知れませんが、
もう、どう考えても退場していただく時期なのかも知れません。
Re:他の産業との違い (スコア:2)
> どの仕事でも同じです。
いや、だから具体的にどの仕事?
見積もりは「1日・2日・たくさん」だけのほうがいい (スコア:1)
人間は、アフリカのサバンナでサバイブしていた時代と同じ遺伝子で作られている。
だから人間が先天的に扱える数なんて「1つ・2つ・たくさん」くらいのもの。
また、サバンナでは3日以上かかるプロジェクトは、日数ではなく季節単位で動いていたはず。妊娠・出産とか。
3日以上の見積もりなんて、「これくらい言っとけば大丈夫かな?」という数字でしかない。
見積ねぇ (スコア:1)
「この作業、どれくらい掛かる?」と聞かれる事より、
「この作業、XX日までに仕上げてね♪」と言われる事の方が多い、
と言うか前者はほぼ無いような気がする。:-)
Re:見積ねぇ (スコア:1)
スケジューリングの話と、見積もりの話は別なのではないですか?
納期って言ったって、同時にかかえてる仕事との兼ね合い、
プロジェクトなりグループなりのリソース(人的・コンピューティングリソース含め)の兼ね合い
なんかは やっぱ SE側じゃないとわからないことも多いので、
見積もりは必要なんじゃないかなと思うんですが。
記事のとおり、見積もりの正確性が低いのは確かなので、
30分単位で見積もれといわれたら無理ですが、
0.5人日単位ぐらいで見積もるのは可能なんじゃないかな。
で、あがってきた見積もり合計に バッファを 2割みて、
余裕があれば全体にさらに1割プラス。
コーディングそのものは従来品の改修で済んで30分で終わっても、
データができあがるのは40時間後、というようなこともなくはないので、
こういう場合は、計算量のオーダをあらかじめ見ておいて、
インプットの量から ゴールタイムを予測して 1.2掛け、ですかね。
Re: (スコア:0)
デスマ待ったなし
Re:見積ねぇ (スコア:1)
>コーダーだから見積しないのが普通でしょ。
コーダーだから「見積もりしない」のを認めるなら、
>計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。
「責任持って仕事させる」の必要も無いよね。
結論:いずれにせよ、日本のIT業界は狂ってる
Re:見積ねぇ (スコア:1)
デジャヴすぎる。
「狂ってる」という結論を持ち出すと、論理立てた考えがすべてリセットされる気がする。
物事を淡々と説明するとだいたい「狂ってる」という結論になる [togetter.com]
ヤクの毛刈り (スコア:1)
日本語だとbkブログのエントリ [0xcc.net]がわかりやすかった
結局、妥協点があるのかないのか (スコア:1)
プログラマーによる開発の見積りの精度が高くないので、見積もるのは無駄だ。だから見積もるのをやめることを主張する。
その理由はヤクの毛を刈るようなものだから、と言っている。
ここで「仕様が変わるから」と愚痴っている人たち、スレッド冒頭では「仕様が変わるから」無駄なんてそんな程度の低い話はされてないと思うよ。
仕様が変わらなくても、見積りは無駄でやめることを主張するプログラマと、
その見積りを締め切りのように扱うマネージャの間に妥協点はあるのかないのか、どうなんだ?
それにこたえてなければそれこそ時間の無駄だとおもうけど。
定数ではなく確率分布では (スコア:1)
○日で完成しますでは不完全で、
○日までに完成する確率は△%ですが正解だと考えています。
http://www.publickey1.jp/blog/09/post_56.html [publickey1.jp]
ジョエルのEBSもそれを基にした計算式で高い精度を叩きだしているみたいですし。
http://local.joelonsoftware.com/wiki/%E4%BA%8B%E4%BE%8B%E3%81%AB%E3%82... [joelonsoftware.com]
問題はその考え方を上から下まで理解してないといけないということでしょうか。
今までの経験では必ずどこかで不理解者が登場し、
その先から%の表記が消えて頓挫しています。
サグラダ・ファミリア聖堂 (スコア:0)
時間は金だからな。時間の見積もりをしないというのは、上限無制限にならないかな?
それとも一括受注ではなく、サービス化する?
結果、サグラダ・ファミリア聖堂のような長期プロジェクトが林立することになるのかな。
例の特許庁の基幹系システム開発プロジェクトに採用したら、どうなっただろう?
Re: (スコア:0)
時間じゃなく成果物の評価額でいいんじゃない?
たとえ1時間で完成できるものでも、誰もが評価する素晴らしいものなら1億円でもいいだろうし。
変な話、ピカソとか著名な芸術家が、ちょちょっと筆をつけただけの作品もたぶん莫大な額の作品になるだろうからなぁ。
Re:サグラダ・ファミリア聖堂 (スコア:1)
だったら完成する前に契約しないで完成してから営業しにこいよって話でしょう。
開発者の能力を外から見て、勝手に完成見込みとリスクを織り込んで、保険をかけておけってことなら
そのコストは商品価格に転嫁しなければならなくなる。
Re: (スコア:0)
プロジェクトの内容が現時点で解決できるか (スコア:0)
正確な見積もりは、今のメンバー(知識+次の使う手法を使える)、使う手法(アルゴリズム)によって確定するので、
未知の問題(不確定要素がある)に対してのプロジェクトに対しては見積もれない。
→不確定要素があれば納期が延びるが、伸ばしている間に解決出来なければ見積もりは失敗(開発者「やべー、現状、この手法だとあぶねーな。」)
→ゼロリスク思考だと、他社を抜けれないよ? (ビジネスによる邪魔 from マネージャー「見積もりよこせ」)
→グダグダ DEATH (あーあプロジェクト失敗だよ、何が原因だっけ?)
SIerに属していた時、やたらと見積もりにうるさく、手法がグダグダ、解決できねー、おそまつだったな。
Re: (スコア:0)
問題はプログラミングの見積もりが不可能なことじゃなくて、見積もりアルゴリズムの評価が正しく行われないことじゃない?
同じ処理から同じ結果が得られるのは同じことをしてるからで、問題は同じことをしてるからじゃないかな。
後出しが無ければ (スコア:0)
後で仕様が変わったりしなければ
時間は見積もれるのですがねぇ
変わらないことが悪だと思っている方々の
なんと多いことか
そんな状況で時間見積もりがーとか言われても
覆されるの確定なんで見積もるだけ無駄
仕様変更の際は人・物・金・時のすべてに
再見積もりが必要と前提を整えてからでないと
正にお話にならない
# 結局不都合の押し付け合いだから力がものをいうだけなんだよね
Re:後出しが無ければ (スコア:1)
ある程度のマージンなどを見込みつつ、実動作を確認して(そして場合によって一部妥協もあり)であるなら、そうかもですね...
M-FalconSky (暑いか寒い)
Re:後出しが無ければ (スコア:1)
見積り指示が出た時点で仕様未確定の案件が多いですね。そりゃ無意味な仕事になるわな
Re: (スコア:0)
例えばある項目が、1つだけ、複数(個数固定)に拡張されうる、複数(個数可変)に拡張されうる、の
3パターンでは、使えるモノからアルゴリズムまで、全然変わってくるからねぇ。
せめてその辺を理解して、ここの仕様なら後から変わっても大丈夫だから当初は曖昧にしといてもOK、とかやってくれれば良いんだけど。
後出しするのは、どっちも同じ (スコア:0)
仕様が確定した時点で、再見積もりすれば良い(というか普通はする)。
逆に仕様変更がなくても、納期直前になって「間に合いません」とか言い出すヤツも多い(それまでは順調だと報告しておいて)。
Re:後出しするのは、どっちも同じ (スコア:1)
仕様が確定した時点で見積もりして開発開始したのに、
8割方進んだところで仕様変更が入ったりするのはよくあること。
その仕様変更が素人の思いつきそのままの無謀な話だったりするのも稀によくある。
はい、デスマ確定。
ψアレゲな事を真面目にやることこそアレゲだと思う。
Re:後出しが無ければ (スコア:2)
完璧な仕様書はソースということになりますね笑い
見積もりをなくすなら、定額報酬も廃止 (スコア:0)
時間の見積もりをなくすなら、給料という時間に対する定額報酬も廃止する必要があるんじゃない?
全部成果報酬にするなら、時間の見積もりをなくしてもいい。
Re: (スコア:0)
金の面ではそうかもしれないが、ある期日までに使えなければっていう制約はなんにでもあるから。
プロとしてやるには、どうしてもあって、完全な解はおそらくない課題
Re: (スコア:0)
労力と等価以上の報酬を支払えるなら、いいんじゃない? でも労力は納品より前に知りたいから、やはり見積もりが要る。後から言い値ではちょっと。
見積もりが外れなきゃいいんだよ。
Re: (スコア:0)
特定のコンサートイベントのための開発なら、そのコンサートイベントまでに開発できなきゃ、損害を補てんしなければならない。
芸術作品を勝手に作って誰かが評価してくれるのを待つっていうならそれでもいいけど
今あるニーズに合わせて作るなら期間的な制約は少なからずあるよね。
ちがう (スコア:0)
金額にあわせて、手を抜く。
やってみないと何時間かかるかわからない (スコア:0)
もんだと思ってましたが違うんですかね。
Re: (スコア:0)
Re: (スコア:0)
見積もりを算出する時間の見積もりはどうなっているんだろ。
見積もりだから明日まで、なのか、(えいやー以外のなにものでもない)
はい見積もりですね→(実際にやってみる)→1ヵ月後「1ヶ月かかります」
後者なら間違いないのに。
Re: (スコア:0)
(複数の業者に見積もりさせて)やっぱり、契約しないことにしました、と言われたりすることも想定すると、1ヵ月分の見積もり料もほしいですね。
Re:やってみないと何時間かかるかわからない (スコア:1)
個人で開発しているなら事情は違うけど、既存のものの改修なんかだと実装が2だとしたら設計が8ぐらいの割合なんだよ。ソフトウェアは。
しかも正確に見積もろうとしたらほとんど設計しているのとほぼ同じ。
10%の工数で出した見積もりなんかは結果的にブレまくると思うね。
Re:システム屋さんってお気楽なの? (スコア:1)
もう何度も何度も何度も何度も何度も、耳にたこができるくらい繰り返し言われてることなんだけど、
マイナーチェンジの新商品開発じゃなくて、新技術の研究開発なのよ。
だからあんたの指摘は的外れ。
ハイブリッドカーの基礎技術も持ってない自動車会社が、
「今年の8月までにハイブリッドカーをリリースすること」
と言った所で実現できないのは変わらない。
Re:システム屋さんってお気楽なの? (スコア:1)
なるほど、開発部門が「新技術の研究」レベルと思ってるものを営業側が無理くり商品に突っ込めと言ってくるわけですか。
それは無理ですね。
> ハイブリッドカーの基礎技術も持ってない自動車会社が、
> 「今年の8月までにハイブリッドカーをリリースすること」
> と言った所で実現できないのは変わらない。
ハイブリッド技術をどっかから買う選択肢を忘れてます。
Re:システム屋さんってお気楽なの? (スコア:1)
ああ、「8月」って適当なたとえじゃなくて今年の8月のことですか。
それでゼロから商品企画立ち上げて売れってなら、そこの一番の「得意分野」だったとしても無理でしょ。
自社開発か買ってくるかってレベルじゃなくてただのバカじゃないですか。
Re:システム屋さんってお気楽なの? (スコア:1)
>もう何度も何度も何度も何度も何度も、耳にたこができるくらい繰り返し言われてることなんだけど、
>マイナーチェンジの新商品開発じゃなくて、新技術の研究開発なのよ。
新技術の研究開発というと、いちいち全く新しいパラダイムの言語でも発明するのでしょうか?
Re:システム屋さんってお気楽なの? (スコア:1)
いや、「新技術の研究開発」というので、何か研究でもするのかと。
規格や単位系を新しく起こすとなるとそれは大変ですね。
私的なイメージはオーダーメードで建築物を作り上げるのに似ているのかなと思ってました。
Re:システム屋さんってお気楽なの? (スコア:2)
1 や 2 や 3 がソフトウェア開発で時間の見積もりが難しい理由なのはよくわかるけれど、 1 も 2 も 3 もまさにソフトウェア開発の本質だと思うので、それを「ソフトウェアとは全く関係ないところ」と表現されると違和感を覚えるなあ。
Re:システム屋さんってお気楽なの? (スコア:1)
いや、本当はお気楽でないことは想像できますよ。
自分は割と小っこい機器の組込メインでしかも生産品より前の先行部署なので、納入先の力関係とか想定外のさらに外ですが
生産部門に直結してないから感覚がぬるいと叩かれまくってます。
Re:システム屋さんってお気楽なの? (スコア:1)
問題として書いてることってソフトウェアと本質的に関係ないよね?
ソフトウエアの開発だから時間の見積もりできないんじゃなくて、ビジネスの進め方として問題があるから時間の見積もりができないのでは。
Re:出来高制にしてもいいけど、生きてゆけないよ? (スコア:1)
この業界が音楽業界やアニメ業界のように
「この仕事に携われることが幸せ」
とか
「いつかは自分も一発当ててのし上がる」
って考えで安月給でも頑張る人材を集められると!?
Re:土木系から見て・・・ (スコア:2)
ビジネスモデルが土木・建設のまねっこ後追い劣化コピーで安定しているものが多いというそのまんまのことでして。
そんな意味では後進分野でしょうね。
Re:土方 (スコア:1)
センチュリ(百人隊長)のあたまかずを土木分野と同じだけ揃えれば見合う
という革命的アイディアを唱える人が
その前に登場して大きな声で何もかも台無しにしてしまう気がする。