作業量の見積もり
CS Harmony Radioの番外編を始めていきたいと思います。よろしくお願いします。
お願いします。
2回前から始めました、明日から使えるチップスシリーズの第3回目。
簡単にって言いながらちょっと喋ってましたけど。
簡単と言いながらちょっと難しいところもありますよね。
今回はですね、作業見積もりのやり方みたいなのを話せたらな。
見積もり制度みたいな話ですか?見積もり制度を高めるみたいな?
そんな話です。
それはむちゃ聞きたいですね。
ちゃんとできてる人も結構いるので、そういう人はあんまり価値ないかもしれないですけど。
結構見積もりに甘い人っているじゃないですか。
その、だいたい例えば1時間で終わるみたいな話をした時に、
1時間で終わるっていうのが正しいっていう話として、
例えば2時間をかかっちゃったっていうのはダメだと思うんですけど、
30分で終わっちゃったっていう話は?
私そのレベルの話してなくて。
なるほど。
できない人って、なんだろう。
そもそも見積もれない人がいるんですか?
見積もれない人がまずいて、1人。
1人っていうか。
1人。
具体的な人をイメージしてるんですか?
具体的な人もイメージとしていますし、何かそういう人はあったことはありません。
見積もりそもそもできないですっていう。
知識がない場合もあるので。
あとは、なんだろう。
金曜までに上がりますって言ってるけど、全然終わりませんみたいな。
なるほど。
じゃあちょっと言い方変えると、期限守らないっていう人ですよね。
はい。
それはよくいますね。
しかも全くそれ手についてないよねとか。
何やっていいかわかってないよねみたいな人たまに。
それだとなんかピンときますね。
確かに期日守らない人でフォローしてから動き出すみたいな。
この前やるって言ってて、締め切り直前なのにこっちから確認しないとやってないってことがわかんないって。
それどういうことみたいなのは体験ありますね。
やらせる話というか、どちらかというとやり方の話なんで。
ちょっと今回その辺の話をしたいなと思って。
今話してるのは作業の見積もりなんですよ。
だから時間の見積もりじゃないですか。
自分がどう作業するか。
プロセス的な話、ちょっと難しいっぽい話です。
プロセスの処理の話なんですよね。
例えば資料を作るのに、この資料だったら見積もりは3時間でできますとか。
そういう感じですか。
3時間って時間が見積もりの数字になってて。
っていう感じなんですけど、あんまり良くない見積もりの仕方のパターンは、
直接その時間を見積もりに行こうとしちゃう。
それはどういうことですか。
言い方を変えると、作業量がどれぐらいかわかんないと実際見積もれないじゃないですか。
そうですね。
わかります?
作業量が見積もれないことがあるかって話ですか?
じゃなくて、作業量がわかんないと作業時間って見積もれないじゃないですか。
当たり前のことを今言ってるように言ってますけど。
成果物の規模の見積もり
当たり前のことを言ってるように聞いてましたけど。
聞こえてますよね。
聞こえてます。
多分、作業を見積もれない人の特徴って、作業量を見積もってないことが多いんですよ。
だから、例えば資料を作るって言ったときに、
10ページなのか100ページなのかを確認せずに3時間って言ってたりする場合があって。
なるほど。
それってあれですね。
明日から使えるシリーズの最初のレビューの話のゴール設定できてないよねみたいな話。
そうですね。それにほぼ近いと思います。
だから作業量をまず見積もるっていうのが鉄則です。
だからプロセス的に言うと、成果物の規模をまず見積もらなきゃいけないんですよ。
何を作るのか、この作業で。
それの量がどれぐらいなのっていうのを最初に見積もらなきゃいけなくて。
で、それが実際自分にとってどのぐらいの速度でできるかっていうのをまた次の見積もりにして。
あとはどれぐらいの量があるのっていう全体像を知らなきゃいけない。
それが必要です。
なるほど。問題点の話がちょっと分かってきます。
分かりました。ありがとうございます。
なので、ここの回で言いたいのはほとんどそれに尽きてます。
作業を見積もりするときは、まず作業する成果物側の分量、規模を見積もりましょうが最初です。
特にやってみないと分かんないパターンがたまにあるので厄介なんですけど。
私も研究者なんで、研究みたいなやつやってみないと分かりませんみたいなことをやるときがあるんですけど、
そのときにまずその作業を見積もりするためにはプレ調査みたいなのをした方がいいですね。
全体像を知りに行くっていうことをしますと。
だから規模を見積もれないみたいなとき、もともとそもそも成果物がどれぐらいのものなのか分からんっていうときは、
成果物の量を調べるっていう作業をした方がいい。
それ自身はたぶんそんな時間がかかんないので、物によりますけど。
それをまずやって、そこから全体像を把握して、それで詳細の作業見積もりにしていくというほうがよくて。
これ自身、我々がやっているクレプモデルのワークショップでも一番最初にやるんですよ。
最初に全体像を知るっていうのをやって、その後に各業務、業務の数何個あんのっていう話ですね。
ワーク取りに行かないと全体作業力見積もれないので、最初にそれやりますっていう。
そこが最初に入ると特に分かんないっていうのがよくて。
それに基づいて、あとは作業の規模ですかね。
規模に合わせて自分だとどれぐらいかかるかっていうのを見積もっていくと。
もし分かんない場合があるじゃないですか。
自分がどれぐらいその規模、例えば100枚のページを作ってもどれぐらい作業速度かかるのかって分かんない場合があるんで。
その場合は抽出してやると。
例えば1ページ、2ページまず作ってみて。
サンプルで試しに作ってみて、それでフェールミスを予定するみたいな。
そういうことです。
なるほど。
そういうやり方が作業見積もりとして精度良くなると。
この辺のやり方ってググってもらうとあるんですけど、
アジャイル開発って使われてるプランニングポーカーっていうのがあるんですよ。
この辺雑談ベースですけど。
プランニングポーカーっていう手法は専用のカードもあるんですけど、トランプでもいいんですけど。
トランプとかで適当な、アジャイル開発ってモノの開発なんですけど、
適当な機能、みんなが知っている適当な機能。
例えばシステムにログインしますとか、ログイン機能、認証機能かな。
認証機能みたいなのを、例えば2にしますと。
2っていうことに意味ないんですけど。
2にします。
例えば5人ぐらい集まって、その2っていうやつに対して、
それぞれの機能、例えばメールとかだとメールを送る機能は認証機能よりも重たいか、
それとも簡単か、比較していって。
見積もりの精度を高める方法
例えばそれの重たさが3倍ぐらい重たいねと思ったら、
2に対して6なんで、6って数字出すとか。
それをみんなで異性の出で出すんだよ。
一応近しい数字を取っていくのと、すごい離れてる。
例えば1と12とか出してきた場合、離れすぎてるので、
なんで1って思ったの?なんで12って思ったの?
一旦みんなで話して、もう一回出し直すとか。
っていうので、真ん中ぐらいの数字に抑えていく感じで、
規模を見積もっていくと。
ここで言っても2とか1とかって数字って別に単位付いてないんですよ。
なので、そこに対して、例えばさっきで言うと、
ログイン機能を実際作ってみるんです。
作ってみると、それが1日でできましたと。
そうなったとすると、数字で6って付いてるやつは3日でできることになる。
それで全体の見積もりができますよねっていうのが、
アジャイル開発、プランニングボーカルというやつ。
私もやったことがあるんですけど、まあまあ当たるんですよ。
人間の感覚って面白いもので、その辺の規模感みたいなのが大体当たる。
全体権は大体正しいみたいな話もよくありますよね。
そういう感じでものを見積もっていくと、
作業って見積もりやすいかなというので、
意識として成果物の規模を見積もることから入るといいよという話。
私の知り合いでも、新人の頃に指導されたっていう話聞いたことありますけどね。
全然知らない分野の仕事だったんで、ちょっとよくわからなかったんですけど、
いつまでできるって言われたら分かりませんって答えざるを得なくて、
その時に上司からサンプルもらえと。
全部100あるんだったら、2個ぐらいサンプルもらって、一体実際やってみろと。
それの掛け算になるから、それで見積もるんだよって教えてもらったっていう話。
それはある意味同じ話かなと。
感じで作業を見積もっていくと、大体ブレないっていうのと、
わからんことでも一応見積もれるので、平和に生きていけるという話かなと。
見積もりそもそもできないっていう話と、
分かんないやつどう見積もるかの話の2つということですね。
2つ同時に話しました。
見積もりについての考え方
明日から使えるって話だと、分かんないやつどう見積もるかは、
今のプランニングポーカーっていうやり方でやると、
ざっくりでもいいから、数値化できるからいいですよって話ですね。
そうですね。
基本的にアウトプットの分量を意識ずっとするっていうのが、
たぶんコツなんじゃないかなとは思います。
そうですね。
前者の話はゴール決めてなきゃそれは見積もれんかなって思っちゃいますけど、
決めずに返事する人が一定数いるっていうことですよね。
一定数いますよ。
とにかく作業から入るタイプの人とか結構いますけど。
確かにそうかなと思うのは、
GHHH的なようは条件確認しないまま、
分かりましたって言って終わる人もいるんで、
そういう人は確かに確認してないけど、
どうするんだろうっていうことはあるなとは思っていて、
そういう時にフォローを受けたりしてる場面もあるんで、
なるほどなって思いながら聞きましたけど。
チップス的にはそんな感じかなと思います。
条件はやっぱり最初に確認するっていう習慣をつけた方がいいですよね。
それはもう。
これが明日から使える話としては結構大きいかも。
一番大事。
CSでもそうですけど、相手の期待値ちゃんと確認しとかないと。
資料作ってもさっきね、冒頭にあったように100ページなのか10ページなのかによっても、
その期待してる内容がだいぶ違うじゃないですか。
全然違うので。
ライトでいいよサクッとって言って1枚もの作ってだったら、
その日に作らないと多分遅いって思われちゃいますね。
100ページの壮大なものってしたら結局裏付けとして必要なもので、
大量生成できれば別ですけど、
そうじゃないとしたら結構ちゃんと調査とかしたベースで
どっかに発表するからいるっていう話なんで。
なんかその辺ちゃんと確認しないとやっぱりそういう疎応というか、
誤解が生まれてしまって、
頼んだものが出てこないみたいな話になるっていうのはありそうだなと思いました。
はい。
なるほど。
今日はそのところで。
はい。ありがとうございます。
ありがとうございます。
