スケジュールとタスクと見積もりと

あせって招待してもらったわりに、一度もPOSTしてなかった。
ずっと前から考えていて、最近また感じたのでここに記す。

開発を仕事としていると、必ず似たようなことがあると思いますが
「〇〇が欲しいんだけど、期間とタスクを出してくれ」
というようなことをよく聞かれます。

これが私には非常に難しい。

見積もりの話なんかは結構書籍があったりするので

Manage It! 現場開発者のための達人式プロジェクトマネジメント

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ソフトウェア見積り―人月の暗黙知を解き明かす
あたりを読んだんですが、私にはどれも「何々がほしい、いつまでにできる？」
という会社からの問に、すぐ答えられるような方法はないという風に感じました。

過去の開発から、定量的なデータをもちいて、次のプロジェクトの予測を
立てるということもある程度はできるとは思います。そういった点から修正などは、
まだ期間の予測が立ちやすく正確性があるものが出し易い(大幅な修正とかは別だが)
とは思います。ただ、程度の差こそあれ毎回違う物を作っていて、違う技術を
使っているような場合にはほとんど役に立たないと思うわけです。

なにかしら作るものがあり、仕様みたいなものがあったりなかったり
会社によって様々だと思いますが、最初の段階でわかっていることは実は
とても少なく、プロジェクトが進行するとともに、仕様にしろ、実装にしろ
理解が進んでいくのが普通だと思うわけです。

そういった点では、唯一プロトタイプは予測するのに有効に働く気がしています。
ただ、それはコードを書いて動かしてみないとわからないということで、できたときが
リリースするときだとほぼ同じなんではないかと。

他に問題として、会社や上司がこういった事に理解がない場合があり、なんで
スケジュール守れないのかとか、なんでこんな長い期間かかるんだとか
言われる場合があるわけです。そもそも正確性なんかほとんどないものを見て。

会社は売上や利益を上げるために、適切なタイミングで商品を出す必要がある
ということは重々わかっています。そんなもんなんとなくで、あとはがんばって
間に合わせろよこのヘタレという意見もあるかと思います。
ただ怖いのです。聞かれてなんの根拠もない数字をひねり出すことが。

最初はなにも決めずに作り始めて、進むたびにスケジュールが更新され
リリースできる日の確度が高くなっていくような形にはできないものだろうか。