「人類がソフトウェアの工数を正確に見積もるのは、もはや不可能である」｜はまあ

はじめにまずこの話をするのにあたって「正しい見積り」という伝承を語らねばならない。 次の章は、筆者が観測してきた100社ほどの開発関連会社におけるトレンドを雑に集約したものなので、当然ながら観測者バイアスがかかっている。 したがって、ITエンジニアのみなさんご自身の体験とはだいぶ違う事もあるかもしれない。その点はご了承願いたい。 ところで、カンブリア爆発のように、ある事柄がきっかけて急激に世界が変わっていくことは産業界にもよくある。 たとえば蒸気機関の登場が産業革命を引き起こしたように。 また、システム開発にも古代と現代を区切るほどのエポックメイキングな出来事が一つあると思っている。 それは「GitHubの台頭」。 本論では、この古代のことを「前GitHub時代」と呼ぶことにする。 ※厳密に言えばGitHub以外にも様々なソースコード共有サイトやリポジトリシステムは存在した。が、それらをコ

[digo]

むかし頼まれてExcelで社内見積もりツールを作ったことがあって「PITS」と名付けた。「pie in the sky（絵に描いた餅）」の略だったがそれは秘密にしといた。

[Keisuke69]

そもそも人類が開発工数を見積もれるなんて幻想なんだよ、きっと。3日で作れる＝3日で仕上げるように努力します、でしかない気がしてる。

[ghostbass]

アジリティが効果あるのは短納期で済むものぐらいで所謂si が作るのは100人月を超えるような巨大なモノリスなのでアジリティよりSTRとVITなんだろう。

[onefootinthegrave]

とりあえず遅れてるか進んでるかの目安のとめに、えいや、で一本引くのが見積。修正していかないとダメなんだけど年次予算とかあるからね、、、つらいね、、、

[hroka]

“幅」 が爆発的に広がってしまうという現象をもたらしたのだ。”

[iselegant]

簡単に見積もれるようなソフトウェアにはそもそもビジネス価値がないはその通りで、不確実性を探ることこそが差別化になる。

[Amigomr]

価値が分かっていても正しく見積もるのは難しい。過去に作ったものと似ていても想定外に難しかったり。受注側のリスク予測が甘かったり、発注側の要件定義が不正確だとそうなるが、どこまでやれば大丈夫かは不明。

[hogeaegxa]

リプレースみたいなのでも不確実だらけのソフトウェア開発で、うん百人がかかわる、うん千うん万のタスクの工数を、事前に正確に把握するのは預言者の領域だと思う。ノストラダムスならできるのかもしれない

[rryu]

正確に見積もれるのはモノが完成した時であるというソフトウェア開発では今も昔も正確に見積もれる事はないと思う。致命的になったのは金額が小さくなってもブレの幅は変わらないからな気がする。

[zuzu_sion]

最初から見積もれないのは当然。社内ライブラリ消滅は業界全体の共通言語が出来たという時代の変わり目。数年もすれば昔通りになるよ。

[qwerty86]

もはやもなにも、最初から出来ないことを出来ると言い張っていただけだろう。

[GEROMAX]

正確な見積もりは無理だけど、まったく見積もらないのもヤバい。

[yug1224]

事業会社でウォーターフォール開発やってるけど、各工程の着手前に毎回何をどれくらいで実施するか予定立てて、進捗に問題があるなら、その都度スケジュールや要件の調整をするのが普通だと思ってた。

[otihateten3510]

安易にライブラリー増やす案件は地雷

[beaber]

後で読む

[Kukri]

先陣を切るリスクだね

[dekokun]

Be Agile!

[slash_01]

ソフトウェア開発の管理的なやつは、おおよそのアタリつけてリスク洗い出して、アウトプット見ながら適時計画を実態に合わせて補正する、ていうのを繰り返していくしかないかな。

[yarumato]

“人のビジネスをコピーして資本で叩き潰す＝簡単に工数を見積もれるスタイルは手堅いが、開発がつまらない。ビジネス価値がない。つまり、今の時代に楽しい、価値ある開発は簡単に工数を見積もれない。Be Agile!”

[for-my-internet-demo]

ブコメの「絵に書いた餅」クスッとしてしまった

[NMP300]

“「簡単に見積もれるようなソフトウェアにはそもそもビジネス価値がない」” なるほど・・・🤔