突撃、俺のプロジェクト見積
インパクト狙いだけでタイトルつけるのやめなさい＞俺。
まぁそれはそれとしまして。一応XPをメインにする予定だったんですよね、ここ。でも最近デジドカ的消極的ウイルスにやられて随分と触ってなかったわ。
わはははは。笑ってる場合か＞俺。
だからという訳でもないのですが、ちょうど手持ちのプロジェクトが一段落つきましたのでそれを肴に無駄話をひとつ。
しかしまぁ今回も難易度こそ低かったとはいえ、やはり時間的／体力的には苦戦を強いられました。最後の最後まで気抜けなかったし。こんなん続けてちゃあ３年持たんぜ。
という訳で過去の過ちは繰り返さないぞ、という心意気の元（？）、今回使ったストーリーカードをひっくり返してみることにしました。前にもやっただろそれというツッコミもありますが気にしない。
という訳でこれがその詳細です。一番肝心なストーリー内容に関しては守秘義務が発生するため残念ながら公開できませんが、それ以外の数値だけでも、あればそれなりには話はできるであろう、という判断です。ご了承を。
（つーか普通こうやって実物のカケラ出すこと自体が世間一般には十分にご法度なんだけどね。まぁいいや細かいこと抜かすな。誰に言ってる＞俺）
ストーリーとは言っていますが、規模自体が小さいことと、突発的変更が多いであろうということから、実質的にはストーリー自体がタスクカードも兼ねています。詳細見てもらうと解りますがほとんどのストーリーが１日以内の見積もりとなっているのもその影響。
という訳でこれらを統計した結果がこれ。
稼働日数 17 ストーリー数 49+2 見積合計(日) 19.4 実績合計(日) 16.3 ホントに綱渡りだったんだな(^^;;;;。もし見積もりが正確だったら、土日出勤確定だったんだ。あ、そうそう、ひとつ自慢させてください。今回久しぶりに休日出勤ゼロであげたぜぇ！いえーい！・・・あ、なぜか空気が寒い。
とはいえ、なんで見積値に対して実績値が下回ったのか、ということに関してはちゃんと把握しておく必要がありそう。
ということでこんな統計も取ってみました。
多く見積もったストーリー 28 少なく見積もったストーリー 9 最大見積超過(日) 0.5 最小見積過小(日) -0.4 平均誤差(日) -0.06 まぁ見積と実績が食い違うのは当たり前のことなんですが、それにしては多く見積もってしまった（時間余った）ストーリーが多いよね、と。
で、詳細見てもらうと解るんですけど、ひとつ傾向があるんです。
どうも私の場合、１日未満のストーリー（タスク）に関しては余裕を多めに取るみたい。見積0.5→実績0.25、見積0.25→実績0.1、という感じで。これが「チリも積もれば」の形で見積値を削り取っていった、ということになるんでしょうな。
確かに考えてみればそうかも。TOCの「クリティカルチェーン」にも記述されていますが、人が見積もる場合「これだけあればまず大丈夫だろう」として、期待値80％以上の値を見積値として算出する。皮肉にも自らの行動で裏付けしてしたとも言える訳で。
ただし。
じゃあこれを見て、「だったら次はその余裕分も取っ払ってさらに短く見積もりできるよね」というのはあまりにも危険なんですよね。
というのも、今回少なく見積もったストーリー（見積期間内に消化できなかった）は９つ存在するのですが、幸運なことに（←ここすごく重要）、その値はいずれも0.5未満、つまり半日以内に収束している、ということが挙げられるんですわ。
だからもし見積4.0と思ってたストーリーが実際には8.0かかったとかなってたら。上のちまちまかき集めた余裕なんぞあっけなく吹っ飛ぶのは簡単に想像できますよね？
あと今回の場合、システム規模が小さかった、それにともなって実測とのバラつきも相対的に小さくなったということも考慮しておく必要がありますな。これが数ヶ月で数人かけて、となってくると誤差も大きくなるのは目に見えている訳で。バラつかなかないように祈ってるだけでは大して意味が無いと。
じゃあこれに対してどう対処していくか？
- 超過しそうなストーリーを早めに潰す
- 完了分の実績を元に未完了分の見積値を打ち直す
・・・こうなるんだろーな。まさに計画ゲーム。
今回は約１ヶ月の開発で、モノ自体は２イテレーションとして提供していったのですが、見積もり分に関してもこのタイミングで見直しかけてれば、終盤で薄氷踏む思いしなくて済んだのかもしれないな・・・。ちょっと次回気をつけよう。
じゃああとはちょっとした数値を拾い集めつつお茶を濁す。
区分 0 0.1 0.2 0.25 0.5 0.6 0.75 1.5 4.5 総計 通常 0 0.8 0.2 2.5 1.5 0.6 0.75 1.5 4.5 12.35 修正 1.3 0.4 0.25 1 2.95 その他 1 1 総計 0 2.1 0.6 2.75 3.5 0.6 0.75 1.5 4.5 16.3 数値は実績値。区分ってのは通常のが「これを作らなきゃいけないよね」のいわゆる普通のストーリー。修正ってのは不具合や仕様変更などで急遽付け加えられたストーリーです。その他は直前に発生したドタバタ作業（笑）。
これを見る限りでは修正自体にかけられた時間はわずか３日分なんですが。
実際に組んでる時には、この修正がこの数値以上に重くのしかかりましたねぇ。「あーこんなんじゃストーリー消化進まねぇよ！」とキレそうになってました。結局修正が入ることで、本来消化しなきゃいけないストーリーと、やり直さなきゃいけないタスクが一時的にとはいえパラレルになってしまう。これは数字以上にストレス感じます。
自分の場合一人プロジェクトなんで必然的にどれからやるかの決断も全部自分でやらなきゃいけない訳ですが、もし複数人で進めてる場合はマネージャークラスが「まずはこれ！次はこれ！」とパラレルにしないようにする。開発者には目の前のストーリー／タスクに集中させるといった動きが必須になると思いましたな。
完了後変更 0 0.1 0.2 0.25 0.5 0.6 0.75 1.5 4.5 総計 あり 0.3 0.4 0.75 0.5 1.5 4.5 7.95 なし 0 1.8 0.2 2 3 0.6 0.75 8.35 総計 0 2.1 0.6 2.75 3.5 0.6 0.75 1.5 4.5 16.3 次。ストーリーが完了した後に再修正が走ったものと、そうでないのとを分けてみました。ここがありになってる、ということは結果的にそれまでにストーリーにかけた時間はゴールに直結していなかった、という判断になると思うんですが。
まぁ再修正ありの時間を認めないことはアジャイルを捨てるということを意味するのでこの数値自体は別にいいんではないかと思います。ムリヤリ前向きに言うなら、顧客の要求満たすために約８日分捨てたぞと（笑）。
逆にもし今回がウォーターフォールだったとしたら。
・・・・わはははは。乾いた笑い。
まぁこの数値見るといかに「１回でびったし要求にあったモン作るのかが至難の業か」ということの証明にもなりそうです。
2/5 2/6 2/9 2/10 2/12 2/13 2/16 2/17 2/18 2/19 2/23 2/24 2/25 2/26 2/27 総計 1 1.5 2.35 0.75 0.55 0.3 0.8 0.25 0.5 1.2 0.2 0.8 0.2 4.6 1.3 16.3 最後にこれ。作業日別の完了実績分類。ブラウザによっては横に長くてすまん。
こうやって見るとムラがあるよねぇ。一応弁護しておくと１日分の仕事はしてるんですよ。それでも0.3とか0.55というのが出てきちゃうと。結局打ち合わせとか電話取次ぎとか雑用とか。そうゆうのにも時間は確実に取られてるってことなんでしょうな。
その一方で2/9の2.35とか、2/26の4.6とか、でかいストーリーが完了となることでぽーんと数字跳ね上がる。こんだけ開発という作業自体にも波があるってことなんでしょう。まだまだ数字だけでは表わせないもんも山のようにあるぞ、と言われてるよーな気がする。
という訳で今回なんかまとまりがありませんが。いつもだろ。こほん。
んじゃとっとと逃走。